Cisco ASR 9000 Series Aggregation Services Router Modular Quality of Service Configuration Guide, Release 4.1
Configuring Hierarchical Modular QoS
Downloads: This chapterpdf (PDF - 299.0KB) The complete bookPDF (PDF - 1.29MB) | Feedback

Table of Contents

Configuring Hierarchical Modular QoS on Cisco ASR 9000 Series Routers

Contents

Information About Hierarchical QoS

Benefits of Hierarchical Policies

Restrictions for Hierarchical Policies

Sample Scenarios of Hierarchical Policies

Two-Level Hierarchical Policies

Two-Level Hierarchical Policing Policy

Two-Level Hierarchical Queueing Policy

Three-Level Hierarchical Policies

Processing Order for Actions in Hierarchical Policies

WRED

Three-Parameter Scheduler

Support for Three-Parameter Scheduler in Hierarchical Policies

Hierarchical Policing

Hierarchical Policing on ASR 9000 Ethernet Line Cards

Hierarchical Policing on the SIP 700 for the ASR 9000

Enhanced Hierarchical Ingress Policing

How to Configure Hierarchical QoS

Configuring the Three-Parameter Scheduler

ASR 9000 Ethernet Line Cards

SIP 700 for the ASR 9000

Policing Traffic at Two Levels of Hierarchy

Attaching Hierarchical Policies to Physical and Virtual Links

Configuring Enhanced Hierarchical Ingress Policing

Restrictions

Configuration Examples for Hierarchical QoS

Two-Level Hierarchical Queueing Policy: Example

Three-Level Hierarchical Queueing Policy: Examples

ASR 9000 Ethernet Line Cards

SIP 700 for the ASR 9000

Three-Parameter Scheduler: Examples

ASR 9000 Ethernet Line Cards

SIP 700 for the ASR 9000

Hierarchical Policing: Examples

ASR 9000 Ethernet Line Cards

SIP 700 for the ASR 9000

Attaching Service Policies to Physical and Virtual Links: Examples

Physical Link: Example

Virtual Link: Example

Enhanced Hierarchical Ingress Policing: Example

Verifying the Configuration of Hierarchical Policies

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance

Configuring Hierarchical Modular QoS on Cisco ASR 9000 Series Routers

Hierarchical QoS allows you to specify QoS behavior at multiple policy levels, which provides a high degree of granularity in traffic management.

Line Card, SIP, and SPA Support

Feature
ASR 9000 Ethernet Line Cards
SIP 700 for the ASR 9000

Enhanced Hierarchical Ingress Policing

no

yes

Hierarchical Policing

yes

yes

Hierarchical QoS

yes

yes

Three-Parameter Scheduler

yes

yes

Feature History for Hierarchical QoS on Cisco ASR 9000 Series Routers

Release
Modification

Release 3.7.1

The Hierarchical Policing feature was introduced on Cisco ASR 9000 Series Routers on ASR 9000 Ethernet Line Cards.

The Hierarchical QoS feature was introduced on Cisco ASR 9000 Series Routers on ASR 9000 Ethernet Line Cards.

The Three-Parameter Scheduler feature was introduced on Cisco ASR 9000 Series Routers on ASR 9000 Ethernet Line Cards.

Release 3.9.0

The Hierarchical QoS feature was supported on the SIP 700 for the ASR 9000. (two-level policies only)

Release 4.0.0

The Enhanced Hierarchical Ingress Policing feature was introduced on Cisco ASR 9000 Series Routers on the SIP 700 for the ASR 9000.

The Hierarchical Policing feature was supported on Cisco ASR 9000 Series Routers on the SIP 700 for the ASR 9000.

For the Hierarchical QoS feature, support was added for three-level policies on the SIP 700 for the ASR 9000.

The Three-Parameter Scheduler feature was supported on the SIP 700 for the ASR 9000.

Information About Hierarchical QoS

Hierarchical QoS allows you to specify QoS behavior at multiple policy levels, which provides a high degree of granularity in traffic management. A hierarchical policy is a QoS model that enables you to specify QoS behavior at multiple levels of hierarchy. You can use hierarchical policies to:

  • Allow a parent class to shape multiple queues in a child policy
  • Apply specific policy map actions on the aggregate traffic
  • Apply class-specific policy map actions
  • Restrict the maximum bandwidth of a virtual circuit (VC) while allowing policing and marking of traffic classes within the VC

The service-policy command is used to apply a policy to another policy, and a policy to an interface, subinterface, VC, or VLAN.

For example, in a three-level hierarchical policy, use the service-policy command to apply:

  • Bottom-level policy to a middle-level policy
  • Middle-level policy to a top-level policy
  • Top-level policy to an interface, subinterface, VC, or VLAN

Benefits of Hierarchical Policies

Depending on the type of hierarchical QoS policy you configure, you can:

  • Shape multiple queues to a single rate
  • Divide a single class of traffic into one or more subclasses
  • Specify the maximum transmission rate of a set of traffic classes that are queued separately, which is essential for virtual interfaces such as Frame Relay PVCs and IEEE 802.1Q virtual VLANs
  • Configure minimum bandwidth queues on virtual circuits
  • Shape the aggregate traffic of queues on a physical interface (for example, provide a 10-megabits per second (Mbps) service on a 100-Mbps physical interface)
  • Restrict the maximum bandwidth of a VC while allowing policing and marking of classes within the VC

Restrictions for Hierarchical Policies

In Cisco IOS XR Release 4.0.0, the following restrictions apply:

ASR 9000 Ethernet Line Cards

