Exam #642-831: Cisco Internetwork Troubleshooting Support (Troubleshooting) Vendor Cisco Systems Status Live. Available at Pearson Vue and Prometric testing centers worldwide. Reviewer's Rating "Take this CCNP exam last -- after the other three (especially Remote Access)...it will be a walk in the park." Test Information 60 to 70+ questions, passing score needed is apx. 804 on a scale of 300 to 1,000. Cost: $125 (U.S.). Who Should Take This Exam? Candidates for Cisco's CCNP title. Can also be used to renew the CCNP. Test Objectives Click here

One great resource you'll want to use to prepare is Cisco Connection Online (CCO). CCO requires registered access for some of its content, but much of it is available to the anonymous user. It is widely recognized as one of the most valuable Internet resources for Cisco professionals, but the site itself can be difficult to navigate, sometimes making locating the simplest of answers a consuming chore. Cisco wants you to be familiar with the CCO for this exam, knowing the tools within for troubleshooting. You'll want to start with the Technical Assistance Center, which is the link to Cisco support engineers. The direct link is www.Cisco.com/TAC. More information on gaining access to CCO can be found here.

In this article I will address some of the high points to study for the new Troubleshooting exam as mapped to the official exam objectives, found here. A quote from that page: “The exam covers topics on Establishing a Baseline, Determining an Effective Troubleshooting Strategy, Resolving Problems at the Physical and Data Link Layers, Resolving Problems at the Network Layer, and Resolving Problems at the Transport and Application Layers.” This is a dead-on description of what you’ll find on this exam! Let's delve deeper into some of the main topics you'll encounter.

Troubleshooting Methodology
There are many approaches to troubleshooting today’s advanced networks. Although the troubleshooting techniques of network support people vary, all have a common goal: To restore the network to its normal state.

To pass this exam, you'll need to know the overreaching approaches to troubleshooting. There are four main ones I'll cover here -- a link at the end of this section will provide you with more details.

• Top-Down: When you apply a top-down approach to troubleshooting a networking problem, you start with the user application and work your way down the layers of the OSI model. If a layer is not in good working order, you inspect the layer below it. When you know that the current layer is not in working order and you discover that a lower layer works, you can conclude that the problem is within the layer above the lower working layer. After you have discovered which layer is the lowest layer with problems, you can begin identifying the cause of the problem from within that layer. The disadvantage to selecting this approach is that if the problem turns out to be more complex or happens to focus on the lower-layers physical, data link, or network, you will have wasted time and effort on examining the user applications or upper OSI layer components. Furthermore, if you have internetwork expertise, you might not necessarily have the expertise to diagnose or correct application layer issues. (More on this later.)
  
• Bottom-Up: This method to troubleshooting a networking problem starts with the physical components of the network and works its way up the layers of the OSI model. If you conclude that all the elements associated to a particular layer are in good working order, you inspect the elements associated with the next layer up until the cause of the problem is identified. Many of us preach or use this method regularly, but the downside this approach is that it requires you to check every device, interface, and so on. In other words, regardless of the nature of the problem, the bottom-up approach starts with an exhaustive check of all the elements of each layer until the problem is found.

TIP: One way to avoid having to start troubleshooting from the physical layer is to test the health of the bottom layers by using the ping or tracert tool. A successful ping across a link eliminates the possibility of broken hardware or data link layer issues such as mismatch encapsulations or inactive frame relay DLCIs. Ping or tracert failure would tell you that problems might exist at the lower layers, requiring investigation. Otherwise, you must inspect the access lists on routers if connectivity fails.

• Divide-and-Conquer: The divide-and-conquer approach to network troubleshooting, unlike the top-down and bottom-up, does not always start with the investigation at a set OSI layer. When you apply the divide-and-conquer approach, you select a layer and test its health; then based on the observed results, you might go in either direction up or down. During the divide-and-conquer troubleshooting process, if you can verify that a layer is working correctly, you can safely assume that the layers below it are working as well. If a layer is not working at all or it is working intermittently or erroneously, you must immediately inspect the layer below it (with the exception of the physical layer, which does not have a layer below it). If the layer below the current layer is in good working condition, the culprit resides in the current layer. If the layer below is also malfunctioning, you should gather symptoms of the problem at that layer and work your way down.
  
