Show Versus Debug Commands
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Over the last few weeks I have found myself focused on router and switch troubleshooting. In doing so I have reaffirmed that the best time to begin learning how to troubleshoot, and about what tools we have at our disposal for troubleshooting is when we are actually starting out in our studies. It is during our CCNA days that many of us are first exposed to routing and switching protocols. It is during this time that we are tasked with memorizing timers, multicast addresses, and finite state machine information just to name a few. It is during this time that a forward thinking candidate should not just be reading about all these technologies, but implementing them as well. Getting a few routers or using a trusted simulator or emulator affords us the opportunity to see firsthand what these protocols do, how they do it, and how we can manipulate them.
When you are ready to setup these devices, make your configurations, and really “dig in”, you will quickly learn that it is almost impossible to do any of this without two of our most basic troubleshooting tools: debug and show commands.
The Big Difference
Show and debug commands are tools integrated into the Cisco IOS that are intended to support troubleshooting. The purpose of show commands is to display static information, where the debug commands display dynamic information regarding events or data. If we take a closer look at each, we can see the major differences:
- Show—used to obtain a snapshot of the state of a given interface, media, or network. This can be used for the purpose of verification, troubleshooting, or monitoring network performance. In essence, we will want to use a show command when we need to gather facts.
- Debug—used to check the actual data flow and control plane operation of a given protocol. This information is often used to troubleshoot configuration issues, equipment failures, or protocol issues. Given that debug commands monitor actual data and communication flows, the ideal purpose for this tool is when we want to actually observe a process in action.
Aside from when we would want to use one command over the other, an additional difference between the two commands is how much CPU utilization and overhead each uses. Debugging, where the actual data flows and processes are being monitored, requires substantially more CPU cycles than any of the most complex show commands ever could. This is a fact that must be taken into account when working on production equipment. It is quite possible, given the processor intensive nature of debug commands, that we could inadvertently disrupt the performance of a network device.
Why Debug Instead of Show?
Actually, there is much that a show command cannot tell us. We could not, for instance, use a show command to tell us when a route leaves our routing table, or what direction an IP packet took through a router, or why an OSPF adjacency failed. That may make it sound like show commands are worthless compared to their debug counterparts, but that could not be further from the truth. Show commands provide us quick access to critical information that lets us know things like: are interfaces up and operational? What routes are in our routing table? Are OSPF adjacencies forming?
The decision on which troubleshooting command to use comes down to exactly what type of information we need.
Show and Debug in Action
Let us examine these commands in action using a topology where we have two devices, R1 and R3, that are connected via their Serial1/1 interfaces. We have configured OSPF on both of these routers, and now we have to ask ourselves, "Are R1 and R3 neighbors?" We can find out if they have become adjacent through the use of the show ip ospf neighbor command:
R1#show ip ospf nei R1#
Notice that we do not see any information that would notify us that we have established a neighbor relationship between these two routers. In order to find out why we have not become neighbors, we have to ask another question, "What is wrong with the OPSF process?" to find that answer, we can debug our OSPF adjacency process:
R1#debug ip ospf adj OSPF adjacency events debugging is on OSPF: Rcv pkt from 10.1.13.3, Serial1/1 : Mismatch Authentication Key - Clear Text R1#undebug all All possible debugging has been turned off R1#
Almost immediately we can see that we have an issue related to a "Mismatch Authentication Key." This tells us that our keys do not match between R1 and R3. We can now use a show command on both R1 and R3 to see what key is being used. We will look at this static configuration with the show run interface Serial 1/1 command first on R1. For this verification, we will us an invaluable show command tool called an 'output modifier' that allows us to filter our output to configuration lines that include the words 'authentication-key':
R1#show run interface Serial 1/1 | inc authentication-key ip ospf authentication-key CISCO R1#
On R3 we can see what authentication key was used on the attached interface by employing the same show command:
R3#show run interface Serial 1/1 | inc authentication-key ip ospf authentication-key cisco R3#
The output of this show command, coupled with the knowledge that passwords are case sensitive, tells us immediately what the issue is!
Three Common Issues with Debugs
We already mentioned that using debugs in production environments can cause significant issues, especially if you are just learning; but the truth of the matter is that even experienced engineers often make mistakes while using them.
The single most common issue that I have seen in production environments is discovering that a debug has been left running in a given environment. We all get caught up in what we are doing from time to time, and it is not hard to imagine accidently leaving a debug running. The real world effect of this is, best-case, we slow the routers performance; worst-case, we render it unusable. Not something any of us would like to have to admit to in front of management, or have discovered by someone else. The command undebug all is your best friend, and will keep this situation from happening. This command ensures that all possible debugging is disabled—get accustomed to using it.
The next most common issue is not realizing that you could crash a router by issuing too many debug commands. Remember that your router or switch only has so much RAM, and its processor can only take so much. A router's processor is built to facilitate the forwarding of packets, not the monitoring and processing of protocols and producing debug messages. Each debug command you execute translates to an individual debug process that must be managed by the CPU. But what most people lose sight of is debug statements are afforded higher priority then things like network traffic. We need to keep in mind that asking our router or switch to process numerous debug commands can have a significant negative impact on its overall performance.
The last issue is probably the most common problem experienced by new or aspiring engineers. Debug was intended for targeted and sporadic use. What do we mean by that? Debugs should be targeted such that we burden the router or switch's CPU as little as necessary. Sporadic refers to the fact that you should not run debugs for extended periods of time, especially in production environments. The longer you run the debug, the more strain you place on the device, and the more output you generate for yourself to have to wade through. Be as specific as possible with your debug commands, and turn them off as quickly as possible.
Conclusion
Cisco IOS show and debug commands are very powerful tools that every engineer or aspiring engineer should know how to use correctly. The show commands give us snapshots of router statistics, interface counters, and protocol states, where debugs give us detailed information regarding data and control plane processes in a close to real time fashion. Knowing when to use one, or both of these tools in unison is one of the hallmarks of a good engineer.