cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
11490
Views
25
Helpful
4
Replies
HUBERT RESCH
Participant

MS NLB in Multicast-Mode

Hi, has somebody exact knowledge

about running MS as NLB-Cluster in Multicast-Mode.

We want to use it instead of Unicast-Mode, because the Cluster-Members are located in the same VLAN with other (non-cluster-Members) Servers.

As I found there is a configuration-option in Multicast-Mode for IGMP.

So I know I ll have to configure static ARP entries on the routers in this VLAN. (Because Routers/L2-switches do not accept a MC-MAC-Address as

a answer for a ARP-request for an UC-IP-adress, which is the Clusters IP-Adress)

Thats all we want to configure statically.

So as I read the MC-MAC-address is derived from the UC-IP-Address in any way. Does anybody know how the relationship is, or is the MAC-adress

configurable in the Cluster configuration ?

If we know the MC-MAC-address and the MS-Guys configured the IGMP-option the next question would be for which IP-Multicast-adress they send a

IGMP-join (because there is a 32:1 overlap between IP-MC and MAC-MC)  On all our switches we use IGMP-Snooping (Assume the Cluster is using IGMP-V2).

Does anybody know how MS is doing this.

I just would need this knowledge to prevent an unwanted overlay with already existing MC-groups.

So in easy words:

Given

IP-UC-Cluster-Address

Which

MAC-MC-Cluster-Address  do they use in the ARP-reply

Which

IP-MC-Address  do they use for IGMP-Join

Thx in advance

Hubert

4 REPLIES 4
Andrew Gossett
Cisco Employee

Hi Hubert,

From a TAC perspective I have seen two different types of NLB multicast modes:

1) General multicast MAC (03bf.xxxx.xxxx)

2) IANA resesrved MAC (0100.5exx.xxxx)

For both cases you need to configured a static ARP on the Cisco router as it will not dynamically learn a multicast MAC for a unicast IP.

For case(1), you can additionally configure a static MAC address on the switches in the NLB vlan.  The NLB servers will never source a packet from the virtual MAC (VMAC) and therefore the switches on the vlan will never learn it.  Thus, all packets destined to the VMAC will be flooded on the vlan.  This ensures that all the NLB servers receive the packet but it also can cause unnecessary traffic for hosts on the vlan that do not need it.  Therefore, as an optimization you can configure a static MAC on all switches in the vlan pointing to the appropriate interfaces to ensure that NLB traffic is only delivered to the NLB servers:

mac-address-table static 03bf.ac00.0001 vlan 10 interface g0/1 g0/2

For case(2), the virtual IP (VIP) will use a multicast MAC that falls into the IANA reserved range for multicast.  For some switches, IGMP snooping will automatically prevent this packets from being flooded onto the vlan.  Therefore, you need to disable IGMP snooping when using an IANA reserved multicast MAC.  IGMP joins and the 32:1 multicast IP to multicast MAC is not relevant in this case as the VIP is a unicast IP.

See below for further details:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml

-Andy

Hi Andy,

in the meantime I found out that there is another possibility to run MS NLB Cluster, called Multicast IGMP mode.

In this case it is not necessary to disable IGMP Snooping an the switches.

MS NLB is sending IGMP report for the IP-Multicastadress which they derive from the NLB VIP-IP Unicast address.

eg. NLB VIP Unicast Address  a.b.c.d ->> derived MC Address 239.255.c.d

The only one we have to do on the Switches/Router is to configure a static arp entry for the NLB VIP Unicast address with the

IANA resesrved MAC (0100.5Exx.xxxx) which is the MC-MAC-Address for the 239.255.c.d (0100.5EFF.ccdd) and to configure an ip igmp querier on the subnet where the NLB-cluster is located

int vlan 100

ip igmp querier

ip arp a.b.c.d 0100.5EFF.ccdd arpa

I already tested and it works fine.

I my opinion its the best way to run NLB Cluster.

kr

Hubert

Hi Andy and Hubert,

When running MS NLB in multicast igmp mode, a customer could see that igmp snooping is not working. All packets are flooded all the ports.

The NLB server uses a VIP multicast MAC 0100.5exx.xxxx  and unicast IP.

The server sends IGMPv1 membership report to corresponding multicast MAC and multicast IP.

So, as far as I understand, igmp snooping should use this packet to map this MAC address to this port only and isolate further traffic to this MAC address.

A “sh ip igmp snooping group” shows the correct ports ( with multicast IP add).

But the packets coming with this destination multicast MAC keep on being flooded on all the ports (according to another discussion, ethertype 0800 shouldn’t be flooded, snif traces however show that these packets are flooded).

Why is igmp snooping not working?

Is this hardware depending, IOS depending?  (you wrote “for some switches”).

Thanks,

Alexandra.

Hi Alexandra,

In regards to IGMP snooping and  flooding behavior, different Cisco switches will operate differently.   For example, on 2960/3560/3750 platforms, if there is no IGMP snooping  mrouter detected on the vlan, the switch will flood all multicast  packets.  Other platforms, will not flood but also will be unable to  program their IGMP snooping tables preventing multicast traffic from  working on the same vlan entirely.  This an excellent document that  explains this behavior:

Multicast Does Not Work in the Same VLAN without an IGMP Querier

http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008059a9df.shtml

When  we are seeing multicast flooded out all ports we want to first check  that an mrouter is present on the vlan via "show ip igmp snooping  mrouter".  Also, some multicast packets will always be flooded if their  MAC address maps to the 224.0.0.x range.  For example, a mulicast group  of 239.0.0.2 has a destination MAC of 0100.5e00.0001.  This MAC will be  flooded (again, different platforms will operate differently).

I hope this helps,

-Andy