Internet Group Management Protocol (IGMP)

IGMP is the multicast signaling protocol IPv4 hosts and routers use to report their IP multicast group memberships to neighboring multicast routers. A multicast router keeps a list of multicast group memberships for each attached network and a timer for each membership.

Multicast group memberships include at least one member of a multicast group on a specific attached network, not a list of all the members. With respect to each of its attached networks, a multicast router can assume one of two roles, querier or non-querier. There is normally only one querier per physical network.

A querier issues two types of queries: a general query and a group-specific query. General queries are issued to solicit membership information with regard to any multicast group. Group-specific queries are issued when a router receives a leave message from the node it perceives as the last group member remaining on that network segment.

Hosts wanting to receive a multicast session issue a multicast group membership report. These reports must be sent to all multicast -enabled routers.

IGMP support in SR Linux includes the following:

IGMP versions 1, 2, and 3 are supported.
Querier support, including timers and relevant parameters.
Trace options.
Static membership groups configured under interfaces.
Support of static <S, G> and <*, G> translation to <S, G>.

IGMP versions and interoperability requirements

If routers run different versions of IGMP, they negotiate the lowest common version of IGMP that is supported on their subnet and operate in that version.

Version 1

Specified in RFC 1112, Host extensions for IP Multicasting, was the first widely deployed version and the first version to become an Internet standard.
Version 2
Specified in RFC 2236, Internet Group Management Protocol, Version 2, added support for ‟low leave latency”, that is, a reduction in the time required for a multicast router to determine that no members of a specific group are present on an attached network.
Version 3

Specified in RFC 3376, Internet Group Management Protocol, Version 3, adds support for source filtering; that is, the ability for a system to report interest in receiving packets only from specific source addresses, as required to support SSM, or from all but specific source addresses, sent to a particular multicast address.

IGMPv3 must keep state per group per attached network. This group state consists of a filter-mode, a list of sources, and various timers. For each connected network running IGMP, a multicast router records the needed reception state for that network.

IGMP version transition

SR Linux routers can interoperate with routers and hosts running IGMPv1, IGMPv2, or IGMPv3. Draft-ietf-magma-igmpv3-and-routing-0x.txt explores some of the interoperability issues and how they affect the various routing protocols.

IGMP version 3 specifies that if at any point a router receives an older version query message on an interface, it must immediately switch into a compatibility mode with that earlier version. Because none of the previous versions of IGMP are source aware, should this occur and the interface switch to Version 1 or 2 compatibility mode, any previously learned group memberships with specific sources (learned from the IGMPv3 specific INCLUDE or EXCLUDE mechanisms) must be converted to non-source specific group memberships. The routing protocol then treats this as if no EXCLUDE definition is present.

Source Specific Multicast (SSM) groups

IGMPv3 allows a receiver to join a group while specifying that it only wants to receive traffic from a particular source. If a receiver does this, and no other receiver on the LAN requires traffic from all sources for that group, then the designated router (DR) can omit performing a (*, G) join to set up the shared tree, and instead issue a source-specific (S, G) join only.

The range of multicast addresses from 232.0.0.0 to 232.255.255.255 is set aside for source-specific multicast in IPv4. For groups in this range, receivers should only issue source-specific IGMPv3 joins. If a PIM router receives a non-source-specific join for a group in this range, it should ignore it.

An SR Linux PIM router must silently ignore a received (*, G) PIM join message where G is a multicast group address from the multicast address group range that has been explicitly configured for SSM. This occurrence should generate an event. If configured, the IGMPv2 request can be translated into IGMPv3. The router allows for the conversion of an IGMPv2 (*, G) request into an IGMPv3 (S, G) request based on manual entries. A maximum of 32 SSM ranges is supported.

IGMPv3 also allows a receiver to join a group while specifying that it wants to receive traffic only if it does not originate from specific sources. In this case, the DR performs a (*, G) join as usual but can combine this with a prune for each source the receiver does not want to receive

Query messages

The IGMP query source address is configurable at two hierarchical levels. It can be configured globally at each router instance IGMP level and can be configured individually at the group-interface level. The group-interface level overrides the source IP address configured at the router instance level.

By default, subscribers with IGMP policies send IGMP queries with an all zero SRC IP address (0.0.0.0). However, some systems only accept and process IGMP query messages with non-zero SRC IP addresses. This feature allows the Broadband Network Gateway (BNG) to inter-operate with those systems.

IGMP configuration

The routers use IGMP to manage membership for a multicast session. IGMP is configured by enabling igmp admin-state under the network-instance protocols context.

The igmp protocol allows the configuration of IGMP parameters in both the default and non-default network instance types, with the ability to apply specific configurations to individual interfaces.

When enabled, at least one interface must be specified in the IGMP context, as IGMP is an interface function. Traffic can only flow away from the router to an IGMP interface and to and from a PIM interface. A router directly connected to a source must have PIM enabled on the interface to that source. The traffic travels in a network from PIM interface to PIM interface and arrives finally on an IGMP enabled interface.

