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 for0 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
1 comments:
Very nice and informative blog. It really helped me add some useful points in my knowledge. Thanks for sharing!
Also check out these amazing Cisco products if you want:
C3850-NM-8-10G
C3850-NM-2-10G
C9200L-24P-4X-E
Post a Comment