lucasburlingham.me

OSI Model for Generic Troubleshooting

The OSI model has always been something I've considered to be a helpful reference, but it never really fit the problems I've encountered in my limited experience. Sure, you could spend an entire semester teaching the intricacies of every layer and how they work together to create the behemoth that is modern communication and computing.

But what if not every problem has seven layers to it?

I've already laid out the OSI model here.

Let's pose a common problem and environment:

You're a sysadmin/helpdesk tech at a company that typically uses MS Windows workstations that are wired with typical CAT 5e Ethernet leading back to a networking switch. They use a typical USB keyboard and mouse, with a single monitor that uses both HDMI and DisplayPort to provide a split screen/PIP configuration. This particular device doesn't have a network connection and the screen has blanked, but the user swears on everything they've ever known they didn't break the computer.
You've just arrived at the user's desk. What do you do?

There are two options:

1. Start at the bottom and work your way up.
2. Start at the top and work your way down.

I prefer to start at the bottom and work my way up. This accomplishes two things:

1. It's easier to check the physical layer first. If the computer isn't plugged in, it doesn't matter if the network is down.
2. Starting at the floor requires the user to move OUT OF THE WAY for me to get under or behind their desk. This allows me to claim CAPTAIN status, and I now control both their space and their keyboard. I don't usually use their mouse.
   The only exception to this is tapping their spacebar to wake the computer while you're on the way down under the desk. 50% of the time you'll fix the "monitor issue."

So, let's start at the bottom:

1. Physical Layer
   - Check/reseat all cables, make sure device appears to be powered on. Trace all important cables back to their origins (check for daisy-chained power cables, and maybe cable manage with some velcro while you're at it.)
2. SKIP DATA LINK
   - CHECK THIS IF YOU HAVE NO IP ADDRESS OR IF YOU SUSPECT 801.2X ERRORS.
3. Network
   - Do the link lights show activity? (Ask yourself if you have the expected level of connectivity as you move up the chain.)
4. Transport - SKIP. The browser or application using a connection will probably tell you if you have issues.
5. Session - SKIP. You'll need to walk back to your desk to check configs if you need this layer.
6. Presentation
   - Instead of how information is displayed on your screen, I consider this layer to deal with if the user can see the information they need. Is the monitor on, is a Windows setting arbitrarily not allowing you move a monitor around in software?
7. Application
   - This is usually the applications that interface with the user, like Microsoft Excel, curl, Visual Studio Code, Google Chrome, etc.

I propose we condense the OSI model into 4 layers:

1. Physical - What you can touch and test for proper placement/connection. Totally analog issues here.
2. Network - Do you have a connection to the device(s) you expect to have a connection to? Where does your connection stop?
3. Display - How/if applications are displayed and is the information displayed by the device in a useful format?
4. Application - Is the user able to process displayed information?

This model can be checked from either way - top down for a thorough and directed approach, bottom up for a generalized "Hey, my computer isn't working!" issue.

Problem: User reports that their computer is not working. They were having network issues when they submitted the ticket but now the screen is blank.
Issue Severity: Medium (User can't work, but it's not a critical system.)
Resolution: Checked all physical connections, reseated all cables. Found that one of the sides of the` monitor was turned off. Powercycled monitor and verified that the user could see their desktop. The network cable was slightly disconnected and was reseated.

You could solve this problem in two ways:

1. Jiggle the mouse and find that one side of the monitor has fallen asleep. Further investigation (skipping down to the Physical layer) shows that the user likely accidentally disconnected the HDMI cable while fiddling with the Ethernet cable. Reseating both resolved the user's issue.
2. Start by checking and reseating all connections to the computer, then restart the workstation. Everything pops up like normal and the user is able to continue working.

This approach shows us where and why the problem occured. This then could be conveyed to the user, who may be a little embarrased or offput for the fix being so simple or being their fault. No worries, all tech guys are also wonderful at customer service, right? The user can be educated, and likely learned something from you berating them about how stupid they were. Another drawback is that it took about 10 minutes to diagnose and fix the issue, then explain it to the user.

The user is happy and will go about their day thinking you're a wizard. A hero. An abolute unit. Good for you! (User will have the same issue tomorrow since you didn't give them pointers on how to fix the issue in the future, but you can be the hero again.) Total time: 2 minutes.

References

• The OSI Model