The Cisco and Juniper MTU Brief

This will be a quick stop before we jump into MPLS LDP and TE, I have decided to write a brief post about the differences on MTU when working with IOS, IOS-XR and JunOS, so for this, I have extracted a part of the bigger topology that we will later use.

 

For now, we have the following setup:

vMX-1: Junos 14.1R1.10

XRv-2: IOS XR  6.0.0

XE-7: IOS XE 03.13.00a.S

I have configured basic IPv4 addressing on the interfaces and turned on OSPF area 0, leaving the MTU and IPv4 MTU on their default settings:

Very straightforward, but let’s take a look at our MTU values, beginning at vMX-1, we can see that the MTU of the physical interface is 1514, and the inet protocol MTU is 1500:

Logically we would think that this means we can ipv4 ping across this interface with a frame size of 1500 bytes without getting fragmentation, but a ping to XRv-2’s loopback proves otherwise:

This is because whenever we tell JunOS to ping with a size of 1500 Bytes, the system is not taking into consideration the 20 bytes of the IP header and the 8 bytes of the ICMP header, so essentially, when JunOS asks for the ping size, it is actually asking for the payload of the ICMP, not considering the ICMP/IP headers, this means that if we want to ping with a total of 1500 bytes, we need to specify a size of 1472, for which if we add the 28 bytes of IP/ICMP headers, make up the 1500 bytes, let’s take a look at a capture on vMX-1’s ge-0/0/0 interface after pinging XRv-2’s loopback again, this time with a ping size of 1472 bytes:

Notice vMX-1 has placed 1514 bytes on the wire, this is because of the source/destination address (12 bytes) and ethertype fields (2 bytes) within the ethernet header, which by the way is explicitly stated as 1514 when we do the show interface ge-0/0/0 | grep MTU, this means the system is explicitly considering the 14 bytes for the ethernet header, we will see that is not the case with IOS-XE. CRC field is not taken into consideration here.

On the other hand, when dealing with Cisco, at least for our IOS-XE and IOS-XR boxes, whenever we are asked for the ping size, we are actually specifying the size of the payload + headers, which makes things a little more simple, but first let’s take a look at the MTUs on the interfaces for both the XRv-2 and XE-7 boxes:

Notice how XRv-2 is explicitly considering the 14 bytes of the ethernet header on the previous output, and also stating that we have 1500 bytes available to IP, this is not the case in IOS-XE, our XE-7 router shows 1500 bytes of MTU on both the physical and IP interface. Despite these minor differences, both Cisco boxes agree on the maximum ping size that we can send before fragmenting the packet, this is because the 1514 and 1500 bytes MTU are both the same, it just happens that one is explicitly considering the ethernet header and the other one is not, the end result is the same:

IP MTU

Let’s now grab the happy OSPF adjacency that we have between vMX-1 and XRv-2 and tear it down by changing the IP MTU on vMX-1’s ge-0/0/0 to 1580 bytes:

After we do this, vMX-1 and XRv-2 are going to start repeatedly sending and receiving DBD packets, these Database Description packets are the ones holding most of the OSPF database information, however, there is this one field within this packet, called Interface MTU, if these are not the same on the sender/receiver, OSPF will start retransmiting this DBD packet, ultimately putting down the adjacency, we can see this in the logs:

That’s vMX-1 receiving and sending the DBD packet, notice the different MTUs, OSPF traceoptions logs are flooded with these now.

Lastly, this is the XRv-2 saying it’s had way too many retransmissions and needs to bring the OSPF neighbor from EXSTART to DOWN state, then explicitly states, Nbr 1.1.1.1 has larger interface MTU, very straightforward.

So let’s fix this, to demonstrate that there is a distinction between the physical interface’s MTU and the IP MTU, I have changed XRv-2’s Gi0/0/0 MTU to 1700 (vMX-1 still has 1600), however, IP MTUs are now both 1580 bytes:

 

This will conclude the post, it is important that we can understand the different MTUs and how they interact across different vendors, specially when we start adding services to our network and, for instance, start adding MPLS labels and dot1q encapsulations.