When MAC learning is not active, newly added ports on a vSphere Distributed Switch (VDS) might go into blocked state

Products

• VMware vSphere ESXi

Issue/Introduction

This article describes the troubleshooting of network connectivity loss for VM needing "MAC Address change."

Symptoms:

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

Cause

This situation was introduced in vCenter 8.0 with the feature "MAC Learning configuration."

Resolution

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.

Workaround:
Use a virtual standard switch (vSS).

Additional Information

Impact/Risks:
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.