MTU Mismatch Test on Cisco IOS ISR4331 Routers
In MTU Test on Cisco IOS ISR4331 Routers we tested different MTU values.
What if we use different MTU values on the routers?
Topology
This is the topology we'll use:
Configuration
Here are the configuration files.
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
We'll change the L2 MTU on R2 to 2000:
R2(config)#interface GigabitEthernet 0/0/1 R2(config-if)#mtu 2000
A ping from R1 to R4 will work:
R1#ping 192.168.34.4 repeat 1 size 1800 Type escape sequence to abort. Sending 1, 1800-byte ICMP Echos to 192.168.34.4, timeout is 2 seconds: ! Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms
This works because the L2 of MTU is 1500 bytes. The IP packet is larger than that but can be fragmented.
We'll try something else from R2. First enable a debug:
R2#debug ip packet detail IP packet debugging is on (detailed)
When you try to send a packet from R2 that will fit the L2 MTU of R3 it works:
R2#ping 192.168.34.4 repeat 1 size 1500 Type escape sequence to abort. Sending 1, 1500-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
Anything larger than that will fail:
R2#ping 192.168.34.4 repeat 1 size 1501 Type escape sequence to abort. Sending 1, 1501-byte ICMP Echos to 192.168.34.4, timeout is 2 seconds: Success rate is 0 percent (0/1)
This makes sense. R2 can use a larger L2 MTU and will do so and transmits the IP packet. You can see it in the debug:
FIBipv4-packet-proc: route packet from (local) src 192.168.23.2 dst 192.168.34.4 FIBfwd-proc: packet routed by adj to GigabitEthernet0/0/1 192.168.23.3 FIBipv4-packet-proc: packet routing succeeded IP: tableid=0, s=192.168.23.2 (local), d=192.168.34.4 (GigabitEthernet0/0/1), routed via FIB IP: s=192.168.23.2 (local), d=192.168.34.4 (GigabitEthernet0/0/1), len 1501, sending ICMP type=8, code=0.
You can also see it with the interface counters. For example, let's send a lot of IP packets:
R2#ping 192.168.34.4 repeat 2000 size 1501 timeout 0 Type escape sequence to abort. Sending 2000, 1501-byte ICMP Echos to 192.168.34.4, timeout is 0 seconds: ...................................................................... [output omitted] ........................................ Success rate is 0 percent (0/2000)
You'll see them on the outgoing packet counter of R2:
R2#show interfaces GigabitEthernet 0/0/1 | incl packets output 2000 packets output, 3030000 bytes, 0 underruns
You'll even see them on the incoming packet counter of R3:
R3#show interfaces GigabitEthernet 0/0/1 | include packets input 2035 packets input, 3032852 bytes, 0 no buffer
But R3 will drop these packets because they are larger than its configured L2 MTU.