11.7 Determining the Path MTU Using Traceroute

Although most systems don't support the path MTU discovery feature, we can easily modify a version of traceroute (Chapter 8) to let us determine the path MTU. What we'll do is send packets with the "don't fragment" bit set. The size of the first packet we send will equal the MTU of the outgoing interface, and whenever we receive an ICMP "can't fragment" error (which we described in the previous section) we'll reduce the size of the packet. If the router sending the ICMP error sends the newer version that includes the MTU of the outgoing interface, we'll use that value; otherwise we'll try the next smallest MTU. As RFC 1191 [Mogul and Deering 1990] states, there are a limited number of MTUs, so our program has a table of the likely values and moves to the next smallest value.

Let's first try it from our host sun to the host slip, knowing that the SLIP link has an MTU of 296:

 sun  % traceroute.pmtu slip  traceroute to slip (140.252.13.65), 30 hops max     outgoing MTU = 1500      1  bsdi (140.252.13.35)  15 ms  6 ms  6 ms      2  bsdi (140.252.13.35)  6 ms     fragmentation required and DF set, trying new MTU = 1492      fragmentation required and DF set, trying new MTU = 1006      fragmentation required and DF set, trying new MTU = 576      fragmentation required and DF set, trying new MTU = 552      fragmentation required and DF set, trying new MTU = 544      fragmentation required and DF set, trying new MTU = 512      fragmentation required and DF set, trying new MTU = 508      fragmentation required and DF set, trying new MTU = 296      2  slip (140.252.13.65)  377 ms  377 ms  377 ms

In this example the router bsdi does not return the MTU of the outgoing interface in the ICMP error, so we step through the likely values for the MTU. The first line of output for a TTL of 2 prints a hostname of bsdi, but that's because it's the router returning the ICMP error. The final line of output for a TTL of 2 is what we're looking for.

It's not hard to modify the ICMP code on bsdi to return the MTU of the outgoing interface, and if we do that and rerun our program, we get the following output:

 sun  % traceroute.pmtu slip  traceroute to slip (140.252.13.65), 30 hops max      outgoing MTU = 1500      1  bsdi (140.252.13.35)  53 ms  6 ms  6 ms      2  bsdi (140.252.13.35)  6 ms     fragmentation required and DF set, next hop MTU = 296       2  slip (140.252.13.65)  377 ms  378 ms  377 ms

Here we don't have to try eight different values for the MTU before finding the right one ”the router returns the correct value.

The Worldwide Internet

As an experiment, this modified version of traceroute was run numerous times to various hosts around the world. Fifteen countries (including Antarctica) were reached and various transatlantic and transpacific links were used. Before doing this, however, the MTU of the dialup SLIP link between the author's subnet and the router netb (Figure 11.12) was increased to 1500, the same as an Ethernet.

Out of 18 runs, only 2 had a path MTU of less than 1500. One of the transatlantic links had an MTU of 572 (a value not even listed as a likely value in RFC 1191) and the router did return the newer format ICMP error. Another link, between two routers in Japan, wouldn't handle a 1500-byte frame, and the router did not return the newer format ICMP error. Setting the MTU down to 1006 did work.

The conclusion we can make from this experiment is that many, but not all, WANs today can handle packets larger than 512 bytes. Using the path MTU discovery feature will allow applications to take advantage of these larger MTUs.