By design, a conventional Layer 2 LAN switch is supposed to flood multicast and broadcast traffic within the broadcast domain (VLAN). This results in wasted resources when no recipients of multicast traffic are present on its physical ports, uplinks, or VLAN trunks.
In a switched network, you can restrain multicast traffic in two ways:
IGMP snooping? This is a feature of modern Layer 2/3 switches.
CGMP? CGMP is used on Cisco Layer 2 switches.
Availability depends greatly on the model and OS version of your Cisco equipment. I am not aware of any noncommercial UNIX implementations that implement IGMP snooping. (It only makes sense on switches.) Cisco IOS architecture defaults to IGMPv2, whereas Linux and BSD operating systems implement IGMPv1/v2 (with early IGMPv3 packages available).
The purpose of IGMP is to report end-system application group memberships to multicast routers in its vicinity, which easily can be identified via 184.108.40.206. The protocol has evolved from v1 up to v3.
IGMPv1 works as follows: When a host joins a particular group for the first time, it sends an unsolicited group membership report to the relevant group address. In addition, multicast routers periodically submit IGMP query messages to 220.127.116.11 that trigger IGMP group membership reports from all multicast-enabled hosts. IGMP protocol packets are always sent with a TTL of 1 and are not supposed to be forwarded. If a router does not hear from a registered host for a while, it assumes the host has left the group. If the requesting router receives no reports, the group is removed ("pruned") from the distribution tree. Therefore, this concept is referred to as flood and prune.
On Linux systems, you can alter the default IGMP group membership limit of 20 via the net.ipv4.igmp_max_memberships sysctl parameter.
IGMPv2 offers an important improvement over IGMPv1: explicit leave_group_messages that reduce the timeout-based leave group latency of IGMPv1 from several minutes to a few seconds, which dramatically reduces traffic on busy network segments. Join latencies are of no concern in this picture. Hosts send explicit leave_group_messages to 18.104.22.168 when they want to leave a subscribed group immediately. Examples 14-1 and 14-2 demonstrate IGMP-relevant commands and their output for Linux and BSD. The highlighted text emphasizes the mapping between multicast IP and MAC addresses.
[root@callisto:~#] netstat -g IPv6/IPv4 Group Memberships Interface RefCnt Group --------------- ------ --------------------- lo 1 ALL-SYSTEMS.MCAST.NET eth0 1 ALL-ROUTERS.MCAST.NET eth0 1 DVMRP.MCAST.NET eth0 1 ALL-SYSTEMS.MCAST.NET eth1 1 22.214.171.124 eth1 1 ALL-ROUTERS.MCAST.NET eth1 1 DVMRP.MCAST.NET eth1 1 NTP.MCAST.NET eth1 1 ALL-SYSTEMS.MCAST.NET [root@callisto:~#] netstat -gn IPv6/IPv4 Group Memberships Interface RefCnt Group --------------- ------ --------------------- lo 1 126.96.36.199 eth0 1 188.8.131.52 eth0 1 184.108.40.206 eth0 1 220.127.116.11 eth1 1 18.104.22.168 eth1 1 22.214.171.124 eth1 1 126.96.36.199 eth1 1 188.8.131.52 eth1 1 184.108.40.206 [root@callisto:~#] ip mroute (192.168.2.7, 220.127.116.11) Iif: eth1 Oifs: eth0 (192.168.1.2, 18.104.22.168) Iif: eth1 Oifs: eth0 (192.168.1.1, 22.214.171.124) Iif: eth1 Oifs: eth0 (192.168.1.1, 126.96.36.199) Iif: eth1 [root@callisto:~#] ip maddr 1: lo inet 188.8.131.52 2: eth0 link 01:00:5e:00:00:02 link 01:00:5e:00:00:04 link 01:00:5e:00:00:01 inet 184.108.40.206 inet 220.127.116.11 inet 18.104.22.168 3: eth1 link 01:00:5e:02:02:02 link 01:00:5e:00:00:02 link 01:00:5e:00:00:04 link 01:00:5e:00:01:01 link 01:00:5e:00:00:01 inet 22.214.171.124 inet 126.96.36.199 inet 188.8.131.52 inet 184.108.40.206 inet 220.127.116.11
[root@castor:~#] netstat ?g ?f inet Virtual Interface Table Vif Thresh Rate Local-Address Remote-Address Pkts-In Pkts-Out 0 1 0 192.168.2.7 1373 5237 1 1 0 192.168.7.7 1007 5174 2 1 0 192.168.80.1 0 0 IPv4 Multicast Forwarding Cache Origin Group Packets In-Vif Out-Vifs:Ttls 192.168.2.7 18.104.22.168 4230 0 1:1 192.168.1.1 22.214.171.124 2347 0 1:1 [root@castor:~#] netstat -gs -f inet IPv4 multicast forwarding: 7898 multicast forwarding cache lookups 3 multicast forwarding cache misses 3 upcalls to mrouted 0 upcall queue overflows 0 upcalls dropped due to full socket buffer 0 cache cleanups 3 datagrams with no route for origin 0 datagrams arrived with bad tunneling 0 datagrams could not be tunneled 1006 datagrams arrived on wrong interface 0 datagrams selectively dropped 0 datagrams dropped due to queue overflow 0 datagrams dropped for being too large
IGMPv3 allows joining a specific group with the addition of source-specific granularity, via source-specific include/exclude reports (S,G). This is the reason why it is often mentioned in an SSM context (single-source multicast). When a multicast router receives an IGMPv3 (S,G) join report, it must be able to build the source-specific tree with a source-aware multicast routing protocol such as PIM-SM. The IGMPv2 leave group message was extended to support source-specific operation.
If you want to play with it on Linux, try the Cisco implementation at http://www.multicasttech.com/igmpv3/ or http://www-sop.inria.fr/planete/Hitoshi.Asaeda/igmpv3/ for NetBSD, or http://www.kloosterhof.com/~wilbert/igmpv3.html for FreeBSD.
Example 14-3 shows the Cisco IOS configuration that enables scar to communicate with mrouted DVMRP gateways via the PIM-DVMRP compatibility mechanism. In addition, the configuration includes an example DVMRP tunnel setup to communicate with ganymed regardless of possible non-multicast-capable gateways in its topological path. The ip igmp join-group 126.96.36.199 statement is just an example of manual IGMP configuration. IGMP-relevant show and debug sequences conclude Example 14.3.
scar# show running-config ... ! ip multicast-routing ip multicast route-limit 100 ! interface Loopback0 ip address 10.0.0.1 255.255.255.255 ! interface Tunnel0 ip unnumbered Loopback0 ip pim sparse-dense-mode ip igmp join-group 188.8.131.52 tunnel source 192.168.14.254 tunnel destination 192.168.1.254 tunnel mode dvmrp ! interface Ethernet0 bandwidth 10000 ip address 192.168.7.254 255.255.255.0 no ip proxy-arp ip pim sparse-dense-mode ip load-sharing per-packet no ip route-cache ip igmp join-group 184.108.40.206 ip cgmp no ip mroute-cache media-type 10BaseT random-detect ! interface Ethernet1 bandwidth 10000 ip address 192.168.14.254 255.255.255.0 no ip proxy-arp ip pim sparse-dense-mode ip load-sharing per-packet no ip route-cache ip ospf network broadcast ip igmp join-group 220.127.116.11 ip cgmp no ip mroute-cache media-type 10BaseT random-detect ! ... scar# show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 18.104.22.168 Ethernet0 00:16:51 00:01:09 192.168.7.254 22.214.171.124 Ethernet0 00:16:49 00:01:05 192.168.7.254 126.96.36.199 Ethernet1 00:16:51 00:02:02 192.168.14.254 188.8.131.52 Ethernet0 00:16:51 00:01:02 192.168.7.254 184.108.40.206 Tunnel0 00:16:51 stopped 0.0.0.0 scar# debug ip igmp IGMP debugging is on 01:11:01: IGMP: Send v2 general Query on Ethernet1 01:11:01: IGMP: Set report delay time to 5.6 seconds for 220.127.116.11 on Ethernet1 01:11:07: IGMP: Send v2 Report for 18.104.22.168 on Ethernet1 01:11:07: IGMP: Received v2 Report on Ethernet1 from 192.168.14.254 for 22.214.171.124 01:11:07: IGMP: Received Group record for group 126.96.36.199, mode 2 from 192.168.14.254 for 0 sources 01:11:07: IGMP: Updating EXCLUDE group timer for 188.8.131.52 01:11:30: IGMP: Previous querier for Ethernet0 has timed out. 01:11:30: IGMP: v2 querier for Ethernet0 is this system. 01:11:30: IGMP: Send v2 init Query on Ethernet0 scar# show ip igmp interface tunnel 0 Tunnel0 is up, line protocol is up Interface is unnumbered. Using address of Loopback0 (10.0.0.1) IGMP is enabled on interface Current IGMP host version is 2 Current IGMP router version is 2 IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query count is 2 Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 1 joins, 0 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 IGMP querying router is 0.0.0.0 (this system) DVMRP/mrouted neighbors present for 00:27:02 [version mrouted 3.255] [flags: GPM] 2 DVMRP neighbor up transitions since system restart 6 DVMRP routes + 0 poison-reverse routes received in last 00:01:00 2/4 Unicast/DVMRP routes last advertised by DVMRP DVMRP output report delay is 100 ms, with burst size of 2 Multicast groups joined by this system (number of users): 184.108.40.206(1) scar# show ip igmp interface ethernet 0 Ethernet0 is up, line protocol is up Internet address is 192.168.7.254/24 IGMP is enabled on interface Current IGMP host version is 2 Current IGMP router version is 2 CGMP is enabled on interface IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query count is 2 Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 2 joins, 0 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 192.168.7.254 (this system) IGMP querying router is 192.168.7.7 DVMRP/mrouted neighbors present for 02:27:24 DVMRP interface ordinal mask: FFFFFFFD DVMRP neighbors: 192.168.7.7, ordinal: 1, [version mrouted 3.255] [flags: GPM] 1 DVMRP neighbor up transitions since system restart 0 DVMRP routes + 0 poison-reverse routes received in last 00:00:02 2/4 Unicast/DVMRP routes last advertised by DVMRP DVMRP output report delay is 100 ms, with burst size of 2 Multicast groups joined by this system (number of users): 220.127.116.11(1) 18.104.22.168(1) scar# show ip interface ethernet 0 Ethernet0 is up, line protocol is up Internet address is 192.168.7.254/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Multicast reserved groups joined: 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 Outgoing access list is not set Inbound access list is not set Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is disabled IP fast switching on the same interface is disabled IP Flow switching is disabled IP CEF switching is disabled IP Fast switching turbo vector IP multicast fast switching is disabled IP multicast distributed fast switching is disabled IP route-cache flags are No CEF Router Discovery is enabled IP output packet accounting is disabled IP access violation accounting is disabled TCP/IP header compression is disabled RTP/IP header compression is disabled Probe proxy name replies are disabled Policy routing is disabled Network address translation is disabled WCCP Redirect outbound is disabled WCCP Redirect inbound is disabled WCCP Redirect exclude is disabled BGP Policy Mapping is disabled IP multicast multilayer switching is disabled
Cisco CGMP runs between Cisco switches and Cisco routers and limits the forwarding of IP multicast packets to only those switch ports that serve IP multicast recipients. These hosts automatically join and leave groups that receive IP multicast traffic, and the switch dynamically changes its forwarding behavior according to these requests after consulting the subnet's/VLAN's router via CGMP. In contrast to IGMP snooping, the switch does not need to provide its own intelligence to intercept IGMP, but instead relies on the intelligence of Cisco multicast routers. CGMP can be configured per router interface with the ip cgmp command. There are no router show commands available for CGMP; however, debug ip cgmp provides sufficient details. CGMP leave processing is a new feature of this protocol that uses the leave group message extension of IGMPv2.
The MRM feature is a Cisco IOS component that is useful for multicast deployments and surveillance. MRM consists of three components, which usually reside on three different routers:
A detailed discussion of this versatile tool goes beyond the scope of this chapter. Consult the Cisco.com article "Using IP Multicast Tools" (IOS 12.2) for a detailed discussion.