Downloads |
 Feedback
|
Table Of Contents
Configuring Quality of Service (QoS)
Classification Based on Layer 2 CoS
Classification Based on IP Precedence
Classification Based on IP DSCP
Ingress Classification Based on QoS ACLs
Classification Based on QoS Groups
Classification Based on Discard Class
Classification Based on VLAN IDs
Classification for MPLS and EoMPLS
Restrictions and Usage Guidelines
Congestion Avoidance and Queuing
Weighted Random Early Detection (WRED)
Congestion Management and Scheduling
Class-Based Weighted Fair Queuing
QoS Treatment for Performance-Monitoring Protocols
Configuration Guidelines and Limitations
Using ACLs to Classify Traffic
Configuring Class-Based Marking
Configuring Output Policy Maps
Configuring Class-Based-Weighted Fair Queuing
Configuring Class-Based Shaping
Configuring Class-Based Priority Queuing
Configuring Weighted Tail Drop
Configuring Weighted Random Early Detection
Hierarchical Policy Maps Configuration Examples
Configuring MPLS and EoMPLS QoS
Default MPLS and EoMPLS QoS Configuration
MPLS QoS Configuration Guidelines
Setting the Priority of Packets with Experimental Bits
Attaching a Service Policy to an Interface or EFP
Configuring Quality of Service (QoS)
This chapter describes how to configure quality of service (QoS) on the ME 3800X and ME 3600X switches by using the modular QoS command-line interface (MQC) commands. With QoS, you can provide preferential treatment to certain types of traffic at the expense of other types. When you do not configure QoS, the switch offers best-effort service to each packet, regardless of the packet contents or size. MQC provides a hierarchical configuration framework for prioritizing or limiting specific streams of traffic.
QoS includes traffic classification, marking, policing, queuing, and scheduling configured with service policies that are attached to ingress and egress targets. On the ME 3800X and ME 3600X switches, targets can be switchports or Ethernet Flow Points (EFPs), also referred to as service instances. The switches do not support the service policies attached to the EtherChannel port channels although you can attach them to ports that belong to an EtherChannel as long as there are no EFPs configured on the EtherChannel.
Ingress QoS includes classification, marking, and policing. Classification can be based on the class of service (CoS), Differentiated Services Code Point (DSCP), IP precedence, or the multiprotocol label switching (MPLS) experimental (EXP) value in the inbound packet. You can classify based on Layer 2 MAC, IP-standard, or IP-extended access control lists (ACLs).
Egress QoS supports the same classifications as ingress QoS except for ACLs, and also includes classification based on QoS group or discard class. Egress QoS also includes queueing based on the weighted tail drop (WTD) algorithm, scheduling based on shaped weights, and an egress priority queue.
You can also use hierarchical QoS to classify, police, mark, queue, and schedule inbound or outbound traffic. You can define a policy map for the first, second, or third level of the hierarchy. Hierarchical QoS offers classification based on the CoS, DSCP, IP precedence, or the MPLS EXP bits in the packet, and classifying a packet based on its VLAN. The switch supports two-rate, three-color policing at different levels. Drop policy actions include passing the packet through without modification is supported and ingress and egress however, marking down the CoS, DSCP, IP precedence, or the MPLS EXP bits in the packet; or dropping the packet is only supported at ingress.
For more information about Cisco IOS MQC commands, see the "Cisco IOS Quality of Service Solutions Command Reference:"
http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_book.html
For complete syntax and usage information for the platform-specific commands used in this chapter, see the command reference for this release.
Understanding QoS
When networks operate on a best-effort delivery basis, all traffic has equal priority and an equal chance of being delivered in a timely manner. When congestion occurs, all traffic has an equal chance of being dropped. When you configure QoS, you can select specific network traffic, prioritize it according to its relative importance, and use traffic-management techniques to provide preferential treatment. Implementing QoS in your network makes network performance more predictable and bandwidth utilization more effective.
Figure 33-1 shows the MQC model.
Figure 33-1 Modular QoS CLI Model
Basic QoS includes these actions.
•
Packet classification organizes traffic on the basis of whether or not the traffic matches a specific criteria. When a packet is received, the switch identifies all key packet fields: CoS, DSCP, IP precedence, or MPLS EXP. The switch classifies the packet based on this content or based on an ACL lookup. The class class-default is used in a policy map for any traffic that does not explicitly match any other class in the policy map. See the "Classification" section.
•
•
•
•
This section includes information about these topics:
•
•
•
•
Modular QoS CLI Configuration
With the modular QoS CLI, you create traffic policies and attach these policies to physical interfaces or EFP service instances. A traffic policy contains a traffic class and one or more QoS features. You define a traffic class to classify traffic, use a traffic policy to define how to treat the classified traffic, and attach the policy to a port or service instance to create a service policy.
Step 1
Use the class-map global configuration command to define a traffic flow or class and to enter class-map configuration mode. A traffic class contains:
•
•
•
Note
Step 2
Use the policy-map global configuration command to create a traffic policy and to enter policy-map configuration mode. A traffic policy specifies the traffic class to act on and defines the QoS features to associate with the specified traffic class. A traffic policy contains a name, a traffic class (specified with the class policy-map configuration command), and the QoS policies configured in the class.
•
•
•
Note
Step 3
Use the service-policy interface configuration command to attach the policy map to a target and to specify if the policy should be applied to packets that enter or leave the target. For example, entering the service-policy output policy1 interface configuration command attaches all the characteristics of the traffic policy named class1 to the interface. Entering the service-policy output policy1 service instance configuration command attaches all the characteristics of the traffic policy named class1 to the EFP service policy. All packets leaving the target are evaluated according to the criteria specified in the traffic policy class1.
Note
Warning: Detaching Policy test1 from Interface GigabitEthernet0/1
Hierarchical QoS
Hierarchical QoS configuration involves traffic classification, policing, queuing, and scheduling. You can create a hierarchy by associating a class-level policy map with a VLAN-level policy map, by associating that VLAN-level policy map with a physical-level policy map, and by attaching the physical-level policy map to a port or EFP. You can omit hierarchical levels, but the order of levels (class level, VLAN level, and then physical level) must be preserved.
You can configure three QoS levels in the hierarchy:
•
At the class level, you can use policy-map class configuration commands to:
–
–
–
–
–
•
At the VLAN level, you can:
–
–
–
–
You can also associate a previously defined child policy at the class level with a new service policy by using the service-policy policy-map class configuration command to apply the class-level policy only to traffic that matches the VLAN class. You cannot mix VLAN-level and class-level matches within a class map.
•
–
–
Classification
Classification distinguishes one kind of traffic from another by examining the fields in the packet header. When a packet is received, the switch examines the header and identifies all key packet fields. A packet can be classified based on an ACL, on the DSCP, the CoS, IP precedence, or MPLS EXP value in the packet, or by the VLAN ID. Figure 33-2 has examples of classification information carried in a Layer 2 or a Layer 3 IP packet header, using six bits from the deprecated IP type of service (ToS) field to carry the classification information.
•
•
Figure 33-2 QoS Classification Layers in Frames and Packets
•
•
•
•
•
•
•
•
•
The match Command
In class-map configuration mode, you use the match class-map configuration command to define the match criterion for the traffic. You can also create a class map that requires that all matching criteria in the class map be in the packet header by using the class map match-all class-map name global configuration command.
Note
You can use the class map match-any class-map name global configuration command to define a classification with any of the listed criteria.
In class-map configuration mode, you use the match command to specify the classification criteria. If a packet matches the configured criteria, it belongs to a specific class and is forwarded according to the specified policy. For example, you can use the match class-map command with CoS, IP DSCP, IP precedence, or MPLS EXP values.You can also match an access group, a QoS group, or a VLAN ID or inner VLAN ID or VLAN ID range for per-port, per-VLAN QoS.
For an input policy map, you cannot configure both an IP classification (match ip dscp, match ip precedence, match ip acl) and a non-IP classification (match mac acl) in the same policy map or class map.
This example shows how to create a class map example to define a class that matches any of the listed criteria. In this example, if a packet is received with the DSCP equal to 32 or a 40, the packet is identified (classified) by the class map.
Switch(config)# class-map match-any exampleSwitch(config-cmap)# match ip dscp 32Switch(config-cmap)# match ip dscp 40Switch(config-cmap)# exitVLAN Match Support
The VLAN Match support feature allows classification based on VLAN on the main interface, which has EVC service instances configured on that interface.
Support VLAN-based policy on an EVC physical-port with the following EFP configuration:
•
•
•
Restrictions and Guidelines
The following restrictions apply to VLAN match support:
•
•
•
•
The following example shows classification based on VLAN on the main interface, where an EVC is configured.
Switch(config)# class-map match-any vlan_classSwitch(config-cmap)# match vlan 200Switch(config-cmap)# policy-map main-interface-policySwitch(config-pmap)# class vlan_classSwitch(config-pmap-c)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy output main-interface-policySwitch(config-if)# service instance 1 EthernetSwitch(config-if-srv)# encapsulation dot1q 200Switch(config-if-srv)# rewrite ingress tag pop 1 symmetricSwitch(config-if-srv)# bridge-domain 200Switch(config-if-srv)# endClassification Based on Layer 2 CoS
You use the match cos command to classify Layer 2 traffic based on the CoS value, which ranges from 0 to 7.
This example shows how to create a class map to match a CoS value of 5:
Switch(config)# class-map premiumSwitch(config-cmap)# match cos 5Switch(config-cmap)# exitClassification Based on IP Precedence
You can classify IPv4 traffic based on the packet IP precedence values, which range from 0 to 7. This example shows how to create a class map to match an IP precedence value of 4:
Switch(config)# class-map sampleSwitch(config-cmap)# match ip precedence 4Switch(config-cmap)# exitClassification Based on IP DSCP
When you classify IPv4 traffic based on the IP DSCP value and enter the match ip dscp class-map configuration command, you have several classification options:
•
•
•
•
•
This display shows the available classification options:
Switch(config-cmap)# match ip dscp ?<0-63> Differentiated services codepoint valueaf11 Match packets with AF11 dscp (001010)af12 Match packets with AF12 dscp (001100)af13 Match packets with AF13 dscp (001110)af21 Match packets with AF21 dscp (010010)af22 Match packets with AF22 dscp (010100)af23 Match packets with AF23 dscp (010110)af31 Match packets with AF31 dscp (011010)af32 Match packets with AF32 dscp (011100)af33 Match packets with AF33 dscp (011110)af41 Match packets with AF41 dscp (100010)af42 Match packets with AF42 dscp (100100)af43 Match packets with AF43 dscp (100110)cs1 Match packets with CS1(precedence 1) dscp (001000)cs2 Match packets with CS2(precedence 2) dscp (010000)cs3 Match packets with CS3(precedence 3) dscp (011000)cs4 Match packets with CS4(precedence 4) dscp (100000)cs5 Match packets with CS5(precedence 5) dscp (101000)cs6 Match packets with CS6(precedence 6) dscp (110000)cs7 Match packets with CS7(precedence 7) dscp (111000)default Match packets with default dscp (000000)ef Match packets with EF dscp (101110)For more information on DSCP prioritization, see RFC-2597 (AF per-hop behavior), RFC-2598 (EF), or RFC-2475 (DSCP).
CoS Mapping
The switch uses EVC and EFPs to support VLAN mapping from the customer VLAN-ID (C-VLAN) to a service-provider VLAN-ID (S-VLAN). See the "Configuring IEEE 802.1Q Tunneling and Layer 2 Protocol Tunneling Using EFPs" section.
For QoS, you can set the service-provider CoS (S-CoS) from either the customer CoS (C-CoS) or the customer DSCP (C-DSCP) value. You can map the inner CoS to the outer CoS for any traffic with traditional 802.1Q tunneling (QinQ). This allows copying the customer CoS into the service provider network.
By default, the switch supports C-CoS to S-CoS propagation for QinQ. When you configure QinQ, you can also set the S-CoS from C-DSCP.
Configuring CoS matching on EFPs configured for tunneling:
•
•
Note
•
Note
•
•
The same CoS mapping rules also apply to EFP rewrite operations (see the "Rewrite Operations" section) when you use the rewrite ingress tag pop symmetric service instance command for VLAN translation.
You can also configure outgoing CoS on an 802.1Q trunk port to simulate CoS mapping.
Ingress Classification Based on QoS ACLs
You can use IP standard, IP extended, or Layer 2 MAC ACLs to define a group of packets with the same characteristics (class). In the QoS context, the permit and deny actions in the access control entries (ACEs) have different meanings than do security ACLs. QoS policies do not match ACLs that use the deny keyword.
•
•
•
•
Note
You implement IP ACLs to classify IP traffic by using the access-list global configuration command. You implement Layer 2 MAC ACLs to classify non-IP traffic by using the mac access-list extended global configuration command. The switch supports MAC ACLs only with destination addresses.
Not all IP ACL options are supported in QoS ACLs. Only these protocols are supported for permit actions in an IP ACL: ICMP, IGMP, GRE, IPINIP, TCP, and UDP. Within a protocol, for IP source and destination, the switch supports only the source or destination IP address, host, or any. For matching criteria, the switch supports only DSCP, time-range, and ToS. See the "Using ACLs to Classify Traffic" section for more specific information. When you define a class map with the ACL, you can add the class to a policy.
You can attach a policy that includes unsupported QoS IP ACL options to the target, but QoS ignores the unsupported options. If you modify an IP ACL in a policy map that is already attached to a target and the modification causes the policy to become invalid, the policy is detached from the target.
Classification Based on QoS Groups
A QoS group is an internal label used by the switch to identify packets as a members of a specific class. The label is not part of the packet header and is restricted to the switch that sets the label and not communicated between devices. QoS groups provide a way to tag a packet for subsequent QoS action without explicitly marking (changing) the packet.
A QoS group is identified at ingress and used at egress. It is assigned in an input policy to identify packets in an output policy. See Figure 33-3.
Figure 33-3 QoS Groups
You use QoS groups to aggregate different classes of input traffic for a specific action in an output policy. For example, you can classify an ACL on ingress by using the set qos-group command and then use the match qos-group command in an output policy.
Switch(config)# class-map aclSwitch(config-cmap)# match access-group name aclSwitch(config-cmap)# exitInput policy map:
Switch(config)# policy-map set-qos-groupSwitch(config-pmap)# class aclSwitch(config-pmap-c)# set qos-group 5Switch(config-cmap-c)# exitOutput policy map:
Switch(config)# policy-map shapeSwitch(config-pmap)# class qos-group 5Switch(config-pmap-c)# shape average 10mSwitch(config-cmap-c)# exitYou can use QoS groups to aggregate multiple input streams across input classes and policy maps to have the same QoS treatment on the egress port. Assign the same QoS group number in the input policy map to all streams that require the same egress treatment, and match the QoS group number in the output policy map to specify the required queuing and scheduling actions.
You can also use QoS groups to implement MPLS tunnel mode. In this mode, the output per-hop behavior of a packet is determined by the input EXP bits, but the packet remains unmodified. You match the EXP bits on input, set a QoS group, and then match that QoS group on output to obtain the required QoS behavior.
To communicate an ACL classification to an output policy, you assign a QoS number to specify packets at ingress. This example identifies specific packets as part of QoS group 1 for later processing in an output policy:
Switch(config)# policy-map in-gold-policySwitch(config-pmap)# class in-class1Switch(config-pmap-c)# set qos-group 1Switch(config-cmap-c)# exitSwitch(config-cmap)# exitYou use the set qos-group command only in an input policy. The assigned QoS group identification is then used in an output policy with no mark or change to the packet. You use the match qos-group in the output policy. You cannot configure match qos-group for an input policy map.
This example creates an output policy to match the QoS group created in the input policy map in-gold-policy. Traffic internally tagged as qos-group 1 is identified and processed by the output policy.
Switch(config)# class-map out-class1Switch(config-cmap)# match qos-group 1Switch(config-cmap)# exitThe switch supports a maximum of 100 QoS groups.
Classification Based on Discard Class
A discard class is very similar to a QoS group in that it is a virtual packet marking that is carried in the packet within a single device. The difference is that a QoS group defines the complete QoS behavior for a packet, while a discard class only communicates the drop precedence of the packet during congestion management. For example, a packet could be classified on input into one QoS group, but within that QoS group, a policer could mark one of three discard classes, depending on whether the packet was determined to conform to, exceed, or violate the configured specifications. On output, a class would match the QoS group. but you could configure three different drop curves, one for each of the discard classes. The discard class value ranges from 0 to 7.
Classification Based on VLAN IDs
With classification based on VLAN IDs, you can apply QoS policies to frames carried on a user-specified VLAN for a given interface. You can use hierarchical policy maps for per-VLAN classification on trunk ports. Per-VLAN classification is not required on access ports because access ports carry traffic for a single VLAN.
You use the match vlan vlan-id class-map configuration command to classify based on the outer VLAN. Use the match vlan inner vlan-id class-map configuration command to classify based on the inner VLAN
QoS-Context Manager
QoS-Contest Manager allocates QoS-context for s-vlan and c-vlan matches. To display qos-context manager information use the show platform qos context struct bridge domain command.
QOS-contexts are allocated only for intersecting combinations of a configured class-map vlans and the vlans present in encapsulation
Packets can come from
•
•
For every egress vlan combination, qos-context is allocated in the ingress tcam based on the ingress rewrite type
Restrictions and limitations
QoS-context manager has the following limitations:
•
•
QoS-context depends on the following:
•
•
•
•
Note
Working Configuration
The following is an example of a working configuration for allocation of qos-context:
Policy Used:
class-map match-any ME-CUSTOMERS-CLASSmatch vlan 1500-3299class-map match-any VOIP-CLASSmatch vlan 1201 1301-1302class-map match-any MGMT-CLASSmatch vlan 1050-1099class-map match-any INTERNET-CLASSmatch vlan 1101bandwidth remaining percent 10policy-map LLU-NAME-PER-SERVICE-POLICYclass VOIP-CLASSPriorityclass MGMT-CLASSbandwidth remaining percent 15class INTERNET-CLASSbandwidth remaining percent 75class class-defaultbandwidth remaining percent 10Configuration:
Switch# sh run int gi0/1Building configuration...Current configuration : 336 bytes!interface GigabitEthernet0/1port-type nniswitchport trunk allowed vlan noneswitchport mode trunkmtu 9216service instance 100 ethernetencapsulation dot1q 1-1080service-policy output LLU-NAME-PER-SERVICE-POLICYbridge-domain 3600!EndBased on the class-maps in the applied policy, 31 vlans in the class-maps intersecting with the encap vlans "encapsulation dot1q 1-1080" (match vlan 1050-1099)
2 Qos-contexts are allocated for every vlan match in the egress side of this evc, total qos-contexts 31*2=62
Policy is accepted as 63 qos-contexts are supported per bridge-domain
Failed Configuration:
The following is an example of a failed configuration for allocation of qos-contexts:
Switch# confure terminalEnter configuration commands, one per line. End with CNTL/Z.Switch(config)# interface GigabitEthernet0/1Switch(config-if)# service instance 100 ethernetSwitch(config-if-srv)# encapsulation dot1q 1-1081QoS: Maximum Egress QosContexts consumed in Bridge-Domain: 3600QoS: Detaching output service-policy LLU-NAME-PER-SERVICE-POLICY from efp 100Switch(config-if-srv)#*Apr 21 14:40:37.443: %QOSMGR-3-EQOS_CXT_EXCEEDED: Maximum Egress QosContexts consumed in the Bridge-DomainBased on the class-maps in the applied policy, 32 vlans in the class-maps intersecting with the encap vlans "encapsulation dot1q 1-1081" (match vlan 1050-1099)
2 Qos-contexts are allocated for every vlan match in the egress side of this evc, total qos-contexts 32*2=64
Policy is rejected as only 63 qos-contexts are supported per bridge-domain
Classification for MPLS and EoMPLS
In an MPLS network, QoS can be specified in different ways. For example, the IP precedence field (the first 3 bits of the DSCP field in the header of an IP packet) can specify the QoS value to give the packet. If the network is an MPLS network, the IP precedence bits are copied into the MPLS EXP field at the edge of the network. If a service provider wants to set a QoS value for an MPLS packet to a different value, instead of overwriting the value in the IP precedence field that belongs to a customer, the service provider can set the MPLS experimental field. The IP header remains available for the customer's use, and the QoS of an IP packet is not changed as the packet travels through the MPLS network.
By choosing different values for the MPLS experimental field, you can mark packets based on their characteristics, such as rate or type, so that packets have the priority that they require during periods of congestion.
Figure 33-4 shows an MPLS network that connects two sites of an IP network that belongs to a customer.
Figure 33-4 MPLS Network Connecting Two Customer Sites
PE1 and PE2 are customer-located routers at the boundaries between the MPLS network and the IP network and are the ingress and egress provider-edge devices. CE1 and CE2 are customer edge devices. P1 and P2 are service provider routers within the core of the service-provider network.
Packets arrive as IP packets at PE1, the ingress provider-edge router, and PE1 sends the packets to the MPLS network as MPLS packets. Within the service-provider network, there is no IP precedence field for the queuing mechanism to look at because the packets are MPLS packets. The packets remain as MPLS packets until they arrive at PE2, the egress provider-edge router. PE2 removes the label from each packet and forwards the packets as IP packets.
Service providers can use MPLS QoS to classify packets according to the type, and other factors by setting (marking) each packet within the MPLS experimental field without changing the IP precedence or DSCP field. You can use the IP precedence or DSCP bits to specify the QoS for an IP packet and use the MPLS experimental bits to specify the QoS for an MPLS packet. In an MPLS network, configure the MPLS experimental field value at PE1 (the ingress router) to set the QoS value in the MPLS packet.
It is important to assign the correct priority to a packet. The packet priority affects how the packet is treated during periods of congestion. For example, service providers have service-level agreements with customers that specify how much traffic the service provider has agreed to deliver. To comply with the agreement, the customer must not send more than the agreed-upon rate. Packets are considered to be in-rate or out-of-rate. If there is congestion in the network, out-of-rate packets might be dropped more aggressively.
MPLS QoS matches only valid MPLS packets. On input, the match is performed before any label processing on the packet. On output, the match is performed on the final packet after all label operations are performed. See the "Configuring MPLS and EoMPLS QoS" section.
EoMPLS and QoS
EoMPLS supports QoS by using three experimental bits in a label to determine the priority of packets. To support QoS between label edge routers (LERs), you set the experimental bits in both the virtual connection and the tunnel labels. EoMPLS QoS classification occurs on ingress, and you can match on Layer 3 parameters (such as IP or DSCP), and Layer 2 parameters (CoS). Mapping does not occur by default and you must set MPLS experimental bits at ingress. See the "Configuring MPLS and EoMPLS QoS" section for more information about EoMPLS and QoS.
Table Maps
You can use table maps to manage a large number of traffic flows with a single command. You can specify table maps in set commands and use them as mark-down mapping for the policers. You can also use table maps to map an incoming QoS marking to a replacement marking without having to configure a large number of explicit matches and sets. Table maps are used only in input policy maps.
Table maps are not supported under class-default.
Table maps can be used to:
•
•
•
A table map includes one of these default actions:
•
•
•
This example creates a table to map specific CoS values to DSCP values. The default command maps all unmapped CoS values to a DSCP value of 63.
Switch(config)# table-map cos-dscp-tablemapSwitch(config-tablemap)# map from 5 to 46Switch(config-tablemap)# map from 6 to 56Switch(config-tablemap)# map from 7 to 57Switch(config-tablemap)# default 63Switch(config-tablemap)# exitThe switch supports a maximum of 256 unique table maps. You can enter up to 64 different map from-to entries in a table map. These table maps are supported on the switch:
•
•
•
•
•
•
•
•
•
Table maps modify only one parameter (CoS, IP precedence, or DSCP, whichever is configured) and are only effective when configured with a with a conform-action or exceed-action command in a police function. Individual policers also support the violate-action command.
Table maps are not supported in output policy maps. For more information, see the "Configuring Table Maps" section.
Policing
After a packet is classified and assigned a QoS label, you can use policing, as shown in Figure 33-5, to regulate the class of traffic. The policing function limits the amount of bandwidth available to a specific traffic flow or prevents a traffic type from using excessive bandwidth and system resources. A policer identifies a packet as in or out of profile by comparing the rate of the inbound traffic to the configuration profile of the policer and traffic class. Packets that exceed the permitted average rate or burst rate are out of profile or nonconforming. These packets are dropped or modified (marked for further processing), depending on the policer configuration.
Policing is used primarily on receiving interfaces. You can attach a policy map with a policer only in an input service policy. The only policing allowed in an output policy map is in priority queues.
All traffic, whether it is bridged or routed, is subjected to a configured policer. As a result, packets might be dropped or might have the DSCP or CoS fields modified when they are policed and marked.
Note
Figure 33-5 Policing of Classified Packets
You can attach a policy map with a policer only in a service policy. The switch supports 1-rate, 2-color and 2-rate, 3-color ingress policing. Only 1-rate, 2-color policing is supported in egress policies.
For 1-rate, 2-color policing, use the police policy map class configuration command to define the policer, the committed rate limitations of the traffic, committed burst size limitations of the traffic, and the action to take for a class of traffic that is below the limits (conform-action) and above the limits (exceed-action). If you do not specify burst size (bc), the system calculates an appropriate burst size value. The calculated value is appropriate for most applications.
When you configure a 2-rate policer, you configure the committed information rate (CIR) for updating the first token bucket, and also the peak information rate (PIR) at which the second token bucket is updated. If you do not configure a PIR, the policer is a standard 1-rate, 2-color policer.
For 2-rate, 3-color policing, you can then choose to set actions to perform on packets that conform to the specified CIR and PIR (conform-action), packets that conform to the PIR, but not the CIR (exceed-action), and packets that exceed the PIR value (violate-action).
•
•
•
Setting the burst sizes too low can reduce throughput in situations with bursty traffic. Setting burst sizes too high can allow too high a traffic rate.
Note
Use the service-policy input interface configuration command to attach the policy map to a physical port or EFP service instance to make it effective. For more information, see the "Attaching a Service Policy to an Interface or EFP" section. Policing is done only on received traffic, so you can only attach a policer to an input service policy.
See the "Configuring a Policy Map with 1-Rate, 2-Color Policing" section for configuration examples.
You can use the conform-action, exceed-action, and violate-action policy-map class configuration commands or the conform-action, exceed-action, and violate-action policy-map class police configuration commands to specify an action when the packet conforms to or exceeds the specified traffic rates. Conform, exceed, and violate actions are to drop the packet, to send the packet without modifications, to set a new CoS, DSCP, or IP precedence value, or to set a QoS group value for classification at the egress.
You can simultaneously configure multiple conform, exceed, and violate actions for each service class.
Priority Policing
Priority policing applies only to output policy maps. You can use the priority policy map class configuration command in an output policy map to designate a low-latency path or class-based priority queuing for a specific traffic class. With strict priority queuing, the packets in the priority queue are scheduled and sent until the queue is empty. Excessive use of high-priority queuing can create congestion for low priority traffic.
Restriction and Usage Guidelines
•
•
•
•
•
•
•
•
•
•
To eliminate this congestion, you can use the Priority with Police feature (priority policing) to reduce the bandwidth used by the priority queue, and allocate traffic rates on other queues. Priority with police is the only form of policing supported in output policy maps.
This example shows how to use the priority command with police command to configure out-class1 as the priority queue, with traffic going to the queue that is limited to 20,000,000 bps. so that the priority queue never uses more than that. Traffic above that rate is dropped. This allows other traffic queues to receive some port bandwidth, in this case a minimum bandwidth guarantee of 500,000 and 200,000 kbps. The class-default, queue gets the remaining port bandwidth.
Switch(config)# policy-map policy1Switch(config-pmap)# class out-class1Switch(config-pmap-c)# prioritySwitch(config-pmap-c)# police 200000000Switch(config-pmap-c)# exitSwitch(config-pmap)# class out-class2Switch(config-pmap-c)# bandwidth 500000Switch(config-pmap-c)# exitSwitch(config-pmap)# class out-class3Switch(config-pmap-c)# bandwidth 200000Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy output policy1Switch(config-if)# exitPacket Marking
You can use packet marking in input policy maps to set or modify the attributes for traffic belonging to a specific class. For example, you can change the CoS value in a class or set IP DSCP or IP precedence values for a specific type of traffic. These new values are then used to determine how the traffic should be treated. You can also use marking to assign traffic to a QoS group within the switch.
Traffic marking is typically performed on a specific traffic type at the ingress port. The marking action can cause the CoS, DSCP, or precedence bits to be rewritten or left unchanged, depending on the configuration. This can increase or decrease the priority of a packet in accordance with the policy used in the QoS domain so that other QoS functions can use the marking information to judge the relative and absolute importance of the packet. The marking function can use information from the policing function or directly from the classification function.
Restrictions and Usage Guidelines
•
•
•
•
•
•
•
•
Specify and mark traffic by using the set commands in a policy map for all supported QoS markings. CoS, IP DSCP, and IP precedence markings are supported in both ingress and egress policies. The task of setting QoS groups is supported only in ingress policies.
Note
A set command unconditionally marks the packets that match a specific class. You can then attach the policy map to an interface or service instance as an input policy map or output policy map.
You can simultaneously configure the actions to modify the DSCP, precedence, and CoS markings in the packet for the same service along with the QoS group marking actions. You can use the QoS group number defined in the marking action for egress classification. Figure 33-6 shows the steps involved in marking traffic.
Figure 33-6 Marking Classified Traffic
This example uses a policy map to remark a packet. The first marking (the set command) applies to the QoS default class map that matches all traffic not matched by class AF31-AF33 and sets all traffic to an IP DSCP value of 1. The second marking sets the traffic in classes AF31 to AF33 to an IP DSCP of 3.
Switch(config)# policy-map ExampleSwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# set ip dscp 1Switch(config-pmap-c)# exitSwitch(config-pmap)# class AF31-AF33Switch(config-pmap-c)# set ip dscp 3Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy input ExampleSwitch(config-if)# exitIf the egress class match criteria is a part of ingress marking set actions, the egress packet will have both ingress and egress marking action applied on it. If ingress and egress set actions act on the same PHB, the egress set action will take precedence over ingress set action.
In this example, the egress packet is set to both DSCP 20 and CoS 3:
Switch(config)# policy-map Ingress ExampleSwitch(config-pmap)# class dscp 10Switch(config-pmap-c)# set dscp 20Switch(config-pmap-c)# exitSwitch(config)# policy-map Egress ExampleSwitch(config-pmap)# class dscp 10Switch(config-pmap-c)# set cos 5Switch(config-pmap-c)# exitCongestion Avoidance and Queuing
The Congestion Avoidance feature uses algorithms such as tail drop to control the number of packets entering the queuing and scheduling stage to avoid congestion and network bottlenecks. The switch uses WTD and Weighted Random Early Detection (WRED) to manage the queue sizes and provide a drop precedence for traffic classifications.
These sections contain additional information on congestion avoidance and queuing:
•
Weighted Tail Drop
You set the queue size limits depending on the markings of the packets in the queue. You can assign each packet that travels through the switch to a specific queue and threshold. For example, you can map specific DSCP or CoS values to a specific egress queue and threshold. If the total destination queue size is greater than the threshold of any classified traffic, the next frame of that traffic is dropped.
Figure 33-7 shows an example of WTD operating on a queue with 1000 microseconds worth of data. Three drop percentages are configured: 40 percent (400 microseconds), 60 percent (600 microseconds), and 100 percent (1000 microseconds). These percentages mean that traffic classified to the 40-percent threshold is dropped when the queue depth exceeds 400 microseconds, traffic classified to 60 percent is dropped when the queue depth exceeds 600 microseconds. Traffic up to 400 microseconds can be queued at the 40-percent threshold, up to 600 microseconds at the 60-percent threshold, and up to 1000 microseconds at the 100-percent threshold.
Figure 33-7 WTD and Queue Operation
In this example, CoS values 6 and 7 have a greater importance than the other CoS values, and they are assigned to the 100-percent drop threshold (queue-full state). CoS values 4 and 5 are assigned to the 60-percent threshold, and CoS values 0 to 3 are assigned to the 40-percent threshold.
If the queue is already filled with 600 microseconds worth of data, and a new frame arrives containing CoS values 4 or 5, the frame is subjected to the 60-percent threshold. When this frame is added to the queue, the threshold would be exceeded, so the switch drops it.
You configure WTD by using the queue-limit policy-map class command to adjust the queue size (buffer size) associated with a particular class of traffic.
Note
You specify the maximum threshold in bytes, microseconds, percent or packets. You can specify different queue sizes for different classes of traffic (CoS, DSCP, MPLS EXP, precedence, discard-class, or QoS group) in the same queue. Setting a queue limit establishes a drop threshold for the associated traffic when congestion occurs.
Note
The switch supports up to three unique queue-limit configurations (including the default) across all output policy maps. Within an output policy map, four or eight queues (classes) are allowed, including the class default. Each queue can have three defined thresholds. Only three unique threshold value configurations are allowed per class. Multiple policy maps can share the same queue-limits. Each class-map in a policy-map can either share the same threshold or can have its own unique values.
You can use these same queue-limit values in multiple output policy maps on the switch. However, changing one of the queue-limit values in a class creates a new, unique queue-limit configuration. At any one time, you can attach only three unique queue-limit configurations in output policy maps to targets. If you attempt to attach an output policy map with a fourth unique queue-limit configuration, you see this error message:
QoS: Configuration failed. Maximum number of allowable unique queue-limit configurations exceeded.By default, queues have unique thresholds based on the speed of the interface. You can decrease the queue size for latency-sensitive traffic or increase the queue size for bursty traffic.
Queue bandwidth and queue size (queue limit) are configured separately and are not interdependent. You should consider the type of traffic being sent when you configure bandwidth and queue-limit:
•
•
•
WTD thresholds:
•
•
•
See the "Configuring Weighted Tail Drop" section.
Weighted Random Early Detection (WRED)
WRED combines the capabilities of the RED algorithm with the IP Precedence feature to enable preferential traffic handling of high-priority packets. WRED can selectively discard low-priority traffic when the switch begins to get congested, and provide differentiated egress drop thresholds based on the DSCP, IP precedence, CoS values, or MPLS EXP bits.
You can configure WRED to ignore IP precedence when making drop decisions so that non weighted RED behavior is achieved.
WRED attempts to anticipate and avoid congestion rather than control congestion after it occurs.
WRED works with ipv6 dscp/class of service.
Why Use WRED?
WRED facilitates early detection of congestion and enables multiple classes of traffic. It also protects against global synchronization. For these reasons, WRED is useful on any output interface on which you expect congestion to occur.
However, WRED is usually used in the core routers of a network rather than at the edge of a network. Edge routers assign IP precedences to packets as they enter the network. WRED uses these precedences to determine how to treat different types of traffic.
WRED provides separate thresholds and weights for different IP precedences, allowing you to provide different qualities of service with regard to packet dropping for different traffic types. Standard traffic can be dropped more frequently than premium traffic during periods of congestion.
How It Works
By randomly dropping packets prior to periods of high congestion, WRED communicates with the packet source to decrease its transmission rate. If the packet source is using TCP, it will decrease its transmission rate until all the packets reach their destination, which indicates that the congestion is cleared.
WRED generally drops packets selectively, based on IP precedence. Packets with a higher IP precedence are less likely to be dropped than packets with a lower precedence. Thus, the higher the priority of a packet, the higher the probability that the packet will be delivered.
WRED reduces the chances of tail drop by selectively dropping packets when the output policy maps begin to show signs of congestion. By dropping some packets early rather than waiting until the queue is full, WRED avoids dropping large numbers of packets at once and minimizes the chances of global synchronization. Thus, WRED allows the transmission line to be used fully at all times.
In addition, WRED statistically drops more packets from large users than from small users. Therefore, traffic sources that generate the most traffic are more likely to be slowed down than traffic sources that generate less traffic.
WRED avoids the globalization problems that occur when tail drop is used as the congestion avoidance mechanism. Global synchronization manifests when multiple TCP hosts reduce their transmission rates in response to packet dropping, and increase their transmission rates once again when the congestion is reduced.
WRED is useful only when the bulk of the traffic is TCP/IP traffic. With TCP, dropped packets indicate congestion. Therefore the packet source will reduce its transmission rate. With other protocols, packet sources may not respond or may resend dropped packets at the same rate. Thus, dropping packets does not decrease congestion.
WRED treats non-IP traffic as precedence 0, the lowest precedence. Therefore, non-IP traffic, in general, is more likely to be dropped than IP traffic.
Figure 33-8 illustrates how WRED works.
Figure 33-8 How WRED works.
Average Queue Size
The router automatically determines the parameters to be used in WRED calculations. The average queue size is based on the previous average and the current size of the queue. The formula is:
average = (old_average * (1-2 -n)) + (current_queue_size * 2 -n)here n is the exponential weight factor, a user-configurable value. The default value of the exponential weight factor is 9. We recommend that you use only the default value for the exponential weight factor. Change this value from the default value only if you have determined that your scenario will benefit from using a different value.
For high values of n, the previous average becomes more important. A large factor smooths out the peaks and lows in queue length. The average queue size is unlikely to change very quickly, avoiding drastic swings in size. The WRED process will be slow to start dropping packets, but it may continue dropping packets for a time after the actual queue size has fallen below the minimum threshold. The slow-moving average will accommodate temporary bursts in traffic.
Note
For low values of n, the average queue size closely tracks the current queue size. The resulting average may fluctuate with changes in the traffic levels. In this case, the WRED process responds quickly to long queues. After the queue falls below the minimum threshold, the process will stop dropping packets.
If the value of n gets too low, WRED will overreact to temporary traffic bursts and drop traffic unnecessarily.
See the "Configuring Weighted Random Early Detection" section.
Congestion Management and Scheduling
MQC provides several related mechanisms in output policy maps to control outgoing traffic flow. The scheduling stage holds packets until the appropriate time to send them to one of the four or eight traffic queues. Queuing assigns a packet to a particular queue based on the packet class and is enhanced by the WTD algorithm for congestion avoidance. You can use different scheduling mechanisms to provide a guaranteed bandwidth to a particular class of traffic while also serving other traffic in a fair way. You can limit the maximum bandwidth that can be consumed by a particular class of traffic and ensure that delay-sensitive traffic in a low-latency queue is sent before traffic in other queues.
The switch supports these scheduling mechanisms:
•
You use the shape average policy map class configuration command to specify that a class of traffic should have a maximum permitted average rate. You specify the maximum rate in bits per second.
•
You can use the bandwidth policy-map class configuration command to control the bandwidth allocated to a specific class. Minimum bandwidth can be specified as a bit rate, or as a percentage of total bandwidth, or as remaining bandwidth.
•
You use the priority policy-map class configuration command to specify the that a class of traffic has low latency requirements with respect to other classes. When you configure this command in a class, you cannot configure bandwidth in any other child class associated with the same parent.
These sections contain additional information about scheduling:
•
Traffic Shaping
Traffic shaping or class-based peak rate scheduling is used to specify the maximum transmission rate for a traffic class. Unlike traffic policing, where nonconforming packets are dropped or marked right away, packets exceeding the rate specified in the shape command are usually buffered and can be sent later when bandwidth is available. While policing propagates traffic bursts, shaping smooths bursts by sending the packets later. Traffic policing is used in input policy maps, and traffic shaping occurs as traffic leaves an interface or service instance.
Configuring a queue for traffic shaping sets the maximum bandwidth or PIR of the queue. You can set the PIR from 1 Kb/s to 10 Gb/s. You can also configure the PIR as a percentage of the PIR of a parent level.
Note
Class-Based Shaping
Class-based shaping uses the shape average policy-map class configuration command to limit the rate of data transmission in bits per second to be used for the committed information rate for a class of traffic. The switch supports separate queues for four or eight classes of traffic, including the default queue for class class-default, unclassified traffic.
See the "Configuring Class-Based Shaping" section.
Port Shaping
Port shaping is applied to all the traffic leaving a target. It uses a policy map with only class default when you specify the maximum bandwidth for a port using the shape average command. You can attach a child policy to the class default in a hierarchical policy map format to specify class-based and VLAN-based actions.
Where EFPs are configured to aggregately shape the EFPs in a port, configure a port policy using a class-default shaper configuration.
See the "Configuring Port Shaping" section.
Restriction and Usage Guidelines
•
•
–
–
•
•
•
•
•
•
•
•
•
–
–
–
–
–
–
–
–
Parent-Child Hierarchy
The switch also supports parent policy levels and child policy levels for traffic shaping. The QoS parent-child structure is used for specific purposes when a child policy is referenced in a parent policy to provide additional control of a specific traffic type.
Note
This is an example of a parent-child configuration:
Switch(config)# policy-map parentSwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# shape average 50000000Switch(config-pmap-c)# service-policy childSwitch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitthernet0/1Switch(config-if)# service-policy output parentSwitch(config-if)# exitYou can also configure the PIR in a child policy to be an absolute rate calculated as a percentage of the PIR of the parent level policy. You can configure the child PIR from 0 percent to 100 percent of the parent policy.
Switch(config)# policy-map childSwitch(config-pmap)# class class2Switch(config-pmap-c)# shape average percent 50Switch(config-pmap-c)# exitClass-Based Weighted Fair Queuing
You can configure class-based weighted fair queuing (CBWFQ) to set the relative precedence of a queue by allocating a portion of the total bandwidth that is available for the port. You use the bandwidth policy-map class configuration command to set the minimum guaranteed output bandwidth or CIR for a class of traffic as a rate (kilobits per second), a percentage of total bandwidth, or a percentage of remaining bandwidth.
Note
•
The sum of all CIR commitments for a set of peer classes cannot exceed the PIR (shape) of the parent level. A queue without a configured CIR commitment does not receive any committed bandwidth in the scheduler and can be entirely superseded other classes. If CIR bandwidth is required for any class, including class-default, you must configure it.
Note
•
Note
For more information, see the "Configuring Class-Based-Weighted Fair Queuing" section.
Priority Queuing
You can use the priority policy-map class configuration command to ensure that a particular class of traffic is given preferential treatment with respect to other classes associated with the same parent entity. With priority queuing, the priority queue is constantly serviced until the queue is empty. With priority queuing, traffic for the associated class is sent before packets in other queues are sent.
When you configure priority in a class, you cannot configure the bandwidth command in any other sibling class associated with the same parent.
Note
Priority queuing has these restrictions:
•
•
•
For more information, see the "Configuring Class-Based Priority Queuing" section.
Input and Output Policy Maps
Policy maps are either input policy maps or output policy maps applied to packets as they enter or leave the switch by service policies attached to targets. Input policy maps perform policing and marking on received traffic. Policed packets are dropped or reduced in priority (marked down) if they exceed the maximum permitted rates. Output policy maps perform scheduling and queuing on traffic as it leaves the switch.
Input policies and output policies have the same basic structure but differ in the characteristics that they regulate. Figure 33-9 shows the relationship of input and output policies.
Figure 33-9 Input and Output Policy Relationship
Input Policy Maps
Input policy map classification criteria include matching CoS, DSCP, IP precedence, or MPLS EXP values or matching an ACL or VLAN ID (for per-port, per-VLAN QoS). Input policy maps support two actions: marking and policing. You can specify these actions in any one level of the hierarchical policy map, but actions cannot be nested. That is, if a child policy has a policer, then the parent policy map cannot have a policer. Likewise, if there is marking in a child policy, there cannot be marking in a parent policy.
Only input policies provide matching on access groups, and only output policies provide matching on QoS groups and discard classes. The class class-default is used in a policy map for any traffic that does not explicitly match any other class in the policy map. Input policy maps do not support queuing and scheduling keywords, such as bandwidth, queue-limit, priority, and shape average.
Output Policy Maps
Output policy map classification criteria include matching CoS, DSCP, an IP precedence, MPLS EXP, or QoS groups. or a discard-class value. Output policy maps can have any of these actions:
•
•
Policies attached to an EFP support only 2-level scheduling. Although you can attach a 3-level hierarchical policy to an EFP, the policy should conform to these rules:
•
•
Output policy maps do not support matching of access groups. You can use QoS groups as an alternative by matching the appropriate access group in the input policy map and setting a QoS group. In the output policy map, you can then match the QoS group. See the "Classification Based on QoS Groups" section for more information.
•
•
•
You can attach an output policy map to any or all targets on the switch. The switch supports configuration and attachment of a unique output policy map for each port or service instance.
However, these output policy maps can contain only three unique configurations of queue limits. These three unique queue-limit configurations can be included in as many output policy maps as there are switch ports. There are no limitations on the configurations of bandwidth, priority, or shaping.
QoS Treatment for Performance-Monitoring Protocols
QoS is not configurable for Cisco IP service level agreements (IP SLA) probes or for traffic to the CPU. QoS treatment is set by default.
Cisco IP-SLAs Probes
For information about Cisco IP service level agreements (IP SLAs), see the "Understanding Cisco IOS IP SLAs" section.
The QoS treatment for IP-SLA probes exactly reflects effects that occur to the normal data traffic crossing the device. The generating device does not change the probe markings. It queues these probes based on the configured queueing policies for normal traffic.
•
By default, the CoS marking of CFM traffic (including IP SLAs using CFM probes) is not changed. QoS configuration cannot change this behavior.
By default, IP traffic marking and the CoS marking of all other Layer 2 non-IP traffic is not changed. The QoS marking feature can change this behavior.
•
IP SLAs traffic is queued according to its ToS or DSCP value and the output policy map configured on the egress target, similarly to normal traffic. QoS cannot change this behavior.
By default, all other Layer 2 non-IP traffic and all IP traffic is statically mapped to a queue on the egress target.
CPU Traffic
By default, the switch assigns a separate classifier, CPU-traffic classifier, for all traffic destined to the CPU. For traffic from the CPU, the switch uses a default classifier for high-priority control protocol traffic. These protocols are considered high priority:
•
•
All other traffic from the CPU is classified with a normal classifier.
Configuring QoS
•
•
•
•
•
Default QoS Configuration
There are no policy maps, class maps, table maps, or policers configured. At the egress target, all traffic goes through a single default queue that is given the full operational bandwidth.
The packets are not modified. The CoS, DSCP, IP precedence, and MPLS EXP values in the packet are not changed. Traffic is switched in pass-through mode without any rewrites and classified as best effort without any policing.
Configuration Guidelines and Limitations
The ME 3800X and ME 3600X switches support the same QoS functionality. All switches support a total of 4,000 QoS instances, where a QoS instance is any target on which a QoS per-hop behavior policy is attached. A target can be a port, a VLAN class, or an EFP service instance.
•
•
•
•
•
•
•
•
•
–
–
–
–
For example: if the per-hop behavior established for a class of traffic by an input policy-map is DSCP ef, you can classify that class of traffic on the egress based only on DSCP ef and not on any other mutually exclusive per-hop behavior such as outer CoS or inner CoS.
•
•
•
•
•
•
Configuring Input Policy Maps
•
•
Configuring Input Class Maps
You use the class-map command to name and to isolate a specific traffic flow (or class) from all other traffic. A class map defines the criteria to use to match against a specific traffic flow to further classify it. You define match criteria with one or more match statements entered in the class-map configuration mode. Match statements can include criteria such as an ACL, inner or outer CoS value, DSCP value, IP precedence values, MPLS experimental labels, or inner or outer VLAN IDs.
In an input policy, the match criteria acts on the packet on the wire before any VLAN-mapping rewrite operations on ingress.
Beginning in privileged EXEC mode, follow these steps to create a class map and to define the match criterion to classify traffic:
Use the no form of the appropriate command to delete an existing class map or remove a match criterion.
This example shows how to create access list 103 and configure the class map called class1. The class1 has one match criterion, which is access list 103. It permits traffic from any host to any destination that matches a DSCP value of 10.
Switch(config)# access-list 103 permit any any dscp 10Switch(config)# class-map class1Switch(config-cmap)# match access-group 103Switch(config-cmap)# exitThis example shows how to create a class map called class2, which matches incoming traffic with DSCP values of 10, 11, and 12.
Switch(config)# class-map match-any class2Switch(config-cmap)# match ip dscp 10 11 12Switch(config-cmap)# exitThis example shows how to create a class map called class3, which matches incoming traffic with IP-precedence values of 5, 6, and 7:
Switch(config)# class-map match-any class3Switch(config-cmap)# match ip precedence 5 6 7Switch(config-cmap)# exitThis example shows how to create a class-map called parent-class, which matches incoming traffic with VLAN IDs in the range from 30 to 40.
Switch(config)# class-map match-any parent-classSwitch(config-cmap)# match vlan 30-40Switch(config-cmap)# exitUsing ACLs to Classify Traffic
You can classify IP traffic by using IP standard or IP extended ACLs. You can classify IP and non-IP traffic by using Layer 2 MAC ACLs. For more information about configuring ACLs, see the chapter on Configuring Network Security with ACLs in the software configuration guide.
Limitations and Usage Guidelines
The following limitations and usage guidelines apply when classifying traffic using an ACL:
•
•
•
–
–
–
–
•
•
•
–
–
–
–
•
•
•
•
•
•
•
•
•
–
–
–
QoS policies match only the permit keyword. Not all ACL criteria are supported for QoS classification. Note the available keywords in the procedures.
To enable layer 4 port matching on the switch use the platform qos enable layer4-port-match command.
You can attach a policy that includes unsupported QoS IP ACL options to the target, but QoS ignores the unsupported options. If you modify an IP ACL in a policy map that is already attached to a target and the modification causes the attached policy to become invalid, the policy is detached from the target.
•
•
•
Creating IP Standard ACLs
Beginning in privileged EXEC mode, follow these steps to create an IP standard ACL for IP traffic:
To delete an access list, use the no access-list access-list-number global configuration command.
This example shows how to allow access for only those hosts on the three specified networks. The wildcard bits apply to the host portions of the network addresses.
Switch(config)# access-list 1 permit 192.5.255.0 0.0.0.255Switch(config)# access-list 1 permit 128.88.0.0 0.0.255.255Switch(config)# access-list 1 permit 36.0.0.0 0.0.0.255Creating IP Extended ACLs
Although you can configure many options in ACLs, only some are supported for QoS ACLs.
•
•
•
Beginning in privileged EXEC mode, follow these steps to create an IP extended ACL for IP traffic:
To delete an access list, use the no access-list access-list-number global configuration command.
This example shows how to create an ACL that permits IP traffic from any source to any destination that has the DSCP value set to 32:
Switch(config)# access-list 100 permit ip any any dscp 32This example shows how to create an ACL that permits IP traffic from a source host at 10.1.1.1 to a destination host at 10.1.1.2 with a ToS value of 5:
Switch(config)# access-list 100 permit ip host 10.1.1.1 host 10.1.1.2 tos 5Creating Layer 2 MAC ACLs
Beginning in privileged EXEC mode, follow these steps to create a Layer 2 MAC ACL for non-IP traffic:
To delete an access list, use the no mac access-list extended access-list-name global configuration command.
This example shows how to create a Layer 2 MAC ACL with a permit statement that allows traffic from the host with MAC address 0001.0000.0001 to the host with MAC address 0002.0000.0001.
Switch(config)# mac access-list extended maclist1Switch(config-ext-macl)# permit 0001.0000.0001 0.0.0 0002.0000.0001 0.0.0Switch(config-ext-macl)# exitConfiguring Class-Based Marking
You use the set policy-map class configuration command to set or modify the attributes for traffic belonging to a specific class.
Follow these guidelines when configuring class-based marking:
•
•
In the privileged EXEC mode, perform these steps to create an input policy map that marks traffic,
After you create the input policy map, attach it to a target. See the "Attaching a Service Policy to an Interface or EFP" section. Use the no form of the appropriate command to delete a policy map or remove an assigned CoS, DSCP, MPLS, precedence, or QoS-group value.
This example uses a policy map to remark a packet. The first marking (the set command) applies to the QoS default class map that matches all traffic not matched by class AF31-AF33 and sets all traffic to an IP DSCP value of 1. The second marking sets the traffic in classes AF31 to AF33 to an IP DSCP of 3.
Switch(config)# policy-map ExampleSwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# set ip dscp 1Switch(config-pmap-c)# exitSwitch(config-pmap)# class AF31-AF33Switch(config-pmap-c)# set ip dscp 3Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet 0/1Switch(config-if)# service-policy input ExampleSwitch(config-if)# exitConfiguring Policing
Policing is used to enforce a traffic-metering profile. A policer meters a particular traffic flow and determines if a packet in the given flow conforms to the specified rate. You use the police policy-map class configuration command to configure individual policers to define the committed rate limitations, committed burst size limitations of the traffic, and the action to take for a class of traffic.
The switch supports 1-rate policing with a 2-color marker, or 2-rate policing with a 3-color marker. Mapped packets can be sent without modification, dropped, or marked to the options specified by the set command. Note that traffic rates are configured in bits per second and burst size is entered in bytes.
Follow these guidelines when configuring policing.
•
•
Configuring a Policy Map with 1-Rate, 2-Color Policing
Beginning in privileged EXEC mode, follow these steps to create a 1-rate, 2 color input policy map with individual policing:
After you create the policy map, attach it to an interface or an EFP. See the "Attaching a Service Policy to an Interface or EFP" section.
This example shows how to create a traffic classification with a CoS value of 4, create a policy map, and attach it to an ingress port. The average traffic rate is limited to 10000000 b/s with a burst size of 10000 bytes:
Switch(config)# class-map video-classSwitch(config-cmap)# match cos 4Switch(config-cmap)# exitSwitch(config)# policy-map video-policySwitch(config-pmap)# class video-classSwitch(config-pmap-c)# police 10000000 10000Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy input video-policySwitch(config-if)# exitThis example shows how to create policy map with a conform action of set dscp and a default exceed action, and attach it to an EFP.
Switch(config)# class-map in-class-1Switch(config-cmap)# match dscp 14Switch(config-cmap)# exitSwitch(config)# policy-map in-policySwitch(config-pmap)# class in-class-1Switch(config-pmap-c)# police 230000 8000 conform-action set-dscp-transmit 33 exceed-action dropSwitch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch (config-if)# service instance 1 EthernetSwitch (config-if-srv)# service-policy input in-policySwitch (config-if-srv)# exitThis example shows how to use policy-map class police configuration mode to set multiple conform actions and an exceed action. The policy map sets a committed information rate of 23000 bits per second (b/s) and a conform burst size of 10000 bytes. The policy map includes multiple conform actions (for DSCP and for Layer 2 CoS) and an exceed action.
Switch(config)# class-map cos-set-1Switch(config-cmap)# match cos 3Switch(config-cmap)# exitSwitch(config)# policy-map map1Switch(config-pmap)# class cos-set-1Switch(config-pmap-c)# police cir 23000 bc 10000Switch(config-pmap-c-police)# conform-action set-dscp-transmit 48Switch(config-pmap-c-police)# conform-action set-cos-transmit 5Switch(config-pmap-c-police)# exceed-action dropSwitch(config-pmap-c-police)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy input map1Switch(config-if)# exitConfiguring a Policy Map with 2-Rate, 3-Color Policing
A 2-rate, 3-color policer uses both the committed information rate (CIR) and the peak information rate (PIR) and includes three profiles (colors) for packets that conform, exceed, or violate the specified rates. You can configure actions to take on each of these profiles.
Beginning in privileged EXEC mode, follow these steps to create an input policy map with individual 2-rate, 3-color policing:
After you create the policy map, attach it to an interface or an EFP. See the "Attaching a Service Policy to an Interface or EFP" section.
Use the no form of the appropriate command to delete an existing policy map, class map, or policer.
This example shows how to configure 2-rate, 3-color policing using policy-map configuration mode.
Switch(config)# class-map cos-4Switch(config-cmap)# match cos 4Switch(config-cmap)# exitSwitch(config)# policy-map in-policySwitch(config-pmap)# class cos-4Switch(config-pmap-c)# police cir 5000000 pir 8000000 conform-action transmit exceed-action set-dscp-transmit 24 violate-action dropSwitch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy input in-policySwitch(config-if)# exitThis example shows how to create the same configuration using policy-map class police configuration mode.
Switch(config)# class-map cos-4Switch(config-cmap)# match cos 4Switch(config-cmap)# exitSwitch(config)# policy-map in-policySwitch(config-pmap)# class cos-4Switch(config-pmap-c)# police cir 5000000 pir 8000000Switch(config-pmap-c-police)# conform-action transmitSwitch(config-pmap-c-police)# exceed-action set-dscp-transmit 24Switch(config-pmap-c-police)# violate-action dropSwitch(config-pmap-c-police)# endConfiguring Output Policy Maps
•
•
•
•
•
Configuring Output Class Maps
You use the class-map global configuration command to name and to isolate a specific traffic flow (or class) from all other traffic. A class map defines the criteria to use to match against a specific traffic flow to further classify it. Match statements can include criteria such as an inner or outer CoS value, DSCP value, IP precedence values, QoS group values, discard class, MPLS experimental labels, or inner or outer VLAN IDs. You define match criterion with one or more match statements entered in the class-map configuration mode.
In an output policy, the match criteria acts on the packet on the wire after any VLAN rewrite mapping operations on egress.
Beginning in privileged EXEC mode, follow these steps to create a class map and to define the match criterion to classify traffic:
Use the no form of the appropriate command to delete an existing class map or remove a match criterion.
This example shows how to create a class map called class2, which matches traffic with DSCP values of 10, 11, and 12.
Switch(config)# class-map match-any class2Switch(config-cmap)# match ip dscp 10 11 12Switch(config-cmap)# exitThis example shows how to create a class map called class3, which matches traffic with IP-precedence values of 5, 6, and 7:
Switch(config)# class-map match-any class3Switch(config-cmap)# match ip precedence 5 6 7Switch(config-cmap)# exitThis example shows how to create a class-map called parent-class, which matches traffic with VLAN IDs in the range from 30 to 40.
Switch(config)# class-map match-any parent-classSwitch(config-cmap)# match vlan 30-40Switch(config-cmap)# exitConfiguring Class-Based-Weighted Fair Queuing
You use the bandwidth policy-map class configuration command to configure class-based weighted fair queuing (CBWFQ). CBWFQ sets the explicit minimum guaranteed rate (CIR) of a class by reserving the configured bandwidth for that class.
Follow these guidelines:
•
•
•
•
•
Beginning in privileged EXEC mode, follow these steps to use CBWFQ to control bandwidth allocated to a traffic class by specifying a minimum bandwidth as a bit rate or a percentage:
After you create the policy map, attach it to an interface or an EFP. See the "Attaching a Service Policy to an Interface or EFP" section. Use the no form of the appropriate command to delete an existing policy map, class map, or bandwidth configuration.
Note
Warning: Detaching Policy test1 from Interface GigabitEthernet0/1
This example shows how to allocate 25 percent of the total available bandwidth to the traffic class defined by the class map:
Switch(config)# policy-map gold_policySwitch(config-pmap)# class out_class-1Switch(config-pmap-c)# bandwidth percent 25Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy output gold_policySwitch(config-if)# exit
Note
This example shows how to set the precedence of output queues by setting bandwidth in kilobits per second. The classes outclass1, outclass2, and outclass3 and class-default get a minimum of 40000, 20000, 10000, and 10000 kb/s. Any excess bandwidth is divided among the classes in the same proportion as the CIR rate.
Switch(config)# policy-map out-policySwitch(config-pmap)# class outclass1Switch(config-pmap-c)# bandwidth 40000Switch(config-pmap-c)# exitSwitch(config-pmap)# class outclass2Switch(config-pmap-c)# bandwidth 20000Switch(config-pmap-c)# exitSwitch(config-pmap)# class outclass3Switch(config-pmap-c)# bandwidth 10000Switch(config-pmap-c)# exitSwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# bandwidth 10000Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet 0/1Switch(config-if)# service-policy output out-policySwitch(config-if)# exitThis example shows how to allocate the excess bandwidth among queues by configuring bandwidth for a traffic class as a percentage of remaining bandwidth. The class outclass1 is given priority queue treatment. The other classes are configured to get percentages of the excess bandwidth if any remains after servicing the priority queue: outclass2 is configured to get 50 percent, outclass3 to get 20 percent, and the class class-default to get the remaining 30 percent.
Switch(config)# policy-map out-policySwitch(config-pmap)# class outclass1Switch(config-pmap-c)# prioritySwitch(config-pmap-c)# exitSwitch(config-pmap)# class outclass2Switch(config-pmap-c)# bandwidth remaining percent 50Switch(config-pmap-c)# exitSwitch(config-pmap)# class outclass3Switch(config-pmap-c)# bandwidth remaining percent 20Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet 0/1Switch(config-if)# service-policy output out-policySwitch(config-if)# exitThis example shows how to match VLAN and CoS in the same policy. When you attach the service policy vlan to an interface, packets with the outer VLAN of 2 and an outer CoS of 2 are included in class map phb.
Switch(config)# class-map vlanSwitch(config-cmap)# match vlan 2Switch(config-cmap)# exitSwitch(config)# class-map phbSwitch(config-cmap)# match cos 2Switch(config-cmap)# exitSwitch(config)# policy-map phbSwitch(config-pmap)# class phbSwitch(config-pmap-c)# bandwidth 1000Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# policy-map vlanSwitch(config-pmap)# class vlanSwitch(config-pmap-c)# bandwidth 1000Switch(config-pmap-c)# service-policy phbSwitch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet 0/1Switch(config-if)# service-policy vlanSwitch(config-if)# exitConfiguring Class-Based Shaping
You use the shape average policy-map class configuration command to configure traffic shaping. Class-based shaping sets the explicit maximum peak information rate (PIR) for the class by limiting it to the configured bandwidth. You can configure class-based shaping at the class level and at the VLAN level.
Beginning in privileged EXEC mode, follow these steps to use class-based shaping to configure the maximum permitted average rate for a class of traffic:
After you create the policy map, attach it to an interface or an EFP. See the "Attaching a Service Policy to an Interface or EFP" section. Use the no form of the appropriate command to delete an existing policy map or class map or to delete a class-based shaping configuration.
This example shows how to configure traffic shaping for outgoing traffic on a Gigabit Ethernet port so that outclass1, outclass2, and outclass3 get a maximum of 50, 20, and 10 Mb/s of the available port bandwidth.
Switch(config)# policy-map out-policySwitch(config-pmap)# class classout1Switch(config-pmap-c)# shape average 50000000Switch(config-pmap-c)# exitSwitch(config-pmap)# class classout2Switch(config-pmap-c)# shape average 20000000Switch(config-pmap-c)# exitSwitch(config-pmap)# class classout3Switch(config-pmap-c)# shape average 10000000Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy output out-policySwitch(config-if)# exitConfiguring Port Shaping
Port shaping is applied to all traffic leaving an interface. It uses a policy map with only class default when the maximum bandwidth for the port is specified by using the shape average command. A child policy can be attached to the class-default in a hierarchical policy map format to specify class-based and VLAN-based actions.
Beginning in privileged EXEC mode, follow these steps to use port shaping to configure the maximum permitted average rate for a class of traffic:
After you create the policy map, attach it to an interface or an EFP. See the "Attaching a Service Policy to an Interface or EFP" section.
Use the no form of the appropriate command to delete an existing hierarchical policy map, to delete a port shaping configuration, or to remove the policy map from the hierarchical policy map.
This example shows how to configure port shaping by configuring a hierarchical policy map that shapes a port to 90 Mb/s, allocated according to the out-policy policy map configured in the previous example.
Switch(config)# policy-map out-policy-parentSwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# shape average 90000000Switch(config-pmap-c)# service-policy out-policySwitch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy output out-policy-parentSwitch(config-if)# exitConfiguring Marking
Use the set policy-map class configuration command to set or modify the attributes for traffic belonging to a specific class.
Follow these guidelines when configuring class-based marking:
•
•
In the privileged EXEC mode, perform these steps to create an output policy map that marks traffic.
After you create the input policy map, attach it to a target. See the "Attaching a Service Policy to an Interface or EFP" section. Use the no form of the appropriate command to delete a policy map or remove an assigned CoS, DSCP, MPLS, or precedence value.
This example uses a policy map to re-mark a packet. The first marking (the set command) applies to the QoS default class map that matches all the traffic not matched by class AF31-AF33 and sets all the traffic to an IP DSCP value of 1. The second marking sets the traffic in classes AF31 to AF33 to an IP DSCP of 3.
Switch(config)# policy-map ExampleSwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# set ip dscp 1Switch(config-pmap-c)# exitSwitch(config-pmap)# class AF31-AF33Switch(config-pmap-c)# set ip dscp 3Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet 0/1Switch(config-if)# service-policy input ExampleSwitch(config-if)# exitConfiguring Policing
Policing is used to enforce a traffic-metering profile. A policer meters a particular traffic flow and determines if a packet in the given flow conforms to the specified rate. Use the police policy map class configuration command to configure individual policers to define the committed rate limitations, committed burst size limitations of the traffic, and the action to take for a class of traffic.
The switch supports 1-rate policing with a 2-color marker. Mapped packets can be sent without modification, dropped, or marked to the options specified by the set command. Note that traffic rates are configured in bits per second and burst size is entered in bytes.
Follow these guidelines when configuring policing:
•
Configuring a Policy Map with 1-Rate, 2-Color Policing
In the privileged EXEC mode, perform these steps to create a 1-rate, 2 color output policy map with individual policing.
After you create the policy map, attach it to an interface or an EFP. See the "Attaching a Service Policy to an Interface or EFP" section.
This example shows how to create a traffic classification with a CoS value of 4, create a policy map, and attach it to an egress port. The average traffic rate is limited to 10000000 b/s with a burst size of 10000 bytes.
Switch(config)# class-map video-classSwitch(config-cmap)# match cos 4Switch(config-cmap)# exitSwitch(config)# policy-map video-policySwitch(config-pmap)# class video-classSwitch(config-pmap-c)# prioritySwitch(config-pmap-c)# police cir 10000000 bc 10000Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy output video-policySwitch(config-if)# exitThis example shows how to create a policy map with a conform action of set dscp and a default exceed action, and attach it to an EFP.
Switch(config)# class-map in-class-1Switch(config-cmap)# match dscp 14Switch(config-cmap)# exitSwitch(config)# policy-map out-policySwitch(config-pmap)# class out-class-1Switch(config-pmap-c)# prioritySwitch(config-pmap-c)# police cir 230000 bc 8000 conform-action set-dscp-transmit 33 exceed-action dropSwitch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch (config-if)# service instance 1 EthernetSwitch (config-if-srv)# service-policy output out-policySwitch (config-if-srv)# exitThis example shows how to configure port shaping when EFP policies are present, by configuring a hierarchical policy map that shapes a port to 50 percent, allocated according to the out-policy policy map configured in the previous example.
Switch(config)# policy-map port-policySwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# shape average percent 50Switch(config-pmap-c)# service-policy out-policySwitch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy output out-policy-parentSwitch(config-if)# exitThis example shows how to use the policy-map class police configuration mode to set multiple conform actions and an exceed action. The policy map sets a committed information rate of 23000 bits per second (b/s) and a conform burst size of 10000 bytes. The policy map includes multiple conform actions (for DSCP and Layer 2 CoS) and an exceed action.
Switch(config)# class-map cos-set-1Switch(config-cmap)# match cos 3Switch(config-cmap)# exitSwitch(config)# policy-map map1Switch(config-pmap)# class cos-set-1Switch(config-pmap-c)# prioritySwitch(config-pmap-c)# police cir 23000 bc 10000Switch(config-pmap-c-police)# conform-action set-dscp-transmit 48Switch(config-pmap-c-police)# conform-action set-cos-transmit 5Switch(config-pmap-c-police)# exceed-action dropSwitch(config-pmap-c-police)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy output map1Switch(config-if)# exitConfiguring Class-Based Priority Queuing
You can use the priority policy-map class configuration command to ensure that a particular class of traffic is given preferential treatment. Strict priority queuing provides low-latency service to the class.
•
•
•
Beginning in privileged EXEC mode, follow these steps to configure a strict priority queue:
After you have created an output policy map, you attach it to an egress port or EFP. See the "Attaching a Service Policy to an Interface or EFP" section.
Use the no form of the appropriate command to delete an existing policy map or class map or to cancel strict priority queuing for the priority class or the bandwidth setting for the other classes.
This example shows how to configure the class out-class1 as a strict priority queue so that all packets in that class are sent before any other class of traffic. Other traffic queues are configured so that out-class-2 gets 50 percent of the remaining bandwidth and out-class3 gets 20 percent of the remaining bandwidth. The class class-default receives the remaining 30 percent with no guarantees.
Switch(config)# policy-map policy1Switch(config-pmap)# class out-class1Switch(config-pmap-c)# prioritySwitch(config-pmap-c)# exitSwitch(config-pmap)# class out-class2Switch(config-pmap-c)# bandwidth remaining percent 50Switch(config-pmap-c)# exitSwitch(config-pmap)# class out-class3Switch(config-pmap-c)# bandwidth remaining percent 20Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy output policy1Switch(config-if)# exitConfiguring Weighted Tail Drop
Weighted tail drop (WTD) adjusts the queue size associated with a traffic class in terms of time and bytes. You configure WTD by using the queue-limit policy-map class configuration command. The queue-limit command is allowed only after you have configured a scheduling action (bandwidth, shape average, or priority).
Beginning in privileged EXEC mode, follow these steps to use WTD to adjust the queue size for a traffic class:
After you have created an output policy map, you attach it to an egress port. See the "Attaching a Service Policy to an Interface or EFP" section.
Use the no form of the appropriate command to delete an existing policy map or class map or to delete a WTD configuration.
Note
This example shows a policy map with a specified bandwidth and queue size. Traffic that is not DSCP 30 or 10 is assigned a queue-limit of 2000 bytes. Traffic with a DSCP value of 30 is assigned a queue-limit of 1000 bytes, and traffic with a DSCP value of 10 is assigned a queue-limit of 1500 bytes. All traffic not belonging to the class traffic is classified into class-default, which is configured with 10 percent of the total available bandwidth and a large queue size of 3000 bytes.
Switch(config)# policy-map gold-policySwitch(config-pmap)# class trafficSwitch(config-pmap-c)# bandwidth percent 50Switch(config-pmap-c)# queue-limit bytes 2000Switch(config-pmap-c)# queue-limit dscp 30 bytes 1000Switch(config-pmap-c)# queue-limit dscp 10 bytes 1500Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# bandwidth percent 10Switch(config-pmap-c)# queue-limit bytes 3000Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# service-policy output gold-policySwitch(config-if)# exitThere can be only three unique qualified queue-limit thresholds. In this example, there are four unique thresholds, so the configuration is rejected:
Switch(config-pmap-c)# queue-limit 100 usSwitch(config-pmap-c)# queue-limit cos 2 200 usSwitch(config-pmap-c)# queue-limit cos 3 300 usSwitch(config-pmap-c)# queue-limit cos 4 400 usIn the next example, although there appear to be only three unique thresholds, in reality there are four threshold configurations, including an implied default threshold. The configuration is rejected.
Switch(config-pmap-c)# queue-limit cos 2 200 usSwitch(config-pmap-c)# queue-limit cos 3 300 usSwitch(config-pmap-c)# queue-limit cos 4 400 usIn this last example, there are only three unique thresholds and the configuration is allowed.
Switch(config-pmap-c)# queue-limit 100 usSwitch(config-pmap-c)# queue-limit cos 2 100 usSwitch(config-pmap-c)# queue-limit cos 3 300 usSwitch(config-pmap-c)# queue-limit cos 4 400 usConfiguring Weighted Random Early Detection
This section describes the tasks involved in configuring Weighted Random Early Detection (WRED).
Restrictions and Usage Guidelines
•
–
–
–
–
–
•
–
–
–
–
•
•
•
•
•
•
•
•
•
•
When a packet arrives, the following events occur:
1.
2.
3.
4.
See Weighted Random Early Detection (WRED) for more details on how WRED works.
To configure WRED on a switch, perform the tasks described in the following sections. The tasks described in the first section are required; the tasks described in the remaining sections are optional.
•
•
Note
Enabling WRED
In the privileged EXEC mode, perform the following steps to enable WRED for a class in a policy map.
The following example configures a policy for a class called acl10 included in a policy map called policy10:
Switch# configure terminalSwitch(config)# policy-map policy10Switch(config-pmap)# class acl10Switch(config-pmap-c)# random-detect dscp-basedSwitch(config-pmap-c)# random-detect precedence 3 500 1000 10Switch(config-pmap-c)# exitSwitch(config-pmap)# exitChanging the WRED Parameters
To change the WRED parameters, use the following commands in the interface configuration mode, as needed.
When you enable WRED with the random-detect interface configuration command, the parameters are set to their default values. The weight factor is 9. For all precedences, the mark probability denominator is 10, and the maximum threshold is based on the output buffering capacity and the transmission speed for the interface.
The default minimum threshold depends on the precedence. The minimum threshold for IP precedence 0 corresponds to half the maximum threshold. The values for the remaining precedences fall between half the maximum threshold and the maximum threshold at evenly spaced intervals.
Hierarchical Policy Maps Configuration Examples
These are examples of using policy maps to configure hierarchical QoS.
Configure policy maps phb and vlan:
Switch(config)# policy-map phbSwitch(config-pmap)# class cos1Switch(config-pmap-c)# shape average 1000Switch(config-pmap-c)# exitSwitch(config-pmap)# class cos2Switch(config-pmap-c)# shape average 2000Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config)# policy-map vlanSwitch(config-pmap)# class vlan1Switch(config-pmap-c)# shape average 5000Switch(config-pmap-c)# service-policy phbSwitch(config-pmap-c)# exitSwitch(config-pmap)# class vlan2Switch(config-pmap-c)# shape average 6000Switch(config-pmap-c)# service-policy phbSwitch(config-pmap-c)# exitSwitch(config-pmap)# exitThis is an example of a policy on a port to address Port-Shaper when EFP policies are present:
Switch(config)# policy-map port-policySwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# shape average percent 50Switch(config-pmap-c)# exitSwitch(config-pmap)# exitSwitch(config-pmap)# policy-map efp-policySwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# shape average percent 25Switch(config-pmap-c)# service-policy child-policySwitch(config-pmap-c)# exitThis is an example of a 3-level output policy. You can attach this policy only to physical ports and not to EFP service instances.
Switch(config)# policy-map interface-policy-with-vlan-childSwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# shape average 10000Switch(config-pmap-c)# service-policy vlan-policySwitch(config-pmap-c)# exitThis is an example of a 2-level output policy. You can attach this policy to physical ports or to EFP service instances.
Switch(config)# policy-map interface-policy-with-phb-childSwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# shape average 10000Switch(config-pmap-c)# service-policy phbSwitch(config-pmap-c)# exitThis is an example of a 2-level output policy. You can attach this policy to physical ports or to EFP service instances.
Switch(config)# policy-map interface-policy-with-phb-childSwitch(config-pmap)# class class-defaultSwitch(config-pmap-c)# service-policy vlan-policySwitch(config-pmap-c)# exitConfiguring Table Maps
You can configure table maps to manage a large number of traffic flows with a single command. You use table maps to correlate specific DSCP, IP precedence and CoS values to each other, to mark down a DSCP, IP precedence, or CoS value, or to assign default values.
These table maps are supported on the switch:
•
•
•
Note these guidelines when configuring table maps:
•
•
•
•
•
Beginning in privileged EXEC mode, follow these steps to create a table map:
To delete a table map, use the no table-map table-map-name global configuration command.
This example shows how to create a DSCP-to-CoS table map. A complete table would typically include additional map statements for the higher DSCP values. The default of 4 in this table means that unmapped DSCP values will be assigned a CoS value of 4.
Switch(config)# table-map dscp-to-cosSwitch(config-tablemap)# map from 1 to 1Switch(config-tablemap)# map from 2 to 1Switch(config-tablemap)# map from 3 to 1Switch(config-tablemap)# map from 4 to 2Switch(config-tablemap)# map from 5 to 2Switch(config-tablemap)# map from 6 to 3Switch(config-tablemap)# default 4Switch(config-tablemap)# endSwitch# show table-map dscp-to-cosConfiguring MPLS and EoMPLS QoS
•
•
•
•
Default MPLS and EoMPLS QoS Configuration
QoS is disabled. Packets are not modified, and the CoS, DSCP, and IP precedence values in the packet are not changed. Traffic is switched in pass-through mode (packets are switched without any rewrites and classified as best effort without any policing).
The default behavior for VLAN and port-based EoMPLS packets is to use a value of 0 in the EXP bits of the virtual-connection and tunnel labels. The default behavior for L3VPN MPLS packets is to relay the IP Precedence bits into the EXP bits of the virtual-connection and tunnel labels. You can change the default behavior for VLAN- or port-based EoMPLS by applying a hierarchical QoS policy.
MPLS QoS Configuration Guidelines
•
–
–
•
•
•
•
•
Setting the Priority of Packets with Experimental Bits
MPLS and EoMPLS provide QoS on the ingress router by using 3 experimental bits in a label to determine the priority of packets. To support QoS between LERs, set the experimental bits in both the virtual-connection and tunnel labels.
The process includes these steps on the ingress router:
•
•
•
Beginning in privileged EXEC mode, follow these steps to set the experimental bits for EoMPLS or MPLS QoS:
To delete an existing policy map, use the no policy-map policy-map-name global configuration command. To delete an existing class, use the no class class-name policy-map configuration command.
This example shows how to use class and policy maps to configure different experimental bit settings for DSCP and IP precedence for MPLS QoS.
Switch(config)# class-map match-all gold-classSwitch(config-cmap)# match ip dscp 1Switch(config-cmap)# exitSwitch(config)# class-map match-all silver-classSwitch(config-cmap)# match ip precedence 2Switch(config-cmap)# exitSwitch(config)# policy-map in-policySwitch(config-pmap)# class gold-classSwitch(config-pmap-c)# set mpls experimental 5Switch(config-pmap-c)# exitSwitch(config-pmap)# class silver-classSwitch(config-pmap-c)# set mpls experimental 4Switch(config-pmap-c)# exitSwitch(config)# interface gigabitethernet1/1/1Switch(config-if)# service-policy input in-policySwitch(config-if)# endMPLS DiffServ Tunneling Modes
The switch supports MPLS DiffServ tunneling modes, which allows QoS to be transparent from one edge of a network to the other edge. A tunnel starts where there is label imposition and ends where there is label disposition.
The switch supports three tunnelling modes:
•
•
•
For additional information, see "MPLS DiffServ Tunneling Modes" section of the MPLS: Traffic Engineering: DiffServ Configuration Guide, Cisco IOS Release 15.x.
Attaching a Service Policy to an Interface or EFP
You use the service-policy interface configuration command to attach a service policy to an interface or EFP (service instance) and to specify the direction in which the policy should be applied: either an input policy map for incoming traffic or an output policy map for outgoing traffic. Input and output policy maps support different QoS features.
You can attach a service policy to a physical port or to an EFP. However, you cannot attach a service policy to a physical port that has EFPs configured. If you try to configure an EFP on a switchport that has a service policy attached, the service policy is detached. However, when EFPs are configured on a physical port, you can attach a port policy with a class-default shaper configuration.
Note
Warning: Detaching Policy test1 from Interface GigabitEthernet0/1The policy map is then detached and deleted.
Beginning in privileged EXEC mode, follow these steps to attach a policy map to a port:
To remove the policy map and port association, use the no service-policy {input | output} policy-map-name interface configuration command.
Beginning in privileged EXEC mode, follow these steps to attach a policy map to an EFP:
Step 1
configure terminal
Enter global configuration mode.
Step 2
interface interface-id
Specify the port to attach to the policy map, and enter interface configuration mode. Valid interfaces are physical ports.
Step 3
service instance number ethernet [name]
Configure an EFP (service instance) and enter service-instance configuration mode. See Chapter 12 "Configuring Ethernet Virtual Connections (EVCs)."
Note
Step 4
encapsulation {default | dot1q | priority-tagged | untagged}
Configure encapsulation type for the service instance.
Note
Step 5
bridge-domain bridge-id [split-horizon group group-id]
Configure the bridge domain ID. The range is from 1 to 8000.
Step 6
service-policy {input | output} policy-map-name
Specify the policy-map name and whether it is an input policy map or an output policy map.
Step 7
end
Return to privileged EXEC mode.
Step 8
show ethernet service instance policy-map
Verify your entries.
Step 9
copy running-config startup-config
(Optional) Save your entries in the configuration file.
To remove the policy map and port association, use the no service-policy {input | output} policy-map-name service-instance configuration command.
Displaying QoS Information
To display QoS information, use one or more of the privileged EXEC commands in Table 33-2. For explanations about available keywords, see the command reference for this release.
You can use the show policy-map interface [interface-id] privileged EXEC command to show input and output policy map statistics per classification. Statistics include the number of packets that match each specified traffic stream, the corresponding configured action, such as policing or scheduling, and the associated statistics.
This is an example of the output of the show policy-map interface command showing statistics for an output policy map.
Switch# show policy-map interface gigabitethernet 0/2GigabitEthernet0/2Service-policy output: phbClass-map: phb (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: cos 2Bandwidth 1000 (kbps)Queue-limit current-queue-depth 0 bytesOutput Queue:Tail Packets Drop: 0Tail Bytes Drop: 0Class-map: class-default (match-any)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: any
