Each and every overlay, including VMware, adds an additional layer of difficulty to the traffic that travels across the network. Following an explanation of how this increased overhead relates to MTU and packet fragmentation characteristics in the network, this section begins by describing the overhead that is added in a standard IPsec network and comparing it to VMware. What follows is an explanation of how this added overhead compares to VMware.
IPsec Overhead Tunnel
The traffic that is transferred between endpoints in a conventional IPsec network is often carried out through an IPsec tunnel. When encrypting traffic, a conventional IPsec tunnel scenario, which uses AES 128-bit encryption and ESP (Encapsulating Security Payload), results in multiple kinds of overhead, including the following:
- Padding
- The size of an AES encrypted block is 16 bytes, and this is called the “block” size.
- If a packet’s body is less than or equal to the block size, it is padded to make it the right size.
Examples:
A 1-byte packet will expand to 16 bytes after padding with 15 bytes.
After 8 bytes of padding, a 1400-byte packet will become 1408 bytes.
Padding is not necessary for a packet of 64 bytes.
Headers and trailers for IPsec:
- This is the UDP header for NAT Traversal (NAT-T).
- The IP header for the IPsec tunnel mode.
- Header and trailer for ESP.
Element |
Size in Bytes |
IP Header |
20 |
UDP Header |
8 |
IPsec Sequence Number |
4 |
IPsec SPI |
4 |
Initialization Vector |
16 |
Padding |
0 – 15 |
Padding Length |
1 |
Next Header |
1 |
Authentication Data |
12 |
Total |
66-81 |
The above examples presuppose that a NAT device is in front of at least one device. IPsec overhead is 20 bytes smaller if NAT is not utilized since NAT-T is not necessary. Whether or whether NAT is present has no effect on how VMware behaves (NAT-T is always active).
VMware Tunnel Overhead
The VeloCloud Multipath protocol (VCMP) is a system that VMware wraps packets in so that it can work with Dynamic Multipath Optimization (DMPO). VCMP adds 31 bytes of extra space to user messages so that errors can be fixed, the network can be analyzed, and the network can be split up within the same tunnel. VCMP works on UDP 2426, which is a port that is listed with IANA. To make sure that VCMP always acts the same way, whether it’s unencrypted, encrypted, or behind a NAT, VCMP is encrypted using IPsec transport mode and a special NAT-T port number 2426 is used to make this happen.
This is because packets sent to the Internet through the SD-WAN Gateway will go straight to the open Internet after leaving the Gateway. With this in mind, Internet Multipath traffic has less cost than VPN traffic.
Internet traffic can be encrypted through the Gateway, and if service providers choose to employ this option, the “VPN” overhead will also apply to Internet traffic. Service providers have the option to encrypt Internet traffic.
VPN Traffic
Element |
Size in Bytes |
IP Header |
20 |
UDP Header |
8 |
IPsec Sequence Number |
4 |
IPsec SPI |
4 |
VCMP Header |
23 |
VCMP Data Header |
8 |
Initialization Vector |
16 |
Padding |
0 – 15 |
Padding Length |
1 |
Next Header |
1 |
Authentication Data |
12 |
Total |
97 – 112 |
Internet Multipath Traffic
Element |
Size in Bytes |
IP Header |
20 |
UDP Header |
8 |
VCMP Header |
23 |
VCMP Data Header |
8 |
Total |
59 |
MTU Discovery of the Path
Once it is known how much overhead will be used, the SD-WAN Edge needs to find the highest MTU that can be used to figure out the actual MTU for customer messages. The Edge does Path MTU Discovery to find the highest MTU that is allowed:
For Public internet WAN links:
- Discovery of Path MTUs is done for every Gateway.
- The minimum MTU that is found will be used as the MTU for all tunnels.
For private WAN links:
- The discovery of the path MTU is carried out to each and every other Edge in the customer’s network. No Attachment Found