ATM Switch Router Software Configuration Guide, 12.1(7a)EY
Configuring IP QoS

Table Of Contents

Configuring Quality of Service

About Quality of Service

Best-Effort Service

Integrated Service

Differentiated Service

About Layer 3 Switching Quality of Service

About Quality of Service Mechanisms

IP Precedence based Class of Service (CoS)

About Scheduling and Weighted Round-Robin

Configuring Precedence to WRR Scheduling

Verifying the QoS Configuration

About IP QoS on the Enhanced Gigabit Ethernet Interfaces

Packet Classification

Traffic Conditioning

Marking

Metering and Policing

Per Hop Behavior Definition

Queuing

Scheduling

Congestion Control

Tail Drop

xRED

Configuring IP QoS Policies Using the Modular CLI

Configuring IP QoS on Enhanced Gigabit Ethernet Interfaces

Attaching a Service Policy to an Interface

TCAM Region for IP QoS

Verifying the IP QoS Configuration

Configuring Quality of Service


This chapter describes the quality of service (QoS) features built into your switch router and includes information on how to configure the QoS functionality. This chapter includes the following sections:

About Quality of Service

About Layer 3 Switching Quality of Service

IP Precedence based Class of Service (CoS)

About IP QoS on the Enhanced Gigabit Ethernet Interfaces

Configuring IP QoS on Enhanced Gigabit Ethernet Interfaces

Verifying the IP QoS Configuration


Note Unless otherwise noted, the information in this chapter applies to the Catalyst 8540 CSR, Catalyst 8510 CSR, and Catalyst 8540 MSR with Layer 3 functionality. For further information about the commands used in this chapter, refer to the ATM and Layer 3 Switch Router Command Reference.


About Quality of Service

QoS refers to the capability of a network to provide better service to selected network traffic over various technologies, including Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet and 802.1 networks, SONET, and IP-routed networks that may use any or all of these underlying technologies.The following sections describe the Best-Effort, Integrated, and Differentiated service models that the QoS functionality offers.


Note For more information about Policy Based Routing, refer to the Layer 3 Switching Software and Feature Configuration Guide.


Best-Effort Service

Best effort is a single service model in which an application sends data whenever it must, in any quantity, and without requesting permission or first informing the network. For best-effort service, the network delivers data if it can, without any assurance of reliability, delay bounds, or throughput.

The Cisco IOS QoS feature that implements best-effort service is first-in, first-out (FIFO) queueing. Best-effort service is suitable for a wide range of network applications such as general file transfers or e-mail.

Integrated Service

Integrated service is a multiple service model that can accommodate multiple QoS requirements. In this model the application requests a specific kind of service from the network before it sends data. Explicit signalling makes the request. The application informs the network of its traffic profile and requests a particular kind of service that can encompass its bandwidth and delay requirements. The application is expected to send data only after it gets a confirmation from the network. It is also expected to send data that lies within its described traffic profile.

The network performs admission control, based on information from the application and available network resources. It also commits to meeting the QoS requirements of the application as long as the traffic remains within the profile specifications. The network fulfills its commitment by maintaining per-flow state and then performing packet classification, policing, and intelligent queueing based on that state.

Differentiated Service

Differentiated service is a multiple service model that can satisfy differing QoS requirements. However, unlike the integrated service model, an application using differentiated service does not explicitly signal the router before sending data.

For differentiated service, the network tries to deliver a particular kind of service based on the QoS specified by each packet. This specification occurs in different ways, for example, while using the IP Precedence bit settings in IP packets or source and destination addresses. The network uses the QoS specification to classify, mark, shape, and police traffic, and to perform intelligent queueing.

About Layer 3 Switching Quality of Service

Layer 3 switching on the Catalyst 8500 switch router uses the packet classification feature in QoS to partition network traffic into multiple priority levels of classes of service. For example, by using the three precedence bits in the type-of-service (ToS) field of the IP packet header—two of the values are reserved for other purposes—you can categorize packets into a limited set of up to six traffic classes.

After you classify packets, you can utilize other QOS features to assign the appropriate traffic handling policies like congestion management and bandwidth allocation for each traffic class.

