Internet Group Management Protocol (IGMP) and Cisco Group Management Protocol (CGMP)

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).

IGMPv1 Operation

The purpose of IGMP is to report end-system application group memberships to multicast routers in its vicinity, which easily can be identified via 224.0.0.2. 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 224.0.0.1 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.

NOTE

On Linux systems, you can alter the default IGMP group membership limit of 20 via the net.ipv4.igmp_max_memberships sysctl parameter.

IGMPv2 Operation

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 224.0.0.2 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.

Example 14-1. Linux IGMP Status Information


[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      224.2.2.2

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      224.0.0.1

eth0            1      224.0.0.2

eth0            1      224.0.0.4

eth0            1      224.0.0.1

eth1            1      224.2.2.2

eth1            1      224.0.0.2

eth1            1      224.0.0.4

eth1            1      224.0.1.1

eth1            1      224.0.0.1



[root@callisto:~#] ip mroute

(192.168.2.7, 224.2.2.2)         Iif: eth1       Oifs: eth0

(192.168.1.2, 224.2.2.2)         Iif: eth1       Oifs: eth0

(192.168.1.1, 224.2.2.2)         Iif: eth1       Oifs: eth0

(192.168.1.1, 224.0.1.1)         Iif: eth1



[root@callisto:~#] ip maddr

1:      lo



        inet  224.0.0.1

2:      eth0

        link  01:00:5e:00:00:02

        link  01:00:5e:00:00:04

        link  01:00:5e:00:00:01

        inet  224.0.0.2

        inet  224.0.0.4

        inet  224.0.0.1

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  224.2.2.2

        inet  224.0.0.2

        inet  224.0.0.4

        inet  224.0.1.1

        inet  224.0.0.1

Example 14-2. BSD IGMP Status Information


[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     224.2.2.2            4230    0    1:1

 192.168.1.1     224.2.2.2            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 Implementations

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.

Cisco IOS Multicast Router Configuration and IGMP/CGMP Operation

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 224.2.2.2 statement is just an example of manual IGMP configuration. IGMP-relevant show and debug sequences conclude Example 14.3.

Example 14-3. Cisco IOS General Multicast Setup and IGMP Configuration


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 224.2.2.2

 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 224.2.2.2

 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 224.2.2.2

 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

224.0.1.111      Ethernet0                00:16:51  00:01:09  192.168.7.254

224.0.1.40       Ethernet0                00:16:49  00:01:05  192.168.7.254

224.2.2.2        Ethernet1                00:16:51  00:02:02  192.168.14.254

224.2.2.2        Ethernet0                00:16:51  00:01:02  192.168.7.254

224.2.2.2        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 224.0.1.40 on Ethernet1

01:11:07: IGMP: Send v2 Report for 224.0.1.40 on Ethernet1

01:11:07: IGMP: Received v2 Report on Ethernet1 from 192.168.14.254 for 224.0.1.40

01:11:07: IGMP: Received Group record for group 224.0.1.40, mode 2 from 192.168.14.254 for

 0 sources

01:11:07: IGMP: Updating EXCLUDE group timer for 224.0.1.40

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):

      224.2.2.2(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):

      224.0.1.40(1)  224.2.2.2(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: 224.0.0.1 224.0.0.2 224.0.0.22 224.0.0.13

  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 Group Management Protocol (CGMP)

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 Cisco IOS Multicast Routing Monitor (MRM)

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:

Manager
Test sender
Test receiver

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.