Configuring IP to ATM Class of Service
Configuring IP to ATM Class of Service
Last Updated: July 26, 2011
This module describes the tasks for configuring the IP to ATM Class of Service (CoS), a feature suite that maps QoS characteristics between IP and ATM.
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.
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 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.
IP to ATM CoS on a Single ATM VC Configuration Task List
To configure IP to ATM CoS for a single ATM virtual circuit (VC), perform the tasks described in the following sections. The tasks in the first two sections are required; the tasks in the remaining sections are optional.
The IP to ATM CoS feature requires ATM permanent virtual circuit (PVC) management.
Defining the WRED Parameter Group
Configuring the WRED Parameter Group
1. Router(config)# random-detect-group group-name
2. Router(config)# exponential-weighting-constant exponentRouter(config)# precedence precedence min-threshold max-threshold mark-probability-denominator
Displaying the WRED Parameters
IP to ATM CoS on an ATM Bundle Configuration Task List
To configure IP to ATM CoS on an ATM bundle, perform the tasks in the following sections.
The IP to ATM CoS feature requires ATM PVC management.
Creating a VC Bundle
Applying Bundle-Level Parameters
Configuring Bundle-Level Parameters
Configuring VC Class Parameters to Apply to a Bundle
Attaching a Class to a Bundle
Committing a VC to a Bundle
Applying Parameters to Individual VCs
Configuring a VC Bundle Member Directly
Configuring VC Class Parameters to Apply to a VC Bundle Member
Configuring a VC Not to Accept Bumped Traffic
Monitoring and Maintaining VC Bundles and Their VC Members
Per-VC WFQ and CBWFQ Configuration Task List
To configure IP to ATM CoS for per-VC WFQ and CBWFQ, perform the tasks described in the following sections.
The IP to ATM CoS feature requires ATM PVC management.
Configuring Class-Based Weighted Fair Queueing
Before configuring CBWFQ for a VC, you must perform the following tasks using standard CBWFQ commands:
Because CBWFQ gives you minimum bandwidth guarantee, you can only apply CBWFQ to VCs having these classes of service: available bit rate (ABR) and variable bit rate (VBR). You cannot apply per-VC WFQ and CBWFQ to UBR and unspecified bit rate plus (UBR+) VCs because both of these service classes are best-effort classes that do not guarantee minimum bandwidth. When CBWFQ is enabled for a VC, all classes configured as part of the service policy are installed in the fair queueing system.
In addition to configuring CBWFQ at the VC level, the IP to ATM CoS feature allows you to configure flow-based WFQ at the VC level. Because flow-based WFQ gives you best-effort class of service--that is, it does not guarantee minimum bandwidth--you can configure per-VC WFQ for all types of CoS VCs: ABR, VBR, UBR, and UBR+.
Per-VC WFQ uses the class-default class. Therefore, to configure per-VC WFQ, you must first create a policy map and configure the class-default class. (You need not create the class-default class, which is predefined, but you must configure it.) For per-VC WFQ, the class-default class must be configured with the fair-queue policy-map class configuration command.
In addition to configuring the fair-queue policy-map class configuration command, you can configure the default class with either the queue-limit command or the random-detectcommand, but not both. Moreover, if you want the default class to use flow-based WFQ, you cannot configure the default class with the bandwidth policy-map class configuration command--to do so would disqualify the default class as flow-based WFQ, and therefore limit application of the service policy containing the class to ABR and VBR VCs.
Attaching a Service Policy and Enabling CBWFQ for a VC
Attaching a Policy Map to a Standalone VC and Enabling CBWFQ
Attaching a Policy Map to an Individual VC and Enabling CBWFQ
Configuring a VC to Use Flow-Based WFQ
Attaching a Policy Map to a Standalone VC and Enabling WFQ
Monitoring per-VC WFQ and CBWFQ
IP to ATM CoS Configuration Examples
Example Single ATM VC with WRED Group and IP Precedence
The following example creates a PVC on an ATM interface and applies the WRED parameter group called sanjose to that PVC. Next, the IP Precedence values are configured for the WRED parameter group sanjose.
interface ATM1/1/0.46 multipoint ip address 18.104.22.168 255.255.255.0 no ip mroute-cache shutdown pvc cisco 46 encapsulation aal5nlpid random-detect attach sanjose ! random-detect-group sanjose precedence 0 200 1000 10 precedence 1 300 1000 10 precedence 2 400 1000 10 precedence 3 500 1000 10 precedence 4 600 1000 10 precedence 5 700 1000 10 precedence 6 800 1000 10 precedence 7 900 1000 10
Example VC Bundle Configuration Using a VC Class
At the outset, this configuration defines a VC class called bundle-class that includes commands that set VC parameters. When the class bundle-class is applied at the bundle level, these parameters are applied to all VCs that belong to the bundle. Note that any commands applied directly to an individual VC of a bundle in bundle-vc mode take precedence over commands applied globally at the bundle level. Taking into account hierarchy precedence rules, VCs belonging to any bundle to which the class bundle-class is applied will be characterized by these parameters: aal5snap encapsulation, broadcast on, use of Inverse Address Resolution Protocol (ARP) to resolve IP addresses, and operation, administration, and maintenance (OAM) enabled.
router isis net 49.0000.0000.0000.1111.00 vc-class atm bundle-class encapsulation aal5snap broadcast protocol ip inarp oam-bundle manage 3 oam retry 4 3 10
The following sections of the configuration define VC classes that contain commands specifying parameters that can be applied to individual VCs in a bundle by assigning the class to that VC.
When the class called control-class is applied to a VC, the VC carries traffic whose IP Precedence level is 7. When the VC to which this class is assigned goes down, it takes the bundle down with it because this class makes the VC a protected one. The QoS type of a VC using this class is vbr-nrt.
vc-class atm control-class precedence 7 protect vc vbr-nrt 10000 5000 32
When the class called premium-class is applied to a VC, the VC carries traffic whose IP Precedence levels are 6 and 5. The VC does not allow other traffic to be bumped onto it. When the VC to which this class is applied goes down, its bumped traffic will be redirected to a VC whose IP Precedence level is 7. This class makes a VC a member of the protected group of the bundle. When all members of a protected group go down, the bundle goes down. The QoS type of a VC using this class is vbr-nrt.
vc-class atm premium-class precedence 6-5 no bump traffic protect group bump explicitly 7 vbr-nrt 20000 10000 32
When the class called priority-class is applied to a VC, the VC is configured to carry traffic with IP Precedence in the 4-2 range. The VC uses the implicit bumping rule, it allows traffic to be bumped, and it belongs to the protected group of the bundle. The QoS type of a VC using this class is ubr+.
vc-class atm priority-class precedence 4-2 protect group ubr+ 10000 3000
When the class called basic-class is applied to a VC, the VC is configured through the precedence other command to carry traffic with IP Precedence levels not specified in the profile. The VC using this class belongs to the protected group of the bundle. The QoS type of a VC using this class is ubr.
vc-class atm basic-class precedence other protect group ubr 10000
The following sets of commands configure three bundles that the router subinterface uses to connect to three of its neighbors. These bundles are called new-york, san-francisco, and los-angeles. Bundle new-york has four VC members, bundle san-francisco has four VC members, and bundle los-angeles has three VC members.
The first part of this example specifies the IP address of the subinterface, the router protocol--the router uses IS-IS as an IP routing protocol--and it creates the first bundle called new-york and enters bundle configuration mode:
interface atm 1/0.1 multipoint ip address 10.0.0.1 255.255.255.0 ip router isis bundle new-york
From within bundle configuration mode, the next portion of the configuration uses two protocol commands to enable IP and Open Systems Interconnect (OSI) traffic flows in the bundle. The OSI routing packets will use the highest precedence VC in the bundle. The OSI data packets, if any, will use the lowest precedence VC in the bundle. If configured, other protocols, such as IPX or AppleTalk, will always use the lowest precedence VC in the bundle.
As the indentation levels of the preceding and following commands suggest, subordinate to bundle new-york is a command that configures its protocol and a command that applies the class called bundle-class to it.
protocol ip 22.214.171.124 broadcast protocol clns 49.0000.0000.2222.00 broadcast class-bundle bundle-class
The class called bundle-class, which is applied to the bundle new-york, includes a protocol ip inarp command. According to inheritance rules, protocol ip, configured at the bundle level, takes precedence over protocol ip inarp specified in the class bundle-class.
The next set of commands beginning with pvc-bundle ny-control 207, which are further subordinate, add four VCs (called ny-control, ny-premium, ny-priority, and ny-basic) to the bundle new-york. A particular class--that is, one of the classes predefined in this configuration example--is applied to each VC to configure it with parameters specified by commands included in the class.
As is the case for this configuration, to configure individual VCs belonging to a bundle, the router must be in bundle mode for the mother bundle. For each VC belonging to the bundle, the subordinate mode is pvc-mode for the specific VC.
The following commands configure the individual VCs for the bundle new-york:
pvc-bundle ny-control 207 class-vc control-class pvc-bundle ny-premium 206 class-vc premium-class pvc-bundle ny-priority 204 class-vc priority-class pvc-bundle ny-basic 201 class-vc basic-class
The following set of commands create and configure a bundle called san-francisco. At the bundle configuration level, the configuration commands included in the class bundle-class are ascribed to the bundle san-francisco and to the individual VCs that belong to the bundle. Then, the pvc-bundle command is executed for each individual VC to add it to the bundle. After a VC is added and bundle-vc configuration mode is entered, a particular, preconfigured class is assigned to the VC. The configuration commands comprising that class are used to configure the VC. Rules of hierarchy apply at this point. Command parameters contained in the applied class are superseded by the same parameters applied at the bundle configuration level, which are superseded by the same parameters applied directly to a VC.
bundle san-francisco protocol clns 49.0000.0000.0000.333.00 broadcast inarp 1 class-bundle bundle-class pvc-bundle sf-control 307 class-vc control-class pvc-bundle sf-premium 306 class-vc premium-class pvc-bundle sf-priority 304 class-vc priority-class pvc-bundle sf-basic 301 class-vc basic-class
The following set of commands create and configure a bundle called los-angeles. At the bundle configuration level, the configuration commands included in the class bundle-class are ascribed to the bundle los-angeles and to the individual VCs that belong to the bundle. Then, the pvc-bundle command is executed for each individual VC to add it to the bundle. After a VC is added and bundle-vc configuration mode is entered, precedence is set for the VC and the VC is either configured as a member of a protected group (protect group) or as an individually protected VC. A particular class is then assigned to each VC to further characterize it. Rules of hierarchy apply. Parameters of commands applied directly and discretely to a VC take precedence over the same parameters applied within a class to the VC at the bundle-vc configuration level, which take precedence over the same parameters applied to the entire bundle at the bundle configuration level.
bundle los-angeles protocol ip 126.96.36.199 broadcast protocol clns 49.0000.0000.4444.00 broadcast inarp 1 class-bundle bundle-class pvc-bundle la-high 407 precedence 7-5 protect vc class-vc premium-class pvc-bundle la-mid 404 precedence 4-2 protect group class-vc priority-class pvc-bundle la-low 401 precedence other protect group class-vc basic-class
Example Per-VC WFQ and CBWFQ on a Standalone VC
The following example creates two class maps and defines their match criteria. For the first map class, called class1, the numbered access control list (ACL) 101 is used as the match criterion. For the second map class called class2, the numbered ACL 102 is used as the match criterion.
Next, the example includes these classes in a policy map called policy1. For class1, the policy includes a minimum bandwidth allocation request of 500 kbps and maximum packet count limit of 30 for the queue reserved for the class. For class2, the policy specifies only the minimum bandwidth allocation request of 1000 kbps, so the default queue limit of 64 packets is assumed. Note that the sum of the bandwidth requests for the two classes comprising policy1 is 75 percent of the total amount of bandwidth (2000 kbps) for the PVC called cisco to which the policy map is attached.
The example attaches the policy map called policy1 to the PVC called cisco. Once the policy map policy1 is attached to PVC cisco, its classes constitute the CBWFQ service policy for that PVC. Packets sent on this PVC will be checked for matching criteria against ACLs 101 and 102 and classified accordingly.
Because the class-default command is not explicitly configured for this policy map, all traffic that does not meet the match criteria of the two classes comprising the service policy is handled by the predefined class-default class, which provides best-effort flow-based WFQ.
class-map class1 match access-group 101 class-map class2 match access-group 102 policy-map policy1 class class1 bandwidth 500 queue-limit 30 class class2 bandwidth 1000 interface ATM1/1/0.46 multipoint ip address 188.8.131.52 255.255.255.0 pvc cisco 46 vbr-nrt 2000 2000 encap aal5snap service policy output policy1
Example Per-VC WFQ and CBWFQ on Bundle-Member VCs
The following example shows a PVC bundle called san-francisco with members for which per-VC WFQ and CBWFQ are enabled and service policies configured. The example assumes that the classes included in the following policy maps have been defined and that the policy maps have been created: policy1, policy2, and policy4. For each PVC, the IP to ATM CoS pvc-bundle command is used to specify the PVC to which the specified policy map is to be attached.
Note that PVC 0/34 and 0/31 have the same policy map attached to them, policy2. Although you can assign the same policy map to multiple VCs, each VC can have only one policy map attached at an output PVC.
bundle san-francisco protocol ip 184.108.40.206 broadcast encapsulation aal5snap pvc-bundle 0/35 service policy output policy1 vbr-nrt 5000 3000 500 precedence 4-7 pvc-bundle 0/34 service policy output policy2 vbr-nrt 5000 3000 500 precedence 2-3 pvc-bundle 0/33 vbr-nrt 4000 3000 500 precedence 2-3 service policy output policy4 pvc-bundle 0/31 service policy output policy2
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 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.