James HanbackI have a contract with an insect control company, just like many people who live in houses. Sometimes, someone will arrive at my door in a clean uniform and a large canister containing some magical chemical concoction. The canister is attached to a long wand, which is used to create an invisible barrier that stops six-, eight-, or hundred-legged creatures entering my space. When I don’t see any small crawling, flying or undulating creatures, I know that the pest control service is effective. The debugger visits my home every now and then because I don’t want any evidence of pests in my home.
The way that debugging in the network world works is a little different. Cisco IOS allows you to enable debugging. This is because you are specifically looking at the root cause of the problem. You want to see the bugs. You have the Cisco IOS debug command. This command is designed to overwhelm you with as much information as you can possibly understand about almost every aspect of an IOS setup.
I don’t mean to. Have you ever tried to follow the context-sensitive help for debug commands? It will take you about 10 screens to list all secondary keywords available immediately after the command.
The debug command is a valuable tool when you have issues that aren’t easy to diagnose. It allows you to examine a running configuration and to inspect the output of show commands that relate to the technology you are trying to troubleshoot. The debug command allows you examine the output in real time, as the device attempts to send or receive traffic. This is an advantage over relying on static output presented in show commands.
There is a caveat. It is not recommended to use debug commands on a network that is in production unless you have been instructed by someone at Cisco Technical Assistance Center (TAC). Debugging can cause significant resource consumption on your hardware, scrolling finger, as well as your eyesight. You should use the debug command sparingly, and only when necessary.
Imagine that you manage Router1’s Enhanced Interior Gateway Routing Protocols (EIGRP) administration, while Router2 is managed remotely by another administrator. Imagine that the Router2 admin adds an additional network to the Router2EIGRP configuration. The Router1 administrator decides that the new network should be kept secret from Router1. Inadvertently, the Router2 admin issues an EIGRP passive interface command for the interface connecting Router2 and Router1. EIGRP passive interfaces prevent both outbound and inbound advertisements. This causes an immediate break in the neighbor relationship between Router2 and Router1.
If you happen to be monitoring Router1’s console at the time, the first sign that something is not right might be a Syslog message like the one below:
%DUAL-5NBRCHANGE: EIGRP–IPv4 10 Neighbor 192.168.51.50.50 (FastEthernet0/0 is down) Interface PEER-TERMINATION received
You might call the Router2 admin to ask a few questions. What if the other administrator was not available? What if the problem wasn’t noticed until the next morning when users arrived at work and began to send support tickets your way? (Of course, this assumes that you didn’t have the foresight or system monitoring to alert you immediately a problem is identified.
You might have completely missed the console message in that case. The passive-interface command was sent to the remote router and not the router you manage, so the console message is not visible.
