Microsoft NLB - IGMP Mode does not really work

[gnijs]

Hello,

I am trying to validate a Microsoft NLB cluster setup that is running in IGMP Multicast mode.

I can see the IGMP snooping result:

300       239.255.82.160           igmp        v1          Gi1/0/9, Gi1/0/10,

                                                           Po4

The switch clearly learns only Gi1/0/9 and Gi1/0/10 as members. However, when i sniff on a server at Gi1/0/11, i still get the multicast packets.

It seems that the restrictions of port forwarding don't work.

(note: gi1/0/9,10 and 11 are actually trunks that contain vlan 300)

If i read the following document:

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

it states:

"However, since the incoming packets have a unicast  destination IP address and multicast destination MAC the Cisco device  ignores this entry and process-switches each cluster-bound packets. In  order to avoid this process switching, insert a static mac-address-table  entry as given below in order to switch cluster-bound packets in  hardware."

For me , this means IGMP is not working. Workaround: static mac

And indeed, when i configure:

mac address-table static 0100.5e7f.52a0 vlan 300 interface GigabitEthernet1/0/9 GigabitEthernet1/0/10

the flooding on Gi1/0/11 stops.

When i test with a "normal" multicast packets (this means: multicast MAC destination and multicast IP destination), i don't have this behaviour and IGMP snooping seems to work perfectly.

Could someone confirm that IGMP snooping and limiting the port flooding does not work if the switch sees a packet with a

multicast MAC destination but with a unicast IP destination (such as in MS NLB) ??

I am running this on WS-CBS3120G-S, Version 12.2(46)SE

regards,

Geert

[Viral Bhutta]

There is a note mentioned at then of the configuration example.

Note:

Ensure that you use the multicast mode on the NLB cluster. Cisco recommends that you do not use multicast MAC addresses that begin with 01 because they are known to have a conflict with the IGMP setup.

So if you are using multicast mode with IGMP then you will have mac address starting with 01.

That being said, if there is no clash with the multicast mac address then you should not see flooding.

Have you tried to enable IGMP querier on the switch.

http://www.cisco.com/en/US/docs/switches/blades/3120/software/release/12.2_46_se/release/configuration/guide/swigmp.html#wp1193337

ip igmp snooping querier version 1

Hope this helps.

[Viral Bhutta]

I did some more research on this.

WS-CBS3120G-S which is based on 3750 software architecture, it allows IGMP snooping based on IP group address and not on multicast mac address. This was done to avoid mac-address aliasing issue. Older 3550 Switches used to do IGMP snooping based on mulitcast address and hence it would work correct in NLB snooping scenario since it does not care about the ip address.

Thus you see flooding for NLB packets which has unicast ip address and multicast mac address. Unfortunately you will have to use static mac address configuration.

Hope this helps.

[gnijs]

Thank you for putting some time into this. It seems indeed the problem is the non-multicast destination address then. As you can see in the igmp output, the cisco switch thinks it is group "239.255.82.160" being used (based on the mac address. In reality, the packets have a destination ip address of 10.102.82.160. I will try your igmp querier suggestion also to see if it makes a difference.

[bdube]

It's normal.

IGMP not understanding MAC multicast: Indeed, IGMP is an IP based protocol, see http://tools.ietf.org/html/rfc3376.

I suspect MS NLB IGMP waits to receive packets on 239.255.82.160 for multicast use, in addition to 10.102.82.160 for unicast use. Both are probably working simultaneously.

Then, for multicast, you have to make natting at your level 3 gateway, then incoming request from outside destined to 10.102.82.160 mapped to 239.255.82.160 on the cluster's vlan.

Don't forget to activate IGMP snooping on your switches and have an IGMP querier activated somewhere (Cisco switch or L3 Gw).

Ben