Hi, Many thanks for your answer.
We tracked down the switch but we don’t have access to it and it is part of some switches that are going to be decomissioned anyway in the coming weeks.
It still makes no sense to me how it became the querier as the address would have to be on the same Vlan.
In preperation for decomissioning this I just wanted to ask a quick question.
Do you know how quickly a new querier should take over ?
I thought it would be every minute of so when the queriers are sent and it would then see the lower ip address of the new querier ?
The reason I am asking is because on a seperate issue we were working on last week we set a querier with a lower ip address than the current querier for that vlan and I would say it took about an hour for the lower ip address to take over as the querier.
Does it normally take this long ? We didn’t want to remove the original querier as we wanted it to be still there as a backup.
Is there anyway to force a querier election ?
By the way the switches we were using were Cisco 9300 and 9500
Yes, that is quite strange. It could be an error in addressing. If you have many switches with SVIs in the same VLAN, one of those SVIs may be assigned an IP address outside of your intended subnet for that VLAN, and if it is a lower IP address, it will indeed win the querier election, and incorrectly so.
According to RFC 2236 for IGMPv2, the querier should be elected at most within 2 minutes.
The following Cisco documentation also depicts a step by step process of how IGMPv2 querier elections take place. This is shown under the statement “Query messages are used to elect the IGMP querier as follows”
IGMPv3 has the same querier election mechanism as v2. If you find that it is taking so long for the election to properly take place, could there be an issue with IGMP versions? Could it be that one of the switches is configured to run with IGMPv1 which could cause problems with the interoperation of IGMP versions?
Hi,
I assume it is always best to put the querier nearest to the source as possible, is that correct ?
Is there any issues if I have the querier in the “middle” of the network ? ie. lets say I have switches between the source and the querier and those switches have some clients attached that require multicast.
If I have a multicast stream for example cctv does the multicast stream have to pass through the querier ? or does the querier just keep a mapping table ?
I’m wondering what type of relationship the querier holds with the source ?
Thanks.
The IGMP querier when applied to a switch (when you have no multicast router available) does not perform all of the same functions as a router that is running both PIM and IGMP. If you had a multicast router, and in particular, a Rendezvous Point (RP) in a large multicast network, then yes all of your multicast traffic would flow through that RP, and it should be placed as near as possible to the multicast source.
However, in the case of a switch running IGMP snooping without a multicast router, it is not as critical to have the querier close to the source. Such an IGMP querier will not have all multicast traffic flow through it, but it will only send general IGMP queries and receive IGMP membership requests etc.
So placing a querier in the middle of your network is just fine, and would actually be preferred as all receivers will have on average a shorter network distance to reach it for sending join messages and membership reports. Even so, the benefits of having it in the middle are minimal simply because multicast traffic does not flow through it.
Many thanks Lazaros,
Your answers are extremely helpful and excellent as always. Thank you.
I understand the query to host\receiver part but what I’m lost at is what the querier actually does with this information ?
As in what is the queriers relationship to the source of the multicast ?
If the querier has a “list” of all the multicast groups to ports mapping so to speak then surely the querier must have some sort of communication with the source of the multicast in order to hook up the sender to receiver ?
Otherwise what is the use in the querier having the queried information that it receives back from potential receivers ?
I see someone had a similar question above and it left me confused where you answered " the querier is the location to which all multicast traffic is flooded within an L2 network where IGMP snooping and a querier are enabled."
If this statement is true then the location of the querier would be very important.
I understand the querier sending out the general querier and getting the replies from potential receivers but again surely the querier must be acting as something similar to a rendezvous point with senders sending to it or what exactly does it do with the query information ? and what are its workings between itself and the source and destination ?
Many thanks.
Hi everyone, very informative site and very qualified stuff, happy to have this opportunity to be of you.
My question is to simple, how to set a multicast from 2 sources on 2 different VLANs and 1 or more receivers much appreciated with same topology explained in the topic “IGMP Snooping without Router”. Thanks
If you have two or more multicast sources in a scenario where there is no router, you can still use one of the three solutions that are described in the lesson, either using an IGMP snooping querier, using PIM on an SVI interface, or a static mrouter port. You are able to assign multiple multicast groups as well as multiple sources in such a scenario. You can even lab it up and try it out for yourself.
I simulated this scenario in Cisco IOU and in GNS via VIRL switch and experiencing 2 issues.
In both cases ip igmp snooping querier command is not supported in CLI of the switch.
SW1(config)#ip igmp snooping ?
last-member-query-count Last member query count
last-member-query-interval Last member query interval
report-suppression Report suppression
robustness-variable IGMP Robustness Variable configuration
tcn Topology change notification configuration
vlan IGMP Snooping enable for Catalyst VLAN
In addition to this mac-address table for multicast is showing empty.
SW1#show mac address-table multicast
Vlan Mac Address Type Ports
---- ----------- ---- -----
SW1#show mac address-table multicast vlan 1
Vlan Mac Address Type Ports
---- ----------- ---- -----
SW1#
You have to ensure that the equipment you are using supports the feature. You can find out more info about the specific command at the following Cisco command reference:
The specific link is for the 2960 but you can further research your specific platform/IOS combination.
In order for the MAC address table entries to appear, you must either configure them manually, as in the lesson, or you must have the querier configured and some multicast traffic must go through the switch in order for an entry to appear.
Thanks for response. I just checked Cisco IOU, Cisco Virl switch and 3600 in Gns, however the command was not available on those switch. Do you have 2960 IOS version available to deploy on GNS and to check if the command is available or not?
Regarding multicast mac address, as I mentioned before I already configured the querier and the multucast traffic is passing through the switch as in the example in this switch, however MAC table for multucast is empty.
Once again, it depends upon the IOS version on the device. We are not able to provide IOS for use with GNS3, but in order to find out which IOS/platform combination willl support the command, you can use the Cisco Feature Navigator.
If this was done using Cisco IOU, there may be a problem in the way it operates as far as IGMP snooping goes. Take a look at this post for more info:
Though one question that comes to mind is , what would the switch prefer incase it is configured as an IGMP quarrier while it still has an mroute port , will it take the IGMP membership report and process it and not forward it to the mrouter port ? or will it just forward it and not process it ? or will it both process it and forward it at the same time ?
When administratively enabled, the IGMP snooping querier moves to the nonquerier state if it detects the presence of a multicast router in the network.
This has been taken from this Cisco Documentation:
This behaviour makes sense since it is always preferable to use an actual multicast router as the querier rather than enabling IGMP snooping on a switch.
Once IGMP snooping is enabled, the switch will detect multicast enabled routers and it does so by listening to the following messages:
IGMP General Query (0100.5e00.0001)
OSPF (0100.5e00.0005 and 0100.5e00.0006)
PIM version 1 and HSRP (0100.5e00.0006)
PIM version 2 (0100.5e00.000d)
DVMRP (0100.5e00.0004)
When the switch detects a multicast enabled router then it will add the corresponding entry in the CAM table.
From these messages, the switch will detect the IGMP snooping querier and it will record the IP address of the router as well as the port on which it receives those messages on. Notice in the lesson, the output of the show ip igmp snooping querier command on both SW1 and SW2:
SW1#show ip igmp snooping querier
Vlan IP Address IGMP Version Port
-------------------------------------------------------------
1 192.168.1.254 v2 Fa0/1
SW2#show ip igmp snooping querier
Vlan IP Address IGMP Version Port
-------------------------------------------------------------
1 192.168.1.254 v2 Fa0/24
It shows the IP address of the multicast router as well as the port on which the multicast messages were detected. For SW1, it is the Fa0/1 interface which is directly connected to the router, but for SW2, it is the Fa0/24 interface which is connected to SW1, but via which the multicast messages were detected. Here’s the topology again for reference:
How will loadbalancing work in a L2 etherchannel, in vmy scenario i’v multiple MC streams over an l2 Etherchannel, will this work?
in the scenario doesn’t exist a router
Etherchannel is viewed as just another L2 interface as far as multicast is concerned. Etherchannel should not affect multicast at all, and all load balancing mechanisms applied on such a link are still valid and are used for any other traffic.
You can use the load balancing algorithms as described in the following lesson without any problems:
