Skip to main content

 

Cisco Meraki Documentation

Layer 2 Multicast and Troubleshooting

by Aman Gupta, Joel Ridgell, Andrew Lester & Chris Fox

compiled by Aman Gupta & Rohit Raj

Overview 

Multicast is beneficial for networks when implemented correctly, but the underlying protocols that allow for proper multicast forwarding are not always well understood. This article will first shed light on IGMP (RFC 1112) and then discuss how to troubleshoot reported L2 multicast problems.  

What is L2 multicast?  

L2 multicast works within the same subnet using IGMP. For multicast traffic to traverse L3 boundaries, we need a multicast router. IGMP manages multicast group memberships based on the query and response mechanism. 

IGMP - What is it?

Hosts and routers/switches use the networking protocol IGMP (Internet Group Management Protocol) for multicast. 

Receiver 10.101.140.72 sending IGMP Join for group 239.255.255.250

For L2 multicast to work, the multicast stream from the source and the IGMP Membership Report (Join) from the receiver should reach the IGMP Querier:

  • When a receiver wants to join a multicast group, it must send a Membership Report (IGMP Join) to the group address for which it wants to receive multicast traffic. 

    • When the multicast-enabled router/querier receives this message, it will start forwarding the requested multicast traffic on the interface where it received the IGMP Membership Report.

    • L2 switches forward IGMP Join/Leave only on ports where it sees an IGMP Membership Query for the same VLAN.

  • A L2 switch only sends multicast streams from a source device on ports where it sees an IGMP Membership Report (Join) or a Membership Query for the appropriate VLAN. 

    • The switch will flood incoming multicast streams to all other ports if "Flood unknown multicast traffic" is enabled and the multicast group is unknown (no active members have joined). 

As the switch forwards both ingressing multicast streams and membership reports from receivers on ports where it sees a multicast query, a Multicast Querier sending periodic membership queries is essential to prevent multicast traffic from getting isolated to a single switch. 

IGMP versions

There are three versions of IGMP: 1, 2, and 3. The versions don’t change how multicast traffic is forwarded. It only changes how hosts join and leave multicast groups.  

  • IGMP v1 uses only two messages: Membership Report and Membership Query. 

  • IGMPv2 is the enhanced version of IGMPv1 with the following new features: 

    • Leave Group messages: When a host no longer wants to listen to a multicast group address, it will report to the router/switch that it has stopped listening.

    • Group-specific Membership Query: the multicast router/querier can now send a Membership Query for a specific group address. When the router/querier receives a leave group message, it will use this query to check if any hosts are still interested in receiving the multicast traffic.

    • MRT (Maximum Response Time) field: a new field in query messages. It specifies how much time hosts have to respond to the query. 

    • Querier election process: IGMP querier election ensures only one device becomes the active querier. The router/switch with the lowest IP address becomes the active querier. 

  • IGMPv3 adds support for "source filtering".

    • IGMPv1 and v2 allow hosts to join multicast groups, but they don’t check the source of the traffic. Any host can receive traffic to the multicast group(s) they joined.

    • With source filtering, hosts can join multicast groups only from specified source addresses

    • As such, IGMP version 3 is a requirement for SSM (Source Specific Multicast).

Note: In IGMP versions 1 and 2, hosts send membership reports to a destination address of the multicast group they would like to join, whereas, in version 3, they always send membership reports using the destination IP address of 224.0.0.22. IGMPv1 and v2 also allow for host membership report suppression, which has drawbacks. 

IGMP Snooping

In the above example, PC 1 is streaming an audio file to the multicast group 239.1.1.1, with the destination MAC address 01:00:5e:01:01:01. When Switch 1 receives this traffic, it does a lookup for the MAC 01:00:5e:01:01:01. As this MAC is a multicast MAC address and would have never been a source MAC, it would have never learned this MAC address. Typically, a switch floods a packet with an unknown destination MAC address on all ports except the receiving port. As such, in the above example, the switch will forward the multicast audio file to all connected devices.

Note: If "Flood unknown multicast traffic" is disabled on the Dashboard, the switches will drop the multicast traffic instead.  

