IGMP is an internal protocol of the IP suite. IP manages multicast traffic by using switches, multicast routers, and hosts that support IGMP. A multicastrouter is not necessary as long as a switch is configured to support IGMP with the querier feature enabled. A set of hosts, routers, and/or switches that send or receive multicast data streams to or from the same sources is called a multicast group, and all devices in the group use the same multicast group address. The multicast group running version 2 of IGMP uses three fundamental types of messages to communicate:
|
Query |
A message sent from the querier (multicast router or switch) asking for a response from each host belonging to the multicast group. If a multicast router supporting IGMP is not present, the switch must assume this function to elicit group membership information from the hosts on the network. If you need to disable the querier feature, do so through the CLI using the IGMP configuration MIB. |
|
Report (Join) |
A message sent by a host to the querier to indicate that the host wants to be or is a member of a given group indicated in the report message. |
|
Leave group |
A message sent by a host to the querier to indicate that the host has ceased to be a member of a specific multicast group. |
An IP multicast packet includes the multicast group (address) to which the packet belongs. When an IGMP client connected to a switch port needs to receive multicast traffic from a specific group, it joins the group by sending an IGMP report (join request) to the network. (The multicast group specified in the join request is determined by the requesting application running on the IGMP client.) When a networking device with IGMP enabled receives the join request for a specific group, it forwards any IP multicast traffic it receives for that group through the port on which the join request was received. When the client is ready to leave the multicast group, it sends a Leave Group message to the network and ceases to be a group member. When the leave request is detected, the appropriate IGMP device ceases transmitting traffic for the designated multicast group through the port on which the leave request was received (as long as there are no other current members of that group on the affected port.)
Thus, IGMP identifies members of a multicast group (within a subnet) and allows IGMP-configured hosts (and routers) to join or leave multicast groups.
To display IGMP data showing active group addresses, reports, queries, querier access port, and active group address data (port, type, and access), see the Management and Configuration Guide for your switch.
You can configure IGMP on VLANs that do not have IP addressing. The benefit of IGMP without IP addressing is a reduction in the number of IP addresses you have to use and configure. This can be significant in a network with a large number of VLANs. The limitation on IGMP without IP addressing is that the switch cannot become Querier on any VLANs for which it has no IP address—so the network administrator must ensure that another IGMP device will act as Querier. It is also advisable to have an additional IGMP device available as a backup Querier.
Comparison of IGMP operation with and without IP addressing
| IGMP function available with IP addressing configured on the VLAN | Available without IP addressing? | Operating differences without an IP address |
|---|---|---|
| Forward multicast group traffic to any port on the VLAN that has received a join request for that multicast group. | Yes | None |
| Forward join requests (reports) to the Querier. | Yes | None |
Configure individual ports in the VLAN to Auto (the default)/Blocked, or Forward. |
Yes | None |
| Configure IGMP traffic forwarding to normal or high-priority forwarding. | Yes | None |
| Age-out IGMP group addresses when the last IGMP client on a port in the VLAN leaves the group. | Yes | Requires that another IGMP device in the VLAN has an IP address and can operate as Querier. This can be a multicast router or another switch configured for IGMP operation. (HP recommends that the VLAN also include a device operating as a backup Querier in case the device operating as the primary Querier fails for any reason.) |
| Support Fast-Leave IGMP and Forced Fast-Leave IGMP (below.) | Yes | |
| Support automatic Querier election. | No | Querier operation not available. |
| Operate as the Querier. | No | Querier operation not available. |
| Available as a backup Querier. | No | Querier operation not available. |
Depending on the switch model, fast-leave is enabled or disabled in the default configuration.
| Switch model or series | Data-driven IGMP included? | IGMP fast-leave setting | Default IGMP behavior |
|---|---|---|---|
| Switch 8200zl
Switch 6600 Switch 6400cl Switch 6200yl Switch 5400zl Switch 5300xl Switch 4200vl Switch 3500 Switch 3500yl Switch 3400cl Switch 2910 Switch 2900 Switch 2610 Switch 2510 Switch 2500 |
Yes | Always Enabled | Drops unjoined mulitcast traffic except for always-fowarded traffic toward the Querier or multicast routers and out of IGMP-forward ports. Selectively forwards joined multicast traffic, except on IGMP-forward ports, which forward all multicast traffic. |
| Switch 2600
Switch 2600-PWR Switch 4100gl Switch 6108 |
No | Disabled in the default configuration | IGMP fast-leave disabled in the default configuration. Floods unjoined multicast traffic to all ports. Selectively forwards joined multicast traffic, except on IGMP-forward ports, which forward all multicast traffic. |
On switches that do not support data-driven IGMP, unregistered multicast groups are flooded to the VLAN rather than pruned. In this scenario, fast-leave IGMP can actually increase the problem of multicast flooding by removing the IGMP group filter before the Querier has recognized the IGMP leave. The Querier will continue to transmit the multicast group during this short time, and because the group is no longer registered, the switch will then flood the multicast group to all ports.
On HP switches that do support data-driven IGMP ("Smart" IGMP), when unregistered multicasts are received the switch automatically filters (drops) them. Thus, the sooner the IGMP leave is processed, the sooner this multicast traffic stops flowing.
Because of the multicast flooding problem mentioned above, the IGMP fast-leave feature is disabled by default on all HP switches that do not support data-driven IGMP (see the table above.) The feature can be enabled on these switches via an SNMP set of this object:
hpSwitchIgmpPortForceLeaveState.vid.port number
However, HP does not recommend this, because it will increase the amount of multicast flooding during the period between the client's IGMP leave and the Querier's processing of that leave. For more information on this topic, see Forced fast-leave IGMP.
If a switch port has the following characteristics, the fast-leave operation will apply:
-
Connected to only one end node.
-
The end node currently belongs to a multicast group, that is, is an IGMP client.
-
The end node subsequently leaves the multicast group.
Then the switch does not need to wait for the Querier status update interval, but instead immediately removes the IGMP client from its IGMP table and ceases transmitting IGMP traffic to the client. (If the switch detects multiple end nodes on the port, automatic fast-leave does not activate—regardless of whether one or more of these end nodes are IGMP clients.)
In Example of automatic fast-leave IGMP criteria, automatic fast-leave operates on the switch ports for IGMP clients "3A" and "5A," but not on the switch port for IGMP clients "7A" and "7B," server "7C," and printer "7D."
When client "3A" running IGMP is ready to leave the multicast group, it transmits a Leave Group message. Because the switch knows that there is only one end node on port A3, it removes the client from its IGMP table and halts multicast traffic (for that group) to port A3. If the switch is not the Querier, it does not wait for the actual Querier to verify that there are no other group members on port A3. If the switch itself is the Querier, it does not query port A3 for the presence of other group members.
Fast-leave operation does not distinguish between end nodes on the same port that belong to different VLANs. Thus, for example, even if all of the devices on port A6 in Example of automatic fast-leave IGMP criteria belong to different VLANs, fast-leave does not operate on port A6.
Fast-leave IGMP is enabled by default. When fast-leave is disabled and multiple IGMP clients are connected to the same port on an IGMP device (switch or router), if only one IGMP client joins a given multicast group, then later sends a Leave Group message and ceases to belong to that group, the switch automatically retains that IGMP client in its IGMP table and continues forwarding IGMP traffic to the IGMP client until the Querier triggers confirmation that no other group members exist on the same port. This delayed leave operation means that the switch continues to transmit unnecessary multicast traffic through the port until the Querier renews multicast group status.
When enabled, forced fast-leave IGMP speeds up the process of blocking unnecessary IGMP traffic to a switch port that is connect ed to multiple end nodes. (This feature does not activate on ports where the switch detects only one end node.) For example, in Example of automatic fast-leave IGMP criteria, even if you configured forced fast-leave on all ports in the switch, the feature would activate only on port A6 (which has multiple end nodes) when a Leave Group request arrived on that port.
When a port having multiple end nodes receives a Leave Group request from one end node for a given multicast group "X," forced fast-leave activates and waits a small amount of time to receive a join request from any other group "X" member on that port. If the port does not receive a join request for that group within the forced-leave interval, the switch then blocks any further group "X" traffic to the port.
This feature adds a global IGMP multicast configuration option to the switch that results in each VLAN having a multicast filter. The filter prevents unjoined multicast traffic from being forwarded on interfaces associated with IGMP queriers. Each filter only contains interfaces that are queriers on the same VLAN, so multicast traffic is only flooded on interfaces that contain queriers that are on the same VLAN as the multicast traffic.
On switch bootup, all VLANs that are IGMP-enabled are guaranteed one multicast filter. You can always reboot the switch to recreate this configuration where each IGMP-enabled VLAN has a multicast filter.
|
|
|
![[NOTE: ]](images/note.gif) |
NOTE: Joined multicast traffic continues to be forwarded as usual. |
|
|
You must reboot the switch after configuring the per-VLAN filter.
Enabling the IGMP multicast filter
HP Switch(config)# igmp filter-unknown-mcast Command will take effect after saving configuration and reboot.
The following example shows the multicast traffic being flooded to all queriers on all VLANs; this is the default behavior. The igmp filter-unknown-mcast command has not been executed.
In the following example, igmp filter-unknown-mcast has been configured. The multicast traffic only goes to the querier on the same VLAN as the multicast server.
To display the status of IGMP multicast filtering use the show ip igmp command. If the IGMP Filter Unknown Multicast setting is different from the IGMP Filter Unknown Multicast status, a reboot is required to activate the desired setting. This setting will then be reflected in the status.
IGMP unknown multicast filter setting being enabled but not yet activated
HP Switch(config)# show igmp filter-unknown-mcast IGMP Filter Unknown Multicast: Enabled IGMP Filter Unknown Multicast Status: Disabled
To display information about IGMP multicast filtering by interface, use the show ip igmp command.
When a network has a border router connecting a PIM-SM domain to a PIM-DM domain, the routers that are completely within the PIM-DM domain have no way to discover multicast flows in the PIM-SM domain. When an IGMP join occurs on a router entirely within the PIM-DM domain for a flow that originates within the PIM-SM domain, it is never forwarded to the PIM-SM domain.
The IGMP proxy is a way to propagate IGMP joins across router boundaries. The proxy triggers the boundary router connected to a PIM-SM domain to query for multicast flows and forward them to the PIM-DM domain. IGMP needs to be configured on all VLAN interfaces on which the proxy is to be forwarded or received, and PIM-DM must be running for the traffic to be forwarded.
You can configure an IGMP proxy on a selected VLAN that will forward IP joins (reports) and IGMP leaves to the upstream border router between the two multicast domains. You must specify the VLANs on which the proxy is enabled as well as the address of the border router to which the joins are forwarded.
The following steps illustrate how to flood a flow from the PIM-SM domain into the PIM-DM domain when an IGMP join for that flow occurs in the PIM-DM domain. See figure IGMP proxy example.
-
Configure Routing Switch 1 with the IGMP proxy forwarding function to forward joins toward Border Router 1; in addition, configure Routing Switch 1 to forward joins from VLAN 1 toward Border Router 2, as is VLAN 4 on Routing Switch 3.
-
Configure VLAN 2 on Routing Switch 2 to forward joins toward Border Router 1.
-
When the host connected in VLAN 1 issues an IGMP join for multicast address 235.1.1.1, the join is proxied by Routing Switch 1 onto VLAN 2 and onto VLAN 4. The routing information table in Routing Switch 1 indicates that the packet to Border Router 1 and Border Router 2 is on VLAN 2 and VLAN 4, respectively.
-
Routing Switch 2 then proxies the IGMP join into VLAN 3, which is connected to Border Router 1.
-
Border Router 1 uses PIM-SM to find and connect to the multicast traffic for the requested traffic. The traffic is flooded into the PIM-DM network where it is routed to the original joining host.
-
Additionally, the join was proxied from Routing Switch 3 to Border Router 2. At first, both border routers will flood the traffic into the PIM-DM domain. However, PIM-DM only forwards multicasts based on the shortest reverse path back to the source of the traffic as determined by the unicast routing tables (routing FIB.) Only one multicast stream is sent to the joining host. This configuration provides a redundant in case the first fails.
-
You can configure up to 12 multicast domains, which indicate a range of multicast addresses and the IP address of the PIM-SM/PIM-DM border router.
-
You must give each domain a unique name, up to 20 characters.
-
The IP address of the border router may be the same or different in each configured domain.
-
Duplicate IGMP joins are automatically prevented, or leaves that would remove a flow currently joined by multiple hosts.
-
Range overlap allows for redundant connectivity and the ability for multicasts to arrive from different border routers based on the shortest path back to the source of the traffic.
-
The configured domain names must be associated with one or more VLANs for which the proxy joins are to be done.
-
All routers in the path between the edge router receiving the initial IGMP packets and the border router have to be configured to forward IGMP using IGMP proxy.
-
All upstream and downstream interfaces using IGMP proxy forwarding require IGMP and PIM to be enabled.
-
You must remove all VLAN associations with the domain name before that domain name can be removed.
-
The appropriate border routers must be used for each VLAN, or PIM-DM will not forward the traffic. This could occur when multiple border routers exist. It may be necessary to configure multiple overlapping domains if the multicast source address can generate the same multicast address and have different best paths to the PIM-DM domain.
|
|
|
![[CAUTION: ]](images/caution.gif) |
CAUTION: Be careful to avoid configuring a IGMP forward loop, because this would leave the VLANs in a joined state forever once an initial join is sent from a host. For example, a join is issued from the host in VLAN 2 and Routing Switch 2 will proxy the join onto VLAN 1. Routing Switch 3 will then proxy the join back onto VLAN 2 and increment its internal count of the number of joins on VLAN 2. Even after the host on VLAN 2 issues a leave, the proxy join will continue to remain and refresh itself each time a query occurs on VLAN 2. This type of loop could be created with multiple routers if an IGMP proxy is allowed to get back to the VLAN of the router that initially received the IGMP join from a host; see Proxy loop scenario. |
|
|
