In multicast how do switches know who the IGMP querier is?

alanraczek11 · ‎05-20-2020

We have a network consisting of Nexus 9000 series switches. We ave had our multicast challenges lately and in poking around I came across something I have a question about. We have 4 racks, each having a 9000 series switch at the top of the rack. All these switches route to a CORE switch. Switches are named TOR1, TOR2, TOR3, TOR4, CORE. TOR4 has a multicast source in it broadcasting on UDP 239.0.0.1. I noticed on the VLAN I am interested in (or the VLAN I would expect traffic on, the normal lab VLAN) all switches know the querier is 10.16.16.2 (for VLAN 110) except TOR4. TOR4 does not show VLAN 110 when I run the command 'sho ip igmp snooping querier detail'.

So the question first is by what mechanism do the routers (switches) know who the IGMP querier is? Is this statically entered or do routers discover this via IGMP?

BTW Cisco novice here.

...AR

Reza Sharifi · ‎05-20-2020

If it is all in the same vlan, you just need to configure each switch with GMP snooping querier

IGMP Snooping Querier

When there is no multicast router in the VLAN to originate the queries, you must configure an IGMP snooping querier to send membership queries.

When an IGMP snooping querier is enabled, it sends out periodic IGMP queries that trigger IGMP report messages from hosts that want to receive IP multicast traffic. IGMP snooping listens to these IGMP reports to establish appropriate forwarding.

Here is a link on Mulicast for Nexus series:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli/CLIConfigurationGuide/IGMPSnooping.html

HTH

alanraczek11 · ‎05-21-2020

Thank you, that answers the queston of 'how'. But my real question is should (in my example) the switch in question TOR4 have an entry for the igmp querier on VLAN 110? All other switches have an entry for a querier on this VLAN but this one does not. Other VLANs on this one switch DO have the querier address set.

Thanks in advance!

...AR

Joseph W. Doherty · ‎05-21-2020

They discover the IGMP querier, by listening for its queries.

Peter Paluch · ‎05-23-2020

Hi Alan, Reza, Joe,

Please allow me to join.

Indeed, as Joe mentioned, switch that run IGMP Snooping learn about the IGMP Querier by listening to the IGMP Membership Query messages. Whoever sends them is considered a Querier. In fact, the address of the Querier is never configured statically. What can be configured statically on Cisco switches is, in absence of multicast-enabled routers, that they act themselves as IGMP Queriers, as Reza pointed out.

But from what you have described, I see a couple of issues.

Based on your description, I believe that the topology of your network is a star, with CORE in the center, and TOR1 through TOR4 being the spokes, connected to CORE through trunk links (Layer2 switched ports with VLAN tagging). Would this be correct?

Now, assuming that your VLAN 110 spans across all your TOR switches and the CORE switch, TOR4 should indeed learn about the IGMP Querier the same way the other TOR switches did. Now the questions are:

Is VLAN 110 created on TOR4?
Is VLAN 110 allowed on the trunk between TOR4 and the CORE (from both ends)?
What is the state of IGMP Snooping for VLAN 110 on TOR4 - is it enabled or disabled?

In addition, the multicast address 239.0.0.1 is highly problematic. As you very likely know, when multicast IPv4 packets are put into Ethernet frames, the destination MAC address of those frames is constructed by taking the lowmost 23 bits of the IPv4 address and prefixing them with 01:00:5e: and one extra bit set to 0. We don't fit enough bits from the IPv4 address into the MAC address to have a 1:1 mapping between multicast IPs and multicast MACs, and this creates an overlap: Multiple IPs (it can be shown that it is exactly 32) map to a single MAC address. Your IP address 239.0.0.1 maps to 01:00:5e:00:00:01 which is exactly the same MAC that the link-local multicast IP address 224.0.0.1 would map to, too (and this multicast group is all-hosts). This means that your particular multicast streaming may be picked up by any single multicast-enabled host in the network if it hits it.

In general, the range 224.0.0.x is where control protocols such as IGMP, OSPF, EIGRP, RIPv2, PIM, HSRP, VRRP, GLBP, LDP, mDNS and many others send some or all their messages. They should not be disturbed by user multicast streaming, and so it is best to avoid interfering with them by avoiding the use of IP multicast groups that would map into the same MAC range 01:00:5e:00:00:xx as the link-local IPv4 range 224.0.0.x.

Because of this overlap, it is highly recommended to avoid using IP addresses from all these ranges since they all map into the link-local MAC range 01:00:5e:00:00:xx:

224.0.0.0/24
224.128.0.0/24
225.0.0.0/24
225.128.0.0/24
...
239.0.0.0/24
239.128.0.0/24

So in your case, using 239.0.0.x or 239.128.0.x is not okay. Using any other address starting with 239 is okay :) If possible, please readdress your multicast streaming application.

Looking forward to hearing from you!

