So I've been trying to complete my MCSA, I'm now on 412. Anyway, NLB (network load balancing)... I'm struggling with how it works.


Each node in the cluster keeps it's own mac and IP address, whilst also using the cluster defined IP and Mac address.

I'm struggling to understand what MAC address the switch is aware of. I was under the impression that the switch would only know the cluster MAC address. Yet, when I use wireshark and look at the ethernet header, the source address is a nodes personal mac address. I thought a switch records the MAC from the source? Yet this multicast NLB seems to suggest otherwise.

Does anyone have any pointers for me?

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 16, 2017 at 22:03

2 Answers 2


There's a very good reason why the use of Microsoft's multicast NLB is not very popular in a whole lot of networks - it's a hack that breaks several basic operating practices and RFC's.

So - under normal circumstances multicast means that the destination IP of a packet is somewhere in the range, with this range broken up into various well-known chunks. In turn, there is a mapping of these IP multicast group addresses to certain MAC addresses. Here is a Microsoft article describing how that mapping is achieved.

Anyhow - what we normally have is that traffic is sent to a multicast group IP that is mapped to a multicast MAC address. The switch is smart enough to snoop on the Internet Group Management Protocol (IGMP) which is how individual end hosts signify which multicast groups they want to receive. When the switch sees an IGMP join request, it programs the port such that any packets to the multicast MAC are copied down. This means that on a network with 100 hosts if only 10 signify interest in this multicast group then traffic bound to that group only shows up on those 10 ports (...vs all 100 in the case of a broadcast).

Where Microsoft broke this is that they require a mapping of a unicast IP to a multicast MAC. They also require the underlying switch to either turn off IGMP snooping (...thus causing the cluster packets to be sent to every host in the subnet, whether they need them or not) or to statically map this address to the physical ports occupied by their servers (hint: this is NOT supported in lots of hardware and breaks vswitches and virtualization pretty horribly as well).

So - in essence Microsoft wrote a really, really hacky and awful way of doing this that requires that the underlying network layer break all kinds of accepted best practices for how networks otherwise work. To their credit they also have some newer modes (IGMP based) that aren't quite as bad but, ultimately, it's now a lot more common in new installations to see folks dropping back to a unicast-based mode that uses some kind of external load balancer to achieve the same effect in a more sane manner.


I don't know how Microsoft characterizes it, but in the real world, a switch looks at the source MAC address to update it MAC address table with the MAC address and interface on which it was seen. Then it looks in its MAC address table to see it it has an interface for the destination address.

Multicast is s special form of broadcast, and a multicast MAC address is only a destination MAC address. A host sending a frame will use its own MAC address as the source address, not a multicast address.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.