All things related to multicast

[Toerless Eckert <>]

> 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.

ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt

> 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.

Was that with Cisco switches supporting IGMP Snooping or non-Cisco IGMP
Snooping switches ?

> 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.

CGMP switches do not do this. The whole premise of CGMP is that the
switches hardware is low-end, so it can not distinguish IGMP membership
reports sent do a multicast group from te actual multicast traffic sent
to the same group. To be able for the switch CPU to process IGMP packets
to a multicast group it would need to receive at that CPU all data packets
for the group too, overloading the switch. CGMP switches pass through IGMP
packets unchanged, except for IGMP v2 leave messages to 224.0.0.2, which
it actually intercept (see the spec).

Actually, the IGMP v2 leave proceessing is by default disabled because
of a minor conflict with HSRP. YOu have to explicitly configure it on
CGMP switches.

> My recommendation is to not mix CGMP-running switches and IGMP-snooping 
> switches within a broadcast domain (VLAN).

Any more specific example of things going wrong ?

Cheers
        Toerless