Duplicate network packets during NSX Edge Bridging over LAG

Products

• VMware NSX

Issue/Introduction

• Applications (e.g., SIP, VoIP) report duplicate frames or Call-IDs (e.g., xvdxghd3fyhdehijgihk1ievzfekj3xc@####).
• Host-level packet captures (pktcap-uw) show inbound traffic arriving on multiple physical uplinks (e.g., vmnic4 and vmnic8) in the LAG simultaneously.
• Network performance degradation due to redundant frame processing.

Environment

• Product: VMware NSX
• NSX Edge Node Sizing: Medium or Large
• NSX Edge Bridge configured over a LAG

Cause

A traffic processing anomaly occurs in the NSX Edge data plane during bridging operations on Large sized Edge nodes. The bridge may forward duplicated frames across all active uplinks in the LAG instead of steering traffic to a single member.

Resolution

To resolve this behavior, the Edge nodes must be appropriately sized to handle the data plane overhead required for bridging, and the environment should be updated to the latest maintenance release.

Workaround:

Migrate the affected Edge segment or bridge to an Extra Large (XL) Edge node. Testing has confirmed that the XL form factor handles the bridging logic more reliably.

Final Fix:

1. Upsize Edge Nodes: Resize NSX Edge Node
   
   • Deploy or redeploy the Edge nodes as Extra Large (XL).
   • Verify that the Edge nodes reside on hosts that meet the minimum resource requirements for the XL form factor.
2. Relocate Traffic: Move the bridging workloads back to the newly upsized and upgraded Edge cluster.
3. Validation: Perform host-level packet captures to ensure traffic is only traversing one physical uplink per flow. Packet capture on ESXi using the pktcap-uw tool

If the above workaround does not resolve the issue, open a support case with Broadcom. Contact Broadcom support

Additional Information

Configure an Edge VM for Bridging

Resize NSX Edge Node

Packet capture on ESXi using the pktcap-uw tool