Troubleshooting Mismatched MTUs – CompTIA Network+ N10-006 – 4.6

A mismatched MTU can cause lack of connectivity and performance problems. In this video, you’ll learn about the maximum transmission unit (MTU) and how to determine the best MTU size.
<< Previous: Troubleshooting Network ConnectivityNext: Troubleshooting NIC Teaming >>

An MTU is the maximum transmission unit. This is the largest amount of IP packet information that you could send through the network from one end to the other and avoid doing any fragmentation along the way. This process of fragmentation slows things down. If we do have to fragment along the way, the packet is split up into smaller pieces and those are sent to the end station. If we lose any of those smaller pieces, the entire packet has to be resent. This also requires additional overhead along the way because devices have to collect all of the pieces before they can put them together and then send them through to the next connection.

When one station is communicating to another, it’ll often find what the correct MTU happens to be, but these automated processes of determining the correct MTU don’t always work properly. You may also have a challenge that the routers between the end stations may be filtering ICMP. And if your application is trying to send information, it may require getting an ICMP message back to know if it needs to fragment or not. And if it’s filtering out the ICMP, you’ll never get that message, and the MTU will be set incorrectly.

Let’s look at the way that an Ethernet frame is constructed and that will give us a better idea of why the MTU is so important. Let’s first start with the data. Your application will need to send data from one device to another, so here’s the TCP data, and it puts a TCP header on the front so that the system knows where to send that particular piece of information. Then it’s sent to the IP layer, which puts an IP header on the front of it, then it’s sent down to the Ethernet card, which puts a DLC header, or an Ethernet header on the front and a frame check sequence on the back.

The part of the frame that we often refer to as the IP packet section, it’s this 1500 bytes that includes the IP header, the TCP header, and the TCP data. When you’re trying to determine an MTU you usually can figure out what the MTU you should be, and it’s really going to stay that number until something dramatic changes with the network infrastructure. That’s because the MTU is generally decided on what the different devices are from end to end.

For example, if you’re tunneling traffic, you may not be able to tunnel a full 1500 bytes because the tunnel itself has to put its own headers around that information. So you may have to create a smaller MTU if you’re going through a tunneled connection. If you are going into one of these connections that requires a smaller MTU and your application is sending this data with a bit inside of the IP packet that says don’t fragment this information, then obviously, the router can’t do anything with it.

It needs to fragment to send it on its way, but you’ve told it specifically do not fragment this data. The router will send an ICMP message back to the original station saying I wasn’t able to send this on its way because I need to fragment but you’ve told me do not fragment this data. We can start troubleshooting what the MTU size should be set to using ping. We’ll tell ping to send information from one side to the other, we’ll specify that this data should not be fragmented, and we’ll send the largest amount possible, which, in this particular case, would be 1472 bytes.

Now, if you recall, the actual size should be 1500 bytes, but because this is being sent with ICMP, there’s an ICMP header put on to the front that’s 8 bytes and 20 bytes of an IP address inside of that as well, which means that the total size of ping data is going to be 1472. And when you send that out, that will be a maximum of 1500 bytes.

To perform this test in Windows, we use the ping command. I’ll use a dash f to specify that this data should not be fragmented. I’ll use dash l to specify the size of the ping data, and that’s 1472, and then I’ll put the IP address of where I’d like to send this information, and we’ll try to send it. And if we get a message back that says I was not able to send this data through because an MTU is set and I need to fragment this data, or we received no response at all back from the ping, then we know it wasn’t able to get to the other side.

So we can start decreasing that number from 1472 to lower numbers to determine how low do we go for it to pass through this particular connection to the other side? And when we finally determine what that number is, we can set that as our maximum transmission unit.