In a three-level hierarchy, the configuration is rejected if the top-level class has queueing actions but the middle-level class or bottom-level class do not have queueing actions.

For example, the following configuration was valid in previous releases but is not valid in Cisco IOS XR Release 4.0.0 because the top-level class has a queueing action (shaping) but the middle-level and bottom-level classes do not have queueing actions:

policy-map grand-parent
class class-default
shape average 10 mbps
service-policy parent
 
policy-map parent
class p1
service-policy child
police rate 10 mbps
class p2
service-policy child
police rate 10 mbps
class p3
police rate 10 mbps
service-policy child
class class-default
 
policy-map child
class c1
police rate 2 mbps
class c2
police rate 5 mbps
class class-default
police rate 10 mbps
 

To correct the configuration and retain queueing in the top-level class, you can add a queueing action to the middle-level or bottom-level classes. For example, the bandwidth remaining action is added to the middle-level classes in this example. You could also correct this configuration by removing queueing from the top-level class.

policy-map grand-parent
class class-default
shape average 10 mbps
service-policy parent
 
policy-map parent
class p1
service-policy child
police rate 10 mbps
bandwidth remaining ratio 1
class p2
service-policy child
police rate 10 mbps
bandwidth remaining ratio 1
class p3
police rate 10 mbps
service-policy child
bandwidth remaining ratio 1
class class-default
 
policy-map child
class c1
police rate 2 mbps
class c2
police rate 5 mbps
class class-default
police rate 10 mbps

SIP 700 for the ASR 9000

  • In a three-level hierarchy, the bottom level does not allow queueing actions.
  • On ingress, queueing actions are not allowed.

Sample Scenarios of Hierarchical Policies

Two-Level Hierarchical Policies

Two-level hierarchical policies, also called nested polices , can be illustrated with a parent-level policy for the top level of the hierarchy and a child-level for the bottom level of the hierarchy. A two-level hierarchical policy can have policing-only polices at the parent and child levels or can have queueing and policing at the parent and child levels. Hierarchical policies are configured by attaching a policy directly to a class of traffic.

Two-Level Hierarchical Policing Policy

Multi-level traffic policing is generally applied on ingress, and is a good application of two-level policies, as shown in Example 1. Aggregate traffic is policed to 10 Mbps and at the same time FTP traffic is policed to 1 Mbps and HTTP traffic is policed to 3 Mbps. The policy child-police is attached to the class-default of the policy parent-police.

Example 1 Two-Level Hierarchical Policing Policy

class-map ftp
match protocol ftp
class-map http
match protocol http
 
policy-map child-police
class ftp
police rate 1 mbps
 
class http
police rate 3mbps
 
class class-default
 
policy-map parent-police
class class-default
police rate percent 10 mbps
service-policy child-police

Two-Level Hierarchical Queueing Policy

A hierarchical Queueing Policy is generally applied on egress, and can be configured by modifying the hierarchical policing policy in Example 1.

In Example 2, the class-default of parent-policy is shaped to10 Mbps. Policy child-queueing-policy is attached to the class-default of parent-policy, and defines three traffic classes:

  • voice-ip matches the real-time protocol RTP and is configured as a priority class with 2 Mbps policing
  • ftp is configured with 1 Mbps of guaranteed bandwidth
  • http is configured with 3 Mbps of guaranteed bandwidth

Example 2 Two-Level Hierarchical Queueing Policy

class-map voice-ip
match protocol rtp
class-map ftp
match protocol ftp
class-map http
match protocol http
 
policy-map child-queueing-policy
class voice-ip
priority level 1
police rate 2 mbps
class ftp
bandwidth 1 mbps
class http
bandwidth 3 mbps
class class-default
 
policy-map parent-policy
class class-default
shape average 10 mbps
service-policy child-queuing-policy

Three-Level Hierarchical Policies

Example 3 shows a three-level hierarchical policy in a Frame Relay environment in which the goal is to shape a Frame Relay PVC to a maximum rate (effectively creating an interface with a specific bandwidth) and then manage the bandwidth of the PVC.


NoteThis example is valid only on the SIP 700 for the ASR 9000. This example is valid only on the SIP 700 for the ASR 9000.


Example 3 Three-Level Hierarchical Queueing Policy: Frame Relay

policy-map frpvc-policy
class class-default
shape average 2 mbps
service-policy bandwidth-mgmt
 
policy-map bandwidth-mgmt
class voice
priority level 1
police rate percent 20
class video
bandwidth percent 50
class class-default
service-policy set-frde
 
policy-map set-frde
class ftp
police rate 2 mbps
conform-action transmit
exceed-action set fr-de 1
class class-default
set-frde 1
 

The policy frpvc-policy is attached to a Frame Relay PVC, which shapes that PVC to 2 Mbps, using the shape average command that is configured on class-default in frpvc-policy. The absence of any user-defined classes in frpvc-policy means that all traffic matches class-default and is shaped (the entire PVC is shaped).

Attaching the bandwidth-mgmt policy to class-default in frpvc-policy specifies how the 2 Mbps in the PVC is allocated to a voice class, a video class, and all other traffic on the PVC. In this case, voice traffic is guaranteed low latency for 20 percent of the 2 Mbps, and the video class is guaranteed 50 percent of the 2 Mbps.

The remaining traffic is classified into two traffic classes. The ftp traffic class is policed at 2 Mbps and any FTP traffic above the policing rate has the Frame Relay DE bit set to 1. The remaining traffic has the Frame Relay DE bit set to 1.

This type of configuration is common in service providers the offer QoS-based services.