About Quality of Service Mechanisms

The Catalyst 8540 campus switch router provides extensive core Quality of Service (QoS) mechanisms that are built into the switch router architecture. These functions ensure policy enforcement and queuing of the ingress port, as well as weighted round-robin (WRR) scheduling at the egress port.

The two mechanisms discussed here are:

IP precedence based Class of Service (CoS)

This is used when the ingress or the egress interface is an EPIF based interface or when the egress interface is an XPIF based interface without a configured IP QoS output policy.

IP QoS (for the Enhanced Gigabit Ethernet interfaces)

IP QoS is the implementation of the Differentiated Services (DiffServ) model. It is used when the ingress and egress interfaces are enhanced Gigabit Ethernet interfaces, and the egress interface has an attached IP QoS output policy.

IP Precedence based Class of Service (CoS)

Layer 3 precedence based CoS uses the IP precedence values to partition traffic into multiple classes of service.

The system gathers IP precedence information from the IP header type-of-service field. For an incoming IP packet, the first two (most significant) bits of the service type field determine the delay priority. Layer 3 switching recognizes four QoS classes, Q-0 to Q-3, as summarized in Table 21-1.

Table 21-1 I QoS Delay Priorities and Queues

IP Precedence Bits 
Delay Priority
Queue Selected 

0 0 0

0 0

Q-0

0 0 1

0 0

Q-0

0 1 0

0 1

Q-1

0 1 1

0 1

Q-1

1 0 0

1 0

Q-2

1 0 1

1 0

Q-2

1 1 0

1 1

Q-3

1 1 1

1 1

Q-3


Your switch router can read the precedence field and switch the packet accordingly, but it cannot reclassify traffic. The edge router or switch is expected to set the precedence field according to its local policy.

The switch router queues packets based on the delay priority and the target next-hop interface.

About Scheduling and Weighted Round-Robin

Frame scheduling becomes increasingly important when an outgoing interface is congested. To handle this situation, network administrators can assign weights to each of the different queues. This provides bandwidth to higher priority applications (using IP precedence), while also granting fair access to lower priority queues. The frame schedule affords each queue the bandwidth allotted to it by the network administrator. This mapping is configurable both at the system and interface levels (as described later in this chapter).

The four queues between any pair of interfaces are configured to be part of the same service class. Bandwidth is not explicitly reserved for these four queues. Each of them is assigned a different WRR-scheduling weight, which determines the way they share the interface bandwidth. The WRR weight is user configurable; you can assign a different WRR weight for each queue.


Tip The higher the WRR weight, the higher the effective bandwidth for that particular queue.


You can find the effective bandwidth (in Mbps) for a particular queue with the following formula:

(W/S) x B = n Mbps,

where

W = WRR weight of the specified queue
S = sum of the weight of all active queues on the outgoing interface
B = available bandwidth in Mbps
n = effective bandwidth in Mbps

For example, if W is 4, S is 15, and B is 100, the formula would be (4/15) x 100 = 26 Mbps, and the effective bandwidth for the specified queue in this example is 26 Mbps.

Configuring Precedence to WRR Scheduling

This section describes the Cisco IOS commands necessary to configure QoS mapping at the system and interface levels. The commands described in this section are unique to the Layer 3 switching software.

Layer 3 switching software enables QoS-based forwarding by default.

To configure QoS scheduling at the system level, use the following command:

Command
Purpose

Router(config)# qos mapping precedence value wrr-weight weight

Sets the mapping between IP precedence and the WRR weight.


To set the precedence back to the default setting for the switch router, use the no version of the qos mapping precedence command.

Table 21-2 shows the default WRR weights for IP precedence.

Table 21-2 IP Precedence and Default WRR Weights

IP Precedence
WRR Weight

0

1

1

2

2

4

3

8


For a complete description of the qos mapping precedence command, see the ATM and Layer 3 Switch Router Command Reference.

Mapping QoS Scheduling at the Interface Level

Configuring the QoS mapping at the interface level overrides the system-level mapping. Using the qos mapping precedence wrr-weight command, the network administrator can assign different WRR-scheduling weights for a particular precedence traffic between a pair of interfaces.

