2

With igmp snooping, upon receiving a multicast packet it looks up the table and decides which ports to forward the packet. What I'm wondering is, if there is not an entry in the table for that multicast address, what action should it take?

My initial reaction is the packet should just be dropped because that's the whole point of igmp. However what happens in the situation where the igmp table is full? That will cause certain addresses to not be in the table, at which point I would expect the packet to be flooded to all ports. Is that correct? If the table is full, should it just drop packets that don't match?

  • Welcome to NE, we hope you will both contribute to and learn from this community. It would help if you could specify a vendor/platform. AFAIK, IGMP snooping is not standardized, so the actual implementation may be vendor dependent. – YLearn Feb 27 '18 at 5:36
  • For which switch model? This will depend on the switch model and software version. – Ron Maupin Feb 27 '18 at 5:36
  • Thanks, this is for implementing my own igmp snooper. I'm going off of tools.ietf.org/html/rfc2236 and couldn't see anything mentioned about these situations. So, if there's no real standard for this, the answer is just whatever I think makes sense? – dempzorz Feb 27 '18 at 5:41
  • @dempzorz, in that case, you are free to do what makes sense in your implementation. Ron has pointed out an informational RFC, but that does not define any sort of standard. – YLearn Feb 27 '18 at 6:00
2

RFC 4541, Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches, Section 2.1.2. Data Forwarding Rules places that decision squarely on the switch vendor and network administration:

3) An unregistered packet is defined as an IPv4 multicast packet with a destination address which does not match any of the groups announced in earlier IGMP Membership Reports.

If a switch receives an unregistered packet, it must forward that packet on all ports to which an IGMP router is attached. A switch may default to forwarding unregistered packets on all ports. Switches that do not forward unregistered packets to all ports must include a configuration option to force the flooding of unregistered packets on specified ports.

In an environment where IGMPv3 hosts are mixed with snooping switches that do not yet support IGMPv3, the switch's failure to flood unregistered streams could prevent v3 hosts from receiving their traffic. Alternatively, in environments where the snooping switch supports all of the IGMP versions that are present, flooding unregistered streams may cause IGMP hosts to be overwhelmed by multicast traffic, even to the point of not receiving Queries and failing to issue new membership reports for their own groups.

It is encouraged that snooping switches at least recognize and process IGMPv3 Join Reports, even if this processing is limited to the behavior for IGMPv2 Joins, i.e., is done without considering any additional "include source" or "exclude source" filtering. When IGMPv3 Joins are not recognized, a snooping switch may incorrectly prune off the unregistered data streams for the groups (as noted above); alternatively, it may fail to add in forwarding to any new IGMPv3 hosts if the group has previously been joined as IGMPv2 (because the data stream is seen as already having been registered).

  • Keep in mind that RFC 4541 is an informational RFC, not a standards track RFC. If you are unsure what this means, then RFC1796 may be a useful read, but in essence this means that it does not provide any sort of standard and vendors are not in any way subject to the information provided. – YLearn Feb 27 '18 at 5:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.