MTU Behavior on IOS XR and IOS Routers

Background

In computer networking, the MTU of a communications protocol of a layer defines the size, in bytes, of the largest protocol data unit that the layer is allowed to transmit over one interface. One MTU parameter is associated with each interface, layer, and protocol.

MTU characteristics in Cisco IOS XR software are:

• MTU config and show commands, at L2 and L3, include the header size of their corresponding layer. For instance, the mtu command that configures the L2 MTU includes 14 bytes for an Ethernet interface (without dot1q), or 4 bytes for Point-to-Point Protocol (PPP) or high-level data link control (HDLC). The ipv4 mtu command includes 20 bytes of the IPv4 header.

• The MTU of a higher layer must fit within the payload of the lower layer. For example, if the interface MTU of a non-dot1q Ethernet interface is the default of 1514 bytes, then higher layer protocols such as Multiprotocol Label Switching (MPLS) can have a maximum MTU of 1500 bytes on that interface. This means you can fit only a 1500 byte MPLS frame (including labels) inside the Ethernet frame. You cannot configure a 1508 byte MPLS MTU on that interface if you want to allow two MPLS tags on top of a 1500 byte IPv4 packet. In order to transmit a 1508 byte MPLS frame on an Ethernet interface, the interface MTU must be increased to 1522, or higher value, in order to ensure that the L2 interface payload is large enough to carry the MPLS frame.
  
  

• In the classical Cisco IOS software (not the Cisco IOS XR software), the interface mtu command configures the L2 payload size, but does not include the L2 header because it is included in Cisco IOS XR software. The L3 MTU commands, as in the case of the ipv4 mtu command, configure the maximum packet size of that protocol, including the L3 header. This is similar to the case of Cisco IOS XR software.

• The default interface MTU in the Cisco IOS XR software must allow the transport of a 1500 byte L3 packet. Therefore, the default MTU is 1514 bytes for a main Ethernet interface and 1504 bytes for a serial interface.

Comparison of Cisco IOS and IOS XR Software

This section compares Cisco IOS and IOS XR software behavior with reference to MTU characteristics.

In Cisco IOS software, the mtu command and the corresponding show commands do not include the L2 header. Use the mtu command in order to configure the L2 payload to the maximum size for the L3 packets, including the L3 header.
This is different from Cisco IOS XR software, where the mtu command includes the L2 header (14 bytes for Ethernet or 4 bytes for PPP/HDLC).

If a Cisco IOS router is configured with mtu x and is connected to a Cisco IOS XR router, then the corresponding interface on the Cisco IOS XR router should be configured with mtu x+14 for Ethernet interfaces, or mtu x+4 for serial interfaces.

Cisco IOS and IOS XR software have the same meaning for the ipv4 mtu, ipv6 mtu and mpls mtu commands; they must be configured with the same values.
As a result, this is the configuration in Cisco IOS software on an Ethernet interface:

mtu 9012
ipv4 mtu 9000
ipv6 mtu 9000

The corresponding configuration on the Cisco IOS XR software neighbor is:

mtu 9026
ipv4 mtu 9000
ipv6 mtu 9000

Routed L3 Interfaces
The MTU values must be the same on all devices connected to an L2 network. 
Otherwise, these symptoms might be reported:



Intermediate System-to-Intermediate System (IS-IS) adjacencies do not come 
up. By default, IS-IS uses hello-padding; therefore, hellos might be 
characterized as giants and might be dropped when one router has an MTU value 
that is lower than the values at the other routers.

Open Shortest Path First (OSPF) adjacencies get stuck in Exstart or Exchange 
state, because large database descriptor (DBD) packets might be characterized as 
giants and might be dropped. When the packets are received on a router with a 
lower MTU value, the databases are not synchronized.

Data traffic is characterized as giants and is dropped when it is received 
on a device with an MTU value that is lower than the one at the transmitting 
device.

There is low throughput when large packets get dropped. In case of path MTU 
discovery, the TCP session can recover when large packets are dropped, but this 
affects the throughput. 

Routed L3 Sub-Interfaces
These characteristics apply to routed L3 sub-interfaces.


A routed sub-interface MTU inherits the MTU of its parent main 
interface; add 4 bytes for each VLAN tag configured on the sub-interface. Thus, 
there are 4 bytes for a dot1q sub-interface and 8 bytes for a IEEE 802.1Q 
tunneling (QinQ) sub-interface.
As a result, L3 packets of the same size can be forwarded both on the main 
interface and the sub-interface.

The mtu command can be configured under the sub-interface, 
but it is applied only if it is lower or equal to the MTU that is inherited from 
the main interface.


This is an example where the MTU of the main interface is 2000 bytes

L2VPN L2 Interface

The MTU for an L2VPN is important because Label Distribution 
Protocol (LDP) does not bring a pseudowire (PW) up when the MTUs on the 
attachment circuits at each side of a PW are not the same.

In this example, note that the MPLS L2VPN provider edges (PEs) at 
each side must signal the same MTU value in order to bring the PW up.

The MTU signaled by MPLS LDP does not include the L2 overhead. 
This is different from the XR interface config and 
show commands that include the L2 overhead. The MTU on the 
sub-interface is 2018 bytes (as inherited from the main interface of 2014 
bytes), but LDP signaled an MTU of 2000 bytes.  As a result, it subtracts 18 
bytes (14 bytes of Ethernet header + 4 bytes of 1 dot1q tag) from the L2 
header.
It is important to understand how each device computes the MTU values of the 
attachment circuits in order to fix MTU mismatches. This depends upon parameters 
such as vendor, platform, software version, and configuration.

EVC (ASR9000)
The Cisco ASR 9000 Series Aggregation Services Router uses the EVC 
infrastructure model, which allows flexible VLAN matching on L2VPN L2 interfaces 
and sub-interfaces.



The EVC L2VPN L2 interfaces have these characteristics:

They allow configuration of one or more tags with the 
encapsulation command.
By default and with just the encapsulation command, tags 
are preserved and transported over PWs. As a result, you do not need to strip 
tags by default, as you need to do on non-EVC platforms.
Use the rewrite command when you decide to pop the incoming 
tags or to push some additional tags on top of the incoming frame.


To compute the sub-interface MTU, 
take the main interface MTU (either the default or the one configured manually 
under the main interface), and add 4 bytes for each VLAN tag configured with the 
encapsulation command. 
When there is an mtu command under the sub-interface, it 
takes effect only if it is lower than the computed MTU. The 
rewrite command does not influence the MTU of the 
sub-interface.

Based on this sub-interface MTU, compute the MTU of the MPLS LDP payload that 
is signaled to the neighbor, and make sure that it is identical to the one 
computed by the remote L2VPN PE. This is where the rewrite 
command comes into play.


In order to compute the MTU of the MPLS LDP payload, take the MTU 
of the sub-interface, then:

Subtract 14 bytes for the Ethernet header.
Subtract 4 bytes for each tag popped in the rewrite command 
configured under the sub-interface.
Add 4 bytes for each tag pushed in the rewrite 
command configured under the sub-interface.

For Network Design, Build and Consulting Services, 

please visit:

www.unistreamnetworks.com