Denise "Fish" Fishburne

Author Archives: Denise "Fish" Fishburne

Tips from a Network Detective

Put your detective hat on your head and your Network Detective badge on your lapel.  It’s times for another installment in the Network Detective Series.

Are we going on our first “case” together?  Nope.  Not just yet.  ?

In this series I’m not going to be able to always call out every time my “techniques” and “methodologies” steer me one way or the other on a case.  But over time you will notice there is a thread in there.  A guiding framework and methodology.

So before we go on our first “case” together… I want to pass on to you what are really my major guiding principles for when I’m on a case.  The “TOP” tips that I think have the biggest return on your time investment as a Network Detective.

helpful_tips_74943355

  1. Be Methodical
  2. Know What is Normal (Knowledge is Key)
  3. Get to the “Crime Scene” as Fast as You Can
  4. Have “Crime Scene Maps”  that Help and don’t Hinder
  5. Let the Clues and Evidence Guide You
  6. Learn and Improve

Tip #1: Be Methodical

Detection is, or ought to be, an exact science and should be treated in the same cold and unemotional manner.

-Sherlock Continue reading

Techniques of a Network Detective: A New Series

Put your detective hat on your head and your Network Detective badge on your lapel.  Introducing a new blog series – Techniques of a Network Detective.  This series will focus on the detective work (troubleshooting side) of our jobs as network engineers.

For over 30 years I’ve been playing in the “world of IT”. During those years there have been a lot of changes in our world. But through all that change, there has been a thread, for me, that has always remained constant. A thread and a passion that always seemed to be with me in every job over all these years.

Troubleshooting!

Being a “Network Detective” is much the same as being a regular detective in many ways.  As a Network Detective we get put on a “case” – the “Case of the Missing Packets” maybe.  We go to the crime scene and try to find answers so we can solve the “who done it”

nd1

When a “crime” happens you need to be right there interviewing the suspects, surveying the crime scene, asking the right questions.  Trying to quickly figure out what is happening, where it is happening, and why it Continue reading

CiscoLive 2016: ‘Summer Camp for Geeks’

The other day I was talking with a friend about my summer plans. As we were talking about July….. my face apparently lit up and my voice got all excited and happy when I mentioned CiscoLive.

“What exactly is CiscoLive?” she asked.

I answered, “CiscoLive is my absolute favorite work week of the entire year. Has been since my first one back in 2006.”

“What do you like so much about it?” she asked.  ……

My answer to her?  ?

“It’s like a week long Summer Camp for Geeks”

july

Why I Love Cisco Live US

  1. Learning & Sharing Knowledge
    1. Breakouts, Technical Seminars, and Labs
    2. Meet the Expert
    3. Lunch and Learn (Formerly Table Topics)
  2. Social Media Fun

Learning & Sharing Knowledge

Learning… learning… learning ….. learning.   I just love learning!  For me… learning from others and passing that on is one of my passions in life.

And WOW is there knowledge to learn at CiscoLive!

Of course, I have never been to a CiscoLive as a non Cisco employee.  Nor have I ever gone and not been a speaker.  So, for me, CiscoLive has always involved me prioritizing technical knowledge sharing/teaching with CiscoLive Continue reading

My Current IWAN Analogies

I use analogies. Just how my brain works…. and how I sometimes learn and teach.  Token-ring source-route bridging analogy was “breadcrumbs thru the network”. Analogy for DLSw+ was a boat getting the breadcrumbs over water between 2 islands.

I think I like analogies cause…. to be superbly honest… when I came to work at Cisco back in 1996 I only knew SNA.  I did NOT know IP.  I was quickly immersed into learning IP. But I mean seriously… using acronyms to explain other acronyms you don’t understand? Don’t get me started!

Ready to play? Yea yea… my brain jumps around with varying analogies. If one doesn’t hit ya maybe the next will.  :)  Happy nerding!

 

Waze on Steroids

wazeImagine you own a rental car agency with 2 locations across town from each other. Your employees are constantly driving the cars back and forth between the two locations to balance out inventory.

If the employees hit issues during the drive (potholes, glass, mud, sand, dirt, major traffic, construction) this is going to cost your company.

So you can see how knowing what is going on via the varying paths between your locations is critical to your Continue reading

FishNet: Single Page Resources for all Things Fishy on the Net

Introducing to Networking with Fish a new page —- “FishNet”.  :)

