Does multicast become broadcast in certain situations?

[huangedmc]

I've read Beau Williamson's mcast bible, and I know how a host sends IGMP report to its router, which then sends PIM join upstream, etc.

Most of the multicast books or documents seem to focus on what happens between the first hop router that the sender/source connects to, and the end user host that desires to receive the mcast stream.

I'm curious to what happens between the mcast source, and its first hop router, specifically on the LAN.

The source server sends traffic to an mcast group address, say 239.1.1.100.

How does the LAN switch where the server plugs into handle it?

Since the source doesn't send IGMP report like the receivers do, there's no IGMP snooping in place.

Does this mean the LAN switch would send the stream out to all ports on that subnet, which basically turns it into broadcast?

If so, is there any way to limit the traffic to only the server access port, and the uplink port towards the first hop PIM router? (IGMP snooping for sender...does such a thing exist?)

======

Now a different question:

We know in text book mcast topology, there must be an RP, and PIM routers to facilitate as the queriers for IGMP queries, etc.

What if the source and receivers are in the same subnet VLAN?

Are RP & PIM routers still required?

If the multicast stream turns into broadcast, and is forwarded out all switchports, the receivers would get a copy of that stream, even w/o the help of RP & PIM routers present, correct?

I'm asking because many of our servers use Cisco ACE load balancers as their default gateway, but ACE does not support multicast. (at least not in routed mode)

[Peter Paluch · Accepted solution]

Hi,

You've got some great questions at hand.

The source server sends traffic to an mcast group address, say 239.1.1.100.
How does the LAN switch where the server plugs into handle it?

If the switch is not running IGMP Snooping then the answer is fairly easily - this multicast will be flooded out all remaining ports in the same VLAN just like any other frames with an unknown destination.

If the switch runs IGMP Snooping then it has to identify router ports, i.e. ports to which multicast routers are connected. Usually, on Catalyst switches, this is performed by listening for PIM and/or DVMRP messages (though the switch is not processing their contents) which are obviously sourced by multicast routers. An example from show ip igmp snooping on a Catalyst 2960 says:

Vlan 1:

--------

IGMP snooping                       : Enabled

IGMPv2 immediate leave              : Disabled

Multicast router learning mode      : pim-dvmrp

CGMP interoperability mode          : IGMP_ONLY

Robustness variable                 : 2

Last member query count             : 2

Last member query interval          : 1000

Also the show ip igmp snooping mrouter command shows you the list of ports that the Catalyst has identified as mrouter ports:

Switch# show ip igmp snooping mrouter

Vlan    ports

----    -----

128    Gi0/24(dynamic)

137    Gi0/24(dynamic)

138    Gi0/18(dynamic), Gi0/24(dynamic)

139    Gi0/24(dynamic)

If necessary, a particular port can be statically designated as mrouter port using the global configuration command:

ip igmp snooping vlan vlan-id mrouter interface name number

Does this mean the LAN switch would send the stream out to all ports on that subnet, which basically turns it into broadcast?

Certainly not. A multicast traffic received by an IGMP Snooping switch is forwarded out all ports with subscribed recipients, and in addition, out all mrouter ports. This is one of reasons IGMP Snooping has to identify mrouter ports.

We have to be careful about saying that "a multicast can turn into broadcast" because that implies a change in the addressing which never takes place.

If so, is there any way to limit the traffic to only the server access  port, and the uplink port towards the first hop PIM router? (IGMP  snooping for sender...does such a thing exist?)

By the virtue of IGMP Snooping switch performing mrouter port discovery, this process already happens as explained earlier.

What if the source and receivers are in the same subnet VLAN? 
Are RP & PIM routers still required?

For basic IP Multicast over a switch that does not run IGMP Snooping, no RP nor PIM routers are necessary. If, however, the switch is running IGMP Snooping, it relies on IGMP queries to discover and periodically refresh the list of connected subscribers. If there is no multicast router in the VLAN, there are no IGMP Membership Query and Report messages being sent, meaning the IGMP Snooping has nothing to act upon. Therefore, switches capable of IGMP Snooping are usually also equipped with a helper function called IGMP Snooping Querier that allows the switch itself to send periodic IGMP Query messages so that it can refresh the list of attached subscribers. Using IGMP Snooping Querier, you can use an IGMP Snooping-enabled switch even in VLANs without multicast routers. This feature is not on by default - you have to explicitly activate it.

If the multicast stream turns into broadcast, and is forwarded out all  switchports, the receivers would get a copy of that stream, even w/o the  help of RP & PIM routers present, correct?

