HTTP Communication Latency and TCP Spurious Retransmission in NSX Environments.

Products

• VMware NSX

Issue/Introduction

• HTTP communication between client and server is significantly slow following an environment migration to NSX.
• Packets captured on server side show frequent TCP Spurious Retransmission messages.
• Wireshark analysis of the traffic reveals numerous [TCP CHECKSUM INCORRECT] errors on ACK packets.
• Encapsulated packets (Geneve) contain a non-zero Ethernet trailer (eth.trailer) or similar.
  
  Example packet capture:
  tshark -r server.pcapng -o tcp.check_checksum:TRUE -T fields -e frame.number -e frame.time_relative -e eth.trailer -e _ws.col.Source -e _ws.col.Destination -e _ws.col.Protocol -e frame.len -e _ws.col.Info

  <frame.number>     <frame.time_relative>             <SERVER_IP>        <CLIENT_IP>      TCP     54      80 → 23433 [ACK] Seq=26 Ack=890 Win=262656 [TCP CHECKSUM INCORRECT] Len=0
<frame.number>     <frame.time_relative>             <SERVER_IP>        <CLIENT_IP>      HTTP    4065    HTTP/1.1 200 OK [Unreassembled Packet [incorrect TCP checksum]]
<frame.number>     <frame.time_relative>     fefefefefefe    <CLIENT_IP>      <SERVER_IP>        TCP     60      23433 → 80 [ACK] Seq=890 Ack=4037 Win=8047 [TCP CHECKSUM INCORRECT] Len=0 <=== this packet is ignored by the server.
<frame.number>     <frame.time_relative>             <SERVER_IP>        <CLIENT_IP>      HTTP    1391    [TCP Spurious Retransmission] HTTP/1.1 200 OK [Unreassembled Packet [incorrect TCP checksum]]
<frame.number>     <frame.time_relative>             <CLIENT_IP>      <SERVER_IP>        TCP     60      [TCP Dup ACK 280#1] 23433 → 80 [ACK] Seq=890 Ack=4037 Win=8047 Len=0

  NOTE: When ethernet trailer is non-zero, actual eth.trailer value such as "fefefefefefe" is displayed.
  In this example, only the line ignored by the server has eth.trailer displayed.
  When ethernet trailer is zero, the command output is empty.

Environment

NSX 4.2.1.1

ESX 8.0 U3

Cause

This issue occurs due to a conflict between certain NIC hardware/firmware and how ESX handles Geneve-encapsulated packets.

When a packet contains a non-zero Ethernet trailer, the hardware-based checksum offload (CSO) may fail to calculate the correct TCP checksum for the inner packet of a Geneve tunnel. The receiving end identifies the incorrect checksum and ignores the ACK, leading the sender to believe the packet was lost and trigger spurious retransmissions.

In this example:

1. Client sends ethernet frame smaller than 60 bytes.
2. Router adds non-zero padding to meets 60 bytes.
3. NSX Edge bridges ethernet frame with non-zero padding in ethernet trailer.
4. vmnic breaks Inner TCP checksum in Geneve packet.

 

Resolution

To resolve this issue on ESX, configure the ESX host to perform IPv4 checksum calculations via software instead of relying on the hardware offload for the affected physical adapters (vmnics).

1. Log in to the ESX host where the affected NSX Edge node or VM is running via SSH.
2. Identify the status of the software checksum offload for your physical NICs.
   esxcli network nic software list
   
   If IPv4 CSO is off, software-based IPv4 checksum offload is disabled.
   
   Output Example:
   NIC     IPv4 CSO  IPv4 TSO  Scatter Gather  Offset Based Offload  VXLAN Encap  Geneve Offload  IPv6 TSO  IPv6 TSO Ext  IPv6 CSO  IPv6 CSO Ext  High DMA  Scatter Gather MP  VLAN Tagging  VLAN Untagging
   ------  --------  --------  --------------  --------------------  -----------  --------------  --------  ------------  --------  ------------  --------  -----------------  ------------  --------------
   vmnic0  off       off       off             off                   off          off             off       off           off       off           off       off                on            on
   vmnic1  off       off       off             off                   off          off             off       off           off       off           off       off                on            on
   
   
3. Enable software-based IPv4 checksum offload for the specific vmnics used to send Geneve traffic.
   esxcli network nic software set --ipv4cso=1 -n vmnicX
   
   NOTE: Replace vmnicX with actual vmnic that sends Geneve packets.
   
   To verify IPv4 CSO status, run following command 
   
   
4. Verify the changes by running the list command again. The IPv4 CSO column should now display on for the modified NICs.
   esxcli network nic software list
   
   IPv4 CSO is on, software-based IPv4 checksum offload is enabled.
   
   Output Example:
   NIC     IPv4 CSO  IPv4 TSO  Scatter Gather  Offset Based Offload  VXLAN Encap  Geneve Offload  IPv6 TSO  IPv6 TSO Ext  IPv6 CSO  IPv6 CSO Ext  High DMA  Scatter Gather MP  VLAN Tagging  VLAN Untagging
   ------  --------  --------  --------------  --------------------  -----------  --------------  --------  ------------  --------  ------------  --------  -----------------  ------------  --------------
   vmnic0  off       off       off             off                   off          off             off       off           off       off           off       off                on            on
   vmnic1  on        off       off             off                   off          off             off       off           off       off           off       off                on            on
   
   In this example, software-based IPv4 checksum offload is enabled on vmnic1.

Additional Information

Some VM TCP sessions don't work correctly