Introduction
In the ever-evolving landscape of networking, understanding different equipment vendors equipment is crucial. One parameter that often plays a pivotal role in network performance is the MTU configuration (Maximum Transmission Unit). Today, we embark on a journey to unravel the MTU mysteries of three networking behemoths: Juniper, Cisco, and Nokia.
This post will cover the MTU deep dive, how the devices treat it at various levels. The next post, Part 2, will cover the ping command. It will look specifically at its relation to the packet size, and testing the understood MTU. These posts will be primarily ethernet focussed as that is the most common scenario.
Section 1: Decoding MTU – What’s Under the Hood?
Before diving into the comparison, let’s take a moment to understand the essence of MTU. Maximum Transmission Unit is the largest size of a data packet that can be transmitted over a network. A higher MTU generally means better efficiency and reduced overhead. A lower MTU means more fragmentation and more packets.
One thing to note about MTU, it is NOT the same as the MRU – maximum receive unit. An interface can be configured for an MTU of 1000 bytes. Yet, it can still, theoretically, receive and process a 1500 byte packet.
FCS – is a 4 byte frame check sequence added to each packet. This is always assumed and does not form part of any MTU calculations.
Components of MTU
At its core, the MTU is akin to a shipping container. It has a set amount of space and all the bits required for the data packet must fit inside this container.
But what’s inside this container? Ah, that’s where the fun begins!
- Ethernet Headers:
These are like a passport. They guide the data packet through each network checkpoints. Helping the data to reache its destination smoothly.
- IP Headers:
Think of them as digital postcards. They are attached to our cargo. The IP Headers contain essential information like source and destination addresses. They act as the container’s GPS, ensuring precise navigation to the final destination.
- Other Headers:
These are specialized tags added to our cargo. Other headers provide crucial details for specific applications or protocols, optimizing the journey.
- Payload: The rest of the packet
It is these headers that form part of the key differences between the providers. And what they see as the whole container – MTU.
Nestled behind the headers, we have the payload, this is the actual data. The data is neatly packed and ready for its digital voyage. And don’t forget the padding, those extra bits ensuring the cargo arrives intact.
Stay with us, as we dive deeper into the mysteries of MTU. Helping you to unlock the secrets of seamless data transmission!
We will also cover the ping command. This is the first step most engineers take into the MTU testing world, but not all boxes are equal here either!
Section 2 : Fragmentation – A Common Misunderstanding
Before we dive deeper, let’s clarify one thing – fragmentation.
So, your packet is too big to leave your interface – your interface MTU configuration is too small right? Simple, we will fragment the packet into smaller packets. Great!! This is the case – as long as your IP MTU limitation is on a layer 3 interface MTU.
If your packet hits any layer 2 MTU limits along the way, it will be thrown into the abyss. No SOS and no report of a packet lost is returned to the sender. So, you must ALWAYS ensure any layer 2 segments in your network can handle the layer 3 MTU configuration on each end. Ignore this at your peril!
Section 3 : Juniper Juggernaut – Pushing the Limits
Juniper Networks has long been a stalwart in the networking realm. Below, we will navigate the MTU waters of the good ship Juniper. For further information on the Juniper MTU, see Juniper’s own pages too – click-here.
Juniper MTU (MX and SRX)
The following shows an MX 1Gbps interface.
By default, this is enabled for 1514 – that covers a full ethernet packet.
Note also the presence here of the MRU – the maximum receive size.
root# run show interfaces ge-0/0/3
Physical interface: ge-0/0/3, Enabled, Physical link is Up
Interface index: 152, SNMP ifIndex: 518
Link-level type: Ethernet, MTU: 1514, MRU: 1522, LAN-PHY mode,
When you enable the interface for vlan-tagging, this leads to an automatic MTU increase – as per the Nokia SROS.
Physical interface: ge-0/0/3, Enabled, Physical link is Up
Interface index: 152, SNMP ifIndex: 518
Link-level type: Ethernet, MTU: 1518, MRU: 1526, LAN-PHY mode,
Finally, enabling the interface for ‘flexible-vlan-tagging’ that supports qinq further increases the port MTU by 4 bytes.
Physical interface: ge-0/0/3, Enabled, Physical link is Up
Interface index: 152, SNMP ifIndex: 518
Link-level type: Ethernet, MTU: 1522, MRU: 1530, LAN-PHY mode,
Juniper MTU (EX)
The general difference for the EX, is that you can enable the interface for trunk mode – which infers tagging, and the interface MTU does not change. But, it automatically allows for the extra 4 bytes of tag.
Physical interface: ge-0/0/46, Enabled, Physical link is Up
Interface index: 695, SNMP ifIndex: 650
Description: to-SAST-1/1/17
Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Link-mode: Full-duplex, Speed: Auto, BPDU Error: None, Loop Detect PDU Error: None,
So, with the above, and with a VLAN interface, a full 1500 byte IP packet was able to be sent out of the interface including the 4 byte tag. Therefore, this interface is supporting a 1518 ethernet MTU.
Section 4 : Cisco Chronicles – Navigating the MTU Terrain
Cisco, a household name in networking, brings its own flavor to the MTU game. Uncover the methodology behind Cisco’s MTU strategy and how it handles Ethernet headers within its framework. For further information on the Cisco MTU, you can check this article on Cisco’s site – click-here.
Cisco MTU (IOS Switch)
The Cisco IOS switch by default (old IOS ethernet) sets the physical interface to 1500 bytes.
The IP interface is also set to 1500.
/Switch#show interfaces ether0/0
Ethernet0/0 is up, line protocol is up (connected)
Hardware is AmdP2, address is aabb.cc00.1800 (bia aabb.cc00.1800)
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
Switch#show ip interface vlan 1
Vlan1 is up, line protocol is up
Internet address is 192.168.200.1/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
The switch interface therefore, does not take into account any headers that will be added as the packet leaves the switch. This also remains no matter the switchport mode or encapsulation.
Therefore, the 1500 should be interpreted as the entire shipping container. The ethernet headers will need to be stuck on the front of it before it can leave.
Cisco MTU (IOS-XE Router)
The Cisco IOS-XE router by default sets the physical interface to 1500 bytes.
The IP interface is also set to 1500.
Router#show int gigabitEthernet 1GigabitEthernet1 is up, line protocol is up
Hardware is CSR vNIC, address is 5000.0019.0000 (bia 5000.0019.0000)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
Router#show ip interface GigabitEthernet 1.100
GigabitEthernet1.100 is up, line protocol is up
Internet address is 192.168.200.2/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
The switch interface does not take into account any headers that will be added as the packet leaves the switch. This also remains no matter the switchport mode.
Therefore, the 1500 should be interpreted as the entire shipping container. The ethernet headers will need to be stuck on the front of it before it can leave.
Cisco MTU (IOS-XR Router)
Now this looks different from the other Cisco platforms!!! The physical interface by default is showing an MTU of 1514. This is because it’s an ethernet interface and covers the ethernet header as well as the main packet payload.
GigabitEthernet0/0/0/0 is up, line protocol is up
Interface state transitions: 1
Hardware is GigabitEthernet, address is 5000.0013.0003 (bia 5000.0013.0003)
Internet address is Unknown
MTU 1514 bytes, BW 1000000 Kbit (Max: 1000000 Kbit)
reliability 255/255, txload 0/255, rxload 0/255
Different again! Now for the IP interface, it is showing 1500 for IP, but 1518 in total. This is because we have enabled a VLAN tag on the sub-interface, so this is automatically then added to the MTU.
RP/0/RP0/CPU0:ios#show ipv4 interface g0/0/0/0.100
Thu Nov 9 20:47:12.738 UTC
GigabitEthernet0/0/0/0.100 is Up, ipv4 protocol is Up
Vrf is default (vrfid 0x60000000)
Internet address is 192.168.200.3/24
MTU is 1518 (1500 is available to IP)
Section 5 : Nokia Networks – MTU in a Connected World
Nokia, a global player, presents its unique take on MTU. Explore the simplistic Nokia approach to the MTU conundrum.
The Nokia SROS networks MTU is probably the most simplistic of the 3, it covers everything apart from CRC. Further info on the Nokia MTU can be found here. Note – the below examples are for a typical Nokia access port. Nokia differentiates between a customer facing access port and a core network facing port. The core facing ports will tend to default to jumbo size.
Nokia MTU Port /Ethernet
Nokia differs from Cisco, in that the port encapsulation must be set at the port level – ie null, dot1q or qinq. The following shows the Nokia defaults.
1514 – for an untagged port. This will allow a maximum ethernet frame of 1514 bytes to be sent out.
1518 – for a tagged port. This will allow a maximum ethernet frame of 1514 to be sent out with an additional 8021q 4 byte tag.
1522 – for a qinq tagged port. This will allow a maximum ethernet frame of 1514 to be sent out with an additional outer and inner 802.1q tags totalling an extra 8 bytes.
The following shows a port enabled for 802.1q encapsulation. This allows for the standard 1514 ethernet + 4 bytes for the dot1q header.
A:vRR# show port 1/1/2
===============================================================================
Ethernet Interface
Description : 10/100/Gig Ethernet SFP
Interface : 1/1/2 Oper Speed : N/A
Link-level : Ethernet Config Speed : 1 Gbps
Admin State : up Oper Duplex : N/A
Oper State : down Config Duplex : full
Physical Link : No MTU : 1518
Nokia MTU – IP
The Nokia IP MTU is either set automatically – based on the port MTU it’s tied to. Eg if the layer 3 interface is tied to a dot1q port with 1518, when the ethernet headers are stripped off, this allows for 1500 bytes of IP payload.
Description : (Not Specified)
If Index : 2 Virt. If Index : 2
Last Oper Chg : 11/09/2023 20:51:40 Global If Index : 257
Mon Oper Grp : None
Srrp En Rtng : Disabled Hold time : N/A
SAP Id : 1/1/2:0
TOS Marking : Untrusted If Type : IES
SNTP B.Cast : False IES ID : 100
MAC Address : 50:00:00:06:00:02 Mac Accounting : Disabled
Ingress stats : Disabled IPv6 DAD : Enabled
TCP MSS V4 : 0 TCP MSS V6 : 0
Arp Timeout : 14400s IPv6 Nbr ReachTime: 30s
Arp Retry Timer : 5000ms
IP Oper MTU : 1500 ICMP Mask Reply : True
Summary
As we have seen, the waters are are lot clearer now we have looked in more detail at the MTU configuration on the various devices.
To summarise, Nokia behaves in a similar way to Juniper and Cisco IOS-XR. That is, the MTUs are driven by the interface and include specific headers.
Cisco IOS and IOS-XE MTUs do not account for any ethernet encapsulations. This is considered to be added as the packet egresses the interface.
Read the next post to understand how this then translates to ICMP size.
Thanks for travelling on this journey with me. I hope it was useful.
