HSRP IP with virtual mac becomes unreachable

Products

• VMware NSX

Issue/Introduction

• HSRP IP with a virtual mac address becomes unreachable, which is assigned to VMs connected to NSX VLAN segments.
• The VLAN segment already has mac change and mac learning with Unknown unicast flooding allowed on NSX.
• qedentv drivers are being used on the host, and the below logs are repeatedly observed for the driver removing the virtual mac address:
  
  2025-07-09T09:28:07.796Z cpu28:2097460)[qedentv_multictx_set_rx_rule:1350(vmnic2)]Applying 00:00:##:##:##:##filter, vlan_id:#####, fp_id:0, hw_fn:0.
2025-07-09T09:28:12.797Z cpu28:2097460)[qedentv_multictx_remove_rx_rule:1756(vmnic2)]Removing mac:00:00:##:##:##:##, vlan_id:#####, from fp:0, op:MAC_DEL, hw_fn:0

• The packets ingressing the ESXi host destined for the HSRP IP are observed on the vmnic, but the same do not reach the VM switchport with the virtual mac address and get dropped within the ESXi host.
• NPAR is configured on the host

Environment

VMware NSX
VMware NSX- Data Center

Cause

• The qedentv NPAR configuration has many limitations which can also cause looping within the uplink.
• The HSRP mac is learned on the uplink instead of the VM vnic and thus, the packets do not get forwarded to the VM switchport.
  The same can be verified with the below command, or in the commands/dump-vswitch-info.py.txt path in support bundle:
  
  nsxdp-cli vswitch mac-table get --dvs-alias #####
PortID: Uplink    MAC: 00:00:##:##:##:## vid: ##### vni: 0        type: learned   aging: yes    elapsed: 0      mac-move: 147092 filterSrcPortID: 0

Resolution

Workaround:

• Associate to the HSRP IP the burned-in MAC of the active unit instead of using the virtual mac.
  
  OR 
• Disable npar_tx_switching on the host:

• • esxcfg-module -s 'npar_tx_switching=0' qedentv
  • Reboot

If this does not resolve the issue, open a case with Broadcom Support Team.