Skip to main content

 

Cisco Meraki Documentation

Multicast Overview, Configurations and Best Practices

  1. Last updated
  2. Save as PDF

compiled by Aman Gupta

Overview

IP multicast is a method of transporting 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. 

IP addresses in the range 224.0.0.0 to 239.255.255.255 are reserved to be used as destination IP addresses in IPv4 multicast packets. 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). 

Source 10.0.200.2 transmitting multicast stream to group 239.1.8.27

Note:  All multicast MAC addresses use an OUI of 01:00:5E. The last 3 octets are derived from the multicast IP address, which can be calculated using multicast IP to MAC conversion tools available online. 

Note: Due to only one MAC OUI available for all multicast IP addresses, there is an overlap between MAC addresses and multicast IP addresses in that multiple multicast IPs utilize the same multicast MAC. As such, 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 seen. Also, if flood unknown multicast is disabled, any traffic that shares a MAC with a 224.0.0.0/24 address but whose IP exists outside of that subnet will subsequently be dropped. The workaround is avoiding multicast IP using x.0.0.x or x.128.0.x addresses. 

Please refer to the following articles for more information on L2 and L3 multicast:

  • L2 Multicast and Troubleshooting
  • L3 Multicast and Troubleshooting

Multicast support

IGMP Support on the Cisco Meraki Security Appliance

MX Security Appliances will forward IGMP traffic for a single broadcast domain. It does not forward multicast traffic upstream, between VLANs, or over a VPN.

Note: Bonjour Forwarding can be enabled on MXs. More more information, please refer to this document.

IGMP Support on the Cisco Meraki Switch

MS/CS Switches can forward IGMP traffic, but will run IGMP snooping by default. This prevents the switch from sending multicast traffic to hosts who are not yet joined with the proper multicast group. IGMP Snooping can be disabled under the Switch > Switch Settings page in the Dashboard.

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

Note: PIM-SM and IGMP Querier are available in MS 9.0+. You can check your current firmware version on the Organization > Firmware Upgrades page.

Note: IGMPv1 is not supported with IGMP snooping. However, the switch will forward IGMPv1 packets with snooping disabled.

IGMP Support in the Cisco Meraki APs 

The MR Access Points will forward multicast and IGMP traffic, but does not itself participate in the process. This means that an MR Access Point will not prevent clients from joining a multicast group, but it will not itself be a destination. In addition, multicast-to-unicast is enabled on all MR Access Points by default. More information on this behavior can be found here.

MS Multicast Routing Configuration

Certain Cisco Meraki Switches support multicast routing; specifically, Protocol Independent Multicast - Sparse Mode (PIM-SM).  PIM-SM on Cisco Meraki switches conform to the RFC7761 standard.  A firmware upgrade may be required to enable this feature, as detailed in each section. 

Supported Models for PIM-SM: MS250, MS350, MS355, MS390, MS410, MS420, MS425, MS450, C9300/L/X-M

Configuring an IGMP Querier Edit section

IGMP snooping is now available on all platforms and conforms to RFC4604 standards. IGMP querier is available as of firmware version MS 9.1. 

To configure an IGMP querier:

  1. Navigate to Switch > Configure > Routing and DHCP.
  2. Select or Add an interface.
  3. Enter Name, Interface IP, and VLAN.
  4. Under multicast support, selection Enable IGMP snooping querier.
  5. Click Save.

Configuring 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:

  1. Navigate to Switch > Configure > Routing and DHCP.
  2. Select the interfaces that require multicast routing.
  3. Under multicast support, select Enable multicast routing.

  4. Click Save at the bottom of the page.
  5. Once saved, navigate back to Switch > Configure > Routing and DHCP.  The Multicast Routing section will now be available below the Layer 3 interface configuration.

  6. Click to configure a rendezvous point.
  7. Enter the rendezvous point (RP) and multicast group information.  This can be a multicast routing enabled interface or custom IP for a third-party RP.

     

  8. Click Save.

IGMP Snooping and Flood Unknown Multicast Settings 

Switch 9 firmware introduced the ability to toggle both the IGMP Snooping and Flood Unkown Multicast settings on the Switch settings pages. Four different scenarios can be configured with these settings, with some being more suitable than others, depending on the use cases.

A snooping switch will never snoop packets with a multicast destination from 224.0.0.0 to 224.0.0.255. Such packets will 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 Edit section

This configuration turns off multicast. All ingress multicast packets are dropped unless they are in the 224.0.0.0/24 scope, in which case they will flood.

Scenario 2 - IGMP Snooping: disabled | Flood Unknown Multicast: enabled   Edit section

In this configuration, all multicast packets should 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 multicast traffic will be treated as a broadcast and flood 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 multicast stream will ONLY forward 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 multicast stream will ONLY forward out the ports that either receivers are known or where 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 have any IGMP queries or MRD advertisements been received. In this case, the multicast traffic is expected to be dropped.


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 multicast stream will ONLY forward out the ports where the IGMP queries and/or MRD advertisements are received.

Note that multicast streams will, 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 will reach this switch and be discarded upon arrival. Therefore, the best practice is to place the Querier as close to the multicast source(s) as possible to prevent unnecessary network traversal.

Configuring 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 can 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 IPv6multicast 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. IGMP snooping settings can be configured from 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.

MLD snooping is not supported on the MS120 and MS125 series switches. On the MS210, MS225, and MS250 series switches, Flood Unknown Multicast should be enabled for MLD snooping to work.

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. clipboard_eebc3f9c22658782fcd3e6f0e75db15f2.png

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.

clipboard_e929a3dd3fd8afbe27e7cfec6190b9888.png

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

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

Note: 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 or not, the core switch will receive all the multicast traffic in that VLAN. While this might not cause problems in a network with sparse multicast traffic, 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, as the RP is in charge of allowing/denying multicast streams to the receiver.

clipboard_efbab168c3213e55edf67a838fd8199d3.png

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 their downstream clients. Switch 1, based on the IGMP/PIM Join it sees, 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. 

  • It is strongly recommended to block SSDP (Simple Service Discovery Protocol) 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 used by SSDP for discovery and advertisements imposes an additional burden on the multicast routing process as 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. 

As of MS 12.12, Meraki MS switches no longer perform Multicast Routing for the SSDP Group of 239.255.255.250. However, this traffic will still continue to be forwarded within the same VLAN. 

  • 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.

    • We recommend placing 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.

Caveats

  • MS switches do not support Fast Leave on IGMPv2. 

  • For CS switches, enabling IGMP snooping also enables the IGMP Querier functionality on all VLANs. 

  • 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 will drop any broadcast/multicast traffic that exceeds 100 packets per second.

    • This rate limiting applies only to packets destined for the WLAN.  

  • MR3*H Treats its LAN ports the same as wireless clients

    • This behavior means LAN clients can be subject to the same rate limit as WLAN clients.