Virtual Machines (VMs) located on two different segments within a VMware NSX-T Data Center federated environment are unable to communicate with one another.
When performing a packet trace utilizing the Traceflow diagnostic tool from the VMware NSX-T Manager UI, the observation trace indicates that the ICMP packets are explicitly "Dropped by Logical Switch" at the Edge Tunnel/Physical hop component.
VMware NSX-T Data Center
The communication failure occurs because the ESXi host incorrectly forwards traffic to an Edge node where the L2 forwarder is down. While the ESXi host's logical switch VTEP group accurately identifies the active Edge Transport Node (TEP), host uplink packet captures reveal that traffic is instead encapsulated and routed to the incorrect, standby Edge node. Upon receiving this misrouted traffic, the standby Edge node drops the packets because it is not the active L2 forwarder for the segment.
Supporting Evidence:
1. ESXi Host VTEP Group Status The ESXi host correctly identifies the Active VTEP to which traffic should be forwarded
get logical-switch <Segment UUID> vtep-group
Wed Apr 29 2026 UTC 10:00:09.205
VTEP Group Label: 83974
Type: Gateway
HA Type: Active/Standby
Activeness Proto: Activeness Notification
HA State Sync (ms): 5744125502
Active Mbr: 1
Label: 71723
VTEP IP: <####>
VTEP MAC: <####>
State: 2
BFD Count: 0
Label: 116738
VTEP IP: <####> <<< Active VTEP to which the traffic has to be forwarded from the host to the Edge.
VTEP MAC: <####>
State: 1 <<<<
BFD Count: 0
2. Active L2 Forwarder on the Edge Verification on the Edge node confirming the VTEP group is actively forwarding
get logical-switch <Segement_uuid> l2forwardersWed Apr 29 2026 UTC 10:03:01.192Logical SwitchUUID : <Segement_uuid>VNI : 72716Global VNI : 267513L2Forwarder State : upTCN notification : active
3. Source Host Uplink Packet Capture The packet capture confirms that the traffic is actively ignoring the identified active TEP and is instead forwarding to the incorrect Edge TEP.[root@<REDACTED_HOSTNAME>:~] pktcap-uw --uplink vmnicX --capture UplinkSndKernel,UplinkRcvKernel -o- | tcpdump-uw -r - -nne | grep -i <destination_VM>The name of the uplink is vmnic4.The session capture point is UplinkSndKernel,UplinkRcvKernel.pktcap: The output file is -.pktcap: No server port specifed, select 36311 as the port.pktcap: Local CID 2.pktcap: Listen on port 36311.pktcap: Main thread: 745362472128.pktcap: Dump Thread: 745363003136.pktcap: Recv Thread: 745363531520.pktcap: The output file format is pcapng.pktcap: Accept...pktcap: Vsock connection from port 1041 cid 2.reading from file -, link-type EN10MB (Ethernet), snapshot length 6553510:07:40.107720 <####> > <####>, ethertype IPv4 (0x0800), length 132: <####>.52692 > <####>.6081: Geneve, Flags [none], vni 0x10c04, proto TEB (0x6558), options [8 bytes]: <####> > <####>, ethertype IPv4 (0x0800), length 74: <####> > <####>: ICMP echo request, id 1, seq 4, length 40 <<<< Check the TEP tip: <####>10:07:45.107825 <####> > <####>, ethertype IPv4 (0x0800), length 132: <####>.52692 > <####>.6081: Geneve, Flags [none], vni 0x10c04, proto TEB (0x6558), options [8 bytes]: <####> > <####>, ethertype IPv4 (0x0800), length 74: <####> > <####>: ICMP echo request, id 1, seq 5, length 4010:07:50.108297 <####> > <####>, ethertype IPv4 (0x0800), length 132: <####>.52692 > <####>.6081: Geneve, Flags [none], vni 0x10c04, proto TEB (0x6558), options [8 bytes]: <####> > <####>, ethertype IPv4 (0x0800), length 74: <####> > <####>: ICMP echo request, id 1, seq 6, length 40
To restore production communication, restart the nsx-nestdb and nsx-proxy services on the affected ESXi host by executing the following commands:
/etc/init.d/nsx-nestdb restart
/etc/init.d/nsx-proxy restart
If a Root Cause Analysis (RCA) is required for this occurrence do not restart the above services, please open a new technical support case with Broadcom Support.