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.
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