1.1. Multicast mode with IGMP

1.1.1. Advantages
· No flooding of the VLAN
· Mutual communication between the NLB members is possible without an extra NIC (compared to Unicast mode)
1.1.2. Disadvantages
· It does not work automatically on all networkequiment (ex. Cisco). An IGMP querier has to be activated in the vlan to enable IGMP snooping
1.1.3. Causes
· on layer 2: When choosing multicast IGMP as NLB operation mode, the original MAC-adresses of the NLB members are not changed. The switch registers the NLB members in its MAC table with their original MAC-addresses.
· on layer 3: an arp-request to the NLB cluster or to an NLB member is always answered with MAC-address: 0100.5e7f.xxxx. This is an official (IANA) multicast MAC-address because it starts with 0100.5exxxx is the hex representation of the NLB-cluster IP-address. example: 89.17.67.197 has 0100.5e7f.43c5 in its ARP response. This MAC-address does not get registered automatically in a Cisco router or L3-switch because Cisco does not accept an ARP response which connects an Unicast IP adres with a multicast MAC-address.
1.1.4. Impact
· Cluster not reachable from behind routerThe cluster ip-address cannot be reached from behind a Cisco router or L3-switch
· FloodingAll switches wants to deliver packets for the NLB member or the NLB cluster to the 0100.5e7f-MAC address. This MAC-address is not registered on in the switches MAC-table. Therefore these packets are sent out on every port of every switch. This behaviour is called “flooding”.As a result every NLB member receives the trafic destined for the NLB cluster. This is how the cluster gets his work done.The downside of this behaviour is that all other members (other NLB’s or standalone servers) on the same VLAN also get spammed with this traffic.
1.1.5. Possible solutions:
· Cluster not reachable from behind Cisco router Adding a static entry in the ARP-table of the router makes the cluster available from behind the router
SWCOGD01(config)# arp 89.17.67.197 0100.5e7f.43c5 ARPA

· FloodingActivate “IGMP snooping” the VLAN. This requires switches that support “IGMP snooping”. On top of this, an IGMP querier has be activated in the vlan. For Cisco this can only be done on a layer 3 switch or router
ip multicast-routinginterface Vlan322ip pim dense-modeip igmp version 3

Multicasting on layer 2 can be looked upon as a dynamic vlan. NLB members in the server vlan can subscribe to a certain multicast stream.
To do this, they send an IGMP Join message to the connected switch. They want to see all traffic towards MAC-address 0100.5e7f.xxxx.xxxx. The switch remembers this by registering this dynamically into his MAC-table. The switch than forwards this to the IGMP querier. This querier is activated in the router of the server vlan. The querier periodically sends out queries to discover if the NLB members stay interested in the NLB multicast traffic. By doing so, all traffic to the NLB1 cluster is sent out only to switchports connected with an NLB1 member.
1.2. Conclusion
An Microsoft NLB is best run in the Multicast IGMP mode because:
· flooding is prevented so other server communication in the vlan is not disturbed
· it requires less administration
· it enables mutual communication between NLB members (as opposed to unicasting)

1.1. Multicast mode


1.1.1. Advantage
· Mutual communication between the NLB members is possible without an extra NIC (compared to Unicast mode)
1.1.2. Disadvantages
· It does not work automatically on all networkequiment (ex. Cisco)
· Traffic to the NLB cluster and to the individual members is received by all servers in the server vlan
1.1.3. Causes
· on layer 2: When choosing multicast as NLB operation mode, the original MAC-adresses of the NLB members are not changed. The switch registers the NLB members in its MAC table with their original MAC-addresses.
· on layer 3: an ARP-request to the NLB cluster is always answered with MAC-address: 03BF.xxxx.xxxx. xxxx.xxxx is the hex representation of the NLB-cluster IP-address. These MAC-addresses are multicast MAC addresses because the broadcast/multicast bit (0100.0000.0000) is set.example: 89.17.67.197 has 03bf.5911.43c5 in its ARP response. This MAC-address does not get registered automatically in a Cisco router or L3-switch because Cisco does not accept an ARP response which connects an Unicast IP adres with a multicast MAC-address.An ARP-request to a NLB member is answered with the original MAC-address of that member. The ARP-responses are registered automatically in the ARP-table.
1.1.4. Impact
· Cluster not reachable from behind routerThe cluster ip-address cannot be reached from behind a Cisco router or L3-switch
· FloodingAll switches wants to deliver packets for the NLB member or the NLB cluster to the 03BF-MAC address. This MAC-address is not registered on in the switches MAC-table. Therefore these packets are sent out on every port of every switch. This behaviour is called “flooding”.As a result every NLB member receives the trafic destined for the NLB cluster. This is how the cluster gets his work done.The downside of this behaviour is that all other members (other NLB’s or standalone servers) on the same VLAN also get spammed with this traffic.
1.1.5. Possible solutions:
· Cluster not reachable from behind Cisco router Adding a static entry in the ARP-table of the router makes the cluster available from behind the routerSWCOGD01(config)# arp 89.17.67.197 03bf.5911.43c5 ARPA

· FloodingFor each NLB, create a vlan to limit the flooding. This is very labour-intensive with regard to setup and maintenance

1.1. Unicast mode


1.1.1. Advantage
· It always “works”. No special actions on the network level are needed. All registrations on network devices work automatically.

1.1.2. Disadvantages
· Traffic to the NLB cluster and to the individual NLB members is received by all servers in the server vlan
· Mutual communication between the NLB members is not possible without an extra NIC
1.1.3. Causes
· on layer 2: The switch registers the NLB members in its MAC table with this MAC-address: 02pp.xxxx.xxxx. “pp” is the priority of the NLB member. example: an NLB member with priority 1 and cluster ip address 89.17.67.197 gets MAC-adres 0201.5911.43c5. The second NLB member with priority 2 gets MAC-adres 0202.5911.43c5
· on layer 3: an arp-request to the NLB cluster or to an NLB member is always answered with MAC-address: 02BF.xxxx.xxxx where xxxx.xxxx is the hex representation of the NLB-cluster IP-address. example: 89.17.67.197 gets dynamically registered in the ARP-table with 02bf.5911.43c5

1.1.4. Impact
· Mutual communication impossibleWhen member1 wants to communicate with member2 of the same NLB it first sends an ARP-request. Member2 answers with 02BF-MAC-adres which also belongs to member1. As a result member1 is unable to sent out a packet.
· FloodingAll switches wants to deliver packets for the NLB member or the NLB cluster to the 02BF-MAC address. This MAC-address is not registered on in the switches MAC-table. Therefore these packets are sent out on every port of every switch. This behaviour is called “flooding”.As a result every NLB member receives the trafic destined for the NLB cluster. This is how the cluster gets his work done.The downside of this behaviour is that all other servers (other NLB’s or standalone servers) on the same VLAN also get spammed with this traffic.
1.1.5. Possible solutions:
· Mutual communication This can be solved by using an extra NIC on each NLB member. These non-NLB NICs register in the MAC-tables of the switches with their real MAC-adres. When the NLB member gets ARP’ed on this new NIC, it answers with its real MAC-adres. Because of this NLB members of the same cluster can now talk to each other.
· FloodingFor each NLB, create a vlan to limit the flooding to that vlan. This is very labour-intensive with regard to setup and maintenance