Processing Order for Actions in Hierarchical Policies

In hierarchical policies, some actions are applied starting at the top level of the hierarchy and others are applied starting at the bottom level of the hierarchy.

For example, if the set dscp command appears at multiple layers in the hierarchy (multiple s et dscp commands can apply to the same packet), the final DSCP value for the packet is the one in the set command at the bottom level of the hierarchy. The hierarchy is processed starting at the top and traversing to the bottom. Packet classification also happens starting at the top and traversing to the bottom.

For all actions other than those using set commands, the hierarchy is traversed from the bottom level of the hierarchy to the top level. For example, all queueing actions and the police action (including when the policer performs marking with the conform, exceed, or violate action at any level of the hierarchy) execute from the bottom level of the hierarchy to the top level of the hierarchy.

WRED

If WRED is configured in the middle-level policy and a set action is configured for the same filter in the bottom-level policy, WRED is based on the newly remarked value of the filter from the bottom-level policy.

If there is a stand-alone set action as part of a policer action, the packet is marked with the set value in the policer, because that is executed last.

Three-Parameter Scheduler

In hierarchical QoS, if a policy is configured with queueing classes at any level in the hierarchy, then the traffic for different classes needs to be scheduled according to certain rules of the scheduler based on the configuration. The Three-Parameter Scheduler is a queueing algorithm that uses the following parameters to control traffic:

  • Minimum bandwidth using the bandwidth command
  • Excess bandwidth using the bandwidth remaining command
  • Maximum bandwidth using the shape average command

The Three-Parameter Scheduler can be implemented in one-level, two-level, or three-level policies. In Example 4, a one-level policy is a sample configuration for a three-parameter scheduler.

For the purposes of this example, if policy_3parameter_scheduler is applied to a T1 serial interface and the T1 interface link bandwidth is 1536 kbps, then the link bandwidth distribution for each class is as follows:

  • Class A is configured explicitly for minimum, maximum, and excess bandwidth. Class A receives a guaranteed minimum bandwidth of 30 percent of 1536 kbps (460.8 kbps) and 80 percent of remaining (excess) bandwidth. When other classes are not using all of their bandwidth share, class A can receive a maximum bandwidth of up to 50 percent of the link bandwidth (768 kbps).
  • Class B is configured explicitly for minimum and excess bandwidth. Class B receives a guaranteed minimum bandwidth of 60 percent of 1536 kbps (921.6 kbps) and10 percent of remaining (excess) bandwidth. If maximum bandwidth is not explicitly configured, the default maximum bandwidth is the link bandwidth (1536 kbps— equal to a configuration of shape percent 100) . When other classes are not using all of their bandwidth share, class B can receive a maximum bandwidth of up to 100 percent of the link bandwidth.
  • Class class-default is not configured explicitly with any queueing parameters. There is no default minimum bandwidth. If maximum bandwidth is not explicitly configured, the default maximum bandwidth is the link bandwidth (1536 kbps ) . When other classes are not using all of their bandwidth share, class-default can receive a maximum bandwidth of up to 100 percent of the link bandwidth. For excess bandwidth, because class A and class B receive a total of 90 percent of remaining (excess) bandwidth, class-default receives the remaining 10 percent.

Example 4 Three-Parameter Scheduler in a One-Level Policy

policy-map policy_3parameter_scheduler
class A
bandwidth percent 30 <----------------- minimum bandwidth
bandwidth remaining percent 80 <-----------excess bandwidth
shape average percent 50 <------------maximum bandwidth
class B
bandwidth percent 60
bandwidth remaining percent 10
class class-default

Support for Three-Parameter Scheduler in Hierarchical Policies

In some cases, a scheduler might not support the three parameters at all levels in hierarchical policies.

ASR 9000 Ethernet Line Cards

Queueing is supported at all levels of hierarchical policies:

  • Top level—Two parameters only: excess bandwidth and maximum bandwidth
  • Middle level—Minimum bandwidth, excess bandwidth, and maximum bandwidth
  • Bottom level—Two parameters only: minimum bandwidth or excess bandwidth; and maximum bandwidth with 128 Mbps upper limit

SIP 700 for the ASR 9000

Queueing is supported at the top and middle levels of hierarchical policies:

  • Top level—Two parameters only: excess bandwidth and maximum bandwidth
  • Middle level—Minimum bandwidth, excess bandwidth, and maximum bandwidth
  • Bottom level—Queueing is not supported

Hierarchical Policing

Hierarchical policing is supported on ingress and egress interfaces. Example 1 shows traffic policing in a two-level policy. Hierarchical policing allows enforcement of service level agreements (SLAs) while applying the classification submodel for different QoS classes on the interface. This allows you to police the interface while applying different classification modes on the interfaces.

Hierarchical Policing on ASR 9000 Ethernet Line Cards

Hierarchical policing is supported with these considerations:

  • Ingress and egress interfaces
  • Main interfaces and subinterfaces on all encapsulation types
  • Two-level hierarchical policies and three-level hierarchical policies
  • Police actions

In middle and bottom policies

Processed from the bottom level of the hierarchy to the top level of the hierarchy

  • Policers

For bottom-level policers, the top-level policer rate is used as the reference bandwidth

  • Policies applied on a bundle interface are replicated to all of the bundle members
  • Statistics for all levels in the hierarchy

Hierarchical Policing on the SIP 700 for the ASR 9000

Hierarchical policing is supported with these considerations:

  • Ingress and egress interfaces
  • Main interfaces and subinterfaces on all encapsulation types
  • Two-level hierarchical policies; in three-level policies at middle and bottom levels.
  • Police actions

