- •QoS Overview
- •“Do I Know This Already?” Quiz
- •QoS: Tuning Bandwidth, Delay, Jitter, and Loss Questions
- •Foundation Topics
- •QoS: Tuning Bandwidth, Delay, Jitter, and Loss
- •Bandwidth
- •The clock rate Command Versus the bandwidth Command
- •QoS Tools That Affect Bandwidth
- •Delay
- •Serialization Delay
- •Propagation Delay
- •Queuing Delay
- •Forwarding Delay
- •Shaping Delay
- •Network Delay
- •Delay Summary
- •QoS Tools That Affect Delay
- •Jitter
- •QoS Tools That Affect Jitter
- •Loss
- •QoS Tools That Affect Loss
- •Summary: QoS Characteristics: Bandwidth, Delay, Jitter, and Loss
- •Voice Basics
- •Voice Bandwidth Considerations
- •Voice Delay Considerations
- •Voice Jitter Considerations
- •Voice Loss Considerations
- •Video Basics
- •Video Bandwidth Considerations
- •Video Delay Considerations
- •Video Jitter Considerations
- •Video Loss Considerations
- •Comparing Voice and Video: Summary
- •IP Data Basics
- •Data Bandwidth Considerations
- •Data Delay Considerations
- •Data Jitter Considerations
- •Data Loss Considerations
- •Comparing Voice, Video, and Data: Summary
- •Foundation Summary
- •QoS Tools and Architectures
- •“Do I Know This Already?” Quiz
- •QoS Tools Questions
- •Differentiated Services Questions
- •Integrated Services Questions
- •Foundation Topics
- •Introduction to IOS QoS Tools
- •Queuing
- •Queuing Tools
- •Shaping and Policing
- •Shaping and Policing Tools
- •Congestion Avoidance
- •Congestion-Avoidance Tools
- •Call Admission Control and RSVP
- •CAC Tools
- •Management Tools
- •Summary
- •The Good-Old Common Sense QoS Model
- •GOCS Flow-Based QoS
- •GOCS Class-Based QoS
- •The Differentiated Services QoS Model
- •DiffServ Per-Hop Behaviors
- •The Class Selector PHB and DSCP Values
- •The Assured Forwarding PHB and DSCP Values
- •The Expedited Forwarding PHB and DSCP Values
- •The Integrated Services QoS Model
- •Foundation Summary
- •“Do I Know This Already?” Quiz Questions
- •CAR, PBR, and CB Marking Questions
- •Foundation Topics
- •Marking
- •IP Header QoS Fields: Precedence and DSCP
- •LAN Class of Service (CoS)
- •Other Marking Fields
- •Summary of Marking Fields
- •Class-Based Marking (CB Marking)
- •Network-Based Application Recognition (NBAR)
- •CB Marking show Commands
- •CB Marking Summary
- •Committed Access Rate (CAR)
- •CAR Marking Summary
- •Policy-Based Routing (PBR)
- •PBR Marking Summary
- •VoIP Dial Peer
- •VoIP Dial-Peer Summary
- •Foundation Summary
- •Congestion Management
- •“Do I Know This Already?” Quiz
- •Queuing Concepts Questions
- •WFQ and IP RTP Priority Questions
- •CBWFQ and LLQ Questions
- •Comparing Queuing Options Questions
- •Foundation Topics
- •Queuing Concepts
- •Output Queues, TX Rings, and TX Queues
- •Queuing on Interfaces Versus Subinterfaces and Virtual Circuits (VCs)
- •Summary of Queuing Concepts
- •Queuing Tools
- •FIFO Queuing
- •Priority Queuing
- •Custom Queuing
- •Weighted Fair Queuing (WFQ)
- •WFQ Scheduler: The Net Effect
- •WFQ Scheduling: The Process
- •WFQ Drop Policy, Number of Queues, and Queue Lengths
- •WFQ Summary
- •Class-Based WFQ (CBWFQ)
- •CBWFQ Summary
- •Low Latency Queuing (LLQ)
- •LLQ with More Than One Priority Queue
- •IP RTP Priority
- •Summary of Queuing Tool Features
- •Foundation Summary
- •Conceptual Questions
- •Priority Queuing and Custom Queuing
- •CBWFQ, LLQ, IP RTP Priority
- •Comparing Queuing Tool Options
- •“Do I Know This Already?” Quiz
- •Shaping and Policing Concepts Questions
- •Policing with CAR and CB Policer Questions
- •Shaping with FRTS, GTS, DTS, and CB Shaping
- •Foundation Topics
- •When and Where to Use Shaping and Policing
- •How Shaping Works
- •Where to Shape: Interfaces, Subinterfaces, and VCs
- •How Policing Works
- •CAR Internals
- •CB Policing Internals
- •Policing, but Not Discarding
- •Foundation Summary
- •Shaping and Policing Concepts
- •“Do I Know This Already?” Quiz
- •Congestion-Avoidance Concepts and RED Questions
- •WRED Questions
- •FRED Questions
- •Foundation Topics
- •TCP and UDP Reactions to Packet Loss
- •Tail Drop, Global Synchronization, and TCP Starvation
- •Random Early Detection (RED)
- •Weighted RED (WRED)
- •How WRED Weights Packets
- •WRED and Queuing
- •WRED Summary
- •Flow-Based WRED (FRED)
- •Foundation Summary
- •Congestion-Avoidance Concepts and Random Early Detection (RED)
- •Weighted RED (WRED)
- •Flow-Based WRED (FRED)
- •“Do I Know This Already?” Quiz
- •Compression Questions
- •Link Fragmentation and Interleave Questions
- •Foundation Topics
- •Payload and Header Compression
- •Payload Compression
- •Header Compression
- •Link Fragmentation and Interleaving
- •Multilink PPP LFI
- •Maximum Serialization Delay and Optimum Fragment Sizes
- •Frame Relay LFI Using FRF.12
- •Choosing Fragment Sizes for Frame Relay
- •Fragmentation with More Than One VC on a Single Access Link
- •FRF.11-C and FRF.12 Comparison
- •Foundation Summary
- •Compression Tools
- •LFI Tools
- •“Do I Know This Already?” Quiz
- •Foundation Topics
- •Call Admission Control Overview
- •Call Rerouting Alternatives
- •Bandwidth Engineering
- •CAC Mechanisms
- •CAC Mechanism Evaluation Criteria
- •Local Voice CAC
- •Physical DS0 Limitation
- •Max-Connections
- •Voice over Frame Relay—Voice Bandwidth
- •Trunk Conditioning
- •Local Voice Busyout
- •Measurement-Based Voice CAC
- •Service Assurance Agents
- •SAA Probes Versus Pings
- •SAA Service
- •Calculated Planning Impairment Factor
- •Advanced Voice Busyout
- •PSTN Fallback
- •SAA Probes Used for PSTN Fallback
- •IP Destination Caching
- •SAA Probe Format
- •PSTN Fallback Scalability
- •PSTN Fallback Summary
- •Resource-Based CAC
- •Resource Availability Indication
- •Gateway Calculation of Resources
- •RAI in Service Provider Networks
- •RAI in Enterprise Networks
- •RAI Operation
- •RAI Platform Support
- •Cisco CallManager Resource-Based CAC
- •Location-Based CAC Operation
- •Locations and Regions
- •Calculation of Resources
- •Automatic Alternate Routing
- •Location-Based CAC Summary
- •Gatekeeper Zone Bandwidth
- •Gatekeeper Zone Bandwidth Operation
- •Single-Zone Topology
- •Multizone Topology
- •Zone-per-Gateway Design
- •Gatekeeper in CallManager Networks
- •Zone Bandwidth Calculation
- •Gatekeeper Zone Bandwidth Summary
- •Integrated Services / Resource Reservation Protocol
- •RSVP Levels of Service
- •RSVP Operation
- •RSVP/H.323 Synchronization
- •Bandwidth per Codec
- •Subnet Bandwidth Management
- •Monitoring and Troubleshooting RSVP
- •RSVP CAC Summary
- •Foundation Summary
- •Call Admission Control Concepts
- •Local-Based CAC
- •Measurement-Based CAC
- •Resources-Based CAC
- •“Do I Know This Already?” Quiz
- •QoS Management Tools Questions
- •QoS Design Questions
- •Foundation Topics
- •QoS Management Tools
- •QoS Device Manager
- •QoS Policy Manager
- •Service Assurance Agent
- •Internetwork Performance Monitor
- •Service Management Solution
- •QoS Management Tool Summary
- •QoS Design for the Cisco QoS Exams
- •Four-Step QoS Design Process
- •Step 1: Determine Customer Priorities/QoS Policy
- •Step 2: Characterize the Network
- •Step 3: Implement the Policy
- •Step 4: Monitor the Network
- •QoS Design Guidelines for Voice and Video
- •Voice and Video: Bandwidth, Delay, Jitter, and Loss Requirements
- •Voice and Video QoS Design Recommendations
- •Foundation Summary
- •QoS Management
- •QoS Design
- •“Do I Know This Already?” Quiz
- •Foundation Topics
- •The Need for QoS on the LAN
- •Layer 2 Queues
- •Drop Thresholds
- •Trust Boundries
- •Cisco Catalyst Switch QoS Features
- •Catalyst 6500 QoS Features
- •Supervisor and Switching Engine
- •Policy Feature Card
- •Ethernet Interfaces
- •QoS Flow on the Catalyst 6500
- •Ingress Queue Scheduling
- •Layer 2 Switching Engine QoS Frame Flow
- •Layer 3 Switching Engine QoS Packet Flow
- •Egress Queue Scheduling
- •Catalyst 6500 QoS Summary
- •Cisco Catalyst 4500/4000 QoS Features
- •Supervisor Engine I and II
- •Supervisor Engine III and IV
- •Cisco Catalyst 3550 QoS Features
- •Cisco Catalyst 3524 QoS Features
- •CoS-to-Egress Queue Mapping for the Catalyst OS Switch
- •Layer-2-to-Layer 3 Mapping
- •Connecting a Catalyst OS Switch to WAN Segments
- •Displaying QoS Settings for the Catalyst OS Switch
- •Enabling QoS for the Catalyst IOS Switch
- •Enabling Priority Queuing for the Catalyst IOS Switch
- •CoS-to-Egress Queue Mapping for the Catalyst IOS Switch
- •Layer 2-to-Layer 3 Mapping
- •Connecting a Catalyst IOS Switch to Distribution Switches or WAN Segments
- •Displaying QoS Settings for the Catalyst IOS Switch
- •Foundation Summary
- •LAN QoS Concepts
- •Catalyst 6500 Series of Switches
- •Catalyst 4500/4000 Series of Switches
- •Catalyst 3550/3524 Series of Switches
- •QoS: Tuning Bandwidth, Delay, Jitter, and Loss
- •QoS Tools
- •Differentiated Services
- •Integrated Services
- •CAR, PBR, and CB Marking
- •Queuing Concepts
- •WFQ and IP RTP Priority
- •CBWFQ and LLQ
- •Comparing Queuing Options
- •Conceptual Questions
- •Priority Queuing and Custom Queuing
- •CBWFQ, LLQ, IP RTP Priority
- •Comparing Queuing Tool Options
- •Shaping and Policing Concepts
- •Policing with CAR and CB Policer
- •Shaping with FRTS, GTS, DTS, and CB Shaping
- •Shaping and Policing Concepts
- •Congestion-Avoidance Concepts and RED
- •WRED
- •FRED
- •Congestion-Avoidance Concepts and Random Early Detection (RED)
- •Weighted RED (WRED)
- •Flow-Based WRED (FRED)
- •Compression
- •Link Fragmentation and Interleave
- •Compression Tools
- •LFI Tools
- •Call Admission Control Concepts
- •Local-Based CAC
- •Measurement-Based CAC
- •Resources-Based CAC
- •QoS Management Tools
- •QoS Design
- •QoS Management
- •QoS Design
- •LAN QoS Concepts
- •Catalyst 6500 Series of Switches
- •Catalyst 4500/4000 Series of Switches
- •Catalyst 3550/3524 Series of Switches
- •Foundation Topics
- •QPPB Route Marking: Step 1
- •QPPB Per-Packet Marking: Step 2
- •QPPB: The Hidden Details
- •QPPB Summary
- •Flow-Based dWFQ
- •ToS-Based dWFQ
- •Distributed QoS Group–Based WFQ
- •Summary: dWFQ Options
726 Chapter 10: LAN QoS
In Figure 10-11, all IP Phones reside on ports 2/1 through 2/48. The set port qos 2/1-48 vlan-based command associates all QoS configuration for these ports on a per-VLAN basis. Any previous QoS configuration attached to the specific ports are removed.
Enabling QoS based on VLAN membership works well for IP telephony because IP Phones typically share the same VLAN membership. However, what if you need to enable QoS for a separate device that does not share the same VLAN, yet needs to have QoS enabled, such as a video server in port 5/10? Example 10-10 assigns QoS configuration to the specific port 5/10.
Example 10-10 Associating QoS with a Port
CatOS> (enable) set port qos 5/10 port-based
Qos interface is set to port-based for ports 5/10
CatOS> (enable)
CoS-to-Egress Queue Mapping for the Catalyst OS Switch
By default, Cisco IP Phones mark voice bearer traffic with a CoS of 5 and voice signaling traffic with a CoS value of 3. The Catalyst 6500 places traffic marked with a CoS value of 5 into the priority queue on 1p2q2t interfaces and Queue 2 on 2q2t interfaces when QoS is enabled.
However, you must perform the additional step of configuring the Catalyst 6500 CoS queue mapping to ensure that traffic with a CoS of 3 is placed into the second queue.
Example 10-11 maps call control traffic, a CoS value of 3, to Queue 2 threshold 1 on a 2q2t interface.
Example 10-11 Map CoS Value of 3 to Queue 2 Threshold 1 for 2q2t
Cat65k> (enable) set qos map 2q2t tx 2 1 cos 3
QoS tx priority queue and threshold mapped to cos successfully.
Cat65k> (enable)
Example 10-12 shows call control traffic, a CoS value of 3, to Queue 2 threshold 1 on a 1p2q2t interface.
Example 10-12 Map CoS Value of 3 to Queue 2 Threshold 1 for 1p2q2t
Cat65k> (enable) set qos map 1p2q2t tx 2 1 cos 3
QoS tx priority queue and threshold mapped to cos successfully.
Cat65k> (enable)
Unlike the Catalyst 6500, the Catalyst 4000 places all packets, regardless of CoS values, in the first queue after QoS has been enabled. Also the Catalyst 4000 must map CoS values to a queue in pairs. In Example 10-13, CoS values of 0 and 1 have been mapped to Queue 1, whereas CoS values of 2 through 7 have been mapped to Queue 2.
QoS Configurations on Catalyst Switches 727
Example 10-13 Mapping CoS Values 2 Through & to Queue 2 Threshold 1
Cat4k> (enable) set qos map 2q1t 1 1 cos 0-1
Cat4k> (enable) set qos map 2q1t 2 1 cos 2-3
Cat4k> (enable) set qos map 2q1t 2 1 cos 4-5
Cat4k> (enable) set qos map 2q1t 2 1 cos 6-
Layer-2-to-Layer 3 Mapping
Cisco follows the recommended standard for setting the DSCP classification values for both the VoIP call control traffic and VoIP bearer traffic. The recommended settings are DSCP = AF31 (or decimal 26) for VoIP call control and DSCP = EF (or decimal 46) for VoIP bearer traffic. By default, the CoS-to-DSCP mapping does not match this recommendation, as shown in Table 10-21.
Table 10-21 Default CoS-to-DSCP Mapping
CoS Value |
DSCP Value |
|
|
0 |
0 |
|
|
1 |
8 |
|
|
2 |
16 |
|
|
3 |
24 |
|
|
4 |
32 |
|
|
5 |
40 |
|
|
6 |
48 |
|
|
7 |
56 |
|
|
To map the Layer 2 CoS and Layer 3 IP precedence settings correctly to these DSCP values, you must modify the default CoS/ToS-to-DSCP mappings.
Example 10-14 demonstrates the configuration required for the CoS-to-DSCP mappings.
Example 10-14 Modifying the CoS-to-DSCP Mappings
CatOS> (enable) set qos cos-dscp-map 0 8 16 26 34 46 48 56
QoS cos-dscp-map set successfully.
CatOS> (enable)
728 Chapter 10: LAN QoS
Example 10-15 demonstrates the configuration required for the IP precedence-to-DSCP mappings.
Example 10-15 Modifying the IP Precedence-to-DSCP Mappings
CatOS> (enable) set qos ipprec-dscp-map 0 8 16 26 32 46 48 56
QoS ipprec-dscp-map set successfully.
Console > (enable)
Configuring Trust Boundaries for a Catalyst OS Switch
Trust boundaries define the point in the network where CoS, IP precedence, or DSCP markings are trusted. Typically this trust is established at the ingress switch port of the access layer switch. After QoS has been enabled, all ports on a Catalyst 6500 are in the untrusted state. This means that any CoS value received by the switch is re-marked with a value of 0. By contrast, after QoS has been enabled on a Catalyst 4000 switch, all ports are in a trusted state, meaning that all CoS values received are trusted on every port. Therefore, the rest of this section discussing trust excludes the Catalyst 4000.
Example 10-16 demonstrates the configuration required to instruct the Catalyst 6500 access layer switch to trust the CoS values received on the 802.1Q trunks that connect to the IP Phones.
Example 10-16 Enabling Trust of CoS
CatOS> (enable) set port qos 2/1-48 trust trust-cos
Trust type trust-cos not supported on port(s) 2/1-48
Receive thresholds enabled on ports(s) 2/1-48
Trust type set to untrusted on port(s) 2/1-48
CatOS> (enable)
On all 63xx series 10/100 Ethernet line cards with 1q4t ports, the trust-cos port keyword displays an error message stating that trust-cos is not supported. This configuration must be entered to activate the receive queue drop thresholds; however, the trust state of the ports will remain untrusted. You must configure a trust-cos ACL to match the ingress traffic to successfully apply the trust-cos trust state. This ACL is discussed in the “Configuring QoS Access Lists on a Catalyst OS Switch” section. The 65xx series 10/100 Ethernet line cards do not have this issue.
A Layer 3 6500 switch offers the capability to classify traffic flows based on IP header information, such as IP precedence and DSCP markings. This can prove useful for end devices that do not have the capability to use 802.1Q or ISL trunks, but can manipulate the IP header fields. In Figure 10-11, CallManager 1 is connected to port 5/1, and CallManager 2 is connected to port 5/2. Either of the following configurations shown in Examples 10-17 or 10-18 can be added to the switch to prioritize CallManager traffic using IP hearer information.
QoS Configurations on Catalyst Switches 729
Example 10-17 Enabling Trust of DSCP
CatOS> (enable) set port qos 5/1-2 trust trust-dscp
Port 5/1-2 qos set to trust-dscp.
CatOS> (enable)
Example 10-18 Enabling Trust of IP Precedence
CatOS> (enable) set port qos 5/1-2 trust trust-ipprec
Port 5/1-2 qos set to trust-ipprec.
CatOS> (enable)
The trust-ipprec and trust-dscp keywords are supported only with a Layer 3 switching engine.
Although the trust command determines whether the received markings are trusted on the ingress switch port, the trust-ext command has little to do with the ingress switch port. The trust-ext command determines how the ASIC on the IP Phone handles the CoS value presented by the attached PC. If the trust-ext command is trusted, the original CoS value presented by the PC to the phone is passed to the switch intact. If the trust-ext command is untrusted, the CoS value presented by the PC is rewritten to a value of 0.
In a typical IP telephony deployment, trust should not be extended to a PC. Be cautious if your design includes extending trust to a PC. If you trust one application on a PC, by default you trust all applications on that PC. This can lead to unintentional voice-quality degradation. Example 10-19 shows the trust-ext configuration of a typical IP telephony deployment.
Example 10-19 Configuring trust-ext
CatOS> (enable) set port qos 2/1-48 trust-ext untrusted
Qos trust extension for ports 2/1-48 set to untrusted.
CatOS> (enable)
Configuring Untagged Frames for the Catalyst OS Switch
What if the end device does not support 802.1Q or ISL trunks? How do you prioritize the traffic of this device? The addition of a Layer 3 switching engine allows the Catalyst to use IP precedence or DSCP to classify this traffic, but what if you do not have a Layer 3 switching engine or you would still prefer to mark the traffic with a CoS value?
You can achieve this by setting the CoS value on the ingress switch port. By doing this, you are telling the switch to mark any frame received on this port with a specific CoS value. Even though the actual received frame may not have even had an ISL or 802.1Q header, the switch can process the frame as if it had a CoS value set, based on configuration. In the sample network, for instance, CallManager 1 is connected to port 5/1, and CallManager 2 is connected to port 5/2. Example 10-20’s configuration can be added to the switch to prioritize CallManager traffic by setting any inbound traffic received on ports 5/1 or 5/2 to a CoS value of 3.
730 Chapter 10: LAN QoS
Example 10-20 Assigning a CoS Value to a Specific Port
CatOS> (enable) set port qos 5/1-2 cos 3
Port 5/1-2 qos cos set to 3
CatOS> (enable)
Because this CoS value is assigned to the port, there is no regard for the end device connected to this port. In other words, any device connected to ports 5/1 or 5/2 receive the configured CoS value. Additionally, all traffic from that end device receive this CoS value. In this configuration, for example, web browsing from the CallManager server receives the same priority across your network as call control traffic. For this reason, it is recommended just to trust DSCP on ports connected to a CallManager, allowing the CallManager to identify the proper QoS classification
To remove the CoS value applied to a specific port, use the clear port qos command, as shown in Example 10-21.
Example 10-21 Clearing a CoS Value from a Specific Port
CatOS> (enable) clear port qos 5/1-2 cos
Port 5/1-2 qos cos setting cleared.
CatOS> (enable)
Configuring QoS Access Lists in the Catalyst OS Switch
As discussed in the “Configuring Trust Boundaries for a Catalyst OS Switch” section, the 63xx series line cards with 1q4t ports do not apply the trust-cos trust state to ingress traffic. An ACL must be configured to enable the port to trust the received CoS values. The set qos acl command is used to accomplish this task. Example 10-22 demonstrates the configuration of a QoS ACL.
Example 10-22 Configuring a QoS ACL
Cat65k> (enable) set qos acl ip IP-PHONES trust-cos any
IP_PHONES editbuffer modified. Use 'commit' command to apply changes.
Cat65k> (enable)
In this example, a QoS access list named IP-PHONES was created. The IP-PHONES QoS ACL is configured to trust the CoS value from any device.
After the ACL has been created, it must be committed to hardware. QoS ACLs reside in hardware ASICs for optimum performance. The commit qos acl command enables you to accomplish this task. Example 10-23 demonstrates the configuration required to commit a QoS ACL to hardware.