What is FishNet? Imagine “casting a net” out on the Internet for all “Fishy IPv6” – in other words… for all the stuff I’ve written, taught (CiscoLive), or YouTube’d that is IPv6 that is somewhere out on the internet.

Topics thus far that I’ve cast a net out hauled in thus far are BGP, DMVPN, IPv6, IWAN, Multicast, and Troubleshooting.  :)    I’ll be keeping them current as a “single source” for all things “Fishy” out on the internet for those topics.

Happy nerding!

fishnet_menu

Going to CiscoLive US 2016? Don’t Forget Your Kilt!

I don’t recall the exact details of how “#KiltedMonday” started last year at CiscoLive US 2015.

I just know

ucgod_kiltkiltedmonday

 

  • I’m SO joining this year!  — Just ordered my kilt.

speaker

 

  • Scott (@ScottMorrisCCIE) is not only planning on joining this year… but he is hoping it falls on the day he will be presenting scott

 

 

 

 

vBrownBag: Techniques of a Network Detective

An essential part of running any network is being able to quickly diagnose and resolve service impacting events. But how does one do that in the world of IT where the only thing constant about technology is the constant change? We need to lean more heavily on the troubleshooting methodology and approach.  On the “techniques” of being a Network Detective.  How does one work towards solving ANY  “who done it”?  Simple…. one  Gathers the Facts Collects the Clues Follows the Evidence Interviews the Witnesses, and Questions the Suspects We will take this approach and show how one can use this and apply it in troubleshooting any networking “who done it”

detective_vbrown

Looking for more on some of the Techniques of a Network Detective?  Check out CiscoLive on Demand Library for BRKARC-2002 or my blog on Packet Pushers. Note: CiscoLive On Demand Library is completely free.

Just click on the one you want.  :)  Have fun!

packet

detective

 

vBrownBag: Troubleshooting Multicast High Level

For “basic” multicast I have always found that >70% of the problems I troubleshoot end up being the same things over and over and over again.

  1. Missing “trigger” to “pull” the multicast down to the receiver
  2. Multicast Distribution Tree (MDT) not built cause router doesn’t know
    1. WHO the root of the MDT is
    2. WHERE the root of the MDT is
    3. WHAT is the PIM RPF Neighbor toward the root of the MDT

Thank you, vBrownBag for asking me to present this.  :)   It was lots of fun.

The Cure for Network Downtime is Not Just Technology

Design and tune your network all you want. But if your company doesn’t also have a culture of high availability, your High Availability and Fast Convergence is not complete.

**This blog is a formatting cleanup and update to a previous blog I posted in 2011 on NetworkWorld.

You just finished watching a CiscoLive session from the online CiscoLive On Demand Library and now you want to run and start figuring out the alphabet soup of choices and decisions that is High Availability (HA) and Fast Convergence (FC) – NSR, NSF, GR, BFD, SSO…

Happens all the time whether it be from reading, classes, discussions with fellow engineers, or in my backyard in the Cisco Customer Proof of Concept lab (CPOC)… You take the proverbial magnifying glass and pair it up with your new found knowledge and proceed to give your network a good looking at while asking the question:

“What can be done with this network so that when a failure occurs the transition from failure to recovery happens as quickly as possible?” 

 

So once you figure that out for your network, and implement changes, you are done.  Right?  My opinion?  No, no, no and Continue reading

Clearing Up Some Misinformation RE: eBGP Multihop and TTL

Myth: You have to set ttl to 2 because it is decremented on the way to the loopback.

**This blog is a formatting cleanup and update to a previous blog I posted in 2013 on NetworkWorld.

 

Years and years ago I was trying to learn more about BGP and I was reading some book with a chapter on the topic.  Back then I pretty much believed that if it made it into a book it must be true and my knowledge had to be in error.  :)  So to say I was confused back then would be an understatement.

Why? Well ya see… they basically said that the reason one must set the TTL to 2 for eBGP peers that are directly connected, but peering with their loopbacks, was cause “the TTL gets decremented on the way to the loopback”

When I try to help someone deprogram this brain washing, I find pictures help.  So for those who’d like to get deprogrammed and learn the truth… Let’s go play in the lab!!!

bgp_ttl_0-100274774-orig

In the picture above we have 3 Routers in 3 different BGP ASes.  We all probably know that if we peer R1 and R2 Continue reading

1 … 4 5 6 7 8