To configure QoS scheduling at the interface level, use the following command:

Command
Purpose

Router(config)# qos mapping [source source-interface] [destination dest-interface] precedence value wrr-weight weight

Assigns different WRR-scheduling weights for a particular precedence traffic between a pair of interfaces.


The QoS commands are applicable to both Gigabit Ethernet and Fast Ethernet interfaces.

To set the precedence back to the system-level default setting for the switch router, use the no version of the qos mapping precedence wrr-weight command.

Both the source and destination interface parameters are optional. When both are not specified, the system-level QoS mapping is configured. Otherwise, you can specify the source interface, the destination interface, or both, to configure the WRR weight for the traffic streams listed below.

The configuration takes precedence in the following order:

1. Traffic streams with a certain precedence, from a particular source interface to a particular destination interface

2. Traffic streams with a certain precedence to a particular destination interface

3. Traffic streams with a certain precedence from a particular source interface

Verifying the QoS Configuration

To verify the QoS configuration, use the following commands:

Command
Purpose

show qos switching

Displays whether QoS-based switching is enabled.

show qos mapping [source source-interface] [destination dest-interface]

Displays effective mapping at either the system level or interface-pair level.


About IP QoS on the Enhanced Gigabit Ethernet Interfaces

DiffServ is a mechanism by which network service providers offer differing levels of network service to different traffic classes in order to provide QoS to users.

In a DiffServ network, routers, within the network handle packets on different traffic flows by applying different per-hop behaviors (PHBs). The PHB to be applied is signalled in-band, and is specified by a DiffServ code-point (DSCP) in the IP header of each packet. No explicit out-of-band signalling protocol such as RSVP is used. Per-hop behaviors are defined to configure granular allocation of bandwidth and resource buffering at each node. Per-flow or per-user forwarding state is not maintained within each node of network. The advantage of such a scheme is that many traffic flows can be aggregated to one of a small number of PHBs, simplifying the processing requirement on each router.

The following components are the building block in the Catalyst 8540 Differentiated Services implementation:

Packet Classification

Traffic Conditioning

Marking

Metering and Policing

Per hop behavior (PHB) definition

Congestion control

Queueing, scheduling, buffer management

Figure 21-1 shows all the DiffServ components and their distribution between the ingress and egress points in the forwarding path.

Figure 21-1 Architechual Model

Packet Classification

Packet classifiers select packets in a traffic stream based on the content of some portion of the packet header.

Classifiers are implemented in a ternary content addressable memory (TCAM). TCAM has the capability of providing variable length matches. The order in which classifiers are defined within a policy map is the order in which entries will be programmed in TCAM.

There are two types of classifiers:

Multi-field (MF) classifiers:

Classify traffic streams identified by the source and/or destination IP addresses, TCP/UDP source and/or destination ports, and/or Layer 4 protocol

Are configured using one or more IP standard or extended, named or numbered Access Control Lists (ACLs)

Behavior Aggregate (BA) classifiers:

Classify traffic streams based on the differentiated services code-point (DSCP) or IP precedence bits in the TOS byte of the IP header


Note In the IP QoS context, the permit and deny actions in the access control entries (ACEs) have different meanings than with security ACLs:


If a match with a permit action is encountered (first-match principle), the specified traffic conditioning action for that classifier is taken.

If a match with a deny action is encountered, the classifier being processed is skipped, and the next classifier's ACL(s) is/are processed.

If no match with a permit action is encountered and all the configured classifiers' ACEs have been examined, the packet is assumed to be in the well known default class (class-default).

Traffic Conditioning

A traffic stream is selected by a classifier, which steers the packets to a logical instance of a traffic conditioner (marker, meter/policer).

Marking

Packet marking is a traffic conditioning action, performed on an identified flow at the ingress port. The marking action could cause the DSCP / precedence bits to be re-written or left unchanged, depending on user configuration.

The following types of markers are supported:

DSCP markers:

Packet markers set the DS field of a packet to a particular code point, adding the marked packet to a particular DS behavior aggregate. Based on configurations, each packet matching a particular classifier may be marked with the specified DSCP value.The marker has the capability of marking all the 64 possible DSCP values.

