[c-nsp] IGMP differences between c3560 & c4948 - Update!

[Mark Tinka]

On Saturday 10 April 2010 05:31:23 pm vince anton wrote:

> ive been doing some work in the lab with igmp and pim on
>  3560 and 4948 and they seemed to behave differently. 
>  i'd like to see if anyone on the list has had similar
>  experiences or if im getting something wrong, or hitting
>  any bugs.

Don't mean to resurrect an old thread, but just wanted to 
report that we experienced a similar issue.

Previous Catalyst switch was unable to stop flooding to the 
VLAN that the receivers + Multicast router live in. The 
workaround was to stop attaching joins to the IGMP instance, 
let the STB boot up, and then add the rest of the joins. Of 
course, this doesn't survive STB reboots, as IGMP Snooping 
mechanisms cease to function once the switch does not have 
any group membership information, and the flooding resumes.

Switching (no pun intended) to a Cisco 3750ME running IOS 
12.2(54)SE does wonders! Without any additional 
configuration (apart from defining the upstream Multicast 
router), unregistered traffic is not flooded to all ports in 
the VLAN by default. Traffic only goes down the port after 
the STB sends a membership report.

This behaviour would seem inconsistent among Catalyst 
platforms, based on this thread as well as other research 
I've done.

The other question will be whether future IOS upgrades 
change behaviour, for better or worse. 

On the other hand, RFC 4541 is clear on flooding of 
unregistered traffic as being normal. In this instance, and 
for IPTv applications, going against the RFC (either with a 
command or as default with a reversing command) would be in 
favour with me. Not all STB's ship with Gig-E ports, and 
even if they did, it still wouldn't be ideal.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20100503/50d23906/attachment.bin>