In top and bottom policies

Processed from the bottom level of the hierarchy to the top level of the hierarchy

  • Policers

Color-blind policers are supported in both top and bottom policies

Policers are not required in bottom-level classes

Police rates can be configured as absolute rates or as percentages

For bottom-level policers, the top-level policer rate is used as the reference bandwidth

  • Statistics for all levels in the hierarchy

Enhanced Hierarchical Ingress Policing

In hierarchical policing, traffic is policed first at the child policer level and then at the parent policer level. It is possible for traffic that conforms to the committed rate specified by the child policer to be dropped by the parent policer.

In Enhanced Hierarchical Ingress Policing, the child-conform-aware command prevents the parent policer from dropping any ingress traffic that conforms to the committed rate specified in the child policer.

How to Configure Hierarchical QoS

When configuring hierarchical QoS, consider the following guidelines:

  • When defining polices, start at the bottom level of the hierarchy. For example, for a two-level hierarchical policy, define the bottom-level policy and then the top-level policy. For a three-level hierarchical policy, define the bottom-level policy, the middle-level policy, and then the top-level policy.
  • Do not specify the input or output keyword in the service-policy command when configuring a bottom-level policy within a top-level policy.
  • Configure bottom-level policies only in middle-level and top-level policies.

This section describes the following tasks:

Configuring the Three-Parameter Scheduler

When configuring the Three-Parameter Scheduler, consider the following guidelines:

  • To use the three-parameter scheduler, a queueing class must be enabled. To enable a queueing class, you must configure at least one of the three parameters. When at least one parameter is configured, a queue is assigned to the class.
  • If you configure only one parameter, the scheduler uses default values for the other two parameters.
  • You can configure all 3 parameters in the same class.
  • Minimum bandwidth must be less than maximum bandwidth.

For information about three-parameter scheduler support on specific line cards or SIPs, see “Support for Three-Parameter Scheduler in Hierarchical Policies” section.

ASR 9000 Ethernet Line Cards

SUMMARY STEPS

1. configure

2. policy-map policy-name

3. class class-name

4. shape average { percent percentage | rate [ units ]}

5. exit

6. policy-map policy-name

7. class class-default

8. bandwidth { rate [ units ] | percent percentage-value }
or
bandwidth remaining [ percent percentage-value | ratio ratio-value ]
or
shape average { percent percentage | rate [ units ]}

9. service-policy policy-map-name

10. end
or
commit

DETAILED STEPS

 

Command or Action
Purpose

Step 1

configure

 

RP/0/RSP0/CPU0:router# configure

Enters global configuration mode.

Step 2

policy-map policy-name

 

RP/0/RSP0/CPU0:router(config)# policy-map bottom-child

Creates or modifies the bottom-level policy.

Step 3

class class-name

 

RP/0/RSP0/CPU0:router(config-pmap)# class Bronze

Assigns the traffic class that you specify to the policy map. Enters policy map class configuration mode.

Step 4

shape average { percent percentage | rate [ units ]}

 

RP/0/RSP0/CPU0:router(config-pmap-c)# shape average 1 mbps

Shapes traffic to the indicated bit rate.

Step 5

exit

 

RP/0/RSP0/CPU0:router(config-pmap-c)# exit

Exits policy map class configuration mode.

Step 6

policy-map policy-name

 

RP/0/RSP0/CPU0:router(config-pmap)# policy-map Top-Parent

Creates or modifies the top-level policy.

Step 7

class class-default

 

RP/0/RSP0/CPU0:router(config-pmap)# class class-default

Configures or modifies the parent class-default class.

Note You can configure only the class-default class in a parent policy. Do not configure any other traffic class.

Step 8

bandwidth { rate [ units ] | percent percentage-value }

or

bandwidth remaining [ percent percentage-value | ratio ratio-value ]

or

shape average { percent percentage | rate [ units ]}

 

 

RP/0/RSP0/CPU0:router(config-pmap-c)# bandwidth percent 30

or

RP/0/RSP0/CPU0:router(config-pmap-c)# bandwidth remaining percent 80

or

RP/0/RSP0/CPU0:router(config-pmap-c)# shape average percent 50

Specifies the minimum bandwidth allocated to a class as a percentage of link bandwidth.

Specifies how to allocate excess bandwidth to a class.

Specifies maximum bandwidth as a percentage of link bandwidth (when other classes are not using all of their bandwidth share).

Note You must configure at least one of the three parameters.

Step 9

service-policy policy-map-name

 

RP/0/RSP0/CPU0:router(config-pmap-c)# service-policy Bottom-Child

Applies a bottom-level policy to the top-level class-default class.

Step 10

end

or

commit

 

RP/0/RSP0/CPU0:router(config-pmap-c)# end

or

RP/0/RSP0/CPU0:router(config-pmap-c)# commit

Saves configuration changes.

  • When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)?
[cancel]:
 

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

  • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

SIP 700 for the ASR 9000

SUMMARY STEPS

1. configure

2. policy-map policy-name

3. class class-name

4. bandwidth { rate [ units ] | percent percentage-value }
or
bandwidth remaining [ percent percentage-value | ratio ratio-value ]
or
shape average { percent percentage | rate [ units ]}

5. exit

6. policy-map policy-name

7. class class-default

8. (Optional) shape average { percent percentage | rate [ units ]}

9. service-policy policy-map-name

10. end
or
commit

DETAILED STEPS

 

Command or Action
Purpose

Step 1

configure

 

RP/0/RSP0/CPU0:router# configure

