The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This module describes how to implement multicast admission control in an IP multicast network. Multicast admission control features are configured on multicast-enabled routers to prevent control plane overload, ensure proper resource allocation, and provide multicast Call Admission Control (CAC) capabilities.
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information Table at the end of this document.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
As the popularity of network video applications grows among consumers, admission control functions--which govern transmission and reception of multicast traffic based on available network resources--are vital. Without admission control, some users may receive degraded multicast streams, rendering programs unwatchable, and others may receive a "Network Busy" message or nothing at all as network resources are overtaxed. Network admission control is important in maintaining a high quality of experience for digital video consumers.
The goals of multicast admission control features, therefore, are as follows:
The Cisco IOS software supports the following multicast admission control features:
The ip multicast route-limit command allows for the configuration of global and per MVRF state limiters, which impose limits on the number of multicast routes (mroutes) that can be added to the global table or to a particular Multicast Virtual Routing and Forwarding (MVRF) table.
The ip msdp sa-limit command allows for the configuration of MSDP SA limiters, which impose limits on the number of Multicast Source Discovery Protocol (MSDP) Source Active (SA) messages that can be cached on a router.
For more information about MSDP, see the " Using MSDP to Interconnect Multiple PIM-SM Domains " module.
This feature allows for the configuration of IGMP state limiters, which impose limits on mroute states resulting from Internet Group Management Protocol (IGMP) membership reports (IGMP joins).
This feature allows for the configuration of per interface mroute state limiters, which impose mroute state limits for different access control list (ACL)-classified sets of multicast traffic on an interface.
This feature allows for the configuration of bandwidth-based multicast CAC policies, which allow for bandwidth-based CAC on a per interface basis.
These admission control features may be invoked by service providers and enterprise network administrators based on different criteria, including the service package an end user has purchased or the privileges an enterprise user is entitled to.
The ip multicast route-limit command allows for the configuration of global and per MVRF mroute state limiters, which impose limits on the number of mroutes that can be added to the global table or to a particular MVRF table, respectively.
Global mroute state limiters are used to limit the number of mroutes that can be added to the global table on a router. Configuring a global mroute state limiter can protect a router in the event of a multicast DoS attack (by preventing mroutes from overrunning the router).
Per VRF mroute state limiters are used to limit the number of mroutes that can be added to an MVRF table on a Multicast VPN (MVPN) provider edge (PE) router. Configuring per MVRF mroute state limits can be used to ensure the fair sharing of mroutes between different MVRFs on an MVPN PE router.
Global and per MVRF mroute state limiters are configured using the ip multicast route-limit command in global configuration mode. The syntax of the ip multicast route-limit command is as follows:
ip multicast [vrf vrf-name] route-limit limit [threshold]
Issuing the ip multicast route-limitcommand without the optional vrf keyword and vrf-name arguments configures a global mroute state limiter. The optional vrf keyword and vrf-name arguments are used with the ip multicast limit command to configure per MVRF mroute state limiters.
Note |
When configuring global and per VRF mroute state limiters, you can only configure one limit for the global table and one limit per MVRF table. |
The value specified for the required limit argument defines the maximum number of mroutes that can be added to either the global table or a particular MVRF table, respectively.
Note |
Global and per MVRF mroute state limiters operate independently and can be used alone or together, depending upon the admission control requirements of your network. |
In addition, for both global and per MVRF mroute state limiters, the optional threshold argument is available to set mroute threshold limits.
The mechanics of global and per MVRF mroute state limiters are as follows:
% MROUTE-4-ROUTELIMIT : <current mroute count> exceeded multicast route-limit of <mroute limit value>
% MROUTE-4-ROUTELIMITWARNING : multicast route-limit warning <current mroute count> threshold <mroute threshold value>
Warning messages continue to be generated until the number of mroutes exceeds the configured limit or until the number of mroute states falls below the configured mroute threshold limit.
The ip msdp sa-limit command allows for the configuration of MSDP SA limiters, which impose limits on the number of MSDP Source Active (SA) messages that an MSDP-enabled router can accept (can be cached) from an MSDP peer. This command provides a means to protect an MSDP-enabled router from denial of service (DoS) attacks.
MSDP SA limiters are configured using the ip msdp sa-limit command in global configuration mode. The syntax of the ip msdp sa-limit command is as follows:
ip msdp [vrf vrf-name] sa-limit {peer-address | peer-name} sa-limit
For the required peer-address argument or peer-name argument, specify either the MSDP peer address or MSDP peer name of the peer to be limited.
For the required sa-limit argument, specify the maximum number of SA messages that can be accepted (cached) from the specified peer. The range is from 1 to 2147483646.
Note |
In an MVPN environment, the optional vrf keyword and vrf-name argument are used to specify the MVRF associated with the MSDP peer. When an MVRF is specified, the MSDP SA limiter is applied to the specified MSDP peer associated with the specified MVRF. |
%MSDP-4-SA_LIMIT: SA from peer <peer address or name>, RP <RP address> for <mroute> exceeded sa-limit of <configured SA limit for MSDP peer>
The IGMP State Limit feature allows for the configuration of IGMP state limiters, which impose limits on mroute states resulting from IGMP membership reports (IGMP joins) on a global or per interface basis. Membership reports exceeding the configured limits are not entered into the IGMP cache. This feature can be used to prevent DoS attacks or to provide a multicast CAC mechanism in network environments where all the multicast flows roughly utilize the same amount of bandwidth.
Note |
IGMP state limiters impose limits on the number of mroute states resulting from IGMP, IGMP v3lite, and URL Rendezvous Directory (URD) membership reports on a global or per interface basis. |
IGMP state limiters are configured using the ip igmp limit command:
ip igmp limit number
For the required number argument, specify a global limit on the number of IGMP membership reports that can be cached. The range is from 1 to 64000.
ip igmp limit number [except access-list]
For the required number argument, specify a limit on the number of IGMP membership reports that can be cached for the specified interface. The range is from 1 to 64000.
Use the optional except access-list keyword and argument to prevent groups or channels from being counted against the interface limit. A standard or an extended ACL can be specified.
Note |
When configuring IGMP state limiters, you can only configure one global limit on a router and one limit per interface. |
The mechanics of IGMP state limiters are as follows:
%IGMP-6-IGMP_GROUP_LIMIT: IGMP limit exceeded for <group (*, group address)> on <interface type number> by host <ip address>
or
%IGMP-6-IGMP_CHANNEL_LIMIT: IGMP limit exceeded for <channel (source address, group address)> on <interface type number> by host <ip address>
The Per Interface Mroute State Limit feature provides the capability to limit the number of mroute states on an interface for different ACL-classified sets of multicast traffic. This feature can be used to prevent DoS attacks or to provide a multicast CAC mechanism when all the multicast flows roughly utilize the same amount of bandwidth.
The Per Interface Mroute State Limit feature essentially is a complete superset of the IGMP State Limit feature (with the exception that it does not support a global limit). The Per Interface Mroute State Limit feature, moreover, is more flexible and powerful (albeit more complex) than the IGMP State Limit feature but is not intended to be a replacement for it because there are applications that suit both features.
The main differences between the Per Interface Mroute State Limit feature and the IGMP State Limit feature are as follows:
Note |
Although the PIM Interface Mroute State Limit feature allows you to limit both IGMP and PIM joins, it does not provide the capability to limit PIM or IGMP joins separately because it does not take into account whether the state is created as a result of an IGMP or PIM join. As such, the IGMP State Limit feature is more specific in application because it specifically limits IGMP joins. |
Both the IGMP State Limit and Per Interface Mroute State Limit features provide a rudimentary multicast CAC mechanism that can be used to provision bandwidth utilization on an interface when all multicast flows roughly utilize the same amount of bandwidth. The Bandwidth-Based CAC for IP Multicast feature, however, offers a more flexible and powerful alternative for providing multicast CAC in network environments where IP multicast flows utilize different amounts of bandwidth.
Note |
For more information about the Bandwidth-Based CAC for IP Multicast feature, see the Bandwidth-Based CAC for IP Multicast. |
The Per Interface Mroute State Limit feature is configured using the ip multicast limit command in interface configuration mode. An ip multicast limit command configured on an interface is called an per interface mroute state limiter. A per interface mroute state limiter is defined by direction, ACL, and maximum number of mroutes. Each per interface mroute state limiter maintains a counter to ensure that the maximum number of mroutes is not exceeded.
The following forms of the ip multicast limitcommand are available to configure per interface mroute state limiters:
This command limits mroute state creation for an ACL-classified set of traffic on an interface when the interface is an outgoing (egress) interface, and limits mroute outgoing interface list (olist) membership when the interface is an incoming (ingress) Reverse Path Forwarding (RPF) interface.
This type of per interface mroute state limiter limits mroute state creation--by accounting each time an mroute permitted by the ACL is created or deleted--and limits mroute olist membership--by accounting each time that an mroute olist member permitted by the ACL is added or removed.
Entering this form of the command (that is, with no optional keywords) is equivalent to specifying the ip multicast limit rpfand ip multicast limit out forms of the command.
This command limits mroute state creation for an ACL-classified set of multicast traffic on an incoming (RPF) interface that is directly connected to a multicast source by accounting each time that an mroute permitted by the ACL is created or deleted.
This command limits mroute olist membership on an outgoing interface for an ACL-classified set of multicast traffic by accounting each time that an mroute olist member permitted by the ACL is added or removed.
This command limits mroute state creation for an ACL-classified set of multicast traffic on an incoming (RPF) interface by accounting each time an mroute permitted by the ACL is created or deleted.
For the required access-list argument, specify the ACL that defines the IP multicast traffic to be limited on an interface. A standard or extended ACL can be specified. Standard ACLs can be used to define the (*, G) state to be limited on an interface. Extended ACLs can be used to define the (S, G) state to be limited on an interface. Extended ACLs also can be used to define the (*, G) state to be limited on an interface, by specifying 0.0.0.0 for the source address and source wildcard--referred to as (0, G)--in the permit or deny statements that compose the extended access list.
The mechanics of per interface mroute state limiters are as follows:
Note |
A per interface mroute state limiter always allows the deletion of an mroute or the removal of an interface from the olist. In those cases, the respective per interface mroute state limiter decreases the counter by the value of the cost multiplier. In addition, RPF changes to an existing mroute are always allowed (in order to not affect existing traffic). However, a per interface mroute state limiter only allows the creation of an mroute or the addition of an mroute olist member if adding the cost does not exceed the maximum number of mroutes permitted. |
The Bandwidth-Based CAC for IP Multicast feature enhances the Per Interface Mroute State Limit feature by implementing a way to count per interface mroute state limiters using cost multipliers (referred to as bandwidth-based multicast CAC policies). This feature can be used to provide bandwidth-based multicast CAC on a per interface basis in network environments where the multicast flows utilize different amounts of bandwidth.
Bandwidth-based multicast CAC policies are configured using the ip multicast limit cost command in global configuration mode. The syntax of the ip multicast limit cost command is as follows:
ip multicast [vrf vrf-name] limit cost access-list cost-multiplier
For the required access-list argument, specify the ACL that defines the IP multicast traffic for which to apply a cost. A standard or extended ACL can be specified. Standard ACLs can be used to define the (*, G) state. Extended ACLs can be used to define the (S, G) state. Extended ACLs also can be used to define the (*, G) state, by specifying 0.0.0.0 for the source address and source wildcard--referred to as (0, G)--in the permit or deny statements that compose the extended access list.
For the required cost-multiplier argument, specify the cost value to be applied to mroutes that match the ACL associated with the bandwidth-based multicast CAC policy. The range is 0 to 2147483647.
Note |
In an MVPN environment, the optional vrf keyword and vrf-name argument are used to specify that the cost be applied only to mroutes associated with MVRF specified for the vrf-name argument. |
The mechanics of bandwidth-based multicast CAC policies are as follows:
Perform the following optional tasks to configure global and per MVRF mroute state limiters.
Global mroute state limiters are used to limit the number of mroutes that can be added to the global table on a router. Configuring a global mroute state limiter can protect a router in the event of a multicast DoS attack (by preventing mroutes from overrunning the router).
Per VRF mroute state limiters are used to limit the number of mroutes that can be added to an MVRF table on an MVPN PE router. Configuring per MVRF mroute state limits can be used to ensure the fair sharing of mroutes between different MVRFs on an MVPN PE router.
Note |
Global and per MVRF mroute state limiters operate independently and can be used alone or together, depending upon the admission control requirements of your network. |
Note |
When configuring global and per VRF mroute state limiters, you can only configure one limit for the global table and one limit per MVRF table. |
The following tasks explain how to configure global and per MVRF mroute state limiters:
Perform this task to limit the number of mroutes that can be added to the global table. States for mroutes that exceed the global mroute limit will not be created.
Proceed to the Configuring Per MVRF Mroute State Limiters task to configure per MVRF mroute state limiters on a PE router.
Perform this optional task to configure per MVRF mroute state limiters to limit the number of mroutes that can be added to a particular MVRF table. This feature can be configured on a PE router to ensure the fair sharing of mroutes between different MVRFs on the router. States for mroutes that exceed the per MVRF mroute limiter are not created.
Perform this optional task to limit the overall number of SA messages that the router can accept from specified MSDP peers. Performing this task protects an MSDP-enabled router from distributed DoS attacks.
Note |
We recommend that you perform this task for all MSDP peerings on the router. |
This task assumes that you are running MSDP and have configured MSDP peers using the tasks described in the " Using MSDP to Interconnect Multiple PIM-SM Domains " module.
Perform the following tasks to configure global and per interface IGMP state limiters. IGMP state limiters are used to limit the number of mroute states resulting from IGMP membership reports (IGMP joins) on a global or per interface basis. Membership reports exceeding the configured limits are not entered into the IGMP cache. IGMP state limiters can be used to prevent DoS attacks or to provide a multicast CAC mechanism in network environments where all the multicast flows roughly utilize the same amount of bandwidth.
Note |
IGMP state limiters impose limits on the number of mroute states resulting from IGMP, IGMP v3lite, and URD membership reports on a global or per interface basis. |
The following tasks explain how to configure global and per interface IGMP state limiters:
Note |
When configuring IGMP state limiters, you can only configure one global limit on a router and one limit per interface. |
Perform this optional task to configure a global IGMP state limiter.
Command or Action | Purpose | |
---|---|---|
|
Example: Router> enable |
Enables privileged EXEC mode.
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
|
Example: Router(config)# ip igmp limit 150 |
Configures a global limit on the number of mroute states resulting from IGMP membership reports (IGMP joins).
|
|
Example: Router(config-if)# end |
Ends the current configuration session and returns to privileged EXEC mode. |
|
Example: Router# show ip igmp groups |
(Optional) Displays the multicast groups with receivers that are directly connected to the router and that were learned through IGMP. |
Proceed to the Configuring Per Interface IGMP State Limiters task to configure per interface IGMP state limiters.
Perform this optional task to configure per interface IGMP state limiters.
Command or Action | Purpose | |
---|---|---|
|
Example: Router> enable |
Enables privileged EXEC mode.
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
|
Example: Router(config)# interface GigabitEthernet0/0 |
Enters interface configuration mode.
|
|
Example: Router(config-if)# ip igmp limit 100 |
Configures a per interface limit on the number of mroutes states created as a result of IGMP membership reports (IGMP joins).
|
|
|
-- |
|
Example: Router(config-if)# end |
Ends the current configuration session and returns to privileged EXEC mode. |
|
Example: Router# show ip igmp interface |
(Optional) Displays information about the status and configuration of IGMP and multicast routing on interfaces.
|
|
Example: Router# show ip igmp groups |
(Optional) Displays the multicast groups with receivers that are directly connected to the router and that were learned through IGMP. |
Perform this task to configure per interface mroute state limiters. Configuring per interface mroute state limiters can be used to prevent DoS attacks or to provide a multicast CAC mechanism to control bandwidth, when all the multicast flows roughly utilize the same amount of bandwidth.
Command or Action | Purpose | |
---|---|---|
|
Example: Router> enable |
Enables privileged EXEC mode. |
|
Example: Router# configure terminal |
Enters global configuration mode. |
|
Example: Router(config)# interface GigabitEthernet0/0 |
Enters interface configuration mode for the specified interface type and number. |
|
Example: Router(config-if)# ip multicast limit 15 100 |
Configures per interface mroute state limiters.
|
|
|
|
|
|
-- |
|
|
-- |
|
Example: Router(config-if)# end |
Exits interface configuration mode, and enters privileged EXEC mode. |
Proceed to the Monitoring Per Interface Mroute State Limiters and Bandwidth-Based Multicast CAC Policies task to monitor per interface mroute state limiters.
Perform this optional task to configure bandwidth-based multicast CAC policies. Bandwidth-based multicast CAC policies provide the capability to assign costs to mroutes that are being limited by per interface mroute state limiters. This task can be used to provide bandwidth-based multicast CAC on a per interface basis in network environments where the multicast flows utilize different amounts of bandwidth. Bandwidth-based multicast CAC policies can be applied globally or per MVRF.
Note |
You can omit Steps 3 to 7 if you have already configured the per interface mroute state limiters for which to apply costs. |
Command or Action | Purpose | |
---|---|---|
|
Example: Router> enable |
Enables privileged EXEC mode. |
|
Example: Router# configure terminal |
Enters global configuration mode. |
|
Example: Router(config)# interface GigabitEthernet 0/0 |
Enters interface configuration mode for the specified interface type and number. |
|
Example: Router(config-if)# ip multicast limit acl-test 100 Example:
|
Configures mroute state limiters on an interface.
|
|
|
|
|
|
|
|
|
-- |
|
|
-- |
|
Example: Router(config-if)# exit |
Exits interface configuration mode, and returns to global configuration mode. |
|
Example: Router(config)# ip multicast limit cost acl-MP2SD-channels 4000 |
Applies costs to per interface mroute state limiters.
|
|
|
-- |
|
Example: Router(config-if)# end |
Exits interface configuration mode, and enters privileged EXEC mode. |
Proceed to the Monitoring Per Interface Mroute State Limiters and Bandwidth-Based Multicast CAC Policies task to monitor bandwidth-based multicast CAC policies.
Perform this optional task to monitor per interface mroute state limiters and bandwidth-based multicast CAC policies.
Step 1 | enable Enables privileged EXEC mode. Enter your password if prompted. Example:
Router> enable
|
Step 2 | debug ip mrouting limits [group-address] Use this command to display debugging information about configured per interface mroute state limiters and bandwidth-based multicast CAC policies. Specify the optional group-address argument to restrict the output to display only per interface mroute state limiter events related to a particular multicast group. The following output is from the debug ip mrouting limits command. The output displays the following events:
Example:
Router# debug ip mrouting limits
MRL(0): incr-ed acl 'rpf-list' to (13 < max 32), [n:0,p:0], (main) GigabitEthernet0/0, (10.41.0.41, 225.30.200.60)
MRL(0): decr-ed acl 'out-list' to (10 < max 32), [n:0,p:0], (main) GigabitEthernet0/0, (*, 225.40.202.60)
MRL(0): Add mroute (10.43.0.43, 225.30.200.60) denied for GigabitEthernet0/2, acl std-list, (16 = max 16)
MRL(0): incr-ed limit-acl `rpf-list' to (12 < max 32), cost-acl 'cost-list' cost 2, [n:0,p:0], (main) GigabitEthernet0/0, (10.41.0.41, 225.30.200.60)
MRL(0): decr-ed limit-acl `out-list' to (8 < max 32), cost-acl 'cost-list'' cost 2, [n:0,p:0], (main) GigabitEthernet0/0, (*, 225.40.202.60) |
Step 3 | show ip multicast limit type number Use this command to display counters related to mroute state limiters configured on the interfaces on the router. Specify the optional type number arguments to restrict the output to displaying only statistics about per interface mroute state limiters configured on the specified interface. For each per interface mroute state limiter shown in the output, the following information is displayed:
The following is sample output from the show ip multicast limit command with the type number arguments. In this example, information about mroute state limiters configured on Gigabit Ethernet interface 0/0 is displayed. Example:
Router# show ip multicast limit GigabitEthernet 0/0
Interface GigabitEthernet 0/0
Multicast Access Limits
out acl out-list (1 < max 32) exceeded 0
rpf acl rpf-list (6 < max 32) exceeded 0
con acl conn-list (0 < max 32) exceeded 0
|
Step 4 | clear ip multicast limit [type number] Use this command to reset the exceeded counter for per interface mroute state limiters. The exceeded counter is displayed in the output of the show ip multicast limitcommand. This counter tracks the total number of times that the limit configured for the per interface mroute state limiter has been exceeded. Each time an mroute is denied due to the configured limit being reached, the exceeded counter is increased by a value of 1. Specify the optional type number arguments to reset the exceeded counter for only per interface mroute state limiters configured on the specified interface. The following example shows how to reset exceeded counters for per interface mroute state limiters configured on Gigabit Ethernet interface 0/0: Example:
clear ip multicast limit interface GigabitEthernet 0/0
|
The following example shows how to configure a global mroute state limiter. In this example, a global mroute state limiter is configured with an mroute limit of 1500 and an mroute threshold limit of 1460.
ip multicast route-limit 1500 1460
The following is a sample mroute threshold warning message. The output shows that the configured mroute threshold limit of 1460 has been exceeded by one mroute.
%MROUTE-4-ROUTELIMITWARNING : multicast route-limit warning 1461 threshold 1460
The following is a sample mroute exceeded warning message. The output shows that the configured mroute limit of 1500 has been exceeded by one mroute. States for mroutes that exceed the configured limit for the global mroute state limiter are not created on the router.
%MROUTE-4-ROUTELIMIT : 1501 routes exceeded multicast route-limit of 1500
The following example shows how to configure an MSDP SA limiter. In this example, an MSDP SA limiter is configured that imposes a limit of 100 SA messages from the MSDP peer at 192.168.10.1.
ip msdp sa-limit 192.168.10.1 100
The following example shows how to configure IGMP state limiters to provide multicast CAC in a network environment where all the multicast flows roughly utilize the same amount of bandwidth.
This example uses the topology illustrated in the figure.
Figure 1 | IGMP State Limit Example Topology |
In this example, a service provider is offering 300 Standard Definition (SD) TV channels. Each SD channel utilizes approximately 4 Mbps.
The service provider must provision the Gigabit Ethernet interfaces on the PE router connected to the Digital Subscriber Line Access Multiplexers (DSLAMs) as follows: 50% of the link's bandwidth (500 Mbps) must be available to subscribers of the Internet, voice, and video on demand (VoD) service offerings while the remaining 50% (500 Mbps) of the link's bandwidth must be available to subscribers of the SD channel offerings.
Because each SD channel utilizes the same amount of bandwidth (4 Mbps), per interface IGMP state limiters can be used to provide the necessary CAC to provision the services being offered by the service provider. To determine the required CAC needed per interface, the total number of channels is divided by 4 (because each channel utilizes 4 Mbps of bandwidth). The required CAC needed per interface, therefore, is as follows:
500Mbps / 4Mbps = 125 mroutes
Once the required CAC is determined, the service provider uses the results to configure the per IGMP state limiters required to provision the Gigabit Ethernet interfaces on the PE router. Based on the network's CAC requirements, the service provider must limit the SD channels that can be transmitted out a Gigabit Ethernet interface (at any given time) to 125. Configuring a per interface IGMP state limit of 125 for the SD channels provisions the interface for 500 Mbps of bandwidth, the 50% of the link's bandwidth that must always be available (but never exceeded) for the SD channel offerings.
The following configuration shows how the service provider uses a per interface mroute state limiter to provision interface Gigabit Ethernet 0/0 for the SD channels and Internet, Voice, and VoD services being offered to subscribers:
interface GigabitEthernet0/0 description --- Interface towards the DSLAM --- . . . ip igmp limit 125
The following example shows how to configure per interface mroute state limiters to provide multicast CAC in a network environment where all the multicast flows roughly utilize the same amount of bandwidth.
This example uses the topology illustrated in the figure.
Figure 2 | Per Interface Mroute State Limit Example Topology |
In this example, a service provider is offering 300 SD TV channels. The SD channels are being offered to customers in three service bundles (Basic, Premium, and Gold), which are available to customers on a subscription basis. Each bundle offers 100 channels to subscribers, and each channel utilizes approximately 4 Mbps of bandwidth.
The service provider must provision the Gigabit Ethernet interfaces on the PE router connected to DSLAMs as follows: 50% of the link's bandwidth (500 Mbps) must be available to subscribers of their Internet, voice, and VoD service offerings while the remaining 50% (500 Mbps) of the link's bandwidth must be available to subscribers of their SD channel bundle service offerings.
For the 500 Mbps of the link's bandwidth that must always be available to (but must never be exceeded by) the subscribers of the SD channel bundles, the interface must be further provisioned as follows:
Because each SD channel utilizes the same amount of bandwidth (4 Mbps), per interface mroute state limiters can be used to provide the necessary CAC to provision the services being offered by the service provider. To determine the required CAC needed per interface, the number of channels for each bundle is divided by 4 (because each channel utilizes 4 Mbps of bandwidth). The required CAC needed per interface, therefore, is as follows:
Once the required CAC required per SD channel bundle is determined, the service provider uses the results to configure the mroute state limiters required to provision the Gigabit Ethernet interfaces on the PE router for the services being offered to subscribers behind the DSLAMs:
The service provider then configures three ACLs to be applied to per interface mroute state limiters. Each ACL defines the SD channels for each SD channel bundle to be limited on an interface:
These ACLs are then applied to per interface mroute state limiters configured on the PE router's Gigabit Ethernet interfaces.
For this example, three per interface mroute state limiters are configured on Gigabit Ethernet interface 0/0 to provide the multicast CAC needed to provision the interface for the SD channel bundles being offered to subscribers:
The following configuration shows how the service provider uses per interface mroute state limiters to provision Gigabit Ethernet interface 0/0 for the SD channel bundles and Internet, Voice, and VoD services being offered to subscribers:
interface GigabitEthernet0/0 description --- Interface towards the DSLAM --- . . . ip multicast limit out acl-basic 75 ip multicast limit out acl-premium 25 ip multicast limit out acl-gold 25
The following example shows how to configure bandwidth-based multicast CAC policies to provide multicast CAC in a network environment where the multicast flows utilize different amounts of bandwidth.
This example uses the topology illustrated in the figure.
Figure 3 | Bandwidth-Based CAC for IP Multicast Example Topology |
In this example, three content providers are providing TV services across a service provider core. The content providers are broadcasting TV channels that utilize different amounts of bandwidth:
The service provider needs to provision the fair sharing of bandwidth between these three content providers to its subscribers across Gigabit Ethernet interfaces. The service provider, thus, determines that it needs to provision each Gigabit Ethernet interface on the PE router connected to the DSLAMs as follows:
The service provider then configures three ACLs:
Because the content providers are broadcasting TV channels that utilize different amounts of bandwidth, the service provider needs to determine the values that need to be configured for the per interface mroute state limiters and bandwidth-based multicast CAC policies to provide the fair sharing of bandwidth required between the content providers.
Prior to the introduction of the Bandwidth-Based CAC for IP Multicast feature, per interface mroute state limiters were based strictly on the number of flows. The introduction of cost multipliers by the Bandwidth-Based CAC for IP Multicast feature expands how per interface mroute state limiters can be defined. Instead of defining the per interface mroute state limiters based on the number of multicast flows, the service provider looks for a common unit of measure and decides to represent the per interface mroute state limiters in kilobits per second (Kbps). The service provider then configures three per interface mroute state limiters, one per content provider. Because the link is a Gigabit, the service provider sets each limit to 250000 (because 250000 Kbps equals 250 Mbps, the number of bits that service provider needs to provision per content provider).
The service provider needs to further provision the fair sharing of bandwidth between the content providers, which can be achieved by configuring bandwidth-based multicast CAC policies. The service provider decides to create four bandwidth-based CAC policies, one policy per channel based on bandwidth. For these policies, the service provider configures the following ACLs:
For each policy, a cost multiplier (represented in Kbps) is defined for each ACL that is based on the bandwidth of the channels defined in the ACL:
The following configuration example shows how the service provider used per interface mroute state limiters with bandwidth-based multicast CAC policies to provision Gigabit Ethernet interface 0/0 for the fair sharing of bandwidth required between the three content providers:
! ip multicast limit cost acl-MP2SD-channels 4000 ip multicast limit cost acl-MP2HD-channels 18000 ip multicast limit cost acl-MP4SD-channels 1600 ip multicast limit cost acl-MP4HD-channels 6000 ! . . . ! interface GigabitEthernet0/0 ip multicast limit out acl-CP1-channels 250000 ip multicast limit out acl-CP2-channels 250000 ip multicast limit out acl-CP3-channels 250000 !
The following sections provide references related to configuring multicast admission control.
Related Topic |
Document Title |
---|---|
Overview of the IP multicast technology area |
" IP Multicast Technology Overview " module |
Concepts, tasks, and examples for configuring an IP multicast network using PIM |
" Configuring a Basic IP Multicast Network " module |
Concepts, tasks, and examples for using MSDP to interconnection multiple PIM-SM domains |
" Using MSDP to Interconnect Multiple PIM-SM Domains " module |
Multicast commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples |
Cisco IOS IP Multicast Command Reference |
Standards |
Title |
---|---|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature. |
-- |
MIBs |
MIBs Link |
---|---|
No new or modified MIBs are supported by this feature. |
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: |
RFCs |
Title |
---|---|
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature. |
-- |
Description |
Link |
---|---|
The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies. To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds. Access to most tools on the Cisco Support website requires a Cisco.com user ID and password. |
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Table 1 | Feature Information for Configuring Multicast Admission Control |
Feature Name |
Releases |
Feature Information |
---|---|---|
Bandwidth-Based CAC for IP Multicast |
12.2(33)SRB 12.4(15)T 12.2(33)SXI |
The Bandwidth-Based CAC for IP Multicast feature enhances the Per Interface Mroute State Limit feature by implementing a way to count per interface mroute state limiters using cost multipliers. This feature can be used to provide bandwidth-based CAC on a per interface basis in network environments where the multicast flows utilize different amounts of bandwidth. The following command was introduced by this feature: ip multicast limit cost. |
IGMP State Limit |
12.2(14)S 12.2(15)T 15.0(1)S |
The IGMP State Limit feature introduces the capability to limit the number of mroute states resulting from IGMP membership states on a per interface or global basis. Membership reports exceeding the configured limits are not entered into the IGMP cache. This feature can be used to prevent DoS attacks or to provide a multicast CAC mechanism in network environments where all the multicast flows roughly utilize the same amount of bandwidth. The following commands were introduced or modified by this feature: ip igmp limit(global), ip igmp limit(interface), show ip igmp interface. |
Per Interface Mroute State Limit |
12.3(14)T 12.2(33)SRB 12.2(33)SXI |
The Per Interface Mroute State Limit feature provides the capability to limit the number of mroute states on an interface for different ACL-classified sets of multicast traffic. This feature can be used to prevent DoS attacks, or to provide a multicast CAC mechanism in network environments where all the multicast flows roughly utilize the same amount of bandwidth. The following commands were introduced or modified by this feature: clear ip multicast limit, debug ip mrouting limits, ip multicast limit, show ip multicast limit. |
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.