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
Hi,
I came across the following command as another solution:
ip igmp snooping vlanidstaticmac-addressinterfaceinterface
which seems to have a similar effect to Solution 4: Static multicast entry. And like solution 4, confirmed using show mac-address-table multicast.
I tried it out, but doesnât seem to work. Any ideas re this command?
Thanks,
Sam
Hello Sam
Thatâs an interesting experiment! Letâs take a look at the command you suggested, and compare it to solution 4 to see why this isnât working as you expect.
First, letâs look at solution 4 from the lesson. Itâs the following commands:
SW1(config)#mac address-table static 0100.5e01.0101 vlan 1 interface FastEthernet 0/3 FastEthernet 0/24
SW2(config)#mac address-table static 0100.5e01.0101 vlan 1 interface FastEthernet 0/4
As the lesson states:
The MAC address that you see above matches destination 239.1.1.1.1. SW1 will forward this traffic on its FastEthernet 0/3 and 0/24 interfaces. SW2 will forward it on its FastEthernet 0/4 interface.
Now these commands on switches SW1 and SW2 operate directly at the Layer 2 forwarding level (i.e. MAC address table). This is kind of a âbrute forceâ method that hardwires the switch to forward any frame with that destination L2 multicast MAC only to the specific interfaces. Itâs hardwired and essentially completely bypasses the IGMP snooping process and logic.
Your command with the appropriate MACs and interfaces included is the following:
SW1(config)# ip igmp snooping vlan 1 static mac-address 0100.5e01.0101 interface FastEthernet0/3 FastEthernet0/24
SW2(config)# ip igmp snooping vlan 1 static mac-address 0100.5e01.0101 interface FastEthernet0/4
Now what do these commands do? They create a static entry in the snooping database. Now the next step depends highly on the platform youâre using. I have found that some platforms will actually allow this to work as you expect (Cat 3750/3560 and NX-OS) however other platforms like IOS XE devices still rely on a querier being present to validate the group! Without the querier, the static entry sits in the table, but the ASIC never installs it as a forwarding entry. So you see it in the show ip igmp snooping groups output, but no packets are forwarded. So this command may not work on some no-router topologies because the snooping engine wonât install the entry into hardware unless a querier is present. So the group stays inactive, and no replication occurs. Does that make sense?
Thatâs a nice deep question, though. Itâs an interesting topic to experiment with if you have access to multiple platforms. Thanks for helping me learn something new!
I hope this has been helpful!
Laz
Hi Laz,
Thanks for getting back to me.
Yes, I understand that mac address static entries are pure L2. That part makes sense.
For IGMP snooping, ip igmp snooping vlan static , according to cisco documentation, is also validated using show mac-address-table multicast, but there is no entry, nor is there an entry under show ip igmp snooping groups when I use it, and there is a querier (router) on the network. ip igmp snooping vlan mrouter does seem to work as it is listed when using sh ip igmp snooping mrouter.
I have also noticed that when a receiver joins a group, there is an entry in the snooping table, but multicast traffic is still sent out of all interfaces (I have packet sniffers running).
Iâm using CML and a vIOS switch, maybe its features donât work fully or correctly.
Thanks.
Sam
Hello Samir
Hmm, thatâs interesting. I just labbed it up now and I find that I am able to reproduce your results, and Iâm not sure why. I issue the command and I get this:
SW1(config)#ip igmp snooping vlan 1 static 0100.5e01.0101 interface gigabitEthernet 0/2
SW1(config)#
IGMPSN: mgt: Vlan 1 gce 0100.5e01.0101 add static member port Gi0/2
L2MM: Add member: gda:0100.5e01.0101, adding Gi0/2
IGMPSN: mgt: added port Gi0/2 on gce 0100.5e01.0101, Vlan 1
So it looks like the member is added correctly, but I donât see it in the MAC address table. I am using CML and vIOS as well, so it may be an issue with that. It would be interesting to see this in action on real devices. Iâll talk to @ReneMolenaar to see if he has any insight on this.
Unfortunately, I donât have a definitive answer for you, but as always, I hope this has been helpful!
Laz
Hi Laz,
Yes, its odd.
The other thing I noticed is that the switch canât dynamically learn multicast routers by monitoring PIM Hello packets. So, in situations where I had 2 routers connected to a LAN, one being the Querier and one being the DR, sh ip igmp snooping mrouter would only list the Querier. ip pim snooping commands are not available on it, so maybe thatâs the reason.
Thanks.
Sam
Hello Sam
After chatting with @ReneMolenaar about this one, he suggests using real equipment rather than emulators like CML. It has been found that multicast, and especially IGMP snooping and similar mechanisms, tend to âmisbehaveâ on network emulation platforms. I donât know what equipment you have available, but unfortunately, that seems to be the caseâŚ
However, if you have gone so deep as to explore these concepts to this detail, I believe that your understanding is more than satisfactory!! If you do end up applying it to real equipment, let us know how you get along.
I hope this has been helpful!
Laz
1 Like
Hi,
Am I right in saying that for Solution 1: IGMP snooping querier, the Querier has to be on the same switch as the multicast source? Because if it was on SW2 then the IGMP report sent by a receiver on SW2 wont be forwarded to SW1 and as a result multicast source traffic wont be sent to receivers on SW2.
Am I understanding that correctly?
Thanks.
Sam
Hello Sam
Actually, this is not the case. You can configure the IGMP snooping querier on any switch in the VLAN, including SW2. Multicast will still work correctly.
In a Layer-2-only VLAN without a multicast router, the switches cannot learn multicast groups by default. The IGMP snooping querier feature solves this by sending periodic IGMP General Queries (224.0.0.1). These queries are flooded across the VLAN.
Whenever a switch receives an IGMP General Query on an interface, it marks that interface as an mrouter port. This simply means, âif there is a multicast router or querier, it is reachable in this direction.â
Because of this, when a switch receives IGMP Reports from hosts, it does not flood them everywhere. Instead, it forwards them only out its mrouter ports. This ensures that any multicast router, or in our case, the snooping querier, can receive the Reports if it needs them. Meanwhile, each switch still learns local group memberships and builds its own multicast forwarding table.
So yes, having the querier on SW2 works perfectly fine, and group membership will be learned throughout the VLAN.
I hope this has been helpful!
Laz
Hi Laz,
Thanks for responding.
I understand how membership reports forwarded to the querier combined with IGMP snooping keeps track of where listeners are located, including on neighbouring switches. My understanding was how multicast traffic from the source would reach listeners on other switches if it didnât have a querier on the same switch was what I was confused about, because IGMP snooping would only know about local listeners.
For example, in the diagram below, SW2 is the querier, which means SW1 would only see H1 as a listener on Fa0/3. Whilst SW2 would see H1 on Fa0/24 and H2 on Fa0/4.
However, as you said, SW1 would mark Fa0/24 as an mrouter port and forward traffic from S1 to it, which actually answers my question as to how source traffic makes it to non-local listeners when the querier is not on the same switch. Thatâs the part I didnât figure out.
Thanks very much!
Sam
Hello Sam
Ah, I understand! I probably covered info that you already knew in my post, but I just wanted the info to be complete. But thank you for sharing your thought process, it helps others in the way they read and understand the concepts involved. Always a pleasure!
I hope this has been helpful!
Laz
1 Like