IP-Precedence markers:

To maintain compatibility with the 3 bit IP precedence (Class of Service) contained in the TOS byte of the IP header, the marker provides an option to mark a classified packet with a specified IP precedence value. The marker has the capability of marking all the 8 possible IP-precedence values. The remaining 3 bits of the DSCP field are set to zero.

Trusted Traffic:

This is a class of traffic that has a service level agreement with an upstream router, and, as a result, may not require the application of a marker.


Note If a marking action is not configured, that class of traffic is implicitly trusted. Alternatively, the user may specifically configure the class of traffic as trusted.


Metering and Policing

Traffic matching a classifier may be metered using the Token Bucket Algorithm. The result of this metering is used to decide whether to police a particular traffic stream or not.

Incoming packets are passed unaltered if the packet conforms to the traffic profile for that class. Out of profile packets are discarded or marked down, depending on user configuration.

There are 32 instances of meters/policers available per physical interface. These may be distributed between Multi-Field/Behavior Aggregate classifiers as required by the user.


Note There must be at least one traffic conditioning element associated with every classifier in an input policy map.


Per Hop Behavior Definition

Per Hop Behavior or PHB is the externally observable forwarding behavior (in terms of buffer/bandwidth resource allocation), applied to a particular traffic class. This is essentially defined by the queuing/scheduling/buffer management in the forwarding path.

Queuing

Once the traffic stream is classified and conditioned, the forwarding engine is consulted to get the destination interface to which the packet needs to be switched. There are four output queues for each physical interface and each can be assigned to an output traffic class. A direct lookup table, called the queue selector table, is used to determine which is the correct queue for the packet. This table is indexed using a combination of the output interface and DSCP from the packet header.

All entries in this table are initialized to 0 by default (Q0 is the queue for best effort behavior). This mapping may be changed through user configuration.

Figure 21-2 Four Queues Per Physical Interface

Figure 21-3 shows queue-implementation for each physical interface. Each queue can be assigned to a particular output traffic class.

Figure 21-3 Queue Implementation

Buffer Management

Each queue is associated with a threshold buffer group, which essentially defines a set of parameters for buffer management and drop behavior.

Threshold group parameters are defined as follows:

Discard limit value:

This is the maximum queue length (in bytes), beyond which the packet will be tail-dropped.

Marking limit value:

This is the point in the queue (in bytes), after which packets in the queue will have the EFCI bit set.


Note The threshold group parameters are configured in bytes and are rounded up so as to be multiples of an ATM cell payload (48 bytes).


The Catalyst 8540 has a maximum of four buffer groups, and the above parameters may be defined for each of these buffer groups through user configuration.

Scheduling

Each of the four traffic classes are served by the scheduler according to it's configured weight. Scheduling is done using the Weighted Round Robin Algorithm.

The WRR scheduler guarantees a minimum bandwidth to each class, based on the assigned weight. Idle bandwidth is shared among the classes in a fair manner.

Congestion Control

Two drop policies are supported, tail drop and XPIF based Random Early Detect (or xRed).

Tail Drop

Queues fill up during periods of congestion. When the output queue is full and tail drop is in effect, packets are dropped until the congestion is eliminated and the queue is no longer full.

On the Catalyst 8540, the point at which packets will start getting dropped is the user configured discard limit - as soon as the buffer filling drops below this threshold, packets will no longer be dropped) This is the default congestion avoidance mechanism.

xRED

This is a variation of the Random Early Detection Algorithm, as implemented on the Catalyst 8540.

A packet is EFCI-marked if the length of the queue in which it is buffered exceeds a pre-set marking threshold. By counting the number of EFCI-marked packets over an interval at an output port, the degree of congestion of the output port can be assessed.

In a given time interval, if Ne represents the total number of EFCI marked packets and Nt represents the total number of packets, then the ratio Ne/Nt follows the average queue length.

Thus, the port's average queue length is monitored, and packets are randomly discarded with a variable probability if the average queue length exceeds the configured threshold.

Configuring IP QoS Policies Using the Modular CLI

