Understanding Tunnel Path MTU Discovery

After experimenting with Tunnel Path MTU Discovery on Cisco IOS based devices, I understand it’s operation. The configuration is simple and there are only a couple of optional parameters that may be set. This feature basically extends the Path MTU Discovery to GRE type interfaces. It works by copying the IP “Don’t Fragment” bit (df-bit) and instructing the router to pay attention to any related ICMP type 3 code 4 (Packet Too Big) messages it receives.

Configuring Tunnel Path MTU Discovery

interface Tunnel0
 ip address 10.1.1.3 255.255.255.0
 tunnel source FastEthernet0/1
 tunnel destination 192.168.1.1
 tunnel path-mtu-discovery
end

In the excerpt above, the tunnel path-mtu-discovery command enables this process. Additional options include the age-timer and min-mtu.

Tunnel Path MTU Discovery Options

R3(config-if)#tunnel path-mtu-discovery ?
  age-timer  Set PMTUD aging timer
  min-mtu    Min pmtud mtu allowed
  

Configuration verification can be performed by using the show interface command.

R3(config-if)#do show int tun 0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.1.1.3/24
  MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 192.168.2.3 (FastEthernet0/1), destination 192.168.1.1
...
  Fast tunneling enabled
  Path MTU Discovery, ager 10 mins, min MTU 92, MTU 0, expires never
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input never, output 00:25:27, output hang never
...

In the interface output, we see the following about Path MTU Discovery

  • It is enabled
  • It has an ager time of 10 minutes (this is a default value)
  • The Minimum MTU is 92 (this is a default value)
  • The current cached MTU is 0 (undefined)
  • The cached MTU will not expire (because it is undefined)

The first question I had was, “What does Tunnel Path MTU Discovery do?” Despite what some may believe, this command does not tell the tunnel interface to proactively discover the MTU. The tunnel path-mtu-discovery command does do two things. First, it tells the tunnel interface to copy the df-bit from the payload packet into the tunnel packet’s IP header. Second, it instructs the router to pay attention to related ICMP Type 3 Code 4 messages and dynamically adjust the tunnel MTU accordingly. Since my example uses GRE alone, the tunnel overhead is 24 bytes.

To illustrate the Tunnel Path MTU Discovery Process, I have built the network shown below.

Tunnel PMTUD

To trigger the process, I will send a packet from Host toward R1‘s tunnel interface (10.1.1.1). For this example, I must set the df-bit.

Host#ping 10.1.1.1  repeat 2 size 1500 df-bit

Type escape sequence to abort.
Sending 2, 1500-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
Packet sent with the DF bit set
M.
Success rate is 0 percent (0/2)
Host#

As expected, the ping failed. After sending the traffic, let’s take a look at the output of show interface tunnel on R3.

R3(config-if)#do show int tun 0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.1.1.3/24
...
  Fast tunneling enabled
  Path MTU Discovery, ager 10 mins, min MTU 92, MTU 1376, expires 00:09:53
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
...
R3(config-if)#

At this point, we can see that the Tunnel MTU has been discovered at 1376 bytes. R2 would have sent an ICMP Packet Too Big message indicating an MTU of 1400. R3, calculated the appropriate MTU based on the 24 bytes of GRE overhead. Also notice that there is a valid expiration now.

While going through this testing, I noted the following about Tunnel Path MTU Discovery in Cisco devices:

  • Carries DF Bit Value from Payload To Tunnel Header
  • Dependent on receipt of ICMP Type3/Code4 Messages
  • Performs Passive MTU Discovery as opposed to actively sending probes
  • Allows Tunnel endpoint to try larger packets only when the aging timer expires
  • Dramatically Decreases (but doesn’t eliminate) the likelihood of fragmentation
  • Tunnel PMTUD is pointless if there are no intermediary layer 3 devices (for example GRE over MetroE)
  • Introducing a lower MTU can dynamically lower the Tunnel MTU and refresh the timer

Other Articles about MTU

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Design. Bookmark the permalink.

3 Responses to Understanding Tunnel Path MTU Discovery

  1. Elvin Arias says:

    Thanks Paul, this blog it’s excellent!

    Elvin

  2. John F says:

    Excellent , really helpful

Comments are closed.