In this session we will delve into how fragmentation works and address its harms, detail MTU and other related resources, its influence on MPLS, IPSEC, GRE packet transport and some recommendations to ensure the correct transmission of datagrams. Follows all topics covered:

We will start by detailing the fragmentation of packages.

Package Fragmentation


By convention, whenever a host forwards an IPv4 packet (datagram) over the network, it cannot be larger than the maximum size supported by the network in question. The maximum acceptable limit is stipulated not only by the network data link, but also by the MTU (Maximum transmission unit), according to RFC 894, most ethernet devices use a maximum value of 1500 bytes, but several factors can interfere with transmission making these values smaller, for example, ethernet networks that are using SNAP (Subnetwork Access Protocol), passing through the LLC layer (Logical link control) or PPPoE (Point-to-Point Protocol over Ethernet) networks have an MTU of 1492 bytes, taking into account that the maximum size of an IPv4 datagram is 65535 bytes, when the packet reaches a point in the network where the MTU is smaller than its size, it is necessary to fragment packets.


Below is a reference table of the standard MTU value for some types of networks.


MTU x Protocol table

Network

MTU (in bytes)

WLAN 802.11

7981

Ethernet Jumbo Frames

1501 - 9198

Token Ring 802.5

4464

FDDI

4352

Ethernet

1500

IEEE 802.3 / 802.2

1492

PPPoE

1492


IP fragmentation is a procedure whose function is to segment the packets into parts that necessarily need to have a size equal to or less than the established limits, thus making it possible to carry out their transfer over a transmission link that has an MTU smaller than the packet original. This process allows the fragments to be forwarded independently, which generates a better use of the network resources, in addition, thanks to fragmentation, very large packets can be transported without causing a loss in performance and also facilitating transport to the destination host, if it did not hear fragmentation the packet would simply be discarded.


For more information regarding the fragmentation process, refer to RFC 791.


During the process of transferring the fragments to their recipient, the receiving host stores the received parts in a buffer while waiting for the transfer to complete, if the transmission takes too long, the destination host may issue a timeout message and discard the fragments, however if the transfer is successful, the fragmented parts of the packet are recomposed by the receiving host using as base certain fields of the IPv4 protocol header, at the end of this process the recipient results in the original packet reconstituted concluding the communication between the hosts.


For more information on the package recomposition process, refer to RFC 815.


The fragmentation process has several negative aspects that cause it to be considered harmful:

  • If a single fragment is lost during the transfer to the destination host, all fragments stored in the buffer are discarded, requiring retransmission of all fragments until the host has the necessary fragments to successfully reassemble the original package.;
  • Packet fragmentation does not send the fragments in a defined order, being characterized by allowing the parts to be sent independently, this requires the receiving host to order the fragments once they are received;
  • The IPv4 fragmentation process generates a small drop in the CPU and memory performance of all devices that perform this process;
  • The receipt of fragments by the receiving host also generates a drop in performance because it requires that it allocate part of its memory to store the fragments and then recreate the original package;
  • There are several devices that inspect the packets during transport, but thanks to fragmentation, only the first fragment of the packet will have the IPv4 header, which ends up causing conflicts with these devices;
  • Etc...


Next we will detail the MTU and define Jumbo Frames and MSS.


MTU, Jumbo Frames and MSS


As denoted by the name, the function of the MTU is to define the maximum size of the data blocks to be manipulated in layer 3 of the OSI model. Effectively the MTU establishes a size limit for the IP packets to be sent in a single transaction of the network layer without having to reduce the packet size (fragmentation), the higher the value, the less the overhead, however as smaller MTUs end up increasing the need for fragmentation, network delays are consequently reduced.

If it is necessary to exceed the maximum transmission capacity of the MTU (1500 bytes), it is possible to enable Jumbo Frames. The latter are a data unit capable of transmitting up to a maximum of 9000 bytes, used over Ethernet links, the use of Jumbo Frames automatically causes more data to be transferred using a smaller amount of packets and precisely because it reduces the need for fragmentation a performance improvement causing less protocol overhead. Despite the positives, Jumbo Frames are configured differently according to the specifications of each manufacturer, so it is necessary to analyze whether all devices on the network are in agreement, if at some point the MTU is limited to 1500 bytes, the package will be discarded or fragmentation will occur, invalidating the benefits of the Jumbo Frame.

Another way to deal with an increase in MTU is to configure the MSS (Maximum Segment Size), it is a parameter of the TCP header whose purpose is to define the maximum data that will be transferred in a single segment. The MSS defines the maximum amount of data that a host is willing to accept in a single IPv4 packet without considering the TCP and IP header, it is also characterized by being negotiated during the handshake process and cannot exceed the limit established by the MTU.


For more information about the MSS, refer to RFC 879 (for IPv4) and RFC 2460 (for IPv6).


Next we will detail the MPLS influence on the MTU and define Baby Giants.

Fragmentation, MTU and Baby Giants in MPLS


Thanks to the particular characteristics of how MPLS works, it ends up impacting the way traffic is routed: Effectively, MPLS adds labels that are used to create its own routing table, since each of these labels is equivalent to 4 bytes in length, there is interference in the size of the Ethernet frames. In normal use situations, this increase does not interfere negatively in the transmission of the packets, however, in the use of IPSEC VPN tunnels for example, the header of the data packets has its size increased even more.

Taking into account a scenario where the IP packet is already using the maximum possible size established by the MTU (1500 bytes), but it is not large enough to justify the use of Jumbo Frames (the packet is less than 1600 bytes), it is classified like a Baby Giant. Most of the time, switches and routers ignore the fact that packets of this type have exceeded the MTU limit and allow communication normally, but this depends on the specifications of each appliance on the network.

Considering this scenario, a way to prevent conflicts is to reduce the MTU of the IP, the MTU of the MPLS itself and the maximum size of the TCP segment (MSS) to transfer a maximum of 1500, so that the packets already with the added labels will not exceed the standard limit.

Considering a scenario where the size of the packages is large enough not to be considered a Baby Giant, it is recommended to use Jumbo Frames to increase the limit to 9000 bytes.


For more information about MPLS, see this page.


Next, we will detail fragmentation in GRE and IPSEC tunnels.

Fragmentation in GRE and IPSEC tunnels


According to RFC 2784, GRE tunnels add 20 bytes in an IPv4 header and an additional 4 bytes in a GRE header, in addition, when encapsulating packets in another protocol, the frame in general ends up increasing in size and causing overhead in the header, which impairs transport by devices using a standard MTU, in the case of IPSEC, about 80 bytes (ESP and IP header) are added to perform the encapsulation, in addition, the encryption algorithms used in VPN tunnels can add more bytes to the transported datagrams (in the practice of padding for example) and finally, another impact factor is whether IPSEC is using the mode of transport or tunnel which can also cause more overload factors.

Thanks to all the points previously mentioned, it is very likely that there will be fragmentation in the packets sent and consequently lose in the performance of the VPN tunnel.

Considering this scenario where the size of the packets is always tending to exceed the MTU limits because of encapsulation, encryption and other factors, it is recommended: Adjust the MTU of the physical interface where the IPSEC was configured, set an MSS value in order to reduce the size of the transported segments and, if necessary, consider changing the encryption algorithm of your tunnel.



  • No labels