Fragmentation considerations

For IPv4, when incoming packets destined for a DVIPA address need to be forwarded to a target TCP/IP stack using a route that was determined by a VIPAROUTE statement, the packet is encapsulated using GRE prior to being forwarded. This enables the packet to be forwarded through the network to the target stack while preserving the original packet's destination IP address (that is, the DVIPA address). The GRE encapsulation process increases the size of the forwarded packet by 28 bytes. As a result, if the size of the encapsulated GRE packets are larger than the maximum transmission unit (MTU) of the network interface that will be used for forwarding the packet, the TCP/IP stack might need to perform fragmentation, creating two or more packets that are forwarded to the target stack. The target stack then reassembles the fragmented packets.

While fragmentation and reassembly processing is not unusual in an IP network, it is desirable to eliminate the need for this processing, optimizing performance. For fragmentation as a result of GRE encapsulation, the cost of the fragmentation and reassembly processing might become a concern if a large percentage of the incoming DVIPA packets to be forwarded require fragmentation. Fortunately, configuration options do exist that can help eliminate the need for this fragmentation and reassembly processing, including the following options:

• Enable path MTU discovery on the client IP hosts (that is, client hosts sending packets to the DVIPA). This enables the client hosts to dynamically discover the smallest MTU along the path from the client to the server. In the case of forwarded DVIPA traffic, the path MTU is adjusted (reduced) by the length of the GRE header, if the addition of this header would have resulted in fragmentation being required. For IPv6, path MTU discovery is automatically enabled for all hosts, and no explicit configuration should be required.
• Ensure that the MTU size of the routes over the network interfaces that are used to forward the DVIPA packets is large enough to account for the largest client packet plus the length of the GRE header. This might be an option if the clients are connected to networks with a smaller MTU size than what is available in the network paths between the z/OS® hosts (that is, the TCP/IP stack forwarding the DVIPA packets and the target TCP/IP stack). Consider the following example:
  • The majority of the client hosts are connected to the network using Fast Ethernet, and as result use an MTU of 1492.
  • The route selected using the VIPAROUTE statement specifies a network path over OSA-Express Gigabit Ethernet between the two z/OS hosts. Gigabit Ethernet accommodates a much larger MTU size than Fast Ethernet (8992 versus 1492). This larger MTU size with Gigabit Ethernet is often referred to as jumbo frames.

  In this configuration, the z/OS hosts can be configured to take advantage of the larger MTU size when communicating with each other over the Gigabit Ethernet network. As a result, fragmentation is avoided for these forwarded DVIPA packets, as the larger MTU easily accommodates the increased packet size resulting from the GRE encapsulation. However, it is important to ensure that this larger MTU size is used only for communications among hosts where the entire network path supports the larger MTU size. Otherwise, packets sent from the z/OS hosts using the larger MTU size might need to be fragmented as they cross network boundaries that support only lower MTU sizes. As a result, when configuring larger MTU sizes, such as jumbo frames for Gigabit Ethernet, it is also important to consider enabling path MTU discovery on the hosts using the larger MTU size. This enables these hosts (in this example, the z/OS hosts) to use the larger MTU size only where appropriate, without introducing fragmentation. For more information on specifying MTU sizes on z/OS, see Determining the maximum transmission unit.