Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

ASR9000/XR: Understanding MTU calculations


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




Core Issue

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:
    • native
    • payload-ethertype
    • exact
    • cos
    • 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.



Interface GigabitEthernet0/0/0/0

  mtu 2014


interface GigabitEthernet0/0/0/0.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




For GigabitEthernet0/0/0/0:

  • l2-mtu = 2014
  • im-l2-payload-mtu = 2000
  • l2-payload-mtu = 2000


For GigabitEthernet0/0/0/0.1:

  • 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


For GigabitEthernet0/0/0/0.2

  • 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[1] 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.



[1] 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)



Related Information



Xander Thuijs, CCIE #6775

Principal Engineer ASR9000

Version history
Revision #:
1 of 1
Last update:
‎03-04-2011 11:32 AM
Updated by:
Labels (1)

Hello Alexander,

Today  I have the MTU configured on the vlan as shown below, but now I am  changing it to the IOS-XR standard (EVC Framework), so my question is,  where do I have to adjust the MTU in a way that it has the same effect  that the old configuration on IOS?



vlan 200

mtu 9012


vlan 3006

mtu 9012


interface vlan 200

ip addr


:router# configure

:router(config)# interface bvi 100

:router(config-if)# vrf vod-management

:router(config-if-vrf)# ipv4 address <IP> <mask>

:router(config-if-vrf)# commit

:router# configure

:router(config)# l2vpn

:router(config-l2vpn)# bridge group VL100

:router(config-l2vpn-bg)# bridge domain VL100

:router(config-l2vpn-bg-bd)# interface gigabitethernet 0/0/0/4

:router(config-l2vpn-bg-bd)# interface gigabitethernet 0/0/0/5.100

:router(config-l2vpn-bg-bd)# commit

:router# configure

:router(config)# interface gigabitethernet Gi0/0/0/4

:router(config-if)# l2transport

:router(config-if)# commit

:router(config-if)# interface Gi0/0/0/5.100 l2transport

:router(config-if)# encapsulation dot1q 100

:router(config-if)# rewrite ingress tag pop 1 symmetric


Thanks in advance,


Cisco Employee


9016 is the value to choose, since you have one tag on the 0/0/0/5.100 EFP and you are popping the tag (which is necessary since you are linking it to a 0/0/0/4 main EFP and using BVI.


New Member

Hi Xander,

                     Can I get to know how to create an object group for monitoring the status of vrf interfaces in XR. Accept my apologies if it's not the right discussion to ask this. I am expecting your valid response.

Cisco Employee

Hi Rakesh, yeah this question is not really related to interface MTU and calculations , you can always raise a new question on the "root" of the XR OS forum, not a problem.

Any case what you are after is what I call Enhanced Object Tracking. There are possibilities, eg via EEM.

For that I have a write up too, you can find it as doc under my profile. I believe it has a section on EOT also, if not

I will post a separate document on establishing object tracking.



Cisco Employee

Ah I found the discussion on EOT you may like:


New Member

Hi Xander,

                 Thanks a lot.I have read the documentation. I need to ask one more question. Can we apply the configuration(which is specified the document) under vrf interfaces ?  I have got another document about object tracking. Don't they specify about the abject group monitoring in vrf interfaces. Let me know if it is not the right document for achieving the required feature .Please go throuh the below link and suggst the right one. Please help me one more time.

New Member

Hello Alexander,

As I understand the default MTU value for Gig / 10Gig interfaces on ASR's is 1514 bytes. This includes the 14 bytes for ethernet header.

Hence the IP MTU come to 1500 bytes.

We intend to use 1G and 10G interfaces as MPLS core interfaces on our ASR's. We will be having these MPLS links between ASR - ASR and ASR - Junipers.

We plan to get our transport links to support 1600 bytes of maximum frame-size. And also configure 1600 as interface MTU on the ASR and Juniper.

The effective IP MTU and MPLS MTU that we should get from the above configuration should be as below

ASR - Interface MTU : 1600 bytes

ASR - IP MTU : 1600 - 14 = 1586 bytes

ASR - MPLS MTU : 1600 - 14 = 1586 bytes

Juniper - Interface MTU : 1600 byte

Juniper - IP MTU : 1600 -14 = 1586 byte

Juniper - MPLS MTU : 1586 - 12 = 1574 byte

Our MPLS Core will have OSPF as IGP. Please suggest if the above understanding and MTU calculations are correct.

We don't intend to hard-code IP MTU and also don't want to use "ip ospf mtu ignore".

Many thanks !!



Cisco Employee

Hello Alexander,

I have a customer with ASR9000 and IOS XR 5.1.3.The customer has deployed aTengigabitethernet link between ASR9K across a Cisco DWDM network.

The asr9000 HW is the following:

 ASR9000  IOS XR 5.1.3 with A9K-MOD80-TR and A9K-MPA-4X10GE -------- <CISCO DWDM NETWORK> -------- ASR9000  IOS XR 5.1.3 with A9K-4T-B


We have configured hte MTU as 9216 in main interfaces in both sides.

Then we could observe that MTU in l3 subinterfaces is 9216 + 4 = 9220

We was waiting to pass across the link pings with a maximum MTU value of 9202 bytes ( 9220- 4 (DOT1Q ETHERNET HEADER) – 14 (ETHERNET HEADER = 9202 BYTES)

But the ping normal and extended with the donotfrag option have reply only for 9198

 I am not sure if the problem is my understanding of the equipment or the DWDM network has a configuration problem.

We would be grateful if you could comment.

Cisco Employee

hi heleon,

yeah you are exceeding the hw limit of the mtu at this configuration. you're 4 bytes over,

and that is precisely the problem you're hitting:

RP/0/RP0/CPU0:ASR9922(config)#int te 0/5/0/10

RP/0/RP0/CPU0:ASR9922(config-if)#mtu 9216

RP/0/RP0/CPU0:ASR9922(config-if)#int te 0/5/0/10.10

RP/0/RP0/CPU0:ASR9922(config-subif)#encap dot1q 10

RP/0/RP0/CPU0:ASR9922(config-subif)#ip add


Fri Jun  3 08:59:53.101 EDT

LC/0/5/CPU0:Jun  3 08:59:53.560 EDT: vic[374]: %L2-ETHERNET-6-MTU_NEAR_HW_LIMIT : The MTU of 9220 on TenGigE0_5_0_10 is over the H/W limit, and hence large frames may be dropped as oversized frames



New Member


Thanks for detailed information.

I would like to know if all ios xr versions follow the same calculation.

Specifically if between 5.1.3 and 5.3.3 we had the MTU defaul value/calculation change.

After upgrade to 5.3.3 some services goes down because of the MTU value change. After manually configure the required MTU values the services back to work again.