Network communication consists of a series of well-orchestrated standards and processes. In this video, you’ll learn about data encapsulation and decapsulation, TCP flags, maximum transmission unit, and IP fragmentation.
Getting data moved from one part of the network to the other relies on something called a PDU, or a protocol data unit. Sometimes you’ll hear these referred to as transmission units, because we’re taking a little bit of data and transferring it across the network as a single unit. For example, if we’re running Ethernet, we know that Ethernet is going to send everything within an Ethernet frame from one device or MAC address on the network to another MAC address that’s on the network.
Ethernet, though, doesn’t care what’s on the inside of this particular frame. It’s simply encapsulating all of the data that may be underneath it and sending that across the network. A similar thing happens at the next layer up with layer 3, or the IP layer, where everything within the IP layer is being sent across the network from one IP address to the other. Inside of that IP packet is UDP data, TCP data, or some other type of data, but IP doesn’t care what’s on the inside. It simply knows that it’s moving data across the network from one IP address to another.
And where there is a TCP header or UDP header, there’s probably going to be a TCP segment, or what we call a UDP datagram within that particular part of the packet. Here’s an illustrated view of how this operates at each layer of the OSI model, and how data is encapsulated between each one of those parts. For example, let’s start with using an application. We’re sending data within our application, such as a web browser, and we need to get that data sent from the web server to the web client.
That application data exists at OSI layers 5, 6, and 7, or what we will generically call the application layers. To be able to send that application data, we need to transport it across the network using the TCP protocol, so we’ll put a TCP header right in front of that application data and send it across using that OSI layer 4, or transport layer. We have to have an IP address that is able to send this TCP data and the application data that might be inside of it, so we need to add an IP header so that we can send information from one IP address to another IP address.
And lastly, over Ethernet, we need to have a DLC, or data link control, layer 2 frame header. And in many cases, there’s also a frame trailer to indicate where the end of this frame might be. The layer 2 frame header encapsulates all of the information within. So inside of this frame will be an IP header, a TCP header, and ultimately, the application data that we would like to send to the other side of the network.
Let’s expand this view to show both the sending and receiving device, and view the way the network might interoperate with all of this. So there’s our application data at OSI layers 5, 6, and 7. On the left side is the source address that’s sending this data, and we somehow want to get that application data to this destination device on the other side of the network. We’ll start by encapsulating this data by including a TCP header, an IP header, and ultimately, the frame header and frame trailer.
That information is going to be sent across the network, where it will then be received by the destination device. The destination device, though, needs the application data that’s inside– it doesn’t need all of this other information. So it will begin decapsulating this information– removing the frame headers, removing the IP header, and ultimately removing the TCP header so that it can then access the application data. And finally, we’ve been able to transfer this data from the source device through the encapsulation process, the decapsulation process, and finally be able to receive the application data at the destination.
Here’s another way to visualize how this data is being encapsulated and decapsulated on both sides. We can start with our layer 5 through 7 application, data such as HTTPS, IMAP email information, or SSH terminal screens, where we’re then going to take all of that and encapsulate it within some type of layer for protocol. This is commonly TCP or UDP.
We will then encapsulate the layer 4 traffic within layer 3– which, these days, is commonly IP traffic– And then finally, layer 2 information on Ethernet. That would be a media access control address or MAC address, and that encapsulates all of this data within it. In previous views of this data, we mentioned that there’s header information that precedes the data associated with these layers. And the header information is important because it tells the rest of the data how it should be processed.
For example, on layer 4, we have TCP data. And within the TCP header, such as we have here, there’s information called a TCP flag. This helps us understand how we can process this data as it’s going through the network. This control information is setting bits that are within the header of this packet, and each one of those bits has a particular definition. This means that the device that’s receiving this data can interpret those bits and understand how to process the data properly.
We call these bits control flags, and we can identify whether a flag has been turned on or turned off, and then decide how these particular flags can affect the data flow. For example, we can look at the flags in this particular protocol decode and we can see that one flag has been set to 1. That means the data that’s contained within this TCP part of the packet is acknowledgment data that has been set. You can see a number of different flags.
For example, if the SYN flag is set, that means that there’s a synchronization of sequence numbers that’s occurring. If the push flag, or PSH flag, has been set, it pushes the data to the application without buffering anything else that might be incoming. There’s also a reset flag, or RST, that resets the connection, and a FIN flag that designates that this is the last packet that will be sent by the sender.
By turning on or off different flags, we can change how a device may interpret the rest of the data that is being sent using that TCP header. Not only are there flags within the TCP or UDP header– there are also flags within the IP header. You can see an example of those flags right here. Most of the flags being used at the IP header deal with the fragmentation of data.
There may be times when you want to send traffic across the network, but because of the architecture or design of the network, you’re, not able to send packets that are very large. In those cases, you may need to fragment the data to be able to get through the smaller size networks. We determine the maximum size that you’re able to send using something called a maximum transmission unit, or an MTU.
This designates the size of the data that we’re able to send through the network without having to fragment any of that information further. The reason we don’t want to fragment is that it commonly slows down the overall flow of traffic, and if you can optimize your network communication so that you’re not fragmenting, you’ll have a much higher throughput of traffic. This also eliminates any overhead of having to chop the data into smaller pieces, send those individual pieces across the network, and then rebuild those pieces when they get to the other side.
That’s why it’s important to know the MTU value that would be used all the way through the network from the beginning of the communication all the way to the very end. But understanding what the MTU might be could sometimes be a very complicated process. There may be many different hops that are used to be able to communicate from point A to point B, and each one of those hops may be using a different MTU. There is an automated process that your system will use to attempt to determine what the MTU is when communicating to that other device, but unfortunately, if ICMP is filtered in that communication, there’s no way to automate that process, which means you’ll have to manually set the MTU on your side.
Let’s take a look at what this fragmentation really means. We’ve seen before, where we’ve taken some TCP, data we put a TCP header in front of it, an IP header in front of that, and finally, a DLC header on the outside to send it across our Ethernet network. The data that’s on the inside from the IP header all the way through to the data that’s being transmitted is our IP packet, and the maximum size of an IP packet on an Ethernet network is 1,500 bytes.
If there’s no fragmentation that’s occurring anywhere on the network, you’ll be able to send all 1,500 bytes through the network without having any of that data fragmented along the way. Let’s take an example, where we can only send a very small amount of data through the network. In this example, 16 bytes of data is the maximum transmission unit that’s supported on this particular network.
That means we might have 44 bytes of data that needs to be fragmented, and as we’re sending it through the network, we’re going to fragment the first section of it, or the first 16 bytes. We’ll then send another frame of data that has another 16 bytes, and the last frame is going to send the remaining amount of data, up to 16 bytes. So if we do need to send data across the network that’s 44 bytes in length, but the MTU of this network is only 16 bytes, we’re going to end up taking a single frame and splitting it up into three separate frames.
Fortunately, when you’re designing and creating a network, the MTU is usually set during that creation process, so once the network is built, it’s very unusual for that MTU to change. We also know that there are going to be MTU changes if we have to tunnel any information, so if you’re using a VPN of any type, you’re probably going to need to set some MTU or ensure that the MTU is going to be properly set automatically.
There is a flag within the IP part of the header that will specify that the information you’re sending should not be fragmented as it goes through the network. And if you send data that’s too large with a Don’t Fragment bit set, that data may not be able to make it all the way through the network. And very commonly, you’ll receive an ICMP message saying that this data is too large to send through this network.
If you’d like to test your network between one device and another to see exactly what the MTU might be, you can test by using the ping utility. You can specify in ping to set that Don’t Fragment bit, and then you can force a particular size of data to be sent through the network. In the case of Ethernet, the maximum size would be 1,472 bytes. Now, normally, that would be 1,500 bytes, but the ping command is specifying that 1,500 bytes minus the ICMP header of 8 bytes, and minus the 20-byte header of the IP address itself, leaving us with 1,472 as the maximum MTU that would be used for the ping command on an Ethernet network.
In Windows, you can test this by using the ping command with the -f, which tells us to ping with the Don’t Fragment bit set, and then with -l, which specifies the length of data you would like to use in bytes. And in this case, it’s 1,472 bytes. And if you’d like to try this against Google’s DNS server, you can then use the IP address of 8.8.8.8.
Let’s try this ping with the -f to don’t fragment. We’ll do -l of 1,472 bytes, and let’s specify the DNS for Google. And you can see that we are able to send traffic with 1,472-byte ping frames from our device all the way through to Google’s DNS, and then we do receive a response back from Google saying that that information was received. If we tried to do a packet that was larger than 1,472– let’s try, for example, 1,482– we’ll send that information, and it says this information needs to be fragmented, but you’ve set the Don’t Fragment bit, which means it’s not going to be able to traverse this particular network, and you’re going to need to use a lower MTU. If this was going over VPN, we would simply keep moving that number lower and lower until finally it was able to send through the network, and we would be able to receive replies to our pings.