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:

Snooping1

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.

Snooping2

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.

Snooping3

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.

Potential Issues with Multicast within a VLAN Spanning Switches
Tagged on:                 

8 thoughts on “Potential Issues with Multicast within a VLAN Spanning Switches

    • July 14, 2014 at 1:21 pm
      Permalink

      It will!

      At the cost of having all multicast flooded to all ports in the VLAN! 🙂

      Reply
  • July 14, 2014 at 5:20 pm
    Permalink

    could you let me know what tool you are using for network diagrams. Thanks !

    Reply
    • July 16, 2014 at 11:39 pm
      Permalink

      It’s Visio with icons from Cisco’s Powerpoint icons set. Sometimes I use icons from VSDFX as well.

      Reply
  • August 10, 2014 at 5:46 pm
    Permalink

    Interesting post. This kind of design (sources and receivers in the same VLAN) is not what you would see too often 😉 I think that the behavior you have described is platform dependent. If you put a stack of 3750 instead of 3650, the receiver would get the stream without any problems, even without IGMP querier. Also, I believe in this case you could also configure SVI in this particular VLAN and run PIM on it, this should also work.

    Reply
    • March 24, 2015 at 4:16 am
      Permalink

      @Marcin…What is the difference in how the 3650 handles igmp over the 3750?

      We are migrating to 3650 from 3560 and it’s breaking our multicast even though we have a querier.. I have beat my head against the wall all day!

      Reply
  • May 7, 2018 at 5:46 pm
    Permalink

    Couldn’t help to notice that in your article you enabled the IGMP Querier in the Source connect switch and in the referenced Cisco article the solution ( solution 2 ) was to enable it in the Client connected switch.

    I guess both of them would work but I wonder if there are any pros and cons to do one way or the other..

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *