BugZero updated this defect 45 days ago.
Data sources
All data on this page is proprietary to BugZero® or gathered from public sources
4/4/2024
vSphere ESXi
No affected releases provided.
No fixed releases provided.
Upon changing the MAC address from within the guest OS (for example, for CARP/VIP failover), vNICs have their port blocked due to L2 security violation - despite the configuration in the vCenter UI showing the policy for such changes is set to "Accept." "net-dvs -l " command shows the effective parameters: deny mac change com.vmware.vswitch.port.security = deny promiscuous; deny mac change; deny forged frames propType = POLICY com.vmware.vswitch.port.macManagement: Allow MAC Change = False MAC Learning = False Unknown Unicast Flooding = False MAC Limit = 4096 MAC Limit Policy = ALLOW propType = CONFIG
This article describes the troubleshooting of network connectivity loss for VM needing "MAC Address change."
This situation was introduced in vCenter 8.0 with the feature "MAC Learning configuration."
It only impacts distributed portgroups created or after the upgrade to (or on a fresh install of) vCenter 8.0, when MAC Learning is set to Disabled.
This issue is resolved in ESXi 8.0 Update 2b - Build 23305546.https://docs.vmware.com/en/VMware-vSphere/8.0/rn/vsphere-esxi-80u2b-release-notes/index.html PR 3308461: When MAC learning is not active, newly added ports on a vSphere Distributed Switch (VDS) might go into blocked state If MAC learning on a VDS is not active, when from the guest OS you change the MAC address of a virtual machine to a new proxy switch port, the newly added port might be in a blocked state due to a L2 violation error, even when the Mac address changes option is set to Accept. The issue occurs only when MAC learning on a VDS is not active. This issue is resolved in this release.
Use a virtual standard switch (vSS).