It is the sole responsibility of administrators to configure the Maximum Transmission Unit (MTU) such that intended services and applications can be successfully implemented in the network. In other words - administrators must make sure that MTUs are configured in a way that packet sizes do not exceed the capabilities of network equipment.
Originally MTU was introduced because of the high error rates and low speed of communications. Fragmentation of the data stream gives the ability to correct corruption errors only by resending corrupted fragments, not the whole stream. Also on low-speed connections such as modems it can take too much time to send a big fragment, so in this case communication is possible only with smaller fragments.
But in the present day we have much lower error rates and higher speed of communication, this opens a possibility to increase the value of MTU. By increasing the value of MTU we will result in less protocol overhead and reduce CPU utilization mostly due to interrupt reduction. This way some non-standard frames started to emerge:
It is common now for Ethernet interfaces to support physical MTU above standard, but this can not be taken for granted. Abilities of other network equipment must be taken into account as well - for example, if 2 routers with Ethernet interfaces supporting physical MTU 1526 are connected through Ethernet switch, in order to successfully implement some application that will produce this big Ethernet frames, the switch must also support forwarding such frames.
Mikrotik RouterOS recognizes several types of MTU:
|
Full frame MTU indicates the actual size of the frame that is sent by a particular interface. Frame Checksum is not included as it is removed by an ethernet driver as soon as it reaches its destination.
L2MTU indicates the maximum size of the frame without the MAC header that can be sent by this interface.
In RouterOS L2MTU values can be seen in the "/interface" menu. L2MTU support is added for all Routerboard related Ethernet interfaces, VLANs, Bridge, VPLS and wireless interfaces. Some of them support the configuration of the L2MTU value. All other Ethernet interfaces might indicate L2MTU only if the chipset is the same as Routerboard Ethernets.
This will allow users to check if the desired setup is possible. Users will be able to utilize additional bytes for VLAN and MPLS tags, or simply increase of interface MTU to get rid of some unnecessary fragmentation.
This table shows max-l2mtu supported by Mikrotik RouterBoards (available in "/interface print" menu as the value of the read-only "max-l2mtu" option):
Model name | MTU description |
RB SXT series, RB LHG, RB LDF, PL6411-2nD, PL7411-2nD, RB711 series, wAP R-2nD, RB912R-2nD-LTm (LtAP mini), RB Metal series, RB SXT Lite series, RB Groove series, Cube Lite60, LHG Lite60 | ether1:2028 |
RB SXT G series, RB DynaDish, wAP ac, RB QRT series, RB711G series, RB911G, RB912UAG | ether1:4076 |
RB OmniTik series, RB750, RB750UP, RB751U-2HnD, RB951-2n | ether1:4076; ether2-ether5:2028 |
RB OmniTik ac series, RB750GL, RB750Gr2 | ether1-ether5:4074 |
RB mAP, RB mAP lite, RB cAP, RB wAP | ether1-ether2:2028 |
RB750r2, RB750P-PBr2, RB750UPr2, RB941-2nD, RB951Ui/RB952Ui series | ether1-ether5:2028 |
RB750Gr3 | ether1-ether5:2026 |
RB751G-2HnD, RB951G-2HnD | ether1-ether5:4074 |
RB962UiGS, RB960PGS | ether1-ether5:4074; sfp1:4076 |
RB LHGG series | ether1:9214 |
LHG XL 52 ac | ether1:9214; sfp1:9214 |
RB1100Hx2, RB1100AHx2 | ether1-ether10:9498; ether11:9500; ether12-ether13:9116 |
RB4011iGS+ series | ether1-ether10:9578; sfp-sfpplus1:9982 |
CCR1009 series | ether1-ether4:10224; ether5-ether8:10226; sfp1:10226; sfp-sfpplus1:10226 |
CCR1016 series | ether1-ether12:10226; sfp1-sfp12:10226; sfp-sfpplus1:10226 |
CCR1036 series | ether1-ether12:10226; sfp1-sfp4:10226; sfp-sfpplus1-sfp-sfpplus2:10226 |
CCR1072 series | ether1:9116; sfp-sfpplus1-sfp-sfpplus8:10226 |
CRS109-8G-1S | ether1-ether8:4064; sfp1:4064 |
CRS125-24G-1S | ether1-ether24:4064; sfp1:4064 |
CRS112-8G-4S, CRS112-8P-4S | ether1-ether8:9204; sfp9-sfp12:9204 |
CRS106-1C-5S | sfp1-sfp5:9204; combo1:9204 |
CRS210-8G-2S+ | ether1-ether8:9204; sfp-sfpplus1:9204; sfpplus2:9204 |
CRS212-1G-10S-1S+ | ether1:9204; sfp1-sfp10:9204; sfpplus1:9204 |
CRS226-24G-2S+ | ether1-ether24:9204; sfp-sfpplus1:9204; sfpplus2:9204 |
CRS326-24G-2S+, CSS326-24G-2S+ | ether1-ether24:10218; sfp-sfpplus1:10218; sfpplus2:10218 |
CRS317-1G-16S+ | ether1:10218; sfp-sfpplus1-sfp-sfpplus16:10218 |
CRS328-24P-4S+ | ether1-ether24:10218; sfp-sfpplus1-sfp-sfpplus4:10218 |
CRS328-4C-20S-4S+ | combo1-combo4:10218; sfp1-sfp20:10218; sfp-sfpplus1-sfp-sfpplus4:10218 |
CRS305-1G-4S+, CRS309-1G-8S+ | ether1:10218; sfp-sfpplus1-sfp-sfpplus4:10218 |
CRS312-4C+8XG | combo1-combo4:10218; ether1-ether8:10218; ether9:2028 |
CRS326-24S+2Q+ | sfp-sfpplus1-sfp-sfpplus24:10218; qsfpplus1-1-qsfpplus2-4:10218; ether1:2028 |
CRS354-48G-4S+2Q+, CRS354-48P-4S+2Q+ | sfp-sfpplus1-sfp-sfpplus4:10218; qsfpplus1-1-qsfpplus2-4:10218; ether1-ether48:10218; ether49:2028 |
D52G-5HacD2HnD (hAP ac²) | ether1-ether5:9124 |
cAP ac | ether1-ether2:9124 |
GPEN21 | ether1-ether2:10222; sfp1: 10222 |
wAP60G, LHG60G | ether1:9124 |
RB260GS series, CSS106-5G-1S, CSS106-1G-4P-1S | ether1-ether5:9198; sfp1:9198 |
RBFTC11 | ether1:4046; sfp1:4046 |
RBM33G | ether1-ether3:2026 |
RBM11G | ether1:2026 |
RB760iGS | ether1-ether5:2026; sfp1:2026 |
RB411 series | ether1:1526 |
RB433 series, RB450, RB493 series | ether1:1526; ether2-ether3:1522 |
RB450Gx4 | ether1-ether5:9214 |
RB411GL | ether1:1520 |
RB433GL, RB435G , RB450G, RB493G | ether1-ether3:1520 |
RB800 | ether1-ether2:9500; ether3:9116 |
RB850Gx2 | ether1-ether5:1580 |
RB921UAGS, RB922UAGS | ether1:4076; sfp1:4076 |
D23UGS-5HPacD2HnD (NetMetal ac²) | ether1:9214 ; sfp1:9214 |
RB953GS | ether1-ether2:4074; sfp1:4074; sfp2:4076 |
RB2011 series | ether1-ether5:4074; ether6-ether10:2028; sfp1:4074 |
RB3011 series | ether1-ether5:8156; ether6-ether10:8156; sfp1:8158 |
RB5009 | ether1-ether8: 9796; sfp-sfpplus1: 9796 |
RB44Ge | ether1-ether4:9116 |
All wireless interfaces in RouterOS (including Nstreme2) support 2290 byte L2MTU.
L2MTU configuration changes evoke all interface reload (link down/link up) due to necessary internal processes. |
Configured in "/mpls interface" menu, specifies the maximal size of the packet, including MPLS labels, that is allowed to send out by the particular interface (default is 1508).
Make sure that MPLS MTU is smaller or equal to L2MTU. MPLS MTU affects packets depending on what action the MPLS router is performing. It is strongly recommended that MPLS MTU is configured to the same value on all routers forming MPLS cloud because of the effects MPLS MTU has on MPLS switched packets. This requirement means that all interfaces participating in MPLS cloud must be configured to the smallest MPLS MTU values among participating interfaces, therefore care must be taken to properly select hardware to be used.
If the packet with labels included is bigger than MPLS MTU, MPLS tries to guess the protocol that is carried inside the MPLS frame:
When a router first introduces label (or labels) on IP packet, and resulting packet size including MPLS labels exceeds MPLS MTU, router behaves as if interface MTU was exceeded - either fragments packet in fragments that do not exceed MPLS MTU when labels are attached (if IP Don't Fragment is not set) or generate ICMP Need Fragmentation error that is sent back to the originator.
When the router encapsulates the Ethernet frame for forwarding over VPLS pseudowire, it checks if packet size with VPLS Control Word (4 bytes) and any necessary labels (usually 2 labels - 8 bytes), exceeds MPLS MTU of the outgoing interface. If it does, VPLS fragments packet so that it honors MPLS MTU of the outgoing interface. A packet is defragmented at the egress point of VPLS pseudowire.
In these examples we will take a look at frames entering and leaving router via Ethernet interfaces.
The image shows the packet MTU size for simple routing, packets size is not modified.
Each VLAN tag is 4 bytes long, the VLAN tag is added by a router. L2-MTU is increased by 4 bytes.
When MPLS is used as a plain replacement for IP routing, only one label is attached to every packet, therefore packet size increases by 4 bytes, we have the situation with two MPLS labels. In order to be able to forward standard size (1500 bytes) IP packet without fragmentation, MPLS MTU must be set to at least 1508 for two MPLS labels.
Two MPLS labels are present when a remote endpoint is not directly attached. One MPLS label is used to get to a remote endpoint, the second label is used to identify the VPLS tunnel.
In this example we will take a closer look at required L2MTU of all Ethernet like interfaces including Bridge, VLAN, VPLS interfaces.
In this setup we will have 3 routers: