Configuration Note RGMP - Router-port Group Management Protocol last updated 04/03/2000 Background CGMP and IGMP Snooping are two existing features to help in restricting multicast traffic in switched networks to those ports that do need to receive the multicast traffic. Both lead to dynamic establishment of multicast group specific forwarding in switches that support these features. Both features do only restrict traffic on those ports of !!! switches to which only hosts are connected. They do not restrict traffic !!! to ports to which at least one multicast router is connected. Any !!! multicast traffic sourced by any router or host on the switched network !!! will be forwarded to all router ports with just IGMP snooping or CGMP (or both) enabled. This is an intrinsic limitation of both mechanisms: IGMP snooping will never allow for this because it relies on snooping of messages that only hosts - but no routers - send. CGMP was never designed to do this. In situations where multiple routers are connected to a switched backbone, IGMP Snooping or CGMP will thus not have the desired effect of reducing multicast traffic and increasing the internal bandwidth through the use of a switch in the network. Example: +---------+ +---------+ +---------+ +-----------+ | source1 |----| router1 | | router2 |----| receiv1/a | +---------+ +---------+ +---------+ +-----------+ | | | <------ | <----- Ports will unnecessarily | | receive traffic from source2 | | +-----------+ +-------------+ +-----------+ | receiv1/b |--------| switch |----------| receiv2/b | +-----------+ +-------------+ +-----------+ | | | <------ | <----- Ports will unnecessarily | | receive traffic from source1 | | +---------+ +---------+ +---------+ +-----------+ | source2 |----| router3 | | router4 |----| receiv2/a | +---------+ +---------+ +---------+ +-----------+ In this example, receiv1/a and receiv1/b want only to receive the multicast traffic from source1 and receiv2/a and receiv2/b want only to receive the multicast traffic from source2. router1...router4 and receiv1/b,receiv2/b are connected to a switch which is running IGMP snooping or CGMP. While receiv1/b and receiv2/b will profit from IGMP snooping or CGMP in that they will not receive the multicast traffic from source2 or source1, which they don't want to receive, all the routers will unnecessarily receive both traffic from source1 and source2 (unless they are the one router sending the traffic into the switched ethernet). CGMP and IGMP Snooping are designed for typical access networks to which many hosts are connected but only one or two (if redundant) routers, which forward traffic from and to those hosts. In these networks the above limitation has no large impact, because the routers will usually have to forward the multicast traffic from or out of the network anyhow. The switches in these networks do predominantly serve to increase the aggregate bandwidth between the hosts (servers and clients for example), and to limit unwanted traffic to hosts. IGMP Snooping or CGMP serve well to achieve this effect for multicast traffic. In switched backbone networks or exchange points, where predominantly routers are connected with each others, the switches are expected to increase the aggregate bandwidth between those routers and to limit unwanted traffic to these routers. Large amount of multicast traffic may thus lead to unexpected congestion on the router ports and to a waste of CPU-cycles in the routers needed to ignore the unwanted multicast traffic. RGMP is a new protocol by cisco to allow restricting multicast traffic to router ports. To effectively restrict traffic, it must be supported both by the switch(es) and the routers in the network. Benefits RGMP will allow routers to receive (almost) only that multicast traffic that it needs. Other multicast traffic will not be forwarded to the router. This frees the router from the effort to drop the unwanted multicast traffic. Especially on low-end routers, where multicast forwarding is done in software, this can free ressources in the router. By removing unwanted traffic from links to routers, this bandwidth can be used by more wanted bandwidth. Sticking to the picture above, if all routers were connected with 100 Mbps full duplex and no RGMP was enabled, then router1 and router3 could only forward traffic each with 50Mbps, because at this point, router2 and router4 would each receive the sum of all traffic, which is 100 Mbps. Router2 for example could not send traffic, because then router4 would need to get more than 100Mbps. With RGMP, not only could router1 and router2 send traffic with 100 Mbps each, but even router2 and router4 could also send traffic if that would only to be forwarded to router1 and router3 respectively. So in the best case, each of the four routers could send full 100Mbps if it had just one other router interested in the traffic. Although quite unlikely in the real world, the maximum speedup achievable with RGMP is thus N, where N is the number of routers connected. [ Note: IGMP-Snooping or CGMP do not really provide this speedup benefit, because the sum of all multicast traffic in a network with just CGMP or IGMP-Snooping must still be seen by the connected routers. IGMP-Snooping and CGMP do thus only remove unwanted multicast traffic from host ports !] Supported Platforms RGMP in routers is supported starting with IOS 12.0(10)S/SC and 12.1(1)E/EX on all platforms supported by those releases. It will also be supported starting with 12.1(3)T. RGMP in switches is supported starting with release 5.4 on Catalyst 5000/6000 series switches that can run this version. Restrictions Cisco Switches do provide RGMP as a global configuration option, applying to all VLANs. On cisco routers, RGMP is a per-interface configuration option. The following restrictions do ONLY apply to networks (VLANs), in which RGMP is active. This is the case when at least one router and one switch connected to the network (VLAN) have RGMP enabled on this network. If RGMP is just enabled on one or more switches in a network, but on no router interface connected to this network, then RGMP is passive and does not have any effect. The restrictions do not apply in this case! It is thus safe to configure RGMP globally on switches, but activate it only one specific VLANs by configuring it on the appropriate router interfaces. + Sparse-mode only. RGMP does currently only support PIM sparse-mode, but not PIM dense-mode. It does explicitly support the two AutoRP groups in dense-mode by not restricting traffic to those groups but flooding it to all router port. "pim sparse-dense-mode" can and should thus be configured. If other groups beside the AutoRP groups are configured for dense-mode their traffic will not be correctly forwarded via router ports enabled for RGMP. + Needs IGMP Snooping enabled. For RGMP to be operational on a switch, IGMP snooping must be enabled on the switch. This does not say that there need to be any hosts profiting from IGMP snooping in the network. The reason is simply that in Cisco switches, RGMP is realized as a layered functionality on top of IGMP snooping. + One router per port. To effectively restrict multicast traffic to a router via RGMP, an RGMP enabled router must be connected to a separate port of an RGMP enabled switch. This should even without RGMP be customary on routers connecting to backbone switches. If more than one router or router(s) and hosts are connected to via the same port of an RGMP enabled switch, then this will lead to malfunctioning of multicast suppression on this port because IGMP messages from hosts and/or RGMP messages from more than one router will conflict with each others. To keep RGMP simple, fast, efficient and easy to maintain, it was designed not to try to handle these situations. + No traffic restrictions for routers without RGMP. RGMP does support routers that do not speak RGMP. RGMP will only restrict traffic to ports on which it detects an RGMP enabled router. If a non RGMP enabled router is detected on a port then that port will simply receive all multicast traffic. Note: Routers that do not route IP Multicast over the network at all, but just unicast are not considered to be routers in this context - due to IGMP-Snooping they will not get any multicast traffic except when they act as a multicast host and join specific groups via IGMP. This is because IGMP-snooping and RGMP do only consider those ports to be router ports where PIM Hello packets are received from (or for the case of IGMP-Snooping packets from other multicast routing protocols). + No directly connected sources. RGMP does not support directly connected sources in the network. A directly connected source will send traffic into the network without signaling this via RGMP or PIM. This traffic will not be received by an RGMP enabled router unless the router already requested receipt of that group via RGMP due to some other (remote) source sending to that group. Especially if the PIM-DR is RGMP enabled, then this source will not be known in the PIM domain because the PIM-DR will not register for that source. This restriction does not only apply to hosts, but also to those functions in routers that do source multicast traffic. This includes the tools "ping" and "mtrace" and multicast application that may source multicast traffic, like UDPTN. Functions that only receive multicast traffic (like the sdr listener support in IOS) are no problem. + Directly connected receivers supported. RGMP does support directly connected receiver in the network. Traffic to these receivers will be restricted by IGMP snooping (which as stated above must always be active if RGMP is enabled), or if the receiver is a router itself via PIM and RGMP. + CGMP not supported with RGMP CGMP is not supported in networks where RGMP is enabled on routers. Enabling RGMP and CGMP on a router interface is mutually exclusive. If RGMP is enabled on an interface, CGMP will be silently disabled or vice versa. + Limitations on switches without RGMP If switches without RGMP are to be used in a network with RGMP, then they should only be deployed as leafs, connecting to one or more (receiver only) hosts and one uplink port to an RGMP enabled switch. The following properties of RGMP are the same as for IGMP Snooping, these are really limitations of the IP Multicast to MAC mapping and the switches being used: + RGMP does only restrict traffic based on the multicast group, not based on the senders IP address. + If (spanning tree) topology changes happen in the network, state is not flushed as it is with CGMP. + RGMP does not restrict traffic for the multicast groups 224.0.0.x (x = 0...255). Thus (for example) PIMv2 BSR can be used via a RGMP controlled network. + RGMP in Cisco switches does effectively operate on MAC addresses and not on the IP multicast addresses. As more than one IP multicast addresses are mapped to one MAC address (see RFC1112), no restriction of traffic will happen between traffic to different IP multicast groups that map to the same MAC address (this is not a limitation of the RGMP protocol, which does operate on IP multicast addresses, but a limitation on the hardware of switches which map those to MAC addresses). Example: If multicast traffic to the groups 224.1.1.1 and 224.129.1.1 is in the network, routers will always receive traffic to both groups, even though they only want to receive traffic to one of the two groups. + The capability of switches to restrict traffic is limited by their appropriate CAM tables. Each multicast group active in the network takes up some of that resources. If the CAM tables are used up because there are too many multicast groups active in the network, then traffic for further multicast groups will be flooded and not restricted. CAM table sizes allow for several thousands of multicast groups. Configuration Tasks 1. Establish an appropriate topology on the virtual lans where you want to utilize RGMP (one router one port, no source hosts). 2. Enable RGMP on the switches: Configure in privileged mode: Switch> (enable) set igmp enable Switch> (enable) set rgmp enable The first command enables IGMP Snooping, the second RGMP. Enabling these features on a switch is a global configuration. !!! RGMP will have no effect in those VLANs where there is not at !!! least a single router also configured for RGMP. 3. Enable RGMP on the routers: On each (vlan-)interface that has a topology appropriate for RGMP (see 1.), enable RGMP in interface configuration mode: router(config)# ip rgmp 4. Monitor RGMP on a switch: Use the following commands on a switch to obtain information about the operations of RGMP: Switch> (enable) show rgmp group [] [] Switch> (enable) show rgmp group count [] Switch> (enable) show rgmp statistics [] Switch> (enable) clear rgmp statistics Switch> (enable) show multicast router [igmp|rgmp] [/] [] Switch> (enable> show multicast protocol status 5. Monitor RGMP on a router: router# show ip igmp interface ... Ethernet1/0 is up, line protocol is up Internet address is 9.1.80.195/24 IGMP is enabled on interface Current IGMP version is 2 RGMP is enabled .... router(enable)# debug ip rgmp [] !!! Note: Do not enable RGMP in a router unless it is on a separate port !!! of an RGMP enabled switch. If another router shares the same port, !!! or if the directly connected switch is not RGMP enabled but only a !!! switch further down in the network is, then the non-RGMP enabled router !!! may be blacked out from multicast traffic [ Catalyst switches may in !!! the future be able to detect this situation or be configured to disable !!! RGMP on a per port base to handle it]. Theory of operations Restricting traffic to host ports with eavesdropping on IGMP packets (IGMP Snooping) proved to be a simple solution that did nor require new software in hosts. A similar solution for router ports that does not require specific software support from routers "PIM Snooping" would be nice, but proved to be too complex: 1. The switches would have to keep track of all PIM routing information of all routers to learn when a router has pruned to all sources for a multicast group. 2. The switches would need to keep track of unicast routing information to map from the IP multicast source address in PIM Join/Prunes to the appropriate L3 ports. 3. Snooping PIM messages is much more complex for a switch than IGMP messages. For this reason, RGMP does also need support by the routers, extracting the information from the readily available unicast and PIM multicast routing tables and creating easily understandable commands to the switches. RGMP knows 4 types of messages sent by routers supporting RGMP as MAC layer multicast packets. These messages are received by the directly connected RGMP enabled switch and if necessary are appropriately forwarded between RGMP enabled switches to establish the required forwarding state on the path towards the originating router. Description Action ------------------------------------------------------------------------ Hello This packet is sent complementary to a PIM hello message. if RGMP is enabled. The switch knows that a router is connected to a port via the PIM hello packet, and it know that the router is RGMP enabled via this RGMP Hello packet. Bye This message is sent if RGMP is disabled, to let the switch know that it should not restrict multicast traffic to this router anymore. Join This message is sent to indicate that the router wants to receive traffic destined to . It is sent for example complementary to a PIM join sent out on the interface. Leave This message is sent to indicate that the router does not want to receive any more traffic destined to arriving on this interface. It is sent for example complementary to sending the PIM prune message for the last (S,G)/(*,G) entry that the router was joined to via this interface, or when timing out this state. Note: RGMP messages are sent to multicast group 224.0.0.25. This address has been assigned by IANA to carry messages from routers to switches. Router Command Reference [ See the switch command reference version 5.4 or higher for the commands on switches. ] Interface configuration command: ip rgmp Enable the router-ports group management protocol (RGMP) at the given interface. no ip rgmp Disable RGMP at the interface. This is the default. RGMP is only supported on 802 type media (ethernet, etc.). Debug command: debug ip rgmp [] Enable RGMP debugging. If a group name or address is specified, then only the debugging message applicable to the subject group will be displayed. Only last command is effective. no debug ip rgmp Disable RGMP debugging. Example Output: RGMP: Sending a Hello packet on Ethernet1/0 RGMP: Sending a Bye packet on Ethernet1/0 RGMP: Sending a Join packet on Ethernet1/0 for group 224.5.5.5 RGMP: Sending a Leave packet on Ethernet1/0 for group 224.5.5.5 Glossary AutoRP - AutoRP is a cisco protocol to disseminate multicast-group to RP mappings in a PIM sparse-mode domain. AutoRP passes traffic on the multicast groups 224.0.1.39 and 224.0.1.40 which needs to be received by all PIM routers in a domain. If PIM sparse-dense mode is configured, these two groups are by default run in dense-mode. CGMP - Cisco Group Management Protocol: A protocol developed by cisco to restrict multicast traffic in networks by legacy switches that can not differentiate between IP multicast data traffic and associated IP IGMP packets and are thus unable to use IGMP Snooping with multicast hardware forwarding performance. IGMP - Internet Group Management Protocol: An Internet standards track protocol used by hosts to announce membership in multicast groups. Current version is IGMPv2. IGMP Snooping - A mechanism to restrict IP multicast traffic in switched networks towards host ports. Requires switches to efficiently intercept IGMP packets. Although IGMP Snooping is implemented by several vendors, there is no formal specification of functionality. RGMP - "Router-port Group Management Protocol". A cisco protocol to support switches in deriving dynamic forwarding information to restrict multicast traffic to ports connected to routers within a switched network. .