In a typical multicast operation, when a host wants to receive traffic for a multicast group, it sends an IGMP membership report (acting as a join message) to the multicast group address. This report notifies the multicast router that the host is interested in joining the group and receiving its traffic. When the host no longer wants to receive multicast traffic, it may send an IGMP leave message (in IGMPv2 or later) to signal that it is leaving the group.

A multicast router keeps a list of multicast group memberships for each attached network and an interval timer for each membership. It periodically sends IGMP queries to check whether hosts still wants to remain part of each group. Hosts still wanting to receive traffic must respond with an updated IGMP membership report. The router maintains an interval for each membership and removes memberships if it no longer gets the required reports.

Basic IGMP configuration

IGMP is configured by enabling igmp admin-state under the network-instance protocols context.

Configuring IGMP for a default network-instance

The following example shows a configuration of IGMP for a default network instance (srl_default_instance). It includes enabling IGMP, configuring basic IGMP parameters, such as configuring IGMP on an interface, specifying the IGMP version for an interface, and setting up the query interval.

--{ +* candidate shared default }--[  ]--
#info network-instance srl_default_instance
    network-instance srl_default_instance {
        type default
        interface ethernet-1/1.2 {
            interface-ref {
                interface ethernet-1/1
                subinterface 2
            }
        }
        protocols {
            igmp {
                admin-state enable
                interface ethernet-1/1.2 {
                    version 3
                    query-interval 50
                    query-last-member-interval 20
                    query-response-interval 34
                }
            }
        }

Configuring IGMP for an `ip-vrf` network-instance

The following example shows a configuration of IGMP for an ip-vrf type network instance (srl_ipvrf_instance). It includes enabling IGMP, configuring basic IGMP parameters, such as configuring IGMP on an interface, specifying the IGMP version for an interface, and setting up the query interval.

--{ +* candidate shared default }--[  ]--
info network-instance srl_ipvrf_instance
    network-instance srl_ipvrf_instance {
        type ip-vrf
        admin-state enable
        interface ethernet-1/1.4 {
            interface-ref {
                interface ethernet-1/1
                subinterface 4
            }
        }
        protocols {
            igmp {
                admin-state enable
                interface ethernet-1/1.4 {
                    version 3
                    query-interval 50
                    query-last-member-interval 20
                    query-response-interval 35
                }
            }
        }
    }

Configuring a static IGMP group membership

You can configure static IGMP group memberships to test multicast forwarding without a receiver host. When IGMP static group membership is enabled, data is forwarded to an interface without receiving membership reports from host members.

When static IGMP group entries on point-to-point links that connect routers to a rendezvous point (RP) are configured, the static IGMP group entries do not generate join messages toward the RP.

Configuring a static IGMP group membership with a specific source IP

The following example configures a static IGMP group membership to ensure that the multicast traffic from source 192.168.1.1 is forwarded to the specified multicast group range 239.1.1.1 to 239.1.1.20 without requiring dynamic IGMP join requests from the hosts.

--{ + candidate shared default }--[  ]--
#info network-instance default protocols igmp interface ethernet-1/1.1 static-membership-groups
    network-instance default {
        protocols {
            igmp {
                interface ethernet-1/1.1 {
                    static-membership-groups {
                        group-range 239.1.1.1 end 239.1.1.20 {
                            source 192.168.1.1 {
                            }
                        }
                    }
                }
            }
        }
    }

Configuring a static IGMP group membership with starg entries

The following example configures a static IGMP group membership to ensure that the multicast traffic from any source is forwarded to the specified multicast group range 239.1.1.1 to 239.1.1.20 without requiring dynamic IGMP join requests from the hosts.

--{ + candidate shared default }--[  ]--
 info network-instance default protocols igmp interface ethernet-1/1.1 static-membership-groups
    network-instance default {
        protocols {
            igmp {
                interface ethernet-1/1.1 {
                    static-membership-groups {
                        group-range 239.1.1.1 end 239.1.1.20 {
                            starg
                        }
                    }
                }
            }
        }
    }

Configuring SSM translation

You can configure static IGMP SSM mappings on the last-hop router to provide SSM translation for receiver hosts running IGMPv1 or IGMPv2.

Configuring the IGMP SSM mapping enables the multicast router to translate (*, G) information in IGMPv1 and IGMPv2 Report messages to (G, INCLUDE, (S1,S2..)) information, enabling SSM service for IGMPv1 and IGMPv2 hosts.

Configuring SSM mapping

In the following configuration, SSM mapping is set up to translate IGMPv1 or IGMPv2 join requests for multicast group range 239.1.1.1 to 239.1.1.20 into SSM join requests with specific source. The SSM mapping ensures that any host attempting to join one of the multicast groups within this range is mapped to the source IP address 192.168.1.1. This means that even if a host does not explicitly specify the source when making a join request (as is the case with IGMPv1 and IGMPv2), the SSM mapping automatically associates the join request with the source 192.168.1.1.

--{ + candidate shared default }--[  ]--
#info network-instance default protocols igmp ssm mappings
    network-instance default {
        protocols {
            igmp {
                ssm {
                    mappings {
                        group-range 239.1.1.1 end 239.1.1.20 {
                            source 192.168.1.1 {
                            }
                        }
                    }
                }
            }
        }
    }