MTU Test on Cisco IOS ISR4331 Routers
This is an overview of how different MTU values impact packet transfer on Cisco IOS ISR4331 routers.
Topology
This is the topology:
Configuration
Here are the configurations.
R1
hostname R1 ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface GigabitEthernet0/0/0 ip address 192.168.12.1 255.255.255.0 negotiation auto ! ip route 0.0.0.0 0.0.0.0 192.168.12.2 ip route 192.168.34.4 255.255.255.255 192.168.12.2 ! end
R2
hostname R2 ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface GigabitEthernet0/0/0 ip address 192.168.12.2 255.255.255.0 ! interface GigabitEthernet0/0/1 ip address 192.168.23.2 255.255.255.0 ! ip route 1.1.1.1 255.255.255.255 192.168.12.1 ip route 4.4.4.4 255.255.255.255 192.168.23.3 ip route 192.168.34.0 255.255.255.0 192.168.23.3 ip route 192.168.34.4 255.255.255.255 192.168.23.3 ! end
R3
hostname R3 ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface GigabitEthernet0/0/0 ip address 192.168.34.3 255.255.255.0 ! interface GigabitEthernet0/0/1 ip address 192.168.23.3 255.255.255.0 ! ip route 1.1.1.1 255.255.255.255 192.168.23.2 ip route 4.4.4.4 255.255.255.255 192.168.34.4 ip route 192.168.12.0 255.255.255.0 192.168.23.2 ip route 192.168.12.1 255.255.255.255 192.168.23.2 ! end
R4
hostname R4 ! interface Loopback0 ip address 4.4.4.4 255.255.255.255 ! interface GigabitEthernet0/0/0 ip address 192.168.34.4 255.255.255.0 ! ip route 0.0.0.0 0.0.0.0 192.168.34.3 ip route 192.168.12.1 255.255.255.255 192.168.34.3 ! end
Verification
The behavior might be different on different platforms, OS versions, interfaces, etc. You might see different behavior when you try this on emulators.
We can play with the L2 and L3 (IP) MTU. You can configure the L2 MTU like this:
R2(config)#interface GigabitEthernet 0/0/0 R2(config-if)#mtu ? <1500-9216> MTU size in bytes
And the IP MTU like this:
R2(config)#interface GigabitEthernet 0/0/0 R2(config-if)#ip mtu ? <68-1500> MTU (bytes)
Default MTU (1500 bytes)
The default MTU is 1500 bytes:
R1#show interfaces GigabitEthernet 0/0/0 | include MTU MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
The default IP MTU is also 1500 bytes:
This packet will work:
R1#ping 192.168.34.4 repeat 1 df-bit size 1500 Type escape sequence to abort. Sending 1, 1500-byte ICMP Echos to 192.168.34.4, timeout is 2 seconds: Packet sent with the DF bit set ! Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms
But a packet with size 1501 fails:
R1#ping 192.168.34.4 repeat 1 df-bit size 1501 Type escape sequence to abort. Sending 1, 1501-byte ICMP Echos to 192.168.34.4, timeout is 2 seconds: Packet sent with the DF bit set . Success rate is 0 percent (0/1)
MTU 1500 bytes and IP MTU 1400 bytes
What if we reduce the ip mtu
somewhere down the line? For example:
R2(config)#interface GigabitEthernet 0/0/1 R2(config-if)#ip mtu 1400
The MTU remains the same:
R2#show interfaces GigabitEthernet 0/0/1 | include MTU MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
And the IP MTU is 1400 bytes:
R2#show ip interface GigabitEthernet 0/0/1 | include MTU MTU is 1400 bytes
This is now our bottleneck. A packet of 1400 bytes works:
R1#ping 192.168.34.4 repeat 1 df-bit size 1400 Type escape sequence to abort. Sending 1, 1400-byte ICMP Echos to 192.168.34.4, timeout is 2 seconds: Packet sent with the DF bit set !
But one with 1401 bytes won't:
R1#ping 192.168.34.4 repeat 1 df-bit size 1401 Type escape sequence to abort. Sending 1, 1401-byte ICMP Echos to 192.168.34.4, timeout is 2 seconds: Packet sent with the DF bit set M Success rate is 0 percent (0/1)
The M
means that the IP packet was too large too transmit without fragmention. Because the DF-bit is set, we can't transmit it.
If we try this without the DF-bit, it's no problem:
R1#ping 192.168.34.4 repeat 1 size 1401 Type escape sequence to abort. Sending 1, 1401-byte ICMP Echos to 192.168.34.4, timeout is 2 seconds: ! Success rate is 100 percent (1/1), round-trip min/avg/max = 2/2/2 ms
This IP packet will be transmitted.
Here you can see what happens with a L2 MTU mismatch: