The Good Old Days
Once upon a time, IP networks were simple. We had shared Ethernet connections and serial connections. They each had their own troubleshooting methods, but they were basic. We ran IP (and a pile of other protocols, but we won’t get into those) on top of those and followed the four-level TCP/IP model (RFC 1122) to figure out the problems in our networks. We worked from the bottom up and reached a quick resolution most of the time.
Things Never Stay Simple
Maybe it never was that uncomplicated and it is just a wistful memory. RFC 1925: The Twelve Networking Truths says it was always more complicated than we thought it was. Still, things got more complicated as we added different transports to the mix.
We slowly moved from the TCP/IP model as a reference to the OSI model (ISO/IEC 7498-1:1994) in order to break things down more specifically, particularly at the Internet layer. Problem-solving still worked its way up from bottom to top, but through more detailed steps.
The Growing Popularity of Encapsulated Protocols
One of the interesting developments that eventually occurred was the idea of using IP networks themselves as generic transports. Instead of developing new physical networks, we started abstracting things using encapsulated protocols and running them over our existing networks. We don’t care about the underlying transports as much, but this moves the complexity rather than eliminating it. There’s a reference to that in RFC 1925 too.
When we’re talking about encapsulated protocols, we’re usually talking about running an overlay network over a base network. Most of us are more than familiar with GRE, L2TPv3, VXLAN or MPLS for this sort of application, but it doesn’t stop there. Mixed voice and data networks brought us H.323/RTP and SIP/RTP. Converged data and storage networks have added FCIP and iSCSI to our list.
These latter protocols can be treated as services and no different from any other application that runs over our networks. One thing sets them apart: Each of them existed independently on other physical layers before migrating to IP networks.
When we diagnose problems with any or all of these, we have to look at two or more layered models to be effective.
Layers Within Layers
Isolating problems when many models are in play can be tricky. Before we work our way up, we have to isolate which model is most likely to be the culprit. Most of the time, we’re going to be working from the outside in because the entire encapsulated model rides on top of the layers of the base network. If we know that we’re dealing with a problem that’s specific to the payload, we may start from within and work our way out. Either way, the old logic of starting from the bottom and working our way up still holds.
The Whisper in the Wires
We are taught from day one to troubleshoot from the physical layer up. Encapsulation doesn’t change that, but it does give us another dimension to consider. Does our troubleshooting begin at the outermost protocol model and work its way in, or does it begin at the innermost and work its way out? That’s going to depend a lot on the scope of the problem. As always, these models are there to help us with reference points, but the process itself is going to vary depending on the circumstances.
We’ve all heard people say that the OSI model isn’t relevant anymore. In some ways, this may be true. For troubleshooting, it still works as a model. We just need to apply it recursively now.
Read My Other Blogs
The Conflicting Demands of Auditing Secure Web Traffic
The Ever-Elusive Single Pane of Glass
Big Ideas in Small Design: SMB vs SME