This section describes the tasks for configuring IP QoS functionality with the Modular QoS CLI.

For a complete description of the commands mentioned in this section, refer to the Cisco IOS Quality of Service Solutions Command Reference. The commands are listed alphabetically within the guide. To locate documentation of a specific command, use the command reference, master index, or on-line search.


Note The Catalyst 8500 does not support all the commands documented in the Quality of Service Solutions Command Reference.


Configuring IP QoS on Enhanced Gigabit Ethernet Interfaces

The IP QoS configuration requires the following three steps, which are detailed in this section:


Step 1 Defining a traffic class with a class-map command

Step 2 Creating a service policy by associating the traffic class with one or more QoS policies using the policy-map command

Step 3 Attaching the service policy to the interface with the service-policy command


Defining a traffic class

The class-map command is used to define a traffic class.

A traffic class consists of two major elements:

a name

one or more match criteria / rules

The following commands describe how to configure a traffic class in global configuration mode:

 
Command
Purpose

Step 1

Router (config) # class-map class-map name

Specifies the user-defined name of the traffic class.

Step 2

Router (config-cmap) # match access-group access-group

Specifies the numbered access list, against whose contents packet headers will be checked to determine if they belong to the class. (MF classification)

 

Router (config-cmap) # match access-group name access-group

Specifies the named access list, against whose contents packet headers will be checked to determine if they belong to the class. (MF classification)

 

Router (config-cmap) # match ip precedence number

Specifies up to eight IP precedence values separated by spaces, to be used as match criteria. (BA classification).

 

Router (config-cmap) # match ip dscp number

Specifies up to eight differentiated services code point (DSCP) values, separated by spaces, to be used as match criteria. The value of each service code point is between 0 and 63. (BA classification).

Example

The following example shows how to configure a multi-field classifier:
(config)#class-map eng-traffic
(config-cmap)#match access-group 101
(config-cmap)#match access-group name tac-traffic

The following example shows how to configure a BA classifier:
(config)#class-map critical-traffic
(config-cmap)#match ip precedence 7
(config)#class-map other-traffic
(config-cmap)#match ip dscp 1 2 3 4 5 6 7 8
(config-cmap)#match ip dscp 9 10 11
(config)#class-map mixed-traffic
(config-cmap)#match ip dscp af11
(config-cmap)#match ip precedence 1

Note Multiple match commands may be specified within the same class-map.


MF classifiers may only be used within input policy maps while BA classifiers may be used within input and/or output policy maps.

Creating a Service Policy

The policy-map command is used to define a service policy.

A policy map definition consists of:

a name

a set of classifiers (class-maps)

their associated traffic conditioners (for input policy maps) or per hop behavior (PHB) definitions (for output policy maps).

The following commands show how to configure a service policy on an ingress interface (input policy map):

 
Command
Purpose

Step 1

Router (config) # policy-map policy-name

Specifies the name of the service policy to configure.

Step 2

Router (config-pmap) # class class-name

Specifies the name of a predefined class, which was defined with the class-map command

 

Router (config-pmap-c) # class class-default

Specifies the well known default class.

Step 3

Router (config-pmap-c) # police rate burst exceed-action [drop | set-dscp-transmit dscp-value | set-precedence-transmit ip precedence-value]

Specifies three parameters to define the meter and policer

rate is the average rate of data arrival (in Kbits/sec)

burst is the maximum burst (in bytes)

exceed action is either drop or mark down.

 

Router (config-pmap-c) # set ip-precedence ip-precedence-value

Specifies an IP precedence marker. The IP precedence value can be any value between 0 and 7.

 

Router (config-pmap-c) # set ip dscp ip-dscp-value

Specifies a DSCP marker. The DSCP value can be any value between 0 and 63.

 

Router (config-pmap-c) # set ip [precedence | dscp] unchanged

Specifies trusted traffic.

Example

Router(config)# policy-map in-policy
Router(config-pmap)# class one
Router(config-pmap-c)# set ip dscp 48
Router(config-pmap-c)# police 96000000 16000000 exceed-action set-dscp-transmit 0
Router(config-pmap)# class two
Router(config-pmap-c)# set ip precedence unchanged
Router(config-pmap-c)# police 96000000 16000000 exceed-action set-dscp-transmit 0
Router(config-pmap-c)# class-default
Router(config-pmap-c)# set ip dscp 0


