Path MTU Discovery using IOS CLI Ping

The idea behind is to send packets of various sizes with the do not fragment bit set. We will send packets with increasing sizes until we get an ICMP packet too big message from the router which is attached to a link which requires fragmenting or we just see no reply packets coming in.

 

In this example we will find out the MTU of the Packet which could be sent to R2 from R1. For this we will be sending ICMP packets to 10.0.25.2 (R2) with an initial size of 980 and then increasing the size of the packet by one byte each time till 1010. R4 which is attached to the link which has an MTU of 1000 and cannot fragment the packet because of the DF bit set should drop the packet and send a Packet too big message to the source.

 

R1#ping
Protocol [ip]:
Target IP address: 10.0.25.2
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: yes
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: verbose
Loose, Strict, Record, Timestamp, Verbose[V]:
Sweep range of sizes [n]: yes
Sweep min size [36]: 980
Sweep max size [18024]: 1010
Sweep interval [1]:
Type escape sequence to abort.
Sending 31, [980..1010]-byte ICMP Echos to 10.0.25.2, timeout is 2 seconds:
Packet sent with the DF bit set
Reply to request 0 (148 ms) (size 980)
Reply to request 1 (112 ms) (size 981)
Reply to request 2 (96 ms) (size 982)
Reply to request 3 (56 ms) (size 983)
Reply to request 4 (60 ms) (size 984)
Reply to request 5 (56 ms) (size 985)
Reply to request 6 (56 ms) (size 986)
Reply to request 7 (60 ms) (size 987)
Reply to request 8 (84 ms) (size 988)
Reply to request 9 (68 ms) (size 989)
Reply to request 10 (96 ms) (size 990)
Reply to request 11 (60 ms) (size 991)
Reply to request 12 (56 ms) (size 992)
Reply to request 13 (100 ms) (size 993)
Reply to request 14 (64 ms) (size 994)
Reply to request 15 (96 ms) (size 995)
Reply to request 16 (60 ms) (size 996)
Reply to request 17 (60 ms) (size 997)
Reply to request 18 (60 ms) (size 998)
Reply to request 19 (60 ms) (size 999)
Reply to request 20 (60 ms) (size 1000)
Unreachable from 10.0.34.4, maximum MTU 1000 (size 1001)
Request 22 timed out (size 1002)
Unreachable from 10.0.34.4, maximum MTU 1000 (size 1003)
Request 24 timed out (size 1004)
Unreachable from 10.0.34.4, maximum MTU 1000 (size 1005)
Request 26 timed out (size 1006)
Unreachable from 10.0.34.4, maximum MTU 1000 (size 1007)
Request 28 timed out (size 1008)
Unreachable from 10.0.34.4, maximum MTU 1000 (size 1009)
Request 30 timed out (size 1010)
Success rate is 67 percent (21/31), round-trip min/avg/max = 56/74/148 ms

In the above example R4 sent an ICMP message indicating the allowed MTU size. If the R4 is configured not to send ICMP messages, then we will not get the packet too big message, but we could assume that somewhere on the network the link has only the MTU of 1000.