This article explains how the MTU is calculated on an IRB interface.

The following logs are seen if the wrong MTU is configured over an IRB logical interface:

This misconfiguration can cause traffic loss during a commit.

The MTU on a logical IRB interface should be configured at less than or equal to the values shown in the following calculations; otherwise, it can cause the deletion and addition of an IRB interface during configuration commits.

Case 1 - IRB interface does not have any MTU configuration, and it is called under a bridge domain that has other physical interfaces:

The MTU calculation of a logical unit on an IRB interface is done by removing the Ethernet overhead from the physical interface MTU. If there are multiple physical interfaces configured under the bridge domain, then the interface with the lowest MTU is used for this MTU calculation.

For example:

The maximum MTU on the physical interface is 9192. Ethernet overhead is 14 bytes = 6(DMAC)+6(SMAC)+2(EtherType)). Thus, the maximum supported MTU on the logical interface on the IRB interface would be 9192 - 14 = 9178.

lab@MX480# show interfaces ge-1/2/4
mtu 9192;
unit 0 {
    family bridge {
         interface-mode access;
         vlan-id 300;
    }
}
lab@MX480# show interfaces irb
unit 300 {
    family inet {
        address 1.1.1.1/30;
    }
}

lab@MX480# show bridge-domains
test {
     domain-type bridge;
     vlan-id 300;
     routing-interface irb.300;
}
lab@MX480# run show interfaces irb.300 | match mtu
    Protocol inet, MTU: 9178
    Protocol multiservice, MTU: 9178<<<<< MTU is 9178 as per calculation 9192-14=9178

If we add another interface to the bridge domain with MTU 9100:

lab@MX480# show | compare
[edit interfaces]
+    ge-1/2/5 {
+        mtu 9100;
+        unit 0 {
+          family bridge {
+               interface-mode access;
+               vlan-id 300;
+          }
+       }
+ }

[edit]
lab@MX480# commit
commit complete

MTU for IRB becomes 9086 as it takes the lowest of the physical interfaces.

[edit]
lab@MX480# run show interfaces irb.300 | match mtu
   Protocol inet, MTU: 9086
   Protocol multiservice, MTU: 9086<<<< MTU is 9086 as per calculation 9100-14=9086

lab@MX480#

Case 2 - IRB interface is configured with some MTU configuration and it is called under a bridge domain that has other physical interfaces:

MTU configuration of the IRB interface will be compared with the MTU configuration of the physical interface (after removing overhead), and the lowest MTU value is considered as the MTU for the IRB interface.

For example:

If the MTU on the physical interface is 6000 and the MTU configuration on the IRB is 5000; then the MTU on the IRB will be 5000.

Same is verified in the lab, as seen below:

lab@MX480# show interfaces ge-1/2/4
mtu 6000;
   unit 0 {
      family bridge {
           interface-mode access;
           vlan-id 300;
       }
}

[edit]
lab@MX480# show interfaces irb.300
family inet {
     mtu 5000;
        address 1.1.1.1/30;
}

[edit]
lab@MX480# run show interfaces irb.300 | match mtu
   Protocol inet, MTU: 5000  <<<<<<MTU is same as configured, as it is lowest
   Flags: Sendbcast-pkt-to-re, User-MTU
   Protocol multiservice, MTU: 5986

Now change the MTU on the physical interface to 4000:

lab@MX480# show | compare
[edit interfaces ge-1/2/4]
  - mtu 6000;
  + mtu 4000;

[edit]
lab@MX480#

[edit]
lab@MX480# commit
commit complete

[edit]
lab@MX480# show interfaces ge-1/2/4
mtu 4000;
  unit 0 {
     family bridge {
         interface-mode access;
         vlan-id 300;
     }
}

[edit]
lab@MX480# run show interfaces irb.300 | match mtu
   Protocol inet, MTU: 3986  <<<<<MTU changes to 4000-14 =3986 as it is lower than configured value of 5000
   Flags: Sendbcast-pkt-to-re, User-MTU
   Protocol multiservice, MTU: 3986

[edit]
lab@MX480#

Case 3 - If flexible-vlan-tagging is configured on the interfaces:

If flexible-vlan-tagging is configured on one of the interfaces, its MTU is calculated by including an additional 8 bytes of overhead (i.e., Service VLAN + Customer VLAN tags), hence the total overhead becomes 22 bytes (i.e., 6(DMAC)+6(SMAC)+2(EtherType)+8(Service VLAN + Customer VLAN), resulting in a maximum MTU of 9170.

Add flexible-vlan-tagging to the interface configuration in Case 2 and change it to trunk, as we cannot configure flexible-vlan-tagging for the access interface.

lab@MX480# show | compare
[edit interfaces ge-1/2/4]
+ flexible-vlan-tagging;
[edit interfaces ge-1/2/4 unit 0 family bridge]
- interface-mode access;
- vlan-id 300;
+ interface-mode trunk;
+ vlan-id-list 300;

[edit]
lab@MX480# commit
commit complete

[edit]
lab@MX480# show interfaces ge-1/2/4
flexible-vlan-tagging;
mtu 4000;
   unit 0 {
      family bridge {
          interface-mode trunk;
          vlan-id-list 300;
      }
}

[edit]
lab@MX480# run show interfaces irb.300 | match mtu
   Protocol inet, MTU: 3978 <<<<<<<<<<<MTU is calculated as 4000-22=3978
   Flags: Sendbcast-pkt-to-re, User-MTU
   Protocol multiservice, MTU: 3978

[edit]
lab@MX480#

Case 4 – Vlan-tagging is configured on the interfaces:

In case of vlan-tagged interfaces, the four bytes for each vlan-tag are considered overhead. Thus, with a single vlan-tagged interface, overhead becomes 18 bytes = 6(DMAC)+6(SMAC)+2(EtherType))+4(VLAN).

[edit]

lab@MX480# show interfaces ge-1/2/4
vlan-tagging;
mtu 4000;
encapsulation flexible-ethernet-services;
         unit 0 {
         encapsulation vlan-bridge;
         vlan-id 300;
}

[edit]
lab@MX480# show bridge-domains
test {
   domain-type bridge;
   vlan-id 300
   interface ge-1/2/4.0;
   routing-interface irb.300;
}

lab@MX480# run show interfaces irb.300 | match mtu
   Protocol inet, MTU: 3982  <<<<<<<MTU is calculated to 4000-18=3982
   Protocol multiservice, MTU: 3982

[edit]
lab@MX480#