Dont-Fragment flag set in SimpliVity management network traffic?

[Sjoerd2106]

I was wondering if somebody knows if SimpliVity management traffic (from the virtual controllers) has the DF (Dont-Fragment) flag set in IP traffic?

I deal with a federation consisting of several SimpliVity clusters which connect through a WAN. Some sites use MPLS, but there is also a site which uses an IPSec VPN tunnel to connect to the other clusters.

The MTU for the management network is the default size of 1500. I can see some drops in network traffic from the SimpliVity nodes in the IPSec connected site.

As you may know, you cannot really send packets with MTU 1472 over an IPSec tunnel because of the encryption overhead. Unless you have the DF flag enabled, the packets will be fragmented over the IPsec tunnel.

Since there are no other issues with the IPsec connected site, I wonder if SimpliVity management network is set to use the DF flag? And if so, is it possible to disable the DF flag?

[db13]

@Sjoerd2106, The do not fragment flag is not set and sockets will adjust the MSS window based on what the network can handle. However, it is best practice to set the MTU for the OVCs to match the supported PMTU of the network. This MTU must be changed on all OVCs in the Federation. Please engage SimpliVity support to run a network test to determine what the OVCs should be configured to, and update the federation.

[Sjoerd2106]

Thank you for your quick reply. What is your definition for "PMTU"? Is this the MTU size of the physical path between the systems (in general 1500) or is the the actual MTU size that is left after different headers are added to a packet in case their is for instance an IPSec tunnel used within the path?

As mentioned before there are multiple scenarios. A scenario in where a MPLS connection is used between 2 clusters and for these scenarios the actual MTU size is similar to the MTU size on a LAN connection (1500) and there is a scenario in where an IPSec tunnel is used between 2 clusters and the actual MTU size for the Tunnel is somewhere around 1400. In both scenarios the physical path has a MTU size of 1500 but depended on the technology used to connect the the locations together where the Simplivity nodes are located, this can lower down to around 1400.

[db13]

@Sjoerd2106 I am referring to PMTU and the maximum support MTU along the entire path. If you have the VPN that reduces the MTU on the Path to 1400, then we would want to set the MTU on the OVCs Management interfaces to use the 1400 MTU. Otherwise, we will send packets out at the 1500 MTU and have to deal with the delays of retransmits. The MSS will be adjusted overtime so that packets will be scaled down, but that will have to happen to each conversation flow.

[Sjoerd2106]

Ok, thank you for that complete answer!

Would you only need to set MTU1400 on the management IP's for the virtual controllers? What about the management IP's for the ESXi hypervisors and the vCenter?

[db13 · Accepted solution]

Ideally, you would want it on all "Management" devices, including the vCenter server, Arbiter and ESXi Hosts port groups used for Management. Typically, the Arbiter and Virtual Controller would suffice as that is where majority of the SimpliVity management traffic is being generated. Also, changing the setting on the ESXi Hosts would affect all other VMs in the same port group, so we usually leave that at 1500.

[Sjoerd2106]

Ah, thank you for this answer! That is what I was somewhat looking for. My situation is that the vCenter also controls non SimpliVity ESXi nodes in a WAN network across Europe. Having to set the MTU to 1400 for all VMware components is a problem.

I know I could've also created a ticket for this issue, but I think it's important for the whole community to understand the MTU size issue when the SimpliVity management networks are connected over an IPSec VPN tunnel.