Note Input policy maps:


can have a maximum of 16 class maps including the default class.

may be configured on the physical interface or on any 64 subinterfaces on the physical interface.

have a maximum number of 32 policer instances which can be applied per physical interface.

should have sufficient TCAM space available for the policy to be programmed (minimum 512 entries).

The following commands show how to configure a service policy on an egress interface (output policy map):

 
Command
Purpose

Step 1

Router (config) # policy-map policy-name

Specifies the name of the service policy to configure.

Step 2

Router (config-pmap) # class class-name

Specifies the name of a predefined class, which was defined with the class-map command

 

Router (config-pmap-c) # class class-default

Specifies the default class

Step 3

Router (config-pmap-c) # bandwidth kbps

Specifies a minimum bandwidth (in Kbits/sec) guaranteed to a traffic class. This must be specified for each class in the output policy, including class-default.

 

Router (config-pmap-c) # random-detect [buffer-group buffer-group-number | max-probability max-probability | freeze-time millisecond]

Enables the XPIF based Random Early Detect (xRED) drop policy.

buffer-group-number specifies one of 4 possible buffer groups available (value 0 to 3)

max-probability range is 1 to 65535, and

freeze-time range is 10 to 2000 milliseconds.

 

Router (config-pmap-c) # queue-limit buffer-group buffer-group-number

Configures the Tail drop policy.

buffer-group-number specifies one of 4 possible buffer groups available (value 0 to 3)

Example

Router(config)# policy-map out-policy
Router(config-pmap)#class prec2
Router(config-pmap-c)#bandwidth 10000
Router(config-pmap-c)#class prec4
Router(config-pmap-c)#bandwidth 100000
Router(config-pmap-c)#random-detect buffer-group 2 max-probability 1024 freeze-time 100
Router(config-pmap-c)#class prec6
Router(config-pmap-c)#bandwidth 100000
Router(config-pmap)#class class-default
Router(config-pmap-c)#bandwidth 10000

Note Output policy maps:


Can have a maximum of 4 class maps, including the default class.

May be configured only on the physical interface.

The classifiers on the output direction must be BA classifiers.

