Layer by Layer Troubleshooting with a Cisco Router

OSI Model - Bottom Up Troubleshooting

If you will recall, the OSI model starts with the physical layer (layer 1) and goes up to layer 7 (application). When troubleshooting with a Cisco router, much of your time will be spent working in layers 1-3. They are:

• Layer 3 - Network
• Layer 2 - Data Link
• Layer 1 - Physical

Because these layers build on each other, Layer 1 is most critical, without layer 1, layer 2 will not function. Without layer 1 & 2, layer 3 will not function, and so on. For this reason, I start troubleshooting at layer 1, physical, and move on up from there.

Here is what you look for:

• Is the interface UP?
• Is the line protocol UP?
• If both the interface and line protocol are NOT up, your connection is never going to work.
• To resolve a line down, I look at the cable or the keepalives
• To resolve a line protocol down, check to make sure that the protocols match on each side of the connection(notice the "line protocol" on each of the interfaces above).
• Are you taking input, CRC, framing, or other errors on the line (notice how the serial interface above does show errors)? If so, check your cable or contact your provider.

In general, verify that you have a good cable on each side, verify that line protocols match, and that clocking settings are correct.

If this is an Ethernet connection, is there a link light on the switch?

If this is a serial connection, do you have an external CSU/DSU? If it is an external CSU, check that the Carrier Detect (CD) light & data terminal ready (DTR) lights are on. If not, contact your provider. This also applies if you have an internal Cisco WIC CSU card. If that is the case, take a look at this Cisco link on understanding the lights on that card.

You can, of course, use the Cisco IOS test commands to test your network interfaces with internal staff and with your telecommunications providers.

Do not proceed to upper level layers until your Physical interface on the router shows as being UP and your line protocol is UP. Until then, don't worry about IP addressing, pinging, access-lists or anything like that.

I would recommend taking this interface configuration and comparing it, side by side, with the remote WAN connection to ensure they are the same. Ask yourself questions like:

• Are these interfaces on the same IP network?
• Do these interfaces have the same subnet mask?
• Are there any access-lists (ACL) that are blocking your traffic?
• Can you remove all optional IP features to make sure that the basic configuration works before adding additional features that could be causing trouble?

Router Troubleshooting at OSI Layer 3 - Network

Once you have Layers 1 & 2 working (your show interface command shows the line is "UP & UP", it is time to move on to layer 3 - the OSI Network layer. The easiest thing to do here to see if layer 3 is working is to ping the remote side of the LAN or WAN link from this router. Make sure you ping as close as possible to the router you are trying to communication with - from one side across to the other side.

Router Troubleshooting at OSI Layer 1 & 2 - Physical & Data link

Remember, if Layer 1 isn't up, nothing else will work so make sure you start here. Examples of layer 1 are your T1 circuit or your Ethernet cable - physical connectivity. I usually troubleshoot layer 1 and layer 2 in union because they are so closely paired. Examples of layer 2 - data link - are your line protocol (such as Ethernet, ATM, 802.11, PPP, frame-relay, HDLC, or PPP).

To troubleshoot at these layers, the first thing I would do on your router is a show interface. 

Router Troubleshooting at OSI Layers 4 - 7

Now, let's say that you have made it to the point where you can ping from LAN to LAN, through your WAN. Congratulations - that is a very good sign. If you are still having trouble, it must be in OSI Layers4-7. Here are those layers listed out and possible issues you might experience in each layer:

• Layer 4 - Transport - in the transport layer are TCP and UDP - you could be have an ACL or QoS feature blocking or slowing this traffic. Your TCP traffic could also be fragmented to the point that it could not be reassembled. Another option is that you may not be receiving an ACK back from your traffic that was successfully sent.

• Layer 5 - Session - in the session layer are protocols like SQL, NFS, SMB, or RPC - you could be taking errors on any one of these session protocols. I would recommend using a protocol analyzer like Wireshark to analyze your session data.

• Layer 6 - Presentation - in the Presentation layer are data encryption, compression, and formatting - your VPN tunnel could be failing or perhaps you are sending one type of data (like a MPEG) and the receiver is trying to view it as a WMV file.

• Layer 7 - Application - in the Application layer are, of course, your applications like FTP, HTTP, SCP, TFTP, TELNET, SSH, and more - you could be trying to connect to a telnet server with the SSH protocol, for example.

• Layer 8 - End User - the standing joke is that "Layer 8" is the user - the user could be just mistyping their username or password or you, the network admin, could have been troubleshooting the wrong IP address all along.

Summary

In summary, using the OSI model to troubleshoot connectivity issues is the fastest and most efficient way to troubleshoot any network issue. Even if someone calls you to work on a Windows share problem, all of the same principles in this article apply to that troublesooting process. So remember, the next time you work on a network issue - remember the OSI model and how to use the bottom-up approach to troubleshooting! It could same you a while lot of time!