[c-nsp] Effect of IGMP version on IGMP Snooping

John Neiberger jneiberger at gmail.com
Tue Jan 25 10:51:03 EST 2011


On Mon, Jan 24, 2011 at 10:58 PM, Aaron Riemer <ariemer at amnet.net.au> wrote:
> I would get wireshark running on one of the hosts that tries to join a
> multicast stream. Set IGMPv3 on the switch and monitor the subsequent IGMP
> packets. i.e. Does an IGMPv3 query get sent out and do the hosts reply with
> a join?
>
> I would assume that swapping from IGMPv2 to IGMPv3 would clear out any
> snooping information on the switch and thus would need to wait for
> subsequent queries / membership reports?

That was my thought, too, but we're going to have to run the test
again to verify that.

This part of the network has some interesting qualities that are
making it difficult to predict how it's supposed to behave. For
example, this is a single VLAN with two switches. Each switch has an
vlan1 with an IP address configured, but ip routing is disabled on
both switches. Interestingly, PIM is enabled on those interfaces and
the two switches see each other as PIM neighbors. However, I don't
think PIM is actually doing anything because there are no actual
routed interfaces involved.

Here's where it gets strange. Since there are no interfaces
functioning as a router, there is no IGMP querier unless we manually
create one. However, it appears that by enabling PIM on the L3 vlan
interfaces, a querier was enabled automatically, as well. So it seems
that PIMs only function at the moment is to enable the querier, which
is enabling snooping to work.

We're changing the IGMP version on the L3 vlan interface, but since
that isn't acting as a router, at least for unicast, I'm not sure why
it even matters.

This is all really complicated and difficult to explain without a good
diagram. lol  But it is strange behavior. I'm tempted to just enable
unicast routing so that those vlan interfaces are unequivocally router
interfaces. Then I could turn PIM off since it isn't doing anything
but turning on the querier. That would make the behavior a bit more
predictable.


More information about the cisco-nsp mailing list