Content

| 7.2 |  | Examining Multicast in a Multilayer Switched Network |
| 7.2.8 |  | IGMP version 1, 2 and 3 interoperability |

The first possible combination of versions might involve hosts with a mix of versions with a version 1 router. All IGMP operations in this scenario are driven by the version that the query router uses. When there is such a combination, the hosts must use version 1 messages. The router does not understand version 2 membership reports, nor does it understand version 2 leave messages.

A second case exists when the router supports IGMPv2, but hosts use IGMPv1. Although the router understands more message types than the hosts, it ultimately uses only version 1 messages. When the version 2 router receives the version 1 membership report, it remembers that they are present and uses only version 1 membership queries. Version 1 queries use the group address 0.0.0.0 and do not generate group-specific queries. If it generated group-specific queries, the version 1 hosts would not recognize the message and would not know how to respond.

What if there are both version 1 and version 2 hosts on the segment with a version 2 router? As in the previous case, the router must remember that there are Version 1 hosts and must, therefore, issue version 1 membership queries. Additionally, if any of the version 2 hosts send a leave message, the router must ignore the leave notification. It ignores the message because it must still issue general queries in case a version 1 member is still active on the segment.

If two routers attach to the segment where one supports version 1 and the other version 2, the version 2 router must be administratively configured as a version 1 router. The version 1 router has no way to detect the presence of the version 2 router. Because the two versions use different methods of selecting the query router, they might not reliably agree on the query router.

IGMP version 3
IGMP Version 3 (IGMPv3) is the next step in the evolution of IGMP. IGMPv3 adds support for "source filtering," which enables a multicast receiver host to signal to a router the groups from which it wants to receive multicast traffic, and from which sources this traffic is expected. This membership information enables Cisco IOS software to forward traffic from only those sources from which receivers requested the traffic. Among other things, this added feature can prevent rogue multicast servers from monopolizing the bandwidth on a segment; receivers must specifically request the servers from which multicast traffic is desired. IGMPv3 helps conserve bandwidth by allowing hosts to specify the sources of multicast traffic.

IGMPv3 supports applications that explicitly signal sources from which they want to receive traffic. With IGMPv3, receivers signal membership to a multicast host group in the following two modes:

- INCLUDE mode In this mode, the receiver announces membership to a host group and provides a list of source addresses (the INCLUDE list) from which it wants to receive traffic.
- EXCLUDE mode In this mode, the receiver announces membership to a multicast group and provides a list of source addresses (the EXCLUDE list) from which it does not want to receive traffic. The host will receive traffic only from sources whose IP addresses are not listed in the EXCLUDE list. To receive traffic from all sources, which is the behavior of IGMPv2, a host uses EXCLUDE mode membership with an empty EXCLUDE list.

As shown in Figure , Host H1 wishes to join group 224.1.1.1 but only wishes to receive traffic from Source 1.1.1.1. The IGMPv3 host can signal the designated router, R3, that it is only interested in multicast traffic from Source 1.1.1.1 for Group 224.1.1.1. Router R3 could then potentially prune the unwanted source, 2.2.2.2.