Enters global configuration mode.

Step 2

policy-map policy-name

 

RP/0/RSP0/CPU0:router(config)# policy-map bottom-child

Creates or modifies the bottom-level policy.

Step 3

class class-name

 

RP/0/RSP0/CPU0:router(config-pmap)# class Bronze

Assigns the traffic class that you specify to the policy map. Enters policy map class configuration mode.

Step 4

bandwidth { rate [ units ] | percent percentage-value }

or

bandwidth remaining [ percent percentage-value | ratio ratio-value ]

or

shape average { percent percentage | rate [ units ]}

 

 

RP/0/RSP0/CPU0:router(config-pmap-c)# bandwidth percent 30

or

RP/0/RSP0/CPU0:router(config-pmap-c)# bandwidth remaining percent 80

or

RP/0/RSP0/CPU0:router(config-pmap-c)# shape average percent 50

Specifies the minimum bandwidth allocated to a class as a percentage of link bandwidth.

Specifies how to allocate excess bandwidth to a class.

Specifies maximum bandwidth as a percentage of link bandwidth (when other classes are not using all of their bandwidth share).

Note You must configure at least one of the three parameters.

Step 5

exit

 

RP/0/RSP0/CPU0:router(config-pmap-c)# exit

Exits policy map class configuration mode.

Step 6

policy-map policy-name

 

RP/0/RSP0/CPU0:router(config-pmap)# policy-map Top-Parent

Creates or modifies the top-level policy.

Step 7

class class-default

 

RP/0/RSP0/CPU0:router(config-pmap)# class class-default

Configures or modifies the parent class-default class.

Note You can configure only the class-default class in a parent policy. Do not configure any other traffic class.

Step 8

shape average { percent percentage | rate [ units ]}

 

RP/0/RSP0/CPU0:router(config-pmap-c)# shape average 1 mbps

(Optional) Shapes traffic to the indicated bit rate.

Step 9

service-policy policy-map-name

 

RP/0/RSP0/CPU0:router(config-pmap-c)# service-policy Bottom-Child

Applies a bottom-level policy to the top-level class-default class.

Step 10

end

or

commit

 

RP/0/RSP0/CPU0:router(config-pmap-c)# end

or

RP/0/RSP0/CPU0:router(config-pmap-c)# commit

Saves configuration changes.

  • When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)?
[cancel]:
 

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

  • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Policing Traffic at Two Levels of Hierarchy

Use this procedure to configure a hierarchical policing policy to police the traffic that enters or exits he router on a specific interface.

SUMMARY STEPS

1. configure

2. policy-map policy-name

3. class class-name

4. (Optional) police rate { value [ units ] | percent percentage } [ burst burst-size [ burst-units ]] [ peak-rate value [ units ]] [ peak-burst peak-burst [ burst-units ]]

5. exit

6. policy-map policy-name

7. class class-default

8. (Optional) police rate { value [ units ] | percent percentage } [ burst burst-size [ burst-units ]] [ peak-rate value [ units ]] [ peak-burst peak-burst [ burst-units ]]

9. service-policy policy-map-name

10. end
or
commit

DETAILED STEPS

 

Command or Action
Purpose

Step 1

configure

 

RP/0/RSP0/CPU0:router# configure

Enters global configuration mode.

Step 2

policy-map policy-name

 

RP/0/RSP0/CPU0:router(config)# policy-map Business

Creates or modifies a bottom-level policy.

Step 3

class class-name

 

RP/0/RSP0/CPU0:router(config-pmap)# class Gold

Assigns the traffic class you specify to the policy map. Enters policy map class configuration mode.

Step 4

police rate { value [ units ] | percent percentage } [ burst burst-size [ burst-units ]] [ peak-rate value [ units ]] [ peak-burst peak-burst [ burst-units ]]

 

RP/0/RSP0/CPU0:router(config-pmap-c)# police rate percent 10

(Optional) Configures traffic policing and enters policy map police configuration mode.

Step 5

exit

 

RP/0/RSP0/CPU0:router(config-pmap-c)# exit

Exits policy map class configuration mode.

Step 6

policy-map policy-name

 

RP/0/RSP0/CPU0:router(config)# policy-map All_Traffic

Creates or modifies a top-level policy.

Step 7

class class-default

 

RP/0/RSP0/CPU0:router(config-pmap)# class class-default

Configures or modifies the default traffic class.

Step 8

police rate { value [ units ] | percent percentage } [ burst burst-size [ burst-units ]] [ peak-rate value [ units ]] [ peak-burst peak-burst [ burst-units ]]

 

RP/0/RSP0/CPU0:router(config-pmap-c)# police rate 128 mbps burst 15000 bytes

(Optional) Configures traffic policing and enters policy map police configuration mode.

Step 9

service-policy policy-map-name

 

RP/0/RSP0/CPU0:router(config-pmap-c)# service-policy Business

Applies the bottom-level policy map to the parent class-default class.

Note Do not specify an input or output keyword.

Step 10

end

or

commit

 

RP/0/RSP0/CPU0:router(config-pmap-c)# end

or

RP/0/RSP0/CPU0:router(config-pmap-c)# commit

Saves configuration changes.

  • When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)?
[cancel]:
 

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

  • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Attaching Hierarchical Policies to Physical and Virtual Links

To attach hierarchical policies to interfaces, subinterfaces, virtual circuits, and virtual LANs, use the service-policy { input | output } policy-map-name command.

SUMMARY STEPS

1. configure

2. interface type interface-path-id

3. service-policy {input | output} policy-map-name