Best regards,
Peter

Joseph W. Doherty · ‎05-23-2020

Peter, Cisco keeping you real busy? You don't seem to be posting as often as you did before you joined them; miss your, so many, excellent posts.

I'm glad you re-addressed the multicast issue of the VLAN 110 on the TOR4 switch, and possible causes. However, I'm wondering if the (as you well describe) the IP multicast to Ethernet multicast addressing is really "highly problematic", or whether that might be, perhaps, using a bit of hyperbole? ;)

I 100% agree that avoiding the overlap is "highly recommended" and best practice should be to avoid overlapping IP multicast to Ethernet multicast addressing (actually for any usage), but if you did, I wouldn't expect that (typically) alone to break anything. The two negative impacts the come to my mind are, IGMP snooping won't stop this traffic to a host that really doesn't want it and the host's NIC couldn't filter out the frame, it would need to pass it up the stack to L3, which should be able to filter the non-desired IP addressed packet without passing it further up the stack.

Am I missing some other potential problem? Something that truly can make this "highly problematic"?

Peter Paluch · ‎05-25-2020

Hi Joe,

So nice to hear from you! How are you?

Peter, Cisco keeping you real busy?

Yeah... my Cisco times are significantly more busy than my university years :)

You don't seem to be posting as often as you did before you joined them; miss your, so many, excellent posts.

You are very kind - thank you so much! I miss the community, too. But I try to stop by and will continue doing that, and I still hope for my schedule to stabilize and allow me to be around more frequently!

I'm wondering if the (as you well describe) the IP multicast to Ethernet multicast addressing is really "highly problematic", or whether that might be, perhaps, using a bit of hyperbole? ;)

Hahaha, you really keep me on my toes, my friend :)

I admit it was perhaps a little exaggerated. The fact is that... in these matters, you never know, really, because the behavior is so strongly platform-dependent. The link-local address scope has a special importance for network devices since control plane protocols use it. Depending on the sophistication of the device (multilayer switch, router, ...), it may be possible that its ASIC just looks at the destination MAC in the incoming frame, not at the destination IP, when deciding whether the frame should be copied and forwarded to CPU. There are several risks here if we have an overlapping multicast stream with a sufficient bandwidth - either the CPU won't be able to handle the amount of traffic and the whole device will become compromised, or the stream will starve the control-plane policing (CoPP) class of the control plane protocol whose address it overlaps with. The CPU will be protected in that case, but the control plane protocol sharing the same CoPP class with the multicast stream may get dropped and its operation will break. It's practically impossible to tell from outside without lab testing how a specific switch or router platform will behave; a different ASIC can have entirely different behavior.

This is what I had in mind...

Best regards,
Peter

Joseph W. Doherty · ‎05-26-2020

Peter, excellent point concerning the capacity/capability of an ASIC and/or a CPU; especially for many switches, even "powerful" switches. Basically, your concern might be summed up as an un-intential DoS impact.

alanraczek11 · ‎05-26-2020

Thank you! Let me explain in more detail. Note I am more of a systems guy and just came into maintaining our Cisco network 4 months ago. So not an SME. Yes you are correct about the star topology of the network. VLAN 110 is considered our normal lab VLAN, so this does exist on all switches (but I have a Q, how do I know what switch that VLAN was created on, rookie question). This is our multicast scenario created by our developers (to match fielded systems-to a degree):

- CORE switch is the snooping querier at 10.16.16.2. We do not have an RP.

- TOR3 has a video server (10.16.16.228) that casts on UDP 224.4.205.[58-61]:8208.

- TOR4 A server (10.16.16.44) under TOR4 receives this stream from 16.228, processes/adds to it and sends it out on 239.0.0.1:[7775-7778].

- TOR1 has a VM (10.16.126.234) that receives UDP and CAN receive the 239.0.0.1 stream but CANNOT receive the 224.4.205.x stream.

-There is a "bench switch" in out lab area also coming off the CORE switch. A developer in that area cannot receive any UDP to his box (pc). So could be a switch issue there. The pc I remote into is also on that switch. Do not have remote access to that switch. We are all temporarily working remotely and do not have physical access to the switches.

This is how the UDP mapping goes:

Video stream input to 10.16.16.228. "Map" server under TOR4

Input Stream Output Stream

udp://224.4.205.58:8208 --> goes to udp://239.0.0.1:7775

udp://224.4.205.59:8208 --> goes to udp://239.0.0.1:7776

udp://224.4.205.60:8208 --> goes to udp://239.0.0.1:7777

udp://224.4.205.61:8208 --> goes to udp://239.0.0.1:7778

I was going to include a drawing but felt that's too much detail for here. But this pretty much sums up the flow.

...Alan

alanraczek11 · ‎05-26-2020

Forgot to mention (possibly) these are Nexus 9000 series switches we are talking about.