How to Troubleshoot MTU Problems with Ax3soft Unicorn

Unicorn tutorials

Preface

We often encounter MTU (Maximum Transmission Unit) issues in enterprise networking, and is an issues with several varieties. Luckily, if you have some network analyzer ,e.g. Unicorn, it’s very easy to discover these issues. regardless of the specific issue. The most common MTU related problems involve PMTU Discovery failure (MS 05-019, KB 898060) and Black Hole Routers.

Troubleshooting MTU Problems in Filter

For PMTU discovery, After a certain period of time, the ICMP Type 3 Code 4 (Destination Unreachable, Fragmentation Needed) messages are not sent by the problem system (which may be the client, server, or both, depending). For this reason, despite being told that the router support MTU discovery feature, the system still continues to send messages that exceed that limit. In traces, you can see this easily by using the Unicorn filters. Please see the figure below, it allow us to only capture ICMP packets and length > 1400 packets.

Figure 1: Filter

Troubleshooting MTU Problems in Events Tab

Let’s start capturing packet with the filter to be just created.  if the MTU problem exist in you network, you should see  “ICMP Need Fragmented But no Flag”,  Please  see the figure below:

Figure 2: Events Tab

Troubleshooting MTU Problems in Packets Tab

Switch to packets tab and find the packet to relate to the  “ICMP Need Fragmented But no Flag” event. It is packet 6,  Please  see the figure below:

Figure 3: Packets Tab

In the figure 3, you can find that the server sent a 1500 byte packet with the DF flag set to port 44445 on the remote host. Next, in frame 6, we see the router respond with an ICMP Type 3 Code 4 message, listing the MTU for the hop to be 1400. According to the source and destination addresses and ports. Finally, in frame 7, we see the server re-transport a same packet which’s length is 1500 byte. it prove that the server isn’t responding correctly to the ICMP messages. For this situation, you will need to update tcpip.sys file(currently KB 913446).
 For black hole routers, the problem can be slightly more difficult. What is  black hole routers?  by definition, don’t respond with ICMP Type 3 Code 4 messages to alert the sender to the MTU of the next hop, they just silently discard any packets that have the DF bit set and don’t meet the MTU requirement. For this reason, what you are typically looking for with PMTU failures are retransmissions on the sending side and missing packets on the receiving side. It is perhaps the easiest way to search for the black hole router in network traces to use the above filter on both the sending and receiving traces.

 When examining traces with this filter, make sure the traces were taken during the problem occurrence, and then apply the filter to both traces and compare them. If you have frames that appear in one trace and those same frames are missing from the other, first make sure that those frames are not missing due to slight timing differences in when the traces were started or stopped. For instance, if Frame 1 in your server trace is missing from the client trace, there is a good chance the server trace was started before the client trace. However, if you have frames before and after the missing frames that you can verify on both traces, then you have identified a very good black hole router candidate. Follow the steps in KB 159211 or 314825 to further diagnose and resolve the problem.

Share this