Multicast and IGMP In Depth

You might have heard that some Dante and AES67 networks rely on Multicast and IGMP to function properly. But what exactly is Multicast and IGMP, and how does it work? This FAQ is intended to give an overview of Multicast and IGMP, and how proper switch configuration can create very stable audio network. Please note that this article will not discuss IPv6 Multicast, which is not currently supported by Shure devices.

What is multicast traffic?

Multicast traffic is a type of IP network traffic intended for one or more destinations. Multicast is more efficient than unicast traffic because a source only needs to send data to the network once, letting the network do the hard part. It's also less bandwidth-intensive than broadcast traffic, because only the units who want the traffic will see it. Receiving devices can be on the local network or across the Internet. For Dante and AES67 networks, we are only concerned with multicast traffic which remains within the local network.

Multicast uses special IPv4 destination addresses between 224.0.0.0 and 239.255.255.255. Each address is generally referred to as a Multicast Group. Traffic intended for the multicast group has a destination address of that multicast group and a source address of the device that sent it. There are a few special groups of addresses:

• 224.0.0.0-224.0.0.255: These are reserved for the local network which the devices are on. It won't be passed along to another subnet by a router. This range is sometimes designated as 224.0.0.0/24, and most switches will send this traffic to all devices on the local network--with a few exceptions noted later.
• 239.0.0.0-239.255.255.255: These are reserved for use by private organizations, and won't be routed over the Internet. Organizations are free to use these addresses as they see fit.

All multicast traffic is UDP/IP, and various manufacturers and organizations have standardized a wide variety of multicast protocols. The special IPv4 multicast group addresses are mapped to a special range of MAC addresses, between 01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF. Note that there is not a 1:1 match between multicast group addresses--because there are 28 bits of freedom in IPv4 multicast addresses but only 23 bits of freedom in IPv4 multicast MAC addresses, each IPv4 MAC address can represent up to 32 possible IPv4 multicast groups.

Individual devices will decide which multicast groups they are interested in joining. In small networks, this works like broadcast traffic--all units receive all traffic, and they self-select the data they want. In larger networks, though, a more efficient solution is needed. This is provided by Internet Group Management Protocol, or IGMP.

What is IGMP and IGMP Snooping?

IGMP is a protocol used by network equipment to specify which devices should receive which multicast groups. Without IGMP, a network switch would forward any multicast traffic to all switchports on the switch. Devices would be responsible for filtering out the traffic that they do not want to receive. This would not work well in large network, as undesired traffic would overwhelm devices.

When IGMP is configured and in use, one device on the network is designated as the IGMP Querier, and it is responsible for asking devices what multicast groups they want to join on the network. The querier then tracks those responses and passes them to the switch or switches to add to their Multicast Forwarding Database. This database is a table of multicast IPv4 or multicast MAC addresses as well the switchports which should receive that traffic. When multicast traffic arrives at the switch, the switch checks the table and then passes the traffic to all ports which should receive it. 

Because the Querier communicates with devices on the network, it needs to have an IP address in the same subnet as the devices wishing to receive the multicast traffic. The Querier is often running on your network switch, so the network switch must have an IP address on the local network (as opposed to the factory default address, in some cases).

The Querier has a few user-configurable options. The most important is the Querier Interval, which is the rate at which the querier will ask devices to report back what groups they wish to maintain membership in. We recommend setting this as low as it can go--30 seconds is a safe number generally. The network switch or switches will talk to the Querier to determine which devices want which Multicast groups. The switches then apply filtering to incoming network traffic, sending multicast traffic only to the desired destinations. When there are multiple switches configured, all switches talk to the Querier to gather this information. The port on a switch which can see the querier is often called the mrouter port.

There are two versions of IGMP commonly in use: IGMPv2 and IGMPv3. IGMPv2 deals only with the destination multicast group. In IGMPv2, a device registers its interest in receiving all traffic sent to a given multicast group, and the network hardware obliges by sending all traffic sent to that group, regardless of origin. IGMPv3 adds the concept of Source-Specific Multicast (SSM), which allows a device to specify not only the group it wishes to receive traffic from, but also the desired sender(s). In addition, while IGMPv2 join requests are sent to the multicast group address desired, IGMPv3 adds IGMP-specific multicast groups to handle join and leave requests. AES67 and Dante both use IGMPv2, though an IGMPv3 querier can handle IGMPv2 requests. Shure devices only require IGMPv2.

