We have all learned an important lesson in life the hard way. When it comes to working on the router or switch, there is often a couple of commands that you discovered after beating your head against the wall for a while that if you had known about them earlier, would have made your life so much easier. These are those commands for me.
Show Interface Description
When we are troubleshooting, especially on a switch, it can require that we look at the configuration for a specific interface. Because there are a lot of interfaces, finding the one in particular that we care about can be a bit of a pain in the butt which is why Cisco allows us to put a description on each interface. Working under the assumption that we actually keep those descriptions accurate as things change, having an easy way to see all of those descriptions (without having to scroll through the pages and pages of actual configuration) can make life significantly easier. Enter the command show interface description.
The command gives us kind of a modified view of the very familiar show ip interface brief, the show interface description gives us the port status for all of our ports and more importantly includes the description (if there is one)of all of those interfaces making it much easier to find the one that we’re looking for.
Terminal Monitor
Not too long ago I wrote a story about a problem a Net Tech was having with one of his HCLOS links. While we were eventually able to figure out the problem, it took a very long time for two reasons. 1. We kept getting kicked out of the router and 2. Once we were in the router we didn’t see a critical message come across the screen that clued us into what was going on. Why didn’t we see the message? Because we never bother to enter the terminal monitor command when we initially logged into the router.
When we console into a router (either directly using a console cable or through a terminal server)the router automatically displays each and every message that it produces on our screen. When we telnet/SSH into a router though (which I would hazard to say is much more common for a Net Tech compared to actually consoling in) a huge number of those messages aren’t displayed on our screen unless we tell the router to do so. As was true in this case, and many other cases, the messages that the router wasn’t displaying were the critical clue that we needed. My advice is simple, if you are doing any kind of troubleshooting, the very first command you should enter once you log onto the router is the terminal monitor command so that you can be sure that you are seeing everything that the router is telling you.
Reload In
We are all very familiar with the reload command and I am sure have used it more than a few times during our career. For many of us, it’s a lifeline that we use when we just completely screw up something, we can reload the router and go back to our last saved configuration. While this is a piece of cake to do when we’re sitting in front of the router, it may not be possible when we’re working remotely.
Personal Story: In 2008, I came through NTC as the Net Tech for 2/1 ID. At the start of the rotation, the Brigade TAC rolled out first while the Main was still in the RUBA. Once the TAC came up, I remoted into its CPP switch to make some final changes including reconfiguring a trunk port that connected it to the JNN. When I “fixed” the trunk port, I just copied the statement that restricted which vlans were allowed through off of another port and pasted it. As soon as I hit paste, my screen locked. It took me a minute to realize that the line I copied didn’t include vlan 6 (the vlan I was going over to get to switch) and it was no longer allowed. I had to call out to the JNN operator and have him go into the CPP to reload the switch to undo my screw up.
I have plenty of stories where I was doing a configuration change that either did or potentially could have locked me out of the router or switch I was working on if I screwed it up. It’s not always possible to have someone there to reboot the device if you get locked out which is why I love the reload in command. Just by adding the “in” extension to the reload command we are able to set a timer to the reload.
In this case what I like to do is give myself a five minute timer (reload in 5) so that if I completely screw something up and get locked out of the router, after 5 minutes it will reload itself off of its previously working configs and I will be back up and working shortly thereafter. It’s a lifeline when no one is around to do it for me.
If things work out once you’re done doing whatever it is you’re doing and the router is still working, just issue the reload cancel command to cancel the pending reload.
Configure Replace
Kind of along the same lines as the reload in command is the configure replace command. This command is used to allow us to rollback to a saved configuration. Many people think that we can do this with the copy command but rather than replacing the configuration, the copy command simply merges the two configurations. Say, for example, your running configuration has an IP address on G0/0 but your startup configuration doesn’t. Using the command copy start run will leave the IP address on that interface.
If instead we want to replace the current running configuration we can use the configure replace command. I use this on my lab at home to go back to a starting configuration when I am done working on a project. The great part about this is that it doesn’t require a reload to take effect so it happens almost instantaneously. The only trick to this is that you have to revert to an actual saved configuration and not just a command script that we wrote and saved.
Debug
Arguably the most power set of commands on any router or switch is the debug command. While debug can’t tell you everything about the device, it can come pretty damn close. The debug commands can tell us exactly what the router/switch is doing, as it is doing it both when it is working correctly and when it isn’t. What exactly you can debug changes from device to device but it is a huge number (the switch in my lab at home has 121 different options just off of the basic debug command.
It is important to realize that when you issue a debug command, it can consume a lot of system resources. This has to be considered before entering the command as it could disrupt the actual operation of the device in some extreme cases. It is also important to ensure you enter the undebug all command when you are done otherwise the system will continue to debug even if you logout.
Note: Cover photo provided by Mitch Barrie on Flickr.