The Open Systems Interconnection Model or OSI Model is an ISO (International Organization of Standards) conceptual model to standardize the communications of systems. It aims to remain agnostic to the underlying architecture or technology as much as possible. OSI can be viewed as an abstraction of networking from the physical layer all the way up to the end user application. Many networking and system administration certifications reference, or at least build off of, the OSI Model since it provides a way to approach networking which is clear and concise without focusing on the actual technology being used. A layer 2 switch is a layer 2 switch whether it uses ethernet or 802.11.
The OSI layer approach is also extremely useful for troubleshooting. If a lower level is impacted, looking higher won’t do anything. A broken ethernet cable means you shouldn’t bother delving into the router’s configuration to solve the issue. If a session can’t be established, there probably isn’t a point looking at SSL. If you can find what’s broken (i.e. which layer), you just have to look down the chain and not up.
OSI vs. TCP/IP
Unfortunately, OSI lost the standardization war with TCP/IP for all intents and purposes. Basically everything is built using TCP/IP. Virtually no one uses the OSI protocols in their stack.
So, why learn about the OSI model in the first place then?
OSI arguably set the standard for the modern networking stack. Even though no one really cares about OSI protocols in the real world, the concept has bled over into TCP/IP (despite RFC3439 [section 3.]). There are layer 2 and layer 3 switches, and what they do is substantially different. A lot of higher end equipment advertises where it can be on the OSI model.
If you’re going for certs, understanding OSI is a must. Understanding the general concepts will help with both networking and system administration. Keep in mind though, OSI is good and useful, but it shouldn’t trump the practical implementations of whatever you’re working for. Many devices don’t adhere strictly to OSI (nor should they).
OSI Layers
Th OSI model divides the network into 7 layers, they are the: Physical Layer, Data Link Layer, Network Layer, Transport Layer (the magic layer), Session Layer, Presentation Layer, and Application Layer. The Transport Layer is the magic layer which corresponds to our Datagram or packets (in TCP/IP). It marks where we go from the network back towards the individual node.
1. Physical Layer – Symbol
The physical layer is the actual physical hardware we’re running everything on. Ethernet is the physical layer, token ring is the physical layer, the actual connection for 802.11 wireless (PHY) is the physical layer. How you get your bits or symbol across is the physical layer.
Our symbol is how we turn our bit into something which goes across our medium, be it a voltage spike or a radio wave. The layer specification includes things like effective range, pinouts, voltages, timing, etc. How does your data get from A to B? The physical hardware that makes it happen is the physical layer.
2. Data Link Layer – Frame
The data link layer abstracts a layer above the physical layer. How does data get from A to B over our physical medium, and how do we account for it reaching its target? The data link layer has some level of error correction and establishes node to node communications. The MAC and LLC portion of 802.11 operates at this level, as do most dumb switches.
We communicate with frames in the data link layer. A frame is the total encapsulated packet of data encapsulated with what it takes to get from A to B before the actual physical transmission of bits over our medium. In TCP/IP, this will be our packet with some padding so that the device knows what to do with it and has a standardized frame of data to work with (preamble, destination, source MAC, CRC checksum, etc.).
Frames are everything which is necessary to get our actual parts we care about between nodes. It is the most basic, and also most complete piece of networking data.
3. Network Layer – Packet
Before we were just concerned with nodes physically connected to each other being able to communicate. The network layer is where we actually route our traffic and focus on the unit of the packet. Routers and the majority of the 802.11 protocol work at this layer. Devices talk to each other and know how to send data to other things outside the immediate device. We want node a to talk to node b even though we might have to jump from device A to device B to do so. Node a also shouldn’t talk to node c. The network layer makes this possible.
The network layer operates on packets. Nodes or devices are allocated addresses so that anything at the network layer can have a way to send a packet so that another device can respond on behalf of that address. If we have switch A and switch B, the actual routing will allow them to talk. This layer is responsible for making sure that the data being sent follows the specifications for a packet, so data may be split up as necessary.
This can be thought of as IP in the TCP/IP scheme.
4. Transport Layer – Datagram
The transport layer is the magic layer; this is where TCP, UDP, etc. exist in the OSI model. The transport layer is also considered the magic layer because it is where we get the transition from the physical data and how it gets around the network to actually doing things with the nodes. This is where we from the network back into a system.
Every layer up until now was focused on just talking to things, but this is the first layer where we have direction and a way to actually say something. The network layer lets us find and pass data to a node, but this is where we let the nodes actually communicate.
The transport layer uses datagrams. Datagrams are the actual data bits embedded in the packet. For TCP/IP, IP gives us the packet, TCP gives us a way to actually use these packets to establish connections. We can send a packet down the line, but our process here allows us to tell the other node we received it and create an actual state for our connection. We perform our handshake with SYN, SYN-ACK, ACK in TCP here.
5. Session Layer – Data
From this point on, we only deal with data for the actual nodes to handle. Now that we can establish a state, we can establish a session. The session layer is where we actually get nodes talking to each other at a higher level. The lower levels should be handled by the OS and networking hardware.
Sockets are the most common way to deal with the session layer in TCP/IP. Raw sockets basically establish our TCP connection and allow the devices to create a session and talk to each other as necessary. At this point, each node will just see raw data going back and forth. Is it encrypted or is it plain data? What are we dealing with? It’s up to them to establish the connection to spit data back and forth at the session layer, not necessarily to work with it.
6. Presentation Layer – Data
After we establish our session, we establish context at the presentation layer. Node a is talking to node b, now it needs to tell node b we’re about to use a secure connection, here is the handshake, or maybe it tells node b it’s about to send over a PDF of x bytes. This is where TLS/SSL, and MIME is in the TCP/IP stack. This can also be something like a compression header or similar as well. We’re presenting what we’re about to send to the node. Without this layer, how would the endpoint know what data is coming without it being predetermined (which means some kind of proprietary protocol in the old days)?
7. Application Layer – Data
This is where we finally have our applications handling data. The actual implementation and handling of this is all independent of the protocol. All that matters here is that our program does what it’s supposed to with the data it’s provided. Everything above the transport layer is handled on the node itself, the transport layer is the glue between the node and the network, and all of the lower layers are handled by the network.
Applying OSI For Troubleshooting
If you run into a networking issue, where should you look? Some people say to look at ping or telnet among other tools. But, why do these tools work?
One of the first goals of figuring out why something isn’t working is to look at where it’s breaking down. Are we having issues with the actual network or the endpoint? It doesn’t matter how fault resilient a protocol is if it can’t find the address it’s trying to connect to. There’s no point trying to debug an application if the session can’t be established.
Track down where the network breaks down. Tools like ping tell us if we can route to something in most cases (assuming ICMP isn’t blocked and all of that). telnet lets us see if we can establish a socket at all (for most modern uses). Tools like trace route let us see if we can route to the item and where the breakdown might be by trying to connect to everything along the way. None of these tools tell us much if the breakdown is a bad port or similar, but they help us narrow down the ultimate cause.
The trick is to start somewhere and work towards the problem. If you can ping the server and telnet on the requisite port, is it going to be a routing issue? Probably not. If you can’t find the IP on the network, then you probably don’t need to mess with the settings in the program on the node itself. Once you figure out which layer is breaking, you know you don’t need to go any higher.
Conclusion
Though TCP/IP won the war, the marks of OSI are left all over the network stack. A layered approach is useful for both troubleshooting and conceptualization. Don’t get too married to the model since TCP/IP is a bit more fluid than OSI.
Apply the OSI model to troubleshooting to help track down where things are breaking down. A layer 2 device is going to do absolutely nothing to help with routing. Working on you layer 3 device won’t fix a broken cable. Each part of the network has its own function. Learn what they are and why they matter so you can understand networking theory better, as well as troubleshoot what is breaking and why.
Featured image by Michael Schwarzenberger from Pixabay