How to Configure and Optimize Multicast on Meraki

Last updated
Save as PDF

Overview

IP multicast transports Internet Protocol (IP) datagrams from a single source [device or application transmitting the multicast] to a group of interested receivers [devices or applications on devices that are interested in receiving the data] in a single transmission.

IPv4 multicast packets use IP addresses in the range 224.0.0.0 to 239.255.255.255 as destination IP addresses. An IP address from this range is commonly referred to as a multicast IP or multicast group because it identifies a group of devices interested in receiving a multicast stream rather than an individual device on the network.

Packet Capture showing multicast stream

Source 10.0.200.2 transmitting multicast stream to group 239.1.8.27

All multicast MAC addresses use an Organizationally Unique Identifier (OUI) of 01:00:5E. The last 3 octets derive from the multicast IP address, which you can calculate using multicast IP to MAC conversion tools available online.

Because only one MAC OUI is available for all multicast IP addresses, MAC addresses and multicast IP addresses overlap, and multiple multicast IPs use the same multicast MAC. MAC addresses shared with a 224.0.0.0/24 multicast IP are always treated as broadcast and never routed, regardless of any Internet Group Management Protocol (IGMP) joins seen. Also, if flood unknown multicast is disabled, the switch drops any traffic that shares a MAC with a 224.0.0.0/24 address but whose IP exists outside of that subnet. The workaround is to avoid multicast IP using x.0.0.x or x.128.0.x addresses.

For more information on L2 and L3 multicast, refer to the following articles:

Multicast support across Cisco Meraki devices

IGMP support on the MX WAN appliance

MXs forward IGMP traffic for a single broadcast domain. They do not forward multicast traffic upstream, between VLANs, or over a VPN.

Note: You can enable Bonjour Forwarding on MXs. For more information, refer to Configuring Bonjour forwarding for the MX Security Appliance.

IGMP support on the MS Switch

MS and Catalyst Switches forward IGMP traffic, but run IGMP snooping by default. IGMP snooping prevents the switch from sending multicast traffic to hosts that have not yet joined the proper multicast group. Disable IGMP snooping under the Switch > Switch Settings page in the dashboard.

Certain Meraki Switches support multicast routing, specifically Protocol Independent Multicast - Sparse Mode (PIM-SM).

PIM-SM and IGMP Querier are available in MS 9.0+. Check your current firmware version on the Organization > Firmware Upgrades page. IGMP snooping does not support IGMPv1. However, the switch forwards IGMPv1 packets with snooping disabled.

IGMP support on MR access points (APs)

MR access points forward multicast and IGMP traffic, but do not participate in the process. An AP does not prevent clients from joining a multicast group, but it does not act as a destination itself. In addition, multicast-to-unicast is enabled on all APs by default. For more information on this behavior, refer to Multicast-Unicast Conversion.

Prerequisites

Confirm the following before you configure multicast routing on MS switches:

PIM-SM is supported on the following models: MS250, MS350, MS355, MS390, MS410, MS420, MS425, MS450, C9300/L/X-M.
PIM-SM and IGMP Querier require firmware version MS 9.1 or later. For MS250 switches, PIM-SM requires firmware MS 9.7.
MLD snooping for IPv6 multicast requires firmware version MS 11.1 or later.
Check your current firmware version on the Organization > Firmware Upgrades page and upgrade if required.

PIM-SM on Cisco Meraki switches conforms to the RFC7761 standard. IGMP snooping conforms to the RFC4604 standard.

Step-by-step instructions

Configure an IGMP querier

IGMP snooping is available on all platforms. IGMP querier is available as of firmware version MS 9.1.

To configure an IGMP querier:

Navigate to Switch > Configure > Routing and DHCP.
Select an interface or choose Add an interface.
Enter the Name, VLAN, Subnet, and Interface IP.
Under Multicast routing, select Enable IGMP snooping querier.
Select Save.

Place the Querier as close to the multicast source(s) as possible. A switch forwards all multicast streams in a VLAN toward the respective querier, so a poorly placed querier can pull streams across trunk links unnecessarily. For a detailed example, go to the Best practices and recommendations section.

Configure PIM-SM

PIM-SM is available as of firmware version MS 9.1. For MS250 switches, firmware MS 9.7 is required.

To configure PIM-SM:

Navigate to Switch > Configure > Routing and DHCP.
Select the interfaces that require multicast routing.
Under Multicast routing, select Enable multicast routing.
Select Save at the bottom of the page.
Navigate back to Switch > Configure > Routing and DHCP. The Multicast routing section now appears below the Layer 3 interface configuration.
Select Click to configure a rendezvous point.
Enter the rendezvous point (RP) and multicast group information. This can be an interface with multicast routing enabled or a custom IP for a third-party RP.
Select Save.

