How soon do you “show run”?

Today I thought it’d be interesting to talk about troubleshooting. It’s always been an interest of mine, ever since my first real computer jobs included the 2 AM phone calls saying “Uhhh, Wendell, the network’s been busted since your changes happened – can you please come fix it?” At least they usually said please, being down in the deep South. Ah, you know it’s a real support job when know the people who work the midnight to 8AM shift in the NOC better than the folks in your own department. But I digress – troubleshooting matters more today with the new CCNA exam, so it’s probably worth a little discussion.

A quick examination of the CCNA exam topics shows that 13 different exam topics list the word “troubleshoot”. Essentially, the CCNA includes troubleshooting of every major topic on the exam. But the troubleshooting process is just a means to an end – they don’t really care how you go about troubleshooting, just as long as you can apply your knowledge to a unique scenario and identify the root cause of the problem.

Let’s face it, a lot of people use a slightly different process to troubleshoot a problem. Most people tend to look at what they know best first, because they can quickly think through the details. But when thinking about the CCNA exam and how to pass, it’s useful to think about some of the things you do when troubleshooting a problem. So, I want to describe a problem, and you can tell me what you’d do.

Let’s say PC1 and Server1 have been connected to two different switches in a campus LAN with 4 switches. The two devices are in different VLANs, and a 1-armed router connects to one of the switches in order to forward packets between the two VLANs/subnets. PC1 opens a web browser, types in the IP address of the server as the URL, and gets no response. What’s the problem? Then, let’s just say the user pings the server’s IP address, and that fails as well. Where do you go from there? Would you telnet to one of the switches? Which one(s) The router? keep issuing commands from PC1? In which order if you want to do all of the above?

The real answer is probably “all of the above” at some point, at least until the problem is fixed. However, I’m hoping to get a few honest answers to a survey related to this scenario, and encourage you to comment. Here’s the question:

If you think your network has a problem related to a particular Cisco router or switch, how long before you do a show running-config command?

I have some opinions of course, and I’ll post the results in a few days so you can see what others may be thinking. Now, let me close today’s post by commenting on a relatively new and very useful CCNA question type that makes you “analyze, synthesize, and evaluate” the knowledge required for the CCNA exams – namely, the simlet question. The concept is simple – the question has a simulator component, plus several multiple choice questions associated with it. You do not need to change the configuration to answer the question – in fact, often times you cannot change the configuration. The questions often boil down to either “something’s broken; answer questions about the problems and the way to resolve the problem”, or “the network may be working fine; answer questions about the current operation and flow of data in the network”. For example, a Simlet might give you the same 4-switch/1-router/2-host scenario I just described, with several multichoice questions that ask about the various problem symptoms that could cause the problem – VTP issues, VLAN trunk issues, misconfigured subnet masks, etc etc.

Of particular note, the Simlets don’t necessarily give you enable mode access – meaning you can’t do a show run. So, if the problem is indeed caused by some misconfiguration on a switch or router, how long does it take you to troubleshoot the problem if you can't do a show run, versus if you can? That’s not rhetorical, let me know what you think. Also, feel free to offer what you’re first 3-4 next steps would be to isolate the problem.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2007 IDG Communications, Inc.