Thanks for that, I was speaking to a friend of mine about this and he suggested that the protocol type in the ethernet frame could be used to distinguish between routing protocols multicasts and regular IP multicasts. That seems one of the most logical solutions to me because deep(er) packet inspection on switches would almost certainly be associated with performance degradation. But I've not seen any articles suggesting that snooping does anything but improve performance (by reducing the amount of multicasts). Also, I understand that there may be lots of switches with the capacity to inspect at L3, but the theory also needs to include smaller and older switches because they also support snooping.
Thanks for all the RFCs and Docs supplied. I did not see the answer there as they are more aligned to describing how snooping works rather than identifying legit 'snooping worthy' frames versus other multicast frames such as routing protocols which are bypassed. Regards, Andres On Fri, Oct 11, 2013 at 8:29 AM, Adam Booth <[email protected]> wrote: > RFC4541 section 2.1.2 explains link local multicast data forwarding rules > for IGMP snooping > > Cheers, > Adam Booth > > > On 10 Oct 2013, at 6:28 pm, Matt McAdory <[email protected]> wrote: > > > > There is a problem with mcast MAC collisions. I'd bet that IGMP snooping > > goes further into the frame than you think. Also the 3560 references IPs > > not MACs for group differentiation. > > > > I suspect that your question is answered in the following quote from the > > below doc: > > > > "*The switch supports IP multicast group-based bridging, rather than > > MAC-addressed based groups*. With multicast MAC address-based groups, if > an > > IP address being configured translates (aliases) to a previously > configured > > MAC address or *to any reserved multicast MAC addresses (in the range > > 224.0.0.xxx)*, the command fails. Because the switch uses IP multicast > > groups, there are no address aliasing issues." > > > > I suspect that additional detail is proprietary and may require > Super-duper > > Top-Secret G14 level clearance to get more specifics. > > > > > http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_52_se/configuration/guide/swigmp.html#wp1027678 > > > > MMc > > > > Matt > > > > > > On Wed, Oct 9, 2013 at 11:36 PM, Andres Villalva <[email protected] > >wrote: > > > >> Hi all, > >> > >> I am trying to find out how "IGMP snooping does not constrain Layer 2 > >> multicasts generated by routing protocols." > >> > >> What is the mechanism by which switches are able to say "yes, you are > >> routing traffic - IGMP snooping rules don't apply" given that they are > >> limited to reading L2 headers? > >> > >> I understand the multicast IP to MAC translation but the last 23 bits > of an > >> IP address does not cover the critical first octet (224), hence, in my > eyes > >> the switch still has no way of knowing whether the packet is a routing > >> protocol or not? > >> > >> Thanks for your help, > >> Andres > >> _______________________________________________ > >> For more information regarding industry leading CCIE Lab training, > please > >> visit www.ipexpert.com > >> > >> Are you a CCNP or CCIE and looking for a job? Check out > >> www.PlatinumPlacement.com <http://www.platinumplacement.com/> > >> > >> http://onlinestudylist.com/mailman/listinfo/ccie_rs > > _______________________________________________ > > For more information regarding industry leading CCIE Lab training, > please visit www.ipexpert.com > > > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com <http://www.platinumplacement.com/> > > > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs
