Years ago, I lived in a small military town attached to a naval base. There were few ways for a civilian like myself to become employed on base, and the first one I latched onto was to get some sort of IT certification. I was good with computers, and I knew I wanted to work with them. So I looked up some certs, picked a few, got the books, and got to studying.
The first of these was a CompTIA A+ Certification book. My first A+ book was from the late 1990s and covered a great deal of very obsolete hardware (I read this around 2008 / 2009), but it also covered a lot of ground with general troubleshooting guidelines. One of the things discussed in this book, and in the “modern” 2009 book I later bought, was the OSI model.
The way that the OSI model broke down data communication opened up something in my mind, and I started to see tech-related problems in an entirely new light. For this reason, I wanted my first “how to solve it” post to be about the OSI model. I truly believe it’s one of the best tools available for troubleshooting technical problems.
First, I’m going to go over the OSI model itself (including all 8 layers)*, then I’ll go over ways to actively use the model in a general troubleshooting capacity.
This won’t be a vague handwaving “if you know x then you can definitely do y.” I’m going to actually demonstrate how you can apply this knowledge. The reason I’m spelling this out ahead of time is because I’ve seen many blog posts and even textbooks do that exact thing. I’m not here to assume your level of knowledge beforehand — so I’m going to start from the ground and work my way up.
If you’re already familiar with the OSI model and its layers, feel free to skip the next section. (Or read it and correct me if I’m wrong; a lot of this is based on memory and personal notes.)
What is the OSI Model?
The OSI model (also known as the Open Systems Interconnection Reference Model) is traditionally discussed in terms of networking. In short, it’s an abstract model used to discuss various networking issues without getting into concrete details. The OSI model doesn’t actually do anything — it’s just a reference model that describes how computers communicate over a network.
There are seven layers to the standard model. Every layer in the model serves the layer above it, and is served by the layer below it. So the Data Link layer is served by the Physical layer, and serves the Network layer.
The OSI Model layers, in very simple terms:
You’ve probably heard some grouchy IT guy grumble about “layer 8 problems” as he toiled away on something he was equally grouchy about. I don’t mean “layer 8” in this same regard; it’s not derogatory here. It’s simply another equally important “layer” to discuss in the troubleshooting process.
The OSI model not only defines the seven layers in an abstract sense, but it also describes specific network protocols that are used by each layer. This is so different applications can reliably communicate with each other at the same layer. While it’s handy to know these, we won’t be focusing on them here. You can find out more at Wikipedia.
Why is This Important?
Understanding how data flows through this model is critical in understanding where to look when that flow is interrupted. When you answer a phone call and a customer says, “I pressed the Print button but it’s not working,” having this model in mind will help you quickly eliminate dead-ends and get straight to the problem — and from there, the solution.
In another article we’ll explore how to tease out the “real” problem when someone says something like, “it’s not working.”
The Layers in More Detail
1. Physical Layer
The lowest layer of the OSI model. The Physical Layer includes the physical equipment involved in data transfer. It defines how long each piece of data is and handles the translation of that data into the electrical pulses that are sent over the wires. It also relates electrical, optical, mechanical, and functional interfaces to the cable.
2. Data Link Layer
The Data Link Layer takes data from the Physical Layer and arranges them into chunks called frames. Included in these chunks is control information indicating the beginning and end of the data stream. This layer can also detect and, possibly, correct errors within the data frames.
This layer is unique in that it’s the only layer of the OSI model that is actually divided into two sub-layers:
- Medium access control (MAC) – in short, the unique physical address of devices
- Logical link control (LLC) – handles encapsulation and error checking of data frames
3. Network Layer
The Network Layer is responsible for logical addressing of messages from one node to another connected in different networks.
Think of this layer as a traffic cop. It’s able to judge the best network path for data based on network conditions and message priority. This layer manages the traffic through packet switching, routing, and controlling congestion of data.
4. Transport Layer
The Transport Layer provides the means of transferring data from host to host while maintaining data quality. This layer’s most important job is to provide error checking and reliable end-to-end communications.
It verifies that packets are received properly by the destination host, controls data flow, and troubleshoots problems with transmitting or receiving data. The Transport Layer also takes larger messages and segments them into smaller ones, or smaller segments and combines them into single pieces, depending on the direction of traffic.
5. Session Layer
The Session Layer allows applications on different computers to establish, maintain, and end a session. Think of a session as a virtual conversation.
6. Presentation Layer
This layer performs protocol conversion and manages data compression, data translation, and encryption. For instance, character set information (UTF-8 vs ASCII) is determined at this level.
7. Application Layer
The layer at which Users can interact directly with software applications. The application layer has no real way to determine the availability of resources on the network — it simply provides access to the data that’s being displayed to the User.
8. User Layer
The User Layer could possibly be expanded to include not just the individual person, but also the organization. Another layer with two sub-layers.
The individual person is the one who calls asking for help when there printer isn’t working properly. They’re clicking the buttons on the screen, relaying info to you, and following your directions. Just like each of the above layers, interfacing with this layer takes training, thought, and sometimes, patience.
The organization is responsible for installing that printer and making sure the user is trained on how to connect to it. It could also be responsible from some business rule that nobody can print personal stuff on company time.
How to Make the OSI Model Work For You
Now that was fun stuff, huh? But how is it really applicable today? Isn’t the OSI model dead?
Maybe. But we’re not here to talk about how the OSI model literally relates to networking. We want to emulate its abstract, generalized approach. Separate the applicable pieces and put those to use. What I’m talking about is sort of an inductive and deductive approach rolled into one.
The arts of deduction and induction are two of the most valuable skills you can learn.
With inductive reasoning, you take observations of specific events or things, find patterns withing these things, formulate some hypotheses based on the patterns you find, and end up with general theories. The bottom-up method.
With deductive reasoning, you work in the reverse: start with a general theory, formulate a specific hypothesis to test, confirm results. The top-down method.
It can sound like a Catch-22, and it sort of is. The important thing to remember about this is that the process always changes, and you must always be ready to “remap” your knowledge. Take what you learned before, slice it up, remix it, generalize what can be generalized, specify what can be specified.
Simply knowing a thing won’t help you become better at solving problems. You must take an active approach. You must be willing to formulate your own sets of rules, and throw them away if they become inaccurate or no longer useful. You have to be able to garner an intimate understanding of a system and its components and their relationships and turn that specific knowledge into a general understanding of the interconnectedness of any system.
The most intelligent and successful people I know never adhere to some walkthrough just because the walkthrough says so — they add their own knowledge to what is being presented.
It’s perfectly fine to be a process-oriented person. Often in a support role, you’re presented with some sort of script to read from or reference. Customer calls about X, you open the X page in your manual and go through the questions.
Don’t do this.
Your job is manifold, but primarily it is to know what you are supporting, and to solve people’s problems. Ditch the script. Do these two things. Nobody did anything good by just doing what they were told.
Put another way: You won’t learn how to program anything by just following steps in a book. Yes, you will have made what the book instructed you to make. But what have you learned, other than how to make that thing? Only by exploring, asking questions, and extrapolating will you truly expand your knowledge.
Extrapolate. Be wrong — and then be right.
My dad always told me, “The only way to really know how something works is to break it.”
So we break up this model into its distinct parts and we ask, “What is this actually describing?” Not in technical jargon, but in a real-world application. Going back to the above example for when you’re trying to figure out why a printer isn’t working. There are many approaches to take, but today we will focus on two.
One End to the Other
Now that I’ve railed against scripts and checklists, let’s talk about using the OSI model as a checklist for troubleshooting.
The most basic approach you can take to solving a problem is to ask questions from one end to the other. Of course, not all layers will always be applicable. But it’s still an effective approach. Use the model as a guide: where to begin, and which direction to go.
We go back to the problem: “My printer isn’t working.”
We go down the list:
- Physical: Is the printer plugged in? Is it on? Is it plugged in directly to the PC, or is it a network printer?
- Network: Is the printer visible on the network? Does it respond to ping?
- Transport: Is the port blocked or used by another process?
- Application: Are the right printer drivers installed? Can anything else print on this printer from this machine?
- User: Did the user choose the right printer? Did they accidentally print to PDF?
Which end of the model you start with will depend on the person you’re talking to.
Sometimes you’re faced with a problem you’ve never seen before, and have no clue where to begin. Using the model as a sort of workflow generator will guarantee you at least have somewhere to start asking questions. When in doubt, start at the Physical layer, and work up. Once you start asking questions and getting answers, you’re over halfway to solving the problem.
Always check your connections.
The Generalized Approach
The OSI model, at its core, was developed to describe in abstract terms the relationships between a specific component of networking, and the components that connect to it.
When you’re trying to solve a problem and you’re looking at a specific component in a system, use the same idea. What else in the system touches this component? What is the purpose and nature of this connection? Did this component, or any of its adjacent components, change recently?
Asking “what changed?” can usually get you to a solution very quickly.
It may be useful, if you work for a software vendor, to make an “OSI model” of your own software and its components. This exercise will help you gain a more intimate understanding of your own product. It will also be a great resource for others on your team. Even more — it could be used as a training tool for both new employees and your customers.
This approach has given me the best mileage. From the support angle, knowing and having mapped out “feature X ties into feature Y but goes through feature Z first” saves so much time when someone calls and says, “I can’t get feature Y to work right.”
Sometimes it takes a little bit more intuiting than you’re used to. More following your gut. But one thing I’ve learned is: your gut is usually right.
We’ve talked about the usefulness of frameworks, and their pitfall. You shouldn’t always blindly follow a checklist or a guide. Develop your knowledge of what you’re supporting and create your own frameworks. And don’t be afraid to adjust your map as your knowledge of the territory grows.
I may not be finished talking about the OSI model, but this post is already over two thousand words, so I will return in another post to finish. I hope something here has been helpful for you.