IGMP snooping allows us to limit multicast traffic - As the multicast MAC will never be a source MAC, the switches "snoop" multicast traffic between the upstream layer 3 device and downstream hosts to build forwarding tables.

  • When a downstream host sends a membership report for a multicast group, the switch adds an entry in the CAM table for the appropriate interface to learn the multicast destination address

  • When the host sends a Leave Group for a multicast group, the switch removes the corresponding entry from the CAM table for the interface that the host connects to.

IGMP host membership report suppression 

When a host sees a membership report for a group it wants to join, it will suppress itself from sending a report. This behavior helps prevent a high number of membership reports from being flooded for multicast groups. 

As the original RFC is from a routing standpoint, this behavior works fine: A routed interface only needs to know about a single host to route multicast traffic out of that interface. However, at layer 2, membership report suppression can negatively impact IGMP snooping, as it stops a switch from seeing all hosts on the layer 2 segment that may want to join a multicast group.

In the example above, note that Switch 1 will not forward multicast traffic to PC 2 since no IGMP Membership Report indicates the host's intent to join the group.

Why do we need an IGMP Querier? 

As a workaround for the above problem of IGMP host membership report suppression, the switch never forwards IGMP Membership, except on designated router/querier ports. This workaround is essential to keep in mind because multicast traffic can be isolated to a single switch in the topology, as detailed in the diagram below:

L2 switches forward IGMP Join/Leave only on ports where it sees an IGMP Membership Query for the same VLAN. For multicast traffic to be sent from the source to the receivers on different switches, multicast queries must traverse the trunk links throughout the whole multi-switch L2 topology. A Multicast Querier (or Router sending IGMP queries) is necessary for the network to achieve this. An L2 switch will forward an IGMP Membership Query to all ports in the same VLAN except the receiving port.

Example of IGMP Query packets

Note: Meraki switches send IGMP proxy queries sourced from 0.0.0.0. These queries are not for designating router/querier ports. They only make clients announce memberships for faster convergence of known multicast hosts.

IGMP Querier election

A switch forwards all multicast streams toward the respective router/querier. When multiple multicast routers (or switches sending queries) are in the same subnet, only one should send query messages to prevent duplicate traffic. IGMP querier election ensures only one device becomes the active querier. The multicast routers (or switches sending queries) exchange IGMP general queries, and the device with the lowest IP address becomes the active querier. 

When the querier election is complete, all other devices (except the elected querier) initiate their query timer, which resets each time they receive a general query from the IGMP querier.

IGMP - Expected Traffic Flow

clipboard_e6c03b638fd8de5d194a78805df1ce239.png

Layer 2 Multicast Traffic Flow

A high-level overview of the expected traffic flow:

  1. Switch 1 is acting as the IGMP Querier. It periodically sends IGMP Query packets on VLAN  10.

    • On receiving this IGMP Query packet, Switch 2 and Switch 3 will now forward all multicast traffic on VLAN 10 and all Membership Reports on VLAN 10 toward the Querier. 

  2. PC 1 sends a multicast stream to group 239.1.1.1 on VLAN 10. 

  3. Switch 2 sends this multicast stream to the Querier. 

  4. PC 2 and PC 3 send a Membership Report for group 239.1.1.1 on VLAN 10. 

  5. Switch 3 forwards the membership reports to the Querier. 

    • Switch 1, upon receiving the membership reports, also adds the multicast MAC address in the CAM table for the appropriate interface.

  6. As there is an IGMP Join for group 239.1.1.1, Switch 1 forwards the multicast stream to Switch 3, which in turn forwards it to PC 2 and PC 3. 

How to troubleshoot L2 multicast? 

  • Check unicast traffic: Before troubleshooting multicast, ensure that unicast traffic is working. 

    • Ping from the multicast receiver to the multicast source to test this. 

  • Validate configuration:

    • Ensure the source and destination of the multicast stream are in the same subnet. 

    • For a multi-switch network, ensure the subnet has an appropriate IGMP Querier. 

  • Investigate multicast:

    • Ensure the client is streaming multicast to the correct group. 

    • Validate whether the receiver is sending IGMP Membership Report messages indicating to join the correct group. 

    • Confirm that the IGMP Query messages from the router/querier reach the switches where the source and receiver connect.

    • The multicast stream from the source and the IGMP Membership Report (Join) from the receiver should reach the IGMP Querier. 

Note: A brief understanding of the IGMP Snooping and Flood Unknown Multicast toggles can be found here

  • Was this article helpful?