Virtual Machines Fail to Communicate: Dropped by Logical Switch in NSX Federated Environments
search cancel

Virtual Machines Fail to Communicate: Dropped by Logical Switch in NSX Federated Environments

book

Article ID: 443303

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

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.

Environment

VMware NSX-T Data Center

Cause

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> l2forwarders
Wed Apr 29 2026 UTC 10:03:01.192
Logical Switch
UUID : <Segement_uuid>
VNI : 72716
Global VNI : 267513
L2Forwarder State : up
TCN 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 65535
10: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 40
10: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

Resolution

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.