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

Products

• VMware NSX Networking

Issue/Introduction

Symptoms:

• 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.

Example:
#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      192.168.141.11    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      192.168.141.12 <--- 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.

Environment

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

Cause

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

Resolution

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

Workaround:
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.