4. end
or
commit

DETAILED STEPS

 

Command or Action
Purpose

Step 1

configure

 

RP/0/RSP0/CPU0:router# configure

Enters global configuration mode.

Step 2

interface type interface-path-id

 

RP/0/RSP0/CPU0:router(config)# interface pos 0/2/0/0

Specifies the interface to attach the hierarchical policy.

Step 3

service-policy {input | output} policy-map-name

 

RP/0/RSP0/CPU0:router(config-if)# service-policy input All_Traffic

Attaches the policy map you specify.

  • input —Apply the QoS policy to inbound packets.
  • output —Apply the QoS policy to outbound packets.
  • policy-map-name— Name of a previously configured top-level policy map

Step 4

end

or

commit

 

RP/0/RSP0/CPU0:router(config-pmap-c)# end

or

RP/0/RSP0/CPU0:router(config-pmap-c)# commit

Saves configuration changes.

  • When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)?
[cancel]:
 

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

  • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Configuring Enhanced Hierarchical Ingress Policing

The difference between configuring enhanced hierarchical ingress policing and configuring hierarchical ingress policing is the addition of the child-conform-aware command.

When used in the parent policer, the child-conform-aware command prevents the parent policer from dropping any ingress traffic that conforms to the maximum rate specified in the child policer.

Restrictions

Enhanced Hierarchical Ingress Policing has the following limitations:

  • Ingress direction only.
  • Sum of all child policer rates cannot be greater than the parent policer rate.
  • Single-rate two-color policer (color blind) only.
  • Configurations that specify burst size in the police rate command are supported; configurations that specify peak burst become single-rate three-color policers and are therefore rejected.
  • Configure the child-conform-aware command only in the parent policer.

SUMMARY STEPS

1. configure

2. policy-map policy-name

3. class class-name

4. service-policy policy-map-name

5. police rate { value [ units ] | percent percentage } [ burst burst-size [ burst-units ]] [ peak-rate value [ units ]] [ peak-burst peak-burst [ burst-units ]]

6. child-conform-aware

7. conform-action [ drop | set options | transmit]

8. exceed-action [ drop | set options | transmit ]

9. end
or
commit

DETAILED STEPS

 

Command or Action
Purpose

Step 1

configure

 

RP/0/RSP0/CPU0:router# configure

Enters global configuration mode.

Step 2

policy-map policy-name

 

RP/0/RSP0/CPU0:router(config)# policy-map parent

Enters policy map configuration mode.

Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.

Step 3

class class-name

 

RP/0/RSP0/CPU0:router(config-pmap)# class class-default

Enters policy map class configuration mode.

Specifies the name of the class whose policy you want to create or change.

Step 4

service-policy policy-map-name

 

RP/0/RSP0/CPU0:router(config-pmap-c)# service-policy child

Applies the bottom-level policy map to the parent class-default class.

Note Do not specify an input or output keyword.

Step 5

police rate { value [ units ] | percent percentage } [ burst burst-size [ burst-units ]] [ peak-rate value [ units ]] [ peak-burst peak-burst [ burst-units ]]

 

RP/0/RSP0/CPU0:router(config-pmap-c)# police rate percent 50

Configures traffic policing and enters policy map police configuration mode.

Step 6

child-conform-aware

 

RP/0/RSP0/CPU0:router(config-pmap-c-police)# child-conform-aware

Prevents the parent policer from dropping any ingress traffic that conforms to the maximum rate specified in a child policer.

Step 7

conform-action [ drop | set options | transmit]

 

RP/0/RSP0/CPU0:router(config-pmap-c-police)# conform-action transmit

Configures the action to take on packets that conform to the rate limit. The allowed action is:

transmit —Transmits the packets.

Step 8

exceed-action [ drop | set options | transmit ]

 

RP/0/RSP0/CPU0:router(config-pmap-c-police)# exceed-action drop

Configures the action to take on packets that exceed the rate limit. The allowed action is:

drop —Drops the packet.

Step 9

end

or

commit

 

RP/0/RSP0/CPU0:router(config-pmap-c-police)# end

or

RP/0/RSP0/CPU0:router(config-pmap-c-police)# commit

Saves configuration changes.

  • When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting(yes/no/cancel)?
[cancel]:
 

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

  • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Configuration Examples for Hierarchical QoS

This section provides the following configuration examples:

Two-Level Hierarchical Queueing Policy: Example

The following example shows a two-level policy applied at the Multilink Frame Relay main interface. The same policy can be applied at Multilink PPP main interface.

class-map match-any video
match precedence 1
end-class-map
!
class-map match-any premium
match precedence 2 3
end-class-map
!
class-map match-any voice-ip
match precedence 0
end-class-map
!
class-map match-any best-effort
match precedence 4
end-class-map
 
policy-map parent_shape
class class-default
service-policy child_policy
shape average percent 90
!
end-policy-map
!
 
policy-map child_policy
class voice-ip
priority level 1
police rate percent 20
!
!
class video
bandwidth percent 40
!
class premium
bandwidth percent 10
random-detect precedence 2 10 ms 100 ms
random-detect precedence 3 20 ms 200 ms
queue-limit 200 ms
!
class best-effort
bandwidth percent 20
queue-limit 200 ms
!
class class-default
!
end-policy-map
!
 
interface Multilink0/2/1/0/1
service-policy output parent_shape
encapsulation frame-relay
frame-relay intf-type dce

Three-Level Hierarchical Queueing Policy: Examples

ASR 9000 Ethernet Line Cards

