Multicast traffic stops flowing after some time when using IGMP snooping

[omerar123]

Hi all,

I have the following setup:

                                                     :  

Where Host 1 is a multicast traffic source, and Host 2 is a multicast traffic client. IGMP snooping is configured on both switches. 
Host 2 boots and sends an IGMP report, in order to join Host 1's multicast group. Since SW2 does not know where the mrouter of the group, it adds port Eth1/1 to the snooping group, and discards the packet the IGMP packet. Once Host 1 boots, it sends an IGMP query (which is flooded over the port channel), and multicast traffic starts flowing to Host 2.
When i ran "show ip igmo snooping groups" I saw the same output on both switches: On both switches the groups contained both Eth1/1 and the port channel, but after a while, the switch connected to Host 2 removed the port channel from the group.
After viewing the switch logs and sniffing the traffic on one of the port channel interfaces on SW1, i got to the conclusion that it happens since SW1 stops sending the queries generated by Host 1, and rather answers them locally (some proxy or something). I also noticed that IGMP reports generated by Host 2 stop arriving on SW1 (since SW2 does not know it has an mrouter connected to the other side of the port channel anymore).

My questions are:

1. How does SW1 know it should keep the port channel as part of the group, if it does not hear IGMP reports coming from SW2 anymore?

2. What happens if Host 2 is not interested in the multicast traffic anymore, but does not send and IGMP leave message (a behavior which is supported according to the protocol, to my knowledge)? how does SW1 know it should stop answer the IGMP queries sent by Host 1?

Thanks in advance,

Omer.

[Philip D'Ath]

I think SW1 sends regular queries to verify port membership.  It it doesn't get a response it drops the port from the group.

Search this link for "membership query" for more info.

https://tools.ietf.org/html/rfc2236

Are you using a modern version of IGMP, like V3?

[Hythim Ali El Hadad]

Hi,

This discussion is great and is very similar to a problem happen with me

I have Microsoft nlb for exchange installed on UCS

the fabric interconnect is in end host mode and connected to Nexus 5548 as layer 3 switch

We configured nlb to use multicast and it produce mac address start with 03xx not IANA standard

we can ping the nlb address from the same vlan only

So I configured static ARP on the nexus for this mac with the nlb ip addres to be reachable from all the network and all is working fine

But the problem is that after few hours [I'm not sure when]. The nlb become not pingable and the exchange become not reachable

I try to ping the nlb from the same vlan but fail.

The issue is solved after resetting nlb server [exchange server] and then after some time the problem happen again and so on.

I see you say that resetting the multicast source will regenerate igmp queries again so I do understand this.

I think configuring PIM won't help on the nexus as this isn't igmp multicast. we are using option multicast only on nlb. [the mac is 03xx not 01xx]

and nexus 5548 not accepting to configure igmp querier on it.

So please suggest me hot to go:

1- Do I need the igmp snooping querier on all L2 switches and not on the nexus 5500 ?

So the querier will always flow through the network but I think Nexus 5500 should be configured with that also to continue sending the queries

2- Is there a time out that I can disable to let the source always to send igmp queries ?

3- we can't ping from the same vlan from server on the UCS also. So do you think at this time nexus 5500 don't know about the source [nlb] ?

Thanks

[Madhukrishnan Gopinathan Nair · Accepted solution]

Hi,

The problem is because you do not have mrouter port sw1. This is well documented under 

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/68131-cat-multicast-prob.html

There are 3 ways you can solve this.

1. Enable Pim on Sw1.

Or

2. Enable ip igmp snooping querier on Sw2

Or 

3. Create staitc mrouter port on sw2.

ip igmp snooping vlan 1 mrouter interface PoX

[Madhukrishnan Gopinathan Nair]

Hope the above helps you.

Thanks,

Madhu

[omerar123]

Hi,

Thanks for the answer, I know that IGMP snooping querier can solve it, but i am more interested in the answers for the two questions i asked above:

1. How does SW1 know it should keep the port channel as part of the group, if it does not hear IGMP reports coming from SW2 anymore?

2. What happens if Host 2 is not interested in the multicast traffic anymore, but does not send and IGMP leave message (a behavior which is supported according to the protocol, to my knowledge)? how does SW1 know it should stop answer the IGMP queries sent by Host 1?

Would really appreciate it if you could answer these.

Thanks a lot,

Omer. 

[Jon Marshall]

1) it doesn't

2) not sure I follow. Hosts do not normally send IGMP queries, that is what your network devices do.

Jon

[omerar123]

Hi,

Host 1 sends both the multicast traffic and the IGMP queries, i.e. it is both the mrouter and the multicast traffic source. to my understanding, this should not affect the switch behavior.

Thanks,

Omer.

[Jon Marshall]

It shouldn't but it obviously is in your setup.

The IGMP query the host sends should be sent to both switches assuming both hosts are in the same vlan.

Jon

[omerar123]

of course it should, but fact is that SW1 forwards it to SW2 only once, and then starts answering host 1's queries with a proxy reports. This is not specific to my setup,I saw it happening on other setups as well. Seems like some optimization the switch performs.

[Jon Marshall]

I can't see how that is an optimisation as it breaks multicast.

SW1 should not be answering on behalf of SW2 because it does not know whether the host on SW2 wants the stream or not.

The IGMP query needs to go to SW2 otherwise it will obviously eventually remove then port channel interface from the multicast group.

I know you realise all of this :)

What switches were in the other setups you saw ?

Jon

[Madhukrishnan Gopinathan Nair]

First one answered by John.

I guess 2nd question is not clear. If Host 2 does not want traffic any more it will send a IGMP leave message. However Host 1 does not send any IGMP query (Thats switch duty to send it)

In the working scenario (I mentioned the scenarios you can make it work ), irrespective of host 2 send a join/leave the traffic will be always forwarded to switch2(since Po will be an mrouter port for Sw1.)

Madhu.

[omerar123]

AFAIK, according to the RFC, a host does not have to send and IGMP leave when it is not interested in receiving the multicast traffic anymore. moreover, since SW1 stops forwarding the IGMP queries generated by Host 1 down to SW2, SW2 "forgets" where the router port is, and i am not sure it will even forward an IGMP leave packet, even if one was sent by Host 2.

[omerar123]

Hi,

I tried the second option (configuring IGMP snooping querier), and it worked for some time, but then the querier timer expired and the multicast traffic stopped again.

is there any way to disable the timeout for the querier? did i do something wrong?

Thanks,

Omer.