VMware VeloCloud SD-WAN first packet dropped in UDP flows

Products

• VMware VeloCloud SD-WAN

Issue/Introduction

The first packet being dropped will cause an issue for some flows. Depending on the nature of the application it can cause a delay in the application establishing.

Environment

VMware VeloCloud SD-WAN

Resolution

It is expected that the first packet be dropped if both:
 - It's a UDP stream
 - The first packet is too large

For TCP, the VCE automatically does TCP MSS adjustment and ensures no large packets are ever sent.

For UDP traffic, the behavior is based in part on the "Do Not Fragment" bit:
Packets greater than 1500 bytes are dropped (Jumbo frames)
Packets greater than user MTU but less than 1500 bytes:
 - If "DNF" is set, the first packet is dropped with an "ICMP unreachable – fragmentation needed" message (RFC 1191).
 - If "DNF" is set, and the edge continues to receive too large of packets, it will do the fragmentation anyway to avoid dropping traffic.
 - If "DNF" is not set, packets are fragmented inside the Edge and sent.

                                                           
In this way, the originator is encouraged to do its own fragmentation whenever possible to distribute the load of a computationally expensive operation, but packets should never be dropped entirely.

In the past this has typically been caused by setting the MTU on the WAN links too low. The default is 1500 but some companies set it lower than that which can cause this issue - even if the MTU that's lower is not on the WAN link that's part of the packet path. It's good to test with all physical and WAN links set to 1500.

So to reiterate - this is not a bug. It is expected behavior and the solution can involve a mix of setting the appropriate MTU on the all the WAN links, and making sure that the device that sends the traffic to the edge sends it with an appropriate MTU.