In this example, policy grand-parent is applied to the main Ethernet interface. The grand-parent policy limits all outbound traffic of the interface up to 500 Mbps. The parent policy has class vlan1 and vlan2, and traffic in vlan1 or vlan2 is limited to 40 percent of 500 Mbps. The policy child_policy classifies traffic based on different services and allocates bandwidth for each class accordingly.

class-map match-any video
match precedence 1
end-class-map
!
class-map match-any premium
match precedence 2 3
end-class-map
!
class-map match-any voice-ip
match precedence 0
end-class-map
!
class-map match-any best-effort
match precedence 4
end-class-map
 
class-map match-any vlan1
match vlan 1
end-class-map
 
class-map match-any vlan2
match vlan 2
end-class-map
 
policy-map grand-parent
class class-default
shape average 500 Mbps
service-policy parent
!
end-policy-map
 
policy-map parent
class vlan1
service-policy child_policy
shape average percent 40
!
class vlan2
service-policy child_policy
shape average percent 40
!
end-policy-map
!
 
policy-map child_policy
class voice-ip
priority level 1
police rate percent 20
!
!
class video
bandwidth percent 40
!
class premium
bandwidth percent 10
random-detect precedence 2 10 ms 100 ms
random-detect precedence 3 20 ms 200 ms
queue-limit 200 ms
!
class best-effort
bandwidth percent 20
queue-limit 200 ms
!
class class-default
!
end-policy-map
 
interface GigabitEthernet0/0/0/9
service-policy output grand-parent

SIP 700 for the ASR 9000

In this example, the policy parent_policy is applied to the Multilink Frame Relay main interface. The policy parent_policy has two classes, which match on Frame Relay DLCIs. The Multilink Frame Relay main interface has two Frame Relay PVCs configured (DLCI 16, DLCI 17).

interface Multilink0/2/1/0/1
mtu 1504
service-policy output parent_policy
encapsulation frame-relay
frame-relay intf-type dce
!
 
policy-map parent_policy
class parentQ_1
service-policy child_queuing_policy
shape average 64 kbps
!
class parentQ_2
service-policy child_queuing_policy
shape average 1 mbps
!
class class-default
!
end-policy-map
!
 
class-map match-any parentQ_1 <----- class map parent class dlci=16
match frame-relay dlci 16
end-class-map
!
 
class-map match-any parentQ_2 <----- class map parent class dlci=17
match frame-relay dlci 17
end-class-map
!
 
interface Multilink0/2/1/0/1.16 point-to-point <------ dlci 16 pvc config
ipv4 address 192.1.1.1 255.255.255.0
pvc 16
encap cisco
!
!
interface Multilink0/2/1/0/1.17 point-to-point <------ dlci 17 pvc config
ipv4 address 192.1.2.1 255.255.255.0
pvc 17
encap cisco
!
!
policy-map child_queuing_policy <--------- child policy map
class voice-ip
priority level 1
police rate percent 20
!
!
class video
bandwidth percent 40
!
class premium
service-policy gchild_policy
bandwidth percent 10
random-detect discard-class 2 10 ms 100 ms
random-detect discard-class 3 20 ms 200 ms
queue-limit 200 ms
!
class best-effort
bandwidth percent 20
queue-limit 200 ms
!
class class-default
!
end-policy-map
!
policy-map gchild_policy <-------- grandchild policy map
class premium_g1
police rate percent 10
!
set discard-class 2
!
class premium_g2
police rate percent 50
!
set discard-class 3
!
class class-default
!
end-policy-map
!
 
show run class-map <----------- shows all class-map configs
Mon Aug 2 11:35:19.479 UTC
class-map match-any video
match precedence 1
end-class-map
!
class-map match-any premium
match precedence 2 3
end-class-map
!
class-map match-any voice-ip
match precedence 0
end-class-map
!
class-map match-any parentQ_1
match frame-relay dlci 16
end-class-map
!
class-map match-any parentQ_2
match frame-relay dlci 17
end-class-map
!
class-map match-any premium_g1
match precedence 2
end-class-map
!
class-map match-any premium_g2
match precedence 3
end-class-map
!
class-map match-any best-effort
match precedence 4
end-class-map

Three-Parameter Scheduler: Examples

ASR 9000 Ethernet Line Cards

This example shows how to configure a three-parameter scheduler in a two-level hierarchical policy.

policy-map Bottom-ChildA
class A1
shape average 400 kbps
class A2
shape average 400 kbps
 
policy-map Bottom-ChildB
class B1
shape average 250 kbps
class B2
shape average 450 kbps
 
policy-map Top-Parent
class parentA
shape average 500 kbps
bandwidth percent 30
bandwidth remaining percent 80
service-policy Bottom-ChildA
class parentB
shape average 500 kbps
bandwidth percent 60
bandwidth remaining percent 10
service-policy Bottom-ChildB

SIP 700 for the ASR 9000

This example shows how to configure a three-parameter scheduler in a two-level hierarchical policy.

policy-map Bottom-Child
class A
bandwidth percent 30
bandwidth remaining percent 80
shape average percent 50
class B
bandwidth percent 60
bandwidth remaining percent 10
class class-default
exit
 
policy-map Top-Parent
class-default
shape average 1 mbps
service-policy Bottom-Child

Hierarchical Policing: Examples

ASR 9000 Ethernet Line Cards

This example shows a two-level policy with police actions at each level. There are two classes in the top level, one for each customer. Aggregated traffic from each customer is subject to a rate limit as specified by the police rate command in the top level. Traffic in different classes in the bottom level is limited by an additional set of police actions to control different types of traffic for each customer.

