News Update :

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

graphics/ccc.gif 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

Share this Article on :

0 comments:

Post a Comment

 

© Copyright Cisco elearning 2010 -2011 | Design by Herdiansyah Hamzah | Published by Borneo Templates | Powered by Blogger.com.