Misconfigured IGMP settings are the primary cause of Network Audio problems. Please review our Configuring a Network Switch for Shure Devices and Dante/AES67 FAQ.

Registered and Unregistered Multicast

In most cases, devices will register for the multicast groups that they want to receive by responding to the IGMP Querier's requests. Each requested group is then added to each switch's Multicast Forwarding Database along with the ports which should receive the traffic. However, sometimes multicast traffic exists on the network which is not registered at all.

Certain IPv4 multicast groups receive special treatment. 224.0.0.0/24 (224.0.0.0-224.0.0.255) is one of these groups, and the IGMP standard generally requires that this traffic be broadcast to all ports on the same VLAN or switch.

However, in some cases a multicast source will be sending traffic to a normal multicast group which has no registered receivers. This can happen when a device, like a video encoder, does not want to receive its own traffic back, and no devices have asked to receive the signal. Switches usually have a configuration option to either forward this traffic to all switchports or filter it. In audio-only networks, forwarding is generally advised, as this traffic is usually low bandwidth. However, filtering the traffic can cause problems, such as preventing devices from discovering one another. However, filtering is required for any networks which contain video traffic due to the amount of bandwidth video requires.

Most switches have the ability to create custom forwarding rules for specific multicast groups. In general, this is usually not necessary. However, in cases where filtering of unregistered multicast traffic is required (for example, in networks with multicast video sources), you may need to manually forward specific groups. If this situation applies to you, please review the Shure Multicast Groups and Ports document for more information on required multicast groups.

An Example of IGMP Snooping in Action

A technician is installing two new conference rooms at his company, and will be using two MXA910's and a third-party DSP unit in each room. To simplify installation and management of the systems, the technician has chosen to use a ten-port Cisco SG350-10P network switch, which will be shared between both rooms. The switch and DSP units are located in his IT closet, and the MXA910 mics are connected directly back to the same switch from the rooms using Cat6 cable. The MXA910's will send audio to the DSP units via AES67, which uses Multicast audio streams.

The network has IP Addresses assigned as follows:

The following Multicast groups were assigned by the Dante chipset in the MXA910 mics (note that in practice, the addresses are randomized):

In addition, the MXA910 mics will need access to the following IP Multicast Groups to function:

• 224.0.0.230-224.0.0.233: Dante Discovery and Metering
• 224.0.0.251: mDNS for Device Discovery (also known as Bonjour)
• 224.0.1.129: PTP Clocking--both PTPv1 for Dante and PTPv2 for AES67
• 239.255.254.253: Shure Control, for Software Update Utility
• 239.255.255.255: Session Announcement Protocol, to announce AES67 streams

When each device boots up, they send a Join request to the group addresses they wish to join:

• 224.0.1.129: All MXA910's and DSP Units
• 239.69.20.20: Room A Front MXA910 and DSP A
• 239.69.21.21: Room A Rear MXA910 and DSP A
• 239.69.40.40: Room B Front MXA910 and DSP B
• 239.69.41.41: Room B Rear MXA910 and DSP B
• 239.255.254.253: All MXA910's
• 239.255.255.255: All MXA910s and DSP Units

The IGMP Querier, running on the SG350, detects these join requests and adds the device switchports to the forwarding table along with the desired group. Now each device will receive Multicast traffic for the groups it has joined. Note that the devices do not ask to join 224.0.0.230-224.0.0.233 or 224.0.0.251, because those groups are assumed to be flooded to the local subnet. If the switch is configured to Filter Unregistered Multicast Traffic, then those two groups will not be sent to all devices, and they will not be able to see each other via mDNS, nor will the Engineer PC be able to query the Dante chipsets for information. You would need to manually add these groups to the Multicast Forwarding Database and elect which ports should receive them.

Once all devices have joined their desired Multicast groups, they will not be flooded with undesired traffic, some of which may be measured in tens of megabits per second.