At 06:18 AM 2/2/02, Nigel Taylor wrote: >Even in an design where the host and the server reside on the same >VLAN(segment) IGMP and CGMP still provide the ability to control flooding >of multicast traffic. Specifically, when the host multicasts the IGMP >membership report to the group with the address 224.1.2.3(MAC >0x0100.5E01.0203) and there's no existing mapping in its CAM table, the >switch will flood the report on all ports in the VLAN.
It's not the membership reports we're concerned about. It's the multicast traffic from the source multicast server. The question can be boiled down to this: When you enable CGMP does that mean the switch automatically stops flooding multicast traffic to all devices in the VLAN? Does the switch instead wait for the recipients to send their membership reports, which go to the router and then get converted into CGMP messages from the router to the switch? Only devices that have sent the membership report can receive the traffic. (There could be a problem if it works this way. The multicast server could start sending before anyone joined.) The question is not about basic IGMP and CGMP behavior. The question has to do with switch behavior in the special case where the source of the multicast traffic is on the same switch and in the same VLAN as the recipients. We're concerned because that sounds like it would cause normal multicast flooding to kick in. For that not to happen, the switch must be smarter than we're thinking. >However, any futher >attempts to join that existing group would then be limited to port listed in >the CAM table that are eligible to recieve the multicast traffic for the >group. Once again we're not talking about the membership reports (joins), although what you say is probably true. I wonder if what's also true is that the first membership report causes the switch to then not forward the server's multicast traffic to any devices not listed in the port list in the CAM table for the multicast address. That would make sense. Devices have to send their joins in order to get on the list and get the traffic. > Chptr 14, pgs 412-442 of Beau Williamson's book Developing IP >Multicast Network provides some really good info on this issue. I couldn't find an answer to our question. Maybe you could?? Thanks. And to add to the question.... I've been wondering about more ordinary multicasts, like OSPF Hellos and even BPDUs. If you enabled CGMP, would these not get sent to any devices that didn't implement IGMP and sent their membership report? That seems kind of ugly. Maybe it's not an issue because you would only use CGMP on the edge in switches that connect end devices. Priscilla >The author >does note that flat switched LAN designs will present major problems in >gaining/maintaining control of multicast flooding. > >I guess this really comes down to the network design as with every other >aspect of building a scalable and efficient network. > >Thoughts.. Anyone! > >Nigel > > > > > > At 09:28 PM 2/1/02, Nigel Taylor wrote: > > >Priscilla, > > > You are correct. Thanks for the added insight. > > > > > >Nigel > > > > You are nice to say this, but you know what I realized?! My answer doesn't > > resolve the quandary either! ;-) > > > > I now think that Fears' real fears had to do with the recipients and the > > server being on the same VLAN. This might cause the switch to forward the > > multicast traffic before it even checks the results of CGMP. The switch >may > > do its default multicast flooding to ports in a VLAN and just make use of > > CGMP to learn about other ports. Am I making any sense? It's late. ;-) > > > > My guess it that the answer is still that CGMP is smart. Once you >configure > > it, the switch knows to not do its normal multicast flooding and instead > > wait to hear from the router regarding which ports should receive the > > multicast flow. Hopefully someone can confirm that. > > > > Priscilla > > > > > > >----- Original Message ----- > > >From: "Priscilla Oppenheimer" > > >To: > > >Sent: Friday, February 01, 2002 2:03 PM > > >Subject: Re: multicast / CGMP towards the multicast server [7:33964] > > > > > > > > > > No offence, but that answer doesn't remove the quandary. The entire > > switch > > > > is a segment from the router's point of view. The router receives the > > IGMP > > > > Join and now knows that packets for that multicast group must be sent >out > > > > that interface to that Ethernet segment. All devices on the switch are > > out > > > > that interface, however. > > > > > > > > What Fears fears is that the router won't be smart enough to tell the > > > > switch that not all devices connected to the switch should receive the > > > > multicast stream. > > > > > > > > But fear not, Fears. CGMP is smarter than you might think. Here's how >I > > > > understand it. Correct me if I'm wrong, please (anyone). > > > > > > > > As you know, when a host wants to join an IP multicast group, it sends >an > > > > IGMP Join message. The Join specifies the host's MAC address and the >IP > > > > multicast group that it wants to join. > > > > > > > > When a router receives the IGMP Join, it creates a CGMP message that > > > > contains the MAC address of the host and the multicast group address. >The > > > > router sends the CGMP message to a well-known address that all >switches > > > > listen to. When a Catalyst switch receives the CGMP message from the > > > > router, the supervisor engine responds by modifying the forwarding >table > > > > automatically. In other words, it now knows the specific port that >must > > > > receive the multicast stream. Other hosts on different ports may Join > > >also, > > > > and the switch will add them to the table. > > > > > > > > This is different from IGMP Snooping, by the way. From what I >understand, > > > > IGMP Snooping allows the switch to proactively snoop into IGMP packets > > and > > > > figure out which ones are Joins. IGMP Snooping requires more powerful > > (and > > > > more expensive) switching hardware (firmware). > > > > > > > > Priscilla > > > > > > > > At 10:18 PM 1/31/02, Nigel Taylor wrote: > > > > >Michael, > > > > > Of course this would depend on if the multicast server >and > > >the > > > > >host connected on the same switch was assigned to the same > > vlan(broadcast > > > > >domain). Just some quick points to mention.. > > > > > > > > > >Routers by default will not forward multicast traffic. However, if >you > > > > >enabled a multicast routing protocol(PIM, DVMRP) then this is >possible. > > >The > > > > >important thing here is that IGMP is used by hosts to inform routers >of > > > > >their intent to become part of a multicast stream. This depends on >your > > > > >implementation of the multicast protocol. IGMPv2 has been improved >to > > > > >support leaves from a multicast group which is not supported in >IGMPv1. > > > > >This way the host is able to notify the source of it's intent to >leave > > >the > > > > >multicast group. This is will allow the routers to prune the >multicast > > > > >traffic from the segment removing the unnecessary traffic, providing >no > > > > >other host on the segment remains a member of the multicast stream > > > > > > > > > >A good title as recommended by a number of folks on the list is > > >Developing > > > > >IP Multicast Networks > > > > >Author: Beau Williamson. ISBN: 157870779 > > > > > > > > > >HTH > > > > > > > > > >Nigel > > > > > > > > > > > > > > > > > > > >---- Original Message ----- > > > > >From: "Fears Michael S SSgt 50 CS/SCBBN" > > > > >To: > > > > >Sent: Thursday, January 31, 2002 4:59 PM > > > > >Subject: multicast / CGMP towards the multicast server [7:33964] > > > > > > > > > > > > > > > > If a multicast server is connected to a Cisco Switch running CGMP, > > and > > > > > > several hosts are connected to the same switch, will a router turn > > off > > > > the > > > > > > switch ports for the users that are not requesting the multicast? > > > > > > > > > > > > So, will CGMP work back towards the multicast server? > > > > > > > > > > > > Fears > > > > ________________________ > > > > > > > > Priscilla Oppenheimer > > > > http://www.priscilla.com > > ________________________ > > > > Priscilla Oppenheimer > > http://www.priscilla.com ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=34224&t=33964 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
