Hi,
Consider the following topology:
Imagine a scenario on which I have my senders and receivers all connected to the access switch marked with the red circle. There are no, senders or receivers running on other devices, so no requirement to send multicast traffic through uplink.
For this hypothetical scenario, do I still need to use an IGMP querier on the access switch? Or just IGMP Snooping will be enough?
Hello Robson
For the topology you shared, the primary concern is to ensure efficient multicast traffic delivery within the Access Switch stack indicated with a red circle since all the senders and receivers are connected to this switch stack and you donât need multicast traffic to travel through the uplink.
Here;s a description of what each IGMP feature will deliver:
IGMP Snooping:
IGMP Querier:
For your described scenario:
If you have only IGMP Snooping enabled without an IGMP Querier: Initially, when the hosts on the red circle Access Switch join a multicast group, theyâll send IGMP join messages. The switch will snoop these messages and begin forwarding multicast traffic to those ports. But without regular IGMP queries, the snooping table might not get refreshed, and thereâs a risk that multicast traffic could be interrupted if thereâs a long period without hosts sending IGMP reports.
If you have both IGMP Snooping and an IGMP Querier enabled: The IGMP Querier will periodically send out queries, prompting hosts to renew their group memberships. This ensures that the multicast forwarding table in the switch remains accurate, guaranteeing the continuous flow of multicast traffic to interested hosts.
So, optimally, you would want to enable both IGMP Snooping and have an IGMP Querier on the red circle Access Switch. However, if youâre certain that the hosts will always send regular IGMP reports (or if the risk of traffic interruption is acceptable in your use case), you might get by with only IGMP Snooping.
However, if your core switch is a Layer 3 switch (which it should ideally be), then you can do away with creating an IGMP querier on the switch, and have the ârouterâ of the core switch play that role. This would be the ideal case.
I hope this has been helpful!
Laz
As I understand all the multicast data is also send to the querier, this could be a switch or router. What is the purpose of this behaviour? Wouldnât it be more efficient if the querier only gets the IGMP-data and sends a join message if itâs wants to receive the multicast data?
I heard that Netgear as an updated IGMP-system where the data is not automatically send. This seems much more efficient, especially with video-multicast.
regards,
Mark.
Hello M.C.
Actually, in a topology with or without a multicast router, multicast data is not sent to the IGMP Snooping Querier. The purpose of the IGMP Snooping Querier is not to receive and/or process the actual multicast data traffic.
Multicast data is sent from the multicast source to a multicast group address. Hosts interested in receiving this multicast traffic will listen to the multicast group address. The multicast data is sent across the network, targeting this group address, not a specific device like the IGMP Snooping Querier.
The IGMP Snooping Querierâs role is to ask hosts which multicast groups they are interested in. It does this by sending out IGMP queries. These queries are not for data, but rather for membership information. Hosts that want to receive data for a specific multicast group will respond to these queries with IGMP reports, indicating their interest in particular multicast groups.
When a network switch has IGMP Snooping enabled and there is no multicast router present, the switch uses the information gathered by the IGMP Snooping Querier to understand which of its ports have devices interested in specific multicast groups. The switch then intelligently forwards multicast traffic only to those ports that have shown interest in that specific multicast group, rather than flooding the traffic to all ports.
This process helps in optimizing the network by ensuring that multicast traffic is only sent to network segments where there are interested recipients, reducing unnecessary network load and improving overall network performance. Does that make sense?
I hope this has been helpful!
Laz
Hey Laz,
They way you describe it is just like I always thought it would be, but testing in practice seems to prove otherwise.
Lately I found out that with Luminex switches (used in the entertainment sector) all multicast data is send to the querier.
Second example, last week I tested this with a Cisco 250 and 350 switch and again the data was send to the querier. As soon as the querier-service was stopped, the data-stream stopped again.
Netgear is marketing a system called IGMP plus, which does configure multicast exactly the way you describe it, suggesting that IGMP normally doesnât work this way.
Can you shed any light on this?
Thanks again!
regards,
Mark.
Hello Mark
Thanks for sharing your experience. Hmm, thatâs interesting. What does your topology look like? Do you have multiple switches? Iâd be interested to hear more about the specific setup and how you have determined that the traffic is indeed routed to the querier.
Secondly, I would be interested to know if you still get the same behavior when you have a multicast router connected to a switch. The router plays the role of the querier in such a case, do you see traffic going to that router as well, even if the source and destination are directly connected to the switch?
It could be that the 250 and 350 Cisco platform switches function this way whenever the switch plays the role of the querier, however, as you have correctly observed, this is quite inefficient. If you do have any additional information about the above, Iâd be interested in further examining it.
I hope this has been helpful!
Laz
Hello Laz,
How we connected the set:
Birddog hdmi converter->Cisco 250
250 port 1: Cisco 350
250 port 2: Laptop 1
250 port 3: Laptop 2
The birddog was sending multicast NDI, about 140mbit. In the 250 we monitored the port utilisation.
If the 350 started as querier, the traffic from the 250 to the 350 went up.
Luminex has a whitepaper about multicast in their ecosystem:
Netgear also published a whitepaper about their igmp plus system:
Let me know what you find, really curious!
Mark.
Hello Mark
This was the case even if the 350 had no hosts connected to it that were requesting multicast traffic?
I believe that what you are seeing has to do with the way that the Cisco 350 series switches handle multicast traffic. I am unfamiliar with this particular small business switch series as I donât have any direct experience with it. However, looking at some of the documentation linked below, you can see that there are several options for configuring IGMP snooping.
Some of those options are the forward-all option and the unregistered multicast option. It may be that these settings will affect if/how multicast traffic is forwarded to the querier.
Concerning the Luminex whitepaper, there is an option of flooding unknown multicast traffic, which may be involved in the specific situation. And from the netgear documentation, it talks about IGMP plus, a netgear-specific feature that ensures that âunsolicited multicast traffic⌠wonât be forwarded to the IGMP Querierâ.
Itâs interesting to see how various vendors and even model types will function somewhat differently. However, strictly speaking, according to the official definition of multicast, queriers, and IGMP snooping, multicast traffic should not be forwarded to the querier, but only to the hosts that request it.
I hope this has been helpful!
Laz
This was the case even if the 350 had no hosts connected to it that were requesting multicast traffic?
Exactly! Unknown flooding was disabled, so that couldnât be it.
Itâs interesting to see how various vendors and even model types will function somewhat differently. However, strictly speaking, according to the official definition of multicast, queriers, and IGMP snooping, multicast traffic should not be forwarded to the querier, but only to the hosts that request it.
I think thatâs the conclusion for now, different vendors use a different approach, even when itâs not following the standards.
Thanks for your help, learned a lot!
cheers,
Mark.
Been a while, but here goes my return to the networking hat!! So I have two vlans, 10 and 30, both require multicast for video/audio distribution. Each video encoder/decoder requires 1GB of dedicated bandwidth. Both vlan interfaces are configured on the core switch located in the main building of the campus. The other switch is located in a building across the campus. Both sets of switches are going to be Cisco 9300 series switches. One set of switches in the main building will be comprised of one Cisco 9300 fiber switch and two Cisco 9300 48 port copper switches. The switches in the other building will be comprised of Cisco 9300 48 port copper switches. The switches in each building will be stacked. The vlan interfaces are on the switch in the main building, 192.168.10.1/23 and 192.168.30.1/23. The switches are trunked together and the routing occurs over the Default vlan of 192.168.0.0/24. Without a router in the topology i would then need to: 1) Enable multicast routing in global config mode on each switch. 2) Enable ip igmp snooping on the respective vlan 10 and 30. 3) Enable PIM sparse-dense on each SVI interface.
Hello Ralph
Welcome back! I think the networking hat looks good on you⌠
Now you titled your thread âIGMP snooping without a routerâ however, strictly speaking, you do have a router, or at least a Layer 3 device performing routing. So this is not a case of IGMP snooping without a router as described in this lesson.
Now having said that, based on your description and your three steps, I believe you are on the right track. Let me give a bit more detail on the steps you described:
First, youâll need to enable multicast routing on your core switch, which is where your VLAN interfaces are located. The command for this in global configuration mode is ip multicast-routing.
Youâll then want to enable IGMP snooping on VLANs 10 and 30. This can be done with the command ip igmp snooping vlan 10 and ip igmp snooping vlan 30. This will ensure that multicast traffic is only sent to the devices that have requested it, rather than flooding the entire VLAN.
Youâll also need to enable PIM on your VLAN interfaces. This can be done with the command ip pim sparse-dense-mode under each VLAN interface configuration mode.
Lastly, youâll need to ensure that your trunk links between the switches are correctly configured to allow VLANs 10 and 30.
If you need any additional information let us know. As you deploy your network we would be interested in hearing more about the process.
I hope this has been helpful!
Laz
Hi there
Iâve an Network with several switches, in fact multiple c1000 switches connected to C9300 switches
in a star-topology.
The Querier is configured on a c9300 switch but the c1000 switches are ignoring the setting on c9300 and a c1000 is be choosen as Querier
any idea why the configured Querier is ignored
regards
Christian
Hello Christian
From the looks of things, it seems that your c1000 is also configured to be a querier. By default, the c1000 has the IGMP snooping querier function disabled, as stated in this Cisco Documentation. And if there is more than one querier on the subnet, it is the device with the lowest IP address that is elected as the IGMP queirer.
So my assumption is that the quireir functionality is enabled on the c1000, and its IP address is lower than that of the c9300 on that particular VLAN/subnet, and thus it is being used as the querier. To resolve the issue, you can disable the querier functionality on the c1000 by issuing the no igmp snooping querier in global configuration mode on the c1000.
Let us know how you get along!
I hope this has been helpful!
Laz
IGMP snooping querier is enabled on all c1000 switches, which is correct. However, it is set to an IP address on one of the c9300 switches, so this should change the querier election. Nevertheless, the c1000 switches seem to be ignoring the querier on the c9300.
Does IGMP snooping work without a querier option on the c1000 switches? (There is no multicast router on the network; the querier is set on the switch with the most multicast sources.)
If I set the querier on the c1000 to the IP address of the c9300, multicast doesnât work on this switches
Regards, Christian
Hello Christian
The ip igmp snooping querier command is used to enable the querier function on the local switch. The command does allow you to specify an IP address, but only for the purpose of choosing the source IP address of the querier, again, on the local switch. Note that the IP address you specify must be an IP address on the local device. If you specify the IP address of the c9300 switch, you are not telling the local switch to use the c9300 as the querier. If that address is not found on the local device (which in your case it is not), then it will use the following process, as described in this Cisco documentation, to determine the source IP address of the querier:
When enabled, the IGMP snooping querier uses the IP address as the query source address.
If there is no IP address configured on the VLAN interface, the IGMP snooping querier tries to use the configured global IP address for the IGMP querier. If there is no global IP address specified, the IGMP querier tries to use the VLAN switch virtual interface (SVI) IP address (if one exists). If there is no SVI IP address, the device uses the first available IP address configured on the device. The first IP address available appears in the output of the
show ip interfaceprivileged EXEC command.
If you use the show ip igmp snooping querier command as shown in this Cisco documentation, you will be able to verify that the IGMP querier has indeed been enabled on the c1000, and it is likely that the IP address it has chosen to use is lower than the one used by the c9300, so it is becoming the querier. To resolve the issue, disable the querier functionality on the c1000 using the no igmp snooping querier command.
I hope this has been helpful!
Laz
Hi,
Ohhh. I didnt notice the keyword âlocalâ
Now itâs Logic.
Thx
Have a nice Day
hi guy 's again me,
disable the snooping querier worked ,
But a new question is there an option to filter unregistered MC on c9300 and c1000 like on the sg350 devices
Best regards
Christian
Hello Christian
Thatâs great to hear!!
Hmm, thatâs a bit tricky. It really depends upon the nuances that each command type delivers. The difficult thing to deal with when comparing the business series of switches with the C9300 and the C1000 is that different terminology is used for similar things, and the functionalities are not always exactly the same.
After doing some research, I have found that the âfilter unregistered multicast trafficâ on the SG350 is somewhat similar to simple IGMP snooping on the 9300. Snooping allows known multicast traffic to exit only the switch interfaces where interested hosts are found.
Other sources have indicated that the IGMP explicit tracking feature is similar to the filter unregistered multicast feature. More info about this can be found here.
So because of the difference in terminology used (which I have found to be a challenge whenever comparing these particular model lines) itâs not always clear what each feature does and how it functions. The best bet is to do a bit of experimenting to see the behavior you actually have in each case, and to see what behavior you actually want to achieve. Does that make sense?
I hope this has been helpful!
Laz
Hello,
Thanks for the lesson. I have a doubt:
When we use the command ip igmp snooping vlan X mrouter interface GX/X on SW2, with the topology that Rene uses in his example⌠do we still need to configure SW1 as a querier?
I labbed it just configuring SW2 and the output of the show ip igmp snooping groups on SW1 is empty, even though on SW2 it shows the group and its interfaces (as expected, since it receives the new join report and forwards it to E0/0). It also pops on the debug of SW1 that no router interface exists, so the report is dropped:
But surprisingly, same as Rene in his example, I see the querier IP adress (SW1 Interface Vlan 1 IP) with the command show ip igmp snooping querier on SW2. How? SW1 cannot send any queries if I donât configure it as a querier right? (please correct if wrong)
So if we have to configure SW1 as a querier, the router interface on SW2 will always be dynamic (even if we set it up statically, there is no point to it!? (please correct if wrong).
What is a scenario for using static mrouter interface configuration? Is it possible to achieve full functionality just configuring statically the mrouter interface, or we still need to configure the querier?
Also, I have a last doubt: why with the command sho mac address-table multicast we only see the interface statically configured, but not dynamically? I have the lab with both a static configured entry for interface E0/2 on SW2 and dynamic on E0/1, andâŚ
Does this mean that switches use different tables to lookup where to forward a multicast ethernet frame? Why? Or is there like a comon table (like the CEF in Cisco Routers) on switches? Is it because the aging time of the dynamic addresses on the regular MAC address entries does not apply to IGMP snooping learned addresses?
Thanks,
Jose
Hello Jose
Hmm, thatâs interesting. I believe that if you use the static mrouter port configuration, SW1 must somehow either be configured as a quierier, or it must be configured with PIM on the SVI port. If you remove those, as in the lesson, SW1 will indeed drop any multicast packets that may be sent its way from SW2 via the manually configured mrouter port. OR, you have to manually configure an mrouter port on SW1 as well!
According to this Cisco Documentation,
Configure an IP address on the VLAN interface. When enabled, the IGMP snooping querier uses the IP address as the query source address. ⢠If there is no IP address configured on the VLAN interface, the IGMP snooping querier tries to use the configured global IP address for the IGMP querier. If there is no global IP address specified, the IGMP querier tries to use the VLAN device virtual interface (SVI) IP address (if one exists).
So if you configure IGMP snooping on SW1, it will automatically choose a querier address based on the above. This would explain why you see the SVI interfaceâs IP address as the queried.
This would be used in small networks where scalability is not an issue. But you have to ensure that the default behavior of the devices is such that it will work as expected.
Note that in the lesson, Rene also specifies that some platforms may function a bit differently. Ultimately, you should check out the behavior of the feature before putting into a production network.
I hope this has been helpful!
Laz
