Troubleshooting and 'target fixation'

I teach CCNP troubleshooting and one thing that is not talked about is that people will very often focus on a single feature or configuration because that is where they expect the problem to be when it is in fact not. Examples are, the last change that was made, the cause of the last problem that looked like the one before you. The issue is that you do not look at simpler causes. For example students will focus on what feature the lab was about, spend an hour on debugs and stuff and the issue was a SVI was no shut. Another example was I bought up a new VPN router with HSRP and focused in the crypto when in fact an ACL on the public interface blocked HSRP packets and it split brained.

The point is, if you can have someone just check the basic stuff like pings, and CDP, routing and packet drops on the interfaces even if your change was to BGP.

Fun with traffic shaping

The largest expsource with traffic shaping at megabit speeds is the number of zeros that you have to type in and the fact that IOS does not support the use of commas. Thus it is very easy to set your shaping rate to 10meg when you mean 100meg. This will often not show up at the time of the change because traffic is less than your shaping rate in your change window. This is even a bigger problem when you are upgrading bandwidth.

The problem will be visible in a sho policyt-map int <your interface>

Class-map: class-default (match-any)
      38004728421 packets, 23186941391069 bytes
      30 second offered rate 0000 bps, drop rate 0000 bps
      Match: any
      Queueing
      queue limit 23500 packets
      (queue depth/total drops/no-buffer drops) 0/5907809/0
      (pkts output/bytes output) 37998852043/23183155616853
      shape (average) cir 94000000, bc 376000, be 376000
      target shape rate 94000000

and you see the large number of drops but 0 no buffer drops, so traffic is being dropped by the shaping policy.

Moral of the story allways cut and paste these can put your on commas in