Configure Multicast Listener Discovery (MLD) snooping for IPv6 multicast

IPv6 routers use Multicast Listener Discovery (MLD) protocol to detect IPv6 multicast subscribers in directly connected networks. Cisco Meraki MS switches forward IPv6 multicast traffic and, on firmware versions MS 11.1 and onward, use MLD snooping to track which of their interfaces connect to active IPv6 multicast subscribers.

Similar to IGMP snooping for IPv4 multicast, MLD snooping allows the switch to maintain a mapping between each multicast stream and the links on which it needs to be forwarded. The switch uses these mappings to optimize IPv6 multicast forwarding by filtering the multicast traffic from links that do not connect to active subscribers.

MLD snooping is enabled or disabled with IGMP snooping, which is enabled by default. Configure IGMP snooping settings under Multicast Settings on the Switch > Switch Settings page.

Meraki MS switches support MLD snooping for MLDv1 and MLDv2 on firmware versions MS 11.1 onward.

On the MS210, MS225, and MS250 series switches, enable Flood Unknown Multicast for MLD snooping to work.

Verification

Use the IGMP snooping and flood unknown multicast settings to confirm that the switch forwards multicast the way you expect. Switch 9 firmware introduced the ability to toggle both settings on the Switch settings pages. You can configure four combinations, and each produces a predictable forwarding outcome. Compare your configuration against the matching scenario below to confirm the switch behaves as intended.

A snooping switch never snoops packets with a multicast destination from 224.0.0.0 to 224.0.0.255. Such packets always flood inside their respective VLAN and are never routed. The only exception to the flooding behavior is for IGMP report packets.

Scenario 1 - IGMP snooping: disabled | Flood unknown multicast: disabled

This configuration turns off multicast. The switch drops all ingress multicast packets unless they are in the 224.0.0.0/24 scope, in which case they flood.

Scenario 2 - IGMP snooping: disabled | Flood unknown multicast: enabled

In this configuration, all multicast packets flood in a VLAN identically to a broadcast. This configuration is not recommended.

Scenario 3 - IGMP snooping: enabled | Flood unknown multicast: enabled

Switch forwarding behavior for multicast has several possibilities here. This is a sub-optimal configuration.

First possibility

The switch has not received IGMP reports on any port from interested receivers. In this case, the switch treats the multicast traffic as a broadcast and floods it on all ports in the VLAN.

Second possibility

The switch has received an IGMP report from an interested receiver and has not received any IGMP queries or MRD advertisements. In this case, the switch forwards the multicast stream ONLY out the ports where receivers are known.

Third possibility

The switch has received an IGMP report from an interested receiver along with an IGMP query and/or MRD advertisement. In this case, the switch forwards the multicast stream ONLY out the ports where either receivers are known or IGMP queries / MRD advertisements are received.

Scenario 4 - IGMP snooping: enabled | Flood unknown multicast: disabled

Switch forwarding behavior for multicast has several possibilities here. This is the ideal configuration.

First possibility

The switch has not received IGMP reports on any port from interested receivers, nor received any IGMP queries or MRD advertisements. In this case, the switch drops the multicast traffic.

Second possibility

Same as Scenario 3.

Third possibility

Same as Scenario 3.

Fourth possibility

The switch has not received IGMP reports on any port from interested receivers but has received an IGMP query and/or MRD advertisement. In this case, the switch forwards the multicast stream ONLY out the ports where the IGMP queries and/or MRD advertisements are received.

Troubleshooting

Use the following behavioral notes to diagnose multicast that does not forward as expected.

Multicast streams flow toward Queriers and MRD Advertisers

Multicast streams, if present, always flow toward Queriers and MRD Advertisers, in addition to reaching known receivers. If a LAN has no actual receivers but one switch acts as a Querier, the stream reaches this switch and is discarded upon arrival. Place the Querier as close to the multicast source(s) as possible to prevent unnecessary network traversal.

Streams shared with 224.0.0.0/24 addresses are never routed

MAC addresses shared with a 224.0.0.0/24 multicast IP are always treated as broadcast and never routed, regardless of any IGMP joins. If flood unknown multicast is disabled, the switch also drops traffic that shares a MAC with a 224.0.0.0/24 address but whose IP exists outside that subnet. If a stream is not routing, confirm the multicast group does not use an x.0.0.x or x.128.0.x address.

