Maximum Transmission Unit (MTU). Myths and reefs
Maximum transmission unit (MTU) is the maximum amount of data that can be transmitted by the protocol in one iteration. For example, an Ethernet MTU is 1500, which means that the maximum amount of data carried by an Ethernet frame cannot exceed 1500 bytes (excluding the Ethernet header and FCS - Fig. 1).
Fig. one
Let's go over MTI with OSI levels:
Ethernet MTU is a special case of Hardware MTU. Hardware MTU definition follows from the general definition:
Hardware MTU is the maximum packet size that an interface can transmit in one iteration (at least the value is indicated in the device specifications - in fact, some chipsets support the transmission of larger packet sizes than stated). Therefore, if you look at Figure 1 in isolation from Ethernet, you will get the following:
Fig. 2
')
Note: However, there can not do without a reservation. As you can see, the HW MTU (Ethernet MTU in particular) does not include the L2 header. However, this is true for IOS and IOS XE, but for IOS XR and JunOS, the L2 header is included in the HW MTU size - Pic. 3. This feature can lead to problems when installing OSPF neighborship between platforms running IOS (XE) and IOS XR (OSPF requires the MTU match in Hello packets). Therefore, when configuring the MTU for the Ethernet interfaces, on the IOS XR side, the MTU should be 14 bytes more (12 bytes of src mac + dst mac and 2 bytes of EtherType). For example, an MTU of 1500 in Cisco IOS is equivalent to an MTU of 1514 for IOS XR.
Fig. 3
In order to change the MTU on routers running Cisco IOS, use the interface level command:
Checking:
AND
IP MTU determines the maximum packet size with an IP header that can be transmitted on this interface without resorting to fragmentation. The relationship between IP MTU and HW MTU is described by the following formula:
Accordingly, when a packet that exceeds the established IP MTU enters the interface, the packet is either fragmented or, if the DF flag is set (DO NOT Fragment) in the IP header, it discards, and the device can generate an ICMP Fragmentation Needed message used in the path MTU mechanism discovery (about it later), and send it back to the sender of the original packet.
To change the IP MTU on routers running Cisco IOS, use the interface level command:
Checking:
AND
Here are the times. The ip mtu command is not visible in show run. Yes, there is an interesting nuance - if ip mtu matches hw mtu, then only hw mtu will be displayed in the show run output. If the values ​​are different then both are displayed.
TCP Maximum Segment Size (MSS) defines the maximum TCP segment size ( without TCP header! ) That can be used (sent / received) during a TCP session. An announcement (namely, an announcement, not a handshake) of TCP MSS sizes occurs during the installation of a TCP session — the receiving side announces to the sending side what size of TCP segment it can accept. Accordingly, the size of the TCP MSS can vary within one TCP session, depending on the direction.
Fig. four
The party making the announcement calculates the TCP MSS value for itself using the following formula:
Here we have two possible scenarios - the router is a transit or a participant in a TCP session.
1) Transit device:
To prevent a packet from being dropped by an intermediate device if there is a link with a small MTU, the router will listen for TCP SYN packets and replace the MSS values ​​advertised by the end device. Which will lead to sending packets of smaller size by the end device and voila - the problem with the drops on the link with a small MTU is prevented.
2) Termination device:
Everything is simple here - the router is a member of a TCP session and we can forcefully set the size of the MSS that it will announce.
It seems everything? No, not all. We remember about MPLS. We recall ... Finished remember, move on to consideration.
Fig. five
MPLS MTU determines the maximum size of the tagged (who knows how to best translate Labeled, please suggest in the comments) IP packet. If the size of the tagged packet exceeds MPLS MTU, then the packet is either fragmented or, if there is a DF bit flag set in the IP header, it drops (as long as the IP MTU is exceeded), with a possible ICMP Fragmentation Needed message.
Note: This is where things are a little different, compared to IP MTU. In an MPLS network, an intermediate node may not have a route to the sender of the packet, so instead of sending an ICMP message directly to the sender, it is encapsulated with the same label stack as the original packet and sent along its route. Reaching the Egress LSR (final MPLS router for this LSP - it already has an IP network without labels), which knows the ip routes to the sender's node, the ICMP message Fragmentation Needed is “deployed” by it, encapsulated with the necessary headers and sent back to the MPLS network to the original sender . Behavior is similar to TTL Expired, and in general it is more likely to relate to the MPLS topic, rather than MTU. So who is not familiar with the process - www.google.kg/?gws_rd=ssl#q=mpls+ttl+expired
What is more interesting here? The MPLS MTU may be larger than the HW MTU (therefore, in Figure 3, the HW MTU is partially indicated by dotted lines). At the same time, IOS will issue a varning, but in most cases it will work (depending on the interface chipset) and successfully skip at least baby-giant frames. And sometimes you can get a drop packet, data corruption, and a hundred years without a crop.
Checking:
Note: MPLS MTU is displayed in the running config, as well as IP MTU - only if the value is different from HW MTU. But, unlike IP MTU, any change in HW MTU changes the value of MPLS MTU to the value of HW MTU (IP MTU does not change this action).
Switches do not support setting MTU on each interface separately (talking about switchport and Vlan interfaces, for multilayer switches with routed ports, settings similar to routers are applicable). You can change current MTU settings for switch ports using 3 methods applicable depending on type port:
Checking:
Since the main method of checking MTU to this day is the PING command, with df-bit set and the packet size, I will conclude with a couple of useful tricks:
That's all. There is also an old draft in the bins of the article on the size of frames and their evolution, which describes the concepts of Jumbo Frame, Baby-Giant Frame, found in this article. If you see fit, I can modify and lay out and her.
Fig. one
Let's go over MTI with OSI levels:
Layer 2.
Ethernet MTU is a special case of Hardware MTU. Hardware MTU definition follows from the general definition:
Hardware MTU is the maximum packet size that an interface can transmit in one iteration (at least the value is indicated in the device specifications - in fact, some chipsets support the transmission of larger packet sizes than stated). Therefore, if you look at Figure 1 in isolation from Ethernet, you will get the following:
Fig. 2
')
Note: However, there can not do without a reservation. As you can see, the HW MTU (Ethernet MTU in particular) does not include the L2 header. However, this is true for IOS and IOS XE, but for IOS XR and JunOS, the L2 header is included in the HW MTU size - Pic. 3. This feature can lead to problems when installing OSPF neighborship between platforms running IOS (XE) and IOS XR (OSPF requires the MTU match in Hello packets). Therefore, when configuring the MTU for the Ethernet interfaces, on the IOS XR side, the MTU should be 14 bytes more (12 bytes of src mac + dst mac and 2 bytes of EtherType). For example, an MTU of 1500 in Cisco IOS is equivalent to an MTU of 1514 for IOS XR.
Fig. 3
Configuration and verification.
In order to change the MTU on routers running Cisco IOS, use the interface level command:
R01(config)#interface gigabitEthernet 5/1 R01(config-if)#mtu 1532 R01(config-if)#exit Checking:
R01#show interfaces gigabitEthernet 5/1 GigabitEthernet5/1 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is 0008.e3ff.fde0 (bia 0008.e3ff.fde0) Description: -- -- MTU 1532 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 82/255, rxload 20/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is LH ..... OUTPUT OMITTED AND
R01#show run interface gigabitEthernet 5/1 interface GigabitEthernet 5/1 description -- -- no switchport mtu 1532 ip address 192.168.1.1 255.255.255.0 end Layer3.
IP MTU determines the maximum packet size with an IP header that can be transmitted on this interface without resorting to fragmentation. The relationship between IP MTU and HW MTU is described by the following formula:
IP MTU ≤ HW MTUAccordingly, when a packet that exceeds the established IP MTU enters the interface, the packet is either fragmented or, if the DF flag is set (DO NOT Fragment) in the IP header, it discards, and the device can generate an ICMP Fragmentation Needed message used in the path MTU mechanism discovery (about it later), and send it back to the sender of the original packet.
Configuration and verification.
To change the IP MTU on routers running Cisco IOS, use the interface level command:
R01(config)#interface gigabitEthernet 5/1 R01(config-if)#ip mtu 1532 R01(config-if)#exit Checking:
show interfaces gigabitEthernet 5/1 GigabitEthernet 5/1is up, line protocol is up Internet address is 192.168.1.1/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1532 bytes Helper address is not set Directed broadcast forwarding is disabled Multicast reserved groups joined: 224.0.0.5 224.0.0.2 Outgoing access list is not set Inbound access list is not set ..... OUTPUT OMITTED AND
R01#show run interface gigabitEthernet 5/1 interface GigabitEthernet 5/1 description -- -- no switchport mtu 1532 ip address 192.168.1.1 255.255.255.0 no ip redirects no ip unreachables no ip proxy-arp end Here are the times. The ip mtu command is not visible in show run. Yes, there is an interesting nuance - if ip mtu matches hw mtu, then only hw mtu will be displayed in the show run output. If the values ​​are different then both are displayed.
Layer 4.
TCP Maximum Segment Size (MSS) defines the maximum TCP segment size ( without TCP header! ) That can be used (sent / received) during a TCP session. An announcement (namely, an announcement, not a handshake) of TCP MSS sizes occurs during the installation of a TCP session — the receiving side announces to the sending side what size of TCP segment it can accept. Accordingly, the size of the TCP MSS can vary within one TCP session, depending on the direction.
Fig. four
The party making the announcement calculates the TCP MSS value for itself using the following formula:
TCM MSS = (IP MTU – [IPHDR + TCPHDR])Configuration.
Here we have two possible scenarios - the router is a transit or a participant in a TCP session.
1) Transit device:
To prevent a packet from being dropped by an intermediate device if there is a link with a small MTU, the router will listen for TCP SYN packets and replace the MSS values ​​advertised by the end device. Which will lead to sending packets of smaller size by the end device and voila - the problem with the drops on the link with a small MTU is prevented.
R01(config)#interface gigabitEthernet 5/1 R01(config-if)#ip tcp adjust-mss? <500-1460> Maximum segment size in bytes 2) Termination device:
Everything is simple here - the router is a member of a TCP session and we can forcefully set the size of the MSS that it will announce.
R01(config)#ip tcp mss? <0-10000> MSS It seems everything? No, not all. We remember about MPLS. We recall ... Finished remember, move on to consideration.
Layer 2.5. MPLS.
Fig. five
MPLS MTU determines the maximum size of the tagged (who knows how to best translate Labeled, please suggest in the comments) IP packet. If the size of the tagged packet exceeds MPLS MTU, then the packet is either fragmented or, if there is a DF bit flag set in the IP header, it drops (as long as the IP MTU is exceeded), with a possible ICMP Fragmentation Needed message.
Note: This is where things are a little different, compared to IP MTU. In an MPLS network, an intermediate node may not have a route to the sender of the packet, so instead of sending an ICMP message directly to the sender, it is encapsulated with the same label stack as the original packet and sent along its route. Reaching the Egress LSR (final MPLS router for this LSP - it already has an IP network without labels), which knows the ip routes to the sender's node, the ICMP message Fragmentation Needed is “deployed” by it, encapsulated with the necessary headers and sent back to the MPLS network to the original sender . Behavior is similar to TTL Expired, and in general it is more likely to relate to the MPLS topic, rather than MTU. So who is not familiar with the process - www.google.kg/?gws_rd=ssl#q=mpls+ttl+expired
What is more interesting here? The MPLS MTU may be larger than the HW MTU (therefore, in Figure 3, the HW MTU is partially indicated by dotted lines). At the same time, IOS will issue a varning, but in most cases it will work (depending on the interface chipset) and successfully skip at least baby-giant frames. And sometimes you can get a drop packet, data corruption, and a hundred years without a crop.
Configuration and verification.
R01(config)#interface gigabitEthernet 5/1 R01(config-if)#mpls mtu 1540 R01(config-if)#exit Checking:
R01#show mpls interfaces gigabitEthernet 5/1 detail Interface gigabitEthernet 5/1: IP labeling enabled (ldp): Interface config LSP Tunnel labeling not enabled BGP labeling not enabled MPLS operational MTU = 1540 Note: MPLS MTU is displayed in the running config, as well as IP MTU - only if the value is different from HW MTU. But, unlike IP MTU, any change in HW MTU changes the value of MPLS MTU to the value of HW MTU (IP MTU does not change this action).
MTU on Cisco switches.
Switches do not support setting MTU on each interface separately (talking about switchport and Vlan interfaces, for multilayer switches with routed ports, settings similar to routers are applicable). You can change current MTU settings for switch ports using 3 methods applicable depending on type port:
SW01(config)#system mtu 1600- Change L2 MTU on FastEthernet portsSW01(config)#system mtu jumbo 1600- Change L2 MTU on GigabitEthernet and Ten GigabitEthernet portsSW01(config)#system mtu routing 1600- Change L3 MTU on routed interfaces
Checking:
SW01#show system mtu System MTU size is 1600 bytes System Jumbo MTU size is 1600 bytes Routing MTU size is 1600 bytes Note to the administrator.
Since the main method of checking MTU to this day is the PING command, with df-bit set and the packet size, I will conclude with a couple of useful tricks:
1) In order to find the minimum MTU (funny combination) on the network, you can use the extended ping command, and from both the end stations / servers and Cisco equipment. Ping from router R01 to router R02 with exposed df-bit, with an initial packet size of 1000 bytes, the last 1500 bytes, and a step of 100 bytes. The number of repetitions 2.R01#ping Protocol [ip]: Target IP address: 192.168.12.2 Repeat count [5]: 2 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.12.1 Type of service [0]: Set DF bit in IP header? [no]: y Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: y Sweep min size [36]: 1000 Sweep max size [18024]: 1500 Sweep interval [1]: 100 Type escape sequence to abort. Sending 12, [1000..1500]-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds: Packet sent with a source address of 192.168.12.1 Packet sent with the DF bit set !!!!..!!!!.. Success rate is 66 percent (8/12), round-trip min/avg/max = 4/24/56 ms
As you can see, only 6 ICMP packets with a size of 1000, 1100, 1200, 1300 bytes pass.
Starting from 1400 bytes and higher packets do not pass. Consequently, the minimum MTU between two points is 1300 and 1400, which can be refined in a few more cycles, compressing the range and relaxing step.
2) A frequent problem arises in the interaction of network and system administrators — packets of the same size pass from the end device, and a larger network device from the one closest to it. The reason is that the operating systems (in particular, Windows), when you specify the packet size to the ping command, perceive this value as a pure paiload — without the ICMP and IP headers, i.e. when specifying ping 192.168.1.2 -l 100, the system will generate 128 byte packets, not 100 (8 bytes ICMP header and 20 bytes IP). If you specify the same ICMP packet size on Cisco network equipment, the size you specify already includes both headers. Therefore, on the default Ethernet link, pings with Windows OS (for example) will show 1472 bytes of the maximum packet size passing without fragmentation, and Cisco 1500 bytes. JunOS, by the way, behaves as well as operating systems (does not include headers)
That's all. There is also an old draft in the bins of the article on the size of frames and their evolution, which describes the concepts of Jumbo Frame, Baby-Giant Frame, found in this article. If you see fit, I can modify and lay out and her.
Source: https://habr.com/ru/post/226807/
All Articles