Feedback
|
Table Of Contents
Prerequisites for RADIUS-Based Policing
Restrictions for RADIUS-Based Policing
Information About RADIUS-Based Policing
Parameterized QoS Policy as VSA 1
How to Configure RADIUS-Based Policing
Configuring per-Service Policing Using RADIUS
Configuring a Hierarchical QoS Child Policy with Policing
Configuring a Hierarchical QoS Parent Policy with Policing
Configuring per-Service Policing on the RADIUS Server
Verifying RADIUS-Based Policing
Configuration Examples for RADIUS-Based Policing
Adding Parameterization of QoS ACLs: Example
Setting the Policing Rate Using an Access-Accept Message: Examples
Setting the Policing Rate Using a CoA Message: Examples
Feature Information for RADIUS-Based Policing
RADIUS-Based Policing
First Published: June 25, 2009Last Updated: November 25, 2009The RADIUS-Based Policing feature enables the router that is acting as the Intelligent Services Gateway (ISG) to make automatic changes to the policing rate of specific sessions and services.
Finding Feature Information
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 for RADIUS-Based Policing" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for RADIUS-Based Policing
•
Restrictions for RADIUS-Based Policing
•
Information About RADIUS-Based Policing
•
How to Configure RADIUS-Based Policing
•
Configuration Examples for RADIUS-Based Policing
•
Feature Information for RADIUS-Based Policing
Prerequisites for RADIUS-Based Policing
You must configure all traffic classes on the ISG before referencing the classes in policy maps.
You must configure and apply QoS policy maps on the ISG before the ISG can construct and apply an ANCP-based dynamic service policy.
Restrictions for RADIUS-Based Policing
Per-service policing cannot be configured on the class-default class at the parent level of a hierarchical policy. You can configure per-service policing on class-default classes at the child or grandchild level.
Transient policies are not visible in the running-configuration file. Only the original policy configuration is visible.
Parameterized quality of service (QoS) is not supported for IP sessions.
The parameterized Access Control List (pACL) name is limited to 80 characters. The pACL name is formed by concatenating the ACL entries in the RADIUS change of authentication (CoA) or Access-Accept message to the ACL name configured on the ISG. If the pACL name exceeds 80 characters, the parameterization operation fails and an error message is displayed. For a CoA message, the ISG also sends a negative Ack (Nack) response to the RADIUS server.
Information About RADIUS-Based Policing
To configure the RADIUS-based policing features, you should understand the following topics:
•
Parameterized QoS Policy as VSA 1
RADIUS Attributes
RADIUS communicates with the ISG device by embedding specific attributes in Access-Accept and CoA messages. RADIUS-based policing employs this exchange of attributes to activate and deactivate services and to modify the active QoS policy applied to a session.
The following sections describe the RADIUS attributes used in RADIUS-based policing:
•
RADIUS Attributes 250 and 252
RADIUS Attributes 250 and 252
RADIUS uses attribute 250 in Access-Accept messages and attribute 252 in CoA messages to activate and deactivate parameterized services. ISG services are configured locally on the ISG device; RADIUS sends only the service name.
Attributes 250 and 252 have the following syntax for service activation:
•
Access-Accept Messages
250 "Aservice(parameter1=value,parameter2=value,...)"•
CoA Messages
252 0b "service(parameter1=value,parameter2=value,...)"RADIUS uses only Attribute 252 in a CoA message when deactivating a service. RADIUS sends the same information in Attribute 252 that was used for service activation, except that service deactivation uses 0c in the syntax instead of the 0b parameter used for service activation.
252 0xC "service(parameter1=value,parameter2=value,...)"VSA 252 has the above syntax for service deactivation.
Cisco VSA 1
RADIUS uses a vendor-specific attribute (VSA) 1 command to modify the active QoS policy on a session. This VSA has the following format:
av-pair = "policy-type=command 9 parameter1 ,...,parametern"Use the following Cisco VSA 1 format to add and remove classes and QoS actions to and from the QoS policy that is currently active on a session:
qos-policy-in=add-class(target,(class-list),qos-actions-list)qos-policy-out=add-class(target,(class-list),qos-actions-list)qos-policy-in=remove-class(target,(class-list))qos-policy-out=remove-class(target,(class-list))Before the ISG can construct a policy using the policing parameters specified in the RADIUS message, a QoS policy must be active on the session. If a QoS policy is not active in the specified direction, the ISG does not create the policy.
When implementing the changes specified in the Cisco VSA, the ISG does not make the changes to the originally configured QoS policy on the ISG device. Instead, the ISG copies the active QoS policy for the session and then makes the required changes to the policy copy, which is referred to as a transient policy. The originally configured QoS policy on the ISG device is not changed.
The following sections describe the Cisco VSA 1 commands used to automatically modify policing parameters of active policies:
Add-Class Primitive
To add or modify QoS actions to a traffic class, use the add-class primitive. This attribute has the following format:
qos-policy-in=add-class(target,(class-list),qos-actions-list)qos-policy-out=add-class(target,(class-list),qos-actions-list)•
target field— indicates the QoS policy to be modified.The only valid value for this field is sub, which indicates the active QoS policy attached to the subscriber session. The Access-Accept or CoA message that includes this attribute must be targeting a subscriber session.
•
class-list field—A list of class names enclosed in parentheses that identifies the traffic class to which the specified QoS action applies. The class names you specify must be either user-configured class maps or the system-generated class-default class. The order in which you specify the class names indicates the hierarchical level of the class within the QoS policy.
For example, the following class list identifies the class named "voip", which gets added to a nested policy. The VoIP class is configured in a nested child policy that is applied to the parent class-default class.
(class-default, voip)•
ISG Configuration
policy-map childclass voippolice 8000policy-map parentclass class-defaultservice-policy childThe following class list specifies the voip-2 class, which is configured in a nested policy that is applied to the voip-aggregate class of another nested child policy. The policy containing the voip-aggregate class is in turn nested under the class-default class of the QoS policy attached to the target session.
(class-default, voip-aggregate, voip-2)•
MSQ Configuration
policy-map child2class voip-2police 8000policy-map child1class voip-aggregatepolice 20000service-policy child2policy-map parentclass class-defaultshape 512000service-policy child1The qos-actions-list field indicates a QoS action such as police, followed by the action parameters enclosed in parentheses and separated by commas. For example, the following sample configuration specifies the police action and defines the parameters bps, burst-normal, burst-max, conform-action, exceed-action, and violate-action. Parentheses enclose the action parameters.
(voip-aggregate police(200000,9216,0,transmit,drop,drop))
Note
The example shows a double-parenthesis at the end, because the syntax of the VSA specifies enclosure of the target, class-list, and qos-actions-list in parentheses.
Remove-Class Primitive
To remove traffic classes and QoS actions defined in the active QoS policy on a session, use the remove-class primitive. This attribute has the following format:
qos-policy-in=remove-class(target,(class-list))qos-policy-out=remove-class(target,(class-list))•
target field—Indicates the QoS policy to be modified. The only valid value for this field is sub, which indicates the active QoS policy attached to the subscriber session. The Access-Accept or CoA message that includes this attribute must be targeting a subscriber session.
•
class-list field—A list of class names enclosed in parentheses that identifies the class or classes to be removed. The class names you specify must be either user-configured class maps or the system-generated class-default class. The order in which you specify the class names indicates the hierarchical level of the class within the QoS policy.
For example, the following VSA1 attribute removes the Class1 class and all associated QoS policy actions from the nested child policy that is applied to the parent class-default class:
qos-policy-out=remove-class(sub,(class-default,Class1))When you remove a traffic class from a QoS policy, all of the attributes for the class are also removed. To readd the class with the same attributes, you must reissue the add-class RADIUS attribute and provide the required parameters and values.
Parameterized QoS Policy as VSA 1
Multiple complex strings in a CoA message are not supported because they do not correct behavior of VSA 1, as shown in the following example:
vsa cisco 250 S152.1.1.2vsa cisco generic 252 binary 0b suffix "q-p-out=IPOne1-isg-acct1(1)((c-d,tv)1(10000))"vsa cisco generic 252 binary 0b suffix "q-p-out=IPOne1-isg-acct(1)((c-d,voip)1(10000))"In the example:
•
All services are enabled on target.
•
Parameterized QoS policy in the second command syntax is not echoed in the ISG service.
•
Parameterized QoS policy in the first command syntax is echoed.
Parameterization of QoS ACLs
The Parameterization of QoS Access Control Lists feature supports multiple ISG and QoS parameterized services in a single Access-Accept or CoA message. This feature allows the authentication, authorization, and accounting (AAA) device to change parameters dynamically.
How to Configure RADIUS-Based Policing
The RADIUS server determines the new policing rate based on vendor-specific attributes (VSAs) configured in a subscriber's user profile on RADIUS and on the Advanced Node Control Protocol (ANCP)-signaled rate received from the ISG. RADIUS sends the new rate to the ISG in an Access-Accept or CoA message.
After receiving the Access-Accept or CoA message, the ISG copies the original policy map applied to the session and changes the policing rate of the copied, transient policy as indicated by RADIUS. The ISG does not change the shaping rate of the original policy. After changing the transient policy, the ISG applies the transient policy to the subscriber service.
This section contains the following tasks:
•
Configuring per-Service Policing Using RADIUS
•
Verifying RADIUS-Based Policing
Configuring per-Service Policing Using RADIUS
To configure per-service policing, perform the following configuration tasks:
•
Configuring a Hierarchical QoS Child Policy with Policing
•
Configuring a Hierarchical QoS Parent Policy with Policing
•
Configuring per-Service Policing on the RADIUS Server
Configuring a Hierarchical QoS Child Policy with Policing
Use the following procedure to configure a hierarchical QoS child policy with policing.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
policy-map policy-map-name
4.
class class-name
5.
shape average mean-rate [burst-size] [excess-burst-size] [account {qinq | dot1q | user-defined offset} aal5 subscriber-encap]
6.
police bps [burst-normal] [burst-max] conform-action action exceed-action action [violate-action action]
7.
exit
DETAILED STEPSPolice Command Actions
The following are keywords you can use to specify actions in the police command:
•
drop—Drops the packet.
•
set-cos-transmit value—Sets the packet Class of Service (COS) value and sends it.
•
set-discard-class-transmit value—Sets the discard class attribute of a packet.
•
set-dscp-transmit value—Sets the IP differentiated services code point (DSCP) value.
•
set-frde-transmit value—Sets the Frame Relay Discard Eligibility (DE) bit from 0 to 1 on the Frame Relay frame.
•
set-mpls-experimental-imposition-transmit value—Sets the Multiprotocol Label Switching (MPLS) experimental (EXP) bits (0 to 7) in the imposed label headers.
•
set-mpls-experimental-topmost-transmit value—Sets the MPLS EXP field value in the topmost MPLS label header at the input and or output interface.
•
set-prec-transmit value—Sets the IP precedence value.
•
set-qos-transmit value—Sets the QoS group value.
•
transmit—Transmits the packet. The packet is not altered.
Configuring a Hierarchical QoS Parent Policy with Policing
Use the following procedure to configure a hierarchical QoS parent policy with policing.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
policy-map policy-map-name
4.
class class-default
5.
shape average mean-rate [burst-size] [excess-burst-size] [account {qinq | dot1q | user-defined offset} aal5 subscriber-encap]
6.
service-policy policy-map-name
7.
exit
DETAILED STEPSConfiguring per-Service Policing on the RADIUS Server
To use RADIUS to set the policing rate for a subscriber service, configure the following Cisco VSAs in the service profile on RADIUS:
vsa cisco generic 1 string "qos-policy-out=add-class(sub,(class-list), shape(rate))"vsa cisco generic 1 string "qos-policy-out=add-class(sub,(class-list), police(rate))"When the ISG receives a RADIUS Access-Accept or CoA message with these VSAs included, the ISG copies the originally configured policy map that is active on the session and changes the policing rate of the traffic class specified in the class-list field. The ISG makes changes only to the transient policy and applies the transient policy to the subscriber service; no changes are made to the original policy map.
Note
Per-service policing does not apply to the parent class-default class.
For more information, see the "RADIUS Attributes" section.
Verifying RADIUS-Based Policing
To verify the configuration of RADIUS-based policing on the ISG, use any of the following commands in privileged EXEC mode.
Configuration Examples for RADIUS-Based Policing
This section provides the following configuration examples:
•
Adding Parameterization of QoS ACLs: Example
•
Setting the Policing Rate Using an Access-Accept Message: Examples
•
Setting the Policing Rate Using a CoA Message: Examples
Adding Parameterization of QoS ACLs: Example
The following example shows how to parameterize the set source IP address and destination IP address parameter, set-src-dst-ip-in-acl, through CoA or Access-Accept messages. The QoS parameterized service is added in the parameterized QoS service RADIUS form:
VSA252 0b q-p-out=IPOne(1)((c-d,voip)13(201.10.1.0/28,202.3.20/29))! The above command activates the service in a CoA message.vsa cisco generic 1 string "qos-policy-out=add-class(sub,(class-default,voip),set-src-dst-ip-in-acl(10.10.1.0/28,10.3 .20/29))"! The above command activates the service in a Access-Accept message.The router is configured as follows:
ip access-list extended IPOne-aclremark Voice-GWpermit ip host 10.0.1.40 any!class-map match-any voipmatch access-group name IPOne-acl!class-map type traffic match-any IPOnematch access-group output name IPOne-aclmatch access-group input name IPOne-acl!!policy-map type service IPOne10 class type traffic IPOneaccounting aaa list default!!policy-map output_parentclass class-defaultpolice 32000 32000 32000 conform-action transmit exceed-action drop violate-action dropservice-policy output_child!!policy-map output_childclass voippolice 32000 32000 32000 conform-action transmit exceed-action drop violate-action drop!!!! RADIUS relays the string for service activation. After the VSA is received, a new ACL is created.ip access-list extended IPOne-acl-10.10.1.0/28,10.3.20/29remark Voice-GWpermit ip host 10.0.1.40 anypermit ip 10.10.1.0 0.0.0.15 anypermit ip any 10.10.1.0 0.0.0.15permit ip 10.3.2.0 0.0.0.7 anypermit ip any 10.3.2.0 0.0.0.7!! A new class map is created.class-map match-any voip-10.10.1.0/28,10.3.20/29match access-group name IPOne-acl-10.10.1.0/28,10.3.20/29!! The old class is replaced with the new class in the output QoS policy of the subscriber, along with any other attributes.Adding Parameterization of QoS ACLs with ISG Service Accounting
The following example shows how to add QoS accounting by configuring the ISG accounting service:
policy-map type service IPOne10 class type traffic IPOneaccounting aaa list default!class type traffic default in-out!!! After the VSA is received, a new traffic class map is created on the service.class-map type traffic match-any IPOne-10.10.1.0/28,10.3.2.0/29match access-group output name IPOne-acl-10.10.1.0/28$10.3.2.0/29match access-group input name IPOne-acl-10.10.1.0/28$10.3.2.0/29!! A new ISG service is created.policy-map type service IPOne(tc_in=IPOne-acl-10.10.1.0/28$10.3.2.0/29)10 class type traffic IPOne-10.10.1.0/28,10.3.2.0/29accounting aaa list default!class type traffic default in-out!Setting the Policing Rate Using an Access-Accept Message: Examples
The examples in this section illustrate how to set the policing rate of a traffic class using an access-accept message.
ISG Original Policy
This configuration example uses a RADIUS Access-Accept message to change the policing rate of a traffic class at the child level of a hierarchical policy:
class-map match-any Premiummatch access-group name Premium_Dest!policy-map Childclass Premiumshape average 5000!policy-map Parentclass class-defaultshape average 10000service-policy Child!ip access-list extended Premium_Destpermit ip any 192.168.6.0 0.0.0.255permit ip any 192.168.5.7 0.0.0.64RADIUS Configuration
The following Cisco VSA is configured in a user profile on RADIUS. This VSA changes the policing rate of the Premium class in the Child policy. The Child policy is applied to the class-default class of the Parent policy.
radius subscriber 6framed protocol pppservice framedvsa cisco generic 1 string "qos-policy-out=add-class(sub,(class-default, Premium), police(200000))"RADIUS Access-Accept Message
The ISG receives the following RADIUS Access-Accept message. Notice that the above Cisco VSA configured in the user's profile is present in the Access-Accept message.
1d21h: RADIUS: Received from id 1645/3 192.168.1.6:1812, Access-Accept, len 100 1d21h: RADIUS: authenticator 4A 2C F7 05 4B 88 38 64 - DE 60 69 5A 4B EE 43 E1 1d21h: RADIUS: Framed-Protocol [7] 6 PPP [1] 1d21h: RADIUS: Service-Type [6] 6 Framed [2] 1d21h: RADIUS: Vendor, Cisco [26] 68 1d21h: RADIUS: Cisco AVpair [1] 62 "qos-policy-out=add-class(sub,(class-default, Premium), police(200000))" 1d21h: RADIUS(0000000D): Received from id 1645/3 1d21h: SSS PM [uid:4][65ADE2E8]: SERVICE: Adding Service attachment to event 1d21h: RADIUS/ENCODE(0000000D):Orig. component type = PPoE 1d21h: RADIUS(0000000D): Config NAS IP: 0.0.0.0 1d21h: RADIUS(0000000D): sendingISG Transient Policy
The ISG copies the service policy that is currently applied to the session and creates a transient policy named New_Parent to which it makes the appropriate changes. Based on the Cisco VSA included in the Access-Accept message, the ISG adds the policing rate to the Premium traffic class. The Premium class is configured in the transient New_Child policy, which is applied to the New_Parent class-default class.
policy-map New_Child [New cloned child policy]class Premiumpolice 200000 [New policing rate]shape average 5000!policy-map New_Parent [New cloned parent policy]class class-defaultshape average 10000service-policy New_Child [New cloned child policy attached to the newcloned parent policy]Setting the Policing Rate Using a CoA Message: Examples
The examples in this section illustrate how to set the policing rate of a service using a CoA message.
ISG Original Policy
This configuration example uses a RADIUS CoA message to change the policing rate of a service and is based on the following ISG configuration:
policy-map Childclass Premiumpolice 12000!policy-map Parentclass class-defaultshape average 10000service-policy ChildRADIUS Configuration
The following Cisco VSA is configured in a user's profile on RADIUS. This VSA modifies the Premium class of the Child policy, which is applied to the class-default class of the Parent policy.
radius subscriber 1048vsa cisco 250 S192.168.1.10vsa cisco generic 1 string "qos-policy-out=add-class(sub,(class-default, Premium), police(200000))"RADIUS CoA Message
The ISG receives the following RADIUS CoA message. Notice that the above Cisco VSA configured in the user profile is present in the CoA message.
1d21h: RADIUS: COA received from id 0 192.168.1.6:1700, CoA Request, len 106 1d21h: COA: 192.168.1.6 request queued 1d21h: RADIUS: authenticator FF A2 6B 63 06 F0 E6 A3 - 0D 04 6C DC 01 0A BE F1 1d21h: RADIUS: Vendor, Cisco [26] 18 1d21h: RADIUS: ssg-account-info [250] 12 "S192.168.1.10" 1d21h: RADIUS: Vendor, Cisco [26] 68 1d21h: RADIUS: Cisco AVpair [1] 62 "qos-policy-out=add-class(sub,(class-default, Premium), police(200000))" 1d21h: ++++++ CoA Attribute List ++++++ 1d21h: 63C829B0 0 00000009 ssg-account-info(427) 10 S192.168.1.10 1d21h: 63C82A18 0 00000009 qos-policy-out(378) 45 add-class(sub,(class-default, Premium), police(200000)) 1d21h:ISG# 1d21h: RADIUS(00000000): sending 1d21h: RADIUS(00000000): Send CoA Ack Response to 192.168.1.6:1700 id 0, len 65 1d21h: RADIUS: authenticator 62 B4 B0 1A 90 10 01 01 - F6 C8 CD 17 79 15 C7 A7 1d21h: RADIUS: Vendor, Cisco [26] 18 1d21h: RADIUS: ssg-account-info [250] 12 "S192.168.1.10" 1d21h: RADIUS: Vendor, Cisco [26] 27 1d21h: RADIUS: ssg-account-info [250] 21 "$IVirtual-Access2.2"ISG Transient Policy
The ISG copies the service policy named Parent currently applied to the session and creates a transient copy named New_Parent to which it makes the appropriate changes. Based on the Cisco VSA included in the Access-Accept message, the ISG changes the policing rate of the Premium traffic class from 5000 bps to 200,000 bps. The Premium class is configured in the New_Child policy, which is applied to the New_Parent class-default class.
policy-map New_Child [New cloned child policy]class Premiumpolice 200000 [New policing rate]!policy-map New_Parent [New cloned parent policy]class class-defaultshape average 10000service-policy New_Child [New cloned child policy attached to the newcloned parent policy]Additional References
The following sections provide references related to the RADIUS-Based Policing feature.
Related Documents
Technical Assistance
Feature Information for RADIUS-Based Policing
Table 1 lists the features in this module.
For information on a feature in this technology that is not documented here, see the Cisco Intelligent Services Gateway Features Roadmap.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.
Table 1 Feature Information for RADIUS-Based Policing
Feature Name Releases Feature InformationISG: Policy Control: Policy Server: RADIUS-Based Policing
12.2(33)XNE
The RADIUS-Based Policing feature extends ISG functionality to allow the use of a RADIUS server to provide subscriber policy information.
The following sections provide information about this feature:
•
"Information About RADIUS-Based Policing" section
RADIUS-Based Policing Attribute Modifications
12.2(33)XNE
The RADIUS-Based Policing Attribute Modifications feature allows the RADIUS server to communicate with the ISG by embedding specific attributes in Access-Accept and CoA messages. RADIUS-based shaping and policing employs this exchange of attributes to activate and deactivate services, and to modify the active QoS policy applied to a session.
The following sections provide information about this feature:
•
"Information About RADIUS-Based Policing" section
Parameterization of QoS ACLs
12.2(33)XNE
The Parameterization of QoS ACLs feature provides enhancements for QoS ACLs. This feature allows the AAA device to change parameters dynamically.
The following sections provide information about this feature:
•
"Information About RADIUS-Based Policing" section
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at 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. (1005R)
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 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.
© 2009 Cisco Systems, Inc. All rights reserved.
Feedback