Logical Span Port mirroring result in GENEVE mac table "poisoning"
search cancel

Logical Span Port mirroring result in GENEVE mac table "poisoning"


Article ID: 324802


Updated On:


VMware NSX Networking


  • Logical Span Port mirroring with direction "Egress" is used.
  • The ESXi host GENEVE mac table shows discrepancy between the entries learnt by the NSX Controllers and the entries learnt by Datapath learning.
#nsxcli -c get logical-switch e740ad8d-c06d-4cb6-b5f2-786f171451e7 mac-table

                         Logical Switch MAC Table

                             Host Kernel Entry
     Inner MAC            Outer MAC            Outer IP      Flags
 00:50:56:88:96:7a    00:50:56:66:3d:2c    0xb <--- Datapath entry pointing to the incorrect TEP

                             LCP Remote Entry
     Inner MAC            Outer MAC            Outer IP
 00:50:56:88:96:7a    00:50:56:6c:d2:3d <--- Controller entry pointing to the correct TEP
  • VMs located on the ESXi host where the Logical Span Port mirroring destination VM is running loose connectivity to VMs with inconsistent GENEVE mac table entries.


VMware NSX-T Data Center
VMware NSX-T Data Center 2.x


This issue occurs because datapath learning is applied to mirrored packets while it should be skipped to avoid GENEVE mac table "poisoning".


This issue is resolved in VMware NSX-T Data Center 2.5.1, available at VMware Downloads.

To work around this issue, do one of the following:
  • Place the Logical Span Port mirroring source and destination VMs on the same ESXi host.
  • Do not use Logical Span Port mirroring with direction "Egress" ("Ingress" can be used as it will not cause the issue highlighted in this KB article).
  • Use Remote L3 Span instead of Logical Span for mirroring.