Must have exactly one class with `match any' for default/unclassified traffic.

Must have bandwidth configured for every class.

`queue-limit' or `random-detect' are mutually exclusive. `queue-limit' is the default if nothing is configured.

Configuring Buffer-Groups

Buffer groups are global resources that can be configured to be shared among output traffic classes. Four possible buffer groups are available.

Command
Purpose

buffer-group buffer-group-number discard-limit discard-limit-range mark-limit mark-limit-range

Specifies the threshold buffer group parameters buffer-group-number is an integer identifying the group (range 0-3)

discard-limit range is the maximum queue length in bytes, beyond which the packet will be tail-dropped

mark-limit range is the point in the queue (in bytes), after which packets in the queue will have the EFCI bit set.



Note Configuring the discard-limit and the mark-limit using the buffer-group command is optional and not a necessary step in defining a service policy. If the buffer-group is not configured, default values for discard-limit and mark-limit apply.


Attaching a Service Policy to an Interface

Use the service-policy interface configuration command to attach a service policy to an interface and to specify the direction of the policy application (either on packets coming into the interface or packets leaving the interface).

Use the no form of the command to detach a service policy from an interface. The service-policy command syntax is:

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

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

Command
Purpose

Router (config-if) # service-policy output policy-map-name

Attaches the output service policy to the interface

Router (config-if) # service-policy input policy-map-name

Attaches the input service policy to the interface


Although you can assign the same service policy to multiple interfaces, each interface can have only one service policy attached at the input and only one service policy attached at the output.

Example

Router(config)# interface gigabitethernet 1/0/1
Router(config-if)# service-policy output out-policy

Router(config-if)#interface gigabitethernet 0/0/1.15
Router(config-if)# service-policy input in-policy

TCAM Region for IP QoS

By default, there is no space reserved for IP QoS in TCAM. There needs to be a minimum of 512 entries for the IP QoS region in TCAM, for IP QoS functionality to be enabled.

This size is configurable, but requires a reload to take effect If enough space is not available in TCAM after the reload, IP QoS will get disabled automatically.


Tips TCAM space may be allocated for IP QoS using the command:


sdm ipqos number_of_entries.

Verifying the IP QoS Configuration

To verify the IP QoS configuration, use the following commands:

Command
Purpose

Router # show class-map

Displays all the traffic class information.

Router # show class-map class-name

Displays the traffic class information for the user-specified traffic class.

Router # show policy-map

Displays all configured service policies.

Router # show policy-map policy-map-name

Displays the user-specified service policy.

Router # show policy-map interface

Displays configurations of all input and output policies that are attached to an interface.

Router # show policy-map interface interface-spec input

Displays configuration of the input policy attached to the interface.

Router # show policy-map interface interface-spec output

Displays configuration of the output policy attached to the interface.

Router # show policy-map interface [interface [interface-spec [input | output] [class class-name]]]

Displays the configuration of the class name configured in the policy.

Router # show sdm size [current | configured]

Displays the currently allocated or the configured TCAM region sizes for different features


Example

The following example shows all policy maps configured:


Router# show policy-map 
 Policy Map four 
  class  five 
   set ip dscp unchanged 
  class  six 
   set ip precedence 7 

 Policy Map one 
  class  one 
   set ip dscp unchanged 
  class  two 
   set ip dscp 63 
  class  three 
   set ip precedence 0 
  class  four 
   set ip precedence 7 
  class  five 
   set ip dscp 22 
  class  six 
   set ip precedence unchanged 
  class  seven 
   set ip dscp 13 
  class  eight 
   set ip dscp 31 
  class  nine 
   set ip dscp unchanged 
  class  ten 
   set ip precedence 3 

 Policy Map two 
  class  five 
   police 32000 1000 exceed-action drop 
  class  four 
   police 33000 2000 exceed-action set-dscp-transmit 0 
  class  three 
   police 32000 3300 exceed-action set-prec-transmit 0 
  class  two 
   police 44000 1980 exceed-action drop 

 Policy Map three 
  class  one 
   set ip dscp 1 
  class  four 
   set ip dscp 4 
  class  three 
   set ip precedence 1 

Example

The following example shows a particular policy map configuration:

Router# show policy-map one

 Policy Map one 
  class  one 
   set ip dscp unchanged 
  class  two 
   set ip dscp 63 
  class  three 
   set ip precedence 0 
  class  four 
   set ip precedence 7 
  class  five 
   set ip dscp 22 
  class  six 
   set ip precedence unchanged 
  class  seven 
   set ip dscp 13 
  class  eight 
   set ip dscp 31 
  class  nine 
   set ip dscp unchanged 
  class  ten 
   set ip precedence 3 

Example

The following example shows all class maps configured:

Router# show class-map 
 Class Map match-all nine (id 10) 
   Match access-group  33 

 Class Map match-all four (id 5) 
   Match access-group  1 
   Match access-group  2 
   Match access-group  4 
   Match access-group  6 
   Match access-group  8 
   Match access-group  12 
   Match access-group  16 
   Match access-group  25 
   Match access-group  31 
   Match access-group  21 
   Match access-group  13 

 Class Map match-all five (id 6) 
   Match ip dscp 5 13 22 27 34 44 45 63 

 Class Map match-any class-default (id 0) 
   Match any 
 Class Map match-all six (id 7) 
   Match ip dscp 2 
   Match ip dscp 3 4 5 6 7 8 9 
   Match ip dscp 52 53 

 Class Map match-all one (id 2) 
   Match access-group name cache-in 

 Class Map match-all seven (id 8) 
   Match ip precedence 2 

 Class Map match-all two (id 3) 
   Match access-group  102 

 Class Map match-all three (id 4) 
   Match access-group  142 
   Match access-group  169 

 Class Map match-all eight (id 9) 
   Match access-group name std-stuff 

 Class Map match-all ten (id 11) 
   Match access-group  102 
   Match access-group  112