IGMP Snooping

[Kevin Dorrell]

I have tried to use IGMP snooping in a certain scenario, and it does not do what I was expecting.

I have two servers on my LAN that are sending out multicasts (to each other)as part of a load-balancing control thing. The multicast destination MAC addresses are 01:00:5e:7f:xx:yy, where xx and yy happen to be the penultimate and last bytes of the server's own individual IP address. To me these look like they should behave like IP multicasts. But the Ethertype is not IP; it is 0x886f.

These multicasts are getting flooded throughout the VLAN, and I was trying to control them by enabling ip igmp snooping, at least on those switches that are not concerned with the multicast. But it does not seem to have any effect on the flooding. If I understand correctly, IGMP snooping should block all 01:00:5e multicasts unless there is a host specifically asking for the stream by sending an IGMP.

Can anyone comment on this? Does IGMP snooping only filter multicasts with an IP Ethertype, or is it purely on MAC address?

I did a show ip igmp snooping group, and I do see some IP multicast groups, but nothing that corresponds to the addresses that these two servers are sending to.

Kevin Dorrell

Luxembourg

[Bobby Thekkekandam · Accepted solution]

Hi Kevin,

Your suspicion is correct. Because of the non-IP ethertype, the multicast traffic will be flooded within the vlan or bridge group.

Your best bet here is to use a static mac-address-table entry for this type of multicast traffic. However, this method may be functionally limited depending on the switch platform in question. For example, on the cat4k, this is only possible in 12.1(22)E1, and 12.2(18)EW and later (see CSCec53996).

[Kevin Dorrell]

Thanks Bobby, that is exactly the information I needed.

My network is made up of:

- some Cat4500 runnning 12.2(25)EWA1,

- some Cat4000 running 8.4(5)GLX,

- some old Cat 5500 running 6.3(10)

- some Cat 2900XL running 12.0(5)WC13

- some Cat 2950 running 12.1(22)EA5

The multicast in question is generating a bachground hoise on the VLAN of about 4 frames per second - not a lot, but worth trimming if I can.

I guess I would be best to do this in the distribution layer, which has a couple of Cat 4506 running 12.2(25)EWA1. The VLAN in question goes to all the access switches, but if I can restrict its scope with static CAM entries, that would seem to fit the bill. Only two access switches out of a total of about 40 actually need this multicast. I guess I could do something with a private VLAN, but I would need to research it first.

Thanks again.

Kevin Dorrell

Luxembourg

[Kevin Dorrell]

There is a complication.

On my Cat 4500 switches, it will not allow me to do a mac-address-table static HHHH.HHHH.HHHH vlan n for an IP multicast MAC address because IGMP snooping is on. (This restriction only applies to MAC addresses with the 01:00:5e header - I tested it with 0123.4567.89ab, and it does allow that) I cannot switch IGMP snooping off because I need it to control my real IP multicast streams.

Instead it suggests using ip igmp snooping vlan 1 static ... . But that is no good either because, like the dynamic IGMP snooping, it only applies to frames with the Etype 0x0800. Which leads us back to square 1.

Ironically, the servers that are generating this multicast seem to believe they are doing IP multicast, because as well as generating their data stream with the strange 0x886F ethertype, they are generating IGMP reports for the equivalent IP multicast addresses, and the switches are putting these into their IGMP snooping tables. Just that the IGMP snooping tables are ineffective because of the strange Ethertype in the multicast data stream.

Even more ironically, the multicast router is also seeing the IGMP reports, and putting them in its table. And to confuse matters even further, it is running CGMP to control the older 4000 series switches. The CGMP does control this multicast stream, because the CGMP does not restrict itself to controlling 0x0800 frames. So ... the multicast is controlled correctly on CGMP switches, but not on IGMP snooping switches. Ha!

I am surprised that Cisco have not come across this problem before, 'cos the protocol in question is Dell VMware virtual server NLB.

The wierdest thing about all this is when you ping one of those servers. When you ARP it, it gives you the IP multicast address. It is basically saying "You can talk to me, but you have to talk to all my partners at the same time." (I presume the overlayed protocols must be UDP-based or something else connectionless. You cannot have multicast at the lower level and connection-oriented at the higher level can you?) So a ping works from a PC in the same VLAN, but not from outside the VLAN ... because the router does not like putting a multicast MAC address in its ARP cache.

I'm stuck again. Any ideas?

Kevin Dorrell

Luxembourg

[Bobby Thekkekandam]

Hi Kevin,

You are right, the caveat here is that with the

mac-addr static vlan protocol all

command, IGMP snooping has to be disabled for that vlan. I can't think of any way around this other than to possibly isolate these Dell NLBs on their own VLAN, disable IGMP snooping on that vlan, and then use the static MAC entry. Of course, this may also defeats the purpose of constraining the mcast traffic if you are already isolating it to its own vlan.

The other option, of course, is to somehow make the Dell servers send its data frames with a valid IP ethertype, but whether that is possible or not is a question for Dell, or whomever wrote the software.

The ARP issue is a bit strange as well. Whichever device is responding to the ARP should be responding with it's own IP address or shared/virtual IP address, and not the IP multicast address, as sourcing a frame from a multicast address is not valid. I'd assume this behavior is independent of switch platform, correct?

[Kevin Dorrell]

Thanks Bobby.

Just on that last point, maybe I didn't explain carefully enough about the ARP. When the client broadcasts an ARP request for the server's unicast IP address, the server responds from its own unicast MAC address to the ARP requester's unicast MAC address. But the field it carries in the "target HA" is the multicast address. In other words, it is telling the client to use the multicast MAC address as destination for the IP unicast data.

This protocol looks really yukky, doesn't it? It may work for load balancing and resilience within the VLAN, but I guess that as soon as I isolate it, it will all stop working. The client won't be able to reach the server, because the router will be unwilling to put the multicast MAC address into its ARP cache on the server-VLAN side.

I wondered whether the multicasts are only intended between server partners, and the client access works some other way. But I cannot imagine how that would work, 'cos the server would still be offering a multicast MAC target, and router would still not like it in its ARP cache.

Time to talk to Dell! Or to isolate the server and tell the server team that they will get connectivity when they can persuade the Dells to behave properly vis-à-vis ARP.

Thanks again.

Kevin Dorrell

Luxembourg

[Kevin Dorrell]

Correction: the last paragraph should read "When you ARP it, it gives you the MAC multicast address as target for the IP unicast address."

[pjbaca777]

I am having the same problem with the flooding of the multicast traffic and

I am using IP.  It seems like the end user router is pruning but i thought the vlan would be doing the

pruning.  any ideas