class-map match-any customera
match vlan 10-14
class-map match-any customerb
match vlan 15-19
class-map match-any prec1
match precedence 1
class-map match-any prec3
match precedence 3
 
policy-map parent
class customera
service-policy childa
bandwidth remaining ratio 10
police rate percent 50
conform-action transmit
exceed-action drop
class customerb
service-policy childb
bandwidth remaining ratio 100
police rate percent 70
conform-action transmit
exceed-action drop
 
policy-map childa
class prec1
police rate percent 25
conform-action transmit
exceed-action drop
class prec3
police rate percent 25
conform-action transmit
exceed-action drop
 
policy-map childb
class prec1
police rate percent 30
conform-action transmit
exceed-action drop
class prec3
police rate percent 30
conform-action transmit
exceed-action drop

SIP 700 for the ASR 9000

In this example, policers are specified in the policy child in class Prec1 and class Prec3, and also in the class-default in the policy parent. The policers in the child policy, police traffic in class Prec1 at 30 percent (of 50 percent), police traffic in class Prec3 at 60 percent (of 50 percent) and police any other traffic at 10 percent (of 50 percent). Cumulatively, all traffic on the interface is policed at 50 percent of the interface rate by the policer in the parent policy.

class-map match-any prec1
match precedence 1
 
class-map match-any prec3
match precedence 3
 
policy-map parent
class class-default
service-policy child
police rate percent 50
conform-action transmit
exceed-action drop
policy-map child
class prec1
police rate percent 30
conform-action transmit
exceed-action drop
class prec3
police rate percent 60
conform-action transmit
exceed-action drop
class class-default
police rate percent 10
conform-action transmit
exceed-action drop

Attaching Service Policies to Physical and Virtual Links: Examples

Physical Link: Example

In this example, the p1 policy is applied to a Gigabit Ethernet interface:

interface gigabitethernet 0/2/0/0
service-policy input p1

Virtual Link: Example

In this example, the p2 policy is applied to the private virtual circuit (PVC) under a multilink Frame Relay subinterface. A QoS policy can be applied only to a PVC under a Frame Relay subinterface; it cannot be applied directly to a Frame Relay subinterface.

interface Multilink0/2/1/0/1.16 point-to-point
encapsulation frame-relay
ipv4 address 192.1.1.1 255.255.255.0
pvc 16
service-policy output p2
encap cisco

Enhanced Hierarchical Ingress Policing: Example

This example shows parent and child policies in which two classes are defined in the child policy. In class AF1, the exceed action is set to an action other than to drop traffic.

If the child-conform-aware command were not configured in the parent policy, the parent policer would drop traffic that matches the conform rate of the child policer but exceeds the conform rate of the parent policer.

When used in the parent policer, the child-conform-aware command prevents the parent policer from dropping any ingress traffic that conforms to the committed rate specified in the child policer.

In this example, class EF in the child policy is configured with a committed rate of 1 Mbps, a conform action and an exceed action. The traffic that is below 1 Mbps is presented to the parent policer with the MPLS EXP bit set to 4, and traffic that exceeds 1 Mbps is dropped.

Class AF1 in the child policy is configured with a committed rate of 1 Mbps, a conform action and an exceed action. The traffic that is below 1 Mbps is presented to the parent policer with the MPLS EXP bit set to 3, and traffic that exceeds 1 Mbps is presented to the parent policer with the MPLS EXP bit set to 2.

With this child policy configuration, the parent policer sees traffic from the child classes as exceeding its committed rate of 2 Mbps. Without the child-conform-aware command in the parent policer, the parent polices to 2 Mbps, which can result into dropping some conformed traffic from class EF in the child policy. When the child-conform-aware command is configured in the parent policer, the parent policer does not drop any traffic that conforms under the child policy.

policy-map parent
class class-default
service-policy child
police rate 2 mbps
child-conform-aware
conform-action transmit
exceed-action drop
 
policy-map child
class EF
police rate 1 mbps
conform-action set mpls experimental imposition 4
exceed-action drop
class AF1
police rate 1 mbps
conform-action set mpls experimental imposition 3
exceed-action set mpls experimental imposition 2

Verifying the Configuration of Hierarchical Policies

To verify hierarchical policies, enter any of the following commands in privileged EXEC mode:

Command
Purpose

show policy-map interface

Displays policy configuration information for all classes configured for all service policies on the specified interface.

show qos interface

Displays QoS information for all classes in the service policy that is attached to the specified interface.

show running-config class-map

Displays the configuration of all class maps configured on the router.

show running-config policy-map

Displays the configuration of all policy maps configured on the router.

show running-config policy-map policy-map-name

Displays the configuration of all classes contained in the policy map you specify.

Additional References

The following sections provide references related to implementing Hierarchical QoS.

Related Documents

Related Topic
Document Title

Initial system bootup and configuration

Cisco ASR 9000 Series Aggregation Services Router Getting Started Guide

Master command reference

Cisco ASR 9000 Series Aggregation Services Router Master Command Listing

QoS commands

Cisco ASR 9000 Series Aggregation Services Router Modular Quality of Service Command Reference

User groups and task IDs

“Configuring AAA Services on Cisco ASR 9000 Series Router” module of Cisco Cisco ASR 9000 Series Aggregation Services Router System Security Configuration Guide

Standards

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
MIBs Link

To locate and download MIBs using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL and choose a platform under the Cisco Access Products menu: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

RFCs

RFCs
Title

No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.

Technical Assistance

Description
Link

The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

http://www.cisco.com/techsupport