IGMP Snooping

[lagapidis (Lazarus Agapidis)]

Hello David

@davidilles

Why is the term “L3-aware ASIC” specifically mentioned here? L3 means that the ASIC can also make routing decisions, correct? However, after viewing these two sections, I don’t see any routing mentioned at all, so what does the term “L3-aware ASIC” have to do with IGMP Snooping in this case?

You are correct in that L3-Aware ASICs can make routing decisions. However, in the context of IGMP Snooping, it’s not about routing, but about the ability of the ASIC to understand and process Layer 3 information. Although IGMP is used to help switches (inherently L2 devices) decide on which ports multicast traffic should be forwarded, IGMP also includes Layer 3 information such as the multicast group addresses. Indeed, IGMP is considered a Layer 3 protocol, so a switch that supports IGMP Snooping must have an ASIC that can process Layer 3 information. Even if the switch isn’t performing routing, it still needs to process IGMP packets, which are Layer 3.

@davidilles

So what’s up with the MAC address table? I don’t think I quite understand what it says.

Putting aside the CAM table as it is displayed in the diagram, when using L3-aware ASICs, the additional capability that is being added is that the ASICs themselves are capable of differentiating between IGMP and non-IGMP messages. This is done not just by the MAC address (which is L2) but by examining the contents of the Layer 3 part of the IGMP message (that’s where the L3-aware part comes in). Non-IGMP traffic (i.e., multicast traffic) are forwarded directly to the intended host while IGMP messages are sent to the CPU.

Now the depiction of the MAC address table may be somewhat confusing because you won’t actually see such this specific information in the entries in a real CAM table. What is being described here is that any IGMP packet (which will have a MAC address of 0100.5EXX.XXXX by definition) will be directed to the INT interface, i.e. the CPU. Remember IGMP packets here are not identified just by the MAC address, but by additional intelligence that detects them and deals with them accordingly.

The second entry says that non-IGMP traffic with a MAC address of 0100.5E01.0101 which is the actual multicast traffic with a destination IP of 239.1.1.1 (as defined by the multicast IP to multicast MAC address mapping process) will be forwarded directly to the appropriate ports corresponding to the hosts that have asked for it, completely bypassing the CPU. Does that make sense?

So it may be worth redesigning this diagram to ensure that the CAM table is not just hanging off of the CPU, but it is information that the ASICs themselves have. I will talk to Rene to see if this can be clarified.

I hope this has been helpful!

Laz