All things related to multicast

[Linda Winkler <>]

At 07:14 PM 2/7/2001, Bill Nickless wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
>
> At 05:27 PM 2/7/2001 -0500, Roy D. Hockett wrote:
> >         Does anyone have a good source of information requarding the
> > deployment
> >of Multicast in enviroments where you have switches that only a portion
> >support CGMP, and the others support IGMP snooping, and get them to
> >interoperate.
> >         Is this an issue, or do I have nothing to be concerned about?
> >         Any pointers would be greatly appreciated.
>
> I can only speak to my experience, and to what I have observed.  I've not
> been able to discover good documentation on the CGMP wire protocol, so my
> suppositions below are based entirely on observation of the behavior I've
> seen and the Cisco documentation.

http://www.cisco.com/warp/public/473/22.html
http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/cgmp_an.htm


> In summary, yes: be very concerned.  We have spent money upgrading switches
> that used to be CGMP-only-capable to be IGMP capable, and moving other
> CGMP-only-capable switches into unicast-only edge applications.
>
> It appears that CGMP is implemented on Ethernet switches by catching
> Ethernet frames with the MAC address 01-00-5e-00-00-01, encapsulating them,
> and sending them by unicast IP to the CGMP router for that
> VLAN.  (01-00-5e-00-00-01 is the MAC address for packets addressed to the
> ALL-SYSTEMS.MCAST.NET multicast group 224.0.0.1, which IGMP uses.)  At the
> CGMP router, the IP packets are decapsulated, and if they are IGMP packets,
> the CGMP router sends instructions back to the Ethernet switches to put in
> appropriate MAC-based forwarding entries in its CAM
> (Content-addressable-memory) table.
>
> Consider these scenarios.  In each scenario, we have a router R, one or two
> switches S0 and S1 (where S0 is doing IGMP snooping and S1 is doing CGMP),
> and hosts H1 and H2.
>
> Scenario 1:    R <--> S0 <--> H1
>                         ^
>                         +----> H2
>
> In this scenario, S0 snoops for IGMP joins from H1, and H2.  When it hears
> an IGMP join from H1, it passes the IGMP join on towards R, and updates its
> internal tables so that the multicast packets are sent to H1.  Likewise, if
> and when H2 transmits an IGMP join, S0 adds H2 to the forwarding list for
> the associated multicast group.
>
> Let's compare that with a CGMP scenario:
>
> Scenario 2:    R <--> S1 <--> H1
>                         ^
>                         +----> H2
>
> The difference here is that S1 doesn't snoop for IGMP packets, it blindly
> encapsulates those packets and forwards the encapsulated IGMP join packets
> to R.  R figures out what to do and instructs S1.  So when H1 sends an IGMP
> join, it gets picked up and encapsulated by S1, send to R, interpreted, and
> instructions are sent back to S1 to add H1 to the forwarding list for the
> associated multicast group.
>
> Packets flow.  So far, so good.
>
> Now let's see what happens when we have both switches involved.
>
> Scenario 3:    R <--> S1 <--> S0 <--> H1
>                         ^
>                         +------------> H2
>
> H1 transmits an IGMP join.  S0 picks up the IGMP join and encapsulates it
> and sends it to R.  R interprets the join and sends instructions to S0 to
> add H1 to the forwarding list for the associated multicast group.
>
> The problem here is that S1 has NOT received an IGMP join on its port
> connected to S0.  Therefore, S1 will NOT add that port to its forwarding
> list. Thus, S0 will not get any packets to forward on to H1.  H1 loses, and
> never gets any packets on the multicast group from the router R.  In fact,
> H1 won't even get any packets from H2 on that multicast group.  Moving H1
> to an S1 port will instantly solve the problem.  Replacing S0 with a switch
> that does IGMP snooping will also solve the problem.
>
> My recommendation is to not mix CGMP-running switches and IGMP-snooping
> switches within a broadcast domain (VLAN).
> ===
> Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
> PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
>
> iQCVAwUBOoHy/Kwgm7ipJDXBAQHKFAP/RtLkc8g8brpKr1PWxgUOskIu04/VBk/o
> zYYKeF+i/Eo/amfOfVX+/qskRwr0slNAl/gVVUeYB9bJ9VwfoMHnygGFrB7oQIfL
> JkB336SgFlKhgRtT11Kk08uxsZyxxFq5+Qo8YkxZPy5ypwKzvh4Y/jvxUi05ff1I
> aqebGFC9cvk=
> =0dbj
> -----END PGP SIGNATURE-----