Networking Cisco Routers And Switches:

Using The OSI Model For Troubleshooting

By Chris Bryant, CCIE #12933

The best kind of troubleshooting is proactive.  That's where proper network documentation comes in - because it helps you identify single points of failure and introducing redundancy before it's needed. 

Using our old friend the OSI model to troubleshoot a network has several advantages.   If we have a network problem and look at it as a whole, it can be very difficult to decide where to even start troubleshooting.  By using a structured approach, we can eliminate possible issues, which helps to - you guessed it - isolate the problem.

Let me warn you here, though, that you've got to be flexible when it comes to your troubleshooting approach.  You're going to learn about several troubleshooting models in this chapter, and they're important, but you don't want to pick one and ignore the other two.  You'll see what I mean as we go through the chapter.

This layered approach allows you to focus on specific factors at each layer as you work your way up or down the model.  At the Physical layer, you're checking cabling, ports, power supplies, etc., and so forth.  This layered approach brings structure to the entire network troubleshooting process.

Using a structured approach also makes the problem less complex than it might seem at the time.  We've all been in situations where at first glance, a network issue seems complex, but it ends up being something simple - anything from a loose cable to a one-line misconfiguration.  

You've got to develop your own troubleshooting approach should reflect where in the OSI model you believe the problem resides.  Two such approaches are bottom-up and top-down, and again the name is the recipe - If you believe the issue is a physical one,  start with the physical layer and work your way up (bottom-up).  If you believe an application is the issue, start with the application layer and work your way down (top-down).

Network issues won't always be so cut-and-dried that you can start at the top or bottom of the OSI model, though!  Let's say you suspect that the issue is with a routing protocol, or with PAT.  In these two cases, you'd begin with the Network or Transport layers, respectively.  There's no need to start at the bottom or the top of the OSI model if you believe the issue is in the middle, so you'll take the divide-and-conquer approach, which is the term used to describe the approach used when a specific middle layer of the OSI model is the first one checked.

If you're using divide-and-conquer, you're assuming that all layers beneath the layer you begin troubleshooting are working correctly.  For example, if you begin troubleshooting by examining the routing table, you're using divide-and-conquer as well as assuming that the Physical and Data Link layers are working correctly.

As you gain more experience, you'll find yourself using the divide-and-conquer method more and more often.  Used by experienced troubleshooters, this approach is often the fastest, especially when you've seen the issue before.  Just another reason to get as much real hands-on practice as you can!

Examples of when each approach would be appropriate:

Regardless of which troubleshooting model we're using, the process remains pretty much the same:

-- Determine the symptoms.  Is traffic stopped? Slow?  What is accessible and what is not?

-- Isolate the problem. What exactly is causing the issue(s)?

-- Fix the problem.  After all, that's what we're here for!

To your success,

Chris Bryant

CCIE #12933

chris@thebryantadvantage.com