Thanks so much for your answers!! The value of this learning for me is incalculable!!!
Jose
1 Like
Hello Laz,
I have several questions regarding IGMP snooping and also how a switch would forward multicast frames within a L2 network/VLAN in general.
I understand that without IGMP snooping being properly enabled, a switch would treat all multicast frames as broadcast frames and flood them within whatever VLAN those multicast frames originated on. I understand this happens due to the fact that a switch uses its MAC address table to forward frames within a L2 segment/VLAN, and since a multicast MAC address would never be the source MAC address of any incoming frames, switches would not be able to populate their MAC address table with any multicast entries. This results in any received multicast frames being flooded within the VLAN/broadcast domain that these multicast frames originated on.
- When we enable IGMP snooping on a particular VLAN, and the switch is forwarding multicast frames between sources and receivers on that same VLAN/L2 segment, would the MAC address table still be involved? My understanding is that switches (Layer 2 and Multi-Layer switches) always use the MAC address table when forwarding frames within the same VLAN, but on the lessons I have seen regarding this topic we always look at the IGMP snooping group table (sh ip igmp snooping group) to see how the switch is forwarding multicast frames within a particular VLAN instead of the MAC address table. So, does IGMP snooping being enabled not add any multicast entries on the MAC address table so that a switch can forward those multicast frames within the same L2 segment? In live networks, I have always seen the snooping group table be populated with plenty of entries while the MAC address table remains empty of any multicast entries. I understand that we populate the MAC address table by looking at the source MAC of a frame, and the source MAC of a frame would never be a multicast one, but wouldnt IGMP snooping be able to add multicast entries to the MAC table? I have observed this behavior mostly on C9200, C9300, and C9500 Cisco switches. Maybe there are some versions of IOS and different switch models that do indeed populate the MAC table with multicast entries after enabling IGMP snooping. On the lesson previous to this one, it is mentioned that âWhen the host sends a membership report for a multicast group then the switch adds an entry in the CAM table for the interface that is connected to the hostâ, I have also found this cisco community post that comes close to answering my question:
-
Would a switch always flood multicast traffic destined for the 224.0.0.0/24 range? In other words, if a multicast packet has a destination IP address in the 224.0.0.0/24 range, and we encapsulate that packet into a multicast frame with the appropriate multicast destination MAC address, would a switch with IGMP snooping enabled still flood those frames within the VLAN they originated on? My understanding is that the link local multicast range will always be flooded regardless of snooping or not, and im assuming this happens because hosts would never send any membership reports for any of the groups in this range. My understanding is that the only way to counter this behavior is to filter unregistered multicast traffic, which brings me to my next question.
-
Unregistered/unknown multicast traffic is just multicast traffic that doesnt have an entry on a snooping table correct? which results in the switch flooding those frames within the VLAN they originated on since it does not know what to do with them. For example, if we connect a multicast source to some VLAN, and it starts transmitting without any receivers sending any membership reports for that specific group, then the switch would not have an entry on its snooping table and thus would flood the multicast traffic coming from that source within that VLAN correct? Can we filter any unknown multicast traffic by applying the âswitchport block multicastâ command to a particular switchport?
Thank You Laz!
Hello Paul
I will address each of your questions as best I can.
No, IGMP snooping does not populate the MAC address table with multicast group addresses. Instead, the switch maintains a separate IGMP snooping table for forwarding decisions. Why? Because the MAC address table is populated based on source MACs, and multicast group addresses are never source addresses.
When IGMP snooping is enabled,t he switch listens to IGMP messages (like Membership Reports) to build a multicast forwarding table (not the MAC address table). This table maps multicast groups to ports (where receivers are located). This table is separate from the MAC address table, and it overrides default flooding behavior.
Now, concerning the quote from the IGMP Snooping lesson you mention, this may need a bit of clarification. On some older Catalyst and non-IOS-XE platforms (such as the 2950 switch mentioned in the Cisco Community post), enabling IGMP snooping may lead to multicast group MACs being inserted into the MAC address table, associating them with ports with subscribed hosts. However, modern switches do not do so. They handle multicast forwarding using a separate multicast group table. I will let Rene know to consider making the clarification in the lesson.
Yes, multicast traffic with destination IPs in the 224.0.0.0/24 range (known as the link-local scope) is always flooded by Layer 2 switches within the VLAN, even if IGMP snooping is enabled. This is because the 224.0.0.0/24 range is reserved for protocol control traffic that must always reach all nodes on the local subnet. These packets will map to multicast MAC addresses in the form of 01:00:5e:00:00:xx which when seen by a switch, will be flooded.
Yes, youâre largely correct in your understanding. Unregistered (or unknown) multicast traffic refers to multicast traffic for which the switch has no entry in its IGMP snooping table. That is, no hosts have sent IGMP membership reports for that multicast group. It has no forwarding constraints, so it floods the traffic to all ports in the VLAN (except the one it arrived on and known router ports).
Not exactly. The switchport block multicast command is misleadingly named. Hereâs what it really does: It prevents unknown destination multicast frames from being egressed on that port. More info can be found here:
I hope this has been helpful!
Laz
Thank You for the responses Laz. As it pertains to my first question, I have a few follow up questions to ensure my understanding is correct.
-
Given that modern switches do not use their MAC address table to forward multicast frames within the same VLAN, when a switch with IGMP snooping enabled receives a multicast frame, it would then perform a lookup on the snooping forwarding table, shown by the command âsh ip igmp snooping groupâ. It seems to me that in order to do this, a Layer 2 or Multi Layer switch would need to look inside the multicast frame in order to examine the destination IP of the multicast packet, since the snooping table contains multicast group IP addresses alongside whichever switchports have receivers that are interested in that traffic. When a match is found for that destination IP on our multicast packet, the switch simply forwards that traffic out of the relevant switchports that have receivers that sent an IGMP membership report for that specific multicast group. If no entry is found for a multicast packet on the table, the multicast frame is just flooded within that specific VLAN the frame originated on. Is this description correct?
-
Above, you mentioned that âThese packets will map to multicast MAC addresses in the form of 01:00:5e:00:00:xx which when seen by a switch, will be flooded.â in regards to multicast packets destined to the multicast link local scope. My doubt with regards to this statement is that we have established that a switch will not look in its MAC address table when forwarding multicast frames when snooping is enabled. So how can a switch look at that multicast MAC address (01:00:5e:00:00:xx ) in order to make a forwarding decision if the snooping table does not contain any MAC addresses? Would modern switches still look at the destination MAC address of those multicast frames then even if the CAM table is not involved in the forwarding decision?
-
This is more of a fundamentals question. My understanding is that within a specific L2 segment or VLAN, we forward frames in order to transmit data between hosts that are connected on that same broadcast domain/VLAN. The frames being forwarded typically have IP packets encapsulated inside of them, so that those packets can reach their destinations. Since we use frames to communicate within a L2 segment/VLAN/broadcast domain, no frames ever leave whatever L2 segment/VLAN/broadcast domain that they originate on. When we configure a VLAN on a switch, since VLANs implement segmentation at L2, a switch only forwards frames within whatever VLAN the frames originate on. For example, if a switch receives an untagged frame on an access port on VLAN 300, then the switch would only ever forward that frame out of other access ports on that same VLAN or any trunk ports allowing traffic for that specific VLAN. When devices on separate VLANs/L2 segments want to communicate with eachother, they encapsulate whatever IP packet they are sending into a frame with the destination MAC address of their configured gateway. That frame is forwarded within that specific L2 segment towards the gateways interface that is connected on the same broadcast domain. Since the frame is only forwarded within that VLAN, the router would strip the frame and create a new frame to carry the packet after it makes its routing decision and determines the egress interface it needs to use to get the packet to its destination. Is my understanding correct? It seems to me that during the whole frame forwarding process within a VLAN on a switch, the destination MAC address of a frame is only checked against the MAC address table whenever its a unicast frame. Most switching lessons simply state a switch is forwarding frames with its MAC address table, but no distinction is made about whether its the same process for multicast/broadcast/unicast frames. Another source that led to my questions in this topic is that, atleast for forwarding unicast frames, a switch would typically not need to look inside the ethernet header to make any forwarding decisions between hosts on the same VLAN. The hosts would just ARP for eachothers MACs, and use their ARP cache to send frames to eachother, in which case the switch would just forward the frames using its CAM table since were just forwarding at L2 and thats about it. But for multicast and IGMP snooping enabled, the switch is looking inside the frame and making a forwarding decision based on the destination multicast IP address of that packet and its snooping table even when just forwarding between sources and listeners on the same VLAN, and that caused some confusion since I thought all forwarding that a switch does within a L2 segment would be done based on the destination MAC address of a frame.
-
So, if i were to configure the switchport block multicast on a specific switchport, and the switch receives a multicast frame carrying a multicast packet with a destination IP that is not in the snooping table, or is in the link local scope, the switch would not forward those frames out of the port with that command configured correct?
Thank You Laz!
Hello Paul
Question 1
Yes, that is correct. Modern switches with IGMP snooping look inside multicast packets to examine the destination IP address, match it against the IGMP snooping table, and selectively forward the packet only to ports with interested receivers. If no match, the switch floods the packet within the VLAN.
Question 2
Specifically, my statement was:
This pertains specifically to the 224.0.0.0/24 subnet, which is the link local multicast scope. Although modern switches do not use the MAC table to forward multicast traffic when IGMP snooping is enabled, they still look at the destination MAC address field. If it is a unicast address, the MAC address table is used. If it is a multicast address, then the frame is decapsualted further to determine the destination multicast IP address and the IGMP snooping table is used. If however, the MAC address destination is of the form 01:00:5e:00:00:xx, it corresponds to the link local subnet which is always flooded. Now I am not sure if a switch will see the 01:00:5e:00:00:xx and automatically floods the frame, or if it decapsulates to the IP header to see the 224.0.0.0/24 network and then floods it. This depends on the internal algorithms of the switch itself, but the behavior is the same. Does that make sense?
Question 3
Your understanding is excellent. Your description of what happens for inter-VLAN communication is spot on. Indeed, the destination MAC is examined, and what happens next depends on what type of MAC address it is.
But in order for a switch to look up the MAC address in the CAM table, it must read the destination MAC from the header of the Ethernet frame. What happens with ARP happens at the host, but the MAC address table lookup takes place at the switch⌠these are two separate mechanisms.
Question 4
Yes thatâs right, but it will still receive known IGMP groups.
I hope this has been helpful!
Laz