- Cisco Employee,
This section describes the equations on how the MTU is being calculated for interfaces in IOS-XR.
The MTU is important since it is used as part of the signaling for Pseudo Wires, hence it is important to understand the way XR calculates MTU.
Also OSPF will benefit from the right mtu tuning
This section describes the symptoms of the problem and the main issue the document resolves.
The L2 MTU of the sub-interface is calculated as follows:
- If no L2 MTU is configured on the sub-interface, then the L2 MTU is derived from the L2 MTU inherited from the parent node.
- sub-l2-mtu = parent-l2-mtu + (4 * encaps-tag-count).
- If the sub-interface has an explicit MTU configured then the L2 MTU of the sub-interface is the minimum of the configured value and the value calculated from the parent-l2-mtu as described above. E.g.
- sub-l2-mtu = min (cfg-sub-l2-mtu, (parent-l2-mtu + (4 * encaps-tag-count)))
- The intention behind the L2 MTU definition is to try and preserve an IP payload of 1500 bytes under default configuration and hence to increase the interface L2 MTU to accommodate space for the tags that are known to be present due to the encapsulation.
The L2 payload MTU is calculated as follows:
- The payload MTU is always derived from the L2 MTU based on the following formula:
- sub-l2-payload-mtu =
sub-l2-mtu – (14 + (4 * (encaps-pop-tags-count – encaps-push-tags-count)))
- The rationale behind the payload MTU calculation is to get the correct maximum payload size of frames that may be carried over an xconnected PW relative to the L2 MTU of the interface.
The IM L2 payload MTU is calculated as follows:
- The IM L2 payload MTU can be derived from the L2 MTU based on the following formula:
- im-l2-payload-mtu = sub-l2-mtu – (14 + (4 * encaps-tag-count))
- The IM MTU is defined to be correct L2 payload MTU for L3 sub-interfaces, and convenient to calculate for L2 sub-interfaces subject to the restrictions placed on MTU handling by IM.
Notes on the calculations above:
- All MTUs are calculated in bytes.
- All MTUs exclude the 4 byte Ethernet FCS bytes.
- The size of the Ethernet header is 14 bytes.
- The size of a 802.1Q tag is 4 bytes.
- sub-l2-mtu: The sub-interface L2 MTU.
- parent-l2-mtu: The parent-interface L2 MTU.
- cfg-sub-l2-mtu: The L2 MTU configured on a sub-interface (or UINT16_MAX) if no MTU has been configured.
- sub-l2-payload-mtu: The sub-interface L2 payload MTU.
- im-l2-payload-mtu: The sub-interface IM L2 payload MTU.
- encaps-tag-count: The number of tags matched in an EFP encapsulation configuration, or VLAN Id configuration. Ranges count as a tag match, but an inner “any” tag match does not.
- rewrite-pop-tags-count: The number of tags popped in the EFP rewrite configuration, or the number of tags matched in VLAN Id configuration (since the VLAN Id configuration has an implicit rewrite operation of popping all tags matched).
- rewrite-push-tags-count: The number of tags pushed in the EFP rewrite configuration.
Notes related to specific EFP encapsulation commands:
- The following encapsulations count as matching 0 tags, i.e. are defined as having an encaps-tag-count of 0:
- encapsulation untagged
- encapsulation default
- The following encapsulation modifiers do not affect the encaps-tag-count:
- ingress source-mac or ingress destination-mac
- encapsulation dot1q|dot1ad priority tagged counts as matching a single tag, i.e. encaps-tag-count of 1.
- The any keyword used as the innermost tag match does not increase the encaps-tag-count. (This is to ensure consistency with the old style XR VLAN Id semantics). E.g.
- Encapsulation dot1q any has an encaps-tag-count of 0.
- Encapsulation dot1ad 10 dot1q any has an encaps-tag-count of 1
- Encapsulation dot1ad any dot1q 7 has an encaps-tag-count of 2.
- Ranges of vlan-ids count as a encaps tag match, e.g.
- Encapsulation dot1q 10-100 has an encaps-tag-count of 1.
- The encapsulation MTU overhead of an EFP that is a disjunctive match is treated as having the MTU of its highest element. E.g.
- Encapsulation dot1q 10-100, untagged has an encaps-tag-count of 1.
dot1q vlan 10 20
interface GigabitEthernet0/0/0/0.2 l2transport
service instance ethernet
encapsulation dot1q 11
rewrite ingress tag push dot1ad 10 dot1q 20 symmetric
- l2-mtu = 2014
- im-l2-payload-mtu = 2000
- l2-payload-mtu = 2000
- encaps-tag-count = 2, rewrite-push-tags-count = 0, rewrite-pop-tags-count = 2
- sub-l2-mtu = 2014 + 4 * 2 = 2022
- im-l2-payload-mtu = 2000
- sub-l2-payload-mtu = 2022 – (14 + (4 * (2 – 0))) = 2000
- encaps-tag-count = 1, rewrite-push-tags-count = 2, rewrite-pop-tags-count = 0
- sub-l2-mtu = 2014 + 4 * 1 = 2018
- im-l2-payload-mtu = 2000
- sub-l2-payload-mtu = 2018 – (14 + (4 * (0 - 2))) = 2012
To further explain the example for GigabitEthernet0/0/0/0.2. If a 2026 byte frame was received from the PW on the disposition path then once the 2 tags have been popped off due to the rewrite policy the packets would be of size 2018, hence matching the MTU of the Egress interface.
 Note the MTU negotiated is the L2 payload MTU and hence the actual maximum size of the frame that may be carried is 14 bytes larger for a type 5 PW and 18 bytes larger for a type 4 PW, although in the case of the type 4 PW the PW 802.1Q tag is effectively discarded and ignored for the purpose of the L2VPN MTU calculations (since it isn’t part of the payload).
Starting in XR release 5.1.1 the ethernet interface driver configuration
for MTU and MRU is determined by the XR config.
Prior to these changes MTU/MRU calculation was simply based on the
configured MTU + 12 bytes for the addition of 2 Ethernet Tags and the CRC
field as mentioned above.
However from 511 onwards, the config determines the actual MTU/MRU.
If no VLAN tags are configured -
then driver MTU/MRU = configured MTU on interface + 4 CRC bytes, ie
If one VLAN is configured -
MTU/MRU = configured MTU + 8 bytes (2 tags + CRC)
If two VLAN tags are configured -
MTU/RMU = configured MTU + 12 bytes (3 tags + CRC)
Xander Thuijs, CCIE #6775
Principal Engineer ASR9000