This can never happen because, first, the multicast never "turns into broadcast", it may just be forwarded/flooded in the same way, and second, neither a switch nor a multicast router ever sends a multicast packet back the interface it came in. That means no duplication can occur here.

This may appear as an offtopic remark, but just for the sake of completeness, you should be aware that all range of multicast IP addresses that maps to the MAC address space of 01:00:5E:00:00:xx is exempted from IGMP Snooping on Catalyst switches, and is hence always flooded. This corresponds to the set of 32 IP addresses of the form:

224-239.{0,128}.0.X

Originally, this MAC address space correspods to the link-local IPv4 multicast scope 224.0.0.0/24. This space is used by many common protocols such as OSPF, RIPv2, EIGRP, VRRP, PIM, etc. As the routers do not send IGMP Membership Reports, as you have noted yourself, these applications would not work over switches with IGMP Snooping activated - so for this reason, the link-local IPv4 multicast scope is exempted from IGMP Snooping.

However, because the corresponding mapping into MAC addresses is not unique, there are in total 32 IP addresses that map into the same MAC space: 224.0.0.0/24, 224.128.0.0/24, 225.0.0.0/24, 225.128.0.0/24, 226.0.0.0/24, ... 239.0.0.0/24, 239.128.0.0/24. You have to be therefore careful when you assign multicast IP addreses to avoid these 32 groups, as they would not be affected by the IGMP Snooping.

Feel welcome to ask further!

Best regards,

Peter

[huangedmc]

hi Peter,

Great detailed response - appreciate you taking the time to answer thoroughly.

To clarify, I meant to say the mcast traffic being forwarded out all ports, therefore in the same behavior as broadcast.

You're correct that I should be more careful in the wording, as destination is not going to change itself from 239.1.1.100 to 255.255.255.255.

I initially thought IGMP snooping only looks at well, IGMP traffic.

So I was apparently wrong, because it also identifies the mrouter ports w/ PIM & other messages.

Apparently I didn't read Beau Williamson's book thoroughly enough.

It turns out a good portion of what you mentioned above is actually already covered in Beau's book!

Chapter 14, section "IGMP Snooping & Send-Only Sources" on p.424 - 426 clearly addresses my exact concern & question w/ a mcast source-only scenario.

A new question came up w/ this investigation though:

P.427 in Beau's mcast book, and p.679 in Wendell Odom's CCIE cert prep book both mention IGMP snooping capable switches can detect mrouter ports with the following messages:

-IGMP Queries

-PIM hellos

-DVMRP probes

-OSPF

-HSRP

However, in the "show ip igmp snooping" output on a Cat 3K running IOS, I get same result as you:

Vlan 29:

--------

IGMP snooping                       : Enabled

IGMPv2 immediate leave              : Disabled

Multicast router learning mode      : pim-dvmrp

CGMP interoperability mode          : IGMP_ONLY

Robustness variable                 : 2

Last member query count             : 2

Last member query interval          : 1000

================================

On a Nexus 7000 running NX-OS, I get similar result:

...

  Router port detection using PIM Hellos, IGMP Queries

...

=================================

Neither of the outputs mention the switches can learn mrouter ports based on messages other than PIM, DVMRP, or IGMP.

So what about OSPF & HSRP?

Can IGMP capable switches learn mrouters based on those messages or not?

Are these books simply out-dated?

Or does it mean if I run OSPF & HSRP, the mrouter ports will be taken care of?

==================================

Now, regarding IGMP querier...it seems that's a function you configure on a routed port, or SVI...something w/ an IP address.

So back to my issue, many of our servers use SVI's on Cisco ACE load balancers as their default-gateway, which do not support multicast, and we can't configure ACE as IGMP querier.

What are our options?

Can we manually set each switch's uplinks as static mrouter ports, so that mcast stream will be forwarded on those ports? On the subnet where these servers reside, it's L2-only VLAN, thus no SVI's to facilitate IGMP query function, whether by setting the SVI w/ PIM, or IGMP querier - SVI is on ACE LB, not L3 switch.

Even if we can manually set the mrouter ports on uplinks, how do we take care of the receiver ports?

When the hosts first come online, they'll send the initial IGMP reports to express their desire to receive mcast stream, but wouldn't the fact that there's no IGMP querier on the VLAN time them out, then remove those ports from the IGMP snoopiong CAM table?

Can we simply change our mcast group address to a link-local address in the 224.0.0.0/24, since things in that range are forwarded out all ports, w/o being subjected to IGMP snooping rules?

224-239.{0,128}.0.X as you put it above.

As long as we use something that's not already assigned, or in use according to IANA, it should work, in theory?

http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml

thx

Kevin