SSDP traffic is no longer routed as of MS 12.12

As of MS 12.12, Meraki MS switches no longer perform Multicast Routing for the Simple Service Discovery Protocol (SSDP) Group of 239.255.255.250. However, the switch continues to forward this traffic within the same VLAN. If SSDP-based service discovery works within a VLAN but not across routed boundaries, this behavior is expected.

Wireless multicast is rate limited and converted

Meraki APs automatically perform a multicast-to-unicast packet conversion for traffic over the wireless network to conserve airtime.
MRs have broadcast/multicast suppression enabled by default.
- MRs drop any broadcast/multicast traffic that exceeds 100 packets per second. If a wireless multicast stream is choppy or incomplete, check whether it exceeds this rate.
- This rate limiting applies only to packets destined for the WLAN.
MR3*H treats its LAN ports the same as wireless clients.
- LAN clients can be subject to the same rate limit as WLAN clients.

Other behavioral caveats

MS (and dashboard-managed CS) switches do not currently support Fast Leave on IGMPv2.
For CS switches, enabling IGMP snooping also enables the IGMP Querier functionality on all VLANs. Ensure the desired querier has the lowest IP address to win the querier election.
Meraki switches support 30 multicast routing-enabled L3 interfaces on a per-switch level. If multicast routing fails to apply on additional interfaces, confirm you have not exceeded this limit.

Best practices and recommendations

Choosing the IGMP querier

A switch forwards all multicast streams in a VLAN toward the respective router/querier for that VLAN.

Switch 1 forwards undesired multicast stream from Switch 2 to Switch 3 (Querier)

In the above example, the switches only have 1 VLAN. Switch 2 - 4 connect to each other via Switch 1. Since Switch 3 is the IGMP Querier for the VLAN, Switch 1 forwards all incoming multicast streams (from Switch 2 and Switch 4) to the IGMP Querier (Switch 3). Depending on the amount of multicast traffic flowing through the network, incorrectly choosing a Querier can saturate the trunk link between Switch 1 and Switch 3. In this example, enabling Switch 1 as the IGMP Querier instead of Switch 3 can reduce traffic from the trunk link between Switch 1 and Switch 3.

Switch 1, the core switch, is now the Querier, no longer saturating the trunk link between it and Switch 3

In the above examples, the Querier does not respond to the IGMP Membership Report from PC 2 with the multicast stream from PC 1, because the Membership Report and the multicast stream both ingress on the same interface.

For CS switches, enabling IGMP snooping also enables the IGMP Querier functionality on all VLANs. When using CS switches, ensure the desired IGMP querier has the lowest IP address to win the querier election and become the active querier.

Deciding between L2 vs L3 multicast

In the above example, regardless of whether there is a receiver, the core switch receives all the multicast traffic in that VLAN. This might not cause problems in a network with sparse multicast traffic, but this topology might not be desirable in a network with a high volume of multicast traffic.

Depending on the topology, L3 multicast can help manage the amount of multicast traffic traversing trunk links, because the RP controls allowing or denying multicast streams to the receiver.

Switch 1, the core switch and the RP, allowing/denying multicast streams from other switches as needed

In the above example, Switch 1 is the RP. Each remaining switch performs multicast routing and acts as a gateway for its downstream clients. Based on the IGMP/PIM Join it sees, Switch 1 appropriately creates RPTs while sending a PIM Register-stop to sources for which it does not know a receiver. In this example, the RP stops Switch 4 from sending its multicast stream across the trunk link.

Other recommendations

Meraki switches support 30 multicast routing-enabled L3 interfaces on a per-switch level.
Do not enable 'Flood unknown multicast traffic' without a specific use case.
Block SSDP traffic when Multicast Routing is enabled.
- Windows clients commonly generate SSDP traffic (UDP multicast to 239.255.255.250) to discover or announce network services. The mechanism SSDP uses for discovery and advertisements imposes an additional burden on the multicast routing process, because it needs to track each client in the routing table. In addition, the high frequency and volume of SSDP messages can cause frequent updates on the multicast routing process for a non-critical service.
In a large L2 deployment, prune unnecessary VLANs off trunk links to constrain unnecessary multicast traffic.
Avoid using non-routable multicast groups (x.0.0.x or x.128.0.x).
PIM SM requires placing a Rendezvous Point (RP) in the network to build the source and shared trees.
- Place the Multicast Source in the same subnet as the Rendezvous Point. This configuration prevents PIM Registers from being sent and reduces network overhead.
- Typically, core/aggregation switches are a good choice for RP placement.