IP Multicast and IGMP
Introduction
IP Multicast is a method of sending IP packets to a group of interested Receivers in a single transmission. It uses specially reserved Multicast Address blocks (Class D: 224.0.0.0 – 239.255.225.255). It is often employed for streaming data protocols in our industry like MA-Net, sACN, Dante and many more.
To take full advantage of IP Multicast, the multicast receivers and the switches need to support the Internet Group Management Protocol (IGMP) for IPv4 multicast or the Multicast Listener Protocol (MLD) for IPv6
Luminex has a white paper on IGMP available for download here.
Luminex GigaCore switches are configured out-of-the-box with IGMP snooping and IGMP Querier enabled.
Settings explained
Snooping
With IGMP snooping enabled, the switch will attempt to route multicast only towards the ports on which a receiver is connected that would like to receive the multicast data. With IGMP snooping disabled, all multicast will be treated as broadcast data.
Unknown flooding
The unknown flooding setting determines what should happen with multicast data for which not a single receiver is known. Luminex recommends to leave this setting disabled since it can give undesired results and a false sense of confidence.
Here is an example to explain this:
- Assume that unknown flooding is enabled
- Assume that there is a multicast sender and a multicast receiver connected to a GigaCore or GigaCore network, sending data on multicast address "a.b.c.d".
- Assume that the multicast receiver doesn't correctly implement the IGMP protocol and therefore, the GigaCore's don't register any multicast registrations for multicast address "a.b.c.d", it will be treated as 'unknown'.
- Because of the unknown flooding setting, you will not notice any issue, the multicast data will just be flooded on all ports, including on the connection towards the receiver.
- Now, if another device is connected to the network or a piece of software (like sACNView) is started that registers correctly to the same multicast address "a.b.c.d", the address becomes known to the GigaCore(s). The GigaCore's will only forward the multicast data to this new device since that is the only one registered and all of a sudden, the multicast receiver that was already connected, no longer receives any multicast data.
With unknown flooding disabled, the receiver with the bad IGMP implementation will never receive any data, indicating from the start that there is something wrong.
Querier
By default, the Querier option is enabled. This defines if the switch is allowed to participate in the Querier election process. Disabling this setting prevents the switch to go into Querier role. Make sure that, at least one switch has the Querier option enabled for IGMP to function.
Querier IP address
The Querier IP address is the source IP address used for IGMP messages generated by the GigaCore. The switch that uses the lowest numerical IP address, will be selected as the Querier. Therefore it can be important to correctly configure the Querier IP Address such to determine the location of the primary querier and maybe a secondary querier.
Luminex uses the following scheme to determine the default querier IP address: "10.a.x.y"
- The first octet is '10', this is used to ensure that the IP address falls in a private network IP range, defined by the Internet Engineering Task Force (IETF) and the Internet Assigned Numbers Authority IANA.
- The second octet, 'a', is generated based on the speed capabilities of the GigaCore and any possible 'Primary' or 'Secondary' configuration. Any switches configured for 'Primary' Querier IP Address will always have a lower IP address, followed by switches configured for 'secondary', and afterwards all switches set to 'default'. Additionally, you probably want the querier switches to be a switch with higher available bandwidth. Therefore, 10Gbps switches will get a lower IP address compared to 1Gbps GigaCore's.
- The last 2 octets 'x.y', correspond with the last 2 octets of the GigaCore IP address.
Additionally, it is possible to configure a custom querier IP address. This can be helpful to ensure that the source IP address falls in the same IP range as the IP address of the end devices, something that is required for some end devices to function correctly.
Araneo
Araneo has various tools to help debug any multicast / IGMP issues.
Querier location
When the IGMP network overlay is enabled, Araneo will indicate which GigaCore is the querier. Preferably, this is a single switch for all groups, but if it is not, the word 'Querier' will be indicated in orange. By clicking on 'Querier', You will get a list of all the groups for which that particular GigaCore is the querier.
Multicast router port
Araneo will show a black square with 'MR' on the multicast router ports, the port towards the querier. If not all groups have the same querier, hovering over the 'MR' icon will indicate for which groups this port is a multicast router port.
IGMP registrations for each GigaCore
When selecting a particular GigaCore, it is possible to go to the 'IGMP' tab on the bottom of the screen. This will give a list of all IGMP registrations known by that GigaCore. Information includes the Group, VLAN ID, multicast address along with a list of ports on which a registration is active. Araneo will give an indication of the protocol used for the multicast address based on a database of known multicast addresses for particular applications. Note that this is just an indication, some protocols might use the same address.
Health check
The Araneo health check, accessible in the top right of the screen, will check for IGMP querier issues. For example:
- It will flag when multiple queriers are detected. We recommend to use a single GigaCore as the querier for all groups
- It will flag if multiple queriers are detected for a particular group. This can happen during the querier election process, but should be resolved when election is completed.
- It will flag if no querier was detected for a particular group.
IGMP testing
At Luminex, we have noticed that a various IGMP related issues are due to a bad IGMP protocol implementation in the multicast receiver. To help manufacturers of these products with the development of a good IGMP implementation, we started an open-source IGMP tester project. The test suite is based on real-world issues along with recommendations from the IGMP standards (IGMPv2: RFC 2236, IGMPv3: RFC 3376). Failures have to be interpreted correctly as some tests are just recommendations, not requirements. We encourage everybody to contribute to the development of this test tool, in an attempt to improve the general stability of multicast networks in our industry and to reduce the time needed to troubleshoot problems.
Related Articles
GigaCore API documentation
In the attached document you can find all the web API commands available for the second generation GigaCore. The API is also available on the device itself by browsing to http://{YOUR_DEVICE_IP}/api/doc This API works for the following devices: ...Gigacore Switches and Avid S6L
As most of you probably know by now, Gigacore switches can be used to connect the different units in an Avid S6L system. The procedure to configure Gigacore switches is described by Avid in this document : ...Can I transport AES50 audio protocol through the GigaCore?
AES50 is an open standard based on the AES10 protocol (MADI) but has been developed much further. Published by the Audio Engineering Society AES, this protocol is using Cat5 cabling for transport. However, the protocol is not Ethernet compliant, this ...GigaCore Bitfocus Companion Streamdeck module
Introduction Luminex products have an open HTTP API. This API can be used to integrate with other software applications. The GigaCore API is documented here (generation 2) and here (generation 1). One such application is Bitfocus Companion, a ...Audinate Dante
All the groups on Luminex switches are configured to work with the Audinate Dante audio protocol out-of-the-box, no additional configuration is needed. GigaCore switches are managed switches with a friendly user interface. The Araneo software can be ...