• Experience: Of course, you can always apply your experience. If you've had experience troubleshooting a particular or similar problem before, you might know of a shortcut to fix the problem. If you are less experienced, you likely should implement a bottom-up approach regardless of the circumstances. If you are skilled at troubleshooting, you might be able to get a head start by beginning at a different layer using the divide-and-conquer approach.

The reference found here will help you understand other parts of the Cisco troubleshooting models. Pay particular attention to the commonly used show commands about three-quarters of the way down.

Now, on to application.

Tools and Techniques
Many of the tools for troubleshooting are available within the operating systems of the network devices. The Cisco IOS (Internetwork Operating System), which you find in Cisco routers and switches, is no exception. From the ping utility to tracert, to show and debug commands, there’s almost no problem that can’t be solved with a logical approach. Of course, you must be able to read the common router output displays that could be present when using the show ip command, for example. To fix a problem, you have to be able to spot it, as well as know what is normal in various situations -- for instance, when an interface is up and up or up and down (but not administratively), and when viewing ISDN interface configurations with the up and up (with spoofing).

When the output of the show interface command is up and up, this means that the interface is administratively enabled and the physical layer is operating correctly. When the output is up and down, the interface again is administratively enabled but there is possible a physical problem with the interface (such as a broken or missing cable). And when displaying the output of an ISDN interface, such as show interface bri0:1, and the interface is up and up (spoofing), this is a valid output and the interface is functionally ready in most cases and ready for Dial on Demand Routing (DDR).

When locating the problem of connectionless protocols such as UDP, IP, and CDP, using the show ip interface, debug UDP traffic, the various CDP display commands (such as show cdp neighbor detail) and the Telnet utility will help you gather diagnostic information. For connection-oriented protocols TCP, SMTP and FTP, the same tools work in most cases, but you’ll also need knowledge of these higher-layer protocols and the applications that use them. For instance, File Transfer Protocol (FTP) uses TCP port 21 for connections by default and includes the get and put commands that allow the client’s application to access files (get) and send (put) files to the FTP site. For example, if you were troubleshooting FTP and could ping the FTP site by name from the client’s PC but couldn’t access the FTP site for login, you might suspect a problem with FTP server. If so, you could attempt to Telnet to port 21 from the router, login and issue the get command to check for a response. If you are successful, you have now eliminated general problems with the network such as router, FTP server, or other common physical layer areas. The problem now points to the client’s application or the ever-demanding user error.

Be sure to know when and why you would use ping with extended mode and what the outputs of the various fields indicate, along with where the network problem or problems may exist.

Tip: When using ping and the response is "HHHHH," this indicates the host is unreachable and/or multiple "….." usually indicates the host is not responding or the destination address does not exist. The expected output would be "!!!!!” -- this means successful replies have been received.

When asked to demonstrate knowledge of common protocol connection sequences, you'll want to rely on the very well known TCP three-way handshake. In it, a TCP source device sends a SYN (Synchronize) segment to a destination and waits for a SYNACK (Synchronize Acknowledge), and then the source sends its own ACK. When troubleshooting TCP, a common command is debug ip-tcp. The output displayed will allow you to find possible errors with the three-way handshake, as well as spot other possible problems.

Tip: Debug commands should only be used when the network traffic is relatively low or during off hours when network users are not present. This prevents any type of denial of service or over utilization of router resources for normal traffic.

Windows clients and servers can require special troubleshooting skills. For instance, in many Windows’ networks, there is a Windows Internet Name Service (WINS) server configured to listen for WINS registrations (including NetBIOS services and IP address mappings); DNS (Domain Name Services) servers configured with host and domain name to IP addresses mappings; and the command-line utility route print, which displays the computer’s local routing table.

Tip: Don’t forget about the results displayed in Windows computers by IPConfig/all and on Unix, Linux and Mac computers IFConfig -a.

VLANs (Virtual Local Area Networks) can pose interesting problems for a routed network and troubleshooting issues galore for the network professional. From the router, the common show and debug commands can be very helpful in locating configuration errors or VLAN problems. VLANs are created to isolate broadcast domains, with trunking allowing multiple VLANs to operate across the same network switch. Normally, each port on the switch only belongs to one VLAN, but a trunk port can be configured to send and receive traffic for many VLANs.

Tip: Duplex mismatch and sometimes auto-negotiation can cause many mysterious problems between the client and the switch. It is highly recommended to always pre-configure the trunk ports and server ports to a fixed negotiation. The set port speed mod_num/port_num command can be used to disable auto-negotiation.

The show port mod_num/port_num command will display the VLAN to which a port belongs and can be used to isolate communication problems. The show VTP domain (Virtual Trunking Protocol) command will display the VTP domain and must match for all member switches (note that the name is case-sensitive). Many of the same commands and utilities previously referenced in this article are also used when troubleshooting VLANs, such as ping, show and debug. For example, verify you can ping the remote switch from the local switch as a first step in troubleshooting. Then use the show and debug commands to find common configuration errors -- for example, use show spantree on the Catalyst OS and debug spanning-tree on the Cisco IOS to find problems related to the Spanning Tree Protocol problems in a switched network.

For ISDN, you must understand the foundations to effectively troubleshoot this type of network. Since ISDN is a dial on demand technology, it presents many unique challenges. ISDN operates at layer 1-3 of the OSI reference model. Two of the most common troubleshooting commands are debug isdn events and debug isdn q931. Deciphering the output of these commands is crucial in dealing with ISDN because it does have so many configurable variables. With the dialer map protocol next-hop-address [name hostname] [broadcast] [dial-string] command, you can correctly configure the DDR requirements, then use show running-configuration to verify.

One of the other typical challenges you run into when troubleshooting ISDN is PPP (Point-to-Point) protocol configuration errors and authentication problems. In this case, starting with the command debug ppp negotiation would be a wise choice. For most ppp negotiation problems, reenter the correct information using the username name password password commands.

Finally, there are Frame Relay networks to troubleshoot. There are many frame-relay command options for show and debug, certainly too many to list within this article. However, I will name some of the more common commands as these are a good starting point. While the implementation and configuration of frame-relay is covered for the most part on the Routing exam, there are a few things to keep in mind here. The DLCI (Data Link Connection Identifier) is configured locally between each router interface and provider’s switch. A Cisco 60 pin cable end is required to connect the router or DTE (Data Terminal Equipment) to the CSU/DSU. The show interfaces serial command will indicate if the cable is connected correctly and if the interface has been administratively enabled by the up and up condition in the output. The show frame-relay lmi command will give you the configured LMI (Local Management Interface) value – remember, it must be the same on all points along the network. Don’t forget about the two different frame-relay encapsulation types, that they must match between devices and the IETF form must be used when connecting Cisco routers to non-Cisco routers; however, the Cisco encapsulation, which is default, can be used between Cisco only devices. Configuration errors such as assigning a DLCI to an incorrect sub-interface can be identified with the show frame-relay pvc and corrected with the frame-relay map protocol protocol-address dlci [broadcast] [ietf | cisco] command. The debug series of commands for frame-relay can be used with the show commands to locate stubborn problems -- for example, debug frame-relay lmi for configuration mismatch -- but don’t forget about the show running-configuration command.

Final Thoughts...
While this exam can't actually test your real-world ability to troubleshoot networks, studying for it should give you some idea of what it’s like. Only through trial and error, blood, sweat, and tears, will you ever truly master the art of troubleshooting! Good luck!

Andy Barkl, CCNP, CCDP, CISSP, MCT, MCSE:Security, MCSA:Security, A+, CTT+, i-Net+, Network+, Security+, Server+, CNA, has over 19 years of experience in the IT field. He's the owner of MCT & Associates LLC, a technical training and consulting firm in Phoenix, Arizona. He spends much of his time in the classroom but has also been responsible for many Microsoft Windows 2000, Exchange 2000, and Cisco networking deployments for many clients across Arizona. He's also the online editor for MCPMag.com, TCPMag.com, CertCities.com, and a contributing author and editor for Sybex and Cisco Press. He hosts a multitude of exam preparation chats monthly on MCPmag.com, TCPmag.com and CertCities.com. You can reach him at .

More articles by Andy Barkl:

• 70-623: A Vista Exam for Consumer Support Techs
  
• Securing Networks with PIX and ASA (SNPA 642-522)
  
• Cisco’s IPS Exam (#642-532): Get Your Network Secure
  
• Securing Virtual Private Networks (642-511)