Potential Issues with Multicast within a VLAN Spanning Switches

Background

I ran into an interesting issue yesterday at work. There is a new video system
being installed, which takes the video output from computers, encodes it and
sends it as multicast to a controller. The controller then displays it on
a video wall. I had been told that the network has to support multicast.
As all the devices were residing in the same VLAN, I did not expect any issues.
However, the system was not able to receive the multicast. At first we expected
it could be the virtual environment and that the vSwitch did not support multicast,
because one server was deployed on the ESX cluster. The topology was this:

Multicast at Layer 2

Before describing the issue, let’s think about how multicast at layer 2 works.
The source will send to a multicast destination IP. This IP is the converted to a
destination MAC address. If the group is 227.0.0.1, this would map to the MAC
address 0100.5e00.0001. Switches forward multicast and broadcast frames to all
ports in a VLAN. This is not effective in the case of multicast as the traffic
may not have been requested by the host connected to a port receiving the
traffic.

IGMP Snooping

IGMP is the protocol used by hosts to indicate that they are interested in
receiving traffic for a multicast group. Cisco switches will by default run a
feature called IGMP snooping. Instead of forwarding multicast traffic to all ports
in the VLAN, the switch will only forward it to the ports that are interested in
receiving it. This works by “snooping” on the IGMP reports from the hosts, if the
switch sees an IGMP report on a port for a group, it knows that the host is interested
in receiving the traffic. The switch will then only forward that traffic to ports
where interested hosts reside. This is a nice feature but it can cause issues
if running multicast in the same VLAN between different switches.

The Issue

Going back to the topology at the start, the source is now sending multicast
traffic into the VLAN. The receiver has sent an IGMP report, because it wants
to receive the traffic.

The multicast traffic from the source reaches the 3650 stack but never leaves,
keeping the traffic from passing through the other switches to the receiver.
Why? The switches are running IGMP snooping, when the Catalyst 3550 at the far
right receives the IGMP report, it adds the port of receiver to receive traffic
for the multicast group. It does not however forward the IGMP report.
This means that the 3650 stack does not know that there are receivers that want
to receive this multicast traffic. The 3650 stack has no entry for the multicast
group in its snooping table. The traffic is essentially black holed.

The Fix

To understand the fix, you must first know about the mrouter port. The mrouter port
is a port leads to a multicast enabled router. For multicast traffic to pass through
IGMP snooping enabled switches, there must be a mrouter port. This port can be
statically assigned or can be dynamically learned. When the switch has a mrouter
port it will forward some of the IGMP reports out the mrouter port, which means that
the IGMP reports will reach the switch where the source is located. Not all reports
must be relayed, it’s enough that the switch learns that there are receivers out there.

In my case I configured the 3650 stack to be an IGMP querier.

SW-1#sh run | i querier
ip igmp snooping querier

This is a dynamic feature that when configured on a switch it considers itself
to be a mrouter, acting as a proxy instead of a router. It will send out general
queries and when the other switches sees this query, they will learn that as a
mrouter port.

SW-3#show ip igmp snooping mrouter 
Vlan    ports
----    -----
  10    Gi0/1(dynamic)

After turning on the IGMP querier feature, the issue was solved.
I hope this post can help someone in case you have issues with multicast in a
switched environment. There is an excellent post about it here from Cisco.