Hi Andres, The Protocol type field (More commonly known as Ethertype) of an Ethernet frame for a routing protocol (for example EIGRP) & for an IGMP packet will be same (provided we are referring to IPv4 in both the cases). The Ether Type defines what next header is going to be & in both the cases it has to be an IPv4 packet.
There is no parameter in the Ethernet frame itself using which a switch, with IGMP snooping enabled, can distinguish between an IGMP packet & Routing Protocol hello packet!! This is the reason why the RFC mentions: (Request for Comments: 4541) In recent years, a number of commercial vendors have introduced products described as "IGMP snooping switches" to the market. These devices do not adhere to the conceptual model that provides the strict separation of functionality between different communications layers in the ISO model, and instead utilize information in the upper level protocol headers as factors to be considered in processing at the lower levels. As the name suggests this feature will do snooping on IGMP packets. How will the switch know that it is an IGMP packet?? The answer is by looking into the IP packet header. In the IP header there is a PROTOCOL field which mentions what the next header will be. For EIGRP this value would be 88, For IGMP this value would be 2. So this is one field that switch needs to look at before performing IGMP snooping. Now as far as implementation by a vendor is concerned we can simply say that for 224.0.0.0/24 group do no use IGMP snooping at all. This is the range that any of the routing protocols will use! In IGMPv2 the group memberships reports are sent to the Multicast address that is being reported. This has to be different from 224.0.0.0/24. I am not sure how different vendors would implement it, however, the switch needs to inspect the packet, beyond the layer 2 header. Hope this helps!! Thanks, Naren ________________________________ From: Andres Villalva <[email protected]> To: Adam Booth <[email protected]> Cc: CCIE OSL <[email protected]> Sent: Friday, 11 October 2013 5:48 AM Subject: Re: [OSL | CCIE_RS] IGMP Snooping and Routing Protocols 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 _______________________________________________ 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
