PDUs are the building blocks of network communication. In this video, you’ll learn about protocol data units and how they are used at different layers of the OSI model.
<< Previous Video: Unicasts, Broadcasts, and Multicasts Next: Network Segmentation >>
A protocol data unit, or a PDU, is a unit of information that is sent by a protocol at a particular OSI layer. For example, a switch is going to operate on the Ethernet PDU. That protocol data unit is the most important thing so that the switch knows where to forward that frame. But inside of that particular frame is data that the switch doesn’t really care about.
The same thing applies if a router is forwarding IP traffic. It’s concerned about the IP addresses. But it doesn’t care about the other data that might be involved with other protocols inside of that packet. And if you’re working with TCP or UDP, the protocol data units for those would be a TCP segment or a UDP datagram.
Let’s see how these different PDUs operate at these different OSI layers. This source device would like to send application information to that destination. So we start with the data associated with that app. To be able to send that application information, we’re going to add on a TCP header. So there’s a protocol data unit inside of that TCP packet that contains the application information.
Then we need to add on an IP header, which of course is going to have a PDU inside of that that contains that TCP header and everything else. We’re also going to need to put MAC addresses. So we put a layer two data link frame around all of that. And then we send it down to layer one and send it across the network. When that frame arrives on the other end of the network, we’ve got this layer two data link frame.
And now we need to strip off the frame header, the IP header, and the TCP header to finally get back to the application PDU for the destination device. The size of the PDU that you’ll transmit will be determined by the MTU, or the maximum transmission unit. This will determine the maximum size of an IP fragment to send across the network without having to fragment that data along the way.
Fragmentation is commonly seen as having a negative impact on overall communication efficiency. That’s because it does take time to fragment the packet into smaller pieces and send it across the network. And if you lose any of those fragments along the way, you have to retransmit all of the fragments that make up that packet.
Another problem with fragmentation is sometimes you don’t know that it’s actually happening. It’s difficult to know what the actual maximum transmission unit size would be from one end of the network to the other. The process of determining the MTU between one device and another is commonly automated when the session is established. But if there is some type of filtering between the devices, especially with ICMP, you may not be able to automatically configure an MTU between devices. And it may be up to you to manually configure these MTU values.
Let’s look at how we build an Ethernet frame and how fragmentation affects this information. Let’s start by sending some TCP data across the network. The maximum amount of TCP data that we can send in a normal Ethernet frame is 1,460 bytes. And we’ll put a 20-byte TCP header on the front of that. We then need an IP header, which is another 20 bytes. And then we’ll wrap Ethernet around all of that, which will require an additional 14 bytes on the header and another four bytes for the frame check sequence.
This is where we might run into problems because now we’ve hit the maximum size of an Ethernet frame at 1,500 bytes. What if we now need to tunnel all of this information over a different connection, perhaps over a VPN? Since we’ve already hit the maximum size of Ethernet, we’ll need to fragment this data before we send it through the tunnel.
Here’s a very simple example of taking an IP header that contains a TCP header and TCP data. And we’re needing to fragment all of that TCP information so that it can be sent through the network. Fortunately, an MTU is not something that changes very often. It’s usually based on a type of communications medium or method of communication over the network. Once you set the MTU, you usually don’t have to go back and make any changes to it.
And as I mentioned earlier, it’s very common to run into MTU problems when you’re tunneling information, especially over a VPN. We have to put additional headers around that IP information, which means it’s now too large to go over an Ethernet network. And we have to fragment that data to get it through that particular VPN tunnel.
Some applications don’t like to have its data fragmented. And in those cases, the application can choose to turn on a special bit in the IP header called the “don’t fragment” bit that tells all of the devices throughout the path of the communication not to fragment any of this data. Normally a fragmentation must occur along that path. A message will be sent back through ICMP to the original station, saying that this information was not able to be sent through this network because the “don’t fragment” bit was set.
It would be much more efficient if you could configure an MTU that would allow all traffic to go through the tunnel without having to require any type of fragmentation. But what is that particular value for the maximum transmission unit? One thing you can do is to use the ping command to try to determine what a good size might be.
You can start with the maximum size of an IP packet and then start working down until you’re able to ping a device on the other side of a network. You can send this ping command with a special option that turns on the “don’t fragment” bit. And then you can set it to be the maximum size of 1,472 bytes. That means that you’re using the entire 1,500 bytes, including the 8-byte ICMP header and a 20-byte IP address, making it 1,472 bytes.
If you’re in Windows, you would use the ping command with a dash f to tell it not to fragment and then a dash l to specify what the length might be. And in our case, we’re going to use 1,472. And then we’ll use the IP address of the device that’s on the other side of this communication. If that ping doesn’t work, we’ll lower the amount of data we’re sending through and try sending it again. We’ll keep lowering that amount until we finally find exactly the right amount to be able to send the largest amount of data through, without requiring any type of fragmentation.