Recent Articles

IP Subnetting Part 1 - IPv4

Despite the large number of jokes in high school about never needing to use mathematics after graduation, the art form known as IP Subnetting requires a solid grasp of math based on binary numbers (0, 1).  In this first part of my devoted attention on IP Subnetting, we'll focus on Internet Protocol version 4 (IPv4) addressing, some history, and the methods available to make IPv4 addressing go farther.

Understanding the "network" command

Many network engineers seem to misunderstand the use of the network command in routing protocols on Cisco IOS, especially once they see the usage in BGP.  This occurrence happens more frequently with those studying to become a CCNA, but may not be obvious to experienced engineers either.  Based on my own experience, I have very distinct memories of confusion when the concept I understood was first corrected by a more experienced engineer.  So let's breakdown the confusion.

Troubleshooting with OSI Model

At Layers 1-4, there are several tools or tricks available to quickly verify normal operations.  I have routinely used each of these tools for many years and expect many of them to be familiar.  Many of these tools are technology-specific, meaning that one tool has an application with one technology but not another.  I should also caution that the list below is not intended to be exhaustive or complete.  It's just a collection of my thoughts on what I find really useful.

backnext

Info Point

Building Bridges from Today to Tomorrow™

Primacore® offers consulting services tailored to your business needs, whether that requires process automation and strict, environmental standardization or if you keep an open mind to new technologies and how they can support your business functions.  Invite us into your world and, together, we can start "Building Bridges from Today to Tomorrow™"

Learn More

Overview of OSI Model

Thumbnail of Layer-to-Layer communication

I frequent Hacki's forums and I've seen something that tends to be pretty common with most folks as they are learning their way in Networking. The OSI model tends to give a lot of people fits, since it's really abstract and doesn't seem practical at first. It's one of the items on the list of upcoming articles and I figure now is a good time to break things down so we can clearly see it in practice.

Why bother?

The OSI Model does provide some really DRY reading, if you want to bother reading the entirety of the standard as it's published by the ITU-T. But the OSI model in practice provides a really useful framework for several aspects of networking, including:

  • Understanding which system components communicate in client-server applications
  • Troubleshooting an application problem as it relates to network infrastructure
  • Designing networks optimized for applications that could logically be hosted anywhere globally, are highly available, and resist the effects of latency introduced by wide-area networks.
  • Among others…

In fact, the first two reasons are where most engineers will eventually see the greatest application of the OSI model in real life, since the model should provide a step-by-step method to determine where a problem lies end-to-end from client to server. First, let's talk about the model itself (very briefly) and we'll make it useful afterwards in the next article.

Model Overview

