Configuration Note "ip multicast rate-limit" Rate limiting for IP Multicast traffic 06/2001 ----------------------------------------- Release history 11/27/2001 - Fixed policying URL, added MIB support information 06/2001 - Initial version Cisco IOS provides different mechanisms to rate-limit IP multicast traffic. This config note explains the "ip multicast rate-limit" command. Other options to limit IP Multicast (and IP Unicast traffic) include the "ip rate-limit" command from the CAR (Committed Access Rate) or modular QoS feature set. Content: Description Description of the command like you would find it on CCO Status Discussion of the status of the command and why the QoS command "rate-limit" should be preferred. Functional description Detailed description of the implementation of the command for a better understanding of it's benefits and limitations Operational implications Lists the most important operational implications, eg: benefits and limitations of the feature implementation. Example configuration Explanation of how to configure "ip multicast rate-limit" and how to replace the per-interface version with "rate-limit" from CAR. Platform support Notes on support and non-support of "ip multicast rate-limit" on different platforms. Interoperability with Bidir-PIM ------------------------------------------------------------------------- Description To rate-limit IP Multicast traffic across a particular interface, configure the following command in interface configuration mode: [no] ip multicast rate-limit in | out [video] | [whiteboard] [group-list ] [source-list ] [] This command limits the rate with which IP multicast traffic can be received or sent across an interface. The "in" and "out" parameters select whether the command applies to received or to sent ip multicast packets on this interface. Rate-limiting can be configured simultaneously for incoming and outgoing packets. The argument selects the rate in kilobits/second to which matching traffic will be limited. The default value for is 0, in which case all ip multicast packets matched by this command will be dropped, eg: the command then works like an access list filtering out matching packets. The "group-list " and "source-list " arguments select a set of (*,G) and (S,G) mroute states to which the command is to be applied. If no such argument is given, then the commands limit will be applied to the aggregate amount of ip multicast traffic in or out of this interface which is not covered by a more specific ip multicast rate-limit command with a "group-list" or "source-list". If the "group-list" or "source-list" argument is given, then the configured limit is applied to each of the matching (*,G) and (S,G) multicast states independently, eg: The configured limit in the command does not apply to the aggregate amount of traffic matched by the command, but to each covered mroute individually. For each direction (in/out) and each interface, you can configure one per-interface limiter and arbitrarily many per mroute-state limiters. If an mroute-state is matched by more than one configured rate-limit command, then the first one matching will be used for this mroute-state. The order in which the configured "ip multicast rate-limit" are searched for for matching an mroute is the order in which the "ip multicast rate-limit" commands are entered. The "whiteboard" and "video" arguments limit rate-limiting to whiteboard or video packets. This only works for sessions in which the media (video/whiteboard) are announced via SDP. See below for further explanation on this parameter. ------------------------------------------------------------------------- Status The "ip multicast rate-limit" command was developed to provide some form of protection against excess traffic for the initial set of ip multicast application, the mbone tools. For current deployments, it is recommended to use the "rate-limit" command instead of "ip multicast rate-limit" for rate limiting on a per-interface basis and to use ip multicast rate-limiting only for per-mroute state rate limiting. Please see the example configuration section below and refer to the following URLs documenting the "rate-limit" command or the "police" command, which replaces "rate-limit" in newer IOS releases: Cisco IOS 12.0 Configuring Committed Access Rate: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/qos_c/qcpart1/qccar.htm Cisco IOS 12.1 Configuring Committed Access Rate: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcprt1/qcdcar.htm Cisco IOS 12.2 Configuring Committed Access Rate: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt1/qcfcar.htm Cisco IOS 12.2(2)T Traffic Policing: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t2/ftpoli.htm If you are using "ip multicast rate-limit" for a larger scale deployment, we would like to know about it, because we are evaluating how to continue support for this feature in upcoming IOS releases. Please send e-mail to "multicast-support@cisco.com". ------------------------------------------------------------------------- Functional description To better understand the operations of ip multicast rate-limiting, the following section will explain it's function in more detail. Ip multicast rate-limiting is a per-mroute rate-limiting, but as shown, it also can be configured to do simple per-interface rate-limiting of ip multicast traffic. Cisco IOS maintains the following data structures in conjunction with ip multicast rate-limiting: Per interface: IfBitsIn: Number of bits of ip multicast traffic received within the last second from this interface and and forwarded to at least one interface. IfBitsIn is reset to 0 once every second. Processing of IfBitsIn is independent of any configured ip multicast rate-limits. Incrementing of IfBitsIn happens after all copies of the packet have been sent out. Ip multicast packets that (for whatever reasons) are not sent out to at least one interface are not being counted. IfBitsOut: Number of bits of ip multicast traffic sent out over this interface within the last second. IfBpsOut is reset to 0 once every second. Processing of IfBitsOut is independent of any configured rate-limits. Whenever an ip multicast packet is sent out this interface, IfBitsOut is incremented by the size in bits of the packet. Incrementing of this counter happens after the packet is sent out this interface. Per mroute ( (*,G) and (S,G) ): MrouteBitsIn: Counter for the number of bits of ip multicast traffic received and forwarded for this mroute during the last second. MrouteBitsIn is reset to 0 once every second. Processing of MrouteBitsIn is independent of any configured rate-limits. This is basically like IfBitsIn but it only counts packets for the individual mroute. Note: For the purpose of ip multicast rate-limiting, there are no separate counters in Cisco IOS for the amount of traffic for a particular mroute output on an individual outgoing interface (eg: no equivalent to IfBitsOut)! (LimitBitsIn, LimitIfIn, InDstPort) This tuple is the actual ip multicast input rate-limiter for this mroute. LimitBitsIn is the rate-limit for this mroute in bits. LimitIfIn is boolean. If true, traffic for this mroute is accounted against an interface limit for multicast traffic and LimitBitsIn indicates this interface limit, else (LimitIfIn == FALSE), LimitBitsIn indicates the input rate limit solely for this multicast route. InDstPort is a valid UDP port number or 0. If no tuple is configured as a result of "ip multicast rate-limit in", the default values are (INF,FALSE,0), where INF is larger than any possible bit rate (eg: no limit). Per OIF entry of the mroute: (OutBitsLimit, OutIfLimit, OutDstPort) This tuple is the actual ip multicast output rate-limiter. OutBitsLimit is a number for the limit in units of bits. OutIfLimit is boolean, OutDstPort is a valid UDP port number or 0. If not configured as a result of "ip multicast rate-limit out" commands, the default values are (INF,FALSE,0). Similar to input rate-limiting, OutBitsLimit is the per-interface or per-multicast-route limit depending on OutIfLimit. When an ip multicast packet is received, the system will look up the matching (*,G) or (S,G) route to forward this packet. Before the router replicates the packet, it performs a couple of operations that may result in the packet being discarded: + RPF-check + Input access-list check + Ip multicast input rate-limiting + Input CAR + ... If a packet passed these checks, it will be replicated to all interfaces in the OIF-List (Outgoing Interfaces List) for the mroute entry. Each copy will be passed through a couple of output checks: + Output access-list check + Ip multicast output rate-limiting + Output CAR + ... Note: Versions of IOS may support additional features that may also lead to discarding of packets. The execution order of features within input and output checks is just for illustration purposes. The actual order is irrelevant to the function of ip multicast rate-limiting, because of the fact that the counters IfBitsIn, IfBitsOut and MrouteBitsIn are only incremented after a packet has passed all checks. Ip multicast input rate-limiting discards packets according to the mroute input rate-limiter if the following condition returns true: (PacketLen is the length of the packet in bits, and PacketPort is the destination UDP Port number in the packet, or 0 if not a UDP packet): ( LimitIfIn ? IfBitsIn + PacketLen > LimitBitsIn : MrouteBitsIn + PacketLen > LimitBitsIn ) && ( InDstPort == 0 || (InDstPort == PacketPort)) Ip multicast output rate-limiting discards packets in the very same fashion, according to the mroute output rate-limiter if the following condition returns true: ( LimitIfOut ? IfBitsOut + PacketLen > LimitBitsOut : MrouteBitsOut + PacketLen > LimitBitsOut ) && ( OutDstPort == 0 || (OutDstPort == PacketPort)) In result, ip multicast rate-limiting for packets matching an mroute can be configured to discard packets either if they exceed a limit set for the mroute or for the aggregate amount on the incoming or outgoing interface. For each mroute ((*,G) and (S,G)), the input rate-limiter (LimitBitsIn, LimitIfIn, InDstPort) and/or the per-OIF entry output rate-limiters (OutBitsLimit, OutIfLimit, OutDstPort) are updated against the configured "ip multicast rate-limit" commands if necessary: - Whenever the RPF interface of the mroute changes (input rate-limiter). - Whenever the configuration of "ip multicast rate-limit" commands is changed. - Whenever the OIF list changes. - Whenever the mroute is created. For the input rate-limiter of an mroute, all "ip multicast rate-limit in" commands are scanned, the first one found with "group-list " and/or "source-list " matching the (S,G) or (*,G) will be used. The limit configured there will become the LimitBitsIn for the entry and LimitIfIn will be set to false. If no matching per-mroute entry was found but a per-interface rate-limit was configured, the limit of that entry is taken for the LimitIfIn and LimitIfIn is set to true for this mroute. If the matching rate-limit entry also has a "whiteboard" or "video" argument, the router then looks into the SDR cache to see if it finds an SDR entry for the group G with a "whiteboard" or "video" session element defined. If it finds one, then it takes the UDP port number defined in that session description element and uses it as the InDstPort, else InDstPort stays 0. ------------------------------------------------------------------------- Operational implications + When matching the source address of mroutes via the "source-list" argument, the source argument for (*,G) mroute entries is the RP for this mroute or 0.0.0.0 for dense-mode routes. + You can not create different limits for different ports for the same group. If you use the "video" or "whiteboard" argument, only one port will be matched for a particular mroute entry. + If you want to input rate-limit traffic for a particular mroute per-mroute, you need to configure the rate-limit on the RPF interface of that mroute. + The per-mroute rate limit is primarily provided to allow limiting the amount of traffic a user can source into a single session like a video conference. As the limit applies to each mroute, this rate-limiter protects the session from a single user who inadvertently sets parameters wrong. It does not protect the network interfaces or the router against an excessive aggregate amount of multicast traffic. + You can limit traffic for some mroutes on a per mroute-basis and traffic for the remaining traffic in aggregate on their incoming or outgoing interface, but you can not use ip multicast rate-limit to apply both a per-mroute and a per-interface limit on the same packet in the same place (eg: you can limit per-interface on input and per-mroute on output, but not both on input or both on output). + Non-RPF traffic is ignored by multicast rate-limiting (eg: it is discarded anyhow and not counted, so the presence of non-RPF traffic will not influence the rate-limiting of traffic that is actually forwarded). + To match (*,G) states in a per-mroute state rate-limiter, the source-list argument (if present) must allow for the RP address of the (*,G) mroute. + If you want to use the "video" or "whiteboard" arguments to only limit traffic for those streams, you must enable "ip sdp listen" on at least one ip multicast enabled interface on the router to receive SDP session descriptions and the sessions that you want to rate-limit must have session descriptions with "video" or "whiteboard" media defined. + When using the "video" or "whiteboard" arguments, traffic is only restricted for packets matching the port number for that particular media of the group. This port number may of course be different for different groups (but not for different sources because the SDP description where the port number is taken from does not support this). The idea of this argument is to ensure that the audio-media of a session is not disturbed by excessive amount of video or whiteboard traffic. This works best in conjunction with the typical MBone-Tools like vic, vat and wb. + Because the rate-limiting is implemented by a fast and simple counter which is reset every second, the resulting rate-limiting translates into a per-second-burst-rate-limit. In result, the limit for a particular rate-limit must be set to the maximum allowed per-second burst-rate for a stream/interface. Example: A source sends 10 packets of size 512 in a burst every 10 seconds. The average of the source is 4 kbps, but the maximum per-second burst rate of the source can be up to 40 kbps. + If the "source-list" or "group-list" argument refers to an undefined access list, then this will be interpreted as an access list with one entry "permit any", eg: it will match all possible sources or groups. If only one of "source-list" or "group-list" arguments is defined, then the other one will also match/permit all possible values. + If you want to rate-limit the aggregate amount of traffic for a certain set of ip multicast traffic (eg: as defined by an extended access list), then you should use CAR. CAR works well together with IP multicast traffic and does also allow to better restrict bursty traffic by mean of committed-rate, burst-rate and burst-size parameters. What CAR can not do is that it does not allow to have per mroute-state rate limiters to be established dynamically. If you would want to do that, you would need to define a separate CAR rate limiter for each possible mroute-state in your network. With "ip multicast rate-limit" you can do aggregate rate limits only indirectly for a certain set of groups: You set the per-interface rate-limit for ip multicast on the interface to the value you want and then use per-mroute rate-limiting (with a large limit) to exclude traffic from limiting for those (S,G)/(*,G) that you do not want to get rate-limited. This of course only works for one aggregate set of traffic per interface. + To see what rate-limits are applied to traffic, use "show ip mroute": (10.0.1.51, 224.2.3.4), 2d06h/00:02:42, flags: CJT Incoming interface: FastEthernet0/0, RPF nbr 171.69.15.229, Mroute [Int] Limit 10 kbps [, port 6666] ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Outgoing interface list: FastEthernet1/0, Forward/Sparse, 2d06h/00:02:06, [Int] Limit 10 kbps [, port 6666] If rate-limiting on input and/or output interface was configured as a per-interface rate-limit, then the display will indicate this with "Int Limit...", otherwise no "Int" field will be shown. + There is no separate counter to show how many packets have been discarded in the router due to ip multicast rate-limiting. ------------------------------------------------------------------------- MIBs LimitBitsIn for each multicast route is reflected in the following CISCO-IPMROUTE-MIB element: enterprises.Cisco.ciscoExperiment.ciscoIpMRouteMIB. ciscoIpMRouteMIBObjects.ciscoIpMRoute.ciscoIpMRouteTable. ciscoIpMRouteEntry.ciscoIpMRouteInLimit2. .. LimitBitsOut for each multicast route is reflected in the following CISCO-IPMROUTE-MIB element: enterprises.Cisco.ciscoExperiment.ciscoIpMRouteMIB. ciscoIpMRouteMIBObjects.ciscoIpMRoute.ciscoIpMRouteNextHopTable. ciscoIpMRouteNextHopEntry.CiscoIpMRouteNextHopEntry. ciscoIpMRouteNextHopOutLimit. .... (, ) is the multicast routing entry, = 0.0.0.0 indicates a (*,) entry. is always 255.255.255.255, is , unless NBMA-mode is being used. The returned value is in Bits/Sec. If no limit is configured, the value returned is (-1), which for ciscoIpMRouteInLimit2 and ciscoIpMRouteNextHopOutLimit is expressed as (4294967295). The MIB element ciscoIpMRouteInLimit is obsolete. Note that only LimitsBitsIn/LimitsBitsOut are reflected in the CISCO-IPMROUTE-MIB. There are no MIB elements for the other rate-limiter variables like LimitIfIn/LimitIfOut. The ipMRouteInterfaceRateLimit elements from the IPMROUTE-MIB are not currently filled in by IOS but are set to 0 in any case. If rate-limiting via CAR is used, the CISCO-CAR-MIB can be used to retrieve information about the configured rate limits. See: ftp://ftp.cisco.com/pub/mibs/v2/CISCO-CAR-MIB.my ------------------------------------------------------------------------- Example configuration interface ethernet0 ip pim sparse-dense-mode ... ip multicast rate-limit in 600 ! [1] ip multicast rate-limit in group-list 10 video 30 ! [2] ip multicast rate-limit in group-list 20 30 ! [3] access-list 10 permit 224.2.10.0 0.0.0.255 access-list 20 permit 224.2.20.0 0.0.0.255 access-list 120 permit ip 10.0.0.0 0.255.255.255 224.2.0.0 0.0.255.255 The first ([1]) ip multicast rate-limit command will create one rate-limiter for all incoming traffic on interface ethernet0 with a value of 600 kbps. The second ([2]) ip multicast rate-limit command will result in the creation of a rate-limiter for each (S,G) and (*,G) entries in the multicast routing table, where G is in the range 224.2.10.0...224.2.10.255 and where the RPF interface for the (S,G) or (*,G) is interface ethernet0. Each of these rate-limiters has a value of 30 kbps and will only match if the UDP destination port number of packets is the port number assigned to video on each of these groups in the SDP descriptions. The third ([3]) ip multicast rate-limit command will result in the very same thing as ([2]) except that in this case all packets will be matched, independent of them being UDP and having a particular UDP destination port number. This works of course only because it is applied to a different set of groups than ([2]). Packets for multicast routes either matched by access-list 10 or 20 will not be accounted against the 600 kbps rate-limit set forth in ([1])!. In the following example, the per-interface ip multicast rate-limit command was replaced with a CAR rate-limit for all ip multicast traffic: interface ethernet0 ip pim sparse-dense-mode ... rate-limit input access-group 30 600000 3750 75000 \ conform-action transmit exceed-action drop ip multicast rate-limit in group-list 10 video 30 ! [2] ip multicast rate-limit in group-list 20 30 ! [3] access-list 10 permit 224.2.10.0 0.0.0.255 access-list 20 permit 224.2.20.0 0.0.0.255 access-list 30 permit 224.0.0.0 0.255.255.255 ! all multicast packets access-list 120 permit ip 10.0.0.0 0.255.255.255 224.2.0.0 0.0.255.255 The rate-limit command [1] will rate limit all ip-multicast traffic (224.0.0.0/4, access-list 30) arriving on the interface down to 600 kbps. The burst sizes are chosen so that the normal burst size will allow for a bucket of up to 1/20 of a second worth of 600kbps and the excess burst size allows for up to 1 second worth of 600kbps. This results in a similar, albeit of course much more accurate limiting than possible with "ip multicast rate-limit". By using "rate-limit", packets matching access lists 10 and 20 will now be limited twice: they will be for once limited against the interface limit of 600 kbps, and in addition, they will be limited against the per-mroute-state limit of 30 kbps as established via the configuration lines [2] and [3]. ------------------------------------------------------------------------- Platform support The simple algorithm allows for "ip multicast rate-limit" to be very fast in Cisco IOS systems that have a CPU switched software forwarding path. On these platforms the overhead for "ip multicast rate-limit" is lower than for CAR. This includes all platforms that only have ip multicast fast-switching (MFS) and/or ip multicast distributed fast-switching (MDFS) path, eg: all Cisco IOS platforms up to and including Cisco-7200 and Cisco-7500. On the Cisco-12000, "ip multicast rate-limit input" is also supported whenever IP Multicast traffic is CPU switched on the linecards, eg: on Eng0 and Eng1, and on Eng2 (currently). It is not supported for Eng4 linecards or for egress ("ip multicast rate-limit output"). On other platforms with hardware accelerated hardware forwarding paths, "ip multicast rate-limit" may not be supported in the hardware forwarding path but may revert forwarding to CPU fast-switching and should then be avoided (eg: Catalyst-6x00/Cisco-7600). On hardware accelerated platforms that do not support "ip multicast rate-limit" in their hardware accelerated multicast forwarding paths, you should instead use CAR (which is more likely available). ------------------------------------------------------------------------- Interoperability with Bidir-PIM To enable per-mroute rate-limiting for Bidir-PIM groups, a per-mroute rate-limiter must be defined on the RPF interface of the Bidir group (the interface towards the RP of that group). Per-interface rate-limiting does not operate correctly due to the chosen implementation. Upstream Bidir-PIM traffic will be rate limited against the rate-limiter for the Bidir group, which then refers to the RPF-interface IfBitsIn. In result, upstream traffic will potentially discarded if the input rate on the RPF-interface exceeds that interfaces configured rate-limit, but it will not get accounted against that interfaces traffic (which is correct), so in result, it will not be rate-limited at all by itself (CSCdu00245). .