Troubleshooting: Use the OSI Model
Troubleshooting from Layer 1 to Layer 7 of the OSI model is what makes you master the technology, rather than someone who has spent weeks or even months studying to pass an eight-hour configuration exercise examination. Use what you learned in your years in networking to troubleshoot your network. The problem is that the network you will configure in a CCIE lab examination does not represent your typical network; in fact, far from it. Common practices are not required because they are too easy to installñobscure commands are what will be required of you. Be prepared to configure the most scalable or desirable solution used in today's large IP networks. Preparation is a vital tool for troubleshooting the following questions:
What is the normal state of the network?
What are typical frame sizes
Do I expect traffic to increase in the morning or evening?
You should have these sorts of trends documented somewhere so you can look at the history of the network.
The same theory applies to any network scenario or lab examination.
Remember: You are being tested on a small set of routers and switches. Otherwise, the exams would be far more complex than they are. Todayís eight-hour examination is a race against time; troubleshooting will, hopefully, be your last resort.
Organization is the main key. Do not panic! If you start looking at the problem from Layer 1 to Layer 7 of the OSI model, you will quickly resolve the fault. For example, the best way to demonstrate this is to perform a lab where IP routing entries are not populating the network. With two routers, one running RIPv1 and the other OSPF, ensure the RIP domain has only Class C networks, while OSPF has subnetted networks for the same Class B address. You will quickly find a fault. CCNP Practical Studies demonstrates this very fault to you.
Basic Troubleshooting Steps:
Access to routers: response/no response/reload—clear line on Communications server
Physical interfaces—up/up, up/down, down/down why?
Show interfaces
IP connectivity between devices—ping loopbacks, ping directly connected interfaces
IP routing (fix one protocol at a time)—show ip route, debug ip route
Other features/protocols—Use CD-ROM to troubleshoot
Ask the proctor—Do not be afraid to challenge the proctor; he is human, too. Remember, itís not the most exciting job in the world and they are probably just surfing the Net and would welcome your interaction.
So, what else should you look for when troubleshooting?
First, start with Layer 1, physical connectivity:
Is the interface up?
Is the line protocol up?
Check the interface statistics and look for sharp rises, such as carrier detects (DCD), that increase rapidly.
You may need to debug Frame Relay frames to decipher what the fault is, for example. Typically, the debug output shows you the fault-like mismatch in LMI types or some higher layer fault, such as a mismatch in CHAP passwords (if you're using PPP over ISDN).
After you recover Layer 1, the protocol state of your connections should also be active.
Check Layer 2 network connectivity by using the show cdp commands to see if the Cisco devices have discovered each other. This is a simple tool when you are pressed for time to ensure you enable CDP globally and on the interface. You still may not see any CDP.
The most crucial tool for the lab is the simple ping command. This simple command is your "best friend" in the CCIE lab. In fact, when marking your exam, the proctors will use the same command to verify network connectivity so you can quickly verify your own solutions as well.
To test Layer 1/2 connectivity between two routers over Frame Relay, for example, simply ping the remote router. If it does work, use debug ip packet or debug frame to decipher the problem. Keep using ping around all your IP network interfaces to ensure that you have full network connectivity. If you can ping over the WAN but not the remote network, you need to check your IP routing table. With a combination of the extended ping command and show ip route, you can quickly see where in your network routing is not occurring.
Again verify with the debug ip routing command to view what the routing process is sending or not sending. It could be that you have a VLSM issue between IGRP/EIGRP or OSPF, for example. It could also be an IOS bug, so feel free to reload the router during your lunch break to save time.
Use the traceroute command to verify no routing loops. This command quickly scrolls down to about 100 entries.
Finally, to ensure Layer 7 connectivity, use the telnet protocol to ensure full connectivity. If you cannot Telnet, you have a problem within your network.
Candidates who typically accomplish this task by the half-way mark of the lab generally succeed in passing the exam. Your network should have full OSI connectivity from Layer 1 to 7, and the second four hours should be spent on non-IP protocols, such as DLSW+ and other miscellaneous topics.
In summary, some of the best tools you can use are the following:
ping
telnet
trace
debug ip packet
debug frame
debug isdn q931/q921
Ask the proctor to verify
Question IOS bugs you think you encountered
Use your extensive troubleshooting experience to help you
It's easy to sit on the other side and say how simple an examination is. In fact, exams are only made harder by your own lack of confidence. CCIE lab exams are very passable. Good luck.