TROUBLESHOOTING: USING THE DEBUG CONDITION INTERFACE COMMAND

There’s two handy troubleshooting tips I’ve learnt during my time as a network engineer. The first is to just ignore a problem and go to the pub. And hey, guess what: it almost always works*!

(*Gets me fired)

The other tip is the debug condition command, which helps you to troubleshoot by limiting debug messages to certain interfaces, IP addresses, MAC addresses, and a whole lot more.

I’ve got a router with two interfaces, looking for OSPF neighbors. No, I’m not making up lies to try to impress you. Look – I’m telling the truth:

R2#debug ip ospf hello
OSPF hello events debugging is on
R2#
*Mar 1 00:17:47.663: OSPF: Send hello to 224.0.0.5 area 0 on Serial0/0 from 192.168.12.2
*Mar 1 00:17:47.667: OSPF: Send hello to 224.0.0.5 area 0 on Serial0/1 from 192.168.23.1
R2#

This is only a small network, so it’s easy to read what’s going on. But if you type this debug command on a router with a lot of interfaces, it quickly become a nightmare to read, especially when you only care about what’s happening on one interface.

So, let’s limit our output to just Serial0/0:

R2#debug condition interface Serial0/0
Condition 1 set
R2#

Let’s see what impact this has on our debugs:

R2#
*Mar 1 00:17:27.663: OSPF: Send hello to 224.0.0.5 area 0 on Serial0/0 from 192.168.12.2
R2#
*Mar 1 00:17:37.663: OSPF: Send hello to 224.0.0.5 area 0 on Serial0/0 from 192.168.12.2
R2#

Cool! On a big router, this would be tons easier to read.

And if you like, you can even stack conditions. You could set a condition for one interface, and another for an IP on a different interface. The world is literally your oyster with this command.

You can see what conditions are on your router by typing this:

R2#show debug condition

Condition 1: interface Se0/0 (1 flags triggered)
 Flags: Se0/0

Now, be careful – there’s some important things to bear in mind:

  • This command doesn’t turn off debugging on all the other interfaces – it’s just hiding the debug output, “for our pleasure”. The debugs are still happening behind the scenes, and your router’s CPU is still going to take the hit.
  • You can do your usual “undebug all” to quickly turn off debugging – but the conditions will still be there. Remember to also type “no debug condition all” to remove the conditions.
  • Alternatively, type “no debug condition 1” to just remove the first condition – a useful command if you’ve got multiple conditions, and you only want to remove one of them.
  • This command might not always work. For example, I found that it didn’t limit messages from a debug eigrp packets. This seems to be IOS specific, so I guess it’s a glitch. You can troubleshoot it by trying a different debug, to see if that works. If it does, you’ll just have to shurg your shoulders and curse the name Barry Cisco, the inventor of the internet.

I hope you found this post helpful!

Leave a Reply

Your email address will not be published. Required fields are marked *