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.
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 don’t see the “router interface” in the 239.1.1.1 entry, just the host interface. I also don’t understand the purpose of seeing that interface… why does traffic destined to 239.1.1.1 should be forwarded to the router too? Is it because in scenarios with more than 1 switch connected to each other?
Also, I see always that when a host joins a multicast group, it sends a membership report destined to the multicast IP address of the group that is joining. However, I see that when a second host connected to the same switch joins the same group, the very first time the join report is forwarded to the router. Then IGMP Snooping does its thing an only forwards one report in the "name: of all hosts of the group when the router sends a memebership query. But why is necessary to forward each new join report to the router for the same multicast group ? From my undersatnding, nothing changes on the router. Only the very first host very first report should be the one forwarded to the router, after that there is no need to forward other new joins reports. The switch should be the only one worried about new joins (is this right?) Why does this not happen, and instead all new join reports for the same multicast group are sent to the router too?
Thanks,
Jose
Hmm, that’s interesting. Let’s first look at why the router interface should appear in the port list. In an IGMP snooping-enabled network, multicast routers play a key role in forwarding multicast traffic beyond the local subnet/VLAN. The switch should forward multicast traffic to the router because hosts send IGMP Membership Reports to the router so that it can request the multicast traffic from upstream. the router needs to receive multicast traffic to forward it to other subnets, if required. If multiple switches are involved, the router helps propagate multicast to other segments where there are interested receivers.
Now why isn’t the router port showing up in your port list? There could be several reasons. The fundamental reason is because the switch has not detected a multicast router on any interface. To troubleshoot this, you should check to see that PIM is enabled on the router, and that it is sending IGMP general queries.
Use the show ip igmp snooping mrouter command to see if the router is detected automatically. If not, then check the router’s configuration. Let us know how you get along with your troubleshooting, and if we can be of further help.
I understand your answer, which now makes more sense to me why should I be seeing the router interface in the switch on the Port List for group 239.1.1.1:
the router needs to receive multicast traffic to forward it to other subnets, if required. If multiple switches are involved, the router helps propagate multicast to other segments where there are interested receivers.
However, in my lab the output of the show command doesn’t show what expected. I was wondering if it can be a CML issue, so I pinged from a host connected to SW1 to 239.1.1.1 and I captured traffic on the link between SW1 and Router, and… I saw the traffic!! So it looks like a CML thing to me…
But I still don’t understand my second question:
Also, I see always that when a host joins a multicast group, it sends a membership report destined to the multicast IP address of the group that is joining. However, I see that when a second host connected to the same switch joins the same group, the very first time the join report is forwarded to the router. Then IGMP Snooping does its thing and only forwards one report in the "name: of all hosts of the group when the router sends a memebership query. But why is necessary to forward each new join report to the router for the same multicast group ? From my undersatnding, nothing changes on the router. Only the very first host very first report should be the one forwarded to the router, after that … why do we need to forward other new joins reports?. The switch should be the only one worried about new joins (is this right?) Why does this not happen, and instead all new join reports for the same multicast group are sent to the router too? My understanding was that the router, as long as it receives 1 report for each group, has enough to start fowrading traffic to that group, independently of how many clients join the group later.
Yes I understand your question. If the router port doesn’t appear in the switch, how does the multicast ping reach the router? It may be an issue with CML. The output for certain show commands can be incomplete or inconsistent, but you verified the actual traffic flow with a packet capture, so that’s a good sign that the underlying functionality is correct even if the show commands appear off.
As for your second question, indeed, I didn’t address it in my previous post, I apologize. You’re right that once the router has a single report for a group, it technically doesn’t need more, even if it is the first join report from a particular host.
However, the idea is that the switch is not responsible for tracking the state of the router, or its related timers. So the protocol is designed to be robust and ensures that multicast traffic continues without unnecessary pruning. The designers of IGMP decided that this robustness can be achieved by allowing one more join message (the first of each host) to be shared even when IGMP snooping is on. You can think about it this way, the switch forwards the new join report because it doesn’t know whether the router needs it or not. The router makes that decision.
It would be more efficient if this was not the case, but the level of efficiency is quite small since we’re talking about a single join message from each host. The number of messages is trivial compared to the multicast traffic itself. In any case, it’s a good thought experiment to examine!
Hello Guys.
Talking about “IGMP snooping with L3 aware ASICs”
When you say "
The first entry tells the switch to forward all IGMP traffic with destination 0100.5exx.xxx to the internal interface. This allows the CPU to look at the different IGMP messages.
The second entry tells the switch to forward all non-IGMP traffic with destination 0100.5e01.0101 (group 239.1.1.1) to interface Gi0/1 and Gi0/4.
The switch will now intercept all IGMP messages, they are only sent to the internal interface which puts our switch in total control of all IGMP traffic.
My question is The traffic between R1 and H1 is not IGMP? It looks like H1 want to recive multicast traffic
Other question that I have is
In the section “IGMP Group Leave”
It says “switch will send a general query” why it this happening? What i meant is, on IGMP v2 we saw that the router sends a specific query when he listened a leve message. So, is best no to use switches? cause it looked at backward a general query from the switch. Or the host need to answer two query… one from the switch and other from the router?
Third question
Same section the text says “The IGMP general query is only sent on the Gi0/1 interface and we do this to check if there are any other hosts that are interested in multicast group 239.1.1.1 on this interface.” is possible to have more than one device in one interface?
Multicast MACs are 23-bits long (considering that the first 24 bits are for the 01:00:5E prefix and the 25th bit is reserved) while multicast IPs are 28-bits long (assuming that the first 4 bits are always 1110). This means that there aren’t enough multicast MACs to create a 1:1 mapping, so 1 multicast MAC maps to 32 different IPs instead.
If a switch that is enabled for IGMP-Snooping receives the multicast stream, is it possible that it will also send it towards someone not interested in it? Considering that multiple MC groups can share the same multicast MAC address. Or does it also read the Layer 3 information?
The traffic between R1 and H1 is not IGMP, it is multicast traffic with a destination of 239.1.1.1, and that traffic will match the non-IGMP entry in the MAC address table. That traffic will also be sent to Gi0/4. If the router does send some IGMP message such as a group query, it of course will match the appropriate MAC address entry in the MAC address table, and be forwarded to the INT interface, to be further processed and sent to the appropriate hosts. However, in the specific diagram, the traffic depicted is non-IGMP traffic, but the actual multicast traffic.
Yes, with IGMPv2, the leave group message is sent to the all-routers multicast group (224.0.0.2), and the router responds with a membership query. IGMP Snooping makes the process more efficient by giving intelligence to the switch to deal with such requests on behalf of the router. The group leave message never reaches the router, and it doesn’t have to, because the request was made within the context of the switch. Only if ALL hosts on the switch send a group leave, and there are no more multicast receivers will the switch send a group leave message to the router.
Yes it is, if you have a switch connected to that port, and you have two or more hosts connected to that switch, then you can have two or more devices that may potentially ask for traffic. So if a group leave is sent on Gi0/1, the switch will sent a general query to see if there are any other hosts there that want to receive traffic. If there are, and they respond, then multicast traffic will still be forwarded on that port. Does that make sense?
Yes indeed. A host that is subscribed to 239.1.1.1 may receive traffic for the 239.129.1.1 group, which uses the same multicast MAC address of 01:00:5E:01:01:01. However, this is highly dependant upon the specific switch, platform, and OS that it is running.
Most modern switches will also use their IGMP snooping table as an additional check for the correct forwarding of multicast traffic. The IGMP snooping table is a correspondence between multicast group and switchport. You can view this table like so:
Router# show ip igmp snooping groups
Flags: I -- IGMP snooping, S -- Static, P -- PIM snooping, A -- ASM mode
Vlan Group/source Type Version Port List
-----------------------------------------------------------------------
2 224.1.1.1 I v2 Te7/4 Te5/2 Gi41/1 Gi41/44 Gi51/1 Gi51/44 Te4/2
