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