Multicast and IGMP In Depth

Date Updated: September 27, 2019 FAQ #5895
Question:
Multicast and IGMP In Depth
Answer:

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 destination IP 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.
  • 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. Please note that there is not a 1:1 match between Multicast group addresses--because there are 28 bits of freedom in IPv4 Multicast IP 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.

By default, a network switch which is not configured to use IGMP will forward Multicast traffic to all switchports on the switch. Devices will be responsible for filtering out the traffic that they do not want to receive.

Switches using IGMP will refer to their Multicast Routing Table to decide which switchports need to receive which Multicast groups. This table is sometimes based on Multicast IP Address Groups and sometimes on Multicast MAC Address groups. On some switches, this is configurable.

Some IPv4 Multicast groups receive special treatment. 224.0.0.0/24 is generally broadcast to all ports on the switch, and is not registered with the IGMP querier. In addition, some devices will not register with the querier, and the traffic is considered to be unregistered. Switches usually have a configuration option to either forward this traffic to all switchports or filter it. Forwarding is generally advised, as this traffic is usually low bandwidth. Filtering the traffic can cause problems, such as preventing devices from discovering one another.

Most switches have the ability to create custom forwarding rules for specific Multicast groups. In general, this is usually not necessary. However, in rare cases where filter of unregistered Multicast traffic is required, 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.

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?

IGMP is a protocol used by network equipment to specify which devices should receive which multicast groups. One device 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. 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).

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.

Note: There are two versions of IGMP commonly in use: IGMPv2 and IGMPv3. One is not inherently better than the other; they are used for different situations. 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 FAQ 5423 for specific instructions on configuring your switch.

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:

Room

Device

Internal Function

Address

Subnet Mask

Switch Port

Room A

Front MXA910

Shure Control

10.1.1.10

255.255.255.0

Gigabit 01

Room A

 

Network Audio

10.1.1.20

255.255.255.0

Gigabit 01

Room A

Rear MXA910

Shure Control

10.1.1.11

255.255.255.0

Gigabit 02

Room A

 

Network Audio

10.1.1.21

255.255.255.0

Gigabit 02

Room B

Front MXA910

Shure Control

10.1.1.30

255.255.255.0

Gigabit 03

Room B

 

Network Audio

10.1.1.40

255.255.255.0

Gigabit 03

Room B

Rear MXA910

Shure Control

10.1.1.31

255.255.255.0

Gigabit 04

Room B

 

Network Audio

10.1.1.41

255.255.255.0

Gigabit 04

IT Closet

DSP A

Network Audio

10.1.1.22

255.255.255.0

Gigabit 05

IT Closet

DSP B

Network Audio

10.1.1.42

255.255.255.0

Gigabit 06

IT Closet

Cisco SG350-10P

Management IP

10.1.1.254

255.255.255.0

Internal

IT Closet

Engineer PC

Computer IP

10.1.1.250

255.255.255.0

Gigabit 07

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

Room A

Front MXA910

239.69.20.20

Room A

Rear MXA910

239.69.21.21

Room B

Front MXA910

239.69.40.40

Room B

Rear MXA910

239.69.41.41

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

  • 0.0.233: Dante Discovery and Metering
  • 0.0.251: mDNS for Device Discovery (aka Bonjour)
  • 0.1.129: PTP Clocking--both PTPv1 for Dante and PTPv2 for AES67
  • 255.254.253: Shure Control, for Software Update Utility
  • 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:

  • 0.1.129: All MXA910's and DSP Units
  • 69.20.20: Room A Front MXA910 and DSP A
  • 69.21.21: Room A Rear MXA910 and DSP A
  • 69.40.40: Room B Front MXA910 and DSP B
  • 69.41.41: Room B Rear MXA910 and DSP B
  • 255.254.253: All MXA910's
  • 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.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.

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.

Attachments: