Downloads |
Table Of Contents
Medianet Campus QoS Design 4.0
Medianet Campus QoS Design Considerations
Port-Based, VLAN-Based, and Per-Port/Per-VLAN-Based QoS
Medianet Campus Port QoS Roles
Cisco Catalyst 2960 and 2975, 3560G and 3750G, and 3560-E and 3750-E QoS Design
Platform-Specific QoS Considerations
Per-Port/Per-VLAN Policing Model
Cisco Catalyst 4500/4900 and 4500-E/4900M QoS Design
Platform-Specific QoS Considerations
Enabling QoS (Classic Supervisors)
Per-VLAN Marking Model (Classic Supervisors)
Per-VLAN Marking Model (Supervisor 6-E)
Per-Port Policing Model (Classic Supervisors)
Per-Port Policing Model (Supervisor 6-E)
Per-Port/Per-VLAN Policing Model (Classic Supervisors)
Per-Port/Per-VLAN Policing Model (Supervisor 6-E)
Per-Port User-Based Rate Limiting (Supervisor V-10GE)
Per-Port/Per-VLAN User-Based Rate Limiting (Supervisor V-10GE)
Egress Queuing 1P3Q1T+DBL (Classic Supervisors) Model
Egress Queuing 1P7Q1T+DBL (Supervisor 6-E) Model
CoPP Considerations and Restrictions
Cisco Catalyst 6500 and 6500-E QoS Design
Platform-Specific QoS Considerations
Per-Port Marking Model (Access-List Based Classification)
Per-Port Marking Model (NBAR-based Classification)
Per-Port Microflow Policing Model
Per-VLAN Microflow Policing Model
1P3Q8T (CoS-Based) Egress Queuing Model
1P7Q8T (CoS-Based) Egress Queuing Model
1P7Q4T (DSCP-Based) Egress Queuing Model
CoPP Considerations and Restrictions
Medianet Campus QoS Design 4.0
Overview
The case for Quality of Service (QoS) in WANs/VPNs is largely self-evident because of the relatively low-speed bandwidth links at these Places-in-the-Network (PINs), as compared to Gigabit/Ten Gigabit campus networks, where the need for QoS is sometimes overlooked or even challenged. This is sometimes due to network administrators equating QoS with queuing policies only; whereas, the QoS toolset extends considerably beyond just queuing tools. Classification, marking, and policing are all important QoS functions that are optimally performed within the campus network, particularly at the access layer ingress edge (access edge).
Five strategic QoS design principles discussed in Chapter 1, "Enterprise Medianet Quality of Service Design 4.0—Overview" are relevant when deploying QoS in the campus:
•
Always perform QoS in hardware rather than software when a choice exists. Cisco IOS routers perform QoS in software. This places additional demands on the CPU, depending on the complexity and functionality of the policy. Cisco Catalyst switches, on the other hand, perform QoS in dedicated hardware Application-Specific Integrated Circuits (ASICs) and as such do not tax their main CPUs to administer QoS policies. You can therefore apply complex QoS policies at Gigabit/Ten Gigabit line rates in these switches.
•
•
•
•
However, before these strategic QoS design principles can be translated into platform-specific configuration recommendations, a few additional campus-specific considerations need to be taken into account and are discussed below.
Medianet Campus QoS Design Considerations
There are several considerations unique to the campus that factor into QoS designs, including:
•
•
These are discussed in the following sections.
Internal DSCP
For the most part, Cisco Catalyst switches perform QoS operations by assigning each packet (where "packet" is being used loosely in this chapter to describe Layer 2 frames as well as Layer 3 packets) an internal DSCP value (which is sometimes referred to as a "QoS label", but is not to be confused with an MPLS label). This internal DSCP value is used to determine if a packet is to be remarked or policed or to which queue it is to be assigned or whether it should be dropped. The internal DSCP value may—or may not be—the same as the actual DSCP value of an IP (IPv4 or IPv6) packet; furthermore, an internal DSCP value is generated even for non-IP protocols (such as Layer 2 protocols like Spanning Tree as well as non-IP Layer 3 protocols like IPX).
The manner in which the internal DSCP value is generated for a packet depends on the trust state of the port on which the packet was received, which is described next.
Trust States and Operation
There are four (static) trust states with which a switch port can be configured:
•
Note
•
•
•
Note
In addition to the four static trust states described above, Cisco Catalyst switches also support a dynamic trust state, where the applied trust state for a port can dynamically toggle, depending on a successful endpoint identification exchange and the configured endpoint trust policy. This feature is referred to as conditional trust and automates user mobility for Cisco IP telephony deployments. Conditional trust operation is illustrated in Figure 2-1.
Figure 2-1 Conditional Trust Operation
The sequence shown in Figure 2-1 is:
1.
2.
3.
4.
Note
The dynamic conditional trust state for Cisco Unified IP phones can be enabled with the interface configuration command [mls] qos trust device cisco-phone.
Regardless of how the Internal DSCP is generated—either by one of the four static port trust states or by the dynamic conditional trust state—it is important to note that as the packet exits the switch (unless explicitly overridden, as discussed in the following paragraph) the Catalyst switch sets the exiting IP packet's DSCP value to the final computed internal DSCP value. If trunking is enabled on the exiting switch port, the exiting packet's CoS value is also similarly set, but only to the first three bits of the final computed internal DSCP value.
If an administrator does not want the internal DSCP to overwrite the packet's ingress DSCP value, they can utilize the DSCP transparency feature, which is enabled by the no mls qos rewrite ip dscp global configuration command. When the DSCP transparency feature is enabled, the packet always has the same DSCP value on egress as it had on ingress, regardless of any internal QoS operations performed on the packet.
Note
Trust Boundaries
Having reviewed the internal DSCP concept and trust state operations, the administrator needs to consider where to enforce the trust boundary, i.e., the network edge at which packets are trusted (or not).
In line with the strategic QoS classification principle mentioned at the outset of this chapter, the trust boundary should be set as close to the endpoints as technically and administratively feasible.
The reason for the "administratively feasible" caveat within this design recommendation is that, while many endpoints (including user PCs) technically support the ability to mark traffic on their NICs, allowing a blanket trust of such markings could easily facilitate network abuse, as users could simply mark all their traffic with Expedited Forwarding, which would allow them to hijack network priority services for their non-realtime traffic and thus ruin the service quality of real time applications throughout the enterprise.
Thus, for many years it was advocated to not trust traffic from user PCs. However, more recently, various Host Intrusion Prevention System (HIPS) software has been released, such as Cisco Security Agent, that allows for PC markings to be centrally administered and enforced. Such centrally-administered software—along with quarantine VLANs for PCs that do not have such software installed—presents the option for network administrators to trust such secure endpoint PCs.
Therefore, from a trust perspective, there are three main categories of endpoints:
•
•
•
The optimal trust boundaries and configuration commands for each of these categories of endpoints are illustrated in Figure 2-2.
Figure 2-2 Optimal Trust Boundaries
Port-Based, VLAN-Based, and Per-Port/Per-VLAN-Based QoS
QoS classification (including trust), marking, and policing policies on Cisco Catalyst switches can be applied in one of three ways:
•
Figure 2-3 Port-Based QoS
•
Figure 2-4 VLAN-Based QoS
•
Figure 2-5 Per-Port/Per-VLAN-Based QoS
These application options allow for efficiency and granularity. For example, marking policies may be more efficiently scaled when applied on a per-VLAN basis. On the other hand, policies requiring policing granularity are best performed on a per-port/per-VLAN basis. Specifically, if an administrator wanted to police VoIP traffic from IP phones to a maximum of 128 kbps from each IP phone, this would could best be achieved by deploying a per-port/per-VLAN policing policy applied to the VVLAN on a given port. A per-port policer would not be sufficient, unless additional classification criteria was provided to specifically identify traffic from the IP phone only; neither could a per-VLAN policy be used, as this would police the aggregate traffic from all ports belonging to the VVLAN to 128 kbps.
EtherChannel QoS
Another case where logical versus physical interfaces has a bearing on QoS design is when provisioning QoS over EtherChannel interfaces. Multiple Gigabit Ethernet or 10-Gigabit Ethernet ports can be logically bundled into a single EtherChannel interface (which is also known as a PortChannel interface, as this is how it appears in the configuration syntax). From a Layer 2/Layer 3 standpoint, these bundled interfaces are represented-and function-as a single interface.
From a QoS perspective, this requires policies to be split two ways:
1.
2.
Two additional important considerations must be kept in mind when deploying QoS policies on EtherChannel interfaces:
•
•
As there is a significant degree of repetition in EtherChannel configuration examples (as the physical port configurations remain identical and are simply repeated) only a single example of EtherChannel QoS design is given in this chapter, in the the Catalyst 3750-E section (Example 2-27).
Campus QoS Models
Generally speaking, there are four main steps to deploying QoS models in the campus:
1.
2.
3.
4.
These campus QoS deployment steps are illustrated in Figure 2-6 and are disscused in additional detail in the following sections..
Figure 2-6 Campus QoS Deployment Steps
Ingress QoS Models
The ingress QoS model applies either a port trust state or an explicit classification and marking policy to the switch ports (or VLANs, in the case of VLAN-based QoS), as well as optional ingress policers and ingress queuing (as required and supported).
To begin with, the administrator needs to consider what application classes are present at the campus access edge (in the ingress direction) and whether these application classes are sourced from trusted or untrusted endpoints. As previously discussed, if PC endpoint markings are secured and centrally administered, then endpoint PCs can also be considered trusted endpoints; however, in most deployment scenarios this is not the case, and as such PCs are considered as untrusted endpoints for the remainder of this chapter.
Not every application class in the Cisco-modified RFC 4594-based model, shown in Figure 1-9 in Chapter 1, "Enterprise Medianet Quality of Service Design 4.0—Overview", is present in the ingress direction at the campus access edge and as such, do not need to be provisioned for at this node. Specifically, network control traffic should never be received from endpoints, and as such, this class is not needed at the campus access edge. A similar case can be made for OAM traffic, as this traffic is primarily generated by network devices and is collected by management stations, which are typically in a data center or a network control center (and not the campus in general). Also, broadcast video and multimedia streaming traffic would originate from data center servers and would be unidirectional to campus endpoints (and should not be sourced from campus endpoints); therefore, these classes also would not need to be provisioned at the campus access edge.
That being said, of the remaining classes, consideration has to be given to which are sourced from trusted versus untrusted endpoints. Voice traffic is primarily sourced from Cisco IP telephony devices residing in the voice VLAN (VVLAN), and as such can be trusted (optimally, by conditional trust polices to facilitate user mobility, as illustrated in Figure 2-1). On the other hand, voice traffic may also be sourced from PC soft-phone applications, like Cisco Unified Personal Communicator (CUPC). However, because such applications share the same UDP port range as multimedia conferencing traffic (specifically, UDP/RTP ports 16384-32767), from a campus access edge classification standpoint, this renders soft-phone VoIP streams virtually indistinguishable from multimedia conferencing streams (unless NBAR technologies are used at the campus access edge). Unless soft-phone VoIP can be definitively distinguished from multimedia conferencing flows, it is simpler and safer to classify and mark the UDP port range of 16384-32767 as multimedia conferencing flows (AF4), as the alternative could allow multimedia conferencing flows to be admitted into strict priority queues intended (and capacity planned) for VoIP-only.
Realtime interactive flows may be sourced from Cisco TelePresence systems, which—like other Cisco IP telephony products—reside in the VVLAN and can be trusted to mark their own traffic, as shown in Figure 2-7. Cisco TelePresence systems can be configured with either static or conditional trust policies.
Figure 2-7 Cisco TelePresence Conditional Trust Operation
At the campus edge, signaling traffic may be sourced from both trusted endpoints (such as Cisco IP phones or Cisco TelePresence systems) or from untrusted endpoints (in the case of soft-phone applications running on PC endpoints, like CUPC). Therefore, both cases need to be accounted for with access edge policies.
Data applications, whether transactional, bulk, or best effort, are typically sourced from untrusted PC endpoints, as are scavenger applications.
These campus access edge endpoint marking and trust categories are summarized in Figure 2-8.
Figure 2-8 Campus Ingress Edge Marking and Trust Categories
Traffic sourced from untrusted endpoints requires explicit classification and marking policies. While the number of applications assigned to the five (non-default) untrusted campus access edge application classes shown in Figure 2-9 is virtually limitless—and is a function of the business objectives of the enterprise, as well as the technical proficiency of the network administrators—only a relatively few applications are used in this design chapter to illustrate these design concepts. Specifically, multimedia conferencing applications are sourced from the DVLAN to/from UDP ports 16384-32767. Signaling applications are limited to Skinny Call Control Protocol (SCCP) on TCP ports 2000-2002 and Session Initiation Protocol (SIP) on TCP/UDP ports 5060 and 5061. HTTPs are classified as a transactional data application (as the use of a secure transport implies a transaction). Additionally, an sample Enterprise Resource Planning (ERP) application, namely Oracle, is likewise classified as a transactional data application. FTP and email applications are classified as bulk data, as are PC-backup applications, such as Connected Backup for PC. Various peer-to-peer media sharing applications, such as iTunes, BitTorrent, and Kazaa, are classified as scavenger, as are gaming applications like Microsoft and Yahoo online gaming services. These applications classes, along with their classification criteria, are summarized in Figure 2-9.
Figure 2-9 Untrusted Application Classification Examples
Note
In addition to explicit marking policies, optional policing policies may also be implemented on the campus access ingress edges to meter and manage flows. For example, voice flows could be policed to 128 kbps, while remaining traffic from the VVLAN (which would for the most part be signaling traffic, with a negligible amount of management traffic) could be policed to 32 kbps. Both VVLAN policers could be configured to drop violating flows, as VoIP and signaling traffic is well-defined and behaved, and traffic bursts in excess of these rates would indicate a network violation or abuse.
Note
In the DVLAN, multimedia conferencing flows come in various resolutions and quality. For example, 384 kbps or 768 kbps H.323 video conferencing streams can be policed at 500 kbps and 1 Mbps, respectively. Higher quality streams, such as 720p or 1080p H.264 streams, can be policed at (approximately) 2 Mbps and 5 Mbps, respectively (depending on motion-handling algorithms and other factors).
Data plane policing policies (discussed in QoS for Security Best Practices in Chapter 1, "Enterprise Medianet Quality of Service Design 4.0—Overview") can be applied to monitor transactional data, bulk data, and best effort flows, such that these flows are metered, with violations being remarked to to either an increased Drop Precedence within a given AF class (such as AF12, AF22, AF32, or AF42 or even to AF13, AF23, AF33, or AF43 in the case of dual-rate policiers) or to CS1. What is important is that these packets are not dropped on ingress. For example, each of these classes can be policed to remark at 10 Mbps.
Note
Finally, a scavenger class can also be implemented to meter "less than best effort" flows—such as peer-to-peer media sharing applications or gaming applications. Such flows could also be policed to 10 Mbps (which is still only 1% of a GE link's capacity), but with a more severe penalty for violations, namely dropping rather than remarking.
Once all ports have been set to trust or classify and mark (and optionally police) traffic, then ingress queuing policies may be applied (on platforms that require and support this feature). Ingress queuing details are discussed in the relevant platform-specific sections of this chapter.
Figure 2-10 summarizes these campus ingress QoS model examples.
Figure 2-10 Campus Ingress QoS Example Models
It bears repeating that not every application class described here needs to be provisioned for at the access edge. For example, if multimedia conferencing applications are not widely deployed or utilized, then this class (along with the DVLAN signaling class) need not be provisioned at the access edge. Similarly, administrators may choose to simplify their data plane provisioning models, such that rather than explicitly provisioning transactional data, bulk data, and best effort classes, these could be provisioned as an aggregate best effort class (and marked as DF and optionally policed at an aggregate policing level). Likewise, explicitly provisioning a scavenger class is completely optional. Nonetheless, full examples, as described, are shown in this design chapter to provide template configurations which may be simplified as needed (or alternatively, expanded on).
Once ingress traffic has been trusted, classified, and (optionally) policed at the campus access edge, then the ingress QoS model for all campus inter-switch links can be set to trust the DSCP markings of all incoming packets.
Egress QoS Models
Egress QoS models primarily deal with queuing and dropping policies (although additional egress QoS features—such as egress policing—are supported on some platforms). As discussed in the previous chapter, critical media applications require service guarantees regardless of network conditions. The only way to provide service guarantees is to enable queuing at any node that has the potential for congestion, regardless of how rarely this may actually occur. This principle applies not only to campus-to-WAN/VPN edges, where speed mismatches are most pronounced, but also to campus inter-switch links, where oversubscription ratios create the potential for instantaneous congestion. There is simply no other way to guarantee service levels other than by enabling queuing wherever a speed mismatch exists.
Additionally, because each medianet application class has unique service level requirements, each should optimally be assigned a dedicated queue. However, on platforms bounded by a limited number of hardware queues, no fewer than four queues would be required to support medianet QoS policies in the campus; specifically the following queues would be considered a minimum:
•
•
•
•
Additionally, given the queuing best practice guidelines outlined in the previous chapter, the following bandwidth allocations are recommended for these queues:
•
•
•
These campus queuing bandwidth allocation recommendations are illustrated in Figure 2-11.
Figure 2-11 Campus Queuing Bandwidth Recommendations
Given these minimum queuing requirements and bandwidth allocation recommendations, the following application classes can be mapped to the respective queues:
•
•
•
•
Obviously, if more queues are supported these should be leveraged to give more granular bandwidth guarantees to these respective application classes. Nonetheless, the general application class hierarchy is to provision realtime applications (such as voice, broadcast video and realtime interactive) in a strict priority queue, followed by control plane protocols (including network/internetwork control, signaling [which is control plane traffic for the voice/video infrastructure] and network management), followed by guaranteed bandwidth, non-realtime applications (including multimedia conferencing, multimedia streaming, and transactional data), followed by the default best effort class, followed by bulk data and scavenger applications. Maintaining such an application class hierarchy serves to ensure consistent per-hop behaviors (PHBs).
Some platforms provide DSCP-to-queue mapping functionality, whereas others (such as some Catalyst 6500 linecards) are limited to CoS-to-queue mapping functionality only. In both cases, it is the value of the internal DSCP that decides the transmit queue to which the packet is assigned; but in the case of CoS-to-queue mapping, internal DSCP values are assigned to queues in blocks of eight. For example, if CoS 1 is mapped to queue 1 (Q1), this means that internal DSCP values 8 through 15 are assigned to Q1; if CoS 2 is assigned to queue 2, this means that internal DSCP values 16-23 are assigned to Q2; if CoS 3 is mapped to queue 3, this means that internal DSCP values 24-31 are assigned to Q3, and so on. Essentially, CoS-to-queue mapping assigns the internal DSCP value that corresponds to the (CoS value * 8), along with the following seven internal DSCP values, to a given queue.
In some CoS-to-queue mapping scenarios, certain application classes may not be distinguishable from one another (due to the limited marking granularity of the 3-bit 802.1Q/p CoS model) and as such need to be assigned to the same queues. For example, since realtime interactive traffic (CS4/32) and multimedia conferencing traffic (AF41/34) share the same CoS value (of 4), these could not be mapped to different queues within a CoS-to-queue mapping model. Such considerations are discussed in more detail in the platform-specific sections of this chapter.
In contrast, with DSCP-to-queue mapping, discrete DSCP values can be mapped to specific queues, allowing for better queuing-policy granularity.
A campus egress QoS model example for a platform that supports DSCP-to-queue mapping with a 1P3Q8T queuing structure is shown in Figure 2-12.
Figure 2-12 Campus Egress QoS Model Example
Medianet Campus Port QoS Roles
The policy elements discussed thus far can be grouped into roles that various switch ports serve within the medianet campus architecture, such as:
•
–
–
–
–
–
•
–
–
–
–
–
•
–
–
–
–
–
•
–
–
–
–
–
Figure 2-13 shows these switch port QoS roles within a medianet campus architecture.
Figure 2-13 Medianet Campus Port QoS Roles
AutoQoS
Due to the complexity of some QoS policies, coupled with the large number of ports on typical Catalyst switches, QoS deployment can often become unwieldy. One option is to make liberal use of the interface range configuration command to deploy policies to multiple interfaces at once. Another option is to use Automatic QoS (AutoQoS), if applicable. Yet another option is to use Smartport macros (which is discussed in the following section).
To address customer demand for simplification of QoS deployment, Cisco developed the AutoQoS feature. AutoQoS is an intelligent macro that allows an administrator to enter one or two simple AutoQoS commands to enable all the recommended QoS settings for IP telephony on a specific switch port interface (this version of AutoQoS is also known as AutoQoS-VoIP).
AutoQoS for Catalyst switches supports three modes of operation, all of which are preceded by the auto qos voip interface configuration command:
•
•
•
Note
For additional details on AutoQoS and the platform-specific commands and settings that it generates, refer to the respective platform's AutoQoS documentation:
•
•
•
•
•
Some may naturally ask, why should I read this lengthy and complex QoS design document when I have AutoQoS? AutoQoS-VoIP is an excellent tool for customers who want to enable QoS for VoIP (only), that have basic QoS needs, or do not have the time or desire to do more with QoS.
However, it is important to remember how AutoQoS developed. AutoQoS features are the result of Cisco QoS feature development coupled with Cisco QoS design guides based on large-scale lab testing. AutoQoS-VoIP is the product of the first QoS design guide (published in 1999) and the AutoQoS-VoIP feature has not been significantly updated since. Therefore, if the business requirement for QoS is for IP Telephony only, then AutoQoS would be an excellent tool to expedite the QoS deployment. If, on the other hand, there are more advanced requirements of QoS—such as those presented in this document—then the configurations presented herein would be recommended over AutoQoS.
Smartport Macros
Smartports macros provide static (and on some platforms, dynamic) configurations to port or VLAN interfaces. With Smartport macros, longer configuration snippets can be deployed with a single command, with some configuration parameters modified dynamically (such as VLAN IDs and IP addresses).
Certain Smartport macros are pre-defined, or built in, within Catalyst IOS switch software, such as macros that configure ports to connect to Cisco IP phones (which includes the configuration and execution of AutoQoS-VoIP on the switchport), Cisco Catalyst switches, Cisco routers, and Cisco wireless access points (among other devices).
Additionally, Smartport macros can be deployed on event triggers. The most common event triggers are based on CDP messages received from connected devices. The detection of a device invokes a CDP event trigger, such as a Cisco IP phone, Cisco switch, Cisco router, or Cisco wireless access point.
Finally, Smartport macros can be custom defined, such that an administrator can assign a Smartport macro name to a custom configuration snippet and apply the macro statically or have it triggered dynamically by an event.
For additional information on Smartport macros refer to the respective platform Smartport Macro documentation.
•
•
•
•
•
•
Control Plane Policing
Control plane policing (CoPP) is a security infrastructure feature available on Catalyst 4500 and 6500 Series switches running Cisco IOS that allows the configuration of QoS policies that rate limit the traffic handled by the main CPU of the switch. This protects the control plane of the switch from direct DoS attacks and reconnaissance activity.
CoPP protects Catalyst 4500 and 6500 switches by allowing the definition and enforcement of QoS policies that regulate the traffic processed by the main switch CPU (route or switch processor). With CoPP, these QoS policies are configured to permit, block, or rate limit the packets handled by the main CPU.
Packets handled by the main CPU, referred to as control plane traffic, typically include the following:
•
•
•
•
•
•
CoPP leverages the modular QoS command line interface (MQC) for its QoS policy configuration. MQC allows the classification of traffic into classes and lets you define and apply distinct QoS policies to separately rate limit the traffic in each class. MQC lets you divide the traffic destined to the CPU into multiple classes based on different criteria. For example, four traffic classes could be defined based on relative importance: critical, normal, undesirable, and default. After the traffic classes are defined, a QoS policy can be defined and enforced for each class according to importance. The QoS policies in each class can be configured to permit all packets, drop all packets, or drop only those packets exceeding a specific rate limit.
Note
CoPP comes into play right after the switching or the routing decision and before traffic is forwarded to the control plane. When CoPP is enabled the sequence of events (at a high level) is:
1.
2.
3.
4.
5.
The Catalyst 4500 and Catalyst 6500 Series switches implement CoPP similarly; however, CoPP has been enhanced on both platforms to leverage the benefits of their hardware architectures, and as a result each platform provides unique features. Therefore, the CoPP implementations on Catalyst 4500 and Catalyst 6500 Series switches are discussed in platform-specific detail in their respective sections within this chapter. Nonetheless, some general guidelines to deploying CoPP are common to both platforms.
Defining CoPP Traffic Classes
Developing a CoPP policy starts with the classification of the control plane traffic. To that end, the control plane traffic needs to be first identified and separated into different class maps.
The Catalyst 4500 Series switches provides a macro which automatically generates a collection of class maps for common Layer 3 and Layer 2 control plane traffic. While very useful, these predefined class maps might not include all the necessary traffic classes reaching the control plane and as a result they might need to be complemented with other user-defined class maps. The Catalyst 6500 Series switches do not provide a configuration macro. Therefore, all class maps need to be defined by the user.
This section presents a classification template that can be used as a model when implementing CoPP on Catalyst 4500 and Catalyst 6500 Series switches. This template presents a realistic classification, where traffic is grouped based on its relative importance and protocol type. The template uses nine different classes, which provide great granularity and make it suitable for real-world environments. It is important to note that, even though you can use this template as a reference, the actual number and type of classes needed for a given network can differ and should be selected based on local requirements, security policies, and a thorough analysis of baseline traffic.
This CoPP template defines the following nine traffic classes:
•
•
•
•
•
•
•
•
•
Note
Deploying CoPP Policies
Because CoPP filters traffic, it is critical to gain an adequate level of understanding about the legitimate traffic destined to the RP prior to deployment. CoPP policies built without proper understanding of the protocols, devices, or required traffic rates involved can block critical traffic, which has the potential of creating a DoS condition. Determining the exact traffic profile needed to build the CoPP policies might be difficult in some networks.
The following steps follow a conservative methodology that facilitates the process of designing and deploying CoPP. This methodology uses iterative ACL configurations to help identify and to incrementally filter traffic.
To deploy CoPP, it is recommended that you perform the following steps:
Step 1
Identify the known protocols that access the RP and divide them into categories using the most useful criteria for your specific network. In the case of the Catalyst 4500 Series switch, you can take advantage of the system predefined classes and chose to combine them with your own classes. In the case of Catalyst 6500 there are no predefined classes, so you need to define all the classes. As an example of classification, the nine categories template presented earlier in this section (BGP, IGP, interactive management, file management, reporting, critical qpplications, undesirable, and default) use a combination of relative importance and traffic type. Select a scheme suited to your specific network, which might require a larger or smaller number of classes.
Step 2
Configure each ACL to permit all known protocols in its class that require access to the RP. At this point, each ACL entry should have both source and destination addresses set to any. In addition, the ACL for the default class should be configured with a single entry, permit ip any any. This matches traffic not explicitly permitted by entries in the other ACLs. After the ACLs have been configured, create a class map for each class defined in Step 1, including one for the default class. Then assign each ACL to its corresponding class map.
Note
Each class map should then be associated with a policy map that permits all traffic, regardless of classification. The policy for each class should be set as conform-action transmit exceed-action transmit.
Step 3
Ideally, the classification performed in Step 1 identified all required traffic destined to the router. However, realistically, not all required traffic is identified prior to deployment and the permit ip any any entry in the default class ACL logs a number of packet matches. Some form of analysis is required to determine the exact nature of the unclassified packets. For example, you can use the show access-lists command to see the entries in the ACLs that are in use and to identify any additional traffic sent to the RP. However, to analyze the unclassified traffic you can use one of the following techniques:
•
•
When traffic has been properly identified, adjust the class configuration accordingly. Remove the ACL entries for those protocols that are not used. Add a permit any any entry for each protocol just identified.
Step 4
Refine the classification ACLs by only allowing the full range of the allocated CIDR block to be permitted as the source address. For example, if the network has been allocated 172.68.0.0/16, then permit source addresses from 172.68.0.0/16 where applicable.
This step provides data points for devices or users from outside the CIDR block that might be accessing the equipment. An external BGP (eBGP) peer requires an exception because the permitted source addresses for the session lies outside the CIDR block. This phase might be left on for a few days to collect data for the next phase of narrowing the ACL entries.
Step 5
Increasingly limit the source address in the classification ACLs to only permit sources that communicate with the RP. For example, only known network management stations should be permitted to access the SNMP ports on a router.
Step 6
Use the show policy-map control-plane command to collect data about the actual policies in place. Analyze the packet count and rate information and develop a rate limiting policy accordingly. At this point, you might decide to remove the class map and ACL used for the classification of default traffic. If so, you should also replace the previously defined policy for the default class by the class default policy.
A tested and validated set of CoPP rates are presented in Table 2-1. It is important to note that the values presented here are solely for illustration purposes, as every environment has different baselines.
This CoPP classification template, deployment model, and rate limits are used in the Catalyst 4500 and 6500 CoPP configuration examples later in this chapter.
Cisco Catalyst 2960 and 2975, 3560G and 3750G, and 3560-E and 3750-E QoS Design
The Cisco Catalyst 2960, 2975, 3560G, 3750G, 3560-E, and 3750-E family of switches all support the (previously discussed) minimum requirements for medianet switches, including Gigabit Ethernet support, as well as supporting a strict priority hardware queue with at least three additional hardware queues.
The specific switch hardware configurations that meet these requirements are shown below, by switch family.
•
–
–
–
•
–
•
–
–
–
–
•
–
–
–
–
–
•
–
–
–
–
–
–
–
•
–
–
–
–
–
Note
At a high-level, the major differences between these switch product families are as follows: the Catalyst 2960 and 2975 are Layer 2-only switches, while the 3560G, 3750G, 3560-E, and 3750-E support Layer 2/Layer 3 multilayer switch feature sets. Additionally, the Catalyst 2960, 3560G, and 3560-E are standalone switches, while the Catalyst 2975, 3750G, and 3750-E are stackable switches; the Catalyst 2975 and 3750G support stacking with Cisco StackWise technology, while the 3750-E uses StackWise Plus technology. All of these Catalyst switches support a dual-counter-rotating ring, which effectively serves as the switching backplane; these rings are internal for non-stackable switches, but external (via special cables) for stackable switches. These rings operate at 16 Gbps each (for a total switching capacity of 32 Gbps), with the exception of the 3560-E and 3750-E, for which the rings operate at 32 Gbps each (for a total switching capacity of 64 Gbps).
Note
These major feature and functionality differences between these switch product families are summarized in Table 2-2.
While these switches have some major feature and functionality differences, their QoS feature set and command syntax are virtually identical, with a few minor differences, as is discussed in the following section.
Platform-Specific QoS Considerations
The Catalyst 2960, 2975, 3560G, 3750G, 3560-E, and 3750-E have virtually identical QoS feature sets, and as such are discussed collectively; additionally, for brevity, these switches are collectively referred to as the Catalyst 3750-E, except when discussing switch-specific differences. The complete QoS model for the Catalyst 3750-E is shown in Figure 2-14.
Figure 2-14 Catalyst 3750-E QoS Model
Traffic is classified on ingress, based on trust-states, access-lists, or class-maps. Marking or policing policies can be applied to physical switch ports or—on multilayer switch platforms—to Switch Virtual Interfaces (SVIs), which allows for per-VLAN or per-port/per-VLAN policies.
Because the total inbound bandwidth of all ports can exceed the bandwidth of the stack or internal ring, ingress queues are located after the packet is classified, policed, and marked and before packets are forwarded into the switch fabric (i.e., the internal or stack rings). Because multiple ingress ports can simultaneously send packets to an egress port (such as an uplink port) and cause congestion, outbound queues are located after the stack or internal rings. The queuing scheduler is Shared Round Robin (SRR), and the dropping algorithm is Weighted Tail Drop (WTD), both of which are discussed in more detail in Queuing Models.
Relating to QoS, the following key switch-specific differences exist:
•
•
•
•
•
Other than these key exceptions, the following commands and configurations work across these switch platforms (unless explicitly noted otherwise).
Enabling QoS
On all the switching platforms discussed in this chapter (with the exception of the Catalyst 4500-E/4900M) QoS needs to be explicitly enabled, as it is disabled by default. This is a critical first step to deploying QoS on these platforms. If this small—but important—step is overlooked, this can lead to frustration in troubleshooting QoS problems; this is because the switch software accepts QoS commands and even displays these within the switch configuration, but none of the QoS commands are active until the mls qos global command is enabled, as shown in Example 2-1.
Example 2-1 Enabling QoS on a Catalyst 3750-E
C3750-E(config)#mls qosThis configuration can be verified with the following command:
•
Example 2-2 Verifying Global QoS on a Catalyst 3750-E—show mls qos
C3750-E#show mls qosQoS is enabledQoS ip packet dscp rewrite is enabledC3750-E#Trust Models
The Catalyst 3750-E switch ports can be configured to statically trust CoS, DSCP, and IP Precedence (although this is considered to be relegated by DSCP-trust) or to dynamically and conditionally trust Cisco IP phones. By default, with QoS enabled, all ports are set to an untrusted state. The complete port trust classification flowchart for the Catalyst 3750-E switch product family is shown in Figure 2-15.
Figure 2-15 Catalyst 3750-E Port Trust Classification Flowchart
Trust-Cos Model
A Catalyst 3750-E switch port can be configured to trust CoS by configuring the interface with the mls qos trust cos command. However, if an interface is set to trust CoS, then it by default calculates a packet's internal DSCP to be the incoming packet's (CoS value * 8). While this may suitable for most markings, this default mapping may not be suitable for VoIP, as VoIP is usually marked CoS 5, which would map by default to DSCP 40 (and not 46, which is the EF PHB as defined by RFC 3246). Therefore, if an interface is set to trust CoS, then the default CoS-to-DSCP mapping table should be modified such that CoS 5 maps to DSCP 46, as shown in Example 2-3.
Example 2-3 Configuring Trust CoS and CoS-to-DSCP Mapping Modification on a Catalyst 3750-E
C3750-E(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56! CoS 5 (the sixth CoS value, starting from 0) is mapped to 46C3750-E(config)#interface GigabitEthernet 1/0/1C3750-E(config-if)#mls qos trust cos! The interface is set to statically trust CoSThis configuration can be verified with the following commands:
•
•
Example 2-4 Verifying Global CoS-to-DSCP Mapping Modifications on a Catalyst 3750-E—show mls qos map cos-dscp
C3750-E#show mls qos map cos-dscpCos-dscp map:cos: 0 1 2 3 4 5 6 7--------------------------------dscp: 0 8 16 24 32 46 48 56C3750-E#In Example 2-4, the CoS-to-DSCP mapping value for CoS 5 has been modified from the default mapping of 40 (CoS 5 * 8) to 46 (to match the recommendation from RFC 3246 that realtime applications be marked DSCP 46/EF).
Example 2-5 Verifying Interface Trust Settings on a Catalyst 3750-E—show mls qos interface
C3750-E#show mls qos interface GigabitEthernet 1/0/1GigabitEthernet1/0/1trust state: trust costrust mode: trust costrust enabled flag: enaCOS override: disdefault COS: 0DSCP Mutation Map: Default DSCP Mutation MapTrust device: noneqos mode: port-basedC3750-E#In Example 2-5, the port trust mode is set to trust CoS and the current (static) state of the interface is likewise set to trust CoS.
Trust-DSCP Model
Because of the additional granularity of DSCP versus QoS markings, it is generally recommended to trust DSCP rather than CoS (everything else being held equal). A Catalyst 3750-E switch port can be configured to trust DSCP with the mls qos trust dscp interface command, as shown in Example 2-6.
Example 2-6 Configuring Trust-DSCP on a Catalyst 3750-E
C3750-E(config)#interface GigabitEthernet 1/0/1C3750-E(config-if)#mls qos trust dscp! The interface is set to statically trust DSCPThis configuration can be verified with the following command:
•
Example 2-7 Verifying Interface Trust Settings on a Catalyst 3750-E—show mls qos interface
C3750-E#show mls qos interface GigabitEthernet 1/0/1GigabitEthernet1/0/1trust state: trust dscptrust mode: trust dscptrust enabled flag: enaCOS override: disdefault COS: 0DSCP Mutation Map: Default DSCP Mutation MapTrust device: noneqos mode: port-basedC3750-E#In Example 2-7, the port trust mode is set to trust DSCP and the current (static) state of the interface is likewise set to trust DSCP.
Conditional-Trust Model
In addition to configuring switch ports to statically trust endpoints, the Catalyst 3750-E family supports dynamic, conditional trust with the mls qos trust device interface command, which can be configured with the cisco-phone keyword to extend trust to Cisco IP phones, after these have been verified via a CDP-negotiation. Additionally, the type of trust to be extended must be specified (either CoS or DSCP). In general, it is recommended to dynamically extend DSCP-trust (over CoS-trust), not only because DSCP has greater marking granularity, but also because the type of trust configured on the ingress switch port on a Catalyst 3750-E family of switches ultimately determines the type of queuing policies that are applied on the egress switch port. Specifically, if an ingress switch port is configured to trust-CoS—whether this is configured statically or dynamically (in conjunction with the mls qos trust device interface command)—a CoS-to-queue mapping determines the (ingress and) egress queuing policy. Conversely, if an ingress switch port is configured to trust-DSCP—whether this is configured statically or dynamically—a DSCP-to-queue mapping determines the (ingress and) egress queuing policy. Since DSCP-to-queue mapping has more granular policy options, it is the preferred way to assign packets to queues and as such depends on the ingress switch port being set to trust DSCP.
An example of a dynamic, conditional trust policy that is set to extend DSCP-trust to CDP-verified Cisco IP phones is shown in Example 2-8.
Example 2-8 Configuring (DSCP-mode) Conditional Trust on a Catalyst 3750-E
C3750-E(config)#interface GigabitEthernet 1/0/1C3750-E(config-if)# switchport access vlan 10C3750-E(config-if)# switchport voice vlan 110C3750-E(config-if)# spanning-tree portfastC3750-E(config-if)# mls qos trust device cisco-phone! The interface is set to conditionally-trust Cisco IP PhonesC3750-E(config-if)# mls qos trust dscp! DSCP-trust will be dynamically extended to Cisco IP PhonesThis configuration can be verified with the following command:
•
Example 2-9 Verifying Interface Trust Settings on a Catalyst 3750-E—show mls qos interface
C3750-E#show mls qos interface GigabitEthernet 1/0/1GigabitEthernet1/0/1trust state: trust dscptrust mode: trust dscptrust enabled flag: enaCOS override: disdefault COS: 0DSCP Mutation Map: Default DSCP Mutation MapTrust device: cisco-phoneqos mode: port-basedC3750-E#In Example 2-9, the trust device feature has been enabled, with the trusted device being specified as a cisco-phone. The port trust mode—that is, the mode of trust (CoS | DSCP | IP Precedence) that is extended dynamically to the IP phone—is set to trust DSCP. Similarly, the current (dynamic) trust state of the interface is likewise set to trust DSCP. This is because there is a Cisco IP phone currently connected to the switch port; if this IP phone is removed from the switch port, the trust state of the interface toggles to "not trusted".
Marking Models
The Catalyst 3750-E family of switches supports two main marking models:
•
•
Each model is detailed in the following sections.
Per-Port Marking Model
The per-port marking model (based on Figure 2-10) matches VoIP and signaling traffic from the VVLAN by matching on DSCP EF and CS3, respectively. Multimedia conferencing traffic from the DVLAN is matched by UDP/RTP ports 16384-32767. Signaling traffic is matched on SCCP ports (TCP 2000-2002), as well as on SIP ports (TCP/UDP 5060-5061). Other transactional data traffic, bulk data, and scavenger traffic are matched on various ports (outlined in Figure 2-9). The service policy is applied to an interface range, along with (DSCP-mode) conditional trust, as shown in Example 2-10.
Example 2-10 Per-Port Marking Configuration Example on a Catalyst 3750-E
! This first section configures IP access-lists to match applicationsC3750-E(config)#ip access-list extended MULTIMEDIA-CONFERENCINGC3750-E(config-ext-nacl)# remark RTPC3750-E(config-ext-nacl)# permit udp any any range 16384 32767C3750-E(config)#ip access-list extended SIGNALINGC3750-E(config-ext-nacl)# remark SCCPC3750-E(config-ext-nacl)# permit tcp any any range 2000 2002C3750-E(config-ext-nacl)# remark SIPC3750-E(config-ext-nacl)# permit tcp any any range 5060 5061C3750-E(config-ext-nacl)# permit udp any any range 5060 5061C3750-E(config)#ip access-list extended TRANSACTIONAL-DATAC3750-E(config-ext-nacl)# remark HTTPSC3750-E(config-ext-nacl)# permit tcp any any eq 443C3750-E(config-ext-nacl)# remark ORACLE-SQL*NETC3750-E(config-ext-nacl)# permit tcp any any eq 1521C3750-E(config-ext-nacl)# permit udp any any eq 1521C3750-E(config-ext-nacl)# remark ORACLEC3750-E(config-ext-nacl)# permit tcp any any eq 1526C3750-E(config-ext-nacl)# permit udp any any eq 1526C3750-E(config-ext-nacl)# permit tcp any any eq 1575C3750-E(config-ext-nacl)# permit udp any any eq 1575C3750-E(config-ext-nacl)# permit tcp any any eq 1630C3750-E(config-ext-nacl)# permit udp any any eq 1526C3750-E(config)#ip access-list extended BULK-DATAC3750-E(config-ext-nacl)# remark FTPC3750-E(config-ext-nacl)# permit tcp any any eq ftpC3750-E(config-ext-nacl)# permit tcp any any eq ftp-dataC3750-E(config-ext-nacl)# remark SSH/SFTPC3750-E(config-ext-nacl)# permit tcp any any eq 22C3750-E(config-ext-nacl)# remark SMTP/SECURE SMTPC3750-E(config-ext-nacl)# permit tcp any any eq smtpC3750-E(config-ext-nacl)# permit tcp any any eq 465C3750-E(config-ext-nacl)# remark IMAP/SECURE IMAPC3750-E(config-ext-nacl)# permit tcp any any eq 143C3750-E(config-ext-nacl)# permit tcp any any eq 993C3750-E(config-ext-nacl)# remark POP3/SECURE POP3C3750-E(config-ext-nacl)# permit tcp any any eq pop3C3750-E(config-ext-nacl)# permit tcp any any eq 995C3750-E(config-ext-nacl)# remark CONNECTED PC BACKUPC3750-E(config-ext-nacl)# permit tcp any eq 1914 anyC3750-E(config)#ip access-list extended SCAVENGERC3750-E(config-ext-nacl)# remark KAZAAC3750-E(config-ext-nacl)# permit tcp any any eq 1214C3750-E(config-ext-nacl)# permit udp any any eq 1214C3750-E(config-ext-nacl)# remark MICROSOFT DIRECT X GAMINGC3750-E(config-ext-nacl)# permit tcp any any range 2300 2400C3750-E(config-ext-nacl)# permit udp any any range 2300 2400C3750-E(config-ext-nacl)# remark APPLE ITUNES MUSIC SHARINGC3750-E(config-ext-nacl)# permit tcp any any eq 3689C3750-E(config-ext-nacl)# permit udp any any eq 3689C3750-E(config-ext-nacl)# remark BITTORRENTC3750-E(config-ext-nacl)# permit tcp any any range 6881 6999C3750-E(config-ext-nacl)# remark YAHOO GAMESC3750-E(config-ext-nacl)# permit tcp any any eq 11999C3750-E(config-ext-nacl)# remark MSN GAMING ZONEC3750-E(config-ext-nacl)# permit tcp any any range 28800 29100C3750-E(config)#ip access-list extended DEFAULTC3750-E(config-ext-nacl)# remark EXPLICIT CLASS-DEFAULTC3750-E(config-ext-nacl)# permit ip any any! This section configures the class-mapsC3750-E(config-cmap)#class-map match-all VVLAN-VOIPC3750-E(config-cmap)# match ip dscp ef! VoIP is trusted (from the VVLAN)C3750-E(config-cmap)#class-map match-all VVLAN-SIGNALINGC3750-E(config-cmap)# match ip dscp cs3! Signaling is trusted (from the VVLAN)C3750-E(config-cmap)#class-map match-all MULTIMEDIA-CONFERENCINGC3750-E(config-cmap)# match access-group name MULTIMEDIA-CONFERENCING! Associates MULTIMEDIA-CONFERENCING access-list with class-mapC3750-E(config-cmap)#class-map match-all SIGNALINGC3750-E(config-cmap)# match access-group name SIGNALING! Associates SIGNALING access-list with class-mapC3750-E(config-cmap)#class-map match-all TRANSACTIONAL-DATAC3750-E(config-cmap)# match access-group name TRANSACTIONAL-DATA! Associates TRANSACTIONAL-DATA access-list with class-mapC3750-E(config-cmap)#class-map match-all BULK-DATAC3750-E(config-cmap)# match access-group name BULK-DATA! Associates BULK-DATA access-list with class-mapC3750-E(config-cmap)#class-map match-all SCAVENGERC3750-E(config-cmap)# match access-group name SCAVENGER! Associates SCAVENGER access-list with class-mapC3750-E(config-cmap)#class-map match-all DEFAULTC3750-E(config-cmap)# match access-group name DEFAULT! Associates DEFAULT access-list with class-map! This section configures the Per-Port ingress marking policy-mapC3750-E(config-cmap)#policy-map PER-PORT-MARKINGC3750-E(config-pmap)# class VVLAN-VOIPC3750-E(config-pmap-c)# set dscp ef! VoIP is marked EF (see note below)C3750-E(config-pmap-c)# class VVLAN-SIGNALINGC3750-E(config-pmap-c)# set dscp cs3! Signaling (from the VVLAN) is marked CS3 (see note below)C3750-E(config-pmap-c)# class MULTIMEDIA-CONFERENCINGC3750-E(config-pmap-c)# set dscp af41! Multimedia-conferencing is marked AF41C3750-E(config-pmap-c)# class SIGNALINGC3750-E(config-pmap-c)# set dscp cs3! Signaling (from the DVLAN) is marked CS3C3750-E(config-pmap-c)# class TRANSACTIONAL-DATAC3750-E(config-pmap-c)# set dscp af21! Transactional Data is marked AF21C3750-E(config-pmap-c)# class BULK-DATAC3750-E(config-pmap-c)# set dscp af11! Bulk Data is marked AF11C3750-E(config-pmap-c)# class SCAVENGERC3750-E(config-pmap-c)# set dscp cs1! Scavenger traffic is marked CS1C3750-E(config-pmap-c)# class DEFAULTC3750-E(config-pmap-c)# set dscp default! An explicit class-default marks all other IP traffic to 0 (see note)! This section attaches the service-policy to the interface(s)C3750-E(config)#interface range GigabitEthernet 1/0/1-48C3750-E(config-if-range)# switchport access vlan 10C3750-E(config-if-range)# switchport voice vlan 110C3750-E(config-if-range)# spanning-tree portfastC3750-E(config-if-range)# mls qos trust device cisco-phone! The interface is set to conditionally-trust Cisco IP PhonesC3750-E(config-if-range)# mls qos trust dscp! DSCP-trust will be dynamically extended to Cisco IP PhonesC3750-E(config-if-range)# service-policy input PER-PORT-MARKING! Attaches the Per-Port Marking policy to the interface(s)
Note
Note
This configuration can be verified with the following commands:
•
•
•
•
Example 2-11 Verifying Interface Trust and Policy Settings on a Catalyst 3750-E—show mls qos interface
C3750-E#show mls qos interface GigabitEthernet 1/0/1GigabitEthernet1/0/1Attached policy-map for Ingress: PER-PORT-MARKINGtrust state: trust dscptrust mode: trust dscptrust enabled flag: enaCOS override: disdefault COS: 0DSCP Mutation Map: Default DSCP Mutation MapTrust device: cisco-phoneqos mode: port-basedC3750-E#In Example 2-11, DSCP-mode conditional trust has been applied to the interface (which allows the port to dynamically extend DSCP-trust to the Cisco IP phone, such that VVLAN-VoIP and VVLAN-Signaling traffic can be matched on DSCP EF and CS3, respectively). Additionally the PER-PORT-MARKING service policy has been attached to the interface to classify both VVLAN and DVLAN traffic.
Example 2-12 Verifying Class Maps on a Catalyst 3750-E—show class-map
C3750-E#show class-mapClass Map match-any class-default (id 0)Match anyClass Map match-all BULK-DATA (id 6)Match access-group name BULK-DATAClass Map match-all VVLAN-SIGNALING (id 2)Match ip dscp cs3 (24)Class Map match-all MULTIMEDIA-CONFERENCING (id 3)Match access-group name MULTIMEDIA-CONFERENCINGClass Map match-all DEFAULT (id 8)Match access-group name DEFAULTClass Map match-all SCAVENGER (id 7)Match access-group name SCAVENGERClass Map match-all SIGNALING (id 4)Match access-group name SIGNALINGClass Map match-all VVLAN-VOIP (id 1)Match ip dscp ef (46)Class Map match-all TRANSACTIONAL-DATA (id 5)Match access-group name TRANSACTIONAL-DATAC3750-E#Example 2-13 Verifying Policy Maps on a Catalyst 3750-E—show policy-map
C3750-E#show policy-mapPolicy Map PER-PORT-MARKINGClass VVLAN-VOIPset dscp efClass VVLAN-SIGNALINGset dscp cs3Class MULTIMEDIA-CONFERENCINGset dscp af41Class SIGNALINGset dscp cs3Class TRANSACTIONAL-DATAset dscp af21Class BULK-DATAset dscp af11Class SCAVENGERset dscp cs1Class DEFAULTset dscp defaultC3750-E#Example 2-14 Verifying Service Policies on a Catalyst 3750-E—show policy-map interface
C3750-E#show policy-map interface GigabitEthernet 1/0/1GigabitEthernet1/0/1Service-policy input: PER-PORT-MARKINGClass-map: VVLAN-VOIP (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: ip dscp ef (46)Class-map: VVLAN-SIGNALING (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: ip dscp cs3 (24)Class-map: MULTIMEDIA-CONFERENCING (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: access-group name MULTIMEDIA-CONFERENCINGClass-map: SIGNALING (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: access-group name SIGNALINGClass-map: TRANSACTIONAL-DATA (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: access-group name TRANSACTIONAL-DATAClass-map: BULK-DATA (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: access-group name BULK-DATAClass-map: SCAVENGER (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: access-group name SCAVENGERClass-map: DEFAULT (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: access-group name DEFAULTClass-map: class-default (match-any)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: any0 packets, 0 bytes5 minute rate 0 bpsC3750-E#As shown in Example 2-14, unlike the show policy-map interface outputs on IOS routers, the corresponding command on the Catalyst 3750-E series of switches does not dynamically increment packet, byte, drop, and bps counters.
Per-VLAN Marking Model
An alternative approach for deploying marking policies on the Catalyst 3560/3750 platforms is to deploy these on a per-VLAN basis. In order to do so, the interfaces belonging to the VLANs need to be configured with the mls qos vlan-based interface command. Additionally, the policy-map can be simplified/broken-apart, as applicable to each VLAN. Adapting the previous example to a VLAN-based marking policing allows for the VVLAN-based policy map to be reduced to only three explicit classes: VoIP, signaling, and the explicit default class. Similarly, the DVLAN-based policy map is reduced to six explicit classes: multimedia conferencing, signaling, transactional data, bulk data, scavenger, and the explicit default class. A per-VLAN marking model is shown in Example 2-15.
Note
Example 2-15 Per-VLAN Marking Configuration Example on a Catalyst 3750-E
! This section configures the ingress marking policy-map for the VVLANC3750-E(config)#policy-map VVLAN-MARKINGC3750-E(config-pmap)# class VVLAN-VOIPC3750-E(config-pmap-c)# set dscp ef! VoIP is trusted (from the VVLAN)C3750-E(config-pmap-c)# class VVLAN-SIGNALINGC3750-E(config-pmap-c)# set dscp cs3! Signaling is trusted (from the VVLAN)C3750-E(config-pmap-c)# class DEFAULTC3750-E(config-pmap-c)# set dscp default! An explicit DEFAULT class marks all other VVLAN IP traffic to DF! This section configures the ingress marking policy-map for the DVLANC3750-E(config)#policy-map DVLAN-MARKINGC3750-E(config-pmap)# class MULTIMEDIA-CONFERENCINGC3750-E(config-pmap-c)# set dscp af41! Multimedia-conferencing is marked AF41C3750-E(config-pmap-c)# class SIGNALINGC3750-E(config-pmap-c)# set dscp cs3! Signaling (from the DVLAN) is marked CS3C3750-E(config-pmap-c)# class TRANSACTIONAL-DATAC3750-E(config-pmap-c)# set dscp af21! Transactional Data is marked AF21C3750-E(config-pmap-c)# class BULK-DATAC3750-E(config-pmap-c)# set dscp af11! Bulk Data is marked AF11C3750-E(config-pmap-c)# class SCAVENGERC3750-E(config-pmap-c)# set dscp cs1! Scavenger traffic is marked CS1C3750-E(config-pmap-c)# class DEFAULTC3750-E(config-pmap-c)# set dscp default! An explicit DEFAULT class marks all other DVLAN IP traffic to DF! This section configures the interface(s) for conditional trust! and enables VLAN-based QoSC3750-E(config)#interface range GigabitEthernet 1/0/1-48C3750-E(config-if-range)# switchport access vlan 10C3750-E(config-if-range)# switchport voice vlan 110C3750-E(config-if-range)# spanning-tree portfastC3750-E(config-if-range)# mls qos trust device cisco-phone! The interface is set to conditionally-trust Cisco IP PhonesC3750-E(config-if-range)# mls qos vlan-based! Enables VLAN-based QoS on the interface(s)! This section attaches the DVLAN policy to the DVLAN interfaceC3750-E(config)#interface Vlan 10C3750-E(config-if)# description DVLANC3750-E(config-if)# service-policy input DVLAN-MARKING! Attaches the DVLAN Per-VLAN Marking policy to the DVLAN interface! This section attaches the VVLAN policy to the VVLAN interfaceC3750-E(config)#interface Vlan 110C3750-E(config-if)# description VVLANC3750-E(config-if)# service-policy input VVLAN-MARKING! Attaches the VVLAN Per-VLAN Marking policy to the VVLAN interface
Note
This configuration can be verified with the following commands:
•
•
•
•
Policing Models
The Catalyst 3750-E family of switches support 256 policers per hardware ASIC. These switches share 2, 4, 6, 8, or 24 ports per ASIC (this depends on the platform and hardware configuration). The number of ASICs for a specific switch can be verified by using the show platform port-asic version verification command. Additionally, the specific switch ports associated with each ASIC can further be identified by the show platform pm platform-block verification command (in the ASIC column).
As a reminder, the following policing caveats apply to these switches:
•
•
The Catalyst 3750-E family of switches supports the following ingress policing models:
•
•
•
The per-port and per-port/per-VLAN policing models for the Catalyst 3750-E family of switches are detailed in the following sections.
Per-Port Policing Model
The per-port policing model is quite similar to the per-port marking model, except that the policy action includes a policing function-in some cases to drop, in others to remark. As shown in Figure 2-10, the VoIP and signaling traffic from the VVLAN can be policed to drop at 128 kbps and 32 kbps, respectively (as any excessive traffic matching this criteria would be indicative of network abuse). Similarly, the multimedia conferencing, signaling, and scavenger traffic from the DVLAN can be policed to drop. On the other hand, data plane policing policies can be applied to transactional, bulk, and best effort data traffic, such that these flows are subject to being remarked (but not dropped at the ingress edge) when severely out-of-profile. Remarking is performed by configuring a policed-DSCP map with the global configuration command mls qos map policed-dscp, which specifies which DSCP values are subject to remarking if out-of-profile and what value these should be remarked as (which in the case of data plane policing/scavenger class QoS policies, this value is CS1/DSCP 8). A per-port policing model for a Catalyst 3750-E is shown in Example 2-16.
Example 2-16 Per-Port Policing Configuration Example on a Catalyst 3750-E
! This section configures the global policed-DSCP markdown mapC3750-E(config)#mls qos map policed-dscp 0 10 18 to 8! DSCP 0 (DF), 10 (AF11) and 18 (AF21) are marked down to 8 (CS1)! if found to be in excess of their (respective) policing rates! This section configures the Per-Port policing policy-mapC3750-E(config)#policy-map PER-PORT-POLICINGC3750-E(config-pmap)# class VVLAN-VOIPC3750-E(config-pmap-c)# set dscp efC3750-E(config-pmap-c)# police 128k 8000 exceed-action drop! VoIP is marked EF and policed to drop at 128 kbpsC3750-E(config-pmap-c)# class VVLAN-SIGNALINGC3750-E(config-pmap-c)# set dscp cs3C3750-E(config-pmap-c)# police 32k 8000 exceed-action drop! (VVLAN) Signaling is marked CS3 and policed to drop at 32 kbpsC3750-E(config-pmap-c)# class MULTIMEDIA-CONFERENCINGC3750-E(config-pmap-c)# set dscp af41C3750-E(config-pmap-c)# police 5m 8000 exceed-action drop! Multimedia-conferencing is marked AF41 and policed to drop at 5 MbpsC3750-E(config-pmap-c)# class SIGNALINGC3750-E(config-pmap-c)# set dscp cs3C3750-E(config-pmap-c)# police 32k 8000 exceed-action drop! (DVLAN) Signaling is marked CS3 and policed to drop at 32 kbpsC3750-E(config-pmap-c)# class TRANSACTIONAL-DATAC3750-E(config-pmap-c)# set dscp af21C3750-E(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit! Trans-data is marked AF21 and policed to remark (to CS1) at 10 MbpsC3750-E(config-pmap-c)# class BULK-DATAC3750-E(config-pmap-c)# set dscp af11C3750-E(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit! Bulk-data is marked AF11 and policed to remark (to CS1) at 10 MbpsC3750-E(config-pmap-c)# class SCAVENGERC3750-E(config-pmap-c)# set dscp cs1C3750-E(config-pmap-c)# police 10m 8000 exceed-action drop! Scavenger traffic is marked CS1 and policed to drop at 10 MbpsC3750-E(config-pmap-c)# class DEFAULTC3750-E(config-pmap-c)# set dscp defaultC3750-E(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit! An explicit default class marks all other IP traffic to DF! and polices all other IP traffic to remark (to CS1) at 10 Mbps! This section attaches the service-policy to the interface(s)C3750-E(config)#interface range GigabitEthernet 1/0/1-48C3750-E(config-if-range)# switchport access vlan 10C3750-E(config-if-range)# switchport voice vlan 110C3750-E(config-if-range)# spanning-tree portfastC3750-E(config-if-range)# mls qos trust device cisco-phone! The interface is set to conditionally-trust Cisco IP PhonesC3750-E(config-if-range)# mls qos trust dscp! DSCP-trust will be dynamically extended to Cisco IP PhonesC3750-E(config-if-range)# service-policy input PER-PORT-POLICING! Attaches the Per-Port Policing policy to the interface(s)
Note
This configuration can be verified with the following commands:
•
•
•
•
•
•
Example 2-17 Verifying Global Policing Markdown Mappings on a Catalyst 3750-E—show mls qos maps policed-dscp
C3750-E#show mls qos maps policed-dscpPoliced-dscp map:d1 : d2 0 1 2 3 4 5 6 7 8 9---------------------------------------0 : 08 01 02 03 04 05 06 07 08 091 : 08 11 12 13 14 15 16 17 08 192 : 20 21 22 23 24 25 26 27 28 293 : 30 31 32 33 34 35 36 37 38 394 : 40 41 42 43 44 45 46 47 48 495 : 50 51 52 53 54 55 56 57 58 596 : 60 61 62 63C3750-E#In Example 2-17, the policing DSCP-markdown mapping is shown. The first digit of the DSCP value of a packet offered to a policer is shown along the Y-axis of the table; the second digit of the DSCP value of a packet offered to a policer is shown along the X-axis of the table. For example, the DSCP value for the transactional data application class (AF21/18) is found in the row d1=1 and column d2=8. And, as shown, packets with this offered DSCP value (along with DF/0 and AF11/10) are remarked to CS1 (08) if found to be in excess of the policing rate.
Example 2-18 Verifying Interface Policers on a Catalyst 3750-E—show mls qos interface interface x/y policers
C3750-E#show mls qos interface GigabitEthernet 1/0/1 policersGigabitEthernet1/0/1policymap=PER-PORT-POLICINGtype=Single, id=1 rate=128000, qlimit=8000, drop=1type=Single, id=2 rate=32000, qlimit=8000, drop=1type=Single, id=3 rate=5000000, qlimit=8000, drop=1type=Single, id=4 rate=32000, qlimit=8000, drop=1type=Single, id=5 rate=10000000, qlimit=8000, drop=0type=Single, id=6 rate=10000000, qlimit=8000, drop=0type=Single, id=7 rate=10000000, qlimit=8000, drop=1type=Single, id=8 rate=10000000, qlimit=8000, drop=0C3750-E#In Example 2-18, the interface policers for GigabitEthernet 1/0/1 are shown, including the policing rates, burst, and drop-function values (drop=1 means that exceeding-traffic is dropped, while drop=0 value means that exceeding-traffic is not dropped, but remarked).
Per-Port/Per-VLAN Policing Model
An alternative—and more discrete—approach for deploying policing policies on the Catalyst 3560/3750 platforms is to deploy these on a per-port/per-VLAN basis, which (on this family of switch platforms) requires the use of hierarchical QoS policies, also known as nested QoS policies.
The first step is to configure a class-map that defines the switch port(s) to which the policers are attached. Then one or more per-port policers need to be defined (according to the various levels of policing rates or exceeding-actions required); these policers reference the previously-defined class map that specifies the switch port(s) are policed. These per-port policers comprise the "child" policy maps in the hierarchy.
Following this, "parent" policy maps are configured that combine the various per-port policers for the various classes of traffic for a given VLAN. Each of these parent policy maps reference child policies that implement the per-port policing functions. Finally, these parent policy maps are applied to the VLAN SVI interfaces.
In Example 2-18, a class map (VLAN-10/110-PORTS) defines the ports on which the policers are enforced, specifically the ports belonging to DVLAN 10 and VVLAN 110 (which in this example equates to Gigabit Ethernet ports 1/0/1 through 1/0/48). Then a series of per-port policers (child policy maps) are defined, one each for 128 kbps (with a dropping action), 32 kbps (with a dropping action), 5 Mbps (with a dropping action), 10 Mbps (with a dropping action), and 10 Mbps (with a remarking action). Following this, a parent policy map for the VVLAN references the child policy maps to police VoIP to 128 kbps, (VLAN) signaling to 32 kbps, and all other VVLAN IP traffic to 32 kbps.
Similarly, a parent policy map for the DVLAN references the child policy,maps to police multimedia conferencing to 5 Mbps, (DVLAN) signaling to 32 kbps, and scavenger traffic to 10 Mbps. However, data plane policing (scavenger class QoS) policies are applied to the transactional data, bulk data, and the (explicitly defined) best effort class to police these (respectively) to 10 Mbps with a remarking action and not a dropping action.
As in the previous example, remarking is performed by configuring a policed DSCP map with the global configuration command mls qos map policed-dscp, which specifies which DSCP values are subject to remarking if out-of-profile and what value these should be remarked as (which in the case of data plane policing/scavenger class QoS policies, this value is CS1/DSCP 8). The switch ports have VLAN-based QoS enabled on them and the parent service policies are applied to the VLAN SVI interfaces for the DVLAN and the VVLAN.
Example 2-19 Per-Port/Per-VLAN Policing Configuration Example on a Catalyst 3750-E
! This section configures the global policed-DSCP markdown mapC3750-E(config)#mls qos map policed-dscp 0 10 18 to 8! DSCP 0 (DF), 10 (AF11) and 18 (AF21) are marked down to 8 (CS1)! if found to be in excess of their (respective) policing rates! This section configures the class-map of switch ports! that the Per-Port/Per-VLAN policing actions will be enforced onC3750-E(config)#class-map match-all VLAN-10/110-PORTSC3750-E(config-cmap)# match input-interface GigabitEthernet1/0/1 - GigabitEthernet1/0/48! This section configures Per-Port policersC3750-E(config-pmap)#policy-map PER-PORT-POLICER-128K-DROPC3750-E(config-pmap)# class VLAN-10/110-PORTSC3750-E(config-pmap-c)# police 128k 8000 exceed-action drop! This policy-map configures a 128 kbps dropping policer for the portsC3750-E(config-pmap)#policy-map PER-PORT-POLICER-32K-DROP-VVLANC3750-E(config-pmap)# class VLAN-10/110-PORTSC3750-E(config-pmap-c)# police 32k 8000 exceed-action drop! This policy-map configures a 32 kbps dropping policer for the ports! but only for use on the VVLAN (see note below)C3750-E(config-pmap)#policy-map PER-PORT-POLICER-32K-DROP-DVLANC3750-E(config-pmap)# class VLAN-10/110-PORTSC3750-E(config-pmap-c)# police 32k 8000 exceed-action drop! This policy-map configures a 32 kbps dropping policer for the ports! but only for use on the DVLAN (see note below)C3750-E(config-pmap)#policy-map PER-PORT-POLICER-5M-DROPC3750-E(config-pmap)# class VLAN-10/110-PORTSC3750-E(config-pmap-c)# police 5m 8000 exceed-action drop! This policy-map configures a 5 Mbps dropping policer for the portsC3750-E(config-pmap)#policy-map PER-PORT-POLICER-10M-DROPC3750-E(config-pmap)# class VLAN-10/110-PORTSC3750-E(config-pmap-c)# police 10m 8000 exceed-action drop! This policy-map configures a 10 Mbps dropping policer for the portsC3750-E(config-pmap)#policy-map PER-PORT-POLICER-10M-REMARKC3750-E(config-pmap)# class VLAN-10/110-PORTSC3750-E(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit! This policy-map configures a 10 Mbps remarking policer for the ports! This section combines the Per-Port policers for the VVLAN policy-mapC3750-E(config-pmap)#policy-map VVLAN-POLICERSC3750-E(config-pmap)# class VVLAN-VOIPC3750-E(config-pmap-c)# set dscp efC3750-E(config-pmap-c)# service-policy PER-PORT-POLICER-128K-DROP! VoIP is marked to EF and! (via a nested service-policy) is policed to drop at 128 kbpsC3750-E(config-pmap-c)# class VVLAN-SIGNALINGC3750-E(config-pmap-c)# set dscp cs3C3750-E(config-pmap-c)# service-policy PER-PORT-POLICER-32K-DROP-VVLAN! (VVLAN) Signaling is marked to CS3 and! (via a nested service-policy) is policed to drop at 32 kbpsC3750-E(config-pmap-c)# class DEFAULTC3750-E(config-pmap-c)# set dscp defaultC3750-E(config-pmap-c)# service-policy PER-PORT-POLICER-32K-DROP-VVLAN! An explicit default class marks all other VVLAN IP traffic to DF! and (via a nested service-policy) polices to drop at 32 kbpsC3750-E(config-pmap-c)#exitC3750-E(config-pmap)#C3750-E(config-pmap)#! This section combines the Per-Port policers for the DVLAN policy-mapC3750-E(config-pmap)#policy-map DVLAN-POLICERSC3750-E(config-pmap)# class MULTIMEDIA-CONFERENCINGC3750-E(config-pmap-c)# set dscp af41C3750-E(config-pmap-c)# service-policy PER-PORT-POLICER-5M-DROP! Multimedia-conferencing is marked AF41 and! (via a nested service-policy) is policed to drop at 5 MbpsC3750-E(config-pmap-c)# class SIGNALINGC3750-E(config-pmap-c)# set dscp cs3C3750-E(config-pmap-c)# service-policy PER-PORT-POLICER-32K-DROP-DVLAN! (DVLAN) Signaling is marked CS3 and! (via a nested service-policy) is policed to drop at 32 kbpsC3750-E(config-pmap-c)# class TRANSACTIONAL-DATAC3750-E(config-pmap-c)# set dscp af21C3750-E(config-pmap-c)# service-policy PER-PORT-POLICER-10M-REMARK! Transactional-data is marked AF21 and (via a nested service-policy)! is policed to remark (to CS1) at 10 MbpsC3750-E(config-pmap-c)# class BULK-DATAC3750-E(config-pmap-c)# set dscp af11C3750-E(config-pmap-c)# service-policy PER-PORT-POLICER-10M-REMARK! Bulk-data is marked AF11 and (via a nested service-policy)! is policed to remark (to CS1) at 10 MbpsC3750-E(config-pmap-c)# class SCAVENGERC3750-E(config-pmap-c)# set dscp cs1C3750-E(config-pmap-c)# service-policy PER-PORT-POLICER-10M-DROP! Scavenger traffic is marked CS1 and (via a nested service-policy)! is policed to drop at 10 MbpsC3750-E(config-pmap-c)# class DEFAULTC3750-E(config-pmap-c)# set dscp defaultC3750-E(config-pmap-c)# service-policy PER-PORT-POLICER-10M-REMARK! An explicit default class marks all other DVLAN IP traffic to DF and! (via a nested service-policy) polices to remark (to CS1) at 10 Mbps! This section configures the interfaces for conditional trust! and enables VLAN-based QoSC3750-E(config)#interface range GigabitEthernet 1/0/1-48C3750-E(config-if-range)# switchport access vlan 10C3750-E(config-if-range)# switchport voice vlan 110C3750-E(config-if-range)# spanning-tree portfastC3750-E(config-if-range)# mls qos trust device cisco-phone! The interface is set to conditionally-trust Cisco IP PhonesC3750-E(config-if-range)# mls qos vlan-based! Enables VLAN-based QoS on the interface(s)! This section attaches the DVLAN policers to the DVLAN interfaceC3750-E(config)#interface Vlan 10C3750-E(config-if)# description DVLANC3750-E(config-if)# service-policy input DVLAN-POLICERS! Attaches the DVLAN Per-VLAN Policing policy to the DVLAN interface! This section attaches the VVLAN policers to the VVLAN interfaceC3750-E(config)#interface Vlan 110C3750-E(config-if)# description VVLANC3750-E(config-if)# service-policy input VVLAN-POLICERS! Attaches the VVLAN Per-VLAN Policing policy to the VVLAN interface
Note
Note
Note
—When a new stack master is selected, the stack master re-enables and reconfigures these features on all applicable interfaces on the stack master.
—When a stack member is added, the stack master re-enables and reconfigures these features on all applicable ports on the stack member.
—When you merge switch stacks, the new stack master re-enables and reconfigures these features on the switches in the new stack.
—When the switch stack divides into two or more switch stacks, the stack master in each switch stack re-enables and reconfigures these features on all applicable interfaces on the stack members, including the stack master.This configuration can be verified with the following commands:
•
•
•
•
•
•
Queuing Models
As shown in Figure 2-14, on the Catalyst 3750-E switch-family platforms, because the total inbound bandwidth of all ports can exceed the bandwidth of the stack or internal ring, ingress queues are located after the packet is classified, policed, and marked and before packets are forwarded into the switch fabric. Additionally, because multiple ingress ports can simultaneously send packets to an egress port and cause congestion, outbound queues are located after the stack or internal ring.
Both the ingress and egress queues are serviced by a Shaped Round Robin (SRR) scheduling algorithm. SRR can be configured in two modes, shaped or sharing.
In shaped mode, the egress queues are guaranteed a percentage of the bandwidth and they are rate limited to that amount. Shaped traffic does not use more than the allocated bandwidth even if the link is idle. Shaping provides a more even flow of traffic over time and reduces the peaks and valleys of bursty traffic. With shaping, the absolute value of each weight is used to compute the bandwidth available for the queues. SRR shaping is configured with the srr-queue bandwidth shape interface command.
In shared mode, the ingress or egress queues share the bandwidth among them according to the configured weights. The bandwidth is guaranteed at this level but not limited to it. For example, if a queue is empty and no longer requires a share of the link, the remaining queues can expand into the unused bandwidth and share it among them. With sharing, the ratio of the weights controls the frequency of dequeuing; the absolute values are meaningless. SRR sharing is configured with the srr-queue bandwidth share interface command.
Furthermore, both the ingress and egress queuing structures support the enabling of a single priority queue, or expedite queue, as it corresponds to the EF PHB. An ingress or egress queue operating as an expedite queue is fully serviced ahead of all other queues until empty. A strict priority queue is enabled with the priority-queue interface command.
With respect to scheduling hierarchy in the Catalyst 3750-E family of switches, shaped mode overrides shared mode and priority mode overrides both shaped and shared modes.
Additionally, the Catalyst 3750-E family of switches supports the weighted tail drop (WTD) congestion avoidance mechanism. WTD is implemented on queues to manage the queue lengths and to provide drop preferences for different traffic classifications. As a packet is enqueued to a particular ingress or egress queue, WTD uses the frame's assigned internal DSCP to subject it to different drop thresholds. If the threshold is exceeded for a given internal DSCP value (in other words, the space available in the destination queue is less than the size of the packet), the switch drops the packet. Each queue has three threshold values. The internal DSCP determines which of the three threshold values is subjected to the frame. Of the three thresholds, two are configurable (explicit) and one is not (implicit), as this last threshold corresponds to the tail of the queue (100% limit).
Packets are mapped to queues and thresholds on the Catalyst 3750-E by either CoS-to-queue/threshold or DSCP-to-queue/threshold mappings. The mapping used directly corresponds to whether the packet was configured to trust CoS on ingress or to trust DSCP on ingress (untrusted packets are simply assigned to the default queue).
Ingress Queuing 1P1Q3T Model
As the Catalyst 3750-E switch platforms have architectures based on oversubscription, they have been engineered to guarantee QoS by protecting critical traffic trying to access the backplane/stack-ring via ingress queuing. Ingress queuing on this platform can be configured as 2Q3T or 1P1Q3T, with the latter being the recommended configuration (as it supports the RFC 3246 EF PHB).
Once 1P1Q3T ingress queuing has been configured, WTD thresholds can be defined on Q1 to provide inter-queue QoS; specifically, Q1T1 can be explicitly set at 80% queue depth and Q1T2 can be explicitly set at 90% queue depth (while Q3 remains implicitly set at 100% queue depth).
With the queues and thresholds set, then VoIP (EF), broadcast video (CS5), and realtime interactive (CS4) traffic can be mapped to the strict priority ingress queue. All other traffic classes can be mapped to the default (non-priority) ingress queue. However, drop preference can be given to control plane traffic, such that network control (CS7) and internetwork control (CS6) traffic is mapped to the highest WTD threshold (Q1T3); additionally, signaling (CS3) traffic can be mapped to the middle WTD threshold (Q1T2). All other flows would be mapped to Q1T1. These 1P1Q3T ingress queuing mappings for the Catalyst 3750-E are shown in Figure 2-16.
Figure 2-16 Catalyst 3750-E 1P1Q3T Ingress Queuing Model
The corresponding configuration for 1P1Q3T ingress queuing on the Catalyst 3750-E is shown in Example 2-20.
Example 2-20 1P1Q3T Ingress Queuing Configuration Example on a Catalyst 3750-E
! This section configures the ingress queuesC3750-E(config)#mls qos srr-queue input priority-queue 2 bandwidth 30! Q2 is enabled as a strict-priority ingress queue with 30% BWC3750-E(config)#mls qos srr-queue input bandwidth 70 30! Q1 is assigned 70% BW via SRR shared weights! Q1 SRR shared weight is ignored (as it has been configured as a PQ)C3750-E(config)#mls qos srr-queue input threshold 1 80 90! Q1 thresholds are configured at 80% (Q1T1) and 90% (Q1T2)! Q1T3 is implicitly set at 100% (the tail of the queue)! Q2 thresholds are all set (by default) to 100% (the tail of Q2)! This section configures ingress CoS-to-Queue mappings (if required)C3750-E(config)#mls qos srr-queue input cos-map queue 1 threshold 1 0 1 2! CoS values 0, 1 and 2 are mapped to Q1T1C3750-E(config)#mls qos srr-queue input cos-map queue 1 threshold 2 3! CoS value 3 is mapped to ingress Q1T2C3750-E(config)#mls qos srr-queue input cos-map queue 1 threshold 3 6 7! CoS values 6 and 7 are mapped to ingress Q1T3C3750-E(config)#mls qos srr-queue input cos-map queue 2 threshold 1 4 5! CoS values 4 and 5 are mapped to ingress Q2 (the PQ)! This section configures ingress DSCP-to-Queue MappingsC3750-E(config)# mls qos srr-queue input dscp-map queue 1 threshold 1 0 8 10 12 14! DSCP DF, CS1 and AF1 are mapped to ingress Q1T1C3750-E(config)# mls qos srr-queue input dscp-map queue 1 threshold 1 16 18 20 22! DSCP CS2 and AF2 are mapped to ingress Q1T1C3750-E(config)# mls qos srr-queue input dscp-map queue 1 threshold 1 26 28 30 34 36 38! DSCP AF3 and AF4 are mapped to ingress Q1T1C3750-E(config)#mls qos srr-queue input dscp-map queue 1 threshold 2 24! DSCP CS3 is mapped to ingress Q1T2C3750-E(config)#mls qos srr-queue input dscp-map queue 1 threshold 3 48 56! DSCP CS6 and CS7 are mapped to ingress Q1T3 (the tail of Q1)C3750-E(config)#mls qos srr-queue input dscp-map queue 2 threshold 3 32 40 46! DSCP CS4, CS5 and EF are mapped to ingress Q2T3 (the tail of the PQ)
Note
Note
This configuration can be verified with the following commands:
•
•
•
Example 2-21 Verifying Ingress Queuing on a Catalyst 3750-E—show mls qos input-queue
C3750-E#show mls qos input-queueQueue : 1 2------------------------------------------buffers : 90 10bandwidth : 70 30priority : 0 30threshold1: 80 100threshold2: 90 100C3750-E#Example 2-21 shows that ingress queuing buffers and bandwidth have been allocated between Q1 and Q2 by a 70:30 split, respectively. Also, that Q2 has been enabled as a strict-priority queue with a 30% maximum bandwidth guarantee. Q1T1 and Q1T2 thresholds have been set to 80% and 90%, but all Q2 thresholds are at 100%.
Example 2-22 Verifying Ingress Queue Mapping on a Catalyst 3750-E—show mls qos maps cos-input-q
C3750-E#show mls qos maps cos-input-qCos-inputq-threshold map:cos: 0 1 2 3 4 5 6 7------------------------------------queue-threshold: 1-1 1-1 1-1 1-2 2-3 2-3 1-3 1-3C3750-E#Example 2-22 shows the ingress CoS-to-queue mappings. Specifically, CoS values 1 and 2 have been mapped to Q1T1, CoS 3 has been mapped to Q1T2, CoS values 4 and 5 have been mapped to Q2T1 (the PQ), and CoS values 6 and 7 have been mapped to Q1T3.
Example 2-23 Example 2-22 Verifying Ingress Queue Mapping on a Catalyst 3750-E—show mls qos maps dscp-input-q
C3750-E#show mls qos maps dscp-input-qDscp-inputq-threshold map:d1 :d2 0 1 2 3 4 5 6 7 8 9------------------------------------------------------------0 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-011 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-012 : 01-01 01-01 01-01 01-01 01-02 01-01 01-01 01-01 01-01 01-013 : 01-01 01-01 02-03 01-01 01-01 01-01 01-01 01-01 01-01 01-014 : 02-03 02-01 02-01 02-01 02-01 02-01 02-03 02-01 01-03 01-015 : 01-01 01-01 01-01 01-01 01-01 01-01 01-03 01-01 01-01 01-016 : 01-01 01-01 01-01 01-01C3750-E#Example 2-23 shows the ingress DSCP-to-queue mappings. The first digit of the DSCP value of a packet is shown along the Y-axis of the table; the second digit of the DSCP value of a packet is shown along the X-axis of the table. The mapping table corresponds to Figure 2-16. It can be noted that CS4 (DSCP 32), CS5 (DSCP 40), and EF (DSCP 46) are all mapped to Q2 (the PQ). It should also be noted that internal DSCP values 40 through 47 are mapped to Q2 by default, which is why the table shows additional values being mapped to this queue.
Egress Queuing 1P3Q3T Model
Egress queuing on the Catalyst 3750-E family of switches can be configured as 4Q3T or 1P3Q3T, with the latter being the recommended configuration (as it supports the RFC 3246 EF PHB).
Two different egress queuing sets can be configured on the Catalyst 3750-E; however, to maintain consistent per-hop behaviors, it is generally recommended to use only one.
Once the primary queuing set has been configured for 1P3Q3T egress queuing, WTD thresholds can be defined on Q2 and Q4 to provide intra-queue QoS. Specifically, Q2T1 can be explicitly set at 80% queue depth and Q2T2 can be explicitly set at 90% queue depth (while Q3 remains implicitly set at 100% queue depth). Also, Q4T1 can be explicitly set at 60% queue depth, while the other thresholds for Q4 remain at their default values (of 100% queue depth).
With the queues and thresholds set, then VoIP (EF), broadcast video (CS5), and realtime interactive (CS4) traffic can be mapped to the strict priority egress queue (Q1). Network management (CS2), transactional data (AF2), multimedia streaming (AF3), and multimedia conferencing (AF4) traffic can be mapped to Q2T1. Signaling (CS3) traffic can be mapped to Q2T2. Network (CS7) and internetwork (CS6) traffic can be mapped to Q2T3. Default (DF) traffic can be mapped to Q3, the default queue. Scavenger (CS1) traffic can be mapped to Q4T1, while bulk data (AF1) is mapped to Q4T2. These 1P3Q3T egress queuing mappings for the Catalyst 3750-E are shown in Figure 2-17.
Figure 2-17 Catalyst 3750-E 1P3Q3T Egress Queuing Model
The corresponding configuration for 1P3Q3T egress queuing on the Catalyst 3750-E is shown in Example 2-24.
Example 2-24 1P3Q3T Egress Queuing Configuration Example on a Catalyst 3750-E
! This section configures explicit WTD thresholds on Q2 and Q4C3750-E(config)#mls qos queue-set output 1 threshold 2 80 90 100 100! Q2T1 is set to 80%; Q2T2 is set to 90%C3750-E(config)#mls qos queue-set output 1 threshold 4 60 100 100 100! Q4T1 is set to 60%; all other thresholds for Q4 remain at 100%! This section configures egress CoS-to-Queue mappings (if required)C3750-E(config)#mls qos srr-queue output cos-map queue 1 threshold 3 4 5! CoS 4 and 5 are mapped to egress Q1T3 (the tail of the PQ)C3750-E(config)#mls qos srr-queue output cos-map queue 2 threshold 1 2! CoS 2 is mapped to egress Q2T1C3750-E(config)#mls qos srr-queue output cos-map queue 2 threshold 2 3! CoS 3 is mapped to egress Q2T2C3750-E(config)#mls qos srr-queue output cos-map queue 2 threshold 3 6 7! CoS 6 and 7 are mapped to Q2T3C3750-E(config)#mls qos srr-queue output cos-map queue 3 threshold 3 0! CoS 0 is mapped to Q3T3 (the tail of the default queue)C3750-E(config)#mls qos srr-queue output cos-map queue 4 threshold 3 1! CoS 1 is mapped to Q4T3 (tail of the less-than-best-effort queue)! This section configures egress DSCP-to-Queue mappingsC3750-E(config)# mls qos srr-queue output dscp-map queue 1 threshold 3 32 40 46! DSCP CS4, CS5 and EF are mapped to egress Q1T3 (tail of the PQ)C3750-E(config)# mls qos srr-queue output dscp-map queue 2 threshold 1 16 18 20 22! DSCP CS2 and AF2 are mapped to egress Q2T1C3750-E(config)# mls qos srr-queue output dscp-map queue 2 threshold 1 26 28 30 34 36 38! DSCP AF3 and AF4 are mapped to egress Q2T1C3750-E(config)#mls qos srr-queue output dscp-map queue 2 threshold 2 24! DSCP CS3 is mapped to egress Q2T2C3750-E(config)#mls qos srr-queue output dscp-map queue 2 threshold 3 48 56! DSCP CS6 and CS7 are mapped to egress Q2T3C3750-E(config)#mls qos srr-queue output dscp-map queue 3 threshold 3 0! DSCP DF is mapped to egress Q3T3 (tail of the best effort queue)C3750-E(config)#mls qos srr-queue output dscp-map queue 4 threshold 1 8! DSCP CS1 is mapped to egress Q4T1C3750-E(config)# mls qos srr-queue output dscp-map queue 4 threshold 2 10 12 14! DSCP AF1 is mapped to Q4T2 (tail of the less-than-best-effort queue)! This section configures interface egress queuing parametersC3750-E(config)#interface range GigabitEthernet1/0/1-48C3750-E(config-if-range)# queue-set 1! The interface(s) is assigned to queue-set 1C3750-E(config-if-range)# srr-queue bandwidth share 1 30 35 5! The SRR sharing weights are set to allocate 30% BW to Q2! 35% BW to Q3 and 5% BW to Q4! Q1 SRR sharing weight is ignored, as it will be configured as a PQC3750-E(config-if-range)# priority-queue out! Q1 is enabled as a strict priority queue
Note
This configuration can be verified with the following commands:
•
•
•
•
Example 2-25 Verifying Egress Queuing on a Catalyst 3750-E—show mls qos interface interface x/y queueing
C3750-E#show mls qos interface GigabitEthernet 1/0/1 queueingGigabitEthernet1/0/1Egress Priority Queue : enabledShaped queue weights (absolute) : 25 0 0 0Shared queue weights : 1 30 35 5The port bandwidth limit : 100 (Operational Bandwidth:100.0)The port is mapped to qset : 1C3750-E#Example 2-25 shows that strict-priority queueing has been enabled on the interface, and that the queues Q2, Q3, and Q4 receive 30%, 35% and 5% of the remaining bandwidth, respectively.
Example 2-26 Verifying Egress Queuing on a Catalyst 3750-E—show mls qos interface interface x/y statistics
C3750-E#show mls qos interface GigabitEthernet 1/0/49 statisticsGigabitEthernet1/0/49 (All statistics are in packets)dscp: incoming-------------------------------0 - 4 : 1729 0 0 0 05 - 9 : 0 0 0 0 010 - 14 : 0 0 0 0 015 - 19 : 0 0 0 0 020 - 24 : 0 0 0 0 025 - 29 : 0 0 0 0 030 - 34 : 0 0 0 0 035 - 39 : 0 0 0 0 040 - 44 : 0 0 0 0 045 - 49 : 0 127292 0 1263 050 - 54 : 0 0 0 0 055 - 59 : 0 0 0 0 060 - 64 : 0 0 0 0dscp: outgoing-------------------------------0 - 4 : 947678 0 0 0 05 - 9 : 0 0 0 23842155 010 - 14 : 1190043 0 0 0 015 - 19 : 0 0 0 1061726 020 - 24 : 0 0 0 0 1037225 - 29 : 0 0 0 0 030 - 34 : 0 0 0 0 832062335 - 39 : 0 0 0 0 040 - 44 : 0 0 0 0 045 - 49 : 0 127291 0 784 050 - 54 : 0 0 0 0 055 - 59 : 0 0 0 0 060 - 64 : 0 0 0 0cos: incoming-------------------------------0 - 4 : 130653 0 0 998 05 - 7 : 127599 613 3156cos: outgoing-------------------------------0 - 4 : 947754 25032199 1061726 10372 83206235 - 7 : 127291 784 3462output queues enqueued:queue: threshold1 threshold2 threshold3-----------------------------------------queue 0: 0 0 127291queue 1: 9382416 10396 4246queue 2: 0 0 947611queue 3: 23842152 1190043 0output queues dropped:queue: threshold1 threshold2 threshold3-----------------------------------------queue 0: 0 0 0queue 1: 0 0 0queue 2: 0 0 0queue 3: 892 0 0Policer: Inprofile: 0 OutofProfile: 0C3750-E#Example 2-26 shows a set of dynamically-updated packet statistic tables for an uplink port on an access layer Catalyst 3750-E switch that is primarily congested in the access-to-distribution direction. The first table shows the incoming DSCP values (from the distribution layer). DSCP values are broken into groups of 4. For example, incoming packets marked DSCP EF/46 are listed in the DSCP 45-49 row in the second column (in this case: 127,292 packets). The second table shows the outgoing packets (to the distribution layer) in a similar format. For example, DSCP CS1/8 is listed in the DSCP 5-9 row in the third column (23,842,155 packets). The third table shows incoming packets (from the distribution layer) by CoS values (again grouped in sets of 4); similarly the fourth table shows outgoing packets (to the distribution layer) by CoS values. The fifth and sixth tables are particularly interesting in terms of queuing statistics: the fifth table shows the number of packets assigned to each queue/threshold combination.
Note
For example, from the fifth table, it can be seen that 127,291 packets were sent to the (tail of the) PQ (shown here as Q0); similarly, 23,842,155 packets were sent to the scavenger/bulk queue first threshold (shown here as Q3T1). Finally, the sixth table shows any drops that have occurred on a per-queue/per-threshold basis; from this table it can be seen that 892 drops occurred in the scavenger/bulk queue first threshold (scavenger class drops).
EtherChannel QoS Model
As discussed in EtherChannel QoS, policies on EtherChannel interfaces have to be split between the ingress policies (which are applied to the PortChannel interface) and the egress-queuing policies (which are applied to the physical ports comprising the EtherChannel). Also, it is recommended to load-balance across the EtherChannel by source-and-destination IP address. An example of an EtherChannel QoS Model for the Catalyst 3750-E family is shown in Example 2-27.
Note
Example 2-27 EtherChannel QoS Design on a Catalyst 3750-E.
! This section configures source-and-destination load-balancing! across the EtherChannelC3750-E(config)# port-channel load-balance src-dst-ip! This section configures ingress QoS policies (in this case: DSCP-trust)! on the (logical) EtherChannel interfaceC3750-E(config)# interface Port-channel1C3750-E(configs-if)# no switchportC3750-E(configs-if)# ip address 10.10.10.1 255.255.255.252C3750-E(configs-if)# mls qos trust dscp! The interface is set to statically trust DSCP! This section configures (1P3Q3T) Egress Queuing across the! (physical) EtherChannel member portsC3750-E(config)#interface range GigabitEthernet1/0/49-50C3750-E(config-if-range)# channel-group 1 mode auto! Associates the physical ports with the logical EtherChannel bundleC3750-E(config-if-range)# queue-set 1! The interfaces are assigned to queue-set 1C3750-E(config-if-range)# srr-queue bandwidth share 1 30 35 5! The SRR sharing weights are set to allocate 30% BW to Q2! 35% BW to Q3 and 5% BW to Q4! Q1 SRR sharing weight is ignored, as it will be configured as a PQC3750-E(config-if-range)# priority-queue out! Q1 is enabled as a strict priority queueThis configuration can be verified with the following commands:
•
•
•
•
•
•
•
•
Cisco Catalyst 4500/4900 and 4500-E/4900M QoS Design
The Catalyst 4500 family of switches provides Layer 2 through Layer 4 network services, including advanced high availability, security, and QoS services in addition to integrated PoE to support unified communications. The Catalyst 4500 and 4900 share common features and syntax and as such are grouped together and discussed as a single switch family, namely the Catalyst 4500 (which may also be designated as ,Classic Supervisors,). Similarly, the Catalyst 4500-E and 4900M share common features and syntax and as such are also grouped together and discussed as a single switch family, namely the Catalyst 4500-E (which may also be designated as Supervisor 6-E).
Catalyst 4500/4500-E switches come in various chassis, supervisor, and linecard combinations, as are discussed in turn.
The Catalyst 4500 switch family offers chassis that support 3, 6, 7, and 10 slots; these models include the Catalyst 4503, 4506, 4507R, and 4510R, respectively (the latter two models supporting a redundant supervisor option). Catalyst 4500 chassis provide 6 Gbps of bandwidth per linecard slot.
Similarly, the Catalyst 4500-E switch family offers chassis that support 3, 6, 7, and 10 slots; these models include the Catalyst 4503-E, 4506-E, 4507R-E, and 4510R-E, respectively (the latter two models supporting a redundant supervisor option). Catalyst 4500 chassis provide 24 Gbps of bandwidth per linecard slot (or 6 Gbps of bandwidth per non "E-series" linecards).
Multiple supervisor options exist for the Catalyst 4500/4500-E family of switches, including:
•
•
•
•
•
•
•
All of the supervisors above—with the exception of the Supervisor 6-E—are referred to as Classic Supervisors. There is a major difference between QoS functionality and syntax on the Catalyst 4500 Classic Supervisors, as compared to the Supervisor 6-E (which is discussed further in the following section).
The Catalyst 4500/4500-E linecards that meet the minimum requirements for medianet switch ports (including Gigabit Ethernet support, as well as supporting a strict priority hardware queue with at least three additional hardware queues), at the time of writing, are listed in Table 2-3.
Platform-Specific QoS Considerations
As mentioned, there is a significant difference in how QoS is implemented on the Catalyst 4500 Classic Supervisor family versus the Catalyst 4500-E Supervisor 6-E family; the former implements a switch-specific QoS (called the switch QoS model), while the latter implements Cisco IOS MQC (called the MQC model) on the switch.
The Catalyst 4500 Classic Supervisor switch QoS model is shown in Figure 2-18.
Figure 2-18 Catalyst 4500 (Classic Supervisor) Switch QoS Model
Traffic is classified on ingress, based on trust states, access lists, or class maps. Policers can be applied to flows, on either a per-port basis or a per-VLAN basis or even a per-port/per-VLAN basis. Similarly, marking policies can be applied on the same basis. Egress queuing is based on a 4Q1T or a 1P3Q1T model (the latter being preferred, as it supports the EF PHB), with a platform-specific proprietary congestion avoidance mechanism providing Active Queue Management (AQM), namely Dynamic Buffer Limiting (DBL). DBL tracks the queue length for each traffic flow in the switch. When the queue length of a flow exceeds its limit, DBL drop packets or sets the Explicit Congestion Notification (ECN) bits in the packet headers.
Catalyst 4500 Classic Supervisor syntax is essentially equivalent to the QoS syntax on other Catalyst platforms, with the exception that the mls command prefix is omitted on this platform. Thus mls qos is abbreviated to simply qos on the Catalyst 4500 Classic Supervisors.
In contrast, the Catalyst 4500 Series Switch using Supervisor Engine 6-E employs the MQC QoS model. In this model, QoS is applied via Modular QoS Command-Line Interface (MQC). As such, certain QoS features are implemented differently (and others are not supported; the following sections detail the differences). The Catalyst 4500 Supervisor 6-E MQC QoS model is shown in Figure 2-19.
Figure 2-19 Catalyst 4500-E (Supervisor 6-E) MQC Model
In the MQC packet, QoS policies are applied as follows:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Enabling QoS (Classic Supervisors)
Note
QoS must be enabled globally on the Catalyst 4500 Classic Supervisors. This is a critical first step to deploying QoS on these platforms. If this small, but important, step is overlooked, it can lead to frustration in troubleshooting QoS problems because the switch software accepts QoS commands and even displays these within the switch configuration, but none of the QoS commands are active until the qos global command is enabled, as shown in Example 2-28.
Example 2-28 Enabling QoS on a Catalyst 4500 Classic Supervisor
C4500-CS(config)#qosC4500-CS(config)#This configuration can be verified with the following command:
•
Example 2-29 Verifying Global QoS on a Catalyst 4500 Classic Supervisor—show qos
C4500-CS#show qosQoS is enabled globallyIP header DSCP rewrite is enabledC4500-CS#Trust Models
Catalyst 4500 Classic Supervisor switch ports can be configured to statically trust CoS, DSCP, or to dynamically and conditionally trust Cisco IP phones. By default, with QoS enabled, all ports are set to an untrusted state.
In contrast, the Catalyst 4500-E Supervisor 6-E does not support trust CoS, as it considers all interfaces to be trusted (via DSCP-trust) by default; it does, however, support conditional trust.
Trust-CoS Model
A Catalyst 4500 Classic Supervisor switch port can be configured to trust CoS by configuring the interface with the qos trust cos command. However, if an interface is set to trust CoS, then it by default calculates a packet's internal DSCP to be the incoming packet's (CoS value * 8). While this may suitable for most markings, this default mapping may not be suitable for VoIP, as VoIP is usually marked CoS 5, which would map by default to DSCP 40 (and not 46, which is the EF PHB as defined by RFC 3246). Therefore, if an interface is set to trust CoS, then the default CoS-to-DSCP mapping table should be modified such that CoS 5 maps to DSCP 46, as shown in Example 2-30.
Note
Example 2-30 Configuring Trust CoS and CoS-to-DSCP Mapping Modification on a Catalyst 4500 Classic Supervisor
C4500-CS(config)#qos map cos 5 to dscp 46! CoS 5 is mapped to DSCP 46 (EF)C4500-CS(config)#interface GigabitEthernet 1/1C4500-CS(config-if)#qos trust cos! The interface is set to statically trust CoSThis configuration can be verified with the following commands:
•
•
Example 2-31 Verifying Global CoS-to-DSCP Mapping Modifications on a Catalyst 4500 Classic Supervisor—show qos map cos-dscp
C4500-CS#show qos map cos-dscpCoS-DSCP Mapping TableCoS: 0 1 2 3 4 5 6 7--------------------------------DSCP: 0 8 16 24 32 46 48 56C4500-CS#In Example 2-31, the CoS-to-DSCP mapping value for CoS 5 has been modified from the default mapping of 40 (CoS 5 * 8) to 46 (to match the recommendation from RFC 3246 that realtime applications be marked DSCP 46/EF).
Example 2-32 Verifying Interface Trust Settings on a Catalyst 4500—show qos interface
C4500-CS#show qos interface GigabitEthernet 1/1QoS is enabled globallyPort QoS is enabledAdministrative Port Trust State: 'cos'Operational Port Trust State: 'cos'Trust device: noneDefault DSCP: 0 Default CoS: 0Appliance trust: noneTx-Queue Bandwidth ShapeRate Priority QueueSize(bps) (bps) (packets)1 250000000 disabled N/A 19202 250000000 disabled N/A 19203 250000000 disabled normal 19204 250000000 disabled N/A 1920C4500-CS#In Example 2-32, the administrative port trust state is set to trust-cos and the current operation port trust state is also at trust-cos.
Trust-DSCP Model
Because of the additional granularity of DSCP versus QoS markings, it is generally recommended to trust DSCP rather than CoS (everything else being equal). A Catalyst 4500 Classic Supervisor switch port can be configured to trust DSCP with the qos trust dscp interface command, as shown in Example 2-33.
Note
Example 2-33 Configuring Trust-DSCP on a Catalyst 4500 Classic Supervisor
C4500-CS(config)#interface GigabitEthernet 1/1C4500-CS(config-if)#qos trust dscp! The interface is set to statically trust DSCPThis configuration can be verified with the following commands:
•
Conditional Trust Model
In addition to configuring switch ports to statically trust endpoints, the Catalyst 4500 Classic Supervisor and the Catalyst 4500-E Supervisor 6-E support dynamic, conditional trust with the qos trust device interface command, which can be configured with the cisco-phone keyword to extend trust to Cisco IP phones, after these have been verified via a CDP-negotiation. Additionally, the type of trust to be extended can be specified (either CoS or DSCP) on the Catalyst 4500 Classic Supervisor. In general, it is recommended to dynamically extend DSCP-trust (over CoS-trust), because DSCP has greater marking granularity. An example of a dynamic, conditional trust policy that is set to extend DSCP-trust to CDP-verified Cisco IP phones is shown in Example 2-34.
Example 2-34 Configuring Conditional (DSCP-mode) Trust on a Catalyst 4500 Classic Supervisor
C4500-CS(config)#interface GigabitEthernet 1/1C4500-CS(config-if)# switchport access vlan 10C4500-CS(config-if)# switchport voice vlan 110C4500-CS(config-if)# spanning-tree portfastC4500-CS(config-if)# qos trust device cisco-phone! The interface is set to conditionally-trust Cisco IP PhonesC4500-CS(config-if)# qos trust dscp! DSCP-trust will be dynamically extended to Cisco IP Phones
Note
This configuration can be verified with the following command:
•
Example 2-35 Verifying Interface Trust Settings on a Catalyst 4500—show qos interface
C4500-CS#show qos interface GigabitEthernet 1/1QoS is enabled globallyPort QoS is enabledAdministrative Port Trust State: 'dscp'Operational Port Trust State: 'dscp'Trust device: cisco-phoneDefault DSCP: 0 Default CoS: 0Appliance trust: noneTx-Queue Bandwidth ShapeRate Priority QueueSize(bps) (bps) (packets)1 250000000 disabled N/A 19202 250000000 disabled N/A 19203 250000000 disabled normal 19204 250000000 disabled N/A 1920C4500-CS#In Example 2-35, the trust device feature has been enabled, with the trusted device being specified as a cisco-phone. The administrative port trust state—that is, the mode of trust (CoS or DSCP) that is extended dynamically to the IP Phone—is set to trust DSCP. Similarly, the current (dynamic) operational port trust state is shown as trusting DSCP. This is because there is a Cisco IP phone currently connected to the switch port; if the IP phone is removed from this switch port, the operational port trust state toggles to "untrusted".
Marking Models
The Catalyst 4500 family of switches supports two main marking models:
•
•
Each model is detailed in the following sections.
Per-Port Marking Model
The per-port marking model (based on Figure 2-10) matches VoIP and signaling traffic from the VVLAN by matching on DSCP EF and CS3, respectively. Multimedia conferencing traffic from the DVLAN is matched by UDP/RTP ports 16384-32767. Signaling traffic is matched on SCCP ports (TCP 2000-2002), as well as on SIP ports (TCP/UDP 5060-5061). Other transactional data traffic, bulk data, and scavenger traffic are matched on various ports (outlined in Figure 2-9). Unlike the Catalyst 3750-E examples, no explicit default class is required, as the implicit class default performs policy actions (such as marking or policing) on the Catalyst 4500. The service policy is applied to an interface range, along with (DSCP-mode) conditional trust, as shown in Example 2-36.
Example 2-36 Per-Port Marking Configuration Example on a Catalyst 4500 Classic Supervisor or a Catalyst 4500-E Supervisor 6-E
! This first section configures IP access-lists to match applicationsC4500-CS(config)#ip access-list extended MULTIMEDIA-CONFERENCINGC4500-CS(config-ext-nacl)# remark RTPC4500-CS(config-ext-nacl)# permit udp any any range 16384 32767C4500-CS(config)#ip access-list extended SIGNALINGC4500-CS(config-ext-nacl)# remark SCCPC4500-CS(config-ext-nacl)# permit tcp any any range 2000 2002C4500-CS(config-ext-nacl)# remark SIPC4500-CS(config-ext-nacl)# permit tcp any any range 5060 5061C4500-CS(config-ext-nacl)# permit udp any any range 5060 5061C4500-CS(config)#ip access-list extended TRANSACTIONAL-DATAC4500-CS(config-ext-nacl)# remark HTTPSC4500-CS(config-ext-nacl)# permit tcp any any eq 443C4500-CS(config-ext-nacl)# remark ORACLE-SQL*NETC4500-CS(config-ext-nacl)# permit tcp any any eq 1521C4500-CS(config-ext-nacl)# permit udp any any eq 1521C4500-CS(config-ext-nacl)# remark ORACLEC4500-CS(config-ext-nacl)# permit tcp any any eq 1526C4500-CS(config-ext-nacl)# permit udp any any eq 1526C4500-CS(config-ext-nacl)# permit tcp any any eq 1575C4500-CS(config-ext-nacl)# permit udp any any eq 1575C4500-CS(config-ext-nacl)# permit tcp any any eq 1630C4500-CS(config-ext-nacl)# permit udp any any eq 1526C4500-CS(config)#ip access-list extended BULK-DATAC4500-CS(config-ext-nacl)# remark FTPC4500-CS(config-ext-nacl)# permit tcp any any eq ftpC4500-CS(config-ext-nacl)# permit tcp any any eq ftp-dataC4500-CS(config-ext-nacl)# remark SSH/SFTPC4500-CS(config-ext-nacl)# permit tcp any any eq 22C4500-CS(config-ext-nacl)# remark SMTP/SECURE SMTPC4500-CS(config-ext-nacl)# permit tcp any any eq smtpC4500-CS(config-ext-nacl)# permit tcp any any eq 465C4500-CS(config-ext-nacl)# remark IMAP/SECURE IMAPC4500-CS(config-ext-nacl)# permit tcp any any eq 143C4500-CS(config-ext-nacl)# permit tcp any any eq 993C4500-CS(config-ext-nacl)# remark POP3/SECURE POP3C4500-CS(config-ext-nacl)# permit tcp any any eq pop3C4500-CS(config-ext-nacl)# permit tcp any any eq 995C4500-CS(config-ext-nacl)# remark CONNECTED PC BACKUPC4500-CS(config-ext-nacl)# permit tcp any eq 1914 anyC4500-CS(config)#ip access-list extended SCAVENGERC4500-CS(config-ext-nacl)# remark KAZAAC4500-CS(config-ext-nacl)# permit tcp any any eq 1214C4500-CS(config-ext-nacl)# permit udp any any eq 1214C4500-CS(config-ext-nacl)# remark MICROSOFT DIRECT X GAMINGC4500-CS(config-ext-nacl)# permit tcp any any range 2300 2400C4500-CS(config-ext-nacl)# permit udp any any range 2300 2400C4500-CS(config-ext-nacl)# remark APPLE ITUNES MUSIC SHARINGC4500-CS(config-ext-nacl)# permit tcp any any eq 3689C4500-CS(config-ext-nacl)# permit udp any any eq 3689C4500-CS(config-ext-nacl)# remark BITTORRENTC4500-CS(config-ext-nacl)# permit tcp any any range 6881 6999C4500-CS(config-ext-nacl)# remark YAHOO GAMESC4500-CS(config-ext-nacl)# permit tcp any any eq 11999C4500-CS(config-ext-nacl)# remark MSN GAMING ZONEC4500-CS(config-ext-nacl)# permit tcp any any range 28800 29100! This section configures the class-mapsC4500-CS(config-cmap)#class-map match-all VVLAN-VOIPC4500-CS(config-cmap)# match ip dscp ef! VoIP is trusted (from the VVLAN)C4500-CS(config-cmap)#class-map match-all VVLAN-SIGNALINGC4500-CS(config-cmap)# match ip dscp cs3! Signaling is trusted (from the VVLAN)C4500-CS(config-cmap)#class-map match-all MULTIMEDIA-CONFERENCINGC4500-CS(config-cmap)# match access-group name MULTIMEDIA-CONFERENCING! Associates MULTIMEDIA-CONFERENCING access-list with class-mapC4500-CS(config-cmap)#class-map match-all SIGNALINGC4500-CS(config-cmap)# match access-group name SIGNALING! Associates SIGNALING access-list with class-mapC4500-CS(config-cmap)#class-map match-all TRANSACTIONAL-DATAC4500-CS(config-cmap)# match access-group name TRANSACTIONAL-DATA! Associates TRANSACTIONAL-DATA access-list with class-mapC4500-CS(config-cmap)#class-map match-all BULK-DATAC4500-CS(config-cmap)# match access-group name BULK-DATA! Associates BULK-DATA access-list with class-mapC4500-CS(config-cmap)#class-map match-all SCAVENGERC4500-CS(config-cmap)# match access-group name SCAVENGER! Associates SCAVENGER access-list with class-map! This section configures the Per-Port ingress marking policy-mapC4500-CS(config)#policy-map PER-PORT-MARKINGC4500-CS(config-pmap)# class VVLAN-VOIPC4500-CS(config-pmap-c)# set dscp ef! VoIP is marked EFC4500-CS(config-pmap-c)# class VVLAN-SIGNALINGC4500-CS(config-pmap-c)# set dscp cs3! Signaling (from the VVLAN) is marked CS3C4500-CS(config-pmap-c)# class MULTIMEDIA-CONFERENCINGC4500-CS(config-pmap-c)# set dscp af41! Multimedia-conferencing is marked AF41C4500-CS(config-pmap-c)# class SIGNALINGC4500-CS(config-pmap-c)# set dscp cs3! Signaling (from the DVLAN) is marked CS3C4500-CS(config-pmap-c)# class TRANSACTIONAL-DATAC4500-CS(config-pmap-c)# set dscp af21! Transactional Data is marked AF21C4500-CS(config-pmap-c)# class BULK-DATAC4500-CS(config-pmap-c)# set dscp af11! Bulk Data is marked AF11C4500-CS(config-pmap-c)# class SCAVENGERC4500-CS(config-pmap-c)# set dscp cs1! Scavenger traffic is marked CS1C4500-CS(config-pmap-c)# class class-defaultC4500-CS(config-pmap-c)# set dscp default! An implicit class-default marks all other traffic to DF! This section attaches the service-policy to the interface(s)C4500-CS(config)#interface range GigabitEthernet 2/1-48C4500-CS(config-if-range)# switchport access vlan 10C4500-CS(config-if-range)# switchport voice vlan 110C4500-CS(config-if-range)# spanning-tree portfastC4500-CS(config-if-range)# qos trust device cisco-phone! The interface is set to conditionally-trust Cisco IP PhonesC4500-CS(config-if-range)# qos trust dscp! DSCP-trust will be dynamically extended to Cisco IP PhonesC4500-CS(config-if-range)# service-policy input INGRESS-MARKING! Attaches the Per-Port Marking policy to the interface(s)
Note
Note
This configuration can be verified with the following commands:
•
•
•
•
Example 2-37 Verifying Service Policies on a Catalyst 4500—show policy-map interface
C4500-CS#show policy-map interface GigabitEthernet 2/1GigabitEthernet2/1Service-policy input: PER-PORT-MARKINGClass-map: VVLAN-VOIP (match-all)65211 packetsMatch: ip dscp ef (46)QoS Setip dscp efClass-map: VVLAN-SIGNALING (match-all)731 packetsMatch: ip dscp cs3 (24)QoS Setip dscp cs3Class-map: MULTIMEDIA-CONFERENCING (match-all)16290 packetsMatch: access-group name MULTIMEDIA-CONFERENCINGQoS Setip dscp af41Class-map: SIGNALING (match-all)130 packetsMatch: access-group name SIGNALINGQoS Setip dscp cs3Class-map: TRANSACTIONAL-DATA (match-all)13211 packetsMatch: access-group name TRANSACTIONAL-DATAQoS Setip dscp af21Class-map: BULK-DATA (match-all)16518 packetsMatch: access-group name BULK-DATAQoS Setip dscp af11Class-map: SCAVENGER (match-all)14238 packetsMatch: access-group name SCAVENGERQoS Setip dscp cs1Class-map: class-default (match-any)25881 packetsMatch: any25881 packetsQoS Setip dscp defaultC4500-CS#Example 2-37 shows that the show policy-map interface command on the Catalyst 4500 Classic Supervisors dynamically increments counters. However, it should be noted that these are slightly delayed and seem to increment only every 10-15 seconds.
Per-VLAN Marking Model (Classic Supervisors)
An alternative approach for deploying marking policies on the Catalyst 4500 Classic Supervisor platforms is to deploy these on a per-VLAN basis. In order to do so, the interfaces belonging to the VLANs need to be configured with the qos vlan-based interface command. Additionally, the policy map can be simplified/broken-apart, as applicable to each VLAN. Adapting the per-port marking example to a VLAN-based marking policing allows for the VVLAN-based policy map to be reduced to only two explicit classes, VoIP and signaling. Similarly, the DVLAN-based policy map is reduced to five explicit classes, multimedia conferencing, signaling, transactional data, bulk data, and scavenger. Both policy maps still retain an implicit default class for all other flows. A per-VLAN marking model is shown in Example 2-38.
Note
Example 2-38 Per-VLAN Marking Configuration Example on a Catalyst 4500 Classic Supervisor
! This section configures the ingress marking policy-map for the VVLANC4500-CS(config)#policy-map VVLAN-MARKINGC4500-CS(config-pmap)# class VVLAN-VOIPC4500-CS(config-pmap-c)# set dscp ef! VoIP is trusted (from the VVLAN)C4500-CS(config-pmap-c)# class VVLAN-SIGNALINGC4500-CS(config-pmap-c)# set dscp cs3! Signaling is trusted (from the VVLAN)C4500-CS(config-pmap-c)# class class-defaultC4500-CS(config-pmap-c)# set dscp default! An implicit class-default marks all other VVLAN traffic to DF! This section configures the ingress marking policy-map for the DVLANC4500-CS(config)#policy-map DVLAN-ARKINGC4500-CS(config-pmap)# class MULTIMEDIA-CONFERENCINGC4500-CS(config-pmap-c)# set dscp af41! Multimedia-conferencing is marked AF41C4500-CS(config-pmap-c)# class SIGNALINGC4500-CS(config-pmap-c)# set dscp cs3! Signaling (from the DVLAN) is marked CS3C4500-CS(config-pmap-c)# class TRANSACTIONAL-DATAC4500-CS(config-pmap-c)# set dscp af21! Transactional Data is marked AF21C4500-CS(config-pmap-c)# class BULK-DATAC4500-CS(config-pmap-c)# set dscp af11! Bulk Data is marked AF11C4500-CS(config-pmap-c)# class SCAVENGERC4500-CS(config-pmap-c)# set dscp cs1! Scavenger traffic is marked CS1C4500-CS(config-pmap-c)# class class-defaultC4500-CS(config-pmap-c)# set dscp default! An implicit class-default marks all other DVLAN traffic to DF! This section configures the interface(s) for conditional trust,! with DSCP-trust and enables VLAN-based QoSC4500-CS(config)#interface range GigabitEthernet 2/1-48C4500-CS(config-if-range)# switchport access vlan 10C4500-CS(config-if-range)# switchport voice vlan 110C4500-CS(config-if-range)# spanning-tree portfastC4500-CS(config-if-range)# qos trust device cisco-phone! The interface is set to conditionally-trust Cisco IP PhonesC4500-CS(config-if-range)# qos trust dscp! DSCP-trust will be dynamically extended to Cisco IP PhonesC4500-CS(config-if-range)# qos vlan-based! Enables VLAN-based QoS on the interface(s)! This section attaches the service-policy to the DVLAN interfaceC4500-CS(config)#interface Vlan 10C4500-CS(config-if)# description DVLANC4500-CS(config-if)# ip route-cache cef! Enables IP CEF on the VLAN interface (required for marking)C4500-CS(config-if)# service-policy input DVLAN-MARKING! Attaches the DVLAN Per-VLAN Marking policy to the DVLAN interface! This section attaches the service-policy to the VVLAN interfaceC4500-CS(config)#interface Vlan 110C4500-CS(config-if)# description VVLANC4500-CS(config-if)# ip route-cache cef! Enables IP CEF on the VLAN interface (required for marking)C4500-CS(config-if)# service-policy input VVLAN-MARKING! Attaches the VVLAN Per-VLAN Marking policy to the VVLAN interfaceThis configuration can be verified with the following commands:
•
•
•
•
Per-VLAN Marking Model (Supervisor 6-E)
The per-VLAN marking model is essentially the same for the Catalyst 4500-E Supervisor 6-E, except for the final set of interface and VLAN commands. The Catalyst 4500-E does not support the qos vlan-based interface command, neither is the qos trust dscp interface command required, and finally, service policies are attached to VLANs via a VLAN-configuration mode (instead of an interface configuration mode), as shown in Example 2-39.
Example 2-39 Per-VLAN Marking Configuration Example on a Catalyst 4500-E Supervisor 6-E
! This section configures the ingress marking policy-map for the VVLANC4500-E(config)#policy-map VVLAN-MARKINGC4500-E(config-pmap)# class VVLAN-VOIPC4500-E(config-pmap-c)# set dscp ef! VoIP is trusted (from the VVLAN)C4500-E(config-pmap-c)# class VVLAN-SIGNALINGC4500-E(config-pmap-c)# set dscp cs3! Signaling is trusted (from the VVLAN)C4500-E(config-pmap-c)# class class-defaultC4500-E(config-pmap-c)# set dscp default! An implicit class-default marks all other VVLAN traffic to DF! This section configures the ingress marking policy-map for the DVLANC4500-E(config)#policy-map DVLAN-MARKINGC4500-E(config-pmap)# class MULTIMEDIA-CONFERENCINGC4500-E(config-pmap-c)# set dscp af41! Multimedia-conferencing is marked AF41C4500-E(config-pmap-c)# class SIGNALINGC4500-E(config-pmap-c)# set dscp cs3! Signaling (from the DVLAN) is marked CS3C4500-E(config-pmap-c)# class TRANSACTIONAL-DATAC4500-E(config-pmap-c)# set dscp af21! Transactional Data is marked AF21C4500-E(config-pmap-c)# class BULK-DATAC4500-E(config-pmap-c)# set dscp af11! Bulk Data is marked AF11C4500-E(config-pmap-c)# class SCAVENGERC4500-E(config-pmap-c)# set dscp cs1! Scavenger traffic is marked CS1C4500-E(config-pmap-c)# class class-defaultC4500-E(config-pmap-c)# set dscp default! An implicit class-default marks all other DVLAN traffic to DF! This section configures the interface(s) for conditional trust,C4500-E(config)#interface range GigabitEthernet 2/1-48C4500-E(config-if-range)# switchport access vlan 10C4500-E(config-if-range)# switchport voice vlan 110C4500-E(config-if-range)# spanning-tree portfastC4500-E(config-if-range)# qos trust device cisco-phone! This section attaches the marking policy to the DVLANC4500-E(config)#vlan config 10C4500-E(config-vlan-config)# service-policy input DVLAN-MARKING! This section attaches the marking policy to the VVLANC4500-E(config)#vlan config 110C4500-E(config-vlan-config)# service-policy input VVLAN-MARKINGThis configuration can be verified with the following commands:
•
•
•
•
Policing Models
The Catalyst 4500 Classic Supervisors support the following policing options:
•
•
–
–
•
In contrast, the Catalyst 4500 Supervisor 6-E supports the following:
•
–
•
–
•
–
•
The Catalyst 4500 family of switches supports the following ingress policing models:
•
•
•
•
The per-port and per-port/per-VLAN policing models and the UBRL models for the Catalyst 4500 family of switches are detailed in the following sections.
Per-Port Policing Model (Classic Supervisors)
The per-port policing model is quite similar to the per-port marking model, except that the policy action includes a policing function—in some cases to drop, in others to remark. As shown in Figure 2-10, the VoIP and signaling traffic from the VVLAN can be policed to drop at 128 kbps and 32 kbps, respectively (as any excessive traffic matching this criteria would be indicative of network abuse). Similarly, the multimedia conferencing, signaling, and scavenger traffic from the DVLAN can be policed to drop. On the other hand, data plane policing policies can be applied to transactional, bulk, and best effort data traffic, such that these flows are subject to being remarked (but not dropped at the ingress edge) when severely out-of-profile. Remarking is performed by configuring a policed-DSCP map with the global configuration command qos map dscp policed, which specifies which DSCP values are subject to remarking if out-of-profile and what value these should be remarked as (which in the case of data plane policing/scavenger class QoS policies, this value is CS1/DSCP 8). A per-port policing for the Catalyst 4500 Classic Supervisor is shown in Example 2-40.
Example 2-40 Per-Port Policing Configuration Example on a Catalyst 4500 Classic Supervisor
! This section configures the global policed-DSCP markdown mapC4500-CS(config)#qos map dscp policed 0 10 18 to dscp 8! DSCP 0 (DF), 10 (AF11) and 18 (AF21) are marked down to 8 (CS1)! if found to be in excess of their (respective) policing rates! This section configures the Per-Port policing policy-mapC4500-CS(config)#policy-map PER-PORT-POLICINGC4500-CS(config-pmap)# class VVLAN-VOIPC4500-CS(config-pmap-c)# set dscp efC4500-CS(config-pmap-c)# police 128k 8000 exceed-action drop! VoIP is marked EF and policed to drop at 128 kbpsC4500-CS(config-pmap-c)# class VVLAN-SIGNALINGC4500-CS(config-pmap-c)# set dscp cs3C4500-CS(config-pmap-c)# police 32k 8000 exceed-action drop! (VVLAN) Signaling is marked CS3 and policed to drop at 32 kbpsC4500-CS(config-pmap-c)# class MULTIMEDIA-CONFERENCINGC4500-CS(config-pmap-c)# set dscp af41C4500-CS(config-pmap-c)# police 5m 8000 exceed-action drop! Multimedia-conferencing is marked AF41 and policed to drop at 5 MbpsC4500-CS(config-pmap-c)# class SIGNALINGC4500-CS(config-pmap-c)# set dscp cs3C4500-CS(config-pmap-c)# police 32k 8000 exceed-action drop! (DVLAN) Signaling is marked CS3 and policed to drop at 32 kbpsC4500-CS(config-pmap-c)# class TRANSACTIONAL-DATAC4500-CS(config-pmap-c)# set dscp af21C4500-CS(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit! Trans-data is marked AF21 and policed to remark (to CS1) at 10 MbpsC4500-CS(config-pmap-c)# class BULK-DATAC4500-CS(config-pmap-c)# set dscp af11C4500-CS(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit! Bulk-data is marked AF11 and policed to remark (to CS1) at 10 MbpsC4500-CS(config-pmap-c)# class SCAVENGERC4500-CS(config-pmap-c)# set dscp cs1C4500-CS(config-pmap-c)# police 10m 8000 exceed-action drop! Scavenger traffic is marked CS1 and policed to drop at 10 MbpsC4500-CS(config-pmap-c)# class class-defaultC4500-CS(config-pmap-c)# set dscp defaultC4500-CS(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit! The implicit default class marks all other traffic to DF! and polices all other traffic to remark (to CS1) at 10 Mbps! This section attaches the service-policy to the interface(s)C4500-CS(config)#interface range GigabitEthernet 2/1-48C4500-CS(config-if-range)# switchport access vlan 10C4500-CS(config-if-range)# switchport voice vlan 110C4500-CS(config-if-range)# spanning-tree portfastC4500-CS(config-if-range)# qos trust device cisco-phone! The interface is set to conditionally-trust Cisco IP PhonesC4500-CS(config-if-range)# qos trust dscp! DSCP-trust will be dynamically extended to Cisco IP PhonesC4500-CS(config-if-range)# service-policy input PER-PORT-POLICING! Attaches the Per-Port Policing policy to the interface(s)
Note
This configuration can be verified with the following commands:
•
•
•
•
•
Example 2-41 Verifying Global Policing Markdown Mappings on a Catalyst 4500 Classic Supervisor—show qos maps dscp policed
C4500-CS#show qos maps dscp policedPoliced DSCP Mapping Table (dscp = d1d2)d1 : d2 0 1 2 3 4 5 6 7 8 9-------------------------------------0 : 08 01 02 03 04 05 06 07 08 091 : 08 11 12 13 14 15 16 17 08 192 : 20 21 22 23 24 25 26 27 28 293 : 30 31 32 33 34 35 36 37 38 394 : 40 41 42 43 44 45 46 47 48 495 : 50 51 52 53 54 55 56 57 58 596 : 60 61 62 63C4500-CS#In Example 2-41, the policing DSCP-markdown mapping is shown. The first digit of the DSCP value of a packet offered to a policer is shown along the Y-axis of the table; the second digit of the DSCP value of a packet offered to a policer is shown along the X-axis of the table. For example, the DSCP value for the transactional data application class (AF21/18) is found in the row d1=1 and column d2=8. And, as shown, packets with this offered DSCP value (along with DF/0 and AF11/10) are remarked to CS1 (08) if found to be in excess of the policing rate.
Per-Port Policing Model (Supervisor 6-E)
The per-port policing model is essentially the same for the Catalyst 4500-E Supervisor 6-E, except that it does not require a global policed-DSCP map and thus the policing commands are slightly different, also no trust-DSCP statement is required on the interface(s), as shown in Example 2-42.
Example 2-42 Per-Port Policing Configuration Example on a Catalyst 4500-E Supervisor 6-E
! This section configures the Per-Port policing policy-mapC4500-E(config)#policy-map PER-PORT-POLICINGC4500-E(config-pmap)# class VVLAN-VOIPC4500-E(config-pmap-c)# set dscp efC4500-E(config-pmap-c)# police 128k bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action drop! VoIP is marked EF and policed to drop at 128 kbpsC4500-E(config-pmap)# class VVLAN-SIGNALINGC4500-E(config-pmap-c)# set dscp cs3C4500-E(config-pmap-c)# police 32k bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action drop! (VVLAN) Signaling is marked CS3 and policed to drop at 32 kbpsC4500-E(config-pmap)# class MULTIMEDIA-CONFERENCINGC4500-E(config-pmap-c)# set dscp af41C4500-E(config-pmap-c)# police 5m bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action drop! Multimedia-conferencing is marked AF41 and policed to drop at 5 MbpsC4500-E(config-pmap)# class SIGNALINGC4500-E(config-pmap-c)# set dscp cs3C4500-E(config-pmap-c)# police 32k bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action drop! (DVLAN) Signaling is marked CS3 and policed to drop at 32 kbpsC4500-E(config-pmap)# class TRANSACTIONAL-DATAC4500-E(config-pmap-c)# set dscp af21C4500-E(config-pmap-c)# police 10m bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action set-dscp-transmit cs1! Trans-data is marked AF21 and policed to remark (to CS1) at 10 MbpsC4500-E(config-pmap)# class BULK-DATAC4500-E(config-pmap-c)# set dscp af11C4500-E(config-pmap-c)# police 10m bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action set-dscp-transmit cs1! Bulk-data is marked AF11 and policed to remark (to CS1) at 10 MbpsC4500-E(config-pmap)# class SCAVENGERC4500-E(config-pmap-c)# set dscp cs1C4500-E(config-pmap-c)# police 10m bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action drop! Scavenger traffic is marked CS1 and policed to drop at 10 MbpsC4500-E(config-pmap)# class class-defaultC4500-E(config-pmap-c)# set dscp defaultC4500-E(config-pmap-c)# police 10m bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action set-dscp-transmit cs1! The implicit default class marks all other traffic to DF! and polices all other traffic to remark (to CS1) at 10 Mbps! This section attaches the service-policy to the interface(s)C4500-E(config)#interface range GigabitEthernet 2/1-48C4500-E(config-if-range)# switchport access vlan 10C4500-E(config-if-range)# switchport voice vlan 110C4500-E(config-if-range)# spanning-tree portfastC4500-E(config-if-range)# qos trust device cisco-phone! The interface is set to conditionally-trust Cisco IP PhonesC4500-E(config-if-range)# service-policy input PER-PORT-POLICING! Attaches the Per-Port Policing policy to the interface(s)
Note
This configuration can be verified with the following commands:
•
•
•
•
Per-Port/Per-VLAN Policing Model (Classic Supervisors)
An alternative—and more discrete—approach for deploying policing policies on the Catalyst 4500 platforms is to deploy these on a per-port/per-VLAN basis. The Catalyst 4500 has a very elegant syntax for deploying per-port/per-VLAN policies (as compared to the Catalyst 3750-E syntax, for example), where policies are applied within a VLAN mode within a switch port's interface configuration mode, as shown in Example 2-43.
In Example 2-43, three policers are applied to the VVLAN of a given access edge trunk port: one to police VoIP to 128 kbps, another to police signaling to 32 kbps, and a third to policy everything else to 32 kbps. On the other hand, six policers are applied to the DVLAN of a given access edge trunk port: one to policy multimedia conferencing traffic to drop at 5 Mbps, a second to police signaling to drop at 32 kbps, a third to police transactional data to remark (to CS1) at 10 Mbps, a fourth to police bulk data to remark (to CS1) at 10 Mbps, a fifth to police scavenger to drop at 10 Mbps, and a sixth to police everything else to remark (to CS1) at 10 Mbps.
As in the previous examples, remarking is performed by configuring a policed-DSCP map with the global configuration command qos map dscp policed, which specifies which DSCP values are subject to remarking (if out-of-profile) and what these values should be remarked to (which in the case of scavenger-class QoS policies, the remarking value is CS1/DSCP 8).
Example 2-43 Per-Port/Per-VLAN Policing Configuration Example on a Catalyst 4500 Classic Supervisor
! This section configures the global policed-DSCP markdown mapC4500-CS(config)#qos map dscp policed 0 10 18 to dscp 8! DSCP 0 (DF), 10 (AF11) and 18 (AF21) are marked down to 8 (CS1)! if found to be in excess of their (respective) policing rates! This section configures the policy-map for the VVLAN policersC4500-CS(config)#policy-map VVLAN-POLICERSC4500-CS(config-pmap)# class VVLAN-VOIPC4500-CS(config-pmap-c)# set dscp efC4500-CS(config-pmap-c)# police 128k 8000 exceed-action drop! VoIP is marked EF and policed to drop at 128 kbpsC4500-CS(config-pmap-c)# class VVLAN-SIGNALINGC4500-CS(config-pmap-c)# set dscp cs3C4500-CS(config-pmap-c)# police 32k 8000 exceed-action drop! (VVLAN) Signaling is marked CS3 and policed to drop at 32 kbpsC4500-CS(config-pmap-c)# class class-defaultC4500-CS(config-pmap-c)# set dscp defaultC4500-CS(config-pmap-c)# police 32k 8000 exceed-action drop! The implicit default class marks all other VVLAN traffic to DF! and polices to drop at 32 kbps! This section configures the policy-map for the DVLAN policersC4500-CS(config)#policy-map DVLAN-POLICERSC4500-CS(config-pmap)# class MULTIMEDIA-CONFERENCINGC4500-CS(config-pmap-c)# set dscp af41C4500-CS(config-pmap-c)# police 5m 8000 exceed-action drop! Multimedia-conferencing is marked AF41 and policed to drop at 5 MbpsC4500-CS(config-pmap-c)# class SIGNALINGC4500-CS(config-pmap-c)# set dscp cs3C4500-CS(config-pmap-c)# police 32k 8000 exceed-action drop! (DVLAN) Signaling is marked CS3 and policed to drop at 32 kbpsC4500-CS(config-pmap-c)# class TRANSACTIONAL-DATAC4500-CS(config-pmap-c)# set dscp af21C4500-CS(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit! Trans-data is marked AF21 and policed to remark (to CS1) at 10 MbpsC4500-CS(config-pmap-c)# class BULK-DATAC4500-CS(config-pmap-c)# set dscp af11C4500-CS(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit! Bulk-data is marked AF11 and policed to remark (to CS1) at 10 MbpsC4500-CS(config-pmap-c)# class SCAVENGERC4500-CS(config-pmap-c)# set dscp cs1C4500-CS(config-pmap-c)# police 10m 8000 exceed-action drop! Scavenger traffic is marked CS1 and policed to drop at 10 MbpsC4500-CS(config-pmap-c)# class class-defaultC4500-CS(config-pmap-c)# set dscp defaultC4500-CS(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit! The implicit default class marks all other traffic to DF! and polices all other traffic to remark (to CS1) at 10 Mbps! This section attaches the policy to the VLANs on a Per-Port basisC4500-CS(config)#interface range GigabitEthernet 2/1-48C4500-CS(config-if-range)# switchport access vlan 10C4500-CS(config-if-range)# switchport voice vlan 110C4500-CS(config-if-range)# spanning-tree portfastC4500-CS(config-if-range)# qos trust device cisco-phone! The interface is set to conditionally-trust Cisco IP PhonesC4500-CS(config-if-range)# qos trust dscp! DSCP-trust will be dynamically extended to Cisco IP PhonesC4500-CS(config-if-range)# vlan 10C4500-CS(config-if-vlan-range)# service-policy input DVLAN-POLICERS! Attaches the Per-Port/Per-VLAN DVLAN Policing policy to the! DVLAN of the trunked interface(s)C4500-CS(config-if-range)# vlan 110C4500-CS(config-if-vlan-range)# service-policy input VVLAN-POLICERS! Attaches the Per-Port/Per-VLAN VVLAN Policing policy to the! VVLAN of the trunked interface(s)This configuration can be verified with the following commands:
•
•
•
•
•
•
Per-Port/Per-VLAN Policing Model (Supervisor 6-E)
The per-port/per-VLAN policing model is essentially the same for the Catalyst 4500-E Supervisor 6-E, except that it does not require a global policed-DSCP map and thus the policing commands are slightly different; also no trust-DSCP statement is required on the interface(s), as shown in Example 2-44.
Example 2-44 Per-Port/Per-VLAN Policing Configuration Example on a Catalyst 4500-E Supervisor 6-E
! This section configures the policy-map for the VVLAN policersC4500-E(config)#policy-map VVLAN-POLICERSC4500-E(config-pmap)# class VVLAN-VOIPC4500-E(config-pmap-c)# set dscp efC4500-E(config-pmap-c)# police 128k bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action drop! VoIP is marked EF and policed to drop at 128 kbpsC4500-E(config-pmap)# class VVLAN-SIGNALINGC4500-E(config-pmap-c)# set dscp cs3C4500-E(config-pmap-c)# police 32k bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action drop! (VVLAN) Signaling is marked CS3 and policed to drop at 32 kbpsC4500-E(config-pmap)# class class-defaultC4500-E(config-pmap-c)# set dscp defaultC4500-E(config-pmap-c)# police 32k bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action drop! The implicit default class marks all other VVLAN traffic to DF! and polices to drop at 32 kbps! This section configures the policy-map for the DVLAN policersC4500-E(config)#policy-map DVLAN-POLICERSC4500-E(config-pmap)# class MULTIMEDIA-CONFERENCINGC4500-E(config-pmap-c)# set dscp af41C4500-E(config-pmap-c)# police 5m bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action drop! Multimedia-conferencing is marked AF41 and policed to drop at 5 MbpsC4500-E(config-pmap)# class SIGNALINGC4500-E(config-pmap-c)# set dscp cs3C4500-E(config-pmap-c)# police 32k bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action drop! (DVLAN) Signaling is marked CS3 and policed to drop at 32 kbpsC4500-E(config-pmap)# class TRANSACTIONAL-DATAC4500-E(config-pmap-c)# set dscp af21C4500-E(config-pmap-c)# police 10m bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action set-dscp-transmit cs1! Trans-data is marked AF21 and policed to remark (to CS1) at 10 MbpsC4500-E(config-pmap)# class BULK-DATAC4500-E(config-pmap-c)# set dscp af11C4500-E(config-pmap-c)# police 10m bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action set-dscp-transmit cs1! Bulk-data is marked AF11 and policed to remark (to CS1) at 10 MbpsC4500-E(config-pmap)# class SCAVENGERC4500-E(config-pmap-c)# set dscp cs1C4500-E(config-pmap-c)# police 10m bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action drop! Scavenger traffic is marked CS1 and policed to drop at 10 MbpsC4500-E(config-pmap)# class class-defaultC4500-E(config-pmap-c)# set dscp defaultC4500-E(config-pmap-c)# police 10m bc 8000C4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action set-dscp-transmit cs1! The implicit default class marks all other traffic to DF! and polices all other traffic to remark (to CS1) at 10 Mbps! This section attaches the policy to the VLANs on a Per-Port basisC4500-E(config)#interface range GigabitEthernet 2/1-48C4500-E(config-if-range)# switchport access vlan 10C4500-E(config-if-range)# switchport voice vlan 110C4500-E(config-if-range)# spanning-tree portfastC4500-E(config-if-range)# qos trust device cisco-phone! The interface is set to conditionally-trust Cisco IP PhonesC4500-E(config-if-range)# vlan 10C4500-E(config-if-vlan-range)# service-policy input DVLAN-POLICERS! Attaches the Per-Port/Per-VLAN DVLAN Policing policy to the! DVLAN of the trunked interface(s)C4500-E(config-if-range)# vlan 110C4500-E(config-if-vlan-range)# service-policy input VVLAN-POLICERS! Attaches the Per-Port/Per-VLAN VVLAN Policing policy to the! VVLAN of the trunked interface(s)
Note
This configuration can be verified with the following commands:
•
•
•
•
•
•
Per-Port User-Based Rate Limiting (Supervisor V-10GE)
UBRL adopts microflow policing capability to dynamically learn traffic flows and rate limit each unique flow to an individual rate and, as such, is a highly effective and efficient policing tool, particularly at the distribution ayer in a medianet campus network.
UBRL is available on Supervisor Engine V-10GE with NetFlow support. UBRL can be applied to ingress traffic on routed interfaces and is typically used in environments where a per-user, granular rate limiting mechanism is required, such as at the distribution layer, to provide a second line of policing defense in the campus. Like other policers, UBRL can be used to drop or remark exceeding flows.
A flow is defined by five-tuples (IP source address, IP destination address, IP protocol field, Layer 4 protocol source, and destination ports), which are the same for each packet in the flow. Flow-based policers apply a single policy to discrete flows without having to specify the virtually-infinite tuple-combinations. UBRL can also be applied with source or destination flow masks; these masks apply an aggregate microflow policing policy to multiple flows sharing the same source or IP destination addresses.
In the per-port UBRL Model, a class map matches on a microflow basis and aggregates these by source addresses. Then a policer applies an aggregate limit to all microflows sharing a common source IP address, remarking traffic in excess of the policing rate.
Remarking is performed by configuring a policed-DSCP map with the global configuration command qos map dscp policed, which specifies which DSCP values are subject to remarking (if out-of-profile) and what these values should be remarked to (which in the case of scavenger class QoS policies, the remarking value is CS1/DSCP 8).
UBRL is supported on Layer 3 interfaces and can be applied on either a per-port or per-port/per-VLAN-basis, as shown in Example 2-45 and Example 2-46, respectively.
In Example 2-45, the campus distribution block is using a routed access design and, as such, has Layer 3 interfaces (TenGigabitEthernet 1/1 and 1/2) connecting it to the access layer switches. UBRL is applied to all flows to ensure that any endpoint transmitting at more than 5% capacity (an example value) of the access edge 10/100/1000 switch ports are subject to data plane policing/scavenger class QoS.
Example 2-45 Per-Port UBRL Configuration Example on a Catalyst 4500 Supervisor V-10GE
! This section configures the global policed-DSCP markdown mapC4500-CS(config)#qos map dscp policed 0 10 18 24 34 46 to dscp 8! DSCP 0 (DF), 10 (AF11) and 18 (AF21), 24 (CS3), 34 (AF41) & 46 (EF)! are marked down to 8 (CS1)if found to be in excess of their! (respective) policing rates! This section defines the sourced-based microflow class-mapC4500-SupV-10GE(config)#class-map match-all ENDPOINTSC4500-SupV-10GE(config-cmap)# match flow ip source-address! All flows sharing a unique source IP address will be matched! This section defines the aggregate per-source-IP UBRL policerC4500-SupV-10GE(config)#policy-map UBRLC4500-SupV-10GE(config-pmap)# class ENDPOINTSC4500-SupV-10GE(config-pmap-c)# police 50m 8000 byte conform-action transmit exceed-action policed-dscp-transmit! Any flows from a single source IP address! will be remarked to CS1 if exceeding 50 Mbps! This section attaches the UBRL policy to a Layer 3 interfaceC4500-SupV-10GE(config)#interface range TenGigabitEthernet1/1-2C4500-SupV-10GE(config-if-range)# description L3-Dwnlnk to Access-LayerC4500-SupV-10GE(config-if-range)# no switchportC4500-SupV-10GE(config-if-range)# qos trust dscp! Sets the interface(s) trust state to statically trust-DSCP! As this is a Distribution-Layer downlinkC4500-SupV-10GE(config-if-range)# service-policy input UBRL! Attaches the UBRL policy to the interface(s)This configuration can be verified with the following commands:
•
•
•
•
•
Per-Port/Per-VLAN User-Based Rate Limiting (Supervisor V-10GE)
In contrast with the previous example, if the campus distribution block is using a Layer 2/Layer 3 design, and as such has Layer 2 trunked interfaces (TenGigabitEthernet 1/1 and 1/2) connecting it to the access layer switches, then UBRL can be applied on a per-port/per-VLAN basis. In this case, separate UBRL policies can be applied to each VLAN traversing the trunked interfaces—via per-port/per-VLAN UBRL policies—as each VLAN is routed through the switch.
To highlight policy flexibility, additional levels of classification are included in this second UBRL example (which incidentally can also be applied to the per-port UBRL model). Instead of applying a blanket UBRL policy to all endpoints, separate UBRL polices can be applied to different types of endpoints or application-and-endpoint-combinations. For example, VoIP from Cisco IP phones in the VVLAN can be rate limited to 128 Kbps, while signaling traffic from these endpoints can be limited to 32 kbps. Similarly, TelePresence endpoints in the VVLAN (which mark their media flows to CS4) can be limited to 25 Mbps. All other endpoint-generated traffic in the VVLAN can be limited to 32 kbps per endpoint.
Similar policy granularity can be applied to the DVLAN policer, if desired. However in this example, a simplified DVLAN policer is applied to all flows to ensure that any DVLAN endpoint transmitting at more than 5% capacity (an example value) of the access edge 10/100/1000 switch ports are subject to data plane policing/scavenger class QoS.
Static DSCP-trust is configured on the physical ports and the per-port/per-VLAN UBRL policers are applied to their respective VLANs within the trunked interface, as shown in Example 2-46.
Example 2-46 Per-Port/Per-VLAN UBRL Configuration Example on a Catalyst 4500 Supervisor V-10GE
! This section configures the global policed-DSCP markdown mapC4500-CS(config)#qos map dscp policed 0 10 18 34 to dscp 8! DSCP 0 (DF), 10 (AF11) and 18 (AF21) and 34 (AF41)! are marked down to 8 (CS1)if found to be in excess of their! (respective) policing rates! This section defines the sourced-based microflow class-maps4507-E(config)#class-map match-all VOIP-ENDPOINTS4507-E(config-cmap)# match ip dscp ef4507-E(config-cmap)# match flow ip source-address! All flows marked EF from a single source IP will be matched4507-E(config)#class-map match-all TELEPRESENCE-ENDPOINTS4507-E(config-cmap)# match ip dscp cs44507-E(config-cmap)# match flow ip source-address! All flows marked CS4 from a single source IP will be matched4507-E(config)#class-map match-all SIGNALING-ENDPOINTS4507-E(config-cmap)# match ip dscp cs34507-E(config-cmap)# match flow ip source-address! All flows marked CS3 from a single source IP will be matchedC4500-SupV-10GE(config)#class-map match-all ENDPOINTSC4500-SupV-10GE(config-cmap)# match flow ip source-address! All flows sharing a unique source IP address will be matched! This section defines the aggregate per-source-IP VVLAN UBRL policer4507-E(config)#policy-map VVLAN-UBRL4507-E(config-pmap)# class VOIP-ENDPOINTS4507-E(config-pmap-c)# police 128k 8000 byte conform-action transmit exceed-action drop! All flows marked EF from a single IP are policed to drop at 128 kbps4507-E(config-pmap)# class TELEPRESENCE-ENDPOINTS4507-E(config-pmap-c)# police 25m 256000 byte conform-action transmit exceed-action drop! All flows marked CS4 from a single IP are policed to drop at 25 Mbps4507-E(config-pmap)# class SIGNALING-ENDPOINTS4507-E(config-pmap-c)# police 32k 8000 byte conform-action transmit exceed-action drop! All flows marked CS3 from a single IP are policed to drop at 32 kbps4507-E(config-pmap)# class ENDPOINTS4507-E(config-pmap-c)# police 32k 8000 byte conform-action transmit exceed-action drop! All other flows from a single VVLAN IP are policed to 32 kbps! This section defines the aggregate per-source-IP DVLAN UBRL policerC4500-SupV-10GE(config)#policy-map DVLAN-UBRLC4500-SupV-10GE(config-pmap)# class ENDPOINTSC4500-SupV-10GE(config-pmap-c)# police 50m 8000 byte conform-action transmit exceed-action policed-dscp-transmit! Any flows from a single source IP address within the DVLAN! will be remarked to CS1 if exceeding 50 Mbps! This section configures static DSCP trust on the trunked interfaces! And attaches the UBRL policies to their respective VLANsC4500-SupV-10GE(config)#interface range TenGigabitEthernet1/1-2C4500-SupV-10GE(config-if-range)# description L2-Dwnlnk to Access-LayerC4500-SupV-10GE(config-if)# switchport trunk encapsulation dot1qC4500-SupV-10GE(config-if)# switchport trunk allowed vlan 10,110C4500-SupV-10GE(config-if)# switchport mode trunkC4500-SupV-10GE(config-if)# qos trust dscp! Sets the interface(s) trust state to statically trust-DSCP! As this is a Distribution-Layer (trunked) downlinkC4500-SupV-10GE(config)#int vlan 10C4500-SupV-10GE(config-if)# service-policy input DVLAN-UBRL! Attaches the Per-Port/Per-VLAN DVLAN UBRL policy to the! DVLAN of the trunked interface(s)C4500-SupV-10GE(config)#int vlan 110C4500-SupV-10GE(config-if)# service-policy input VVLAN-UBRL! Attaches the Per-Port/Per-VLAN VVLAN UBRL policy to the! DVLAN of the trunked interface(s)This configuration can be verified with the following commands:
•
•
•
•
•
•
Queuing Models
The Catalyst 4500 switch family only supports egress queuing models, which can be configured on the Classic Supervisor branch to operate in either a 4Q1T mode or a 1P3Q1T mode (the latter of which is recommended for medianet campus networks, as it supports the EF PHB) and on the Supervisor 6-E branch can be configured (via MQC) to provide a flexible queuing structure, to a maximum of 1P7Q1T.
Additionally, the Catalyst 4500 family uses a platform-specific congestion avoidance algorithm to provide Active Queue Management (AQM), namely Dynamic Buffer Limiting (DBL). DBL tracks the queue length for each traffic flow in the switch. When the queue length of a flow exceeds its limit, DBL drop packets or set the Explicit Congestion Notification (ECN) bits in the packet headers.
Furthermore, the Catalyst 4500 supports DSCP-to-queue mapping on both branches.
The Catalyst 4500 Classic Supervisor 1P3Q1T+DBL model and the Supervisor 6-E 1P7Q1T+DBL models are detailed in the following sections.
Egress Queuing 1P3Q1T+DBL (Classic Supervisors) Model
On the Catalyst 4500 Classic Supervisors, queue 3 can be enabled as a strict-priority queue. Once enabled, Q4 can be used as a guaranteed bandwidth queue, Q2 can be used as the default best effort queue, and Q1 can be used as a less than best effort (scavenger) queue. Bandwidth can be assigned as: 5%, 35%, 30%, and 30% for queues 1 through 4, respectively.
DBL can be enabled on all DSCP values, with the exception of DSCP values that are mapped to the PQ (specifically, CS4/32, CS5/40, and EF/46), as this may cause drops to occur on these real time flows. Additionally, DBL can be enabled to mark the IP Explicit Congestion Notification (IP ECN) bits within the IP ToS Bye in the event of congestion. A service policy can be configured to enable DBL on all flows (except those already noted) and applied to each interface on which queuing is enabled.
Once these queues have been configured, then VoIP (EF), broadcast video (CS5), and realtime interactive (CS4) traffic can be mapped to the strict priority queue (Q3). Network control (CS7), internetwork control (CS6), signaling (CS3), and management (CS2) traffic can be mapped to Q4, along with multimedia conferencing (AF4), multimedia streaming (AF3), and transactional data (AF2). Best effort traffic is sent to the default queue (Q2), while bulk data (AF1) and scavenger (CS1) traffic are mapped to the deferential queue (Q1). These 1P3Q1T+DBL egress queuing mappings for the Catalyst 4500 Classic Supervisor are shown in Figure 2-20.
Figure 2-20 Catalyst 4500 Classic Supervisor 1P3Q1T+DBL Egress Queuing Model
The corresponding configuration for 1P3Q1T+DBL egress queuing on a Catalyst 4500 Classic Supervisor is shown in Example 2-47.
Example 2-47 1P3Q1T+DBL Egress Queuing Configuration Example on a Catalyst 4500 Classic Supervisor
! This section enables and configures DBLC4500-CS(config)#qos dbl! DBL is globally enabledC4500-CS(config)#no qos dbl dscp-based 32C4500-CS(config)#no qos dbl dscp-based 40C4500-CS(config)#no qos dbl dscp-based 46! DBL is explicitly disabled on DSCP CS4, CS5 and EF! as these DSCP values are assigned to the PQ! and as such should never experience congestion avoidance dropsC4500-CS(config)#qos dbl exceed-action ecn! DBL will mark IP ECN bits in the event of congestion! This section configures the DBL policy-mapC4500-CS(config)#policy-map DBLC4500-CS(config-pmap)# class class-defaultC4500-CS(config-pmap-c)# dbl! DBL is enabled on all flows! (with the exception of DSCP CS4, CS5 and EF)! This section configures the DSCP-to-Queue mappingsC4500-CS(config)#qos map dscp 8 10 12 14 to tx-queue 1! DSCP CS1 and AF1 are mapped to Q1 (the less than best effort queue)C4500-CS(config)#qos map dscp 0 to tx-queue 2! DSCP DF is mapped to Q2 (the best effort/default queue)C4500-CS(config)#qos map dscp 32 40 46 to tx-queue 3! DSCP CS4, CS5 and EF are mapped to Q3 (the PQ)C4500-CS(config)#qos map dscp 16 18 20 22 to tx-queue 4! DSCP CS2 and AF2 are mapped to Q4 (guaranteed BW queue)C4500-CS(config)#qos map dscp 24 26 28 30 to tx-queue 4! DSCP CS3 and AF3 are mapped to Q4 (guaranteed BW queue)C4500-CS(config)#qos map dscp 34 36 38 to tx-queue 4! DSCP AF4 is mapped to Q4 (guaranteed BW queue)C4500-CS(config)#qos map dscp 48 56 to tx-queue 4! DSCP CS6 and CS7 are mapped to Q4 (guaranteed BW queue)! This section configures the interface(s) for egress queuingC4500-CS(config)#interface range GigabitEthernet 1/1-2C4500-CS(config-if-range)# tx-queue 1C4500-CS(config-if-tx-queue)# bandwidth percent 5! Q1 (less than best effort queue) is assigned 5% BWC4500-CS(config-if-tx-queue)# tx-queue 2C4500-CS(config-if-tx-queue)# bandwidth percent 35! Q2 (default/best effort queue) is assigned 35% BWC4500-CS(config-if-tx-queue)# tx-queue 3C4500-CS(config-if-tx-queue)# priority highC4500-CS(config-if-tx-queue)# bandwidth percent 30! Q3 is enabled as a PQ and assigned 30% BWC4500-CS(config-if-tx-queue)# tx-queue 4C4500-CS(config-if-tx-queue)# bandwidth percent 30! Q4 (guaranteed BW queue) is assigned 30% BWC4500-CS(config-if-range)# service-policy output DBL! DBL policy-map is attached to the interface(s)This configuration can be verified with the following commands:
•
•
•
•
•
•
Example 2-48 Verifying DBL on a Catalyst 4500 Classic Supervisor—show qos dbl
C4500-CS#show qos dblQOS is enabled globallyDBL is enabled globally on DSCP values:0-31,33-39,41-45,47-63DBL flow includes vlanDBL flow includes layer4-portsDBL uses ecn to indicate congestionDBL exceed-action probability: 15%DBL max credits: 15DBL aggressive credit limit: 10DBL aggressive buffer limit: 2 packetsC4500-CS#Example 2-48 shows that DBL has been globally enabled and is active on all DSCP values with the exception of CS4/32, CS5/40, and EF/46. Also that DBL uses IP ECN to indicate congestion.
Example 2-49 Verifying DSCP-to-Queue Mappings on a Catalyst 4500 Classic Supervisor—show qos maps dscp tx-queue
C4500-CS#show qos maps dscp tx-queueDSCP-TxQueue Mapping Table (dscp = d1d2)d1 : d2 0 1 2 3 4 5 6 7 8 9-------------------------------------0 : 02 01 01 01 01 01 01 01 01 011 : 01 01 01 01 01 01 04 02 04 022 : 04 02 04 02 04 02 04 02 04 023 : 04 02 03 03 04 03 04 03 04 034 : 03 03 03 03 03 03 03 03 04 045 : 04 04 04 04 04 04 04 04 04 046 : 04 04 04 04C4500-CS#Example 2-49 shows the ingress DSCP-to-queue mappings. The first digit of the DSCP value of a packet is shown along the Y-axis of the table; the second digit of the DSCP value of a packet is shown along the X-axis of the table. The mapping table corresponds to Figure 2-20. It can be noted that CS4 (DSCP 32), CS5 (DSCP 40), and EF (DSCP 46) are all mapped to Q3 (the PQ). It should also be noted that internal DSCP values 32 through 47 are mapped to Q2 by default, which is why the table shows additional values being mapped to this queue.
Example 2-50 Verifying Queuing Settings on a Catalyst 4500 Classic Supervisor—show qos interface
C4500-CS#show qos interface GigabitEthernet 1/1QoS is enabled globallyPort QoS is enabledAdministrative Port Trust State: 'dscp'Operational Port Trust State: 'dscp'Trust device: noneDefault DSCP: 0 Default CoS: 0Appliance trust: noneTx-Queue Bandwidth ShapeRate Priority QueueSize(bps) (bps) (packets)1 50000000 disabled N/A 19202 350000000 disabled N/A 19203 300000000 disabled high 19204 300000000 disabled N/A 1920C4500-CS#Example 2-50 shows that interface GigabitEthernet 1/1 has been configured such that Q1 through Q4 receive 5%, 35%, 30%, and 30% (respectively) of the interface bandwidth (1 Gbps) and that Q3 has been enabled as a high priority/strict priority queue.
Egress Queuing 1P7Q1T+DBL (Supervisor 6-E) Model
The Catalyst 4500-E Supervisor 6-E hardware supports (up to) eight transmit queues per port. Queues are assigned when an output policy is attached to a port with one or more queuing related actions for one or more classes of traffic. Because there are only eight queues per port, there can be at most eight classes of traffic (including the reserved class, class default) with queuing actions defined.
On the Catalyst 4500-E Supervisor 6-E only one transmit queue on a port can be configured as strict priority queue (which, in effect, constitutes a hardware low latency queue) with the priority policy-map class action command. The priority queue is serviced first until it is empty or until it is under its limited rate. Only one traffic stream can be destined for the priority queue per class level policy (in other words, multiple hardware LLQs are not supported on the Supervisor 6-E). The hardware LLQ can starve other queues unless it is rate limited and, as such, the Supervisor 6-E supports an unconditional (explicit) policer to rate limit packets enqueued to the strict priority queue. When the priority queue is configured on one class of a policy map without a policer, only bandwidth remaining is accepted on other classes (guaranteeing a minimum bandwidth for other classes from the remaining bandwidth of what is left after using the priority queue); however, when the priority queue is configured with a policer, then either bandwidth or bandwidth remaining is accepted on the other queuing classes.
Additionally, as with the Classic Supervisors, DBL can be enabled on a per-class basis, but is most effective when applied against TCP-based traffic flows (as opposed to UDP-based traffic flows).
Thus the Catalyst 4500-E Supervisor 6-E can be configured to operate in a 1P7Q1T+DBL mode. VoIP (EF), broadcast video (CS5), and realtime interactive (CS4) flows can be assigned to the strict priority queue. Network and internetwork control (CS6 and CS7, respectively), along with signaling and management (CS3 and CS2, respectively), can all share a control/management queue. This allows for dedicated queues to be provisioned for multimedia conferencing (AF4), multimedia streaming (AF3), transactional data (AF2), and bulk data (AF1). Also, scavenger (CS1) traffic can share a bandwidth-constrained "less than best effort" queue, while all other traffic is assigned to the default/best effort queue. The recommended 1P7Q1T Sup 6-E egress queuing configuration for the C4500-E Supervisor 6-E is illustrated in Figure 2-21.
Figure 2-21 Catalyst 4500-E Supervisor 6-E 1P7Q1T+DBL Egress Queuing Model
The corresponding configuration for 1P7Q1T+DBL egress queuing on a Catalyst 4500-E Supervisor 6-E is shown in Example 2-51.
Example 2-51 1P7Q1T+DBL Egress Queuing Configuration Example on a Catalyst 4500-E Supervisor-6E
! This section configures the class-maps for the egress queuing policy! Note: these class-maps require unique names from any ingress! policy class-maps; otherwise classification errors may occur! due to overlapping classification logicC4500-E(config)#class-map match-any PRIORITY-QUEUEC4500-E(config-cmap)# match dscp efC4500-E(config-cmap)# match dscp cs5C4500-E(config-cmap)# match dscp cs4! VoIP (EF), Broadcast Video (CS5) and Realtime Interactive (CS4)! are all mapped to the PQC4500-E(config)#class-map match-any CONTROL-MGMT-QUEUEC4500-E(config-cmap)# match dscp cs7C4500-E(config-cmap)# match dscp cs6C4500-E(config-cmap)# match dscp cs3C4500-E(config-cmap)# match dscp cs2! Network Control (CS7), Internetwork Control (CS6),! Signaling (CS3) and Management (CS2) are mapped! to a Control/Management QueueC4500-E(config)#class-map match-all MULTIMEDIA-CONFERENCING-QUEUEC4500-E(config-cmap)# match dscp af41 af42 af43! Multimedia Conferencing (AF4) is assigned a dedicated queueC4500-E(config)#class-map match-all MULTIMEDIA-STREAMING-QUEUEC4500-E(config-cmap)# match dscp af31 af32 af33! Multimedia Streaming (AF3) is assigned a dedicated queueC4500-E(config)#class-map match-all TRANSACTIONAL-DATA-QUEUEC4500-E(config-cmap)# match dscp af21 af22 af23! Transactional Data (AF2) is assigned a dedicated queueC4500-E(config)#class-map match-all BULK-DATA-QUEUEC4500-E(config-cmap)# match dscp af11 af12 af13! Bulk Data (AF1) is assigned a dedicated queueC4500-E(config)#class-map match-all SCAVENGER-QUEUEC4500-E(config-cmap)# match dscp cs1! Scavenger (CS1) is assigned a dedicated queue! This section configures the 1P7Q1T+DBL egress queuing policy-mapC4500-E(config)#policy-map 1P7Q1TC4500-E(config-pmap-c)# class PRIORITY-QUEUEC4500-E(config-pmap-c)# priorityC4500-E(config-pmap-c)# police cir percent 30 bc 33 msC4500-E(config-pmap-c-police)# conform-action transmitC4500-E(config-pmap-c-police)# exceed-action drop! Defines a priority queue with an explicit policer (30% BW)! Burst parameter accommodates 30 fps video (such as TelePresence)C4500-E(config-pmap-c)# class CONTROL-MGMT-QUEUEC4500-E(config-pmap-c)# bandwidth percent 10! Defines a control/management queue with 10% BW guaranteeC4500-E(config-pmap-c)# class MULTIMEDIA-CONFERENCING-QUEUEC4500-E(config-pmap-c)# bandwidth percent 10! Defines a multimedia conferencing queue with 10% BW guaranteeC4500-E(config-pmap-c)# class MULTIMEDIA-STREAMING-QUEUEC4500-E(config-pmap-c)# bandwidth percent 10! Defines a multimedia streaming queue with 10% BW guaranteeC4500-E(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUEC4500-E(config-pmap-c)# bandwidth percent 10C4500-E(config-pmap-c)# dbl! Defines a transactional data queue with 10% BW guarantee + DBLC4500-E(config-pmap-c)# class BULK-DATA-QUEUEC4500-E(config-pmap-c)# bandwidth percent 4C4500-E(config-pmap-c)# dbl! Defines a bulk data queue with 10% BW guarantee + DBLC4500-E(config-pmap-c)# class SCAVENGER-QUEUEC4500-E(config-pmap-c)# bandwidth percent 1! Defines a (minimal) scavenger queue with 1% BW guarantee/limitC4500-E(config-pmap-c)# class class-defaultC4500-E(config-pmap-c)# bandwidth percent 25C4500-E(config-pmap-c)# dbl! Provisions the default/Best Effort queue with 25% BW guarantee + DBL! This section attaches the egress queuing policy to the interface(s)C4500-E(config)#interface range TenGigabitEthernet 1/1-2C4500-E(config-if-range)# service-policy output 1P7Q1T
Note
This configuration can be verified with the following commands:
•
•
•
Example 2-52 Verifying Queuing Policies on a Catalyst 4500-E Supervisor-6E—show policy-map interface
C4500-E#show policy-map interface TenGigabitEthernet 1/1TenGigabitEthernet1/1Service-policy output: 1P7Q1TClass-map: PRIORITY-QUEUE (match-any)102598 packets
