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 18.104.22.168 area 0 on Serial0/0 from 192.168.12.2 *Mar 1 00:17:47.667: OSPF: Send hello to 22.214.171.124 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 126.96.36.199 area 0 on Serial0/0 from 192.168.12.2 R2# *Mar 1 00:17:37.663: OSPF: Send hello to 188.8.131.52 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!