The standard described by ITU-T X.200 is a open, reference model for how systems connect to each other. The term reference model is probably convoluted to most, but the concept behind it is hiding complex, minute details of an entire system (or part of a system) so that the system can be broken into layers. Each layer has its own special focus and the complexities of each layer are hidden from the next layer (or at least the next layer doesn't require knowledge of the others). By taking this step, each layer of the model can be viewed and acted upon in a self-contained manner. It's like isolating the brake system of a car, where you know you don't have to examine the exhaust or spark plugs to fix a problem with the brakes (thankfully!). There are instances where one layer can negatively affect other layers, but we'll leave that discussion for a later article. In the OSI reference model, seven layers are defined that provide a really high-level view of how systems connect. What follows is my brief summary of the layers (listed, in my view, from top to bottom).

Application (think web browser, email client)

Application layer usually is the easiest to understand, so we should start our discussion here. This layer can be the program running on your computer (or on a server) that connects you to Google.com, eBay, or this blog. The client application will exchange data with the server application (and vice versa) without understanding Ethernet, TCP/IP, or other networking techniques (in general). This application data requires some processing locally before sending it to the server, care of the next several layers. I've provided examples next to the layer name, to help connect the layer to a common implementation.

Presentation (think encryption, compression)

Presentation layer provides formatting for data to be transferred between systems, so the end-system can readily receive and interpret the application data correctly. This step was vital when differing standards of data format were a problem (think 7-bit ASCII vs 8-bit EBCDIC). The most common examples now would be any encryption/decryption required for transmitting application data (not VPN-based, but application-based encryption) or the use of compression within applications transmitting data between systems.

Session (think Remote Procedure Calls)

Session layer provides a way for applications to "synchronize" their client-server communication and translate between "transport addresses" of Layer 4 and the "session addresses" that represent the application. If a system were running Firefox and Internet Explorer simultaneously, the session layer keeps Layer 4 connections associated with the right browser (or the pages displayed would be unusable in most cases). A good example of this layer are the remote procedure calls (RPC) associated with many client-server applications like Microsoft Exchange and Network File System (NFS).

Transport (think TCP/UDP segments)

Thumbnail for TCP header pic

Transport layer is the first real layer of "networking" (or last, from a bottom-up perspective), as most everything above Layer 4 is really geared toward the application. Before this layer, Layers 5-7 have dealt with a chunk of application data as a whole. One of the chief functions of this layer is to segment that data for transmission. Some protocols have a built-in maximum segment size (UDP has a byte-length field of 2 bytes, to represent length of 65535 including 8-byte header). Others can negotiate this length (TCP uses a option called Maximum Segment Size — or MSS — which can be sized big or small, depending on the host). If the application data is too large to fit in one segment, multiple segments are used for the single application data chunk. Each transport layer protocol has a different header format.

Network (think IP packets or datagrams)

Thumbnail for IP header pic

Network layer provides logical abstraction for physical addressing of devices attached to a common Data Link network. If that doesn't clear things up, then let's use more practical terms. In essence, a pair of separate, Data Link networks can have a single, logical addressing scheme where all the hosts can communicate freely without requiring access to the same physical media to exchange packetized data between systems. So, communication between two systems does not require a knowledge of the physical interface address as with Layer 2. Instead, Layer 2 could be a completely different technology than the local system can support (such as Ethernet vs Token Ring). But a Layer 3 device (like a Router) could translate between both physical media and permit intersystem communication using logical addresses. Each segment received from Layer 4 is (generally) assigned a source and destination address, which represents the logical network segments on which each system resides. Other properties, such as header checksum and time-to-live, are also set based on system (and sometimes application) configuration. To repeat the earlier theme, the IP stack of a system does not need knowledge of the application protocol, encryption type, or other Layer 4-7 characteristics to provide a means of intersystem communication across large internetworks. As with the transport layer, each network layer protocol will have a different header format. Here's an example Layer 3 header in Wireshark:

Data Link (think Ethernet frames)

Thumbnail for Ethernet header pic

Data link layer provides the method for how data bits are placed on the wire as Frames. There are a lot of functions that occur at the data link layer, including error detection, negotiation of connection parameters, and many others. It's not important to discuss Data Link in depth, though I'll provide a article later that describes the difference between the two sublayers, known as Media Access Control (MAC) and Logical Link Control (LLC). It's really important to view this layer as localized, i.e. not spanning multiple networks. All data link connections exist either between just two systems (e.g. PPP, Frame Relay) or a group of systems via a media that provides access to multiple systems at once (e,g, Ethernet, Token Ring). These protocols generally interpret the first X number of bits in the frame to represent the source and destination physical addresses of the systems involved in the communication (this is less important in point-to-point connections). And it should come as no surprise that each data link protocol will have a different format for the bits that describe the data link payload. Here's an example Layer 2 header in Wireshark:

Physical (think hardware/bits)

Physical layer is the stuff you can touch. It's generally the real, physical stuff that makes up the basis of the system. In networking, this layer is a pathway for bits of data (1s and 0s) to flow between systems. Think hardware and bits when thinking physical layer. The two words that stand out to me from the standard are "mechanical" and "electrical". Every layer above this is really abstract by comparison, so physical layer components tend to be the more tangible. As such, no header is required for Physical layer communications, as only the mechanical/electrical components of a system are involved.

What does it all mean?

In the next article, I'll examine how to put these layers together to isolate and troubleshoot problems with your network and applications.