-
null
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Note ● For complete syntax and usage information for the commands used in this chapter, see these publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
Participate in the Technical Documentation Ideas forum
The classification, marking, and policing configuration is defined by the policies attached to an interface. Classification, marking, and policing are unaffected by any QoS commands configured on ingress interfaces or by queueing policies.
Traffic classification allows the network to recognize traffic as it falls into classes that you have configured. Network traffic must be classified to apply specific QoS to it.
Classification can be inclusive (for example, all of the traffic in a Layer 2 VLAN or all of the traffic passing through an interface) or classification can be very specific (for example, you can use a class map with match commands that recognize specific aspects of the traffic).
You can classify and apply QoS (for example, marking) and then, on another interface or network device, classify again based on the marked value and apply other QoS.
The PFC and any DFCs supports a single match command in class-map match-all class maps, except that the match protocol command can be configured in a class map with the match dscp or match precedence command.
The PFC and any DFCs supports multiple match commands in class-map match-any class maps.
Note PFC QoS supports a maximum of 9 commands that match DSCP or IP precedence values in class maps and ACLs.
Class maps can use the match commands listed in Table 63-1 to configure a traffic class that is based on the match criteria.
|
|
|
---|---|---|
match access-group { access_list_number | name access_list_name } |
Note Use ACLs to match the following: |
|
Note The match protocol command can be configured in a class map with the match dscp command. |
||
Layer 2 traffic flooded in a VLAN because it is addressed to a currently unlearned MAC-Layer destination address. |
||
Note The match protocol command can be configured in a class map with the match precedence command. |
||
match protocol { arp | ip | ipv6 } Note The match protocol command can be configured in a class map with the match dscp or match precedence command. |
||
The PFC and any DFCs supports these ACL types for use with the match access group command:
|
|
|
|
---|---|---|---|
Note Policing can also mark traffic.
Marking network traffic allows you to set or modify the attributes for a specific class of traffic, which allows class-based QoS features to recognize traffic classes based on the marking. There are two traffic marking methods:
|
|
|
|
---|---|---|---|
set cos cos_value |
|||
set dscp dscp_value |
|||
set precedence precedence_value |
|||
set dscp tunnel dscp_value |
Layer 3 DSCP value in the tunnel header of a Generic Routing Encapsulation (GRE) tunneled packet |
||
set discard-class discard_value |
|||
set qos-group group_id |
|||
set mpls experimental imposition exp_value |
|||
set mpls experimental topmost exp_value |
|
|
|
|
|
---|---|---|---|---|
You can configure policers to do the following:
Policers can be applied to ingress and egress interfaces. Ingress policing is applied first, followed by egress policing.
Policing can rate limit incoming and outgoing traffic so that it adheres to the traffic forwarding rules defined by the QoS configuration. Sometimes these configured rules for how traffic should be forwarded through the system are referred to as a contract. If the traffic does not adhere to this contract, it is marked down to a lower DSCP value or dropped.
Policing does not buffer out-of-profile packets. As a result, policing does not affect transmission delay. In contrast, traffic shaping works by buffering out-of-profile traffic, which moderates traffic bursts. (PFC QoS does not support shaping.)
The PFC and DFCs support ingress and egress PFC QoS, which includes ingress and egress policing. Policers act on ingress traffic per-port or per-VLAN. For egress traffic, the policers act per-VLAN only.
Policing uses the Layer 2 frame size. You specify the bandwidth utilization limit as a committed information rate (CIR). You can also specify a higher peak information rate (PIR). Packets that exceed a rate are “out of profile” or “nonconforming.”
In each policer, you specify if out-of-profile packets are to be dropped or to have a new DSCP value applied to them (applying a new DSCP value is called “markdown”). Because out-of-profile packets do not retain their original priority, they are not counted as part of the bandwidth consumed by in-profile packets.
If you configure a PIR, the PIR out-of-profile action cannot be less severe than the CIR out-of-profile action. For example, if the CIR out-of-profile action is to mark down the traffic, then the PIR out-of-profile action cannot be to transmit the traffic.
For all policers, PFC QoS uses a configurable global table that maps the internal DSCP value to a marked-down DSCP value. When markdown occurs, PFC QoS gets the marked-down DSCP value from the table. You cannot specify marked-down DSCP values in individual policers.
Note ● By default, the markdown table is configured so that no markdown occurs: the marked-down DSCP values are equal to the original DSCP values. To enable markdown, configure the table appropriately for your network.
PFC QoS applies the bandwidth limits specified in a per-interface policer to matched traffic. For example, if you configure a per-interface policer to allow 1 Mbps for all matched TFTP traffic, it limits the TFTP traffic to 1 Mbps.
You define per-interface policers in a policy map class with the police command. If you attach per-interface policers to multiple ingress ports, each one polices the matched traffic on each ingress port separately.
PFC QoS applies the bandwidth limits specified in an aggregate policer cumulatively to all flows in matched traffic. For example, if you configure an aggregate policer to allow 1 Mbps for all TFTP traffic flows on VLAN 1 and VLAN 3, it limits the TFTP traffic for all flows combined on VLAN 1 and VLAN 3 to 1 Mbps.
You create named aggregate policers with the platform qos aggregate-policer command. If you attach a named aggregate policer to multiple ingress ports, it polices the matched traffic from all the ingress ports to which it is attached.
You can configure up to 1,023 aggregate policers; the configured aggregate policers can be applied to interfaces to configure up to 16,384 policer instances.
When distributed aggregate policing is enabled, aggregate policers synchronize policing on interfaces supported by different DFC-equipped switching modules or the PFC. Distributed aggregate policing applies to the first 4,096 aggregate policer instances of these types:
With distributed aggregate policing enabled, aggregate policers in excess of the hardware-supported capacity function as nondistributed aggregate policers.
Nondistributed aggregate policing works independently on each DFC-equipped switching module and independently on the PFC, which supports any non-DFC-equipped switching modules. Aggregate policing does not combine flow statistics from different DFC-equipped switching modules. You can display aggregate policing statistics for each DFC-equipped switching module and for the PFC and any non-DFC-equipped switching modules supported by the PFC.
Each PFC or DFC polices independently, which might affect QoS features being applied to traffic that is distributed across the PFC and any DFCs. Examples of these QoS feature are:
Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent policing rates.
PFC QoS applies the bandwidth limit specified in a microflow policer separately to each flow in matched traffic. For example, if you configure a microflow policer to limit the TFTP traffic to 1 Mbps on VLAN 1 and VLAN 3, then 1 Mbps is allowed for each flow in VLAN 1 and 1 Mbps for each flow in VLAN 3. In other words, if there are three flows in VLAN 1 and four flows in VLAN 3, the microflow policer allows each of these flows 1 Mbps.
You can configure PFC QoS to apply the bandwidth limits in a microflow policer as follows:
You can include both an aggregate policer and a microflow policer in each policy map class to police a flow based on both its own bandwidth utilization and on its bandwidth utilization combined with that of other flows.
Note If traffic is both aggregate and microflow policed, then the aggregate and microflow policers must both be in the same policy-map class and each must use the same conform-action and exceed-action keyword option: drop, set-dscp-transmit, set-prec-transmit, or transmit.
For example, you could create a microflow policer with a bandwidth limit suitable for individuals in a group, and you could create a named aggregate policer with bandwidth limits suitable for the group as a whole. You could include both policers in policy map classes that match the group’s traffic. The combination would affect individual flows separately and the group aggregately.
For policy map classes that include both an aggregate and a microflow policer, PFC QoS responds to an out-of-profile status from either policer and, as specified by the policer, applies a new DSCP value or drops the packet. If both policers return an out-of-profile status, then if either policer specifies that the packet is to be dropped, it is dropped; otherwise, PFC QoS applies a marked-down DSCP value.
To enable distributed aggregate policing, perform this task:
|
|
---|---|
Router(config)# platform qos police distributed { strict | loose } |
This example shows how to enable strict distributed aggregate policing globally:
This example shows how to disable distributed aggregate policing globally:
To create a class map, perform this task:
|
|
---|---|
Router(config)# class-map [ match-all | match-any ] class_name |
Note If you do not enter a match keyword, the default is match-all. |
To configure filtering in a class map, enter match commands as described in Table 63-1 , “Traffic Classification Class Map match Commands and Match Criteria” .
To verify class map configuration, perform this task:
|
|
|
---|---|---|
This example shows how to create a class map named ipp5 and how to configure filtering to match traffic with IP precedence 5:
This example shows how to verify the configuration:
Policy maps can contain one or more policy map classes, each with different policy map commands.
Configure a separate policy map class in the policy map for each type of traffic that an interface receives. Put all commands for each type of traffic in the same policy map class. PFC QoS does not attempt to apply commands from more than one policy map class to matched traffic.
To create a policy map, perform this task:
|
|
---|---|
To create a policy map class and configure it to filter with a class map, perform this task:
|
|
---|---|
Creates a policy map class and configures it to filter with a class map. Note PFC QoS supports class maps that contain a single match command. |
– You can use the set ip dscp and set ip precedence commands on non-IP traffic to mark the internal DSCP value, which is the basis of the egress Layer 2 CoS value.
– The set ip dscp and set ip precedence commands are saved in the configuration file as set dscp and set precedence commands.
– Mark traffic with the set commands
In a policy map class, you can either mark traffic with the set commands or do one or both of the following:
Note When configure policing, you can mark traffic with policing keywords.
PFC QoS supports policy map class marking for all traffic with set policy map class commands. To configure policy map class marking, perform this task:
Note You cannot attach a policy map that configures a trust state with the service-policy output command.
To configure the policy map class trust state, perform this task:
|
|
---|---|
Configures the policy map class trust state, which selects the value that PFC QoS uses as the source of the initial internal DSCP value. |
When configuring the policy map class trust state, note the following information:
Policy Map Class Policing Restrictions
Using a Named Aggregate Policer
To use a named aggregate policer, perform this task:
|
|
---|---|
Configures the policy map class to use a previously defined named aggregate policer. |
– Distributed aggregate policers synchronize policing on interfaces supported by different DFC-equipped switching modules or the PFC. Distributed aggregate policing applies to the first 4,096 aggregate policers of these types:
—Aggregate policers applied to VLAN, tunnel, or port channel interfaces.
—Aggregate policers in egress policies.
– Distributed aggregate policers in excess of the hardware-supported capacity function as nondistributed aggregate policers.
– Aggregate policing works independently on each DFC-equipped switching module and independently on the PFC, which supports any non-DFC-equipped switching modules. Aggregate policing does not combine flow statistics from different DFC-equipped switching modules. You can display aggregate policing statistics for each DFC-equipped switching module and for the PFC and any non-DFC-equipped switching modules supported by the PFC.
– Each PFC or DFC polices independently, which might affect QoS features being applied to traffic that is distributed across the PFC and any DFCs. Examples of these QoS feature are:
—Policers applied to a port channel interface.
—Policers applied to a switched virtual interface.
—Egress policers applied to either a Layer 3 interface or an SVI.
– Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent policing rates.
Configuring a Per-Interface Policer
To configure a per-interface policer, perform this task:
– Minimum—32 kilobits per second, entered as 32000
– Maximum—256 gigabits per second, entered as 256000000000
– Because the token bucket must be large enough to hold at least one frame, configure the token bucket size to be larger than the maximum size of the traffic being policed.
– For TCP traffic, configure the token bucket size as a multiple of the TCP window size, with a minimum value at least twice as large as the maximum size of the traffic being policed.
– The maximum_burst_bytes parameter must be set larger than the normal_burst_bytes parameter.
– To sustain a specific rate, set the token bucket size to be at least the rate value divided by 2000.
– The minimum token bucket size is 1 byte, entered as 1.
– The maximum token bucket size is 512 megabytes, entered as 512000000.
– Minimum—32 kilobits per second, entered as 32000 (the value cannot be smaller than the CIR bits_per_second parameters)
– Maximum—256 gigabits per second, entered as 256000000000
– The default conform action is transmit, which sets the policy map class trust state to trust DSCP unless the policy map class contains a trust command.
– To set PFC QoS labels in untrusted traffic, you can enter the set-dscp-transmit keyword to mark matched untrusted traffic with a new DSCP value or enter the set-prec-transmit keyword to mark matched untrusted traffic with a new IP precedence value. The set-dscp-transmit and set-prec-transmit keywords are only supported for IP traffic. PFC QoS sets egress ToS and CoS from the configured value.
– You can enter the drop keyword to drop all matched traffic.
– Ensure that aggregate and microflow policers that are applied to the same traffic each specify the same conform-action behavior.
– For marking without policing, you can enter the transmit keyword to transmit all matched out-of-profile traffic.
– The default exceed action is drop, except with a maximum_burst_bytes parameter (drop is not supported with a maximum_burst_bytes parameter).
Note When the exceed action is drop, PFC QoS ignores any configured violate action.
– You can enter the policed-dscp-transmit keyword to cause all matched out-of-profile traffic to be marked down as specified in the markdown map.
Note When you create a policer that does not use the pir keyword and the maximum_burst_bytes parameter is equal to the normal_burst_bytes parameter (which is the case if you do not enter the maximum_burst_bytes parameter), the exceed-action policed-dscp-transmit keywords cause PFC QoS to mark traffic down as defined by the policed-dscp max-burst markdown map.
– For marking without policing, you can enter the transmit keyword to transmit all matched out-of-profile traffic.
– The default violate action is equal to the exceed action.
– You can enter the policed-dscp-transmit keyword to cause all matched out-of-profile traffic to be marked down as specified in the markdown map.
This example shows how to create a policy map named max-pol-ipp5 that uses the class-map named ipp5, which is configured to trust received IP precedence values and is configured with a maximum-capacity aggregate policer and with a microflow policer:
Configuring a Per-Interface Microflow Policer
To configure a per-interface microflow policer, perform this task:
Note The flowmask requirements of microflow policing, NetFlow, and NetFlow data export (NDE) might conflict.
– Minimum—32 kilobits per second, entered as 32000
– Maximum—256 gigabits per second, entered as 256000000000
– Because the token bucket must be large enough to hold at least one frame, configure the token bucket size to be larger than the maximum size of the traffic being policed.
– For TCP traffic, configure the token bucket size as a multiple of the TCP window size, with a minimum value at least twice as large as the maximum size of the traffic being policed.
– The maximum_burst_bytes parameter must be set larger than the normal_burst_bytes parameter.
– To sustain a specific rate, set the token bucket size to be at least the rate value divided by 2000.
– The minimum token bucket size is 1 byte, entered as 1.
– The maximum token bucket size is 512 megabytes, entered as 512000000.
– The default conform action is transmit, which sets the policy map class trust state to trust DSCP unless the policy map class contains a trust command.
– To set PFC QoS labels in untrusted traffic, you can enter the set-dscp-transmit keyword to mark matched untrusted traffic with a new DSCP value or enter the set-prec-transmit keyword to mark matched untrusted traffic with a new IP precedence value. The set-dscp-transmit and set-prec-transmit keywords are only supported for IP traffic. PFC QoS sets egress ToS and CoS from the configured value.
– You can enter the drop keyword to drop all matched traffic.
– Ensure that aggregate and microflow policers that are applied to the same traffic each specify the same conform-action behavior.
– For marking without policing, you can enter the transmit keyword to transmit all matched out-of-profile traffic.
– The default exceed action is drop, except with a maximum_burst_bytes parameter (drop is not supported with a maximum_burst_bytes parameter).
Note When the exceed action is drop, PFC QoS ignores any configured violate action.
– You can enter the policed-dscp-transmit keyword to cause all matched out-of-profile traffic to be marked down as specified in the markdown map.
Note When you create a policer that does not use the pir keyword and the maximum_burst_bytes parameter is equal to the normal_burst_bytes parameter (which is the case if you do not enter the maximum_burst_bytes parameter), the exceed-action policed-dscp-transmit keywords cause PFC QoS to mark traffic down as defined by the policed-dscp max-burst markdown map.
To verify policy map configuration, perform this task:
|
|
|
---|---|---|
Exits policy map class configuration mode. Note Enter additional class commands to create additional classes in the policy map. |
||
This example shows how to verify the configuration:
To attach a policy map to an interface, perform this task:
– Aggregate policers applied to VLAN, tunnel, or port channel interfaces.
– Aggregate policers in egress policies.
With distributed aggregate policing enabled, aggregate policers in excess of the hardware-supported capacity function as nondistributed aggregate policers.
Each PFC or DFC polices independently, which might affect QoS features being applied to traffic that is distributed across the PFC and any DFCs. Examples of these QoS feature are:
– Policers applied to a port channel interface.
– Policers applied to a switched virtual interface.
– Egress policers applied to either a Layer 3 interface or an SVI.
Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent policing rates.
– Policers applied to a port channel interface.
– Policers applied to a switched virtual interface.
– Egress policers applied to either a Layer 3 interface or an SVI.
Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent policing rates.
This example shows how to attach the policy map named pmap1 to gigabit Ethernet port 5/36:
This example shows how to verify the configuration:
To define the policy maps and associate them with an identity policy, follow these steps:
To remove the identity policy, use the no identity policy policy_name command.
After the policy maps have been defined, configure the Cisco AV pair attributes in each user profile on the RADIUS server using the policy map names:
To set the Cisco AV pair attributes on the RADIUS server, perform the following task:
This example shows the configuration in the user file on the RADIUS server:
This example shows the output of the show epm session summary command when a session is active:
This example shows the output of the show epm session ip ip_addr command when a session is active on the interface with IP address 192.0.2.1:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
Participate in the Technical Documentation Ideas forum