Switch change liao NLB Unicast broken, heartbeat kenna dropped by switch port. How to configure?

Chang Min 40 Reputation points
2026-08-07T06:10:05.03+00:00

Guys, need some help here. Just swapped out our core switch, now the NLB cluster running in Unicast mode totally down the drain. Traffic not balancing across nodes at all.

Checked the switch logs, turns out the port security / MAC spoofing protection on the new switch is blocking the inter-node heartbeats. Because Unicast mode uses the same virtual MAC across nodes, the switch think someone is doing MAC spoofing and straight away drop the packets.

Now the cluster cannot converge liao. What’s the proper switch port config to fix this ah? Must disable port security entirely, or need to configure static MAC/ARP mapping on the switch ports? Anyone hit this issue before, appreciate any advice!

Windows for business | Windows Server | Networking | Other
0 comments
Answer accepted by question author
Domic Vo 32,305 Reputation points Independent Advisor
2026-08-07T08:06:22.31+00:00

Hello,

You’re hitting the classic limitation of NLB in Unicast mode. By design, all cluster nodes share the same virtual MAC, and the switch sees multiple ports advertising that MAC. With modern switches, features like port security, MAC anti-spoofing, and dynamic ARP inspection will immediately flag this as a violation and drop the traffic. That’s why your inter-node heartbeat and convergence are failing.

You don’t need to disable port security globally, but you do need to adjust the configuration on the ports connected to the NLB nodes. The proper fix is to allow multiple instances of the same MAC on those specific ports. On Cisco IOS, for example, you’d configure the NLB-facing interfaces with switchport port-security maximum 2 (or higher depending on node count) and switchport port-security mac-address sticky disabled, so the switch accepts the shared virtual MAC. On some platforms, you may need to explicitly disable MAC spoofing protection or configure a static MAC entry for the NLB virtual MAC pointing to all cluster ports.

Another best practice is to consider switching the NLB cluster to Multicast mode instead of Unicast. In Multicast, the cluster uses a unique multicast MAC that doesn’t conflict with the node MACs, and you avoid the spoofing issue altogether. The trade-off is that you’ll need to configure a static ARP entry on the switch/router mapping the cluster’s virtual IP to the multicast MAC, otherwise upstream devices won’t know how to reach it.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-08-07T06:10:27.9633333+00:00

    For NLB in Unicast mode, the switch issue is expected: all cluster nodes replace their adapter MAC with the same NLB MAC, so switches cannot maintain correct MAC tables and can start flooding or mishandling traffic. The documented fix is not static ARP/MAC mapping for unicast mode.

    Use one of these supported approaches:

    1. Isolate the NLB nodes from the rest of the switch fabric
      • Put the NLB servers in a separate VLAN.
      • Ensure other subnets can still reach that VLAN.
      • This keeps the NLB traffic limited to the ports assigned to that VLAN.
    2. Place a hub between the switch and the NLB nodes
      • The hub presents the NLB unicast MAC on a single switch port.
      • The switch can then manage its MAC table correctly for that uplink.
      • The hub forwards traffic to the NLB nodes.
    3. If the nodes use dual NICs on Windows Server 2008 or later, enable IP forwarding
      • First get the cluster NIC index: 
             netsh interface ipv4 show int
      • Then enable forwarding on the cluster interface: 
             netsh interface ipv4 set interface <Cluster Idx> forwarding=enabled
      • Verify: 
             netsh interface ipv4 show interface <Cluster Idx> l=verbose
    4. Verify the cluster is actually set to Unicast in NLB Manager
      • Open Server Manager → Administrative tools → Network Load Balancing Manager.
      • Connect to the cluster if needed.
      • Right-click the cluster → Cluster Properties.
      • On Cluster Parameters, confirm Cluster operation mode is Unicast.
    5. Confirm the expected NLB MAC
      • Run: 
             NLB IP2MAC <VIP of NLB>
      • In Unicast mode, the MAC starts with 02-BF.

    For the specific question about switch configuration:

    • Static ARP and static MAC table entries are documented for Multicast mode, not Unicast mode.
    • For Unicast mode, the documented network-side fixes are hub insertion or dedicated VLAN isolation.
    • If switch security features are blocking the shared NLB MAC, the practical requirement is to allow that behavior on the affected NLB-facing ports or isolate those ports in a dedicated VLAN. Disabling protection across the whole switch is not required by the documented guidance.

    If the environment is a virtualized Hyper-V deployment, also enable MAC address spoofing on the VM NIC, because virtual switches commonly block the unicast behavior by default.

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.