Implementing Cisco QoS

QoS
Ìmplementing Cisco Quality of

Service (QOS) v2.0
Student Guide
Version 2.0
© 2004 KnowledgeNet.com, Ìnc. All Rights Reserved.
KNOWLEDGENET is a registered trademark; and the K DESÌGN and THE BEST OF A NEW BREED are trademarks of
KnowledgeNet.com, Ìnc. All other trademarks are the property of their respective companies.
Copyright © 2004, KnowledgeNet.com, Ìnc. All rights reserved. Ìmplementing Cisco Quality of Service (QOS) v2.0 i
MODULE 1 - INTRODUCTION TO IP QOS 1-1
Overview 1-1
Module Objectives 1-2
Outline 1-2
LESSON ONE: THE NEED FOR QOS 1-3
Overview 1-3
Objectives 1-4
Outline 1-5
Converged Networks 1-6
Converged Networks Quality Ìssues 1-8
Available Bandwidth 1-10
End-to-End Delay 1-12
Packet Loss 1-17
Summary 1-19
Quiz 1-20
LESSON TWO: UNDERSTANDING QOS 1-23
Overview 1-23
Objectives 1-23
Outline 1-24
QoS Defined 1-25
QoS for Converged Networks 1-26
QoS Requirements 1-27
QoS Traffic Classes 1-31
QoS Policy 1-32
Summary 1-35
Quiz 1-36
LESSON THREE: IMPLEMENTING IP QOS 1-39
Overview 1-39
Objectives 1-39
Outline 1-41
Methods for Ìmplementing QoS Policy 1-42
Legacy CLÌ 1-43
Modular QoS CLÌ 1-44
AutoQoS 1-45
QoS Ìmplementation Methods Compared 1-46
QoS Policy Manager 1-47
Network Management MÌBs for Monitoring QoS 1-49
MÌBs for Managing QoS 1-50
Summary 1-53
Quiz 1-54
MODULE ASSESSMENT 1-57
Overview 1-57
Quiz: Ìntroduction to ÌP QoS 1-58
Module Assessment Answer Key 1-61
MODULE SUMMARY 1-63
MODULE 2 - THE BUILDING BLOCKS OF IP QOS 2-1
Overview 2-1
Outline 2-2
LESSON ONE: MODELS FOR IMPLEMENTING QOS 2-3
ii Ìmplementing Cisco Quality of Service (QOS) v2.0 Copyright © 2003, KnowledgeNet.com, Ìnc. All rights reserved.
Overview 2-3
Objectives 2-4
Outline 2-5
QoS Models 2-6
Best-Effort Model 2-7
Ìntegrated Services Model 2-9
Differentiated Services Model 2-14
Summary 2-17
Quiz 2-18
LESSON TWO: THE DIFFERENTIATED SERVICES MODEL 2-21
Overview 2-21
Objectives 2-21
Outline 2-22
Differentiated Services Model 2-23
DSCP Encoding 2-25
Per-Hop Behaviors 2-26
Backward Compatibility Using the Class Selector 2-31
Summary 2-32
Quiz 2-33
LESSON THREE: IP QOS MECHANISMS 2-37
Overview 2-37
Objectives 2-37
Outline 2-38
QoS Mechanisms 2-39
Classification 2-40
Marking 2-42
Congestion Management 2-43
Congestion Avoidance 2-45
Policing and Shaping 2-46
Compression 2-48
Link Fragmentation and Ìnterleaving 2-49
Applying QoS to Ìnput and Output Ìnterfaces 2-50
Summary 2-51
Quiz 2-52
LESSON FOUR: CASE STUDY: QOS MECHANISMS 2-55
Overview 2-55
Objectives 2-55
Outline 2-56
Review Customer QoS Requirements 2-58
Ìdentify QoS Service Class Requirements 2-60
Ìdentify Network Locations Where QoS Mechanisms Should Be Applied 2-61
Present Your Solution 2-64
LESSON FIVE: CASE STUDY: THE LIFE OF A PACKET 2-69
Overview 2-69
Objectives 2-69
Outline 2-70
Overview 2-71
Life of a High-Priority (VoÌP) Packet 2-72
Life of a Low-Priority (FTP) Packet 2-81
Summary 2-91
Overview 2-93
Quiz: The Building Blocks of ÌP QoS 2-94
Copyright © 2004, KnowledgeNet.com, Ìnc. All rights reserved. Ìmplementing Cisco Quality of Service (QOS) v2.0 iii
MODULE SUMMARY 2-99
MODULE 3 - INTRODUCTION TO MODULAR QOS CLI AND AUTOQOS 3-1
Overview 3-1
Outline 3-2
LESSON ONE: INTRODUCING MODULAR QOS CLI 3-3
Overview 3-3
Objectives 3-3
Outline 3-4
Modular QoS CLÌ 3-5
Modular QoS CLÌ Components 3-6
Class Maps 3-7
Configuring and Monitoring Class Maps 3-9
Policy Maps 3-13
Configuring and Monitoring Policy Maps 3-14
Service Policy 3-21
Attaching Service Policies to Ìnterfaces 3-22
Summary 3-24
Quiz 3-25
LESSON TWO: INTRODUCING AUTOQOS 3-29
Overview 3-29
Objectives 3-30
Outline 3-30
AutoQoS 3-31
AutoQoS: Router Platforms 3-35
AutoQoS: Switch Platforms 3-36
Configuring AutoQoS 3-38
Monitoring AutoQoS 3-47
Automation with Cisco AutoQoS 3-53
Summary 3-54
Quiz 3-56
Overview 3-59
Quiz: Ìntroduction to Modular QoS CLÌ and AutoQoS 3-60
MODULE SUMMARY 3-63
MODULE 4 - CLASSIFICATION AND MARKING 4-1
Overview 4-1
Outline 4-2
LESSON ONE: CLASSIFICATION AND MARKING OVERVIEW 4-3
Overview 4-3
Objectives 4-4
Outline 4-5
Classification 4-6
Marking 4-7
Classification and Marking at the Link Layer 4-8
Classification and Marking at the Network Layer 4-13
iv Ìmplementing Cisco Quality of Service (QOS) v2.0 Copyright © 2003, KnowledgeNet.com, Ìnc. All rights reserved.
Mapping CoS to Network Layer QoS 4-14
QoS Service Class Defined 4-16
Ìmplementing a QoS Policy Using a QoS Service Class 4-18
Trust Boundaries 4-21
Summary 4-23
Quiz 4-24
LESSON TWO: CASE STUDY: CLASSIFICATION AND MARKING 4-27
Overview 4-27
Objectives 4-27
Outline 4-28
Ìdentify Network Locations Where Classification and Marking Should be
Applied
4-36
LESSON THREE: USING MQC FOR CLASSIFICATION 4-41
Overview 4-41
Objectives 4-42
Outline 4-43
MQC Classification Options 4-44
Configuring Classification with MQC 4-46
Configuring Classification Using Ìnput Ìnterface 4-49
Configuring Classification Using CoS 4-50
Configuring Classification Using Access Lists 4-51
Configuring Classification Using ÌP Precedence 4-53
Configuring Classification Using DSCP 4-54
Configuring Classification Using a UDP Port Range 4-58
Monitoring Class Maps 4-59
Summary 4-60
Quiz 4-61
LESSON FOUR: USING MQC FOR CLASS-BASED MARKING 4-65
Overview 4-65
Objectives 4-66
Outline 4-67
Class-Based Marking Overview 4-68
MQC Marking Options 4-69
Configuring Class-Based Marking 4-70
Configuring Class-Based Marking 4-72
Configuring ÌP Precedence Marking 4-73
Configuring ÌP DSCP Marking 4-74
Monitoring Class-Based Marking 4-75
Summary 4-78
Quiz 4-79
LESSON FIVE: USING NBAR FOR CLASSIFICATION 4-83
Overview 4-83
Objectives 4-84
Outline 4-85
Network Based Application Recognition 4-86
NBAR Application Support 4-88
Packet Description Language Module 4-92
Protocol Discovery 4-93
Configuring and Monitoring Protocol Discovery 4-95
Configuring NBAR for Static Protocols 4-97
Configuring NBAR for Stateful Protocols 4-100
Summary 4-105
Copyright © 2004, KnowledgeNet.com, Ìnc. All rights reserved. Ìmplementing Cisco Quality of Service (QOS) v2.0 v
Quiz 4-106
LESSON SIX: CONFIGURING QOS PRE-CLASSIFY 4-109
Overview 4-109
Objectives 4-110
Outline 4-111
Ìmplementing QoS with Pre-Classification 4-112
QoS Pre-Classify Applications 4-113
QoS Pre-Classify Deployment Options 4-117
Configuring QoS Pre-Classify 4-119
Monitoring QoS Pre-Classify 4-122
Summary 4-124
Quiz 4-125
LESSON SEVEN: CONFIGURING QOS POLICY PROPAGATION
THROUGH BGP
4-127
Overview 4-127
Objectives 4-127
Outline 4-128
QoS Policy Propagation Through BGP 4-129
ÌP QoS and BGP Ìnteraction 4-131
Cisco Express Forwarding 4-132
QPPB Configuration Tasks 4-136
Summary 4-150
Quiz 4-151
LESSON EIGHT: CONFIGURING LAN CLASSIFICATION AND MARKING 4-153
Overview 4-153
Objectives 4-154
Outline 4-154
LAN Classification and Marking 4-155
QoS Trust Boundaries 4-156
LAN Classification and Marking Platforms 4-159
Configuring LAN-Based Classification and Marking 4-171
Monitoring LAN-Based Classification and Marking 4-186
Summary 4-188
Quiz 4-189
Overview 4-191
Quiz: Classification and Marking 4-192
MODULE SUMMARY 4-195
MODULE 5 - CONGESTION MANAGEMENT 5-1
Overview 5-1
Outline 5-2
LESSON ONE: INTRODUCTION TO QUEUING 5-3
Overview 5-3
Objectives 5-3
Outline 5-4
Congestion and Queuing 5-5
Queuing Algorithms 5-8
FÌFO 5-9
vi Ìmplementing Cisco Quality of Service (QOS) v2.0 Copyright © 2003, KnowledgeNet.com, Ìnc. All rights reserved.
Priority Queuing 5-10
Round Robin 5-11
Weighted Round Robin 5-12
Deficit Round Robin 5-14
Summary 5-15
Quiz 5-16
LESSON TWO: QUEUING IMPLEMENTATIONS 5-19
Overview 5-19
Objectives 5-19
Outline 5-20
Queuing Components 5-21
Hardware Queue (TxQ) Size 5-24
Congestion on Software Ìnterfaces 5-26
Queuing Ìmplementations in Cisco ÌO 5-27
Summary 5-28
Quiz 5-29
LESSON THREE: FIFO AND WFQ 5-31
Overview 5-31
Objectives 5-31
Outline 5-32
FÌFO Queuing 5-33
Weighted Fair Queuing 5-35
WFQ Classification 5-38
WFQ Ìnsertion and Drop Policy 5-41
WFQ Scheduling 5-43
Benefits and Drawbacks of WFQ 5-51
Configuring WFQ 5-52
Monitoring WF 5-55
Summary 5-57
Quiz 5-58
LESSON FOUR: CBWFQ AND LLQ 5-61
Overview 5-61
Objectives 5-62
Outline 5-63
CBWFQ and LLQ 5-64
CBWFQ 5-65
CBWFQ Architecture 5-66
CBWFQ Benefits 5-72
Configuring and Monitoring CBWFQ 5-73
LLQ 5-78
LLQ Architecture 5-80
LLQ Benefits 5-81
Configuring and Monitoring LLQ 5-82
Summary 5-88
Quiz 5-89
LESSON FIVE: LAN CONGESTION MANAGEMENT 5-93
Overview 5-93
Objectives 5-93
Outline 5-94
Queuing on Catalyst Switches 5-95
Weighted Round Robin 5-101
Configuring PQ on Catalyst 2950 Switches 5-103
Configuring WRR on Catalyst 2950 Switches 5-104
Monitoring Queuing on Catalyst 2950 Switches 5-106
Summary 5-109
Copyright © 2004, KnowledgeNet.com, Ìnc. All rights reserved. Ìmplementing Cisco Quality of Service (QOS) v2.0 vii
Quiz 5-111
Overview 5-115
Quiz: Congestion Management 5-116
MODULE SUMMARY 5-121
MODULE 6 - CONGESTION AVOIDANCE 6-1
Overview 6-1
Outline 6-2
LESSON ONE: INTRODUCTION TO CONGESTION AVOIDANCE 6-3
Overview 6-3
Objectives 6-3
Outline 6-4
Behavior of TCP Senders and Receivers 6-5
Congestion and TCP 6-7
Managing Ìnterface Congestion with Tail Drop 6-9
Tail-Drop Limitations 6-10
Summary 6-13
Quiz 6-14
LESSON TWO: INTRODUCTION TO RED 6-17
Overview 6-17
Objectives 6-17
Outline 6-18
Random Early Detection 6-19
RED Profiles 6-20
RED Modes 6-22
TCP Traffic Before and After RED 6-23
Applying Congestion Avoidance 6-25
Summary 6-26
Quiz 6-27
LESSON THREE: CONFIGURING CLASS-BASED WEIGHTED RED 6-31
Overview 6-31
Objectives 6-31
Outline 6-32
Weighted Random Early Detection 6-33
WRED Profiles 6-37
Configuring CB-WRED 6-42
Configuring DSCP-Based CB-WRED 6-49
Monitoring CB-WRED 6-54
Summary 6-55
Quiz 6-56
LESSON FOUR: CASE STUDY: WRED TRAFFIC PROFILES 6-61
Overview 6-61
Objectives 6-61
Outline 6-62
Create WRED Traffic Profiles 6-66
viii Ìmplementing Cisco Quality of Service (QOS) v2.0 Copyright © 2003, KnowledgeNet.com, Ìnc. All rights reserved.
LESSON FIVE: CONFIGURING EXPLICIT CONGESTION NOTIFICATION 6-73
Overview 6-73
Objectives 6-73
Outline 6-74
Explicit Congestion Notification 6-75
ECN Field Defined 6-76
ECN and WRED 6-77
Configuring ECN-Enabled WRED 6-79
Monitoring ECN-Enabled WRED 6-80
Summary 6-83
Quiz 6-84
Overview 6-87
Quiz: Congestion Avoidance 6-88
MODULE SUMMARY 6-95
MODULE 7 - TRAFFIC POLICING AND SHAPING 7-1
Overview 7-1
Outline 7-2
LESSON ONE: TRAFFIC POLICING AND TRAFFIC SHAPING OVERVIEW 7-3
Overview 7-3
Objectives 7-4
Outline 7-5
Traffic Policing and Shaping Overview 7-6
Why Use Traffic Conditioners? 7-7
Policing vs. Shaping 7-11
Measuring Traffic Rates 7-12
Single Token Bucket Class-Based Policing 7-14
Dual Token Bucket Class-Based Policing 7-15
Dual-Rate Token Bucket Class-Based Policing 7-18
Class-Based Traffic Shaping 7-21
Cisco ÌOS Traffic Policing and Shaping Mechanisms 7-22
Applying Traffic Conditioners 7-24
Summary 7-25
Quiz 7-26
LESSON TWO: CONFIGURING CLASS-BASED POLICING 7-29
Overview 7-29
Objectives 7-30
Outline 7-31
Class-Based Policing Overview 7-32
Configuring Single-Rate Class-Based Policing 7-34
Configuring Dual-Rate Class-Based Policing 7-38
Configuring Percentage-Based Class-Based Policing 7-40
Monitoring Class-Based Policing 7-42
Summary 7-43
Quiz 7-44
LESSON THREE: CONFIGURING CLASS-BASED SHAPING 7-47
Overview 7-47
Objectives 7-47
Outline 7-48
Copyright © 2004, KnowledgeNet.com, Ìnc. All rights reserved. Ìmplementing Cisco Quality of Service (QOS) v2.0 ix
Class-Based Shaping Overview 7-49
Traffic Shaping Methods 7-50
Configuring Class-Based Shaping 7-51
Monitoring Class-Based Shaping 7-57
Summary 7-59
Quiz 7-60
LESSON FOUR: CONFIGURING CLASS-BASED SHAPING ON FRAME
RELAY INTERFACES
7-63
Overview 7-63
Objectives 7-63
Outline 7-64
Frame Relay Refresher 7-65
Frame Relay Congestion Control 7-66
Frame Relay Congestion Adaptation 7-67
FECN to BECN Propagation 7-68
Configuring Frame Relay Adaptive Class-Based Shaping 7-69
Monitoring Class-Based Shaping with FR Adaptation 7-71
Summary 7-72
Quiz 7-73
Overview 7-77
Quiz: Traffic Policing and Shaping 7-78
MODULE SUMMARY 7-83
MODULE 8 - LINK EFFICIENCY MECHANISMS 8-1
Overview 8-1
Outline 8-2
LESSON ONE: LINK EFFICIENCY MECHANISMS OVERVIEW 8-3
Overview 8-3
Objectives 8-4
Outline 8-4
Link Efficiency Mechanisms Overview 8-5
L2 Payload Compression 8-8
Header Compression 8-10
Large Packets ¨Freeze Out¨ Voice on Slow WAN Links 8-13
Link Fragmentation and Ìnterleaving 8-15
Applying Link Efficiency Mechanisms 8-16
Summary 8-17
Quiz 8-18
LESSON TWO: CLASS-BASED HEADER COMPRESSION 8-21
Overview 8-21
Objectives 8-22
Outline 8-22
Header Compression Overview 8-23
Class-Based TCP Header Compression 8-25
Class-Based RTP Header Compression 8-28
Configuring Class-Based Header Compression 8-31
Monitoring Class-Based Header Compression 8-34
Summary 8-35
Quiz 8-36
x Ìmplementing Cisco Quality of Service (QOS) v2.0 Copyright © 2003, KnowledgeNet.com, Ìnc. All rights reserved.
LESSON THREE: LINK FRAGMENTATION AND INTERLEAVING 8-39
Overview 8-39
Objectives 8-40
Outline 8-40
Fragmentation Options 8-41
Serialization Delay and Fragment Sizing 8-42
Configuring MLP with Ìnterleaving 8-44
Monitoring MLP with Ìnterleaving 8-47
FRF.12 Frame Relay Fragmentation 8-49
Configuring FRF.12 Frame Relay Fragmentation 8-51
Monitoring FRF.12 Frame Relay Fragmentation 8-53
Summary 8-55
Quiz 8-56
Overview 8-59
Quiz: Link Efficiency Mechanisms 8-60
MODULE SUMMARY 8-65
MODULE 9 - QOS BEST PRACTICES 9-1
Overview 9-1
Outline 9-2
LESSON ONE: TRAFFIC CLASSIFICATION BEST PRACTICES 9-3
Overview 9-3
Objectives 9-3
Outline 9-4
QoS Best Practices 9-5
Voice/Video/Data QoS Requirements 9-10
QoS Requirements Summary 9-17
Traffic Classification 9-18
Enterprise to Service Provider QoS Class Mapping 9-24
Summary 9-27
Quiz 9-28
LESSON TWO: CASE STUDY: DEPLOYING END-TO-END QOS 9-33
Overview 9-33
Objectives 9-34
Outline 9-34
QoS Service Level Agreements 9-35
Deploying End-to-End QoS Case Study Ìntroduction 9-41
Enterprise Campus QoS Ìmplementations 9-43
WAN Edge (CE/PE) QoS Ìmplementations 9-52
Service Provider Backbone QoS Ìmplementations 9-63
Summary 9-71
Quiz 9-73
Overview 9-77
Quiz: Ìntroduction to ÌP QoS 9-78
MODULE SUMMARY 9-83
Copyright © 2004, KnowledgeNet.com, Ìnc. All rights reserved. Ìmplementing Cisco Quality of Service (QOS) v2.0 xi
QOS
Course Ìntroduction
Overview
Implementing Cisco Quality of Service (QOS) v2.0 provides students with in-depth knowledge
oI IP quality oI service (QoS) requirements, conceptual models such as Best EIIort, Integrated
Services (IntServ) and DiIIerentiated Services (DiIIServ), and the implementation oI IP QoS on
Cisco IOS platIorms.
The curriculum covers the theory oI IP QoS, design issues, and conIiguration oI various QoS
mechanisms to Iacilitate the creation oI eIIective administrative policies providing QoS. Case
studies and lab exercises included in the course help students apply the concepts that are
mastered in individual modules to real-liIe scenarios.
The course also gives students design and usage rules Ior various advanced IP QoS Ieatures and
the integration oI IP QoS with underlying Layer 2 QoS mechanisms, allowing them to design
and implement eIIicient, optimal, and trouble-Iree multiservice networks.
2 Ìmplementing Cisco Quality of Service (QOS) v2.0 Copyright © 2003, Cisco Systems, Ìnc.
Course GoaI and Objectives
This section describes the course goal and objectives.
Upon completing this course, you will be able to meet these objectives:
Explain the need to implement QoS and explain methods Ior implementing and managing
QoS
IdentiIy and describe diIIerent models used Ior ensuring QoS in a network and explain key
IP QoS mechanisms used to implement the models
Explain the use oI MQC and AutoQoS to implement QoS on the network
ClassiIy and mark network traIIic to implement a policy deIining QoS requirements
Use Cisco QoS queuing mechanisms to manage network congestion
Use Cisco QoS congestion avoidance mechanisms to reduce the eIIects oI congestion on
the network
Use Cisco QoS traIIic policing and traIIic shaping mechanisms to eIIectively limit the rate
oI network traIIic
Use Cisco link eIIiciency mechanisms to improve the bandwidth eIIiciency oI low-speed
WAN links
Correctly select the most appropriate QoS mechanisms Ior providing QoS using Cisco
'best practices¨ in service provider and enterprise networks
© 2003, Cisco Systems, Inc. AII rights reserved. QOS v2.0-4
Course GoaI
"To identify, describe, and correctIy
impIement the appropriate QoS
mechanisms required to create an
effective administrative poIicy providing
QoS."
Implementing Cisco Quality of
Service (QOS)
Copyright © 2003, Cisco Systems, Ìnc. Course Ìntroduction 3
Course OutIine
The outline lists the modules included in this course.
Course OutIine
· Introduction to IP QoS
· The BuiIding BIocks of IP QoS
· Introduction to ModuIar QoS CLI and AutoQoS
· CIassification and Marking
· Congestion Management
· Congestion Avoidance
· Traffic PoIicing and Shaping
· Link Efficiency Mechanisms
· QoS Best Practices
Cisco Certifications
This topic discusses Cisco career certiIications and paths.
Cisco provides three levels oI general career certiIications Ior IT proIessionals with several
diIIerent tracks to meet individual needs. Cisco also provides Iocused Cisco QualiIied
Specialist (CQS) certiIications Ior designated areas such as cable communications, voice, and
security.
There are many paths to Cisco certiIication, but only one requirementpassing one or more
exams demonstrating knowledge and skill. For details, go to
http://www.cisco.com/go/certiIications.
Cisco Certifications
Learner SkiIIs and KnowIedge
This topic lists the course prerequisites.
To beneIit Iully Irom this lesson, you must have these prerequisite skills and knowledge:
Completion oI the Interconnecting Cisco Networking Devices (ICND) course or Cisco
CCNA
®
certiIication.
Prerequisite Learner SkiIIs
and KnowIedge
Interconnecting Cisco
Networking Devices
(ICND)
or
Cisco Certified
Networking Associate
(CCNA)
Interconnecting Cisco
Networking Devices
(ICND)
or
Cisco Certified
Networking Associate
(CCNA)
Implementing Cisco Quality
of Service (QOS)
Implementing Cisco Quality
of Service (QOS)
Learner ResponsibiIities
This topic discusses the responsibilities oI the learners.
To take Iull advantage oI the inIormation presented in this course, you must have completed the
prerequisite requirements.
In class, you are expected to participate in all lesson exercises and assessments.
In addition, you are encouraged to ask any questions relevant to the course materials.
II you have pertinent inIormation or questions concerning Iuture Cisco product releases and
product Ieatures, please discuss these topics during breaks or aIter class. The instructor will
answer your questions or direct you to an appropriate inIormation source.
Learner ResponsibiIities
· CompIete
prerequisites
· Introduce
yourseIf
· Ask questions
GeneraI Administration
This topic lists the administrative issues Ior the course.
The instructor will discuss these administrative issues:
Sign-in process
Starting and anticipated ending times oI each class day
Class breaks and lunch Iacilities
Appropriate attire during class
Materials that you can expect to receive during class
What to do in the event oI an emergency
Location oI the rest rooms
How to send and receive telephone and Iax messages
GeneraI Administration
CIass-ReIated
· Sign-in sheet
· Length and times
· Break and Iunchroom
Iocations
· Attire
FaciIities-ReIated
· Course materiaIs
· Site emergency
procedures
· Rest rooms
· TeIephones/faxes
Course FIow
This topic covers the suggested Ilow oI the course materials.
The schedule reIlects the recommended structure Ior this course. This structure allows enough
time Ior the instructor to present the course inIormation and Ior you to work through the
laboratory exercises. The exact timing oI the subject materials and labs depends on the pace oI
your speciIic class.
Course FIow
Congestion
Management
(Cont.)
Course
Introduction
Introduction
to IP QoS
BuiIding BIocks
of IP QoS
Traffic
PoIicing and
Shaping
Lunch
Introduction to
ModuIar QoS
CLI and
AutoQoS (Cont.)
Congestion
Avoidance
Link Efficiency
Mechanisms
A
M
P
M
Congestion
Management
QoS Best
Practices
Day 1 Day 2 Day 3 Day 4 Day 5
BuiIding
BIocks of IP
QoS (Cont.)
Introduction
to MModuIar
QoS CLI and
AutoQoS
CIassification
and Marking
CIassification
and Marking
(Cont.)
CIassification
and Marking
(Cont.)
Icons and SymboIs
This topic shows the Cisco icons and symbols used in this course.
Cisco Icons and SymboIs
Router
TerminaI
Server
100BaseT
Hub
Workgroup
Switch:
CoIor/Subdued
Network
CIoud,
White
PC
Network
CIoud,
Standard
CoIor
Camera
PC/Video
IP Phone
Learner Introductions
This is the point in the course where you introduce yourselI.
Prepare to share the Iollowing inIormation:
Your name
Your company
II you have most or all oI the prerequisite skills
A proIile oI your experience
What you would like to learn Irom this course
Learner Introductions
· Your name
· Your
company
· SkiIIs and
knowIedge
· Brief history
· Objective
Course EvaIuations
Cisco relies on customer Ieedback to make improvements and guide business decisions. Your
valuable input will help shape Iuture Cisco learning products and program oIIerings.
On the Iirst and Iinal days oI class, your instructor will provide the Iollowing inIormation
needed to Iill out the evaluation:
Course acronym (printea on stuaent kit siae label) ¸¸¸¸¸¸¸¸¸¸
Course version number (printea on stuaent kit siae label) ¸¸¸¸¸¸¸¸¸¸
Cisco Learning Partner ID # ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Instructor ID # ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Course ID # (for courses registerea in Cisco Learning Locator) ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Please use this inIormation to complete a brieI (approximately 10 minutes) online evaluation
concerning your instructor and the course materials in the student kit. To access the evaluation,
go to http://www.cisco.com/go/clpevals.
AIter the completed survey has been submitted, you will be able to access links to a variety oI
Cisco resources, including inIormation on the Cisco Career CertiIication programs and Iuture
Cisco Networkers events.
II you encounter any diIIiculties accessing the course evaluation URL or submitting your
evaluation, please contact Cisco via email at clpevals¸support¸external.cisco.com.
Course EvaIuations
ModuIe 1
Ìntroduction to ÌP QoS
Overview
As user applications continue to drive network growth and evolution, demands to support
diIIerent types oI traIIic is also increasing. DiIIerent types oI applications with diIIering
network requirements create a need Ior administrative policies mandating how individual
applications are to be treated by the network. Network traIIic Irom business-critical
applications must be protected Irom other types oI traIIic. Requests Irom business-critical and
delay-sensitive applications must be serviced with priority. The employment and enIorcement
oI quality oI service (QoS) policies within a network plays an essential role in enabling network
administrators and architects to meet networked application demands. QoS is a crucial element
oI any administrative policy that mandates how to handle application traIIic on a network. This
module introduces the concept oI QoS, explains key issues oI networked applications, and
describes diIIerent methods Ior implementing QoS.
1-2 Ìmplementing Cisco Quality of Service (QOS) v2.0 Copyright © 2003, Cisco Systems, Ìnc.
ModuIe Objectives
Upon completing this module, you will be able to explain the need to implement QoS and
explain methods Ior implementing and managing QoS.
ModuIe OutIine
The outline lists the components oI this module.
© 2003, Cisco Systems, Inc. AII rights reserved. QOS v2.0-1-3
ModuIe Objectives
· Identify probIems that couId Iead to poor quaIity
of service and expIain how the probIems might
be resoIved
· Define the term QoS and identify and expIain the
key steps to impIementing QoS on a converged
network
· List and describe methods for impIementing
QoS
ModuIe OutIine
· The Need for QoS
· Understanding QoS
· ImpIementing IP QoS
The Need for QoS
Overview
A communications network Iorms the backbone oI any successIul organization. These
networks transport a multitude oI applications and data, including high-quality video and delay-
sensitive data such as real-time voice. Bandwidth-intensive applications stretch network
capabilities and resources, but also complement, add value, and enhance every business
process. Networks must provide secure, predictable, measurable, and sometimes guaranteed
services. Achieving the required QoS by managing delay, delay variation (jitter), bandwidth,
and packet loss parameters on a network becomes the secret to a successIul end-to-end business
solution. QoS is the set oI techniques used to manage network resources.
ReIevance
With the emergence oI networks incorporating many types oI traIIic with diIIerent
requirements, QoS has become an essential component oI networking. As more converged
networks are implemented, QoS becomes more important.
Objectives
Upon completing this lesson, you will be able to identiIy problems that could lead to poor
quality oI service and explain how the problems might be resolved. This includes being able to
meet these objectives:
Describe a converged IP network supporting voice, video, and data traIIic
IdentiIy the Iour key quality issues with converged networks
Explain how a lack oI bandwidth can cause quality problems and ways to resolve those
problems
Explain how end-to-end delay can cause quality problems and ways to resolve those
problems
Explain how packet loss can cause quality problems and ways to resolve those problems
Basic knowledge oI internetworking with TCP/IP concepts
Copyright © 2003, Cisco Systems, Ìnc. Ìntroduction to ÌP QoS 1-5
OutIine
The outline lists the topics included in this lesson.
OutIine
· Overview
· Converged Networks
· Converged Networks QuaIity Issues
· AvaiIabIe Bandwidth
· End-to-End DeIay
· Packet Loss
· Summary
· Quiz
Converged Networks
This topic explains why QoS was not important beIore networks converged.
BeIore networks converged, network engineering Iocused on connectivity. The rates at which
data came onto the network resulted in bursty data Ilows. Data, arriving in packets, tried to grab
as much bandwidth as it could at any given time. The access was very egalitariana Iirst-
come, Iirst-served basis. Whoever arrived Iirst got the bandwidth.
As a result oI this somewhat anarchic way oI attacking the network, the data rate is adaptive to
network conditions.
The protocols that have been developed have adapted to the bursty nature oI data networks, and
brieI outages are survivable. For example, iI retrieving e-mail, a delay oI a Iew seconds is
generally not noticeable. A delay oI minutes is annoying, but not serious.
Traditional networks also had requirements Ior applications such as data, video, and systems
network architecture (SNA). Since each application had diIIerent traIIic characteristics and
requirements, network designers deployed nonintegrated networks designed Ior carrying a
speciIic type oI traIIic: data network, SNA network, voice network, and video network.
Before Converged Networks
TraditionaI data traffic characteristics:
· Bursty data fIow
· First-come, first-served access
· MostIy not time sensitive - deIays OK
· Brief outages are survivabIe
The Iigure illustrates a converged network in which voice, video, and data traIIic use the same
network Iacilities. Merging these diIIerent traIIic streams with dramatically diIIering
requirements can lead to a number oI problems.
Although packets carrying voice traIIic are typically very small, they cannot tolerate delay and
delay variation as they traverse the network. Voices will break up and words will become
incomprehensible.
On the other hand, packets carrying Iile transIer data are typically large and can survive delays
and drops. It is possible to retransmit part oI a dropped (data) Iile, but it is not Ieasible to
retransmit a part oI a (voice) conversation.
The constant, but small packet voice Ilow competes with bursty data Ilows. Unless some
mechanism mediates the overall Ilow, voice quality will be severely compromised at times oI
network congestion. The critical voice traIIic must get priority.
Voice and video traIIic are very time sensitive. They cannot be delayed and they cannot be
dropped or the resulting quality oI voice and video will suIIer.
And, Iinally, converged networks cannot Iail. While a Iile transIer or e-mail packet can wait
until the network recovers, voice and video packets cannot. Even a brieI network outage on a
converged network can seriously disrupt business operations.
After Converged Networks
Converged traffic characteristics:
· Constant smaII packet voice fIow competes
with bursty data fIow
· CriticaI traffic must get priority
· Voice and video are time sensitive
· Brief outages not acceptabIe
Converged Networks QuaIity Issues
This topic describes the basic quality issues presented by converged networks.
With inadequate preparation oI the network, voice transmission is choppy or unintelligible.
Gaps in speech are particularly troublesome where pieces oI speech are interspersed with
silence, and speech literally disappears. In voice-mail systems this silence is a problem. For
example, you dial 68614. In a situation where the gaps in speech are actually gaps in the tone,
68614 becomes 6688661144, because the gaps in speech are perceived as pauses in the touch
tones.
Poor caller interactivity is the consequence oI delay. It causes two problemsecho and talker
overlap.
Echo is caused by the signal reIlecting the speaker voice Irom the Iar-end telephone
equipment back into the speaker ear.
Talker overlap is caused when one-way delay becomes greater than 250 ms. When this
occurs, one talker steps in on the speech oI the other talker resulting in a 'walkie-talkie¨
call mode.
Disconnected calls are the worst cases: II there are long gaps in speech, the parties will hang
up; iI there are signaling problems, the calls are disconnected. Such events are completely
unacceptable in the voice world yet are quite common Ior an inadequately prepared data
network that is attempting to carry voice.
Multimedia streams, such as those used in IP telephony or videoconIerencing, may be
extremely sensitive to delivery delays and create unique QoS demands on the underlying
networks that carry them. When packets are delivered using the 'best-eIIort¨ delivery model,
they may not arrive in order, in a timely manner, or at all. The result is unclear pictures, jerky
and slow movement, and sound that is out oI synchronization with the image.
Converged Networks:
QuaIity Issues
· TeIephone CaII: "I cannot understand you;
your voice is breaking up."
· TeIeconferencing: "The picture is very jerky.
Voice not synchronized."
· Brokerage House: "I needed that information
two hours ago. Where is it?"
· CaII Center: "PIease hoId whiIe my screen
refreshes."
The Iour big problems Iacing converged enterprise networks are bandwidth capacity, delay
(both Iixed and variable), variation oI delay (also called jitter), and packet loss.
Large graphic Iiles, multimedia uses, and increasing use Ior voice and video cause bandwidth
capacity problems over data networks.
Delay is the time it takes Ior a packet to reach the receiving endpoint aIter being transmitted
Irom the sending endpoint. This time is termed the 'end-to-end delay,¨ and consists oI two
components: Iixed network delay and variable network delay. Jitter is the delta, or diIIerence,
in the total end-to-end delay values oI two voice packets in the voice Ilow.
Two types oI Iixed delay are serialization and propagation delays. Serialization is the process oI
placing bits on the circuit. The higher the circuit speed, the less time it takes to place the bits on
the circuit. ThereIore, the higher the speed oI the link, the less serialization delay is incurred.
Propagation delay is the time it takes Ior Irames to transit the physical media.
Processing delay is a type oI variable delay, and is the time required by a networking device to
look up the route, change the header, and complete other switching tasks. In some cases, the
packet also must be manipulated. For example, the encapsulation type or the hop count must be
changed. Each oI these steps can contribute to the processing delay.
Loss oI packets is usually caused by congestion in the WAN, resulting in speech dropouts or a
stutter eIIect iI the play-out side tries to accommodate by repeating previous packets.
Converged Networks:
QuaIity Issues (Cont.)
· Lack of bandwidth: muItipIe fIows compete for a
Iimited amount of bandwidth
· End-to-end deIay (fixed and variabIe): packets
have to traverse many network devices and Iinks
that add up to the overaII deIay
· Variation of deIay (jitter): sometimes there is a
Iot of other traffic, which resuIts in more deIay
· Packet Loss: packets may have to be dropped
when a Iink is congested
video Lacking
Proper QoS
AvaiIabIe Bandwidth
This topic explains how a lack oI bandwidth can adversely impact QoS in a network and
describes ways to eIIectively increase bandwidth on a link.
The example illustrates an empty network with Iour hops between a server and a client. Each
hop is using diIIerent media with a diIIerent bandwidth. The maximum available bandwidth is
equal to the bandwidth oI the slowest link.
The calculation oI the available bandwidth, however, is much more complex in cases where
multiple Ilows are traversing the network. The calculation oI the available bandwidth in the
illustration is a rough approximation.
Lack of Bandwidth
· Maximum avaiIabIe bandwidth equaIs the bandwidth of the weakest
Iink.
· MuItipIe fIows are competing for the same bandwidth resuIting in
much Iess bandwidth being avaiIabIe to one singIe appIication.
Bandwidth
max
= min (10 Mbps, 256 kbps, 512 kbps, 100 Mbps) = 256kbps
Bandwidth
avaiI
= bandwidth
max
/ fIows
Bad voice Due to
Lack of BW
The best approach is to increase the link capacity to accommodate all applications and users,
with some extra bandwidth to spare. Although this solution sounds simple, it brings a high cost
in terms oI the expense and time it takes to implement. Very oIten there are also technological
limitations Ior upgrading to a higher bandwidth.
Another option is to classiIy traIIic into QoS classes and prioritize it according to importance.
(Voice and business-critical traIIic should get suIIicient bandwidth to support their application
requirements, voice should get prioritized Iorwarding, and the least important traIIic should get
whatever unallocated bandwidth is remaining.) A wide variety oI mechanisms are available in
Cisco IOS QoS soItware that provide bandwidth guarantees:
Priority queuing (PQ) or custom queuing (CQ)
ModiIied deIicit round robin (MDRR) (on Cisco 12000 series routers)
Distributed type oI service (ToS)-based and QoS group-based weighted Iair queuing
(WFQ) (on Cisco 7 00 series routers)
Class-based weighted Iair queuing (CBWFQ)
Low-latency queuing (LLQ)
Optimizing link usage by compressing the payload oI Irames (virtually) increases the link
bandwidth. Compression, on the other hand, also increases delay because oI the complexity oI
compression algorithms. Using hardware compression can accelerate packet payload
compressions. Stacker and Predictor are two compression algorithms that are available in Cisco
IOS soItware.
Another link eIIiciency mechanism is header compression. This mechanism is especially
eIIective in networks where most packets carry small amounts oI data (that is, where payload-
to-header ratio is small). Typical examples oI header compression are TCP header compression
and Real-Time Transport Protocol (RTP) header compression.
Ways to Increase AvaiIabIe Bandwidth
End-to-End DeIay
This topic explains how end-to-end delay can adversely impact QoS in a network and describes
ways to eIIectively reduce delay.
This Iigure illustrates the impact a network has on the end-to-end delay oI packets going Irom
one end to the other. Each hop in the network adds to the overall delay because oI these Iactors:
Propagation delay is caused by the speed oI light traveling in the media; Ior example, the
speed oI light traveling in Iiber optics or copper media.
Serialization delay is the time it takes to clock all the bits in a packet onto the wire. This is
a Iixed value that is a Iunction oI the link bandwidth.
There are processing and queuing delays within a router, which can be caused by a wide
variety oI conditions.
Propagation delay is generally ignored but it can be signiIicant; Ior example, about 40 ms
coast-to-coast, over optical. Internet Control Message Protocol (ICMP) echo (ping) is one way
to measure the round-trip time oI IP packets in a network.
End-to-End DeIay
· End-to-end deIay equaIs a sum of aII propagation, processing
and queuing deIays in the path.
· In best-effort networks, propagation deIay is fixed, processing
and queuing deIays are unpredictabIe.
DeIay = P1 + Q1 + P2 + Q2 + P3 + Q3 + P4 = X ms
Bad voice Due to
Delay variation
ExampIe: Effects of DeIay
A customer has a router in New York and a router in San Francisco, each connected by a 128-
kbps WAN link. The customer sends a 66-byte voice Irame across the link. To transmit the
Irame (528 bits) it will take 4.125 ms to clock out (serialization delay). However, the last bit
will not arrive until 40 ms it clocks out (propagation delay). The total delay equals 44.125
ms.
Now, change the circuit to a T1. To transmit the Irame (528 bits) it will take 0.344 ms to clock
out (serialization delay). However, the last bit will not arrive until 40 ms aIter transmission
(propagation delay) Ior a total delay oI 40.344 ms. In this case, the signiIicant Iactor is
propagation delay. In the same situationbut Ior a link between Seattle and San Francisco
serialization delay remains the same and propagation delay drops to around 6 ms, making 528
bits take 10.125 (128-kbps link) and 6.344 (T1 link).
As is evident, you must take both serialization and propagation delays into account.
There are Iour kinds oI delay:
Processing Delay: The time it takes Ior a router to take the packet Irom an input interIace
and put it into the output queue oI the output interIace. The processing delay depends on
various Iactors, such as:
CPU speed
CPU utilization
IP switching mode
Router architecture
ConIigured Ieatures on both input and output interIace
Queuing Delay: The time a packet resides in the output queue oI a router. It depends on
the number and sizes oI packets already in the queue and on the bandwidth oI the interIace.
It also depends on the queuing mechanism.
Serialization Delay: The time it takes to place a Irame on the physical medium Ior
transport.
Propagation Delay: The time it takes to transmit a packet. (This usually depends on the
type oI media interIace.)
Processing and Queuing DeIay
· Processing DeIay: The time it takes for a router to take the packet from an input
interface, examine it, and put it into the output queue of the output interface
· Queuing DeIay: The time a packets resides in the output queue of a router
· SeriaIization DeIay: The time it takes to pIace the "bits on the wire"
· Propagation DeIay: The time it takes to transmit a packet
Assuming that a router is powerIul enough to make a Iorwarding decision in negligible time, it
can be said that most processing, queuing, and serialization delay is inIluenced by the Iollowing
Iactors:
Average length oI the queue
Average length oI packets in the queue
Link bandwidth
There are several approaches to accelerate packet dispatching oI delay-sensitive Ilows:
Increase link capacity: SuIIicient bandwidth causes queues to shrink, making sure packets
do not have to wait long beIore they can be transmitted. Additionally, more bandwidth
reduces serialization time. On the other hand, this might be an unrealistic approach because
oI the costs associated with the upgrade.
Prioritize delay-sensitive packets: This is a more cost-eIIective approach. There are a
wide variety oI queuing mechanisms available in Cisco IOS soItware that have pre-emptive
queuing capabilities, Ior example:
PQ
CQ
Strict-priority or alternate priority queuing within the MDRR (on Cisco 12000 series
routers)
LLQ
Compress payload: Payload compression reduces the size oI packets and, thereIore,
virtually increases link bandwidth. Additionally, compressed packets are smaller and need
less time to be transmitted. On the other hand, compression uses complex algorithms that
take time and add to the delay. This approach is, thereIore, not used to provide low-delay
propagation oI packets.
Ways to Reduce DeIay
Header compression: Header compression is not as CPU-intensive as payload
compression and can be used in combination with other mechanisms to reduce delay. It is
especially useIul Ior voice packets that have a bad payload-to-header ratio, which is
improved by reducing the header oI the packet (RTP header compression). By minimizing
delay, jitter is also reduced (delay is more predictable).
Packet Loss
This topic explains how packet loss can adversely impact QoS in a network and describes ways
to manage packet loss so that QoS is not aIIected.
The usual packet loss occurs when routers run out oI buIIer space Ior a particular interIace
(output queue). The Iigure illustrates a Iull interIace output queue, which causes newly arriving
packets to be dropped. The term used Ior such drops is simply 'output drop¨ or 'tail-drop¨
(packets are dropped at the tail oI the queue).
Routers might also drop packets Ior other (less common) reasons, Ior example:
Input queue drop: Main CPU is congested and cannot process packets (the input queue is
Iull).
Ignore: Router ran out oI buIIer space.
Overrun: CPU is congested and cannot assign a Iree buIIer to the new packet.
Frame errors: Hardware-detected error in a Iramecyclic redundancy check (CRC), runt,
giant.
Packet Loss
· TaiI-drops occur when the output queue is fuII. These are
common drops, which happen when a Iink is congested.
· Many other types of drops exist, usuaIIy the resuIt of router
congestion, that are uncommon and may require a hardware
upgrade (input drop, ignore, overrun, frame errors).
Bad voice Due
to Packet Loss
Packet loss is usually the result oI congestion on an interIace. Most applications that use TCP
experience slowdown because TCP adjusts to the network resources. (Dropped TCP segments
cause TCP sessions to reduce their window sizes.) There are some other applications that do
not use TCP and cannot handle drops (Iragile Ilows).
The Iollowing approaches can be taken to prevent drops oI sensitive applications:
Increased link capacity to ease or prevent congestion.
Guarantee enough bandwidth and increase buIIer space to accommodate bursts oI Iragile
applications. There are several mechanisms available in Cisco IOS QoS soItware that can
guarantee bandwidth and provide prioritized Iorwarding to drop-sensitive applications, Ior
example:
PQ
CQ
MDDR (on Cisco 12000 series routers)
IP RTP prioritization
CBWFQ
LLQ
Prevent congestion by dropping other packets beIore congestion occurs. Weighted random
early detection (WRED) can be used to start dropping other packets beIore congestion
occurs.
There are some other mechanisms that can also be used to prevent congestion:
TraIIic shaping delays packets instead oI dropping them (generic traIIic shaping |GTS|,
Frame Relay traIIic shaping |FRTS|, and class-based shaping).
TraIIic policing can limit the rate oI less important packets to provide better service to drop-
sensitive packets (committed access rate |CAR| and class-based policing).
Ways to Prevent Packet Loss
Summary
This topic summarizes the key points discussed in this lesson.
References
For additional inIormation, reIer to this resource:
To learn more about QoS, reIer to 'Cisco IOS Quality oI Service (QoS)¨ at the Iollowing
URL: http://www.cisco.com/warp/public/732/Tech/qos/
Summary
· Converged networks create new requirements
for managing network traffic.
· Converged networks suffer from different quaIity
issues incIuding Iack of adequate bandwidth,
end-to-end and variabIe deIay, and Iost packets.
· Networks experience different types of deIay
incIuding processing deIay, queuing deIay,
seriaIization deIay, and propagation deIay.
· Many technoIogies exist today that can
overcome the probIems presented by Iack of
bandwidth, deIay, variabIe deIay, and packet
Ioss.
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are
Iound in the Quiz Answer Key.
Q1) Which three types oI traIIic can typically tolerate packets being dropped? (Choose
three.)
A) Iile transIers
B) voice
C) e-mail
D) HTTP
Q2) Which three oI the Iollowing are key quality issues speciIically Ior converged
networks? (Choose three.)
A) lack oI bandwidth
B) end-to-end delay
C) variable delay
D) propagation delay
Q3) The maximum bandwidth available between two points is ¸¸¸¸¸.
A) the bandwidth oI the slowest link
B) the bandwidth oI the Iastest link
C) the average bandwidth across the links
D) the average oI the slowest and Iastest links
Q4) What are three ways to reduce delay Ior time-sensitive packets in a network? (Choose
three.)
A) compress headers
B) Iorward the most important packets Iirst
C) upgrade bandwidth on the links
D) aggressively drop packets
Q5) Which is the most common drop to occur when a link is congested?
A) tail drop
B) input drop
C) overrun drop
D) no buIIer drop
Quiz Answer Key
Q1) A, C, D
ReIates to: Converged Networks
Q2) A, B, C
ReIates to: Converged Networks Quality Ìssues
Q3) A
ReIates to: Available Bandwidth
Q4) A, B, C
ReIates to: End-to-End Delay
Q5) A
ReIates to: Packet Loss
Understanding QoS
Overview
The basic concepts and key terminology oI QoS are explained in this lesson. The three key
steps involved in implementing a QoS policy are described.
ReIevance
To understand the more technical aspects oI network QoS, it is Iirst important to understand the
basic concepts oI QoS and to be able to deIine some key QoS terms.
Objectives
Upon completing this lesson, you will be able to deIine the term QoS and identiIy and explain
the key steps to implementing QoS on a converged network. This includes being able to meet
these objectives:
DeIine the term 'QoS¨ with respect to traIIic in a network
List and explain the key steps involved in implementing a QoS policy on a network
Explain the QoS requirements oI the common types oI network applications
DeIine the term 'QoS service policy¨
DeIine the term 'QoS policy¨
OutIine
OutIine
· Overview
· QoS Defined
· QoS for Converged Networks
· QoS Requirements
· QoS Traffic CIasses
· QoS PoIicy
· Summary
· Quiz
QoS Defined
This topic deIines the term 'QoS.¨
QoS is the ability oI the network to provide better or 'special¨ service to selected users and
applications to the detriment oI other users and applications.
Cisco IOS QoS Ieatures enable network administrators to control and predictably service a
variety oI networked applications and traIIic types, thus allowing network managers to take
advantage oI a new generation oI media-rich and mission-critical applications.
The goal oI QoS is to provide better and more predictable network service by providing
dedicated bandwidth, controlled jitter and latency, and improved loss characteristics. QoS
achieves these goals by providing tools Ior managing network congestion, shaping network
traIIic, using expensive wide-area links more eIIiciently, and setting traIIic policies across the
network. QoS oIIers intelligent network services that, when correctly applied, help to provide
consistent, predictable perIormance.
QoS Defined
QoS for Converged Networks
This topic describes the three steps necessary Ior implementing QoS on a network.
There are three basic steps involved in implementing QoS on a network:
Step 1 IdentiIy traIIic and its requirements. Study the network to determine the type oI
traIIic running on the network and then determine the QoS requirements Ior the
diIIerent types oI traIIic.
Step 2 Group the traIIic into classes with similar QoS requirements. In the example below,
Iour classes oI traIIic could be deIined: voice, high priority, low priority, and
browser.
Step 3 DeIine QoS policies that will meet the QoS requirements Ior each traIIic class.
ExampIe: Three Steps to ImpIementing QoS on a Network
In a typical network, voice will always require absolute minimal delay. Some data associated
with key applications will require very low delay (transaction-based data used in airline
reservations or online banking applications). Other types oI data can tolerate a great deal oI
delay (Iile transIers and e-mail). Nonbusiness network surIing can also be delayed or even
prohibited.
A one-to-one mapping between traIIic classes and QoS policies need not be made. For
example, three QoS policies could be implemented to meet the requirements oI the Iour traIIic
classes deIined above:
Assign to voice traIIic
: Assign to high-priority traIIic
Assign to both the low priority and browser traIIic
QoS for Converged Networks
QoS Requirements
This topic explains how traIIic is identiIied on a network and describes elemental QoS
requirements.
The Iirst step in implementing QoS is identiIying the traIIic on the network and determining
QoS requirements Ior the traIIic.
Determine users QoS problems. Measure the traIIic on the network during congested periods.
Conduct CPU utilization assessment on each oI their network devices during busy periods to
determine where problems might be occurring.
Determine the business model, business goals, and obtain a list oI business requirements. This
will help you deIine the number oI classes and determine the business requirements Ior each
traIIic class.
DeIine the service levels required by diIIerent traIIic classes in terms oI response time and
availability. What is the impact on business iI a transaction is delayed by two or three seconds?
Can Iile transIers wait until the network is quiescent?
Step 1:
Identify Traffic and Its Requirements
· Network audit
÷ Identify traffic on the
network
· Business audit
÷ Determine how each type
of traffic is important for
business
· Service IeveIs required
÷ Determine required
response time
Voice traIIic has extremely stringent QoS requirements. Voice traIIic generally generates a
smooth demand on bandwidth and has minimal impact on other traIIic as long as it is managed.
While voice packets are typically small (60 to 120 bytes), they cannot tolerate delay or drops.
The result oI delays and drops are poorand oIten unacceptablevoice quality. Because drops
cannot be tolerated, User Datagram Protocol (UDP) is used to package voice packets because
TCP retransmit capabilities have no value.
Voice packets can tolerate no more than a 15-ms delay (one-way requirement) and less than 1
percent packet loss.
A typical voice call will require 17 to 106 kbps oI guaranteed priority bandwidth plus an
additional 150 bps per call Ior voice-control traIIic. Multiplying these bandwidth requirements
times the maximum number oI calls expected during the busiest time period will provide an
indication oI the overall bandwidth required Ior voice traIIic.
· Latency < 150 ms*
· Jitter < 30 ms*
· Loss < 1%*
· 17-106 kbps guaranteed
priority bandwidth
per caII
· 150 bps (+ Layer 2
overhead) guaranteed
bandwidth for voice-
controI traffic per caII
*one-way requirements
QoS Traffic Requirements:
Voice
-
-
-
QoS Requirements:
Videoconferencing
· Latency < 150 ms
· Jitter < 30 ms
· Loss < 1%
· Minimum priority
bandwidth guarantee
required is:
÷ Video-Stream + 20%
÷ For exampIe, a 384 kbps
stream wouId require 460
kbps of priority bandwidth
-
-
-
VideoconIerencing applications also have very stringent QoS requirements very similar to
voice.
But videoconIerencing traIIic is oIten bursty and greedy in nature and, as a result, can impact
other traIIic. ThereIore, it is important to understand the videoconIerencing requirements Ior a
network and to provision careIully Ior it.
The minimum bandwidth Ior a videoconIerencing stream would require the actual bandwidth oI
the stream (dependent upon the type oI videoconIerencing codec being used) plus some
overhead. For example, a 384-kbps video stream would actually require a total oI 460 kbps oI
priority bandwidth.
The QoS requirements Ior data traIIic vary greatly.
DiIIerent applications (Ior example, a human resources application versus an automated teller
machine application) may make greatly diIIerent demands on the network. Even diIIerent
versions oI the same application may have varying network traIIic characteristics.
While data traIIic can demonstrate either smooth or bursty characteristics depending upon the
application, data traIIic diIIers Irom voice and video in terms oI delay and drop sensitivity.
Almost all data applications can tolerate some delay and generally can tolerate high drop rates.
Because data traIIic can tolerate drops, the retransmit capabilities oI TCP become important
and, as a result, many data applications use TCP.
In enterprise networks, important (business-critical) applications are usually easy to identiIy.
Most applications can be identiIied based on TCP or UDP port numbers. Some applications use
dynamic port numbers that, to some extent, make classiIications more diIIicult. Cisco IOS
soItware supports network-based application recognition (NBAR), which can be used to
recognize dynamic port applications.
It is recommended that data traIIic be classiIied into no more than Iour to Iive-classes as
described in the graphic above. There will still remain additional classes Ior voice and video.
Data
· Different appIications have
different traffic characteristics
· Different versions of the same
appIication can have different
traffic characteristics
· CIassify data into reIative-priority
modeI with no more than four- to
five-cIasses:
÷ Mission-CriticaI Apps: LocaIIy
defined criticaI appIications
÷ TransactionaI: Interactive
traffic, preferred data service
÷ Best-Effort: Internet, e-maiI,
unspecified traffic
÷ Less-Than-Best-Effort
(Scavenger): Napster/Kazaa,
peer-to-peer appIications
QoS Traffic CIasses
This topic explains how to divide traIIic into traIIic classes.
AIter the majority oI network traIIic has been identiIied and measured, use the business
requirements to deIine traIIic classes.
Because oI its stringent QoS requirements, voice traIIic will almost always exist in a class by
itselI. Cisco has developed speciIic QoS mechanisms such as LLQ that ensure that voice
always receives priority treatment over all other traIIic.
AIter the applications with the most critical requirements have been deIined, the remaining
traIIic classes are deIined using the business requirements.
ExampIe: Traffic CIassification
A typical enterprise might deIine Iive traIIic classes as:
Voice: Absolute priority Ior Voice over IP (VoIP) traIIic
Mission critical: Small set oI locally deIined critical business applications
Transactional: Database access, transaction services, interactive traIIic, preIerred data
services
Best effort: Internet, e-mail
Scavenger (less-than-best-effort): Napster/Kazaa and other point-to-point applications
Step 2:
Divide Traffic into CIasses
QoS PoIicy
This topic describes how to deIine QoS policies aIter traIIic classes have been deIined.
Finally, deIine a QoS policy Ior each traIIic class. DeIining a QoS policy involves:
Setting a minimum bandwidth guarantee
Setting a maximum bandwidth limit
Assigning priorities to each class
Using QoS technologies, such as advanced queuing, to manage congestion
ExampIe: Defining QoS PoIicies
Using the traIIic classes previously deIined, QoS policies could be determined as:
Voice: Minimum bandwidth 1 Mbps. Use QoS marking to mark voice packets as priority 5;
use LLQ to always give voice priority.
Mission critical: Minimum bandwidth 1 Mbps. Use QoS marking to mark critical data
packets as priority 4; use CBWFQ to prioritize critical class traIIic Ilows.
Best effort: Maximum bandwidth 500 kbps. Use QoS marking to mark these data packets
as priority 2; use CBWFQ to prioritize best-eIIort traIIic Ilows that are below mission-
critical and voice.
Scavenger: Maximum bandwidth 100 kbps. Use QoS marking to mark less-than-best-
eIIort (scavenger) data packets as priority 0; use weighted random early detection (WRED)
to drop these packets whenever the network has a propensity Ior congestion.
Step 3:
Define PoIicies for Each Traffic CIass
· Set minimum
bandwidth guarantee
· Set maximum
bandwidth Iimits
· Assign priorities to
each cIass
· Manage congestion
A QoS policy is a network-wide deIinition oI the speciIic levels oI QoS assigned to diIIerent
classes oI network traIIic.
Having a QoS policy is just as important in a converged network as a security policy. A written
and public QoS policy allows users to understand and negotiate Ior QoS in the network.
QoS PoIicy
A network-wide
definition of the
specific IeveIs of
quaIity of service
assigned to different
cIasses of network
traffic
The graphic illustrates how a QoS policy could be deIined Ior a network.
Enterprise Resource Planning (ERP) applications have a high QoS priority and must be
available all the time.
Video applications are guaranteed 100 kbps oI bandwidth, but can operate only between the
hours oI 9:00 a.m. to 5:00 p.m. on weekdays.
Voice traIIic is guaranteed less than 150 ms delay in each direction but limited to the hours oI
9:00 a.m. to 5:00 p.m. on weekdays; toll calls are completely restricted to avoid personal long-
distance calls.
QoS PoIicy (Cont.)
AIign Network Resources with Business Priorities
Summary
References
For more inIormation on QoS, reIer to 'Implementing Quality oI Service¨ at the Iollowing
URL:
http://www.cisco.com/en/US/partner/tech/tk543/tk757/technologies¸white¸paper09186a00
8017I93b.shtml
Summary
· QoS is the abiIity of the network to provide
better or "speciaI" service to users/appIications.
· BuiIding QoS requires three steps: identify
requirements, cIassify network traffic, and define
network-wide poIicies for quaIity.
· Voice, video, and data have very different QoS
requirements to run effectiveIy on a network.
· A QoS poIicy is a network-wide definition of the
specific IeveIs of QoS assigned to cIasses of
network traffic.
Quiz
Q1) Quality oI Service is deIined as 'the ability oI the network to¸¸¸¸¸.¨
A) improve the quality oI voice transmission
B) oIIer end-to-end circuits with preIerred priority
C) provide special services to user and applications
D) consistently move priority packets to the Iront oI queues
Q2) Which three oI the Iollowing represent the three steps to implementing Quality oI
Service in converged networks? (Choose three.)
A) deIine QoS policies
B) divide traIIic into classes
C) identiIy traIIic and its requirements
D) interview users to determine problems
Q3) Which three oI the Iollowing represent characteristics oI voice traIIic? (Choose three.)
A) drop sensitive
B) smooth, constant Ilow
C) benign, does not aIIect other traIIic
D) relies on TCP to handle packet loss
Q4) Which type oI application typically uses TCP Ior a transport protocol?
A) data
B) voice
C) video
D) videoconIerencing
Q5) Which three oI the Iollowing does QoS policy involve? (Choose three.)
A) assigning priorities to each class
B) setting a maximum bandwidth limit
C) setting a minimum bandwidth guarantee
D) combining traIIic classes to go under one policy
Quiz Answer Key
Q1) C
ReIates to: QoS Defined
Q2) A, B, C
ReIates to: QoS for Converged Networks
Q3) A. B, C
ReIates to: QoS Requirements
Q4) A
ReIates to: QoS Requirements
Q5) A, B, C
ReIates to: QoS Policy
Ìmplementing ÌP QoS
Overview
Cisco recommends using either the Modular QoS command-line interIace (MQC) or Cisco
AutoQoS Ior implementing QoS in a network. The MQC oIIers a highly modular way to Iine-
tune a network. AutoQoS oIIers an automated method Ior almost instantly incorporating
consistent voice QoS in a network oI routers and switches. In addition, CiscoWorks QoS Policy
Manager (QPM) provides centralized QoS design, administration, and traIIic monitoring that
scales to large QoS deployments.
ReIevance
It is very important to understand the diIIerent ways to implement QoS in a network. There are
tradeoIIs regarding the use oI the MQC versus AutoQoS in implementing QoS and knowing the
diIIerences between MQC and AutoQoS can help a network administrator save time and
resources.
Objectives
Upon completing this lesson, you will be able to list and describe methods Ior implementing
QoS. This includes being able to meet these objectives:
List and describe methods Ior conIiguring and monitoring QoS on a network
Explain at a high level, the CLI (nonmodularized) method oI conIiguring QoS
Explain at a high level, the MQC method oI conIiguring QoS
Explain at a high level, the AutoQoS method oI conIiguring QoS
IdentiIy and explain the advantages and disadvantages oI using each oI the methods oI
implementing QoS on a network
Explain how QPM can be used to manage QoS policies on a network
Explain the purpose oI a MIB and how it is used with QPM to monitor network
Explain how the QoS MIBs can be used with QPM to monitor QoS on a network
Basic understanding oI the Cisco IOS command-line interIace (CLI)
OutIine
OutIine
· Overview
· Methods for ImpIementing QoS PoIicy
· Legacy CLI
· ModuIar QoS CLI
· AutoQoS
· QoS ImpIementation Methods Compared
· QoS PoIicy Manager
· Network Management MIBs for Monitoring QoS
· MIBs for Managing QoS
· Summary
· Quiz
Methods for ImpIementing QoS PoIicy
This topic describes Iour diIIerent methods Ior implementing and managing a QoS policy.
Just a Iew years ago, the only way to implement QoS in a network was by using the CLI to
individually conIigure QoS policies at each interIace. This was a time-consuming, tiresome,
and error-prone task involving cutting and pasting conIigurations Irom one interIace to another.
Cisco introduced the MQC in order to simpliIy QoS conIiguration by making conIigurations
modular. Using MQC, QoS can be conIigured in a building block approach using a single
module repeatedly to apply policy to multiple interIaces.
Cisco AutoQoS represents innovative technology that simpliIies the challenges oI network
administration by reducing QoS complexity, deployment time, and cost in enterprise networks.
Cisco AutoQoS incorporates value-added intelligence in Cisco IOS soItware and Cisco Catalyst
soItware to provision and assist in the management oI large-scale QoS deployments.
The Iirst phase oI Cisco AutoQoS oIIers straightIorward capabilities to automate VoIP
deployments Ior customers who want to deploy IP telephony but lack the expertise and staIIing
to plan and deploy IP QoS and IP services.
Customers can more easily provision and manage successIul QoS deployments by using Cisco
AutoQoS together with CiscoWorks QPM. Cisco AutoQoS provides QoS provisioning Ior
individual routers and switches, simpliIying deployment and reducing human error.
CiscoWorks QPM provides centralized QoS design, administration, and traIIic monitoring that
scales to large QoS deployments.
Methods for ImpIementing QoS PoIicy
· CLI
· MQC
· AutoQoS
· QPM
Legacy CLI
This topic describes the CLI method Ior implementing QoS.
At one time, CLI was the only way to implement QoS in a network. It was a painstaking task
involving copying one interIace conIiguration and then pasting it into other interIace
conIigurations. It took a lot oI time and patience.
The CLI method was nonmodularthere was no way to separate the classiIication oI traIIic
Irom the actual deIinition oI policy. Network administrators had to do both on every interIace.
The Iigure illustrates an example oI the complex conIiguration tasks involved in using CLI.
While CLI is not recommended Ior implementing QoS policy, it is still used to Iine-tune QoS
implementations that have been generated using the Cisco AutoQoS macro.
ImpIementing QoS with CLI
· TraditionaI method
· NonmoduIar
· Cannot separate
traffic cIassification
from poIicy
definitions
· Used to augment,
fine-tune newer
AutoQos method
interface serial 0/0
ip address 10.1.61.1 255.255.255.0
ip tcp header~compression iphc~format
load~interval 30
custom~queue~list 1
ppp multilink
ppp multilink fragment~delay 10
ppp multilink interleave
multilink~group 1
ip rtp header~compression iphc~format
!
interface serial0/1
bandwidth 256
no ip address
encapsulation ppp
no ip mroute~cache
load~interval 30
no fair~queue
ppp multilink
multilink~group 1
ip address 10.1.61.1 255.255.255.0
load~interval 30
custom~queue~list 1
ppp multilink
multilink~group 1
!
interface serial0/1
bandwidth 256
no ip address
encapsulation ppp
no ip mroute~cache
load~interval 30
no fair~queue
ppp multilink
multilink~group 1
ModuIar QoS CLI
This topic describes the MQC method Ior implementing QoS.
The MQC is a CLI structure that allows users to create traIIic polices and then attach these
polices to interIaces. A traIIic policy contains one or more traIIic classes and one or more QoS
Ieatures. A traIIic class is used to classiIy traIIic; the QoS Ieatures in the traIIic policy
determine how to treat the classiIied traIIic.
The MQC oIIers signiIicant advantages over the legacy CLI method Ior implementing QoS. By
using MQC, a network administrator can signiIicantly reduce the time and eIIort it takes to
conIigure QoS on a complex network. Rather than conIiguring 'raw¨ CLI commands interIace
by interIace, the administrator develops a uniIorm set oI traIIic classes and QoS policies, which
can be applied on interIaces.
The use oI the MQC allows the separation oI traIIic classiIication Irom the deIinition oI QoS
policy. This enables easier initial QoS implementation and maintenance as new traIIic classes
emerge and QoS policies Ior the network evolve.
ImpIementing QoS with MQC
· A command syntax for
configuring QoS poIicy
· Reduces configuration
steps and time
· Configure poIicy, not "raw"
per-interface commands
· Uniform CLI across major
Cisco IOS pIatforms
· Uniform CLI structure for aII
QoS features
· Separates cIassification
engine from the poIicy
class~map VoIP~RTP
match access~group 100
class~map VoIP~Control
!
policy~map QoS~Policy
class VoIP~RTP
priority 100
class VoIP~Control
bandwidth 8
class class~default
fair~queue
!
service~policy output QoS~Policy
!
access~list 100 permit ip any any
precedence 5
access~list 100 permit ip any any dscp ef
access~list 101 permit tcp any host
10.1.10.20 range 2000 2002
10.1.10.20 range 11000 11999
class~map VoIP~RTP
class~map VoIP~Control
!
policy~map QoS~Policy
class VoIP~RTP
priority 100
class VoIP~Control
bandwidth 8
class class~default
fair~queue
!
!
access~list 100 permit ip any any
precedence 5
access~list 100 permit ip any any dscp ef
10.1.10.20 range 2000 2002
10.1.10.20 range 11000 11999
AutoQoS
This topic describes the use oI Cisco AutoQos Ior implementing QoS in a network.
ImpIementing QoS
with AutoQoS
· LAN & WAN-routers
and switches
· One command
enabIes Cisco QoS for
VoIP on a given
port/interface/PVC
Using Cisco AutoQos, network administrators can implement the QoS Ieatures that are required
Ior VoIP traIIic without an in-depth knowledge oI the Iollowing underlying technologies:
PPP
Frame Relay
ATM
Service policies
Link eIIiciency mechanisms, such as link Iragmentation and interleaving (LFI)
The AutoQoS VoIP Ieature simpliIies QoS implementation and speeds up the provisioning oI
QoS technology over a Cisco network. It also reduces human error and lowers training costs.
With the AutoQoS VoIP Ieature, one command (the command) enables QoS Ior VoIP
traIIic across every Cisco router and switch.
Network administrators can also use existing Cisco IOS commands to modiIy the
conIigurations that are automatically generated by the AutoQoS VoIP Ieature in case the
deIault AutoQoS conIiguration is not suIIicient.
CiscoWorks QPM can be used in conjunction with the AutoQoS VoIP Ieature to provide a
centralized, web-based tool to cost eIIectively manage and monitor network-wide QoS policies.
The AutoQoS VoIP Ieature, together with CiscoWorks QPM, eases QoS implementation,
provisioning, and management.
Note: Cisco AutoQoS was introduced in the 12.2(15)T Cisco ÌOS software release.
QoS ImpIementation Methods Compared
This topic compares the diIIerent methods Ior implementing QoS.
The three methods Ior conIiguring QoS on a network are the legacy CLI method, the MQC
method, and Cisco AutoQoS.
Cisco recommends the use oI the MQC and Cisco AutoQoS Ior implementing QoS.
While MQC is much easier to use than CLI, AutoQoS can simpliIy the conIiguration oI QoS.
As a result, the Iastest implementation possible can usually be accomplished with AutoQoS.
MQC oIIers excellent modularity and the ability to Iine-tune complex networks. AutoQoS
oIIers the Iastest way to implement QoS, but has limited Iine-tuning capabilities. When an
AutoQoS conIiguration has been generated, it is necessary to use CLI commands to Iine-tune
an AutoQoS conIiguration iI necessary. (On most networks Iine-tuning will not be necessary
Ior AutoQoS.)
Comparing Methods
for ImpIementing QoS
QoS PoIicy Manager
This topic describes the use oI the QPM Ior managing QoS on a network.
CiscoWorks QPM provides a scalable platIorm Ior deIining, applying, and monitoring QoS
policy on a system-wide basis Ior Cisco devices, including routers and switches.
QPM enables you to baseline proIile network traIIic, create QoS policies at an abstract level,
control the deployment oI policies, and then monitor QoS to veriIy intended results. As a
centralized tool QPM is used to monitor and provision QoS Ior groups oI interIaces and
devices.
QPM provides a web-based intuitive user interIace to deIine QoS policies and translates those
policies into the device CLI commands.
QPM lets you analyze traIIic throughput by application or service class. This analysis leverages
that inIormation to conIigure QoS policies to diIIerentiate traIIic and deIine the QoS Iunctions
that are applied to each type oI traIIic Ilow.
By simpliIying QoS policy deIinition and deployment, QPM makes it easier Ior you to create
and manage end-to-end diIIerentiated services in your network, thus making more eIIicient and
economical use oI your existing network resources. For example, you can deploy policies that
ensure that your mission-critical applications always get the bandwidth required to run your
business.
QoS PoIicy Manager
Suite of management functions aIIow network
administrators to fuIIy Ieverage the Cisco inteIIigent IP
infrastructure, enabIe network-wide QoS for voice, and
obtain precise, easy to understand QoS information
with monitoring and reporting.
÷ Voice QoS ready devices
÷ DepIoyment audit
÷ Device overwrite report
÷ Voice QoS ready devices
÷ DepIoyment audit
÷ Device overwrite report
· Device QoS
TroubIeshooting
· Device QoS
TroubIeshooting
· Recommendations via
wizards, tempIates
· Verification
· Customize
· Recommendations via
wizards, tempIates
· Verification
· Customize
Reporting Monitoring Provisioning
Customers can more easily provision and manage successIul QoS deployments using Cisco
AutoQoS together with QPM. Cisco AutoQoS provides QoS provisioning Ior individual routers
and switches, simpliIying deployment and reducing human error. CiscoWorks QPM provides
centralized QoS design, administration, and traIIic monitoring that scales to large QoS
deployments.
Cisco AutoQoS with CiscoWorks QPM
Use AutoQoS to
configure each switch or
router.
Use QPM to manage
network-wide QoS for
muItipIe devices.
Network Management MIBs for Monitoring QoS
This topic describes the key Management InIormation Bases (MIBs) that are used in managing
QoS implementations.
An MIB is a Simple Network Management Protocol (SNMP) structure that describes the
particular device being monitored. Cisco provides many standards-based MIBs Ior use in
monitoring the status oI devices on a network.
Advanced network management products, such as CiscoWorks QPM, use these MIBs to
generate statistics on the perIormance oI the network. Specialized QoS MIBs enable QPM to
graphically display key QoS inIormation to aid in the management oI QoS policies on the
network.
Note: See the ¨Cisco Network Management Toolkit for MÌBs¨ at http://www.cisco.com/public/sw-
center/netmgmt/cmtk/mibs.shtml
Network Management MIBs for
Monitoring QoS
· MIB: Management Information Base
· An SNMP structure that describes the particuIar
device being monitored
MIBs for Managing QoS
This topic describes the key MIBs that are used Ior managing QoS policy on a network.
The Class-Based QoS MIB (CBQoSMIB) provides read access to QoS conIigurations. This
MIB also provides QoS statistics inIormation based on the MQC, including inIormation
regarding class map and policy map parameters.
This CBQoSMIB actually contains two MIBs: Cisco Class-Based QoS MIB and Cisco Class-
Based QoS Capability MIB.
CIass-Based QoS MIB (CBQoSMIB)
· Provides read access to configuration and statisticaI
information for MQC-based QoS poIicies
· Provides MQC configuration information and appIication
statistics
· Provides CBQoS statistics on a per-poIicy/per-interface
or PVC basis
· AIIows monitoring of pre- and post-poIicy bit rates on a
device
CiscoWorks QPM uses the inIormation collected in the class-based MIB to build a number oI
reports showing the eIIect oI QoS policies on the network.
These reports can graphically illustrate the overall input traIIic Ilow divided by traIIic class, the
traIIic that was actually sent, and the traIIic that was dropped because oI QoS policy
enIorcement.
In the Reports tab Ior QPM, under Historical Reports, it is possible to create graphs, some oI
which include:
'Matching TraIIic Per Class Prior to QoS Actions¨ graphs that display the traIIic that
matched each policy group Iilters, beIore any policy actions were perIormed
'Matching TraIIic Per Class After QoS Actions¨ graphs that display the traIIic that matched
each policy group Iilters and was transmitted (not dropped) by the conIigured QoS policies
'Matching TraIIic Per Class Discaraea by QoS Drop Actions¨ graphs that display the
traIIic that matched each policy group Iilters and was dropped (not transmitted) by QoS
policy drop actions
QPM: Monitoring and Reporting
with CBQoSMIB
Another important MIB that is used Ior monitoring QoS is the Cisco NBAR Protocol Discovery
MIB (CNPD MIB). Using the inIormation collected by this MIB, it is possible to collect
detailed protocol and application-level network utilization statistics.
Note: CNPD MÌB is discussed further in the module ¨Classification and Marking¨ when NBAR is
explained.
Cisco NBAR ProtocoI Discovery MIB
· NBAR protocoI
discovery statistics
onIy avaiIabIe on the
configured device
· Provides abiIity to
retrieve statistics via
SNMP into a centraI
performance
monitoring system
Summary
References
For additional inIormation, reIer to these resources:
For more inIormation on QPM, reIer to 'Introduction to QPM¨ at the Iollowing URL:
http://www.cisco.com/en/US/products/sw/cscowork/ps2064/products¸user¸guide¸chapter0
9186a00800e0a00.html
For more inIormation on Cisco MIBs, reIer to 'Cisco Network Management Toolkit Ior
MIBs¨ at the Iollowing URL: http://www.cisco.com/public/sw-
center/netmgmt/cmtk/mibs.shtml
Summary
· There are four different methods for impIementing
QoS: CLI, MQC, AutoQoS, and QPM.
· CLI QoS configurations can be compIex and in
many cases requires Iearning different syntax for
different QoS mechanisms.
· MQC separates the cIassification of network traffic
from the definition of the QoS poIicy.
· AutoQoS is used to automaticaIIy impIement a set
of QoS poIicies on a router or switch.
· QPM can be used with the two QoS MIBs
(CBQoSMIB and CNPD-MIB) to provide enhanced
monitoring of network QoS.
Quiz
Q1) Which three methods are used to implement QoS policy? (Choose three.)
A) AutoQoS
B) QoS CLI Manager
C) QoS Policy Manager
D) Command-Line InterIace
Q2) Which oI the Iollowing is a major advantage oI MQC?
A) capability to generate QoS CLI code automatically
B) ability to separate classiIication Irom policy deIinition
C) capability to do Iine-tuning with 'raw¨ CLI commands
D) ability to automatically recognize new classes oI traIIic
Q3) Which three oI the Iollowing are advantages oI Cisco AutoQoS over other methods Ior
implementing QoS? (Choose three.)
A) reduces human error
B) lowers training costs
C) increases consistency
D) works Ior all situations
Q4) Which three oI the Iollowing are Ieatures oI QPM? (Choose three.)
A) baseline proIile network traIIic
B) control deployment oI policies
C) create QoS policies at an abstract level
D) auto alert users oI QoS policy violation
Q5) MIB is an acronym Ior¸¸¸¸¸.
A) Management Interrupt Block
B) Management InIormation Base
C) Management InIormation Block
D) Management Implementation Block
Q6) Using the Class-Based QoS MIB with QPM, it is possible to create which two oI the
Iollowing? (Choose two.)
A) AutoQoS Macro EIIiciency Analysis
B) matching TraIIic Per Class After QoS Actions
C) matching TraIIic Per Class Prior to QoS Actions
D) matching TraIIic by AutoQoS Generated Classes
Quiz Answer Key
Q1) A, C, D
ReIates to: Methods for Ìmplementing QoS Policy
Q2) B
ReIates to: Modular QoS CLÌ
Q3) A, B, C
ReIates to: AutoQoS
Q4) A, B, C
ReIates to: QoS Policy Manager
Q5) B
ReIates to: Network Management MÌBs for Monitoring QoS
Q6) B, C
ReIates to: MÌBs for Managing QoS
Module Assessment
Overview
Use this assessment to test what you learned in this module. The correct answers and solutions
are Iound in the Module Assessment Answer Key.
Quiz: Introduction to IP QoS
Complete the Quiz to assess what you have learned in the module.
Objectives
This activity tests your knowledge on how to meet these objectives:
IdentiIy problems that could lead to poor QoS and explain how the problems might be
resolved
DeIine the term QoS and identiIy and explain the key steps to implementing QoS on a
converged network
List and describe methods Ior implementing QoS
Instructions
Complete these steps:
Step 1 Answer all questions in this quiz by selecting the best answer(s) to each question.
Step 2 VeriIy your results against the answer key located at the end oI this section.
Step 3 Review the topics in this module that relate to the questions that you answered
incorrectly.
Q1) Which oI the Iollowing terms is used to describe the time it takes to actually transmit a
packet on a link (put bits on the wire)?
A) encoding delay
B) processing delay
C) serialization delay
D) transmission delay
Q2) What is the 'best¨ solution Ior reducing delay on a link?
A) compress data and headers
B) drop low priority packets early
C) increase the bandwidth oI the link
D) incorporate advanced queuing technologies
Q3) Which three oI the Iollowing are characteristics oI converged network traIIic? (Choose
three.)
A) constant small packet Ilow
B) time-sensitive packets
C) brieI outages are unacceptable
D) bursty small packet Ilow
Q4) How much one-way delay can a voice packet tolerate?
A) 15 ms
B) 150 ms
C) 300 ms
D) 200 ms
Q5) Which transport layer protocol is used Ior voice traIIic?
A) UDP
B) TCP
C) XNS
D) HTTP
Q6) Which three oI the Iollowing represent components in the deIinition oI a QoS policy?
(Choose three.)
A) user validated
B) network-wide
C) speciIic levels oI quality oI service
D) diIIerent classes oI network traIIic
Q7) How are QoS implementations generated using AutoQoS Iine-tuned?
A) command-line interIace
B) Modular QoS CLI
C) QoS AutoTune
D) QoS Policy Manager
Q8) Which three oI the Iollowing are advantages oI using MQC? (Choose three.)
A) reduction in time to conIigure a complex policy
B) ability to apply one policy to multiple interIaces
C) separation oI classiIication Irom policy deIinition
D) automatic generation oI CLI commands Irom MQC macros
Q9) Which QoS implementation method has the quickest implementation time Ior simple
networks?
A) CLI
B) MQC
C) AutoQoS
D) AutoTuner
Q10) Which two oI the Iollowing are MIBS speciIically designed Ior managing QoS in a
network? (Choose two.)
A) Modular QoS MIB
B) class-based QoS MIB
C) QoS Policy Manager MIB
D) Cisco NBAR Protocol Discover MIB
Scoring
You have successIully completed the quiz Ior this lesson when you earn a score oI 80 percent
or better.
ModuIe Assessment Answer Key
Q1) C
ReIates to: The Need for QoS
Q2) C
Q3) A, B, C
Q4) B
ReIates to: Understanding QoS
Q5) A
Q6) B, C, D
Q7) A
ReIates to: Ìmplementing ÌP QoS
Q8) A, B, C
Q9) C
Q10) B, D
ModuIe Summary
This topic summarizes the key points discussed in this module.
Voice and video traIIic present new challenges to networking. QoS is the network glue that
makes it possible to incorporate voice and video traIIic into a traditional networking
environment.
The MQC, Cisco AutoQoS, and QPM oIIer much more cost-eIIective and simple ways to
conIigure and manage a QoS-enabled network.
ModuIe Summary
· Converged networks create new requirements, which create
chaIIenges for managing network traffic.
· QoS is the abiIity of the network to provide better or "speciaI"
service to seIect users and appIications.
· Voice, video, and data have very different requirements.
· A QoS poIicy is a network-wide definition of the specific IeveIs
of QoS assigned to cIasses of network traffic.
· Four methods are used to impIement QoS poIicy: CLI, MQC,
AutoQoS, and QPM.
· MQC provides a moduIar method of impIementing QoS poIicies
and AutoQoS can automaticaIIy impIement poIicy on a switch
or router.
· QPM can be used with two QoS MIBs to provide enhanced
monitoring of QoS poIicies on a network.
ModuIe 2
The Building Blocks of ÌP QoS
Overview
Quality oI service (QoS) and its implementations are necessarily complex. The complex
requirements oI diIIerent applications in a converged network can create many challenges Ior
network administrators and architects. As technology evolves over time, diIIerent approaches to
solving the problems oI providing service quality to network applications are introduced. Many
oI these QoS 'building blocks¨ or 'Ieatures¨ operate at diIIerent parts oI a network to create an
end-to-end QoS system. Managing how these 'building blocks¨ are assembled and how
diIIerent QoS 'Ieatures¨ are used can be a diIIicult task. In response to these diIIiculties, three
diIIerent implementation models Ior QoS have been developed.
This module discusses the diIIerent implementation models oI QoS and describes how the
diIIerent 'building blocks¨ oI QoS integrate into each oI them. This module also discusses the
diIIerent QoS Ieatures and where they are typically implemented within a network. Because the
end result oI QoS implementations is to eIIect application traIIic traversing over a QoS enabled
network, this module also describes the eIIects that diIIerent QoS Ieatures have on network
traIIic.
ModuIe Objectives
Upon completing this module, you will be able to identiIy and describe diIIerent models used
Ior ensuring QoS in a network and explain key IP QoS mechanisms that are used to implement
the models.
ModuIe OutIine
ModuIe Objectives
· CorrectIy match a Iist of QoS actions to one or more of
the three modeIs for impIementing QoS on a network
· Describe the Differentiated Services modeI and expIain
how it can be used to impIement QoS in that network
· CorrectIy match a Iist of QoS actions to mechanisms for
impIementing QoS and identify where in a network the
different QoS mechanisms are commonIy used
· CorrectIy identify the QoS status of packets as they pass
through various points in the network
ModuIe OutIine
· ModeIs for ImpIementing QoS
· The Differentiated Services ModeI
· Case Study: QoS Mechanisms
· Case Study: The Life of a Packet
Models for Ìmplementing QoS
Overview
Three diIIerent models exist Ior implementing QoS on a network. The Best-EIIort model was
designed Ior best-eIIort, no-guarantee delivery oI packets. This model is still predominant in
the Internet today. The Integrated Services (IntServ) model was introduced to supplement the
best-eIIort delivery by setting aside some bandwidth Ior applications that require bandwidth
and delay guarantees. The IntServ model expects applications to signal their requirements to
the network. The DiIIerentiated Services (DiIIServ) model was added to provide greater
scalability in providing QoS to IP packets. The main diIIerence between the IntServ and
DiIIServ models is that in the DiIIServ model the network recognizes packets (no signaling is
needed) and provides the appropriate services to them. IP networks today can use all three
models at the same time.
ReIevance
To select the most appropriate method or methods Ior implementing QoS on a network, it is
vital to understand the primary methods available.
Objectives
Upon completing this lesson, you will be able to correctly match QoS actions to one or more
models Ior implementing QoS on a network. This includes being able to meet these objectives:
List the models Ior providing QoS on a network
Explain the key Ieatures oI the Best-EIIort model Ior QoS
Explain the key Ieatures oI the IntServ model Ior QoS
Explain the key Ieatures oI the DiIIServ model Ior QoS
Copyright © 2003, Cisco Systems, Ìnc. The Building Blocks of ÌP QoS 2-5
OutIine
OutIine
· Overview
· QoS ModeIs
· Best-Effort ModeI
· Integrated Services ModeI
· Differentiated Services ModeI
· Summary
· Quiz
QoS ModeIs
This topic lists the models Ior providing QoS on a network.
Three diIIerent models exist Ior implementing QoS in a network:
With the Best-EIIort model, QoS is not applied to packets. II it is not important when or
how packets arrive, the Best-EIIort model is appropriate.
The IntServ model can provide very high QoS to IP packets. Essentially, applications
signal to the network that they will require special QoS Ior a period oI time and bandwidth
is reserved. With the IntServ model, packet delivery is guaranteed. However, the use oI the
IntServ model can severely limit the scalability oI a network.
The DiIIServ model provides the greatest scalability and Ilexibility in implementing QoS in
a network. Network devices recognize traIIic classes and provide diIIerent levels oI QoS to
diIIerent traIIic classes.
Three ModeIs for QuaIity of Service
· Best-Effort (BE): No QoS is appIied to packets
· IntServ: AppIications signaI to the network that
they require speciaI QoS
· DiffServ: The network recognizes cIasses that
require speciaI QoS
Best-Effort ModeI
This topic explains the key Ieatures oI the Best-EIIort model Ior QoS.
The Internet was designed Ior best-eIIort, no-guarantee delivery oI packets. This behavior is
still predominant on the Internet today.
II QoS policies are not implemented, traIIic is Iorwarded using the Best-EIIort model. All
network packets are treated exactly the samean emergency voice message is treated exactly
like a digital photograph attached to an e-mail. Without QoS implemented, the network cannot
tell the diIIerence and, as a result, cannot treat packets preIerentially.
When you drop a letter in standard postal mail, you are using a Best-EIIort model. Your letter
will be treated exactly the same as every other letter'it will get there when it gets there.`
With the Best-EIIort model the letter may actually never arrive and, unless you have a separate
notiIication arrangement with the letter recipient, you may never know iI the letter does not
arrive.
Best-Effort ModeI
It will get there when it gets
there.
· The Internet was initiaIIy
based on a best-effort
packet deIivery service.
· This is the defauIt mode
for aII traffic.
· No differentiation between
types of traffic.
· Like using standard maiI.
The Best-EIIort model does have two signiIicant beneIits:
It has virtually unlimited scalability. The only way to reach scalability limits is to reach
bandwidth limits; then, everything becomes equally delayed.
No special QoS mechanisms need be employed to use the Best-EIIort model. It is, as a
result, the easiest and quickest to deploy.
The Best-EIIort model also has obvious drawbacks:
Nothing is guaranteed. Packets will arrive whenever they can, in any order possible, iI they
arrive at all.
Packets are not given preIerential treatment. Critical data is treated the same as casual e-
mail.
Best-Effort ModeI (Cont.)
+ Benefits:
· HighIy scaIabIe
· No speciaI mechanisms required
÷ Drawbacks:
· No service guarantees
· No service differentiation
Integrated Services ModeI
This topic explains the key Ieatures oI the IntServ model Ior QoS.
Some applications, such as high-resolution video, require consistent, dedicated bandwidth to
provide suIIicient quality Ior viewers. The IntServ model was introduced to guarantee
predictable network behavior Ior these applications.
Because the IntServ model reserves bandwidth throughout a network, no other traIIic can use
the reserved bandwidth. Bandwidth unused, but reserved, is wasted.
This is similar to a concept known as 'Hard QoS.¨ With Hard QoS traIIic characteristics such
as bandwidth, delay, and packet-loss rates, are guaranteed end-to-end. This guarantee ensures
both predictable and guaranteed service levels Ior mission-critical applications. Guaranteed
traIIic cannot be impacted when guarantees are made, regardless oI additional network traIIic.
Hard QoS is accomplished by negotiating speciIic QoS requirements upon connection
establishment and by using Call Admission Controls (CACs) to ensure that no new traIIic will
violate the guarantee. Such guarantees require an end-to-end QoS approach with both
complexity and scalability limitations. Large network environments that contain heavy traIIic
loads will be extremely challenged to track QoS guarantees Ior hundreds oI thousands oI
signaled Ilows.
Using the IntServ model is like having a private courier airplane or truck dedicated to the
delivery oI your traIIic. It ensures quality and delivery, is expensive, and is not scalable.
Integrated Services ModeI
· Some appIications have
speciaI bandwidth and/or
deIay requirements.
· The IntServ modeI was
introduced to guarantee a
predictabIe behavior of
the network for these
appIications.
· Guaranteed deIivery: no
other traffic can use
reserved bandwidth.
· Like having your own
private courier pIane.
It will be there by 10:30 AM.
IntServ is a multiple-service model that can accommodate multiple QoS requirements. The
IntServ model inherits the connection-oriented approach Irom telephony network design. Every
individual communication must explicitly speciIy its traIIic descriptor as well as requested
resources to the network. The edge router perIorms admission control to ensure that available
resources are suIIicient in the network. The IntServ standard assumes that routers along a path
set and maintain state Ior each individual communication.
The role oI Resource Reservation Protocol (RSVP) in the Cisco QoS architecture is to provide
resource admission control Ior Voice over IP (VoIP) networks. II resources are available,
RSVP accepts a reservation and installs a traIIic classiIier in the QoS Iorwarding path. The
traIIic classiIier tells the QoS Iorwarding path how to classiIy packets Irom a particular Ilow
and what Iorwarding treatment to provide.
In this model the application requests a speciIic kind oI service Irom the network beIore
sending data. The application inIorms the network oI its traIIic proIile and requests a particular
kind oI service that can encompass its bandwidth and delay requirements. The application is
expected to send data only after it gets a conIirmation Irom the network. It is also expected to
send data that lies within its described traIIic proIile.
The network perIorms admission control based on inIormation Irom the application and
available network resources. It commits to meeting the QoS requirements oI the application as
long as the traIIic remains within the proIile speciIications. The network IulIills its commitment
by maintaining per-Ilow state, and then perIorming packet classiIication, policing, and
intelligent queuing based on that state.
Integrated Services ModeI (Cont.)
· Provides muItipIe service
IeveIs
· Requests specific kind of
service from the network
before sending data
· Uses RSVP to reserve
network resources
· Uses inteIIigent queuing
mechanisms
· End-to-end
The QoS Ieature set in Cisco IOS soItware includes these Ieatures that provide controlled-load
service:
RSVP can be used by applications to signal their QoS requirements to the router.
Intelligent queuing mechanisms can be used with RSVP to provide these QoS service
levels:
Guaranteed-rate: Allows applications to reserve bandwidth to meet their
requirements. For example, a VoIP application can reserve 32 Mbps end-to-end
using this type oI service. Cisco IOS QoS uses low latency queuing (LLQ) with
RSVP to provide this type oI service.
Controlled-load: Allows applications to have low delay and high throughput, even
during times oI congestion. For example, adaptive real-time applications such as the
playback oI a recorded conIerence can use this service. Cisco IOS QoS uses RSVP
with weighted random early detection (WRED) to provide this type oI service.
RSVP is an IP service that allows end systems or hosts on either side oI a router network to
establish a reserved-bandwidth path between them to predetermine and ensure QoS Ior their
data transmission. RSVP is currently the only standard signaling protocol designed to guarantee
network bandwidth Irom end to end Ior IP networks.
RSVP is an Internet Engineering Task Force (IETF) standard (RFC 2205) protocol Ior allowing
an application to dynamically reserve network bandwidth. RSVP enables applications to
request a speciIic QoS Ior a data Ilow (shown in the graphic). Cisco implementation also allows
RSVP to be initiated within the network, using conIigured proxy RSVP. Network managers can
take advantage oI RSVP beneIits in the network, even Ior non-RSVP-enabled applications and
hosts.
Hosts and routers use RSVP to deliver QoS requests to the routers along the paths oI the data
stream. Hosts and routers also use RSVP to maintain router and host state to provide the
requested service, usually bandwidth and latency. RSVP uses a mean data rate; that is, the
largest amount oI data the router will keep in queue and the minimum QoS used to determine
bandwidth reservation.
LLQ or WRED act as the workhorses Ior RSVP, setting up the packet classiIication and
scheduling that is required Ior the reserved Ilows. Using LLQ, RSVP can deliver an IntServ
guaranteed service. Using WRED, it can deliver a controlled-load service. RSVP can be
deployed in existing networks with a soItware upgrade.
· RSVP QoS services
÷ Guaranteed service
÷ ControIIed service
· RSVP provides the poIicy to QoS mechanisms
The main beneIits oI the IntServ model and RSVP are:
It signals QoS requests per individual Ilow. The network can then provide guarantees to
these individual Ilows. The problem with this is that it does not scale to large networks
because oI the large numbers oI concurrent RSVP Ilows.
It inIorms network devices oI Ilow parameters (IP addresses and port numbers). Some
applications use dynamic port numbers, which can be diIIicult Ior network devices to
recognize. Network-based application recognition (NBAR) is a mechanism that has been
introduced to supplement RSVP Ior applications that use dynamic port numbers but do not
use RSVP.
It supports admission control that allows a network to reject (or downgrade) new RSVP
sessions iI one oI the interIaces in the path has reached the limit (that is, all reservable
bandwidth is booked).
The main drawbacks oI the IntServ model and RSVP are:
Continuous signaling because oI the stateIul RSVP operation.
RSVP is not scalable to large networks where per-Ilow guarantees would have to be made
to thousands oI Ilows.
+ Benefits:
· ExpIicit resource admission controI (end to end)
· Per-request poIicy admission controI (authorization object,
poIicy object)
· SignaIing of dynamic port numbers (for exampIe, H.323)
÷ Drawbacks:
· Continuous signaIing because of statefuI architecture
· A fIow-based approach is not scaIabIe to Iarge
impIementations such as the pubIic Internet (can be made
more scaIabIe when combined with eIements of the
Differentiated Services ModeI)
Differentiated Services ModeI
This topic explains the key Ieatures oI the DiIIServ model Ior QoS.
The DiIIServ model was designed to overcome the limitations oI both the Best-EIIort and
IntServ models. The DiIIServ model can provide an 'almost guaranteed¨ QoS while still being
cost-eIIective and scalable.
This is similar to a concept known as 'SoIt QoS.¨ With SoIt QoS, QoS mechanisms are used
without prior signaling. In addition, QoS characteristics (bandwidth and delay, Ior example),
are managed on a hop-by-hop basis by policies that are established independently at each
intermediate device in the network. The soIt QoS approach is not considered an end-to-end
QoS strategy because end-to-end guarantees cannot be enIorced. However, soIt QoS is a more
scalable approach to implementing QoS than hard QoS because many (hundreds or potentially
thousands) oI applications can be mapped into a small set oI classes upon which similar sets oI
QoS behaviors are implemented. Although QoS mechanisms in this approach are enIorced and
applied on a hop-by-hop basis, uniIormly applying global meaning to each traIIic class
provides both Ilexibility and scalability.
With DiIIServ, network traIIic is divided into classes based on business requirements. Each oI
the classes can then be assigned a diIIerent level oI service. As the packets traverse a network,
each oI the network devices identiIies the packet class and services the packet according to that
class.
· Network traffic identified
by cIass
· Network QoS poIicy
enforces differentiated
treatment of traffic
cIasses
· You choose the IeveI of
service for each traffic
cIass
· Like using a package
deIivery service
Do you want overnight
delivery?
Do you want 2-day air
delivery?
Do you want 3- to 7-day
ground delivery?
It is possible to choose many levels oI service with DiIIServ. For example, voice traIIic Irom IP
Phones is usually given preIerential treatment over all other application traIIic. E-mail is
generally given 'best-eIIort¨ service. And nonbusiness traIIic can either be given very poor
service or blocked entirely.
DiIIServ works like a package delivery service. You request (and pay Ior) a level oI service
when you send your package. Throughout the package network, the level oI service is
recognized and your package is given either preIerential or normal service, depending on what
you requested.
The DiIIServ model has two key beneIits:
It is highly scalable.
It provides many diIIerent levels oI quality.
The DiIIServ model also has drawbacks:
No absolute guarantee oI service quality can be made.
It requires a set oI complex mechanisms to work in concert throughout the network.
Differentiated Services ModeI (Cont.)
+ Benefits:
· HighIy scaIabIe
· Many IeveIs of quaIity possibIe
÷ Drawbacks:
· No absoIute service guarantee
· CompIex mechanisms
Summary
References
To learn more about the Integrated Services model, reIer to 'Integrated Services in the
Internet Architecture: an Overview¨ at the Iollowing URL:
http://www.ietI.org/rIc/rIc1633.txt
To learn more about RSVP, reIer to RFC 2210, 'The Use oI RSVP with IETF Integrated
Services¨ at the Iollowing URL: http://www.ietI.org/rIc/rIc2210.txt
To learn more about the DiIIerentiated Services model, reIer to RFC 2475 'An
Architecture Ior DiIIerentiated Services¨ at the Iollowing URL:
Summary
· There are three different modeIs for providing QoS: Best-
Effort, Integrated Services, and Differentiated Services.
· WhiIe the Best-Effort modeI is highIy scaIabIe, it has no
provision for differentiating among types of network
traffic and, as a resuIt, does not provide QoS.
· The Integrated Services modeI offers absoIute QoS
guarantees by expIicitIy reserving bandwidth, but is not
scaIabIe.
· The Differentiated Services modeI provides the abiIity to
cIassify network traffic and offer many IeveIs of QoS
whiIe being highIy scaIabIe.
Quiz
Q1) Which one oI the models Ior implementing QoS requires that applications signal their
special QoS requirements thereby reserving bandwidth?
A) Integrated Services
B) Best-EIIort
C) DiIIerentiated Services
D) Quantitative Services
Q2) Which one oI the models Ior implementing QoS oIIers no guarantee oI packet
delivery?
A) Best-EIIort
B) Integrated Services
Q3) Which oI the models Ior implementing QoS was introduced because certain
applications have special bandwidth and/or delay requirements?
A) Best-EIIort
Q4) Which QoS mechanism does Cisco IOS soItware rely upon Ior providing Integrated
Services?
A) Low Latency Queuing (LLQ)
B) Generic TraIIic Shaping (GTS)
C) Real Time Protocol (RTP)
D) Resource Reservation Protocol (RSVP)
Q5) Which two oI the Iollowing represent beneIits oI the Integrated Services model?
(Choose two.)
A) dynamic port number signaling
B) explicit resource admission control
C) a highly scalable QoS implementation
D) continuous signaling because oI a stateless architecture
Q6) Which two oI the Iollowing represent beneIits oI the DiIIerentiated Services model?
(Choose two.)
A) highly scalable
B) simple QoS mechanisms
C) absolute service guarantee
D) many levels oI quality possible
Quiz Answer Key
Q1) A
ReIates to: QoS Models
Q2) A
ReIates to: Best-Effort Model
Q3) B
ReIates to: Ìntegrated Services Model
Q4) D
Q5) A, B
Q6) A, D
ReIates to: Differentiated Services Model
The Differentiated Services
Model
Overview
DiIIServ is a multiple-service model designed to satisIy various QoS requirements. With
DiIIServ, the network tries to deliver a particular kind oI service that is based on the QoS
speciIied by each packet. This speciIication can occur in diIIerent ways; Ior example, using the
DiIIServ code point (DSCP) in IP packets or source and destination addresses. The network
uses the QoS speciIication oI each packet to classiIy, shape, and police traIIic and to perIorm
intelligent queuing.
ReIevance
The DiIIServ model is the primary model used to implement QoS in IP networks.
Objectives
Upon completing this lesson, you will be able to describe the DiIIerentiated Services model and
explain how it can be used to implement QoS in that network. This includes being able to meet
these objectives:
Explain the purpose and Iunction oI the DiIIServ model
Describe the basic Iormat oI and explain the purpose oI the DSCP Iield in the IP header
DeIine and explain the diIIerent per-hop behaviors used in DSCP
Explain the interoperability between DSCP-based and IP precedence-based devices in a
network
OutIine
OutIine
· Overview
· Differentiated Services ModeI
· DSCP Encoding
· Per-Hop Behaviors
· Backward CompatibiIity Using the CIass SeIector
· Summary
· Quiz
This topic explains the purpose and Iunction oI the DiIIServ model.
The DiIIServ architecture is based on a simple model where traIIic entering a network is
classiIied and possibly conditioned at the boundaries oI the network. The traIIic class is then
identiIied with a DSCP or bit marking in the IP header.
DSCP values are used to mark packets to select a per-hop behavior. Within the core oI the
network, packets are Iorwarded according to the per-hop behavior that is associated with the
DSCP. The per-hop behavior is deIined as an externally observable Iorwarding behavior
applied at a DS-compliant node to a collection oI packets with the same DSCP value.
One oI the primary principles oI the DiIIServ model is that you should mark packets as close to
the edge oI the network as possible. It is oIten a diIIicult and time-consuming task to
understand to which traIIic class a data packet belongs. ThereIore, you want to classiIy the data
as Iew times as possible. By marking the traIIic at the network edge, core network devices and
other devices along the Iorwarding path will be able to quickly determine the proper class oI
service (CoS) to apply to a given traIIic Ilow.
The primary advantage oI the DiIIServ model is scalability.
· Differentiated Services modeI describes services
associated with traffic cIasses.
· CompIex traffic cIassification and conditioning is
performed at network edge resuIting in a per-packet
Differentiated Services Code Point (DSCP).
· No per-fIow/per-appIication state in the core.
· Core onIy performs simpIe 'per-hop behaviors' on traffic
aggregates.
· The goaI is scaIabiIity.
DiIIServ is used Ior mission-critical applications and Ior providing end-to-end QoS. Typically,
DiIIServ is appropriate Ior aggregate Ilow because it perIorms a relatively coarse level oI
traIIic classiIication.
The DiIIServ model describes services and allows many user-deIined services to be used in a
DiIIServ-enabled network.
Services are deIined as QoS requirements and guarantees that are provided to a collection oI
packets with the same DSCP value. Services are provided to classes. A class can be identiIied
as a single application, multiple applications with like service needs, or, based on source or
destination IP addresses.
Provisioning is used to allocate resources to deIined traIIic classes. An example oI provisioning
would be the set oI methods that are used to set up the network conIigurations on devices that
would correctly enable the devices to provide the correct set oI capabilities Ior a particular
traIIic class.
The idea is Ior the network to recognize a class without having to receive a request Irom
applications. This allows the QoS mechanisms to be applied to other applications that do not
have the RSVP Iunctionality, which is the case in 99 percent oI applications that use IP.
The introduction oI DSCPs replaces IP precedence, a three-bit Iield in the type oI service (ToS)
byte oI the IP header originally used to classiIy and prioritize types oI traIIic. However,
DiIIServ maintains interoperability with non-DiIIServ-compliant devices (those that still use IP
precedence). Because oI this backward compatibility, DiIIServ can be deployed gradually in
large networks.
Differentiated Services ModeI (Cont.)
· Wide variety of services and provisioning
poIicies
· DecoupIe service and appIication in use
· No appIication modification
· No hop-by-hop signaIing
· InteroperabiIity with non-DiffServ-compIiant
nodes
· IncrementaI depIoyment
DSCP Encoding
This topic describes the basic Iormat oI DSCP and explains the purpose oI the DSCP Iield in
the IP header.
The DiIIServ model uses the DiIIServ Iield in the IP header to mark packets according to their
classiIication into behavior aggregates (BAs). The DiIIServ Iield occupies the same eight bits
oI the IP header that were previously used Ior the ToS byte.
There are three IETF standards describing the purpose oI those eight bits:
RFC 791 includes speciIication oI the ToS Iield where the high-order three bits are used Ior
IP precedence. The other bits are used Ior delay, throughput, reliability, and cost.
RFC 1812 modiIies the meaning oI the ToS Iield by removing meaning Irom the Iive low-
order bits (those bits should all be zero). This gained widespread use and became known as
the original IP precedence.
RFC 2474 replaces the ToS Iield with the DiIIServ Iield where the six high-order bits are
used Ior the DSCP. The remaining two bits are used Ior explicit congestion notiIication.
Each DSCP value identiIies a BA. Each BA is assigned a per-hop behavior (PHB). Each PHB
is implemented using the appropriate QoS mechanism or a set oI QoS mechanisms.
DSCP Encoding
· DiffServ fieId: The IPv4 header ToS octet or the IPv6
traffic cIass octet when interpreted in conformance
with the definition given in RFC2474
· DSCP: The first six bits of the DiffServ fieId, used to
seIect a PHB (forwarding and queuing method)
Per-Hop Behaviors
This topic deIines and explains the diIIerent per-hop behaviors that are used in DSCP.
The Iollowing PHBs are deIined by IETF standards:
Default PHB: Used Ior Best-EIIort service (bits 5 to 7 oI DSCP ÷ '000¨)
Expedited Forwarding PHB: Used Ior low-delay service (bits 5 to 7 oI DSCP ÷ '101¨)
Assured Forwarding PHB: Used Ior guaranteed bandwidth service (bits 5 to 7 oI DSCP ÷
'001¨, '010¨, '011¨, or '100¨)
Class Selector PHB: Used Ior backward compatibility with non-DS-compliant devices
(RFC 1812 compliant devices |bits 2 to 4 oI DSCP ÷ '000¨|)
Per-Hop Behavior
· DSCP seIects PHB throughout the network
÷ DefauIt PHB (FIFO, TaiI Drop)
÷ Expedited Forwarding (EF) PHB
÷ Assured Forwarding (AF) PHB
÷ CIass SeIector (IP precedence) PHB
The EF PHB is identiIied, based on the Iollowing parameters:
Ensures a minimum departure rate. Provides the lowest possible delay to delay-sensitive
applications.
Guarantees bandwidth. Prevents starvation oI the application iI there are multiple
applications using EF PHB.
Polices bandwidth. Prevents starvation oI other applications or classes that are using
this PHB.
Packets requiring Expedited Forwarding should be marked with DSCP binary value
'101110¨ (46 or 0x2E).
Non-DiIIServ-compliant devices will regard EF DSCP value '101110¨ as IP precedence 5
(101).This precedence is the highest user-deIinable IP precedence and is typically used Ior
delay-sensitive traIIic (such as VoIP). Bits 5 to 7 oI the EF DSCP value are '101,¨ which
matches IP precedence 5 and allows backward compatibility.
Per-Hop Behavior (Cont.)
· Expedited Forwarding (EF) PHB:
÷ Ensures a minimum departure rate
÷ Guarantees bandwidth-the cIass is guaranteed an amount of
bandwidth with prioritized forwarding
÷ PoIices bandwidth-the cIass is not aIIowed to exceed the
guaranteed amount (excess traffic is dropped)
· DSCP vaIue: "101110"; Iooks Iike IP precedence 5 to
non-DiffServ compIiant devices
÷ Bits 5 to 7: "101" = 5 (Same three bits used for IP precedence)
÷ Bits 3 to 4: "11" = Low drop probabiIity
÷ Bit 2: just "0"
The Assured Forwarding (AF) PHB is identiIied, based on the Iollowing parameters:
Guarantees a certain amount oI bandwidth to an AF class.
Allows access to extra bandwidth, iI available.
Packets requiring AF PHB should be marked with DSCP value 'aaadd0¨ where 'aaa¨ is the
number oI the class and 'dd¨ is the drop probability.
There are Iour standard-deIined AF classes. Each class should be treated independently and
have allocated bandwidth that is based on the QoS policy.
· Assured Forwarding (AF) PHB:
÷ Guarantees bandwidth
÷ AIIows access to extra bandwidth if avaiIabIe
· Four standard cIasses (af1, af2, af3 and af4)
· DSCP vaIue range: "aaadd0"
÷"aaa" is a binary vaIue of the cIass
÷ "dd" is drop probabiIity
As illustrated in the Iigure and the table, there are three DSCP values assigned to each oI the
Iour AF classes.
AF CIass
AF CIass Drop ProbabiIity DSCP VaIue
AF Class 1 Low 001 01 0
Medium 001 10 0
High 001 11 0
Medium 010 10 0
High 010 11 0
Medium 011 10 0
High 011 11 0
Medium 100 10 0
High 100 11 0
· Each AF cIass uses three DSCP vaIues.
· Each AF cIass is independentIy forwarded with its
guaranteed bandwidth.
· Congestion avoidance is used within each cIass to
prevent congestion within the cIass.
An AF implementation must attempt to minimize long-term congestion within each class, while
allowing short-term congestion resulting Irom bursts. This requires an active queue
management algorithm. An example oI such an algorithm is WRED that is described in detail
in the 'Congestion Avoidance¨ module in this course.
The AF speciIication does not deIine the use oI a particular algorithm, but does require that
several properties hold.
An AF implementation must detect and respond to long-term congestion within each class by
dropping packets, while handling short-term congestion (packet bursts) by queuing packets.
This implies the presence oI a smoothing or Iiltering Iunction that monitors the instantaneous
congestion level and computes a smoothed congestion level. The dropping algorithm uses this
smoothed congestion level to determine when packets should be discarded.
The dropping algorithm must treat all packets within a single class and precedence level
identically. ThereIore, within a single traIIic class, the discard rate oI a particular packet Ilow
will be proportional to the percentage oI the total amount oI traIIic.
· A DiffServ node must aIIocate a configurabIe,
minimum amount of forwarding resources
(buffer space and bandwidth) per AF cIass.
· Excess resources may be aIIocated between
non-idIe cIasses. The manner must be specified.
· Reordering of IP packets of the same fIow is not
aIIowed if they beIong to the same AF cIass.
Backward CompatibiIity Using the CIass SeIector
This topic explains the interoperability between DSCP-based and IP-precedence-based devices
in a network.
The meaning oI the 8 bits in the DiIIServ Iield oI the IP packet has changed over time to meet
the expanding requirements oI IP networks.
Originally, the Iield was reIerred to as the ToS Iield and the Iirst 3 bits oI the Iield (bits 7 to 5)
deIined a packet IP precedence value. A packet could be assigned one oI six priorities based
on the value oI the IP precedence value (8 total values minus 2 reserved values). IP precedence
5 ('101¨) was the highest priority that could be assigned. (RFC 791)
RFC 2474 replaced the ToS Iield with the DiIIServ Iield where a range oI eight values (class
selector) is used Ior backward compatibility with IP precedence. There is no compatibility with
other bits used by the ToS Iield.
The class selector PHB was deIined to provide backwards compatibility Ior DSCP with ToS-
based IP precedence. RFC 1812 simply prioritizes packets according to the precedence value.
The PHB is deIined as the probability oI timely Iorwarding. Packets with higher IP precedence
should be (on average) Iorwarded in less time than packets with lower IP precedence.
The last three bits oI the DSCP (2 to 4) set to zero identiIy a class selector PHB.
Backward CompatibiIity Using the
CIass SeIector
· CIass SeIector "xxx000" DSCP
· CompatibiIity with current IP precedence usage (RFC
1812) = maps IP precedence to DSCP
· Differentiates probabiIity of timeIy forwarding
(xyz000) >= (abc000) if xyz > abc
÷ If a packet has DSCP = "011000", then it has a greater
probabiIity of timeIy forwarding than a packet with DSCP =
"001000"
Summary
References
To learn more about DiIIerentiated Services, reIer to 'An Architecture Ior DiIIerentiated
Services¨ at the Iollowing URL: http://www.ietI.org/rIc/rIc2475.txt
To learn more about the DS Iield, reIer to 'DeIinition oI the DiIIerentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers¨ at the Iollowing URL:
To learn more about Assured Forwarding, reIer to 'Assured Forwarding per-hop behavior
(PHB) Group¨ at the Iollowing URL: http://www.ietI.org/rIc/rIc2597.txt
To learn more about Expedited Forwarding, reIer to 'An Expedited Forwarding per-hop
behavior (PHB)¨ at the Iollowing URL: http://www.ietI.org/rIc/rIc2598.txt
To learn more about the Class Selector PHB, reIer to RFC 2474 at the Iollowing URL:
Summary
· The Differentiated Services modeI describes services
associated with traffic cIasses.
· CompIex traffic cIassification and conditioning is performed at
network edge resuIting in a per-packet DSCP.
· A per-hop behavior is an externaIIy observabIe forwarding
behavior appIied at a DiffServ-compIiant node to a DiffServ
behavior aggregate.
· The EF PHB guarantees and poIices bandwidth whiIe ensuring
a minimum departure rate.
· The AF PHB guarantees bandwidth whiIe providing four cIasses
each having three DSCP vaIues.
· The DSCP is backward compatibIe with IP precedence and
cIass-seIector code point.
Quiz
Q1) In the diIIerentiated service model, where should packets be marked?
A) just as they hit the Iirst congested link
B) as they leave the service provider core
C) as soon as they hit the service provider core
D) as close to the edge oI the network as possible
Q2) Using DiIIServ, how aware oI the actual application is the core oI the network?
A) no awareness at all
B) awareness at layer 2 through MAC address
C) awareness at layer 5 through HTTP connections
D) awareness at layer 4 through TCP/UDP port numbers
Q3) What is the term used to describe the Iorwarding behavior that is applied at a DiIIServ-
compliant node to a traIIic class?
A) Per-Hop Behavior (PHB)
B) Behavior Aggregate (BA)
C) Behavior ModiIication (BM)
D) Class Behavior Mechanism (CBM)
Q4) The DSCP Iield makes up which bits oI the entire 8-bit DiIIServ Iield?
A) the entire 8 bits oI the DiIIServ Iield
B) the last 6 least signiIicant bits (0 to 5)
C) the Iirst 6 most signiIicant bits (2 to 7)
D) maps over the IP precedence portion (bits 5 to 7)
Q5) Which three oI the Iollowing Per-Hop Behaviors (PHBs) is determined by content oI
the Iirst 3 bits (5 to 3) oI the DSCP Iield? (Choose three.)
A) deIault PHB
B) class selector PHB
C) Assured Forwarding PHB
D) Expedited Forwarding PHB
Q6) Which DSCP value appears to be IP precedence 5 to a non-DiIIServ-compliant device?
A) 5 '101¨
B) 45 '101101¨
C) 46 '101110¨
D) 47 '101111¨
Quiz Answer Key
Q1) D
Q2) A
Q3) A
Q4) C
ReIates to: DSCP Encoding
Q5) A, C, D
ReIates to: Per-Hop Behaviors
Q6) C
ReIates to: Backward Compatibility Using the Class Selector
ÌP QoS Mechanisms
Overview
IP QoS mechanisms are used to implement a coordinated QoS policy in devices throughout the
network. The moment an IP packet enters the network, it is classiIied and usually marked with
its class identiIication. From that point on, the packet is treated by a variety oI IP QoS
mechanisms according to the packet classiIication. Depending upon the mechanisms it
encounters, the packet could be expedited, delayed, compressed, Iragmented, or even dropped.
ReIevance
The IP QoS mechanisms described in this lesson Iorm the base technologies that are used to
implement QoS in any IP network.
Objectives
Upon completing this lesson, you will be able to correctly match a list oI QoS actions to
mechanisms Ior implementing QoS and identiIy where in a network the diIIerent QoS
mechanisms are commonly used. This includes being able to meet these objectives:
List the key mechanisms used to implement QoS in an IP network
DeIine classiIication and identiIy where classiIication is commonly implemented in a
network
DeIine marking and identiIy where marking is commonly implemented in a network
DeIine congestion management and identiIy where congestion management is commonly
implemented in a network
DeIine congestion avoidance and identiIy where congestion avoidance is commonly
DeIine policing and shaping and identiIy where policing and shaping are commonly
Explain the Iunctions oI compression and identiIy where compression is commonly
implemented in the network
Explain the Iunctions oI LFI and identiIy where LFI is commonly implemented in the
network
IdentiIy whether QoS mechanisms are used Ior input or output or both
OutIine
OutIine
· Overview
· QoS Mechanisms
· CIassification
· Marking
· Congestion Management
· Congestion Avoidance
· PoIicing and Shaping
· Compression
· Link Fragmentation and InterIeaving
· AppIying QoS to Input and Output Interfaces
· Summary
· Quiz
QoS Mechanisms
This topic lists the key mechanisms use to implement QoS in an IP network.
This slide shows the main categories oI tools and describes in lay terms how they contribute to
QoS.
ClassiIication and marking is the identiIying and splitting oI traIIic into diIIerent classes and
the marking oI traIIic according to behavior and business policies.
Congestion management is the prioritizing, protection, and isolation oI traIIic based on
markings.
Congestion avoidance discards speciIic packets based on markings, to avoid network
congestion.
TraIIic conditioning mechanisms police traIIic by dropping misbehaving traIIic to maintain
network integrity. They also shape traIIic to control bursts by queuing traIIic.
One type oI link eIIiciency technology is packet header compression that improves the
bandwidth eIIiciency oI a link. Another technology is link Iragmentation and interleaving (LFI)
that can decrease the 'jitter¨ oI voice transmission by reducing voice packet delay.
QoS Mechanisms
· CIassification: Each cIass-oriented QoS mechanism has
to support some type of cIassification.
· Marking: Used to mark packets based on cIassification
and/or metering.
· Congestion Management: Each interface must have a
queuing mechanism to prioritize transmission of
packets.
· Congestion Avoidance: Used to drop packets earIy in
order to avoid congestion Iater in the network.
· PoIicing and Shaping: Used to enforce a rate Iimit based
on the metering (excess traffic is either dropped,
marked, or deIayed).
· Link Efficiency: Used to improve bandwidth efficiency
through compression and Iink fragmentation and
interIeaving.
CIassification
This topic deIines classiIication and identiIies where classiIication is commonly implemented
in a network.
ClassiIication is the identiIying and splitting oI traIIic into diIIerent classes. In a QoS-enabled
network, all traIIic is classiIied at the input interIace oI every QoS-aware device. Packet
classiIication can be recognized based on many Iactors including:
DSCP
IP precedence
Source address
Destination address
The concept oI 'trust¨ is key Ior deploying QoS. When an end device (such as a workstation or
an IP Phone) marks a packet with CoS or DSCP, a switch or router has the option oI accepting
or not accepting values Irom the end device. II the switch or router chooses to accept the
values, the switch or router 'trusts¨ the end device. II the switch or router trusts the end device,
it does not need to do any reclassiIication oI packets coming Irom that interIace. II the switch
or router does not trust the interIace, then it must perIorm a reclassiIication to determine the
appropriate QoS value Ior the packet coming Irom that interIace. Switches and routers are
generally set to 'not trust¨ end devices and must speciIically be conIigured to 'trust¨ packets
coming Irom an interIace.
ClassiIication tools include NBAR, policy-based routing (PBR), and classiIication and marking
using modular QoS command-line interIace (CLI |MQC|).
CIassification
· CIassification is the identifying and spIitting of traffic into
different cIasses.
· Traffic can be cIassed by various means incIuding the
DSCP.
· ModuIar QoS CLI aIIows cIassification to be impIemented
separateIy from poIicy.
Note: The tools for classification are covered in detail in the ¨Classification and Marking¨ module in
this course.
Marking
This topic deIines marking and identiIies where marking is commonly implemented in a
network.
Marking, which is also known as coloring, involves marking each packet as a member oI a
network class so that devices throughout the rest oI the network can quickly recognize the
packet class. Marking is perIormed as close to the network edge as possible, and is typically
done using the MQC.
QoS mechanisms set bits in the DSCP or IP precedence Iields oI each IP packet according to
the class that the packet is in. The settings Ior the DSCP Iield and their relationship to the IP
precedence Iields were discussed in the previous lesson. Other Iields can also be marked to aid
in the identiIication oI a packet class.
Other QoS mechanisms use these bits to determine how to treat the packets when they arrive. II
they are marked as high-priority voice packets, the packets will generally never be dropped by
congestion avoidance mechanisms and be given immediate preIerence by congestion
management queuing mechanisms. On the other hand, iI the packets are marked as low-priority
Iile transIer packets, they will be dropped when congestion is occurring and generally move to
the end oI the congestion management queues.
Note: The tools for marking are covered in detail in the ¨Classification and Marking¨ module in this
course.
Marking
· Marking, which is aIso known as coIoring, marks each
packet as a member of a network cIass so that the packet
cIass can be quickIy recognized throughout the rest of
the network.
Congestion Management
This topic deIines congestion management and identiIies where congestion management is
commonly implemented in a network.
Congestion management mechanisms (queuing algorithms) use the marking on each packet to
determine in which queue to place packets. DiIIerent queues are given diIIerent treatment by
the queuing algorithm based on the class oI packets in the queue. Generally, queues with higher
priority packets receive preIerential treatment.
All output interIaces in a QoS-enabled network use some kind oI congestion management
(queuing) mechanism to manage the outIlow oI traIIic. Each queuing algorithm was designed
to solve a speciIic network traIIic problem and has a particular eIIect on network perIormance.
The Cisco IOS soItware Ieatures Ior congestion management or queuing, include:
FIFO
Priority queuing (PQ)
Custom queuing (CQ)
Weighted Iair queuing (WFQ)
Class-based weighted Iair queuing (CBWFQ)
LLQ
LLQ is currently the preIerred queuing method. It is a hybrid (PQ and CBWFQ) queuing
method that was developed to speciIically meet the requirements oI real-time traIIic, such as
voice.
· Congestion management uses the marking on each
packet to determine in which queue to pIace packets.
· Congestion management utiIizes sophisticated queuing
technoIogies such as Weighted Fair Queuing (WFQ) and
Iow Iatency queuing (LLQ) to ensure that time-sensitive
packets Iike voice are transmitted first.
Note: All of the queuing technologies discussed are described further in the ¨Congestion
Management¨ module in this course.
Congestion Avoidance
This topic deIines congestion avoidance and identiIies where congestion avoidance is
Congestion-avoidance mechanisms monitor network traIIic loads in an eIIort to anticipate and
avoid congestion at common network bottlenecks. Congestion avoidance is achieved through
packet dropping.
Congestion avoidance mechanisms are typically employed on output interIaces wherever a
high-speed link or set oI links Ieed into a lower-speed link (that is, a LAN Ieeding into a slower
WAN link.) This ensures that the WAN is not instantly congested by LAN traIIic.
WRED is a Cisco primary congestion-avoidance technique.
WRED increases the probability that congestion is avoided by dropping low-priority packets
rather than high-priority packets.
Note: WRED is not recommended for voice queues. A network should not be designed to drop
voice packets.
Note: The tools for congestion avoidance are covered in detail in the ¨Congestion Avoidance¨
module in this course.
· Congestion avoidance may randomIy drop packets from
seIected queues when previousIy defined Iimits are
reached.
· By dropping packets earIy, congestion avoidance heIps
prevent bottIenecks downstream in the network.
· Congestion avoidance technoIogies incIude Random
EarIy Detection (RED) and Weighted RED (WRED).
PoIicing and Shaping
This topic deIines policing and shaping and identiIies where policing and shaping are
Policing or shaping mechanisms are oIten used to condition traIIic beIore transmitting traIIic to
a network or receiving traIIic Irom a network.
Policing is the ability to control bursts and conIorm traIIic to ensure that certain types oI traIIic
get certain types oI bandwidth.
Policing drops or marks packets when predeIined limits are reached.
Policing mechanisms can be set to Iirst drop traIIic classes that have lower QoS priority
markings.
Policing mechanisms can be used at either input or output interIaces. They are typically used to
control the Ilow into a network device Irom a high-speed link by dropping excess low-priority
packets. A good example would be the use oI policing by a service provider to throttle a high-
speed inIlow Irom a customer that was in excess oI the service agreement. In a TCP
environment, this will cause the sender to slow their packet transmission.
Tools include class-based policing and committed access rate (CAR).
Note: The tools for policing are covered in detail in the ¨Traffic Policing and Shaping¨ module in
this course.
PoIicing
· PoIicing drops or marks packets when a
predefined Iimit is reached.
Shaping helps smooth out speed mismatches in the network and limits transmission rates.
Shaping mechanisms are used on output interIaces. They are typically used to limit the Ilow
Irom a high-speed link to a lower-speed link to ensure that the lower-speed link does not
become overrun with traIIic. Shaping could also be used to manage the Ilow oI traIIic at a point
in the network where multiple Ilows are aggregated. Service providers use it to manage the
Ilow oI traIIic to and Irom customers to ensure that the Ilows conIorm to service agreements
between the customer and provider.
Cisco QoS soItware solutions include two traIIic-shaping tools to manage traIIic and
congestion on the network: Generic TraIIic Shaping (GTS) and Frame Relay traIIic shaping
(FRTS).
Note: The tools for shaping are covered in detail in the ¨Traffic Policing and Shaping¨ module in
this course.
Shaping
· Shaping queues packets when a predefined Iimit
is reached.
Compression
This topic explains the Iunctions oI compression and identiIies where compression is
commonly implemented in the network.
Cisco IOS QoS soItware oIIers link-eIIiciency mechanisms that work in conjunction with
queuing and traIIic shaping to manage existing bandwidth more eIIiciently and predictably.
One oI these is compressed Real-Time Transport Protocol (cRTP).
Real-Time Transport Protocol (RTP) is a host-to-host protocol that is used Ior carrying
converged traIIic (including packetized audio and video) over an IP network. RTP provides
end-to-end network transport Iunctions intended Ior applications that transmit real-time
requirements such as audio, video, simulation data multicast, or unicast network services.
A voice packet carrying a 20-byte voice payload, Ior example, typically carries a 20-byte IP
header, an 8-byte User Datagram Protocol (UDP) header, and a 12-byte RTP header. By using
cRTP, as shown in the illustration, the three headers oI a combined 40 bytes are compressed
down to 2 or 4 bytes, depending on whether or not the CRC is transmitted. This compression
can dramatically improve the perIormance oI a link.
Compression would typically be used on WAN links between sites to improve bandwidth
eIIiciency.
Note: Compression technology is discussed in the ¨Link Efficiency Mechanisms¨ module in this
course.
Compression
· Header compression can dramaticaIIy reduce
the overhead associated with voice transport.
Link Fragmentation and InterIeaving
This topic explains the Iunctions oI LFI and identiIies where LFI is commonly implemented in
the network.
Interactive traIIic, such as Telnet and VoIP, is susceptible to increased latency and jitter when
the network processes large packets, such as LAN-to-LAN FTP Telnet transIers, traversing a
WAN link. This susceptibility increases as the traIIic is queued on slower links.
LFI can reduce delay and jitter on slower-speed links by breaking up large datagrams and
interleaving low-delay traIIic packets with the resulting smaller packets.
LFI would typically be used on WAN links between sites to ensure minimal delay Ior voice and
video traIIic.
Note: LFÌ technology is covered in detail in the ¨Link Efficiency Mechanisms¨ module in this
course.
· Without Link Fragmentation and InterIeaving, time-
sensitive voice traffic can be deIayed behind Iong, non-
time-sensitive data packets.
· Link Fragmentation breaks Iong data packets apart and
interIeaves time-sensitive packets so that they are not
deIayed.
AppIying QoS to Input and Output Interfaces
This topic identiIies whether QoS mechanisms are used Ior input or output or both.
In a QoS-enabled network, classiIication is perIormed on every input interIace.
Marking should be perIormed as close to the network edge as possiblein the originating
network device, iI possible. Devices Iarther Irom the edge oI the network, such as routers and
switches, can be conIigured to 'trust¨ or 'untrust¨ the markings made by devices on the edge oI
the network. An IP Phone, Ior example, will not 'trust¨ the markings oI an attached PC while a
switch will generally be conIigured to 'trust¨ the markings oI an attached IP Phone.
Congestion management, congestion avoidance, and traIIic shaping mechanisms only make
sense to use on output interIaces as they help maintain smooth operation oI links by controlling
how much and which type oI traIIic is allowed on a link. On some router and switch platIorms,
congestion management mechanisms such as weighted round robin (WRR) and modiIied
deIicit round robin (MDRR) can be applied on the input interIace.
Congestion avoidance is typically employed on an output interIace wherever there is a chance
that a high-speed link or aggregation oI links Ieeds into a slower link (a LAN Ieeding into a
WAN).
Policing and shaping are typically employed on output interIaces to control the Ilow oI traIIic
Irom a high-speed link to lower-speed links. Policing is also employed on input interIaces to
control the Ilow into a network device Irom a high-speed link by dropping excess low-priority
packets.
Both compression and LFI are typically used on slower-speed WAN links between sites to
improve bandwidth eIIiciency.
AppIying QoS to Input and
Output Interfaces
Congestion
Management*
Congestion
Avoidance
(aIways)
(high-speed to
Iow-speed Iinks or
aggregation points)
Mark
CIassify
(aIways)
(as cIose to the
source as possibIe)
PoIicing PoIicing
Shaping (going to Iower-speed
Iinks or from points of
aggregation)
(coming from a
higher-speed Iink or
aggregation)
Fragmentation &
InterIeaving
Compression
(Iow-speed
WAN Iinks)
Output
interface
Input
interface
Summary
References
To see more inIormation on Cisco IP QoS mechanisms, reIer to 'Quality oI Service (QoS)¨
at the Iollowing URL:
http://www.cisco.com/en/US/tech/tk543/tech¸topology¸and¸network¸serv¸and¸protocol¸s
uite¸home.html
Summary
· Different mechanisms can be used to impIement QoS in a
network: cIassification, marking, congestion management,
congestion avoidance, poIicing, shaping, and Iink efficiency.
· First step is aIways to identify cIasses of traffic so that the
appropriate QoS treatment can be appIied to different traffic
types.
· Congestion avoidance mechanisms heIp prevent Iink
congestion by dropping excess traffic before it becomes a
probIem.
· Traffic conditioners such as poIicers and shapers are used to
Iimit the maximum rate of traffic sent or received on an
interface.
· Bandwidth efficiency can be improved through Iink efficiency
mechanisms such as compression and fragmentation and
interIeaving.
Quiz
Q1) Which oI the Iollowing IP QoS mechanisms queues the transmission oI packets?
A) metering
B) traIIic shaping
C) traIIic policing
D) congestion avoidance
Q2) By which Iour Iields are IP packets oIten classiIied? (Choose Iour.)
A) TTL
B) DSCP
C) IP precedence
D) source address
E) destination address
Q3) Which one oI the Iollowing congestion management technologies was developed
speciIically to meet the requirements oI real-time traIIic such as voice?
A) low latency queuing (LLQ)
B) weighted Iair queuing (WFQ)
C) class-based WFQ (CBWFQ)
D) priority-voice queuing (PVQ)
Q4) The acronym RED stands Ior ¸¸¸¸¸.
A) random early detection
B) regular expedited dropping
C) regular early dropping
D) random early dropping
Q5) Which two IP QoS mechanisms manage traIIic by queuing packets? (Choose two.)
A) traIIic shaping
B) traIIic policing
C) congestion avoidance
D) congestion management
Q6) How many header bytes does the normal voice packet carry Ior IP, UDP, and RTP?
A) 32
B) 40
C) 64
D) 80
Quiz Answer Key
Q1) B
ReIates to: QoS Mechanisms
Q2) B, C, D, E
ReIates to: Classification
Q3) A
ReIates to: Congestion Management
Q4) A
ReIates to: Congestion Avoidance
Q5) A, D
ReIates to: Policing and Shaping
Q6) B
ReIates to: Compression
Case Study: QoS Mechanisms
Overview
This case study activity provides inIormation regarding the QoS administrative policy
requirements oI a large, multisite network. Your task is to work with a partner to evaluate the
QoS requirements, and based on these requirements, identiIy where QoS mechanisms should be
applied. You will discuss your solution with the instructor and other classmates, and the
instructor will present a solution Ior the case study to the class.
ReIevance
The ability to properly sort traIIic into service classes and correctly position QoS mechanisms
are important steps in correctly implementing an administrative QoS policy.
Objectives
In this activity, you will correctly identiIy which QoS mechanisms can be used, and where QoS
mechanisms should be applied to the network to implement an administrative QoS policy.
Upon completing this case study, you will be able to meet these objectives:
Review customer QoS requirements
IdentiIy QoS service class requirements
IdentiIy where QoS mechanisms should be applied to the network to meet customer
requirements
Present a solution to the case study
To beneIit Iully Irom this activity, you must have these prerequisite skills and knowledge:
OutIine
The outline lists the topics included in this activity.
Required Resources
These are the resources required to complete this exercise:
Case Study Activity: QoS Mechanisms
A workgroup consisting oI two learners
Job Aids
No job aids are required to complete this case study.
OutIine
· Overview
· Review Customer QoS Requirements
· Identify QoS Service CIass Requirements
· Identify Network Locations Where QoS
Mechanisms ShouId Be AppIied
· Present Your SoIution
Case Study Tasks
The activity includes these tasks:
Step 1 Review customer QoS requirements: Completely read the customer requirements
provided.
Step 2 Identify QoS service class requirements: With the aid oI your partner, identiIy the
service classes required to implement the administrative QoS policy based on
customer requirements.
Step 3 Identify network locations where QoS mechanisms should be applied: IdentiIy
locations in the network where the QoS mechanisms should be applied to most
eIIectively implement QoS policy.
Step 4 Present your solution: AIter the instructor presents a solution to the case study,
present your solution to the class with your partner.
Case Study Verification
You have completed this activity when your case study solution has been presented to the class
and you have justiIied any major deviations Irom the case study solution supplied by the
instructor.
Review Customer QoS Requirements
Company Background
Nuevo Health Care Systems (NHCS) provides health care inIormation to health care
proIessionals in ten major regions oI the country.
Customer Situation
NHCS network currently has limited bandwidth capacity in their WAN links and they do not
envision being able to increase bandwidth in the near Iuture. All ten remote sites (two are
pictured in the network illustration) connect to the central site through a service provider
through a Frame Relay, Layer 2, 1-Mbps link service. The NHCS headquarters site also
connects to the service provider via a Frame Relay, Layer 2, 1-Mbps link. NHCS LAN
bandwidth is 10 Mbps. NHCS connects to the Internet through its headquarters site.
Since the installation oI a new IP telephony system, NHCS has been encountering increasingly
serious problems with their network:
Users oI the enterprise resource planning (ERP) applications have been complaining oI
unacceptable response times. Their sub-second response time has now stretched to multiple
seconds in many cases and up to a minute in some cases.
Key patient inIormation Iiles that used to arrive almost instantly are now taking 10 to 15
minutes to be transIerred Irom headquarters to users at the remote sites. (These are
moderate sized, mostly text Iiles.)
Patient graphics Iiles (x-rays, MRIs) that used to take 20 to 30 minutes to transIer between
the remote sites and headquarters now oIten have to be transIerred overnight. (This is
acceptable as they are usually not needed immediately and they tend to be extremely large
graphics Iiles.)
Users oI the new IP telephony devices are the most upset. The quality oI their calls is very
poor and their calls oIten just drop.
The key applications running on NHCS network are:
AppIications Running on NHCS Network
AppIication AppIication
Importance
Response Time
Requirements
Use of Bandwidth
(Daytime)
Enterprise Resource Planning CriticaI Immediate Moderate
Patient Ìnformation Files Important Immediate Moderate
Patient Graphics Files Important MinimaI Heavy
ÌP Telephony Important No deIay Moderate
Browser Traffic Not important MinimaI Heavy
Nuevo HeaIth Care Systems Network
Device Number Device Type
1 ÌP Phone
2 LAN Switch
3 Customer Edge Router
4 Service Provider Router
Nuevo HeaIth Care Systems Network
n Device no. on ProbIem Spreadsheet
Identify QoS Service CIass Requirements
Given the NHCS network as described, how would you recommend classiIying network
traIIic?
Traffic CIassification and Prioritization
Type of Traffic (AppIication) Traffic Priority
(Rank from 1 to 5)
Identify Network Locations Where QoS
Mechanisms ShouId Be AppIied
Given NHCS network as described, how would you recommend deploying QoS mechanisms?
Check each box (X) where you believe that QoS mechanisms could be applied to eIIectively
resolve QoS problems at NHCS.
Where to AppIy QoS Mechanisms: CIassification and Marking
Device
#
Network Device Interface CIassification
On Input
CIassification
On Output
Marking
On Input
Marking
On Output
1 IP Phone-Interface to
Workstation

1 IP Phone-Interface to
Switch

2 Switch-Interface to IP
Phone

2 Switch-Interface to
Customer Edge Router

3 Customer Edge Router-
Interface to Switch

Interface to WAN (Service
Provider Router)

4 Service Provider Router-
Interface to Customer Edge
Router

Where to AppIy QoS Mechanisms: Congestion Management and Avoidance
Device
#
Network Device Interface Congestion
Management
On Input
Congestion
Management
On Output
Congestion
Avoidance
On Input
Congestion
Avoidance
On Output
2 Switch-Interface to IP
Phone

2 Switch-Interface to

Interface to Switch

Provider Router)

4 Service Provider
Router-Interface to

Where to AppIy QoS Mechanisms: Traffic PoIicing and Traffic Shaping
Device
#
Network Device Interface Traffic
PoIicing
On Input
Traffic
PoIicing
On Output
Traffic
Shaping
On Input
Traffic
Shaping
On Output
2 Switch-Interface to IP Phone
2 Switch-Interface to Customer
Edge Router

Interface to Switch

Provider Router)

Router

Where to AppIy QoS Mechanisms: Link Efficiency
Device
#
Network Device Interface Compression
On Input
Compression
On Output
LFI On
Input
LFI On
Output
2 Switch-Interface to IP Phone
2 Switch-Interface to Customer
Edge Router

Interface to Switch

Provider Router)

Router

Present Your SoIution
Together with your partner, present your solution to the class. Include the Iollowing
inIormation:
Customer service class requirements
Network diagrams indicating where classiIication and marking should be applied
JustiIication Ior diIIerences Irom the solution presented by the instructor
Case Study Answer Key
Traffic CIassification and Prioritization
Type of Traffic (AppIication) Traffic Priority
ÌP Telephony Highest - 1
Enterprise Resource Planning High - 2
Patient Ìnformation Files Moderate - 3
Patient Graphics Files Low - 4
Browser Traffic Low - 4
Where to AppIy QoS Mechanisms: CIassification and Marking
Device
#
Network Device Interface CIassification
On Input
CIassification
On Output
Marking
On Input
Marking
On
Output
1 IP Phone-Link to
Workstation
X X*
1 IP Phone-Link to Switch X
2 Switch-Link to IP Phone X No,
trusted*
2 Switch-Link to Customer
Edge Router
X
Link to Switch
X
Link to WAN (Service
Provider Router)
X
Link to Customer Edge
Router
X
Note: *The ÌP Phone will normally be set to remark any traffic coming from its downstream
workstation (the ÌP Phone connection to the workstation is ¨untrusted¨). The switch will not
remark traffic coming from the ÌP Phone (traffic from the ÌP Phone is ¨trusted¨). Further
explanation of ¨trusted¨ and ¨untrusted¨ interfaces is provided in the ¨Classification and
Marking¨ module of this course.
Where to AppIy QoS Mechanisms: Congestion Management and Avoidance
Device
#
Network Device Interface Congestion
Management
On Input
Congestion
Management
On Output
Congestion
Avoidance
On Input
Congestion
Avoidance
On Output
2 Switch-Link to IP Phone X
2 Switch-Link to
X Possible
Link to Switch
X
Link to WAN (Service
Provider Router)
X Possible
4 Service Provider
Router-Link to
X Possible
Where to AppIy QoS Mechanisms: Traffic PoIicing and Traffic Shaping
Device
#
Network Device Interface Traffic
PoIicing
On Input
Traffic
PoIicing
On Output
Traffic
Shaping
On Input
Traffic
Shaping
On Output
2 Switch-Link to IP Phone X
2 Switch-Link to Customer Edge
Router

3 Customer Edge Router-Link to
Switch
X
3 Customer Edge Router-Link to
WAN (Service Provider Router)
Possible
4 Service Provider Router-Link to
X Possible
Where to AppIy QoS Mechanisms: Link Efficiency
Device
#
Network Device Interface Compression
On Input
Compression
On Output
LFI On
Input
LFI On
Output
2 Switch-Link to IP Phone
2 Switch-Link to Customer
Edge Router

3 Customer Edge Router-Link
to Switch

3 Customer Edge Router-Link
to WAN (Service Provider
Router)
X X
4 Service Provider Router-Link
to Customer Edge Router
X X
Note: Because this is a Frame Relay network the service provider will pass frames through
transparently without compressing or fragmenting the frames.
Case Study: The Life of a
Packet
Overview
This case study activity provides inIormation regarding the application oI QoS mechanisms
throughout a simple network. The case study Iollows two packetsa high-priority voice packet
and a low-priority Iile transIer packet as they traverse a QoS-enabled network.
ReIevance
The ability to recognize the exact impact oI QoS mechanisms on packets as they traverse a
network is vitally important Ior correctly implementing QoS in a network.
Objectives
In this activity, you will learn how IP QoS mechanisms impact IP packets. Upon completing
this case study, you will be able to meet these objectives:
On a network diagram, identiIy key points where the QoS status oI a high-priority (VoIP)
packet can be altered as QoS policies are applied to the IP packet
On a network diagram, identiIy key points where the QoS status oI a low-priority (FTP)
packet can be altered as QoS policies are applied to the IP packet
OutIine
The outline lists the topics included in this case study.
Required Resources
No resources are required to complete this exercise.
Job Aids
Case Study Steps
No steps are required Ior this case study.
You have completed this activity when the instructor has completed the presentation on LiIe oI
a Packet.
OutIine
· Overview
· Life of a High-Priority (VoIP) Packet
· Life of a Low-Priority (FTP) Packet
Overview
The case study Iollows two packetsone at a timeas they traverse an IP QoS-enabled
network.
The Iirst packet, Packet 1, is a high-priority VoIP packet that will receive preIerential treatment
as it moves through the network.
The second packet, Packet 2, is a low-priority FTP packet that will receive deIerential treatment
as it moves through the network.
In this case study, a QoS peering relation between the enterprise and the service provider is
assumed. The service provider, in this case study, will recognize and act upon QoS
classiIications made by the enterprise customer. The relationship shows how QoS can be
eIIectively honored across an enterprise and service provider boundary.
Overview
Life of a High-Priority (VoIP) Packet
As it begins its liIe in the IP Phone, the VoIP packet is immediately marked with both:
Layer 2 802.1Q CoS ÷ 5 (highest priority on an Ethernet LAN)
Layer 3 DSCP ÷ EF (highest priority in an IP network)
Note: The 802.1Q standard is an ÌEEE specification for implementing virtual LANs (VLANs) in
Layer 2 switched networks. 802.1Q and its use in QoS will be discussed further in the
¨Classification and Marking¨ module in this course.
With the Irame marked at CoS ÷ 5 and DSCP ÷ EF, this Irame should receive priority treatment
every time it encounters any QoS mechanism in the network.
Note: A UDP header is used for voice packets rather than TCP.
Notice that an RTP header has been added because this is a voice packet. RTP helps
synchronize real-time transmissions such as voice by time-stamping packets so that they can be
resynchronized at the receiving end. This helps minimize jitter.
In the Cisco 2950 edge switch, the CoS ÷ 5 means to treat the Irame with PQ. This means that
you should move the Irame beIore any other Irames with lower CoS.
The deIault CoS-to-DSCP mapping is set to recognize the CoS ÷ 5 as DSCP ÷ 40. To a Cisco
2950 switch, the means EF. The EF value is 46 on input to the switch as set by the IP Phone.
Because the deIault CoS to DSCP marking is CoS 5 ÷ DSCP 40 in the Cisco 2950 switch (not
46), DSCP is set to 40 on output.
When the Irame arrives at the 2950 it is instantly recognized as a high-priority Irame because oI
the CoS ÷ 5 and is immediately enqueued in the high-priority, no-delay queue. Because the
switch recognizes the Irame as a CoS ÷ 5, it re-marks the DSCP Iield to 40.
DefauIt CoS-to-DSCP Mapping in Cisco 2950 Switch
COS VaIue DSCP VaIue
0 0
1 8
2 16
3 24
4 32
5 40
6 48
7 56
(Cont.)
When the packet hits the edge router, the router recognizes the packet as a voice packet due to
the DSCP ÷ 40 setting (as was set by the Cisco 2950 switch).
The packet is immediately dispatched ahead oI any non-voice packets using LLQ. LLQ is
designed to provide instant dispatch oI voice packets ahead oI data while careIully managing
the dispatch oI data.
II the link to the service provider is a relatively slow link, then both header compression (in this
case, class-based RTP header compression) and LFI would be employed to improve the
bandwidth eIIiciency oI the link.
II the WAN link were a Frame Relay link, the packet would use Frame Relay TraIIic Shaping
(FRTS) and FRF.12.
Note: Both of these technologies are explained further in the ¨Traffic Shaping and Policing¨ module
in this course.
(Cont.)
When the packet arrived at the service provider, the service provider would reclassiIy the
packet to Iit within the service provider QoS classiIication policy.
In this case, the service provider has deIined Iour traIIic classes:
Real-Time (EF)
Gold (CS 4)
Silver (CS3)
Best-EIIort
In this case study, the service provider is providing IP QoS service level agreement (SLA) Ior
the Real-Time, Gold, Silver, and Best-EIIort traIIic class. The service provider is mapping the
enterprise customer QoS classiIications into the service provider Iour deIined traIIic classes.
The service provider router recognizes that the packet as a high-priority voice packet and
assigns the packet to the Real-Time EF class. The packet is re-marked to DSCP ÷ 46 to Iit the
service provider classiIication conventions and sent on its way as a member oI the Real-Time
class.
Note: The FÌFO represents the queuing mechanism that is being used on the output interface of
the service provider router.
(Cont.)
In the service provider core network, the packet will move along with minimal delay using EF.
The key congestion avoidance technologyWREDis used in the service provider network.
WRED will ensure that lower-priority packets are dropped to ensure that priority packets make
their way quickly through the network.
Because the voice packet is marked as EFthe service provider Real-Time classWRED
should have no impact on the packet. QoS policy Ior the service provider should be not to drop
voice packets so that WRED would not be applied to packets identiIied as Real-Time.
The packet will almost certainly not be dropped and will encounter absolute minimal delay.
(Cont.)
While the packet traversed the service provider network, the DSCP was marked as 46 so that
the packet would be immediately dispatched as a member oI the service provider Real-time
class.
But the packet was marked DSCP ÷ 40 by the customer beIore it entered the service provider
network. At the edge oI the service provider network, the DSCP is re-marked to '40¨ to match
the classiIication scheme being used by the enterprise customer.
The packet is dispatched immediately using the LLQ method that always provides absolute
priority to voice packets.
(Cont.)
Upon arriving at the enterprise network router, the voice packet is sent out the LAN interIace
toward the switch using FIFO queuing on the LAN interIace.
(Cont.)
Upon arriving at the Cisco 2950 switch, the DSCP-to-CoS mappings are used to recognize the
Irame as a high-priority voice Irame and the Layer 2 priority is set to CoS ÷ 5. The Irame jumps
ahead oI any non-voice Irame and is immediately dispatched to the PQ.
(Cont.)
The packet Iinally arrives at the receiving IP Phone.
The RTP header is used to ensure that the packet is synchronized correctly with other packets
Irom the same voice Ilow and the voice payload is delivered.
(Cont.)
Life of a Low-Priority (FTP) Packet
The low-priority FTP packet begins liIe as a very low-priority DSCP ÷ 0.
Should the user application in the host attempt to mark the packet as a high-priorityDSCP ÷
46 (EF)packet, the IP Phone would recognize that the packet was not voice and overwrite the
packet DSCP priority with a lower priority.
Note: The FTP packet is using TCP rather than UDP (which was used by the voice packet).
All traIIic arriving Irom the workstation attached to the IP Phone is set to be 'untrusted.¨
As a result, the IP Phone will not accept any marking done by the workstation and will re-mark
all DSCP values Irom the workstation to DSCP ÷ 0 and set the CoS ÷ 0. This ensures that the
voice traIIic generated by the IP phone will always receive priority treatment over any traIIic
generated by the workstation.
(Cont.)
In the Cisco 2950 switch, the CoS-to-DSCP mapping would be used to map the CoS value oI
the packet to the switches DSCP equivalent. In the case oI the FTP Irame, the DSCP ÷ 0
matches the CoS ÷ 0, so the Irame DSCP value would not change.
The switch congestion management technologyWRRwould dispatch the Irame, but not
until all high-priority voice Irames had been dispatched. (WRR is explained Iurther in the
'Congestion Management¨ module in this course.)
DefauIt CoS-to-DSCP Mapping in Cisco 2950 Switch
COS VaIue DSCP VaIue
0 0
1 8
2 16
3 24
4 32
5 40
6 48
7 56
(Cont.)
In the enterprise router, a classiIication technology, NBAR, would recognize the packet as an
FTP packet and assign the packet a DSCP ÷ '001010¨ ÷ AF11.
With a DSCP ÷ AF11, the packet would then be dispatched as a low-priority class packet by
CBWFQ. CBWFQ is the component oI LLQ that careIully manages the dispatch oI data traIIic.
The AF11 class is given a minimum guarantee oI bandwidth. II the link to the service provider
were congested, the packet would have a good probability oI being dropped to ensure that
higher-priority packets are not delayed.
(Cont.)
In this case study, the service provider is providing IP QoS SLA Ior the Real-Time, Gold,
Silver, and Best-EIIort traIIic classes. The service provider is mapping the enterprise customer
QoS classiIications into the service provider Iour deIined traIIic classes.
Upon arriving at the service provider network, the packet would be identiIied as an FTP packet
and assigned to the Silver class (CS3).
(Cont.)
The packet traverses the service provider core marked as a Silver class (CS3) packet.
While in the service provider core network, the FTP packet would have a much better
probability oI being dropped by WRED than the voice packet.
(Cont.)
BeIore the packet entered the service provider network, it was marked DSCP ÷ AF11, which Iit
the classiIication scheme used by the enterprise customer. As the packet leaves the service
provider network, the packet is re-marked to DSCP ÷ AF11 Ior the enterprise customer.
The AF11 class is given a minimum guarantee oI bandwidth.
(Cont.)
As the packet reenters the enterprise network, it is recognized as an AF11 class packet and is
passed through the enterprise router without being re-marked.
The FTP packet is sent out the LAN interIace toward the switch using FIFO queuing on the
LAN interIace.
(Cont.)
Using its DSCP-to-CoS mapping, the Cisco 2950 switch recognizes the DSCP ÷ AF11 packet
(Layer 3) as a CoS ÷ 3 priority Irame (Layer 2).
The FTP Irame is treated by WRR with the CoS 3 (which can be conIigured to have less weight
than CoS 4 or 5 Irames, but more weight than CoS 1 or 2 Irames).
(Cont.)
The FTP packet Iinally arrives at the destination host and the payload is delivered.
II the packet had been dropped at any point along the way, TCP would recognize that Iact, and
request retransmission oI the packet.
(Cont.)
Summary
Next Steps
For the associated lab exercise, reIer to the Iollowing section oI the course Lab Guide:
Lab Exercise 2-1: QoS Lab Setup and Initialization
Lab Exercise 2-2: Baseline QoS Measurement
Summary
· High-priority and Iow-priority packets are treated very
differentIy in a network using Differentiated Services.
· The high-priority (VoIP) packet begins Iife at an IP Phone as a
CoS 5 on the LAN, which transIates to DSCP 40 as the packet
hits the WAN and is given EF status in the service provider core
network.
· With a CoS 5 and a DSCP 40, the high-priority packet is
immediateIy transmitted by aII devices as it moves through the
network.
· The Iow-priority (FTP) packet, begins Iife as a CoS 0 packet
which transIates to DSCP 0 and Assured Forwarding 11 in the
service provider core network.
· In a busy network, the Iow-priority packet wiII wait at every
device and has a high probabiIity of being dropped at any of
severaI points.
Module Assessment
Overview
Quiz: The BuiIding BIocks of IP QoS
Objectives
Correctly match a list oI QoS actions to one or more oI the three models Ior implementing
QoS on a network
Describe the DiIIerentiated Services model and explain how it can be used to implement
QoS in that network
Correctly match a list oI QoS actions to mechanisms Ior implementing QoS and identiIy
where in a network the diIIerent QoS mechanisms are commonly used
Correctly identiIy the QoS status oI packets as they pass through various points in the
network
Instructions
incorrectly.
Q1) Which oI the models Ior implementing QoS is least scalable?
A) Best-EIIort
Q2) Which three IP QoS mechanisms work together to provide a set oI complete integrated
services on a network? (Choose three.)
A) Weighted RED (WRED)
B) Weighted Fair Queuing (WFQ)
C) Generic TraIIic Shaping (GTS)
D) Resource Reservation Protocol (RSVP)
Q3) What is the most important advantage oI DiIIerentiated Services over other QoS
models?
A) high scalability
B) many service levels
C) guaranteed service
D) deterministic delays
E) advanced queuing mechanisms
Q4) Services are provided to which entities in the DiIIerentiated Services model?
A) Irames
B) packets
C) applications
D) classes oI traIIic
Q5) How many bits is the DSCP Iield oI the IP header?
A) 3
B) 4
C) 6
D) 8
Q6) What PHB would be indicated iI the DSCP was equal to 46 (101110)?
A) deIault PHB
B) selector PHB
C) Assured Forwarding PHB
D) Expedited Forwarding PHB
Q7) Which Assured Forwarding Class and what drop probability would be indicated iI the
DSCP was equal to '100100?¨
A) AF Class 1 and medium
B) AF Class 4 and medium
C) AF Class 1 and high
D) AF Class 4 and high
Q8) II DSCP Ior packets A, B, C, and D was respectively set to '101000¨, '011000¨,
'111000¨, and '001000¨, which packet would have the greatest probability oI timely
Iorwarding?
A) A
B) B
C) C
D) D
Q9) Match the Iollowing IP QoS mechanisms to their Iunction.
A) congestion avoidance
B) congestion management
C) classiIication
D) traIIic policing
E) traIIic shaping
F) packet header compression
¸¸¸¸¸ 1. Drops misbehaving traIIic to maintain network integrity.
¸¸¸¸¸ 2. Improves the bandwidth eIIiciency oI a link.
¸¸¸¸¸ 3. Controls traIIic by delaying bursts.
¸¸¸¸¸ 4. Discards speciIic packets based on markings.
¸¸¸¸¸ 5. IdentiIying and splitting oI traIIic.
¸¸¸¸¸ 6. Prioritizing, protection, and isolation oI traIIic based on markings.
Q10) Which oI the Iollowing IP QoS mechanisms is used on both input and output
interIaces?
A) classiIication
B) traIIic policing
C) traIIic shaping
D) congestion management
Scoring
or better.
Q1) B
ReIates to: Models for Ìmplementing QoS
Q2) A, B, D
ReIates to: Models for Ìmplementing QoS
Q3) A
ReIates to: The Differentiated Services Model
Q4) D
Q5) C
Q6) D
Q7) B
Q8) C
Q9) 1 ÷ D
2 ÷ F
3 ÷ E
4 ÷ A
5 ÷ C
6 ÷ B
ReIates to: ÌP QoS Mechanisms
Q10) B
ReIates to: ÌP QoS Mechanisms
ModuIe Summary
Three diIIerent models exist Ior implementing QoS on a network. The Best-EIIort model was
designed Ior best-eIIort, no-guarantee delivery oI packets. This model is still predominant on
the Internet today. The Integrated Services model was introduced to supplement the best-eIIort
delivery by setting aside some bandwidth Ior applications that require bandwidth and delay
guarantees. The Integrated Services model expects applications to signal their requirements to
the network. The DiIIerentiated Services model was added to provide greater scalability in
providing QoS to IP packets. The main diIIerence between the Integrated Services and
DiIIerentiated Services models is that with the DiIIerentiated Services model, the network
recognizes packets (no signaling is needed) and provides the appropriate services to them. IP
networks oI today can use all three models at the same time.
DiIIerentiated Services is a multiple-service model that is designed to satisIy various QoS
requirements. With DiIIerentiated Services, the network tries to deliver a particular kind oI
service based on the QoS speciIied by each packet. This speciIication can occur in diIIerent
ways, Ior example, using the DiIIerentiated Services Code Point in IP packets or source and
destination addresses. The network uses the QoS speciIication oI each packet to classiIy, shape,
and police traIIic and to perIorm intelligent queuing.
IP networks use a variety oI mechanisms to implement QoS including: classiIication, marking,
congestion management, congestion avoidance, metering, traIIic policing, traIIic shaping, and
link eIIiciency. IP QoS mechanisms are used to implement a coordinated QoS policy in devices
throughout the network. The moment an IP packet enters the network, it is classiIied and
usually marked with its class identiIication. From that point on, the packet is treated by a
variety oI IP QoS mechanisms according to the packet classiIication. Depending upon the
mechanisms it encounters, the packet could be expedited, delayed, compressed, Iragmented, or
even dropped.
ModuIe Summary
· The three modeIs used for impIementing QoS in IP
networks are: Best-Effort, Integrated Services, and
Differentiated Services.
· The Differentiated Services modeI is the primary one
used to impIement QoS in IP networks because it is
highIy scaIabIe and offers the capabiIity to define many
different IeveIs of service.
· The Differentiated Services modeI uses a 6-bit DSCP to
mark packets so that they wiII be treated with different
IeveIs of service as they traverse an IP network.
· IP networks use a variety of mechanisms to impIement
QoS incIuding: cIassification, marking, congestion
management, congestion avoidance, metering, traffic
poIicing, traffic shaping, and Iink efficiency.
ModuIe 3
Ìntroduction to Modular QoS
CLÌ and AutoQoS
Overview
Quality oI Service (QoS) conIigurations can be complex. In Cisco IOS soItware conIigurations,
there are many diIIerent QoS mechanisms, many oI which have similar Ieatures. Because there
are also many options available Ior providing QoS to diIIerent traIIic types, it can easily
become an overwhelming eIIort to deploy QoS end-to-end in a network inIrastructure.
Fortunately, Cisco Systems has uniIied QoS conIiguration by separating the diIIerent
components oI a QoS policy into diIIerent conIiguration modules. It is these modules that
comprise the Cisco Modular QoS command-line interIace (CLI |MQC|) that allow network
administrators and network implementers to more easily deploy QoS. MQC conIigurations are
consistent Ior diIIerent QoS mechanisms and are thereIore easier to learn, deploy and
troubleshoot.
There are cases, however, when some customers do not want to be concerned with the speciIics
oI QoS conIiguration. These customers would preIer to enable QoS in a global Iashion with a
single command and allow the Cisco IOS router and switch to automate the required complex
QoS conIiguration. For those customers, Cisco has developed AutoQoS. This module
introduces MQC and AutoQoS as conIiguration methods Ior implementing QoS. This module
will also serve as the Ioundation Ior more advanced MQC conIigurations that include additional
QoS Ieatures and techniques.
ModuIe Objectives
Upon completing this module, you will be able to explain the use oI MQC and AutoQoS, and to
implement QoS on the network.
ModuIe OutIine
ModuIe Objectives
· ExpIain how to impIement a QoS poIicy using
MQC
· CorrectIy identify capabiIities provided by
AutoQoS and successfuIIy configure QoS on a
network using AutoQoS
ModuIe OutIine
· Introducing to ModuIar QoS CLI
· Introducing to AutoQoS
Ìntroducing Modular QoS CLÌ
Overview
This chapter explains how to implement QoS policies using the MQC.
ReIevance
MQC is one oI the two key methods recommended Ior implementing QoS on a network. MQC
may be the best choice Ior implementing a large, Iinely tuned network incorporating voice and
video applications.
Objectives
Upon completing this lesson, you will be able to explain how to implement a QoS policy using
MQC. This includes being able to meet these objectives:
Explain how to implement a given 'QoS policy¨ using MQC
DiIIerentiate between class maps, policy maps, and service policies
Describe how a class map is used to deIine a class oI traIIic
Describe the Cisco IOS MQC commands required to conIigure and monitor a class map
Describe how a policy map is used to assign a QoS policy to a class oI traIIic
Describe the Cisco IOS MQC commands required to conIigure and monitor a policy map
Explain how a service policy is assigned to an interIace
Describe the MQC commands used to attach a service policy to an interIace
Basic understanding oI the Cisco IOS command-line interIace
OutIine
OutIine
· Overview
· ModuIar QoS CLI
· ModuIar QoS CLI Components
· CIass Maps
· Configuring and Monitoring CIass Maps
· PoIicy Maps
· Configuring and Monitoring PoIicy Maps
· Service PoIicy
· Attaching Service PoIicies to Interfaces
· Summary
· Quiz
Copyright © 2003, Cisco Systems, Ìnc. Ìntroduction to Modular QoS CLÌ and AutoQoS 3-5
ModuIar QoS CLI
This topic describes the MQC method Ior implementing QoS on a network.
The MQC was introduced to allow any supported classiIication to be used with any QoS
mechanism.
The separation oI classiIication Irom the QoS mechanism allows new Cisco IOS versions to
introduce new QoS mechanisms and reuse all available classiIication options. On the other
hand, old QoS mechanisms can beneIit Irom new classiIication options.
Another important beneIit oI the MQC is the reusability oI conIiguration. MQC allows the
same QoS policy to be applied to multiple interIaces. The MQC, thereIore, is a consolidation oI
all the QoS mechanisms that have so Iar only been available as standalone mechanisms.
ExampIe: Advantages of Using MQC
ConIiguring committed access rate (CAR), Ior example, required entire conIigurations to be
repeated between interIaces and time-consuming conIiguration modiIications. MQC allows the
same QoS policy to be applied to multiple interIaces.
ModuIar QoS CLI
· The ModuIar QoS CLI
(MQC) provides a
moduIar approach to
configuration of QoS
mechanisms.
· FinaIIy, assign the
poIicy moduIes to
interfaces.
· First, buiId moduIes
defining cIasses of
traffic.
· Then, buiId moduIes
defining QoS poIicies
and assign cIasses to
poIicies.
ModuIar QoS CLI Components
This topic describes the three steps involved in implementing a QoS policy using MQC.
Implementing QoS by using the MQC consists oI three steps:
First, conIigure classiIication by using the class-map command.
Second, conIigure traIIic policy by associating the traIIic class with one or more QOS
Ieatures using the policy-map command.
Finally, attach the traIIic policy to inbound or outbound traIIic on interIaces, subinterIaces,
or virtual circuits by using the service-policy command.
ExampIe: Configuring MQC
Consider a network with voice telephony:
First, classiIy traIIic as Voice, High Priority, Low Priority, and Browser in class-maps.
Second, build a single policy-map that deIines three diIIerent traIIic policies (diIIerent
bandwidth and delay requirements Ior each traIIic class): NoDelay, BestService, and
Whenever, and assign the already deIined classes oI traIIic to the policies. Voice is assigned
to NoDelay. High Priority traIIic is assigned to BestService. Both Low Priority, and
Browser traIIic are assigned to Whenever.
Finally, assign the policy-map to selected router and switch interIaces.
ModuIar QoS CLI Components
AppIy a Service
PoIicy
"Where wiII this
poIicy be
impIemented?"
Attaches a
Service PoIicy
configured with a
poIicy map to an
interface.
Define QoS PoIicies
for CIasses
"What wiII be done to
this traffic?"
Defines a PoIicy Map
which configures the
QoS features
associated with a
traffic cIass
previousIy identified
using a cIass map.
Define CIasses
of Traffic
"What traffic do we
care about?"
Each cIass of traffic
is defined using a
CIass Map.
CIass Maps
This topic describes the use oI Class Maps.
Class maps are used to create classiIication templates that are later used in policy maps where
QoS mechanisms are bound to classes.
Routers can be conIigured with a large number oI class maps (currently limited to 256). Each
traIIic policy, however, may support a limited number oI classes; Ior example, class-based
weighted Iair queuing (CBWFQ) and class-based low-latency queuing (LLQ) are limited to 64
classes.
A class map is created using the class-map global conIiguration command. Class maps are
identiIied by case-sensitive names. Each class map contains one or more conditions that
determine iI the packet belongs to the class.
There are two ways oI processing conditions when there is more than one condition in a class
map:
Match all: All conditions have to be met to bind a packet to the class.
Match any: At least one condition has to be met to bind the packet to the class.
The deIault match strategy oI class maps is 'match all.¨
CIass Maps
· 'What traffic do we care about?"
· Each cIass is identified using a cIass map.
· A traffic cIass contains three major eIements:
÷ A case-sensitive name
÷ A series of match commands
÷ If more than one match command exists in the traffic cIass, an
instruction on how to evaIuate these match commands
· CIass maps can operate in two modes:
÷ Match aII: aII conditions have to succeed
÷ Match any: at Ieast one condition must succeed
· The defauIt mode is match aII.
· MuItipIe traffic cIasses can be configured as a singIe
traffic cIass (nested).
The Iigure illustrates the Iull process oI determining iI a packet belongs to a class (match) or
not (no match).
The process goes through the list oI conditions and:
Returns a 'match¨ result iI one oI the conditions is met and the match-any strategy is used
Returns a 'match¨ result iI all conditions are met and the match-all strategy is used
II either oI these conditions is not met it returns 'no match.¨
CIassification Using CIass Maps
· Match aII requires aII conditions to return a positive answer. If
one condition is not met the cIass map wiII return a "no match"
resuIt.
· Match any requires at Ieast one condition to return a positive
answer. If no condition is met the cIass map wiII return a "no
match" resuIt.
Configuring and Monitoring CIass Maps
This topic explains the commands that are necessary to conIigure and monitor class maps.
Use the class-map global conIiguration command to create a class map and enter the class map
conIiguration mode. A class map is identiIied by a case-sensitive name; thereIore, all
subsequent reIerences to the class map must use exactly the same name.
At least one match command should be used within the class map conIiguration mode (match
none is the deIault).
The description command is used Ior documenting a comment about the class map.
ExampIe: CIass Map Configuration
The Iollowing example shows a traIIic class conIigured with the class-map match-all
command:
Router(config)= class-map match-all ciscoI
Router(config-cmap)= match protocol ip
Router(config-cmap)= match qos-group 4
Router(config-cmap)= match access-group I0I
II a packet arrives on a router with traIIic class called cisco1 conIigured on the interIace, the
packet is evaluated to determine iI it matches the IP protocol, QoS group 4, ana access group
101. II all three oI these match criteria are met, the packet matches traIIic class cisco1.
Configuring CIass Maps
class~map (match~all | match~any) class~map~name class~map (match~all | match~any) class~map~name
router(config)#
· Enter the cIass-map configuration mode.
· Specify the matching strategy.
· Match-aII is the defauIt matching strategy.
match condition match condition
router(config~cmap)#
· Use at Ieast one condition to match packets.
description description description description
· It is recommended to use descriptions in Iarge and compIex
configuration.
· The description has no operationaI meaning.
The match commands are used to speciIy various criteria Ior classiIying packets. Packets are
checked to determine whether they match the criteria speciIied in the match commands. II a
packet matches the speciIied criteria, that packet is considered a member oI the class and is
Iorwarded according to the QoS speciIications set in the traIIic policy. Packets that Iail to meet
any oI the matching criteria are classiIied as members oI the deIault traIIic class. The MQC
does not necessarily require that users associate a single traIIic class to one traIIic policy.
Multiple traIIic classes can be associated with a single traIIic policy using the match any
command.
The match not command inverts the condition speciIied. It speciIies a match criterion value
that prevents packets Irom being classiIied as members oI a speciIied traIIic class. All other
values oI that particular match criterion belong to the class.
The MQC allows multiple traIIic classes (nested traIIic classes, which are also called nested
class maps) to be conIigured as a single traIIic class. This nesting can be achieved with the use
oI the match class-map command. The only method oI combining match-any and match-all
characteristics within a single traIIic class is with the match class-map command.
Configuring CIassification Using
SpeciaI Options
match not condition match not condition
· The "not" keyword inverts the condition.
match class~map class~map~name match class~map class~map~name
· One cIass map can use another cIass map for cIassification.
· Nested cIass maps aIIow generic tempIate cIass maps to be
used in other cIass maps.
match any match any
· The "any" keyword can be used to match aII packets.
ExampIe: Using the match Command
The Iollowing example shows a traIIic class conIigured with the class-map match-any
command:
Router(config)= class-map match-any cisco?
In traIIic class called cisco2, the match criteria are evaluated consecutively until a successIul
match criterion is located. The packet is Iirst evaluated to determine whether IP protocol can be
used as a match criterion. II IP protocol is not a successIul match criterion, then QoS group 4 is
evaluated as a match criterion. Each matching criterion is evaluated to see iI the packet matches
that criterion. When a successIul match occurs, the packet is classiIied as a member oI traIIic
class cisco2. II the packet matches none oI the speciIied criteria, the packet is classiIied as a
member oI the traIIic class.
ExampIe: Nested Traffic CIass to Combine match-any and
match-aII Characteristics in One Traffic CIass
The only method oI including both match-any and match-all characteristics in a single traIIic
class is to use the match class-map command. To combine match-any and match-all
characteristics into a single class, a traIIic class created with the match-any instruction must
use a class conIigured with the match-all instruction as a match criterion (through the match
class-map command), or vice versa.
The Iollowing example shows how to combine the characteristics oI two traIIic classes, one
with match-any and one with match-all characteristics, into one traIIic class with the match
class-map command. The result oI traIIic class class4 requires a packet to match one oI the
Iollowing three match criteria to be considered a member oI traIIic class class4: IP protocol and
QoS group 4, destination MAC address 1.1.1, or access group 2.
In this example, only the traIIic class called class4 is used with the traIIic policy called policy1:
Router(config)= class-map match-all class·
Router(config-cmap)= exit
Router(config)= class-map match-any class4
Router(config-cmap)= match class-map class·
Router(config-cmap)= match destination-address mac I.I.I
Router(config-cmap)= match access-group ?
Router(config)= policy-map policyI
Router(config-pmap)= class class4
Router(config-pmap-c)= police 8I00 IS00 ?S04 conform-action
transmit exceed-action set-qos-transmit 4
Router(config-pmap-c)= exit
The show class-map command lists all class maps with their match statements.
The show class-map command with a name oI a class map displays the conIiguration oI the
selected class map.
The example oI show class-map in the illustration shows three class maps:
The Iirst, class-3, will match any packet to access-group 103.
The second, class-2, matches IP packets.
The third matches any input Irom interIace Ethernet 1/0.
Monitoring CIass Maps
show class~map (class~name) show class~map (class~name)
router>
router>show class~map
Class Map class~3
Match access~group 103
Class Map class~2
Match protocol ip
Class Map class~1
Match input~interface Fthernet1/0
· DispIays aII cIass maps and their matching criteria
PoIicy Maps
This topic describes how to implement QoS policies using policy maps.
The policy-map command is used to create a traIIic policy. The purpose oI a traIIic policy is to
conIigure the QoS Ieatures that should be associated with the traIIic that has been classiIied in a
user-speciIied traIIic class or classes. A traIIic policy contains three elements: a case-sensitive
name, a traIIic class (speciIied with the class command), and the QoS policies.
The name oI a traIIic policy is speciIied in the policy-map CLI (Ior example, issuing the
policy-map class1 command would create a traIIic policy named class1). AIter the policy map
command is issued, the user is placed into policy map conIiguration mode. The name oI a
traIIic class can then be entered, and the user enters policy map class conIiguration mode. Here
is where the user enters QoS Ieatures to apply to the traIIic that matches this class.
The MQC does not necessarily require that users associate only one traIIic class to a single
traIIic policy. When packets match to more than one match criterion, multiple traIIic classes
can be associated with a single traIIic policy.
Note: A packet can match only one traffic class within a traffic policy. Ìf a packet matches more
than one traffic class in the traffic policy, the first traffic class defined in the policy will be
used.
PoIicy Maps
· 'What will be done to this traffic?"
· Defines a traffic poIicy, which configures the QoS
features associated with a traffic cIass previousIy
identified using a cIass map.
· A traffic poIicy contains three major eIements:
÷ A case-sensitive name
÷ A traffic cIass
÷ The QoS poIicy associated with that traffic cIass
· Up to 256 traffic cIasses can be associated with a singIe
traffic poIicy.
· MuItipIe poIicy maps can be nested to infIuence the
sequence of QoS actions.
Configuring and Monitoring PoIicy Maps
This topic describes the commands that are necessary to conIigure and monitor policy maps.
Service policies are conIigured using the policy-map command. Up to 256 classes can be used
within one policy map using the class command with the name oI a preconIigured class map.
A nonexistent class can also be used within the policy map conIiguration mode iI the match
condition is speciIied aIter the name oI the class. The running conIiguration will reIlect such a
conIiguration by using the match-any strategy and inserting a Iull class map conIiguration.
The Iollowing table shows starting and resulting conIiguration modes Ior the class-map,
policy-map, and class commands:
Configuration Modes
Starting configuration mode Command Configuration mode
Router(config)# class-map Router(config-cmap)#
Router(config)# policy-map Router(config-pmap)#
Router(config-pmap)# class Router(config-pmap-c)#
All traIIic that is not classiIied by any oI the class maps that are used within the policy map is
part oI the deIault class class-default. This class has no QoS guarantees by deIault. The deIault
class, when used on output, can use one FIFO queue or Ilow-based weighted Iair queuing
(WFQ). The deIault class is part oI every policy map even iI not conIigured.
Configuring PoIicy Maps
policy~map policy~map~name policy~map policy~map~name
router(config)#
· Enter poIicy-map configuration mode.
· PoIicy maps are identified by a case-sensitive name.
class ¦class~name | class~default} class ¦class~name | class~default}
router(config~pmap)#
· Enter the per-cIass poIicy configuration mode by using the name of a
previousIy configured cIass map.
· Use the name "cIass-defauIt" to configure the poIicy for the defauIt
cIass.
class class~map~name condition class class~map~name condition
· OptionaIIy you can define a new cIass map by entering the condition
after the name of the new cIass map.
· CIass map wiII use the match-any strategy.
Policy maps, like class maps, should use descriptions in large QoS implementations where a
large number oI diIIerent policy maps are used.
Renaming a policy map would normally require the renaming oI all the reIerences to the policy
map. Using the rename command simpliIies the renaming process by automatically renaming
all reIerences.
ExampIe: PoIicy Map ExampIe
The example shows the conIiguration oI a policy map using three classes. The Iirst two classes
were separately conIigured using the class-map command. The third class was conIigured by
speciIying the match condition aIter the name oI the class:
class-map match-all TestI
match protocol http
match access-group I00
class-map match-any Test?
match protocol http
match access-group I0I
!
policy-map Test
class TestI
bandwidth I00
class Test?
bandwidth ?00
class Test· access-group I00
bandwidth ·00
!
access-list I00 permit tcp any host I0.I.I.I
access-list I0I permit tcp any host I0.I.I.?
Class Test1 has two match conditions evaluated in the match-all strategy. Classes Test2 and
Test3 use the match-any strategy.
Configuring PoIicy Maps (Cont.)
description description description description
· It is recommended to use descriptions in Iarge and compIex
configurations
· The description has no operationaI meaning
<PHB mechanism> <PHB mechanism>
router(config~pmap~c)#
· Per-cIass service poIicies are configured within the per-cIass poIicy
map configuration mode
· MQC supports the foIIowing QoS mechanisms:
÷ CIass-based weighted fair queuing (CBWFQ)
÷ Low-Iatency queuing
÷ CIass-based poIicing
÷ CIass-based shaping
÷ CIass-based marking
The service-policy policy-map-name command is used to create hierarchical service policies in
policy map class conIiguration mode.
The service-policy |input , output| policy-map-name command is a diIIerent command that is
used in interIace conIiguration mode. The purpose oI the service-policy |input , output|
policy-map-name is to attach service policies to interIaces.
The child policy is the previously deIined service policy that is now associated with the new
service policy through the use oI the service-policy command. The new service policy that uses
the preexisting service policy is called the parent policy. In the hierarchical policy maps
example below, the service policy named, 'chila¨ is the child policy and service policy named,
'parent¨ is the parent policy.
The service-policy policy-map-name command has the Iollowing restrictions:
The set command is not supported on the child policy.
The priority command can be used in either the parent or the child policy, but not both
policies simultaneously.
The fair-queue command cannot be deIined in the parent policy.
HierarchicaI (Nested) PoIicy Maps
service~policy policy~map~name
· PoIicy maps are normaIIy appIied to interfaces.
· Nested poIicy maps can be appIied directIy inside
other poIicy maps to infIuence sequence of QoS
actions.
· For exampIe: shape aII traffic to 2 Mbps; queue
shaped traffic to provide priority and bandwidth
guarantees.
ExampIe: HierarchicaI PoIicy Maps
In the example diagram, a child policy-map QueueAll is created, which guarantees bandwidth
oI 1 Mbps to HTTP traIIic.
The QueueAll policy map is then nested within a parent policy map named ShapeAll.
Finally, the parent policy map ShapeAll is applied to the FastEthernet interIace.
TraIIic out oI the FastEthernet interIace will Iirst be shaped to 2 Mbps and then HTTP traIIic
will be guaranteed 1 Mbps oI the 2 Mbps oI shaped traIIic.
Note: Additional information on traffic shaping is covered in the ¨Traffic Policing and Shaping¨
module in this course.
ExampIe: HierarchicaI PoIicy Map Configuration
Follow these steps to apply a hierarchical policy:
Step 1 Create a child or lower-level policy that conIigures a queuing mechanism. In the
example below, LLQ is conIigured using the priority command.
policy-map child
class voice
priority SI?
HierarchicaI (Nested) PoIicy Maps
ExampIe
ExampIe poIicy:
· Shape aII traffic on FastEthernet to 2 Mbps
· Out of the 2 Mbps, guarantee 1 Mbps to HTTP traffic
class~map AllTraffic
match any
!
policy~map ShapeAll
class AllTraffic
shape 2000000
service~policy QueueAll
!
interface FastFthernet0/0
service~policy output ShapeAll
class~map AllTraffic
match any
!
policy~map ShapeAll
class AllTraffic
shape 2000000
service~policy QueueAll
!
service~policy output ShapeAll
class~map HTTP
match protocol http
!
policy~map QueueAll
class HTTP
bandwidth 1000
class~map HTTP
match protocol http
!
policy~map QueueAll
class HTTP
bandwidth 1000
Step 2 Create a parent or top-level policy that applies class-based shaping. Apply the child
policy as a command under the parent policy because the admission control Ior the
child class is based on the shaping rate Ior the parent class.
policy-map parent
class class-default
shape average ?000000
service-policy child
Step 3 Apply the parent policy to the subinterIace.
interface ethernet0/0.I
service-policy output parent
The show policy-map command can be used to veriIy the conIiguration oI a policy map.
Monitoring PoIicy Maps
show policy~map (policy~map) show policy~map (policy~map)
router>
router>show policy~map
Policy Map Test
Class Test1
Weighted Fair Queueing
Bandwidth 100 (kbps) Max Threshold 64 (packets)
Class Test2
Class Test3
· DispIays the configuration of aII cIasses for a specified service
poIicy map or aII cIasses for aII existing poIicy maps.
The show policy-map command also displays live inIormation iI the interface keyword is
used. The sample output shows the parameters and statistics oI the policy map that is attached
to outbound traIIic on interIace FastEthernet0/0.
Monitoring PoIicy Maps (Cont.)
show policy~map interface interface~name (input | output) show policy~map interface interface~name (input | output)
router>
router>show policy~map interface FastFthernet0/0 output
FastFthernet0/0
Service~policy output: Test (1101)
Class~map: Test1 (match~any) (1103/3)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access~group 101 (1107)
Match: access~group 102 (1111)
Match: protocol http (1115)
output Queue: Conversation 265
(pkts matched/bytes matched) 0/0
(depth/total drops/no~buffer drops) 0/0/0
...
Class~map: class~default (match~any) (1143/0)
25 packets, 19310 bytes
Match: any (1147)
Service PoIicy
This topic describes how to attach a QoS policy to an interIace using service policies.
The last conIiguration step when conIiguring QoS mechanisms using the MQC is to attach a
policy map to the inbound or outbound packets using the service-policy command.
Using the service-policy command it is possible to assign a single policy map to multiple
interIaces or to assign multiple policy maps to a single interIace (a maximum oI one in each
direction, inbound and outbound).
A service policy can be applied Ior inbound or outbound packets.
Service PoIicy
· 'Where will this policy be implemented?"
· Attaches a traffic poIicy configured with a poIicy
map to an interface.
· Service poIicies can be appIied to an interface
for inbound or outbound packets.
Attaching Service PoIicies to Interfaces
This topic explains how to attach service policies to interIaces.
Use the service-policy interIace conIiguration command to attach a traIIic policy to an
interIace and to speciIy the direction in which the policy should be applied (either on packets
coming into the interIace or packets leaving the interIace).
The router immediately veriIies the correctness oI parameters that are used in the policy map. II
there is a mistake in the policy map conIiguration, the router will display a message explaining
what is wrong with the policy map.
The sample conIiguration shows how a policy map is used to separate HTTP Irom other traIIic.
HTTP is guaranteed 2 Mbps. All other traIIic belongs to the deIault class and is guaranteed 6
Mbps.
ExampIe: CompIete MQC Configuration
Traffic CIasses Defined
In the Iollowing example, two traIIic classes are created and their match criteria are deIined.
For the Iirst traIIic class called class1, access control list (ACL) 101 is used as the match
criterion. For the second traIIic class called class2, ACL 102 is used as the match criterion.
Packets are checked against the contents oI these ACLs to determine iI they belong to the class:
Router(config)= class-map classI
Router(config)= class-map class?
Router(config-cmap)= match access-group I0?
Attaching Service PoIicies to Interfaces
class~map HTTP
match protocol http
!
policy~map PM
class HTTP
bandwidth 2000
class class~default
bandwidth 6000
!
class~map HTTP
match protocol http
!
policy~map PM
class HTTP
bandwidth 2000
class class~default
bandwidth 6000
!
service~policy ¦input | output} policy~map~name service~policy ¦input | output} policy~map~name
router(config~if)#
· Attaches the specified service poIicy map to the input or
output interface
interface Serial0/0
service~policy output PM
!
Traffic PoIicy Created
In the Iollowing example, a traIIic policy called policy1 is deIined to contain policy
speciIications Ior the two classesclass1 and class2. The match criteria Ior these classes were
deIined in the traIIic classes.
For class1, the policy includes a bandwidth allocation request and a maximum packet count
limit Ior the queue reserved Ior the class. For class2, the policy speciIies only a bandwidth
allocation request:
Router(config)= policy-map policyI
Router(config-pmap)= class classI
Router(config-pmap-c)= bandwidth ·000
Router(config-pmap-c)= queue-limit ·0
Router(config-pmap)= class class?
Router(config-pmap-c)= bandwidth ?000
Traffic PoIicy Attached to an Interface
The Iollowing example shows how to attach an existing traIIic policy (which was created in the
preceding section) to an interIace. AIter you deIine a traIIic policy with the policy-map
command, you can attach it to one or more interIaces to speciIy the traIIic policy Ior those
interIaces by using the service-policy command in interIace conIiguration mode. Although you
can assign the same traIIic policy to multiple interIaces, each interIace can have only one traIIic
policy attached at the input and a single traIIic policy attached at the output:
Router(config)= interface eI/I
Router(config-if)= service-policy output policyI
Router(config-if)= exit
Router(config)= interface faI/0/0
Router(config-if)= service-policy output policyI
Summary
References
For more inIormation on the Modular Quality oI Service Command-Line InterIace, reIer to
'Modular Quality oI Service Command-Line InterIace Overview ¨ at the Iollowing URL:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products¸conIiguration¸guide¸c
hapter09186a00800bd908.html
'QC: Part 8: Modular Quality oI Service Command-Line InterIace¨ at the Iollowing URL:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products¸conIiguration¸guide¸
book09186a00800b75e4.html
'ConIiguring the Modular Quality oI Service Command-Line InterIace ¨ at the Iollowing
URL:
hapter09186a00800bd909.html
Summary
· MQC is a moduIar approach to designing and
impIementing an overaII QoS poIicy.
· AppIying an overaII QoS poIicy invoIves three steps:
defining cIass maps to identify cIasses of traffic, defining
QoS poIicy maps, and assigning the poIicy maps to
interfaces.
· Each cIass of traffic is defined in a cIass map moduIe.
· A poIicy map moduIe defines a traffic poIicy, which
configures the QoS features associated with a traffic
cIass previousIy identified using a cIass map.
· A service poIicy attaches a traffic poIicy configured with
a poIicy map to an interface.
Quiz
Q1) Which three oI the Iollowing are steps in implementing a QoS policy using MQC?
(Choose three.)
A) classiIy traIIic
B) conIigure queuing mechanisms
C) deIine QoS policies and assign traIIic
D) attach policies to interIaces
Q2) Match the MQC implementation step with its associated Cisco IOS command:
A) deIine classes oI traIIic
B) deIine QoS policies Ior classes
C) apply policy map to interIace
¸¸¸¸¸ 1. policy-map
¸¸¸¸¸ 2. service-policy
¸¸¸¸¸ 3. class-map
Q3) Which match type is the deIault mode Ior class maps?
A) match none
B) match all
C) match any
D) match Iirst
Q4) When using the match-any conditional when deIining a class map, what happens iI a
packet matches more than one condition?
A) The packet would not be considered a member oI the class.
B) The packet would be considered a member oI the class.
C) The packet would be moved to the speciIied alternate match class.
D) The packet would be dropped.
Q5) How many traIIic classes can be assigned to a single policy map?
A) 32
B) 64
C) 256
D) 1044
Q6) How do you conIigure the class deIault?
A) Using the class-map default command.
B) No need toit is automatically conIigured.
C) As the last class deIined within a class map.
D) As the last class speciIied in a policy map.
Quiz Answer Key
Q1) A, C, D
ReIates to: Modular QoS CLÌ
Q2) A 3, B 1, C - 2
ReIates to: Modular QoS CLÌ Components
Q3) B
ReIates to: Class Maps
Q4) B
ReIates to: Configuring and Monitoring Class Maps
Q5) C
ReIates to: Policy Maps
Q6) B
ReIates to: Configuring and Monitoring Policy Maps
Ìntroducing AutoQoS
Overview
Cisco AutoQoS represents innovative technology that simpliIies network administration
challenges, reducing QoS complexity, deployment time, and cost in enterprise networks. Cisco
AutoQoS incorporates value-added intelligence in Cisco IOS soItware and Cisco Catalyst
soItware to provision and manage large-scale QoS deployments. Cisco AutoQoS provides QoS
provisioning Ior individual routers and switches, simpliIying deployment and reducing human
error.
The Iirst phase oI Cisco AutoQoS oIIers straightIorward capabilities to automate Voice over IP
(VoIP) deployments Ior customers who want to deploy IP telephony, but who lack the expertise
and staIIing to plan and deploy IP QoS and IP services.
ReIevance
AutoQoS is one oI the two key methods recommended Ior implementing QoS on a network.
AutoQoS may be the best choice Ior quickly and easily implementing networks incorporating
voice applications.
Objectives
Upon completing this lesson, you will be able to correctly identiIy capabilities provided by
AutoQoS and successIully conIigure QoS on a network using AutoQoS. This includes being
able to meet these objectives:
Explain how AutoQoS is used to implement QoS policy
Describe the router environments in which AutoQoS can be used
Describe the switch environments in which AutoQoS can be used
ConIigure AutoQoS on a network using CLI
Use Cisco IOS commands to examine and monitor a network conIiguration aIter AutoQoS
has been enabled
IdentiIy several oI the QoS technologies that were automatically implemented on the
Basic understanding oI the Cisco IOS command-line interIace
OutIine
OutIine
· Overview
· AutoQoS
· AutoQoS: Router PIatforms
· AutoQoS: Switch PIatforms
· Configuring AutoQoS
· Monitoring AutoQoS
· Automation with Cisco AutoQoS
· Summary
· Quiz
AutoQoS
This topic describes the basic purpose and Iunction oI AutoQoS.
AutoQoS gives customers the ability to deploy QoS Ieatures Ior converged IP telephony and
data networks much Iaster and more eIIiciently. It simpliIies and automates the MQC deIinition
oI traIIic classes and the creation and conIiguration oI traIIic policies. (Cisco AutoQoS
generates traIIic classes and policy map CLI templates.) ThereIore, when AutoQoS is
conIigured at the interIace or permanent virtual circuit (PVC), the traIIic receives the required
QoS treatment automatically. In-depth knowledge oI the underlying technologies, service
policies, link eIIiciency mechanisms, and Cisco QoS best practice recommendations Ior voice
requirements is not required to conIigure AutoQoS.
Cisco AutoQoS can be extremely beneIicial Ior the Iollowing scenarios:
Small- to medium-sized businesses that must deploy IP telephony quickly, but lack the
experience and staIIing to plan and deploy IP QoS services.
Large customer enterprises that need to deploy Cisco telephony solutions on a large scale,
while reducing the costs, complexity, and timeIrame Ior deployment and ensuring that the
appropriate QoS Ior voice applications is being set in a consistent Iashion.
International enterprises or service providers requiring QoS Ior VoIP where little expertise
exists in diIIerent regions oI the world and where provisioning QoS remotely and across
diIIerent time zones is diIIicult.
Service providers requiring a template-driven approach to delivering managed services and
QoS Ior voice traIIic to large numbers oI customer premise devices.
AutoQoS
One command per interface to enabIe and configure QoS
Cisco AutoQoS automatically creates the QoS-speciIic Ieatures required Ior supporting the
underlying transport mechanism and link speed oI an interIace or PVC type. For example,
Frame Relay traIIic shaping (FRTS) would be automatically conIigured and enabled by Cisco
AutoQoS Ior Frame Relay links. Link Iragmentation and interleaving (LFI) and compressed
Real-Time Transport Protocol (cRTP) would be automatically conIigured via the Cisco
AutoQoS template Ior slow link speeds (less than 768 kbps). ThereIore, it is very important that
the bandwidth statement be properly set on the interIace prior to conIiguring AutoQoS because
the resulting conIiguration will vary, based on this conIigurable parameter.
Using Cisco AutoQoS, VoIP traIIic is automatically provided with the required QoS template
Ior voice traIIic by conIiguring auto qos voip on an interIace or PVC. Cisco AutoQoS enables
the required QoS based on Cisco best-practices methodologies. (The conIiguration generated
by Cisco AutoQoS can be modiIied iI necessary.)
AutoQoS (Cont.)
interface Multilink1
ip address 10.1.61.1 255.255.255.0
load~interval 30
ppp multilink
multilink~group 1
!
interface Serial0
bandwidth 256
no ip address
encapsulation ppp
no ip mroute~cache
load~interval 30
no fair~queue
ppp multilink
multilink~group 1
interface Serial0
bandwidth 256
ip address 10.1.61.1 255.255.255.0
auto qos voip
AutoQoS
ManuaI QoS
Cisco AutoQoS simpliIies and shortens the QoS deployment cycle. Cisco AutoQoS helps in all
Iive major aspects oI successIul QoS deployments:
Application Classification: Cisco AutoQoS leverages intelligent classiIication on routers
utilizing Cisco network-based application recognition (NBAR) to provide deep and stateIul
packet inspection. Cisco AutoQoS uses Cisco Discovery Protocol (CDP) Ior voice packets,
ensuring that the device attached to the LAN is really an IP Phone.
Policy Generation: Cisco AutoQoS evaluates the network environment and generates an
initial policy. It automatically determines WAN settings Ior Iragmentation, compression,
encapsulation, and Frame Relay-to-ATM Service Interworking (FRF.8), eliminating the
need to understand QoS theory and design practices in various scenarios. Customers can
meet additional or special requirements by modiIying the initial policy as they normally
would.
The Iirst release oI Cisco AutoQoS provides the necessary AutoQoS VoIP Ieature to
automate QoS settings Ior VoIP deployments. This Ieature automatically generates
interIace conIigurations, policy maps, class maps, and ACLs. AutoQoS VoIP will
automatically employ Cisco NBAR to classiIy voice traIIic, and mark it with the
appropriate diIIerentiated services code point (DSCP) value. AutoQoS VoIP can be
instructed to rely on, or trust, the DSCP markings previously applied to the packets.
Configuration: With one command, Cisco AutoQoS conIigures the port to prioritize voice
traIIic without aIIecting other network traIIic while still oIIering the Ilexibility to adjust
QoS settings Ior unique network requirements.
Not only will Cisco AutoQoS automatically detect Cisco IP Phones and enable QoS
settings, it will disable the QoS settings when a Cisco IP Phone is relocated or moved to
prevent malicious activity.
AutoQoS generated router and switch conIigurations are customizable using the standard
Cisco IOS CLI.
AutoQoS (Cont.)
· AppIication CIassification
÷ AutomaticaIIy discovers appIications
and provides appropriate QoS treatment
· PoIicy Generation
÷ AutomaticaIIy generates initiaI and
ongoing QoS poIicies
· Configuration
÷ Provides high-IeveI business
knobs, and muIti-device/domain
automation for QoS
· Monitoring & Reporting
÷ Generates inteIIigent, automatic
aIerts and summary reports
· Consistency
÷ EnabIes automatic, seamIess
interoperabiIity among aII QoS features and
parameters across a network topoIogy -
LAN, MAN, and WAN
Monitoring & Reporting: Cisco AutoQoS provides visibility into the classes oI service
deployed via system logging and Simple Network Management Protocol (SNMP) traps,
with notiIication oI abnormal events (that is, VoIP packet drops).
Consistency: When deploying QoS conIigurations using AutoQoS, conIigurations
generated are consistent among router and switch platIorms. This level oI consistency
ensures seamless QoS operation and interoperability within the network.
AutoQoS: Router PIatforms
This topic identiIies the router platIorms on which AutoQoS will operate.
Initial support Ior AutoQoS includes the Cisco 2600 (including XM models), 3600, 3700, and
7200 series routers. Support Ior additional platIorms will become available.
The Cisco AutoQoS VoIP Ieature is supported only on the Iollowing interIaces and PVCs:
Serial interIaces with PPP or high-level data link control (HDLC)
Frame Relay data-link connection identiIiers (DLCIs)PPP subinterIaces only
Cisco AutoQoS does not support Frame Relay multipoint interIaces
ATM PVCs
Cisco AutoQoS VoIP is supported on low-speed ATM PVCs on PPP subinterIaces
only (link bandwidth less than 768 kbps)
Cisco AutoQoS VoIP is Iully supported on high-speed ATM PVCs (link bandwidth
greater than 768 kbps)
AutoQoS: Router PIatforms
· Cisco 1760, 2600, 3600, 3700
and 7200 series routers
· User can meet the voice
QoS requirements without
extensive knowIedge about:
÷ UnderIying technoIogies
(for exampIe: PPP, FR, ATM)
÷ Service poIicies
÷ Link efficiency mechanisms
· AutoQoS Iends itseIf to
tuning of aII generated
parameters & configurations
AutoQoS: Switch PIatforms
This topic identiIies the switch platIorms on which AutoQoS will operate.
Initial support Ior AutoQoS includes the Cisco Catalyst 6500, 4500, 3550, and 2950 (EI) series
switches. Support Ior additional platIorms including the Cisco Catalyst 4000 will become
available.
The Enhanced Image (EI) is required on the Cisco Catalyst 2950 series switches.
AutoQoS: Switch PIatforms
· Cisco CataIyst 6500, 4500,
3550, and 2950 (EI) Switches
· User can meet the voice QoS
requirements without extensive
knowIedge about:
÷ Trust boundary
÷ CoS to DSCP mappings
÷ Weighted round robin (WRR) &
priority queue (PQ) scheduIing
parameters
· Generated parameters and
configurations are user tunabIe
To conIigure the QoS settings and the trusted boundary Ieature on the Cisco IP Phone, you
must enable CDP version 2 or later on the port. II you enable the trusted boundary Ieature, a
syslog warning message displays iI CDP is not enabled or iI CDP is running version 1.
You need to enable CDP only Ior the ciscoipphone QoS conIiguration; CDP does not aIIect the
other components oI the automatic QoS Ieatures. When you use the ciscoipphone keyword
with the port-speciIic automatic QoS Ieature, a warning displays iI the port does not have CDP
enabled.
When executing the port-speciIic automatic QoS command with the ciscoipphone keyword
without the trust option, the trust-device Ieature is enabled. The trust-device Ieature is
dependent on CDP. II CDP is not enabled or not running version 2, a warning message displays
as Iollows:
Console> (enable) set port qos 4/1 autoqos voip ciscoipphone
Warning. CDP is disabled or CDP version I is in use. Ensure
that CDP version ? is enabled globally, and also ensure that
CDP is enabled on the port(s) you wish to configure autoqos
on.
Port 4/I ingress QoS configured for ciscoipphone.
It is recommended to execute the "set qos autoqos" global
command if not executed previously.
Console> (enable)
AutoQoS: Switch PIatforms (Cont.)
· SingIe command at the interface IeveI configures
interface and gIobaI QoS
÷ Support for Cisco IP Phone & Cisco SoftPhone
· Support for Cisco SoftPhone currentIy exists onIy on the Cat6500
÷ Trust Boundary is disabIed when IP Phone is
moved/reIocated
÷ Buffer AIIocation & Egress Queuing dependent on interface
type (GigabitEthernet [GE]/FastEthernet [FE])
· Supported on static, dynamic-access, voice VLAN
access, and trunk ports
· CDP must be enabIed for AutoQoS to function
properIy
Configuring AutoQoS
This topic describes one oI the key prerequisites Ior using AutoQoS.
BeIore conIiguring AutoQoS, the Iollowing prerequisites must be met:
Cisco Express Forwarding (CEF) must be enabled at the interIace or ATM PVC. Cisco
AutoQoS uses NBAR to identiIy various applications and traIIic types and CEF is a
prerequisite Ior NBAR.
Ensure that no QoS policies (service policies) are attached to the interIace. This Ieature
cannot be conIigured iI a QoS policy (service policy) is attached to the interIace.
AutoQoS classiIies links as either low-speed or high-speed depending upon the link
bandwidth. Remember that on a serial interIace, iI the deIault bandwidth is not speciIied it
is 1.544 Mbps. ThereIore, it is important that the correct bandwidth be speciIied on the
interIace or subinterIace where AutoQoS is to be enabled.
For all interIaces or subinterIaces, be sure to properly conIigure the bandwidth by
using the bandwidth command. The amount oI bandwidth that is allocated should be
based on the link speed oI the interIace.
II the interIace or subinterIace has a link speed oI 768 kbps or lower, an IP address
must be conIigured on the interIace or subinterIace using the ip address command.
By deIault, AutoQoS will enable Multilink PPP (MLP) and copy the conIigured IP
address to the multilink bundle interIace.
Configuring AutoQoS:
Prerequisites for Using AutoQoS
· Cisco Express Forwarding (CEF) must be
enabIed at the interface or ATM PVC.
· This feature cannot be configured if a QoS poIicy
(service poIicy) is attached to the interface.
· An interface is cIassified as Iow-speed if its
bandwidth is Iess than or equaI to 768 kbps. It is
cIassified as high-speed if its bandwidth is
greater than 768 kbps.
÷ The correct bandwidth shouId be configured on aII
interfaces or subinterfaces using the bandwidth
command.
÷ If the interface or subinterface has a Iink speed of 768
kbps or Iower, an IP address must be configured using
the ip address command.
In addition to the AutoQoS prerequisites, the Iollowing are recommendations and requirements
when conIiguring AutoQoS. Be aware that these may change with Cisco IOS releases and
should be veriIied beIore implementing AutoQoS in your environment.
The Cisco AutoQoS VoIP Ieature is supported only on the Iollowing interIaces and PVCs:
Serial interIaces with PPP or HDLC
Frame Relay DLCIs (PPP subinterIaces only)
Cisco AutoQoS does not support Frame Relay multipoint interIaces
ATM PVCs
ConIiguration template (CLI) generated by conIiguring Cisco AutoQoS on an interIace or
PVC can be tuned manually (via CLI conIiguration) iI desired.
Cisco AutoQoS cannot be conIigured iI a QoS service-policy is already conIigured and
attached to the interIace or PVC.
MLP is conIigured automatically Ior a serial interIace with low-speed link. The serial
interIace must have an IP address and this IP address is removed and put on the MLP
bundle. Cisco AutoQoS VoIP must also be conIigured on the other side oI the link
The no auto qos voip command removes Cisco AutoQoS. However, iI the interIace or
PVC Cisco AutoQoS generated QoS conIiguration is deleted without conIiguring the no
auto qos voip command, Cisco AutoQoS VoIP will not be completely removed Irom the
conIiguration properly.
Cisco AutoQoS SNMP traps are only delivered when an SNMP server is used in
conjunction with Cisco AutoQoS.
The SNMP community string 'AutoQoS¨ should have 'write¨ permissions.
II the device is reloaded with the saved conIiguration aIter conIiguring Cisco AutoQoS and
saving the conIiguration to NVRAM, some warning messages may be generated by
Remote Monitoring (RMON) threshold commands. These warning messages can be
ignored. (To avoid Iurther warning messages, save the conIiguration to NVRAM again
without making any changes to the QoS conIiguration.)
By deIault, Cisco 7200 series routers and below that support MQC QoS, reserve up to 75
percent oI the interIace bandwidth Ior user-deIined classes. The remaining bandwidth is
used Ior the deIault class. However, the entire remaining bandwidth is not guaranteed to the
deIault class. This bandwidth is shared proportionately between the diIIerent Ilows in the
deIault class and excess traIIic Irom other bandwidth classes. At least one percent oI the
available bandwidth is reserved and guaranteed Ior class deIault traIIic by deIault on Cisco
7500 series routers. (Up to 99 percent can be allocated to the other classes.)
To conIigure the AutoQoS VoIP Ieature on an interIace, use the auto qos voip command in
interIace conIiguration mode or Frame Relay DLCI conIiguration mode. To remove the
AutoQoS VoIP Ieature Irom an interIace, use the no Iorm oI the auto qos voip command.auto
qos voip ¡trust] ¡fr-atm]
no auto qos voip ¡trust] ¡fr-atm]
Syntax Description
Parameter Description
trust (Optional) Ìndicates that the DSCP markings of a packet are trusted (relied on) for
classification of the voice traffic. Ìf the optional trust keyword is not specified, the
voice traffic is classified using NBAR, and the packets are marked with the
appropriate DSCP value.
fr-atm (Optional) Enables the AutoQoS VoÌP feature for the Frame Relay-to-ATM links.
This option is available on the Frame Relay DLCÌs for Frame Relay-to-ATM
interworking only.
The bandwidth oI the serial interIace is used to determine the link speed. The link speed is one
element that is used to determine the conIiguration generated by the AutoQoS VoIP Ieature.
The AutoQoS VoIP Ieature uses the bandwidth at the time the Ieature is conIigured and does
not respond to changes made to bandwidth aIter the Ieature is conIigured.
For example, iI the auto qos voip command is used to conIigure the AutoQoS VoIP Ieature on
an interIace with 1000 kbps, the AutoQoS VoIP Ieature generates conIigurations Ior high-speed
interIaces. However, iI the bandwidth is later changed to 500 kbps, the AutoQoS VoIP Ieature
will not use the lower bandwidth. The AutoQoS VoIP Ieature retains the higher bandwidth and
continues to use the generated conIigurations Ior high-speed interIaces.
To Iorce the AutoQoS VoIP Ieature to use the lower bandwidth (and thus generate
conIigurations Ior the low-speed interIaces), use the no auto qos voip command to remove the
AutoQoS VoIP Ieature and then reconIigure the Ieature.
Routers
auto qos voip (trust) (fr~atm) auto qos voip (trust) (fr~atm)
router(config~if)# or router(config~fr~dlci)#
· Configures the AutoQoS VoIP feature.
· Untrusted mode by defauIt.
· trust: Indicates that the differentiated services code point
(DSCP) markings of a packet are trusted (reIied on) for
cIassification of the voice traffic.
· fr-atm: For Iow-speed Frame ReIay DLCIs interconnected
with ATM PVCs in the same network, the fr-atm keyword
must be expIicitIy configured in the auto qos voip
command to configure the AutoQoS VoIP feature properIy.
ExampIe: Configuring the AutoQoS VoIP Feature on a High-
Speed SeriaI Interface
In this example, the AutoQoS VoIP Ieature is conIigured on the high-speed serial
interIace s1/2:
Router> enable
Router= configure terminal
Router(config)= interface sI/?
Router(config-if)= bandwidth IS40
Router(config-if)= auto qos voip
ExampIe: Configuring the AutoQoS VoIP Feature on a Low-
Speed SeriaI Interface ExampIe
In this example, the AutoQoS VoIP Ieature is conIigured on the low-speed serial interIace s1/3:
Router= configure terminal
Router(config)= interface sI/·
Router(config-if)= bandwidth SI?
Router(config-if)= ip address I0.I0.I00.I ?SS.?SS.?SS.0
Router(config-if= auto qos voip
When you execute the global automatic QoS macro, all the global QoS settings are applied to
all ports in the switch. AIter completion, a prompt will display showing the CLI Ior the port-
based automatic QoS commands that are currently supported.
Cisco CataIyst 6500 Switch
Console>(enable)set qos autoqos
QoS is enabled
.........
All ingress and egress QoS scheduling parameters configured on all
ports.CoS to DSCP, DSCP to CoS, IP Precedence to DSCP and policed
dscp maps configured.
Global QoS configured, port specific autoqos recommended:
set port qos <mod/port> autoqos trust <cos|dscp>
set port qos <mod/port> autoqos voip <ciscoipphone|ciscosoftphone>
set qos autoqos set qos autoqos
Console> (enable)
· GIobaI configuration command.
· AII the gIobaI QoS settings are appIied to aII ports in the
switch.
· Prompt dispIays showing the CLI for the port-based
automatic QoS commands currentIy supported.
Cisco CataIyst 6500 Switch (Cont.)
set port qos autoqos <mod/port> trust (cos|dscp) set port qos autoqos <mod/port> trust (cos|dscp)
Console> (enable)
· trust dscp and trust cos are automatic QoS keywords
used for ports requiring a "trust aII" type of soIution.
· trust dscp shouId be used onIy on ports that connect to
other switches or known servers as the port wiII be
trusting aII inbound traffic marking Layer 3 (DSCP).
· trust cos shouId onIy be used on ports connecting other
switches or known servers as the port trusts aII inbound
traffic marking in Layer 2 (CoS).
· The trusted boundary feature is disabIed and no QoS
poIicing is configured on these types of ports.
The port-speciIic automatic QoS macro handles all inbound QoS conIiguration that is speciIic
to a particular port.
The QoS ingress port speciIic settings include port trust, deIault class oI service (CoS),
classiIication, and policing, but does not include scheduling. Input scheduling is programmed
through the global automatic QoS macro. Together with the global automatic QoS macro
command, all QoS settings are conIigured properly Ior a speciIic QoS traIIic type.
Any existing QoS ACLs that are already associated with a port are removed when AutoQoS
modiIies ACL mappings on that port. The ACL names and instances are not changed.
The port-speciIic automatic QoS macro accepts a moa/port combination and must include a
Cisco Architecture Ior Voice, Video and Integrated Date (AVVID) type oI keyword. The
ciscoipphone, ciscosoftphone, and trust keywords are supported.
With the ciscoipphone keyword, the port is set up to trust-cos as well as to enable the trusted
boundary Ieature. Combined with the global automatic QoS command, all settings are
conIigured on the switch to properly handle the signaling and voice bearer and PC data entering
and leaving the port.
In addition to the switch-side QoS settings that are covered by the global automatic QoS
command, the IP Phone has a Iew QoS Ieatures that need to be conIigured Ior proper labeling
to occur. QoS conIiguration inIormation is sent to the IP Phone through CDP Irom the switch.
The QoS values that need to be conIigured are the trust settings oI the 'PC port¨ on the IP
Phone (trust or untrusted) and the CoS value that is used by the IP Phone to remark packets in
case the port is untrusted (ext-cos).
Only the Catalyst 6500 supports AutoQoS Ior Cisco SoItPhone. On the ports that connect to a
Cisco SoItPhone, QoS settings must be conIigured to trust the Layer 3 markings oI the traIIic
that enters the port. Trusting all Layer 3 markings is a security risk because PC users could
send non-priority traIIic with DSCP 46 and gain unauthorized perIormance beneIits. Although
not conIigured by AutoQos, policing on all inbound traIIic can be used to prevent malicious
users Irom obtaining unauthorized bandwidth Irom the network. Policing is accomplished by
rate limiting the DSCP 46 (EF) inbound traIIic to the codec rate used by the Cisco SoItPhone
application (worst case G.722). Any traIIic that exceeds this rate is marked down to the deIault
traIIic rate (DSCP 0 - BE). Signaling traIIic (DSCP 24) is also policed and marked down to
zero iI excess signaling traIIic is detected. All other inbound traIIic types are reclassiIied to
deIault traIIic (DSCP 0 - BE).
Note: You must disable the trusted boundary feature for Cisco SoftPhone ports.
Cisco CataIyst 6500 Switch (Cont.)
set port qos autoqos <mod/port> voip (ciscosoftphone
| ciscoipphone)
set port qos autoqos <mod/port> voip (ciscosoftphone
| ciscoipphone)
Console> (enable)
ciscosoftphone
· The trusted boundary feature must be disabIed for Cisco SoftPhone
ports.
· QoS settings must be configured to trust the Layer 3 markings of the
traffic that enters the port.
· OnIy avaiIabIe on CataIyst 6500.
ciscoipphone
· The port is set up to trust-cos as weII as to enabIe the trusted boundary
feature.
· Combined with the gIobaI automatic QoS command, aII settings are
configured on the switch to properIy handIe the signaIing and voice
bearer and PC data entering and Ieaving the port.
· CDP must be enabIed for the ciscoipphone QoS configuration.
ExampIe: Using the Port-Specific AutoQoS Macro
This example shows how to use the ciscoipphone keyword:
Console> (enable) set port qos 3/1 autoqos help
Usage. set port qos <mod/port> autoqos trust <cos|dscp>
set port qos <mod/port> autoqos voip
<ciscoipphone|ciscosoftphone>
Console> (enable) set port qos 3/1 autoqos voip ciscoipphone
Port ·/I ingress QoS configured for Cisco IP Phone.
Console> (enable)
This example shows how to use the ciscosoftphone keyword:
Console> (enable) set port qos 3/1 autoqos voip ciscosoftphone
Port ·/I ingress QoS configured for Cisco Softphone.
Console> (enable)
This example shows how to use the trust cos keyword:
Console> (enable) set port qos 3/1 autoqos trust cos
Port ·/I QoS configured to trust all incoming CoS marking.
Console> (enable)
This example shows how to use the trust dscp keyword:
Console> (enable) set port qos 3/1 autoqos trust dscp
Port ·/I QoS configured to trust all incoming DSCP marking.
Console> (enable)
When you enable the AutoQoS Ieature on the Iirst interIace, QoS is globally enabled (mls qos
global conIiguration command).
When you enter the auto qos voip trust interIace conIiguration command, the ingress
classiIication on the interIace is set to trust the CoS QoS label received in the packet, and the
egress queues on the interIace are reconIigured. QoS labels in ingress packets are trusted.
When you enter the auto qos voip cisco-phone interIace conIiguration command, the trusted
boundary Ieature is enabled. It uses the CDP to detect the presence or absence oI a Cisco IP
Phone. When a Cisco IP Phone is detected, the ingress classiIication on the interIace is set to
trust the QoS label received in the packet. When a Cisco IP Phone is absent, the ingress
classiIication is set to not trust the QoS label in the packet. The egress queues on the interIace
are also reconIigured. This command extends the trust boundary iI IP Phone is detected.
CataIyst 2950 (EI), 3550 Switches
auto qos voip trust auto qos voip trust
Switch(config~if)#
· The upIink interface is connected to a trusted switch or
router, and the VoIP cIassification in the ingress packet is
trusted.
auto qos voip cisco~phone auto qos voip cisco~phone
Switch(config~if)#
· AutomaticaIIy enabIes the trusted boundary feature, which
uses the CDP to detect the presence or absence of a
Cisco IP Phone.
· If the interface is connected to a Cisco IP Phone, the QoS
IabeIs of incoming packets are trusted onIy when the IP
Phone is detected.
Monitoring AutoQoS
This topic describes the commands that are used to monitor AutoQoS conIigurations.
When the auto qos voip command is used to conIigure the AutoQoS VoIP Ieature,
conIigurations are generated Ior each interIace or PVC. These conIigurations are then used to
create the interIace conIigurations, policy maps, class maps, and ACLs. The show auto qos
command can be used to veriIy the contents oI the interIace conIigurations, policy maps, class
maps, and ACLs.
The show auto qos interface command can be used with Frame Relay DLCIs and ATM PVCs.
When the interface keyword is used along with the corresponding interIace type argument, the
show auto qos interface |interface type| command displays the conIigurations created by the
AutoQoS VoIP Ieature on the speciIied interIace.
When the interface keyword is used but an interIace type is not speciIied, the show auto qos
interface command displays the conIigurations created by the AutoQoS VoIP Ieature on all the
interIaces or PVCs on which the AutoQoS VoIP Ieature is enabled.
Monitoring AutoQoS:
Routers
show auto qos (interface interface type) show auto qos (interface interface type)
router>
router>show auto qos interface Serial6/0
Serial6/0 ~
!
interface Serial6/0
service~policy output AutoQoS~Policy~UnTrust
· DispIays the interface configurations, poIicy maps, cIass
maps, and ACLs created on the basis of automaticaIIy
generated configurations.
ExampIe: Show Auto QoS and Show Auto QoS Interface
The show auto qos command displays all oI the conIigurations created by the AutoQoS VoIP
Ieature:
Router= show auto qos
Serial8/I.I. DLCI I00 -
!
interface Serial8/I
frame-relay traffic-shaping
!
interface Serial8/I.I point-to-point
frame-relay interface-dlci I00
class AutoQoS-VoIP-FR-Serial8/I-I00
frame-relay ip rtp header-compression
!
map-class frame-relay AutoQoS-VoIP-FR-Serial8/I-I00
frame-relay cir SI?000
frame-relay bc SI?0
frame-relay be 0
frame-relay mincir SI?000
service-policy output AutoQoS-Policy-UnTrust
frame-relay fragment 840
To display the conIiguration oI all classes conIigured Ior all service policies on the speciIied
interIace, or to display the classes Ior the service policy Ior a speciIic PVC on the interIace, use
the show policy-map interface EXEC or privileged EXEC command.
show policy~map interface interface-name (vc (vpi/) vci)(dlci
dlci) (input | output)
Monitoring AutoQoS:
Routers (Cont.)
router>show policy~map interface FastFthernet0/0.1
FastFthernet0/0.1
Service~policy output: voice_traffic
Class~map: dscp46 (match~any)
0 packets, 0 bytes
Match: ip dscp 46
0 packets, 0 bytes
5 minute rate 0 bps
Traffic Shaping
Target Byte Sustain Fxcess Interval Increment Adapt
Rate Limit bits/int bits/int (ms) (bytes) Active
2500 10000 10000 333 1250 ~
..rest deleted
show policy~map interface (interface type) show policy~map interface (interface type)
router>
· DispIays the packet statistics of aII cIasses that are configured for aII
service poIicies, either on the specified interface or subinterface.
To display the inital AutoQoS conIiguration, use the show auto qos |interface |interface-ia||
privileged EXEC command. To display any user changes to that conIiguration, use the show
running-config privileged EXEC command. You can compare the show auto qos and the
show running-config command output to identiIy the user-deIined QoS settings.
Monitoring AutoQoS:
Switches
show auto qos (interface interface~id) show auto qos (interface interface~id)
Switch#
Switch#show auto qos
Initial configuration applied by AutoQoS:
wrr~queue bandwidth 20 1 80 0
no wrr~queue cos~map
wrr~queue cos 1 0 1 2 4
wrr~queue cos 3 3 6 7
wrr~queue cos 4 5
mls qos map cos~dscp 0 8 16 26 32 46 48 56
!
mls qos trust device cisco~phone
mls qos trust cos
· DispIays the AutoQoS configuration that was initiaIIy appIied
· Does not dispIay any user changes to the configuration that
might be in effect
The show mls qos interface command is used to display QoS inIormation at the interIace
level, including the conIiguration oI the egress queues and the CoS-to-egress-queue map, the
interIaces that have conIigured policers, and ingress and egress statistics (including the number
oI bytes dropped).
II no keyword is speciIied with the show mls qos interface command, the port QoS mode
(DSCP trusted, CoS trusted, untrusted, and so Iorth), deIault CoS value, DSCP-to-DSCP-
mutation map (iI any) that is attached to the port, and policy map (iI any) that is attached to the
interIace, are displayed. II a speciIic interIace is not speciIied, the inIormation Ior all interIaces
is displayed.
Expressions are case sensitive. For example, iI you enter , exclude output, the lines that
contain output are not displayed, but the lines that contain output are displayed.
Monitoring AutoQoS:
Switches (Cont.)
Switch#show mls qos interface gigabitethernet0/1 statistics
Ingress
dscp: incoming no_change classified policed dropped (in bytes)
1 : 0 0 0 0 0
others: 203216935 24234242 178982693 0 0
Fgress
1 : 0 n/a n/a 0 0
WRFD drop counts:
qid thresh1 thresh2 FreeQ
1 : 0 0 1024
2 : 0 0 1024
...rest deleted
Switch#show mls qos interface gigabitethernet0/1 statistics
Ingress
1 : 0 0 0 0 0
others: 203216935 24234242 178982693 0 0
Fgress
1 : 0 n/a n/a 0 0
WRFD drop counts:
qid thresh1 thresh2 FreeQ
1 : 0 0 1024
2 : 0 0 1024
...rest deleted
show mls qos interface (interface~id | vlan vlan~id)
(buffers | policers | queueing | statistics)
( | ¦begin | exclude | include} expression)
show mls qos interface (interface~id | vlan vlan~id)
(buffers | policers | queueing | statistics)
( | ¦begin | exclude | include} expression)
Switch#
· DispIays QoS information at the interface IeveI
To generate an internal DSCP value representing the priority oI the traIIic, display the QoS
mapping inIormation.
Monitoring AutoQoS:
Switches (Cont.)
show mls qos maps (cos~dscp | dscp~cos | dscp~
mutation dscp~mutation~name | dscp~switch~priority |
ip~prec~dscp | policed~dscp) ( | ¦begin | exclude |
include} expression
show mls qos maps (cos~dscp | dscp~cos | dscp~
mutation dscp~mutation~name | dscp~switch~priority |
ip~prec~dscp | policed~dscp) ( | ¦begin | exclude |
include} expression
Switch#
Switch#show mls qos maps dscp~cos
Dscp~cos map:
dscp: 0 8 10 16 18 24 26 32 34 40 46 48 56
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cos: 0 1 1 2 2 3 3 4 4 5 5 6 7
· Maps are used to generate an internaI DSCP vaIue, which
represents the priority of the traffic.
Automation with Cisco AutoQoS
This topic identiIies several oI the QoS technologies that are automatically implemented on the
network when using AutoQoS.
Cisco AutoQoS perIorms the Iollowing Iunctions:
WAN:
Automatically classiIy RTP payload and VoIP control packets (H.323, H.225 Unicast,
Skinny, session initiation protocol (SIP), Media Gateway Control protocol (MGCP).
Build service policies Ior VoIP traIIic that are based on Cisco MQC.
Provision LLQpriority queuing (PQ) Ior VoIP bearer and bandwidth guarantees Ior
control traIIic.
Enable WAN traIIic shaping that adheres to Cisco best practices, where required.
Enable link eIIiciency mechanisms, such as LFI and cRTP where required.
Provide SNMP and syslog alerts Ior VoIP packet drops.
LAN:
EnIorce the trust boundary on Cisco Catalyst switch access ports and uplinks/downlinks.
Enable Cisco Catalyst strict PQ (also known as expedited queuing) with WRR scheduling
Ior voice and data traIIic, where appropriate.
ConIigure queue admission criteria (map CoS values in incoming packets to the appropriate
queues).
ModiIy queue sizes and weights where required.
Automation with Cisco AutoQoS:
DiffServ Functions Automated
Summary
References
For more inIormation on Cisco AutoQos, reIer to 'Cisco AutoQoS Whitepaper¨ at the
Iollowing URL:
http://www.cisco.com/en/US/tech/tk543/tk759/technologies¸white¸paper09186a00801348
bc.shtml
For more inIormation on Cisco AutoQos, reIer to 'ConIiguring Automatic QoS¨ at the
Iollowing URL:
http://www.cisco.com/en/US/products/hw/switches/ps708/products¸conIiguration¸guide¸c
hapter09186a0080121d11.html#1032637
For more inIormation on Cisco AutoQos, reIer to 'ConIiguring QoS¨ at the Iollowing
URL:
aapter09186a0080115928.html
For more inIormation on Cisco AutoQos, reIer to 'AutoQos VoIP¨ at the Iollowing URL:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products¸Ieature¸guide09186a0
080153ece.html#73342
For more inIormation on Cisco AutoQos, reIer to 'Cisco IOS Quality oI Service
ConIiguration Guide, Release 12.3¨ at the Iollowing URL:
http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/prod¸conIiguration¸guide09186
a008017d8e5.html
Summary
· QoS can be enabIed on a network by a singIe
command-per-interface using AutoQoS.
· AutoQoS works on a variety of Cisco routers and
switches.
· AutoQos automaticaIIy configures and enabIes
the DiffServ mechanisms necessary for QoS.
Next Steps
Lab Exercise 3-1: ConIiguring QoS with AutoQos
Quiz
Q1) For which Iour oI the Iollowing scenarios could Cisco AutoQos be most helpIul?
(Choose Iour.)
A) small- to medium-sized businesses that need to deploy IP telephony quickly
B) service providers requiring a template-driven approach to delivering managed
services
C) international enterprises or service providers requiring QoS Ior VoIP where
little expertise exists in diIIerent regions oI the world
D) large customer enterprises needing to ensure that the appropriate QoS Ior voice
applications is being set in a consistent Iashion
E) service providers with highly specialized customer requirements and large,
well-trained staIIs
Q2) Which three oI the Iollowing aspects oI QoS deployment does AutoQoS accomplish?
(Choose three.)
A) conIiguration
B) packet marking
C) monitoring and reporting
D) application classiIication
Q3) Which two oI the Iollowing series oI routers support AutoQoS? (Choose two.)
A) 2600
B) 12000
C) 7600
D) 7200
Q4) Which two oI the Iollowing series oI switches support AutoQoS? (Choose two.)
A) Catalyst 3550
B) Catalyst 1900-E
C) Catalyst 9509
D) Catalyst 6500
Q5) Which Cisco Ieature must be enabled on a switch to use AutoQoS?
A) CDM
B) ADE
C) QPM
D) CDP
Q6) Why must CEF be enabled to use AutoQoS?
A) to enable Iast switching Ior interIace speeds
B) CEF Iorwarding is used by AutoQoS Ior conIiguration
C) AutoQoS examines FIB tables to determine best policies
D) CEF is required Ior NBAR which is used by AutoQoS
Quiz Answer Key
Q1) A, B, C, D
ReIates to: AutoQoS
Q2) A, B, D
ReIates to: AutoQoS
Q3) A, D
ReIates to: AutoQoS: Router Platforms
Q4) A, D
ReIates to: AutoQoS: Switch Platforms
Q5) D
ReIates to: AutoQoS: Switch Platforms
Q6) D
ReIates to: Configuring AutoQoS
Module Assessment
Overview
Quiz: Introduction to ModuIar QoS CLI and
AutoQoS
Objectives
Explain how to implement a QoS policy using MQC
Correctly identiIy capabilities provided by AutoQoS and successIully conIigure QoS on a
Instructions
incorrectly.
Q1) Which command would you use to attach a QoS policy to an interIace?
A) policy-set-interface
B) policy-map
C) policy-interface
D) service-policy
Q2) In what manner can a service policy be attached to an interIace?
A) Ior inbound packets only
B) Ior outbound packets only
C) Ior inbound or outbound, not both
D) Ior inbound only, outbound only, or Ior both inbound and outbound
Q3) What is 'trusted¨ when the auto qos voip command is conIigured with the 'trust¨
parameter?
A) source address
B) MAC address oI sender
C) DES keyword
D) DSCP
Q4) Which three oI the Iollowing terms are displayed by the show auto qos interface
command? (Choose three.)
A) ACLs
B) class maps
C) policy maps
D) service maps
Q5) Which command would you use on a Catalyst switch to display the conIiguration oI the
egress queues?
A) show mls qos maps
B) show auto qos
C) show auto qos inteface
D) show mls qos interface
Q6) Which three oI the Iollowing does AutoQoS VoIP automatically do when used to
automatically conIigure a WAN interIace? (Choose three.)
A) enable payload compression
B) provision Low Latency Queuing (LLQ)
C) automatically classiIy RTP payload and VoIP control packets
D) enable Link Fragmentation and Interleaving (LFI) where required
Scoring
or better.
Q1) D
ReIates to: Ìntroducing Modular QoS CLÌ
Q2) D
ReIates to: Ìntroducing Modular QoS CLÌ
Q3) D
ReIates to: Ìntroducing AutoQoS
Q4) A, B, C
Q5) D
Q6) B, C, D
ModuIe Summary
Both the MQC and Cisco AutoQoS were designed to aid in more rapid and consistent design,
implementation, and maintenance oI QoS policies Ior converged networks. The MQC oIIers a
three-step, building-block approach to implementing extremely modular QoS policies Ior
network administrators with the requirement to careIully manage large and complex networks.
Cisco AutoQoS provides an easy-to-use, mostly automated means to provide consistent QoS
policies throughout a network with a minimal design and implementation eIIort.
ModuIe Summary
· ModuIar QoS is a three-step, buiIding bIock approach to
impIementing QoS in a network.
· Each cIass of traffic is defined in a cIass map moduIe.
· A poIicy map moduIe defines a traffic poIicy which
configures the QoS features associated with a traffic
cIass previousIy identified using a cIass map
· A service poIicy attaches a traffic poIicy configured with
a poIicy map to an interface.
· QoS can be enabIed on a network by a singIe command-
per-interface using AutoQoS.
· AutoQoS works on a variety of Cisco routers and
switches and automaticaIIy configures and enabIes the
mechanisms necessary for QoS.
ModuIe 4
Classification and Marking
Overview
In any network where networked applications require diIIerentiated levels oI service, traIIic
must be sorted into diIIerent classes upon which quality oI service (QoS) is applied.
ClassiIication and marking are two critical Iunctions oI any successIul QoS implementation.
ClassiIication allows network devices to identiIy traIIic as belonging to a speciIic class with
speciIic QoS requirements as determined by an administrative QoS policy. AIter network
traIIic is sorted, individual packets are colored or marked so that other network devices can
apply QoS Ieatures uniIormly to those packets in compliance with the deIined QoS policy.
This module introduces classiIication and marking and the diIIerent methods oI perIorming
these critical QoS Iunctions on Cisco routers and switches.
ModuIe Objectives
Upon completing this module, you will be able to successIully classiIy and mark network
traIIic to implement a policy deIining QoS requirements.
ModuIe OutIine
ModuIe Objectives
· ExpIain the purpose of cIassification and marking
and how they can be used to define a QoS service
cIass
· Use MQC commands to cIassify packets
· Use cIass-based marking to assign packets to a
specific service cIass
· Use NBAR to discover network protocoIs and
appIications, and to cIassify packets
· Use the QoS pre-cIassify feature to cIassify GRE,
IPSec, L2F, and L2TP encapsuIated packets
· ExpIain how to impIement cIassification and marking
in an interdomain network using QPPB
· Describe LAN-based methods for impIementing
cIassification and marking
ModuIe OutIine
· CIassification and Marking Overview
· Case Study: CIassification and Marking
· Using MQC fo CIassification
· Using MQC for CIass-Based Marking
· Using NBAR for CIassification
· Configuring QoS Pre-CIassify
· Configuring QoS PoIicy Propagation Through
BGP
· Configuring LAN CIassification and Marking
Classification and Marking
Overview
Overview
By its very deIinition, QoS is the ability to provide diIIerential levels oI treatment to speciIic
classes oI traIIic. BeIore any QoS applications or mechanisms can be applied, traIIic must be
identiIied and sorted into diIIerent classes. It is upon these diIIerent traIIic classes to which
QoS is applied. Network devices use classiIication to identiIy traIIic as belonging to a speciIic
class. AIter network traIIic is sorted, marking can be used to color (tag) individual packets so
that other network devices can apply QoS Ieatures uniIormly to those packets as they travel
through the network.
This lesson introduces the concepts oI classiIication and marking, explains the diIIerent
markers that are available at the data link and network layer, and identiIies where classiIication
and marking should be used in a network. The concept oI a QoS service class and how a service
class can be used to represent an application or set oI applications is also discussed.
ReIevance
ClassiIication and marking are the Ioundations Ior any network deployment oI QoS. As such, it
is oI key importance to understand the classiIication and marking mechanisms and how they
are used in implementing QoS.
Objectives
Upon completing this lesson, you will be able to explain the purpose oI classiIication and
marking and how they can be used to deIine a QoS service class. This includes being able to
Explain the purpose oI packet classiIication
Explain the purpose oI packet marking
Describe IP packet classiIication and marking at the data link layer
Describe IP packet classiIication and marking at the network layer
Describe data link to network layer interoperability between QoS markers
DeIine the term 'QoS service class¨ and describe how service classes can be used to create
a service policy throughout a network
Explain how link layer and network layer markings are used to deIine service classes and
the diIIerent applications represented by each oI these service classes
Explain the concept oI trust boundaries and how they are used with classiIication and
marking
Copyright © 2003, Cisco Systems, Ìnc. Classification and Marking 4-5
OutIine
OutIine
· Overview
· CIassification
· Marking
· CIassification and Marking at the Link Layer
· CIassification and Marking at the Network Layer
· Mapping CoS to Network Layer QoS
· QoS Service CIass Defined
· ImpIementing a QoS PoIicy Using a QoS Service CIass
· Trust Boundaries
· Summary
· Quiz
CIassification
This topic describes the purpose oI packet classiIication.
ClassiIication is the process oI identiIying traIIic and categorizing it into diIIerent classes.
Packet classiIication uses a traIIic descriptor to categorize a packet within a speciIic group in
order to deIine that packet. Typically used traIIic descriptors include: incoming interIace, IP
precedence, diIIerentiated services code point (DSCP), source or destination address, and
application. AIter the packet has been deIined (that is, classiIied), the packet is then accessible
Ior QoS handling on the network.
Using packet classiIication, network administrators can partition network traIIic into multiple
priority levels or classes oI service. When traIIic descriptors are used to classiIy traIIic, the
source agrees to adhere to the contracted terms and the network promises a QoS. DiIIerent QoS
mechanisms, such as traIIic policing, traIIic shaping, and queuing techniques, use the traIIic
descriptor oI the packet (that is, the classiIication oI the packet) to ensure adherence to that
agreement.
ClassiIication should take place at the network edge, typically in the wiring closet, within IP
Phones or at network endpoints. It is preIerred that classiIication occur as close to the source oI
the traIIic as possible.
CIassification
· The component of a QoS feature that recognizes
and distinguishes between different traffic
streams.
· Most fundamentaI QoS buiIding bIock.
· Without cIassification, aII packets are treated
the same.
Marking
This topic describes the purpose oI packet marking.
Marking is related to classiIication. Marking allows network devices to classiIy a packet or
Irame based on a speciIic traIIic descriptor. Typically used traIIic descriptors include: class oI
service (CoS), DSCP, IP precedence, QoS group, and Multiprotocol Label Switching (MPLS)
experimental bits. Marking can be used to set inIormation in the Layer 2 or Layer 3 packet
headers.
Marking a packet or Irame with its classiIication allows network devices to easily distinguish
the marked packet or Irame. Marking is a useIul Ieature because it allows network devices to
easily identiIy packets or Irames as belonging to a speciIic class. AIter they are identiIied as
belonging to a speciIic class, QoS mechanisms can be uniIormly applied to ensure compliance
with administrative QoS policies.
Marking
· The QoS feature component that "coIors" a
packet (frame) so it can be identified and
distinguished from other packets (frames) in
QoS treatment.
· CommonIy used markers incIude: CoS (ISL,
802.1p), DSCP, and IP precedence.
CIassification and Marking at the Link Layer
This topic describes diIIerent classiIication and marking options that are available at the data
link layer.
The 802.1Q standard is an IEEE speciIication Ior implementing virtual LANs (VLANs) in
Layer 2 switched networks. The 802.1Q speciIication deIines two 2-byte Iields (Tag Protocol
IdentiIier |TPID|) and Tag Control InIormation |TCI|) that are inserted within an Ethernet
Irame Iollowing the source address Iield. The TPID Iield is currently Iixed and assigned the
value 0x8100. The TCI Iield is composed oI three Iields as Iollows:
User Priority Bits (3 bits): The speciIications oI this 3-bit Iield are deIined by the IEEE
802.1p standard. These bits can be used to mark packets as belonging to a speciIic CoS.
The CoS marking uses the three 802.1p user priority bits and allows a Layer 2 Ethernet
Irame to be marked with 8 diIIerent levels oI priority (values 0-7). Three bits allow Ior 8
levels oI classiIication, allowing a direct correspondence with IPv4 (IP precedence) type oI
service (ToS) values. The IEEE 802.1p speciIication deIines these standard deIinitions Ior
each CoS:
CoS 7 (111): network
CoS 6 (110): internet
CoS 5 (101): critical
CoS 4 (100): Ilash-override
CoS 3 (011): Ilash
CoS 2 (010): immediate
CoS 1 (001): priority
CoS 0 (000): routine
Ethernet 802.1Q CIass of Service
· IEEE specification
· 802.1p user priority fieId aIso caIIed CoS
· Supports up to 8 cIasses of service
· Focuses on support for QoS over LANs and
802.1Q ports
· Preserved through the LAN, not end-to-end
One disadvantage oI using CoS markings is that Irames will lose their CoS markings when
transiting a non-802.1Q/p link. ThereIore, a more ubiquitous permanent marking should be
used Ior network transit. This is typically accomplished through translating a CoS marking
into another marker or simply using a diIIerent marking mechanism.
Canonical Format Identifier (CFI) (1 bit): This bit indicates whether the bit order is
canonical or noncanonical. The CFI bit is used Ior compatibility between Ethernet and
Token Ring networks.
VLAN Identifier (VLAN ID) (12 bits): The VLAN ID Iield is a 12-bit Iield that deIines
the VLAN used by 802.1Q. The Iact that the Iield is 12 bits restricts the number oI VLANs
supported by 802.1Q to 4096. For most enterprise customers, 4096 VLANs is adequate.
For service provider applications, 4096 VLANs may not be enough.
Inter-Switch Link (ISL) is a proprietary Cisco protocol Ior interconnecting multiple switches
and maintaining VLAN inIormation as traIIic goes between switches. ISL was created prior to
the standardization oI 802.1Q. However, ISL is compliant with the IEEE 802.1p standard.
The ISL Irame header contains a 1-byte User Iield that carries an IEEE 802.1p CoS values
in the three least signiIicant bits. When an ISL Irame is marked Ior priority, the three
802.1p CoS bits are set to a value 0-7. In compliance with the IEEE 802.1p speciIication,
ISL Iollows the standard deIinitions Ior each CoS:
CoS 7 (111): network
CoS 6 (110): internet
CoS 5 (101): critical
CoS 4 (100): Ilash-override
CoS 3 (011): Ilash
CoS 2 (010): immediate
CoS 1 (001): priority
CoS 0 (000): routine
Similar to 802.1Q, ISL CoS markings are not maintained end-to-end iI a non-ISL or 802.1Q
trunk is transited. As a result, network administrators typically translate CoS markings into
another marker or simply use a diIIerent marking mechanism altogether.
Cisco ISL CIass of Service
· Cisco proprietary specification
· ISL EncapsuIation adds 30 bytes to Ethernet
frame
· ISL Header contains VLAN fieId
· VLAN fieId consists of VLAN ID and CoS
· Supports up to 8 cIasses of service
· Focuses on support for QoS over ISL trunks
· Preserved through the LAN, not end-to-end
BeIore the Internet Engineering Task Force (IETF) deIined QoS methods Ior the network layer,
the ITU-T (International Union Ior Telecommunications), ATM Forum, and the Frame Relay
Forum (FRF) had already derived standards Ior link layer QoS in ATM and Frame Relay
networks.
ATM standards deIine a very rich QoS inIrastructure by supporting traIIic contracts, many
adjustable QoS knobs (such as peak cell rate |PCR|, minimum cell rate |MCR|, and so on),
signaling, and admission control. Frame Relay provides a simpler set oI QoS mechanisms to
ensure a committed inIormation rate (CIR), congestion notiIication, and Frame Relay
Iragmentation (FRF.12).
One component oI Frame Relay QoS is packet discard when congestion is experienced in the
network. Frame Relay will allow network traIIic to be sent at a rate exceeding its CIR. Frames
sent that exceed the committed rate can be marked as discard eligible (DE). II congestion
occurs in the network, Irames marked DE will be discarded prior to discarding Irames that do
not.
ATM cells consist oI 48 bytes oI payload and 5 bytes oI header. The ATM header includes the
1-bit cell loss priority (CLP) Iield, which indicates the drop priority oI the cell iI it encounters
extreme congestion as it moves through the ATM network. The CLP bit represents two values:
0 to indicate higher priority and 1 to indicate lower priority. Setting the CLP bit to 1 lowers the
priority oI the cell, increasing the likelihood that the cell will be dropped when the ATM
network experiences congestion.
Frame ReIay / ATM QoS
· Frame ReIay DTE devices can set the DE bit of a frame so that if the
network becomes congested, Frame ReIay devices wiII discard frames with
the DE bit set before discarding those that do not.
· Preserved throughout the Frame ReIay network.
· The CLP bit indicates that the ceII shouId be discarded if it encounters
congestion as it moves through the network.
· Preserved throughout the ATM network.
When a customer transmits IP packets Irom one site to another, the IP precedence Iield (the
Iirst 3 bits oI the DSCP Iield in the header oI an IP packet) speciIies the CoS. Based on the IP
precedence marking, the packet is given the desired treatment, such as guaranteed bandwidth or
latency. II the service provider network is an MPLS network, then the IP precedence bits are
copied into the MPLS experimental Iield at the edge oI the network. However, the service
provider might want to set an MPLS packet QoS to a diIIerent value that is determined by the
service oIIering.
The MPLS experimental Iield allows the service provider to provide QoS without overwriting
the value in the customer IP precedence Iield. The IP header remains available Ior customer
use; the IP packet marking is not changed as the packet travels through the MPLS network.
MPLS ExperimentaI Bits
· MPLS uses a 32-bit IabeI fieId (shim header)
which is inserted between Layer 2 and
Layer 3 headers (frame mode).
· Supports up to 8 cIasses of service.
· The IP precedence/DSCP fieId is not directIy
visibIe to MPLS IabeI switch routers.
· By defauIt, Cisco IOS software copies the
three most significant bits of the DSCP or the
IP precedence of the IP packet to the EXP
fieId.
· Preserved throughout the MPLS network.
CIassification and Marking at the Network Layer
This topic describes the diIIerent classiIication and marking options that are available at the
network layer.
At the network layer, IP packets are typically classiIied based on source or destination IP
address, packet length, or the contents oI the ToS byte. Link layer media oIten changes as a
packet travels Irom its source to its destination. Because a CoS Iield does not exist in a standard
Ethernet Irame, CoS markings at the link layer are not preserved as packets traverse the
network. Using marking at the network layer provides a more permanent marker that is
preserved Irom source to destination. The network layer markers most typically used are IP
precedence and DSCP.
The header oI an IPv4 packet contains the ToS byte. IP precedence uses three precedence bits
in the ToS Iield oI the IPv4 header to speciIy CoS Ior each packet. IP precedence values range
Irom 0 to 7 and allow network administrators to partition traIIic in up to six useable classes oI
service. (Settings 6 and 7 are reserved Ior internal network use.)
DiIIerentiated Services (DiIIServ) is a new model that supersedesand is backward
compatible withIP precedence. DiIIServ redeIines the ToS byte and uses six prioritization
bits that permits classiIication oI up to 64 values (0 to 63) oI which 32 are commonly used. A
DiIIServ value is called a DSCP.
With DiIIServ, packet classiIication is used to partition network traIIic into multiple priority
levels or classes oI service. Packet classiIication uses the DSCP traIIic descriptor to categorize
a packet within a speciIic group to deIine that packet. AIter the packet has been deIined
(classiIied), the packet is then accessible Ior QoS handling on the network.
CIassification and Marking at the Network Layer
IP Precedence and DSCP
· IP Precedence: Three most significant bits of ToS byte are
caIIed IP precedence-other bits unused.
· DiffServ: Six most significant bits of ToS byte are caIIed
DSCP-remaining two bits used for fIow controI.
· DSCP is backward compatibIe with IP precedence.
Mapping CoS to Network Layer QoS
This topic describes the diIIerent QoS markers that can be used Ior interoperability between
data link layer and network layer QoS.
IP headers are preserved end-to-end when IP packets are transported across a network; data link
layer headers are not. This means that the IP layer is the most logical place to mark packets Ior
end-to-end QoS. However, there are edge devices that can only mark Irames at the data link
layer and there are many other network devices that only operate at the data link layer. To
provide true end-to-end QoS, the ability to map QoS marking between the data link layer and
the network layer is essential.
Enterprise networks typically consist oI a number oI remote sites connected to the headquarters
campus via a WAN. Remote sites typically consist oI a switched LAN, and the headquarters
campus network is both routed and switched. Providing end-to-end QoS through such an
environment requires that CoS markings that are set at the LAN edge be mapped into QoS
markings (such as IP precedence or DSCP) Ior transit through Campus or WAN routers.
Campus and WAN routers can also map the QoS markings to new data link headers Ior transit
across the LAN. In this way, QoS can be preserved and uniIormly applied across the enterprise.
Service providers oIIering IP services have a requirement to provide robust QoS solutions to
their customers. The ability to map network layer QoS to link layer CoS allows these providers
to oIIer a complete end-to-end QoS solution that does not depend on any speciIic link layer
technology.
Compatibility between an MPLS transport and network layer QoS is also achieved by mapping
between MPLS experimental (EXP) bits and the IP precedence or DSCP bits. A service
provider can map the customer network layer QoS marking as-is, or change them to Iit an
agreed upon service level agreement (SLA). The inIormation in the MPLS EXP bits can be
Mapping CoS to Network Layer QoS
carried end-to-end in the MPLS network, independent oI the transport media. In addition, the
network layer marking can remain unchanged so that when the packet leaves the service
provider MPLS network, the original QoS markings remain intact. Thus, a service provider
with an MPLS network can help provide a true end-to-end QoS solution.
QoS Service CIass Defined
This topic deIines the term, 'QoS service class¨ and describes how service classes can be used
to create a service policy throughout a network.
When an administrative policy requiring QoS is created, it must be determined how network
traIIic is to be treated. As part oI that policy deIinition, network traIIic must be associated with
a speciIic service class. QoS classiIication mechanisms are used to separate traIIic and identiIy
packets as belonging to a speciIic service class. QoS marking mechanisms are used to tag each
packet as belonging to the assigned service class. AIter the packets are identiIied as belonging
to a speciIic service class, QoS mechanisms such as policing, shaping, queuing techniques can
be applied to each service class to meet the speciIications oI the administrative policy. Packets
belonging to the same service class are given the same treatment with regards to QoS.
A QoS service class, being a logical grouping, can be deIined in many ways, some oI which
include:
Organization or department (Marketing, Engineering, Sales, and so on)
A speciIic customer or set oI customers
SpeciIic applications or set oI applications (Telnet, FTP, Voice, SAP, Oracle, Video, and
so on)
SpeciIic users or sets oI users (based on MAC address, IP address, LAN port, and so on.)
SpeciIic network destinations (tunnel interIaces, Virtual Private Networks |VPNs|, and
so on)
QoS Service CIass Defined
· A QoS service cIass is a IogicaI grouping of
packets that are to receive a simiIar IeveI of
appIied quaIity.
· A QoS service cIass can be a:
÷ SingIe user: MAC address, IP address.
÷ Department, customer: Subnet, interface.
÷ AppIication: Port numbers, URL.
ExampIe: Defining QoS Service CIasses
A network administrator wishes to apply QoS to the corporate network to better control
bandwidth allocation oI diIIerent network applications. BeIore QoS can be applied, an
administrative QoS policy is Iirst devised as Iollows:
Voice traIIic is to be given a strict priority over all other traIIic types.
Business applications (FTP, TN3270, and Oracle) should be given priority over web traIIic
and have a guaranteed bandwidth oI 20 percent.
Web traIIic should consume no more than 30 percent oI any WAN link.
As a result oI this policy, three QoS service classes have been deIined:
Voice class: To be treated with a strict priority service.
Business applications class: Requires a guaranteed bandwidth oI 20 percent and is to be
given priority over web traIIic.
Web class: Only allowed to consume up to 30 percent oI any WAN link.
ImpIementing a QoS PoIicy Using a QoS Service
CIass
This topic describes how link layer and network layer markers are used to deIine QoS service
classes and the diIIerent applications that can be represented by each oI these service classes.
SpeciIying an administrative policy Ior QoS requires that a speciIic set oI service classes be
deIined. QoS mechanisms are uniIormly applied to these individual service classes to meet the
requirements oI the administrative policy. Because the application oI QoS mechanisms is
applied to diIIerent service classes and used to diIIerentiate between applications, users, and
traIIic, the service class is a key component oI a successIul QoS implementation.
There are many diIIerent methods in which service classes can be used to implement an
administrative policy. The Iirst step is to identiIy the traIIic that exists in the network and the
QoS requirements Ior each traIIic type. Then, traIIic can be grouped into a set oI service classes
Ior diIIerentiated QoS treatment in the network.
One popular model Ior the application oI QoS service classes is the customer model which is
typically used by service providers when reIerring to customer traIIic. The customer model
deIines the Iollowing service classes (although many variations exist):
Voice service class: Delivers low latency Ior voice services.
Mission-critical service class: Guarantees latency and delivery Ior the transport oI
mission-critical business applications like SNA.
Transactional service class: Guarantees delivery and is used Ior more general applications
that are not as sensitive to delay, like e-commerce.
Best-effort service class: Used to support small business and e-mail and other best-eIIort
applications.
How can a QoS service cIass be used
to impIement a QoS PoIicy?
Provisioning for Data:
GeneraI PrincipIes
· ProfiIe appIications to their basic network requirements.
· Do not over-engineer provisioning. Use no more than 4 to
5 traffic cIasses for data traffic:
÷ Mission-CriticaI: LocaIIy defined criticaI appIications
÷ TransactionaI: ERP, SAP, OracIe
÷ Best-Effort: E-maiI, unspecified
÷ Less-than-best-effort (Scavenger): Point-to-point appIications
· Do not assign more than 3 appIications to Mission-
CriticaI or TransactionaI cIasses.
· Use proactive poIicies before reactive (poIicing) poIicies.
· Seek executive endorsement of reIative ranking of
appIication priority prior to roIIing out QoS poIicies for
data.
One key element oI deIining QoS service classes is to understand the basic quality needs oI
network applications. It is essential that applications be given QoS treatment inline with their
needs. For example, improperly speciIying voice traIIic into a service class with guaranteed
bandwidthwithout a guaranteed latency (delay)would not meet the needs oI the voice
traIIic.
While it is important to Iully understand network application requirements, it is equally
important not to over-provision or over design the administrative policy. An administrative
policy should be proactive in nature and require as Iew service classes as possible. One good
rule is to limit the number oI service classes to no more than Iour or Iive. A typical network has
the Iollowing application types:
Mission critical applicationsOracle, SAP, SNA
Interactive applicationsTelnet, TN3270
Bulk applicationsFTP, TFTP, database synchronization/backup
Best-eIIort applicationse-mails, Web
Scavenger applicationsNaspter, Kazaa
The QoS requirements oI these applications can be met with a Iew well-designed service
classes. The more service classes implemented in support oI an administrative QoS policy, the
more complex the QoS implementation will be. This complexity also extends to support and
troubleshooting as well.
It is also important that the highest-priority classes be reserved Ior a select Iew number oI
applications. Marking 90 percent oI network traIIic as high priority will render most
administrative QoS policies useless.
Although there are several sources oI inIormation that can be used as guidelines Ior
determining a QoS policy, none oI them can determine exactly what is proper Ior a speciIic
network. Each network presents its own unique challenges and administrative policies. To
properly implement QoS, measurable goals must be declared. Then a plan Ior achieving these
goals must be Iormulated and implemented.
QoS must be implemented consistently across the entire network. It is not so important whether
call signaling is marked as DSCP 34 or 26, but rather that DSCP 34 is treated in a manner that
is necessary to accomplish the QoS policy. It is also important that data marked DSCP 34 is
treated consistently across the network. II data travels over even a small portion oI a network
where diIIerent policies are applied (or no policies are applied), the entire QoS policy is
nulliIied. Whether the data is crossing slow WAN links or gigabit Ethernet, whether it is being
switched by a Layer 2 switch or routed in a Layer 3 router, the policies must be implemented in
a way that causes a consistent eIIect that satisIies the policy requirements.
ExampIe AppIication Service CIasses
Trust Boundaries
This topic describes the concept oI trust boundaries and how they are used with classiIication
and marking.
The concept oI trust is important and integral to deploying QoS. AIter the end devices have set
CoS or ToS values, the switch has the option oI trusting them. II the switch trusts the values, it
does not need to reclassiIy; iI it does not trust the values, then it must perIorm reclassiIication
Ior the appropriate QoS.
The notion oI trusting or not trusting Iorms the basis Ior the trust boundary. Ideally,
classiIication should be done as close to the source as possible. II the end device is capable oI
perIorming this Iunction, the trust boundary Ior the network is at the end device. II the device is
not capable oI perIorming this Iunction, or the wiring closet switch does not trust the
classiIication done by the end device, the trust boundary might shiIt. How this shiIt happens
depends on the capabilities oI the switch in the wiring closet. II the switch can reclassiIy the
packets, the trust boundary is in the wiring closet. II the switch cannot perIorm this Iunction,
the task Ialls to other devices in the network, going toward the backbone. In this case, one good
rule is to perIorm reclassiIication at the distribution layer. This means that the trust boundary
has shiIted to the distribution layer. It is likely that there is a high-end switch in the distribution
layer with Ieatures to support this Iunction. II possible, try to avoid perIorming this Iunction in
the core oI the network.
Trust Boundaries
CIassify Where?
· Cisco QoS modeI assumes that the CoS carried in a frame may
or may not be trusted by the network device.
· For scaIabiIity, cIassification shouId be done as cIose to the
edge as possibIe.
· End hosts can mostIy not be trusted to tag a packet priority
correctIy.
· The outermost trusted devices represent the trust boundary.
· 1 and 2 are optimaI, 3 is acceptabIe (if access switch
cannot perform cIassification).
1 2 3
ClassiIication should take place at the network edge, typically in the wiring closet or within
endpoints (servers, hosts, video endpoints, or IP telephony devices) themselves.
For example, consider the campus network containing IP telephony and host endpoints. Frames
can be marked as important by using link layer CoS settings or the IP precedence/DSCP bits in
the ToS/DS Iield in the IPv4 header. Cisco IP Phones can mark voice packets as high priority
using CoS as well as ToS. By deIault, the IP Phone sends 802.1p tagged packets with the CoS
and ToS set to a value oI 5 Ior its voice packets. Because most PCs do not have an 802.1Q
capable network interIace card (NIC), they send packets untagged. This means that the Irames
do not have an 802.1p Iield. Also, unless the applications running on the PC send packets with
a speciIic CoS value, this Iield is zero.
Note: A special case exists where the TCP/ÌP stack in the PC has been modified to send all
packets with a ToS value other than zero. Typically this does not happen, and the ToS value
is zero.
Even iI the PC is sending tagged Irames with a speciIic CoS value, Cisco IP Phones can zero
out this value beIore sending the Irames to the switch. This is the deIault behavior. Voice
Irames coming Irom the IP Phone have a CoS oI 5 and data Irames coming Irom the PC have a
CoS oI 0.
II the end device is not a trusted device, the reclassiIication Iunction (setting/zeroing the bits in
the CoS and ToS Iields) can be perIormed by the access layer switch iI that device is capable oI
doing so. II the device is not capable, then the reclassiIication task Ialls to the distribution layer
device. II reclassiIication cannot be perIormed at one oI these two layers, a hardware and/or
Cisco IOS soItware upgrade may be necessary.
Trust Boundaries
Mark Where?
· For scaIabiIity, marking shouId be done as cIose to the
source as possibIe.
Summary
References
For an overview oI classiIication, reIer to 'ClassiIication Overview¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios122/122cgcr/Iqos¸c/Iqcprt1/
qcIclass.htm#wp1000872
For additional inIormation on 802.1p/Q marking, reIer to 'Bridging Between IEEE 802.1Q
VLANs¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios121/121newIt/121t/121t3/dtb
ridge.htm#xtocid114535
For additional inIormation on ISL marking, reIer to 'ConIiguring Routing between VLANs
with ISL Encapsulation¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios113ed/113ed¸cr/switch¸c/xc
isl.htm
For additional inIormation on ISL marking, reIer to 'ConIiguring QoS: Understanding
How QoS Works¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw¸5¸5/cnIg¸gd/qos.htm
For additional inIormation on DiIIServ, reIer to 'DiIIServThe Scalable End-to-End QoS
Model¨ at the Iollowing URL:
http://www.cisco.com/warp/public/cc/pd/iosw/ioIt/ioIwIt/prodlit/diIse¸wp.htm
Summary
· CIassification is a QoS mechanism responsibIe for
distinguishing between different traffic streams.
· Marking is a QoS mechanism that "coIors" a packet so it
can be distinguished from other packets during the
appIication of QoS.
· Packets can be cIassified and marked using many
different mechanisms incIuding: 802.1Q, ISL, IP
precedence, DSCP, MPLS experimentaI bits, the Frame
ReIay DE bit, and the ATM CLP bit.
· A QoS service cIass is a IogicaI grouping of packets that,
as specified in an administrative poIicy, are to receive a
simiIar IeveI of appIied quaIity.
· It is important that a trust boundary be specified aIIowing
cIassification and marking as cIose to the source as
possibIe.
Quiz
Q1) What is the main purpose oI the QoS classiIication mechanism?
A) to set Iields in IP packets and identiIy that packet as belonging to a speciIic
class oI service
B) to signal network devices on which QoS mechanism should be employed to
meet the requirements oI a particular service class
C) to identiIy traIIic as belonging to a speciIic class oI service
D) to provide a mapping between link layer and network layer QoS
Q2) What are two main purposes oI the QoS marking mechanism? (Choose two.)
A) to sort traIIic into diIIerent service classes Ior QoS treatment
B) to signal network devices on which QoS mechanism should be employed to
meet the requirements oI a particular service class
C) to set Iields in IP packets and identiIy that packet as belonging to a speciIic
class oI service
D) to allow edge devices to select the QoS level on an application-by-application
basis
Q3) What are three QoS markers commonly used at the link layer? (Choose three.)
A) ISL
B) DSCP
C) 802.1p
D) IP precedence
E) Frame Relay DE bits
Q4) What are two QoS markers commonly used at the network layer? (Choose two.)
A) ISL
B) DSCP
C) MPLS experimental bits
D) IP precedence
Q5) When 802.1p CoS marking is used, what ensures end-to-end QoS? (Choose two.)
A) classiIication should be done as close to the edge as possible
B) the 802.1Q header travels with the packet Irom the source to the destination
C) core devices must be capable oI perIorming the marking and policing Iunctions
D) using marking at the network layer provides a more permanent marker that is
preserved Irom source to destination
Q6) What is a QoS service class?
A) an applied per-hop behavior
B) a logical grouping oI packets that are to receive similar QoS treatment
C) a mechanism Ior changing packet markings Ior trusted and non-trusted packets
D) a method oI providing a mapping between link layer and network layer QoS
Q7) In which two scenarios would it be acceptable to place the trust boundary at the
distribution layer? (Choose two.)
A) when the access layer device is not capable oI perIorming this Iunction
B) when the wiring closet switch does not trust the classiIication done by the end
device
C) when the application in use is not oI high importance and thereIore marking is
not required
D) when the network is very large and there are too many access layer switches to
properly conIigure the marking capabilities
Quiz Answer Key
Q1) C
ReIates to: Classification
Q2) B, C
ReIates to: Marking
Q3) A, C, E
ReIates to: Classification and Marking at the Link Layer
Q4) B, D
ReIates to: Classification and Marking at the Network Layer
Q5) A, D
ReIates to: Mapping CoS to Network Layer QoS
Q6) B
ReIates to: QoS Service Class Defined
Q7) A, B
ReIates to: Trust Boundaries
Case Study: Classification and
Marking
Overview
requirements oI a large, multisite network. Your task is to work with a partner to evaluate the
QoS requirements, and based on these requirements, identiIy where QoS classiIication and
marking mechanisms should be applied. You will discuss your solution with the instructor and
other classmates, and the instructor will present a solution Ior the case study to the class.
ReIevance
The ability to properly sort traIIic into service classes is an important step in correctly
implementing an administrative QoS policy.
Objectives
In this activity, you will deIine a QoS policy that assigns network traIIic to service classes and
identiIy where classiIication and marking should be applied to the network. Upon completing
this case study, you will be able to meet these objectives:
IdentiIy QoS service class requirements
IdentiIy network locations where classiIication and marking should be applied
OutIine
Required Resources
Case Study Activity: ClassiIication and Marking with QoS Service Classes
Job Aids
Case Study Tasks
Step 1 Review customer QoS requirements: Completely read the customer requirements
provided.
Step 2 Identify QoS service class requirements: With the aid oI your partner, identiIy the
Step 3 Identify network locations where classification and marking should be applied:
IdentiIy locations in the network where the QoS classiIication and marking
mechanisms should be applied to properly implement the administrative QoS policy.
Step 4 Present your solution: AIter the instructor presents a solution to the case study,
OutIine
· Overview
· Identify Network Locations Where CIassification
and Marking ShouId be AppIied
instructor.
This case study involves analyzing an administrative QoS policy oI the JC Whitney
Corporation, a Iictitious manuIacturer oI medical equipment. The company has provided you
with a brieI description oI their requirements. It is your task to provide the network engineers
Irom JC Whitney a QoS solution to meet their requirements.
Read the customer requirements and discuss them with your partner. IdentiIy the diIIerent types
oI traIIic in use in the JC Whitney network and the diIIerent service classes required to
implement their administrative QoS policy.
Company Background
JC Whitney Corporation is a leading manuIacturer oI medical equipment used in outpatient
surgical centers throughout the United States. The company headquarters are located in
Eugene, Oregon. The JC Whitney corporate network is shown in the Iigure.
In addition to the headquarters Iacility, JC Whitney consists oI 5 manuIacturing Iacilities and
120 regional sales and distribution centers. The network at each oI the manuIacturing Iacilities
is similar to the JC Whitney corporate network. The regional sales and distribution centers are
very low-cost, low-overhead sites.
JC Whitney Corporate Network
The regional sales and distribution center networks are shown in the Iigure.
The manuIacturing strategy oI JC Whitney is to leverage the expertise oI contract
manuIacturers through its extensive extranet oI partners. Currently, the JC Whitney extranet
consists oI nine contract manuIacturers and suppliers that are all connected using a national
service provider backbone.
JC Whitney RegionaI SaIes Office Network
The provider currently utilizes MPLS on its backbone as shown in the Iigure.
JC Whitney Extranet Network
Customer Situation
JC Whitney has recently opened up Internet access to its regional manuIacturing Iacilities and
to its regional sales and distribution centers. As a result, access times to many oI the company
mission-critical applications such as sales and manuIacturing databases have increased
dramatically. In addition, response time between the corporate headquarters and JC Whitney
extranet partners has increased, causing database queries to time out in some instances. No new
applications have been added to the network other than enabling corporate-wide Internet
access.
The JC Whitney network engineering staII explains their network applications in the Iollowing
manner:
JC Whitney has standardized on Open Shortest Path First (OSPF) as its routing protocol
and thereIore uses it on all oI its routers company wide.
The corporate headquarters and the Iive manuIacturing Iacilities use VoIP Ior all intra-site
and inter-site communications.
The entire enterprise resource planning (ERP) database Ior the company is located at the
corporate site. All sites (manuIacturing, regional sales and distribution centers, extranet
partners), use this centralized database Ior inventory control, sales data, invoicing, etc.
Without complete access and reachability to the ERP database and its applications, JC
Whitney could not manuIacture product, ship inventory, or bill Ior its services.
E-mail is another application that is used heavily at JC Whitney. The exchange servers and
mail gateways are all located in the server Iarm at the corporate headquarters location.
Internet services have recently been introduced company wide. One oI its largest uses has
been messaging between regional sales and distribution centers and between corporate staII
and manuIacturing. No internal messaging service currently exists at JC Whitney. As a
result, the productivity gains realized by this Internet service have become somewhat
important to the company. No other business applications currently exist on the Internet.
Although the JC Whitney manuIacturing Iacilities operate 24/7, the evening shiIts have a
reduced staII and line output. As a result, database synchronization and server backups are
perIormed during the evening hours. A TCP-based backup application manages Iile
transIers between manuIacturing sites and the corporate headquarters using an automated
version oI FTP. Database synchronization is also TCP-based and has no critical bandwidth
or latency requirements.
Working with the network engineering staII at JC Whitney and the service provider, you have
been enlisted to assist JC Whitney by deIining QoS requirements Ior their network. Their Iirst
priority is to determine what service classes to use and to identiIy where QoS classiIication and
marking mechanisms should be conIigured in the network to enable JC Whitney administrative
QoS policy, resolving the response time issues they are experiencing.
IdentiIy the diIIerent service classes required to implement the JC Whitney administrative QoS
policy. Use the QoS Service Classes table to help you with your answer choices. Write your
answers in the table below.
JC Whitney Service CIasses
Customer Traffic Service CIass
QoS Service CIasses
PHB DSCP DSCP
VaIue
Intended
ProtocoIs and
AppIications
Service
CIass
Service CIass and
Configuration
EF EF 101110 Ìnteractive Voice Voice Bearer Admission Control = RSVP
Queuing = Priority
AF1 AF11
AF12
AF13
001010
001100
001110
Ìntranet, General Data
Service
Bulk Data Queuing = Rate Based
Active Queue Mgt = WRED
minth AF13 < maxth AF13 <=
minth AF11 < maxth AF11
AF2 AF21
AF22
AF23
010010
010100
010110
Database access,
transaction services,
interactive traffic,
preferred data service
Transactional Queuing = Rate Based
AF3 AF31
AF32
AF33
011010
011100
011110
Locally defined
mission-critical
applications
Mission-
Critical
Queuing = Rate Based
AF4 AF41
AF42
AF43
100010
100100
100110
Ìnteractive video and
associated voice
Ìnteractive
Video
Admission Control = RSVP
CS6 Class 6 110000 BGP, OSPF, etc Routing
(Reserved)
Small guaranteed minimum rate
Active Queue Mgt = RED
minth < maxth, but minth is
deep to minimize loss
CS4 Class 4 100000 Often proprietary Streaming
Video
minth < maxth
PHB DSCP DSCP
VaIue
Intended
ProtocoIs and
AppIications
Service
CIass
Service CIass and
Configuration
CS3 Class 3 011000 SÌP, H.323, etc. Voice
Signaling
minth < maxth, but minth is deep
to minimize loss
CS1 Class 1 001000 User-selected service,
Point-to-Point
Applications
Less-than-
Best Effort
Data
(Scavenger)
No bandwidth guarantee
minth < maxth
DefauIt Default
(Best-
Effort)
Class 0
000000 Unspecified traffic,
Email
Best-Effort Queuing = Rate Based
Minimal bandwidth guarantee
Active Queue Mgt or Per-flow
fair queuing
minth < maxth
In order to provide end-to-end QoS, multiple markers may be required. For each service class
required Ior the JC Whitney network, complete the table below with the appropriate value oI
each speciIied marker.
JC Whitney QoS Service CIass Requirements
L 3 CIassification L 2 CIassification
Service CIass
DSCP PHB DSCP IP Precedence CoS MPLS EXP

Identify Network Locations Where CIassification
and Marking ShouId be AppIied
Using the inIormation provided in the review oI customer QoS requirements Ior this case study,
use the diagrams oI the JC Whitney network below to indicate trust boundaries, where
classiIication and marking should be applied, markers in use, and locations where QoS markers
change to ensure end-to-end QoS. Below is a sample network showing trust boundaries, where
classiIication and marking should be applied, and markers in use. Use this sample to assist you
in completing this activity. When completing this activity, indicate the Iollowing on each
network diagram provided:
Trust boundaries
QoS markers in use
Network locations where classiIication and marking should be used
Locations where QoS markers change
SampIe network iIIustration of what shouId be marked for this section of the case study.
ExampIe Network
JC Whitney Corporate Headquarters Network
The JC Whitney network consists oI a converged voice and data network. Because voice is a
business-critical application, all voice traIIic should be treated appropriately. The user
community at JC Whitney ranges Irom novice data-entry clerks, to advanced systems
programmers. As a result, security measures require that user workstations should  be
allowed to set packet priorities.
Use the network diagram oI the JC Whitney corporate network below to indicate the Iollowing:
Trust boundaries
QoS markers in use
JC Whitney RegionaI SaIes and Distribution Center Networks
The JC Whitney regional sales and distribution center networks are very low-overhead
operations. Each sales oIIice is staIIed with three to nine employees. Distribution centers are
similar to sales oIIices, but can be supported by up to 20 employees. The network at each center
consists oI a basic 10/100 Mbps desktop switch that is used to connect the oIIice workstations
to the corporate headquarters or a regional manuIacturing Iacility via a Frame Relay connected
low-end router.
Use the network diagram oI the JC Whitney corporate network below to indicate the Iollowing:
Trust boundaries
QoS markers in use
inIormation:
Network diagrams indicating where classiIication and marking should be applied
JC Whitney Service CIasses
Customer Traffic Service CIass
OSPF Routing Protocol Reserved
Voice over ÌP Voice Bearer
Voice Signaling (Skinny, SÌP, etc.) Voice Signaling
ERP (Transactional Database) Transactional Data
E-mail Best-Effort Data
Ìnternet (Browsing, Messaging) Bulk Data
Backup, Synch (FTP Bulk transfer) Bulk Data
JC Whitney QoS Service CIass Requirements
L 3 CIassification L 2 CIassification
Service CIass
DSCP PHB DSCP IP Precedence CoS MPLS EXP
Reserved CS 6 48 (110 000) 6 6 6
Voice Bearer EF 46 (101 110) 5 5 5
Voice Signaling AF31 26 (011 010) 3 3 3
Transactional Data AF21 18 (010 010) 2 2 2
Bulk Data AF11 10 (001 010) 1 1 1
Best-Effort Data Default 0 (000 000) 0 0 0
Identify Network Locations Where CIassification and Marking ShouId be AppIied
JC Whitney Corporate Headquarters Network
JC Whitney RegionaI SaIes and Distribution Center Networks
Case Study ResuIts:
Case Study ResuIts:
Using MQC for Classification
Overview
The application oI QoS requires that traIIic be separated into service classes upon which
diIIerentiated levels oI service are applied. Separation oI traIIic into diIIerent service classes
requires QoS classiIication mechanisms. The MQC is one such mechanism Ior classiIying
network traIIic.
This lesson describes the packet classiIication Ieatures oI the MQC including input interIace,
access control lists (ACLs), CoS, IP precedence, and DSCP. This lesson also describes how
MQC class maps can be conIigured to classiIy network traIIic.
ReIevance
ClassiIication is a Iundamental requirement Ior any network deployment oI QoS. As such, it is
oI key importance to understand what traIIic can be classiIied, how diIIerent classiIication
mechanisms Iunction, and how classiIication mechanisms are conIigured on Cisco IOS devices
when implementing QoS.
Objectives
Upon completing this lesson, you will be able to use MQC CLI commands to classiIy packets.
This includes being able to meet these objectives:
Describe the diIIerent IP packet classiIication options in the MQC
IdentiIy the Cisco IOS commands used to conIigure classiIication oI packets with MQC
IdentiIy the Cisco IOS commands required to classiIy IP packets using input interIace with
MQC
IdentiIy the Cisco IOS commands required to classiIy IP packets using CoS with MQC
IdentiIy the Cisco IOS commands required to classiIy IP packets using access lists with
MQC
IdentiIy the Cisco IOS commands required to classiIy IP packets using IP precedence with
MQC
IdentiIy the Cisco IOS commands required to classiIy IP packets using DSCP with MQC
IdentiIy the Cisco IOS commands required to classiIy IP packets using RTP (UDP port
range) with MQC
IdentiIy the Cisco IOS commands used to monitor classiIication with MQC
Basic knowledge oI the Cisco IOS command-line interIace
OutIine
OutIine
· Overview
· MQC CIassification Options
· Configuring CIassification with MQC
· Configuring CIassification Using Input Interface
· Configuring CIassification Using CoS
· Configuring CIassification Using Access Lists
· Configuring CIassification Using IP Precedence
· Configuring CIassification Using DSCP
· Configuring CIassification Using a UDP Port Range
· Monitoring CIass Maps
· Summary
· Quiz
MQC CIassification Options
This topic describes the diIIerent IP packet classiIication options available in MQC.
ClassiIication using MQC is accomplished by speciIying a traIIic match criteria within a
conIigured class map Ior each diIIerent service class. In order Ior QoS mechanisms to utilize
the class map, it must be reIerenced through the use oI a policy map, which is subsequently
applied to an inbound our outbound interIace as a service policy.
In older Cisco IOS soItware releases, the router classiIied a packet against every individual
QoS Ieature. This resulted in additional processing overhead, inaccurate packet counters, and
double accounting issues. Common classiIication is a Ieature that was introduced in Cisco IOS
12.2, and is enabled by deIault whenever classiIication is invoked within a policy map. With
common classiIication, a packet is classiIied only once per service policy and matches a single
class in the policy. Because matching terminates at the Iirst matching class it is important to
ensure that the classes are conIigured in the right sequence within a policy. AIter a packet is
classiIied against a particular class, it is subjected to all the QoS Ieatures conIigured within that
class.
MQC classiIication with class maps is extremely Ilexible and can classiIy packets by using the
Iollowing classiIication tools:
Access list: Access lists Ior any protocol can be used within the class map conIiguration
mode. The MQC can be used Ior other protocols, not only IP.
IP precedence: IP packets can be classiIied directly by speciIying IP precedence values.
DSCP: IP packets can be classiIied directly by speciIying IP DSCP values. DiIIServ
enabled networks can have up to 64 classes iI DSCP is used to mark packets.
MQC CIassification Options
· CIassification options configured in a cIass map
· Requires a referring poIicy map to be usefuI
· MQC cIassification options incIude the
foIIowing:
· IEEE 802.1Q/ISL CoS/Priority
vaIues
· Input interface
· Source MAC address
· Destination MAC address
· RTP (UDP) port range
· Any packet
· Access Iist
· IP precedence vaIue
· IP DSCP vaIue
· QoS group number
· MPLS experimentaI bits
· ProtocoI (incIuding NBAR)
· Using another cIass map
· Frame ReIay DE bit
QoS group: A QoS group parameter can be used to classiIy packets in situations where up
to 100 classes are needed or the QoS group parameter is used as an intermediary marker;
Ior example, MPLS to QoS group translation on input and QoS group to DSCP translation
on output. QoS group markings are local to a single router.
MPLS experimental bits: Packets can be matched based on the value in the experimental
bits oI the MPLS header oI labeled packets.
Protocol: ClassiIication is possible by identiIying Layer 3 or Layer 4 protocols. Advanced
classiIication is also available by using the NBAR tool where dynamic protocols are
identiIied by inspecting higher-layer inIormation.
Class map hierarchy: Another class map can be used to implement template-based
conIigurations.
Frame Relay DE bit: Packets can be matched based on the value oI the underlying Frame
Relay DE bit.
CoS: Packets can be matched based on the inIormation contained in the three CoS bits
(when using IEEE 802.1Q encapsulation) or priority bits (when using the ISL
encapsulation).
Input interface: Packets can be classiIied based on the interIace Irom which they enter the
Cisco IOS device.
MAC address: Packets can be matched based on their source or destination MAC
addresses.
User Datagram Protocol (UDP) port range: Real-Time Transport Protocol (RTP)
packets can be matched based on a range oI UDP port numbers.
All packets: MQC can also be used to implement a QoS mechanism Ior all traIIic in which
case classiIication will put all packets into one class.
Configuring CIassification with MQC
This topic identiIies the Cisco IOS commands used to conIigure classiIication oI packets with
MQC.
The class-map global conIiguration command is used to create a class map and enter the class
map conIiguration mode. A class map is identiIied by a case-sensitive name; thereIore, all
subsequent reIerences to the class map must use exactly the same name.
The match command is used to speciIy the classiIication criteria when in class map
conIiguration mode. Multiple match commands can be used within a class map. At least one
match command should be used within the class map conIiguration mode. (Match none is the
deIault.)
Configuring CIassification with MQC
class~map (match~any | match~all) class~map~name class~map (match~any | match~all) class~map~name
router(config)#
· Enters the cIass map configuration mode.
· Names can be a maximum of 40 aIphanumeric characters.
· Match aII is the defauIt matching strategy.
match condition match condition
· Use at Ieast one condition to match packets.
match class~map class~map match class~map class~map
· One cIass map can use another cIass map for cIassification.
· Nested cIass maps aIIow generic tempIate cIass maps to be
used in other cIass maps.
It is also possible to nest class maps in MQC conIigurations. Nesting class maps is
accomplished using the match class-map command within the class map conIiguration. By
nesting class maps, the creation oI generic classiIication templates and more sophisticated
classiIication are possible.
class-map ¡match-any [ match-all] class-map-name
Syntax Description
classmapname Name of the class for the class map. The class name is used for
both the class map and to configure policy for the class in the
policy map.
match~all | match~any Name of the class for the class map. The name can be a
maximum of 40 alphanumeric characters. The class name is
used for both the class map and to configure policy for the class
in the policy map.
There are some additional options that give extra power to class maps:
Any condition can be negated by inserting the keyword 'not¨.
A class map can use another class map to match packets.
The any keyword can be used to match all packets.
The example shows three class maps:
Class map Well-known-services uses an access list to match all the packets with the source
or destination port number lower than 1024.
Class map Unknown-services uses the Iirst class map but negates the result. The same
could be achieved by using the same access list with a negation.
Class map All-services actually matches all the packets.
match not match-criteria.
Syntax Description
matchcriteria (Required) Specifies the match criterion value that is an
unsuccessful match criterion. All other values of the specified
match criterion will be considered successful match criteria.
Configuring CIassification
with MQC (Cont.)
match not match~criteria match not match~criteria
· The "not" keyword inverts the condition.
match any match any
· The "any" keyword can be used to match aII packets.
class~map Well~known~services
!
Class~map Unknown~services
match not class~map Well~known~services
!
Class~map All~services
match any
!
access~list 100 permit tcp any any lt 1024
access~list 100 permit tcp any lt 1024 any
Configuring CIassification Using Input Interface
This topic identiIies the Cisco IOS commands that are required to classiIy IP packets using
input interIace with MQC.
As shown in the example, a packet can also be classiIied based on the input interIace. In the
Iirst class map example, called Ethernets, the match input-interface will match any packet that
arrives on either the E0/0 or E0/1 interIaces.
In the second class map, FastEthernets, any packet arriving on either the FastEthernet 1/0 or
FastEthernet 1/1 interIace will be matched.
And in the last class map example, Serials, incoming packets arriving on any oI S2/0, S2/1,
S2/2 or S2/3 will be matched.
match input-interface interface-name
Syntax Description
interfacename Name of the input interface to be used as match criteria.
Input Interface
match input~interface interface~name match input~interface interface~name
class~map match~any Fthernets
match input~interface Fthernet0/0
match input~interface Fthernet0/1
!
class~map match~any FastFthernets
match input~interface FastFthernet1/0
match input~interface FastFthernet1/1
!
class~map match~any Serials
match input~interface Serial2/0
· AII packets received through the seIected input interface are
matched by this cIass map.
Configuring CIassification Using CoS
This topic identiIies the Cisco IOS commands that are required to classiIy IP packets using CoS
with MQC.
Routers can also match on the three CoS bits in 802.1Q headers or priority bits in the ISL
header. These bits can be used in a LAN-switched environment to provide diIIerentiated quality
oI service.
This is demonstrated in the example. In the Iirst class map, Strict-priority, packets will be
matched iI they have a CoS value oI 5.
In the second class map example High-priority, packets will be matched iI they have a CoS
value oI either 4, 6, or 7.
And in the last class map example Low-priority, packets will be matched iI they have a CoS
value oI any oI 0, 1, 2, or 3.
match cos cos-value ¡cos-value cos-value cos-value]
Syntax Description
cosvalue (Optional) Specific ÌEEE 802.1Q/ÌSL CoS value. The is
from 0 to 7; up to four CoS values can be specified in one match
cos statement.
Configuring CIassification Using CoS
match cos cos~value (cos~value cos~value cos~value) match cos cos~value (cos~value cos~value cos~value)
class~map Strict~priority
match cos 5
!
class~map High~priority
match cos 4 6 7
!
class~map Low~priority
match cos 0 1 2 3
· SeIect up to four CoS/Priority vaIues.
· AIIowed vaIues are 0 to 7.
· This cIassification option can onIy be used on interfaces using
802.1Q or ISL encapsuIation.
Configuring CIassification Using Access Lists
access lists with MQC.
Access Lists
· Access Iists are the oIdest cIassification tooI
used with QoS mechanisms.
· CIass maps support aII types of access Iists
· CIass maps are muItiprotocoI.
· CIass maps can use named access Iists and
numbered access Iists (in the range from 1 to
2699) for aII protocoIs.
Access lists were originally used Ior Iiltering oI inbound or outbound packets on interIaces.
They were later reused Ior Iiltering oI routing updates and also Ior classiIication with early QoS
tools; Ior example, priority queuing (PQ) custom queuing, and traIIic shaping.
Access lists are still one oI the most powerIul classiIication tools. Class maps can use any type
oI access list (not only IP access lists).
Access lists also have a drawback. Compared to other classiIication tools they are one oI the
most CPU-intensive. For this reason access lists should not be used Ior classiIication on high-
speed links where they could severely impact perIormance oI routers. Access lists are typically
used on low-speed links at network edges where packets are classiIied and marked (Ior
example, with IP precedence). ClassiIication in the core is done based on the IP precedence
value.
Use the match access-group command to attach an access list to a class map.
The example in the Iigure shows how a numbered or named access list can be used Ior
classiIication.
In the Iirst example, class map Telnet, packets will matched according to those allowed by the
access-group 100. When exploring what will be allowed, access-list 100 will permit port 23.
In the second example, packets will be allowed iI they matched according to those allowed by
the access-list IPX¸Printers.
match access-group ¦number [ name]
Syntax Description
accessgroup A numbered ACL whose contents are used as the match criteria
against which packets are checked to determine if they belong to
this class.
name access-group-name A named ACL whose contents are used as the match criteria
against which packets are checked to determine if they belong to
this class.
Access Lists (Cont.)
match access~group ¦number | name} match access~group ¦number | name}
class~map Telnet
!
class~map IPX_Printers
match access~group IPX_Printers
!
access~list 100 permit tcp any any eq 23
access~list 100 permit tcp any eq 23 any
!
ipx access~list sap IPX_Printers
permit ~1 7
· SeIect an access Iist to be used for cIassification.
Configuring CIassification Using IP Precedence
This topic identiIies the Cisco IOS commands required to classiIy IP packets using IP
precedence with MQC.
A much Iaster method oI classiIication is by matching the IP precedence. Up to Iour IP
precedence values or names can be used to classiIy packets based on the IP precedence Iield in
the IP header.
The Iigure contains a mapping between IP precedence values and names. The running
conIiguration, however, only shows IP precedence values (not names).
match ip precedence ip-prec-value ¡ip-prec ¡ip-prec ¡ip-prec]]]
Syntax Description
ipprecedencevalue Specifies the exact value from 0 to 7 used to identify an ÌP
precedence value.
IP Precedence
match ip precedence ip~prec~value (ip~prec (ip~prec (ip~prec))) match ip precedence ip~prec~value (ip~prec (ip~prec (ip~prec)))
class~map VoIP
match ip precedence 5
!
class~map Mission~Critical
match ip precedence 3 4
!
class~map Transactional
!
class~map Best~Fffort
match ip precedence routine
· SeIect up to four IP precedence vaIues or names.
· AII packets marked with one of the seIected IP precedence
vaIues are matched by this cIass map.
Configuring CIassification Using DSCP
DSCP with MQC.
IP packets can also be classiIied based on the IP DSCP Iield. A QoS design can be based on IP
precedence marking or DSCP marking. DSCP marking can include backward compatibility
with IP precedence by using the Class Selector (CS) values (most signiIicant three bits oI the
DSCP value).
match ip dscp ip-ascp-value ¡ip-ascp-value ...]
Syntax Description
ip (Optional) Specifies that the match is for ÌPv4 packets only. Ìf not
used, the match is on both ÌPv4 and ÌPv6 packets.
dscpvalue Specifies the exact value from 0 to 63 used to identify an ÌP
DSCP value.
DSCP
match ip dscp ip~dscp~value (ip~dscp~value ...) match ip dscp ip~dscp~value (ip~dscp~value ...)
· SeIect up to eight DSCP vaIues or names.
· AII packets marked with one of the seIected DSCP vaIues are
matched by this cIass map.
A sample design that includes backward compatibility would use the Iollowing values to mark
packets belonging to class Gold, which is guaranteed Assured Forwarding (AF) per-hop
behavior (PHB):
aI11 marks low-drop packets
aI12 marks medium-drop packets
aI13 marks high-drop packets
cs4 marks low-drop packets (Ior backward compatibility with IP precedence 4)
cs3 marks high-drop packets (Ior backward compatibility with IP precedence 3)
The Iigure illustrates implementation oI a design with Iive classes:
Voice: IdentiIied by DSCP value eI, which looks like IP precedence value 5 in non-DSCP
compliant devices.
Mission-critical: IdentiIied by DSCP values aI31, aI32 and aI33. The class is also
identiIied by IP precedence 3.
Transactional: IdentiIied by DSCP values aI21, aI22 and aI23. The class is also identiIied
by IP precedence 2.
Bulk: IdentiIied by DSCP values aI11, aI12 and aI13. The class is also identiIied by IP
precedence 1.
Best-effort: IdentiIied by the deIault DSCP value that is equal to the deIault IP precedence
value (0).
From a non-DSCP compliant device the design looks slightly diIIerent:
Voice: IP precedence 5
Mission-critical: IP precedence 3
Transactional: IP precedence 2
Bulk: IP precedence 1
Best-effort: IP precedence 0
A DSCP-compliant device treats packets marked by a non-DSCP-compliant device according
to the design. A non-DSCP-compliant device does not treat packets marked by a DSCP-
compliant device correctly due to values oI drop ratings:
AF1 (001xx0) looks like IP precedence 1. ThereIore, class bulk incorrectly appears as class
mission-critical in a non-DSCP-compliant device.
DSCP (Cont.)
class~map Voice
match ip dscp ef cs5
!
class~map Mission~Critical
match ip dscp af31 af32 af33 cs3
!
class~map Transactional
!
class~map Bulk
!
class~map Best~Fffort
match ip dscp default
AF2 (010xx0) looks like IP precedence 2. ThereIore, class transactional correctly appears
as class transactional in a non-DSCP-compliant device.
AF3 (011xx0) looks like IP precedence 3. ThereIore, class mission-critical appears as class
bulk in a non-DSCP compliant device.
EF (101110) looks like IP precedence 5, which is also used Ior voice in a non-DSCP
compliant device.
As seen Irom the example it is very important to understand the impact oI DSCP on non-
DSCP-compliant devices. A DiIIServ-based QoS design should include the impact oI DSCP on
parts oI the networks where all routers are not DSCP-compliant.
The example shows that a network core, iI upgraded to support DSCP, can correctly handle
packets classiIied by edge devices that have not yet been upgraded.
Configuring CIassification Using a UDP Port
Range
RTP (UDP port range) with MQC.
IP RTP Priority was introduced to provide low-latency queuing (LLQ) in combination with
weighted Iair queuing (WFQ). The match ip rtp command can be used to match packets in the
same way as with IP RTP Priority. It should also be combined with LLQ to generate a similar
result as IP RTP Priority.
match ip rtp starting-port-number port-range
Syntax Description
startingportnumber The starting RTP port number. Values range from 2000 to 65535.
portrange The RTP port number range. Values range from 0 to 16383.
Configuring CIassification Using a
UDP Port Range
match ip rtp starting~port~number port~range match ip rtp starting~port~number port~range
class~map RTP
match ip rtp 16384 16383
· Use this command to impIement cIassification equaI to IP RTP
Priority.
· AII UDP packets with source or destination port numbers within
the specified range are matched.
· Range is between the starting-port (vaIues from 2000 to 65535)
and the sum of the starting-port and the port-range (vaIues from
0 to 16383).
· The command shouId be used in combination with cIass-based
Iow-Iatency queuing to impIement RTP Priority using MQC.
This topic identiIies the Cisco IOS commands that are used to monitor classiIication with
MQC.
The show class-map command lists all class maps with their match statements. This command
can be issued Irom the EXEC or Privileged EXEC mode.
The show class-map command with a name oI a class map displays the conIiguration oI the
selected class map.
In the Iigure, the show class map Cisco IOS command shows all the class maps that have been
conIigured and what match statements are contained in the maps.
The Iirst class map listed is the deIault class map. The deIault class map contains only a single
match statement; match-any.
The second class map listed, Well-known-services, has one match statement that will compare
packets against the conIigured access-group 100.
The third class map displayed, All-services, contains two match statements that compare
packets against two other conIigured class maps, well-known-services and unknown-services.
show class-map ¡class-map-name]
Syntax Description
class-map-name (Optional) Name of the class map.
show class~map (class~map~name) show class~map (class~map~name)
router>
router>show class~map
Class Map match~any class~default (id 0)
Match any
Class Map match~all Well~known~services (id 2)
Match access~group 100
Class Map match~any All~services (id 4)
Match class~map Well~known~services
Match class~map Unknown~services
Class Map match~all Unknown~services (id 3)
Match not class~map Well~known~services
· DispIays aII cIass maps and their matching criteria.
Summary
References
For more inIormation on classiIication using MQC, reIer to 'Cisco Modular Quality oI
Service Command Line InterIace¨ at the Iollowing URL:
http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/moqcs¸wp.pdI
For more inIormation on classiIication using MQC, reIer to ConIiguring the Modular
Quality oI Service Command-Line InterIace¨ at the Iollowing URL:
qcImcli2.pdI
Summary
· The MQC uses cIass maps to specify match criteria,
aIIowing cIassification of traffic for QoS treatment.
· MQC cIass maps are used in conjunction with MQC poIicy
maps. CIass maps add no specific vaIue without a
referring poIicy map.
· With MQC cIass maps, many cIassification options are
avaiIabIe incIuding: IP precedence, DSCP, MPLS
experimentaI bits, CoS, input interface, access Iist, and
so on.
· CIass maps can be nested to increase cIassification
fIexibiIity and configuration options.
Quiz
Q1) MQC classiIication is obtained by speciIying a traIIic match criteria within a
conIigured ¸¸¸¸¸.
A) class map
B) policy map
C) route map
D) service policy
Q2) What command within a class map is used to speciIy the classiIication criteria?
A) all
B) match
C) set
D) none oI the above
Q3) Which oI the Iollowing commands is correct and will classiIy packets based on an
interIace?
A) match interface name interface
B) match interface interface name
C) match interface name input-interface
D) match input-interface interface name
Q4) What is the maximum number oI CoS values that can be speciIied when using the
match cos cos-value?
A) 1
B) 2
C) 4
D) 8
Q5) Class maps can use which oI the Iollowing?
A) IP
B) IPX
C) named only
D) any access list
Q6) When classiIying packets using IP precedence which oI the Iollowing is correct?
A) only 1 value can be speciIied
B) up to 2 values can be speciIied
C) up to 4 values can be speciIied
D) only the IP precedence name can be used, not the numerical value
Q7) When classiIying packets using DSCP, which oI the Iollowing is correct?
A) up to 8 DSCP values can be speciIied at the same time
B) up to 8 DSCP class names can be speciIied at the same time
C) only DSCP class names, class cs1cs7 and eI, can be matched
D) packets cannot be matched based on DSCP iI packets arrive on a serial
interIace
Q8) The match ip rtp command is equal to which oI the Iollowing?
A) ip rtp priority
B) ip tcp priority
C) ip idp priority
D) none oI the above
Q9) Which oI the Cisco IOS commands is correct to display all conIigured class maps?
A) Router~show class map
B) Router~show class-map
C) router(conIig)# show class map
D) router(conIig)# show class-map
Quiz Answer Key
Q1) A
ReIates to: MQC Classification Options
Q2) B
ReIates to: Configuring Classification with MQC
Q3) D
ReIates to: Configuring Classification Using Ìnput Ìnterface
Q4) C
ReIates to: Configuring Classification Using CoS
Q5) D
ReIates to: Configuring Classification Using Access Lists
Q6) C
ReIates to: Configuring Classification Using ÌP Precedence
Q7) A
ReIates to: Configuring Classification Using DSCP
Q8) A
ReIates to: Configuring Classification Using a UDP Port Range
Q9) B
ReIates to: Monitoring Class Maps
Using MQC for Class-Based
Marking
Overview
The process oI packet classiIication can be both complex and CPU-intensive. ThereIore, it is
desirable to classiIy packets as close to the source as possibleat the edges oI the network.
PerIorming classiIication in the core is undesirable because it would necessarily add delay in
transiting the core. To provide diIIerential levels oI treatment to service classes, traIIic must be
identiIied as 'belonging¨ to a speciIic class. Instead oI classiIying traIIic at each hop in the
network as the packet traverses the network to its ultimate destination, QoS marking
mechanisms are used. Marking allows speciIic Iields in a Irame or packet to be set that
identiIies that Irame or packet as belonging to a speciIic service class. The MQC provides one
such mechanism Ior marking network traIIic.
This lesson describes the class-based marking capability oI the Cisco IOS MQC and how
policy maps can be conIigured to mark network traIIic. MQC marking Ieatures covered in this
lesson include CoS, IP precedence, and DSCP.
ReIevance
Marking is a Iundamental requirement Ior any network deployment oI QoS. As such, it is oI
key importance to understand what markers can be set aIter traIIic has been classiIied, how
diIIerent marking mechanisms Iunction, and how marking mechanisms are conIigured on Cisco
IOS devices when implementing QoS.
Objectives
Upon completing this lesson, you will be able to use class-based marking to assign packets to a
speciIic service class. This includes being able to meet these objectives:
Describe class-based marking
Describe the diIIerent IP packet marking options available in class-based marking
IdentiIy the Cisco IOS commands required to conIigure class-based marking
IdentiIy the Cisco IOS commands required to mark IP packets using CoS with class-based
marking
IdentiIy the Cisco IOS commands required to mark IP packets using IP precedence with
class-based marking
IdentiIy the Cisco IOS commands required to mark IP packets using DSCP with class-
based marking
IdentiIy the Cisco IOS commands used to monitor class-based marking
OutIine
OutIine
· Overview
· CIass-Based Marking Overview
· MQC Marking Options
· Configuring CIass-Based Marking
· Configuring CoS Marking
· Configuring IP Precedence Marking
· Configuring IP DSCP Marking
· Monitoring CIass-Based Marking
· Summary
· Quiz
CIass-Based Marking Overview
This topic describes the MQC class-based marking mechanism.
Marking packets or Irames lets you set inIormation in the Layer 2 and Layer 3 headers oI a
packet, so the packet or Irame can be identiIied and distinguished Irom other packets or Irames.
The class-based weighted Iair queuing (CBWFQ) provides packet-marking capabilities using
class-based marking, which is conIigured within the Cisco IOS MQC Ieature. It is the most
Ilexible Cisco IOS marking tool, extending the marking Iunctionality oI committed access rate
(CAR) and policy routing.
Class-based marking can be used on input or output oI interIaces as part oI a deIined input or
an output service policy. On input, class-based marking can be combined with class-based
policing, and on output, with any other CBWFQ QoS Ieature.
CIass-Based Marking Overview
· CIass-based marking is an additionaI tooI avaiIabIe with
the MQC that aIIows static per-cIass marking of packets.
· It can be used to mark inbound or outbound packets.
· It can be combined with any other QoS feature on output.
· It can be combined with cIass-based poIicing on input.
· CEF must be configured on the interface before the cIass-
based packet marking feature can be used.
MQC Marking Options
This topic describes the diIIerent IP packet marking options that are available in class-based
marking.
Class-based marking supports the Iollowing markers:
IP precedence
IP DSCP value
QoS group
MPLS experimental bits
IEEE 802.1Q or ISL CoS/priority bits
Frame Relay DE bit
ATM CLP bit
Class-based marking can be combined with other mechanisms available in the MQC.
MQC Marking Options
· Packets can be marked with one of the foIIowing
markers:
÷ IP precedence
÷ IP DSCP
÷ QoS group
÷ MPLS experimentaI bits
÷ IEEE 802.1Q or ISL CoS/priority bits
÷ Frame ReIay DE bit
÷ ATM CLP bit
Configuring CIass-Based Marking
This topic identiIies the Cisco IOS commands that are required to conIigure class-based
marking.
When conIiguring class-based marking, three conIiguration steps need to be completed:
Create a class-map
Create a policy-map
Attach the policy-map to an interIace by using the service-policy Cisco IOS command.
class-map class-map-name
Syntax Description
classmapname Name of the class for the class map. The class name is used for
both the class map and to configure policy for the class in the
policy map.
match~all | match~any Determines how packets are evaluated when multiple match
criteria exist. Packets must either meet all of the match criteria
(match-aII) or one of the match criteria (match-any) in order to
be considered a member of the class.
class~map (match~any | match~all) class~map~name class~map (match~any | match~all) class~map~name
router(config)#
1. Create CIass Map: A traffic cIass (match access Iist, input
interface, IP Prec, DSCP, protocoI [NBAR] src/dst MAC
address).
router(config)#
2. Create PoIicy Map (Service PoIicy): Associate a
cIass map with one or more QoS marking poIicies.
router(config~if)#
3. Attach Service PoIicy: Associate the poIicy map to an input or
output interface.
policy-map policy-map-name
Syntax Description
policymapname Name of the policy map.
service-policy policy-map-name
Syntax Description
policymapname Specifies the name of the predefined policy map to be used as a
QoS policy. The name can be a maximum of 40 alphanumeric
characters.
In the Iigure, two class-maps have been conIigured, Well-known-services and Unknown-
services. The match criterion is speciIied in access-list 100.
The policy-map set-DSCP has been created to associate the class-maps Well-known-services
and Unknown-services with it.
For packets allowed by class-map Well-known-services the IP DSCP value will be set AF21.
Those matching class-map Unknown-services will have the IP DSCP value set to 0.
The policy-map is attached to E0/0 Ior incoming packets by the service-policy command.
(Cont.)
class~map Well~known~services
!
class~map Unknown~services
match not class~map Well~known~services
!
policy~map set~DSCP
class Well~known~services
set DSCP AF21
class Unknown~services
set DSCP 0
!
access~list 100 permit tcp any any lt 1024
access~list 100 permit tcp any lt 1024 any
!
Interface ethernet 0/0
service~policy input set~DSCP
Configuring CoS Marking
This topic identiIies the Cisco IOS commands that are required to mark IP packets using CoS
with class-based marking.
The IEEE 802.1p standard speciIies a standard Ior delivering QoS in LANs. Packets are
marked with three CoS bits where CoS values range Irom zero Ior low priority to seven Ior
high priority. CoS can only be applied on trunks because VLAN trunking encapsulations
designate Iields with available space to carry CoS bits. There are currently two widely deployed
trunking protocols that can transport CoS markings as Iollows:
ISL Irame headers have a 1-byte user Iield that carries the CoS value in the three least
signiIicant bits.
IEEE 802.1p and 802.1q Irame headers have a 2-byte TCI Iield that carries the CoS value
in the three most signiIicant bits that are called the user priority bits.
Note: Other frame types (untagged) cannot carry CoS values.
In general, Layer 2 switches can examine, use, or alter MAC layer markings (but not IP
precedence or DSCP settings), because IP precedence and DSCP are Layer 3. Layer 2 markings
are generally applied on egress trunk ports.
set cos cos-value
Syntax Description
cos~value Specific ÌEEE 802.1Q CoS value from 0 to 7.
Configuring CoS Marking
set cos cos~value set cos cos~value
· Mark frames with the specified vaIue (0 to 7).
· The vaIue appIies to the CoS bits with the IEEE 802.1Q
encapsuIation or priority bits with the ISL encapsuIation.
· The command can onIy be used on LAN interfaces that are
using one of the two mentioned encapsuIations.
policy~map SetCoS
class Class1
set cos 1
class Class2
set cos 2
class Class3
set cos 3
Configuring IP Precedence Marking
This topic identiIies the Cisco IOS commands that are required to mark IP packets using IP
precedence with class-based marking.
IP precedence is encoded into the three high-order bits oI the ToS Iield in the IP header. It
supports eight classes: two oI these classes, IP precedence 6 and 7, are reserved and should not
be used Ior user-deIined classes. IP precedence 0 is the deIault value and is usually used Ior the
best-eIIort class.
To set the precedence value in the IP header, use the set ip precedence QoS policy-map
conIiguration command. To leave the precedence value at the current setting, use the no Iorm
oI this command.
set ip precedence ip-preceaence-value
Syntax Description
ipprecedencevalue A number from 0 to 7 that sets the precedence bit in the ÌP
header.
Configuring IP Precedence Marking
set ip precedence ip~precedence~value set ip precedence ip~precedence~value
· Mark IP packets with the specified IP precedence vaIue.
· IP precedence can be set using a vaIue (0 to 7) or a
corresponding name (for exampIe, routine, priority,
immediate).
policy~map SetPrec
class Class1
set ip precedence priority
class Class2
set ip precedence flash
class Class3
set ip precedence 5
Configuring IP DSCP Marking
This topic identiIies the Cisco IOS commands that are required to mark IP packets using DSCP
with class-based marking.
DiIIerentiated Services (DiIIServ) is a new model that supercedesand is backward
compatible withIP precedence. DiIIServ uses 6 prioritization bits that permit classiIication oI
up to 64 values (0 to 63). A DiIIServ value is called a DSCP. The set ip dscp command is used
to mark packets oI a class with a DSCP value.
To mark a packet by setting the IP DSCP in the ToS byte, use the set ip dscp QoS policy-map
conIiguration command. To remove a previously set IP DSCP, use the no Iorm oI this
command.
set ip dscp ip-ascp-value
Syntax Description
ipdscpvalue A number from 0 to 63 that sets the ÌP DSCP value. Reserved
keywords EF (expedited forwarding), AF11 (assured forwarding
class AF11), and AF12 (assured forwarding class AF12) can be
specified instead of numeric values.
Configuring IP DSCP Marking
set ip dscp ip~dscp~value set ip dscp ip~dscp~value
· Mark IP packets with the specified DSCP vaIue.
· DSCP can be set using a vaIue (0 to 63) or a
corresponding name (for exampIe, af11, af12, af13, af21,
ef, cs1, defauIt).
policy~map SetDSCP
class Class1
set ip dscp af11
class Class2
set ip dscp af21
class Class3
set ip dscp ef
Monitoring CIass-Based Marking
This topic identiIies the Cisco IOS commands that are used to monitor class-based marking.
The show policy-map command displays all classes Ior service policy that is speciIied in the
command line.
To display the conIiguration oI all classes Ior a speciIied service policy map or all classes Ior
all existing policy maps, use the show policy-map EXEC or privileged EXEC command.
show policy-map |policy-map|
Syntax Description
policymap (Optional) The name of the service policy map whose complete
configuration is to be displayed.
Router>
· DispIays the configuration of aII cIasses for a specified service
poIicy map or aII cIasses for aII existing poIicy maps.
router#show policy~map
Policy Map SetCoS
Class Class1
set cos 1
Class Class2
set cos 2
Class Class3
set cos 3
Class Class4
set cos 4
Class Class5
set cos 5
Class Class6
set cos 6
Class Class7
set cos 7
The show policy-map interface command displays all service policies applied to the interIace.
Among the settings, marking parameters and statistics are displayed.
To display the conIiguration oI all classes conIigured Ior all service policies on the speciIied
interIace or to display the classes Ior the service policy Ior a speciIic permanent virtual circuit
(PVC) on the interIace, use the show policy-map interface EXEC or privileged EXEC
command.
(Cont.)
router#show policy~map interface serial 0/0
Serial0/0
Service~policy input: SetMPLS (1837)
Class~map: Class1 (match~any) (1839/12)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: qos~group 1 (1843)
0 packets, 0 bytes
30 second rate 0 bps
QoS Set
mpls experimental 1
...
show policy~map interface interface~name show policy~map interface interface~name
Router>
· DispIays the configuration of aII cIasses configured for aII
service poIicies on the specified interface.
show policy-map interface interface-name |vc | /| ||dlci | |input [ output|
Syntax Description
interfacename Name of the interface or subinterface whose policy configuration
is to be displayed.
vpi/ (Optional) ATM network virtual path identifier (VPÌ) for this PVC.
The absence of the ¨/¨ and a value defaults the value to 0.
On the Cisco 7200 and 7500 series routers, this value ranges
from 0 to 255.
The and arguments cannot both be set to 0; if one is 0, the
other cannot be 0.
Ìf this value is omitted, information for all virtual circuits (VCs) on
the specified ATM interface or subinterface is displayed.
vci (Optional) ATM network virtual channel identifier (VCÌ) for this
PVC. This value ranges from 0 to 1 less than the maximum value
set for this interface by the atm vc-per-vp command. Typically,
lower values 0 to 31 are reserved for specific traffic (F4
Operation, Administration, and Maintenance [OAM], switched
virtual circuit [SVC] signalling, Ìntegrated Local Management
Ìnterface [ÌLMÌ], and so on) and should not be used.
The VCÌ is a 16-bit field in the header of the ATM cell. The VCÌ
value is unique only on a single link, not throughout the ATM
network, because it has local significance only.
The and arguments cannot both be set to 0; if one is 0, the
other cannot be 0.
dlci (Optional) Ìndicates that a specific PVC for which policy
configuration will be displayed.
dlci (Optional) A specific data-link connection identifier (DLCÌ) number
used on the interface. Policy configuration for the corresponding
PVC will be displayed when a DLCÌ is specified.
input (Optional) Ìndicates that the statistics for the attached input policy
will be displayed.
output (Optional) Ìndicates that the statistics for the attached output
policy will be displayed.
Summary
Summary
· CIass-based marking can mark inbound or outbound packets.
· Packets can be marked by IP precedence, IP DSCP, QoS group, MPLS
experimentaI bits, and so on.
· CIass-based marking requires three configuration steps: cIass map,
poIicy map, service poIicy.
· Use set cos cos-value to set (mark) the L2 cos vaIue of an outgoing
packet.
· Use set ip precedence ip-precedence-value to set (mark) the
precedence vaIue in the IP header.
· Use set ip dscp ip-dscp-value to set (mark) packets of a cIass with a
DSCP vaIue.
· In order to use cIass-based marking CEF must be enabIed.
· Use show poIicy-map to dispIay the configuration of a service poIicy
map created using the poIicy-map command.
· Use show poIicy-map interface to dispIay aII service poIicies appIied to
the specified interface.
References
For more inIormation on Class-Based Marking, reIer to 'Class-Based Marking¨ at the
Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios121/121newIt/121t/121t5/cb
pmark2.pdI
Next Steps
Lab Exercise 4-1: ClassiIication and Marking Using MQC
Quiz
Q1) Which oI the Iollowing cannot be accomplished by marking packets or Irames?
A) set inIormation in Layer 1 header
B) set inIormation in Layer 2 header
C) set inIormation in Layer 3 header
D) set inIormation in Layer 4 header
Q2) Which three oI the Iollowing markers are supported by class-based marking? (Choose
three.)
A) ATM DE bit
B) Frame Relay group
C) MPLS experimental bits
D) IEEE 802.1Q or ISL CoS/priority bits
E) IP precedence
Q3) Which three oI the Iollowing are steps in conIiguring class-based marking? (Choose
three.)
A) create a class map
B) create a policy map
C) apply a policy to a class map
D) attach a service policy to an interIace
Q4) How many bits is the CoS Iield?
A) 2 bits
B) 3 bits
C) 4 bits
D) 6 bits
Q5) IP precedence is encoded as how many bits and in which Iield in the IP header?
A) 3 low order bits oI the CoS Iield
B) 3 low order bits oI the ToS Iield
C) 3 high order bits oI the CoS Iield
D) 3 high order bits oI the ToS Iield
Q6) DSCP uses how may prioritization bits?
A) 2
B) 3
C) 4
D) 6
Q7) Which oI the Iollowing commands will display the conIiguration oI all classes
conIigured Ior all service policies on the speciIied interIace?
A) show policy map s0/0
B) show policy-map s0/0 policy default
C) show policy-map interface s0/0
D) show policy-map interface s0/0 class default
Quiz Answer Key
Q1) A
ReIates to: Class-Based Marking Overview
Q2) C, D, E
ReIates to: MQC Marking Options
Q3) A, B, D
ReIates to: Configuring Class-Based Marking
Q4) B
ReIates to: Configuring CoS Marking
Q5) D
ReIates to: Configuring ÌP Precedence Marking
Q6) D
ReIates to: Configuring ÌP DSCP Marking
Q7) C
ReIates to: Monitoring Class-Based Marking
Using NBAR for Classification
Overview
NBAR, a Ieature in Cisco IOS soItware, provides intelligent network classiIication Ior your
inIrastructure. NBAR is a classiIication engine that can recognize a wide variety oI
applications, including Web-based applications and client and server applications that
dynamically assign TCP or UDP port numbers. AIter the application is recognized, the network
can invoke speciIic services Ior that particular application. NBAR currently works with QoS
Ieatures to ensure that the network bandwidth is best used to IulIill company objectives. These
Ieatures include the ability to guarantee bandwidth to critical applications, limit bandwidth to
other applications, drop selective packets to avoid congestion, and mark packets appropriately
so that the your network and the service provider network can provide QoS Irom end to end.
This lesson describes NBAR, a Cisco IOS protocol discovery and classiIication mechanism.
NBAR Ieatures covered in this lesson include applications that NBAR can support, Packet
Description Language Modules (PDLMs), and NBAR protocol discovery.
ReIevance
oI key importance to understand the diIIerent ways that traIIic can be classiIied.
Objectives
Upon completing this lesson, you will be able to use NBAR to discover network protocols and
to classiIy packets. This includes being able to meet these objectives:
Describe the Iunction oI NBAR
IdentiIy the types oI applications recognized by NBAR
Explain the purpose oI PDLMs in NBAR
Describe NBAR protocol discovery and the NBAR Protocol Discovery MIB
IdentiIy the Cisco IOS commands required to conIigure and monitor NBAR protocol
discovery
IdentiIy the Cisco IOS commands required to conIigure NBAR to recognize static port
protocols
IdentiIy the Cisco IOS commands required to conIigure NBAR to recognize TCP and UDP
stateIul protocols
OutIine
OutIine
· Overview
· Network Based AppIication Recognition
· NBAR AppIication Support
· Packet Description Language ModuIe
· ProtocoI Discovery
· Configuring and Monitoring ProtocoI Discovery
· Configuring NBAR for Static ProtocoIs
· Configuring NBAR for StatefuI ProtocoIs
· Summary
· Quiz
Network Based AppIication Recognition
This topic describes the NBAR, a Cisco IOS protocol discovery and classiIication mechanism.
NBAR is an MQC-enabled classiIication and protocol discovery Ieature. NBAR can determine
the mix oI traIIic on the network, which is important in isolating congestion problems.
NBAR can classiIy application traIIic by looking beyond the TCP/UDP port numbers oI a
packet. This is subport classiIication. NBAR looks into the TCP/UDP payload itselI and
classiIies packets based on the content within the payload, such as transaction identiIier,
message type, or other similar data.
ClassiIication oI HTTP, by URL or Multipurpose Internet Mail Extensions (MIME) type is an
example oI subport classiIication. NBAR classiIies HTTP traIIic by text within the URL, using
regular expression matching. NBAR uses the UNIX Iilename speciIication as the basis Ior the
URL speciIication Iormat. The NBAR engine then converts the speciIication Iormat into a
regular expression.
The NBAR protocol discovery Ieature provides an easy way to discover application protocols
that are transiting an interIace. The protocol discovery Ieature discovers any protocol traIIic
supported by NBAR. Protocol discovery can be applied to interIaces and can be used to
monitor both input and output traIIic. Protocol discovery maintains the Iollowing per-protocol
statistics Ior enabled interIaces: total number oI input and output packets and bytes, and input
and output bit rates.
An external PDLM can be loaded at run time to extend the NBAR list oI recognized protocols.
PDLMs can also be used to enhance an existing protocol recognition capability. PDLMs allow
NBAR to recognize new protocols without requiring a new Cisco IOS image or a router reload.
Network Based
AppIication Recognition
· NBAR soIves the probIem of how to cIassify modern
cIient/server and web-based appIications.
· NBAR performs the foIIowing functions:
÷ Identification of appIications and protocoIs (Layer 4 to Layer 7)
÷ ProtocoI discovery
÷ Provides traffic statistics
· EnabIes downstream actions based on QoS poIicies via
random earIy detection, cIass-based queuing, and
poIicing.
· New appIications are easiIy supported by Ioading PDLM.
NBAR is not supported on the Iollowing logical interIaces:
Fast EtherChannel
InterIaces conIigured to use tunneling or encryption
NBAR does not support the Iollowing:
More than 24 concurrent URLs, hosts, or MIME-type matches
Matching beyond the Iirst 400 bytes in a packet payload
Multicast and switching modes other than Cisco Express Forwarding (CEF)
Fragmented packets
URL/host/MIME classiIication with secure HTTP
Packets originating Irom or destined to the router running NBAR
Note: NBAR cannot be used to classify output traffic on a WAN link where tunneling or encryption
is used. Therefore, NBAR should be configured on other interfaces on the router (such as a
LAN link) to perform input classification before the traffic is switched to the WAN link for
output. However, NBAR protocol discovery is supported on interfaces where tunneling or
encryption is used. You can enable protocol discovery directly on the tunnel or on the
interface where encryption is performed to gather key statistics on the various applications
that are traversing the interface. The input statistics also show the total number of
encrypted/tunneled packets received in addition to the per-protocol breakdowns.
To run distributed NBAR on a Cisco 7500 series router, you must be using a processor that has
64 MB oI DRAM or more. At the time oI this publication, the Iollowing processors met this
requirement:
Versatile interIace processor (VIP)2-50, VIP4-50, VIP4-80, and VIP6-80
GigabitEthernet InterIace Processor (GEIP) and GEIP¹
Spatial Reuse Protocol InterIace Processor (SRPIP)
Note: For the latest information regarding NBAR use restrictions, please refer to the Cisco ÌOS
documentation for your specific software release.
NBAR AppIication Support
This topic describes how NBAR supports various applications.
NBAR supports simpler conIiguration coupled with stateIul recognition oI Ilows. The simpler
conIiguration means you do not have to examine a protocol analyzer capture to calculate ports
and details. StateIul recognition means smarter, deeper packet recognition.
NBAR can be used to recognize packets belonging to diIIerent types oI applications:
Static applications establish sessions to well-known TCP or UDP destination port numbers.
Such applications were classiIied by using access lists.
Dynamic applications use multiple sessions that use dynamic TCP or UDP port numbers.
Typically, there is a control session to a well-known port number and the other sessions are
established to destination port numbers negotiated through the control sessions. NBAR
inspects the port number exchange through the control session.
Some non-IP protocols can also be recognized by NBAR.
NBAR also has the capability to inspect some applications Ior other inIormation and
classiIy based on that inIormation. For example, NBAR can classiIy HTTP sessions based
on the requested URL, including MIME type or host name.
NBAR AppIication Support
NBAR can cIassify appIications that use:
· StaticaIIy assigned TCP and UDP port numbers
· Non-UDP and non-TCP IP protocoIs
· DynamicaIIy assigned TCP and UDP port numbers negotiated
during connection estabIishment (requires statefuI inspection)
· Subport cIassification: cIassification of HTTP (URLs, MIME, or
host names) and Citrix appIications (ICA traffic based on
pubIished appIication name)
· CIassification based on deep packet inspection and muItipIe
appIication specific attributes (RTP payIoad cIassification)
The Iollowing table lists the non-TCP and non-UDP protocols supported by NBAR.
Non-TCP and Non-UDP NBAR Supported ProtocoIs
ProtocoI Network
ProtocoI
ProtocoI ID Description
EGP ÌP 8 Exterior Gateway Protocol
GRE ÌP 47 Generic Routing Encapsulation
ÌCMP ÌP 1 Ìnternet Control Message Protocol
ÌPÌNÌP ÌP 4 ÌP in ÌP
ÌPSec ÌP 50, 51 ÌP Encapsulating Security
Payload/Authentication Header
EÌGRP ÌP 88 Enhanced Ìnterior Gateway Routing Protocol
Although access lists can also be used to classiIy applications based on static port numbers,
NBAR is easier to conIigure and can provide classiIication statistics that are not available when
using access lists.
NBAR AppIication Support (Cont.)
The Iollowing table contains the static IP protocols supported by NBAR.
Static TCP and UDP NBAR Supported ProtocoIs
ProtocoI Network
ProtocoI
BGP TCP/UDP 179 Border Gateway Protocol
CU-SeeMe TCP/UDP 7648, 7649 Desktop videoconferencing
CU-SeeMe UDP 24032 Desktop video conferencing
DHCP/ BOOTP UDP 67, 68 Dynamic Host Configuration Protocol/
Bootstrap Protocol
DNS TCP/UDP 53 Domain Name System
Finger TCP 79 Finger user information protocol
Gopher TCP/UDP 70 Ìnternet Gopher Protocol
HTTP TCP 80 Hypertext Transfer Protocol
HTTPS TCP 443 Secured HTTP
ÌMAP TCP/UDP 143, 220 Ìnternet Message Access Protocol
ÌRC TCP/UDP 194 Ìnternet Relay Chat
Kerberos TCP/UDP 88, 749 Kerberos Network Authentication Service
L2TP UDP 1701 L2F/L2TP tunnel
LDAP TCP/UDP 389 Lightweight Directory Access Protocol
MS-PPTP TCP 1723 Microsoft Point-to-Point Tunneling Protocol
for VPN
MS-SQLServer TCP 1433 Microsoft SQL Server Desktop
Videoconferencing
NetBÌOS TCP 137, 139 NetBÌOS over ÌP (MS Windows)
NetBÌOS UDP 137, 138 NetBÌOS over ÌP (MS Windows)
NFS TCP/UDP 2049 Network File System
NNTP TCP/UDP 119 Network News Transfer Protocol
Notes TCP/UDP 1352 Lotus Notes
Novadigm TCP/UDP 3460-3465 Novadigm Enterprise Desktop
Manager (EDM)
NTP TCP/UDP 123 Network Time Protocol
PCAnywhere TCP 5631, 65301 Symantec PCAnywhere
PCAnywhere UDP 22, 5632 Symantec PCAnywhere
POP3 TCP/UDP 110 Post Office Protocol
Printer TCP/UDP 515 Printer
RÌP UDP 520 Routing Ìnformation Protocol
RSVP UDP 1698,17 Resource Reservation Protocol
SFTP TCP 990 Secure FTP
ProtocoI Network
ProtocoI
SHTTP TCP 443 Secure HTTP
SÌMAP TCP/UDP 585, 993 Secure ÌMAP
SÌRC TCP/UDP 994 Secure ÌRC
SLDAP TCP/UDP 636 Secure LDAP
SNNTP TCP/UDP 563 Secure NNTP
SMTP TCP 25 Simple Mail Transfer Protocol
SNMP TCP/UDP 161, 162 Simple Network Management Protocol
SOCKS TCP 1080 Firewall security protocol
SPOP3 TCP/UDP 995 Secure POP3
SSH TCP 22 Secured Shell
STELNET TCP 992 Secure Telnet
Syslog UDP 514 System Logging Utility
Telnet TCP 23 Telnet Protocol
X Windows TCP 6000-6003 X11, X Windows
The Iollowing table lists the dynamic (or stateIul) protocols supported by NBAR.
StatefuI NBAR Supported ProtocoIs
StatefuI ProtocoI Transport
ProtocoI
Description
FTP TCP File Transfer Protocol
Exchange TCP MS-RPC for Exchange
HTTP TCP HTTP with URL, MÌME, or Host classification
Netshow TCP/UDP Microsoft Netshow
Realaudio TCP/UDP RealAudio Streaming Protocol
r-commands TCP rsh, rlogin, rexec
StreamWorks UDP Xing Technology Stream Works audio and video
SQL*NET TCP/UDP SQL*NET for Oracle
SunRPC TCP/UDP Sun Remote Procedure Call
TFTP UDP Trivial File Transfer Protocol
VDOLive TCP/UDP VDOLive Streaming Video
Packet Description Language ModuIe
This topic describes PDLM.
New Ieatures are usually added to new versions oI the Cisco IOS soItware. NBAR is the Iirst
mechanism that supports dynamic upgrades without having to change the Cisco IOS version or
restart a router.
PDLMs contain the rules that are used by NBAR to recognize an application and can be used to
bring new or changed Iunctionality to NBAR.
An external PDLM can be loaded at run time to extend the NBAR list oI recognized protocols.
PDLMs can be used to enhance an existing protocol recognition capability. PDLMs allow
NBAR to recognize new protocols without requiring a new Cisco IOS image or a router reload.
Note: New PDLMs are released only by Cisco and are available from local Cisco representatives.
They can be loaded from flash memory. Registered users can find them at:
http://www.cisco.com/cgi-bin/tablebuild.pl/pdlm
To extend or enhance the list oI protocols recognized by NBAR through a PDLM provided by
Cisco, use the ip nbar pdlm conIiguration command. Use the no Iorm oI this command to
unload a PDLM iI it was previously loaded.
Use the show ip nbar port-map command to display the current protocol-to-port mappings in
use by NBAR.
Packet Description Language ModuIe
· An externaI PDLM can be Ioaded at run time to extend the
NBAR Iist of recognized protocoIs.
· PDLMs can aIso be used to enhance an existing protocoI
recognition capabiIity.
· PDLMs aIIow NBAR to recognize new protocoIs without
requiring a new Cisco IOS image or a router reIoad.
· PDLMs must be produced by Cisco engineers.
· CurrentIy avaiIabIe PDLMs incIude:
÷ Peer 2 Peer fiIe sharing appIications - KaZaa, Morpheus, Grokster,
and GnuteIIa
÷ Citrix
÷ Novadigm Enterprise Desktop Manager (EDM)
ProtocoI Discovery
This topic describes the NBAR protocol discovery Ieature.
To develop and apply QoS policies, NBAR includes a protocol discovery Ieature that provides
an easy way to discover application protocols that are transiting an interIace. The protocol
discovery Ieature discovers any protocol traIIic that is supported by NBAR.
NBAR protocol discovery captures key statistics associated with each protocol in a network.
These statistics can be used to deIine traIIic classes and QoS policies Ior each traIIic class.
Protocol discovery can be applied to interIaces and can be used to monitor both input and
output traIIic. In addition, protocol discovery shows the mix oI applications currently running
on the network. This helps in deIining QoS classes and polices, such as how much bandwidth
to provide to mission-critical applications and to determine which protocols should be policed.
The Iollowing per-protocol, bidirectional statistics are available:
Packet and byte counts
Bit rates
ProtocoI Discovery
· ProtocoI discovery anaIyzes appIication traffic patterns in
reaI time and discovers which traffic is running on the
network.
· Provides bidirectionaI, per-interface, per-protocoI
statistics:
÷ 5-minute bit rate (bps)
÷ Packet counts
÷ Byte counts
· Important monitoring tooI supported by Cisco QoS
management tooIs.
÷ Generates reaI-time appIication statistics
÷ Provide traffic distribution information at key network Iocations
· HistoricaI QoS statisticaI information avaiIabIe through
the ProtocoI Discovery MIB.
The Protocol Discovery Management InIormation Base (MIB) allows users to:
Enable NBAR protocol discovery on multiple interIaces across multiple routers in a
network
Gather statistics
Set traps and threshold alarms on protocols
Study historical trending Ior a whole network.
ProtocoI Discovery MIB
· The NBAR ProtocoI Discovery MIB uses SNMP
to provide the foIIowing new protocoI discovery
functionaIity:
÷ EnabIe or disabIe protocoI discovery per interface
÷ DispIay protocoI discovery statistics
÷ Configure and view muItipIe top-n tabIes that Iist
protocoIs by bandwidth usage
÷ Configure threshoIds based on traffic of particuIar
NBAR-supported protocoIs or appIications that report
breaches and send notifications when these
threshoIds are crossed
· ReIeased in Cisco IOS ReIease 12.2(15)T
Configuring and Monitoring ProtocoI Discovery
This topic identiIies the Cisco IOS commands that are required to conIigure and monitor
NBAR protocol discovery.
The NBAR Ieature has two components:
One component monitors applications traversing a network.
The other component classiIies traIIic by protocol.
In order to monitor applications traversing a network, protocol discovery must be enabled. The
ability to classiIy traIIic by protocol using NBAR and then applying QoS to the classiIied
traIIic is conIigured using the MQC.
Use the ip nbar protocol-discovery command to conIigure NBAR to keep traIIic statistics Ior
all protocols known to NBAR. Protocol discovery provides an easy way to discover application
protocols transiting an interIace so that QoS policies can be developed and applied. The
protocol discovery Ieature discovers any protocol traIIic supported by NBAR. Protocol
discovery can be used to monitor both input and output traIIic and can be applied with or
without a service policy enabled.
Note: You must enable CEF before you configure NBAR. For more information on CEF, refer to
Cisco Express Forwarding Overview at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/switch_c/xcprt2/xc
dcef.htm.
Configuring ProtocoI Discovery
ip nbar protocol~discovery ip nbar protocol~discovery
router(config~if)#
· To configure NBAR to discover traffic for aII protocoIs
known to NBAR on a particuIar interface
· Requires CEF be enabIed before protocoI discovery
· Can be appIied with or without a service poIicy enabIed
snmp~server enable traps cnpd snmp~server enable traps cnpd
router(config)#
· EnabIes Cisco NBAR ProtocoI Discovery notifications
· ReIeased in Cisco IOS ReIease 12.2(15)T
Use the show ip nbar protocol-discovery command to display statistics gathered by the
NBAR protocol discovery Ieature. This command, by deIault, displays statistics Ior all
interIaces on which protocol discovery is currently enabled. The deIault output oI this
command includesin the Iollowing orderinput bit rate (bps), input byte count, input packet
count, and protocol name. Output statistics include packet count, byte count, and the output bit
rate in bps.
Protocol discovery can be used to monitor both input and output traIIic and can be applied with
or without a service policy enabled. NBAR protocol discovery gathers statistics Ior packets
switched to output interIaces. These statistics are not necessarily Ior packets that exited the
router on the output interIaces because packets might have been dropped aIter switching Ior
various reasons (policing at the output interIace, access lists, or queue drops). The example
displays partial output oI the show ip nbar protocol-discovery command Ior an Ethernet
interIace.
Monitoring ProtocoI Discovery
show ip nbar protocol~discovery show ip nbar protocol~discovery
Router#
· DispIays the statistics for aII interfaces on which protocoI
discovery is enabIed
router#show ip nbar protocol~discovery
Fthernet0/0
Input output
Protocol Packet Count Packet Count
Byte Count Byte Count
5 minute bit rate (bps) 5 minute bit rate (bps)
~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
realaudio 2911 3040
1678304 198406
19000 1000
http 19624 13506
14050949 2017293
0 0
. . .
Configuring NBAR for Static ProtocoIs
This topic identiIies the Cisco IOS commands that are required to conIigure NBAR Ior static
protocols.
When conIiguring NBAR the administrator does not need to understand the way a certain
protocol works. The conIiguration simply requires the administrator to enter the name oI the
protocol (static or stateIul).
match protocol protocol-name
Syntax Description
protocol~name Name of the protocol used as a matching criterion. Supported
protocols include the following (some protocols omitted. Refer to
Cisco ÌOS documentation for complete details):
aarp÷AppleTalk Address Resolution Protocol
arp÷ÌP Address Resolution Protocol (ARP)
bridge÷bridging
cdp÷Cisco Discovery Protocol
compressedtcp÷compressed TCP
dIsw÷data-link switching
ip÷ÌP
ipx÷Novell ÌPX
Configuring NBAR for
Static ProtocoIs
match protocol protocol match protocol protocol
· Configures the match criteria for a cIass map on the basis
of the specified protocoI.
· Static protocoIs are recognized based on the weII-known
destination port number.
· Dynamic protocoIs are recognized by inspecting the
session.
· A match not command can be used to specify a QoS
poIicy vaIue that is not used as a match criterion. In this
case, aII other vaIues of that QoS poIicy become
successfuI match criteria.
Some protocols (static or stateIul) can use additional TCP or UDP ports. Use the ip nbar port-
map command to extend the NBAR Iunctionality Ior well-known protocols to new port
numbers.
To extend or enhance the list oI protocols recognized by NBAR through a Cisco PDLM, use
the ip nbar pdlm global conIiguration command.
The palm-file parameter should be in the URL Iormat and can point to the Ilash where the
Cisco IOS soItware is stored (Ior example, flash://citrix.pdlm). The Iile can also be located on
a TFTP server (Ior example, tftp://10.1.1.1/nbar.pdlm).To unload a PDLM iI it was
previously loaded, use the no Iorm oI this command.
ip nbar pdlm pdlm-name
Syntax Description
pdlmname The URL where the PDLM can be found on the Flash card.
Static ProtocoIs (Cont.)
ip nbar port~map protocol (tcp | udp) new~port (new~port ...) ip nbar port~map protocol (tcp | udp) new~port (new~port ...)
router(config)#
· Configure NBAR to search for a protocoI or protocoI name
using a port number other than the weII-known port.
· Up to 16 additionaI port numbers can be specified.
ip nbar pdlm pdlm~file ip nbar pdlm pdlm~file
router(config)#
· Specifies the Iocation of the Packet Description Language
ModuIe fiIe to extend the NBAR capabiIities of the router.
· The fiIename is in the URL format (for exampIe,
fIash://citrix.pdIm).
ExampIe: Configuring NBAR for Static ProtocoIs
The example illustrates a simple classiIication oI all HTTP sessions. HTTP sessions using the
deIault well-known TCP port number 80 are simple to classiIy (it is a static protocol).
HTTP is oIten used on other port numbers. The example shows the usage oI the ip nbar port-
map command to also enable HTTP recognition on TCP port 8080.
The class map called HTTP is used to match the http protocol. The policy map LIMITWEBB
will use the class map HTTP and set the bandwidth Ior HTTP traIIic to 256.
The policy map is then applied as a service policy Ior outbound traIIic on S0/0.
Static ProtocoIs ExampIe
· HTTP is a static protocoI using a weII-known port number
80. However, other port numbers may aIso be in use.
· The ip nbar port-map command wiII inform the router that
other ports are aIso used for HTTP.
Configuring NBAR for StatefuI ProtocoIs
This topic identiIies the Cisco IOS commands that are required to conIigure NBAR Ior stateIul
protocols.
NBAR has enhanced classiIication capabilities Ior HTTP. It can classiIy packets belonging to
HTTP Ilows based on:
URL portion aIter the host name, which appears in the GET request oI the HTTP session
Host name speciIied in the GET request
MIME type speciIying the type oI object in the HTTP response
Note: The match protocoI command has been discussed previously in this lesson
The Iollowing example classiIies, within the class map called 'class1,¨ HTTP packets based on
any URL containing the string 'whatsnew/latest¨ Iollowed by zero or more characters:
class-map classI
match protocol http url whatsnew/latest*
The Iollowing example classiIies, within the class map called 'class2,¨ packets based on any
host name containing the string 'cisco¨ Iollowed by zero or more characters:
class-map class?
match protocol http host cisco*
The Iollowing example classiIies, within the class map called 'class3,¨ packets based on the
Joint Photographics Expert Group (JPEG) MIME type:
class-map class·
match protocol http mime "*jpeg"
StatefuI ProtocoIs
match protocol http url url~string match protocol http url url~string
· Recognizes the HTTP GET packets containing the URL, and then
matches aII packets that are part of the HTTP GET request.
· IncIude onIy the portion of the URL foIIowing the address or host name
in the match statement.
match protocol http host hostname~string match protocol http host hostname~string
· Performs a reguIar expression match on the host fieId contents inside
an HTTP GET packet and cIassifies aII packets from that host.
match protocol http mime MIME~type match protocol http mime MIME~type
· SeIect the MIME type to be matched.
· Matches a packet containing the MIME type and aII subsequent packets
untiI the next HTTP transaction.
Applications that use FastTrack include KaZaA, Grokster, and Morpheus (although newer
versions oI Morpheus use Gnutella).
A regular expression is used to identiIy speciIic FastTrack traIIic. For instance, entering 'cisco¨
as the regular expression would classiIy the FastTrack traIIic containing the string 'cisco¨ as
matches Ior the traIIic policy.
To speciIy that all FastTrack traIIic be identiIied by the traIIic class, use '*¨ as the regular
expression.
The Iollowing example conIigures NBAR to match all FastTrack traIIic:
match protocol fasttrack file-transfer ¯*º
In the Iollowing example, all FastTrack Iiles that have the '.mpeg¨ extension will be classiIied
into class map nbar.
class-map match-all nbar
match protocol fasttrack file-transfer "*.mpeg"
The Iollowing example conIigures NBAR to match FastTrack traIIic that contains the string
'cisco¨:
match protocol fasttrack file-transfer ¯*cisco*º
StatefuI ProtocoIs (Cont.)
match protocol fasttrack file~transfer "regular~expression" match protocol fasttrack file~transfer "regular~expression"
· StatefuI mechanism to identify a group of peer-to-peer fiIe
sharing appIications.
· AppIications that use FastTrack incIude KaZaA, Grokster,
and Morpheus.
· A Cisco IOS reguIar expression is used to identify specific
FastTrack traffic.
· To specify that aII FastTrack traffic be identified by the
traffic cIass, use "*" as the reguIar expression.
· Introduced in Cisco IOS 12.1(12c)E.
RTP consists oI a data and a control part. The control part is called RTC Protocol (RTCP). It is
important to note that the NBAR RTP payload classiIication Ieature does not identiIy RTCP
packets, and that RTCP packets run on odd numbered ports while RTP packets run on even
numbered ports.
The data part oI RTP is a thin protocol providing support Ior applications with real-time
properties (such as continuous media |audio and video|), which includes timing reconstruction,
loss detection, and security and content identiIication. The RTP payload type is the data
transported by RTP in a packet (Ior example, audio samples or compressed video data).
NBAR RTP payload classiIication not only allows one to stateIully identiIy real-time audio and
video traIIic, but it also can diIIerentiate on the basis oI audio and video codecs to provide
more granular QoS. The RTP payload classiIication Ieature, thereIore, looks deep into the RTP
header to classiIy RTP packets.
The payload string parameter can contain commas to separate payload-type values and hyphens
to indicate a range oI payload-type values. A payloaa-string can be speciIied in hexadecimal
(prepend 0x to the value) and binary (prepend b to the value) notations in addition to standard
number values.
NBAR RTP payload type classiIication was Iirst introduced in Cisco IOS Release 12.2(8)T and
is also available in Cisco IOS Release 12.1(11b)E.
StatefuI ProtocoIs (Cont.)
match protocol rtp (audio | video | payload~type payload~string) match protocol rtp (audio | video | payload~type payload~string)
· StatefuI mechanism to identify reaI time audio and video
traffic
· Differentiate on the basis of audio and video codecs
· The match protocoI rtp command has these options:
audio: Match by payIoad-type vaIues 0 to 23, reserved for audio
traffic
video: Match by payIoad-type vaIues 24 to 33, reserved for video
traffic
payIoad-type: Specifies matching by a specific payIoad-type vaIue,
providing more granuIarity than the audio or video options
· Introduced in Cisco IOS 12.2(8)T and 12.1(11b)E
ExampIe: Configuring NBAR for StatefuI ProtocoIs
The example illustrates a simple classiIication oI RTP sessions, both on the input interIace and
on the output interIace oI the router.
On the input interIace three class maps have been created: voice-in, videoconIerencing-in, and
interactive-in. The voice-in class map will match the RTP audio protocol; the
videoconIerencing-in class map will match the RTP video protocol and the interactive-in class
map will match the Citrix protocol.
The policy map class mark will then do the Iollowing:
II the packet matches the voice-in class map, the packet DSCP Iield will be set to EF. II the
packet matches the videoconIerencing-in class map the packet DSCP Iield will be set to AF
41. II the packet matches the interactive-in class map, the DSCP Iield will be set to AF 31.
The policy map class mark is applied to the input interIace, E0/0.
On the output three class maps have been created, voice-out, videoconIerencing-out, and
interactive-out. The voice-out class map will match the DSCP Iield, EF. The
videoconIerencing-out class map will match the DSCP Iield, AF 41, and the interactive-out
class map will match the DSCP Iield, AF 31.
StatefuI ProtocoIs ExampIe
In the Iigure, policy-map qos-policy will then do the Iollowing:
II the packet matches the class map voice-out, the packet priority will be set to 10 percent
oI the bandwidth. II the packet matches the class map videoconIerencing-out, the packet
priority will be set to 20 percent oI the bandwidth. II the packet matches the class map
interactive-out, the packet priority will be set to 30 percent oI the bandwidth. All other
packets will be classiIied as class-deIault and Iair-queuing will be perIormed on them.
The policy map class mark is applied to the output interIace, S0/0.
Summary
References
For a description oI all NBAR Ieatures and commands, reIer to 'Network-Based
Application Recognition¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios121/121newIt/121t/121t5/dtn
bar.htm
Next Steps
Lab Exercise 4-2: ClassiIication using NBAR
Summary
· NBAR aIIows new appIications to be supported by Ioading PDLMs.
· NBAR supports both staticaIIy and dynamicaIIy assigned TCP and
UDP port numbers aIong with other means to recognize appIications.
· Loading new PDLMs aIIow NBAR to recognize new protocoIs without a
new Cisco IOS image or router reIoad.
· ProtocoI Discovery anaIyzes appIication traffic patterns in reaI time
and discovers which traffic is running on the network.
· In order to monitor appIications traversing a network, ProtocoI
Discovery needs to be enabIed.
· Using the match protocoI command wiII aIIow static protocoIs
to be recognized based on weII-known port numbers.
· match protocoI rtp is a command to aIIow identification of reaI time
audio and video traffic.
· The IogicaI interfaces Fast EtherChanneI or interfaces configured for
tunneIing or encryption is not supported by NBAR.
Quiz
Q1) NBAR classiIication oI HTTP (by URL or MIME type) is an example oI ¸¸¸¸¸.
A) PDLM
B) port classiIication
C) subport classiIication
D) FastTrack
Q2) Which two oI the Iollowing are NBAR supported applications? (Choose two.)
A) BGP
B) EIGRP
C) OSPF
D) RIP
Q3) Which oI the Iollowing is correct regarding extending application support Ior NBAR?
A) FastTrack
B) QoS
C) PDLM
D) RTP
Q4) Which oI the Iollowing is not a Ieature oI Protocol Discovery?
A) bidirectional
B) per-interIace
C) per-protocol statistics
D) FastTrack run time protocol
Q5) The ip nbar protocol-discovery conIiguration command is perIormed at the ¸¸¸¸¸.
A) class map conIiguration level
B) global conIiguration level
C) interIace conIiguration level
D) router conIiguration level
Q6) The match protocol protocol conIiguration command is perIormed at the ¸¸¸¸¸.
A) class map conIiguration level
B) global conIiguration level
C) interIace conIiguration level
D) router conIiguration level
Q7) What will be the result oI the Iollowing conIiguration?
ip nbar port-map http tcp 80 8080
!
class-map HTTP
match protocol http
!
policy-map LIMITWEBBW
class HTTP
bandwidth ?S8
!
service-policy output LIMITWEBBW
A) All HTTP traIIic will be matched.
B) Only port 80 traIIic will be matched.
C) Only port 8080 traIIic will be matched.
D) Both port 80 and port 8080 traIIic will be matched.
Quiz Answer Key
Q1) C
ReIates to: Network Based Application Recognition
Q2) A, B
ReIates to: NBAR Application Support
Q3) C
ReIates to: Packet Description Language Module
Q4) D
ReIates to: Protocol Discovery
Q5) C
ReIates to: Configuring and Monitoring Protocol Discovery
Q6) A
ReIates to: Configuring NBAR for Static Protocols
Q7) D
ReIates to: Configuring NBAR for Stateful Protocols
Configuring QoS Pre-Classify
Overview
The QoS Ior virtual private networks (VPNs) Ieature (QoS pre-classiIy) provides a solution Ior
ensuring Cisco IOS QoS services operate in conjunction with tunneling and encryption on an
interIace. Cisco IOS soItware can classiIy packets and apply the appropriate QoS service before
the data is encrypted and tunneled. The QoS Ior VPN Ieature allows users to look inside a
packet so that packet classiIication is based on original port numbers and on source and
destination IP addresses. This allows service providers and enterprises to treat mission-critical
or multiservice traIIic with higher priority across their networks while using VPNs Ior secure
transport.
The QoS pre-classiIy Ieature is designed Ior tunnel interIaces. When the new Ieature is enabled,
the QoS Ieatures on the output interIace classiIy packets beIore encryption, allowing traIIic
Ilows to be adjusted in congested environments. The result is more eIIective packet tunneling.
This lesson describes QoS pre-classiIy, using QoS policies on VPN interIaces and conIiguring
and monitoring VPN QoS.
ReIevance
oI key importance to understand how traIIic can be classiIied in a VPN network.
Objectives
Upon completing this lesson, you will be able to use the QoS pre-classiIy Ieature to classiIy
GRE, IPSec, and L2F and L2TP encapsulated packets. This includes being able to meet these
objectives:
Describe the purpose oI pre-classiIication to support QoS in various VPN (IPSec, GRE,
L2TP) conIigurations
DiIIerentiate situations where pre-classiIication is appropriate Irom those where it is not
IdentiIy the diIIerent VPN applications (IPSec, GRE, L2TP) that support QoS pre-
classiIication
IdentiIy the Cisco IOS commands required to support IPSec, GRE, and L2TP QoS pre-
classiIication
IdentiIy the Cisco IOS commands used to monitor IPSec, GRE, and L2TP QoS pre-
classiIication
OutIine
© 2003, Cisco Systems, Inc. AII rights reserved. QOSv2.0-4-3
OutIine
· Overview
· ImpIementing QoS with Pre-CIassification
· QoS Pre-CIassify AppIications
· QoS Pre-CIassify DepIoyment Options
· Configuring QoS Pre-CIassify
· Monitoring QoS Pre-CIassify
· Summary
· Quiz
ImpIementing QoS with Pre-CIassification
This topic presents an overview and the purpose Ior the VPN QoS Ieature.
The QoS Ior virtual private networks (VPNs) Ieature (QoS pre-classiIy) is designed Ior tunnel
interIaces. When the Ieature is enabled, the QoS Ieatures on the output interIace classiIy
packets before encryption, allowing traIIic Ilows to be adjusted in congested environments. The
result is more eIIective packet tunneling.
The QoS pre-classiIy Ieature provides a solution Ior making Cisco IOS QoS services operate in
conjunction with tunneling and encryption on an interIace. Cisco IOS soItware can classiIy
packets and apply the appropriate QoS service beIore the data is encrypted and tunneled. The
QoS Ior VPN Ieature allows users to look inside the packet so that packet classiIication can be
done based on original port numbers and based on source and destination IP addresses. This
allows the service provider to treat mission-critical or multiservice traIIic with higher priority
across its network.
QoS pre-classiIy is supported Ior Generic Routing Encapsulation (GRE), IP in IP (IPIP)
tunnels, Layer 2 Tunneling Protocol (L2TP), Layer 2 Forwarding (L2F), Point-to-Point
Tunneling Protocol (PPTP), and IPSec.
QoS Pre-CIassify
· VPNs are growing in
popuIarity.
· The need to cIassify traffic
within a traffic tunneI is aIso
gaining importance.
· QoS for VPNs (QoS Pre-
cIassify) is a Cisco IOS
feature that aIIows packets to
be cIassified before tunneIing
and encryption occur.
· Pre-cIassification aIIows
traffic fIows to be adjusted in
congested environments.
QoS Pre-CIassify AppIications
This topic describes some oI the VPN applications that support QoS pre-classiIication.
When packets are encapsulated by a tunneling or encryption protocol, the original packet
header is no longer available Ior examination. From the QoS perspective, without the capability
to examine the original packet header, providing diIIerentiated levels oI service becomes
challenging. The main issue is that the QoS parameter normally Iound in the header oI the IP
packet should be reIlected in the tunnel packet header, regardless oI the type oI tunnel in use.
Consider the Iour primary tunneling protocols relevant to VPNs:
L2TP
IPSec
L2F
GRE
QoS Pre-CIassify Issues:
TunneI Headers
· When packets are encapsuIated by tunneI or encryption
headers, QoS features are unabIe to examine the originaI
packet headers and correctIy cIassify packets.
· Packets traveIing across the same tunneI have the same
tunneI headers, so the packets are treated identicaIIy if
the physicaI interface is congested.
GRE tunnels that are based on RFC 1702 allow any protocol to be tunneled in an IP packet.
Today, Cisco oIIers support Ior encapsulation oI data using either IPSec or GRE. In either oI
these scenarios, Cisco IOS soItware oIIers the ability to copy the IP ToS values Irom the packet
header into the tunnel header. This Ieature, which appears in Cisco IOS version 11.3T, allows
the ToS bits to be copied to the tunnel header when the router encapsulates the packets.
It allows routers between GRE-based tunnel endpoints to adhere to precedence bits, thereby
improving the routing oI premium service packets. Now, Cisco IOS QoS technologies, such as
policy routing, WFQ, and weighted random early detection (WRED), can operate on
intermediate routers between GRE tunnel endpoints.
GRE tunnels are commonly used to provide dynamic routing resilience over IPSec. Normal
IPSec conIigurations cannot transIer routing protocols, such as Enhanced Interior Gateway
Routing Protocol (EIGRP) and OSPF, or non-IP traIIic, such as Internetwork Packet Exchange
(IPX) and AppleTalk.
GRE TunneIing
· ToS cIassification of encapsuIated packets is based on
the tunneI header.
· By defauIt the ToS fieId of the originaI packet header is
copied to the ToS fieId of the GRE tunneI header.
· GRE tunneIs commonIy are used to provide dynamic
routing resiIience over IPSec adding a second Iayer of
encapsuIation.
IPSec does not deIine the speciIic security algorithms to use, but rather it provides an open
Iramework Ior implementing industry-standard algorithms.
Authentication Header (AH) provides strong integrity and authentication Ior IP datagrams
using Secure Hash Algorithm (SHA) or MD5 hash algorithm. It also can provide non-
repudiation. The Internet Assigned Numbers Authority (IANA) has assigned protocol number
51 to AH. Thus, in the presence oI an AH header with both tunnel mode and transport mode,
the IP header uses a value oI 51 in the protocol Iield.
With tunnel mode, the ToS byte value is copied automatically Irom the original IP header to the
tunnel header.
IPSec Authentication Header (AH)
· IPSec AH is for authentication onIy and does not perform
encryption.
· With tunneI mode, the ToS byte vaIue is copied
automaticaIIy from the originaI IP header to the tunneI
header.
· With transport mode, the originaI header is used and
therefore the ToS byte is accessibIe.
IPSec does not deIine the speciIic security algorithms to use, but rather it provides an open
Iramework Ior implementing industry-standard algorithms.
Encapsulating Security Payload (ESP) consists oI an unencrypted header Iollowed by encrypted
data and an encrypted trailer. ESP can provide both encryption and authentication.
As with AH, ESP supports SHA and MD5 hash algorithms Ior authentication. It supports Data
Encryption Standard (DES) and 3DES as encryption protocols. The ESP header is at least 8
bytes. The IANA has assigned protocol number 50 to ESP. Thus, in the presence oI (only) an
ESP header with both tunnel mode and transport mode, the IP header uses a value oI 50 in the
protocol Iield.
With tunnel mode, the ToS byte value is copied automatically Irom the original IP header to the
tunnel header.
QoS Pre-CIassify Issues: IPSec
EncapsuIating Security PayIoad (ESP)
· IPSec ESP supports both authentication and encryption.
· IPSec ESP consists of an unencrypted header foIIowed
by encrypted data and an encrypted traiIer.
· With tunneI mode, the ToS byte vaIue is copied
automaticaIIy from the originaI IP header to the tunneI
header.
QoS Pre-CIassify DepIoyment Options
This topic describes situations where pre-classiIication is appropriate.
ClassiIication deIines the process oI matching one or more Iields in a packet header Layer 2, 3,
or 4 and then placing that packet in a group or class oI traIIic. Using packet classiIication, you
can partition network traIIic into multiple priority levels or classes oI service.
When conIiguring IPSec with GRE, the simplest classiIication approach is to match on IP
precedence or DSCP values. Cisco IOS soItware release 11.3T introduced support Ior IPSec.
Along with this support was the ToS byte preservation Ieature in which the router automatically
copies the ToS header value Irom the original IP packet to the encapsulating IP header when
using IPSec in tunnel mode.
ToS byte preservation also applies to AH. Also note that ESP in transport mode retains the
original IP header and the original ToS value is transmitted even without ToS byte
preservation. II packets arrive at the router without a set IP precedence or DSCP values, you
can use class-based marking to re-mark the packet headers beIore encryption or encapsulation.
When the packets reach the egress interIace, the QoS output policy then can match and act on
the re-marked values.
Alternately, you may need to classiIy traIIic based on values other than IP precedence or
DSCP. For example, you may need to classiIy packets based on IP Ilow or Layer 3 inIormation,
such as source and destination IP address. To do so, you must use the QoS Ior VPNs Ieature
that you enable with the qos pre-classify command. This Ieature is available Ior Cisco 7100
series VPN routers and Cisco 7200 series routers (since 12.1(5)T) and Ior 2600 and 3600 series
routers (since 12.2(2)T).
Using QoS PoIicies on VPN Interfaces
· TunneI interfaces support
many of the same QoS
features as physicaI
interfaces.
· In VPN environments, a QoS
servi ce poIicy can be appIied
to the tunneI interface or to
the underIying physicaI
interface.
· The decision of whether to
configure the qos pre-
cIassify command depends
on which header is used for
cIassifi cation.
The qos pre-classify mechanism allows Cisco routers to make a copy oI the inner IP header
and to run a QoS classiIication beIore encryption, based on Iields in the inner IP header.
Without this Ieature the classiIication engine sees only a single encrypted and tunneled Ilow
because all packets traversing across the same tunnel have the same tunnel header and thus,
will receive the same treatment in the event oI congestion.
II your classiIication policy matches on the ToS byte, you do not need to use the qos pre-
classify command because the ToS value is copied to the outer header by deIault. In addition,
you can create a simple QoS policy that sorts traIIic into classes based on IP precedence.
However, diIIerentiating traIIic within a class and separating it into multiple Ilow-based queues
requires the qos pre-classify command.
Note: ToS byte copying is done by the tunneling mechanism and not by the qos pre-cIassify
command.
Using QoS PoIicies on
VPN Interfaces (Cont.)
Note: ToS byte copying is done by the tunneIing mechanism and not by the qos pre-cIassify command
Configuring QoS Pre-CIassify
This topic describes the Cisco IOS commands that are necessary to conIigure pre-classiIication.
The qos-pre-classify Cisco IOS command enables the QoS pre-classiIication Ieature. The
command can be applied to a tunnel interIace, a virtual template interIace, or a crypto map.
Configuring QoS Pre-CIassify
qos pre~classify qos pre~classify
router(config~if)#
· EnabIes the QoS pre-cIassification feature.
· This command is restricted to tunneI interfaces, virtuaI
tempIates, and crypto maps.
· Introduced for Ci sco 2600 and 3600 in Ci sco IOS 12.2(2)T.
GRF and IPIP Tunnels
router(config)# interface tunnel0
router(config~if)# qos pre~classify
L2F and L2TP Tunnels
router(config)# interface virtual~template1
router(config~if)# qos pre~classify
IPSec Tunnels
router(config)# crypto map secured~partner
router(config~crypto~map)# qos pre~classify
The Iigure shows the successIul conIiguration oI the qos pre-classify command.
The conIiguration oI the branch router is shown as Iollows:
On the S0/0 interIace there is an outgoing service-policy that sets the bandwidth oI the
interIace at 128 kbps and is policed at a rate oI 256 kbps. This policy is applied to any
match in the class map branch110.
Also, a traIIic tunnel has been built on interIace S0/0 (whose destination is HQ Ior this
branch ip address 205.51.11.5). It is on this traIIic tunnel that qos pre-classiIication has
been conIigured.
The example conIiguration also shows that qos pre-classiIy has been successIully enabled on
the crypto map named vpn. This crypto map has also been applied to S0/0. II qos pre-classiIy is
only enabled on the crypto map and not on the tunnel interIace, the router will see one Ilow
only, the GRE tunnel (protocol 47).
There are a Iew restrictions when conIiguring the QoS Ior VPNs Ieature:
The QoS Ior VPNs Ieature can be enabled on IP packets only.
II a packet is Iragmented aIter encryption, only the Iirst Iragment is pre-classiIied.
Subsequent Iragments might receive diIIerent classiIications. This behavior is consistent
with QoS classiIication oI non-tunneled Iragments.
InterIaces that run cascading QoS Ieatures, such as generic traIIic shaping or custom
queuing, are required to have QoS Ior VPNs enabled or disabled on all cascading Ieatures.
II the QoS Ior VPN Ieature is enabled on one cascading Ieature, the QoS Ior VPN Ieature
must be enabled on all cascading Ieatures. Similarly, iI the QoS Ior VPN Ieature is disabled
on one cascading Ieature, the QoS Ior VPN Ieature must be disabled on all cascading
Ieatures.
Configuring QoS Pre-CIassify (Cont.)
When conIiguring VPN QoS in conjunction with GRE or IPSec tunnel interIaces, the only
congestion management (queuing) strategy that can be employed on the tunnel interIace is
FIFO because the device on the other end oI the tunnel expects to receive packets in order.
Any packet not arriving in order, because oI queue management Ior example, will be
discarded at the tunnel endpoint.
Monitoring QoS Pre-CIassify
This topic describes the Cisco IOS commands that are necessary to monitor pre-classiIication.
The show interfaces command is used to veriIy that the QoS Ior VPN Ieature has been
enabled. VeriIied by examining the queuing strategy line in the above Iigure:
Queueing strategy. fifo (QOS pre-classification)
Monitoring QoS Pre-CIassify
show interfaces show interfaces
router>
· Di spIay traffic seen on a specific interface
· Used to verify that QoS pre-cIassi fy has been successfuIIy
enabIed
router>show interfaces
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 192.168.16.110/24
Tunnel source 205.51.11.110 (Serial0/0), destination 205.51.11.5
Tunnel protocol/transport GRF/IP, key disabled, sequencing disabled
Checksumming of packets disabled, fast tunneling enabled
Last input 00:00:04, output 00:00:04, output hang never
Last clearing of "show interface" counters 00:00:51
Queueing strategy: fifo (QoS pre~classification)
output queue 0/0, 0 drops; input queue 0/75, 0 drops
In the example the show crypto map command has been issued. This command will show
current crypto map conIiguration and also whether the QoS Ior VPN Ieature has been
successIully enabled on a crypto map.
show crypto map |interface interface , tag map-name|
Syntax Description
interface interface (Optional) Displays only the crypto map set applied to the
specified interface.
tag mapname (Optional) Displays only the crypto map set with the specified
.
Monitoring QoS Pre-CIassify (Cont.)
show crypto map (interface interface | tag map~name) show crypto map (interface interface | tag map~name)
router>
· Di spIays the current crypto map configuration
· Used to verify that QoS pre-cIassi fy has been successfuIIy
enabIed on a crypto map
router>show crypto map
Crpyto Map "vpn" 10 ipsec~isakmp
Peer = 205.51.11.5
Fxtended IP access list 110
access~list 110 permit gre host 205.51.11.110 host 205.51.11.5
Current peer:205.51.11.5
Security association lifetime: 4608000 kilobytes/86400 seconds
PFS (Y/N): N
Transform sets=¦ branch~vpn, }
QoS pre~classification
Summary
References
For more inIormation on QoS Pre-ClassiIy, reIer to 'ReIerence Guide to Implementing
Crypto and QoS¨ at the Iollowing URL:
http://www.cisco.com/warp/customer/105/crypto¸qos.pdI
For more inIormation on QoS Pre-ClassiIy, reIer to 'ConIiguring QoS Ior Virtual Private
Networks¨ at the Iollowing URL:
qcIvpn.pdI
Next Steps
Lab Exercise 4-3: ConIiguring QoS Pre-ClassiIy
Summary
· The QoS for VPNs (QoS pre-cIassi fy) feature is designed for
tunneI interfaces.
· When packets are encapsuIated by tunneI or encryption
headers, QoS features are unabIe to examine the originaI
packets headers and correctIy cIassify the pakcets.
· QoS Pre-cIassify i s enabIed by the qos pre-cIassify Ci sco IOS
command.
· qos pre-cIassify i s configured on tunneI interfaces, virtuaI
tempIates, and crypto maps.
· show interface command is used to verify if QoS Pre-cIassi fy
has been enabIed.
Quiz
Q1) When QoS pre-classiIy is enabled, the QoS Ieatures on the output interIace are ¸¸¸¸¸
beIore encryption?
A) marked
B) policed
C) shaped
D) classiIied
Q2) In GRE tunneling, by deIault the ToS Iield oI the original packet header is copied to the
¸¸¸¸¸ Iield oI the ToS Iield Ior GRE tunnel header.
A) COS
B) DSCP
C) ToS
D) IP precedence
Q3) Which oI the Iollowing Cisco IOS commands enables the QoS pre-classiIy Ieature?
A) crytpo map vpn
B) qos pre-classify
C) qos-pre-classify
D) crytpo map vpn ipsec-isakmp
Q4) At what conIiguration level is the QoS pre-classiIy Ieature enabled?
A) global
B) router
C) interIace
D) privileged
Q5) Which oI the Iollowing Cisco IOS commands is used to veriIy whether QoS pre-
classiIy is enabled?
A) qos pre-classify
B) show interface
C) show crypto map
D) crytpo map vpn ipsec-isakmp
Quiz Answer Key
Q1) D
ReIates to: Ìmplementing QoS with Pre-Classification
Q2) C
ReIates to: QoS Pre-Classify Applications
Q3) B
ReIates to: QoS Pre-Classify Deployment Options
Q4) C
ReIates to: Configuring QoS Pre-Classify
Q5) B
ReIates to: Monitoring QoS Pre-Classify
Configuring QoS Policy
Propagation Through BGP
Overview
The QoS Policy Propagation in Border Gateway Protocol (BGP |QPPB|) Ieature allows you to
classiIy packets based on access lists, BGP community lists, and BGP autonomous system (AS)
paths. The supported classiIication policies include IP precedence setting and the ability to tag
the packet with a QoS class identiIier internal to the router. AIter a packet has been classiIied,
you can use other QoS Ieatures such as CAR and WRED to speciIy and enIorce business
policies to Iit your business model.
This lesson describes the QPPB classiIication mechanism. QPPB Ieatures covered in this lesson
include a review oI CEF and the tasks and Cisco IOS commands that are required to conIigure
QPPB on Cisco routers.
ReIevance
oI key importance to understand the diIIerent ways that traIIic can be classiIied.
Objectives
Upon completing this lesson, you will be able to explain how to implement classiIication and
marking in an inter-domain network using QPPB. This includes being able to meet these
objectives:
Describe the QPPB mechanism
Describe the interaction between IP QoS and the Border Gateway Protocol
Describe the operation oI CEF
List the steps required to conIigure QPPB on Cisco routers
IdentiIy the Cisco IOS commands required to conIigure QPPB on Cisco routers
OutIine
OutIine
· Overview
· QoS PoIicy Propagation Through BGP
· IP QoS and BGP Interaction
· Cisco Express Forwarding
· QPPB Configuration Tasks
· Configuring QPPB
· Summary
· Quiz
QoS PoIicy Propagation Through BGP
This topic describes the QPPB Ieature, which propagates QoS policy via BGP.
BGP is an inter-domain routing protocol that exchanges reachability inIormation with other
BGP systems. The QoS policy propagation via the BGP Ieature allows classiIying packets
based on access lists, BGP community lists, and BGP AS paths.
The supported classiIication policies include IP precedence setting and the ability to tag the
packet with a QoS class identiIier internal to the router. AIter a packet has been classiIied, one
can use other QoS Ieatures such as policing, WRED, and traIIic shaping to speciIy and enIorce
business policies to Iit the business model.
The QoS policy propagation via BGP Ieature has the Iollowing enhancements:
QoS group ID: You can set an internal QoS group ID that can be used later to perIorm
policing or WFQ, based on the QoS group ID.
Source and destination address lookup: You can speciIy whether the IP precedence level
or QoS group ID used is obtained Irom the source (input) address or destination (output)
address entry in the route table.
QoS PoIicy Propagation Through BGP
· QPPB uses BGP attributes to advertise CoS to other
routers in the network.
· BGP communities are usuaIIy used to propagate CoS
information bound to IP networks.
· Packet cIassification poIicy can be propagated via BGP
without having to use compIex access Iists at each of a
Iarge number of border (edge) routers.
· A route map is used to transIate BGP information (for
exampIe, BGP community vaIue) into IP precedence or
QoS group.
· QPPB can onIy cIassify and mark inbound packets.
BGP propagates the CoS by encoding it into the Iollowing BGP attributes:
BGP communities attribute
AS path attribute
IP preIix attribute
Or any other BGP attribute
BGP can translate the selected BGP attribute into either:
IP precedence
QoS group
The QPPB Ieature requires that CEF and packet marking is enabled on interIaces.
BGP Marking
1. Propagate the CoS by encoding it into BGP attributes:
÷ BGP communities
÷ AS paths
÷ IP prefixes
÷ Any other BGP attribute
2. TransIate the seIected BGP attribute into either:
÷ IP precedence
÷ QoS group
3. EnabIe CEF and packet marking on interfaces
IP QoS and BGP Interaction
This topic describes the interaction between QoS and BGP.
When using QPPB, the IP QoS Ieature works independently Irom BGP routing. BGP is only
used to propagate the QoS policy.
In QBBP conIigurations, the network administrator speciIies whether to use IP precedence or
the QoS group ID obtained Irom the source (input) address or destination (output) address entry
in the route table.
You can speciIy either the input or output address.
QPPB works only on high-end routers:
Cisco 7200 series
Cisco 7500 series
Cisco 7000 series with the RSP 7000 and RSP 7000CI
Cisco 10000 series
Cisco 12000 series
IP QoS and BGP Interaction
· IP QoS features work independentIy of BGP
routing.
· BGP is used onIy to propagate poIicies for
source or destination IP prefixes through the
network.
· QPPB works onIy on high-end pIatforms.
Cisco Express Forwarding
This topic presents a review oI CEF switching on Cisco IOS platIorms.
When the router is initialized Ior CEF, two main tables are built inside the router:
The Forwarding InIormation Base (FIB), which lists all paths to all reachable networks,
together with the output interIace inIormation
The adjacency table, which lists all required next-hops on output interIaces
To enable scalable Iorwarding, CEF builds a Iorwarding table called the FIB. Contrary to
demand-switching methods, the FIB is not a small subset oI the routing table. The FIB is a Iull
extract oI the routing table, with all the Iorwarding parameters precalculated at the time oI FIB
creation, and updated with any topology (routing table) changes.
The second table is the adjacency table. This table contains all the Layer 2 next-hops, which are
currently being used by the router to Iorward traIIic.
The two tables are interconnected, so that every destination network is linked to its appropriate
local next-hop adjacency. Many destinations can be linked to the same next-hop adjacency,
removing redundancy and increasing manageability oI CEF tables. Moreover, a single
destination can point to multiple next-hop adjacencies, enabling Ilexible traIIic load balancing.
· The two main components of CEF operation:
÷ Forwarding Information Base
÷ Adjacency TabIes
· CEF was first introduced on the foIIowing pIatforms:
÷ Ci sco 7x00 series in 11.1CC
÷ AII RISC-based pIatforms in IOS 12.0
· QPPB is onIy supported on high-end routers (Cisco
7x00 and above)
The Iigure shows a sequence oI events when process switching and Iast switching are used Ior
destinations learned through BGP.
When a BGP update is received and processed, an entry is created in the routing table.
When the Iirst packet arrives Ior this destination, the router tries to Iind the destination in
the Iast-switching cache. Because it is not there, process switching has to switch the packet
when the process is run. The process perIorms a recursive lookup to Iind the outgoing
interIace. It may possibly trigger an ARP request or Iind the Layer 2 address in the Address
Resolution Protocol (ARP) cache. Finally, it creates an entry in the Iast-switching cache.
All subsequent packets Ior the same destination are Iast-switched:
The switching occurs in the interrupt code (the packet is processed immediately).
Fast destination lookup is perIormed (no recursion).
The encapsulation uses a pregenerated Layer 2 header that contains the destination as well as
Layer 2 source (MAC) address (no ARP request or ARP cache lookup is necessary).
Review: Standard IP Switching
The generation oI entries in the FIB table is not packet-triggered but change-triggered. When
something changes in the IP routing table, the change is also reIlected in the FIB table.
As the FIB contains the complete IP switching table, the router can make deIinitive decisions
based on the FIB. Whenever a router receives a packet that should be CEF-switched, but the
destination is not in the FIB, the packet is dropped.
The FIB table is also diIIerent Irom other Iast-switching caches in that it does not contain
inIormation about the outgoing interIace and the corresponding Layer 2 header. That
inIormation is stored in a separate tablethe adjacency table. This table is more or less a copy
oI the ARP cache, but instead oI holding only the destination MAC address, it holds the Layer
2 header (source and destination MAC address).
The Iigure illustrates how the CEF switching entries are built. When a route is added or
changed in the main routing table (Ior example, learned via BGP), a new FIB entry is created,
and the next hop is calculated via recursive lookups to the routing table (iI necessary). The FIB
entry is then linked to the next-hop adjacency entry, which provides the necessary Layer 2
inIormation used to Iorward the packet on the output medium.
Review: CEF Switching
In the Iigure above, the tables Irom the previous page are displayed, with the diIIerence that
BGP communities being translated to IP precedence and QoS group are inserted into the FIB
table also.
CEF Switching with QoS
Packet Marking
QPPB Configuration Tasks
This topic lists the conIiguration tasks required to enable the QPPB Ieature.
The tasks required to enable QPPB are as Iollows:
Create a route map(s) to set IP precedence or QoS group. The route-map command is used
to accomplish this task as Iollows:
route-map <route-map name> permit I0
match community <community-list>
set ip precedence <ip precedence value>
set ip qos-group <qos-group =>
Apply the route map to BGP routes that are in the BGP table. The table-map command is
used to accomplish this task as Iollows:
router bgp <as =>
table-map <route-map name>
Enable the required interIace(s) Ior packet marking. The bgp-policy command is used to
accomplish this task as Iollows:
interface X
bgp-policy <source | destination> ip-prec-map
QPPB Configuration Tasks
1. Create a route map to set IP precedence or
QoS group.
2. AppIy the route map to BGP routes transferred
to main IP routing tabIe.
3. EnabIe per-interface packet marking.
Configuring QPPB
This topic identiIies the Cisco IOS commands that are required to conIigure QPPB.
Use the route-map command to deIine a route map to match based on a bgp community list,
bgp as-path, or access-list and to set the ip precedence or qos-group. To set the precedence
value (and an optional IP number or IP name) in the IP header, use the set ip precedence route-
map conIiguration command. To leave the precedence value unchanged, use the no Iorm oI this
command.
set ip precedence ¡precedence [ name]
Syntax Description
precedence ] name A number or name that sets the precedence bits in the ÌP header.
The values for the argument and the corresponding
argument are listed in the following table from least to most
important.
Setting IP Precedence or QoS Group
in the IP Routing TabIe
table~map route~map~name table~map route~map~name
router(config~router)#
· Specifies the route map used to set additionaI routing tabIe
attributes
route~map name permit seq
match as~path path~list~number
match ip address access~list~number
match community community~list
set ip precedence precedence
set ip qos~group group
route~map name permit seq
match as~path path~list~number
match ip address access~list~number
match community community~list
set ip precedence precedence
set ip qos~group group
router(config)#
· Defines a route map to set ip precedence or qos-group
· Specifies IP precedence and QoS group vaIues in the routing
tabIe/FIB tabIe entry
The Iollowing table lists the values Ior the preceaence argument and the corresponding name
argument Ior precedence values in the IP header. They are listed Irom least to most important.
Precedence Name
0 routine
1 priority
2 immediate
3 flash
4 flash-override
5 critical
6 internet
7 network
To set a group ID that can be used later to classiIy packets, use the set qos-group QoS policy
map conIiguration command. To remove the group ID, use the no Iorm oI this command.
set qos-group group-id
Syntax Description
groupid Group ÌD number in the range from 0 to 99.
Note: To display QoS group information, use the show ip cef command.
Use the bgp table-map command to apply the route map to the BGP routing process. This will
populate the corresponding BGP routes in the IP routing table and Forwarding InIormation
Base (FIB) with the CoS (IP precedence and/or qos-group) inIormation. To modiIy metric and
tag values when the IP routing table is updated with BGP learned routes, use the table-map
command in address Iamily or router conIiguration mode. To disable this Iunction, use the no
Iorm oI the command.
table-map map-name
Syntax Description
map-name Route map name, from the route-map command.
AIter the IP routing table and the FIB table contain the CoS inIormation (IP precedence or QoS
group), CEF-based markings can be conIigured on the input interIaces by using the bgp-policy
interIace conIiguration command.
Using the bgp-policy interIace conIiguration command, CEF-based markings can be perIormed
based on the source or destination address oI an incoming packet. Use the source option to
mark packets sourced Irom a customer. Use the destination option to mark packets destined to a
customer.
The packets can be marked with the ip precedence or qos-group value Irom the FIB table. Use
the ip-prec-map option to mark the packets with ip precedence and use the ip-qos-map option
to mark the packets with qos-group.
EnabIe Per-Interface Packet Marking
bgp~policy ¦source | destination} ip~prec~map bgp~policy ¦source | destination} ip~prec~map
router(config~if)#
· Mark packets usi ng the IP precedence based on the packet
source address and/or destination address.
· If both source and destination are specified on an interface, the
software Iookup for the destination address occurs Iast and the
packet is re-marked based on the destination address.
bgp~policy ¦source | destination} ip~qos~map bgp~policy ¦source | destination} ip~qos~map
router(config~if)#
· Mark packets usi ng the QoS group ID based on the packet
source address and/or destination address.
bgp-policy ¦source [ destination] ¦ip-prec-map [ ip-qos-map]
Syntax Description
source The ÌP precedence bit or QoS group ÌD from the source address
entry in the route table
destination The ÌP precedence bit or QoS group ÌD from the destination
address entry in the route table
ip~prec~map QoS policy based on the ÌP precedence
ip~qos~map The QoS policy based on the QoS group ÌD
Note: Ìf you specify both source and destination on the interface, the software looks up the
source address in the routing table and classifies the packet based on the source address
first; then the software looks up the destination address in the routing table and reclassifies it
based on the destination address.
ExampIe: Configuration
router bgp ·0
table~map precedence~map
neighbor ?0.?0.?0.I remote-as I0
neighbor ?0.?0.?0.I send-community
!
ip bgp-community new-format
!
! Match community I and set the IP precedence to priority and
set the QoS group to I
route-map precedence-map permit I0
match community I
set ip precedence priority
set ip qos-group I
!
! Match community ? and set the IP precedence to immediate
route-map precedence-map permit ?0
match community ?
set ip precedence immediate
!
ip community-list I permit 80.I
ip community-list ? permit 80.?
!
interface HSSI S/0
no ip address
encapsulation frame-relay
!
interface HSSI S/0/0.I point-to-point
ip address ?0.?0.?0.I ?SS.?SS.?SS.0
bgp~policy source ip~prec~map
no ip mroute-cache
frame-relay interface-dlci ?0 IETF
In this example the community attribute is being matched and then the action is taken on those
attributes. II the community is 60:1 (ip community list 1) its IP precedence will be set to
priority and the qos group will be set to 1as speciIied in the route map precedence map.
II the community attribute is 60:2 (ip community list 2) its IP precedence will be set to
immediate.
The policy is then applied to the interIace HSSI 5/0/0/0.1, using the bgp-policy source
command. The ip-prec-map keyword indicates that the QoS policy is based on IP precedence.
ExampIe: Configuring QPPB
The Iigure shows an example oI conIiguring QPPB.
In a service provider network an end-to-end IP QoS solution must be created.
The requirements are:
Customer in AS 73 is a Premium customer
All packets to AS 73 shall be sent with IP precedence Ilash
Configuring QPPB
ExampIe
Create an end-to-end IP QoS soIution in a service
provider network:
· Customer in AS 73 is a Premium customer.
· AII packets to AS 73 shaII be sent with IP precedence .
· This exampIe iIIustrates destination-based ip precedence
marking using QPPB.
Because we are going to create an end-to-end QoS solution, the Iigure shows the Iirst step
requirements:
Routes that are received Irom AS 24 and destined Ior AS 73 will have IP precedence set to
flash on the NAP router (in AS 12).
Step 1: Distribute QoS Functions
This Iigure shows the second requirement:
Enable CEF-based marking on the NAP router serial interIace connecting to AS 24.
Step 2: SeIect QoS Mechanisms
This Iigure shows the third step requirement:
BGP routes that are received into AS 12 Irom AS 73 will be marked with a community
value oI 12:17 on the points oI presence (POP) router.
Community propagation will have to be conIigured on the POP router so that the
community value oI 12:17, set on the POP router, will be propagated to the NAP router.
All the BGP routes with a community oI 12:17 in the IP routing table and the FIB table on
the AS 12 NAP routers will contain the IP precedence Ilash.
Step 3: Design IndividuaI
QoS Mechanisms
The Iigure shows the conIiguration that is necessary to meet the requirement that routes coming
Irom AS 73 will be marked with the special community value oI 12:17.
ConIiguration on the POP router to mark BGP routes Irom AS 73 with the community value
12:17:
router bgp I?
neighbor I.?.·.4 remote-as I·
neighbor I.?.·.4 route-map Premium in
!
route-map Premium permit I0
set community 12:17 additive
Mark Routes Coming from AS 73
The Iigure shows the conIiguration that is necessary to propagate the special community value,
12:17, which has been added on the POP router and will be seen on the NAP router.
ConIiguration on the POP router to mark to propagate the community value (12:17) to the NAP
router:
router bgp I?
neighbor ?.·.4.S remote-as I?
neighbor ?.·.4.S send~community
Configure Community Propagation
The NAP router in AS 12 uses a route map to translate BGP community values into appropriate
IP precedence values. The Iigure illustrates how all BGP routes carrying BGP community
12:17 are tagged with IP precedence Ilash in the routing table and the FIB table. All other BGP
routes are tagged with IP precedence 0.
ConIiguration on the NAP router to set/change the IP precedence oI those BGP routes that
match the community value (12:17):
router bgp I?
table-map PremiumCheck
!
route-map PremiumCheck permit I0
match community II
set ip precedence flash
!
route-map PremiumCheck permit ?0
set ip precedence 0
!
ip community-list II permit I?.II
The conIiguration shows that iI the route map PremiumCheck matches the community attribute
oI 12:17, the corresponding packet will have its IP precedence changed to Ilash, as is required
in the example.
Set FIB TabIe Based on BGP
Community
The last conIiguration step is to enable CEF-based marking on NAP router in AS 12. This
example requires that all packets going to (destination-based marking) the customer (AS 73)
network be marked with IP precedence Ilash.
In this case, the AS 12 NAP router HSSI 0/0 interIace connects to AS 24. ThereIore, the bgp-
policy destination ip-prec-map command is conIigured under the HSSI 0/0 interIace to enable
destination-based CEF-based marking. All packets Irom AS 24 destined to the customer AS 73
will be marked with IP precedence Ilash.
QPPB marking is only available in combination with CEF switching. The global ip cef
command enables CEF switching on all interIaces that support CEF.
ConIiguration on the NAP router to conIigure CEF packet marking:
ip cef
!
interface hssi 0/0
bgp-policy destination ip-prec-map
Configure CEF Packet Marking
Summary
References
For more inIormation on QPPB, reIer to 'ClassiIication Overview¨ at the Iollowing URL:
qcIclass.pdI
For more inIormation on QPPB, reIer to 'Quality oI Service Policy Propagation via Border
Gateway Protocol¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios111/cc111/bgpprop.pdI
For more inIormation on conIiguring QPPB, reIer to 'ConIiguring QoS Policy Propagation
via Border Gateway Protocol¨ at the Iollowing URL:
qcIprop.pdI
Summary
· QPPB can onIy cIassify and mark inbound packets.
· When using QPPB QoS works independentIy from BGP
routing.
· CEF switching with QoS packet marking wiII popuIate the
FIB tabIe with IP precedence and QoS group vaIues.
· Route-maps are used to set IP precedence and QoS
group id.
· bgp-poIicy Cisco IOS command (interface IeveI) is used
to propagate the QoS poIicy via BGP.
Quiz
Q1) BGP translates the selected attribute into which two oI the Iollowing: (Choose two.)
A) BGP communities
B) DSCP value
C) IP precedence
D) QoS group
Q2) When using QPPB, BGP is used only to propagate QoS policies Ior which two oI the
Iollowing? (Choose two.)
A) COS value
B) DSCP value
C) Source IP PreIix
D) Destination IP PreIix
Q3) The FIB table (CEF cache) is diIIerent Irom other Iast-switching caches in that it does
not contain inIormation about the outgoing interIace and ¸¸¸¸¸.
A) IP address
B) adjacency pointer
C) corresponding L2 header
D) corresponding L3 header
Q4) Which oI the Iollowing is not a QPPB conIiguration task?
A) disable CEF
B) enable per-interIace packet marking
C) create a route map to set IP precedence or QoS group
D) apply route map to BGP routes transIerred to IP routing table
Q5) Which oI the Iollowing commands enable per-interIace packet marking?
A) bgp-policy
B) set qos group
C) set ip precedence
D) set packet-marking
Quiz Answer Key
Q1) C, D
ReIates to: QoS Policy Propagation Through BGP
Q2) C, D
ReIates to: ÌP QoS and BGP Ìnteraction
Q3) C
ReIates to: Cisco Express Forwarding
Q4) A
ReIates to: QPPB Configuration Tasks
Q5) A
ReIates to: Configuring QPPB
Configuring LAN Classification
and Marking
Overview
A switch may be the Iastest switch in the world, but iI you have many inputs to the switch and
Iewer outputs or have larger input pipes than output pipes, the switch will experience
congestion. At times oI congestion, iI the congestion management Ieatures are not in place,
packets will be dropped. When packets are dropped, retransmissions occur. When
retransmissions occur, the network load can increase. In networks that are already congested,
this can add to existing perIormance issues and potentially Iurther degrade perIormance. With
converging networks, congestion management is even more critical. Latency-sensitive traIIic
such as voice and video can be severely impacted iI delays are incurred. Simply adding more
buIIers to a switch will not necessarily alleviate congestion problems. Latency-sensitive traIIic
must to be switched as Iast as possible. First, you need to identiIy this important traIIic through
classiIication techniques, and then implement buIIer management techniques to avoid the
higher priority traIIic Irom being dropped during congestion.
This lesson will introduce the learner to classiIication and marking as it is implemented on
Cisco Catalyst switches. Topics covered include LAN classiIication and marking options and
platIorms, and conIiguring and monitoring LAN-based classiIication and marking.
ReIevance
oI major importance in the converged networks oI today.
Objectives
Upon completing this lesson, you will be able to describe LAN-based methods Ior
implementing classiIication and marking. This includes being able to meet these objectives:
Describe LAN-based classiIication and marking using a Layer 2 Catalyst workgroup switch
Describe QoS trust boundaries and their signiIicance in LAN-based classiIication and
marking
IdentiIy the diIIerent classiIication and marking options available on Cisco L2 and L3
switching platIorms
IdentiIy the Cisco IOS commands required to conIigure LAN-based classiIication and
marking
IdentiIy the Cisco IOS commands required to monitor LAN-based classiIication and
marking
OutIine
OutIine
· Overview
· LAN CIassification and Marking
· QoS Trust Boundaries
· LAN CIassification and Marking PIatforms
· Configuring LAN-Based CIassification and Marking
· Monitoring LAN-Based CIassification and Marking
· Summary
· Quiz
LAN CIassification and Marking
This topic provides an introduction to QoS classiIication and marking in a LAN environment.
© 2003, CiscoSystems, Inc. AII rights reserved. QOSv2.0-4-4
LAN CIassification and Marking
· CIassi fication and marking shouId typicaIIy be performed as
cIose to the source of the traffic as possibIe.
· Defining trust boundaries i s important when performing
cIassifi cation and marking in the LAN.
· For QoS marking transparency, mapping between Layer 2 and
Layer 3 cIassification schemes must be accompIished.
· Ci sco CataIyst switches have cIassification and marking
capabiIities and are ideaI Iocations for performing these criticaI
QoS functions.
· CIassi fication and marking mechanisms of workgroup switches
are based on DSCP and CoS, but compatibiIity with IP
precedence can be achieved as DiffServ i s backwards
compatibIe.
· OnIy ports that have been configured as ISL or 802.1Q trunks
can carry Layer 2 CoS vaIues.
In the Catalyst line oI multilayer switches is the capability to provide QoS at Layer 2 or
Layer 3, depending on the switch type. At Layer 2, the Irame uses CoS in 802.1p and Inter-
Switch Link (ISL). CoS uses 3 bits, just like IP precedence, and maps well Irom Layer 2 to
Layer 3, and vice versa.
The switches have the capability to diIIerentiate Irames based on CoS settings. II multiple
queues are present, Irames can be placed in diIIerent queues and serviced via weighted round
robin (WRR). This allows each queue to have diIIerent service levels.
ClassiIication is only perIormed on a Catalyst switch iI QoS has been globally enabled on the
switch.
QoS Trust Boundaries
This topic describes QoS trust boundaries and their signiIicance in LAN-based classiIication
and marking.
QoS Trust Boundaries in the LAN
· Benefits of appIying QoS at the edge of the network:
÷ AbiIity to cIassify and mark traffic immediateIy
÷ Minimizes upstream congestion
÷ Frees up router processing power
It is recommended that QoS be applied as close to the source oI the traIIic as possible.
Some oI the beneIits oI applying QoS at the edge (or close to the source oI the traIIic) are as
Iollows:
Ability to classiIy and mark traIIic immediately. This will reduce the upstream devices
CPU utilization oI the upstream device, thus reducing the possibility that priority traIIic,
such as voice, would be delayed at some point Iurther in the network.
Frees up router processing power.
© 2003, CiscoSystems, Inc. AII rights reserved. QOSv2.0-4-6
QoS Trust Boundary in the LAN
CIassify and Mark Where?
· Ci sco QoS modeI assumes that the CoS carried in a frame may
or may not be trusted by the network device.
· CIassi fication shouId be done as cIose to the edge as possibIe.
· End hosts Iike user PCs can mostIy not be trusted to tag a
packet priority correctIy.
ClassiIication should take place at the network edge, typically in the wiring closet or within
video endpoints or IP Phones themselves.
The Iigure demonstrates this with an IP telephony example. Packets can be marked as
important by using Layer 2 CoS settings in the user priority bits oI the 802.1p portion oI the
802.1p/Q Iield or the IP precedence/DSCP bits in the ToS/DS Iield in the IPv4 header. Cisco IP
Phones can mark voice packets as high priority using CoS as well as ToS. By deIault, the IP
Phone sends 802.1p tagged packets with the CoS and ToS set to a value oI 5.
Because most PCs do not have an 802.1Q-capable network interIace card (NIC), they send the
packets untagged. This means that the Irames do not have an 802.1p Iield. Also, unless the
applications running on the PC send packets with a speciIic CoS value, this Iield is zero. A
special case is where the TCP/IP stack in the PC has been modiIied to send all packets with a
ToS value other than zero. Typically, this does not happen and the ToS value is zero.
Even iI the PC is sending tagged Irames with a speciIic CoS value, Cisco IP Phones can zero
out this value beIore sending the Irames to the switch. This is the deIault behavior. Voice
Irames coming Irom the IP Phone have a CoS oI 5 and data Irames coming Irom the PC have a
CoS oI 0. When the switch receives these Irames, it can take into account these values Ior
Iurther processing based on its capabilities.
The switch uses its queues (available on a per-port basis) to buIIer incoming Irames beIore
sending them to the switching engine. (It is important to remember that input queuing comes
into play only when there is congestion.) The switch uses the CoS value(s) to put the Irames in
appropriate queues. The switch can also employ mechanisms, such as WRED, to make
intelligent drops within a queue (also known as congestion avoidance) and WRR to provide
more bandwidth to some queues than to others (also known as congestion management).
Connecting the IP Phone
· 802.1Q trunking between the switch and IP Phone for muItipIe VLAN
support (separation of voice/data traffic) is preferred.
· The 802.1Q header contains the VLAN information and the CoS 3-bit
fieId, which determines the priority of the packet.
· For most Cisco IP Phone configurations, traffic sent from the IP Phone
to the switch is trusted to ensure that voice traffic is properIy
prioritized over other types of traffic in the network.
· The trusted boundary feature uses CDP to detect an IP Phone and
otherwise disabIes the trusted setting on the switch port to prevent
misuse of a high-priority queue.
In a typical network, you connect a Cisco IP Phone to a switch port as shown in the Iigure.
TraIIic sent Irom the telephone to the switch is typically marked with a tag that uses the 802.1Q
header. The header contains the VLAN inIormation and the CoS 3-bit Iield, which determines
the priority oI the packet. For most Cisco IP Phone conIigurations, the traIIic sent Irom the
telephone to the switch is trusted to ensure that voice traIIic is properly prioritized over other
types oI traIIic in the network. By using the mls qos trust device cisco-phone and the mls qos
trust cos interIace conIiguration commands, you can conIigure the switch port to which the
telephone is connected to trust the CoS labels oI all traIIic received on that port.
LAN CIassification and Marking PIatforms
This topic will discuss several oI the Catalyst switches, highlighting their capabilities to
perIorm QoS Iunctions.
CataIyst 6500
With a Layer 2 switching engine and a policy Ieature card (PFC), QoS can classiIy traIIic that
is addressed to speciIied MAC address/VLAN pairs to be marked with a conIigured CoS value.
ClassiIication and marking with a Layer 2 switching engine uses Layer 2 CoS values.
ClassiIication and marking with a Layer 2 switching engine does not use or set Layer 3 IP
precedence or DSCP values. ClassiIication with a Layer 3 switching engine uses Layer 2, 3,
and 4 values. Marking with a Layer 3 switching engine uses Layer 2 CoS values and Layer 3 IP
precedence or DSCP values.
QoS schedules traIIic through the transmit queues based on CoS values and uses CoS-value-
based transmit-queue drop thresholds to avoid congestion in traIIic that is transmitted Irom
Ethernet ports. The implementation oI scheduling and congestion avoidance is hardware-
dependent, and with each speciIic platIorm diIIerent queue capabilities exist.
Queues are deIined as a number oI queues, the type oI queue and the number oI drop thresholds
per queue. Here are a Iew examples:
2q2t: Indicates two standard queues, each with two conIigurable tail-drop thresholds.
1p2q2t: Indicates one strict-priority queue and two standard queues, each with two
conIigurable WRED-drop thresholds.
1p3q1t: Indicates one strict-priority queue and three standard queues, each with one
conIigurable WRED-drop threshold (on 1p3q1t ports, each standard queue also has one
nonconIigurable tail-drop threshold).
and so on.
CIassification and Marking on
CataIyst Switches
With 1p3q1t, the three standard transmit queues each have one WRED-drop threshold and one
nonconIigurable tail-drop threshold.
Frames with CoS 5 go to the strict-priority transmit queue (queue 4), where the switch
drops Irames only when the buIIer is 100 percent Iull.
Frames with CoS 0 and 1 go to the low-priority standard transmit queue (queue 1).
Frames with CoS 2, 3, or 4 go to the medium-priority standard transmit queue (queue 2).
Frames with CoS 6 or 7 go to the high-priority standard transmit queue (queue 3).
CataIyst 4000
ClassiIication on the Catalyst 4000 is enabled only iI QoS is globally enabled on the switch. By
deIault, QoS is globally disabled and classiIication does not occur.
SpeciIy which Iields in the Irame or packet that you want to use to classiIy incoming traIIic.
For IP traIIic, you have the Iollowing classiIication options:
Trust the IP DSCP in the incoming packet (conIigure the port to trust DSCP), and assign
the same DSCP to the packet Ior internal use.
Trust the CoS value (iI present) in the incoming packet, and generate the DSCP by using
the CoS-to-DSCP map.
PerIorm the classiIication based on a conIigured IP standard or extended ACL, which
examines various Iields in the IP header. II no ACL is conIigured, the packet is assigned
the deIault DSCP based on the trust state oI the ingress port; otherwise, the policy map
speciIies the DSCP to assign to the incoming Irame.
A packet can be classiIied Ior QoS using multiple match criteria, and the classiIication can
speciIy whether the packet should match all oI the speciIied match criteria or at least one oI the
match criteria. To deIine a QoS classiIier, provide the match criteria using the 'match¨
statements in a class map. In the 'match¨ statements, speciIy the Iields in the packet to match
on, or use IP standard or IP extended ACLs.
During QoS processing, the switch represents the priority oI all traIIic with an internal DSCP
value:
During classiIication, QoS uses conIigurable mapping tables to derive the internal DSCP
Irom received CoS. These maps include the CoS-to-DSCP map.
During policing, QoS can assign another DSCP value (iI the packet is out oI proIile and the
policer speciIies a marked down DSCP value).
BeIore the traIIic reaches the scheduling stage, QoS uses the internal DSCP to select one oI
the Iour egress queues Ior output processing. The DSCP-to-egress queue mapping can be
conIigured using the qos map dscp to tx-queue command.
The CoS-to-DSCP and DSCP-to-CoS map have deIault values that might or might not be
appropriate Ior your network.
Each physical port has Iour transmit queues (egress queues). Each packet that needs to be
transmitted is enqueued to one oI the transmit queues. The transmit queues are then serviced
based on the transmit queue scheduling algorithm.
AIter the Iinal transmit DSCP is computed (including any markdown oI DSCP), the transmit
DSCP-to transmit-queue mapping conIiguration determines the transmit queue. The packet is
placed in the transmit queue oI the transmit port, determined Irom the transmit DSCP. Use the
qos map dscp to tx-queue command to conIigure the transmit DSCP to transmit queue
mapping.
The transmit queue 3 on each port can be conIigured as the priority queue using the priority
high tx-queue conIiguration command in the interIace conIiguration mode. When transmit
queue 3 is conIigured with higher priority, packets in transmit queue 3 are scheduled ahead oI
packets in other queues.
CataIyst 3550
Each Gigabit-capable Ethernet port has Iour egress queues, one oI which can be the egress
expedite or priority queue. II the expedite (priority) queue is enabled, WRR services it until it is
empty beIore servicing the other three queues. Ingress Irame or packet classiIication options
include:
Non-IP traIIic
Use the port deIault. II the Irame does not contain a CoS value, the switch assigns
the deIault port CoS value to the incoming Irame. Then, the switch uses the
conIigurable CoS-to-DSCP map to generate the internal DSCP value.
Trust the CoS value in the incoming Irame (conIigure the port to trust CoS). Then,
the switch uses the conIigurable CoS-to-DSCP map to generate the internal DSCP
value. Layer 2 ISL Irame headers carry the CoS value in the three least-signiIicant
bits oI the 1-byte user Iield. Layer 2 802.1Q Irame headers carry the CoS value in
the three most signiIicant bits oI the TCI Iield. CoS values range Irom 0 Ior low
priority to 7 Ior high priority.
The trust DSCP and trust IP precedence conIigurations are meaningless Ior non-IP
traIIic. II you conIigure a port with either oI these options and non-IP traIIic is
received, the switch assigns the deIault port CoS value and generates the internal
DSCP Irom the CoS-to-DSCP map.
PerIorm the classiIication based on the conIigured Layer 2 MAC ACL, which can
examine the MAC source address, the MAC destination address, and the Ethertype
Iield. II no ACL is conIigured, the packet is assigned the deIault DSCP oI 0, which
means best-eIIort traIIic; otherwise, the policy map speciIies the DSCP to assign to
the incoming Irame.
IP traIIic
Trust the IP DSCP in the incoming packet (conIigure the port to trust DSCP), and
assign the same DSCP to the packet Ior internal use. The IETF deIines the 6 most
signiIicant bits oI the 1-byte ToS Iield as the DSCP. The priority represented by a
particular DSCP value is conIigurable. DSCP values range Irom 0 to 63.
Trust the IP precedence in the incoming packet (conIigure the port to trust IP
precedence), and generate a DSCP by using the conIigurable IP-precedence-to-
DSCP map. The IP version 4 speciIication deIines the three most signiIicant bits oI
the 1-byte ToS Iield as the IP precedence. IP precedence values range Irom 0 Ior low
priority to 7 Ior high priority.
Trust the CoS value (iI present) in the incoming packet, and generate the DSCP by
using the CoS-to-DSCP map.
PerIorm the classiIication based on a conIigured IP standard or an extended ACL,
which examines various Iields in the IP header. II no ACL is conIigured, the packet
is assigned the deIault DSCP oI 0, which means best-eIIort traIIic; otherwise, the
policy map speciIies the DSCP to assign to the incoming Irame.
Class maps and policy maps
A class map is a mechanism that you use to name and to isolate a speciIic traIIic
Ilow (or class) Irom all other traIIic. The class map deIines the criteria that is used to
match against a speciIic traIIic Ilow to Iurther classiIy it; the criteria can include
matching the access group deIined by the ACL, matching a speciIic list oI DSCP or
IP precedence values, or matching a speciIic list oI VLAN IDs associated with
another class map that deIines the actual criteria (Ior example, to match a standard or
extended ACL). II you have more than one type oI traIIic that you want to classiIy,
you can create another class map and use a diIIerent name. AIter a packet is matched
against the class-map criteria, you Iurther classiIy it through the use oI a policy map.
A policy map speciIies which traIIic class to act on. Actions can include trusting the
CoS, DSCP, or IP precedence values in the traIIic class; setting a speciIic DSCP or
IP precedence value in the traIIic class; or speciIying the traIIic bandwidth
limitations and the action to take when the traIIic is out oI proIile. BeIore a policy
map can be eIIective, you must attach it to an interIace.
CIassification and Marking on
CataIyst 2950 Switches
· Port can be configured to
trust CoS, DSCP or Cisco-
Phone (defauIt = untrusted)
· Has defauIt CoS-to-DSCP
and DSCP-to-CoS maps
· Can set the defauIt CoS by
port
· Can use cIass-based
marking to set DSCP
· Limited ACLs-no port range
Cisco Catalyst 2950 series switches oIIer superior and highly granular QoS based on Layer 2
through Layer 4 inIormation to ensure that network traIIic is classiIied and prioritized, and that
congestion is avoided in the best possible manner.
Cisco Catalyst 2950 series switches can classiIy, reclassiIy, police (determine iI the packet is in
or out oI predetermined proIiles and aIIect actions on the packet), and mark or drop the
incoming packets beIore the packet is placed in the shared buIIer. Packet classiIication allows
the network elements to discriminate between various traIIic Ilows and enIorce policies based
on Layer 2 and Layer 3 QoS Iields.
The QoS implementation is based on the DiIIServ architecture, an emerging standard Irom the
IETF. This architecture speciIies that each packet is classiIied upon entry into the network. The
classiIication is carried in the IP packet header, using 6 bits Irom the deprecated IP ToS Iield to
carry the classiIication (class) inIormation.
ClassiIication can also be carried in the Layer 2 Irame:
Prioritization values in Layer 2 Irames
Layer 2 802.1Q Irame headers used in trunks except Ior native VLAN Irames.
Other Irame types cannot carry Layer 2 CoS values.
Prioritization bits in Layer 3 packets
Layer 3 IP packets with DSCP values 0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48, and
56 only.
The Catalyst 2950 switch supports Iour egress queues, which allow the network administrator
to be more discriminating in assigning priorities Ior the various applications on the LAN. Strict-
priority scheduling conIiguration helps ensure that time-sensitive applications (such as voice)
always Iollow an expedited path through the switch Iabric. WRR scheduling, another
signiIicant enhancement, ensures that lower-priority traIIic receives attention without
comprising the priority settings administered by a network manager. These Ieatures allow
network administrators to prioritize mission-critical, time-sensitive traIIic, such as voice (IP
telephony traIIic), ERP (Oracle, SAP, and so on), and CAD/CAM over less time-sensitive
applications such as FTP or e-mail (Simple Mail TransIer Protocol |SMTP|).
Actions at the egress interIace include queuing and scheduling:
Queuing evaluates the CoS value and determines which oI the Iour egress queues in which
to place the packet.
Scheduling services the Iour egress queues based on their conIigured WRR.
The Catalyst 2950 supports packet classiIication based on QoS ACLs as Iollows:
You can use IP standard, IP extended, and Layer 2 MAC ACLs to deIine a group oI
packets with the same characteristics (class). In the QoS context, the permit and deny
actions in the access control entries (ACEs) have diIIerent meanings than with security
ACLs.
II a match with a permit action is encountered (Iirst-match principle), the speciIied QoS-
related action is taken.
II no match with a permit action is encountered and all the ACEs have been examined, no
QoS processing occurs on the packet.
II multiple ACLs are conIigured on an interIace, the packet matches the Iirst ACL with a
permit action, and QoS processing begins.
ConIiguration oI a deny action is not supported in QoS ACLs on the switch.
AIter a traIIic class has been deIined with the ACL, you can attach a policy to it. A policy
might contain multiple classes with actions speciIied Ior each one oI them. A policy might
include commands to classiIy the class as a particular aggregate (Ior example, assign a DSCP)
or rate-limit the class. This policy is then attached to a particular port on which it becomes
eIIective.
You implement IP ACLs to classiIy IP traIIic by using the access-list global conIiguration
command; you implement Layer 2 MAC ACLs to classiIy Layer 2 traIIic by using the mac
access-list extended global conIiguration command.
In the case oI Irames that arrive without a CoS value (such as untagged Irames), these switches
support classiIication based on a deIault CoS value per port assigned by the network
administrator. AIter the Irames have been classiIied or reclassiIied using one oI the above
modes, they are assigned to the appropriate queue at the egress port.
Note: To use the features described in this chapter, you must have the enhanced software image
(EÌ) installed on your switch.
CataIyst 2950: Aggregate QoS ModeI
· QoS ACLs using Layer 2/3/4 Access ControI Parameters (ACPs)
÷ Source / Destination MAC Address, 16-bit Ethertype, Source / Destination IP
Address, TCP / UDP Source or Destination Port Number
· QoS-based on DSCP cIassification; Support for 13 wideIy used,
weII known DSCP vaIues (0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46,
48, and 56)
· CoS Override per port
The example in the illustration provides a quick synopsis oI what happens on the Catalyst 2950
regarding QoS.
On incoming packets, classiIication and reclassiIication are perIormed by identiIying packet
groups using either DSCP or CoS. Policing and metering, iI conIigured, are then perIormed on
the packets to ensure compliance to conIigure rates. Marking is the last action perIormed on
incoming packets based on the CoS-to-DSCP or DSCP-to-CoS mappings.
Outgoing packets are scheduled and queued Ior congestion control. There are 4 queues per port
and are scheduled based on WRR and strict priority scheduling.
DefauIt QoS Configuration:
CataIyst 2950 and 3550 Switches
· The defauIt port CoS vaIue is 0.
· The defauIt port trust state is "untrusted."
· The CoS vaIue of 0 is assigned to aII incoming packets.
· DefauIt CoS assignment to priority queues is:
÷ CoS 6 to 7: Queue 4
· DefauIt CoS assignment can be aItered during
configuration.
The deIault QoS settings Ior the Catalyst 2950 and 3550 switches is as Iollows:
The deIault port CoS value is 0.
The CoS value oI 0 is assigned to all incoming packets.
The deIault port trust state is untrusted. II a port is connected to an IP Phone, should change
the deIault port conIig to trust the CoS setting Irom the IP Phone using the mls qos trust
command.
No policy maps are conIigured.
No policers are conIigured.
DeIault CoS assignment to priority queues is:
CoS 6 to 7: Queue 4
CoS 4 to 5: Queue 3
CoS 2 to 3: Queue 2
CoS 0 to 1: Queue 1
Mapping TabIes:
CataIyst 2950 and 3550 Switches
· During QoS processing, the switch represents the priority of aII
traffic (incIuding non-IP traffic) with an internaI DSCP vaIue.
· During cIassification, QoS uses configurabIe mapping tabIes to
derive the internaI DSCP (a 6-bit vaIue) from received CoS vaIue.
· Before the traffic reaches the scheduIing stage, QoS uses the
configurabIe DSCP-to-CoS map to derive a CoS vaIue from the
internaI DSCP vaIue.
Actions at the egress interIace include queuing and scheduling:
Queuing evaluates the internal DSCP and determines which oI the Iour egress queues in
which to place the packet. The DSCP value is mapped to a CoS value, which selects one oI
the queues.
Scheduling services the Iour egress queues based on their conIigured WRR weights and
thresholds. One oI the queues can be the expedite queue, which is serviced until empty
beIore the other queues are serviced. Congestion avoidance techniques include tail drop
and WRED on Gigabit-capable Ethernet ports and tail drop (with only one threshold) on
10/100 Ethernet ports.
During QoS processing, the switch represents the priority oI all traIIic (including non-IP traIIic)
with an internal DSCP value:
During classiIication, QoS uses conIigurable mapping tables to derive the internal DSCP (a
6-bit value) Irom received CoS or IP precedence (3-bit) values. These maps include the
CoS-to-DSCP map and the IP-precedence-to-DSCP map.
On an ingress interIace conIigured in the DSCP-trusted state, iI the DSCP values are diIIerent
between the QoS domains, you can apply the conIigurable DSCP-to-DSCP-mutation map to the
interIace that is on the boundary between the two QoS domains.
During policing, QoS can assign another DSCP value to an IP or non-IP packet (iI the
packet is out oI proIile and the policer speciIies a marked down DSCP value). This
conIigurable map is called the policed-DSCP map.
BeIore the traIIic reaches the scheduling stage, QoS uses the conIigurable DSCP-to-CoS
map to derive a CoS value Irom the internal DSCP value. Through the CoS-to-egress-queue
map, the CoS values select one oI the Iour egress queues Ior output processing.
The CoS-to-DSCP, DSCP-to-CoS, and the IP-precedence-to-DSCP (Catalyst 3550 only) map
have deIault values that might or might not be appropriate Ior your network.
The deIault DSCP-to-DSCP-mutation (Catalyst 3550 only) map and the deIault policed-DSCP
map are null maps; they map an incoming DSCP value to the same DSCP value.
The DSCP-to-DSCP-mutation map is the only map you apply to a speciIic Gigabit-capable
Ethernet port or to a group oI 10/100 Ethernet ports.
All other maps apply to the entire switch.
Mapping TabIes ExampIe 1:
This Iigure provides an example oI a CoS value mapped to the DSCP value in a Catalyst 2950
switch.
The trust boundary has been established on the switch port to trust the CoS setting Irom the IP
Phone. By deIault, the CoS and DSCP value oI a packet coming Irom a Cisco IP Phone is set to
CoS 5 and DSCP EF (numeric 46).
On the output oI the switch, in the Layer 3 header, the DSCP will be set to 40 using the deIault
CoS-to-DSCP map.
Mapping TabIes ExampIe 2:
This Iigure shows the previous packet as it arrives at its destination aIter traversing the
network.
In this example, the switch port connecting to the router is set to trust DSCP. ThereIore, the
Layer 3 header will have a DSCP value oI 40 (Irom the previous slide) and as it traverses the
switch, its CoS value is set to 5 using the deIault DSCP-to-CoS map.
Configuring LAN-Based CIassification and
Marking
This topic identiIies the Cisco IOS commands that are required to conIigure LAN-based
classiIication and marking.
Configuring CIassification and
Marking on CataIyst 2950 Switches
mls qos trust (cos (pass~through dscp) | device cisco~
phone | dscp)
mls qos trust (cos (pass~through dscp) | device cisco~
phone | dscp)
Switch(config~if)#
· Configures the port to trust state on an interface.
· When a port is configured with trust DSCP and the incoming
packet is a tagged non-IP packet, the CoS vaIue for the packet is
set to 0, and the DSCP-to-CoS map is not appIied.
· If DSCP i s trusted, the DSCP fieId of the IP packet is not
modified, but it is stiII possibIe that the CoS vaIue of the packet
is modified according to the DSCP-to-CoS map.
mls qos cos ¦default~cos | override} mls qos cos ¦default~cos | override}
Switch(config~if)#
· Defines the defauIt cIass of service vaIue of a port or assigns
the defauIt CoS to aII incoming packets on the port.
This Iigure shows some oI the QoS conIiguration commands that are necessary Ior Catalyst
2950 switches. The deIaults Ior its interIaces are as Iollows:
The port is not trusted.
Pass-through mode is disabled.
Trusted boundary is disabled.
II no keyword is speciIied and the switch is running the EI, the deIault is dscp.
mls qos trust ¡cos ¡pass-through dscp] [ device cisco-phone [ dscp]
Syntax Description
cos (Optional) Specifies that the CoS bits in incoming frames are
trusted and derives the internal DSCP value from the CoS bits.
cos pass~through dscp (Optional) Configure the interface to classify ingress packets by
trusting the CoS value and to send packets without modifying the
DSCP value (pass-through mode).
device cisco~phone (Optional) Classify ingress packets by trusting the value sent from
the Cisco ÌP Phone (trusted boundary).
dscp (Optional) Classify ingress packets with packet DSCP values
(most significant 6 bits of the 8-bit service-type field). For non-ÌP
packets, the packet CoS value is set to 0. This keyword is
available only if your switch is running the EÌ software.
To deIine the deIault CoS value Ior an interIace, use the mls qos cos command. Use the no
Iorm oI this command to remove a prior entry. QoS assigns the CoS value speciIied with mls
qos cos interIace conIiguration command to untagged Irames received on trusted and untrusted
ports. The deIault cos value is 0.
mls qos cos cos-value
Syntax Description
cosvalue Default CoS value for the interface; valid values are from 0 to 7.
Configuring CIassification and Marking
on CataIyst 2950 Switches (Cont.)
mls qos map cos~dscp dscpl...dscp8 mls qos map cos~dscp dscpl...dscp8
Switch(config)#
· Defines the CoS-to-DSCP mapping.
· For dscp1...dscp8, enter eight DSCP vaIues that correspond to CoS
vaIues 0 to 7. Separate each DSCP vaIue with a space.
· The supported DSCP vaIues are 0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48,
and 56.
mls qos map dscp~cos dscp~list to cos mls qos map dscp~cos dscp~list to cos
Switch(config)#
· Defines the DSCP-to-CoS mapping.
· For dscp-Iist, enter up to 13 DSCP vaIues separated by spaces. Then
enter the to keyword. The supported DSCP vaIues are 0, 8, 10, 16, 18,
24, 26, 32, 34, 40, 46, 48, and 56.
· For cos, enter the CoS vaIue to which the DSCP vaIues correspond. The
CoS range is 0 to 7.
The commands listed in the Iigure show how to change the deIault CoS-to-DSCP and DSCP-
to-CoS mappings.
CoS-to-DSCP DefauIt Mapping
Marker VaIue
CoS Values 0 1 2 3 4 5 6 7
DSCP
Values
0 8 16 24 32 40 48 56
To deIine the ingress CoS-to-DSCP mapping Ior trusted interIaces, use the mls qos map cos-
dscp command. The CoS-to-DSCP map is used to map the CoS oI packets arriving on trusted
interIaces (or Ilows) to a DSCP where the trust type is trust-cos. This map is a table oI eight
CoS values (0 through 7) and their corresponding DSCP values. Use the no Iorm oI this
command to remove a prior entry.
mls qos map cos-dscp values
Syntax Description
values Eight DSCP values, separated by spaces, corresponding to the
CoS values; valid values are from 0 to 63.
DSCP-to-CoS DefauIt Mapping
Marker VaIue
DSCP
Values
0 8, 10 16, 18 24, 26 32, 34 40, 42 48 56
CoS Values 0 1 2 3 4 5 6 7
To deIine an egress DSCP-to-CoS mapping, use the mls qos map dscp-cos command. The
DSCP-to-CoS map is used to map the Iinal DSCP classiIication to a Iinal CoS. You use the
DSCP-to-CoS map to map DSCP values in incoming packets to a CoS value, which is used to
select one oI the Iour egress queues. The CoS map is written into the ISL header or 802.1Q tag
oI the transmitted packet on trunk interIaces and contains a table oI 64 DSCP values and the
corresponding CoS values. You can enter up to eight DSCP values separated by a space. You
can enter up to eight CoS values separated by a space. Use the no Iorm oI this command to
remove a prior entry.
mls qos map dscp-cos ascp-values to cos-values
Syntax Description
dscpvalues DSCP values; valid values are from 0 to 63.
to Defines mapping.
cosvalues CoS values; valid values are from 0 to 63.
This Iigure shows a conIiguration example on a Catalyst 2950 switch where the CoS-to-DSCP
map has been changed Irom the deIault.
The deIault map is:
Marker VaIue
CoS Values 0 1 2 3 4 5 6 7
DSCP
Values
0 8 16 24 32 40 48 56
And the map aIter conIiguration is:
Marker VaIue
CoS Values 0 1 2 3 4 5 6 7
DSCP
Values
0 10 18 26 34 46 48 56
Also we see that interIace has been set to trust the CoS value using the mls qos trust command
using both the cos and cisco-phone options. The result oI the conIiguration is that the switch
interIace to trust CoS only when a Cisco IP Phone is attached. The switch uses CDP to detect iI
a Cisco IP Phone is attached and also passes the voice VLAN ID inIormation to the Cisco IP
Phone using CDP.
The last command in the conIiguration is the switchport priority extend cos 0 command. The
switchport priority extend cos 0 interIace conIiguration command is used to enable the IP
Phone to override the CoS marking Irom the PC attached to the IP Phone with a CoS value
oI 0.
Use the switchport priority extend interIace conIiguration command to set a port priority Ior
the incoming untagged Irames or the priority oI Irames received by the IP Phone connected to
the speciIied port. Use the no Iorm oI this command to return to the deIault setting.
switchport priority extend ¦cos value [ trust}
Syntax Description
cos value Set the ÌP Phone port to override the priority received from PC or
the attached device.
The CoS value is a number from 0 to 7. 7 is the highest priority.
The default is 0.
trust Set the ÌP Phone port to trust the priority received from PC or the
attached device.
CIassification and marking can aIso be performed
using MQC (cIass maps and poIicy maps)
1. Create an IP standard or extended ACL for IP traffic or a
Layer 2 MAC ACL for non-IP traffic.
2. Create a cIass map and define the match criterion to
cIassify traffic.
3. Create a service poIicy to perform the appropriate QoS
action (mark, poIice, and so on).
4. AppIy the service poIicy to a switch interface.
A class map is a mechanism that you use to isolate and name a speciIic traIIic Ilow (or class)
Irom all other traIIic. The class map deIines the criteria used to match against a speciIic traIIic
Ilow to Iurther classiIy it; the criteria can include matching the access group deIined by the
ACL. II you have more than one type oI traIIic that you want to classiIy, you can create another
class map and use a diIIerent name. AIter a packet is matched against the class-map criteria,
you Iurther classiIy it through the use oI a policy map.
A policy map speciIies which traIIic class to act on. Actions can include setting a speciIic
DSCP value in the traIIic class or speciIying the traIIic bandwidth limitations and the action to
take when the traIIic is out oI proIile. BeIore a policy map can be eIIective, you must attach it
to an interIace.
You create a class map by using the class-map global conIiguration command or the class
policy-map conIiguration command. You should use the class-map global conIiguration
command when the map is shared among many ports. When you enter the class-map global
conIiguration command, the switch enters the class-map conIiguration mode. In this mode, you
deIine the match criterion Ior the traIIic by using the match class-map conIiguration command.
You create and name a policy map by using the policy-map global conIiguration command.
When you enter this command, the switch enters the policy-map conIiguration mode. In this
mode, you speciIy the actions to take on a speciIic traIIic class by using the class policy-map
conIiguration or set policy-map class conIiguration command. To make the policy map
eIIective, you attach it to an interIace by using the service-policy interIace conIiguration
command.
The policy map can also contain commands that deIine the policer, the bandwidth limitations oI
the traIIic, and the action to take iI the limits are exceeded.
You use the class-map global conIiguration command to isolate a speciIic traIIic Ilow (or
class) Irom all other traIIic and to name it. The class map deIines the criteria to use to match
against a speciIic traIIic Ilow to Iurther classiIy it. Match statements can only include ACLs.
The match criterion is deIined with one match statement entered within the class-map
conIiguration mode.
A policy map speciIies which traIIic class to act on. Actions can include trusting the CoS or
DSCP values in the traIIic class; setting a speciIic DSCP value in the traIIic class; and
speciIying the traIIic bandwidth limitations Ior each matched traIIic class (policer) and the
action to take when the traIIic is out oI proIile (marking).
A policy map also has these characteristics:
A policy map can contain multiple class statements, each with diIIerent match criteria and
policers.
A separate policy-map class can exist Ior each type oI traIIic received through an interIace.
You can attach only one policy map per interIace in the input direction.
access~list access~list~number ¦deny | permit |
remark} ¦source source~wildcard | host source | any}
access~list access~list~number ¦deny | permit |
remark} ¦source source~wildcard | host source | any}
Switch(config)#
· Configures a standard IP access controI Iist that is based on source
address onIy.
· The defauIt standard ACL is aIways terminated by an impIicit deny
statement for aII packets.
access~list access~list~number ¦deny | permit | remark} protocol
¦source source~wildcard | host source | any} (operator port)
¦destination destination~wildcard | host destination | any}
(operator port) (dscp dscp~value) (time~range time~range~name)
access~list access~list~number ¦deny | permit | remark} protocol
¦source source~wildcard | host source | any} (operator port)
¦destination destination~wildcard | host destination | any}
(operator port) (dscp dscp~value) (time~range time~range~name)
Switch(config)#
· Configures an extended IP access controI Iist that can be based on
source, destination, port, DSCP vaIue, or a time range.
· The defauIt extended ACL is aIways terminated by an impIicit deny
statement for aII packets.
You can use IP standard, IP extended, and Layer 2 MAC ACLs to deIine a group oI packets
with the same characteristics (class). In the QoS context, the permit and deny actions in the
ACEs have diIIerent meanings than with security ACLs:
II a match with a permit action is encountered (Iirst-match principle), the speciIied QoS-
related action is taken.
II no match with a permit action is encountered and all the ACEs have been examined, no
QoS processing occurs on the packet.
II multiple ACLs are conIigured on an interIace, the packet matches the Iirst ACL with a
permit action, and QoS processing begins.
ConIiguration oI a deny action is not supported in QoS ACLs on the switch.
Use the standard version oI the access-list global conIiguration command to conIigure a
standard IP ACL. Use the no Iorm oI this command to remove a standard IP ACL.
access-list access-list-number ¦deny [ permit [ remark] ¦source source-wildcard [ host source
[ any]
Syntax Description
accesslistnumber Number of an ACL, from 1 to 99 or from 1300 to 1999.
deny Deny access if conditions are matched.
permit Permit access if conditions are matched.
remark ACL entry comment up to 100 characters.
source sourcewildcard
| host source | any
Define a source ÌP address and wildcard.
The source is the source address of the network or host from
which the packet is being sent, specified in one of these ways:
The 32-bit quantity in dotted-decimal format. The source-
wildcard applies wildcard bits to the source.
The keyword host, followed by the 32-bit quantity in dotted-
decimal format, as an abbreviation for source and source-
wildcard of source 0.0.0.0.
The keyword any as an abbreviation for source and source-
wildcard of 0.0.0.0 255.255.255.255. You do not need to enter
a source-wildcard.
Use the extended version oI the access-list global conIiguration command to conIigure an
extended IP ACL. Use the no Iorm oI this command to remove an extended IP ACL.
access-list access-list-number ¦deny [ permit [ remark] protocol ¦source source-wildcard [
host source [ any] ¡operator port] ¦destination destination-wildcard [ host destination [ any]
¡operator port] ¡dscp dscp-value] ¡time-range time-range-name]
Syntax Description
accesslistnumber Number of an ACL, from 100 to 199 or from 2000 to 2699.
protocol Name of an ÌP protocol.
protocol can be ip, tcp, or udp.
deny Deny access if conditions are matched.
permit Permit access if conditions are matched.
remark ACL entry comment up to 100 characters.
source sourcewildcard
| host source | any
Define a source ÌP address and wildcard.
The source is the source address of the network or host from
which the packet is being sent, specified in one of these ways:
The 32-bit quantity in dotted-decimal format. The source-
wildcard applies wildcard bits to the source.
decimal format, as an abbreviation for source and source-
wildcard of source 0.0.0.0.
The keyword any as an abbreviation for source and source-
wildcard of 0.0.0.0 255.255.255.255. You do not need to enter
a source-wildcard.
destination
destinationwildcard |
host destination | any
Define a destination ÌP address and wildcard.
The destination is the destination address of the network or host
from which the packet is being sent, specified in one of these
ways:
The 32-bit quantity in dotted-decimal format. The destination-
wildcard applies wildcard bits to the destination.
decimal format, as an abbreviation for destination and
destination-wildcard of source 0.0.0.0.
The keyword any as an abbreviation for destination and
destination-wildcard of 0.0.0.0 255.255.255.255. You do not
need to enter a destination-wildcard.
operator port (Optional) Define a source or destination port.
The operator can be only eq (equal).
Ìf operator is after the source ÌP address and wildcard, conditions
match when the source port matches the defined port.
Ìf operator is after the destination ÌP address and wildcard,
conditions match when the destination port matches the defined
port.
The port is a decimal number or name of a Transmission Control
Protocol (TCP) or User Datagram Protocol (UDP) port. The
number can be from 0 to 65535.
Use TCP port names only for TCP traffic.
Use UDP port names only for UDP traffic.
dscp dscpvalue (Optional) Define a Differentiated Services Code Point (DSCP)
value to classify traffic.
For the dscp-value, enter any of the 13 supported DSCP values
(0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48, and 56), or use the
question mark (?) to see a list of available values.
time~range timerange
name
(Optional) For the time-range keyword, enter a meaningful name
to identify the time range. For a more detailed explanation of this
keyword, refer to the software configuration guide.
class~map class~map~name class~map class~map~name
Switch(config)#
· Creates a cIass map to be used for matching packets.
· OnIy one match criterion per cIass map is supported. For
exampIe, when defining a cIass map, onIy one match command
can be entered.
match ¦access~group acl~index | access~group name acl~name
| ip dscp dscp~list}
match ¦access~group acl~index | access~group name acl~name
| ip dscp dscp~list}
Switch(config~cmap)#
· Defines the match criteria to cIassify traffic.
· OnIy IP access groups, MAC access groups, and cIassification
based on DSCP vaIues are supported.
MQC class maps can also be used on Catalyst 2950 switches Ior packet classiIication purposes.
However the match command used in conjunction with the class map has diIIerent parameters
when executed on a Catalyst switch.
Use the match class-map conIiguration command to deIine the match criteria to classiIy traIIic.
Use the no Iorm oI this command to remove the match criteria.
match ¦access-group acl-inaex , access-group name acl-name , ip dscp dscp-list}
Syntax Description
access-group acl-index Number of an ÌP standard or extended ACL.
For an ÌP standard ACL, the ACL index range is 1 to 99 and 1300
to 1999. For an ÌP extended ACL, the ACL index range is 100 to
199 and 2000 to 2699.
access~group name acl-
name
Name of an ÌP standard or extended ACL or name of an
extended MAC ACL.
Note The ACL name must begin with an alphabetic character to
prevent ambiguity with numbered ACLs. A name also cannot
contain a space or quotation mark.
ip dscp dscplist List of up to eight DSCP values for each match statement to
match against incoming packets. Separate each value with a
space. The supported DSCP values are 0, 8, 10, 16, 18, 24, 26,
32, 34, 40, 46, 48, and 56.
Switch(config)#
· Creates or modifies a poIicy map that can be attached to muItipIe
interfaces
class class~map~name (access~group name acl~index~or~name) class class~map~name (access~group name acl~index~or~name)
Switch(config~pmap)#
· Defines a traffic cIassification for the poIicy to act on using the cIass-
map name or access group
set ip dscp new~dscp set ip dscp new~dscp
Switch(config~pmap~c)#
· Used to mark packets with a new DSCP vaIue. Supported DSCP vaIues
are 0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48, and 56
Recall that a policy map creates or modiIies a policy that can be attached to multiple interIaces.
The class command deIines traIIic classiIication Ior the policy to act on based on the class map
or the access group. Use the class policy-map conIiguration command to deIine a traIIic
classiIication Ior the policy to act on using the class map name or access group. Use the no
Iorm oI this command to delete an existing class map.
class class-map-name |access-group name acl-inaex-or-name|
Syntax Description
access~group name acl-
index-or-name
(Optional) Number or name of an ÌP standard or extended ACL or
name of an extended MAC ACL. For an ÌP standard ACL, the
index range is 1 to 99 and 1300 to 1999; for an ÌP extended ACL,
the index range is 100 to 199 and 2000 to 2699.
Use the set policy-map class conIiguration command to classiIy IP traIIic by setting a DSCP
value.
set ip dscp new-ascp
Syntax Description
newdscp New DSCP value assigned to the classified traffic.
The supported DSCP values are 0, 8, 10, 16, 18, 24, 26, 32, 34,
40, 46, 48, and 56.
service~policy input policy~map~name service~policy input policy~map~name
Switch(config~if)#
· AppIies a poIicy map defined by the poIicy-map command to the
input of a particuIar interface
mac access~list extended maclist1
permit host 0001.0000.0001 host 0002.0000.0001
!
class~map macclass1
match access~group name maclist1
!
policy~map macpolicy1
class macclass1
set ip dscp 26
!
interface gigabitethernet0/1
switchport mode trunk
mls qos trust cos
service~policy input macpolicy1
The last step in conIiguring a policy is to apply the policy to the interIace.
In the above example an extended access-list has been created Ior a mac address, maclist1. A
class-map, macclass1 has been created that will match any MAC address permitted by the
access-list maclist1.
II there is a match Ior the class map macclass1 the DSCP Iield will be set to 26 as deIined in the
policy-map macpolicy1.
This policy map has been implemented on the gigabit Ethernet port 0/1 Ior incoming packets.
Monitoring LAN-Based CIassification and
Marking
This topic describes some oI the Cisco IOS commands that can be used to monitor QoS on
Catalyst switches.
Monitoring QoS on
show mls qos interface (interface~id) (policers) show mls qos interface (interface~id) (policers)
Switch>
Switch> show mls qos interface fastethernet0/1
FastFthernet0/1
trust state:trust cos
trust mode:trust cos
CoS override:dis
default CoS:0
pass~through:none
trust device:cisco~phone
AIter QoS has been conIigured on a Catalyst switch, the network administrator will want to
veriIy proper operation oI QoS and the policies they may have conIigured. In the example, we
see that the trust state has been set Ior CoS and that the deIault value oI CoS is 0.
Use the show mls qos interface user EXEC command to display QoS inIormation at the
interIace level.
show mls qos interface ¡interface-id] |policers]
Syntax Description
interfaceid (Optional) Display QoS information for the specified interface.
policers (Optional) Display all the policers configured on the interface,
their settings, and the number of policers unassigned (available
only when the switch is running the EÌ software).
Monitoring QoS on
CataIyst 2950 Switches (Cont.)
show mls qos maps (cos~dscp | dscp~cos) show mls qos maps (cos~dscp | dscp~cos)
Switch>
· DispIays QoS mapping information
Switch> show mls qos maps
Dscp~cos map:
dscp: 0 8 10 16 18 24 26 32 34 40 46 48 56
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cos: 0 1 1 2 2 3 7 4 4 5 5 7 7
Cos~dscp map:
cos: 0 1 2 3 4 5 6 7
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dscp: 0 8 16 24 32 40 48 56
Another important monitoring command is shown above. The show mls qos maps command
will display the CoS-to-DSCP and DSCP-to-CoS mappings.
Use the show mls qos maps user EXEC command to display QoS mapping inIormation. Maps
are used to generate an internal DSCP value, which represents the priority oI the traIIic.
show mls qos maps |cos-dscp [ dscp-cos]
Syntax Description
cos~dscp (Optional) Display CoS-to-DSCP map.
dscp~cos (Optional) Display DSCP-to-CoS map.
Summary
Summary
· QoS cIassification and marking on workgroup switches
are based on DiffServ and CoS.
· On most CataIyst switches if a frame does not contain a
CoS vaIue the switch defauIt CoS is assigned.
· For most Cisco IP Phone configurations, the traffic sent
from the teIephone to the switch is trusted to ensure that
voice traffic is properIy prioritized.
· CoS-to-DSCP and DSCP-to-CoS mappings can be
manuaIIy configured.
· Use the show mIs qos interface command to dispIay
generaI QoS information.
References
For more inIormation on classiIication and marking on the Catalyst 2950, reIer to
'ConIiguring QoS¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2950/12111yj4/lrescg/swqos.htm
For more inIormation on conIiguring classiIication and marking on the Catalyst 2950, reIer
to 'LAN Based Packet ClassiIication¨ at the Iollowing URL:
http://www.cisco.com/application/pdI/en/us/guest/products/ps628/c1051/ccmigration¸0918
6a0080150b6c.pdI
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat4000/rel7¸1/conIig/qos.htm
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw¸7¸6/conIg¸gd/qos.htm
Next Steps
Lab Exercise 4-4: LAN-Based Packet ClassiIication and Marking
Quiz
Q1) II multiple queues are present, Irames can be placed in diIIerent queues and serviced
via ¸¸¸¸¸.
A) Weighted Fair Queue
B) Weighted Round Robin
C) CB-Weighted Fair Queue
D) Weighted Random Early Detection
Q2) What is the deIault CoS value as used by Cisco IP Phones Ior voice packets?
A) 0
B) 3
C) 5
D) 7
Q3) The deIault CoS value on Catalyst 2950 and 3550 switches is ¸¸¸¸¸.
A) 0
B) 3
C) 5
D) 7
Q4) The command to assign a deIault CoS value on a Catalyst switch is ¸¸¸¸¸.
A) mls qos
B) qos cos
C) mls qos cos
D) qos mls cos
Q5) The command to display the CoS-to-DSCP and DSCP-to-CoS maps is ¸¸¸¸¸.
A) show maps
B) show mls maps
C) show qos maps
D) show mls qos maps
Quiz Answer Key
Q1) B
ReIates to: LAN-Based Classification and Marking
Q2) C
ReIates to: QoS Trust Boundaries
Q3) A
ReIates to: LAN Classification and Marking Platforms
Q4) C
ReIates to: Configuring LAN-Based Classification and Marking
Q5) D
ReIates to: Monitoring LAN-Based Classification and Marking
Module Assessment
Overview
Quiz: CIassification and Marking
Objectives
Explain the purpose oI classiIication and marking and how they can be used to deIine a
QoS service class
Use MQC CLI commands to classiIy packets
Use class-based marking to assign packets to a speciIic service class
Use NBAR to discover network protocols and applications, and to classiIy packets
Use the QoS pre-classiIy Ieature to classiIy GRE, IPSec, and L2F and L2TP encapsulated
packets
Explain how to implement classiIication and marking in an interdomain network using
QPPB
Describe LAN-based methods Ior implementing classiIication and marking
Instructions
Step 1 Answer all questions in this quiz by selecting the best answer(s) to each question
Step 2 VeriIy your results against the answer key located at the end oI this section
Step 3 Review the topics in this module that relates to the questions that you answered
incorrectly.
Q1) ClassiIication oI packets should occur ¸¸¸¸¸.
A) at the distribution layer
B) anywhere in the core oI the network
C) as close to the source oI the traIIic as possible
D) as close to the destination oI the traIIic as possible
Q2) To utilize a class map, QoS must be reIerenced through the use oI ¸¸¸¸¸.
A) route map
B) access list
C) policy map
D) service map
Q3) What is a requirement Ior using CB marking?
A) CEF must be enabled
B) CEF must be disabled
C) CEF can only be used on serial interIaces
D) CEF can only be used on Ethernet interIaces
Q4) What is the MQC Ieature that allows traIIic to be classiIied by a packet sub-port
number?
A) LDPM
B) NBAR
C) service maps
D) service classes
Q5) The QoS Ior VPN Ieature is designed to operate on ¸¸¸¸¸.
A) logical interIaces
B) loopback interIaces
C) tunnel interIaces
D) physical interIaces
Q6) Which oI the Iollowing is the proper command that will allow Cisco routers to make a
copy oI the inner IP header and to run a QoS classiIication beIore encryption based on
Iields in the inner IP header?
A) qos classify
B) qos pre-classify
C) qos nbar classify
D) qos vpn classify
Q7) Which oI the Iollowing commands will modiIy metric and tag values when the IP
routing table is updated with BGP learned routes?
A) table-map
B) bgp-policy
C) map bpg ip
D) bgp table-map
Q8) Which oI the Iollowing commands will enable the propagation oI the QoS policy via
BGP on an interIace?
A) table-map
B) bgp-policy
C) bgp send-policy
D) bgp policy-propagation
Q9) Which oI the Iollowing commands will display both the CoS-to-DSCP and DSCP-to-
CoS mappings on a Catalyst switch?
A) show mls maps
B) show mls qos maps
C) show mls maps both
D) show qos mls maps both
Scoring
or better.
Q1) C
ReIates to: Classification and Marking Overview
Q2) C
ReIates to: Using MQC Classification
Q3) A
ReIates to: Using MQC for Class-Based Marking
Q4) B
ReIates to: Using NBAR for Classification
Q5) C
ReIates to: QoS Pre-Classify
Q6) B
ReIates to: QoS Pre-Classify
Q7) A
ReIates to: Configuring QoS Policy Propagation Through BGP
Q8) B
ReIates to: Configuring QoS Policy Propagation Through BGP
Q9) B
ReIates to: Configuring LAN Classification and Marking
ModuIe Summary
ClassiIication is the process oI identiIying traIIic and categorizing it into diIIerent classes.
Packet classiIication allows some packets to be handled more quickly or with a higher priority
than other packets. Applications such as voice typically need to be treated Iaster than a Iile
transIer.
ClassiIication uses a traIIic descriptor to categorize a packet within a speciIic group to deIine
that packet. Typically, used traIIic descriptors include: CoS (ISL, 802.1Q) incoming interIace,
IP precedence, DSCP, QoS group ID, MPLS experimental bits, Frame Relay DE bit, ATM CLP
bit, source or destination address, or application.
Marking a packet or Irame with its classiIication allows network devices to easily distinguish
the marked packet or Irame. Marking is a useIul Ieature in that it allows network devices to
easily identiIy packets or Irames as belonging to a speciIic class. AIter packets have been
identiIied as belonging to a speciIic class, QoS mechanisms can be uniIormly applied to ensure
compliance with administrative QoS policies.
Packet classiIication can be implemented using such tools MQC class maps and policy maps;
NBAR, QoS pre-classiIy (VPN QoS), QPPB.
ClassiIication and Marking can be done at the network or link layer.
ModuIe Summary
· CIassification is a criticaI QoS component that recognizes
and distinguishes between different traffic streams.
Without cIassification, aII packets are treated
the same.
· Marking is a QoS component that "coIors" a packet so it
can be identified and distinguished from other packets in
QoS treatment.
· CIassification can be achieved using a variety of
mechanisms incIuding: CoS (ISL, 802.1Q), IP precedence,
DSCP, QoS group, MPLS experimentaI bits, Frame ReIay
DE bit and ATM CLP bit.
· Many different mechanisms exist to perform
cIassification and marking incIuding: MQC, cIass maps,
cIass-based marking, NBAR, QoS pre-cIassify, QPPB, and
LAN-based CoS marking.
ModuIe 5
Overview
Congestion can occur in many diIIerent locations within a network and is the result oI many
Iactors including oversubscription, insuIIicient packet buIIers, traIIic aggregation points,
network transit points, and WAN links. Increasing link bandwidth is not a simple Iix that solves
the congestion issue in most cases. Aggressive traIIic can Iill interIace queues and starve more
Iragile Ilows such as voice and interactive traIIic. The results can be devastating Ior these
delay-sensitive traIIic types, making it diIIicult to meet the service level requirements these
applications require. Fortunately, there are many congestion management techniques available
on Cisco IOS platIorms. These congestion management techniques provide network
administrators with an eIIective means to manage soItware queues and to allocate the required
bandwidth to speciIic applications when congestion conditions exist.
This module examines the components oI queuing systems and the diIIerent congestion
management mechanisms available on Cisco IOS devices.
ModuIe Objectives
Upon completing this module, you will be able to use Cisco QoS queuing mechanisms to
manage network congestion.
ModuIe OutIine
ModuIe Objectives
· Identify and expIain the operation of basic queuing
aIgorithms incIuding FIFO, priority, and round-robin
queuing
· Describe hardware and software queuing on a network
device
· Configure weighted fair queuing to manage congestion
· Configure CBWFQ and LLQ to manage congestion
· Configure WRR on a CataIyst switch to manage LAN
congestion
ModuIe OutIine
· Introduction to Queuing
· Queuing ImpIementations
· FIFO and WFQ
· CBWFQ and LLQ
· LAN Congestion Management
Ìntroduction to Queuing
Overview
Queuing algorithms are one oI the primary ways to manage congestion in a network. Network
devices handle an overIlow oI arriving traIIic by using a queuing algorithm to sort traIIic and
determine a method oI prioritizing the traIIic onto an output link. Each queuing algorithm was
designed to solve a speciIic network traIIic problem and has a particular eIIect on network
perIormance. This lesson describes the basic queuing algorithms.
ReIevance
In order to understand how an advanced queuing mechanism such as class-based weighted Iair
queuing (CBWFQ) will operate on a Cisco router, it is important to Iirst understand the basic
queuing mechanisms upon which CBWFQ is built.
Objectives
Upon completing this lesson, you will be able to identiIy and explain the operation oI basic
queuing algorithms including FIFO, priority, and round-robin queuing. This includes being able
to meet these objectives:
Explain the need Ior congestion management mechanisms
List the diIIerent queuing algorithms
Describe FIFO queuing
Describe priority queuing
Describe round-robin queuing
Describe weighted round-robin queuing
Describe deIicit round-robin queuing
No special skills or knowledge are required.
OutIine
OutIine
· Overview
· Congestion and Queuing
· Queuing AIgorithms
· FIFO
· Priority Queuing
· Round Robin
· Weighted Round Robin
· Deficit Round Robin
· Summary
· Quiz
Copyright © 2003, Cisco Systems, Ìnc. Congestion Management 5-5
Congestion and Queuing
This topic explains the relationship between congestion and queuing.
Congestion can occur anywhere within a network where speed mismatches (that is, a 1000-
Mbps link Ieeding a 100-Mbps link), aggregation (that is, multiple 100-Mbps links Ieeding an
upstream 100-Mbps link), or conIluence (the Ilowing together oI two or more traIIic streams).
Queuing algorithms are used to manage congestion. Many algorithms have been designed to
serve diIIerent needs. A well-designed queuing algorithm will provide some bandwidth and
delay guarantees to priority traIIic.
· Congestion can occur at any point in the network where
there are points of speed mismatches, aggregation, or
confIuence.
· Queuing manages congestion to provide bandwidth and
deIay guarantees.
Speed mismatches are the most typical cause oI congestion in a network.
Speed mismatches are most common when traIIic moves Irom a high-speed LAN environment
(100 or 1000 Mbps) to lower-speed WAN links (1 or 2 Mbps). Speed mismatches are also
common in LAN-to-LAN environments when, Ior example, a 1000-Mbps link Ieeds into a 100-
Mbps link. In these situations, congestion tends to be persistent and must continually be
managed.
Speed Mismatch
· Speed mismatches are the most typicaI cause of congestion.
· PossibIy persistent when going from LAN to WAN.
· UsuaIIy transient when going from LAN to LAN.
The second most common site oI congestion is at points oI aggregation in a network.
Typical points oI aggregation occur in WANs when multiple remote sites Ieed back into a
central services site.
In a LAN environment, congestion resulting Irom aggregation oIten occurs at the distribution
layer oI networks where the diIIerent access layer devices Ieed traIIic to the distribution-level
switches.
Aggregation
Queuing AIgorithms
This topic lists the diIIerent queuing algorithms.
Key queuing algorithms include:
FIFO: The simplest algorithm.
Priority queuing (PQ): Allows traIIic to be prioritized.
Round robin: Allows several queues to share bandwidth.
Weighted round robin (WRR): Allows sharing oI bandwidth with prioritization.
Deficit round robin (DRR): Resolves problem with some WRR implementations.
Queuing AIgorithms
· FIFO
· Priority queuing (PQ)
· Round robin
· Weighted round robin (WRR)
· Deficit round robin (DRR)
FIFO
This topic describes the FIFO queuing algorithm.
FIFO is the simplest queuing algorithm.
Packets are placed into a single queue and serviced in the order they were received.
All individual queues are, in Iact, FIFO queues. Other queuing methods rely upon FIFO as the
congestion management mechanism Ior single queues while utilizing multiple queues to
perIorm more advanced Iunctions such as prioritization.
FIFO
· First packet in is
first packet out
· SimpIest of aII
· One queue
· AII individuaI
queues are FIFO
Priority Queuing
This topic describes the priority queuing algorithm.
The PQ algorithm is also quite simple.
Each packet is assigned a priority and placed into a hierarchy oI queues based on priority.
When there are no more packets in the highest queue, the next-lower queue is serviced.
Then, packets are dispatched Irom the next-highest queue until either the queue is empty or
another packet arrives Ior a higher PQ.
Only when all higher-priority queues are empty will packets be dispatched Irom a lower queue.
II a packet arrives Ior a higher queue, the packet Irom the higher queue is dispatched beIore any
packets in lower-level queues.
The problem with PQ is that queues with lower priority can 'starve¨ iI a steady stream oI
packets continues to arrive Ior a queue with a higher priority. Packets waiting in the lower-
priority queues may never be dispatched.
Priority Queuing
· PQ
· Uses muItipIe queues
· AIIows prioritization
· AIways empties first queue
before going to the next
queue:
÷ Empty Queue no. 1
÷ If Queue no. 1 empty, then
dispatch one from Queue
no. 2
÷ If both Queue no. 1 and Queue
no. 2 empty, then dispatch
one from Queue no. 3
· Queues no. 2 and no. 3
may "starve"
Round Robin
This topic describes the round-robin queuing algorithm.
With round-robin queuing, one packet is taken Irom each queue and then the process repeats.
II all packets are the same size, all queues share the bandwidth equally. II packets being put
into one queue are larger, that queue will receive a larger share oI bandwidth.
No queue will 'starve¨ with round robin as they all receive an opportunity to dispatch a packet
every round.
A limitation oI round robin is the inability to prioritize traIIic.
Round Robin
· Round robin
· Uses muItipIe queues
· No prioritization
· Dispatches one from
each queue in each
round
÷ One from Queue no. 1
÷ Then repeat
Weighted Round Robin
This topic describes the WRR queuing algorithm.
The WRR algorithm was developed to provide prioritization capabilities Ior round robin.
In WRR, packets are assigned a class (voice, Iile transIer, and so on) and placed into the queue
Ior that class oI service. Packets are accessed round-robin style, but queues can be given
priorities called 'weights.¨ For example, in a single round, Iour packets Irom a high-priority
class might be dispatched, Iollowed by two Irom a middle-priority class, and then one Irom a
low-priority class.
Some implementations oI the WRR algorithm will dispatch a conIigurable number oI bytes
during each round.
· WRR
· AIIows prioritization
· Assign a "weight" to
each queue
· Dispatches packets from
each queue proportionaI
to an assigned weight:
÷ Dispatch up to 4 from
Queue no. 1
÷ Dispatch up to 2 from
Queue no. 2
÷ Dispatch 1 from Queue
no. 3
÷ Go back to Queue no. 1
Weighted Round Robin (Cont.)
· ProbIem with WRR
÷ Some impIementations of WRR dispatch a configurabIe number of
bytes (threshoId) from each queue for each round-severaI packets
can be sent in each turn.
÷ The router is aIIowed to send the entire packet even if the sum of aII
bytes is more than the threshoId.
Some implementations oI the weighted round robin algorithm provide prioritization by
dispatching a conIigurable number oI bytes each round rather than a number oI packets (Cisco
custom queuing |CQ| mechanism is an example oI this implementation).
The Iigure illustrates the worst-case scenario oI the WRR algorithm where the Iollowing
parameters were used to implement WRR queuing on an interIace:
Maximum Transmission Unit (MTU) oI the interIace is 1500 bytes.
The byte-count to be sent each round Ior the queue is 3000 (twice the MTU).
The example shows how the router Iirst sent two packets with a total size oI 2999 bytes.
Because this is still within the limit (3000), the router can send the next packet (MTU-sized).
The result was that the queue received almost 50 percent more bandwidth in this round than it
should.
This is one oI the drawbacks oI WRR queuingit does not allocate bandwidth accurately.
The limit or weight oI the queue is conIigured in bytes. The accuracy oI WRR queuing depends
on the weight (byte-count) and the MTU.
II the ratio between the byte-count and the MTU is too small, WRR queuing will not allocate
bandwidth accurately.
II the ratio between the byte-count and the MTU is too large, WRR queuing will cause long
delays.
Deficit Round Robin
This topic describes the deIicit round-robin queuing algorithm.
DeIicit round robin is an implementation oI the WRR algorithm developed to resolve the WRR
problem described on the previous page. The Cisco modiIied deIicit round robin (MDRR)
method used on the Cisco 12000 series is an implementation oI deIicit round robin.
DeIicit round robin uses a deIicit counter to track the number oI 'extra¨ bytes dispatched over
the number oI bytes that was to be conIigured to be dispatched each round. During the next
round, the number oI 'extra¨ bytesthe deIicitis eIIectively subtracted Irom the
conIigurable number oI bytes that are dispatched.
Deficit Round Robin
· DRR
· SoIves probIem with some impIementations of WRR
described on previous sIide
· Keeps track of the number of "extra" bytes dispatched
in each round - the "deficit"
· Adds the "deficit" to the number of bytes dispatched in
the next round
· ProbIem from previous sIide resoIved with deficit round
robin:
÷ ThreshoId of 3000
÷ Packet sizes of 1500, 1499, and 1500
÷ TotaI sent in round = 4499 bytes
÷ Deficit = (4499 - 3000) = 1499 bytes
÷ On the next round send onIy the (threshoId - deficit) = (3000 -
1499) = 1501 bytes
Summary
References
To learn more about congestion and queuing, reIer to 'Understanding Delay in Packet
Voice Networks¨ at the Iollowing URL:
http://www.cisco.com/en/US/tech/tk652/tk698/technologies¸white¸paper09186a00800a89
93.shtml
To learn more about congestion and queuing, reIer to 'Understanding Jitter in Packet Voice
Networks (Cisco IOS PlatIorms)¨ at the Iollowing URL:
http://www.cisco.com/en/US/tech/tk652/tk698/technologies¸tech¸note09186a00800945dI.
shtml
Summary
· Congestion can occur at any point in the network, but
particuIarIy at points of speed mismatches and traffic
aggregation.
· Three basic queuing aIgorithms are used to manage
congestion: FIFO, priority, and round-robin queuing.
· FIFO is the simpIest queuing aIgorithm.
· Priority queuing aIIows for the prioritization of traffic through
the use of muItipIe queues but can starve Iower-priority queues.
· Round-robin queuing uses muItipIe queues to provide equaI
access to aII queues.
· Weighted round robin offers priority access to muItipIe queues
by assigning "weights" to queues but some impIementations
may provide inaccurate access to some queues.
· Deficit round-robin queuing soIves the inaccuracy probIem with
round robin by keeping a "deficit" count.
Quiz
Q1) Which three oI the Iollowing represent three likely points in a network where
congestion would occur? (Choose three.)
A) points oI aggregation
B) points oI conIluence
C) points oI convergence
D) points oI speed mismatches
Q2) Which oI the Iollowing is the simplest queuing algorithm?
A) priority queuing
B) Iirst-in, Iirst-out
C) weighted round robin
D) round robin
Q3) Which oI the Iollowing queuing algorithms would be most likely to 'starve¨ lower-
priority queues?
A) priority queuing
B) weighted round robin
C) round robin
D) deIicit round robin
Q4) Which oI the Iollowing queuing algorithms would be most likely to dispatch an equal
number oI packets Irom each queue?
A) round robin
B) priority queuing
C) weighted round robin
D) deIicit round robin
Q5) When WRR is conIigured on a switch with Iour transmit queues, given that weights
have been assigned to each oI the queues as Iollows and that all queues are Iull, how
many packets Irom queue 4 would be dispatched every time a packet Irom queue 2 is
dispatched?
Queue Weight
4 8
3 4
2 2
1 1
A) 2
B) 4
C) 16
D) 24
Q6) Given that a deIicit round-robin queue is conIigured to dispatch 4000 bytes each round
and it has just dispatched 4500 bytes, what will be the maximum number oI bytes the
queue will try to dispatch during the next round?
E) 4000
F) 4500
G) 3500
H) 7500
Quiz Answer Key
Q1) A, B, D
ReIates to: Congestion and Queuing
Q2) B
ReIates to: Queuing Algorithms
Q3) A
ReIates to: Priority Queuing
Q4) A
ReIates to: Round Robin
Q5) B
ReIates to: Weighted Round Robin
Q6) C
ReIates to: Deficit Round Robin
Queuing Ìmplementations
Overview
Queuing technologies are one oI the primary ways to manage congestion in a network. Network
devices handle an overIlow oI arriving traIIic by using a queuing algorithm to sort traIIic and
determine a method oI prioritizing the traIIic onto an output link. Each queuing algorithm was
designed to solve a speciIic network traIIic problem and has a particular eIIect on network
perIormance. This lesson explains the underlying principles behind queuing on Cisco
networking devices.
ReIevance
In order to understand how an advanced queuing mechanism such as CBWFQ will operate on a
Cisco router, it is important to Iirst understand how queuing is implemented on Cisco network
devices.
Objectives
Upon completing this lesson you will be able to describe hardware and soItware queuing on a
network device. This includes being able to meet these objectives:
Explain the components oI hardware and soItware queuing systems on Cisco routers
Explain the eIIects oI tuning the size oI the hardware queue on router and network
perIormance
Describe how congestion aIIects soItware interIaces on Cisco routers
List and describe the basic queuing mechanisms available in Cisco IOS
OutIine
OutIine
· Overview
· Queuing Components
· Hardware Queue (TxQ) Size
· Congestion on Software Interfaces
· Queuing ImpIementations in Cisco IOS
· Summary
· Quiz
Queuing Components
This topic describes the primary components oI a queuing mechanism.
Queuing on routers is necessary to accommodate bursts when the arrival rate oI packets is
greater than the departure rate, usually because oI one the Iollowing two reasons:
Input interIace is Iaster than the output interIace
Output interIace is receiving packets coming in Irom multiple other interIaces
Initial implementations oI queuing used a single FIFO strategy. More complex queuing
mechanisms were introduced when special requirements need routers to diIIerentiate between
packets oI diIIerent importance.
Queuing was split into two parts:
Hardware queue: Uses FIFO strategy, which is necessary Ior the interIace drivers to
transmit packets one by one. The hardware queue is sometimes reIerred to as the transmit
queue (TxQ).
Software queue: Schedules packets into the hardware queue based on the QoS
requirements.
Queuing Components
· Each physicaI interface has a hardware and a
software queuing system.
The Iigure illustrates the actions that have to be taken beIore a packet can be transmitted:
Most queuing mechanisms include classiIication oI packets.
AIter a packet is classiIied, a router has to determine whether it can put the packet into the
queue or it has to drop the packet. Most queuing mechanisms will drop a packet only iI the
corresponding queue is Iull (tail drop). Some mechanisms use a more intelligent dropping
scheme (WFQ) or a random dropping scheme (weighted random early detection |WRED|).
II the packet is allowed to be enqueued it will be put into the FIFO queue Ior that particular
class.
Packets are then taken Irom the individual per-class queues and put into the hardware
queue.
Queuing Components (Cont.)
· The hardware queuing system aIways uses FIFO queuing.
· The software queuing system can be seIected and
configured depending on the pIatform and Cisco IOS
version.
The implementation oI soItware queuing was optimized Ior periods when the interIace is not
congested. The soItware queuing system is bypassed whenever there is no packet in the
soItware queue and there is room in the hardware queue.
The soItware queue is, thereIore, only used when data must wait to be placed into the hardware
queue.
The Software Queue
· GeneraIIy, a fuII hardware queue indicates interface congestion
and software queuing is utiIized to manage it.
· When a packet is being forwarded, the router wiII bypass the
software queue if the hardware queue has space in it (no
congestion).
Hardware Queue (TxQ) Size
This topic explains the signiIicance oI the size oI the hardware queue.
The double queuing strategy (soItware and hardware queue) has its impacts on the results oI
overall queuing. SoItware queues serve a valuable purpose. II the hardware queue is too long, it
will contain a large number oI packets scheduled in the FIFO Iashion. A long FIFO hardware
queue most likely deIeats the quality oI service (QoS) design that required a certain complex
soItware queuing system (Ior example, CQ).
So why use the hardware queue at all? Or why not just set its length to one? That would Iorce
all packets to go through the soItware queue and be scheduled one by one to the interIace Ior
transmission. This approach has the Iollowing drawbacks:
Each time a packet is transmitted, the interIace driver interrupts the CPU and requests more
packets to be delivered into its hardware queue. Some queuing mechanisms have complex
scheduling that takes time to deliver more packets. The interIace does not send anything
during that time (link utilization is decreased) iI the hardware queue is empty because its
maximum size is one.
The CPU schedules packets one by one instead oI many at the same time (in the same
interrupt interval). This increases the CPU utilization.
Choosing the appropriate length oI the hardware queue is very important. The deIault TxQ size
is determined by the Cisco IOS soItware, based on the bandwidth oI the media, and should be
Iine Ior most queuing implementations. Some platIorms and QoS mechanisms will
automatically adjust the TxQ size to an appropriate value. Faster interIaces have longer
hardware queues because they produce less delay. Slower interIaces have shorter hardware
queues to prevent too much delay in the worst-case scenario where the entire hardware queue is
Iull oI MTU-sized packets.
Hardware Queue (TxQ) Size
· Routers determine the Iength of the hardware queue
based on the configured bandwidth of the interface.
· The Iength of the hardware queue can be adjusted with
the tx-ring-Iimit command.
· Reducing the size of the transmit ring has two benefits:
÷ It reduces the maximum amount of time packets wait in the FIFO
queue before being transmitted.
÷ It acceIerates the use of QoS in the Cisco IOS software.
· ImproperIy tuning of the hardware queue may produce
undesirabIe resuIts:
÷ Long TxQ may resuIt in poor performance of the software queue.
÷ Short TxQ may resuIt in a Iarge number of interrupts, which causes
high CPU utiIization and Iow Iink utiIization.
Note: Refer to Cisco ÌOS software configuration documentation for more information.
The transmit ring serves as a staging area Ior packets in line to be transmitted. The router needs
to enqueue a suIIicient number oI packets on the transmit ring and ensure that the interIace
driver has packets with which to Iill available cell timeslots.
The primary reason to tune the transmit ring is to reduce latency caused by queueing. On any
network interIace, queueing Iorces a choice between latency and the amount oI burst that the
interIace can sustain. Larger queue sizes sustain longer bursts while increasing delay. Tune the
size oI a queue when you think traIIic is experiencing unnecessary delay.
The size oI the transmit ring must be small enough to avoid introducing latency because oI
queuing and it must be large enough to avoid drops and a resulting impact to TCP-based Ilows.
Queuing on the transmit ring introduces a serialization delay that is directly proportional to the
depth oI the ring. An excessive serialization delay can impact latency budgets Ior delay-
sensitive applications such as voice. Thus, Cisco recommends reducing the size oI the transmit
ring Ior VCs carrying voice. Select a value based on the amount oI serialization delay,
expressed in seconds, introduced by the transmit ring. Use the Iollowing Iormula:
((P*8)*D)/S
P ¬ Packet size in bytes. Multiply by eight to convert to
bits.
D ¬ Transmit-ring depth.
S ¬ Speed of the VC in bps.
Note: ÌP packets on the Ìnternet are typically one of three sizes: 64 bytes (for example, control
messages), 1500 bytes (for example, file transfers), or 256 bytes (all other traffic). These
values produce a typical overall Ìnternet packet size of 250 bytes.
Congestion on Software Interfaces
This topic explains how congestion occurs on soItware interIaces.
SubinterIaces and soItware interIaces do not have queues. ThereIore, no congestion can occur.
These interIace types include dialers, tunnels, and Irame-relay subinterIaces and will only
congest when their hardware interIace congests. The transmit (tx) ring state is an indication oI
congestion Ior soItware interIaces.
Congestion on Software Interfaces
· Subinterfaces and software interfaces do not have
any queues, therefore no congestion can occur.
÷ DiaIers, tunneIs, frame-reIay subinterfaces
÷ They congest, when their hardware interface congests
· The tx-ring state (fuII, not fuII) is therefore an
indication of congestion.
· OnIy hardware interfaces have a tx-ring.
Queuing ImpIementations in Cisco IOS
This topic describes the basic soItware queuing technologies used on Cisco network devices.
The Iigure lists some oI the available soItware queuing technologies.
PQ
A Cisco implementation oI the priority queuing algorithm
Allows Iour queues to be used Ior prioritizatoin (high, medium, normal, low)
Allows Ior a variety oI classiIication including source IP address, destination IP
address, IP precedence, and DSCP
Custom queuing
A Cisco implementation oI WRR
Allows up to 16 queues to be used Ior traIIic classiIication
Allows Ior a variety oI classiIication including: source IP address, destination IP
address, IP precedence, and DSCP
Tail drop is used within each individual queue
MDRR
A Cisco implementation oI deIicit round robin
Available only on the Cisco 12000 series routers
Queuing ImpIementations
in Cisco IOS
· Priority Queuing
÷ ImpIementation of priority queuing
÷ Four queues (high, medium, normaI, Iow)
· Custom Queuing
÷ ImpIementation of Weighted Round Robin
÷ Up to 16 queues
÷ ThreshoId based on number of bytes
÷ ConfigurabIe priority queues
÷ Inaccurate bandwidth aIIocation due to threshoId issue with
weighted round robin
· Modified Deficit Round Robin
÷ Deficit round robin with a priority queue for Cisco 12xxx routers
Summary
Summary
· Each physicaI interface has a hardware and a software
queuing system.
· If there is no congestion, the software queue wiII be
bypassed and the packet wiII be pIaced in the FIFO
hardware queue.
· The Iength of the hardware queue has a significant
impact on performance and can be configured on a router
with the tx-ring-Iimit command.
· Software interfaces have no queues; they congest onIy
when their hardware interface congests.
· Cisco offers impIementations of basic queuing
aIgorithms: priority queuing, custom queuing, and
modified deficit round robin.
References
To learn more about congestion and queuing, reIer to 'Understanding Delay in Packet
Voice Networks¨ at the Iollowing URL:
http://www.cisco.com/en/US/tech/tk652/tk698/technologies¸white¸paper09186a00800a89
93.shtml
To learn more about congestion and queuing, reIer to 'Understanding Jitter in Packet Voice
Networks (Cisco IOS PlatIorms)¨ at the Iollowing URL:
http://www.cisco.com/en/US/tech/tk652/tk698/technologies¸tech¸note09186a00800945dI.
shtml
Quiz
Q1) Every physical interIace must have which two oI the Iollowing? (Choose two.)
A) priority queuing
B) custom queuing
C) soItware queuing system
D) hardware queuing system
Q2) Which two would be the likely results oI a hardware queue with too short oI a TxQ?
(Choose two.)
A) jitter
B) low link utilization
C) high CPU utilization
D) poor soItware queue perIormance
Q3) How many queues does a soItware interIace have by deIault?
A) 0
B) 1
C) 2
D) 4
Q4) What would be the likely result oI a hardware queue with too long oI a TxQ?
A) jitter
B) low link utilization
C) high CPU utilization
D) poor soItware queue perIormance
Q5) Which oI the Iollowing is a Cisco implementation oI the weighted round robin
algorithm?
A) custom queuing (CQ)
B) low latency queuing (LLQ)
C) weighted Iair queuing (WFQ)
D) class-based weighted Iair queuing (CBWFQ)
Quiz Answer Key
Q1) C, D
ReIates to: Queuing Components
Q2) B, C
ReIates to: Hardware Queue (TxQ) Size
Q3) A
ReIates to: Congestion on Software Ìnterfaces
Q4) D
ReIates to: Hardware Queue (TxQ) Size
Q5) A
ReIates to: Queuing Ìmplementations in Cisco ÌOS
FÌFO and WFQ
Overview
FIFO and WFQ are the two primary deIault queuing mechanisms that are implemented on
Cisco routers. WFQ was developed to resolve some oI the problems resulting Irom the use oI
basic queuing methods such as queue starvation, delay, and jitter. WFQ dynamically divides
available bandwidth by a calculation based on the total number oI Ilows and the weight oI each
given Ilow. Bandwidth cannot be guaranteed, as the number oI Ilows are constantly changing
and thus so is the allocated bandwidth to each Ilow.
ReIevance
WFQ is a key technology Ior ensuring QoS in a converged network and is used as a key
element oI the more advanced queuing methods.
Objectives
Upon completing this lesson, given a network with suboptimal QoS perIormance, you will be
able to conIigure WFQ to manage congestion. This includes being able to meet these
objectives:
Describe the FIFO queuing mechanism
Give a detailed explanation oI WFQ using a block diagram
IdentiIy the parameters on which WFQ can classiIy traIIic
Explain the insertion and drop policy used by WFQ using a block diagram
Explain how Iinish time is calculated based on weight and used in the operation oI WFQ
Describe the beneIits and drawbacks oI using WFQ to implement QoS
IdentiIy the Cisco IOS commands required to conIigure WFQ on a Cisco router
IdentiIy the Cisco IOS commands required to monitor WFQ on a Cisco router
Basic knowledge oI internetworking with TCP/IP concepts and knowledge oI basic Cisco
IOS commands
OutIine
OutIine
· Overview
· FIFO Queuing
· Weighted Fair Queuing
· WFQ CIassification
· WFQ Insertion and Drop PoIicy
· WFQ ScheduIing
· Benefits and Drawbacks of WFQ
· Configuring WFQ
· Monitoring WFQ
· Summary
· Quiz
FIFO Queuing
This topic describes FIFO queuing.
FIFO queuing has no classiIication because all packets belong to the same class. Packets are
dropped when the output queue is Iull (tail drop). The scheduler services packets in the order
they arrived.
SoItware FIFO queue is basically an extension oI the hardware FIFO queue.
FIFO Queuing
· Software FIFO queue is basicaIIy an extension to the
hardware FIFO queue.
Although FIFO queuing might be regarded as the Iairest queuing mechanism, it has a long list
oI drawbacks:
FIFO is extremely unIair when an aggressive Ilow is contesting with a Iragile Ilow.
Aggressive Ilows send a large number oI packets, many oI which are dropped. Fragile
Ilows send a modest amount oI packets and most oI them are dropped because the queue is
always Iull because oI the aggressive Ilow. This type oI behavior is called starvation.
Short or long bursts cause a FIFO queue to Iill. Packets entering an almost Iull queue have
to wait a long time beIore they can be transmitted. Another time, the queue might be empty
causing packets oI the same Ilow to experience almost no delay. Variation in delay is called
jitter.
In spite oI all the drawbacks, FIFO is still the most used queuing mechanism because oI the
Iollowing beneIits:
It is simple and Iast. Most high-end routers with Iast interIaces are not really challenged by
the drawbacks mentioned earlier. Furthermore, routers are not capable oI complex
classiIication and scheduling when they have to process a large number oI packets-per-
second. FIFO is, thereIore, the most suitable queuing mechanism on these platIorms.
It is supported on all platIorms.
FIFO queuing is supported in all versions oI Cisco IOS.
FIFO Queuing (Cont.)
+ Benefits
· SimpIe and fast (one singIe queue with a simpIe
scheduIing mechanism)
· Supported on aII pIatforms
· Supported in aII switching paths
· Supported in aII IOS versions
÷ Drawbacks
· Causes starvation (aggressive fIows can monopoIize
Iinks)
· Causes jitter (bursts or packet trains temporariIy fiII the
queue)
Weighted Fair Queuing
This topic explains the purpose and Iunction oI WFQ.
WFQ was introduced as a solution to the problems oI the Iollowing queuing mechanisms:
FIFO queuing causes starvation, delay, and jitter.
PQ causes starvation oI other lower-priority classes and suIIers Irom all FIFO problems
within each oI the Iour queues.
CQ causes long delays and also suIIers Irom all FIFO problems within each oI the 16
queues.
The idea oI WFQ is to:
Have a dedicated queue Ior each Ilow (no starvation, delay, or jitter within the queue).
Fairly and accurately allocate bandwidth among all Ilows (minimum scheduling delay,
guaranteed service).
Use IP precedence as weight when allocating bandwidth.
· Queuing aIgorithm shouId share the bandwidth fairIy
among fIows by:
÷ Reducing response time for interactive fIows by scheduIing them to
the front of the queue.
÷ Preventing high voIume conversations from monopoIizing an
interface.
· In the WFQ impIementation, messages are sorted into
conversations (fIows) and transmitted by the order of the
Iast bit crossing its channeI.
· Unfairness is reinstated by introducing weight to give
proportionateIy more bandwidth to fIows with higher
weight.
WFQ uses automatic classiIication. Manually deIined classes are not supported.
WFQ dropping is not a simple tail drop. WFQ drops packets oI the most aggressive Ilows.
WFQ scheduler is a simulation oI a time-division multiplexing (TDM) system. The bandwidth
is Iairly distributed to all active Ilows.
WFQ Architecture
· WFQ uses per-fIow FIFO queues
WFQ is supported on most Cisco routers as well as on Versatile InterIace Processors (VIP).
The implementation oI WFQ on the VIP diIIers slightly Irom the one discussed in this lesson in
the Iollowing ways:
ClassiIication identiIies a Ilow and assigns a queue to the Ilow.
Weight is used Ior scheduling to give proportionately more bandwidth to Ilows with a
higher IP precedence.
Tail-dropping scheme is improved to drop packets oI the most aggressive Ilows.
'Figure Box Top` with a Page Break
WFQ ImpIementations
· ImpIementation parameters
÷ Queuing pIatform: centraI CPU or VIP
÷ CIassification mechanism
÷ Weighted fairness
· Modified TaiI-Drop within each queue
WFQ CIassification
This topic explains how classiIication is accomplished with WFQ.
WFQ CIassification
· Packets of the same fIow end up in the same queue.
· ToS fieId is the onIy parameter that might change causing
packets of the same fIow to end up in different queues.
WFQ classiIication has to identiIy individual Ilows. (The term conversation is also used to
signiIy Ilows.) A Ilow is identiIied based on the Iollowing inIormation taken Irom the IP header
and the TCP or UDP headers:
Source IP address
Destination IP address
Protocol number (identiIying TCP or User Datagram Protocol (UDP)
Type oI service Iield
Source TCP/UDP port number
Destination TCP/UDP port number
The Iollowing parameters are usually Iixed Ior a single Ilow, although there are some
exceptions:
A QoS design could mark packets with diIIerent IP precedence values even iI they belong
to the same Ilow. This kind oI behavior should be avoided when using WFQ.
Some applications change port numbers (Ior example, TFTP).
II packets oI the same Ilow do not have the same parameters (Ior example, a diIIerent type oI
service |ToS| Iield), the packets can end up in diIIerent queues and reordering can occur.
The parameters are used as input Ior a hash algorithm that produces a Iixed-length number that
is used as the index oI the queue.
WFQ uses a Iixed number oI queues. The hash Iunction is used to assign a queue to a Ilow.
There are eight additional queues Ior system packets and optionally up to 1000 queues Ior
Resource Reservation Protocol (RSVP) Ilows. The number oI dynamic queues WFQ uses by
deIault is based on the interIace bandwidth. Using the deIault interIace bandwidth, WFQ uses
256 dynamic queues by deIault. The number oI queues can be conIigured in the range between
16 and 4096 (the number must be a power oI 2). The deIault number oI dynamic queues Ior
diIIerent interIace bandwidths is shown in the table.
Bandwidth Range Number of Dynamic Queues
Less than or equal to 64 kbps 16
More than 64 kbps and less than or equal to 128 kbps 32
More than 512 kbps 256
II there are a large number oI concurrent Ilows it is very likely that two Ilows could end up in
the same queue. It is recommended to have several times as many queues as there are Ilows (on
average). This may not be possible in larger environments where the number oI concurrent
Ilows is in thousands.
The probability oI two Ilows ending up in the same Ilow could be calculated using the
Iollowing Iormula:
)! (
!
1
Flows Queues Queues
Queues
P
Flows

 
WFQ CIassification (Cont.)
· Fixed number of per-fIow queues is configured.
· A hash function is used to transIate fIow parameters into
queue number.
· System packets (8 queues) and RSVP fIows (if
configured) are mapped into separate queues.
· Two or more fIows couId map into the same queue,
resuIting in Iower per-fIow bandwidth.
· Important: the number of queues configured has to be
Iarger than the expected number of fIows.
The Iollowing table lists the probability values Ior 3 sizes oI the WFQ system (64, 128, and 256
queues), with the number oI concurrent Ilows Irom 5 to 40. The table shows the probability
values Ior three sizes oI the WFQ system.
FIows 64 Queues 128 Queues 256 Queues
5 15% 8% 4%
10 52% 30% 16%
15 83% 57% 34%
20 96% 79% 53%
25 100% 92% 70%
30 100% 98% 83%
35 100% 99% 91%
40 100% 100% 96%
Below is the sample calculation oI the probability value Ior 5 Ilows and 64 queues:
Flows. S
Queues. 84
Probability ¬ I ÷ ((84!) / ((84´S) * (S9!)))
¬ I ÷ ((84 * 8· * 8? * 8I * 80) / (84 * 84 * 84 *
84 * 84)
¬ I ÷ 0.8S?I0S8I8
¬ 0.I4I894·8? or I4.I% (IS% rounded off)
WFQ Insertion and Drop PoIicy
This topic explains WFQ insertion and drop policy.
WFQ uses two parameters that aIIect the dropping oI packets.
The congestive discard threshold (CDT) is used to start dropping packets oI the most
aggressive Ilow, even beIore the hold-queue limit is reached.
The hold-queue out limit deIines the total maximum number oI packets that can be in the
WFQ system at any time.
There are two exceptions to the WFQ insertion and drop policy as Iollows:
II the WFQ system is above the CDT limit the packet is still enqueued iI the per-Ilow
queue is empty.
The dropping strategy is not directly inIluenced by IP precedence.
WFQ Insertion and Drop PoIicy
· WFQ has two modes of dropping:
÷ EarIy dropping when the congestion discard threshoId is
reached
÷ Aggressive dropping when the hoId-queue out Iimit is
reached
· WFQ aIways drops packets of the most aggressive
fIow
· Drop Mechanism Exceptions
÷ Packet cIassified into an empty sub-queue is never dropped
÷ The packet precedence has no effect on the dropping
scheme
The Iigure illustrates the dropping scheme oI WFQ. The process can be organized into the
Iollowing steps:
Step 1 Drop the new packet iI the WFQ system is Iull (hold-queue limit reached) and the
new packet has the worst Iinish time (the last in the entire system).
Step 2 Drop the packet with the worst Iinish time in the WFQ system iI the system is Iull.
Enqueue the new packet.
Step 3 When the WFQ system is above the CDT limit, a new packet is dropped iI it is the
last in the WFQ system, even though the WFQ system is still within the hold-queue
limit.
Step 4 When the WFQ system is above the CDT limit, and iI a new packet would not be the
last in the WFQ system, the new packet can be enqueued and no other packet is
dropped.
WFQ Insertion and Drop PoIicy (Cont.)
· HQO (hoId-queue out Iimit) is the max. number of packets that the WFQ
system can hoId.
· CDT is the threshoId when WFQ starts dropping packets of the most
aggressive fIow.
· N is the number of packets in the WFQ system when the N-th packet arrives.
WFQ ScheduIing
This topic describes scheduling in WFQ.
The length oI queues (Ior scheduling purposes) is not in packets but in the time it would take to
transmit all the packets in the queue. The end result is that WFQ adapts to the number oI active
Ilows (queues) and allocates equal amounts oI bandwidth to each Ilow (queue).
The side eIIect is that Ilows with small packets (usually interactive Ilows) get a much better
service because they do not need a lot oI bandwidth. They, however, need low-delay, which
they get because small packets have a low Iinish time.
The Iigure illustrates how two queues (queue A and queue B) are contesting Ior link bandwidth.
For this example, assume the time units are in ms and time T (value 0 is used in the Iigure) is
the starting point.
Queue A is receiving packets in the Iollowing order and the Iollowing times:
Packet A1 arrives at time T ¹ 0 ms and would require 100 ms to be transmitted.
Packet A2 arrives at time T ¹ 60 ms (the input interIace is obviously Iaster than the output
interIace because the arrival time oI packet A2 is beIore the Iinish time oI packet A1) and
would require 20 ms to be transmitted.
Packet A3 arrives at time T ¹ 70 ms (the input interIace is obviously much Iaster than the
output interIace) and would require 10 ms to be transmitted.
Queue B is receiving packets in the Iollowing order and the Iollowing times:
Packet B1 arrives at time T ¹ 50 ms and would require 300 ms to be transmitted.
Packet B2 arrives at time T ¹ 100 ms and would also require 300 ms to be transmitted.
Finish Time CaIcuIation
The Iinish time oI packets in Queue A are:
Packet A1 has a Iinish time which is the sum oI the current time (because the queue was
empty at the time oI arrival) and the time it takes to transmit this packet (100 ms): FT
A1
÷ 0
ms ¹ 100 ms ÷ 100 ms.
Packet A2 has a Iinish time which is the sum oI the Iinish time oI the last packet in queue A
(Packet A1) and the time it would take to transmit this packet (20 ms): FT
A2
÷ 100 ms ¹ 20
ms ÷ 120 ms.
Packet A3 has a Iinish time which is the sum oI the Iinish time oI the last packet in Queue
A (Packet A2) and the time it would take to transmit this packet (20 ms): FT
A3
÷ 120 ms ¹
10 ms ÷ 130 ms.
The Iinish time Ior the packets in queue B are:
Packet B1 has a Iinish time which is the sum oI the current time (because the queue was
empty at the time oI arrival) and the time it takes to transmit this packet (300 ms): FT
B1
÷
50 ms ¹ 300 ms ÷ 350 ms.
Packet B2 has a Iinish time which is the sum oI the Iinish time oI the last packet in queue B
(Packet B1) and the time it would take to transmit this packet (300ms): FT
B2
÷ 350 ms ¹
300 ms ÷ 650 ms.
The packets are scheduled into the hardware queue (or the TxQ) in the ascending order oI
Iinish times:
1. A1 (100 ms)
2. A2 (120 ms)
3. A3 (130 ms)
4. B1 (350 ms)
5. B2 (650 ms)
Note: WFQ prevents reordering of packets within a single flow (conversation). Small packets are
automatically preferred over large packets.
This Iigure introduces the weight into the Iinish time calculation. The time it takes to transmit
the packet is divided by IP precedence increased by one (to prevent division by zero).
The WFQ implementation in Cisco routers was optimized in the Iollowing way:
The real time it takes to transmit the packet is not relevant. The packet size can be used
instead because it is proportional to the transmit time.
The packet size is not divided by IP precedence (division is a CPU-intensive operation).
Instead, the size is multiplied by a Iixed value (one multiplication value Ior each IP
precedence value).
Packets with IP precedence one appear halI the size they really are. The result is that these
packets receive twice as much bandwidth as packets with IP precedence zero.
Weight in WFQ ScheduIing
The Iirst Iormula in the Iigure is the Iirst optimisation where the Iinish time is really the sum oI
packet sizes divided by an increased IP precedence value.
The second Iormula shows Iurther optimization where, instead oI dividing, the packet size is
multiplied by 32384/(IP precedence ¹ 1). A number Ior each diIIerent IP precedence value is
stored in a table and thereIore, does not have to be calculated Ior each packet.
Packets belonging to RSVP Ilows and system packets have special low weights that guarantee
them more bandwidth.
Note: Cisco ÌOS versions before 12.0(5)T use a new formula where the weight is calculated on the
following formula: Weight = 4096 / (ÌP precedence +1).
If FIow F Active, If FIow F Active,
Then FT( Then FT(P P
k k+1 +1
) = FT( ) = FT(P P
k k
) + Size( ) + Size(P P
k k+1 +1
)/( )/(IPPrec IPPrec+1) +1)
Otherwise FT(P Otherwise FT(P
0 0
) = Now + Size(P ) = Now + Size(P
0 0
)/( )/(IPPrec IPPrec+1) +1)
Finish Time CaIcuIation with Weights
If FIow F Active, If FIow F Active,
Then FT( Then FT(P P
k k+1 +1
) = FT( ) = FT(P P
k k
) + Size( ) + Size(P P
k k+1 +1
)*32384/( )*32384/(IPPrec IPPrec+1) +1)
Otherwise FT(P Otherwise FT(P
0 0
) = Now + Size(P ) = Now + Size(P
0 0
)*32384 /( )*32384 /(IPPrec IPPrec+1) +1)
· Finish time is adjusted based on IP precedence of the packet.
· IOS impIementation scaIes the finish time to aIIow integer
arithmetic.
· RSVP packets and high-priority internaI packets have speciaI
weights (4 and 128).
The illustration shows the mapping between IP precedence values and WFQ weights.
Note: These figures are subject to change. Refer to the Cisco ÌOS documentation for the latest
information on WFQ weights.
IP Precedence to Weight Mapping
· RSVP packets and high-priority internaI packets have speciaI weights
(4 and 128).
· Lower weight makes packets appear smaIIer (preferred).
· These numbers are subject to change.
The Iollowing case study is used to describe how packets are dropped in diIIerent situations.
The WFQ system was reduced to a modest hold-queue limit oI ten and a congestive discard
threshold oI eight.
There are already ten packets in the WFQ system. The new packet would be the 11th and also
the last in the entire WFQ system.
WFQ Case Study
· WFQ system can hoId a maximum of ten packets
(hoId-queue Iimit).
· EarIy dropping (of aggressive fIows) shouId start
when there are eight packets (congestive
discard threshoId) in the WFQ system.
WFQ Case Study
Interface Congestion
· HQO (hoId-queue out Iimit) is the maximum number of packets
that the WFQ system can hoId and HQO = 10.
The new packet is dropped.
WFQ Case Study
Interface Congestion (Cont.)
· HQO (hoId-queue out Iimit) is the maximum number of packets
that the WFQ system can hoId and HQO = 10.
· AbsoIute maximum (HQO=10) exceeded, new packet is the Iast
in the TDM system and is dropped.
This example illustrates how WFQ can drop packets even iI the WFQ system is still within the
hold-queue limit. The system, however, is above the CDT limit. In this case a packet can be
dropped iI it is the last in the system.
In this case, a packet can be dropped iI it is the last in the system.
WFQ Case Study
FIow Congestion
· EarIy dropping (of aggressive fIows) shouId start when there
are eight packets (congestive discard threshoId) in the WFQ
system.
WFQ Case Study
FIow Congestion (Cont.)
· CDT exceeded (CDT=8), new packet wouId be the Iast in the
TDM system and is dropped.
· EarIy dropping (of aggressive fIows) shouId start when there
are eight packets (congestive discard threshoId) in the WFQ
system.
Benefits and Drawbacks of WFQ
This topic compares the beneIits and drawbacks oI WFQ.
These are the main beneIits oI WFQ:
Simple conIiguration (no manual classiIication is necessary)
Drops packets oI the most aggressive Ilows
These are the main drawbacks:
Not always possible to have one Ilow per queue
Does not allow manual classiIication
Cannot provide Iixed guarantees
Benefits and Drawbacks of WFQ
+ Benefits
· SimpIe configuration (cIassification does not have to be configured)
· Guarantees throughput to aII fIows
· Drops packets of most aggressive fIows
· Supported on most pIatforms
· Supported in aII IOS versions
÷ Drawbacks
· MuItipIe fIows can end up in one queue
· Does not support the configuration of cIassification
· Cannot provide fixed bandwidth guarantees
· CompIex cIassification and scheduIing mechanisms
Configuring WFQ
This topic explains how to conIigure WFQ.
WFQ is automatically enabled on all interIaces that have a deIault bandwidth oI less than 2
Mbps. The fair-queue command is used to enable WFQ on interIaces where it is not enabled
by deIault or was previously disabled.
fair-queue |congestive-aiscara-threshola |aynamic-queues |reservable-queues|||
Syntax Description
congestivediscard
threshold
(Optional) Number of messages allowed in each queue. The
default is 64 messages, and a new threshold must be a power of
2 in the range from 16 to 4096. When a conversation reaches this
threshold, new message packets are discarded.
dynamicqueues (Optional) Number of dynamic queues used for best-effort
conversations. Values are 16, 32, 64, 128, 256, 512, 1024, 2048,
and 4096.
reservablequeues (Optional) Number of reservable queues used for reserved
conversations in the range 0 to 1000. The default is 0.
Reservable queues are used for interfaces configured for
features such as RSVP.
Configuring WFQ
· congestive-discard-threshoId (CDT)
÷ Number of messages aIIowed in the WFQ system before the
router starts dropping new packets for the Iongest queue.
÷ The vaIue can be in the range from 1 to 4096 (defauIt is 64)
· dynamic-queues
÷ Number of dynamic queues used for best-effort
conversations (vaIues are: 16, 32, 64, 128, 256, 512, 1024,
2048, and 4096)
· reservabIe-queues
÷ Number of reservabIe queues used for reserved
conversations in the range 0 to 1000 (used for interfaces
configured for features such as RSVP - the defauIt is 0)
fair~queue (cdt (dynamic~gueues (reservable~
gueues)))
fair~queue (cdt (dynamic~gueues (reservable~
gueues)))
router(config~intf)#
The same hold-queue command that can be used with FIFO queuing can also be used with
WFQ. The deIault hold-queue limit with WFQ is 1000 packets.
The WFQ system will generally never reach the hold-queue limit because the CDT limit starts
dropping packets oI aggressive Ilows. Under special circumstances it would be possible to Iill
the WFQ system. For example, a denial-oI-service attack that Iloods the interIace with a large
number oI packets (each diIIerent) could Iill all queues at the same rate.
AdditionaI WFQ Configuration
Parameters
hold~queue max~limit out hold~queue max~limit out
router(config~if)#
· Specifies the maximum number of packets that can be in
aII output queues on the interface at any time.
· The defauIt vaIue for WFQ is 1000.
· Under speciaI circumstances WFQ can consume a Iot of
buffers which may require Iowering this Iimit.
The Iigure explains the deIault behavior oI WFQ. As mentioned previously, WFQ is
automatically enabled on all interIaces slower than 2 Mbps. WFQ is also required on interIaces
using Multilink PPP (MLP).
WFQ cannot be used iI reordering oI Irames is not allowed due to sequence numbering oI
Layer 2 Irames or iI the switching path does not support WFQ.
WFQ Configuration DefauIts
· Fair queuing is enabIed by defauIt on
÷ PhysicaI interfaces whose bandwidth is Iess than or
equaI to 2.048 Mbps
÷ Interfaces configured for MuItiIink PPP
· Fair queuing is disabIed
÷ If you enabIe the autonomous or siIicon switching
engine mechanisms
÷ For any sequenced encapsuIation: X.25, SDLC, LAPB,
reIiabIe PPP
Monitoring WFQ
This topic describes the Cisco IOS commands that are used to monitor the operation oI WFQ.
The same show commands can be used as with other queuing mechanisms:
show interface
show queue
show queueing
The show interface command can be used to determine the queuing strategy. The summary
statistics are also displayed.
The sample output in the Iigure shows that there are currently no packets in the WFQ system
that allows up to 1000 packets (hold-queue limit) with CDT 64. WFQ is using 256 queues. The
maximum number oI concurrent conversations (active queues) was 4.
Monitoring WFQ
show interface interface show interface interface
router>
· DispIays interface deIays incIuding the activated queuing
mechanism with the summary information
Router>show interface serial 1/0
Hardware is M4T
MTU 1500 bytes, BW 19 Kbit, DLY 20000 usec, rely 255/255, load
147/255
Fncapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/4/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 18000 bits/sec, 8 packets/sec
5 minute output rate 11000 bits/sec, 9 packets/sec
. rest deleted ...
The show queue command is used to display the contents oI packets inside a queue Ior a
particular interIace, including Ilow (conversation) statistics:
Queue depth is the number oI packets in the queue.
Weight is 4096/(IP precedence ¹ 1) or 32384/(IP precedence ¹ 1), depending on the Cisco
IOS version.
In the command output, discards are used to represent the number oI drops due to the CDT
limit.
In the command output, tail drops are used to represent the number oI drops due to the
hold-queue limit.
Monitoring WFQ (Cont.)
show queue interface~name interface~number show queue interface~name interface~number
router>
· DispIays detaiIed information about the WFQ system of the
seIected interface
Router>show queue serial 1/0
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
(depth/weight/discards/tail drops/interleaves) 1/4096/0/0/0
Conversation 124, linktype: ip, length: 580
source: 193.77.3.244, destination: 20.0.0.2, id: 0x0166, ttl: 254,
ToS: 0 prot: 6, source port 23, destination port 11033
(depth/weight/discards/tail drops/interleaves) 1/4096/0/0/0
Conversation 127, linktype: ip, length: 585
source: 193.77.4.111 destination: 40.0.0.2, id: 0x020D, ttl: 252,
ToS: 0 prot: 6, source port 23, destination port 11013
Summary
References
To learn more about conIiguring WFQ, reIer to 'ConIiguring Weighted Fair Queueing¨ at
the Iollowing URL:
hapter09186a00800ca597.html
Next Steps
Lab Exercise 5-1: ConIiguring Basic Queuing
Summary
· The software FIFO queue is basicaIIy an extension to the
hardware FIFO queue.
· WFQ was deveIoped to overcome the Iimitations of the
more basic queuing methods.
· With WFQ, bandwidth is shared fairIy among fIows by:
÷ Reducing response time for interactive fIows by scheduIing them to
the front of the queue
÷ Preventing high voIume conversations from monopoIizing an
interface
· In WFQ, traffic is sorted into fIows and transmitted by the
order of the Iast bit crossing its channeI.
· Unfairness is reinstated into WFQ by introducing weight
(IP precedence) to give proportionateIy more bandwidth
to fIows with higher weight.
Quiz
Q1) Which three oI the Iollowing represent the strategy behind WFQ? (Choose three.)
A) dedicated queue Ior each Ilow
B) immediately dispatch all voice packets
C) Iairly allocate bandwidth among all Ilows
D) use IP precedence as weight when allocating bandwidth
Q2) Which three oI the Iollowing would be used to identiIy a WFQ Ilow? (Choose three.)
A) destination IP address
B) HTTP application identiIier
C) source TCP/UDP port number
D) protocol number (identiIying TCP or UDP)
Q3) How many queues are recommended with WFQ?
A) same number oI queues as there are Ilows
B) several times as many queues as there are Ilows
C) depends upon the QoS requirements oI the applications
D) one queue Ior each predicted three or Iour Ilows (on average)
Q4) Which two represent the two modes oI dropping used in WFQ? (Choose two.)
A) early dropping when HQO is reached
B) early dropping when CDT is reached
C) aggressive dropping when CDT is reached
D) aggressive dropping when HQO is reached
Q5) Given that the Iollowing Iive packets arrive at a router using WFQ, in what order
would the packets be dispatched? (Each packet typeA or Brepresents a diIIerent
Ilow and, thereIore, will go to a diIIerent queue.)
Packets Arriving at Router
Packet ArrivaI Time Time to Transmit Packet
A1 T + 0 500 ms
A2 T + 50 100 ms
B1 T + 150 250 ms
B2 T + 150 400 ms
B3 T + 200 400 ms
A) A1, B1, A2, B2, B3
B) A1, A2, B1, B2, B3
C) A1, B1, B2, A2, B3
D) B1, A1, A2, B2, B3
Q6) Which three oI the Iollowing represent beneIits oI WFQ? (Choose three.)
A) simple conIiguration
B) guaranteed throughput to all Ilows
C) provides Iixed bandwidth guarantees
D) drops packets oI the most aggressive Ilows
Quiz Answer Key
Q1) A, C, D
ReIates to: Weighted Fair Queuing
Q2) A, C, D
ReIates to: WFQ Classification
Q3) B
ReIates to: WFQ Classification
Q4) B, D
ReIates to: WFQ Ìnsertion and Drop Policy
Q5) A
ReIates to: WFQ Scheduling
Q6) A, B, D
ReIates to: Benefits and Drawbacks of WFQ
CBWFQ and LLQ
Overview
CBWFQ extends the standard WFQ Iunctionality to provide support Ior user-deIined traIIic
classes. With CBWFQ, you deIine traIIic classes based on match criteria including protocols,
access control lists (ACLs), and input interIaces. Packets satisIying the match criteria Ior a
class constitute the traIIic Ior that class. A queue is reserved Ior each class, and traIIic
belonging to a class is directed to the queue Ior that class.
LLQ brings strict priority queuing to CBWFQ. Strict priority queuing allows delay-sensitive
data such as voice to be dequeued and sent Iirst (beIore packets in other queues are dequeued),
giving delay-sensitive data preIerential treatment over other traIIic.
ReIevance
These advanced queuing models oIIer the best QoS congestion management solutions Ior
networks with converged traIIic.
Objectives
Upon completing this lesson, you will be able to conIigure CBWFQ and LLQ to manage
congestion. This includes being able to meet these objectives:
Explain how basic queuing mechanisms can be used to build advanced queuing
mechanisms
Explain the purpose and Ieatures oI CBWFQ
Describe CBWFQ Ieatures and explain how CBWFQ works using a block diagram
Describe the beneIits oI CBWFQ
IdentiIy the Cisco IOS commands required to conIigure and monitor CBWFQ on a Cisco
router
Explain the purpose and Ieatures oI LLQ
Explain how LLQ works using a block diagram and identiIy situations in which LLQ is
most appropriate Ior providing QoS
Describe the beneIits oI LLQ
IdentiIy the Cisco IOS commands required to conIigure and monitor LLQ on a Cisco router
Basic knowledge oI internetworking with TCP/IP concepts and basic knowledge oI Cisco
IOS commands
OutIine
OutIine
· Overview
· CBWFQ and LLQ
· CBWFQ
· CBWFQ Architecture
· CBWFQ Benefits
· Configuring and Monitoring CBWFQ
· LLQ
· LLQ Architecture
· LLQ Benefits
· Configuring and Monitoring LLQ
· Summary
· Quiz
CBWFQ and LLQ
This topic explains how basic queuing mechanisms can be used to build more advanced
queuing mechanisms.
Neither the basic queuing methods nor the more advanced WFQ completely solved the QoS
problems resulting Irom converged network traIIic. Some problems remaining were:
II only priority queuing (PQ) was used Ior a voice-enabled network, voice would get the
priority needed. However, data traIIic would suIIer.
II only CQ was used Ior voice-enabled network, data traIIic would be assured oI some
bandwidth. However, voice traIIic would suIIer delays.
II WFQ was used, voice still experienced delay even when treated 'Iairly¨ by WFQ.
All oI the classiIication, marking, and queuing mechanisms were complicated to use and
time-consuming when applied on an interIace-by-interIace basis.
Newer queuing mechanisms were developed, which took the best aspects oI existing queuing
methods and applied them to give voice the priority it required while still ensuring that data
was serviced eIIiciently on a class basis.
CBWFQ and LLQ
Basic methods
are combined to
create more
versatiIe
queuing
mechanisms.
CBWFQ
This topic explains the purpose oI CBWFQ.
CBWFQ extends the standard WFQ Iunctionality to provide support Ior user-deIined traIIic
classes. With CBWFQ, the user deIines the traIIic classes based on match criteria that includes
protocols, ACLs, and input interIaces. Packets satisIying the match criteria Ior a class constitute
the traIIic Ior that class. A queue is reserved Ior each class, and traIIic belonging to a class is
directed to that class queue.
AIter a class has been deIined according to its match criteria, you can assign it characteristics.
To characterize a class, you assign it bandwidth, weight, and maximum packet limit. The
bandwidth assigned to a class is the minimum bandwidth delivered to the class during
congestion.
To characterize a class, you also speciIy the queue limit Ior that class, which is the maximum
number oI packets allowed to accumulate in the class queue. Packets belonging to a class are
subject to the bandwidth and queue limits that characterize the class. AIter a queue has reached
its conIigured queue limit, enqueuing oI additional packets to the class causes tail drop or
random packet drop to take eIIect, depending on how the class policy is conIigured.
CIass-Based Weighted Fair Queuing
· CBWFQ is a mechanism that is used to guarantee
bandwidth to cIasses.
· CBWFQ extends the standard WFQ functionaIity to
provide support for user-defined traffic cIasses.
÷ CIasses are based on user-defined match criteria.
÷ Packets satisfying the match criteria for a cIass constitute the
traffic for that cIass.
· A queue is reserved for each cIass, and traffic beIonging
to a cIass is directed to that cIass queue.
CBWFQ Architecture
This topic explains the Ieatures oI CBWFQ and how CBWFQ works.
CBWFQ supports multiple class maps (number depends upon platIorm) to classiIy traIIic into
their corresponding FIFO queues. Tail drop is the deIault dropping scheme oI CBWFQ
although it can be combined with WRED.
The CBWFQ scheduler is used to guarantee bandwidth that is based on the conIigured weights.
Note: Currently, except for the Cisco 7500 series router platform, all traffic classes (default traffic
class excluded) only support FÌFO queuing within the class. On all platforms, the default
traffic class can support either FÌFO or WFQ within the class. Check Cisco.com for the latest
information for WFQ support within each traffic class.
CBWFQ Architecture
· Supports muItipIe cIasses (depending on pIatform)
Any classiIication option can be used depending on the availability in the Cisco IOS version
and the support on the selected interIace and encapsulation.
It is important to note that CBWFQ is conIigured using Modular QoS command-line interIace
(CLI |MQC|).
CBWFQ Architecture:
CIassification
· CIassification uses cIass maps.
· AvaiIabiIity of certain cIassification options depends on
the Cisco IOS version.
· Some cIassification options depend on type of interface
and encapsuIation where service poIicy is used.
· For exampIe:
÷ Matching on Frame ReIay discard eIigibIe (DE) bits can onIy be
used on interfaces with Frame ReIay encapsuIation.
÷ Matching on MPLS experimentaI bits has no effect if MPLS is not
enabIed.
÷ Matching on ISL Priority bits has no effect if ISL is not used.
CBWFQ reserves multiple FIFO queues in the WFQ system. The deIault queue limit is 64 (tail-
drop) and can be conIigured with WRED (random drop).
CBWFQ Architecture:
Insertion PoIicy
· Each queue has a maximum number of packets that
it can hoId (queue size).
· The maximum queue size is pIatform-dependent.
· After a packet is cIassified to one of the queues, the
router wiII enqueue the packet if the queue Iimit has
not been reached (taiI-drop within each cIass).
· WRED can be used in combination with CBWFQ to
prevent congestion of the cIass.
You can conIigure bandwidth guarantees by using one oI the Iollowing commands:
The bandwidth command allocates a Iixed amount oI bandwidth by speciIying the amount
in kbps. The reserved bandwidth is subtracted Irom the available bandwidth oI the interIace
where the service policy is used. The allocated bandwidth must also be within the
conIigured reservable limit (75 percent by deIault).
The bandwidth percent command can be used to allocate a percentage oI the deIault or
available bandwidth oI an interIace. The deIault bandwidth usually equals the maximum
speed oI an interIace. Sometimes it actually reIlects the real speed oI an interIace (Ior
example, Ethernet or FastEthernet). The deIault value can be replaced by using the
bandwidth interIace command. It is recommended that the bandwidth reIlect the real speed
oI the link. The allocated bandwidth is subtracted Irom the available bandwidth oI the
interIace where the service policy is used.
The bandwidth remaining percent command can be used to allocate a portion oI the
unallocated bandwidth. The bandwidth is not subtracted Irom the available bandwidth oI
the interIace where the service policy is used.
A single service policy cannot mix the Iixed bandwidth (in kbps) and bandwidth percent
commands (except with strict priority queues).
CBWFQ Architecture:
ScheduIing
· CBWFQ guarantees bandwidth according to weights
assigned to traffic cIasses.
· Weights can be defined by specifying:
÷ Bandwidth (in kbps)
÷ Percentage of bandwidth (percentage of avaiIabIe interface
bandwidth)
÷ Percentage of remaining avaiIabIe bandwidth
· One service poIicy can not have mixed types of weights.
· The show interface command can be used to dispIay the
avaiIabIe bandwidth.
The available bandwidth displayed by the show interface command is calculated by
subtracting all Iixed bandwidth reservations Irom 75 percent oI the conIigured bandwidth oI an
interIace.
CBWFQ Architecture:
AvaiIabIe Bandwidth
· AvaiIabIe bandwidth is caIcuIated according to the
foIIowing formuIa:
Properly provisioning the network bandwidth is a major component oI successIul network
design. You can calculate the required bandwidth by adding the bandwidth requirements Ior
each major application (Ior example, voice, video, and data). The resulting sum represents the
minimum bandwidth requirement Ior any given link, and it should not exceed approximately 75
percent oI the total available bandwidth Ior the link. This 75 percent rule assumes that some
bandwidth is required Ior overhead traIIic, such as routing and Layer 2 keepalive messages, as
well as Ior additional applications such as e-mail and HTTP traIIic.
Thus, the total amount oI bandwidth allocated Ior all classes included in a policy map should
not exceed 75 percent oI the available bandwidth on the interIace. The max-reserved bandwidth
command overrides the 75 percent limitation, but overriding is recommended only Ior the most
knowledgeable network administrators who have access to precise Iigures Ior available, used
and required bandwidth. II not all oI the bandwidth is allocated, the remaining bandwidth is
proportionally allocated among the classes, based on their conIigured bandwidth.
Note that the 75 percent rule is conservative.
CBWFQ Architecture:
75 Percent RuIe
· Add up:
÷ CIass bandwidths
÷ RSVP maximum reserved bandwidth
· ResuIt must be Iess than or equaI to 75% of interface
bandwidth (or Frame ReIay, data-Iink connection identifier
[DLCI], committed information rate [CIR])
÷ Leaves headroom for caII signaIing, SimpIe Network Management
ProtocoI (SNMP), LocaI Management Interface (LMI), and routing
traffic
· The 75% ruIe is a conservative ruIe
· command overrides 75% Iimit,
but seIdom recommended
CBWFQ Benefits
This topic describes the beneIits oI CBWFQ.
CBWFQ Benefits
+ Benefits
· Minimum bandwidth aIIocation
· Finer granuIarity and scaIabiIity
· MQC interface easy to use
· Maximizes transport of priority traffic
· Weights guarantee minimum bandwidth
· Unused capacity shared among the other cIasses
· Queues separateIy configured for QoS
÷ Drawbacks
· Voice traffic can stiII suffer unacceptabIe deIay
CBWFQ allows the user to deIine traIIic classes based on custom-deIined match criteria such
as ACLs, input interIaces, protocol, and QoS label. For example, a class might consist oI a team
working on a certain project or a class can be created Ior the important mission-critical
applications such as enterprise resource planning (ERP). When the traIIic classes have been
deIined, they can be assigned a bandwidth, queue limit, or drop policy such as WRED.
Additional beneIits oI CBWFQ are the Iollowing:
Bandwidth allocation: CBWFQ allows you to speciIy the exact amount oI bandwidth to
be allocated Ior a speciIic class oI traIIic. Accounting Ior available bandwidth on the
interIace, you can conIigure multiple classes (number depends upon platIorm).
Finer granularity and scalability: CBWFQ allows you total Ilexibility to deIine a class,
based on ACLs and protocols or input interIaces, thereby providing Iiner granularity.
Supported by MQC: CBWFQ is supported by the easy-to-use MQC.
The CBWFQ Ieature is supported on all platIorms that WFQ is supported on; in other words,
the Cisco 7200, 4700, 4500, 3600, and 2600 series, and so on.
Configuring and Monitoring CBWFQ
This topic describes the Cisco IOS commands that are used to conIigure and monitor CBWFQ.
The bandwidth policy-map class conIiguration command is used to speciIy or modiIy the
bandwidth allocated Ior a class belonging to a policy map.
All classes belonging to one policy map should use the same type oI bandwidth guarantee
(Iixed in kbps, in percentage oI interIace bandwidth, in percentage oI available bandwidth).
ConIiguring bandwidth in percentages is most useIul when the underlying link bandwidth is
unknown or the relative class bandwidth distributions are known.
bandwidth ¦banawiath-kbps [ remaining percent percentage [ percent percentage]
Syntax Description
bandwidthkbps Amount of bandwidth, in kbps, to be assigned to the class.
remaining percent
percentage
Amount of guaranteed bandwidth, based on a relative percent of
available bandwidth. The percentage can be a number from 1 to
100.
percent percentage Amount of guaranteed bandwidth, based on an absolute percent
of available bandwidth. The percentage can be a number from 1
to 100.
Configuring CBWFQ
bandwidth bandwidth bandwidth bandwidth
· AIIocate a fixed amount of bandwidth to a cIass
· Set the vaIue in kbps
bandwidth percent percent bandwidth percent percent
· AIIocate a percentage of bandwidth to a cIass
· The configured (or defauIt) interface bandwidth is used to
caIcuIate the guaranteed bandwidth
bandwidth remaining percent percent bandwidth remaining percent percent
· AIIocate a percentage of avaiIabIe bandwidth to a cIass
The Iollowing restrictions apply to the bandwidth command:
II the percent keyword is used, the sum oI the class bandwidth percentages cannot exceed
100 percent.
The amount oI bandwidth conIigured should be large enough to also accommodate Layer 2
overhead.
A policy map can have all the class bandwidths speciIied in kbps or all the class
bandwidths speciIied in percentages, but not a mix oI both. However, the unit Ior the
priority command in the priority class can be diIIerent Irom the bandwidth unit oI the low
priority class.
The deIault queue limit oI 64 packets can be changed using the queue-limit command. It is
recommended not to change the deIault value.
The deIault class can be selected by speciIying the class-default name oI the class. The deIault
class supports two types oI queuing: one FIFO queue (deIault) or a Ilow-based WFQ system.
Both types can be combined with WRED. FIFO queue can also get a bandwidth guarantee.
ExampIe: Configuration of FIFO Queuing
The Iollowing example shows the conIiguration oI FIFO queuing within the deIault class. The
deIault class is also guaranteed 1 Mbps oI bandwidth and the maximum queue size is limited to
40 packets.
policy-map A
class A
bandwidth I000
class class-default
bandwidth I000
queue-limit 40
ExampIe: Configuration of WFQ Queuing
This next example shows the conIiguration oI WFQ queuing within the deIault class. The
number oI dynamic queues is set to 1024 and the discard threshold is set to 50.
policy-map A
class A
bandwidth I000
class class-default
fair-queue I0?4
Configuring CBWFQ (Cont.)
queue~limit gueue~limit queue~limit gueue~limit
· Set the maximum number of packets this queue can hoId
· The defauIt maximum is 64
fair~queue (number~of~dynamic~gueues) fair~queue (number~of~dynamic~gueues)
· The "cIass-defauIt" cIass can be configured to use WFQ
· The number of dynamic queues is a power of 2 number in the
range from 16 to 4096 specifying the number of dynamic queues
The sample conIiguration shows how CBWFQ is used to guarantee bandwidth to each oI the
two classes.
Configuring CBWFQ (Cont.)
Router(config)# access~list 101 permit udp host 10.10.10.10 host
10.10.10.20 range 16384 20000
Router(config~if)# access~list 101 permit udp host 10.10.10.10
host 10.10.10.20 range 53000 56000
Router(config)# class~map class1
Router(config~cmap)# match access~group 101
Router(config~cmap)# exit
Router(config~cmap)# class~map class2
Router(config~cmap)# match access~group 102
Router(config~cmap)# exit
Router(config)# policy~map policy1
Router(config~pmap)# class class1
Router(config~pmap~c)# bandwidth 3000
Router(config~pmap~c)# queue~limit 30
Router(config~pmap~c)# exit
Router(config~pmap)# class class2
Router(config~pmap~c)# bandwidth 2000
Router(config~pmap~c)# exit
The show policy-map interface command displays all service policies applied to the interIace.
Among the settings, policing parameters and statistics are displayed.
Monitoring CBWFQ
show policy~map interface (interface) show policy~map interface (interface)
router>
· DispIays parameters and statistics of CBWFQ
router>show policy~map interface
FastFthernet0/0
Service~policy output: Policy1
Class~map: Class1 (match~any)
0 packets, 0 bytes
Match: any
Bandwidth remaining 20 (%) Max Threshold 64 (packets)
Class~map: class~default (match~any)
Match: any
LLQ
This topic describes the purpose and Ieatures oI LLQ.
While WFQ provides a Iair share oI bandwidth to every Ilow, and provides Iair scheduling oI
its queues, it cannot provide guaranteed bandwidth and low delay to select applications. For
example, voice traIIic may still compete with other aggressive Ilows in the WFQ queuing
system because the WFQ system lacks priority scheduling Ior time-critical traIIic classes.
The LLQ Ieature brings strict priority queuing to CBWFQ. Strict priority queuing allows delay-
sensitive data such as voice to be dequeued and sent Iirst (beIore packets in other queues are
dequeued), giving delay-sensitive data preIerential treatment over other traIIic.
Without LLQ, CBWFQ provides weighted Iair queuing based on deIined classes with no strict
priority queue available Ior real-time traIIic. CBWFQ allows you to deIine traIIic classes and
then assign characteristics to that class. For example, you can designate the minimum
bandwidth delivered to the class during congestion.
For CBWFQ, the weight Ior a packet belonging to a speciIic class is derived Irom the
bandwidth that you assigned to the class when you conIigured it. ThereIore, the bandwidth
assigned to the packets oI a class determines the order in which packets are sent. All packets
are serviced Iairly based on weight; no class oI packets may be granted strict priority. This
scheme poses problems Ior voice traIIic, which is largely intolerant oI delay, especially
variation in delay. For voice traIIic, variations in delay introduce irregularities oI transmission
maniIesting as jitter in the heard conversation.
The LLQ Ieature provides strict priority queuing Ior CBWFQ, reducing jitter in voice
conversations. ConIigured by the priority command, LLQ enables use oI a single, strict
priority queue within CBWFQ at the class level, allowing you to direct traIIic belonging to a
class to the CBWFQ strict priority queue. To enqueue class traIIic to the strict priority queue,
you conIigure the priority command Ior the class aIter you speciIy the named class within a
Low-Latency Queuing
· Priority queue added to CBWFQ for reaI-time
traffic
· High-priority cIasses are guaranteed:
÷ Low-Iatency propagation of packets
÷ Bandwidth
· High-priority cIasses are aIso poIiced - they can
not exceed the guaranteed bandwidth
· Lower priority cIasses use CBWFQ
policy map. (Classes to which the priority command is applied are considered priority classes.)
Within a policy map, you can give one or more classes priority status. When multiple classes
within a single policy map are conIigured as priority classes, all traIIic Irom these classes is
enqueued to the same, single, strict priority queue.
LLQ Architecture
This topic explains how LLQ works and identiIies situations in which LLQ is most appropriate
Ior providing QoS.
When CBWFQ is conIigured as the queuing system, it creates a number oI queues, into which
it classiIies traIIic classes. These queues are then scheduled with a WFQ-like scheduler, which
can guarantee bandwidth to each class.
II LLQ is used within the CBWFQ system, it creates an additional priority queue in the WFQ
system, which is serviced by a strict priority scheduler. Any class oI traIIic can thereIore be
attached to a service policy, which uses priority scheduling, and hence can be prioritized over
other classes.
LLQ Architecture
LLQ Benefits
This topic describes the beneIits oI LLQ.
The LLQ priority scheduler guarantees both low-latency propagation oI packets and bandwidth
to high-priority classes. Low-latency is achieved by expediting traIIic using a priority
scheduler. Bandwidth is also guaranteed by the nature oI priority scheduling, but is policed to a
user-conIigurable value. The strict PQ scheme allows delay-sensitive data such as voice to be
dequeued and sent Iirstthat is, beIore packets in other queues are dequeued. Delay-sensitive
data is given preIerential treatment over other traIIic.
This Ieature provides strict PQ on ATM virtual circuits (VCs); the IP Real-Time Transport
Protocol (RTP) priority Ieature only allows PQ on interIaces. Because you can conIigure the
priority status Ior a class within CBWFQ, you are not limited to UDP port numbers to stipulate
priority Ilows (which were necessary with IP RTP). Instead, all oI the valid match criteria used
to speciIy traIIic Ior a class now applies to priority traIIic.
Policing oI priority queues also prevents the priority scheduler Irom monopolizing the CBWFQ
scheduler and starving non-priority classes, like legacy PQ does. By conIiguring the maximum
amount oI bandwidth allocated Ior packets belonging to a class, you can avoid starving non-
priority traIIic.
LLQ Benefits
Benefits
· High-priority cIasses are guaranteed:
÷ Low-Iatency propagation of packets
÷ Bandwidth
· Consistent configuration and operation across aII media
types
· Entrance criteria to a cIass can be defined by an ACL
÷ Not Iimited to UDP ports as with IP RTP priority
÷ Ensure trust boundary is defined to ensure simpIe cIassification
and entry to a queue
Configuring and Monitoring LLQ
This topic describes the Cisco IOS commands that are used to conIigure and monitor LLQ.
When you speciIy the priority command Ior a class, it takes a bandwidth argument that gives
maximum bandwidth in kbps. You use this parameter to speciIy the maximum amount oI
bandwidth allocated Ior packets belonging to the class conIigured with the priority command.
The bandwidth parameter both guarantees bandwidth to the priority class and restrains the Ilow
oI packets Irom the priority class.
Configuring LLQ
priority bandwidth (burst) priority bandwidth (burst)
· AIIocate a fixed amount of bandwidth (in kbps) to a cIass
and ensure expedited forwarding.
· Traffic exceeding the specified bandwidth is dropped if
congestion otherwise poIicy is not used.
priority percent percentage (burst) priority percent percentage (burst)
· AIIocate a percentage of configured or defauIt interface
bandwidth to a cIass and ensure expedited forwarding.
· Traffic exceeding the specified bandwidth is dropped if
congestion otherwise poIicy is not used.
priority ¦bandwidth-kbps , percent percentage} |burst|
bandwidth~kbps Guaranteed allowed bandwidth, in kbps, for the priority traffic.
The amount of guaranteed bandwidth varies according to the
interface and platform in use. Beyond the guaranteed bandwidth,
the priority traffic will be dropped in the event of congestion to
ensure that the non-priority traffic is not starved.
percent Specifies that the amount of guaranteed bandwidth will be
specified by the percent of available bandwidth.
percentage Used in conjunction with the percent keyword, specifies the
percentage of the total available bandwidth to be set aside for the
priority class. The percentage can be a number from 1 to 100.
burst (Optional) Specifies the burst size, in bytes. The range of the
burst is 32 to 2,000,000 bytes.
In the event oI congestion, when the bandwidth is exceeded policing is used to drop packets.
Voice traIIic enqueued to the priority queue is UDP-based and thereIore not adaptive to the
early packet drop characteristic oI WRED. Because WRED is ineIIective, you cannot use the
WRED random-detect command with the priority command. In addition, because policing is
used to drop packets and queue limit is not imposed, the queue-limit command cannot be used
with the priority command.
When congestion occurs, traIIic destined Ior the priority queue is metered to ensure that the
bandwidth allocation conIigured Ior the class to which the traIIic belongs is not exceeded.
Priority traIIic metering has the Iollowing qualities:
It is much like Committed Access Rate (CAR) rate limiting, except that priority traIIic
metering is only perIormed under congestion conditions. When the device is not congested,
the priority class traIIic is allowed to exceed its allocated bandwidth. When the device is
congested, the priority class traIIic above the allocated bandwidth is discarded.
PerIormed metering on a per-packet basis, and tokens are replenished as packets are sent. II
not enough tokens are available to send the packet, the packet is dropped.
Restrains priority traIIic to its allocated bandwidth to ensure that non-priority traIIic, such
as routing packets and other data, is not starved.
With metering, the classes are policed and rate-limited individually. That is, although a single
policy map might contain Iour priority classes, all oI which are enqueued in a single priority
queue, they are each treated as separate Ilows with separate bandwidth allocations and
constraints.
Note: Ìt is important to note that because bandwidth for the priority class is specified as a
parameter to the priority command, you cannot also configure the bandwidth command for
a priority class. To do so is a configuration violation that would only introduce confusion in
relation to the amount of bandwidth to allocate.
Keep the Iollowing guidelines in mind when using the priority command:
Layer 2 encapsulations are accounted Ior in the amount oI bandwidth speciIied with the
priority command. However, ensure that a bandwidth is conIigured with room Ior the cell-
tax overhead.
Use the priority command Ior Voice over IP (VoIP) on serial links and ATM PVCs.
Note: An exception to these guidelines for LLQ is Frame Relay on the Cisco 7200 router and other
non-Route Switch Processor (RSP) platforms. The original implementation of LLQ over
Frame Relay on these platforms did not allow the priority classes to exceed the configured
rate during periods of non-congestion. Cisco ÌOS Software release 12.2 removes this
exception and ensures that non-conforming packets are only dropped if there is congestion.
Ìn addition, packets smaller than an FRF.12 fragmentation size are no longer sent through
the fragmenting process, resulting in reduced CPU utilization.
Use the priority command in conjunction with the set command. You cannot use the
priority command in conjunction with any other command, including the random-detect,
queue-limit, and bandwidth commands.
You can conIigure the priority command in multiple classes, but you should only use it Ior
voice-like, constant bit rate (CBR) traIIic. II the traIIic is not CBR, you must conIigure a
large enough bandwidth parameter to absorb the data bursts.
Warning Although it is possible to enqueue various types of real-time traffic to the strict priority queue,
it is strongly recommended that you direct only voice traffic to it. This recommendation is
made because voice traffic is well behaved, whereas other types of real-time traffic are not.
Moreover, voice traffic requires that delay is non-variable in order to avoid jitter. Real-time
traffic such as video could introduce variation in delay, thereby thwarting the steadiness of
delay required for successful voice traffic transmission.
ExampIe: CaIcuIating LLQ BW Required for VoIP
The bandwidth consumed by VoIP streams is calculated by adding the packet payload and all
the headers, then multiplying that total number by the per-second packet rate.
The Iollowing example shows how to calculate the VoIP bearer bandwidth requirement Ior a
single VoIP call using a G.711 codec:
G.III ¬ I80 bytes payload size
Packet size ¬ payload size + IP/UDP/RTP headers
¬ I80 bytes + ?0 bytes + 8 bytes + I? bytes
¬ ?00 bytes
Sampling Rate ¬ ?0 msec per sample ¬ S0 samples per second
Bandwidth (bytes/sec) without Layer ? overhead
¬ ?00 bytes/packet x S0 packets/second
¬ I0000 bytes/second
Bandwidth (bits/sec) without Layer ? overhead
¬ I0000 bytes/second * 8 bits/byte
¬ 80000 bytes/second (80 kbps)
Bandwidth (bits/sec) with Layer ? overhead
¬ 80000 bytes/second + L? overhead
bytes/second
This Iigure shows a conIiguration example where the VoIP traIIic class, classiIied by the IP
precedence oI 5, is queued in a priority queue within the CBWFQ system. The priority class
received priority scheduling compared to other classes queues: it is guaranteed but limited to 10
percent oI bandwidth.
Configuring LLQ (Cont.)
class~map voip
match ip precedence 5
!
class~map mission~critical
!
class~map transactional
!
policy~map Policy1
class voip
priority percent 10
class mission~critical
bandwidth percent 30
random~detect
class transactional
random~detect
class class~default
fair~queue
random~detect
The show policy-map interface command displays the packet statistics oI all classes that are
conIigured Ior all service policies on the speciIied interIace. Some oI the key Iields in the
command output are described as Iollows:
Class~map Class of traffic being displayed. Output is displayed for each
configured class in the policy.
offered rate Rate, in kbps, of packets coming in to the class.
drop rate Rate, in kbps, at which packets are dropped from the class. The
drop rate is calculated by subtracting the number of successfully
transmitted packets from the offered rate.
Match Match criteria specified for the class of traffic.
pkts matched/bytes
matched
Number of packets (also shown in bytes) matching this class that
were placed in the queue.
depth/total drops/no~
buffer drops
Number of packets discarded for this class. No-buffer indicates
that no memory buffer exists to service the packet.
Monitoring LLQ
show policy~map interface interface show policy~map interface interface
router>
· DispIays the packet statistics of aII cIasses that are configured for aII
service poIicies either on the specified interface or subinterface
router>show policy~map interface fastethernet 0/0
FastFthernet0/0
Service~policy output: LLQ
Class~map: LLQ (match~any)
0 packets, 0 bytes
Match: any
Strict Priority
Bandwidth 1000 (kbps) Burst 25000 (Bytes)
(total drops/bytes drops) 0/0
0 packets, 0 bytes
Match: any
Summary
References
To learn more about CBWFQ, reIer to 'Class-Based Weighted Fair Queueing¨ at the
Iollowing URL:
080087a84.html
To learn more about LLQ, reIer to 'Low Latency Queueing¨ at the Iollowing URL:
080087b13.html
To learn more about WFQ and DWFQ, reIer to 'ConIiguring Weighted Fair Queueing¨ at
the Iollowing URL:
hapter09186a00800ca597.html
To learn more about conIiguring CBWRQ with FRTS, reIer to 'ConIiguring Class Based
Weighted Fair Queueing with FRTS¨ at the Iollowing URL:
http://www.cisco.com/en/US/tech/tk713/tk237/technologies¸conIiguration¸example09186a
008009486b.shtml
Next Steps
Lab Exercise 5-2: ConIiguring LLQ
Summary
· CBWFQ is a mechanism that is used to guarantee
bandwidth to cIasses of network traffic.
· CBWFQ extends the standard WFQ functionaIity to
provide support for user-defined traffic cIasses.
· CIasses are based on user-defined match criteria.
· Packets satisfying the match criteria for a cIass
constitute the traffic for that cIass.
· LLQ extends the functionaIity of CBWFQ by adding
priority queues for time-sensitive traffic such as voice
and video.
Quiz
Q1) How does CBWFQ extend the Iunctionality oI standard WFQ?
A) ensures that all Ilows go to a single queue
B) oIIers signiIicant new classiIication options
C) provides support Ior user-deIined traIIic classes
D) provides a low-latency queue to ensure instant dispatch oI voice packets
Q2) Which three oI the Iollowing options can be used to deIine weights in CBWFQ?
(Choose three.)
A) IP precedence
B) bandwidth (in kbps)
C) bandwidth percentage
D) percentage oI available bandwidth
Q3) Which oI the Iollowing is used when conIiguring bandwidth guarantees Ior CBWFQ?
A) class-map
B) policy-map
C) queue-policy
D) service-policy
Q4) Which oI the Iollowing statements best represents the LLQ policy Ior high-priority
classes?
A) They are shaped and cannot exceed bandwidth guarantee.
B) They are policed and cannot exceed bandwidth guarantee.
C) They are shaped to provide minimal delay with no packet loss.
D) They are not policed to ensure low-latency packets are always dispatched.
Q5) How does LLQ prevent starvation oI non-priority queues?
A) alternate priority queues
B) pre-emptive non-priority queues
C) bandwidth policing oI priority queues
D) ModiIied Round Robin servicing oI all queues
Q6) Which header should be included when calculating bandwidth Ior LLQ Ior ATM?
A) cell tax overhead
B) Layer 2 encapsulation
C) RTP headers Ior voice
D) UTP and RTP headers Ior voice
Quiz Answer Key
Q1) C
ReIates to: CBWFQ
Q2) B, C, D
ReIates to: CBWFQ Architecture
Q3) B
ReIates to: Configuring and Monitoring CBWFQ
Q4) B
ReIates to: LLQ
Q5) C
ReIates to: LLQ Architecture
Q6) A
ReIates to: Configuring and Monitoring LLQ
LAN Congestion Management
Overview
DiIIerent Cisco Catalyst switches oIIer various mechanisms Ior providing QoS. This lesson
provides an overview oI the way several key Catalyst switches provide queuing support Ior
QoS and how to conIigure those switches Ior QoS. PQ, WRR queuing, and WRR with an
expedite queue (as used on the Cisco Catalyst 2950 switches) are explained in this lesson.
ReIevance
The most eIIective QoS implementation begins at the edge oI the network where Cisco Catalyst
switches are normally deployed. Understanding how queuing works at the earliest stage oI QoS
deployment is key to designing and building an eIIective QoS-aware network.
Objectives
Upon completing this lesson you will be able to conIigure WRR on a Catalyst switch to
manage LAN congestion. This includes being able to meet these objectives:
Describe the diIIerent queuing capabilities available on Cisco Catalyst switches
Explain how WRR works on a Catalyst 2950 switch
Describe the commands required to conIigure PQ on Catalyst 2950 switches
Describe the commands required to conIigure WRR on Catalyst 2950 switches
Describe the commands required to monitor queuing on Catalyst 2950 switches
Basic knowledge oI internetworking with TCP/IP concepts and basic Catalyst IOS
commands
OutIine
OutIine
· Overview
· Queuing on CataIyst Switches
· Weighted Round Robin
· Configuring PQ on CataIyst 2950 Switches
· Configuring WRR on CataIyst 2950 Switches
· Monitoring Queuing on CataIyst 2950 Switches
· Summary
· Quiz
Queuing on CataIyst Switches
This topic explains the diIIerent methods oI queuing that are available on key Catalyst
switches.
Queuing on CataIyst Switches
· MuItipIe queues protect the
queue containing important
traffic (voice) from drops.
· The number of queues
avaiIabIe depends upon the
switch modeI and port
type.
· On some switches "drop
threshoIds" can be
assigned to each queue.
· On some switches, queues
can have normaI taiI-drop
or WRED dropping.
· Drops happen in data-onIy
queue(s).
In a converged network, it is vital to ensure that voice traIIic is not dropped. The use oI
multiple queues in Catalyst switches protects the queue containing important traIIic (voice)
Irom being dropped. Cisco Catalyst switches oIIer a variety oI queuing capabilities depending
upon the switch model and port type.
One oI the key options that can be assigned to queues in most Catalyst switches is 'drop
thresholds.¨ A queue can be assigned one or more drop thresholds. Packets are queued until the
thresholds are exceeded.
For example, all packets with diIIerentiated services code points (DSCPs) that are assigned to
the Iirst threshold are dropped until the threshold is no longer exceeded. However, packets
assigned to a second threshold continue to be queued and sent as long as the second threshold is
not exceeded. The thresholds are all speciIied as percentages ranging Irom 1 to 100. A value oI
10 indicates a threshold when the buIIer is 10 percent Iull.
On some switches, queues can have normal tail drop or WRED dropping. WRED is explained
Iurther in the next module oI this course.
Drops will happen only in data-only queues. The purpose oI using multiple queues is to prevent
voice traIIic Irom being dropped or delayed.
DiIIerent Cisco Catalyst switches oIIer diIIerent queuing capabilities. The queuing capabilities
include:
The number oI queues per port
The type oI queues (priority or standard)
The capability to have drop thresholds Ior a queue
The number oI drop thresholds per queue
The type oI drop thresholds (tail drop or WRED).When you view inIormation on Cisco
Catalyst switches, queuing inIormation is displayed in an abbreviated Iormat. For example:
2Q2T indicates that the switch supports two standard queues and two drop
thresholds per queue.
1P2Q2T indicates that the switch supports one priority queue, two standard queues,
and two drop thresholds per queue.
· Key queuing features depend upon the switch
hardware:
÷ The number of queues per port
÷ The type of queues (priority or standard)
÷ The capabiIity to have drop threshoIds for a queue
÷ The number of drop threshoIds per queue
÷ The type of drop threshoIds (taiI drop or WRED)
· Switch queuing capabiIities are shown as:
÷ 2Q2T
· 2Q2T: Two queues
· 2Q2T: Two drop threshoIds for each queue
÷ 1P2Q2T
· 1P2Q2T: One priority queue
· 1P2Q2T: Two additionaI queues
· 1P2Q2T: Two drop threshoIds for each queue
Queuing on CataIyst Switches (Cont.)
The chart shows the capabilities oI Catalyst switch models.
6500 Series CataIyst Switches
The Catalyst 6500 provides both receive (Rx) and transmit (Tx) queues. The number and type
oI queues is dependent upon the line card.
The Rx queues are designed to protect voice traIIic Irom delays or drops. An example oI the
implementation oI an Rx queue with a priority queue and a standard queue with drop thresholds
(1p1q4t) is:
Frames with class oI service (CoS) 5 go to the priority queue.
Frames with CoS 0, 1, 2, 3, 4, 6, or 7 go to the standard Rx queue as Iollows:
Using standard receive-queue tail-drop threshold 1, the switch drops incoming
Irames with CoS 0 or 1 when the receive-queue buIIer is 50 percent or more Iull.
Irames with CoS 2 or 3 when the receive-queue buIIer is 60 percent or more Iull.
Irames with CoS 4 when the receive-queue buIIer is 80 percent or more Iull.
Irames with CoS 6 or 7 when the receive-queue buIIer is 100 percent Iull.
An example oI the implementation oI a Tx queue with 2 queues and 2 drop thresholds (2q2t) on
the Catalyst 6500 is:
For 2q2t ports, each Tx queue has two tail-drop thresholds that Iunction as Iollows:
Frames with CoS 0, 1, 2, or 3 go to the low-priority Tx queue (queue 1):
Using Tx queue 1, tail-drop threshold 1, the switch drops Irames with CoS 0 or
1 when the low-priority transmit-queue buIIer is 80 percent Iull.
3 when the low-priority transmit-queue buIIer is 100 percent Iull.
Frames with CoS 4, 5, 6, or 7 go to the high-priority Tx queue (queue 2):
5 when the high-priority transmit-queue buIIer is 80 percent Iull.
7 when the high-priority transmit-queue buIIer is 100 percent Iull.
4000 Series CataIyst Switches
On the Catalyst 4000 with a Supervisor III engine, each physical port has Iour Tx queues
(egress queues). Each packet that needs to be transmitted is enqueued to one oI the Tx queues.
The Tx queues are then serviced based on the Tx queue scheduling algorithm.
When the Iinal transmit DSCP is computed (including any markdown oI DSCP), the transmit
DSCP to Tx queue mapping conIiguration determines the Tx queue. The packet is placed in the
Tx queue oI the transmit port, determined Irom the transmit DSCP.
The Iour Tx queues Ior a transmit port share the available link bandwidth oI that transmit port.
You can set the link bandwidth to be shared diIIerently among the Tx queues using bandwidth
command in interIace Tx queue conIiguration mode. With this command, you assign the
minimum guaranteed bandwidth Ior each Tx queue.
By deIault, all queues are scheduled in a round robin manner.
You can conIigure Tx queue 3 on each port with higher priority. When Tx queue 3 is
conIigured with higher priority, packets in Tx queue 3 are scheduled ahead oI packets in other
queues.
When Tx queue 3 is conIigured at a higher priority, the packets are scheduled Ior transmission
beIore the other Tx queues only iI it has not met the allocated bandwidth sharing conIiguration.
Any traIIic that exceeds the conIigured shape rate will be queued and transmitted at the
conIigured rate. II the burst oI traIIic exceeds the size oI the queue, packets will be dropped to
maintain transmission at the conIigured shape rate.
Drop thresholds can be conIigured as tail drop or WRED.
3550 CataIyst Switches
On the 3550 Catalyst switches, the deIault scheduling method is strict priority. Strict priority
scheduling is based on the priority oI queues. Packets in the high-priority queue always
transmit Iirst, and packets in the low-priority queue do not transmit until all the higher-priority
queues become empty.
CoS values can be assigned to queues during conIiguration. The deIault CoS to queue
assignment is:
CoS 6 to 7 placed in queue 4
The switches support PQ, WRR scheduling, and WRR with a priority queue.
The WRR scheduling algorithm ensures that lower-priority packets are not entirely starved
Ior bandwidth and are serviced without compromising the priority settings administered by
the network manager.
WRR with a priority queue ensures that higher-priority packets will always get serviced
Iirst, ahead oI other traIIic in lower-priority queues. The priority queue is deIined as
queue 4.
Queue weights and queue depths are conIigurable.
Drop thresholds can be conIigured as tail drop or WRED.
On the Catalyst 2950 series switches, the deIault scheduling method is strict priority. Strict
priority scheduling is based on the priority oI queues. Packets in the high-priority queue always
transmit Iirst; packets in the low-priority queue do not transmit until all the high-priority queues
become empty.
CoS values can be assigned to queues during conIiguration. The deIault CoS to queue
assignment is:
Catalyst 2950 switches support PQ, WRR scheduling, and WRR with a priority queue.
The WRR scheduling algorithm ensures that lower-priority packets are not entirely starved
Ior bandwidth and are serviced without compromising the priority settings administered by
the network manager.
WRR with a priority queue ensures that higher-priority packets will always get serviced
Iirst, ahead oI other traIIic in lower priority queues. The priority queue is deIined as
queue 4.
Queue weights are conIigurable.
· 4 Transmit Queues
(1P3Q or 4Q)
· Need to configure PQ and
ensure that CoS 5 traffic
assigned to the PQ
÷ ConfigurabIe PQ for queue 4
÷ ConfigurabIe CoS to specific
queue
÷ ConfigurabIe queue weight
This topic explains how WRR works on a Catalyst 2950 switch.
WRR scheduling requires that you speciIy a number that indicates the importance (weight) oI
the queue relative to the other CoS queues. WRR scheduling prevents the low-priority queues
Irom being completely neglected during periods oI high-priority traIIic. The WRR scheduler
transmits some packets Irom each queue in turn. The number oI packets it sends corresponds to
the relative importance oI the queue. For example, iI one queue has a weight oI 3 and another
has a weight oI 4, three packets are sent Irom the Iirst queue Ior every Iour that are sent Irom
the second queue. By using this scheduling, low-priority queues have the opportunity to send
packets even though the high-priority queues are not empty.
WRR scheduling with an expedite priority queue (also reIerred to as strict PQ) uses one oI the
egress queues as an expedite queue (queue 4 on a Catalyst 2950). The remaining queues
participate in WRR. When the expedite queue is conIigured, it is a priority queue and is
serviced until it is empty beIore the other queues are serviced by WRR scheduling. Actions at
the egress interIace include queuing and scheduling:
Queuing evaluates the internal DSCP and determines which oI the Iour egress queues in
which to place the packet. The DSCP value is mapped to a CoS value, which selects one oI
the queues.
Scheduling services the Iour egress queues based on their conIigured WRR weights and
thresholds. One oI the queues can be the expedite queue, which is serviced until empty
beIore the other queues are serviced.
Congestion avoidance techniques include tail drop and WRED on Gigabit-capable Ethernet
ports and tail drop (with only one threshold) on 10/100 Ethernet ports.
· PQ can starve Iower priority queues.
· WRR scheduIing prevents Iow PQs from being compIeteIy
starved during periods of heavy high-priority traffic.
· Different weights assigned to each queue .
· For exampIe, in one scheduIing round, the WRR
scheduIer wiII transmit:
÷ Three frames from a queue assigned Weight 3
÷ Four frames from a queue assigned Weight 4
· WRR with an Expedite Queue: When WRR is configured
on a CataIyst 2950, the option exists to configure queue 4
as a priority queue - an "Expedite Queue."
With WRR, lower-priority queues have the opportunity to transmit packets even though the
high-priority queues have not been emptied. With WRR with an expedite queue, one queue
(queue 4 on the Catalyst 2950 and 3550) can be conIigured as an expedite priority queue All
traIIic Irom the expedite queue must be serviced beIore the remaining three queues are
serviced. The expedite queue can be used to ensure that voice traIIic incurs minimal delay and
no drops.
Configuring PQ on CataIyst 2950 Switches
This topic explains how to conIigure PQ on the Cisco Catalyst 2950 switch.
To conIigure PQ on the Catalyst 2950 switch, speciIy the queue ID oI the CoS priority queue.
(Ranges are 1 to 4 where 1 is the lowest CoS priority queue.) Then, speciIy the CoS values that
are mapped to the queue ID.
wrr-queue cos-map quia cos1...cosn
Syntax Description
quid The queue ÌD of the CoS priority queue. Ranges are 1 to 4 where
1 is the lowest CoS priority queue.
cosI...cosn The CoS values that are mapped to the queue ÌD.
The deIault CoS to priority queue assignments are shown in the table.
Queue 1 2 3 4
CoS Values 0, 1 2, 2 4, 5 6, 7
Configuring PQ on
wrr~queue cos~map guid cosl...cosn wrr~queue cos~map guid cosl...cosn
Switch(config)#
· Assigns CoS vaIues to CoS priority queues
· quid: Specifies the queue ID of the CoS priority queue. (Ranges
are 1 to 4 where 1 is the Iowest CoS priority queue.)
· cos1...cosn: Specifies the CoS vaIues that are mapped to the
queue ID.
· DefauIt ID vaIues are:
Queue ID CoS VaIues
1 0, 1
2 2, 3
3 4, 5
4 6, 7
Configuring WRR on CataIyst 2950 Switches
This topic explains how to conIigure WRR on the Catalyst 2950 switch.
The wrr-queue bandwidth global conIiguration command is used to assign WRR weights to
the Iour CoS priority queues on the Catalyst 2950 switch. Using the no Iorm oI this command
will disable the WRR scheduler and enable the strict priority scheduler.
For weight 1, weight 2, and weight 3, the range is 1 to 255. The range Ior weight 4 is 0 to 255.
Queues 1, 2, and 3 can be conIigured Ior WRR scheduling and queue 4 can be conIigured Ior
strict priority scheduling. To conIigure queue 4 as the expedite queue, set weight4 to 0. When
queue 4 is empty, packets Irom queues 1, 2, and 3 are sent according to the assigned WRR
weights.
wrr-queue bandwidth weight1...weight4
Syntax Description
weightI...weight~ The ratio of weight 1, weight 2, weight 3, and weight 4 determines
the weights of the WRR scheduler.
Note: Ìn Cisco ÌOS software releases earlier than Release 12.1(12c)EA1, the ranges for all queues
is 1 to 255.
Configuring WRR on
wrr~queue bandwidth weightl...weight4 wrr~queue bandwidth weightl...weight4
Switch(config)#
· Assigns WRR weights to the four egress queues
· Ranges for the WRR vaIues:
÷ For weightl, weight2, and weight3, the range is 1 to 255.
÷ For weight4, the range is 0 to 255 (when weight4 is set to 0,
queue 4 is configured as the expedite queue).
mls qos
!
interface GigabitFthernet0/12
wrr~queue bandwidth 20 1 80 0
no wrr~queue cos~map
wrr~queue cos~map 1 0 1 2 4
wrr~queue cos~map 3 3 6 7
wrr~queue cos~map 4 5
In this example Ior the Catalyst 2950 switch, the Iollowing conIiguration has been made:
The interIace is set to GigabitEthernet 0/12
Queue bandwidth (queue weight) is set to these weights:
Queue 1: 20
Queue 2: 1
Queue 3: 80
Queue 4: 0 (because this is 0, this is the expedite queue)
The CoS map is set to its deIault settings.
CoS is mapped to queues according to the Iollowing:
Queue 1: CoS 0, 1, 2, 4
Queue 2: No CoS assigned
Queue 3: CoS 3, 6, 7
Queue 4: CoS 5 (voice traIIic goes to the expedite queue)
Note: This is the AutoQoS configuration for the Catalyst 2950.
Monitoring Queuing on CataIyst 2950 Switches
This topic lists the commands used Ior monitoring queuing on Catalyst 2950 switches.
The show mls qos maps command is used to display QoS mapping inIormation on the Catalyst
2950 switch. Maps are used to generate an internal DSCP value, which represents the priority
oI the traIIic.
The show mls qos maps command is available only iI the Catalyst 2950 switch is running the
enhanced image (EI) soItware.
II the show mls qos maps command is used without any keywords, it will display all maps.
show mls qos maps ¡cos-dscp [ dscp-cos]
Syntax Description
cos~dscp (Optional) Display CoS-to-DSCP map.
dscp~cos (Optional) Display DSCP-to-CoS map.
Monitoring Queuing on
show mls qos maps (cos~dscp | dscp~cos) show mls qos maps (cos~dscp | dscp~cos)
Switch>
· DispIay QoS mapping information.
· This command is avaiIabIe with enhanced software image (EI)
switches.
Switch> show mls qos maps
Dscp~cos map:
dscp: 0 8 10 16 18 24 26 32 34 40 42 48 56
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cos: 0 1 1 2 2 3 3 4 4 5 5 6 7
Cos~dscp map:
cos: 0 1 2 3 4 5 6 7
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dscp: 0 8 16 24 32 40 48 56
The show wrr-queue bandwidth command is used to display the WRR bandwidth allocation
Ior the Iour CoS priority queues.
The show wrr-queue cos-map command is used to display the mapping oI the CoS priority
queues.
show wrr~queue cos~map show wrr~queue cos~map
Switch>
· DispIay the mapping of the CoS priority queues
show wrr~queue bandwidth show wrr~queue bandwidth
Switch>
· DispIay the WRR bandwidth aIIocation for the CoS priority
queues
Switch> show wrr~queue bandwidth
WRR Queue : 1 2 3 4
Bandwidth : 10 20 30 40
Switch> show wrr~queue cos~map
CoS Value : 0 1 2 3 4 5 6 7
Priority Queue : 1 1 2 2 3 3 4 4
show mls qos interface (interface~id) (policers) show mls qos interface (interface~id) (policers)
Switch>
Switch> show mls qos interface fastethernet0/1
FastFthernet0/1
trust state:trust cos
trust mode:trust cos
CoS override:dis
default CoS:0
pass~through:none
trust device:cisco~phone
The show mls qos interface command is used to display QoS inIormation at the interIace
level. Although it will be visible in CLI help strings, the policers keyword is available only
when the Catalyst 2950 switch is running the enhanced soItware image.
show mls qos interface ¡interface-ia] ¡policers]
Syntax Description
interfaceid (Optional) Display QoS information for the specified interface.
policers (Optional) Display all the policers configured on the interface,
their settings, and the number of policers unassigned. Available
only when the switch is running the EÌ software.
Summary
References
To learn more about queuing on the Cisco Catalyst 3550 series switches, reIer to
hapter09186a008014I36e.html#1127419
hapter09186a008014I2c0.html#1025310
hapter09186a008007eddd.html
hapter09186a0080121d31.html#36454
Summary
· The number of queues and capabiIities of queues on
CataIyst switches depend upon the modeI of the switch,
supervisor, and Iine cards.
· PQ and WRR are the two queuing methods used for
CataIyst switches.
· The use of PQ can starve Iower-priority queues.
· With WRR, different weights are assigned to each queue.
· The use of WRR scheduIing prevents the Iow-priority
queues from being compIeteIy negIected during periods
of high-priority traffic.
· On most CataIyst switches, a singIe priority queue can be
configured with WRR to ensure priority dispatch of voice
traffic.
Next Steps
Lab Exercise 5-3: Queuing on Catalyst Switches
Quiz
Q1) Which three oI the Iollowing are queuing Ieatures that diIIer among Catalyst switch
models? (Choose three.)
A) number oI queues per port
B) the speed at which the queue transmits
C) the type oI queues (priority or standard)
D) capability to have drop thresholds Ior a queue
Q2) Which oI the Iollowing names would represent the queuing Ieatures oI a switch with 4
queues, one priority queue, and 2 standard queues, each with 2 drop thresholds?
A) 1P3Q2T
B) 1P4S2T
C) 1P4Q2T
D) 1P3S2T
Q3) When using WRR on a Cisco Catalyst 2950, what is the most certain way to ensure
minimal delay Ior voice traIIic?
A) conIigure an expedite queue
B) conIigure LLQ
C) use MDRR
D) conIigure the high queue with a very high weight Iactor
Q4) When WRR is conIigured on a switch with Iour Tx queues, given that weights have
been assigned to each oI the queues as Iollows and that all queues are Iull, how many
packets Irom queue 4 would be dispatched every time a packet Irom queue 2 is
dispatched?
Queue Weight
4 8
3 4
2 2
1 1
A) 2
B) 4
C) 16
D) 24
Q5) Which three oI the Iollowing queuing algorithms are available on the Cisco Catalyst
2950 switch? (Choose three.)
A) Priority Queuing
B) Weighted Round Robin
C) ModiIied DeIicit Round Robin
D) Weighted Round Robin with an expedite queue
Q6) Which two represent options Ior conIiguring drop thresholds? (Choose two.)
A) WRED
B) tail drop
C) expedite drop
D) priority drop
Q7) On the Cisco Catalyst 2950 switch, what is the eIIect oI conIiguring the wrr-queue
bandwidth weight parameter oI queue 4 as '0¨?
A) queue 4 is disabled
B) queue 4 has the lowest weight
C) queue 4 becomes the expedite queue
D) queues 1, 2, and 3 obtain extra bandwidth
Q8) On the Cisco Catalyst 2950 switch, which command would you use to assign CoS
values 0, 1, 2, and 3 to queue 1?
E) wrr-queue cos -map 1 0 1 2 3
F) wrr-queue cos -map 0 1 2 3 1
G) wrr-queue cos -map 0,1,2,3,1
H) wrr-queue cos -map 0 1/ 2/3/1
Q9) Which command is used to display the trust state oI a port on a Cisco Catalyst 2950
switch?
A) show mls qos maps
B) show mls qos interIace
C) show wrr-queue bandwidth
D) show mls interIace trust-state
Quiz Answer Key
Q1) A, C, D
ReIates to: Queuing on Catalyst Switches
Q2) A
Q3) A
ReIates to: Configuring WRR on Catalyst 2950 Switches
Q4) B
ReIates to: Weighted Round Robin
Q5) A, B, D
Q6) A, B
Q7) C
Q8) A
ReIates to: Configuring PQ on Catalyst 2950 Switches
Q9) B
ReIates to: Monitoring Queuing on Catalyst 2950 Switches
Module Assessment
Overview
Quiz: Congestion Management
Objectives
IdentiIy and explain the operation oI basic queuing algorithms including FIFO, priority,
and round-robin queuing
Describe the Iunctions oI hardware and soItware queuing
ConIigure weighted Iair queuing to manage congestion
ConIigure CBWFQ and LLQ to manage congestion
ConIigure WRR on a Catalyst switch to manage LAN congestion
Instructions
Step 1 Answer all questions in this quiz by selecting the best answer(s) to each question
Step 2 VeriIy your results against the answer key located at the end oI this section
incorrectly.
Q1) In FIFO queuing, what happens to packets when the queue is Iull?
A) they are delayed
B) they are dropped
C) they are retransmitted
D) they are moved to another queue
Q2) What happens when the highest-priority queue becomes congested in priority queuing
algorithm?
A) all the other queues starve
B) tail dropping Iocuses on the highest-priority queue
C) other queues are served on a round-robin basis
D) packets in the highest-priority queue are moved to a lower-priority queue
Q3) In WRR implementation using a byte threshold as a measurement oI each queue share
oI bandwidth, given an MTU oI 2000 and a byte-count oI 4000, what would the router
do with the next packet Ior queue 2 (800 bytes) iI the router had just dispatched two
packets Irom queue 2 (sizes 2000 and 1600) to the hardware queue?
A) tail drop the next packet
B) dispatch the Iirst packet Irom the next queue
C) dispatch the next packet to the hardware queue
D) split the packet and transmit the Iirst 400 bytes
Q4) On a network device connecting a LAN and a WAN, what type oI congestion would be
likely Ior traIIic moving Irom the LAN to the WAN?
A) bursty
B) transient
C) persistent
D) Iluctuating
Q5) Given that the hardware queue is NOT Iull, how will the next packet be serviced by the
soItware queue?
A) soItware queue will be bypassed
B) soItware queue will enqueue the packet
C) soItware queue will expedite the packet
D) soItware queue will only meter the packet
Q6) How does WFQ implement tail dropping?
A) drops the last packet to arrive
B) drops all non-voice packets Iirst
C) drops the lowest-priority packets Iirst
D) drops packets Irom the most aggressive Ilows
Q7) Consider that a WFQ system has a modest hold-queue limit oI ten (HQO÷10) and a
congestive discard threshold oI eight (CDT÷8), and that there are already eight (8)
packets in the system. II a newly arriving packet had the worst Iinish time oI all packets
in the system, what would happen to the packet?
A) it would be dropped
B) it would be enqueued
C) it would be buIIered until a spot in a queue came open
D) it would be dispatched
Q8) Which oI the Iollowing is the deIault dropping scheme Ior CBWFQ?
A) RED
B) WRED
C) tail-drop
D) class-based policing
Q9) What does LLQ bring to CBWFQ?
A) strict priority scheduling
B) alternate priority scheduling
C) non-policed queues Ior low latency traIIic
D) special voice traIIic classiIication and dispatch
Q10) What type oI traIIic should you limit the use oI the priority command to?
A) low-latency data traIIic
B) voice-like, CBR traIIic
C) high volume, VBR traIIic
D) video and teleconIerencing, available (ABR) traIIic
Q11) When WRR with an expedite queue has been conIigured on a Cisco Catalyst 2950
switch, which queue is emptied beIore any other queues are serviced?
A) queue 1
B) queue 2
C) queue 3
D) queue 4
Scoring
or better.
Q1) A
ReIates to: Ìntroduction to Queuing
Q2) A
Q3) C
Q4) C
ReIates to: Queuing Ìmplementations
Q5) A
ReIates to: Queuing Ìmplementations
Q6) D
ReIates to: FÌFO and WFQ
Q7) A
ReIates to: FÌFO and WFQ
Q8) C
ReIates to: CBWFQ and LLQ
Q9) A
Q10) B
Q11) D
ReIates to: LAN Congestion Management
ModuIe Summary
EIIective congestion management is key to QoS in converged networks. Low latency traIIic
such as voice and video must be constantly moved to high priority queues in order to ensure
reasonable quality.
Cisco routers oIIer a variety oI simple (FIFO, PQ, and CQ) and sophisticated (WFQ, CBWFQ,
and LLQ) queuing algorithms to provide eIIective congestion management on converged
networks. LLQ, the most sophisticated, was speciIically designed to provide the highest QoS to
voice traIIic.
Cisco switches oIIer a variety oI queuing capabilities depending upon the model oI switch
being used. On most Catalyst switches, three queuing methods are available Ior use: PQ, WRR,
and WRR with a priority queue.
ModuIe Summary
· Congestion can occur at any point in the network, but
particuIarIy at points of speed mismatches and traffic
aggregation.
· Queuing aIgorithms such as FIFO, Priority, and Round Robin
are used to manage congestion.
· Each physicaI interface has a hardware and a software queuing
system.
· Weighted Fair Queuing (WFQ) was deveIoped to over come the
Iimitations of the more basic queuing methods. CBWFQ
extends the standard WFQ functionaIity to provide support for
user-defined traffic cIasses.
· Low Latency Queuing (LLQ) extends the functionaIity of
CBWFQ by adding priority queues for time-sensitive traffic
such as voice and video.
· PQ, WRR, and WRR with a PQ are the three key queuing
methods used for CataIyst switches.
ModuIe 6
Overview
Congestion is a normal occurrence in networks today. Whether congestion occurs as a result oI
a lack oI buIIer space, network aggregation points, or a low-speed wide area link, many
congestion management techniques exist to ensure speciIic applications and traIIic classes are
given their share oI available bandwidth when congestion occurs. Congestion management
does, however, come at a price. When congestion occurs, some traIIic is delayed or even
dropped at the expense oI other traIIic. When drops occur, diIIerent problems may arise, which
can exacerbate the congestion such as retransmissions and TCP global synchronization in
TCP/IP networks.
Congestion avoidance mechanisms are designed to reduce the negative eIIects oI congestion by
penalizing the most aggressive traIIic streams as soItware queues begin to Iill. This module
discusses the problems with TCP congestion management and the beneIits oI deploying
congestion avoidance mechanisms in a network.
ModuIe Objectives
Upon completing this module, you will be able to use Cisco QoS congestion avoidance
mechanisms to reduce the eIIects oI congestion on the network.
ModuIe OutIine
ModuIe Objectives
· ExpIain the probIems that may resuIt from the
Iimitations of TCP congestion management
mechanisms on a converged network
· ExpIain how RED can be used to avoid
congestion
· Configure CB-WRED to avoid congestion
· Configure ECN to enhance the congestion
avoidance features of WRED
ModuIe OutIine
· Introduction to Congestion Avoidance
· Introduction to RED
· Configuring CIass-Based Weighted RED
· Case Study: WRED Traffic ProfiIes
· Configuring ExpIicit Congestion Notification
Ìntroduction to Congestion
Avoidance
Overview
This lesson explains the behavior oI the TCP when hosts send and receive packets. This lesson
also explains traIIic management mechanisms that are used by TCP during periods oI
congestion and the eIIects oI packet loss on TCP sessions.
ReIevance
Congestion avoidance mechanisms are important tools Ior reducing the eIIects oI congestion on
networks. To understand the problems these mechanisms solve, and the beneIits they bring, it is
Iirst helpIul to understand how TCP recognizes and responds to congestion.
Objectives
Upon completing this lesson, you will be able to explain the problems that may result Irom the
limitations oI TCP congestion management mechanisms on a converged network. This includes
being able to meet these objectives:
Explain the behavior oI TCP senders and receivers
Explain how TCP responds to congestion
Describe tail drop as a congestion control mechanism
Explain the drawbacks oI tail drop
OutIine
OutIine
· Overview
· Behavior of TCP Senders and Receivers
· Congestion and TCP
· Managing Interface Congestion with TaiI Drop
· TaiI-Drop Limitations
· Summary
· Quiz
Copyright © 2003, Cisco Systems, Ìnc. Congestion Avoidance 6-5
Behavior of TCP Senders and Receivers
This topic describes the behavior oI TCP senders and receivers when sending packets.
BeIore any data is transmitted using TCP, a connection must Iirst be established between the
transmitting and receiving hosts. When the connection is initially established, the two hosts
must agree on certain parameters that will be used during the communication session. One oI
the parameters that must be decided is called the window size, or how many data bytes to
transmit at a time. Initially, TCP sends a small number oI data bytes, and then exponentially
increases the number sent. For example, a TCP session originating Irom host A begins with a
window size oI 1 and thereIore sends one packet. When host A receives a positive ACK Irom
the receiver, it increases its window size to 2. Host A then sends 2 packets, receives a positive
ACK, and increases its window size to 4, and so on.
Note: TCP tracks window size by byte count. For purposes of illustration packets (N) is used.
In traditional TCP, the maximum window size is 64 Kb (65,535 bytes). Extensions to TCP
speciIied in RFC 1323, allow Ior tuning TCP by extending the maximum TCP window size to
2
30
bytes. TCP extensions Ior high perIormance, although supported on most operating systems,
may not be supported on your system.
Behavior of a TCP Sender
· Sender sends "N" bytes (as much as
credit aIIows)
· Start credit (window size) is smaII
÷ To avoid overIoading network queues
· Increases credit IinearIy
÷ To gauge network capabiIity
ExampIe: ExampIe of Windowing in TCP
AIter connecting to an Internet website, a Iile transIer using the FTP download is initiated.
Watching the progress oI the transIer, it is noticed that the bytes per second counter steadily
increases during the Iile transIer. This is an example oI TCP windowing in action.
When the receiver receives a data segment, it checks that data segment sequence number (byte
count). II the data received Iills in the next sequence oI numbers expected, it indicates that the
data segment was received in order. The receiver then:
Delivers all the data that it holds to the target application
Updates the sequence number to reIlect the next byte number in expected order
When this process is complete, it perIorms one oI the Iollowing actions:
Immediately transmits an acknowledgment (ACK) to the sender
Schedules an ACK to be transmitted to the sender aIter a short delay
The ACK notiIies the sender that the receiver received all data segments up to but not including
the byte number in the new sequence number. Receivers usually try to send an ACK in
response to alternating data segments they receive. They send the ACK because Ior many
applications, iI the receiver waits out a small delay, it can eIIiciently piggyback its reply
acknowledgment on a normal response to the sender. However, when the receiver receives a
data segment out oI order, it immediately responds with an ACK to direct the sender to
retransmit the lost data segment.
Note: TCP tracks window size by byte count. For purposes of illustration packets (N) is used.
Behavior of a TCP Receiver
· Receiver scheduIes an ACK on
receipt of "next message."
· TCP acknowIedges the next segment
it expects to receive, not the Iast
segment it received.
÷ In the exampIe N+1 is bIocked so the
receiver keeps acknowIedging N+1 (the
next segment it expects to receive).
Congestion and TCP
This topic describes the TCP response to lost data packets.
When the sender receives an ACK, it determines iI any data is outstanding:
II no data is outstanding, the sender determines that the ACK is a keepalive, meant to keep
the line active, and it does nothing.
II data is outstanding, the sender determines whether the ACK indicates that the receiver
has received some or none oI the data.
II the ACK acknowledges receipt oI some data sent, the sender determines iI new
credit has been granted to allow it to send more data.
When the ACK acknowledges receipt oI none oI the sent data and there is
outstanding data, the sender interprets the ACK to be a repeatedly sent ACK. This
condition indicates that some data was received out oI order, Iorcing the receiver to
remit the Iirst ACK, and that a second data segment was received out oI order,
Iorcing the receiver to remit the second ACK. In most cases, the receiver would
receive two segments out oI order because one oI the data segments had been
dropped.
When a TCP sender detects a dropped data segment, it retransmits the segment. Then it slows
its transmission rate so that the rate is halI oI what it was beIore the drop was detected. This is
known as the TCP slow-start mechanism.
In the Iigure, a station transmits three packets to the receiving station. UnIortunately, the Iirst
packet is dropped somewhere in the network. ThereIore the receiver sends an ACK 1, to
request the missing packet. Because the transmitter does not know iI the ACK was just a
duplicate ACK, it will wait Ior three ACK 1 packets Irom the receiver. Upon receipt oI the third
ACK, the missing packet, packet 1 is resent to the receiver. The receiver now sends an ACK 4
indicating it has already received packets 2 and 3 and is ready Ior the next packet.
TCP SIow Start
· If ACK acknowIedges something
÷ Update credit and send
· If not, presumes it indicates a Iost
packet
÷ Send first unacknowIedged message
right away
÷ HaIve current credit (sIow down)
÷ Increase sIowIy to gauge network
throughput
Although the TCP slow-start behavior is appropriately responsive to congestion, problems can
arise when multiple TCP sessions are concurrently carried on the same router and all TCP
senders slow down transmission oI packets at the same time.
II a TCP sender does not receive acknowledgement Ior sent segments, it cannot wait
indeIinitely beIore it assumes that the data segment it sent never arrived at the receiver. TCP
senders maintain the retransmission timer as a means oI signaling a segment retransmission.
The retransmission timer can impact TCP perIormance. II the retransmission timer is too short,
duplicate data will be sent into the network unnecessarily. II the retransmission timer is too
long, the sender will wait (remain idle) Ior too long, slowing down the Ilow oI data.
The selective acknowledgment (SACK) mechanism, as proposed in RFC 2018, can improve the
time it takes Ior the sender to recover Irom multiple packet losses as non-contiguous blocks oI
data can be acknowledged, and the sender only has to retransmit data that is actually lost.
SACK is used to convey extended acknowledgement inIormation Irom the receiver to the
sender to inIorm the sender oI non-contiguous blocks oI data that have been received. Using the
example in the slide, instead oI sending back an ACK N ¹ 1, the receiver can send a SACK N ¹
1 and also indicate back to the sender that N ¹ 3 has been correctly received with the SACK
option.
In standard TCP implementations, a TCP sender can only discover that a single packet has been
lost each round-trip time (RTT), causing poor TCP perIormance when multiple packets are lost.
Remember, the sender must receive three duplicate ACK packets beIore it realizes that a packet
has been lost. As a result oI receiving the third ACK, the sender will immediately send the
segment reIerred to by the ACK. This TCP behavior is called Iast retransmit.
MuItipIe Drops in TCP
· If muItipIe drops occur in the same
session:
÷ Current TCPs wait for time-out
÷ SeIective acknowIedge (SACK) may be a
work around
÷ New "fast retransmit phase" takes
severaI round-trip times (RTTs) to
recover
Managing Interface Congestion with TaiI Drop
This topic describes the deIault mechanism Ior managing interIace congestion, tail drop.
When an interIace on a router cannot transmit a packet immediately, the packet is queued,
either in an interIace transmit (Tx) ring, or the interIace output hold queue, depending on the
switching path that is used. Packets are then taken out oI the queue and eventually transmitted
on the interIace.
II the arrival rate oI packets to the output interIace exceeds the router capability to buIIer and
Iorward traIIic, the queues increase to their maximum length and the interIace becomes
congested. Tail drop is the deIault queuing response to congestion. Tail drop treats all traIIic
equally and does not diIIerentiate between classes oI service. Applications may suIIer
perIormance degradation due to packet loss caused by tail drop. When the output queue is Iull
and tail drop is in eIIect, all packets trying to enter (at the tail oI) the queue are dropped until
the congestion is eliminated and the queue is no longer Iull.
Weighted Iair queuing (WFQ), iI conIigured on an interIace, has a more elaborate scheme Ior
dropping traIIic, as it is able to punish the most aggressive Ilows via its congestive discard
threshold (CDT)-based dropping algorithm. UnIortunately, WFQ does not scale to backbone
speeds.
Managing Interface Congestion
with TaiI Drop
· Router interfaces experience congestion when the output
queue is fuII:
÷ AdditionaI incoming packets are taiI-dropped
÷ Dropped packets may cause significant appIication performance
degradation
÷ TaiI drop has significant drawbacks
TaiI-Drop Limitations
This topic describes the limitations oI using tail drop as a congestion management mechanism.
The simple tail-drop scheme unIortunately does not work very well in environments with a
large number oI TCP Ilows or in environments in which selective dropping is required.
Understanding the network interaction between TCP stack intelligence and dropping is required
to implement a more eIIicient and Iair dropping scheme, especially in service provider
environments.
Tail drop has the Iollowing shortcomings:
When congestion occurs, dropping aIIects most oI the TCP sessions, which simultaneously
back oII and then restart again. This causes ineIIicient link utilization at the congestion
point (TCP global synchronization).
TCP starvation, where all buIIers are temporarily seized by aggressive Ilows, and normal
TCP Ilows experience buIIer starvation.
There is no diIIerentiated drop mechanism, and thereIore premium traIIic is dropped in the
same way as best-eIIort traIIic.
TaiI-Drop Limitations
· TaiI drop shouId be avoided as it contains
significant fIaws:
÷ TCP synchronization
÷ TCP starvation
÷ No differentiated drop
A router can handle multiple concurrent TCP sessions. There is a high probability that when
traIIic exceeds the queue limit, it vastly exceeds the limit due to the bursty nature oI packet
networks. However, there is also a high probability that excessive traIIic depth caused by
packet bursts are temporary and that traIIic does not stay excessively deep except at points
where traIIic Ilows merge, or at edge routers.
II the receiving router drops all traIIic that exceeds the queue limit, as is done by deIault (with
tail drop), many TCP sessions then simultaneously go into slow start. Consequently, traIIic
temporarily slows down to the extreme and then all Ilows slow-start again. This activity creates
a condition called global synchronization.
Global synchronization occurs as waves oI congestion crest only to be Iollowed by troughs
during which the transmission link is not Iully utilized. Global synchronization oI TCP hosts
can occur because packets are dropped all at once. Global synchronization maniIests when
multiple TCP hosts reduce their transmission rates in response to packet dropping. When
congestion is reduced their transmission rates are increased. The most important point is that
the waves oI transmission known as global synchronization result in signiIicant link
underutilization.
TCP Synchronization
· MuItipIe TCP sessions start at different times.
· TCP window sizes are increased.
· TaiI drops cause many packets of many sessions to be
dropped at the same time.
· TCP sessions restart at the same time (synchronized).
During periods oI congestion, packets are queued up to the Iull queue length, which also causes
increased delay Ior packets that are already in the queue. In addition, queuing, being a
probabilistic mechanism, introduces unequal delays Ior packets oI the same Ilow, thus
producing jitter.
Another TCP-related phenomenon that reduces optimal throughput oI network applications is
TCP starvation. When multiple Ilows are established over a router, some oI these Ilows may be
much more aggressive as compared to others. For instance, when a Iile transIer application
TCP transmit window increases, it can send a number oI large packets to its destination. The
packets immediately Iill the queue on the router, and other, less aggressive Ilows can be starved
because there is no diIIerentiated treatment indicating which packets should be dropped. As a
result, these less aggressive Ilows are tail-dropped at the output interIace.
Based on the knowledge oI TCP behavior during periods oI congestion, it can be concluded
that tail drop is not the optimal mechanism Ior congestion avoidance and thereIore should not
be used. Instead, more intelligent congestion avoidance mechanisms should be used that slow
down traIIic beIore actual congestion occurs.
TCP DeIay and Starvation
· Constant high buffer usage (Iong queue) causes deIay
· More aggressive fIows can cause other fIows to starve
· No differentiated dropping
Summary
References
Further details on TCP slow start can be Iound in RFC 2001 at the Iollowing URL:
http://www.Iaqs.org/rIcs/rIc2001.html
For more inIormation, and a list oI operating systems supporting RFC 1323, reIer to:
http://www.psc.edu/networking/perI¸tune.html#table.
For a detailed discussion oI TCP protocol behavior see GeoII Huston, Telstra, 'TCP
PerIormance,¨ Internet Protocol Journal, Vol. 3, No. 2, June 2000, at the Iollowing URL:
http://www.cisco.com/warp/public/759/ipj¸3-2/ipj¸3-2¸tcp.html
For a detailed discussion oI TCP congestion behavior see GeoII Huston, Telstra, 'The
Future Ior TCP,¨ Internet Protocol Journal, Vol. 3, No. 3, September 2000, at the
Iollowing URL: http://www.cisco.com/warp/public/759/ipj¸3-3/ipj¸3-3¸IutureTCP.html
Summary
· TCP uses windowing and the TCP sIow-start mechanism
as its means of controIIing congestion.
· By defauIt, routers resort to taiI drop, hence reIying on
TCP congestion controIs, when queues become fuII.
· TaiI drop shouId be avoided as it causes significant
issues incIuding TCP synchronization, starvation, and
deIay.
· TCP synchronization decreases the average utiIization of
network Iinks.
· Starvation and deIay can have detrimentaI resuIts on
some fragiIe fIows and other traffic sensitive to these
characteristics.
Quiz
Q1) What are two main drawbacks oI using tail drop as a means oI congestion control?
(Choose two.)
A) global synchronization
B) small window sizes
C) head oI line blocking
D) starvation
Q2) How does a TCP receiver respond to the receipt oI an out-oI-order segment?
A) It will send an ICMP error to the sender and close the TCP session.
B) It will store all received segments in a buIIer and reorder the packets.
C) It immediately sends an ACK to the sender indicating the sequence number oI
the missing segment.
D) It will wait Ior the last segment to be transmitted to ensure the missing segment
was not delayed by an alternate network path or network congestion.
Q3) Which two reasons conIirm why tail drop is inadequate Ior avoiding congestion?
(Choose two.)
A) Tail drop drops packets at the receiver, not the sender, and thereIore does not
slow the cause oI congestion.
B) Tail drop treats all traIIic equally and does not diIIerentiate between classes oI
service.
C) Tail drop can result in many sessions simultaneously utilizing the TCP slow-
start mechanism at the same time.
D) Tail drop depends upon TCP to control window sizes as a means oI congestion
control.
Q4) What are two ways that a TCP sender interprets an unacknowledged packet? (Choose
two.)
A) it assumes the packet was dropped due to congestion and retransmits the packet
B) it will wait Ior the ACK timer to expire and then close the TCP session
C) it will send an ACK to probe the receiver
D) it will reduce the window size to ½ oI its value beIore the unacknowledged
packet was detected
Q5) What is the largest negative impact oI global synchronization in TCP networks?
A) TCP sessions are closed
B) signiIicant link under-utilization
C) poor TCP response to congestive discard techniques
D) Reduces the ability oI TCP to utilize bursting
Q6) What is the deIault router response to a Iull queue resulting Irom congestion?
A) as congestion increases (measured by the average size oI the queue),
selectively drop packets proportional to the increase in queue size
B) dynamically increase the queue buIIer size to accommodate newly arriving
packets
C) drop packets Irom the end oI the queue to make room to buIIer the incoming
packets
D) tail drops all incoming packets until the queue has scheduled packets and is no
longer Iull
Quiz Answer Key
Q1) A, D
ReIates to: Tail Drop Limitations
Q2) C
ReIates to: Behavior of TCP Senders and Receivers
Q3) C, D
ReIates to: Tail-Drop Limitations
Q4) A, D
ReIates to: Congestion and TCP
Q5) B
ReIates to: Tail-Drop Limitations
Q6) D
ReIates to: Managing Ìnterface Congestion with Tail Drop
Ìntroduction to RED
Overview
Congestion avoidance techniques monitor network traIIic loads in an eIIort to anticipate and
avoid congestion at common network bottleneck points. Congestion avoidance is achieved
through packet dropping using a more complex dropping technique than simple tail drop. This
lesson introduces the congestion avoidance technique random early detection (RED) and its
scalable dropping method, which is suitable Ior low- and high-speed networks.
ReIevance
Congestion avoidance techniques oIIer a viable alternative to the deIault router congestion
response, tail drop. RED is one oI the most commonly used congestion avoidance techniques
used in high-speed transit networks.
Objectives
Upon completing this lesson, you will be able to explain how RED can be used to avoid
congestion. This includes being able to meet these objectives:
Describe RED and how it can be used to prevent congestion
Describe the elements oI a RED traIIic proIile
Describe the diIIerent drop modes oI RED
Describe the eIIects oI RED on TCP traIIic
IdentiIy the points in a network where congestion avoidance can most eIIectively be
employed
OutIine
OutIine
· Overview
· Random EarIy Detection
· RED ProfiIes
· RED Modes
· TCP Traffic Before and After RED
· AppIying Congestion Avoidance
· Summary
· Quiz
Random EarIy Detection
This topic describes the purpose and Iunction oI RED.
RED is a dropping mechanism that randomly drops packets beIore a queue is Iull. The
dropping strategy is based primarily on the average queue lengththat is, when the average
size oI the queue increases, RED will be more likely to drop an incoming packet than when the
average queue length is shorter.
Because RED drops packets randomly, it has no per-Ilow intelligence. The rationale is that an
aggressive Ilow will represent most oI the arriving traIIic and thereIore it is more probable that
RED will drop a packet oI an aggressive session. RED thereIore punishes more aggressive
sessions with higher statistical probability and is, thereIore, able to somewhat selectively slow
down the most signiIicant cause oI congestion. Directing one TCP session at a time to slow
down allows Ior Iull utilization oI the bandwidth, rather than utilization that maniIests itselI as
crests and troughs oI traIIic.
As a result oI implementing RED, the problem oI TCP global synchronization is much less
likely to occur and TCP can utilize link bandwidth more eIIiciently. In RED implementations,
the average queue size also decreases signiIicantly, as the possibility oI the queue Iilling up is
reduced. This is because oI very aggressive dropping in the event oI traIIic bursts, when the
queue is already quite Iull.
RED distributes losses over time and normally maintains a low queue depth while absorbing
traIIic spikes. RED can also utilize IP precedence or diIIerentiated services code point (DSCP)
bits in packets to establish diIIerent drop proIiles Ior diIIerent classes oI traIIic.
Random EarIy Detection
· TaiI drop can be avoided if congestion is prevented.
· RED is a mechanism that randomIy drops packets before
a queue is fuII.
· RED increases drop rate as the average queue size
increases.
· RED resuIt:
÷ TCP sessions sIow down to the approximate rate of output-Iink
bandwidth
÷ Average queue size is smaII (much Iess than the maximum queue
size)
÷ TCP sessions are desynchronized by random drops
RED ProfiIes
This topic describes the elements oI a RED traIIic proIile that is used to implement the RED
packet dropping strategy.
A RED traIIic proIile is used to determine the packet dropping strategy and is based on the
average queue length. The probability oI a packet being dropped is based on three conIigurable
parameters contained within the RED proIile:
Minimum threshold: When the average queue length is above the minimum threshold,
RED starts dropping packets. The rate oI packet drop increases linearly as the average
queue size increases, until the average queue size reaches the maximum threshold.
Maximum threshold: When the average queue size is above the maximum threshold, all
packets are dropped.
Mark probability denominator: This is the Iraction oI packets that are dropped when the
average queue depth is at the maximum threshold. For example, iI the denominator is 512,
one out oI every 512 packets is dropped when the average queue is at the maximum
threshold. The linear increase oI packet drops Irom the minimum threshold (0 drops) to the
maximum threshold is based on this parameter and the queue size between the minimum
and maximum thresholds.
The minimum threshold value should be set high enough to maximize the link utilization. II the
minimum threshold is too low, packets may be dropped unnecessarily, and the transmission
link will not be Iully used.
The diIIerence between the maximum threshold and the minimum threshold should be large
enough to avoid global synchronization. II the diIIerence is too small, many packets may be
dropped at once, resulting in global synchronization.
RED ProfiIes
The mark probability has the eIIect oI controlling the number oI packets that are dropped when
the average queue length reaches the maximum threshold. II the value is set too low, the
behavior oI tail drop will rapidly be approached, resulting in too many dropped packets. II the
value is set too large, RED dropping can be rendered ineIIective.
ExampIe: RED Traffic ProfiIe
The Iollowing is an example oI a RED traIIic proIile.
SampIe RED Traffic ProfiIe
In the RED traIIic proIile shown in the example, the minimum threshold is 36. RED will not
drop any packets until the average queue size is 36 or greater.
II the average queue size is greater than or equal to 36, but less than 40, RED will randomly
discard packets Irom the more aggressive traIIic Ilows. The rate oI packet discard will linearly
increase as the length oI the average queue increases.
The maximum threshold Ior this RED proIile is 40. When the average queue length is 40 or
greater, all packets will be discarded until the average queue size is below 40. At the moment in
time that the average queue size reaches 40, the router will be dropping 1 out oI every 10
packets (mark probability denominator ÷ 10).
RED Modes
This topic describes the diIIerent packet drop modes oI RED.
Based on the average queue size, RED has three dropping modes:
When the average queue size is between 0 and the conIigured minimum threshold, no drops
occur and all packets are queued.
When the average queue size is between the conIigured minimum threshold, and the
conIigured maximum threshold, random drop occurs, which is linearly proportional to the
mark probability denominator and the average queue length.
When the average queue size is at or higher than the maximum threshold, RED perIorms
Iull (tail) drop in the queue. This event is unlikely, as RED should slow down TCP traIIic
ahead oI congestion. II a lot oI non-TCP traIIic is present, RED cannot eIIectively drop
traIIic to reduce congestion, and tail drops are likely to occur.
RED Modes
· RED has three modes:
÷ No drop: when the average queue size is between 0
and the minimum threshoId
÷ Random drop: when the average queue size is between
the minimum and the maximum threshoId
÷ FuII drop (taiI drop): when the average queue size is at
maximum threshoId or above
· Random drop shouId prevent congestion
(prevent taiI drops)
TCP Traffic Before and After RED
This topic describes the eIIects oI using RED on TCP traIIic by comparing TCP traIIic Ilows
both beIore and aIter the application oI RED.
The Iigure shows TCP throughput behavior compared to link bandwidth in a congested network
scenario where the tail-drop mechanism is in use on a router. The global synchronization
phenomenon causes all sessions to slow down when congestion occurs, as all sessions are
penalized when tail drop is used because it drops packets with no discrimination between
individual Ilows.
When all sessions slow down, congestion on the router interIace is removed and all TCP
sessions restart their transmission at roughly the same time. Again, the router interIace quickly
becomes congested, causing tail drop. As a result, all TCP sessions back oII again. This
behavior cycles constantly, resulting in a link that is always underutilized on the average.
TCP Traffic Before RED
· TCP synchronization prevents average Iink utiIization
cIose to the Iink bandwidth
· TaiI drops cause TCP sessions to go into sIow-start
The Iigure shows TCP throughput behavior compared to link bandwidth in a congested network
scenario where RED has been conIigured on a router. RED randomly drops packets,
inIluencing a small number oI sessions at a time, beIore the interIace reaches congestion.
Overall throughput oI sessions is increased, as well as average link utilization. Global
synchronization is very unlikely to occur, as there is selective, but random dropping oI adaptive
traIIic.
TCP Traffic After RED
· Average Iink utiIization is much cIoser to Iink bandwidth
· Random drops cause TCP sessions to reduce window
sizes
AppIying Congestion Avoidance
This topic describes where congestion avoidance mechanisms are commonly deployed in
enterprise and service provider networks.
RED is most useIul in enterprise and service provider networks on output interIaces where
congestion is expected to occur. This typically relegates the use oI RED to the core routers in a
network rather than the routers at the network edge. Edge routers or switches typically classiIy
and mark packets as they enter the network. Congestion avoidance mechanisms can use these
packet markings to indicate a set oI drop criteria Ior a traIIic stream.
Congestion avoidance mechanisms are also applicable to the campus or LAN environment. In
these networks, congestion avoidance is best used on interIaces that connect to WAN gateways,
as these interIaces are typically sites Ior congestion to occur.
AppIying Congestion Avoidance
Summary
References
For a detailed discussion oI TCP congestion behavior see GeoII Huston, Telstra, 'The
Future Ior TCP,¨ Internet Protocol Journal, Vol. 3, No. 3, September 2000, at the
Iollowing URL: http://www.cisco.com/warp/public/759/ipj¸3-3/ipj¸3-3¸IutureTCP.html
For more inIormation on Random Early Detection, reIer to, 'Congestion Avoidance
Overview¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios121/121cgcr/qos¸c/qcprt3/qc
dconav.htm
Summary
· RED is a mechanism that randomIy drops packets before
a queue is fuII, preventing congestion and avoiding taiI
drop.
· RED operates by increasing the rate at which packets are
dropped from queues as the average queue size
increases.
· RED has three modes of operation, no drop, random
drop, and fuII drop (taiI drop).
· With RED, TCP gIobaI synchronization is eIiminated and
the average Iink utiIization increases.
Quiz
Q1) What are three ways in which RED avoids congestion? (Choose three.)
A) RED uses random dropping oI packets to slow aggressive TCP Ilows.
B) RED provides a Ilow control mechanism directing senders to throttle the rate at
which traIIic is sent.
C) RED distributes losses over time and normally maintains a low queue depth.
D) RED increases the rate at which packets are dropped as congestion increases.
Q2) What are the three modes oI RED? (Choose three.)
A) no drop
B) random drop
C) immediate drop
D) Iull drop
Q3) What is the purpose oI the mark probability denominator?
A) It indicates at what average queue depth RED should begin tail drop.
B) It indicates at what average queue depth RED should begin random dropping.
C) It indicates the number oI packets to drop when the average queue length is
above the minimum threshold.
D) It is the Iraction oI packets dropped when the average queue depth is at the
maximum threshold.
Q4) In a RED proIile, what can result Irom setting the diIIerence between the minimum and
maximum threshold too small?
A) packets might never be dropped
B) global synchronization can occur
C) link utilization will be maximized
D) TCP congestive management will not operate properly
Q5) Where is RED typically applied in enterprise and service provider networks?
A) on the edge, to reduce the eIIects oI congestion towards hosts and servers
B) at the distribution, on output interIaces pointing to network edge devices
C) on core devices where congestion is most likely to occur
D) on network gateways and interIaces connecting these devices to the network
Q6) What are two ways in which the application oI RED helps to increase link utilization?
(Choose two.)
A) It prioritizes traIIic Irom Iragile Ilows ahead oI more aggressive Ilows.
B) RED eliminates global synchronization and its eIIects.
C) RED buIIers packets in memory when interIace queues are congested.
D) Random drops Iorces TCP session to reduce window sizes preventing
congestion.
Q7) Match the terms below with their location on the Iigure.
A) Minimum Threshold
B) Maximum Threshold
C) No Drop
D) Random Drop
E) Full Drop
F) Mark probability denominator
G) Maximum Drop Probability
H) Average Queue Length
I) Drop Probability
8. __________
1. __________
10%
100%
20 40
3. __________ 5. __________
6. __________
2. __________ 4. __________ 6. __________
9. __________
8. __________
1. __________
10%
100%
20 40
3. __________ 5. __________
7. __________
2. __________ 4. __________ 6. __________
9. __________
Quiz Answer Key
Q1) A, C, D
ReIates to: Random Early Detection
Q2) A, B, D
ReIates to: RED Modes
Q3) D
ReIates to: RED Profiles
Q4) B
Q5) C
ReIates to: Applying Congestion Avoidance
Q6) B, D
ReIates to: TCP Traffic Before and After RED
Q7) 1-I
2-C
3-A
4-D
5-B
6-E
7-G
8-H
9-F
Configuring Class-Based
Weighted RED
Overview
avoid congestion at common network bottleneck points using advanced packet discard
techniques. This lesson introduces the congestion avoidance technique weighted random early
detection (WRED), which is the Cisco implementation oI RED.
ReIevance
response, tail drop. WRED combines the capabilities oI the RED algorithm with IP precedence
Ior preIerential traIIic handling oI higher-priority packets. When congestion begins on an
interIace, WRED can selectively discard lower-priority traIIic, providing diIIerentiated
perIormance characteristics Ior diIIerent service classes.
Objectives
Upon completing this lesson, you will be able to conIigure CB-WRED to avoid congestion.
Describe WRED and how it can be used to prevent congestion
Describe the traIIic proIiles used in WRED implementations
IdentiIy the Cisco IOS commands required to conIigure CB-WRED
IdentiIy the Cisco IOS commands required to conIigure DSCP-based CB-WRED
IdentiIy the Cisco IOS commands used to monitor CB-WRED
Fundamentals oI congestion avoidance with RED
OutIine
OutIine
· Overview
· Weighted Random EarIy Detection
· WRED ProfiIes
· Configuring CB-WRED
· Configuring DSCP-Based CB-WRED
· Monitoring CB-WRED
· Summary
· Quiz
Weighted Random EarIy Detection
This topic describes WRED and how it can be used to prevent congestion.
WRED combines RED with IP precedence or DSCP and perIorms packet dropping based on IP
precedence or DSCP markings.
As with RED, WRED monitors the average queue length in the router and determines when to
begin discarding packets based on the length oI the interIace queue. When the average queue
length is greater than the user-speciIied 'minimum threshold,¨ WRED begins to randomly drop
packets (both TCP and User Datagram Protocol |UDP|) with a certain probability. II the
average length oI the queue continues to increase such that it becomes larger than the user-
speciIied 'maximum threshold,¨ WRED reverts to a 'tail drop¨ packet discard strategy, where
all incoming packets might be dropped.
The idea behind using WRED is to maintain the queue length at a level somewhere between the
minimum and maximum thresholds, and to implement diIIerent drop policies Ior diIIerent
classes oI traIIic. WRED can selectively discard lower-priority traIIic when the interIace
becomes congested and can provide diIIerentiated perIormance characteristics Ior diIIerent
classes oI service. WRED can also be conIigured so that non-weighted RED behavior is
achieved.
For interIaces conIigured to use the Resource Reservation Protocol (RSVP), WRED chooses
packets Irom other Ilows to drop rather than the RSVP Ilows. Also, IP precedence or DSCP
governs which packets are dropped because traIIic that is at a lower priority has a higher drop
rate than traIIic at a higher priority (and, thereIore, lower priority is more likely to be throttled
back). In addition, WRED statistically drops more packets Irom large users than small users.
ThereIore, traIIic sources that generate the most traIIic are more likely to be slowed down than
traIIic sources that generate little traIIic.
Weighted Random EarIy Detection
· WRED can use muItipIe different RED profiIes.
· Each profiIe is identified by:
÷ Minimum threshoId
÷ Maximum threshoId
÷ Maximum drop probabiIity
· WRED profiIe seIection is based on:
÷ IP precedence (8 profiIes)
÷ DSCP (64 profiIes)
· WRED drops Iess important packets more aggressiveIy
than more important packets.
· WRED can be appIied at the interface, VC, or cIass IeveI.
WRED reduces the chances oI tail drop by selectively dropping packets when the output
interIace begins to show signs oI congestion. By dropping some packets early rather than
waiting until the queue is Iull, WRED avoids dropping large numbers oI packets at once and
minimizes the chances oI global synchronization. As a result, WRED maximizes the utilization
oI transmission lines.
WRED is only useIul when the bulk oI the traIIic is TCP traIIic. With TCP, dropped packets
indicate congestion, so the packet source reduces its transmission rate. With other protocols,
packet sources might not respond or might re-send dropped packets at the same rate, and so
dropping packets might not decrease congestion.
WRED treats non-IP traIIic as precedence 0, the lowest precedence. ThereIore, non-IP traIIic,
in general, is more likely to be dropped than IP traIIic.
WRED should be used wherever there is a potential bottleneck (congested link), which could
very well be an access/edge link. However, WRED is normally used in the core routers oI a
network rather than at the network edge. Edge routers assign IP precedence or DSCP to packets
as they enter the network. WRED uses these assigned values to determine how to treat diIIerent
types oI traIIic.
Note that WRED is not recommended Ior any voice queue, although it may be enabled on an
interIace carrying voice traIIic. WRED will not throttle back voice traIIic because it is UDP-
based. (The network itselI should not be designed to lose voice packets because lost voice
packets result in reduced voice quality.) WRED controls congestion by impacting other
prioritized traIIic and avoiding congestion helps to ensure voice quality.
Congestion avoidance techniques monitor the network interIace load in an eIIort to anticipate
and avoid congestion at common network bottlenecks. Congestion avoidance is achieved
through intelligent packet dropping techniques. Traditionally, Cisco IOS soItware used
standalone RED and WRED mechanisms to avoid congestion on an interIace. Those
mechanisms can perIorm a diIIerentiated drop based on the IP precedence or DSCP value.
The class-based weighted Iair queuing (CBWFQ) system supports the use oI WRED inside the
queuing system, thereIore implementing class-based weighted random early detection (CB-
WRED). Each class is queued in its separate queue, and has a queue limit, perIorming tail drop
by deIault. WRED can be conIigured as the preIerred dropping method in a queue,
implementing a diIIerentiated drop based on traIIic class and Iurther on the IP precedence or
DSCP value.
Note: The combination of CB-WFQ with WRED on a single device is currently the only way to
implement the DiffServ Assured Forwarding per-hop behavior (AF PFB) using Cisco ÌOS
software.
The class-based conIiguration oI WRED is analogous to standalone WRED conIiguration.
Flow-based WRED is a variant oI WRED that enIorces more 'Iairness¨ in the way packets are
dropped Irom diIIerent traIIic Ilows. Flow-based WRED is not available within the CBWFQ
queuing system and the Cisco IOS modular QoS command-line interIace (MQC).
CIass-Based WRED
· CIass-based WRED is avaiIabIe when configured
in combination with CBWFQ.
· Using CBWFQ with WRED aIIows the
impIementation of DiffServ Assured Forwarding
PHB.
· CIass-based configuration of WRED is identicaI
to standaIone WRED.
The Iigure shows how WRED is implemented, and the parameters that are used by WRED to
inIluence packet drop decisions.
The router constantly updates the WRED algorithm with the calculated average queue length,
which is based on the recent history oI queue lengths.
ConIigured in the traIIic proIile are the parameters that deIine the drop characteristics used by
WRED (minimum threshold, maximum threshold, and mark probability denominator). It is
these parameters that deIine the WRED probability slopes.
When a packet arrives at the output queue, the IP precedence or DSCP value is used to select
the correct WRED proIile Ior the packet. The packet is then passed to WRED Ior processing.
Based on the selected traIIic proIile and the average queue length, WRED calculates the
probability Ior dropping the current packet and either drops it or passes it to the output queue.
II the queue is already Iull, the packet is tail-dropped. Otherwise, the packet will eventually be
transmitted out onto the interIace. II the average queue length is greater than the minimum
threshold but less than the maximum threshold, based on the drop probability, WRED will
either queue the packet or perIorm a random drop.
WRED BuiIding BIocks
WRED ProfiIes
This topic describes the diIIerent traIIic proIiles that are used in WRED implementations.
The Iigure shows two diIIerent WRED proIiles that are used Ior traIIic oI two diIIerent QoS
classes ('BE¨ class and 'Premium¨ class).
The BE traIIic class has a much lower minimum (10) and maximum threshold (30). As a result,
traIIic belonging to the BE class will be dropped much earlier and more aggressively than
traIIic Irom the Premium class. When heavy congestion occurs, traIIic belonging to the BE
class will ultimately be tail-dropped.
The Premium traIIic class has been conIigured with higher minimum (20) and maximum
thresholds (40). ThereIore packet drop as a result oI congestion will occur later (longer average
queue size) and is less likely, as compared to the BE class. The diIIerences in these traIIic
proIiles, as deIined in the Iigure, maintain diIIerentiated levels oI service in the event oI
congestion.
To avoid the need oI setting all WRED parameters in a router, 8 deIault values are already
deIined Ior precedence-based WRED, and 64 DiIIServ aligned values are deIined Ior DSCP-
based WRED. ThereIore, the deIault settings should suIIice in the vast majority oI
deployments.
By deIault, the maximum threshold Ior all DSCP values is 40. The deIault mark probability
denominator Ior all DSCP values is 10.
WRED ProfiIes
· WRED profiIes can be manuaIIy set.
· WRED has 8 defauIt vaIue sets for precedence-based
WRED.
· WRED has 64 defauIt vaIue sets for DSCP-based WRED.
A PHB is the externally observable Iorwarding behavior applied at a DiIIServ-compliant node
to a DiIIServ Behavior Aggregate (BA). With the ability oI the system to mark packets
according to DSCP setting, collections oI packets (each with the same DSCP setting and sent in
a particular direction) can be grouped into a DiIIServ BA. Packets Irom multiple sources or
applications can belong to the same DiIIServ BA.
The class selector BA is used Ior backward compatibility with non-DiIIServ-compliant devices
(RFC 1812 compliant devices and, optionally, RFC 791 compliant devices). ThereIore, the
class selector range oI DSCP values is used Ior backward compatibility with IP precedence.
The same WRED proIiles are applied to equal IP precedence and class selector values:
IP Precedence and CIass SeIector ProfiIes
IP Precedence DSCP (CIass
SeIector)
DefauIt Minimum
ThreshoId
0 (000) Default (0) 20
1 (001) cs1 (8) (001000) 22
2 (010) cs2 (16) (010000) 24
3 (011) cs3 (24) (011000) 26
4 (100) cs4 (32) (100000) 28
5 (101) cs5 (40) (101000) 30
6 (110) cs6 (48) (110000) 32
7 (111) cs7 (56) (111000) 34
RSVP RSVP 37
IP Precedence and
CIass SeIector ProfiIes
In DSCP, the Expedited Forwarding (EF) PHB is identiIied based on the Iollowing parameters:
Ensures a minimum departure rate to provide the lowest possible delay to delay-sensitive
applications
Guarantees bandwidth to prevent starvation oI the application iI there are multiple
applications using EF PHB
Polices bandwidth to prevent starvation oI other applications or classes that are not using
this PHB
Packets requiring EF should be marked with DSCP binary value '101110¨ (46 or 0x2E)
For the EF DiIIServ traIIic class, WRED conIigures itselI by deIault so that the minimum
threshold is very high, thus increasing the probability oI no drops being applied to that traIIic
class. It is expected then, that EF traIIic should be dropped very late, as compared to other
traIIic classes, and is thereIore prioritized in the event oI congestion.
Expedited Forwarding ProfiIe
DSCP (Six Bits) DefauIt Minimum ThreshoId
EF (101110) 36
DSCP-Based WRED
(Expedited Forwarding)
In DSCP, the Assured Forwarding (AF) PHB is identiIied based on the Iollowing parameters:
Guarantees a certain amount oI bandwidth to an AF class
Allows access to extra bandwidth, iI available
Packets requiring AF PHB should be marked with DSCP value 'aaadd0¨ where 'aaa¨ is the
number oI the class and 'dd¨ is the drop probability or drop preIerence oI the traIIic class.
There are Iour standard-deIined AF classes. Each class should be treated independently and
have bandwidth allocated that is based on the QoS policy. For the AF DiIIServ traIIic class,
WRED conIigures itselI by deIault Ior three diIIerent proIiles, depending on the drop
preIerence DSCP marking bits. ThereIore, AF traIIic should be classiIied into the three possible
classes based on the sensitivity oI the application or applications represented by the class to
packet drops.
DSCP-Based WRED
(Assured Forwarding)
Assured Forwarding ProfiIes
Assured Forwarding
CIass
Drop ProbabiIity (AF CIass) DSCP DefauIt Minimum
ThreshoId
Low Drop Prob (AF11) 001010 32
Medium Drop Prob (AF12) 001100 28
AF cIass 1
High Drop Prob (AF13) 001110 24
AF cIass 2
Assured Forwarding
CIass
Drop ProbabiIity (AF CIass) DSCP DefauIt Minimum
ThreshoId
AF cIass 3
AF cIass 4
Configuring CB-WRED
This topic describes the Cisco IOS commands that are required to conIigure CB-WRED.
To conIigure CB-WRED (WRED at the class level with CB-WFQ), the dscp-based and prec-
based arguments are conIigured within MQC. SpeciIic CB-WRED conIiguration arguments are
applied within a policy map. The policy map conIiguration can then be applied wherever policy
maps are attached (Ior example, at the interIace level, the per-virtual circuit |VC| level, or the
shaper level).
Configuring CB-WRED
class~map (match~any | match~all) class~name class~map (match~any | match~all) class~name
router(config)#
policy~map policy~name policy~map policy~name
router(config)#
router(config~if)#
1. Create CIass Map-Used for matching packets to a specified
cIass
2. Create PoIicy Map (Service PoIicy)-Specify a traffic poIicy that
can be attached to one or more interfaces
3. Attach Service PoIicy-Associate the poIicy map to an output
interface or VC
The random-detect command is used to enable WRED on an interIace. By deIault, WRED is
precedence-based and uses eight deIault WRED proIiles, one Ior each value oI IP precedence.
Within the CBWFQ system, WRED is used to perIorm per-queue dropping within the class
queues. ThereIore, each class queue has its own WRED method, which can be Iurther weighed
based on the IP precedence or DSCP value. Each queue can thereIore be conIigured with a
separate dropping policy to implement diIIerent drop policies Ior every class oI traIIic.
WRED will treat all non-IP traIIic as precedence 0. As a result, non-IP traIIic is more likely to
be dropped than IP traIIic.
II the random-detect command is used on virtual IP (VIP)-based interIaces, distributed WRED
(DWRED) is enabled and the VIP CPU is responsible Ior WRED dropping. This can
signiIicantly increase router perIormance when used in the context oI distributed Cisco Express
Forwarding (CEF) switching, which is a prerequisite Ior DWRED Iunctionality. Also, DWRED
can be combined with distributed weighted Iair queuing (DWFQ), enabling truly distributed
queuing and congestion avoidance techniques, running independently Irom the central CPU.
WRED cannot be conIigured on the same interIace as custom queuing (CQ), priority queuing
(PQ), or WFQ. However, both DWRED and DWFQ can be conIigured on the same interIace.
In addition, CB-WRED can be conIigured in conjunction with CBWFQ. Restricting non-
distributed, non-class-based WRED to only FIFO queuing on an interIace is typically not a
major issue because WRED is usually applied in the network core, where advanced queuing
mechanisms are not typically used. WRED is suited Ior the network core as it has a relatively
low perIormance impact on routers. Further, DWRED or CB-WRED can be used to overcome
this limitation by combining WRED with WFQ.
Configuring CB-WRED (Cont.)
random~detect random~detect
· EnabIes IP precedence based WRED in the seIected cIass
within the service poIicy configuration mode.
· DefauIt service profiIe is used.
· Command can be used at the interface, per-VC (with
random-detect-group) or the cIass IeveI (service-poIicy).
· Precedence-based WRED is the defauIt mode.
· WRED treats non-IP traffic as precedence 0.
When WRED is enabled, deIault values are selected Ior each traIIic proIile based on the weight
used (IP precedence or DSCP). Network administrators can then modiIy these deIault values to
match their speciIic administrative QoS policy goals. When modiIying the deIault WRED
proIile Ior IP precedence, the Iollowing values are conIigurable:
Minimum threshold: When the average queue depth is above the minimum threshold,
WRED starts dropping packets. The rate oI packet drop increases linearly as the average
Note: The default maximum threshold is equal to the default hold queue size (40) on an interface.
The size of the hold queue is equivalent to the number of packets that can be held within a
queue. The hold queue length ranges from 0 to 4096, and therefore, the minimum/maximum
threshold range is 1 to 4096. The default maximum threshold will reflect the defined hold
queue size. Thus, if the hold queue is changed, the maximum threshold will change.
Note: Ìf the difference between the maximum threshold and the minimum threshold is too small,
many packets might be dropped at once, resulting in global synchronization.
Mark probability denominator: This is the Iraction oI packets dropped when the average
queue depth is at the maximum threshold. For example, iI the denominator is 10, one out oI
every 10 packets is dropped when the average queue is at the maximum threshold.
Note: The maximum probability of drop at the maximum threshold can be expressed as 1/mark-
prob-denominator. The maximum drop probability is 10 percent if default settings are used
that have a mark probability denominator value of 10. The value of the mark probability can
range from 1 to 65536.
Changing the WRED Traffic ProfiIe
random~detect precedence precedence min~threshold
max~threshold mark~prob~denominator
random~detect precedence precedence min~threshold
max~threshold mark~prob~denominator
· Changes WRED profiIe for specified IP precedence
vaIue.
· Packet drop probabiIity at maximum threshoId is:
1 / mark-prob-denominator
· Non-weighted RED is achieved by using the same
WRED profiIe for aII precedence vaIues.
II required, RED can be conIigured as a special case oI WRED, by assigning the same proIile
to all eight IP precedence values.
Note: The default WRED parameter values are based on the best available data. Cisco
recommends that these parameters should not be changed from their default values unless
you have determined that your applications will benefit from the changed values.
WRED does not calculate the drop probability using the current queue length, but rather uses
the average queue length. The average queue length is constantly recalculated using two terms:
the previously calculated average queue size and the current queue size. An exponential
weighting constant N inIluences the calculation by weighing the two terms, thereIore
inIluencing how the average queue size Iollows the current queue size, in the Iollowing way:
For high values oI N, the previous average becomes more important. A large Iactor will
smooth out the peaks and lows in queue length. The average queue size is unlikely to
change very quickly, avoiding drastic swings in size. The WRED process will be slow to
start dropping packets, but it may continue dropping packets Ior a time aIter the actual
queue size has Iallen below the minimum threshold. The slow-moving average will
accommodate temporary bursts in traIIic.
Note: Ìf the value of N gets too high, WRED will not react to congestion. Packets will be
transmitted or dropped as if WRED were not in effect.
For low values oI N, the average queue size closely tracks the current queue size. The
resulting average may Iluctuate with changes in the traIIic levels. In this case, the WRED
process responds quickly to long queues. When the queue Ialls below the minimum
threshold, the process will stop dropping packets.
Note: Ìf the value of N gets too low, WRED will overreact to temporary traffic bursts and drop traffic
unnecessarily.
The deIault value oI N is 9. This value should suIIice Ior most scenarios except perhaps those
involving extremely high-speed interIaces (like OC12), where it can be increased slightly (to
about 12) to allow more bursts.
· WRED takes the average queue size to determine the
current WRED mode (no drop, random drop, fuII drop)
· High vaIues of N aIIow short bursts
· Low vaIues of N make WRED more burst-sensitive
· DefauIt vaIue (9) shouId be used in most scenarios
· Average output queue size with N=9 is
Q
ave
(t+1) = Q
ave
(t) * 0.998 + Q
t
* 0.002
Changing WRED Sensitivity to Bursts
random~detect exponential~weighting~constant n random~detect exponential~weighting~constant n
ExampIe: CBWFQ Using IP Precedence with CB-WRED
The Iollowing example oI CBWFQ with WRED Iocuses on a network, which provides three
diIIerent service levels Ior three traIIic classes:
Mission-critical class: Marked with IP precedence values oI 3 and 4 (3 is used Ior high
drop, and 4 is used Ior low drop within the service class) should get 30 percent oI an
interIace bandwidth
Bulk class: Marked with IP precedence values oI 1 and 2 (1 being high-drop, and 2 being
low-drop service) should get 20 percent oI the interIace bandwidth
Best-effort class: Should get the remaining bandwidth share, and should be Iair-queued
To enIorce this service policy, a router will use CBWFQ to perIorm bandwidth sharing and
WRED within service classes to perIorm diIIerentiated drop.
CB-WRED Using IP Precedence with
CBWFQ ExampIe
· EnabIe CBWFQ to prioritize traffic according to the
foIIowing requirements:
÷ CIass Mission-criticaI is marked with IP precedence
vaIues 3 and 4 (3 is high drop, 4 is Iow drop) and
shouId get 30% of interface bandwidth
÷ CIass BuIk is marked with IP precedence vaIues 1 and
2 (1 is high drop, 2 is Iow drop) and shouId get 20% of
interface bandwidth
÷ AII other traffic shouId be per-fIow fair-queued
· Use differentiated WRED to prevent congestion in aII
three cIasses
The Iigure shows the WRED traIIic proIile representing the QoS service policy and the
conIiguration that is used to implement the example service policy. The traIIic is classiIied
based on the precedence bits, and all non-contract traIIic is classiIied into the deIault class.
The Mission-critical class is guaranteed at least 30 percent oI bandwidth with a custom
WRED proIile that establishes a low-drop and a high-drop per-hop behavior.
The bulk class is guaranteed at least 20 percent oI bandwidth, is conIigured with somewhat
lower WRED drop thresholds, and is thereIore more likely to be dropped than the Mission-
critical class in the event oI interIace congestion.
All other traIIic is part oI the deIault class and is Iair-queued with deIault WRED
parameters.
CB-WRED Using IP Precedence with
CBWFQ ExampIe (Cont.)
Configuring DSCP-Based CB-WRED
This topic describes the Cisco IOS commands that are required to conIigure DSCP-based CB-
WRED.
The random-detect dscp-based command is used to enable DSCP-based WRED on an
interIace. By deIault, WRED is precedence-based, and uses eight deIault WRED proIiles, one
Ior each value oI IP precedence. Changing WRED weighting to values based on DSCP
increases the number oI WRED traIIic proIiles to 64.
You can conIigure WRED as part oI the policy Ior a standard class or the deIault class. The
WRED random-detect command and the WFQ queue-limit command are mutually exclusive
Ior class policy. II you conIigure WRED, its packet drop capability is used to manage the queue
when packets exceeding the conIigured maximum count are enqueued. II you conIigure the
WFQ queue-limit command Ior class policy, tail drop is used.
WRED cannot be conIigured on the same interIace as CQ, PQ, or WFQ. However, both
DWRED and DWFQ can be conIigured on the same interIace. In addition, CB-WRED can be
conIigured in conjunction with CBWFQ. Restricting non-distributed, non-class-based WRED
only to FIFO queuing on an interIace is not a major issue because WRED is usually applied in
the network core, where advanced queuing mechanisms are not typically deployed. WRED is
suited Ior the network core as it has a relatively low perIormance impact on routers. Further,
DWRED or CB-WRED can be used to overcome this limitation by combining WRED with
WFQ.
Configuring DSCP-Based CB-WRED
random~detect dscp~based random~detect dscp~based
· EnabIes DSCP-based WRED.
· Command can be used at the interface, per-VC (with
random-detect-group) or the cIass IeveI (service-poIicy).
· DefauIt service profiIe is used.
· The WRED random-detect command and the WFQ queue-
Iimit command are mutuaIIy excIusive for cIass poIicy.
When DSCP-based WRED is enabled, deIault values are selected Ior each traIIic proIile based
on DSCP. Network administrators can then modiIy these deIault values to match their speciIic
administrative QoS policy goals. When modiIying the deIault WRED proIile Ior DSCP, the
Iollowing values are conIigurable:
Minimum threshold: When the average queue depth is above the minimum threshold,
WRED starts dropping packets. The rate oI packet drop increases linearly as the average
Note: The default maximum threshold is equal to the default hold queue size (40) on an interface.
The size of the hold queue is equivalent to the number of packets that can be held within a
queue. The hold queue length ranges from 0 to 4096, and therefore, the minimum/maximum
threshold range is 1 to 4096. The default maximum threshold will reflect the defined hold
queue size. Thus, if the hold queue is changed, the maximum threshold will change.
Note: Ìf the difference between the maximum threshold and the minimum threshold is too small,
many packets might be dropped at once, resulting in global synchronization.
Mark probability denominator: This is the Iraction oI packets dropped when the average
queue depth is at the maximum threshold. For example, iI the denominator is 10, one out oI
every 10 packets is dropped when the average queue is at the maximum threshold.
Note: The maximum probability of drop at the maximum threshold can be expressed as 1/mark-
prob-denominator. The maximum drop probability is 10 percent if default settings are used
that have a mark probability denominator value of 10. The value of the mark probability can
range from 1 to 65536.
Changing the WRED Traffic ProfiIe
random~detect dscp dscpvalue min~threshold max~
threshold mark~prob~denominator
random~detect dscp dscpvalue min~threshold max~
threshold mark~prob~denominator
· Changes WRED profiIe for specified DSCP vaIue
· Packet drop probabiIity at maximum threshoId is:
1 / mark-prob-denominator
Note: The default WRED parameter values are based on the best available data. Cisco
recommends that these parameters should not be changed from their default values.
ExampIe: CB-WRED Using DSCP with CBWFQ
In the previous example oI CBWFQ with WRED, the service policy was implemented using
classes oI service based on IP precedence. In this example, the same service policy will be
conIigured. In this case, however, DSCP-based classes oI service are used. Remember that the
DiIIServ model itselI provides deIined traIIic classes and their associated PHB. DiIIServ-based
classiIication is used in this example:
Mission-critical class: Marked using DSCP AF class 2 should get 30 percent oI an
interIace bandwidth
Bulk class: Marked using DSCP AF class 1 should get 20 percent oI the interIace
bandwidth
Best-effort class: TraIIic should get the remaining bandwidth share, and should be Iair-
queued
To enIorce this service policy, a router will use CBWFQ to perIorm bandwidth sharing, and
WRED within service classes to perIorm diIIerentiated drop.
CB-WRED Using DSCP with CBWFQ
ExampIe
· EnabIe CBWFQ to prioritize traffic according to the
foIIowing requirements:
÷ CIass Mission-criticaI is marked using DSCP AF2 and
shouId get 30% of interface bandwidth
÷ CIass BuIk is marked using DSCP AF1 and shouId get
20% of interface bandwidth
÷ AII other traffic shouId be per-fIow fair-queued
· Use differentiated WRED to prevent congestion in aII
three cIasses.
· Make sure the new configurations stiII conform to the
design and impIementation from the previous exampIe.
The conIiguration example shows how traIIic classiIication is perIormed using DSCP-based
classes, representing the Mission-critical class as the AF1 class, and using the AF2 class as the
Bulk class. WRED DSCP-based parameters are sent reIlecting the class-dependent drop
strategy.
The Mission-critical class is guaranteed at least 30 percent oI bandwidth, with a custom
WRED proIile, which establishes three diIIerent drop probabilities Ior AF class 2.
The Bulk class is guaranteed at least 20 percent oI bandwidth, is conIigured with three
diIIerent drop probabilities Ior AF class 1, and has a somewhat lower WRED maximum
threshold. As a result, Bulk class traIIic is more likely to be dropped than the Mission-
critical class in the event oI interIace congestion.
All other traIIic is part oI the deIault class, is Iair-queued, with deIault WRED parameters.
CB-WRED Using DSCP with CBWFQ
ExampIe (Cont.)
Monitoring CB-WRED
This topic describes the Cisco IOS commands that are required to monitor CB-WRED.
The show policy-map interface command displays the conIiguration oI all classes conIigured
Ior all service policies on the speciIied interIace. This includes all WRED parameters
implementing the dropping policy on the speciIied interIace.
The Iollowing table explains some oI the key Iields oI the show policy-map interface
command.
show poIicy-map interface Parameters
Service-policy output Name of the output service policy applied to the specified
interface or VC.
Class-map Class of traffic being displayed. Output is displayed for each
configured class in the policy. The choice for implementing class
matches (for example, match-all or match-any) can also appear
next to the traffic class.
Match Match criteria specified for the class of traffic. Choices include
criteria such as ÌP precedence, ÌP DSCP value, Multiprotocol
Label Switching (MPLS) experimental value, access groups, and
QoS groups.
exponential weight Exponent used in the average queue size calculation for a WRED
parameter group.
mean queue depth Average queue depth based on the actual queue depth on the
interface and the exponential weighting constant. Ìt is a
fluctuating average. The minimum and maximum thresholds are
compared against this value to determine drop decisions.
Monitoring CB-WRED
router#
· DispIay the configuration of aII cIasses configured for aII
service poIicies on the specified interface
router#show policy~map interface Fthernet 0/0
Fthernet0/0
Service~policy output: Policy1
Class~map: Mission~critical (match~all)
0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 2 Match: ip dscp 18 20 22
Bandwidth 30 (%) Bandwidth 3000 (kbps)
exponential weight: 9
mean queue depth: 0
Dscp Transmitted Random drop Tail drop Minimum Maximum Mark
(Prec) pkts/bytes pkts/bytes pkts/bytes threshold threshold probability
0(0) 0/0 0/0 0/0 20 40 1/10
1 0/0 0/0 0/0 22 40 1/10
2 0/0 0/0 0/0 24 40 1/10
...
Summary
References
For more inIormation on WRED and conIiguring WRED, reIer to, 'ConIiguring Weighted
Random Early Detection¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios120/12cgcr/qos¸c/qcpart3/qc
wred.htm
For more inIormation on DSCP-Based WRED, reIer to, 'DiIIServ Compliant Weighted
Random Early Detection¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios121/121newIt/121t/121t5/dtd
swred.htm
For inIormation regarding WRED on Cisco GSR 12000 routers, reIer to, 'Weighted
Random Early Detection on the Cisco 12000 Series Router¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios112/ios112p/gsr/wred¸gs.ht
m
Summary
· WRED uses a different RED profiIe for each weight.
· WRED uses weighting based on IP precedence or DSCP.
· Each WRED profiIe defines the minimum and maximum
threshoId and the maximum drop probabiIity.
· The mark probabiIity denominator is the fraction of
packets dropped when the average queue size is at the
maximum threshoId and is defined by: 1 / mark-
probabiIity-denominator.
· WRED can be appIied at the interface, VC, or cIass IeveI.
· CB-WRED configuration is identicaI to standard WRED.
· Using CBWFQ with WRED aIIows the impIementation of
DiffServ AF PHB.
Quiz
Q1) Which two proIiles are supported by WRED? (Choose two.)
A) one traIIic proIile Ior all traIIic
B) eight proIiles Ior IP precedence-based WRED
C) 64 proIiles Ior DSCP-based WRED
D) up to 256 user-deIined proIiles
Q2) What two Iactors is the 'weight¨ based on in WRED? (Choose two.)
A) a user-deIinable metric ranging Irom 0 to 32768
B) IP precedence
C) DiIIServ Code Point
D) QoS-Group
Q3) A maximum drop probability oI 20 percent is required Ior a WRED proIile. Which
value should be conIigured as the mark probability denominator?
A) 2
B) 10
C) 20
D) depends upon the length oI the queue limit
Q4) What are two ramiIications oI modiIying the exponential weighting constant in
WRED? (Choose two)
A) Setting the constant too low can cause WRED to drop traIIic unnecessarily.
B) Setting the constant too low can cause WRED to not drop traIIic until the max
threshold has been reached.
C) Setting the constant too high can make WRED unresponsive to congestion.
D) Setting the constant too high can cause WRED to begin dropping high levels oI
traIIic beIore it should.
Q5) Which oI the Iollowing commands provides service level Ior IP precedence 3 with min-
threshold oI 20, max-threshold oI 40 and mark-prob-denominator value Ior 5 percent
drop probability?
A) random-detect precedence 3 40 20 5
B) random-detect precedence 3 20 40 5
C) random-detect precedence 3 20 40 20
D) random-detect precedence 5 2 4 5
Q6) What three actions does the, (config-pmap-c)# random-detect dscp 8 24 40 command
complete? (Choose three.)
A) enables DSCP-based WRED
B) conIigures the minimum threshold to 8
C) conIigures the minimum threshold to 24
D) conIigures the maximum threshold to 24
E) conIigures the maximum threshold to 40
F) conIigures the mark probability denominator to 40
G) conIigures the mark probability to 10
Q7) Match the DSCP-based WRED proIile with the DSCP PHB it implements as shown in
the Iigures below.
A) AF
B) EF
C) CS
¸¸¸¸¸ 1.
¸¸¸¸¸ 2.
¸¸¸¸¸ 3.
Average
Queue
Size
Drop
ProbabiIity
10%
100%
20 40
RSVP 0 1 2 3 4 5 6 7
22 24 26 28 30 32 34 36
Average
Queue
Size
Drop
ProbabiIity
10%
100%
20 40
RSVP 0 1 2 3 4 5 6 7
22 24 26 28 30 32 34 36
Average
Queue
Size
Drop
ProbabiIity
10%
100%
20 40 36
Average
Queue
Size
Drop
ProbabiIity
10%
100%
20 40 36
Average
Queue
Size
Drop
ProbabiIity
10%
100%
20 40 32 24 28
Average
Queue
Size
Drop
ProbabiIity
10%
100%
20 40 32 24 28
Q8) Given the Iollowing Cisco router console output, Iill in the blanks Ior each question.
router= show policy-map interface serial 4/0
Serial4/0
Service-policy output. AVVID (?0??)
Class-map. silver (match-all) (?0?·/?)
?SII8? packets, ·IS?·80?8 bytes
I minute offered rate 8I?000 bps, drop rate 0 bps
Match. ip dscp I8 ?0 ?? (?0?S)
Output Queue. Conversation ?8S
Bandwidth ?S (%)
(pkts matched/bytes matched) ·/448?
(depth/total drops/no-buffer drops) 0/0/0
mean queue depth. 0
Dscp Random drop Tail drop Minimum Maximum
Mark
(Prec) pkts/bytes pkts/bytes threshold threshold
probability
I8 0/0 0/0 ?0 40
I/?0
?0 0/0 0/0 ?0 40
I/IS
?? 0/0 0/0 ?0 40
I/I0
A) What QoS mechanism has been conIigured? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
B) What traIIic types belong to the traIIic class shown? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸
C) What DSCP PHB is being used in this service class? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸
D) II the interIace becomes congested, at what average queue length will the
interIace resort to tail drop? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
E) At the time the average queue length reaches the maximum threshold, what
percentage oI traIIic will be dropped by WRED Ior all traIIic types in this
traIIic class? ¸¸¸¸¸¸¸¸¸¸¸¸¸, ¸¸¸¸¸¸¸¸¸¸¸¸¸, ¸¸¸¸¸¸¸¸¸¸¸¸¸
Quiz Answer Key
Q1) B, C
ReIates to: Weighted Random Early Detection
Q2) B, C
ReIates to: Weighted Random Early Detection
Q3) C
ReIates to: WRED Profiles
Q4) A, C
ReIates to: Configuring CB-WRED
Q5) B
ReIates to: Configuring CB-WRED
Q6) C, E, G
ReIates to: Configuring DSCP-Based CB-WRED
Q7) 1-C
2-B
3-A
ReIates to: WRED Profiles
Q8) A) CB-WRED with CB-WFQ
B) DSCP 18, DSCP 20, DSCP 22
C) Assured Forwarding (AF)
D) 40
E) DSCP 18 - 5°, DSCP 20 - 6.67°, DSCP 22 - 10°
ReIates to: Monitoring CB-WRED
Case Study: WRED Traffic
Profiles
Overview
requirements oI a small to mid-sized network. Your task is to work with a partner to evaluate
the QoS requirements, and based on these requirements, create WRED traIIic proIiles that you
can use to implement the required QoS administrative policy. You will discuss your traIIic
proIile with the instructor and other classmates, and the instructor will present a solution Ior the
case study to the class.
ReIevance
The creation oI traIIic proIiles is an important step in correctly implementing an active queue
management strategy using congestion avoidance mechanisms such as WRED.
Objectives
In this activity, you will create the appropriate WRED traIIic proIile to properly implement a
customer QoS administrative policy. Upon completing this case study, you will be able to meet
these objectives:
IdentiIy the service classes required to implement the policy
Create WRED traIIic proIiles that can be used to implement the policy
Fundamentals oI congestion avoidance with WRED
OutIine
Required Resources
Case Study Activity: WRED TraIIic ProIiles
Job Aids
OutIine
· Overview
· Create WRED Traffic ProfiIes
Case Study Tasks
Step 1 Review customer QoS requirements. Completely read the customer requirements
provided.
Step 2 IdentiIy QoS service class requirements. With the aid oI your partner, identiIy the
Step 3 Create WRED traIIic proIiles. Create the WRED traIIic proIiles required to properly
implement the administrative QoS policy.
Step 4 Present your solution. AIter the instructor presents a solution to the case study,
instructor.
This case study involves analyzing an administrative QoS policy oI LCR Incorporated, a
Iictitious manuIacturer oI recumbent bicycles. The company has provided you with a short
description oI their requirements. It is your task to provide the network engineers Irom LCR
with a QoS solution to meet their requirements.
Read the customer requirements and discuss them with your partner. IdentiIy the diIIerent
classes oI service required and hence the number oI WRED traIIic proIiles required to solve
this customer problem.
Company Background
LCR Incorporated began making recumbent bicycles in the garage oI its owner Patrick Cagney,
in 1984. Since that time, the company has grown to be a global provider oI recumbent bicycles.
Headquartered in St. Petersburg, Florida, LCR has two manuIacturing Iacilities and Iive sales
oIIices in the United States.
Each site utilizes dedicated 100 Mb switching to the desktop and contains a distributed server
Iarm. Each site connects over a private WAN connection to the corporate headquarters using an
IP-enabled Frame Relay service Irom a global service provider. WAN link speeds are all T1
(1.544 Mbps).
Customer Situation
LCR Incorporated is currently experiencing application perIormance problems and has an
urgent need to resolve them. Internet usage at LCR is extremely high because most oI the sales
and customer contacts oI the company use the Internet. The company currently has redundant,
3-Mbps Internet connections at its headquarters. Much oI the use oI the Internet, however, is
Ior non-business-critical applications. ThereIore, Internet browsing and non-critical
applications should be treated as the lowest priority.
Many oI the applications at LCR are distributed between sites because they require
collaboration between members oI the LCR staII. Examples are Oracle and Citrix.
ManuIacturing and Finance use Oracle databases to manage inventory, shipping, order entry,
and customer billing. These systems are integrated across the company and reside in the main
data center at the headquarter location. Citrix is heavily used Ior quality assurance monitoring
oI manuIacturing and its automated systems. LCR has indicated that the Oracle application and
Citrix transactions are critical to the company. Internet traIIic should not be allowed to interIere
with Oracle or Citrix transactions.
Working with the network engineering staII at LCR and the service provider, you have been
enlisted to assist LCR by deIining QoS requirements Ior their network. Their Iirst priority is to
deploy active congestion management mechanisms across the provider backbone to ease the
congestion issues they are experiencing.
IdentiIy the diIIerent traIIic classes required to implement the customer administrative QoS
policy. Use the table below to help you with your answer choices. Write your answers on the
lines below:
Customer TraIIic: ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸ PHB: ¸¸¸¸¸¸¸¸¸¸¸¸ DSCP: ¸¸¸¸¸¸¸¸¸¸¸¸
QoS Service CIasses
PHB DSCP DSCP
VaIue
Intended
ProtocoIs and
AppIications
Service
CIass
Service CIass and
Configuration
EF EF 101110 Ìnteractive Voice Voice Bearer Admission Control = RSVP
Queuing = Priority
AF1 AF11
AF12
AF13
001010
001100
001110
General Data Service,
FTP, Backups
Bulk Data Queuing = Rate Based
AF2 AF21
AF22
AF23
010010
010100
010110
Database access,
transaction services,
interactive traffic,
preferred data service
Transactional Queuing = Rate Based
AF3 AF31
AF32
AF33
011010
011100
011110
Locally defined
mission-critical
applications
Mission-
critical
AF4 AF41
AF42
AF43
100010
100100
100110
Ìnteractive video and
associated voice
Ìnteractive
Video
CS6 Class 6 110000 Border Gateway
Control (BGP), Open
Shortest Path First
(OSPF), etc.
Routing
(Reserved)
CS4 Class 4 100000 Often proprietary Streaming
Video
minth < maxth
CS3 Class 3 011000 Session Ìnitiation
Protocol (SÌP), H.323,
etc.
Call Signaling Queuing = Rate Based
CS1 Class 1 001000 User-selected service,
PPP Applications
Less-than-
Best-Effort
Data
(Scavenger)
No bandwidth guarantee
minth < maxth
DefauIt Default
(Best
Effort)
Class 0
000000 Unspecified traffic, E-
mail, Ìnternet
Best-Effort Queuing = Rate Based
Minimal bandwidth guarantee
Active Queue Mgt or Per-flow
fair queuing
minth < maxth
Create WRED Traffic ProfiIes
Create a WRED traIIic proIile Ior each oI the service classes identiIied in the previous section.
Use the Iollowing table to assist you in creating your proIile. When completing each proIile, be
sure to draw the traIIic proIile and include all inIormation on the blank proIile graphic
provided.
Cisco IOS DefauIt WRED ProfiIe VaIues
PHB
Minimum
ThreshoId
Maximum
ThreshoId Mark ProbabiIity
af11 32 40 1/10
af12 28 40 1/10
af13 24 40 1/10
af21 32 40 1/10
af22 28 40 1/10
af23 24 40 1/10
af31 32 40 1/10
af32 28 40 1/10
af33 24 40 1/10
af41 32 40 1/10
af42 28 40 1/10
af43 24 40 1/10
cs1 22 40 1/10
cs2 24 40 1/10
cs3 26 40 1/10
cs4 28 40 1/10
cs5 30 40 1/10
cs6 32 40 1/10
cs7 34 40 1/10
EF 36 40 1/10
RSVP 36 40 1/10
Default (BE) 20 40 1/10
Traffic ProfiIe 1:
TraIIic Class: ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸ PHB: ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
WRED TraIIic ProIile Parameters:
Minimum Threshold: ¸¸¸¸¸¸¸¸¸¸¸¸¸ Maximum Threshold: ¸¸¸¸¸¸¸¸¸¸¸¸¸
Mark Probability Denominator: ¸¸¸¸¸¸¸¸¸¸
Traffic ProfiIe 2:
100%
Average
Queue
Size
Drop
ProbabiIity
Traffic ProfiIe 3:
100%
Average
Queue
Size
Drop
ProbabiIity
inIormation:
WRED traIIic proIiles
Identify Customer QoS Requirements
Customer TraIIic: Oracle PHB: AF2 DSCP: AF21
Customer TraIIic: Citrix PHB: AF2 DSCP: AF22
Customer TraIIic: Internet PHB: DeIault (BE) DSCP: 0
Create WRED Traffic ProfiIes
Traffic Profile 1:
TraIIic Class: Transactional PHB: AF21
Minimum Threshold: 32 Maximum Threshold: 40 Mark Probability Denominator: 10
Traffic Profile 2:
TraIIic Class: Transactional PHB: AF22
Traffic Profile 3:
TraIIic Class: DeIault PHB: 0
100%
Average
Queue
Size
Drop
ProbabiIity
10%
20 40
No drop Random drop FuII drop
100%
Average
Queue
Size
Drop
ProbabiIity
10%
20 40
No drop Random drop FuII drop
100%
Average
Queue
Size
Drop
ProbabiIity
32 28
AF22 AF21
No Drop Random Drop TaiI Drop
100%
Average
Queue
Size
Drop
ProbabiIity
32 28
AF22 AF21
No Drop Random Drop TaiI Drop
Configuring Explicit
Congestion Notification
Overview
avoid congestion at common network bottleneck points. Congestion avoidance is achieved
through packet dropping by using more complex techniques than simple tail drop. With the
addition oI ECN extensions to IP, routers now have an alternative method oI indicating
congestion to peers. This lesson introduces the concept oI ECN and the Cisco IOS commands
that are required to conIigure and monitor ECN.
ReIevance
response, tail drop. ECN extends the number oI available options Ior avoiding congestion by
allowing routers to signal peers about congestive states without dropping packets.
Objectives
Upon completing this lesson, you will be able to conIigure ECN to enhance the congestion
avoidance Ieatures oI WRED. This includes being able to meet these objectives:
Describe the ECN extensions to IP
IdentiIy key characteristics oI the ECN Iield in IP
Explain how ECN interacts with WRED
IdentiIy the Cisco IOS commands required to conIigure ECN
IdentiIy the Cisco IOS commands used to monitor ECN
Congestion avoidance with WRED
OutIine
OutIine
· Overview
· ExpIicit Congestion Notification
· ECN FieId Defined
· ECN and WRED
· Configuring ECN-EnabIed WRED
· Monitoring ECN-EnabIed WRED
· Summary
· Quiz
ExpIicit Congestion Notification
This topic describes ECN as an extension to IP.
TCP determines how many unacknowledged packets it can send (window size) by gradually
increasing the number oI packets it sends until it experiences a dropped packet. As a result,
TCP tends to cause router queues to build up at network bottleneck points. When queues
become Iull, tail drop begins dropping all incoming packets until there is room in the queue.
Tail drop does not provide diIIerential treatment and thereIore some oI the Iragile Ilow packets,
sensitive to latency, may be dropped. In addition, tail drop can lead to global synchronization oI
packet loss across multiple Ilows.
Active queue management mechanisms such a RED or WRED, detect congestion beIore
queues Iill and overIlow. Through the use oI selective packet discard, these mechanisms
provide congestion indication to end nodes. ThereIore, active queue management (congestion
avoidance) mechanisms can reduce queuing delays Ior all traIIic sharing a speciIic queue. In
addition, active queue management means that it is no longer necessary to rely on buIIer
overIlow as the only means oI indicating congestion.
Traditional active queue management mechanisms, such as RED, rely on the use oI packet
drops to indicate congestion. Packet dropping in these mechanisms is based on the average
queue length exceeding a predeIined threshold, rather than only when queues overIlow.
However, because packets are dropped prior to queues actually overIlowing, the router
dropping the packet is not always constrained by memory limitations and needs to actually drop
the packet. With the 'Addition oI Explicit Congestion NotiIication to IP¨ (RFC 3168), active
queue management allows routers to signal that congestion has been experienced by the router,
instead oI relying on the use oI packet drops. Through the use oI signaling congestion,
aggressive Ilows can be slowed, thus reducing the impact oI congestion and packet loss on
latency-sensitive Ilows.
ExpIicit Congestion Notification
· TCP congestion controIs are not suited to appIications
that are sensitive to deIay or packet Ioss.
· ECN (RFC 3168) removes need to reIy on packet Ioss as a
congestion indicator.
· ECN marks packets instead of dropping them when the
average queue Iength exceeds a specific threshoId vaIue.
· Routers and end hosts can use ECN marking as a signaI
that the network is congested and send packets at a
sIower rate.
ECN FieId Defined
This topic describes the characteristics oI the ECN Iield.
'The Addition oI Explicit Congestion NotiIication to IP¨ (RFC 3168), redeIines the
DiIIerentiated Services (DiIIServ) Iield (Iormer type oI service |ToS| byte) to contain an ECN-
speciIic Iield. The ECN Iield consists oI the last two low-order bits oI the DiIIServ Iield and is
comprised oI the ECN-capable Transport (ECT) bit and the congestion experienced (CE) bit.
The ECT bit and the CE bit can be used to make Iour ECN Iield combinations oI 00, 01, 10,
and 11. The diIIerent ECT and CE bit combinations in the ECN Iield have the Iollowing
meaning:
00: The ECN Iield combination indicates that a packet is not using ECN.
01 and 10: The ECN Iield combinations, called ECT(1) and ECT(0), respectively, are set
by the data sender to indicate that the endpoints oI the transport protocol are ECN-capable.
Routers will treat these two Iield combinations identically. Data senders can use either one
or both oI these two combinations.
11: The ECN Iield combination indicates to the endpoints that congestion has been
experienced. Packets arriving at a Iull queue oI a router will be dropped.
ECN FieId Defined
ECN and WRED
This topic describes how ECN interacts with WRED.
On Cisco IOS routers, ECN is an extension to WRED Iunctionality. WRED is an active queue
management mechanism that utilizes packet drops as a congestion indicator to endpoints.
Packets are dropped by WRED based on the average queue length exceeding a speciIic set oI
predeIined threshold values (minimum and maximum threshold). ECN is an extension to
WRED in that ECN marks packets instead oI dropping them when the average queue length
exceeds a speciIic threshold value. When ECN is conIigured with WRED, routers and end
hosts would use this marking as a signal that the network is congested and would slow down
the rate at which packets are sent.
One important aspect oI ECN is that it must be interoperable with non-ECN-compliant devices.
Because ECN is conIigured as an extension to WRED, packets are treated diIIerently by
WRED when ECN has been enabled.
II the average queue length is below the deIined WRED minimum threshold, all packets are
queued and transmitted normally. This behavior is identical to devices that are conIigured to
use non-ECN-enabled WRED.
II the average queue length is greater than the maximum threshold, packets are tail-dropped.
This behavior is identical to devices conIigured to use non-ECN-enabled WRED.
ECN and WRED
· ECN is an extension to WRED.
· Congestion in WRED is indicated based on the average
queue Iength exceeding a specific threshoId vaIue.
· If the number of packets in the queue is beIow the
minimum threshoId, packets are transmitted.
÷ Treatment is identicaI to a network using onIy WRED.
· If the number of packets in the queue is above the
maximum threshoId, packets are taiI-dropped.
÷ Treatment is identicaI to a network using onIy WRED.
Where non-ECN-enabled WRED and ECN-enabled WRED routers diIIer is in how packets are
treated where the average queue length is between the minimum and maximum thresholds.
II the average queue length is greater than the deIined WRED minimum threshold but less than
the deIined WRED maximum threshold, one oI three actions is possible:
II endpoints support ECN (ECN-capable) and the WRED algorithm determines that the
packet should be dropped based on the drop probability, both the ECT and CE bits are
marked (set to 1), to indicate that congestion has been experienced. The packet is then
transmitted towards its destination. When the ECN-capable endpoint receives the packet, it
will slow its transmission rate.
II endpoints do not support ECN (non-ECN-capable), it is up to the WRED algorithm to
determine wheter to drop the packet or not based on the drop probability. This behavior is
identical to devices that are conIigured to use non-ECN-enabled WRED.
II the incomming packet already has the ECT and CE bits marked (set to 1), indicating that
congestion has been experienced, the packet is transmitted towards its destination without
modiIying its ECN marking. Transmision oI the packet towards the endpoint without
modiIying its ECN markings (or dropping the packet) are important because the ECN bits
are the signal that congestion is occurring and the endpoint should slow its packet
transmission rate. However, iI the incomming packet arrives at a Iull output queue, the
packet will be tail-dropped.
ECN and WRED (Cont.)
If the number of packets in the queue is between
the minimum and maximum threshoId, one of three
scenarios can occur:
· ECN-capabIe endpoints and WRED determine that the
packet shouId be dropped based on the drop probabiIity:
÷ ECT and CE bits for the packet are changed to 1 and the packet is
transmitted.
· Non ECN-capabIe endpoints:
÷ The packet may be dropped based on the WRED drop probabiIity.
· The network is experiencing congestion:
÷ The packet is transmitted and no further marking is required.
Configuring ECN-EnabIed WRED
This topic describes the Cisco IOS commands that are required to conIigure ECN extensions to
WRED.
The ECN Ieature must be conIigured through the MQC. ECN is conIigured as part oI a policy
map aIter CB-WRED has been enabled. ECN can be used whether the CB-WRED
conIiguration is based on IP precedence or DSCP.
Note: The ECN feature was introduced in Cisco ÌOS release 12.2(8)T.
Configuring ECN-EnabIed WRED
random~detect ecn random~detect ecn
· EnabIes expIicit congestion notification (ECN).
· ECN can be used whether WRED is based on the IP
precedence or DSCP vaIue.
· ECN must be configured through MQC.
router(config)# policy~map MyPolicy
router(config~pmap)# class class~default
router(config~pmap)# bandwidth percent 70
router(config~pmap~c)# random~detect
router(config~pmap~c)# random~detect ecn
Monitoring ECN-EnabIed WRED
This topic describes the Cisco IOS commands that are required to monitor ECN-enabled
WRED.
The show policy-map command displays the conIiguration oI a service policy map created
using the show policy-map command. The show policy-map command will display ECN
marking inIormation only iI ECN is enabled on the interIace. The Iollowing table explains
some oI the key Iields oI the show policy-map command.
show poIicy-map Parameters
explicit congestion
notification
Ìndication that ECN is enabled.
class ÌP precedence value.
min-threshold Minimum threshold. Minimum WRED threshold in number of
packets.
max-threshold Maximum threshold. Maximum WRED threshold in number of
packets.
mark-probability Fraction of packets dropped when the average queue depth is at
the maximum threshold.
Monitoring ECN-EnabIed WRED
router#
· DispIays the configuration of aII cIasses for a specified
service poIicy map or aII cIasses for aII existing poIicy
maps
router#show policy~map
Policy Map MyPolicy
Class class~default
Bandwidth 70 (%)
exponential weight 9
explicit congestion notification
class min~threshold max~threshold mark~probability
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0 ~ ~ 1/10
1 ~ ~ 1/10
2 ~ ~ 1/10
3 ~ ~ 1/10
. . .
The show policy-map interface command displays the conIiguration oI all classes conIigured
Ior all service policies on the speciIied interIace. The counters displayed aIter the show policy-
map interface command is entered are updated only iI congestion is present on the interIace.
The show policy-map interface command displays ECN marking inIormation only iI ECN is
enabled on the interIace. The Iollowing table explains some oI the key Iields oI the show
policy-map interface command.
show poIicy-map interface Parameters
explicit congestion
notification
Ìndication that ECN is enabled.
Monitoring ECN-EnabIed WRED (Cont.)
router#
· DispIays the configuration of aII cIasses configured for aII
service poIicies on the specified interface
router#show policy~map interface Serial4/1
Serial4/1
Service~policy output:policy_ecn
Class~map:prec1 (match~all)
Match:ip precedence 1
output Queue:Conversation 42
Bandwidth 20 (%)
Bandwidth 100 (kbps)
exponential weight:9
show poIicy-map interface Parameters (Cont.)
mean queue depth Average queue depth based on the actual queue depth on the
interface and the exponential weighting constant. Ìt is a moving
average. The minimum and maximum thresholds are compared
against this value to determine drop decisions.
class ÌP precedence value.
Transmitted pkts/bytes Number of packets (also shown in bytes) transmitted.
Random drop pkts/bytes Number of packets (also shown in bytes) randomly dropped when
the mean queue depth is between the minimum threshold value
and the maximum threshold value for the specified ÌP precedence
value.
Tail drop pkts/bytes Number of packets dropped when the mean queue depth is
greater than the maximum threshold value for the specified ÌP
precedence value.
Minimum threshold Minimum WRED threshold in number of packets.
Maximum threshold Maximum WRED threshold in number of packets.
Mark probability Fraction of packets dropped when the average queue depth is at
the maximum threshold.
ECN Mark pkts/bytes Number of packets (also shown in bytes) marked by ECN.
Monitoring ECN-EnabIed WRED (Cont.)
mean queue depth:0
class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes threshold threshold probability
0 0/0 0/0 0/0 20 40 1/10
1 545/68125 0/0 0/0 22 40 1/10
2 0/0 0/0 0/0 24 40 1/10
3 0/0 0/0 0/0 26 40 1/10
4 0/0 0/0 0/0 28 40 1/10
5 0/0 0/0 0/0 30 40 1/10
6 0/0 0/0 0/0 32 40 1/10
7 0/0 0/0 0/0 34 40 1/10
rsvp 0/0 0/0 0/0 36 40 1/10
class FCN Mark
pkts/bytes
0 0/0
1 43/5375
2 0/0
3 0/0
4 0/0
5 0/0
6 0/0
7 0/0
rsvp 0/0
Summary
This section summarizes the key points discussed in this lesson.
References
For more inIormation on using WRED with ECN, reIer to, 'WREDExplicit Congestion
NotiIication,¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios122/122newIt/122t/122t8/It
wrdecn.htm
For more inIormation on ECN, reIer to, 'RFC 3168: The Addition oI Explicit Congestion
NotiIication to IP,¨ at the Iollowing URL: http://www.ietI.org/rIc/rIc3168.txt
Next Steps
Lab Exercise 6-1: ConIiguring DSCP-Based WRED
Summary
· ECN is an extension to WRED that removes the need to
reIy on packet Ioss as a congestion indicator.
· ECN marks packets instead of dropping them when the
average queue Iength exceeds a specific threshoId vaIue.
· ECN defines two fIow controI bits as extensions to the
DiffServ fieId: The ECT bit and the CE bit.
· ECN can be used whether WRED is based on the IP
precedence or DSCP vaIue.
· On Cisco IOS routers, the ECN feature must be
configured through MQC.
Quiz
Q1) What is a key advantage oI active queue management using Explicit Congestion
NotiIication?
A) Packets Irom aggressive Ilows are randomly dropped as a means oI avoiding
global synchronization, congested queues, and tail drop.
B) Congestion is signaled without drops, causing aggressive Ilows to be slowed,
reducing the impact oI congestion and packet loss on latency-sensitive Ilows.
C) Packet drops are used as an indication that senders should reduce transmission
rates, removing the congested state.
D) Packets are not dropped unless the queue exhausts its packet buIIer memory,
allowing endpoints to request a transmission rate Ior sending Ilows into the
network controls congestion. ECN maintains the Ilow transmission process.
Q2) What two bits are deIined as part oI the ECN extensions to IP? (Choose two.)
A) transmission control bit
B) ECN-capable transport bit
C) congestion-experienced bit
D) Forward Explicit Congestion NotiIication bit
Q3) What is indicated by the ECN Iield bit combination oI 00?
A) Congestion has been experienced in the network.
B) The packet is not Irom an ECN- capable endpoint.
C) The endpoint recognizes ECN, but no congestion has been encountered.
D) Packets have been dropped because oI experienced congestion.
Q4) How does ECN extend the capabilities oI WRED-conIigured Cisco routers?
A) ECN allows diIIerential packet dropping based on IP precedence or DSCP.
B) ECN allows routers to dynamically allocate packet buIIers based on congestion
signaling.
C) ECN removes the need to drop packets when the average queue length is
between the two deIined WRED thresholds.
D) ECN uses signaling to manage previously deIined packet transmission rates oI
network endpoints.
Q5) In an ECN-enabled WRED conIiguration, what happens iI the average queue length
grows larger than the minimum threshold but the endpoints are not ECN-capable?
A) The router will automatically allocate more packet buIIers to prevent packet
loss.
B) The router will request ECN options Irom the endpoints.
C) The packet will be dropped or transmitted according to normal WRED drop
probability calculations.
D) The packet will be dropped as a means oI slowing the packet transmission rate.
Q6) What two requirements must be met prior to conIiguring ECN on Cisco IOS routers?
(Choose two.)
A) CB-WRED must Iirst be conIigured using the random-detect command.
B) CBWFQ must Iirst be conIigured using MQC.
C) WRED must be conIigured to use DSCP as its weight.
D) The ECN bits must be reset (marked 0,0) using a policy map.
Q7) What two Cisco IOS commands can be used to veriIy that ECN has been enabled?
(Choose two.)
A) show interface
B) show policy-map
C) show policy-map interface
D) show interface random-detect
Quiz Answer Key
Q1) B
ReIates to: Explicit Congestion Notification
Q2) B, C
ReIates to: ECN Field Defined
Q3) B
ReIates to: ECN Field Defined
Q4) C
ReIates to: ECN and WRED
Q5) C
ReIates to: ECN and WRED
Q6) A, B
ReIates to: Configuring ECN-Enabled WRED
Q7) B, C
ReIates to: Monitoring ECN-Enabled WRED
Module Assessment
Overview
Quiz: Congestion Avoidance
Objectives
Explain the problems that may result Irom the limitations oI TCP congestion management
mechanisms on a converged network
Explain how RED can be used to avoid congestion
ConIigure CB-WRED to avoid congestion
ConIigure ECN to enhance the congestion avoidance Ieatures oI WRED
Instructions
incorrectly.
Q1) What are two ways in which TCP manages congestion? (Chose two.)
A) TCP uses tail drop on queues that have reached their queue limit.
B) TCP uses dropped packets as an indication that congestion has occurred.
C) TCP uses variable window sizes to reduce and increase the rates at which
packets are sent.
D) TCP measures the average size oI device queues and drops packets, linearly
increasing the amount oI dropped packets with the size oI the queue.
Q2) What are two active congestion management mechanisms available on Cisco IOS
routers? (Choose two.)
A) tail drop
B) weighted round robin
C) explicit congestion notiIication
D) weighted random early detection
Q3) Two stations (A and B) are communicating using TCP. Station A has negotiated a TCP
window size oI 5 and as a result sends 5 packets to station B.
Station A receives 3 ACK messages Irom station B indicating ACK 3.
Which two oI the Iollowing descriptions best describe the status oI the communication
between A and B? (Choose two)
A) Station B is acknowledging receipt oI packets 1, 2, and 3, but has lost packets 4
and 5.
B) Station A initiates a Iast-retransmit and immediately sends packet 3 to B.
C) Station B has not received packet 3.
D) Station B has received packets 1, 2, and 3, but not packet 4. It cannot be
determined where packet 5 was received at B until packet 4 has been sent.
E) Station A will send packets 4 and 5 to station B upon receipt oI the station B
ACK.
Q4) What are three important limitations oI using a tail-drop mechanism to manage queue
congestion? (Choose three.)
A) Tail drop can cause many Ilows to synchronize, lowering overall link
utilization.
B) Tail drop can cause starvation oI Iragile Ilows.
C) Tail drop increases the amount oI packet buIIer memory required, as queues
must be Iull beIore congestion management becomes active.
D) Tail drop results in variable delays, which can interIere with delay-sensitive
traIIic Ilows.
Q5) What are three advantages oI active congestion management using RED? (Choose
three.)
A) RED uses selective packet discard to eliminate global synchronization oI TCP
Ilows.
B) RED avoids congestion by ensuring that interIace queues never become Iull.
C) RED increases the overall utilization oI links.
D) RED uses selective packet discard to penalize aggressive Ilows.
Q6) A speciIic RED proIile has been conIigured with a mark probability denominator oI 1.
What is the eIIect oI this conIiguration on packet loss as the average queue length
reaches the maximum threshold?
A) Given this conIiguration, no packets will be dropped until the average queue
length is greater than the maximum threshold.
B) For every active traIIic Ilow, one packet will be discarded.
C) When the average queue length is at the maximum threshold, all packets are
dropped.
D) This is an invalid conIiguration.
Q7) ReIer to the Iollowing RED traIIic proIile. How will the RED traIIic proIile in the
Iigure aIIect the traIIic Ilows to which it is applied? (Choose two.)
Figure: RED Traffic ProfiIe
A) Packets may be dropped unnecessarily as the minimum threshold is too low.
B) This proIile can result in global synchronization as the diIIerence between the
minimum and maximum thresholds is too small.
C) RED will not be eIIective as the mark probability denominator is 50 when the
average queue length reaches the maximum threshold.
D) The reduced size oI the maximum threshold will prevent tail drop and
maximize link utilization.
Q8) What are the three traIIic drop modes in Random Early Detection? (Choose three.)
A) no drop
B) Iull drop
C) random drop
D) deIerred drop
Q9) What two QoS markers can you base the 'weight¨ in WRED on when conIiguring CB-
WRED? (Choose two.)
A) CoS
B) DSCP
C) QoS group
D) IP precedence
Average
Queue
Size
Drop
ProbabiIity
50%
100%
8 10
Average
Queue
Size
Drop
ProbabiIity
50%
100%
8 10
Q10) What are two requirements Ior conIiguring CB-WRED? (Choose two.)
A) An MQC conIiguration that includes a policy map must be conIigured.
B) CEF must be enabled Ior IP.
C) Random detect must be enabled Ior DSCP-based CB-WRED.
D) A previous conIiguration oI CB-WFQ must be present.
Q11) Given the Iollowing CB-WRED conIiguration, what command should be entered in the
Bronze traIIic class to properly enable CB-WRED using a minimum threshold oI 22, a
maximum threshold oI 36, and a drop probability oI 10 percent?
class-map Bronze
match ip dscp csI
!
policy-map PolicyI
class Bronze
bandwidth percent IS
random-detect dscp-based
( <~ _____ ~> )
!
class class-default
fair-queue
A) random-detect dscp-based 22 36 10
B) random-detect dscp-based cs1 22 36 10
C) random-detect dscp cs1 22 36
D) random-detect dscp cs1 10 22 36
Q12) What will a router do with a newly arriving packet iI its output queue is Iull and ECN
Iields are both set to a 1?
A) drop the last packet on the queue and enqueue the newly arriving packet
B) perIorm a tail drop and drop the new packet
C) move the packet to the head oI the queue to ensure that the receiver is signaled
about the network congestion condition
D) allocate additional interIace buIIers to store the packet since it contains
congestion notiIication inIormation
Q13) Given the Iollowing conIiguration, what Cisco IOS conIiguration command must be
added to the deIault class to enable Explicit Congestion NotiIication (ECN)?
policy-map MyPolicy
class class-default
bandwidth percent I0
random-detect
( <~ _____ ~> )
A) wred ecn
B) ecn enable
C) random-detect ecn
D) random-detect ecn enable
Scoring
or better.
Q1) B, C
ReIates to: Ìntroduction to Congestion Avoidance
Q2) C, D
ReIates to: Weighted Random Early Detection (WRED), Explicit Congestion Notification (ECN)
Q3) B, C
Q4) A, B, D
Q5) A, C, D
ReIates to: Ìntroduction to RED
Q6) C
Q7) A, B
Q8) A, B, C
Q9) B, D
ReIates to: Configuring Class-Based Weighted RED
Q10) A, D
Q11) C
Q12) B
ReIates to: Configuring Explicit Congestion Notification
Q13) C
ReIates to: Configuring Explicit Congestion Notification
ModuIe Summary
Congestion management is an area oI concern Ior all networks that require a diIIerentiated
treatment oI packet Ilows. Active queue management mechanisms address the limitations oI
relying solely on TCP congestion management techniques, which simply wait Ior queues to
overIlow and then drop packets to signal that congestion has occurred. Congestion avoidance
mechanisms such as RED and WRED allow Ior speciIic packet Ilows to be selectively
penalized and slowed by applying a traIIic proIile. TraIIic Ilows are matched against this
proIile and transmitted or dropped depending upon the average length oI the interIace output
queue. In addition, RED and WRED are extremely eIIective tools at preventing global
synchronization oI many TCP traIIic Ilows. Another active queue management technique is
ECN. ECN is an extension to WRED that allows Ior signaling to be sent to ECN-enabled
endpoints, instructing them to reduce their packet transmission rates. ECN also provides the
beneIit oI not requiring packet drops when the WRED drop probability indicates otherwise.
ModuIe Summary
· By defauIt, routers use taiI drop as a means of
congestion controI when an output queue is fuII. TaiI
drop treats aII traffic equaIIy and does not differentiate
between cIasses of service. When taiI drop is in effect,
packets are dropped untiI the congestion is eIiminated
and the queue is no Ionger fuII.
· Congestion avoidance techniques, Iike RED, monitor
network traffic Ioads in an effort to anticipate and avoid
congestion at common network bottIenecks. Congestion
avoidance is achieved through packet dropping.
· WRED, the Cisco impIementation of RED, combines the
capabiIities of the RED aIgorithm with IP precedence or
DSCP.
· ECN is an extension to WRED that enabIes fIow controI
and congestion signaIing without requiring packet drops.
ModuIe 7
Traffic Policing and Shaping
Overview
Within a network, diIIerent Iorms oI connectivity can have signiIicantly diIIerent costs to an
organization. For instance, a LAN connection will cost considerably less than a WAN
connection Ior an equal amount oI bandwidth. Because WAN bandwidth is relatively
expensive, many organizations would like to limit the amount oI traIIic that speciIic
applications can send. This is especially true when enterprise networks use Internet connections
Ior remote site and extranet connectivity. Downloading non-business-critical images, music,
and movie Iiles can greatly reduce the amount oI bandwidth available to other mission-critical
applications. TraIIic policing and traIIic shaping are two quality oI service (QoS) techniques
that can be used to limit the amount oI bandwidth a speciIic application can use on a link.
From a services perspective, many service providers would like to install a larger bandwidth
connection to customers but provision a smaller circuit so that incremental bandwidth upgrades
do not require provisioning new circuits or installing new equipment. Called sub-rate access,
traIIic policing and traIIic shaping techniques can also assist in this regard.
In this module, the operation oI traIIic policing and traIIic shaping, and how these techniques
can be used to rate-limit traIIic is discussed. As Frame Relay WANs have speciIic
requirements, class-based traIIic shaping on Frame Relay networks is also covered in this
module.
ModuIe Objectives
Upon completing this module, you will be able to use Cisco QoS traIIic policing and traIIic-
shaping mechanisms to eIIectively limit the rate oI network traIIic.
ModuIe OutIine
ModuIe Objectives
· ExpIain how traffic poIicing and traffic shaping can be
used to rate-Iimit traffic
· Configure cIass-based poIicing to rate-Iimit traffic
· Configure cIass-based shaping to rate-Iimit traffic
· Configure cIass-based shaping on Frame ReIay WAN
interfaces to rate-Iimit traffic
ModuIe OutIine
· Traffic PoIicing and Traffic Shaping Overview
· Configuring CIass-Based PoIicing
· Configuring CIass-Based Shaping
· Configuring CIass-Based Shaping on Frame
ReIay Interfaces
Traffic Policing and
Traffic Shaping Overview
Overview
TraIIic policing can be used to control the maximum rate oI traIIic sent or received on an
interIace. TraIIic policing is oIten conIigured on interIaces at the edge oI a network to limit
traIIic into or out oI the network. TraIIic that Ialls within the rate parameters is sent, whereas
traIIic that exceeds the parameters is dropped or sent with a diIIerent priority.
TraIIic shaping can be used to control the traIIic going out an interIace in order to match its
Ilow to the speed oI the remote target interIace and to ensure that the traIIic conIorms to
policies contracted Ior it. Thus, traIIic adhering to a particular proIile can be shaped to meet
downstream requirements, thereby eliminating bottlenecks in topologies with data-rate
mismatches.
TraIIic policing and traIIic shaping diIIer in the way they respond to traIIic violations. Policing
typically drops traIIic, while shaping typically queues excess traIIic by using a shaping queue
to hold packets and shape the Ilow when the data rate oI the source is higher than expected.
This lesson describes the traIIic-policing and traIIic-shaping QoS mechanisms that are used to
limit the available bandwidth to traIIic classes. Because both traIIic policing and traIIic shaping
use the token bucket metering mechanism, this lesson also explains how a token bucket works.
ReIevance
Enterprise and service provider networks have a variety oI requirements Ior traIIic
conditioning. TraIIic policing and traIIic shaping are important traIIic conditioning tools to
allow traIIic rates to be controlled.
Objectives
Upon completing this lesson, you will be able to explain how traIIic policing and traIIic
shaping can be used to condition traIIic. This includes being able to meet these objectives:
Describe the purpose oI traIIic conditioning using traIIic policing and traIIic shaping
List key beneIits oI traIIic conditioning using traIIic policing and traIIic shaping
DiIIerentiate between the Ieatures oI traIIic policing and traIIic shaping
Explain how network devices measure traIIic rates
Explain how traIIic can be policed using a single token bucket scheme
Explain how traIIic can be policed using a dual token bucket scheme
Explain how traIIic can be policed using a dual-rate metering scheme
Explain how traIIic can be shaped using a single token bucket scheme
IdentiIy the key traIIic policing and shaping mechanisms available in Cisco IOS soItware
and diIIerentiate among them
IdentiIy the points in a network where traIIic conditioning can most eIIectively be
employed
A good understanding oI Frame Relay operation and conIiguration
A good understanding oI traIIic classiIication
Copyright © 2003, Cisco Systems, Ìnc. Traffic Policing and Shaping 7-5
OutIine
OutIine
· Overview
· Traffic PoIicing and Shaping Overview
· Why Use Traffic Conditioners?
· PoIicing vs. Shaping
· Measuring Traffic Rates
· SingIe Token Bucket CIass-Based PoIicing
· DuaI Token Bucket CIass-Based PoIicing
· DuaI-Rate Token Bucket CIass-Based PoIicing
· CIass-Based Traffic Shaping
· Cisco IOS Traffic PoIicing and Shaping Mechanisms
· AppIying Traffic Conditioners
· Summary
· Quiz
Traffic PoIicing and Shaping Overview
This topic describes the purpose oI traIIic conditioning using traIIic policing and traIIic
shaping.
Both traIIic shaping and policing mechanisms are traIIic-conditioning mechanisms that are
used in a network to control the traIIic rate. Both mechanisms use classiIication so that they can
diIIerentiate traIIic. They both measure the rate oI traIIic and compare it to the conIigured
traIIic-shaping or traIIic-policing policy.
The diIIerence between traIIic shaping and policing can be described in terms oI their
implementation:
TraIIic shaping buIIers excessive traIIic so that it stays within the desired traIIic rate. With
traIIic shaping, traIIic bursts are smoothed out by queuing the excess traIIic to produce a
steadier Ilow oI data. Reducing traIIic bursts helps reduce congestion in the network.
TraIIic policing drops excess traIIic in order to control traIIic Ilow within speciIied rate
limits. TraIIic policing does not introduce any delay to traIIic that conIorms to traIIic
policies. It can, however, cause more TCP retransmissions, because traIIic in excess oI
speciIied limits is dropped.
In Cisco IOS soItware, traIIic-policing mechanisms such as class-based policing or committed
access rate (CAR) also have marking capabilities in addition to rate-limiting capabilities.
Instead oI dropping the excess traIIic, traIIic policing can alternatively mark and then send the
excess traIIic. This allows the excess traIIic to be re-marked with a lower priority beIore they
are sent out.
TraIIic shapers like class-based shaping, generic traIIic shaping, Frame Relay traIIic shaping
(FRTS), or virtual IP (VIP)-based distributed traIIic shaping in Cisco IOS soItware do not have
the ability to mark traIIic.
Traffic PoIicing and Shaping Overview
· These mechanisms must cIassify packets before poIicing
or shaping the traffic rate.
· Traffic shaping queues excess packets to stay within the
desired traffic rate.
· Traffic poIicing typicaIIy drops or marks excess traffic to
stay within a traffic rate Iimit.
Why Use Traffic Conditioners?
This topic lists the key beneIits oI traIIic conditioning using traIIic policing and traIIic shaping.
TraIIic policing is typically used to satisIy one oI the Iollowing requirements:
Limiting the access rate on an interIace when high-speed physical inIrastructure is used in
transport. Rate limiting is typically used by service providers to oIIer customers sub-rate
access. For example, a customer may have an OC-3 connection to the service provider but
pay only Ior a T1 access rate. The service provider can rate-limit the customer traIIic to T1
speed.
Engineering bandwidth so that traIIic rates oI certain applications or classes oI traIIic
Iollow a speciIied traIIic rate policy. For example, rate limiting traIIic Irom Iile sharing
applications to 64 kbps maximum.
Re-marking excess traIIic with a lower priority at Layer 2 and Layer 3 or both beIore
sending them out. Cisco class-based traIIic policing can be conIigured as a multiaction
policer to mark packets at both Layer 2 and Layer 3. For example, excess traIIic can be re-
marked to a lower diIIerentiated services code point (DSCP) value and also have the Frame
Relay discard eligible (DE) bit set beIore the packet is sent out.
Why Use PoIicing?
· To Iimit access to resources when high-speed
access is used but not desired (sub-rate access)
· To Iimit the traffic rate of certain appIications or
traffic cIasses
· Mark down (re-coIor) exceeding traffic at Layer 2
and/or Layer 3
TraIIic shaping is typically used to:
Prevent and manage congestion in ATM and Frame Relay networks, where asymmetric
bandwidths are used along the traIIic path. II shaping is not used, then buIIering can occur
at the slow (usually the remote) end, which can lead to queuing causing delays and
overIlow causing drops.
Prevent dropping oI noncompliant traIIic by the ATM or Frame Relay service provider by
not allowing the traIIic to burst above the subscribed (committed) rate. This allows the
customer to keep local control oI traIIic regulation.
Why Use Shaping?
· To prevent and manage congestion in ATM and
Frame ReIay networks, where asymmetric
bandwidths are used aIong the traffic path.
· To reguIate the sending traffic rate to match the
subscribed (committed) rate in Frame ReIay or
ATM networks.
ExampIe: Traffic PoIicing
The Iigure shows an application Ior traIIic policing. TraIIic policing can be used to divide the
shared resource (the upstream WAN link) between many Ilows. In this example, the router Fast
Ethernet interIace has an input traIIic-policing policy applied to it, where the mission-critical
server traIIic rate is not rate-limited but the User X Iile-sharing application traIIic is rate-
limited to 56 kbps. All Iile-sharing application traIIic Irom User X that exceeds the rate limit oI
56 kbps will be dropped.
Traffic PoIicing ExampIe
· Rate-Iimit fiIe-sharing appIications traffic to 56 kbps.
· Do not rate-Iimit traffic from mission-criticaI server.
ExampIe: Traffic Shaping
TraIIic-shaping tools limit the transmit rate Irom a source by queuing the excess traIIic. This
limit is typically a value lower than the line rate oI the transmitting interIace. TraIIic shaping
can be used to account Ior speed mismatches that are common in nonbroadcast multiaccess
(NBMA) networks, such as Frame Relay and ATM.
In the Iigure, two types oI speed mismatches are shown:
The central site can have a higher speed link than the remote site. Thus, traIIic shaping can
be deployed at the central site router to shape the traIIic rate out oI the central site router to
match the link speed oI the remote site. For example, the central router can shape the
permanent virtual circuit (PVC) (going to the top remote-site router) outgoing traIIic rate to
128 kbps to match that remote site link speed. At each remote site router, traIIic shaping is
also implemented to shape the remote site outgoing traIIic rate to 128 kbps to match the
committed inIormation rate (CIR).
The aggregate link speed oI all the remote sites can be higher than the central site link
speed (over-subscribing the central site link speed). In this case, the remote-site routers can
be conIigured Ior traIIic shaping to avoid oversubscription at the central site. For example,
the bottom two remote-site routers can be conIigured to shape the PVC outgoing traIIic rate
to 256 kbps to avoid the central-site router Irom being over-subscribed.
Traffic Shaping ExampIe
· Both situations resuIt in buffering and in
deIayed or dropped packets.
· CentraI to remote site speed mismatch.
· Remote to centraI site over-subscription.
PoIicing vs. Shaping
This topic describes the diIIerence between the Ieatures oI traIIic policing and traIIic shaping.
Shaping queues excess traIIic by holding packets inside a shaping queue. TraIIic shaping is
used to shape the outbound traIIic Ilow when the outbound traIIic rate is higher than a
conIigured shape rate. TraIIic shaping smoothes traIIic by storing traIIic above the conIigured
rate in a shaping queue. ThereIore, shaping increases buIIer utilization on a router and causes
nondeterministic packet delays. TraIIic shaping can also interact with a Frame Relay network,
adapting to indications oI Layer 2 congestion in the WAN. For example, iI the backward
explicit congestion notiIication (BECN) bit is received, the router can lower the rate limit to
help reduce congestion in the Frame Relay network.
Policing can be applied to either the inbound or outbound direction while a shaper can only be
applied in the outbound direction. Policing drops nonconIorming traIIic instead oI queuing
them like a shaper and also supports marking oI traIIic. TraIIic policing is more eIIicient in
terms oI memory utilization than traIIic shaping because no additional queuing oI packets is
needed.
Both traIIic policing and shaping ensure that traIIic does not exceed a bandwidth limit, but they
have diIIerent impacts on the traIIic:
Policing drops packets more oIten, generally causing more retransmissions oI connection-
oriented protocols like TCP.
Shaping adds variable delay to traIIic, possibly causing jitter.
PoIicing vs. Shaping
· Incoming and outgoing directions
· Out-of-profiIe packets are dropped
· Dropping causes TCP retransmits
· Supports packet marking/
re-marking
· Less buffer usage (shaping
requires an additionaI shaping
queuing system)
· Outgoing direction onIy
· Out-of-profiIe packets are queued
untiI a buffer gets fuII
· Buffering minimizes TCP
retransmits
· Marking/re-marking not supported
· Shaping supports interaction with
Frame ReIay congestion indication
Measuring Traffic Rates
This topic explains how a token bucket can be used by network devices to measure traIIic rates.
The token bucket is a mathematical model that is used by routers and switches to regulate
traIIic Ilow. The model has two basic components:
Tokens: Where each token represents the permission to send a Iixed number oI bits into
the network. Tokens are put into a token bucket at a certain rate by the Cisco IOS soItware.
Token bucket: Has the capacity to hold a speciIied amount oI tokens. Each incoming
packet, iI Iorwarded, takes tokens Irom the bucket, representing the packet size. II the
bucket Iills to capacity, newly arriving tokens are discarded. Discarded tokens are not
available to Iuture packets. II there are not enough tokens in the token bucket to send the
packet, the traIIic conditioning mechanisms may:
Wait Ior enough tokens to accumulate in the bucket: traIIic shaping
Discard the packet: traIIic policing
Using a single token bucket model, the measured traIIic rate can be conIorming or exceeding
the speciIied traIIic rate. The measured traIIic rate is conIorming iI there are enough tokens in
the single token bucket to transmit the traIIic. The measured traIIic rate is exceeding iI there are
not enough tokens in the single token bucket to transmit the traIIic.
The Iigure shows a single token bucket traIIic-policing implementation. Starting with a current
capacity oI 700 bytes worth oI tokens accumulated in the token bucket, when a 500-byte packet
arrives at the interIace, its size is compared to the token bucket capacity (in bytes). The 500-
byte packet conIorms to the rate limit (500 bytes · 700 bytes), and the packet is Iorwarded: 500
bytes worth oI tokens are taken out oI the token bucket leaving 200 bytes worth oI tokens Ior
the next packet.
SingIe Token Bucket
· If sufficient tokens are avaiIabIe (conform action):
÷ Tokens equivaIent to the packet size are removed from the
bucket.
÷ The packet is transmitted.
Continuing on with the single token bucket example Irom the previous slide, when the next
300-byte packet arrives immediately aIter the Iirst packet, and no new tokens have been added
to the bucket (which is done periodically), the packet exceeds the rate limit. The current packet
size (300 bytes) is greater than the current capacity oI the token bucket (200 bytes), and the
exceed action is perIormed. The exceed action can be to drop or mark the packet when traIIic
policing.
ExampIe: Token Bucket as a Piggy Bank
Think oI a token bucket as a piggy bank. Every day you can insert a dollar into the piggy bank
(the token bucket). At any given time, you can only spend what you have saved up in the piggy
bank. On the average, iI your saving rate is a dollar per day, your long-term average spending
rate will be one dollar per day iI you constantly spend what you saved. However, iI you do not
spend any money on a given day, then you can build up your savings in the piggy bank up to
the maximum limit the piggy bank can hold. For example, iI the size oI the piggy bank is
limited to hold Iive dollars and iI you save and do not spend Ior Iive straight days, the piggy
bank will contain Iive dollars. When the piggy bank Iills to its capacity, you will not be able to
put any more money in it. Then at any time, you can spend up to Iive dollars (bursting above
the long-term average rate oI one dollar per day).
ConIorming rate using the piggy bank example means iI you have two dollars in the piggy bank
and you try to spend one dollar, then that is considered conIorming because you are not
spending more than what you have saved in the piggy bank.
Exceeding rate, using the piggy bank example, means that iI you have two dollars in the piggy
bank and you try to spend three dollars, it is considered exceeding because you are spending
more than what you have saved in the piggy bank.
SingIe Token Bucket (Cont.)
· If sufficient tokens are NOT avaiIabIe (exceed action):
÷ Drop (or mark) the packet
SingIe Token Bucket CIass-Based PoIicing
This topic explains how traIIic can be policed using a single token bucket scheme.
Token bucket operations rely on parameters such as: CIR, committed burst (Bc), and
committed time window (Tc). CIR is the committed inIormation rate. Bc is known as the
normal burst size. Tc is an interval constant that represents time. The mathematical relationship
between CIR, Bc, and Tc is:
CIR (bps) ÷ Bc (bits) / Tc (sec)
With traIIic policing, new tokens are added into the token bucket based on the inter-packet
arrival rate and the CIR. Every time a packet is policed, new tokens are added back into the
token bucket. The amount oI tokens added back into the token bucket is calculated as Iollows:
(Current Packet Arrival Time Previous Packet Arrival Time) * CIR
An amount (Bc) oI tokens is Iorwarded without constraint in every time interval (Tc). For
example, iI 8000 bits (Bc) worth oI tokens are placed in the bucket every 250 milliseconds
(Tc), the router can steadily transmit 8000 bits every 250 milliseconds iI traIIic constantly
arrives at the router.
CIR (normal burst rate) ÷ 8000 bits (Bc) / 0.25 seconds (Tc) ÷ 32 kbps
When conIiguring Cisco IOS class-based traIIic policing, it is recommended to allow the IOS
soItware to automatically calculate the optimal Bc and Tc value based on the conIigured CIR.
Without any excess bursting capability, iI the token bucket Iills to capacity (Bc oI tokens), the
token bucket will overIlow and newly arriving tokens are discarded. Using the example where
the CIR is 32 kbps (Bc ÷ 8000 bits and Tc ÷ 0.25 seconds), the maximum traIIic rate can never
exceed a hard rate limit oI 32 kbps.
SingIe Token Bucket CIass-Based
PoIicing
· B
c
is normaI burst size
· Tc is the time intervaI
· CIR is the committed information rate
· CIR = Bc/Tc
DuaI Token Bucket CIass-Based PoIicing
This topic explains how traIIic can be policed using a dual token bucket scheme.
Class-based traIIic policing can be conIigured to support excess bursting capability. With
excess bursting, aIter the Iirst token bucket is Iilled to Bc, extra (excess) tokens can be
accumulated in a second token bucket. Excess burst (Be) is known as the excess burst size. Be
is the maximum amount oI excess traIIic over and above Bc that can be sent during the time
interval a period oI inactivity.
With a single rate metering mechanism, the second token bucket with a maximum size oI Be
Iills at the same rate (CIR) as the Iirst token bucket. II the second token bucket Iills up to
capacity, then no more tokens can be accumulated and the excess tokens are discarded.
When using a dual token bucket model, instead oI a single token bucket, the measured traIIic
rate can be conIorming, exceeding or violating:
Conforming: There are enough tokens in the Iirst token bucket with a maximum size oI
Bc.
Exceeding: There are not enough tokens in the Iirst token bucket but there are enough
tokens in the second token bucket with a maximum size oI Be.
Violating: There are not enough tokens in the Iirst or second token bucket.
With dual token bucket traIIic policing, the typical actions perIormed can be:
Send all conIorm traIIic
Re-mark (to a lower priority)
Send all exceeding traIIic
Drop all violating traIIic
DuaI Token Bucket (SingIe Rate)
CIass-Based PoIicing
· Be: Excess burst size
· Tc: Tokens in Bc bucket
· Te: Tokens in Be bucket
· The return vaIue is conform or exceed or vioIate
The main beneIit oI using a dual token bucket method is the ability to distinguish between
traIIic that exceeds the Bc but not the Be. This enables a diIIerent policy to be applied to
packets in the Be category.
ReIerring to the piggy bank example, think oI the CIR as the savings rate (one dollar per day).
Bc is how much you can save into the piggy bank per day (one dollar). Tc is the interval at
which you put money into the piggy bank (one day). Be (Iive dollars) allows you to burst over
the average spending rate oI one dollar per day iI you are not spending a dollar per day.
Using a dual token bucket model allows traIIic exceeding the normal burst rate (CIR) to be
metered as exceeding and traIIic that exceeds the excess burst rate to be metered as violating
traIIic. DiIIerent actions then can be applied to the conIorming, exceeding, and violating traIIic.
DuaI Token Bucket (SingIe Rate)
CIass-Based PoIicing (Cont.)
· Traffic is conforming, exceeding, or vioIating
DuaI-Rate Token Bucket CIass-Based PoIicing
This topic explains how traIIic can be policed using a dual-rate metering scheme.
With dual-rate metering, traIIic rate can be enIorced according to two separate rates: CIR and
peak inIormation rate (PIR). BeIore this Ieature was available, you could meter traIIic using a
single rate based on the CIR with single or dual buckets. Dual-rate metering supports a higher
level oI bandwidth management and supports a sustained excess rate based on the PIR.
With dual-rate metering, the PIR token bucket Iills at a rate based on the packet arrival rate, and
the conIigured PIR and the CIR token bucket Iills at a rate based on the packet arrival rate and
the conIigured CIR.
When a packet arrives, the PIR token bucket is Iist checked to see iI there are enough tokens in
the PIR token bucket to send the packet. The violating condition occurs iI there are not enough
tokens in the PIR token bucket to transmit the packet. II there are enough tokens in the PIR
token bucket to send the packet, then the CIR token bucket is checked. The exceeding condition
occurs iI there are enough tokens in the PIR token bucket to transmit the packet but not enough
tokens in the CIR token bucket to transmit the packet. The conIorming condition occurs iI there
are enough tokens in the CIR bucket to transmit the packet.
Dual-rate metering is oIten conIigured on interIaces at the edge oI a network to police the rate
oI traIIic entering or leaving the network. In the most common conIigurations, traIIic that
conIorms is sent and traIIic that exceeds is sent with a decreased priority or is dropped. Users
can change these conIiguration options to suit their network needs.
DuaI-Rate CIass-Based PoIicing
· Tc: Tokens in CIR bucket
· Tp: Tokens in PIR bucket
· Enforce traffic poIicing according to two separate rates:
÷ Committed Information Rate (CIR)
÷ Peak Information Rate (PIR)
In addition to rate limiting, a traIIic policing using dual-rate metering allows marking oI traIIic
according to whether the packet conIorms, exceeds, or violates a speciIied rate.
The token bucket algorithm provides users with three diIIerent actions Ior each packet: a
conIorm action, an exceed action, and an optional violate action. TraIIic entering the interIace
with two-rate policing conIigured is placed into one oI these categories. Within these three
categories, users can decide packet treatments. For example, a user may conIigure a policing
policy as Iollows:
ConIorming packets are transmitted. Packets that exceed may be transmitted with a
decreased priority; packets that violate are dropped.
The violating condition occurs iI there are not enough tokens in the PIR bucket to transmit
the packet.
The exceeding condition occurs iI there are enough tokens in the PIR bucket to transmit the
packet but not enough tokens in the CIR bucket to transmit the packet. In this case, the
packet can be transmitted and the PIR bucket is updated to Tp B remaining tokens where
Tp is the size oI the PIR bucket and B is the size oI the packet to be transmitted.
The conIorming condition occurs iI there are enough tokens in the CIR bucket to transmit
the packet. In this case, the packets are transmitted and both buckets (Tc and Tp) are
decremented to Tp B and to Tc B, respectively, where Tc is the size oI the CIR bucket,
Tp is the size oI the PIR bucket, and B is the size oI the packet to be transmitted.
DuaI-Rate CIass-Based
PoIicing (Cont.)
Two-rate poIicer marks packets as either
conforming, exceeding, or vioIating a specified
rate.
· If (B > Tp), the packet is marked as vioIating the specified
rate; eIse
· If (B > Tc), the packet is marked as exceeding the
specified rate, and the Tp token bucket is updated as
Tp = Tp - B; eIse
· If the packet is marked as conforming to the specified
rate, and both token buckets (Tc and Tp) are updated as
Tp = Tp - B and Tc = Tc - B.
ExampIe: DuaI-Rate Token Bucket as a Piggy Bank
Using a dual-rate token bucket is like using two piggy banks and each with a diIIerent savings
rate. However, you can only take out money Irom one oI the piggy banks at a time.
For example, you can save ten dollars per day into the Iirst piggy bank (PIR ÷ peak spending
rate ÷ $10 per day) and then at the same time, you can save Iive dollars per day into the second
piggy bank (CIR ÷ normal average spending rate ÷ $5 per day). However, the maximum
amount you can spend is $10 per day, not $15 per day, because you can only take out money
Irom one piggy bank at a time.
In this example, aIter one day oI savings, your Iirst piggy bank (PIR bucket) will contain $10
and your second piggy bank (CIR bucket) will contain $5. The three diIIerent spending cases
are examined here to show how dual-rate metering operates using the piggy banks example:
Case 1: II you try to spend $11 at once, then you are violating (Tp·B), your peak-spending
rate oI $10 per day. In this case, you will not be allowed to spend the $11 because $11 is
greater than the $10 you have in the Iirst piggy bank (PIR bucket). Remember, you can
only take out money Irom one oI the piggy bank at a time.
Case 2: II you try to spend $9 at once, then you are exceeding (Tp~B~Tc), your normal
average spending rate oI $5 per day. In this case, you will be allowed to spend the $9 and
just the Iirst piggy bank (PIR bucket) will be decremented to $10 - $9 or $1.
AIter spending $9, the maximum amount you can continue to spend on that day is
decremented to $1.
Case 3: II you try to spend $4, then you are conIorming (Tp~B and Tc~B) to your normal
average spending rate oI $5 per day. In this case, you will be allowed to spend the $4, and
both piggy banks (PIR and CIR bucket) will be updated.
The Iirst piggy bank (PIR bucket) will be updated to $10 - $4 ÷ $6, and the second piggy bank
(CIR bucket) will be updated to $5 - $4 ÷ $1.
Both piggy banks are updated because aIter spending $4, the maximum amount you can
continue to spend on that day is decremented to $6, and the normal spending rate Ior that same
day is decremented to $1.
ThereIore, aIter spending $4, the Iollowing will occur:
II you continue to spend $7 on that same day, then you will be violating your peak-
spending rate Ior that day. In this case, you will not be allowed to spend the $7 because $7
is greater than the $6 you have in the Iirst piggy bank (PIR bucket).
II you continue to spend $5 on that same day, then you will be exceeding your normal
average spending rate Ior that day. In this case, you will be allowed to spend the $5 and just
the Iirst piggy bank (PIR bucket) will be decremented to $6 - $5, or $1.
II you continue to spend 50 cents on that same day, then you will be conIorming to your
normal average spending rate Ior that day. In this case, you will be allowed to spend the 50
cents, and both piggy banks (PIR and CIR bucket) will be updated. The Iirst piggy bank
(PIR bucket) will be updated to $6 $0.5 ÷ $5.5 and the second piggy bank (CIR bucket)
will be updated to $1 - $0.5 ÷ $0.5.
CIass-Based Traffic Shaping
This topic explains how traIIic can be shaped using a single token bucket scheme.
Cisco class-based traIIic shaping only applies Ior outbound traIIic.
Class-based traIIic shaping uses the basic token bucket mechanism where Bc oI tokens are
added at every Tc time interval. The maximum size oI the token bucket is Bc ¹ Be. You can
think oI the traIIic shaper operation like opening and closing oI a transmit gate at every Tc
interval. II the shaper gate is opened, the shaper checks to see iI there are enough tokens in the
token bucket to send the packet. II there are enough tokens, the packet is immediately
Iorwarded. II there are enough tokens, the packet is queued in the shaping queue until the
next Tc interval. II the gate is closed, the packet is queued behind other packets in the shaping
queue.
For example, on a 128-kbps link, iI the CIR is 96 kbps, the Bc is 12 kbps, the Be is 0, and the
Tc ÷ 0.125 seconds, then during each Tc (125 ms) interval, the traIIic shaper gate opens and up
to 12 Kb can be sent. To send 12 Kb over a 128-kbps line, it will only take 91.25 ms.
ThereIore, this means the router will on the average be sending at three-quarters oI the line rate
(128 kbps * / ÷ 96 kbps).
TraIIic shaping also includes the ability to send more than Bc oI traIIic in some time intervals
aIter a period oI inactivity. This extra number oI bits in excess to the Bc is called Be.
CIass-Based Traffic Shaping
Cisco IOS Traffic PoIicing and Shaping
Mechanisms
This topic identiIies the key traIIic policing and shaping mechanisms available in Cisco IOS
soItware and diIIerentiates between them.
This Iigure lists the characteristics oI the class-based traIIic-policing mechanism that is
available in Cisco IOS soItware. Class-based policing is also available on some Cisco Catalyst
switches.
Class-based policing supports a single or dual token bucket. Class-based policing also supports
single-rate or dual-rate metering and multiactions policing. Multiactions policing allows more
than one action to be applied; Ior example marking the Frame Relay DE bit and also the DSCP
value beIore sending the exceeding traIIic.
Class-based policing is conIigured using Modular QoS command-line interIace (CLI) (MQC)
with the 'police¨ command under the policy map.
Cisco IOS Traffic-PoIicing
Mechanisms
This Iigure lists some oI the diIIerent traIIic-shaping mechanisms available in Cisco IOS
soItware, the newer class-based traIIic shaping, distributed traIIic shaping (DTS), and FRTS.
Class-based traIIic shaping uses MQC to allow traIIic to be shaped per traIIic class as deIined
by the class map. Class-based traIIic shaping can be used in combinations with class-based
weighted Iair queuing (CBWFQ), where the shaped rate is used to deIine an upper rate limit
while the bandwidth statement within the CBWFQ conIiguration is used to deIine a minimum
rate limit.
DTS is a Ieature that is speciIic to the higher-end platIorms such as the Cisco 7500 or the Cisco
12000 series routers. These platIorms have the ability to oIIload traIIic shaping Irom the main
processor to the individual interIace processors (Versatile InterIace Processor |VIP| or line
card). In networks where distributed Cisco Express Forwarding (dCEF) is the preIerred mode
oI switching, DTS on the VIP or line card is the logical choice Ior implementing traIIic
shaping.
FRTS is used to shape Frame Relay traIIic only. FRTS allows individual PVC (data-link
connection identiIier |DLCI|) to be shaped. FRTS can use priority queuing (PQ), custom
queuing (CQ) or weighted Iair queuing (WFQ) as the shaping queue and only supports WFQ as
the soItware queue.
Both DTS and FRTS support FRF.12 Frame Relay Iragmentation while class-based shaping
does not support FRF.12 Iragmentation Ior Frame Relay.
All these traIIic-shaping mechanisms can interact with a Frame Relay network, adapting to
indications oI Layer 2 congestion in the WAN. For example, iI the BECN bit is received, the
router can lower the rate limit to help reduce congestion in the Frame Relay network. And iI the
Iorward explicit congestion notiIication (FECN) bit is received, the router can generate a test
Irame with the BECN bit set. This enables the sender to notice congestion even iI there is no
data traIIic Ilowing back Irom the receiver to the sender.
Only class-based shaping conIigurations will be discussed in this module.
Cisco IOS Traffic-Shaping
Mechanisms
AppIying Traffic Conditioners
This topic identiIies the points in a network where rate-limiting can most eIIectively be
employed.
In a typical enterprise network, traIIic policing is oIten implemented at the access or
distribution layer to limit certain traIIic classes beIore that traIIic exits the campus onto the
WAN. TraIIic shaping is oIten implemented at the WAN edge when there are speed
mismatches or over-subscription.
In a typical service provider network, traIIic policing is oIten implemented inbound at the PE
(provider edge) router to rate-limit incoming traIIic Irom the CE (customer edge) router to
ensure the customer traIIic rate is not exceeding the contractual rate. TraIIic shaping is oIten
implemented outbound at the PE and at the CE to limit the traIIic rate between the PE and CE
and to allow Ior FRF.12 Iragmentation on Frame Relay connections between the CE and PE.
AppIying Rate Limiting
Summary
References
To learn more about traIIic policing and traIIic shaping, reIer to 'Part 4: Policing and
Shaping¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios123/123cgcr/qos¸vcg.htm#1
001018
For inIormation on other traIIic shaping mechanisms, reIer to the soItware conIiguration
documentation Ior your Cisco IOS soItware release.
Summary
· Traffic shaping and poIicing mechanisms are used to Iimit
traffic rate.
· Traffic shaping queues excess packets to stay within the
contractuaI rate.
· Traffic poIicing typicaIIy drops excess traffic to stay within
the Iimit; aIternativeIy it can re-mark then send excess
traffic.
· Traffic rate is metered using a token bucket mathematicaI
modeI.
· CIass-based poIicing is the Iatest Cisco IOS traffic-poIicing
mechanism.
· CIass-based shaping, DTS, and FTRS are three Cisco IOS
traffic-shaping mechanisms.
Quiz
Q1) Which two are common to both traIIic policing and traIIic shaping? (Choose two.)
A) both use token bucket to meter traIIic
B) both use a queue to delay excess traIIic
C) both use traIIic classiIication to diIIerentiate traIIic
D) both drop all excess traIIic
Q2) TraIIic policing can be implemented in which directions?
A) TraIIic policing can be implemented in both the inbound and outbound
directions.
B) TraIIic policing can be implemented in the inbound direction only.
C) TraIIic policing can be implemented in the outbound direction only.
D) TraIIic policing can be applied in the inbound direction Ior rate-limiting and in
the outbound direction Ior marking purposes only.
Q3) TraIIic shaping can be implemented in which directions?
A) TraIIic shaping can be implemented in both the inbound and outbound
directions.
B) TraIIic shaping can be implemented in the inbound direction only.
C) TraIIic shaping can be implemented in the outbound direction only.
D) TraIIic shaping can be implemented in the outbound direction Ior rate-limiting
and the inbound direction Ior marking purposes only.
Q4) What are the three possible conditions Ior the metered traIIic when using dual token
bucket policing? (Choose three.)
A) accept
B) conIorm
C) non-conIirm
D) obey
E) exceed
F) violate
Q5) What is the mathematical Iormula between CIR, Bc, and Tc?
A) Tc ÷ CIR * Bc
B) Tc ÷ CIR / Bc
C) Bc ÷ CIR / Tc
D) CIR ÷ Bc / Tc
Q6) What is the main advantage oI using a dual token bucket versus a single token bucket
when implementing class-based policing?
A) the ability to burst above the Be
B) the ability to distinguish exceeding traIIic that exceeds the normal burst rate
versus the violating traIIic that exceeds the excess burst rate and diIIerent
actions then can be applied to the exceeding and violating traIIic
C) the ability to speciIy a maximum token bucket size greater than Bc
D) the ability to queue the excess traIIic in the second token bucket to reduce
packet drops
Q7) Correctly identiIy each Cisco IOS traIIic shaping and traIIic-policing mechanism by
matching it to the correct term below.
1. traIIic shaping
2. traIIic policing
3. neither
A) WRED ¸¸¸¸¸¸¸¸¸¸
B) CB-Shaping ¸¸¸¸¸¸¸¸¸¸
C) DTS ¸¸¸¸¸¸¸¸¸¸
D) WFQ ¸¸¸¸¸¸¸¸¸¸
E) FRTS ¸¸¸¸¸¸¸¸¸¸
F) LLQ ¸¸¸¸¸¸¸¸¸¸
G) CB-Policing ¸¸¸¸¸¸¸¸¸¸
H) RED ¸¸¸¸¸¸¸¸¸¸
I) PBR ¸¸¸¸¸¸¸¸¸¸
Quiz Answer Key
Q1) A, C
ReIates to: Traffic Policing and Shaping Overview
Q2) A
Q3) C
Q4) B, E, F
ReIates to: Measuring Traffic Rates
Q5) D
ReIates to: Single Token Bucket Class-Based Policing
Q6) B
ReIates to: Dual Token Bucket Class-Based Policing
Q7) A ÷ 3
B ÷ 1
C ÷ 1
D ÷ 3
E ÷ 1
F ÷ 3
G ÷ 2
H ÷ 3
I ÷ 3
ReIates to: Cisco ÌOS Traffic Policing and Shaping Mechanisms
Policing
Overview
Cisco IOS soItware supports two diIIerent traIIic-policing mechanisms: CAR and class-based
policing. CAR is an older Cisco traIIic policing Ieature and class-based policing is a newer
Cisco traIIic-policing mechanism based on the MQC. Cisco recommends using MQC Ieatures
when possible to implement QoS in the network. TraIIic policing conIigurations using CAR,
Ior which no new Ieatures or Iunctionality is planned, should be avoided. However, Cisco will
continue to support CAR Ior existing implementations.
This lesson describes the tasks to conIigure the diIIerent options that are used to implement
class-based traIIic policing to rate-limit certain traIIic classes.
ReIevance
TraIIic policing is a valuable QoS tool to limit the rate at which traIIic enters or exits an
interIace on a Cisco router or switch. TraIIic policing using class-based policing is the preIerred
method oI conIiguring policing.
Objectives
Upon completing this lesson, you will be able to conIigure class-based policing to rate-limit
traIIic. This includes being able to meet these objectives:
Explain the key Ieatures oI class-based policing
IdentiIy the Cisco IOS commands required to conIigure single-rate class-based policing
IdentiIy the Cisco IOS commands required to conIigure dual-rate class-based policing
IdentiIy the Cisco IOS commands required to conIigure percentage-based class-based
policing
IdentiIy the Cisco IOS commands used to monitor class-based policing
Knowledge oI using MQC to implement Cisco QoS mechanisms
Knowledge oI how to conIigure class maps to classiIy traIIic
Knowledge oI how traIIic is metered using a token bucket
Knowledge oI the operation oI a single token bucket versus a dual token bucket
OutIine
OutIine
· Overview
· CIass-Based PoIicing Overview
· Configuring SingIe-Rate CIass-Based PoIicing
· Configuring DuaI-Rate CIass-Based PoIicing
· Configuring Percentage-Based CIass-Based PoIicing
· Monitoring CIass-Based PoIicing
· Summary
· Quiz
CIass-Based PoIicing Overview
This topic explains the key Ieatures oI class-based policing.
The class-based policing Ieature perIorms the Iollowing Iunctions:
Limits the input or output transmission rate oI a class oI traIIic based on user-deIined
criteria
Marks packets by setting diIIerent Layer 2 or Layer 3 markers or both.
Class-based policing can be implemented using a single or double token bucket method as the
metering mechanism. The single token bucket algorithm is used when the violate action option
is not speciIied in the police MQC command.
The dual token bucket algorithm is used when the violate action option is speciIied in the police
MQC command.
Using a dual token bucket, traIIic can:
ConIorm to the rate limit when it is within the average bit rate
Exceed the rate limit when it exceeds the average bit rate, but does not exceed the allowed
excess burst
Violate the rate limit when it exceeds both the average rate and the excess bursts
CIass-Based PoIicing Overview
· CIass-based poIicing is used to rate-Iimit a traffic cIass to
a configured bit rate.
· CIass-based poIicing can drop or re-mark and transmit
exceeding traffic.
· CIass-based poIicing can be impIemented using a singIe
or duaI token bucket scheme.
· CIass-based poIicing supports muItiactions poIicing:
÷ AppIying two or more set parameters as a conform or exceed or
vioIate action
· CIass-based poIicing conforms to two RFCs:
÷ RFC 2697, "A SingIe Rate Three CoIor Marker"
÷ RFC 2698, "A DuaI Rate Three CoIor Marker"
· CIass-based poIicing is configured using the MQC
method.
Based on the current packet conIorming, exceeding, or violating the rate limit, one or more
actions can be taken by class-based policing as Iollows:
Transmit: The packet is transmitted.
Drop: The packet is dropped.
Set precedence (or DSCP value) and transmit: The IP precedence (type oI service
|ToS|) or DSCP bits in the packet header are rewritten. The packet is then transmitted. This
action can be used to either color (set precedence) or recolor (modiIy existing packet
precedence) the packet.
Set QoS group and transmit: The QoS group can be set and the packet Iorwarded.
Because QoS group is only locally signiIicant within the router (that is, it is not transmitted
outside the router), the QoS group setting is used in later QoS mechanisms and perIormed
in the same router, such as CBWFQ, on an outgoing interIace.
Set MPLS experimental bits and transmit: The Multiprotocol Label Switching (MPLS)
experimental bits can be set. The packet is then transmitted. These are usually used to
signal QoS parameters in a MPLS cloud.
Set Frame Relay DE bit and transmit: The Frame Relay DE bit is set in the Layer 2
(Frame Relay) header and the packet is transmitted. This setting can be used to mark
excessive or violating traIIic (which should be dropped with preIerence on Layer 2
switches) at the edge oI a Frame Relay network.
Set ATM cell loss priority (CLP) bit and transmit: The ATM CLP bit is set in the Layer
2 (ATM) header and the packet is transmitted. This setting can be used to mark excessive
or violating traIIic (which should be dropped with preIerence on Layer 2 switches) at the
edge oI an ATM network.
Multiaction policing is a mechanism that can apply more than one action to a packet; Ior
example, setting the DSCP as well as the CLP bit on the exceeding packets.
Class-based policing also supports single- or dual-rate metering. With the two-rate policer,
traIIic policing can be enIorced according to two separate rates: CIR and PIR. You can speciIy
the use oI these two rates, along with their corresponding values, by using two keywords, cir
and pir, oI the police command.
Cisco class-based policing mechanism conIorms to the two Iollowing RFCs:
RFC 2697, A Single Rate Three Color Marker: The Single Rate Three Color Marker
meters an IP packet stream and marks its packets green (conIorm), yellow (exceed), or red
(violate). Marking is based on a CIR) and two associated burst sizes, a Bc size and a Be
size. A packet is marked green iI it does not exceed the Bc, yellow iI it does exceed the Bc,
but not the Be, and red otherwise.
RFC 2698, A Two Rate Three Color Marker: The Two Rate Three Color Marker meters
an IP packet stream and marks its packets either green (conIorm), yellow (exceed), or red
(violate). A packet is marked red iI it exceeds the PIR. Otherwise it is marked either yellow
or green, depending on whether it exceeds or does not exceed the CIR. This is useIul, Ior
example, Ior ingress policing oI a service where a peak rate needs to be enIorced separately
Irom a committed rate.
Configuring SingIe-Rate CIass-Based PoIicing
This topic identiIies the Cisco IOS commands that are required to conIigure single-rate class-
based policing.
The MQC-based police command deIines policing parameters Ior a speciIic traIIic class. The
avg-rate parameter deIines the policed average traIIic rate (CIR); Bc and Be deIine the token
bucket sizes in bytes; and the action deIines an action Ior conIorming, exceeding, and
optionally violating traIIic.
II Bc (in bytes) is not speciIied, it will deIault to the avg-rate (CIR)/32 or 1500 bytes,
whichever is higher. When using the Iormula CIR/32 to calculate the deIault Bc (in bytes),
Cisco IOS soItware uses a Tc oI 0.25 second where:
Bc (in bytes) ÷ (CIR x Tc) / 8
Bc (in bytes) ÷ (CIR x 0.25 seconds) / 8 ÷ CIR / 32
II Be (in bytes) is not speciIied, it will deIault to Bc. In a single token bucket case, Cisco IOS
soItware ignores the Be value. This means excess bursting is disabled.
The Be rate can be speciIied when a violate action is conIigured, thereIore using a dual token
bucket. This allows Be to be explicitly conIigured instead oI using the deIault value oI Be÷Bc.
Be speciIies the size oI the second (excess) token bucket.
Dual token bucket policing with the violate action was introduced in Cisco IOS 12.1(5)T.
Configuring SingIe-Rate CIass-Based
PoIicing
police avg~rate (B
C
(B
F
)) (conform~action action)
(exceed~action action) (violate~action action)
police avg~rate (B
C
(B
F
)) (conform~action action)
(exceed~action action) (violate~action action)
·avg-rate: traffic rate in bps (8,000 to 200,000,000)
·B
C
: normaI burst sets the size in bytes
÷defauIt is 1500 or CIR/32; whatever is higher
·B
E
: excess burst sets the size in bytes
÷defauIt is B
C
·action:
÷transmit (defauIt conform action)
÷drop (defauIt exceed and vioIate action)
÷set-prec-transmit ip-precedence
÷set-dscp-transmit dscp
÷set-qos-transmit qos-group
÷set-mpIs-exp-transmit mpIe-exp
÷set frde-transmit
÷set-cIp-transmit
This class-based policing conIiguration example shows two conIigured traIIic classes based on
upstream MAC addresses. TraIIic Irom the particular web server, which is classiIied by its
MAC address, is policed to a Iixed bandwidth with no excess burst capability using a single
token bucket. ConIorming traIIic will be sent as-is and exceeding traIIic is dropped. In this
case, the www.123.com Web server is policed to a rate oI 512 kbps and the www.456.com Web
server is policed to a rate oI 256 kbps.
Because the violate action is not speciIied, this will use a single token bucket scheme and no
excess bursting is allowed.
In this example, the normal burst size (Bc) is not speciIied, and thereIore it will deIault to the
512000/32 (16000 bytes) and 256000/32 (8000 bytes), respectively.
The deIault Bc setting can be examined by showing the policy map. Notice that the Be is not
displayed because no excess bursting is allowed using a single token bucket with class-based
policing:
router=show policy-map ServerFarm
Policy Map ServerFarm
Class www.I?·.com
police cir 512000 bc 16000
conform-action transmit
exceed-action drop
Class www.4S8.com
exceed-action drop
CIass-Based PoIicing ExampIe:
SingIe Rate, SingIe Token Bucket
ExampIe: SingIe Rate, DuaI Token Bucket CIass-Based PoIicing
This class-based policing conIiguration example shows two conIigured traIIic classes based on
upstream MAC addresses. TraIIic Irom the particular web server, which is classiIied by its
MAC address, is policed to a Iixed bandwidth with excess burst capability using a dual token
bucket by conIiguring a violate action. ConIorming traIIic will be sent as-is, exceeding traIIic
will be marked to IP precedence 3 and transmitted, and all violating traIIic will be dropped.
In this example because the violate action is speciIied, this will use a dual token bucket scheme
with excess bursting. The normal burst size (Bc) is not speciIied, and thereIore it will deIault to
the 512000/32 (16000 bytes) and 256000/32 (8000 bytes), respectively. The excess burst size
(Be) is also not speciIied, and thereIore it will deIault to Bc.
The deIault Bc and Be settings can be examined by showing the policy map:
router=show policy-map ServerFarm
Policy Map ServerFarm
Class www.I?·.com
police cir 512000 bc 16000 be 16000
exceed-action set-prec-transmit ·
violate-action drop
Class www.4S8.com
police cir 256000 bc 8000 be 8000
violate-action drop
SingIe Rate, DuaI Token Bucket
ExampIe: MuItiactions CIass-Based PoIicing
This class-based policing conIiguration is an example oI a multiactions class-based policing. In
this case, all Kazaa2 traIIic is policed to 56 kbps. All conIorming traIIic will be marked with a
DSCP value oI 8, and then transmitted. All exceeding traIIic will be marked with a DSCP value
oI 0, and the CLP bit in the ATM header will also be set beIore it is transmitted. All violating
traIIic will be dropped.
The multiactions Ieature was introduced in Cisco IOS 12.2(8)T and is primarily used so that
class-based policing can mark at Layer 2 and also at Layer 3 at the same time.
MuItiactions CIass-Based PoIicing
· AvaiIabIe in Cisco IOS
12.2(8)T
· MainIy Used for Setting
Layer 2 and Layer 3
QoS FieIds
Configuring DuaI-Rate CIass-Based PoIicing
This topic identiIies the Cisco IOS commands that are required to conIigure dual-rate class-
based policing.
Dual-rate class-based policing was introduced in Cisco IOS 12.2(4)T. With dual-rate policing,
traIIic policing can be enIorced according to two separate rates: CIR and PIR. The use oI these
two rates can be speciIied, along with their corresponding values, by using two keywords, cir
and pir, oI the police command. The Bc and Be keywords and their associated arguments
(conIorm-burst and peak-burst, respectively) are optional. II Bc is not speciIied, Bc (in bytes)
will deIault to CIR/32 or 1500 bytes, whichever is higher. II Be is not speciIied, Be (in bytes)
will deIault to PIR/32 or 1500 bytes, whichever is higher.
Configuring DuaI-Rate CIass-Based
PoIicing
police ¦cir cir} (bc conform~burst) ¦pir pir} (be
peak~burst) (conform~action action) (exceed~action
action) (violate~action action)
police ¦cir cir} (bc conform~burst) ¦pir pir} (be
peak~burst) (conform~action action) (exceed~action
action) (violate~action action)
· Specifies both the CIR and the PIR for two-rate traffic
poIicing
· CIR: Committed Information Rate (bps)
· PIR: Peak Information Rate (bps)
· The bc and be keywords and their associated arguments
(conform-burst and peak-burst, respectiveIy) are optionaI
· AvaiIabIe in Cisco IOS ReIease 12.2(4)T
ExampIe: DuaI-Rate CIass-Based PoIicing
In this example, the two-rate policer is conIigured on the 'http¨ traIIic class to limit http traIIic
to an average committed rate oI 500 kbps and a peak rate oI 1 Mbps. ConIorming traIIic will be
sent as-is, traIIic exceeding 500 kbps (but not exceeding 1 Mbps) will be marked with IP
precedence 3 and then sent, and all traIIic exceeding 1 Mbps will be dropped.
Because the Bc and Be is not speciIied, the deIault Bc in bytes will be CIR/32 (Tc ÷ 0.25
seconds) or 1500 bytes, whichever is higher. The deIault Be in bytes will be PIR/32 (Tc ÷ 0.25
seconds) or 1500 bytes, whichever is higher.
In this example, the deIault Bc ÷ 500000/32 ÷ 15625 bytes and the deIault Be ÷ 1000000/32 ÷
31250 bytes.
The show policy-map command can be used to display the deIault settings oI the Bc and Be
parameters:
Router =show policy-map police-http
Policy Map police-http
Class silver
police cir 500000 bc 15625 pir 1000000 be 31250
violate-action drop
DuaI Rate CIass-Based PoIicing
Configuring Percentage-Based CIass-Based
PoIicing
This topic identiIies the Cisco IOS commands that are required to conIigure percentage-based
class-based policing.
The percent policing Ieature was introduced in Cisco IOS 12.2(13)T. BeIore this Ieature, traIIic
policing was conIigured on the basis oI a user-speciIied amount oI bandwidth available on the
interIace. Policy maps were then conIigured on the basis oI that speciIic amount oI bandwidth,
meaning that separate policy maps were required Ior each interIace with diIIerent bandwidth.
This Ieature provides the ability to conIigure traIIic policing based on a percentage oI
bandwidth available on the interIace. ConIiguring traIIic policing and traIIic shaping in this
manner enables customers to use the same policy map Ior multiple interIaces with diIIering
amounts oI bandwidth.
ConIiguring traIIic policing based on a percentage oI bandwidth is accomplished by using the
police (percent) command.
This Ieature also provides the option oI speciIying burst sizes in ms instead oI in bytes when
conIiguring traIIic policing based on a percentage oI bandwidth.
In this dual-rate percentage-based policing example, the bulk-Itp traIIic class is policed to a
CIR oI 20 percent and a PIR oI 40 percent oI the interIace bandwidth.
Since Bc and Be are not speciIied, the deIault Bc in bytes will be CIR/32 or 1500 bytes,
whichever is higher. The deIault Be in bytes will be PIR/32 or 1500 bytes, whichever is higher.
Configuring Percentage-Based
CIass-Based PoIicing
police cir percent percent (bc conform~burst~in~msec) (pir
percent percent) (be peak~burst~in~msec) (conform~action
action) (exceed~action action) (violate~action action)
police cir percent percent (bc conform~burst~in~msec) (pir
percent percent) (be peak~burst~in~msec) (conform~action
action) (exceed~action action) (violate~action action)
· EnabIes the same poIicy map for muItipIe interfaces with
different bandwidth
· AvaiIabIe in Cisco IOS ReIease 12.2(13)T
policy~map police1
class bulk~ftp
police cir percent 20 pir percent 40
conform~action set~dscp~transmit af11 exceed~action set~dscp~transmit 0
violate~action drop
!
interface Fthernet 0/0
service~policy input police1
!
interface Serial 0/0
service~policy input police1
ExampIe: Configuring Percentage-Based CIass-Based PoIicing
In the example, the CIR is 20 percent and the PIR is 40 percent (with no Bc and Be speciIied)
and the policy is applied to an Ethernet (10 Mbps) interIace. The CIR and PIR in bps Ior the
Ethernet interIace is computed as:
CIR ÷ 10 Mbps * 0.20 ÷ 2 Mbps
PIR ÷ 10 Mbps * 0.40 ÷ 4 Mbps
The deIault values oI the Bc and Be parameters will automatically set to:
Bc ÷ 2 Mbps/32 ÷ 62500 bytes
Be ÷ 4 Mbps/32 ÷ 125000 bytes
Monitoring CIass-Based PoIicing
This topic identiIies the Cisco IOS commands that are used to monitor class-based policing.
The show policy-map interface command is used to examine the policy map that is being
applied to an interIace.
This show output displays the percent-based policing policy map example shown on the
previous slide.
This show output displays the actual Cisco IOS soItware calculated value oI CIR and PIR in
bps and the Bc and Be values in bytes, based on the interIace bandwidth and the percentage
conIigurations.
Monitoring CIass-Based PoIicing
router#show policy interface Fthernet 0/0
Fthernet0/0
Service~policy input: police1
Class~map: bulk~ftp (match~all)
0 packets, 0 bytes
Match: protocol ftp
police:
cir 20 %
cir 2000000 bps, bc 62500 bytes
pir 40 %
pir 4000000 bps, be 125000 bytes
conformed 0 packets, 0 bytes; actions:
set~dscp~transmit cs1
exceeded 0 packets, 0 bytes; actions:
set~dscp~transmit default
violated 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps
...
Summary
References
To learn more about conIiguring class-based policing, reIer to 'ConIiguring TraIIic
Policing¨ at the Iollowing URL:
qcIpoli.htm
To learn more about metering in class-based policing, reIer to 'RFC 2697: A Single Rate
Three Color Marker¨ at the Iollowing URL: http://www.Iaqs.org/rIcs/rIc2697.html
To learn more about metering in class-based policing, reIer to 'RFC 2698: A Two Rate
Three Color Marker¨ at the Iollowing URL: http://www.Iaqs.org/rIcs/rIc2698.html
Next Steps
Lab Exercise 7-1: ConIiguring Class-Based Policing
Summary
· CIass-based poIicing is configured using the MQC
method and is used to rate-Iimit traffic cIass to a
configured bit rate.
· CIass-based poIicing can use a singIe or duaI token
bucket metering scheme. If a vioIate action is configured,
then a duaI token bucket wiII be used.
· CIass-based poIicing supports singIe- or duaI-rate
metering. DuaI-rate metering aIIows metering of traffic
based on two rates (the PIR and the CIR).
· CIass-based poIicing supports singIe or muItiactions.
MuItiactions aIIows the marking of Layer 2 and Layer 3
information at the same time.
· Cisco IOS software can automaticaIIy caIcuIate an
optimaI vaIue of Bc and Be based on the configured
poIiced rate.
Quiz
Q1) Which parameter in the police MQC command will enable the use oI a dual token
bucket?
A) Be
B) Bc
C) Exceed action
D) Violate action
Q2) What is the deIault value oI Be iI the Be parameter is not speciIied in the police MQC
command when conIiguring single-rate, dual token bucket policing?
A) The excess burst rate (Be) will deIault equal to Bc.
B) The excess burst rate (Be) will deIault equal to 0.
C) The excess burst rate (Be) will deIault equal to 1500 bytes.
D) The excess burst rate (Be) will deIault equal to 8000 bytes.
Q3) What is the beneIit oI using multiaction policing?
A) allows policing to deIine diIIerent conIorming, exceeding, and violating
actions
B) to allow the use oI dual token buckets to distinguish between exceeding and
violating traIIic
C) allows policing to mark at Layer 2 and also at Layer 3 at the same time
D) allows policing to rate-limit traIIic using two rates (PIR and CIR)
Q4) Given the Iollowing police command, what will be the deIault values oI the Bc?
police cir ?S0000 pir S00000
A) 1500 bytes
B) 7812 bytes
C) 15655 bytes
D) 31250 bytes
Q5) Which oI the Iollowing statements is true regarding dual-rate class-based policing?
A) One token bucket Iills at the PIR and has a maximum size oI Be. The other
token bucket Iills at the CIR and has a maximum size oI Bc.
B) Both token buckets Iill at a rate equal to CIR.
C) Both token buckets Iill at a rate equal to PIR.
D) The PIR will deIault to the CIR iI the PIR is not speciIied in the police
command.
E) The PIR will deIault to the CIR * 2 iI the PIR is not speciIied in the police
command.
Q6) II the same class-based policing conIiguration is implemented on diIIerent interIaces
with diIIering amounts oI bandwidth, which class-based conIiguration should be used?
A) dual-rate class-based policing
B) dual token bucket class-based policing
C) multiactions class-based policing
D) percentage-based class-based policing
Quiz Answer Key
Q1) D
ReIates to: Configuring Single-Rate Class-Based Policing
Q2) A
Q3) C
Q4) B
ReIates to: Configuring Dual-Rate Class-Based Policing
Q5) A
ReIates to: Configuring Dual-Rate Class-Based Policing
Q6) D
ReIates to: Configuring Percentage-Based Class-Based Policing
Shaping
Overview
TraIIic shaping allows network administrators to control outgoing traIIic on an interIace to
match the speed oI transmission to the speed oI the remote interIace, and to ensure that the
traIIic conIorms to administrative QoS policies. TraIIic adhering to a particular proIile can be
shaped to meet downstream requirements, thereby eliminating bottlenecks in topologies with
data-rate mismatches.
This lesson describes the tasks to conIigure class-based traIIic shaping to rate-limit certain
traIIic classes.
ReIevance
The primary reasons to use traIIic shaping are to control access to available bandwidth, to
ensure that traIIic conIorms to the policies established Ior it, and to regulate the Ilow oI traIIic
so that you can avoid congestion that can occur when the sent traIIic exceeds the access speed
oI its remote, target interIace. TraIIic shaping is especially important in Frame Relay networks
because Frame Relay switches cannot determine which Irames take precedence, and thereIore
which Irames should be dropped when congestion occurs.
Objectives
Upon completing this lesson, you will be able to conIigure class-based shaping to rate-limit
traIIic. This includes being able to meet these objectives:
Explain the key Ieatures oI class-based shaping
Explain how the two rate limitsaverage rate and peak ratecan be used to rate-limit
traIIic
IdentiIy the Cisco IOS commands required to conIigure class-based shaping
IdentiIy the Cisco IOS commands used to monitor class-based shaping
Knowledge oI the MQC conIiguration method to implement Cisco QoS mechanisms
Knowledge oI how to conIigure class maps to classiIy traIIic
Knowledge oI how to conIigure CBWFQ
Knowledge oI how traIIic is metered using a token bucket
OutIine
OutIine
· Overview
· CIass-Based Shaping Overview
· Traffic Shaping Methods
· Configuring CIass-Based Shaping
· Monitoring CIass-Based Shaping
· Summary
· Quiz
CIass-Based Shaping Overview
This topic explains the key Ieatures oI class-based shaping.
TraIIic shaping allows you to control the traIIic going out an interIace to match its transmission
to the speed oI the remote, target interIace or to ensure that the traIIic conIorms to policies
contracted Ior it. TraIIic adhering to a particular proIile can be shaped to meet downstream
requirements, thereby eliminating bottlenecks in topologies with traIIic-rate mismatches or
over-subscriptions. Class-based shaping has these properties:
Class-based shaping is conIigured via MQC.
Class-based shaping has no packet-marking capability.
Class-based shaping works by queuing excessive packets until they conIorm to the
conIigured shaped rate.
Class-based shaping can also be used within the CBWFQ queuing system.
When operating within CBWFQ, the shaped rate provides an upper bandwidth limit
while the bandwidth statement within CBWFQ provides a minimum bandwidth
guarantee.
CIass-Based Shaping Overview
· CIass-based shaping is used to rate-Iimit packets.
· CIass-based shaping deIays exceeding packets rather
then dropping them.
· CIass-based shaping has no marking capabiIities.
· CIass-based shaping is a version of GTS using MQC.
Traffic Shaping Methods
This topic explains how the two rate limitsaverage rate and peak ratecan be used to rate-
limit traIIic.
Class-based shaping can be conIigured in two diIIerent ways:
Shaping to the average rate, which Iorwards up to Bc oI traIIic at every Tc time interval
with additional bursting capability when enough tokens are accumulated in the bucket. Bc
oI tokens are added to the token bucket at every Tc time interval. AIter the token bucket is
drained, additional bursting cannot occur until tokens are allowed to accumulate, which can
occur only during periods oI silence or when transmit rate is lower than average rate. AIter
a period oI low traIIic activity, up to Bc ¹ Be oI traIIic can be sent.
Shaping to the peak rate, which Iorwards up to Bc ¹ Be oI traIIic at every Tc time interval.
Bc ¹ Be oI tokens are added to the token bucket at every Tc time interval. Shaping to the
peak rate sends traIIic at the peak rate, which is deIined as the average rate multiplied by
(1 ¹ Be/Bc). Sending packets at the peak rate may result in dropping in the WAN cloud
during network congestion. Shaping to the peak rate is only recommended when the
network has additional available bandwidth beyond the CIR and applications can tolerate
occasional packet drops.
Average rate shaping is the more common approach being deployed.
Traffic Shaping Methods
· CIass-based shaping has two shaping methods:
÷ Shaping to the configured average rate
÷ Shaping to the peak rate
· Average rate is forwarding packets at the configured
average rate with aIIowed bursting up to Be when there
are extra tokens avaiIabIe. This is the more common
method used.
· Peak rate is forwarding packets at the peak rate of up to
Bc + Be of traffic at every Tc. However, traffic sent above
the CIR may be dropped during network congestion. Peak
rate shaping recommended when:
÷ Network has additionaI bandwidth avaiIabIe
÷ AppIication toIerates occasionaI packet Ioss
Configuring CIass-Based Shaping
This topic identiIies the Cisco IOS commands that are required to conIigure class-based
shaping.
The shape average and shape peak commands conIigure average and peak shaping,
respectively. The Bc and Be value in bits can be explicitly conIigured or Cisco IOS soItware
can automatically calculate the optimal value Ior Bc and Be. It is recommended not to
conIigure the Bc and Be and let the Cisco IOS algorithm determine the best Bc and Be value to
use. Class-based traIIic shaping uses a single token bucket with a maximum token bucket size
oI Bc ¹ Be.
The shape percent command is oIten used in conjunction with the bandwidth and priority
commands. The bandwidth and priority commands can be used to calculate the total amount
oI bandwidth available on an entity (Ior example, a physical interIace). When the bandwidth
and priority commands calculate the total amount oI bandwidth available on an entity, the total
bandwidth is the bandwidth on the physical interIace.
The shape max-buffers command (not shown) speciIies the maximum size oI the shaping
queue. The shaping queue will queue excess packets until they conIorm to the shaping rate. II
the shaping queue is Iull, packets are tail-dropped. The deIault max-buIIer size is 1000 packets
and is usually not changed.
Configuring CIass-Based Shaping
shape ¦average | peak} average~bit~rate (Bc) (Be) shape ¦average | peak} average~bit~rate (Bc) (Be)
· Recommended that Bc and Be be omitted to Iet Cisco IOS
software seIect the optimaI vaIues for these variabIes.
shape ¦average | peak} percent (Bc) (Be) shape ¦average | peak} percent (Bc) (Be)
· Specifies the bandwidth percentage. VaIid range is a number
from 1 to 100.
· Recommended that Bc and Be be omitted to Iet Cisco IOS
software seIect the optimaI vaIues for these variabIes.
· The shape (percent) command cannot be configured for use in
nested poIicy maps on 7500 routers or beIow.
ExampIe: Average Rate, Peak Rate
This Iigure shows an example conIiguration Ior standalone class-based shaping (no CBWFQ).
Citrix traIIic is classiIied into the 'Shape¨ class. The 'Shape¨ class is then shaped to diIIerent
rates on two interIaces:
On the Serial 0/0 interIace, traIIic is shaped to the average rate, while on the Serial 0/1
interIace, traIIic is shaped to the peak rate. In both cases, the Bc and Be values are not
conIigured, allowing Cisco IOS soItware to automatically calculate the optimal values.
On the Serial 0/0 interIace, the Citrix traIIic is shaped to the average rate oI 16000
bps. The resulting automatically determined Be and Bc values will both be 8000 bits
with a Tc oI 500 ms.
On the Serial 0/1 interIace, the Citrix traIIic is shaped to the peak rate. Using this peak rate
shaping example, because the Be and Bc were not speciIied, Cisco IOS soItware will
automatically calculate the optimal value Ior Tc, Bc, and Be. The shape statement is 'shape
peak 16000¨. The resulting automatically determined Be and Bc values will both be 8000
bits with a Tc oI 500 ms, thereIore, the peak rate will be:
peak rate ¬ ave rate * (I+Be/Bc) ¬ I8000 * (I+8000/8000)
¬ I8000 * ? ¬ ·?000 bps
Cisco IOS software caIcuIated vaIues:
Bc=Be=8000 bits, Tc=500ms
Peak Rate = AvgRate * (1+Be/Bc)
= 16000 * (1+8000/8000)
= 32000 bps
Cisco IOS software caIcuIated vaIues:
Bc=Be=8000 bits, Tc=500ms
Peak Rate = AvgRate * (1+Be/Bc)
= 16000 * (1+8000/8000)
= 32000 bps
CIass-Based Shaping ExampIe:
Average Rate, Peak Rate
class~map Shape
match protocol citrix
!
policy~map ShapeAvg
class Shape
shape average 16000
!
policy~map ShapePeak
class Shape
shape peak 16000
!
interface Serial0/0
service~policy output ShapeAvg
!
interface Serial0/1
service~policy output ShapePeak
Showing the policy map on the interIace will display the average rate, peak rate, Bc, Be, and Tc
values:
router=show policy-map interface s0/I
Serial0/0
Service-policy output. ShapePeak
Class-map. Shape (match-all)
0 packets, 0 bytes
S minute offered rate 0 bps, drop rate 0 bps
Match. protocol citrix
Traffic Shaping
Target/Average Byte Sustain Excess Interval
Increment
Rate Limit bits/int bits/int (ms)
(bytes)
32000/16000 2000 8000 8000 500
?000
Adapt Queue Packets Bytes Packets Bytes
Shaping
Active Depth Delayed Delayed
Active
- 0 0 0 0 0
no
Class-map. class-default (match-any)
0 packets, 0 bytes
Match. any
ExampIe: CIass-Based Shaping with CBWFQ
Class-based shaping can be used in combination with CBWFQ. The shape rate provides a
maximum rate limit Ior the traIIic class while the bandwidth statement within CBWFQ
provides a minimum bandwidth guarantee.
In this example, the 'cust1¨ traIIic class is shaped to an average rate oI 384 kbps while it is
guaranteed a minimum oI 256 kbps by the CBWFQ bandwidth statement. Because the Bc and
Be are not speciIied it will be automatically calculated by the Cisco IOS soItware.
CIass-Based Shaping with CBWFQ
· Bandwidth statement
provides a minimum
bandwidth guarantee for
the traffic cIass.
· Shape statement provides
a maximum traffic rate for
the traffic cIass, excess
traffic is queued.
policy~map shape~cbwfq
!
class cust1
shape average 384000
bandwidth 256
!
interface Serial 0/0
service~policy output shape~cbwfq
ExampIe: CIass-Based Shaping HierarchicaI PoIicy Maps
This example uses hierarchical policy maps and conIigures CBWFQ inside the class-based
shaping.
The parent policy is the cust-policy. This parent policy reIerences a child policy named cust1-
classes.
The parent policy map cust-policy speciIies an average shape rate oI 384 kbps Ior all the
'cust1¨ traIIic and assigns the service policy called cust1-classes as the child policy.
Within the 'cust1¨ traIIic class, the 'cust1¨ traIIic is Iurther classiIied into three distinct traIIic
subclasses:
Subclass-x: The subclass-x class is conIigured to have a minimum guarantee equal to 50
percent oI the shaped bandwidth.
Subclass-y: The subclass-y class is conIigured to have a minimum guarantee equal to
20 percent oI the shaped bandwidth.
Subclass-z: The subclass-z class is conIigured to have a minimum guarantee equal to 10
percent oI the shaped bandwidth.
For example, in a service provider implementation, the 'cust1¨ traIIic can be all traIIic going to
a speciIic customer edge router on a Frame Relay subinterIace. The traIIic to that speciIic
customer edge router is Iurther classiIied into:
Subclass-x class Ior interactive traIIic
Subclass-y class Ior business-critical traIIic
Subclass-z class Ior bulk traIIic
CIass-Based Shaping HierarchicaI PoIicy Maps
The traIIic going out to that speciIic customer edge router over the Frame Relay subinterIace is
rate-limited to 384 kbps total. The interactive traIIic has a minimal guarantee oI 192 kbps (384
x 0.5), the business-critical traIIic has a minimal guarantee oI 76.8 kbps (384 x 0.2), and the
bulk traIIic has a minimal guarantee oI 38.4 kbps (384 x 0.1).
Monitoring CIass-Based Shaping
This topic identiIies the Cisco IOS commands that are used to monitor class-based shaping.
The show policy-map command displays the policy-map conIiguration.
This output represents the CBWFQ in conjunction with the class-based shaping conIiguration
example shown earlier where the cust1 traIIic class is shaped to an average rate oI 384 kbps,
with a deIault buIIer limit oI 1000 packets and a minimum bandwidth guarantee oI 256 kbps.
router>show policy~map shape~cbwfq
Policy Map shape~cbwfq
Class cust1
Traffic Shaping
Average Rate Traffic Shaping
CIR 384000 (bps) Max. Buffers Limit 1000 (Packets)
show policy~map policy~map~name show policy~map policy~map~name
router>
· DispIays information about the indicated poIicy map
incIuding the configuration of aII cIasses for a specified
service poIicy map.
The show policy-map interface command displays all service policies that are applied to the
interIace.
This output represents the CBWFQ in conjunction with the class-based shaping conIiguration
example shown earlier, where the cust1 traIIic class is shaped to an average rate oI 384 kbps
and has a minimum bandwidth guarantee oI 256 kbps.
Among the settings shown are the class-based shaping parameters like Be (excess bits/int), Bc
(sustain bits/int), and Tc (interval), and other statistics.
In this example, the shape average rate is 384 kbps and the automatically calculated values Ior
Bc and Be are 7872 bits, with a Tc oI 207 ms.
(Cont.)
router#show policy interface s0/0
Serial0/0
Service~policy output: shape~cbwfq
Class~map: cust1 (match~all)
0 packets, 0 bytes
Match: access~group 101
Traffic Shaping
Target/Average Byte Sustain Fxcess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
38400/38400 1968 7872 7872 207 984
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
~ 0 0 0 0 0 no
Queueing
0 packets, 0 bytes
Match: any
Summary
References
To learn more about class-based shaping, reIer to 'ConIiguring Class-Based Shaping¨ at
the Iollowing URL:
qcIcbshp.htm
To learn more about DTS, reIer to 'ConIiguring Distributed TraIIic Shaping¨ at the
Iollowing URL:
qcIdts.htm
To learn more about FRTS, reIer to 'ConIiguring Frame Relay and Frame Relay TraIIic
Shaping¨ at the Iollowing URL:
Irts.htm
To learn more about FRTS, reIer to 'TraIIic Shaping¨ at the Iollowing URL:
http://www.cisco.com/warp/public/125/21.pdI
Summary
· CIass-based shaping queues exceeding packets rather
than dropping them.
· CIass-based shaping has no marking capabiIities.
· CIass-based shaping can shape to the average or peak
rate for packets satisfying the match criteria for a cIass.
· Peak Rate = Average Rate * (1 + Be/Bc).
· CIass-based shaping is configured using the MQC.
Quiz
Q1) II the average rate is 64 kbps, the Bc is 8000 bits, and the Be is 4000 bits, what will the
peak rate be?
A) 96 kbps
B) 128 kbps
C) 192 kbps
D) 224 kbps
Q2) Which one oI the Iollowing statements is true regarding class-based shaping
conIigurations?
A) SpeciIying the Bc and Be values are mandatory.
B) SpeciIying the Be value is only required Ior peak-rate shaping.
C) SpeciIying the Be value is only required to implement a dual token bucket.
D) SpeciIying the Bc and Be values are optional. II Bc and Be are not speciIied,
IOS soItware will calculate an optimal value Ior them.
Q3) Which one oI the Iollowing statements is true when implementing CBWFQ with class-
based shaping?
A) CBWFQ deIines the token bucket size used within class-based shaping.
B) CBWFQ deIines the maximum rate limit Ior a traIIic class using class-based
shaping.
C) CBWFQ provides a minimum bandwidth guarantee to the traIIic class, while
class-based shaping provides a maximum rate limit Ior the traIIic class.
D) CBWFQ can be used in conjunction with class-based shaping only iI the
shaping queue is conIigured as a FIFO queue.
Q4) Complete the Iollowing Cisco IOS MQC conIiguration to enable hierarchical class-
based shaping based on the Iollowing requirements:
Shape the customer-one traIIic class to an average rate oI 64 kbps.
Within the customer-one traIIic class, conIigure the gold class to use 40 percent oI the
bandwidth, the silver class to use 20 percent oI the bandwidth, and the bronze class to
use 10 percent oI the bandwidth.
policy-map customer-one-classes
class mission-critical
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
class transactional
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
class bulk
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
!
policy-map customer-one-policy
class customer-one
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
!
InterIace serial 0/0.1
Service-policy output customer-one-policy
Quiz Answer Key
Q1) A
ReIates to: Configuring Class-Based Shaping
Q2) D
Q3) C
Q4)
policy-map customer-one-classes
class transactional
class bulk
!
policy-map customer-one-policy
class customer-one
shape average 64000
service~policy customer~one~classes
!
Interface serial 0/0.I
Service-policy output customer-one-policy
Shaping on Frame Relay
Ìnterfaces
Overview
FRTS builds upon existing Frame Relay support on Cisco routers by adding new capabilities
that improve the scalability and perIormance oI a Frame Relay network. FRTS can help
eliminate bottlenecks in Frame Relay networks consisting oI high-speed connections at a
central hub site and low-speed connections at branch spoke sites. Using FRTS, network
administrators can conIigure rate enIorcement to either the CIR or some other deIined value
such as the excess inIormation rate on a per-virtual circuit (VC) basis. One limitation oI FRTS
is that it applies only to Frame Relay PVCs and switched virtual circuits (SVCs).
Class-based shaping can be conIigured to behave the same as FRTS by allocating one DLCI per
subinterIace and using BECN support. This lesson describes the tasks to conIigure class-based
traIIic shaping to rate-limit certain traIIic classes on Frame Relay interIaces.
ReIevance
TraIIic shaping is an important addition to Frame Relay networks because Frame Relay
switches cannot determine which Irames take precedence, and thereIore which Irames should
be dropped when congestion occurs. By enabling traIIic shaping over Frame Relay interIaces,
especially when there are speed mismatches or network over-subscriptions, drops in the Frame
Relay network can be controlled.
Objectives
Upon completing this lesson, you will be able to conIigure class-based shaping on Frame Relay
WAN interIaces to rate-limit traIIic. This includes being able to meet these objectives:
Explain the purpose oI the Frame Relay FECN, BECN, and the DE bit
Explain the use oI FECN and BECN as a Frame Relay congestion control mechanism
Explain how class-based shaping can adapt dynamically to available Frame Relay
bandwidth by integrating BECN signals
Explain the FECN to BECN propagation mechanism
IdentiIy the Cisco IOS commands required to conIigure Frame Relay adaptive class-based
shaping on Frame Relay interIaces
IdentiIy the Cisco IOS commands used to monitor class-based shaping on FR interIaces
Basic knowledge oI Frame Relay operation and conIiguration
Knowledge oI class-based shaping operation and conIiguration
OutIine
OutIine
· Overview
· Frame ReIay Refresher
· Frame ReIay Congestion ControI
· Frame ReIay Congestion Adaptation
· FECN to BECN Propagation
· Configuring Frame ReIay Adaptive CIass-Based Shaping
· Monitoring CIass-Based Shaping with FR Adaptation
· Summary
· Quiz
Frame ReIay Refresher
This topic explains the purpose oI the Frame Relay FECN, BECN, and the DE bit.
When the Frame Relay network becomes congested to the point that it cannot process new data
transmissions, it begins to discard Irames. These discarded Irames are detected and then
retransmitted by higher layer protocols, thus causing more congestion. In an eIIort to prevent
this situation, several mechanisms have been developed to notiIy user devices at the onset oI
congestion, so that the oIIered load may be reduced.
Frame Relay perIorms congestion notiIication to its Layer 2 endpoints (FR DTE) by including
congestion signaling inside the Layer 2 Irame headers. The FECN, BECN,and DE bits in the
Q.922 header oI the Irame provide in-band congestion signaling.
The FECN and BECN bit is set by a Frame Relay switch to notiIy an end device (FR DTE,
which may be a router) that it should initiate congestion avoidance procedures.
When there is congestion, the network must decide which Irames to discard. The DE bit
provides the network with a signal to help determine which Irames to discard. The DE bit
indicates that a Irame may be discarded in preIerence to other Irames, iI congestion occurs, to
maintain the committed QoS within the network. The DE bit may be set by the user on lower-
priority Irames. Alternatively, the network may set the DE bit to indicate to other nodes that a
Irame should be preIerentially selected Ior discard, iI necessary.
Frame ReIay Refresher
· Frame ReIay expIicit congestion notification
÷ FECN (forward expIicit congestion notification)
÷ BECN (backward expIicit congestion notification)
÷ Set by the Frame ReIay switch to notify an end device
of congestion in the network
· ImpIicit Congestion Notification
÷ Provides the Frame ReIay network a signaI to
determine which frames to discard in preference to
their frames
÷ DE (Discard EIigibiIity) bit
Frame ReIay Congestion ControI
This topic explains the use oI FECN and BECN as a Frame Relay congestion control
mechanism.
A Frame Relay switch can explicitly report congestion in two directions: Iorward and
backward.
When a Irame queue inside a switch is congested, the switch will generate congestion signals
based on the FECN and BECN bits.
II congestion occurs in a queue towards the main receiver oI traIIic, FECN signals are sent to
the receiving Layer 2 endpoint and BECN signals are sent to the sending Layer 2 endpoint.
FECN and BECN bits are not sent as separate Irames, but are piggybacked inside data Irames.
Frame ReIay Congestion ControI
· FR Switch detects congestion on output queue and
informs:
÷ The receiver by setting the FECN bit on forwarded frames
÷ The source by setting the BECN bit on frames going in the opposite
direction
Frame ReIay Congestion Adaptation
This topic explains how class-based shaping can adapt dynamically to available Frame Relay
bandwidth by integrating BECN signals.
Class-based shaping is able to respond to Layer 2 congestion in the Frame Relay network by
reducing its shaping rate to three-quarters oI the current rate, until the Layer 2 Frame Relay
network recovers Irom congestion. When BECN Ilags are no longer received, the rate is slowly
ramped up again to the original shaping rate.
Frame ReIay Congestion Adaptation
· CIass-based shaping can adapt dynamicaIIy to
avaiIabIe Frame ReIay bandwidth by integrating
BECN signaIs:
÷ The bit rate is reduced when BECN packets are
received to reduce the data fIow through congested
Frame ReIay network.
÷ The bit rate is graduaIIy increased when the
congestion is no Ionger present (BECN packets are no
Ionger received).
FECN to BECN Propagation
This topic explains the FECN to BECN propagation mechanism.
Another adaptation method, FECN to BECN propagation, conIigures a router Frame Relay
subinterIace to reIlect received FECN bits as BECN in Q.922 Test Response messages. This
enables the sender to notice congestion in the Layer 2 Frame Relay network, even iI there is no
data traIIic Ilowing Irom the receiver back to the sender.
FECN to BECN Propagation
Configuring Frame ReIay Adaptive CIass-Based
Shaping
This topic identiIies the Cisco IOS commands that are required to conIigure Frame Relay
adaptive class-based shaping on Frame Relay interIaces.
The shape adaptive command conIigures the class-based shaping system to adapt the shaping
rate to BECN indications.
The min-rate (also called min-cir) parameter speciIies the minimum-shaping rate that is
allowed. Typically, this is set to the CIR guaranteed Ior the traIIic class when there is
congestion in the network. Taking a closer look at BECN integration:
II router receives any BECNs during current time interval, it decreases the transmit rate by
25 percent. It will continue to drop with each BECN (limit one drop per time interval) until
the traIIic rate gets to min-rate where it stops.
AIter the traIIic rate has decreased, it takes 16 time intervals oI receiving no BECNs to start
to increase traIIic again. The amount it increases by is (Be ¹ Bc)/16. Thus it takes much
longer to get back to CIR than it did to drop to min-rate (similar to slow start in TCP/IP).
The shape fecn-adapt command conIigures the class-based shaping system to respond to
FECN-marked Irames with BECN test Irames.
Configuring Frame ReIay
Adaptive CIass-Based Shaping
shape adaptive min~rate shape adaptive min~rate
· Adapts the shaping rate when BECN bits are received
· min-rate: Each BECN bit causes the shaping rate to be
reduced to three-quarters of the previous rate but not
beIow the
· This command has effect onIy if used on Frame ReIay
interfaces
shape fecn~adapt shape fecn~adapt
· Responds to FECN bits by creating test frames in the
opposite direction with the BECN bit set
ExampIe: CIass-Based Shaping with Frame ReIay Adaptation
CIass-Based Shaping ExampIe: CIass- Based
Shaping with Frame ReIay Adaptation
The min-rate shouId be
equaI to or greater than the
minimum bandwidth
guarantee for that traffic
cIass.
This example shows a typical class-based adaptive shaping in conjunction with CBWFQ
conIiguration.
In this case, two traIIic classes are deIined with diIIerent shape rate and minimum bandwidth
guarantee.
The interactive traIIic class is shaped to an average rate oI 256 kbps with a minimum
bandwidth guarantee oI 128 kbps. When BECN bit is detected, the shape rate can start
throttling down to a min-rate oI 128 kbps.
The bulk traIIic class is shaped to an average rate oI 384 kbps with a minimum bandwidth
guarantee oI 192 kbps. When the BECN bit is detected, the shape rate will start throttling down
to a min-rate oI 192 kbps.
When using class-based traIIic shaping with CBWFQ, the min-rate should be equal to or
greater than the minimum bandwidth guarantee Ior that traIIic class.
Monitoring CIass-Based Shaping with FR
Adaptation
This topic identiIies the Cisco IOS commands that are used to monitor class-based shaping on
FR interIaces.
The show policy-map command displays the policy-map conIiguration.
In this example, class-based adaptive shaping is used in conjunction with CBWFQ on the
interactive and bulk traIIic classes.
The interactive traIIic class is shaped to an average rate oI 256 kbps with a minimum
bandwidth guarantee oI 128 kbps and a min-rate oI 128 kbps.
The bulk traIIic class is shaped to an average rate oI 384 kbps with a minimum bandwidth
guarantee oI 192 kbps and a min-rate oI 192 kbps.
Monitoring CIass-Based Shaping with
FR Adaptation
show policy~map policy~map~name show policy~map policy~map~name
router>
· DispIays the poIicy-map configuration for aII
configured traffic cIasses
router#show policy~map shape~cbwfq
Policy Map shape~cbwfq
Class interactive
Traffic Shaping
Adapt to 128000 (bps)
Class bulk
Traffic Shaping
Adapt to 192000 (bps)
Summary
References
To learn more about class-based shaping, reIer to 'ConIiguring Class-Based Shaping¨ at
the Iollowing URL:
qcIcbshp.htm
For inIormation about Frame Relay conIiguration, reIer to 'ConIiguring Frame Relay and
Frame Relay TraIIic Shaping¨ at the Iollowing URL:
Irts.htm
For inIormation about Frame Relay conIiguration, reIer to 'ConIiguring and
Troubleshooting Frame Relay¨ at the Iollowing URL:
http://www.cisco.com/en/US/tech/tk713/tk237/technologies¸tech¸note09186a0080094372.
shtml
Next Steps
Lab Exercise 7-2: ConIiguring Class-Based Shaping
Summary
· CIass-based shaping can adapt dynamicaIIy to avaiIabIe
Frame ReIay bandwidth by integrating BECN signaIs.
· The bit rate is reduced when BECN packets are received
to reduce the data fIow through congested Frame ReIay
network.
· The bit rate is graduaIIy increased when the congestion is
no Ionger present (BECN packets are no Ionger received).
· CIass-based shaping can respond to FECN bits by
creating test frames in the opposite direction with the
BECN bit set.
Quiz
Q1) Which three oI the Iollowing bits in the Frame Relay header are used Ior in-band
congestion signaling? (Choose three.)
A) CLP
B) DE
C) FECN
D) BECN
E) DLCI
F) PTI
G) LMI
Q2) When a router receives a Irame with the FECN bit set, but the router has no reverse
traIIic to send back to the source, what can be enabled so that the router can send a test
Irame back to the source with the BECN bit set?
A) FECN-to-BECN propagation (shape Iecn-adapt)
B) BECN-to-FECN propagation (shape becn-adapt)
C) adaptive traIIic shaping (shape adaptive min-rate)
D) adaptive FECN traIIic shaping (shape Iecn min-rate)
Q3) Which one oI the Iollowing statements correctly describes the BECN and FECN bit
operations?
A) FECN and BECN bits are set by the Frame Relay switch to notiIy the Frame
Relay DTE oI congestion in the network using special Q.922 test Irame.
B) FECN and BECN bits are set by the Frame Relay DTE to indicate to the
network that a Irame may be discarded in preIerence to other Irames when the
network is congested.
C) II congestion occurs in a queue towards the main receiver oI traIIic, BECN
signals are sent to the receiving Layer 2 endpoint and FECN signals are sent to
the sending Layer 2 endpoint.
D) II congestion occurs in a queue towards the main receiver oI traIIic, FECN
signals are sent to the receiving Layer 2 endpoint and BECN signals are sent to
the sending Layer 2 endpoint.
Q4) Which oI the Iollowing correctly explains how the traIIic rate adapts to the BECN
congestion notiIication signal when adaptive Frame Relay traIIic shaping is enabled on
the router?
A) When a router receives a Irame with the BECN bit set, it decreases the transmit
rate directly to the min-rate. When a FECN bit is then received, the router
increases the transmit rate by 25 percent. It will continue to increase the
transmit rate with each FECN until the traIIic rate gets to the average or peak
shape rate.
B) When a router receives any BECNs, it decreases the transmit rate by 25
percent. It will continue to drop the transmit rate with each BECN until the
traIIic rate gets to the min-rate where it stops. When the traIIic rate has been
decreased, aIter 16 time intervals oI receiving no BECNs, the traIIic rate will
start to increase by (Be ¹ Bc)/16.
C) When a router receives a Irame with the BECN bit set, it decreases the transmit
rate directly to the min-rate. When a FECN bit is then received, the router
increases the transmit rate back to the average or peak shape rate.
D) When a router receives any BECNs, it decreases the transmit rate by 25
percent. It will continue to drop the transmit rate with each BECN until the
traIIic rate gets to the min-rate where it stops. The traIIic rate will increase
back to the average or peak shape rate once a FECN bit is received.
Q5) Which oI the Iollowing is the correct conIiguration to enable adaptive Frame Relay
traIIic shaping on the gold traIIic class where the gold traIIic will be shaped to an
average rate oI 768 kbps, and will adapt to a minimum rate oI 256 kbps when there is
congestion in the Frame Relay network?
A) Class gold
Shape average 768000
Shape adaptive 256000
Bandwidth 256000
B) Class gold
Bandwidth 768000
C) Class gold
Shape Iecn-adapt 256000
Bandwidth percent 50
D) Class gold
Shape Iecn-adapt
Bandwidth percent 50
Quiz Answer Key
Q1) B, C, D
ReIates to: Frame Relay Refresher
Q2) A
ReIates to: FECN to BECN Propagation
Q3) D
ReIates to: Frame Relay Congestion Control
Q4) B
ReIates to: Frame Relay Congestion Adaptation
Q5) A
ReIates to: Configuring Frame Relay Adaptive Class-Based Shaping
Module Assessment
Overview
Quiz: Traffic PoIicing and Shaping
Objectives
Explain how traIIic policing and traIIic shaping can be used to rate-limit traIIic
ConIigure class-based policing to rate-limit traIIic
ConIigure class-based shaping to rate-limit traIIic
ConIigure class-based shaping on Frame Relay WAN interIaces to rate-limit traIIic
Instructions
Step 1 Answer all questions in this quiz by selecting the best answer(s) to each question,
incorrectly.
Q1) Which oI the Iollowing is a major diIIerence between traIIic policing versus traIIic
shaping?
A) TraIIic policing drops excess traIIic while traIIic shaping delays excess traIIic
by queuing them.
B) TraIIic policing is only applied in the outbound direction while traIIic shaping
can be applied to both the inbound and outbound directions.
C) TraIIic policing is not available on the Catalyst switches like the 2950. TraIIic
shaping is available on Catalyst switches like the 2950.
D) TraIIic policing requires policing queues to buIIer excess traIIic while traIIic
shaping does not require any queues to buIIer excess traIIic.
Q2) What mathematical model is used by traIIic policing mechanisms to meter traIIic?
A) token bucket
B) RED
C) FIFO metering
D) predictor or stacker
Q3) When conIiguring single-rate class-based policing, what conIiguration parameter is
used to enable a dual token bucket?
A) conIiguring a 'violate¨ action
B) conIiguring an 'exceed¨ action
C) conIiguring the PIR in addition to the CIR
D) conIiguring Be
Q4) What is the main advantage oI using multiaction policing?
A) to distinguish between exceeding and violating traIIic
B) to distinguish between conIorming and exceeding traIIic
C) to allow the setting oI both Layer 2 and Layer 3 QoS markers at the same time
D) to allow marking oI the traIIic beIore transmission
Q5) Which three oI the Iollowing situations typically requires the use oI a rate-limiting
mechanism? (Choose three.)
A) Frame Relay connection with mismatch speeds at the two end points
B) hub-and-spoke Frame Relay topology with over-subscription at the hub site
C) service provider providing sub-rate access
D) in the service provider high-speed backbone to avoid congestion
Q6) What is the min-rate?
A) the minimum bandwidth guaranteed by CBWFQ Ior the traIIic class
B) the minimum bandwidth guaranteed by the LLQ Ior the traIIic class
C) the minimum speed the traIIic rate will throttle down to when the BECN bits
are being received
D) the minimum speed the traIIic rate will throttle down to when the FECN bits
are being received
E) the minimum class-based policing traIIic rate Ior a traIIic class
Q7) Which two oI the Iollowing statements is true when class-based shaping is used in
conjunction with CBWFQ? (Choose two.)
A) The bandwidth command deIines the minimum guaranteed bandwidth Ior the
traIIic class.
B) The bandwidth command deIines the maximum guaranteed bandwidth Ior the
traIIic class.
C) The shape peak command deIines the maximum rate limit Ior the traIIic class.
D) The shape average command deIines the minimum bandwidth guaranteed Ior
the traIIic class.
Q8) What is the Iunction oI FECN to BECN propagation?
A) to allow a receiving router to send back a test Irame with the BECN bit set to
the sender when the receiver has no data to send back to the sender aIter
receiving the FECN bit
B) to allow a router to throttle down the traIIic rate to the min-rate when either the
FECN or BECN bit is received
C) to allow a router to throttle down the traIIic rate to the min-rate when the
BECN bit is received
D) to allow a router to throttle down the traIIic rate to the min-rate when the
FECN bit is received
E) to allow a receiving router to set the BECN bit on a user data Irame going back
to the sender aIter receiving the FECN bit
Q9) What are the two conIiguration options when conIiguring class-based traIIic shaping?
(Choose two.)
A) shape average
B) shape peak
C) single or dual token bucket
D) single or multiactions traIIic shaping
E) single- or dual-rate traIIic shaping
Q10) Which three are Ieatures oI class-based policing? (Choose three.)
A) single or dual token bucket
B) single or multiactions policing
C) single- or dual-rate policing
D) single or dual FIFO queuing
E) single or dual drop threshold
Scoring
or better.
Q1) A
ReIates to: Traffic Policing and Traffic Shaping Overview
Q2) A
Q3) A
ReIates to: Configuring Class-Based Policing
Q4) C
Q5) A, B, C
Q6) C
ReIates to: Configuring Class-Based Shaping on Frame Relay Ìnterfaces
Q7) A, C
Q8) A
ReIates to: Configuring Class-Based Shaping on Frame Relay Ìnterfaces
Q9) A, B
Q10) A, B, C
ModuIe Summary
Rate-limiting is the ability to prevent excess traIIic Irom entering or leaving the network. Rate-
limiting is required because oI speed mismatches, oversubscriptions, sub-rate access, and to
prevent unwanted traIIic Irom causing network congestions.
To measure the traIIic rate, a token bucket is used. Parameters that deIine the operations oI a
token bucket includes the CIR, Bc (normal burst size), Be size, and Tc.
The CIR can be calculated by using the Iollowing Iormula:
CIR (in bps) ÷ Bc (in bits)/ Tc (in seconds)
Both traIIic policing and traIIic shaping are QoS mechanisms that are used to rate-limit a traIIic
class. TraIIic policing operates by dropping excess traIIic while traIIic shaping delays excess
traIIic with the aid oI queuing.
In Cisco IOS soItware, the most current rate-limiting mechanisms are class-based policing and
class-based shaping. Both oI these rate-limiting mechanisms are conIigured using the MQC. On
Frame Relay interIaces, class-based shaping can be used in conjunction with CBWFQ and
supports BECN adaptation and FECN-to-BECN propagation.
ModuIe Summary
· Traffic shaping queues excess packets to stay within the shape
rate.
· Traffic poIicing typicaIIy drops excess traffic to stay within the
rate Iimit; aIternativeIy it can remark then sends excess traffic.
· Traffic rate is measured using a token bucket mathematicaI
modeI.
· CIass-based poIicing features incIude: Drop or remark and
transmit exceeding traffic, singIe or duaI token bucket, singIe or
duaI rate poIicing, muItiaction poIicing.
· CIass-based shaping can shape to the average or peak rate for
a traffic cIass.
· CIass-based shaping can throttIe down the traffic rate
dynamicaIIy when BECN bits are received.
· CIass-based shaping can respond to FECN bits by creating test
frames in the opposite direction with the BECN bit set.
ModuIe 8
Link Efficiency Mechanisms
Overview
In many networks consisting oI a large WAN covering many sites, the monthly recurring costs
oI even the smallest link upgrades can be too high. In some cases, the only option Ior these low
bandwidth remote sites is to upgrade their wide area circuit. In other cases, a set oI quality oI
service (QoS) techniques can be used that can improve the eIIiciency oI these low-speed WAN
links. Header compression and payload compression mechanisms reduce the size oI packets,
reducing delay and increasing available bandwidth on a link. Other QoS link eIIiciency
techniques such as link Iragmentation and interleaving (LFI) allow Iragile traIIic types, such as
voice and interactive traIIic, to be sent either ahead or interleaved with larger, more aggressive
Ilows. These techniques decrease latency and assist in meeting the service level requirements oI
delay-sensitive traIIic types such as voice.
This module discusses the diIIerent link eIIiciency mechanisms (LEMs) that are available in
Cisco IOS soItware to implement header compression, payload compression, and LFI.
ModuIe Objectives
Upon completing this module, you will be able to use Cisco link eIIiciency mechanisms to
improve the bandwidth eIIiciency oI low-speed WAN links.
ModuIe OutIine
ModuIe Objectives
· ExpIain how Iink efficiency mechanisms can be
used to improve bandwidth efficiency and
reduce deIay
· Configure cIass-based TCP and cIass-based RTP
header compression to improve bandwidth
efficiency and reduce deIay
· Configure LFI to improve bandwidth efficiency
and reduce deIay
ModuIe OutIine
· Link Efficiency Mechanisms Overview
· CIass-Based Header Compression
Link Efficiency Mechanisms
Overview
Overview
Interactive traIIic such as Telnet and Voice over IP (VoIP) are susceptible to increased latency
when network processes using large packets, such as bulk FTP, traverse WAN links. Packet
delay is especially signiIicant when FTP packets are queued on slower links within the WAN.
To solve delay problems on slow bandwidth links, a method Ior Iragmenting larger Irames, and
then queuing the smaller Irames between Iragments oI the large Irames, is required. To this
requirement, Cisco IOS soItware supports PPP multilink LFI as well as Frame Relay
Iragmentation (FRF.12 and FRF.11.C). In addition, other tools, such as header and payload
compression techniques, can be used to reduce the size oI Irames that are sent on WAN links.
This lesson describes diIIerent approaches to improving the eIIiciency oI WAN links. It
discusses LEMs that either compress the payload oI packets (stacker and predictor) or reduce
packet headers overhead by compressing the headers (TCP and Real-Time Transport Protocol
|RTP| header compression). It also discusses the diIIerent Layer 2 link LFI mechanisms
(Multilink PPP |MLP| LFI and Frame Relay Fragmentation FRF.12 and FRF.11.C) that are
available in Cisco IOS soItware.
ReIevance
WAN links are an expensive resource in all enterprise and service provider networks.
Improving the eIIiciency oI these expensive and vital resources is important because it can
improve response times, reduce delays, and extend the longevity oI some slower WAN links.
Objectives
Upon completing this lesson, you will be able to explain how link eIIiciency mechanisms can
be used to improve bandwidth eIIiciency and reduce delay. This includes being able to meet
these objectives:
Explain the various link eIIiciency mechanisms and their Iunctions
Describe the purpose oI Layer 2 payload compression and how Layer 2 payload
compression aIIects throughput and delay
Describe the purpose oI header compression and how header compression aIIects
throughput and delay
Explain how VoIP packets are susceptible to increased latency when large packets such as
FTP transIers traverse slow WAN links
Explain LFI operation and how LFI reduces the delay and jitter oI VoIP packets
IdentiIy the points in a network where link eIIiciency mechanisms can most eIIectively be
employed
OutIine
OutIine
· Overview
· Link Efficiency Mechanisms Overview
· L2 PayIoad Compression
· Header Compression
· Large Packets "Freeze Out" Voice on SIow WAN Links
· AppIying Link Efficiency Mechanisms
· Summary
· Quiz
Copyright © 2003, Cisco Systems, Ìnc. Link Efficiency Mechanisms 8-5
Link Efficiency Mechanisms Overview
This topic explains the various LEMs and their Iunctions.
While many QoS mechanisms exist Ior optimizing throughput and reducing delay in network
traIIic, QoS mechanisms do not create bandwidth. QoS mechanisms optimize the use oI
existing resources, and enable the diIIerentiation oI traIIic according to a policy.
Link eIIiciency QoS mechanisms like payload compression, header compression, and LFI are
deployed on WAN links to optimize the use oI WAN links.
Payload compression squeezes packet payloads, and thereIore increases the amount oI data that
can be sent through a transmission resource in a given time period. Payload compression is
primarily perIormed on Layer 2 Irames and thereIore compresses the entire Layer 3 packet. The
Layer 2 payload compression methods available in Cisco IOS soItware include stacker,
predictor, and MicrosoIt Point-to-Point Compression (MPPC). These algorithms diIIer vastly in
their compression eIIiciency and in utilization oI router resources.
RFC 2393, IP PCP (Payload Compression Protocol) is a Iairly new technique Ior compressing
the IP payload at Layer 3. (IP PCP will not be discussed in this lesson.)
All compression methods are based on eliminating redundancy when sending the same or
similar data over a transmission medium. One piece oI data, which is oIten repeated, is the
protocol header. In a Ilow, the protocol header inIormation oI packets in the same Ilow does not
change much over the liIetime oI that Ilow. ThereIore, using header compression mechanisms,
most oI header inIormation could be sent only at the beginning oI the session, stored in a
dictionary, and then reIerenced in later packets by a short dictionary index. The header
compression methods available in Cisco IOS include: TCP and RTP header compression, and
class-based TCP and RTP header compression.
Link Efficiency Mechanisms Overview
· Link efficiency mechanisms are often depIoyed
on WAN Iinks to increase the throughput and to
decrease deIay and jitter
· Cisco IOS Iink efficiency mechanisms incIude:
÷ L2 payIoad compression (stacker, predictor, MPPC)
÷ Header compression (TCP, RTP, cIass-based TCP,
and cIass-based RTP)
÷ LFI (MLP, FRF.12, and FRF.11.C)
LFI is a Layer 2 technique where large Layer 2 Irames are broken into small, equal-size
Iragments, and transmitted over the link in an interleaved Iashion. Using LFI, large Irames
waiting in the queuing system are Iragmented, smaller Irames are prioritized, and a mixture oI
Iragments is sent over the link. LFI reduces the queuing delay oI small Irames, as they are sent
almost immediately. Link Iragmentation thereIore reduces delay and jitter by expediting the
transIer oI smaller Irames through the hardware transmit (Tx) queue. The LFI methods
available in Cisco IOS soItware include: MLP LFI, FRF.12 and FRF.11.C.
Layer 2 payload compression squeezes Layer 2 payloads (the entire Layer 3 packet). Layer 2
payload compression both increases the throughput and latency in transmission because smaller
packets (with compressed payloads) take less time to transmit than the larger, uncompressed
packets. Layer 2 payload compression is perIormed on a link-by-link basis.
Header compression methods work by transmitting repeated inIormation in packet headers
throughout a session. The two peers on a PPP Layer 2 connection (such as a dial-up link) agree
on session indices, which index a dictionary oI packet headers. The dictionary is built at the
start oI every session and is used Ior all subsequent (non-initial) packets. Only changing (non-
constant) parameters in the headers are actually sent along with the session index.
It is important to note that header compression is perIormed on a link-by-link basis. Header
compression cannot be perIormed across multiple routers because routers need Iull Layer 3
header inIormation to be able to route packets to the next hop.
ExampIe: Indexing Operations
Compressed RTP (cRTP) maintains the state Ior session contexts. A session context is deIined
by the combination oI the IP source and destination addresses, the User Datagram Protocol
(UDP) source and destination ports, and the RTP synchronization source (SSRC) Iield. A
compressor implementation might use a hash Iunction on these Iields to index a table oI stored
session contexts. The compressed packet carries a small integer, called the session context
identiIier, to indicate in which session context that packet should be interpreted. The
decompressor can use the context identiIier to index its table oI stored session contexts directly.
Note: Refer to RFC 2508 for more information on cRTP operations.
Compression
· PayIoad compression reduces the size of the payIoad.
· Header compression reduces the headers overhead.
· Compression increases throughput and decreases
Iatency.
L2 PayIoad Compression
This topic describes the purpose oI Layer 2 payload compression and how Layer 2 payload
compression aIIects throughput and delay.
The Iigure shows a basic block diagram oI a Layer 2 payload compression method. When a
router Iorwards a packet, it is subjected to the Layer 2 compression method aIter it has been
encapsulated at the output. The compression method squeezes the payload oI the Layer 2 Irame
(the entire Layer 3 packet), and transmits the packet on the interIace.
Layer 2 payload compression is a CPU-intensive task and can add per-packet compression
delay due to the application oI the compression method to each Irame. The serialization delay,
however, is reduced, because the resulting Irame is smaller. Serialization delay is the Iixed
delay that is required to clock the Irame onto the network interIace. Depending on the
complexity oI the Layer 2 payload compression algorithm, overall latency might be reduced,
especially on low-speed links.
Cisco routers support hardware-assisted compression to reduce the CPU load and the Layer 2
payload compression delay.
L2 PayIoad Compression
· L2 payIoad compression reduces the size of the frame payIoad.
· Entire IP packet is compressed.
· Software compression can add deIay due to its compIexity.
· Hardware compression reduces the compression deIay.
· SeriaIization deIay is reduced, overaII Iatency might be reduced.
ExampIe: L2 PayIoad Compression ResuIts
The Iigure compares three throughput/latency scenarios on a PPP link.
II no compression is used, the throughput is limited by the link bandwidth, and the average
delay is inIluenced only by the Iorwarding/buIIering delay, the serialization, and the
propagation delay.
II compression is enabledeven iI the serialization delay is now shorter because the Irame is
smallerthe compression/decompression delay may increase the overall latency between the
two hops. The perceived throughput is generally increased because the size oI the Layer 2
payload is reduced, thereIore allowing more Layer 2 Irames to be sent through a transmission
resource in a given time period. The throughput is limited by the eIIectiveness oI the Layer 2
payload compression algorithm and may be signiIicantly higher than the link bandwidth limit.
II hardware-assisted Layer 2 payload compression is used, the compression/decompression
delays may become insigniIicant compared to Iorwarding and serialization delays, and overall
latency may decrease. The throughput is again limited by the eIIectiveness oI the Layer 2
payload compression method and may be signiIicantly higher than the link bandwidth limit.
Note: Layer 2 payload compression configuration will not be covered in this module. Refer to the
latest Cisco ÌOS documentation for configuration details.
L2 PayIoad Compression ResuIts
· Compression increases throughput and decreases deIay
· Use hardware compression when possibIe
· ExampIes: stacker, predictor, MPPC
Header Compression
This topic describes the purpose oI header compression and how header compression aIIects
throughput and delay.
Header compression increases the perceived throughput and reduces the delay by compressing
the protocol headers. Header compression is most useIul Ior applications that generate small
payloads because the protocol headers oI such applications consume a signiIicant percentage oI
available bandwidth on a link relative to their payload. Real-time applications typically
generate small payloads. Target applications Ior header compression include Telnet and RTP
applications, such as VoIP.
TCP and RTP header compression applies to all TCP and RTP Ilows. For example, iI TCP
compression is enabled on a link, there is no mechanism to restrict its Iunction to speciIic
application types. TCP header compression Ior bulk data transIer (packets with a large payload)
yields little bandwidth savings. Using the newer class-based TCP header compression, TCP
header compression can be perIormed only on a certain traIIic class; Ior example, only perIorm
TCP header compression on the Telnet traIIic class.
The Iigure shows a block diagram oI a header compression method. The header compression
algorithm tracks active transport-layer connections over an interIace. AIter the packet has been
Iorwarded, the header compression algorithm compresses the Layer 3 and Layer 4 headers
within the Irame, and replaces them with a session index Irom the session dictionary (table).
Only the non-constant parameters in the headers will be sent along with the session index. The
packet is then sent to the output queue, and transmitted to the remote peer. When the remote
peer receives the packet, the header is decompressed using the local session table, and passed to
the Iorwarding process.
Header Compression
· Header compression reduces the size of the packet
headers
· The payIoad size is not changed
· ExampIe: (cIass-based) TCP and (cIass-based) RTP
header compression
For example, without RTP header compression, the IP/UDP/RTP header overhead oI the voice
packet shown in the Iigure is about 67 percent (40/60 x 100 percent). With RTP header
compression, the IP/UDP/RTP header can be reduced to 2 or 4 bytes (without and with
checksum, respectively) Ior most packets, thus the IP/UDP/RTP header overhead can be
reduced to about 9 percent (2/22 x 100 percent) or 17 percent (4/24 x 100 percent).
ExampIe: Header Compression ResuIts
The Iigure compares two throughput/latency scenarios on a PPP link.
II header compression is not used, the throughput is limited by the link bandwidth, and the
average delay is inIluenced only by the Iorwarding/buIIering delay, the serialization, and the
propagation delay.
II header compression is enabled, by compressing the protocol headers, the packet gets smaller,
thereIore allowing more packets to be sent through a transmission resource in a given time
period to increase the throughput. Because the packet size is smaller, the serialization delay
also becomes smaller, thus reducing the overall delay. Header compression has low CPU
overhead and a low compression delay.
Header Compression ResuIts
· Header compression increases throughput and
reduces deIay.
Large Packets "Freeze Out" Voice on SIow WAN
Links
This topic explains how VoIP packets are susceptible to increased latency when large packets
such as FTP transIers traverse slow WAN links.
When considering delay between two hops in a network, queuing delay in a router must be
considered because it may be comparable toor even exceedthe serialization and
propagation delay on a link. In an empty network, an interactive or voice session experiences
low or no queuing delay because it does not compete with other applications on an interIace
output queue. Also, the small delay does not vary enough to produce considerable jitter on the
receiving side.
In a congested network, interactive data and voice applications compete in the router queue
with other applications. Queuing mechanisms may prioritize voice traIIic in the soItware queue,
but the hardware queue (Tx ring) always uses a FIFO scheduling mechanism. ThereIore, aIter
packets oI diIIerent applications leave the soItware queue, they will mix with other packets in
the hardware tx-queue (TxQ), even iI their soItware queue processing was expedited. Thus, a
voice packet may be immediately sent to the hardware TxQ where two large FTP packets may
still be waiting Ior transmission. The voice packet must wait until the FTP packets are
transmitted, thus producing an unacceptable delay in the voice path. Because links are variably
utilized, this delay varies with time and may produce unacceptable jitter in jitter-sensitive
applications such as voice.
Large Packets "Freeze Out" Voice on
SIow WAN Links
ProbIems:
· Excessive deIay due to sIow Iink and MTU-sized (Iarge) packets
· Jitter (variabIe deIay) due to variabIe Iink utiIization
Serialization delay is the Iixed delay that is required to clock a voice or data packet onto the
network interIace. Serialization delay is directly related to the link speed and the size oI the
packet.
This Iigure shows the serialization delay as a Iunction oI the link speed and packet size.
For example, the serialization delay Ior a 1500-byte packet over a 56-kbps link will be 214 ms,
while the serialization delay is only 7.5 ms over a 1.536-Mbps link Ior the same 1500-byte
packet.
SeriaIization DeIays
This topic explains LFI operation and how LFI reduces the delay and jitter oI VoIP packets.
Using a hybrid queuing method like LLQ can provide low latency and low jitter Ior VoIP
packets while servicing other data packets in a Iair manner. But even iI VoIP packets are
always sent to the Iront oI the soItware queue, there is still the issue oI serialization delay. A
large packet may be on its way out oI the hardware TxQ, which is FIFO when a VoIP packet is
sent to the Iront oI the soItware queue. The serialization oI the large packet can cause the VoIP
packet to wait Ior a long time beIore it can be transmitted out.
For example, the serialization delay oI a 1500-byte packet over a 56-kbps link will be 214 ms.
For VoIP traIIic, the maximum recommended end-to-end delay is 150 ms. ThereIore, having a
1500-byte packet ahead oI a VoIP packet in the hardware TxQ on a 56-kbps link can cause the
end-to-end delay oI the voice packet to be over the budget oI 150 ms.
The solution to this problem is to Iragment the large packets so that they never cause a VoIP
packet to wait Ior more than a predeIined amount oI time. The VoIP packets must also be
allowed to transmit in between the Iragments oI the larger packets (interleaving), or there will
be no point in doing the Iragmenting.
When conIiguring the proper Iragment size to use on a link, a typical goal is to have a
maximum serialization delay oI around 10 to 15 milliseconds. Depending on the LFI
mechanisms being conIigured, the Iragment size is either conIigured in bytes or in
milliseconds.
· LFI reduces the deIay and jitter of smaII packets (for
exampIe, VoIP).
AppIying Link Efficiency Mechanisms
This topic identiIies the points in a network where link eIIiciency mechanisms can most
eIIectively be employed.
Header compression and LFI are typically conIigured at the WAN edge Ior WAN links below
T1 or E1 speeds to optimize the use oI the WAN link and to prevent long serialization delay.
Layer 2 payload compression is less commonly being deployed on WAN links, especially
without the use oI hardware-assisted payload compression.
AppIying Link Efficiency Mechanisms
Summary
References
For more inIormation on the link eIIiciency mechanisms, reIer to 'Link EIIiciency
Mechanisms Overview¨ at the Iollowing URL:
qcIlem.htm
For more inIormation on the Layer 2 payload compression, reIer to 'Understanding Data
Compression¨ at the Iollowing URL:
http://www.cisco.com/warp/public/116/compress¸overview.html
Summary
· Link efficiency mechanisms increase throughput
and decrease Iatency on sIow WAN Iinks.
· PayIoad compression uses a compression
aIgorithm to compress the payIoad of Layer 2
frames.
· Header compression reduces overhead by
compressing the IP and upper Iayer headers.
· LFI reduces the deIay and jitter of smaII packets
(for exampIe, VoIP).
Quiz
Q1) What are stacker, predictor, and MPPC?
A) Layer 2 payload compression methods
B) link Iragmentation and interleaving methods
C) TCP header compression methods
D) RTP header compression methods
Q2) RTP header compression is used to reduce the overhead oI which protocol header(s)?
A) only the RTP header
B) only the UDP and RTP headers
C) only the TCP and RTP headers
D) the IP, UDP, and RTP headers
E) the IP, TCP, and RTP headers
Q3) Using Layer 2 payload compression over a slow WAN link, which two statements are
true about the resulting overall total delay and perceived throughput? (Choose two.)
A) The overall total delay will always decrease because the packet sizes are
smaller resulting in lower serialization delay.
B) The overall total delay may increase due to compression/decompression delays
iI hardware-assisted compression is not used.
C) The perceived throughput is generally increased because the size oI the Layer 2
payload is reduced, thereIore allowing more Layer 2 Irames to be sent through
a transmission resource in a given time period.
D) The perceived throughput may be decreased due to
compression/decompression delays iI hardware-assisted compression is not
used.
Q4) How many bytes are in the RTP and UDP headers?
A) UDP ÷ 8 bytes. RTP ÷ 12 bytes.
B) UDP ÷ 8 bytes, RTP ÷ 20 bytes.
C) UDP ÷ 12 bytes, RTP ÷ 8 bytes.
D) UDP ÷ 12 bytes. RTP ÷ 20 bytes.
Q5) What problem does LFI solve?
A) A large packet in the soItware queue delaying a VoIP packet because the
soItware queue is FIFO.
B) The serialization delay oI VoIP packets over a slow WAN link.
C) The large overhead oI the VoIP packet protocol headers.
D) A large packet may be on its way out oI the hardware tx-queue which is FIFO
when a VoIP packet is sent to the Iront oI the soItware queue. The serialization
oI the large packet can cause the VoIP packet to wait Ior a long time beIore it
can be transmitted out.
Q6) What should be the target budget Ior the end-to-end delay oI VoIP packets to ensure
high voice quality?
A) 10 to 15 ms
B) 50 ms
C) 150 ms
D) 300 ms
Quiz Answer Key
Q1) A
ReIates to: Link Efficiency Mechanisms Overview
Q2) D
ReIates to: L2 Payload Compression
Q3) B, C
ReIates to: L2 Payload Compression
Q4) A
ReIates to: Header Compression
Q5) D
ReIates to: Link Fragmentation and Ìnterleaving
Q6) C
ReIates to: Large Packets ¨Freeze Out¨ Voice on Slow WAN Liinks
Class-Based Header
Compression
Overview
Headers exist on almost every communication layer oI the Open System Interconnection (OSI)
stack. When data is sent between workstations, headers will typically be applied at the session,
transport, network, and data link layers.
RTP is a protocol Ior the transport oI real-time data. RTP includes a data portion and a header
portion. The data portion oI RTP is a thin protocol that provides support Ior the real-time
properties oI applications, such as continuous media, including timing reconstruction, loss
detection, and content identiIication. The header portion oI RTP is considerably large,
especially when compared to the payload data that it supports. To avoid the unnecessary
consumption oI available bandwidth, RTP header compression (reIerred to as cRTP) is used on
a link-by-link basis.
TCP header compression is also supported on Cisco routers to reduce the overhead that is
associated with TCP and IP headers in TCP/IP packets. TCP header compression is most
eIIective Ior interactive traIIic with small packet size such as Telnet on slow WAN links.
Using the MQC method, Cisco IOS soItware supports class-based RTP and TCP header
compression so that the header compression can be perIormed on a speciIic traIIic class.
This lesson discusses both class-based RTP and class-based TCP header compression,
including conIiguration and monitoring.
ReIevance
To improve the WAN link eIIiciency, header compression can be used to reduce the overhead
oI the protocol headers. This is especially eIIective Ior packets having small payload, like VoIP
packets; and interactive TCP packets, like Telnet packets. Header compression is essential on
low-speed WAN links where voice transport is a requirement.
Objectives
Upon completing this lesson, you will be able to conIigure class-based TCP and class-based
RTP header compression to improve bandwidth eIIiciency and reduce delay. This includes
Explain the purpose oI header compression and provide some common reasons Ior its use
Roughly calculate the overhead that can be saved by using class-based TCP header
compression
Roughly calculate the overhead that can be saved on VoIP packets using class-based RTP
header compression
IdentiIy the Cisco IOS commands required to conIigure class-based header compression
IdentiIy the Cisco IOS commands used to monitor class-based header compression
Knowledge oI using MQC to implement Cisco QoS mechanisms
OutIine
OutIine
· Overview
· Header Compression Overview
· CIass-Based TCP Header Compression
· CIass-Based RTP Header Compression
· Configuring CIass-Based Header Compression
· Monitoring CIass-Based Header Compression
· Summary
· Quiz
Header Compression Overview
This topic explains the purpose oI header compression and provides some common reasons Ior
its use.
All compression methods are based on eliminating redundancy when sending the same or
similar data over a transmission medium. One piece oI data, which is oIten repeated, is the
protocol header. In a Ilow, the header inIormation oI packets in the same Ilow does not change
much over the liIetime oI that Ilow. ThereIore, most oI header inIormation could be sent only at
the beginning oI the session, stored in a dictionary, and then reIerenced in later packets by a
short dictionary index.
Two methods were standardized by the Internet Engineering Task Force (IETF) Ior use with IP
protocols:
TCP header compression (also known as the Van Jacobson or VJ header compression) is
used to compress the packet IP and TCP headers over slow links, thus considerably
improving the interactive application perIormance.
RTP header compression is used to compress the packet IP, UDP, and RTP headers, thus
lowering the delay Ior transporting real-time data, such as voice and video over slower
links.
When TCP and RTP header compression is enabled, it occurs by deIault in the Iast-switched
path or the Cisco Express Forwarding (CEF)-switched path, depending on which switching
method is enabled on the interIace.
Class-based header compression enables RTP or TCP header compression on a per-class basis.
This Ieature was introduced in Cisco IOS release 12.2(13)T.
Header Compression Overview
· TCP header compression and CB-TCP header
compression:
÷ Compresses IP and TCP headers
÷ Used to reduce the overhead of TCP segments
÷ Most effective on sIow Iinks with a Iot of TCP sessions with smaII
payIoads (for exampIe, TeInet)
· RTP header compression and CB-RTP header
compression:
÷ Compresses IP, UDP, and RTP headers
÷ Used to reduce deIay and increase throughput for RTP
÷ Improves voice quaIity
÷ Most effective on sIow Iinks
· CB header compression - IOS 12.2(13)T.
· Header compression is enabIed on a Iink-by-Iink basis.
Note: Ìt is important to note that header compression is performed on a link-by-link basis. Header
compression cannot be performed across multiple routers because routers need full Layer 3
header information to be able to route packets to the next hop.
ExampIe: RTP Header Compression
RTP header compression is oIten implemented on WAN links to reduce the IP/UDP/RTP
header overhead Ior VoIP packets. Reducing the protocol header overhead will result in
increased throughput and decrease in serialization delay.
CIass-Based TCP Header Compression
This topic roughly calculates the overhead that can be saved by using class-based TCP header
compression.
With TCP header compression, the IP and TCP headers, which normally use 20 bytes each, is
reduced to a session index, and the changing part oI the header. With all optimizations, the
combined header length oI 40 bytes can be reduced to a 3 to 5-byte compressed header.
Class-based TCP header compression enables TCP header compression on a per-class basis,
when a class is conIigured within a policy map. Policy maps are created using the modular
Quality oI Service (QoS) Command-Line InterIace (CLI) (MQC). The policy maps are attached
to an interIace by using the service-policy command. The service-policy command gives
customers the option oI speciIying either an input service policy (Ior input interIaces), or an
output service policy (Ior output interIaces). For this Ieature, only output service policies can be
speciIied.
Enabling TCP header compression on an interIace applies header compression to all TCP Ilows
out oI the interIace. II TCP compression is enabled on a link, there is no mechanism to restrict
its Iunction to speciIic application types. TCP header compression Ior bulk data transIer
(packets with a large payload) yields little bandwidth savings. Using the newer class-based
TCP header compression, TCP header compression can be perIormed only on certain traIIic
classes; Ior example, only perIorm TCP header compression on the interactive traIIic class
where the packet payload sizes are small.
CIass-Based TCP Header Compression
· Most Internet appIications use TCP as the transport
protocoI.
· Most of the information in the headers (IP and TCP) is
static or predictabIe throughout the session.
· IP (20 bytes) and TCP (20 bytes) use 40 bytes.
· TCP header compression can squeeze these two headers
into 3 to 5 bytes.
· CIass-based TCP header compression aIIows
compression on a traffic cIass.
· CIass-based TCP header compression is configured via
MQC.
ExampIe: CIass-Based TCP Header Compression
This example illustrates the beneIits oI TCP header compression on slow links. A 64-kbps link
is used to transport a TCP-based application using PPP as the Layer 2 Iraming protocol. For the
case study application (Telnet), the average packet payload size is 5 bytes. Because PPP has 6
bytes oI Irame header, the total header overhead is 6 ¹ 20 ¹ 20 ÷ 46 bytes, counting the PPP,
IP, and TCP headers.
CIass-Based TCP Header
Compression ExampIe
· Link bandwidth is 64 kbps.
· The Iink is used for a number of interactive TCP
sessions.
· PPP encapsuIation is used.
· Average packet size is 5 bytes.
· Each segment has 46 bytes of overhead
(PPP, IP, and TCP headers).
The Iigure shows the packet size beIore and aIter TCP header compression. AIter TCP header
compression, the IP and TCP headers are reduced to 4 bytes, resulting in 10 bytes oI overall
headers. The overhead is reduced Irom 90 percent to 67 percent, when small packets are used.
Because oI the packet size reduction, the serialization delay decreases Irom 6 ms to 2 ms on the
same 64-kbps link.
The table in the Iigure shows how TCP header compression impacts perIormance when
diIIerent packet sizes are used. TCP header compression is most eIIective on small packets, and
is oIten used on slow links.
CIass-Based TCP Header
Compression ExampIe (Cont.)
CIass-Based RTP Header Compression
This topic roughly calculates the overhead that can be saved on VoIP packets using class-based
RTP header compression.
RTP is the Internet standard (RFC 1889) protocol Ior the transport oI real-time data. It is
intended to provide end-to-end network transport Iunctions Ior applications that support audio,
video, or simulation data over multicast or unicast network services. RTP is used in most VoIP
applications to transport voice packets.
RTP includes a data portion and a header portion. The data portion oI RTP is a thin protocol
that provides support Ior the real-time properties oI applications, such as continuous media, and
includes timing reconstruction, loss detection, and content identiIication. RTP contains a
relatively large-sized header. The 12 bytes oI the RTP header, combined with 20 bytes oI IP
header and 8 bytes oI the UDP header, create a 40-byte IP/UDP/RTP header. For compressed-
payload audio applications, the RTP packet typically has a 20-byte to 160-byte payload
depending on the audio compression codec. Given the size oI the IP/UDP/RTP header
combinations, it is ineIIicient to send the IP/UDP/RTP header without compressing it.
To avoid the unnecessary consumption oI available bandwidth, the RTP header compression
Ieature (cRTP) is used on a link-by-link basis. cRTP can reduce the header Irom 40 bytes to a
2- or 4-byte header, which signiIicantly reduces delay on slow links.
Class-based RTP header compression enables RTP header compression on a per-class basis,
when a class is conIigured within a policy map. Policy maps are created using the MQC. The
policy maps are attached to an interIace by using the service-policy command. The service-
policy command gives customers the option oI speciIying either an input service policy (Ior
input interIaces), or an output service policy (Ior output interIaces). For this Ieature, only output
service policies can be speciIied.
CIass-Based RTP Header Compression
· Voice sessions use ReaI-time Transport ProtocoI (RTP).
· RTP uses UDP, for transport.
· Most of the information in the headers (IP, UDP and RTP)
is static throughout the session.
· IP (20 bytes), UDP (8 bytes), and RTP (12 bytes) use 40
bytes.
· RTP header compression can squeeze these three
headers into 2 or 4 bytes.
· CIass-based RTP header compression aIIows
compression on a traffic cIass.
· CIass-based RTP header compression is configured via
MQC.
ExampIe: CIass-Based RTP Header Compression
CIass-Based RTP Header
Compression ExampIe
· Link bandwidth is 64 kbps.
· The Iink is used for VoIP.
· PPP encapsuIation is used.
· G.729 codec is used (8 kbps of voice data, 50
sampIes per second, 20 bytes per sampIe).
· Each segment has 46 bytes of overhead (PPP,
IP, UDP, and RTP headers).
This example illustrates the beneIits oI RTP header compression on slow links.
A 64-kbps link is used to transport VoIP using PPP as the Layer 2 Iraming protocol.
For the case study application (voice using the G.729 audio compression codec), the payload
size is 20 bytes. Because PPP has 6 bytes oI Irame header, the total header overhead is 6 ¹ 20 ¹
8 ¹ 12 ÷ 46 bytes, counting the PPP, IP, UDP, and RTP headers.
The Iigure shows the packet size beIore and aIter RTP header compression. The IP, UDP, and
RTP headers are reduced to 4 bytes, resulting in 10 bytes oI overall headers. The overhead is
reduced Irom 70 percent to 33 percent, when small packets are used. Because oI the packet size
reduction, the serialization delay decreases Irom 8 ms to 4 ms, and the bandwidth that is used to
transport a single voice call (using the G.729 codec) is reduced Irom 26.4 kbps (66 bytes/Irame
* 50 Irames/sec * 8 bits/byte) to 12 kbps (30 bytes/Irame * 50 Irames/sec * 8 bits/byte).
ThereIore, a 64-kbps link can support up to two G.729 voice calls without cRTP, but up to Iive
G.729 voice calls with cRTP.
The table in the Iigure shows how RTP header compression impacts perIormance when a
diIIerent audio codec is used. For the traditional G.711 voice codec, RTP header compression
still optimizes its transmission over slow links. However, the diIIerence is more obvious when
using advanced, low-bandwidth codecs.
CIass-Based RTP Header
Compression ExampIe (Cont.)
Configuring CIass-Based Header Compression
This topic identiIies the Cisco IOS commands that are required to conIigure class-based header
compression.
Class-based TCP and RTP header compression is conIigured within a policy map using the
compression header ip command.
II you do not speciIy either RTP or TCP header compression (that is, you simply enter a
carriage return aIter the compression header ip command), then both RTP and TCP header
compression will be conIigured.
Configuring CIass-Based Header
Compression
compression header ip (rtp | tcp ) compression header ip (rtp | tcp )
· EnabIes RTP or TCP IP header compression for a specific
traffic cIass
· If the rtp or tcp options are not specified, both RTP and
TCP header compressions are configured
· The number of concurrent compressed connections is
autonegotiated up to 1000
· Can be used at any IeveI in the poIicy map hierarchy
configured with MQC
ExampIe: Configuring CIass-Based TCP Header Compression
In the Iigure, the compression header ip command has been conIigured to use TCP header
compression Ior a traIIic class called 'interactive¨. The 'interactive¨ traIIic class is part oI
policy map called 'cust1¨. This 'cust1¨ policy map is applied to the s0/0 interIace in the
outbound direction.
This policy provides a minimum bandwidth guarantee oI 64 kbps Ior the 'interactive¨ traIIic
class and will perIorm TCP header compression on the 'interactive¨ traIIic class (all Telnet
packets in this example) leaving the s0/0 interIace.
ExampIe: Configuring CIass-Based
TCP Header Compression
class~map interactive
match protocol telnet
!
policy~map cust1
class interactive
bandwidth 64
compression header ip tcp
!
<output omitted>
!
int s0/0
service~policy output cust1
<output omitted>
ExampIe: Configuring CIass-Based RTP Header Compression
In the Iigure, the compression header ip command has been conIigured to use RTP header
compression Ior a traIIic class called 'voip¨. The 'voip¨ traIIic class is part oI policy map
called 'cust1¨. This 'cust1¨ policy map is applied to the s0/0 interIace in the outbound
direction.
This policy provides a maximum bandwidth guarantee oI 384 kbps Ior the 'voip¨ traIIic class
and will perIorm RTP header compression on the 'voip¨ traIIic class (all RTP packets in this
example) leaving the s0/0 interIace.
ExampIe: Configuring CIass-Based
RTP Header Compression
class~map voip
match protocol rtp
!
policy~map cust1
!
class voip
priority 384
compression header ip rtp
!
<output omitted>
!
int s0/0
service~policy output cust1
<output omitted>
Monitoring CIass-Based Header Compression
This topic identiIies the Cisco IOS commands that are used to monitor class-based header
compression.
The show policy-map interface command output displays the type oI header compression
conIigured (RTP in this example), the interIace to which the policy map called 'cust1¨ is
attached (serial 0/0), the number oI packets sent, the number oI packets compressed, the
number oI bytes saved, and the number oI bytes sent.
Other statistical inIormation provided in the output includes the 'eIIiciency improvement
Iactor,¨ which indicates the percentage oI increased bandwidth eIIiciency as a result oI header
compression. For example, an 'eIIiciency improvement Iactor¨ oI 3.33 means 330 percent
eIIiciency improvement. The 'hit ratio¨ is the percentage oI packets that are Iound in the
context database. In most instances, this percentage should be high. The 'Iive-minute miss
rate¨ is the number oI traIIic Ilows in the last Iive minutes that were Iound in the context
database. The rate is the actual traIIic rate aIter the packets are compressed.
Monitoring CIass-Based Header
Compression
router>show policy~map interface Serial 0/0
Serial0/0
Service~policy output:cust1
Class~map: voip (match~all)
Match:protocol rtp
Queueing
Strict Priority
(total drops/bytes drops) 0/0compress:
compress:
header ip rtp
UDP/RTP Compression:
Sent:1000 total, 999 compressed,
41957 bytes saved, 17983 bytes sent
3.33 efficiency improvement factor
99% hit ratio, five minute miss rate 0 misses/sec, 0 max rate 5000 bps
router>
· DispIays the packet statistics of aII cIasses configured for
aII service poIicies on the specified interface
Summary
References
For more inIormation on TCP and RTP header compression, reIer to the Iollowing RFCs:
RFC 2508 (RTP header compression)
RFC 1144 (TCP header compression)
For more inIormation on Cisco class-based TCP and RTP header compression, reIer to
'Class-Based RTP and TCP Header Compression¨ at the Iollowing URL:
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios122/122newIt/122t/122t13/It
hdrcmp.htm#wp1044256
Next Steps
Lab Exercise 8-1: ConIiguring Class-Based Header Compression
Summary
· TCP and RTP are two header compression methods.
· CIass-based header compression is avaiIabIe on IOS
12.2(13)T.
· TCP header compression compresses the IP and TCP
headers.
· RTP header compression compresses the IP, UDP, and
RTP headers.
· Header compression is most effective on sIow Iinks.
Quiz
Q1) By deIault, iI RTP or TCP is not speciIied with the compression header IP command,
which header compression will be enabled?
A) none
B) RTP header compression only
C) TCP header compression only
D) both RTP and TCP header compression.
Q2) Typically, class-based TCP header compression should be perIormed on WAN links
Ior which traIIic class?
A) interactive traIIic class
B) VoIP traIIic class
C) bulk traIIic class
D) RTP traIIic class
Q3) RTP uses which transport layer protocol?
A) TCP
B) UDP
C) SPX
D) RTCP
Q4) cRTP can reduce the IP/UDP/RTP header to how many byte(s)?
A) 1 byte
B) 2 or 4 bytes
C) 4 or 8 bytes
D) 6 or 12 bytes
Q5) From the show policy-map interface command, what is the 'hit ratio¨?
A) the percentage oI packets Iound in the context database
B) the percentage oI packets matched by the class map
C) the percent oI packets being policy routed
D) the percent oI packets not compressed
Q6) What is incorrect about the Iollowing class-based RTP header compression
conIiguration?
class-map voip
match protocol rtp
!
policy-map compress-me
class voip
priority ·84
compression header ip rtp
!
Interface serial 0
service-policy input compress-me
!
A) The tcp parameter is missing in the compression header ip rtp command.
B) The priority command can not be used in conjunction with the compression
header ip command in the policy map.
C) The service-policy should be applied to the output not the input.
D) Nothing is incorrect about the conIiguration.
Quiz Answer Key
Q1) D
ReIates to: Configuring Class-Based Header Compression
Q2) A
ReIates to: Class-Based TCP Header Compression
Q3) B
ReIates to: Header Compression Overview
Q4) B
ReIates to: Class-Based RTP Header Compression
Q5) A
ReIates to: Monitoring Class-Based Header Compression
Q6) C
ReIates to: Configuring Class-Based Header Compression
Link Fragmentation and
Ìnterleaving
Overview
Because the hardware TxQ is a FIFO queue, having a large packet like a FTP packet in Iront oI
a small packet like a VoIP packet can cause excessive delay Ior the VoIP packet. LFI allows
the large packets to be Iragmented into smaller Iragments, and then the small unIragmented
packets are interleaved in between the Iragments. LFI reduces the delay and jitter oI small
packets like VoIP packets over a WAN link.
This lesson discusses the conIiguration and monitoring oI two diIIerent LFI mechanisms
supported in Cisco IOS soItware, MLP with interleaving and FRF.12.
ReIevance
Improving the eIIiciency oI WAN links is important in that it can improve response times,
reduce delays, and extend the longevity oI some slower WAN links. To improve the WAN link
eIIiciency, link Iragmentation and interleaving techniques can be used to reduce the delays that
are incurred by small interactive traIIic types that are waiting in queues as large data Irames are
transmitted. LFI techniques are especially eIIective Ior VoIP packets and interactive TCP
packets like Telnet packets.
Objectives
Upon completing this lesson, you will be able to conIigure LFI to improve bandwidth
eIIiciency and reduce delay. This includes being able to meet these objectives:
IdentiIy the diIIerent options available Ior link Iragmentation
Given a list oI link speeds and a speciIic delay requirement, determine the proper Iragment
size to use at each link speed and identiIy the typical delay requirement Ior VoIP packets
IdentiIy the Cisco IOS commands required to conIigure MLP with interleaving
IdentiIy the Cisco IOS commands used to monitor MLP with interleaving
Explain when FRF.12 can be used and explain how FRF.12 aIIects VoIP packets
IdentiIy the Cisco IOS commands required to conIigure FRF.12
IdentiIy the Cisco IOS commands required to monitor FRF.12
Knowledge oI basic PPP operation and conIiguration on Cisco IOS routers
Knowledge oI basic Frame Relay operation and conIiguration on Cisco IOS routers
OutIine
OutIine
· Overview
· Fragmentation Options
· SeriaIization DeIay and Fragment Sizing
· Configuring MLP with InterIeaving
· Monitoring MLP with InterIeaving
· FRF.12 Frame ReIay Fragmentation
· Configuring FRF.12 Frame ReIay Fragmentation
· Monitoring FRF.12 Frame ReIay Fragmentation
· Summary
· Quiz
Fragmentation Options
This topic identiIies the diIIerent options that are available Ior link Iragmentation.
LFI is a Layer 2 technique, where all Layer 2 Irames are broken into small, equal-size
Iragments, and transmitted over the link in an interleaved Iashion. LFI reduces delay and jitter
by expediting transIer oI smaller Irames through the hardware TxQ.
There are three LFI mechanisms implemented in Cisco IOS soItware:
MLP with interleaving is by Iar the most common and widely used Iorm oI LFI.
FRF.12 Frame Relay LFI is used with Frame Relay data connections.
FRF.11 Annex C LFI is used with Voice over Frame Relay (VoFR).
Note: For configurations information on FRF.11.C, refer to the latest Cisco ÌOS documentation.
Fragmentation Options
· Cisco IOS LFI mechanisms incIude:
÷ MuItiIink PPP with InterIeaving: PPP Links
÷ FRF.12: FR PVC carrying data traffic
incIuding VoIP over FR traffic
÷ FRF.11.C: FR PVC carrying VoFR traffic
SeriaIization DeIay and Fragment Sizing
This topic describes the proper Iragment size to use on links based on their speed and identiIies
the typical delay requirements Ior VoIP packets.
Serialization delay is the Iixed delay required to clock a voice or data packet onto the network
interIace. Serialization delay is directly related to the link speed and the size oI the packet.
This Iigure shows the serialization delay as a Iunction oI the link speed and packet size. For
example, the serialization delay Ior a 1500-byte packet over a 64-kbps link will be:
(|1500 bytes * 8 bits/byte|/64 kbps) ÷ 187 ms
To ensure low delay and jitter Ior voice packets on slow links, the recommended standard goal
Ior serialization delay is around 10 to 15 ms. ThereIore, on a T1 or higher speed link, LFI is not
necessary since the serialization delay Ior a 1500-byte packet is only 7.5 ms on a T1 link. T1
link has a bandwidth oI 1536 kbps excluding the T1 Iraming overheads.
SeriaIization DeIays
· For 1500-byte packets, fragmentation is not necessary above T1 (1.5M)
To meet the standard serialization delay goal oI 10 to 15 ms to ensure low delay and jitter Ior
voice packets, a Iragment size oI about 80 bytes per every 64 kbps oI the clocking rate Ior the
interIace should be conIigured.
Depending on the LFI mechanism, the Iragment size is either conIigured in bytes or in ms. For
example, MLP LFI maximum Iragment size is conIigured in ms while FRF.12 maximum
Iragment size is conIigured in bytes.
ExampIe: Determining the Proper Fragment Size
On a 64-kbps link, the proper Iragment size to use is 80 bytes.
On a 128-kbps link, the proper Iragment size to use is 160 bytes (80 * 2).
And so on.
Fragment Size Recommendation
for Voice
Configuring MLP with InterIeaving
This topic identiIies the Cisco IOS commands required to conIigure MLP with interleaving.
To conIigure MLP with interleaving, the Iollowing conIiguration steps must be perIormed:
Step 1 Enable MLP on a PPP interIace.
Step 2 On the multilink interIace, enable interleaving within MLP.
Step 3 In the multilink interIace conIiguration, speciIy the maximum Iragment size by
speciIying the maximum desired serialization delay in ms.
Configuration steps:
· EnabIe MLP on an interface (using a muItiIink
group interface)
· EnabIe MLP interIeaving on the muItiIink
interface
· Specify maximum fragment size by setting the
maximum deIay on the muItiIink interface
The ppp multilink command enables MLP on a PPP interIace.
The ppp multilink interleave command enables interleaving oI Iragments within the multilink
connection.
The ppp multilink fragment-delay command speciIies the maximum desired Iragment delay
Ior the interleaved multilink connection. The maximum Iragment size is calculated Irom the
interIace bandwidth and the speciIied maximum delay. The deIault is set at 30 ms. To support
voice packets, a maximum Iragment size oI 10 to 15 ms should be used.
II distributed Cisco Express Forwarding (dCEF) is conIigured on a Versatile InterIace
Processor (VIP) interIace, MLP with interleaving will run in distributed mode on the VIP.
ppp multilink ppp multilink
router(config~if)#
· EnabIes MLP
ppp multilink interleave ppp multilink interleave
router(config~if)#
· EnabIes interIeaving of frames with fragments
ppp multilink fragment~delay delay ppp multilink fragment~delay delay
router(config~if)#
· Configure maximum fragment deIay in ms
· The router caIcuIates the maximum fragment size from the
interface bandwidth and the maximum fragment deIay
· Fragment Size = Interface Bandwidth * maximum fragment deIay
· DefauIt maximum fragment deIay is 30 ms
ExampIe: MLP with InterIeaving
The Iigure shows an example conIiguration oI MLP with interleaving on a multilink group
interIace. A non-deIault maximum desired delay oI 10 ms is conIigured.
MLP with InterIeaving ExampIe
interface Multilink1
ip address 172.22.130.1 255.255.255.252
fair~queue
ppp multilink
multilink~group 1
bandwidth 128
!
interface Serial0/0
no ip address
encapsulation ppp
ppp multilink
multilink~group 1
Monitoring MLP with InterIeaving
This topic identiIies the Cisco IOS commands that are used to monitor MLP with interleaving.
The show interface multilink command output includes MLP LFI statistics inIormation and
indicates whether MLP interleaving is enabled on the interIace. Multilink should be in the open
state along with link control protocol (LCP) and IP Control Protocol (IPCP).
Monitoring MLP InterIeaving
show interfaces multilink interface~number show interfaces multilink interface~number
router>
· DispIays MLP statistics incIuding the number of interIeaved frames
router>show interfaces multilink 1
Multilink1 is up, line protocol is up
Hardware is multilink group interface
MTU 1500 bytes, BW 64 Kbit, DLY 100000 usec,
reliability 255/255, txload 27/255, rxload 1/255
Fncapsulation PPP, loopback not set
Keepalive set (10 sec)
DTR is pulsed for 2 seconds on reset
LCP open, multilink open
open: IPCP
Last input 00:00:03, output never, output hang never
Last clearing of "show interface" counters 6d00h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
output queue: 0/1000/64/0/2441 (size/max total/threshold/drops/interleaves)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 7000 bits/sec, 6 packets/sec
The debug ppp multilink fragments command is a valuable troubleshooting tool when
monitoring MLP LFI operations. This command outputs the result oI every Iragmentation
operation, indicating whether the packets are Iragmented into correct-sized Iragments. This
command should be used with extreme caution in a production environment, because oI the
amount oI output that is created.
Monitoring MLP InterIeaving (Cont.)
debug ppp multilink fragments debug ppp multilink fragments
router#
· DispIays information about individuaI muItiIink fragments and
interIeaving events
router#debug ppp multilink fragments
Multilink fragments debugging is on
Mar 17 20:03:08.995: Se0/0 MLP~FS: I seq C0004264 size 70
Mar 17 20:03:09.015: Se0/0 MLP~FS: I seq 80004265 size 160
Mar 17 20:03:09.091: Se0/0 MLP~FS: I seq C0004269 size 70
Mar 17 20:03:09.099: Se0/0 MLP~FS: I seq C000426A size 70
Mar 17 20:03:09.103: Mu1 MLP: Packet interleaved from queue 24
Mar 17 20:03:09.107: Se0/0 MLP~FS: I seq C000426B size 70
Mar 17 20:03:09.119: Se0/0 MLP~FS: I seq C000426C size 70
Mar 17 20:03:09.135: Se0/0 MLP~FS: I seq C000426D size 70
Mar 17 20:03:09.155: Se0/0 MLP~FS: I seq C000426F size 70
FRF.12 Frame ReIay Fragmentation
This topic explains when FRF.12 can be used and how FRF.12 aIIects VoIP packets.
FRF.12 is the recommended Iragmentation to be used with VoIP over Frame Relay while
FRF.11c is the recommended Iragmentation to be used with VoFR.
The FRF.12 Implementation Agreement deIines FRF.12 Iragmentation. The FRF.12
Implementation Agreement was developed to allow long data Irames to be Iragmented into
smaller pieces and interleaved with real-time Irames. In this way, real-time voice and non-real-
time data Irames can be carried together on lower-speed Frame Relay links without causing
excessive delay and jitter to the real-time traIIic like VoIP.
Because Frame Relay is a Layer 2 protocol, it has no way to tell which Irame contains voice
(VoIP) or data. ThereIore, it will Iragment all packets larger than the Iragment size into smaller
Irames, including VoIP packets. In a VoIP over Frame Relay network, it is important to
conIigure the Iragment size on the data-link connection identiIier (DLCI) so that VoIP Irames
will not get Iragmented. For example, a G.711 VoIP packet without cRTP is 200 bytes long.
For this DLCI, do not set the Iragment size to less than 200 bytes.
Frame Relay permanent virtual circuits (PVCs) not conIigured Ior VoFR use normal Frame
Relay (FRF.3.1) data encapsulation. II Iragmentation is turned on Ior this DLCI, it uses FRF.12
Ior the Iragmentation headers.
FRF.12 specifies fragmentation of Frame ReIay
data frames:
· Frame ReIay data frames that exceed the specified
fragmentation size are fragmented
· SmaIIer time-sensitive packets can be interIeaved
· This is the recommended Frame ReIay fragmentation
method to be used with VoIP over Frame ReIay
· Fragments VoIP over Frame ReIay packets if the fragment
size is set to a vaIue smaIIer than the voice packet size
· FRF.12 requires FRTS or DTS
FRF.12 speciIies three types oI Iragmentation, oI which only one Iorm is supported in Cisco
IOS soItware:
End-to-end: Supported in Cisco IOS soItware
Packets contain the FRF.12 Iragmentation header
Occurs at the PVC level
LMI packets are not Iragmented
UNI: Not supported in Cisco IOS soItware releases
NNI: Not supported in Cisco IOS soItware releases
FRF.12 is conIigured on a per-PVC basis. It should be noted that iI one PVC or subinterIace
has Iragmentation but another does not (on the same physical interIace), large packets can and
will delay smaller packets. For applications where Iragmentation is needed, all PVCs or
subinterIaces that carry large packets must have Iragmentation turned on. FRF.12
Iragmentation is conIigured within a Frame Relay map class using the frame-relay fragment
command. The conIigured map class is then associated to the speciIic DLCIs. In addition, you
must enable Frame Relay traIIic shaping (FRTS) on the interIace in order Ior FRF.12
Iragmentation to work.
Cisco IOS release 12.1(5)T introduced a distributed version oI FRF.12 Frame Relay
Iragmentation to use with DTS (distributed traIIic shaping).
Configuring FRF.12 Frame ReIay Fragmentation
This topic identiIies the Cisco IOS commands that are required to conIigure FRF.12.
FRF.12 Iragmentation is conIigured within the Frame Relay map class. The frame-relay
fragment command sets the maximum Iragment size in bytes. On an interIace, the frame-relay
class command applies the map class to the interIace, subinterIace, or a DLCI.
FRF.12 also requires FRTS to be enabled.
Configuring FRF.12 Frame ReIay
Fragmentation
map~class frame~relay map~class~name map~class frame~relay map~class~name
router(config)#
· Specifies a map cIass to define QoS vaIues for a virtuaI circuit
frame~relay fragment fragment~size frame~relay fragment fragment~size
router(config~map~class)#
· EnabIes fragmentation of Frame ReIay frames for a Frame ReIay
map cIass
· Set the maximum fragment size in bytes
frame~relay class name frame~relay class name
router(config~if)# | (config~subif)# | (config~fr~dlci)#
· Associates a map cIass with an interface or subinterface or DLCI
ExampIe: FRF.12 Frame ReIay Fragmentation
The Iigure shows a conIiguration example where FRF.12 Iragmentation is applied to a data
Frame Relay circuit conIigured on the serial 0/0.1 subinterIace. The maximum Iragment size is
also set to 80 bytes. This would be used in a VoIP over Frame Relay environment.
FRF.12 also requires FRTS to be enabled. FRTS is enabled on the interIace and the FRTS
token bucket parameters are conIigured within the Frame Relay map class. In this Iigure, FRTS
is enabled with a committed inIormation rate (CIR) oI 64 kbps, a committed burst (Bc) (normal
burst size) oI 2600 bits and uses weighted Iair queuing (WFQ) as the shaping queue.
ExampIe
encapsulation frame~relay
frame~relay traffic~shaping
!
interface serial 0/0.1 point~to~point
frame~relay interface~dlci 100
class FRF12
!
map~class frame~relay FRF12
frame~relay fragment 80
!FRTS parameters
frame~relay cir 64000
frame~relay bc 2600
frame~relay fair~queue
Monitoring FRF.12 Frame ReIay Fragmentation
This topic identiIies the Cisco IOS commands that are required to monitor FRF.12.
The show frame-relay fragment command displays inIormation about the FRF.12 Frame
Relay Iragmentation process. The Iragment type will always display end-to-end because this is
the only type presently supported on Cisco IOS soItware. In addition to Iragment type, the
Iragment size in bytes and associated DLCI is displayed.
Monitoring FRF.12 Frame ReIay
Fragmentation
show frame~relay fragment (interface interface (DLCI)) show frame~relay fragment (interface interface (DLCI))
router>
router>show frame~relay fragment
interface dlci frag~type frag~size in~frag out~frag dropped~frag
Serial0/0.1 100 end~to~end 80 0 0 0
· DispIays information about the Frame ReIay fragmentation
The show frame-relay pvc command output includes settings related to the FRF.12
Iragmentation process. This output shows the Iragment size (80 bytes in this example), used on
the Frame Relay PVC. The Iragment type is end-to-end because Cisco IOS soItware currently
only supports end-to-end FRF.12 Iragmentation.
Monitoring FRF.12 Frame ReIay
Fragmentation (Cont.)
show frame~relay pvc (interface interface) (dlci) show frame~relay pvc (interface interface) (dlci)
router>
· DispIays statistics about PVCs for Frame ReIay interfaces
router>show frame~relay pvc 100
PVC Statistics for interface Serial0/0 (Frame Relay DTF)
DLCI = 100, DLCI USAGF = LoCAL, PVC STATUS = INACTIVF, INTFRFACF = Serial0/0.1
<output omitted>
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
output queue size 0/max total 600/drops 0
fragment type end~to~end fragment size 80
cir 64000 bc 2600 be 0 limit 325 interval 40
mincir 32000 byte increment 320 BFCN response no IF_CoNG no
frags 0 bytes 0 frags delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Summary
References
For more inIormation on FRF.12 and DTS conIiguration, reIer to 'Frame Relay TraIIic
Shaping With Distributed QoS¨ at the Iollowing URL:
http://www.cisco.com/warp/public/105/distribIrts.html#topic2°20URL
For inIormation on FRF.11c, reIer to 'VoFR Encapsulation and Fragmentation¨ at the
Iollowing URLs:
http://www.cisco.com/warp/public/788/voip/voIr¸encap¸Irag¸5733.html
http://www.cisco.com/univercd/cc/td/doc/product/soItware/ios121/121newIt/121limit/121e/
121e2/voIvip/voIr3vip.htm
Next Steps
Lab Exercise 8-2: ConIiguring LFI
Summary
· LFI improves the seriaIization deIay for packets Ieaving the
router and prevents the voice packets from waiting on Iarge
data packets to be processed.
· InterIeaving on MLP aIIows Iarge packets to be fragmented into
a smaII enough size to satisfy the deIay requirements of reaI-
time traffic. SmaII reaI-time packets are not fragmented
and are sent between fragments of the Iarge packets.
· FRF.12 stipuIates that when fragmentation is turned on for a
DLCI, onIy data frames that exceed the specified fragmentation
size are fragmented. This arrangement aIIows smaII VoIP
packets, which are not fragmented due to their size, to be
interIeaved as frames between Iarge data packets that have
been fragmented into smaIIer frames.
· To ensure Iow deIay and jitter for voice packets on sIow Iinks,
the recommended standard goaI for seriaIization deIay is
around 10 to 15 ms.
Quiz
Q1) On a 64-kbps link, what is the proper Iragment size (in bytes) to use?
A) 10 bytes
B) 20 bytes
C) 80 bytes
D) 160 bytes
Q2) How is the Iragment size conIigured with multilink PPP and with FRF.12?
A) in bytes Ior FRF.12 and in milliseconds Ior multilink PPP
B) in milliseconds Ior FRF.12 and in bytes Ior multilink PPP
C) both in milliseconds
D) both in bytes
Q3) FRF.12 requires what else to be conIigured?
A) FRTS
B) FRF.11c
C) Multilink PPP
D) Frame Relay Inverse-Arp
E) LMI
Q4) With FRF.12, iI the Iragment size is set too small, what can happen to VoIP packets
that are bigger than the Iragment size?
A) The VoIP packets will be dropped.
B) The VoIP packets will not be Iragmented because Cisco IOS soItware will
automatically increase the Iragment size.
C) The VoIP packets will not be Iragmented and will be interleaved with the other
Iragments.
D) The VoIP packets will also be Iragmented.
Q5) When enabling Multilink PPP, interleaving is also enabled by deIault.
A) true
B) Ialse
Q6) Complete the Iollowing FRF.12 conIiguration:
_____________________
!
interface serial 0/0.I point-to-point
______________________
!
map-class frame-relay FRFI?
_______________________
!
!FRTS parameters
!
frame-relay cir 84000
frame-relay bc ?800
frame-relay fair-queue
Quiz Answer Key
Q1) C
ReIates to: Serialization Delay and Fragment Sizing
Q2) A
ReIates to: Fragmentation Options
Q3) A
ReIates to: Configuring FRF.12 Frame Relay Fragmentation
Q4) D
ReIates to: FRF.12 Frame Relay Fragmentation
Q5) B
ReIates to: Configuring MLP with Ìnterleaving
Q6)
frame~relay traffic~shaping
!
interface serial 0/0.I point-to-point
class FRF12
!
map-class frame-relay FRFI?
frame~relay fragment 80
!FRTS parameters
frame-relay cir 84000
frame-relay bc ?800
frame-relay fair-queue
ReIates to: Configuring FRF.12 Frame Relay Fragmentation
Module Assessment
Overview
Quiz: Link Efficiency Mechanisms
Objectives
Explain how link eIIiciency mechanisms can be used to improve bandwidth eIIiciency and
reduce delay
ConIigure class-based TCP and class-based RTP header compression to improve
bandwidth eIIiciency and reduce delay
ConIigure LFI to improve bandwidth eIIiciency and reduce delay
Instructions
incorrectly.
Q1) With Layer 2 payload compression, what can be done to improve the
compression/decompression delay oI the router?
A) enable CEF switching
B) enable Iast switching
C) use the stacker or predictor compression algorithm
D) use hardware-assisted compression
Q2) Which three oI the Iollowing statements about FRF12 and FRF11.C are correct?
(Choose three.)
A) FRF.12 Iragmentation is used on DLCIs conIigured Ior VoIP.
B) FRF.12 Iragmentation is used on DLCIs conIigured Ior VoFR.
C) FRF.11c Iragmentation is used on DLCIs conIigured Ior VoIP.
D) FRF.11c Iragmentation is used on DLCIs conIigured Ior VoFR.
E) FRF.12 Iragmentation requires FRTS to be enabled.
F) Cisco IOS soItware supports UNI and NNI FRF.12 Iragmentation and not end-
to-end Iragmentation.
Q3) When conIiguring multilink PPP with interleaving, where is the Iragment size
conIigured?
A) The Iragment size in milliseconds is conIigured under the physical serial
interIaces with PPP encapsulation and multilink PPP enabled.
B) The Iragment size in milliseconds is conIigured under the logical multilink
interIace.
C) The Iragment size in bytes is conIigured under the map-class.
D) The Iragment size in bytes is conIigured within the policy-map.
Q4) Which two Iactors will inIluence the serialization delay? (Choose two.)
A) link speed
B) speed oI the light in the media
C) router CPU processing power
D) packet size
Q5) To ensure good voice quality, what is the recommended Iragment size?
A) 80 bytes per every 64 kbps oI the clocking, which will result in a 10-ms
serialization delay.
B) 40 bytes per every 64 kbps oI the clocking, which will result in a 20-ms
C) 20 bytes per every 64 kbps oI the clocking, which will result in a 10-ms
D) 120 bytes per every 64 kbps oI the clocking, which will result in a 150-ms
Q6) Which two statements are true, based on the Iollowing show output? (Choose two.)
wg8rI=show policy-map interface s0/I
Serial0/I
Service-policy output. custI
Class-map. voip (match-all)
·00 packets, ?0?0·S bytes
S minute offered rate ?000 bps, drop rate 0 bps
Match. protocol rtp
Queueing
Strict Priority
Output Queue. Conversation ?84
Bandwidth ·84 (kbps) Burst 9800 (Bytes)
(pkts matched/bytes matched) ?·?/I·99IS
(total drops/bytes drops) IS/ISI9S
compress.
header ip rtp
UDP/RTP compression.
Sent. ?8S total, ?84 compressed,
9088 bytes saved, II80I4 bytes sent
I.S efficiency improvement factor
99% hit ratio, five minute miss rate 0 misses/sec, 0 max
rate ?000 bps
A) Both class-based TCP and RTP header compression are enabled Ior the VoIP
traIIic class.
B) IP payload compression is enabled Ior the VoIP traIIic class.
C) LLQ is enabled Ior the VoIP traIIic class.
D) Class-based RTP header compression is enabled Ior all RTP traIIic.
Q7) From the show interface multilink output, which state(s) should be in the open state to
indicate proper multilink PPP operation over an IP interIace?
A) LCP, Multilink, and IPCP
B) LCP, IPCP, LFICP
C) LCP and MLP
D) LCP and IPCP
Q8) Which two oI the Iollowing are correct regarding TCP and RTP header compression?
(Choose two.)
A) Hardware assisted header compression is required to reduce the header
compression delay.
B) TCP header compression compresses both the IP and TCP headers.
C) RTP header compression compresses the IP, UDP, and RTP headers.
D) TCP and RTP header compression can compress the respective protocol
headers down to 10 bytes.
Q9) TCP header compression is most eIIective on which oI the Iollowing applications?
A) VoIP
B) FTP
C) video streaming
D) Telnet
E) TFTP
Q10) RTP header compression is most eIIective on which oI the Iollowing applications?
A) FTP
B) VoIP
C) TFTP
D) Telnet
E) HTTP
Scoring
or better.
Q1) D
ReIates to: Link Efficiency Mechanisms Overview
Q2) A, D, E
Q3) B
Q4) A, D
Q5) A
Q6) C, D
ReIates to: Class-Based Header Compression
Q7) A
Q8) B, C
Q9) D
Q10) B
ModuIe Summary
The diIIerent link eIIiciency mechanisms available in Cisco IOS soItware include class-based
TCP and RTP header compression, Layer 2 payload compression, MLP with interleaving, and
FRF.12 Frame Relay Iragmentation. These QoS mechanisms are used on slower WAN links to
improve the link eIIiciency by increasing the perceived throughput and decreasing the overall
delay.
Class-based TCP and RTP header compressions are conIigured using the MQC method to
reduce the protocol headers overhead. Header compression is most eIIective Ior packets with
small payload size.
Layer 2 payload compression is not being implemented much because oI the soItware
compression delay overhead. Using a hardware compression module can help reduce the
soItware compression delay.
For LFI, MLP with interleaving is supported on PPP interIace while FRF.12 (Ior VoIP) and
FRF.11.c (Ior VoFR) are supported on Frame Relay interIace. LFI is used to reduce the
serialization delay oI large packets. Serialization delay is based on the link speed and packet
size. To ensure high voice quality, the recommended serialization delay is 10 to 15 ms
maximum. As a general rule, a Iragment size oI 80 bytes Ior every 64 kbps oI link speed is
recommended.
ModuIe Summary
· Link efficiency mechanisms are used to increase the
perceived throughput and decrease the Iatency on WAN
Iinks.
· CIass-based TCP and cIass-based RTP header
compression enabIe header compression on specific
traffic cIass using the MQC method.
· LFI improves the seriaIization deIay for packets Ieaving
the router and prevents the voice packets from waiting on
Iarge data packets to be processed.
· To ensure Iow deIay and jitter for voice packets on sIow
Iinks, the recommended standard goaI for seriaIization
deIay is around 10 to 15 ms.
· FRF.12 fragmentation is used on DLCIs configured for
VoIP over Frame ReIay.
ModuIe 9
QoS Best Practices
Overview
IP was designed to provide best-eIIort service Ior delivery oI data packets and to run across
virtually any network transmission media and system platIorm. The increasing popularity oI IP
has shiIted the paradigm Irom 'IP over everything,¨ to 'everything over IP.¨ In order to
manage the multitude oI applications such as streaming video, voice over IP, e-commerce,
enterprise resource planning (ERP), and others, a network requires quality oI service (QoS) in
addition to best-eIIort service. DiIIerent applications have varying needs Ior delay, delay
variation (jitter), bandwidth, packet loss, and availability. These parameters Iorm the basis oI
QoS. The IP network should be designed to provide the requisite QoS to applications.
To Iacilitate true end-to-end QoS on an IP network, the Internet Engineering Task Force (IETF)
has deIined two models: Integrated Services (IntServ) and DiIIerentiated Services (DiIIServ).
IntServ Iollows the signaled QoS model, where the end-hosts signal their QoS need to the
network. DiIIServ works on the provisioned QoS model where network elements are set up to
service multiple classes oI traIIic, with varying QoS requirements.
This module Iocuses on the implementation oI the DiIIServ model in service provider and
enterprise networks. The Iirst lesson provides examples oI baseline traIIic classiIications. The
second lesson provides a case study oI a DiIIServ implementation in a typical enterprise
campus and service provider network.
ModuIe Objectives
Upon completing this module, you will be able to correctly select the most appropriate QoS
mechanisms Ior providing QoS using Cisco 'best practices¨ in service provider and enterprise
networks.
ModuIe OutIine
ModuIe Objectives
· CorrectIy identify and describe the set of
cIassification practices that most cIoseIy
represent Cisco QoS "best practices."
· CorrectIy identify and describe the set of QoS
mechanisms used to impIement Cisco end-to-
end QoS "best practices" in a typicaI enterprise
network connected thru a service provider.
· Providing Layer 3 IP services.
ModuIe OutIine
· Traffic CIassification Best Practices
· Case Study: DepIoying End-to-End QoS
Copyright © 2003, Cisco Systems, Ìnc. QoS Best Practices 9-3
Traffic Classification Best
Practices
Overview
TraIIic classiIication entails using a traIIic descriptor to categorize a packet within a speciIic
group to deIine that packet and make it accessible Ior QoS handling on the network. Using
proper traIIic classiIication, the network traIIic is partitioned into multiple priority levels or
classes oI service.
ReIevance
TraIIic classiIication is the pivotal key Ior proper QoS implementation. It is counterproductive
to use too many discrete traIIic classes. This is because the more classes that are deIined, the
less the distinction between the diIIerent service levels.
This lesson includes a baseline recommendation Ior traIIic classiIication and marking in a
typical enterprise and service provider environment.
Objectives
Upon completing this lesson, you will be able to correctly identiIy and describe the set oI
classiIication practices that most closely represent Cisco QoS 'best practices.¨ This includes
DeIine some oI the key QoS best practices recommendations
Explain the QoS requirements oI the diIIerent application types
List typical enterprise traIIic classes then identiIy the delay, jitter, packet loss, and
bandwidth requirements oI each traIIic class
Map diIIerent enterprise application types into the appropriate PHB (DSCP)
Describe how to map diIIerent enterprise traIIic classes into appropriate service provider
traIIic classes
A good understanding oI using the MQC conIiguration method to implement Cisco IOS
QoS mechanisms
A good understanding oI how to conIigure low-latency queuing (LLQ) and class-based
weighted Iair queuing (CBWFQ)
OutIine
OutIine
· Overview
· QoS Best Practices
· Voice/Video/Data QoS Requirements
· QoS Requirements Summary
· Traffic CIassification
· Enterprise to Service Provider QoS CIass Mapping
· Summary
· Quiz
QoS Best Practices
This topic deIines some oI the QoS best practices recommendations.
An IP network Iorms the backbone oI any successIul organization. These IP networks transport
a multitude oI applications and data, including high-quality video and delay-sensitive data
(such as real-time voice). These applications stretch the IP network capabilities and resources,
but also complement, add value, and enhance every business process. IP networks must provide
secure, predictable, measurable, and sometimes guaranteed services. Achieving the required IP
QoS by managing the delay, delay variation (jitter), bandwidth, and packet-loss parameters on
an IP network becomes the secret to a successIul end-to-end business solution.
IP QoS is the set oI techniques and tools that are used to manage network resources. The Iigure
lists some oI the keys IP QoS best practices recommendations.
QoS Best Practices
Enterprise Networks
· Networks must provide predictabIe, measurabIe, and
sometimes guaranteed services
· Achieving the required QoS by managing the deIay, deIay
variation (jitter), bandwidth, and packet-Ioss parameters
on a network
· CIassify and mark traffic as cIose to the source as
possibIe
· Use NBAR to discover the appIications on the network
· Ensure that reaI-time traffic gets priority with minimaI
deIay
· Ensure that business-criticaI traffic is correctIy serviced
· Ensure scavenger traffic (for exampIe, fiIe sharing) does
NOT consume too much vaIuabIe bandwidth
· Use Iink efficiency techniques on WAN Iinks
The Iirst element oI a QoS policy is to identiIy the traIIic to be treated diIIerently. By
classiIying the application traIIic into diIIerent traIIic classes, a baseline methodology is set to
provide end-to-end QoS. DiIIServ enables this classiIication by utilizing the diIIerentiated
services code point (DSCP) Iield. Using DiIIServ, a properly designed network can deliver
assured bandwidth, low latency, low jitter, and low packet loss Ior voice while simultaneously
ensuring slices oI available bandwidth to other traIIic classes. Packets entering a DiIIServ
domain (collection oI DiIIServ routers) can be classiIied in a variety oI ways:
IP source and destination addresses
Layer 4 protocol and port numbers
Incoming interIace
MAC address
IP precedence
DSCP value
Layer 2 inIormation (such as Frame-Relay discard eligible |DE| bits, Ethernet 802.1p bits)
The Cisco value-added mechanism network-based application recognition (NBAR)
It is best practice to classiIy and mark the traIIic as close to the source oI the traIIic as possible.
In an enterprise environment, the IP QoS policies should allow critical business applications to
receive requisite resources, while ensuring that other applications are not neglected. IP QoS
policies should also ensure the quality oI real-time traIIic, like voice and video. It may also be
important to prevent non-business-related network traIIic (scavenger traIIic) like Iile sharing
traIIic (that is, Kazaa, Napster, etc.) Irom taking up too much oI the network bandwidth.
Network administrators oIten cannot justiIy continual upgrade oI the link speeds in their
networks. Cisco IOS soItware QoS Ieatures provide an alternative solution to link upgrade by
managing the links eIIiciently to meet the application demands. Use QoS mechanisms such as
Multilink PPP (MLP), link Iragmentation and interleaving (LFI), compressed Real-Time
Protocol (cRTP), CBWFQ, and LLQ to allow the most eIIicient distribution oI the available
bandwidth among the applications.
QoS Best Practices
Service Provider Networks
· Use DiffServ backbone
· TypicaIIy define 3 to 4 service cIasses at the network
core:
÷ ControIIed Iatency (EF) CIass
÷ One or two controIIed Ioad cIass
÷ Best-effort cIass
· TypicaIIy over-provision the controIIed Iatency cIass with
a factor of 2
· May have more service cIasses at the network edge:
÷ ExampIe: management cIass
· Use LLQ or MDRR (GSR), WRED
· When poIicing and re-marking excess traffic, re-mark to
the same AF CIass with higher drop probabiIity:
÷ ExampIe: Re-mark AF 31 exceeding traffic to AF 32 (do not re-mark
AF 31 to AF 21)
In an IP service provider environment, the recommended backbone architecture is to deploy a
DiIIServ backbone with a diIIerent over-provisioning ratio Ior the diIIerent traIIic classes. Most
service providers will typically classiIy their customer traIIic into 3 or 4 traIIic classes
(controlled latency, controlled load, and best eIIort). At the network edge, the service provider
may deIine additional traIIic classes, Ior example, deIining a management traIIic class Ior all
network management traIIic (like Simple Network Management Protocol |SNMP| and Telnet
traIIic).
In the service provider core, where all the links are very high speed, the typical QoS
mechanisms required are LLQ, modiIied deIicit round robin (MDRR) (Gigabit Switch Router
|GSR|), and weighted random early detection (WRED).
At the ingress to the service provider core, the customer traIIic is typically policed by the
service provider to ensure that the rate oI customer traIIic does not exceed the contractual rate.
When re-marking the exceeding customer traIIic, re-mark the DSCP value to the same Assured
Forwarding (AF) class, but increase the drop probability. For example, re-mark AF 31
exceeding traIIic to AF 32 or AF 33; do not re-mark AF 31 exceeding traIIic to AF 21 or
AF 11.
A set oI QoS tools is needed to manage the delay, delay variation (jitter), bandwidth, and
packet-loss parameters on a network. These QoS tools include the QoS classiIication,
scheduling, and provisioning tools.
Only aIter traIIic is identiIied can traIIic policies be applied. The Iirst element oI a QoS policy
is to identiIy the traIIic to be treated diIIerently. ClassiIication must be consistent throughout
the enterprise Ior it to be eIIective. QoS classiIication tools mark a packet with a speciIic
priority. This marking is determined by examining:
Layer 2 parameters like 802.1q class oI service (CoS) bits, MAC address, Multiprotocol
Label Switching (MPLS) experimental bits.
Layer 3 parameters like IP precedence, DSCP, source/destination IP address.
Layer 4 parameters like TCP or User Datagram Protocol (UDP) ports.
At the network edge, QoS markings may be accepted or rejected. This is reIerred to as the trust
boundary. II packets are entering the network Irom a source that is trusted to set the packet
marking properly, the packets are coming Irom a trusted device and can be leIt marked as-is. II
the packets are entering the network Irom a device that cannot be trusted to properly mark
packets, these packets must be re-marked. This is the location oI the trust boundary.
The QoS scheduling tools are used to determine how a packet exits a node. Whenever packets
enter a device Iaster than they can exit the device (as with speed mismatch), then a point oI
congestion can occur. Devices have buIIers that allow Ior scheduling oI higher-priority packets
to exit sooner than lower-priority packets, which is commonly called queuing. Queuing is
utilized only when a device is experiencing congestion and is bypassed when the congestion
clears.
Design Approach to EnabIing QoS
The QoS provisioning tools include the traIIic policing and traIIic shaping tools and the link
eIIiciency mechanisms (LEM) tools. TraIIic policers and shapers are the oldest Iorm oI QoS
mechanisms. These tools have the same objectives: namely, to identiIy and respond to traIIic
violations. Policers and shapers usually identiIy traIIic violations in a similar manner; however,
their main diIIerence is the manner in which they respond to violations:
A policer drops excess traIIic.
A shaper delays excess traIIic using a shaping queuing mechanism to hold packets and to
shape the Ilow when the data rate is higher than expected.
LEMs are oIten used on WAN links to improve the perceived throughput and to reduce the
delays on WAN links. Link eIIiciency mechanisms include LFI, payload compression, and
header compression.
Implementing QoS is a means to use bandwidth eIIiciently, but not a blanket substitute Ior
bandwidth itselI. When the network is Iaced with ever increasing congestion, a certain point is
reached where QoS alone will not solve bandwidth requirements. At such a point, nothing short
oI additional bandwidth will suIIice.
ExampIe: Cisco IOS QoS TooIs Summary
In this course, you have learned about the various QoS tools available within Cisco IOS
soItware.
The Iollowing list groups some oI these tools into the proper categories.
ClassiIication tools:
Class-based marking
NBAR
QoS Policy Propagation on Border Gateway Protocol (QPPB)
QoS pre-classiIy
Scheduling tools:
CBWFQ
LLQ
WRED
Provisioning Tools:
Class-based shaping
Class-based policing
MLP interleaving
FRF.12
Class-based TCP and class-based Real-Time Transport Protocol (RTP) header
compression
Voice/Video/Data QoS Requirements
This topic explains the QoS requirements oI the diIIerent application types.
Voice quality is directly aIIected by all QoS quality Iactors: loss, delay, and jitter.
Loss causes voice clipping and skips. The industry standard coded algorithms that are used in
Cisco digital signal processors (DSPs) can correct Ior up to 30 ms oI lost voice. For example, iI
a 20 ms sample oI voice payload is used per Voice over IP (VoIP) packet, only a single voice
packet can be lost during any given time. II two successive voice packets are lost, the 30-ms
correctable window is exceeded and voice quality begins to degrade.
Delay can cause voice quality degradation iI it is above 200 ms. The International
Telecommunication Union (ITU) standard Ior VoIP (G.114) states that a 150-ms one-way delay
budget is acceptable Ior high voice quality.
With respect to jitter (delay variations), there are adaptive jitter buIIers within Cisco IP
telephony devices. However, these can usually only compensate Ior 20 to 50 ms oI jitter.
To determine the bandwidth requirement per each VoIP call, several Iactors must be
considered. These Iactors include the codec used, the sampling rate, and the Layer 2 protocol.
Each VoIP call also requires 150 bps oI bandwidth Ior the voice control (call-signaling) traIIic.
Voice
· Latency < 150 ms*
· Jitter < 30 ms*
· Loss < 1%*
· Requires guaranteed
priority bandwidth per
caII
· 150 bps (+ Iayer 2
overhead) guaranteed
bandwidth for Voice-
ControI traffic per caII
-
-
-
When addressing the bandwidth requirement Ior voice traIIic, keep the Iollowing in mind:
The required bandwidth per call depends on the codec, the packetization interval, and the
Layer 2 protocol.
The bandwidth required Ior the voice control (signaling) traIIic, which is about 150 bps per
call.
The bandwidth consumed by VoIP streams is calculated by adding the packet payload (in bits)
and all the headers (in bits), then multiplying the total number oI bits per packet by the per-
second packet rate. This does not take into account the eIIect oI any link eIIiciency tools such
as RTP header compression and LFI. This graphic illustrates the VoIP bearer traIIic bandwidth
requirements Ior diIIerent codecs with diIIerent sampling rates. To have a more accurate
method Ior VoIP bandwidth provisioning, also include the Layer 2 overhead (that is,
preambles, headers, Ilags, cyclic redundancy checks (CRC)s, ATM cell-padding, and others) in
bandwidth calculations.
Provisioning for Voice:
VoIP Bandwidth Reference TabIes
A more accurate method for provisioning is to incIude
the Layer 2 overhead into the bandwidth caIcuIations:
ExampIe: G.711 Voice Bearer Bandwidth Requirement
CaIcuIation
The Iollowing example shows how to calculate the VoIP bearer bandwidth requirement Ior a
single VoIP call using a G.711 codec (Layer 2 overhead not included):
G.III ¬ I80 bytes payload size
Packet size ¬ payload size + IP/UDP/RTP headers
¬ I80 bytes + ?0 bytes + 8 bytes + I? bytes
¬ ?00 bytes
Sampling Rate ¬ ?0 msec per sample ¬ S0 samples per second
Bandwidth (bytes/sec) without Layer ? overhead
¬ ?00 bytes/packet x S0 packets/second
¬ I0000 bytes/second
Bandwidth (bits/sec) without Layer ? overhead
¬ I0000 bytes/second * 8 bits/byte
¬ 80000 bytes/second (80 kbps)
VideoconIerencing has the same latency, jitter, and packet-loss requirements as voice, but the
traIIic patterns oI videoconIerencing are radically diIIerent Irom voice. For example,
videoconIerencing traIIic has varying packet sizes and extremely variable packet rates. Because
oI its bursty nature, videoconIerencing has two unique best-practice requirements in
provisioning Ior strict-priority bandwidth:
The LLQ should be provisioned to the stream rate plus 20 percent.
The LLQ burst parameter should be provisioned to 30 KB per 384-kbps stream.
Compared to videoconIerencing, streaming video applications have more lenient QoS
requirements. Video streaming applications are more delay insensitive and are largely jitter
insensitive due to application buIIering. When provisioning Ior streaming video applications,
take into account the video content distribution requirements. Video Iile distribution is similar
to FTP traIIic in nature and can have a major impact on network perIormance because oI the
large Iile size. Content distribution traIIic should be managed to avoid impacting the network.
ExampIe: CaIcuIating the Bandwidth Requirement for a
384-kbps Videoconference Stream
The Iollowing example shows how to calculate the bandwidth requirement Ior a 384-kbps
videoconIerencing stream.
·84 kbps + (?0% x ·84 kbps) ¬ ·84 kbps + I8.8 kbps
¬ 480.8 kbps
Videoconferencing
· Latency < 150 ms
· Jitter < 30 ms
· Loss < 1%
· Minimum priority
bandwidth guarantee
required is:
÷ Video stream + 20%
÷ For exampIe, a 384-kbps
stream wouId require 460
kbps of bandwidth
*One-way requirements
-
-
-
Because bandwidth requirements vary greatly Irom application to application (and even
between versions oI the same applications) it is not possible to provide a blanket rule Ior
provisioning data bandwidth.
TraIIic analysis and lab testing are required to ascertain bandwidth requirements Ior data
applications.
Data
· Different appIications
have different traffic
characteristics.
· Different versions of
the same appIication
can have different
traffic characteristics.
For data classiIication, a relative-priority model oI no more than Iour to Iive traIIic classes has
been proven to work well in most enterprise environments: Ior example, a mission-critical,
transactional, best-eIIort (deIault), and less-than-best-eIIort (scavenger) class. Each traIIic class
can be assigned a minimum bandwidth guarantee using CBWFQ. An example oI using a
relative-priority model between the diIIerent data traIIic classes is:
The mission-critical traIIic class gets a minimum oI 50 percent oI the remaining bandwidth
aIter the LLQ is serviced.
The transactional traIIic class gets a minimum oI 20 percent oI the remaining bandwidth
aIter the LLQ is serviced.
The best-eIIort (deIault/best eIIort) traIIic class gets a minimum oI 25 percent oI the
remaining bandwidth aIter the LLQ is serviced.
The less-than-best-eIIort traIIic class gets a minimum oI 5 percent oI the remaining
bandwidth aIter the LLQ is serviced.
It is counterproductive to use too many discrete classes Ior data traIIic. This is because the
more classes that are deIined, the less the distinction between service-levels. Additionally, iI
too many applications are assigned to the mission-critical class, then the overall eIIectiveness
oI QoS provisioning is dampened. Taken to an extreme, iI all applications are assigned to the
mission-critical class, then the end result is the same as when no QoS is provisioned at all.
Mission-critical applications should be limited to those that directly contribute to the core
operations oI the business. These are usually highly interactive and are thereIore sensitive to
delay and loss. Examples oI mission-critical applications include ERP applications, such as
Oracle, SAP and PeopleSoIt, as well as proprietary applications that were designed in-house.
When classiIying the diIIerent network applications into traIIic classes, it is very important to
try to only group applications with the common characteristics and QoS requirements together
into the same traIIic class. For example, because interactive applications and bulk transIer
applications have very diIIerent bandwidth and delay requirements, interactive and bulk traIIic
should not be classiIied into the same traIIic class.
Provisioning for Data:
GeneraI PrincipIes
· ProfiIe appIications to their basic network requirements.
· Do not overengineer provisioning. Use no more than 4 to 5
traffic cIasses for data traffic:
÷ Mission-CriticaI: LocaIIy defined criticaI appIications
÷ TransactionaI: ERP, SAP, OracIe
÷ Best-Effort: E-maiI, unspecified
÷ Less-than-Best-Effort (Scavenger): Peer-to-peer appIications
· Do not assign more than 3 appIications to mission-criticaI or
transactionaI cIasses.
· OnIy group appIications with common characteristics together
into the same cIass.
· Most appIications faII under best effort; make sure that
adequate bandwidth is provisioned for this defauIt cIass.
· Seek executive endorsement of reIative ranking of appIication
priority prior to roIIing out QoS poIicies for data.
ExampIe: RCL Enterprise
In this example, the RCL enterprise network administrator used NBAR and determined the
major sources oI network traIIic are Irom the Iollowing applications:
Structured Query Language (SQL), VoIP, FTP, HTTP, Domain Name System (DNS),
Exchange, Napster
The RCL senior management team has determined that only SQL and HTTP traIIic are
mission-critical to the company.
RCL has decided to implement Iour traIIic classes as Iollows:
A real-time traIIic class Ior VoIP traIIicall RTP traIIic
A mission-critical data traIIic class Ior mission-critical traIIicSQL and HTTP traIIic
A bulk traIIic class Ior business traIIic that is not mission-criticalFTP, DNS, Exchange
A best-eIIort traIIic class Ior all best-eIIort traIIicNapster and all other traIIic
The RCL network administrator has decided not to implement a scavenger traIIic class to limit
the Napster traIIic at this time, but is constantly monitoring the Napster traIIic. In the Iuture, iI
more bandwidth is required Ior the business-related applications, a scavenger traIIic class will
be added and the Napster traIIic will be classiIied into this scavenger traIIic class.
QoS Requirements Summary
This topic lists typical enterprise traIIic classes and identiIies the delay, jitter, packet-loss, and
bandwidth requirements oI each enterprise traIIic class.
This table summarizes the key QoS requirements (bandwidth, packet loss, delay and jitter) Ior
some oI the major diIIerent applications category.
ExampIe: QoS Requirements of the Major AppIications
Category
VoIP and videoconIerencing applications share the same low drop, low delay, and low jitter
requirements. For example, a latency oI less than 150 ms, a jitter oI less than 30 ms, and a
packet loss oI less than 1 percent are typically required.
Mission-critical applications like ERP applications have diIIerent bandwidth requirements,
depending on the application and even the particular version oI the application. In general,
mission-critical applications are more drop, delay, and jitter sensitive than bulk traIIic.
Bulk applications like FTP are less sensitive to drop, delay, and jitter, but generally require
more bandwidth than real-time traIIic, such as voice traIIic.
QoS Requirements Summary
Traffic CIassification
This topic maps diIIerent enterprise applications types into the appropriate per-hop behavior
(PHB) (DSCP).
AIter the QoS requirements Ior the diIIerent applications running on the network have been
determined, the next step is to determine how to classiIy the traIIic into multiple service
classes. It is best practice to classiIy and mark traIIic as close to the source oI the traIIic as
possible. At the enterprise campus LAN, classiIication and marking is typically done at the
access or distribution layer. Both Cisco IOS routers and IOS Catalyst switches have class-based
marking capabilities. NBAR is also supported on Cisco IOS routers and some IOS Catalyst
switches.
AIter the traIIic classiIication requirements have been determined, the next step is to establish
the proper scheduling policy Ior each traIIic class. For example, at the WAN edge router where
the traIIic exits the enterprise campus LAN onto the WAN, it is best practice to implement
LLQ/CBWFQ to provided congestion management.
Traffic CIassification and ScheduIing
1. Identify the network traffic and its QoS
requirements.
2. CIassify the network traffic into the
appropriate traffic cIasses and mark the
network traffic as cIose to the source as
possibIe.
3. Define the scheduIing poIicy for each
traffic cIass.
The Iollowing design principles apply when determining bandwidth provisioning requirements
Ior combining voice, video, and data over a single WAN link:
Video requires 460 kbps oI LLQ Ior each 384 kbps stream (stream-rate plus 20 percent).
VoIP also requires LLQ bandwidth. The actual amount oI bandwidth depends on the
number oI IP Phones, codecs used, sampling-rates, and Layer 2 protocol.
The ratios oI voice and video within the LLQ will vary, depending on the voice and video
traIIic requirements.
As a general rule, the total LLQ provisioning is recommended to be 33 percent oI the link
capacity. This maximum number varies depending on many Iactors, such as the router
platIorm and the traIIic proIiles.
In a relative-priority model, mission-critical traIIic should have greater bandwidth
guarantees than the other data classes.
Because most traIIic may end up in the deIault (best-eIIort) class, ensure there is enough
bandwidth leIt over Ior the best-eIIort traIIic class.
By deIault, the sum oI all bandwidth guarantees should be 75 percent oI the link
bandwidth. For example, iI the link bandwidth is 10 Mbps, the maximum available
bandwidth will be 7.5 Mbps.
Enterprise WAN Edge Bandwidth
AIIocation ExampIe
The amount of maximum bandwidth to be aIIocated for the LLQ cIass
depends on many factors such as the router pIatform, the traffic
profiIes, and QoS features enabIed.
ExampIe: LLQ Bandwidth AIIocation
The example in the graphic shows a LLQ bandwidth allocation example between six diIIerent
traIIic classes:
VoIP bearer traffic class: The VoIP bearer traIIic class has a maximum bandwidth
guarantee oI 17 percent oI the link bandwidth.
Video traffic class: The video traIIic class has a maximum bandwidth guarantee oI 16
percent oI the link bandwidth.
VoIP control traffic class: The VoIP control traIIic class has a minimum bandwidth
Mission-critical data class: The mission-critical traIIic class has a minimum bandwidth
Transactional data class: The transactional traIIic class has a minimum bandwidth
Best-effort (default) class: The best-eIIort (deIault) traIIic class has a minimum bandwidth
Note: Ìn this example, the max reservable bandwidth on the link is set to 0 percent so up to 100
percent of the link bandwidth can be guaranteed between the different classes.
This Iigure illustrates a QoS baseline recommendation Ior traIIic classiIication and markings. In
this example, the enterprise traIIic is classiIied into 11 traIIic classes including:
Five data classes (mission critical, transactional, bulk, scavenger, best eIIort)
One class Ior network management traIIic
One class Ior routing protocol traIIic
One class Ior voice traIIic
One separate class Ior voice call-signaling traIIic
One class Ior videoconIerencing traIIic
One class Ior streaming video traIIic
In the Iigure, the recommended IP precedence value, the PHB, the DSCP value, and the Layer
2 CoS markings are shown Ior each traIIic class. The markings oI some oI the traIIic classes are
as Iollows:
Voice is marked with DSCP 46 and CoS 5.
Voice call-signaling traIIic is marked with Class Selector (CS) 3 and CoS 3.
VideoconIerencing (AF 41) is marked diIIerently than streaming video (CS 4) because the
QoS requirements are diIIerent Ior videoconIerencing than Ior streaming video.
Mission-critical data is marked with AF 31 and CoS 3.
A scavenger class is used and is marked with CS 1 and CoS 1.
Routing traIIic is marked with CS 6 and CoS 6. Cisco IOS soItware assigns an IP
precedence oI 6 to routing protocol packets on the control plane.
QoS BaseIine CIassification Summary
A marking oI CS 3 is recommended Ior voice call-signaling traIIic. However, Cisco IP Phones
and other Cisco IP telephony devices currently mark voice call-signaling traIIic to AF 31. Until
migration to CS 3 is complete, both AF 31 and CS 3 should be reserved Ior the voice call-
signaling traIIic class.
Because voice call-signaling traIIic is currently marked to AF 31, the mission-critical data
should be marked as DSCP 25 instead oI AF 31, as shown in the previous Iigure, until
migration to CS 3 is complete.
QoS BaseIine CIassification
Summary (Cont.)
ExampIe: LLQ ExampIe on the Enterprise WAN Edge Router
This Iigure illustrates an example oI an enterprise WAN-edge router conIiguration using LLQ
with class-based WRED on certain data traIIic classes. This assumes the markings Ior the
diIIerent traIIic classes are already done at the access or at the distribution layer within the
campus network.
Currently (except Ior the 7500 router platIorm) all traIIic classes except Ior the deIault traIIic
class support only FIFO queuing within the class. Check Cisco.com Ior the latest inIormation
on weighted Iair queuing (WFQ) support within each traIIic class.
On all platIorms, the deIault traIIic class can support either FIFO or WFQ within the class. But
iI the deIault traIIic class is allocated a minimum bandwidth as shown in this graphic, WFQ
will not be supported in the deIault traIIic class. The only current exception is Ior the 7500
series platIorms. In this case, the deIault traIIic class will support only FIFO queuing.
WAN Edge LLQ Configuration
class~map match~all RoUTING
match ip dscp cs6
class~map match~all VoICF
match ip dscp ef
class~map match~all VIDFo~CoNF
match ip dscp af41
class~map match~all STRFAM~VIDFo
match ip dscp cs4
class~map match~all MISSIoN~CRIT
match ip dscp 25
class~map match~any VoICF~CoNTRoL
match ip dscp cs3
match ip dscp af31
class~map match~all TRANSACT
match ip dscp af21
class~map match~all NFTWoRK~MGMT
match ip dscp cs2
class~map match~all BULK
match ip dscp af11
class~map match~all SCAVFNGFR
match ip dscp cs1
class~map match~all RoUTING
match ip dscp cs6
class~map match~all VoICF
match ip dscp ef
class~map match~all VIDFo~CoNF
match ip dscp af41
class~map match~all STRFAM~VIDFo
match ip dscp cs4
class~map match~all MISSIoN~CRIT
match ip dscp 25
class~map match~any VoICF~CoNTRoL
match ip dscp cs3
match ip dscp af31
class~map match~all TRANSACT
match ip dscp af21
class~map match~all NFTWoRK~MGMT
match ip dscp cs2
class~map match~all BULK
match ip dscp af11
class~map match~all SCAVFNGFR
match ip dscp cs1
policy~map WAN~FDGF
class RoUTING
bandwidth percent 3
class VoICF
priority percent 18
class VIDFo~CoNF
priority percent 15
class STRFAM~VIDFo
class MISSIoN~CRIT
random~detect dscp~based
class VoICF~CoNTRoL
bandwidth percent 2
class TRANSACT
bandwidth percent 8
class NFTWoRK~MGMT
bandwidth percent 2
class BULK
bandwidth percent 4
class SCAVFNGFR
bandwidth percent 1
class class~default
policy~map WAN~FDGF
class RoUTING
bandwidth percent 3
class VoICF
priority percent 18
class VIDFo~CoNF
priority percent 15
class STRFAM~VIDFo
class MISSIoN~CRIT
class VoICF~CoNTRoL
bandwidth percent 2
class TRANSACT
bandwidth percent 8
class NFTWoRK~MGMT
bandwidth percent 2
class BULK
bandwidth percent 4
class SCAVFNGFR
bandwidth percent 1
class class~default
If the defauIt cIass is aIIocated a bandwidth,
WFQ cannot be enabIed for the traffic within the
defauIt cIass. This is true for aII pIatforms
except the 7500 (and soon the 7200).
Enterprise to Service Provider QoS CIass
Mapping
This topic describes how to map diIIerent enterprise traIIic classes into traIIic classes that are
appropriate Ior service provider use.
This Iigure illustrates how the diIIerent enterprise traIIic classes can be mapped into the Iour
traIIic classes oIIered by a service provider. In the example, there is no streaming video traIIic.
The Iour traIIic classes oIIered by the service provider are:
Controlled Latency: A traIIic class Ior all real-time traIIic. The controlled latency class
admits packets marked with CS 5 and Expedited Forwarding (EF).
Controlled Load 1: A traIIic class Ior all highly bursty traIIic. The controlled load 1 class
admits packets marked with CS 3, AF 31, and CS 6.
Controlled Load 2: A traIIic class Ior the less bursty traIIic. The controlled load 2 class
admits packets marked with AF 21.
Best Effort: A traIIic class Ior the best-eIIort traIIic. All other traIIic is assigned to the
best-eIIort class.
The Iigure also shows an example oI bandwidth allocation between the Iour traIIic classes
where 35 percent oI the link bandwidth is allocated Ior the controlled latency traIIic class, 43
percent Ior controlled load 1 traIIic class, 15 percent Ior controlled load 2 traIIic class, and 7
percent Ior best-eIIort traIIic class.
Enterprise to Service Provider QoS
CIass Mapping ExampIe
ExampIe: Remapping the Enterprise Managed CE Traffic
CIasses into the Traffic CIasses Offered by the Service
Provider
This Iigure illustrates a sample content engine (CE) provider edge (PE) router conIiguration
using LLQ with class-based WRED on certain data traIIic classes. Class-based markings are
also used to re-mark the enterprise markings into the markings that are expected by the service
provider where:
VideoconIerencing traIIic is re-marked Irom AF 41 to CS 5 and has a maximum bandwidth
Mission-critical traIIic is re-marked Irom DSCP 25 to AF 31 and has a minimum
bandwidth guarantee oI 25 percent oI the link bandwidth.
Voice control (signaling) traIIic is re-marked Irom AF 31 and CS 3 to CS 5 and has a
maximum bandwidth guarantee oI 2 percent oI the link bandwidth.
Transactional data traIIic is re-marked Irom AF 21 to CS 3 and has a minimum bandwidth
Network management traIIic is re-marked Irom CS 2 to CS 3 and has a minimum
bandwidth guarantee oI 2 percent oI the link bandwidth.
Bulk data traIIic is re-marked Irom AF 11 to AF 21 and has a minimum bandwidth
Scavenger data traIIic is re-marked Irom CS 1 to DSCP 0 and has a minimum bandwidth
Routing traIIic is not re-marked and has a minimum bandwidth guarantee oI 3 percent oI
the link bandwidth.
WAN Edge LLQ Configuration
ExampIe 2
Mapping enterprise service cIasses to service provider supported
service cIasses
Voice bearer traIIic is not re-marked and has a maximum bandwidth guarantee oI 20
percent oI the link bandwidth.
The deIault class is not re-marked and has a minimum bandwidth guarantee oI 6 percent oI
the link bandwidth.
Summary
References
For more inIormation on QoS ClassiIication best practices, reIer to 'ClassiIication &
Marking¨ at the Iollowing URL: http://www.cisco.com/pcgi-
bin/Support/browse/psp¸view.pl?p÷Internetworking:ClassiIication¸and¸Marking&viewall
÷true
Summary
· QoS is achieved by managing the deIay, deIay variation
(jitter), bandwidth, and packet Ioss.
· Ensure that reaI-time traffic gets priority with minimaI
deIay.
· Assign as few as possibIe appIications to mission-
criticaI.
· Most appIications faII under best effort. Make sure that
adequate bandwidth is provisioned for the defauIt cIass.
· Most service providers offer 3 to 5 cIasses onIy: remap of
traffic cIasses at the network may be required.
Quiz
Q1) According to the ITU standard, to ensure high voice quality, what is the recommended
maximum one-way delay budget Ior VoIP traIIic?
A) 10 ms
B) 50 ms
C) 150 ms
D) 300 ms
E) 500 ms
Q2) On a typical converged network supporting voice, video, and data, what type oI traIIic
should be serviced in the LLQ?
A) mission-critical data
B) voice and videoconIerencing
C) videoconIerencing and streaming video
D) voice and mission-critical data
E) voice, videoconIerencing, streaming video, and mission-critical data
Q3) Cisco IP Phones and other Cisco IP telephony devices currently mark call-signaling
traIIic to what DSCP value?
A) EF
B) CS1
C) CS 6
D) AF 11
E) AF 31
F) AF 41
Q4) What are two proper Layer 3 and Layer 2 markings Ior voice bearer traIIic? (Choose
two.)
A) AF 31
B) AF 41
C) EF
D) CoS 4
E) CoS 5
F) CoS 6
Q5) The adaptive jitter buIIer within Cisco IP telephony devices can usually only
compensate Ior how much jitter?
A) 1 to 10 ms oI jitter
B) 20 to 50 ms oI jitter
C) 150 to 200 ms oI jitter
D) 250 to 300 ms oI jitter
Q6) What three Iactors determine the amount oI bandwidth needed per VoIP call? (Choose
three.)
A) codec type
B) voice sampling rate
C) Layer 2 Media
D) jitter buIIer size
E) router CPU speed
Q7) Mission-critical data should be classiIied with what CoS value?
A) 1
B) 2
C) 3
D) 4
E) 5
F) 6
G) 7
Q8) Review the Iollowing QoS conIiguration:
class-map match-all ROUTING
match ip dscp cs8
class-map match-all VOICE
match ip dscp ef
class-map match-all VIDEO-CONFERENCING
match ip dscp af4I
class-map match-all MISSION-CRITICAL-DATA
match ip dscp ?S
class-map match-any VOICE-CONTROL
match ip dscp cs·
match ip dscp af·I
class-map match-all TRANSACTIONAL-DATA
match ip dscp af?I
class-map match-all NETWORK-MANAGEMENT
match ip dscp cs?
class-map match-all BULK-DATA
match ip dscp afII
class-map match-all SCAVENGER-DATA
match ip dscp csI
!
policy-map CE-EDGE
class ROUTING
bandwidth percent ·
class VOICE
priority percent ?0
class VIDEO-CONFERENCING
priority percent I·
set ip dscp csS
class MISSION-CRITICAL-DATA
bandwidth percent ?S
set ip dscp af·I
class VOICE-CONTROL
priority percent ?
set ip dscp csS
class TRANSACTIONAL-DATA
bandwidth percent I·
set ip dscp cs·
class NETWORK-MANAGEMENT
bandwidth percent ?
set ip dscp cs·
class BULK-DATA
bandwidth percent IS
set ip dscp af?I
class SCAVENGER-DATA
bandwidth percent I
set ip dscp default
class class-default
bandwidth percent 8
Based on the above conIiguration, which two oI the Iollowing statements are correct? (Choose
two.)
A) Only voice bearer and voice control (signaling) traIIic will be serviced by the
LLQ.
B) Voice control traIIic will be remapped to CS 5.
C) Scavenger traIIic is guaranteed less bandwidth than the best-eIIort class.
D) Routing protocol traIIic will be serviced by the LLQ.
E) WRED is enabled Ior the voice traIIic class.
F) Scavenger traIIic will be remapped to CS 1.
Q9) In a typical converged network, which two oI the Iollowing is considered a QoS best
practice? (Choose two.)
A) TraIIic classiIication and marking should be perIormed at the high speed core
layer and close to the destination.
B) A tool like NBAR should be used to discover all the applications running on
the network.
C) Ensure real-time traIIic gets the highest priority and minimum delay.
D) All traIIic that is not real-time should be classiIied into the scavenger traIIic
class.
E) Ensure mission-critical applications have higher priority over all other traIIic.
Q10) Which oI the Iollowing applications are typically less delay and jitter-sensitive than
VoIP? (Choose all that apply.)
A) videoconIerencing
B) ERP
C) streaming video
D) call-signaling
E) FTP
Quiz Answer Key
Q1) C
ReIates to: QoS Requirements Summary
Q2) B
ReIates to: Traffic Classification
Q3) E
Q4) C, E
Q5) B
Q6) A, B, C
Q7) C
Q8) B, C
ReIates to: Enterprise to Service Provider QoS Class Mapping
Q9) B, C
ReIates to: QoS Best Practices
Q10) B, C, D, E
ReIates to: Voice/Video/Data QoS Requirements
Case Study: Deploying End-to-
End QoS
Overview
When using public transport, a traveler may beneIit Irom contractual commitments Irom the
public transport provider; Ior example, a guarantee Irom an airline that 95 percent oI their
Ilights will arrive within 5 minutes oI the scheduled time. The commitments may include other
parameters or metrics such as number oI stops en route. The more competitive the market Ior
the particular service, the more comprehensive and the tighter the commitments or service level
agreements (SLA) that are oIIered.
In the same way, the increase oI competition between IP service providers, together with the
heightened importance oI IP to business operations, has led to an increased demand and
consequent supply oI IP services with tighter SLAs Ior IP perIormance.
The DiIIServ architecture enables IP networks to be engineered to support tight SLA
commitments.
ReIevance
For a service provider IP service, the SLA commitments are based on delay, jitter, packet-loss
rate, throughput, and availability. This lesson gives examples oI these IP QoS SLA parameters,
and describes how the diIIerent Cisco IOS QoS mechanisms should be used so that SLA
parameters can be met.
In service provider IP backbone networks, it is noted that the mechanisms employed at the edge
oI the network to deliver tight SLAs are more involved than those used in the core. In the core,
where traIIic is aggregated, SLA requirements Ior a traIIic class can be translated into the
appropriate bandwidth requirements, and the problem oI SLA assurance can eIIectively be
reduced to that oI bandwidth provisioning.
Objectives
Upon completing this lesson, you will be able to correctly identiIy and describe the set oI QoS
mechanisms that are used to implement Cisco end-to-end QoS 'best practices¨ in a typical
enterprise network connected through a service provider that is providing Layer 3 IP services.
Explain IP QoS SLA and provide some SLA examples
Explain the typical network requirements within each Iunctional block (campus LAN,
WAN edge, service provider backbone, branch), which makes up the end-to-end network
Explain the best practice QoS implementations and conIigurations within the campus LAN
Explain the best practice QoS implementations and conIigurations on the WAN CE and PE
routers
Explain the best practice QoS implementations and conIigurations on the service provider
backbone (P) and PE routers
A good understanding oI using the MQC conIiguration method to implement Cisco IOS
QoS mechanisms
A good understanding oI Cisco IOS QoS classiIication/marking, scheduling, and
provisioning mechanisms
OutIine
OutIine
· Overview
· QoS Service LeveI Agreements
· DepIoying End-to-End QoS Case Study Introduction
· Enterprise Campus QoS ImpIementations
· WAN Edge (CE/PE) QoS ImpIementations
· Service Provider Backbone QoS ImpIementations
· Summary
· Quiz
QoS Service LeveI Agreements
This topic explains IP QoS SLA and provides some SLA examples.
An SLA stipulates the delivery and pricing oI numerous service levels and spells out penalties
Ior shortIalls. SLAs can cover an assortment oI data services like Irame relay, leased lines,
Internet access, Web hosting, etc. The best way to understand SLAs is to break them into two
pieces: negotiating the technology agreement and veriIying that promises made are promises
kept.
To support integrated voice, video, and data services, service providers are under increasing
pressure to oIIer diIIerentiated service levels to their customers, oIten in conjunction with SLAs
that provide contractual assurance Ior meeting the diIIerent traIIic QoS requirements. A QoS
SLA typically provides contractual assurance Ior parameters such as delay, jitter, packet loss,
throughput, and availability.
With the rapid growth oI new multimedia real-time applications like IP telephony, web-
conIerencing and e-learning, oIIering IP QoS SLA is becoming a key service diIIerentiator Ior
service providers.
QoS Service LeveI Agreements
· QoS SLAs provide contractuaI assurance for meeting the
different traffic QoS requirements.
· QoS SLAs typicaIIy provide contractuaI assurance for
parameters such as:
÷ DeIay (fixed and variabIe)
÷ Jitter
÷ Packet Ioss
÷ Throughput
÷ AvaiIabiIity
· QoS SLAs are a key differentiator for service providers.
This Iigure illustrates a service provider providing only Layer 2 services to the enterprise
customer. The customer edge (CE) routers at the various customer sites are inter-connected by
Frame Relay virtual circuits (VCs). These VCs can be Iully meshed, partially meshed, or set up
as hub-and-spokes, depending on the customer requirements.
In this environment, the service provider is only responsible Ior the end-to-end Layer 2 VC
connections. The service provider only provides a PPP SLA guarantee Ior each VC connection.
The service provider is not involved with providing IP QoS to the customer.
To provide IP QoS Ior voice, video, and data integration over the Frame Relay VCs, the
customer must conIigure the proper QoS mechanisms like traIIic shaping, LLQ, FRF.12, and
cRTP at the WAN CE routers because the Frame Relay WAN link is likely to get congested.
Enterprise Network with TraditionaI
Layer 2 Service
· Provider seIIs the customer a
Layer 2 service
· PPP SLA from the provider
· Enterprise WAN IikeIy to get
congested
· IP QoS required for voice,
video, data integration
· Service provider is not
invoIved in IP QoS
This Iigure illustrates a service provider that is providing Layer 3 services to the enterprise
customer. The CE routers at the various customer sites connect to the provider edge (PE) oI the
service provider router. From a particular customer site perspective, every IP address that is not
located on-site is reachable via the service provider IP backbone network.
In this environment, because the service provider is responsible Ior providing IP services, the
service provider can provide value-added IP services to the customer by providing point-to-
cloud SLAs Ior the conIorming traIIic Irom the customer. For example, divide customer traIIic
at the network edge into controlled latency, controlled load 1, and controlled load 2 classes, and
then provide IP QoS assurances to each traIIic class that is conIorming to the contractual rate
over a DiIIServ IP backbone. For all nonconIorming (exceeding) traIIic, the service provider
can re-mark and delivery all nonconIorming traIIic with best-eIIort service.
Enterprise Network with IP Service
· Customer buys Layer 3 service
from the provider
· Point-to-cIoud SLA from provider
for conforming traffic
· Enterprise WAN IikeIy to get
congested
· Service Provider is invoIved in IP
QoS
A typical IP QoS SLA oIIered by most service providers oIten includes 3 to 5 traIIic classes;
Ior example, a real-time traIIic class, a mission-critical data traIIic class, one or two other data
traIIic classes, and a best-eIIort traIIic class. The IP QoS SLA Ior the real-time traIIic class
should be guaranteed a Iixed maximum bandwidth while the data traIIic classes should be
guaranteed a minimum bandwidth. Typically, the bandwidth allocation is conIigured as a
percentage oI the interIace bandwidth. Each traIIic class can also have a latency, delay, jitter,
and packet-loss guarantee.
At the CE PE edge, there may be additional traIIic classes that are used by the service providers
only. For example, a management traIIic class Ior traIIic like Telnet or SNMP, Irom the service
provider to the service provider-managed CE routers.
II a single physical interIace is only serving one customer, the SLA is typically set up per
interIace. To provide easy bandwidth upgrades, service providers oIten install a high-speed link
to the customer and then oIIer a sub-rate access.
II a single physical interIace is serving many diIIerent customers, the SLA is typically set up
per PVC or per virtual LAN (VLAN). To provide easy bandwidth upgrades, the service
provider oIten installs a high-speed link to the customer and then oIIers a sub-rate access.
Know the SLA Offered by Your SP
· SLA typicaIIy incIudes
between 3 and 5 cIasses.
· ReaI-time traffic gets fixed
bandwidth aIIocation.
· Data traffic gets variabIe
bandwidth aIIocation with
minimum guarantee.
· AdditionaI cIasses not
visibIe to customer may
exist at the edge (for
exampIe,
management/controI
traffic).
To meet the QoS requirements Ior the diIIerent traIIic types, both the enterprise and the service
provider must implement the proper QoS mechanisms to provide end-to-end QoS Ior the
packets traversing across a service provider IP network. In the Iigure, the enterprise
headquarters and the enterprise branch oIIice are connected to a service provider that is
providing Layer 3 services.
In this example, the service provider is providing an SLA Ior voice traIIic with a latency oI 60
ms or less, a jitter oI 20 ms or less, and a packet loss oI 0.5 percent or less. To meet the end-to-
end QoS requirements Ior voice packets within headquarters, within the branch oIIice, and on
the two WAN edge links, the accumulative total delay should be 90 ms (150 to 60) or less, the
jitter should be 10 ms (30 to 20) or less, and the packet loss should be 0.5 percent (1 to 0.5) or
less.
TypicaI SLA Requirements for Voice
This Iigure shows an example oI a typical IP QoS SLA Irom an IP service provider. In this
example, the service provider is oIIering three service classes to the customer: controlled
latency, controlled load, best eIIort. This example SLA guarantees include:
For the controlled latency class:
A one-way delay oI 40 ms that is guaranteed 90 percent oI the time.
A jitter oI 2 ms that is guaranteed 90 percent oI the time.
A packet loss oI 0.5 percent that is guaranteed 90 percent oI the time.
For the controlled load class:
For the best-eIIort class:
This is just an example. Actual SLA oIIered by service providers may vary.
In the United States tier 1 Internet backbone, a typical round-trip time (RTT) delay between
two service provider POPs (points oI presence) is about 40 ms. It is typical Ior a service
provider to oIIer a monthly average loss on its network oI less than 1 percent.
Service Provider SLA ExampIe
This is just an exampIe. The actuaI SLA offered by service
providers may vary.
DepIoying End-to-End QoS Case Study
Introduction
This topic explains the typical network requirements within each Iunctional block (headquarter
campus LAN, WAN edge, service provider backbone, branch oIIice), which makes up the end-
to-end network used in the case study.
To meet the QoS requirements Ior diIIerent traIIic types, both the enterprise and the service
provider must implement the proper IP QoS mechanisms to provide end-to-end QoS Ior the
packets traversing across a service provider network.
Branch QoS is simiIar to Campus QoS
Introduction
To provide end-to-end QoS, both the enterprise and service provider must implement the
proper QoS mechanisms to ensure the proper PHBs Ior each traIIic class across the whole
network. Until recently, IP QoS was not an issue in an enterprise campus network where
bandwidth is plentiIul. But as more applications like IP telephony, videoconIerencing, e-
learning, and mission-critical data applications are being implemented in the campus, it has
become evident that buIIer management, not just bandwidth, is an issue that must be addressed.
IP QoS Iunctions such as classiIication, scheduling, and provisioning are also now required
within the campus to manage bandwidth and buIIers to minimize loss, delay, and jitter.
This Iigure lists some oI the requirements within the diIIerent building blocks that make up the
end-to-end network. Most oI the more complex QoS conIigurations occur at the WAN edge. In
the IP core (service provider cloud), only queuing like LLQ or MDRR and WRED should be
required.
DepIoying End-to-End QoS Overview
Enterprise Campus QoS ImpIementations
This Iirst part oI the case study explains some oI the best practice QoS implementations and
conIigurations within the campus LAN.
Applications like IP telephony, videoconIerencing, e-learning, and mission-critical data
applications are becoming more commonly implemented in enterprise networks. IP QoS
Iunctions such as classiIication, scheduling, and provisioning are required within the campus to
manage the LAN bandwidth and the LAN switches output buIIers to minimize loss, delay, and
jitter within these campus networks. There are many points in a campus network where QoS
mechanisms are required. Some oI the general guidelines when implementing campus QoS
include:
The campus network design should use a hierarchical design model, which has 3 layers:
access layer, distribution layer, and core layer.
Use multiple queues on the transmit interIaces to minimize the potential Ior dropped or
delayed traIIic caused by transmit buIIer congestion.
Real-time voice and video traIIic should have priority over the data traIIic.
Establish proper trust boundaries. For example, at the access layer switches, only trust the
IP Phone CoS marking, not the PC CoS marking.
ClassiIy and mark the traIIic as soon as possible. For example, use class-based markings at
the access layer switches to classiIy and mark the traIIic coming into the network.
NBAR can be used on the access or distribution switches to classiIy traIIic iI the switch
supports NBAR.
At the access or distribution layers, use class-based policing to limit any undesired non-
business-related excess traIIic: Ior example, rate-limiting peer-to-peer Iile-sharing traIIic to
a minimal rate.
Part 1: Campus QoS ImpIementation
· A robust, modern switching design is a requirement.
· Buffer management is more of a concern than bandwidth
management.
· MuItipIe queues are required on aII interfaces to prevent Tx
queue congestions/drops.
· Voice traffic shouId aIways go into the highest priority queue.
· Trust Cisco IP Phone CoS setting but not the PC CoS setting.
· CIassify and mark traffic as cIose to the source as possibIe.
· Use cIass-based poIicing to rate-Iimit certain unwanted excess
traffic.
Campus QoS GeneraI GuideIines:
No classiIication or marking should be done at the core layer, as this slows down traIIic.
The core layer provides high-speed transport between the distribution layers and generally
requires no QoS mechanisms.
Most oI the more complex QoS conIigurations like traIIic shaping, header compression,
LFI, LLQ, WRED, and re-marking oI traIIic occur at the WAN CE router.
The graphics will go through the typical QoS conIigurations that are required at the access and
distribution layer switches. In this example, core layer conIigurations will not be illustrated.
Typically, the high-speed core layer does not require any QoS mechanisms because all the links
are very high speed.
Campus Access and Distribution
Layer QoS ImpIementation
In this case study, the access layer switches are the Catalyst 3550 switches.
The recommended conIiguration Ior the transmit interIace Ior the Catalyst 3550 is one priority
queue and three queues, each with a single drop threshold.
Scheduling is perIormed using weighted round robin (WRR), where each queue is given a
relative weight while the priority queue is serviced exhaustively. The deIault CoS to queue
mapping is as Iollows:
Frames marked with a CoS 6 and 7 will go into queue 4 (priority queue Ior the Catalyst
3550).
Frames marked with a CoS 4 and 5 will go into queue 3.
When servicing voice traIIic, CoS 5 Irames should be conIigured to go to the priority (expedite)
queue. By deIault, Cisco IP Phones Iorward the voice traIIic with an 802.1Q priority oI 5
(CoS 5).
At the access layer switch, conIigure the trust boundary to trust only the CoS marking on the
Cisco IP Phone, not the CoS marking on the PC. Also conIigure the trust boundary to trust the
DSCP or CoS marking Irom the distribution layer switches, depending on the capabilities oI the
distribution layer switch that is attached.
CataIyst 3550 Access Switch
· 1P3Q2T (recommended) or 4Q2T
· WRR defauIt
÷ Each queue is given a reIative weight
with one priority queue
· DefauIt vaIues are as foIIows:
CoS VaIue CoS Priority Queues
0, 1 1
2, 3 2
4, 5 3
6, 7 4 (priority queue)
· Move CoS 5 traffic to queue 4
· Trust Cisco IP Phone on access Iinks
· Trust DSCP or CoS on upIinks
· CoS-to-DSCP mappings
· CIassify and mark mission-criticaI traffic
using ACLs
For Layer 2 to Layer 3 QoS mappings, the Catalyst 3550 has deIault CoS-to-DSCP mappings.
However, these deIault mappings can be manually conIigured to override the deIault mappings.
The deIault CoS-to-DSCP map is as Iollows:
Marker VaIue
CoS Values 0 1 2 3 4 5 6 7
DSCP
Values
0 8 16 24 32 40 48 56
As a general rule, it is best to classiIy and mark the traIIic as close to the source as possible.
ThereIore, at the access layer switches, class-based markings can be conIigured to classiIy and
mark the traIIic.
This Iigure shows a sample QoS conIiguration on a Catalyst 3550 access switch.
When classiIication oI traIIic by the access-layer switch is required, the Catalyst 3550 provides
a powerIul set oI Ieatures Ior classiIying traIIic as it enters the network. This conIiguration
example uses three class maps to classiIy traIIic into three classes (voice-bearer, voice-control
and mission-critical) using three extended IP access control lists (ACLs). The access ports are
conIigured to trust only the CoS markings Irom the Cisco IP Phone; all other traIIic will be
classiIied and marked using the traIIic policy called 'mark¨. This traIIic policy is used to mark
the voice-bearer class with a DSCP oI EF, the voice-control (call-signaling) class with a DSCP
oI 26, and the mission-critical class with a DSCP oI AF 31. This traIIic policy is then applied to
the switch access ports.
Note: Ìf using the Catalyst 2950, the ACLs are limited to match a single TCP or UDP port. For
example, the Catalyst 2950 ACLs cannot be used to match against a UDP or TCP port
range for matching VoÌP RTP bearer and control traffic.
The uplink switch ports are conIigured to trust the DSCP markings Irom the distribution layer
switches. Layer 3 capable distribution layer switches are being used in this case study.
The Catalyst 3550 supports multiple VLANs on the access port to which the Cisco IP Phone is
attached. The switchport voice vlan interIace conIiguration command is used to conIigure
voice VLAN on the port. In this example, all the voice traIIic Irom the access port will belong
to VLAN 111 while the data traIIic will belong to VLAN 11.
To ensure EF Ior the voice-bearer traIIic, all CoS 5 traIIic is conIigured to go into queue 4 (the
priority queue |PQ|) along with the CoS 6 and CoS 7 traIIic.
The deIault CoS-to-DSCP mapping is also changed so that CoS 3 (voice control) maps to AF
31, CoS 4 (videoconIerencing) maps to AF 41, and CoS 5 (voice bearer) maps to DSCP 46
(EF).
CataIyst 3550 Access Switch
Configuration
mls qos
!
!
class~map match~all voice~bearer
class~map match~all voice~control
class~map match~all mission~critical
!
policy~map mark
class voice~bearer
set ip dscp ef
class voice~control
set ip dscp 26
set ip dscp af31
!
access~list 101 permit udp any any range 16394 32767
access~list 102 permit tcp any any range 2000 2002
access~list 102 permit udp any any eq 2427
access~list 103 permit <Misson~Critical Traffic>
mls qos
!
!
class~map match~all voice~bearer
class~map match~all voice~control
class~map match~all mission~critical
!
policy~map mark
class voice~bearer
set ip dscp ef
class voice~control
set ip dscp 26
set ip dscp af31
!
access~list 101 permit udp any any range 16394 32767
access~list 102 permit udp any any eq 2427
access~list 103 permit <Misson~Critical Traffic>
!
description Uplink to Distribution
no ip address
mls qos trust dscp
priority~queue out
!
description to IP Phone
cdp enable
no ip address
service~policy input mark
mls qos trust cos
switchport priority extend cos 0
switchport voice vlan 111
switchport access vlan 11
priority~queue out
<output omitted>
!
description Uplink to Distribution
no ip address
mls qos trust dscp
priority~queue out
!
description to IP Phone
cdp enable
no ip address
service~policy input mark
mls qos trust cos
switchport priority extend cos 0
switchport voice vlan 111
switchport access vlan 11
priority~queue out
<output omitted>
In this case study, the distribution layer switches are the Catalyst 4000 switches.
The Catalyst 4000 has a total oI Iour queues, each with two diIIerent drop thresholds. The link
bandwidth can be conIigured to be shared diIIerently among the Iour transmit queues by
assigning the minimum guaranteed bandwidth Ior each transmit queue. By deIault, all Iour
queues are scheduled in a round robin manner with each queue having 25 percent oI the link
bandwidth. The transmit queue 3 on each port can be conIigured with higher priority. When
transmit queue 3 is conIigured with higher priority, packets in transmit queue 3 are scheduled
ahead oI packets in other queues. The deIault DCSP-to-transmit queue map (which can be
manually conIigured to override the deIault) is as Iollows:
DSCP 0-15 to queue 1
At the distribution switch, conIigure the trust boundary to trust the DSCP or CoS marking Irom
the core and access layer switches. For Layer 2 to Layer 3 and Layer 3 to Layer 2 QoS
mappings, the Catalyst 4000 has deIault CoS-to-DSCP and DSCP-to-CoS mappings. However,
these deIault mappings can be manually conIigured to override the deIault mappings. The
Catalyst 4000 has the Iollowing CoS-to-DSCP and DSCP-to-CoS mappings:
Marker VaIue
CoS Values 0 1 2 3 4 5 6 7
DSCP
Values
0 8 16 24 32 40 48 56
QoS in CataIyst 4000:
Distribution (SUPIII)
· 4 queues (1P3Q2T)
÷ ConfigurabIe PQ for queue 3
÷ CoS vaIue 4, 5 seIects queue 3
· Trust DSCP or CoS
· DefauIt mapping from CoS
to DSCP and DSCP to CoS
· CIass-based poIicing to
rate-Iimit traffic
DSCP-to-CoS DefauIt Mapping
Marker VaIue
DSCP
Values
0 - 7 8 - 15 16 - 23 24 - 31 32 - 39 40 - 47 48 - 55 56 - 63
CoS Values 0 1 2 3 4 5 6 7
Class-based policing may also be implemented to rate-limit certain traIIic classes.
This Iigure shows a sample QoS conIiguration on a Catalyst 4000 distribution switch.
This conIiguration uses a class map to classiIy the Citrix server traIIic into the citrix-server
traIIic class.
A traIIic policy called 'police-citrix¨ is used to police the Citrix traIIic to a CIR oI 48000 bps
with a committed burst (Bc) oI 8000 bits. All excess traIIic is dropped.
The downlink and uplink ports are conIigured to trust the DSCP markings Irom the access and
core layer switches.
The transmit queue 3 is conIigured as the high-priority queue.
CataIyst 4000 Distribution Switch
Configuration
class~map citrix~server
!
policy~map police~citrix
class citrix~server
police 48000 8000 exceed~action drop
!
description to access switch
service~policy in police~citrix
qos trust dscp
tx~queue 3
priority high
!
description to core
qos trust dscp
tx~queue 3
priority high
!
access~list 1 permit host <citrix~server IP address>
class~map citrix~server
!
policy~map police~citrix
class citrix~server
police 48000 8000 exceed~action drop
!
description to access switch
service~policy in police~citrix
qos trust dscp
tx~queue 3
priority high
!
description to core
qos trust dscp
tx~queue 3
priority high
!
access~list 1 permit host <citrix~server IP address>
WAN Edge (CE/PE) QoS ImpIementations
This second part oI the case study explains some oI the best practice QoS implementations and
conIigurations on the WAN CE and PE routers.
The Iollowing slides will go through the typical QoS conIigurations that are required at the CE
and PE WAN routers.
On the CE PE WAN link, LLQ/CBWFQ, traIIic shaping, cRTP, and LFI are typically required.
DepIoying End-to-End QoS Case Study Part 2:
WAN Edge (CE/PE) QoS ImpIementation
The QoS requirements on the CE and PE router will diIIer, depending on whether or not the CE
is managed by the service provider.
For traIIic leaving the enterprise CE router towards the service provider PE router, the Iigure
illustrates the general QoS requirements on the CE and PE routers.
For managed CE service, the WAN edge output QoS policy on the CE will be managed and
conIigured by the service provider.
For unmanaged CE service, the WAN edge output QoS policy on the CE will be managed and
conIigured by the enterprise customer.
For managed CE service, the service provider can enIorce the SLA Ior each traIIic class using
the output QoS policy on the CE; Ior example, use LLQ/CBWFQ to give a maximum
bandwidth guarantee to the real-time voice and video traIIic class and give a minimum
bandwidth guarantee to the data traIIic classes and use class-based shaping to provide a
maximum rate limit to each data traIIic class.
For unmanaged CE service, because the service provider has no control oI the CE, the service
provider can only enIorce the SLA Ior each traIIic class at the input oI the PE router. For
example, use class-based policing to rate-limit the input traIIic rate oI the diIIerent traIIic
classes and to re-mark the exceeding traIIic.
Traffic Leaving Enterprise Network
· Output QoS poIicy on CE
controIIed by SP.
· SP enforces SLA using the
output QoS poIicy on CE.
· Output poIicy uses queuing,
dropping, and possibIy shaping.
· EIaborate traffic cIassification
or mapping of existing
markings.
· May require LFI / cRTP.
· Output QoS poIicy on CE not
controIIed by SP.
· SP enforces SLA using input
QoS poIicy on PE.
· Input poIicy uses poIicing and
marking.
· EIaborate traffic cIassification
or mapping of existing
markings on PE.
For the traIIic leaving the CE router, this Iigure illustrates the diIIerent QoS mechanisms that
are commonly implemented at the CE and PE routers, depending on whether or not the CE is
managed by the service provider.
For example, Ior unmanaged CE, the CE output policy is managed and conIigured by the
enterprise customer. ThereIore, it is irrelevant to the service provider. At the PE input interIace,
the service provider will have a policy to classiIy, mark, or remaps the traIIic. The service
provider also typically implements traIIic policing to rate-limit the input traIIic rate Irom the
enterprise customer so the traIIic rate does not exceed the contractual rate as speciIied in the
SLA.
For managed CE, the CE output policy is managed and conIigured by the service provider. The
service provider typically has an output policy on the CE router to classiIy and mark the traIIic
exiting the CE router. LLQ/CBWFQ and WRED are also used to Ior congestion management
and congestion avoidance. To compensate Ior speed mismatch or oversubscription, traIIic
shaping may be required. To improve the link eIIiciency, LFI and cRTP are used.
Traffic Leaving Enterprise
Network (Cont.)
CE
Output PoIicy
CIassification /
Marking / Mapping
LLQ
WRED
[Shaping]
[LFI / cRTP]
PE
Input PoIicy
<Not required>
CE
Output PoIicy
<irreIevant>
PE
Input PoIicy
CIassification /
Marking / Mapping
PoIicing
For traIIic leaving the service provider PE router towards the enterprise CE router, this Iigure
illustrates the general QoS requirements on the CE and PE routers.
For both managed and unmanaged CE service, the service provider can enIorce the SLA Ior
each traIIic class using the output QoS policy on the PE. For example, use LLQ/CBWFQ to
give a maximum bandwidth guarantee to the real-time voice and video traIIic class and give a
minimum bandwidth guarantee to the data traIIic classes and use class-based shaping to provide
a maximum rate limit to each data traIIic class.
Traffic Leaving Service Provider
Network
output QoS poIicy on PE.
dropping, and optionaIIy,
shaping.
· No input QoS poIicy on CE
needed.
output QoS poIicy on PE.
dropping, and optionaIIy,
shaping.
· Input QoS poIicy on CE
irreIevant.
For traIIic leaving the service provider PE router towards the enterprise CE router, this Iigure
illustrates the diIIerent QoS mechanisms that are commonly implemented at the PE router.
For both managed and unmanaged CE service, the service provider typically has an output
policy on the PE router using LLQ/CBWFQ and WRED Ior congestion management and
congestion avoidance. To compensate Ior speed mismatch or over-subscription, traIIic shaping
may be required. To improve the link eIIiciency, LFI and cRTP are used.
A customer edge input policy is not required Ior managed and unmanaged CE services.
Traffic Leaving Service Provider
Network (Cont.)
CE
Input PoIicy
<Not needed>
PE
Output PoIicy
LLQ
WRED
[Shaping]
[LFI / cRTP]
CE
Input PoIicy
<IrreIevant>
PE
Output PoIicy
LLQ
WRED
[Shaping]
[LFI / cRTP]
Managed CE with Three Service
CIasses ExampIe
The service provider in this case study is offering managed
customer edge service with three service cIasses:
· Premium (VoIP): Maximum bandwidth, Iow Iatency, no Ioss
· Business: Maximum bandwidth, Iow Ioss
· CIass-DefauIt: No guarantees (best effort)
Most DiffServ depIoyments use a proportionaI
differentiation modeI:
· Rather than aIIocate absoIute bandwidths to each cIass, service
provider adjusts reIative bandwidth ratios between cIasses to
achieve SLA differentiation:
÷ VoIP serviced with priority up to a max. % of bandwidth, for
exampIe, 25%
÷ Business cIass gets majority of remaining bandwidth, for
exampIe, 75%
÷ Best effort gets whatever is Ieft, for exampIe, 25% of
remaining bandwidth
In this case study, the service provider is implementing an IP DiIIServ backbone and is oIIering
three traIIic classes with diIIerent SLAs Ior each:
The premium traIIic class is intended Ior voice traIIic. This class has a maximum
bandwidth limit, a low latency, and no loss guarantee.
The business traIIic class is intended Ior mission-critical traIIic. This class has a minimum
bandwidth and a low loss guarantee.
The deIault (best eIIort) traIIic class is intended Ior all other traIIic. This class has no
guarantee.
When implementing LLQ/CBWFQ, the bandwidth guarantees can be speciIied in kbps or in
percent oI the available bandwidth or in percentage oI the remaining available bandwidth. Most
DiIIServ deployments today use a proportional diIIerentiation model where the bandwidth
guarantees are conIigured as a percentage instead oI a Iixed kbps.
For example, with three traIIic classes, the bandwidth allocation can be divided as such:
The premium (VoIP) class LLQ can have a maximum bandwidth guarantee oI 25 percent
oI the link bandwidth.
The business (mission-critical) class can have a minimum bandwidth guarantee oI 75
percent oI the remaining bandwidth aIter the LLQ is serviced.
The deIault (best eIIort) class can have a minimum bandwidth guarantee oI whatever is leIt,
in this case, 25 percent oI the remaining bandwidth aIter the LLQ is serviced.
This slide highlights the required PHB Ior each oI the three traIIic classes supported by the
service provider.
For the premium (VoIP) traIIic class, the VoIP packets will be marked with EF and go into the
LLQ with the Iollowing parameters:
The LLQ will be policed and have a maximum bandwidth oI 25 percent oI the CIR.
All excess traIIic will be dropped.
The call-signaling traIIic will share the LLQ with the VoIP bearer traIIic.
For the business (mission-critical) traIIic class, the business class packets will be marked with
AF 31 and go into the CBWFQ:
This class will be policed and have a minimum bandwidth guarantee oI 75 percent oI the
remaining available bandwidth.
All exceeding and violating traIIic will be re-marked then sent.
WRED will be used on this traIIic class to optimize TCP throughput.
For the deIault (best eIIort) traIIic class, the best-eIIort class packets will be marked with DSCP
oI 0:
This class is not policed and has a minimum bandwidth guarantee oI 25 percent oI the
remaining available bandwidth.
WRED will be used on this traIIic class to optimize TCP throughput.
WAN Edge Design
· VoIP
÷ EF cIass LLQ
÷ Max BW = 25% of CIR
÷ PoIiced
÷ excess dropped
÷ VoIP signaIIing shares the LLQ with VoIP traffic
· Business data
÷ AF31 cIass CBWFQ
÷ AIIocated 75% of remaining bandwidth once LLQ has been serviced
÷ PoIiced
÷ excess/vioIate remarked
÷ WRED configured to optimise TCP throughput
· Best Effort
÷ BE cIass CBWFQ
÷ Whatever is Ieft = 25% of remaining bandwidth once LLQ has been serviced
÷ WRED configured to optimise TCP throughput
This Iigure shows the QoS conIigurations on the managed CE router outbound interIace to
implement the required QoS policy required Ior each oI the three service provider traIIic
classes. The traIIic policy called 'OUT-POLICY¨ is conIigured to provide the LLQ/CBWFQ
and WRED. Each traIIic class bandwidth guarantee is conIigured using a percentage rather than
a Iixed bandwidth in kbps.
Both the enterprise voice bearer and voice control traIIic will be matched using access-list 101
and will be serviced by the LLQ with a maximum bandwidth guarantee oI 25 percent oI the
link bandwidth.
The enterprise mission-critical traIIic will be matched using access-list 102 and has a minimum
guarantee bandwidth oI 75 percent oI the remaining available bandwidth aIter the LLQ has
been serviced.
All other traIIic Irom the enterprise will be classiIied into the deIault class and has a minimum
guarantee bandwidth oI 25 percent oI the remaining available bandwidth aIter the LLQ has
been serviced.
CE-to-PE QoS for Frame ReIay Access
CE Outbound
In this example, the CE and PE link is a Frame Relay link and traIIic shaping is implemented
on the PVC using FRTS.
FRTS is conIigured using a Frame Relay map class with a committed inIormation rate (CIR) oI
256 kbps, a Bc oI 2560 bits, an excess burst (Be) oI 0 (no bursting), and a minimum CIR
(mincir) oI 128 kbps. The CIR is the rate you want to normally send at when there is no
congestion. The CIR needs to be remote end link speed or the actual CIR oI the virtual circuit.
The Bc is the amount you will send per time interval. The CIR and Bc will be used to compute
a committed time window (Tc), where Tc ÷ Bc/CIR. For FRTS, CLI will only allow Bc values
that would result in a Tc that is between 10 ms and 125 ms. A recommended value Ior Tc is 10
ms. To get a Tc oI 10 ms, the Bc should set to 1/100 oI the CIR. The mincir is the lower bound
value that you will slow down to during congestion. II adaptive shaping is enabled, the mincir
must be larger than required voice bandwidth.
FRF.12 Iragmentation and interleaving and cRTP are also enabled within the Frame Relay map
class. The Iragment size in bytes is set to derive 10 ms to 15 ms delay maximum. The Iragment
size should be same on both ends.
The 'OUT-POLICY¨ traIIic policy deIined on the previous slide is applied within the Frame
Relay map class.
CE Outbound (Cont.)
This Iigure shows the QoS conIigurations on the ingress PE router inbound interIace to
implement the required QoS policy that is required Ior each oI the three service provider traIIic
classes.
In this case, a traIIic policy called 'IN-POLICY¨ is conIigured to provide the required class-
based policing. For the premium class, the rate limit is set to 25 percent oI the link bandwidth.
All exceeding premium class traIIic is dropped. For the business class, the rate limit is set to 38
percent oI the link bandwidth. All exceeding and violating business class traIIic are re-marked
with a higher drop probability then sent. The deIault class is not policed.
The 'IN-POLICY¨ traIIic policy is applied within the Frame Relay map class.
PE Inbound
This Iigure is similar to the previous Iigure except that the service provider core is now
Multiprotocol Label Switching (MPLS) instead oI IP. The diIIerences here are the markings
within the traIIic policy. In this case, a traIIic policy called 'IN-POLICY¨ is conIigured to
provide the required class-based policing. The premium and business class traIIic is policed and
then marked with the proper MPLS experimental bits:
All conIorming premium traIIic is marked with MPLS experimental 5 then sent.
All exceeding premium traIIic is dropped.
All conIorming business traIIic is marked with MPLS experimental 4 then sent.
All exceeding business traIIic is marked with MPLS experimental 3 then sent.
All violating business traIIic is marked with MPLS experimental 2 then sent.
The best-eIIort class traIIic is not policed but just marked with MPLS experimental 0.
The 'IN-POLICY¨ traIIic policy is applied within the Frame Relay map class.
PE Inbound (Cont.)
Service Provider Backbone QoS ImpIementations
This third and last part oI the case study explains some oI the best practice QoS
implementations and conIigurations on the service provider IP core PE and P routers.
The Iigures will go through the typical QoS conIigurations required at the PE and P routers
within the service provider IP core network.
The service provider IP core is used to provide high-speed packet transport. ThereIore, all the
markings, policing, and shaping should be perIormed only at the PE router on the PE-to-CE
link and not at the core.
Using the DiIIServ model, only the edge requires complex QoS policy. At the core, only
queuing and WRED are required. The operation oI queuing and WRED will be based on the
markings done at the edge (PE).
It is common to implement GSRs within the service provider IP core. With the GSRs, the
queuing mechanism is MDRR. II a router like the 7500 is used in the core, then LLQ will be
the queuing mechanism. (In this case study, only the 7500 LLQ/WRED conIigurations will be
discussed.)
DepIoying End-to-End QoS Case Study Part 3:
Service Provider Backbone QoS ImpIementation
· Marking, poIicing, and
shaping shouId be
done at the edges
of the network.
· Queuing and
dropping done in the
core based on packet
marking done at the
edge.
Two oI the IP backbone design methods include a best-eIIort backbone with overprovisioning
and a DiIIServ backbone.
The more traditional approach is to use a best-eIIort backbone with overprovisioning. However,
to meet the application needs oI today (VoIP, videoconIerencing, e-learning, and so on),
deploying a DiIIServ backbone and oIIering diIIerent SLAs Ior the diIIerent traIIic classes can
greatly reduce the cost and improve the delay, jitter, and packet loss and meet network QoS
requirements.
With overprovisioning, service provider typically uses an overprovisioning Iactor oI 2. For
example, iI the aggregate traIIic load on the network is 10 Gbps, then the network is
provisioned Ior 20 Gbps oI maximum capacity. Some oI the problems with a best-eIIort
backbone with overprovisioning include:
II the capacity planning is not accurate and congestion occurs, because the traIIic types are
not diIIerentiated, the VoIP packets will not be treated with higher priority than other data
traIIic resulting in suboptimal treatment Ior VoIP packets.
Overprovisioning Ior all traIIic is very expensive to implement.
During capacity planning, maybe not all the Iailure scenarios are analyzed. Unplanned
Iailures can cause unexpected congestions in the network. A link or node Iailure leading to
traIIic re-routing can take up all the excess capacity.
The network can experience unexpected traIIic demands, which can cause congestions in
the network.
Denial oI Service (DOS) attacks on one service will aIIect all other services.
Using DiIIServ, the traIIic is isolated into diIIerent classes, and each traIIic class is provisioned
with a diIIerent traIIic policy that is based on the QoS requirements oI the traIIic class. This
will reduce the cost and provide better overall latency, delay, and jitter.
Service Provider Backbone
· Overprovisioning best-effort
backbone is an aIternative
but, has these drawbacks:
÷ Expensive
÷ Fate sharing
÷ PIanning mistakes
÷ FaiIure conditions
÷ Unexpected traffic demand
· DiffServ backbone is better
This Iigure lists two oI the main beneIits oI using DiIIServ over a best-eIIort with
overprovisioning backbone.
Instead oI overprovisioning based on the aggregate bandwidth oI all traIIic, with DiIIServ, each
traIIic class can be designed with diIIerent provisioning ratios. II the premium traIIic class is
only 20 percent oI the total capacity, then overprovisioning Ior 100 percent oI the traIIic load is
expensive and not necessary in order to guarantee the QoS requirements Ior the premium traIIic
class.
Let us examine an overprovisioning example with and without DiIIServ:
II the total aggregate bandwidth is 10 Gbps, where the premium class ÷ 2 Gbps, the
business class ÷ 3 Gbps, and the deIault class ÷ 5 Gbps:
With best eIIort and an overprovisioning ratio oI 2:1, the provisioned bandwidth ÷
10G * 2÷ 20 Gbps.
With DiIIServ, and the premium class having an overprovisioning ratio oI 2:1, the
business class having a lower overprovisioning ratio oI 1.5:1, and the deIault class
not having any overprovisioning, the provisioned bandwidth ÷ (2 G * 2) ¹ (3 G *
1.5) ¹ 5 G ÷ 13.5Gbps.
By isolating the traIIic into diIIerent traIIic classes then treating the diIIerent traIIic classes
with diIIerent PHBs, DiIIServ can reduce the bandwidth requirement on the network while
achieving the same SLA when compared to the non-DiIIServ case.
What are the benefits of using a
DiffServ backbone?
· DiffServ aIIows support of muItipIe cIasses of
traffic with different underprovisioning and
overprovisioning ratios per cIass of service.
· Maximum potentiaI economic benefit of DiffServ
stands to be gained from where the traffic
requiring the highest SLA targets represents a
minor proportion of the overaII capacity.
The Iigures will go through the typical QoS conIigurations required at the service provider core
PE and P routers.
The complex QoS policies with classiIication and markings, policing, shaping, LFI, cRTP are
only required at the edge. In the core, only LLQ (or MDRR Ior GSR) and WRED are needed.
This Iigure shows the QoS conIigurations on the ingress PE router outbound interIace to the P
router.
In this case, a traIIic policy called 'OUT-POLICY¨ is conIigured to provide the LLQ/CBWFQ
No inbound policy is required on the P router.
PE-to-P QoS
PE Outbound
This Iigure shows the QoS conIigurations on the P router outbound interIace to another P
router.
No inbound policy is required on the receiving P router.
P-to-P QoS
P Outbound
This Iigure shows the QoS conIigurations on the P router outbound interIace to the egress PE
router.
No inbound policy is required on the egress PE router.
P-to-PE QoS
P Outbound
This is the continual discussion oI the PE CE WAN edge QoS requirements.
This Iigure shows the QoS conIigurations on the egress PE router outbound interIace to
implement the required QoS policy required Ior each oI the three service provider traIIic
classes (as previously discussed).
No inbound policy is required on the CE router.
PE-to-CE QoS for Frame ReIay Access
PE Outbound
In this example, the PE-CE link is a Frame Relay link and Frame Relay traIIic shaping (FRTS)
is enabled on the permanent virtual circuit (PVC).
FRTS is conIigured using a Frame Relay map class with a CIR oI 512 kbps, a Bc oI 5120 bits,
a Be oI 0 (no bursting), and a mincir oI 256 kbps. The CIR is the rate you want to normally
send at when there is no congestion. The CIR needs to be remote end link speed or the actual
CIR on virtual circuit. The Bc is the amount you will send per time interval. The CIR and Bc
will be used to compute a Tc, where Tc ÷ Bc/CIR. For FRTS, CLI will only allow Bc values
that would result in a 125 ms · Tc ·10 ms. A recommended value Ior Tc is 10 ms. To get a Tc
oI 10 ms, the Bc should set to 1/100 oI the CIR. The mincir is the lower bound value you will
slow down to during congestion. II adaptive shaping is enabled, the mincir must be larger than
required voice bandwidth.
FRF.12 Iragmentation and interleaving and cRTP are also enabled within the Frame Relay map
class. The Iragment size in bytes is set to derive 10 ms to 15 ms delay maximum. The Iragment
size should be same on both ends.
The 'OUT-POLICY¨ traIIic policy deIined on the previous slide is applied within the Frame
Relay map class.
PE-to-CE QoS for Frame ReIay Access
PE Outbound (Cont.)
Summary
Summary
· At the campus, a robust, modern switching design is a
requirement.
· Queuing and scheduIing capabiIities differ for different
CataIyst switches.
· Voice traffic shouId aIways go into the high-priority
queue.
· EstabIish proper trust boundary, for exampIe mIs qos
trust device cisco-phone.
· CIassify and mark traffic as cIose to the source as
possibIe.
· CataIyst switches Iike the 2950 and 3550 have defauIt
CoS-to-DSCP and DSCP-to-CoS mappings.
· Use cIass-based poIicing to rate-Iimit certain non-
business reIated traffic.
Summary (Cont.)
· QoS SLA is a key differentiator for service providers.
· Different QoS design options for managed versus
unmanaged customer edge.
· DiffServ backbone aIIows support of muItipIe cIasses of
traffic with different or over/underprovisioning ratios per
cIass of service.
· Marking, poIicing, and shaping shouId be done at the
edges of the network.
· Queuing and dropping done in the service provider
backbone based on packet marking at the edge.
· Service provider typicaIIy offers one priority cIass for
Iow-Iatency traffic pIus a smaII number of additionaI
cIasses for other traffic. AdditionaI traffic cIasses not
visibIe to customer may exist at the edge (for exampIe,
management/controI traffic).
References
For more inIormation on Enterprise QoS Design, reIer to 'Cisco AVVID Network
InIrastructure Enterprise Quality oI Service Design¨ at the Iollowing URL:
http://www.cisco.com/application/pdI/en/us/guest/netsol/ns17/c649/ccmigration¸09186a00
800d67ed.pdI
For more inIormation on end-to-end QoS implementation, reIer to 'Implementing DiIIServ
Ior End-to-End Quality oI Service Overview¨ at the Iollowing URL:
qcIdIsrv.pdI
Quiz
Q1) What is an advantage oI using a DiIIServ backbone over a best-eIIort backbone?
A) provide better guarantee Ior the best-eIIort traIIic class
B) simpliIy conIigurations on the core backbone routers
C) reduce the cost by using diIIerent overprovisioning ratio Ior diIIerent traIIic
class
D) provide more deterministic network response by allowing the use oI a single
overprovisioning ratio Ior all aggregated traIIic
Q2) At which two layers oI the campus network is traIIic policing typically implemented?
(Choose two.)
A) core layer
B) access layer
C) distribution layer
D) data center layer
Q3) Which one oI the Iollowing is correct about traIIic classiIication?
A) It is best practice to classiIy and mark traIIic at the core layer switches.
B) It is best practice to classiIy and mark traIIic as close to the destination as
possible.
C) It is best practice to classiIy and mark traIIic as close to the source as possible.
D) It is best practice to classiIy and mark traIIic using an external server running
NBAR.
Q4) Which two QoS mechanisms are typically deployed at the service provider core (non-
GSR) routers? (Choose two.)
A) LFI
B) LLQ
C) WRED
D) class-based shaping
E) class-based RTP header compression
Q5) What two queue types can the Catalyst 2950 queues be conIigured as? (Choose two.)
A) WFQ
B) FIFO
C) PQ
D) CQ
E) WRR
Q6) With managed CE service, what inbound QoS policy is typically required at the PE
router?
A) none
B) LFI and cRTP
C) traIIic shaping
D) traIIic policing
E) classiIication/marking
Q7) When would an SLA be set up per PVC or per VLAN?
A) iI using managed CE services
B) iI the service provider is using a DiIIServ backbone
C) iI a single physical interIace is serving one customer
D) iI a single physical interIace is serving many diIIerent customers
E) iI the service provider is using a best-eIIort backbone with overprovisioning
Q8) What is used by service providers to provide a contractual assurance Ior parameters
such as delay, jitter, packet loss, throughput, and availability?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Q9) What are two possible causes oI congestion on LAN switch ports? (Choose two.)
F) port speed mismatch
G) ISL or 802.1Q trunking overhead
H) Iull duplex communications on trunk ports
I) excessive delays caused by CSMA/CD operations
J) many access ports being aggregated into a single uplink
Quiz Answer Key
Q1) C
ReIates to: Service Provider Backbone QoS Ìmplementations
Q2) B, C
ReIates to: Enterprise Campus QoS Ìmplementations
Q3) C
Q4) B, C
ReIates to: Service Provider Backbone QoS Ìmplementations
Q5) C, E
Q6) A
ReIates to: WAN Edge (CE/PE) QoS Ìmplementations
Q7) D
ReIates to: QoS Service Level Agreements
Q8) An IP QoS Service Level Agreement
ReIates to: QoS Service Level Agreements
Q9) A, E
Module Assessment
Overview
Quiz: QoS Best Practices
Objectives
Correctly identiIy and describe the set oI classiIication practices that most closely represent
Cisco QoS 'best practices¨
Correctly identiIy and describe the set oI QoS mechanisms used to implement Cisco end-to
end QoS 'best practices¨ in a typical enterprise network connected through a service
provider providing Layer 3 IP services
Instructions
incorrectly.
Q1) Which three oI the Iollowing QoS tools is used to manage the delay, delay variation
(jitter), bandwidth, and packet-loss parameters on a network? (Choose three.)
A) coding/decoding (codec) tools
B) Ilow-control (windowing) tools
C) scheduling tools
D) provisioning tools
E) classiIication tools
Q2) Which oI the Iollowing statements is true regarding the bandwidth requirement oI data
applications?
A) It is not possible to provide a blanket rule Ior provisioning data bandwidth
because the bandwidth requirements vary greatly Irom application to
application (and even between versions oI the same applications).
B) All ERP applications have similar bandwidth requirements.
C) All data applications should be provisioned a minimum bandwidth guarantee
matching their data rate ¹ 20 percent.
D) ERP applications should use the LLQ and be provisioned a maximum
bandwidth guarantee matching their data rate.
Q3) List three QoS requirements Ior voice. (Choose three.)
A) latency 150 ms
B) jitter 30 ms
C) loss 1 percent
D) bandwidth ÷ 80 kbps per call minimum Ior all codecs
E) retransmit interval 10 ms
Q4) Which three oI the Iollowing statements is a general guideline Ior implementing
campus QoS? (Choose three.)
A) Use multiple queues on the transmit interIaces to minimize the potential Ior
dropped or delayed traIIic caused by transmit buIIer congestion.
B) ClassiIication or marking should be done at the high-speed core layer.
C) Most oI the more complex QoS conIigurations, like traIIic shaping, header
compression, LFI, LLQ, and WRED, occur at the (CE) WAN edge router.
D) Establish proper trust boundary. For example, at the access layer switches, only
trust the IP Phone CoS marking, but not the PC CoS marking.
E) Always use NBAR to classiIy traIIic because all Cisco Catalyst switches
support NBAR.
F) QoS in the campus is generally not a buIIer management issue as much as it is
a bandwidth management issue. ThereIore, link eIIicient mechanisms should
be implemented between the access and distribution layer links.
Q5) The Cisco Catalyst 2950 switch has Iour transmit queues with a single drop threshold.
By deIault, the transmit queues are serviced with which type oI scheduling?
A) Priority
B) WRR
C) MDRR
D) FIFO
Q6) What are two typical PHB behaviors required Ior the EF traIIic class? (Choose two.)
A) policed to a maximum bandwidth by LLQ
B) guaranteed a minimum bandwidth by CBWFQ
C) the dropping method should be tail-drop
D) the dropping method should be WRED to prevent congestion
Q7) Based on the Iollowing conIiguration, which two statements are true? (Choose two.)
class-map match-all PREMIUM
match ip access-group I0I
class-map match-all BUSINESS
match ip access-group I0?
!
policy-map OUT-POLICY
class PREMIUM
priority percent ?S
set ip dscp ef
class BUSINESS
bandwidth percent remaining IS
set ip dscp af·I
class class-default
bandwidth percent remaining ?S
set ip dscp 0
A) The premium traIIic class has a maximum bandwidth guarantee equal to 25
percent oI the available interIace bandwidth.
B) The business traIIic class has a maximum bandwidth guarantee equal to 75
percent oI the interIace bandwidth.
C) The deIault traIIic class has a maximum bandwidth guarantee equal to 25
percent oI the interIace bandwidth.
D) Tail drop is used on the business traIIic class.
E) WRED is used on the premium traIIic class.
F) WRED is used on the deIault traIIic class.
Q8) What is wrong with the Iollowing conIiguration?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
class-map match-all PREMIUM
match ip dscp ef
class-map match-all BUSINESS
match ip dscp af·I
!
policy-map IN-POLICY
!
class PREMIUM
police percent ?S
exceed-action drop
!
class BUSINESS
police percent S8
exceed-action set-mpls-exp-transmit ·
violate-action set-mpls-exp-transmit ?
!
class class-default
set mpls experimental 0
!
interface Serial0/0.I point-to-point
ip address I0.·?.I4.? ?SS.?SS.?SS.0
service-policy input IN-POLICY
Q9) II the service provider core network is using Cisco GSR as the P routers, what will be
the queuing mechanism used on the Cisco GSR P routers?
A) MDRR
B) LLQ
C) CBWFQ
D) D-WFQ
E) IP RTP Priority
Q10) The QoS requirements on the CE and PE router diIIer depending on what Iactor?
A) whether or not the PE router is managed by the service provider or not
B) whether or not the CE router is managed by the service provider or not
C) whether or not the service provider is using an MPLS core or not
D) the number oI traIIic classes supported by the service provider
E) the SLAs oIIered by the service provider
Scoring
or better.
Q1) C, D, E
ReIates to: Traffic Classification Best Practices
Q2) A
Q3) A, B, C
Q4) A, C, D
ReIates to: Case Study: End-to-End QoS
Q5) A
Q6) A, C
Q7) A, F
Q8) The conIorm actions are missing Irom the conIiguration.
ReIates to: End-to-End QoS
Q9) A
Q10) B
ModuIe Summary
When an enterprise network is connected by a service provider that provides Layer 3 IP
services, both the enterprise and the service provider must implement the proper IP QoS
mechanisms. This is necessary to satisIy the end-to-end QoS requirements oI the diIIerent
applications running at the enterprise. A key diIIerentiator Ior service providers when oIIering
Layer 3 IP services is to oIIer SLAs Ior each oI the traIIic classes supported by the service
provider. SLAs provide the needed assurance to the enterprise customers that the service
provider network can meet the QoS requirements oI the enterprise applications traversing
across the service provider network.
This module discusses some oI the key best practices Ior deploying IP QoS at the enterprise
and at the service provider network. The Iirst lesson oI the module included a baseline traIIic
classiIication recommendation detailing the PHB, DSCP, IP precedence, and Layer 2 CoS
values Ior some oI the common enterprise traIIic types. The recommendation can be reIerenced
by network engineers and designers as a guide Ior overall system design and QoS Ieature
implementation.
The second lesson oI this module provides a long case study illustrating the typical IP QoS
implementations at the enterprise campus LAN, at the WAN edge (CE and PE routers), and at
the service provider core.
Within the enterprise campus LAN, a hierarchical design is required along with proper buIIer
management at the LAN switches. ClassiIication and marking should be perIormed as close to
the source as possible. Class-based policing can be implemented to rate-limit certain non-
business-related applications (like peer-to-peer Iile sharing applications, Napster, and so on).
ModuIe Summary
· QoS Best Practices incIude:
÷ Ensuring reaI-time traffic gets priority with minimaI deIay.
÷ Ensuring that mission-criticaI traffic is serviced appropriateIy.
÷ Do not assign too many appIications to mission-criticaI traffic cIass.
÷ Ensure adequate bandwidth is provisioned for the defauIt cIass.
÷ EstabIish proper trust boundary. CIassify and mark traffic as cIose to
the source as possibIe.
÷ Use cIass-based poIicing to rate-Iimit certain non-business-reIated traffic.
· QoS SLA is a key differentiator for service providers. SLAs typicaIIy
incIude between 3 to 5 cIasses. AdditionaI cIasses not visibIe to
customers may exist at the edge (for exampIe, for
management/controI traffic).
· Different QoS design options are required for managed versus
unmanaged CE.
· DiffServ backbone aIIows support of muItipIe cIasses of traffic with
different under/overprovisioning ratios per service cIass.
· DiffServ can reduce the bandwidth requirement on the network whiIe
achieving the same SLA when compared to the non-DiffServ case.
More complex QoS conIigurations will be required at the WAN edge. The QoS conIiguration
required at the WAN edge CE and PE routers is diIIerent depending on whether or not the CE
is managed by the service provider or by the enterprise customer. LLQ/CBWFQ will be
required Ior congestion management. TraIIic shaping will be required on Frame Relay PVCs.
Link eIIicient mechanisms like LFI and cRTP will be required to improve the WAN link
eIIiciency. Class-based marking is also required iI the enterprise customer traIIic classes need
to be remapped into the service provider traIIic classes.
At the service provider high-speed core, typically only WRED or LLQ/MDRR are required,
based on the previous packet QoS marking. In the service provider core (backbone), two oI the
design options include implementing a best-eIIort backbone with overprovisioning or
implementing a DiIIServ backbone with a diIIerent provisioning ratio Ior each traIIic class. By
deploying a DiIIServ backbone, service providers can signiIicantly reduce their cost while
providing the required SLAs Ior their customers.
QOS
Course Glossary
The Course Glossary Ior Implementing Cisco Quality of Service (QOS) v2.0 highlights and
deIines key terms and acronyms used throughout this course. Many oI these terms are also
described in the Cisco Internetworking Terms and Acronyms resource, available via
http://www.cisco.com.
Acronym or
Term
Short Definition for
Mouseover
Expansion and Definition of
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Description for this
Course Context
802.1p ÌEEE specification
for defining priority.
Defined in the ÌEEE 802.1Q
specification as the priority field.
Within the Tag Control Ìnformation
field, the priority field is 3-bits and
hence represents up to 8 priority
levels. The ÌEEE 802.1p specification
defines the use of these 3 bits.
http://www
.cisco.com
/univercd/
cc/td/doc/
product/so
ftware/ios
121/121ne
wft/121t/1
21t3/dtbrid
ge.htm
802.1Q ÌEEE specification
for tagging Ethernet
frames with VLAN
information.
ÌEEE specification for inserting VLAN
membership information into Ethernet
frames. The VLAN information is
inserted into the frame in a field called
the Tag Control Ìnformation that
contains VLAN and QoS priority
identification.
http://www
.cisco.com
/univercd/
cc/td/doc/
product/so
ftware/ios
121/121ne
wft/121t/1
21t3/dtbrid
ge.htm
ACK acknowledgment.
Notification
indicating
successful receipt of
a message.
acknowledgment. Notification sent
from one network device to another to
acknowledge that some event
occurred (for example, the receipt of a
message). Sometimes abbreviated
ACK.
ÌTA/Jan
2001
ACL access control list.
Filter list used for
services such as
security, QoS, and
routing.
access control list. A list kept by
routers to control access to or from
the router for a number of services.
(For example, to prevent packets with
a certain ÌP address from leaving a
particular interface on the router).
ÌTA/Jan
2001
AF Assured Forwarding Assured Forwarding. A DSCP PHB
providing for the delivery of ÌP packets
in four independently forwarded AF
classes. Within each AF class, an ÌP
packet can be assigned one of three
different levels of drop precedence:
low, medium and high.
ÌETF RFC
2597
AH authentication
header. Security
protocol providing
data authentication.
authentication header. A security
protocol that provides data
authentication and optional anti-replay
services. AH is embedded in the data
to be protected (a full ÌP datagram).
ÌTA/Jan
2001
ATM Asynchronous
Transfer Mode.
Ìnternational
standard for cell
relay.
Asynchronous Transfer Mode. The
international standard for cell relay in
which multiple service types (such as
voice, video, or data) are conveyed in
fixed-length (53-byte) cells. Fixed-
length cells allow cell processing to
occur in hardware, thereby reducing
transit delays. ATM is designed to
take advantage of high-speed
transmission media, such as E3,
SONET, and T3.
ÌTA/Jan
2001
Copyright © 2003, Cisco Systems, Ìnc. Course Glossary 3
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
BA behavior aggregate behavior aggregate. A collection of
packets with the same DiffServ code
point crossing a link in a particular
direction.
ÌETF RFC
2475
backbone Part of a network that acts as the
primary path for traffic that is most
often sourced from, and destined for,
other networks.
ÌTA/Jan
2001
bandwidth The rated
throughput capacity
of a given network
medium.
The difference between the highest
and lowest frequencies available for
network signals. The term also is
used to describe the rated throughput
capacity of a given network medium
or protocol. The frequency range
necessary to convey a signal
measured in units of hertz (Hz). For
example, voice signals typically
require approximately 7 kHz of
bandwidth and data traffic typically
requires approximately 50 kHz of
bandwidth.
ÌTA/Jan
2001
Bc committed burst committed burst. Negotiated tariff
metric in Frame Relay internetworks.
The maximum amount of data (in bits)
that a Frame Relay internetwork is
committed to accept and transmit at
the committed information rate (CÌR).
ÌTA/Jan
2001
Be excess burst excess burst. Negotiated tariff metric
in Frame Relay internetworks. The
number of bits that a Frame Relay
internetwork attempts to transmit after
Bc is accommodated. Be data, in
general, is delivered with a lower
probability than Bc data because Be
data can be marked as DE by the
network.
ÌTA/Jan
2001
BECN backward explicit
congestion
notification. Frame
Relay congestion
signaling
mechanism.
backward explicit congestion
notification. Bit set by a Frame Relay
network in frames traveling in the
opposite direction of frames
encountering a congested path. DTE
receiving frames with the BECN bit
set can request that higher-level
protocols take flow control action as
appropriate.
ÌTA/Jan
2001
best-effort
delivery
No guarantee made
on delivery of
packets.
Describes a network system that does
not use a sophisticated
acknowledgment system to guarantee
reliable delivery of information.
ÌTA/Jan
2001
BGP Border Gateway
Protocol.
Border Gateway Protocol.
Ìnterdomain routing protocol that
replaces EGP. BGP exchanges
reachability information with other
BGP systems. Ìt is defined by RFC
1163.
ÌTA/Jan
2001
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
buffer A storage area used
for handling data in
transit.
A storage area used for handling data
in transit. Buffers are used in
internetworking to compensate for
differences in processing speed
between network devices. Bursts of
data can be stored in buffers until they
can be handled by slower processing
devices. Sometimes referred to as a
packet buffer.
ÌTA/Jan
2001
burst A sequence of
signals counted as
one unit in
accordance with
some specific
criterion or
measure.
Ìn data communications, a sequence
of signals counted as one unit in
accordance with some specific
criterion or measure.
ÌTA/Jan
2001
bursty traffic An uneven pattern
of data
transmission.
A data communications term referring
to an uneven pattern of data
transmission.
ÌTA/Jan
2001
CAR committed access
rate. A traffic
policing and
marking
mechanism.
committed access rate. The CAR and
DCAR (distributed CAR) services limit
the input or output transmission rate
on an interface or subinterface based
on a flexible set of criteria.
ÌTA/Jan
2001
CBWFQ class-based
weighted fair
queueing
class-based weighted fair queueing.
CBWFQ extends the standard WFQ
functionality to provide support for
user-defined traffic classes. Allows
the user to define traffic classes
based on customer-defined match
criteria such as access control lists
(ACLs), input interfaces, protocol, and
quality-of-service (QoS) label. When
traffic classes have been defined,
they can be assigned a bandwidth,
queue limit, or drop policy such as
weighted random early detection
(WRED).
ÌTA/Jan
2001
The ABCs
of Cisco
ÌOS
Software
Acronyms
CDT Congestive Discard
Threshold
Congestive Discard Threshold. Ìn
WFQ, the CDT is defined as the
number of messages allowed in each
queue. When a conversation reaches
this threshold, new message packets
are discarded.
Cisco ÌOS
12.2
document
ation:
http://www
.cisco.com
/univercd/
cc/td/doc/
product/so
ftware/ios
122/122cg
cr/fqos_r/q
rfcmd1.ht
m#109824
9
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
CEF Cisco Express
Forwarding
Cisco Express Forwarding. Ìncreases
performance by adopting a new
caching mechanism that optimizes
Ìnternet traffic and enhances network
scalability.
The ABCs
of Cisco
ÌOS
Software
Acronyms
CE router customer edge
router
customer edge router. A router that is
part of a customer network and that
interfaces to a provider edge (PE)
router.
ÌTA/Jan
2001
CÌR committed
information rate
committed information rate. The rate
at which a Frame Relay network
agrees to transfer information under
normal conditions, averaged over a
minimum increment of time. CÌR,
measured in bits per second, is one of
the key negotiated tariff metrics.
ÌTA/Jan
2001
Cisco ÌOS
Software
Cisco operating
system software
that runs on routers
and switches
Cisco ÌOS Software, the leading and
most widely deployed network system
software, delivers intelligent network
services on a flexible networking
infrastructure that enables the rapid
deployment of Ìnternet applications.
The ABCs
of Cisco
ÌOS
Software
Acronyms
class map Ìn the Modular QoS
CLÌ, the class-map
command is used to
define a traffic class.
Ìn the Modular QoS CLÌ, the class-
map command is used to define a
traffic class. The purpose of a traffic
class is to classify traffic.
Cisco ÌOS
12.2
document
ation:
http://www
.cisco.com
/univercd/
cc/td/doc/
product/so
ftware/ios
122/122cg
cr/fqos_c/f
qcprt8/qcf
mdcli.htm
classification Ìdentifying traffic as
belonging to a
specific traffic class.
Classification entails using a traffic
descriptor to categorize a packet
within a specific group to define that
packet and make it accessible for
QoS handling on the network.
Cisco ÌOS
12.2
document
ation:
http://www
.cisco.com
/univercd/
cc/td/doc/
product/so
ftware/ios
122/122cg
cr/fqos_c/f
qcprt1/qcf
class.htm
CLÌ command-line
interface
command-line interface. An interface
that allows the user to interact with
the operating system by entering
commands and optional arguments.
The UNÌX operating system and DOS
provide CLÌs.
ÌTA/Jan
2001
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
CLP cell loss priority.
Field in the ATM cell
header that
determines the
probability of a cell
being dropped if the
network becomes
congested.
cell loss priority. Field in the ATM cell
header that determines the probability
of a cell being dropped if the network
becomes congested. Cells with CLP =
0 are insured traffic, which is unlikely
to be dropped. Cells with CLP = 1 are
best-effort traffic, which might be
dropped in congested conditions to
free up resources to handle insured
traffic.
ÌTA/Jan
2001
codec coder-decoder.
Used to compress /
decompress speech
or audio signals.
coder-decoder. Ìntegrated circuit
device that typically uses pulse code
modulation to transform analog
signals into a digital bit stream and
digital signals back into analog
signals. Ìn Voice over ÌP, Voice over
Frame Relay, and Voice over ATM, a
DSP software algorithm used to
compress/decompress speech or
audio signals.
ÌTA/Jan
2001
compression Technique used to
reduce the size of
transmitted data.
The running of a data set through an
algorithm that reduces the space
required to store or the bandwidth
required to transmit the data set.
ÌTA/Jan
2001
confluence The flowing together
of two or more
streams (of traffic)
The flowing together of two or more
streams (of traffic)
Merriam-
Webster
online
Dictionary
conforming
[traffic]
Traffic that is within
predefined
bandwidth limits.
[traffic] obedient or compliant (to
predefined bandwidth limits)
Merriam-
Webster
online
Dictionary
congestion Traffic in excess of
network capacity.
Traffic in excess of network capacity. ÌTA/Jan
2001
congestion
avoidance
Congestion
avoidance
techniques monitor
network traffic loads
in an effort to
anticipate and avoid
congestion at
common network
bottlenecks.
Mechanism by which an ATM network
controls the traffic entering the
network to minimize delays. To use
resources most efficiently, lower-
priority traffic is discarded at the edge
of the network if conditions indicate
that it cannot be delivered.
ÌTA/Jan
2001
and
http://www
.cisco.com
/univercd/
cc/td/doc/
product/so
ftware/ios
122/122cg
cr/fqos_c/f
qcprt3/qcf
conav.htm
converged
network
The integration of
the telephone
system with ÌP-
based data
networks.
The integration of the telephone
system with ÌP-based data networks.
Merriam-
Webster
online
Dictionary
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
CoS class of service class of service. An indication of how
an upper-layer protocol requires a
lower-layer protocol to treat its
messages.
ÌTA/Jan
2001
CQ custom queuing custom queuing. A Cisco ÌOS
congestion management feature
where bandwidth is allocated
proportionally for each different class
of traffic. CQ allows you to specify the
number of bytes or packets to be
drawn from the queue, which is
especially useful on slow interfaces.
http://www
.cisco.com
/univercd/
cc/td/doc/
product/so
ftware/ios
122/122cg
cr/fqos_c/f
qcprt2/qcf
conmg.ht
m#48685
CS class selector To preserve backward-compatibility
with any ÌP precedence scheme
currently in use on the network,
DiffServ has defined a DSCP value in
the form xxx000, where x is either 0 or
1. These DSCP values are called
Class-Selector Code Points.
Cisco ÌOS
12.2
document
ation:
http://www
.cisco.com
/en/US/pro
ducts/sw/i
osswrel/ps
1839/prod
ucts_featu
re_guide0
9186a008
0087afb.ht
ml#xtocid2
DE discard eligible.
Frame Relay
congestion control
mechanism.
discard eligible. Ìf the network is
congested, DE traffic can be dropped
to ensure the delivery of higher
priority traffic.
ÌTA/Jan
2001
delay The time required to
move a packet from
source to
destination over a
given path.
The time between the initiation of a
transaction by a sender and the first
response received by the sender.
Also, the time required to move a
packet from source to destination over
a given path.
ÌTA/Jan
2001
DiffServ differentiated
service
differentiated service. A paradigm for
providing QoS on the Ìnternet by
employing a small, well-defined set of
building blocks from which a variety of
services can be built.
ÌTA/Jan
2001
DLCÌ data-link connection
identifier. Value that
specifies a PVC or
an SVC in a Frame
Relay network.
data-link connection identifier. Value
that specifies a PVC or an SVC in a
Frame Relay network. Ìn the basic
Frame Relay specification, DLCÌs are
locally significant (connected devices
might use different values to specify
the same connection). Ìn the LMÌ
extended specification, DLCÌs are
globally significant (DLCÌs specify
individual end devices).
ÌTA/Jan
2001
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
DSCP DiffServ Code Point. Differentiated service code point. Six
bits in the type-of-service (ToS) field.
The ABCs
of Cisco
ÌOS
Software
Acronyms
ECN Explicit Congestion
Notification
A congestion indication for incipient
congestion where the notification can
sometimes be through marking
packets rather than dropping them
RFC 3168
http://www
.rfc-
editor.org/
rfc/rfc3168
.txt
EF Expedited
Forwarding
Expedited Forwarding. A DSCP PHB
intended to provide a building block
for low delay, low jitter and low loss
services by ensuring that the EF
aggregate is served at a certain
configured rate.
ÌETF RFC
3246
ESP Encapsulating
Security Payload.
Security protocol
providing data
encapsulation
protection.
Encapsulating Security Payload.
Security protocol that provides data
privacy services, optional data
authentication, and anti-replay
services. ESP encapsulates the data
to be protected.
ÌTA/Jan
2001
exceeding
traffic
Traffic which goes
beyond a limit
Traffic which goes beyond a limit set Merriam-
Webster
online
Dictionary
FECN forward explicit
congestion
notification. Frame
Relay congestion
signaling
mechanism.
forward explicit congestion
notification. Bit set by a Frame Relay
network to inform DTE receiving the
frame that congestion was
experienced in the path from source
to destination. DTE receiving frames
with the FECN bit set can request that
higher-level protocols take flow-
control action as appropriate.
ÌTA/Jan
2001
FÌFO first-in, first-out first-in, first-out. Refers to a buffering
scheme where the first byte of data
entering the buffer is the first byte
retrieved by the CPU. Ìn telephony,
FÌFO refers to a queueing scheme
where the first calls received are the
first calls processed.
ÌTA/Jan
2001
FÌFO
queueing
first-in, first-out
queueing
first-in, first-out queueing. Ìnvolves
buffering and forwarding of packets in
the order of arrival. FÌFO embodies no
concept of priority or classes of traffic.
There is only one queue, and all
packets are treated equally. Packets
are sent out an interface in the order
in which they arrive.
ÌTA/Jan
2001
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
flow Stream of data
traveling between
two endpoints
across a network.
Stream of data traveling between two
endpoints across a network (for
example, from one LAN station to
another). Multiple flows can be
transmitted on a single circuit.
ÌTA/Jan
2001
Frame Relay Ìndustry-standard,
switched data link
layer protocol.
Ìndustry-standard, switched data link
layer protocol that handles multiple
virtual circuits using HDLC
encapsulation between connected
devices. Frame Relay is more efficient
than X.25, the protocol for which it
generally is considered a
replacement.
ÌTA/Jan
2001
FRF.11 Frame Relay Forum
implementation
agreement for Voice
over Frame Relay.
Frame Relay Forum implementation
agreement for Voice over Frame
Relay (v1.0 May 1997). This
specification defines multiplexed data,
voice, fax, DTMF digit-relay, and
CAS/Robbed-bit signaling frame
formats but does not include call
setup, routing, or administration
facilities.  www.frforum.com.
ÌTA/Jan
2001
FRF.12 Frame Relay Forum
implementation
agreement for
Frame Relay
Fragmentation.
The FRF.12 Ìmplementation
Agreement (also known as FRF.11
Annex C) was developed to allow long
data frames to be fragmented into
smaller pieces and interleaved with
real-time frames. Ìn this way, real-time
voice and non real-time data frames
can be carried together on lower
speed links without causing excessive
delay to the real-time traffic.  
www.frforum.com.
ÌTA/Jan
2001
FRTS Frame Relay traffic
shaping
Frame Relay traffic shaping.
Queueing method that uses queues
on a Frame Relay network to limit
surges that can cause congestion.
Data is buffered and sent into the
network in regulated amounts to
ensure that the traffic can fit within the
promised traffic envelope for the
particular connection.
ÌTA/Jan
2001
GRE generic routing
encapsulation. A
tunneling protocol
developed by Cisco
for carrying traffic
inside ÌP tunnels.
generic routing encapsulation.
Tunneling protocol developed by
Cisco that can encapsulate a wide
variety of protocol packet types inside
ÌP tunnels, creating a virtual point-to-
point link to Cisco routers at remote
points over an ÌP internetwork. By
connecting multiprotocol subnetworks
in a single-protocol backbone
environment, ÌP tunneling using GRE
allows network expansion across a
single-protocol backbone
environment.
ÌTA/Jan
2001
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
GTS generic traffic
shaping
Generic traffic shaping. Provides a
mechanism to control the traffic flow
on a particular interface. Ìt reduces
outbound traffic flow to avoid
congestion by constraining specified
traffic to a particular bit rate (also
known as the token bucket approach),
while queuing bursts of the specified
traffic. Thus, traffic adhering to a
particular profile can be shaped to
meet downstream requirements,
eliminating bottlenecks in topologies
with data-rate mismatches.
The ABCs
of Cisco
ÌOS
Software
Acronyms
header Control information
placed before data
when encapsulating
that data for network
transmission.
Control information placed before
data when encapsulating that data for
network transmission.
ÌTA/Jan
2001
ÌEEE Ìnstitute of Electrical
and Electronics
Engineers
Ìnstitute of Electrical and Electronics
Engineers. Professional organization
whose activities include the
development of communications and
network standards. ÌEEE LAN
standards are the predominant LAN
standards today.
ÌTA/Jan
2001
ÌETF Ìnternet Engineering
Task Force
Ìnternet Engineering Task Force.
Task force consisting of over 80
working groups responsible for
developing Ìnternet standards. The
ÌETF operates under the auspices of
ÌSOC.
ÌTA/Jan
2001
ÌntServ integrated services The Ìnternet integrated services
framework provides the ability for
applications to choose among
multiple, controlled levels of delivery
service for their data packets.
RFC 2210
http://www
.ietf.org/rfc
/rfc2210.tx
t
ÌP Ìnternet Protocol.
Network layer
protocol in the
TCP/ÌP stack
offering a
connectionless
internetwork
service.
Ìnternet Protocol. Network layer
protocol in the TCP/ÌP stack offering a
connectionless internetwork service.
ÌP provides features for addressing,
type-of-service specification,
fragmentation and reassembly, and
security. Defined in RFC 791.
ÌTA/Jan
2001
ÌP
precedence
A 3-bit value in the
type of service
(TOS) byte used for
assigning
precedence to ÌP
packets.
A 3-bit value in the type of service
(TOS) byte used for assigning
precedence to ÌP packets.
ÌTA/Jan
2001
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
ÌPSec ÌP Security. A
framework of open
standards that
provides data
confidentiality, data
integrity, and data
authentication
between
participating peers.
ÌP Security. A framework of open
standards that provides data
confidentiality, data integrity, and data
authentication between participating
peers. ÌPSec provides these security
services at the ÌP layer. ÌPSec uses
ÌKE to handle the negotiation of
protocols and algorithms based on
local policy and to generate the
encryption and authentication keys to
be used by ÌPSec. ÌPSec can protect
one or more data flows between a
pair of hosts, between a pair of
security gateways, or between a
security gateway and a host.
ÌTA/Jan
2001
ÌSL Ìnter-Switch Link Ìnter-Switch Link. Cisco-proprietary
protocol that maintains VLAN
information as traffic flows between
switches and routers.
Cisco.com
jitter The interpacket
delay variance; that
is, the difference
between interpacket
arrival and
departure.
The interpacket delay variance; that
is, the difference between interpacket
arrival and departure. Jitter is an
important QoS metric for voice and
video applications.
ÌTA/Jan
2001
LAN local-area network local-area network. High-speed, low-
error data network covering a
relatively small geographic area (up to
a few thousand meters). LANs
connect workstations, peripherals,
terminals, and other devices in a
single building or other geographically
limited area. LAN standards specify
cabling and signaling at the physical
and data link layers of the OSÌ model.
Ethernet, FDDÌ, and Token Ring are
widely used LAN technologies.
ÌTA/Jan
2001
latency Delay used to
measure packet
transmission time.
1. Delay between the time a device
requests access to a network and the
time it is granted permission to
transmit. 2. Delay between the time a
device receives a frame and the time
that frame is forwarded out the
destination port.
ÌTA/Jan
2001
LFÌ link fragmentation
and interleaving
Link fragmentation and interleaving
reduces delay on slower-speed links
by breaking up large datagrams and
interleaving low-delay traffic packets
with the smaller packets resulting
from the fragmented datagram.
Cisco.com
http://www
.cisco.com
/en/US/pro
ducts/sw/i
osswrel/ps
1831/prod
ucts_confi
guration_g
uide_chap
ter09186a
00800ca6
d4.html
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
LLQ low-latency queuing low-latency queuing. Brings strict
priority queuing to class-based
weighted fair queuing (CBWFQ).
Strict priority queuing allows delay-
sensitive data such as voice to be de-
queued and sent first (before packets
in other queues are de-queued),
giving delay-sensitive data
preferential treatment over other
traffic.
The ABCs
of Cisco
ÌOS
Software
Acronyms
marking To label so as to
indicate
membership in a
specific traffic class.
To designate as if by a mark; to make
or leave a mark on; or to label so as
to indicate quality (in this case, the
quality of service level associated with
a packet).
Merriam-
Webster
online
Dictionary
MDRR Modified Deficit
Round Robin
Modified Deficit Round Robin
(MDRR). A variant of Deficit Round
Robin (DRR). Regular DRR selects
packets from each virtual output
queue in a regular round-robin
mechanism, thus providing every
class-of-service (CoS) queue equal
scheduling into the fabric. Ìn MDRR,
all queues are also serviced in a
round-robin fashion, with the
exception of one of the queues.
The ABCs
of Cisco
ÌOS
Software
Acronyms
metering To measure by
means of a meter.
To measure by means of a meter. Merriam-
Webster
online
Dictionary
MÌB Management
Ìnformation Base.
Database of
network
management
information that is
used and
maintained by a
network
management
protocol.
Management Ìnformation Base.
Database of network management
information that is used and
maintained by a network management
protocol, such as SNMP or CMÌP. The
value of a MÌB object can be changed
or retrieved using SNMP or CMÌP
commands, usually through a GUÌ
network management system. MÌB
objects are organized in a tree
structure that includes public
(standard) and private (proprietary)
branches.
ÌTA/Jan
2001
MPLS Multiprotocol Label
Switching
Multiprotocol Label Switching.
Switching method that forwards ÌP
traffic using a label. This label
instructs the routers and the switches
in the network where to forward the
packets based on preestablished ÌP
routing information.
ÌTA/Jan
2001
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
MQC Modular QoS CLÌ Modular QoS CLÌ (MQC), the simple,
scalable, and powerful QoS
framework in ÌOS. The MQC allows
for the clear separation of
classification, from the policy applied
on the classes, to the application of a
QoS policy on an interface or sub-
interface.
http://www
in.cisco.co
m/cmc/cc/
pd/iosw/pr
odlit/iosq_
ds.htm#xt
ocid4
NBAR network-based
application
recognition
network-based application recognition
(NBAR). A new classification engine
that can recognize a wide variety of
application-level protocols, including
HTTP via Universal Resource
Locator/Multipurpose Ìnternet Mail
Extensions (URL/MÌME) type and
protocols that utilize dynamic port
assignments. When the traffic is
classified by NBAR, appropriate
quality-of-service (QoS) policies can
be applied to the traffic classes using
existing Cisco ÌOS QoS features.
The ABCs
of Cisco
ÌOS
Software
Acronyms
P provider router provider router. A router in the core of
a service provider network that
interfaces to other P routers or to a
PE router. P routers only do MPLS
switching across the Ìnternet service
provider (ÌSP) backbone based on
label swapping of the first-level label
to the BGP next-hop address.
packet Logical grouping of
information that
includes a header
containing control
information and
(usually) user data.
Logical grouping of information that
includes a header containing control
information and (usually) user data.
Packets most often are used to refer
to network layer units of data. The
terms datagram, frame, message, and
segment also are used to describe
logical information groupings at
various layers of the OSÌ reference
model and in various technology
circles.
ÌTA/Jan
2001
payload Portion of a cell,
frame, or packet
that contains upper-
layer information
(data).
Portion of a cell, frame, or packet that
contains upper-layer information
(data).
ÌTA/Jan
2001
PBR Policy Based
Routing
Policy-based routing. Routing scheme
that forwards packets to specific
interfaces based on user-configured
policies. Such policies might specify
that traffic sent from a particular
network should be forwarded out one
interface, while all other traffic should
be forwarded out another interface.
The ABCs
of Cisco
ÌOS
Software
Acronyms
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
PDLM Packet Description
Language Module
An external Packet Description
Language Module (PDLM) can be
loaded at run time to extend the
NBAR list of recognized protocols.
PDLMs can also be used to enhance
an existing protocol recognition
capability. PDLMs allow NBAR to
recognize new protocols without
requiring a new Cisco ÌOS image or a
router reload.
Cisco.com
http://www
.cisco.com
/en/US/pro
ducts/sw/i
osswrel/ps
1835/prod
ucts_confi
guration_g
uide_chap
ter09186a
00800c75
d1.html
PE router provider edge router Provider edge router. A router that is
part of a service provider's network
and that is connected to a customer
edge (CE) router. The PE router
function is a combination of an MLS
edge label switch router (LSR)
function with some additional
functions to support VPNs.
http://www
.cisco.com
/univercd/
cc/td/doc/
product/rtr
mgmt/vpn
sc/mpls/2_
1/prov_gd/
mplsgl.pdf
PHB per-hop behavior per-hop behavior. A description of the
externally observable forwarding
treatment applied at a differentiated
services-compliant node to a behavior
aggregate.
ÌETF
RFC2475
ping packet internet
groper. ÌCMP echo
message and its
reply.
packet internet groper. ÌCMP echo
message and its reply. Often used in
ÌP networks to test the reachability of
a network device.
ÌTA/Jan
2001
PÌR peak information
rate. Maximum rate,
in kilobits per
second, at which a
virtual circuit can
transmit.
peak information rate. Maximum rate,
in kilobits per second, at which a
virtual circuit can transmit.
ÌTA/Jan
2001
policing Traffic policing
allows control over
the maximum rate of
traffic sent or
received on an
interface.
To supervise the operation, execution,
or administration of to prevent or
detect and prosecute violations of
rules and regulations (in this case,
regarding pre-defined traffic
bandwidth). Traffic policing allows you
to control the maximum rate of traffic
sent or received on an interface, and
to partition a network into multiple
priority levels or class of service
(CoS).
Merriam-
Webster
online
Dictionary
and
http://www
.cisco.com
/univercd/
cc/td/doc/
product/so
ftware/ios
122/122cg
cr/fqos_c/f
qcprt4/qcf
polsh.htm
#22120
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
policy Any defined rule
that determines the
use of resources
within the network.
Any defined rule that determines the
use of resources within the network. A
policy can be based on a user, a
device, a subnetwork, a network, or
an application.
ÌTA/Jan
2001
policy map A policy map is a
traffic policy.
A policy map is a traffic policy. The
purpose of a traffic policy is to
configure the QoS features that
should be associated with the traffic
that has been classified in a user-
specified traffic class or classes. A
traffic policy contains three elements:
a name, a traffic class (specified with
the class command), and the QoS
policies.
Cisco.com
http://www
.cisco.com
/en/US/pro
ducts/sw/i
osswrel/ps
1835/prod
ucts_confi
guration_g
uide_chap
ter09186a
00800bd9
08.html
PPP Point-to-Point
Protocol
Point-to-Point Protocol. Successor to
SLÌP that provides router-to-router
and host-to-network connections over
synchronous and asynchronous
circuits. Whereas SLÌP was designed
to work with ÌP, PPP was designed to
work with several network layer
protocols, such as ÌP, ÌPX, and ARA.
PPP also has built-in security
mechanisms, such as CHAP and
PAP. PPP relies on two protocols:
LCP and NCP.
ÌTA/Jan
2001
PQ priority queuing priority queuing. Routing feature in
which frames in an output queue are
prioritized based on various
characteristics, such as packet size
and interface type.
ÌTA/Jan
2001
PQ/CBWFQ priority
queueing/class-
based weighted fair
queueing
priority queueing/class-based
weighted fair queueing (PQ/CBWFQ).
Feature that brings strict priority
queueing to CBWFQ. Strict priority
queueing allows delay-sensitive data,
such as voice, to be dequeued and
sent first (before packets in other
queues are dequeued), giving delay-
sensitive data preferential treatment
over other traffic.
ÌTA/Jan
2001
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
predictor One of the two most
commonly used
compression
algorithms on
internetworking
devices.
The two most commonly used
compression algorithms on
internetworking devices are the
Stacker compression and the
predictor data compression
algorithms. The predictor
compression algorithm tries to predict
the next sequence of characters in a
data stream by using an index to look
up a sequence in the compression
dictionary.
Cisco.com
http://www
.cisco.com
/en/US/pro
ducts/hw/
modules/p
s2957/pro
ducts_mo
dule_instal
lation_gui
de_chapte
r09186a00
8007e5da.
html#xtoci
d2
processing
delay
The time it takes to
manipulate data in
the computer
The time it takes to manipulate data in
the computer. The computer is said to
be processing no matter what action it
is taking upon the data; whether the
data is actually being updated in a
database or just being displayed on
screen.
TechEncy
clopedia
http://www
.techweb.c
om/encycl
opedia/def
ineterm?te
rm=propa
gation&x=
12&y=9
propagation
delay
The time it takes to
transmit a signal
from one place to
another.
The time it takes to transmit a signal
from one place to another.
Propagation delay is dependent solely
on distance and two thirds the speed
of light. Signals going through a wire
or fiber generally travel at two thirds
the speed of light.
TechEncy
clopedia
http://www
.techweb.c
om/encycl
opedia/def
ineterm?te
rm=propa
gation&x=
12&y=9
provisioning Creation of an
active subscriber
account, or
modification of
parameters for an
existing subscriber
account.
Creation of an active subscriber
account, or modification of
parameters for an existing subscriber
account. Provisioning of a subscriber
account includes subscriber account
registration and device activation.
ÌTA/Jan
2001
QoS quality of service Quality of service (QoS). The goal of
QoS is to provide better and more
predictable network service by
providing dedicated bandwidth,
controlled jitter and latency, and
improved loss characteristics. QoS
achieves these goals by providing
tools for managing network
congestion, shaping network traffic,
using expensive wide-area links more
efficiently, and setting traffic policies
across the network.
The ABCs
of Cisco
ÌOS
Software
Glossary
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
QPPB QoS Policy
Propagation on
BGP
The quality of service (QoS) policy
propagation via Border Gateway
Protocol (BGP) feature allows you to
classify packets based on access
lists, BGP community lists, and BGP
autonomous system (AS) paths.
Cisco.com
http://www
.cisco.com
/en/US/pro
ducts/sw/i
osswrel/ps
1820/prod
ucts_featu
re_guide0
9186a008
00f4898.ht
ml
queue A sequence of
messages or jobs
held in auxiliary
storage awaiting
transmission.
A sequence of messages or jobs held
in auxiliary storage awaiting
transmission or processing or a data
structure that consists of a list of
records such that records are added
at one end and removed from the
other.
Merriam-
Webster
online
Dictionary
queuing delay Queuing delay is
time spent being
held in a queue.
Queuing is the process of lining up
events in the order you want them
processed. Whether it refers to
packets in an ÌP network that search
for the most optimal path to their
destination, or telephone callers
sitting in a "hold queue" waiting to be
answered, queuing means the same
thing: deciding on priorities through
bottle-necked passageways. Queuing
delay is time spent being held in a
queue.
TechEncy
clopedia
http://www
.techweb.c
om/encycl
opedia/def
ineterm?te
rm=propa
gation&x=
12&y=9
and
http://www
.cisco.com
/en/US/tec
h/tk652/tk
698/techn
ologies_w
hite_paper
09186a00
800a8993.
shtml#cod
eprocessd
elay
RED random early
detection
Random early detection. This class of
algorithms is designed to avoid
congestion in internetworks before it
becomes a problem. RED works by
monitoring traffic load at points in the
network and stochastically discarding
packets if the congestion begins to
increase. The result of the drop is that
the source detects the dropped traffic
and slows its transmission. RED is
designed to work primarily with TCP
in ÌP internetwork environments.
The ABCs
of Cisco
ÌOS
Software
Glossary
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
RSVP Resource
Reservation
Protocol. Protocol
that supports the
reservation of
resources across an
ÌP network.
Resource Reservation Protocol.
Protocol that supports the reservation
of resources across an ÌP network.
Applications running on ÌP end
systems can use RSVP to indicate to
other nodes the nature (bandwidth,
jitter, maximum burst, and so on) of
the packet streams they want to
receive. RSVP depends on ÌPv6. Also
known as Resource Reservation
Setup Protocol.
ÌTA/Jan
2001
RTP Real-Time
Transport Protocol.
RTP is designed to
provide end-to-end
network transport
functions for
applications
transmitting real-
time data.
Real-Time Transport Protocol.
Commonly used with ÌP networks.
RTP is designed to provide end-to-
end network transport functions for
applications transmitting real-time
data, such as audio, video, or
simulation data, over multicast or
unicast network services. RTP
provides such services as payload
type identification, sequence
numbering, timestamping, and
delivery monitoring to real-time
applications.
ÌTA/Jan
2001
scheduling Method used to
schedule data for
transmission.
A (scheduling algorithm is a) method
used to schedule jobs for execution
(or, in this case, data for
transmission). Priority, length of time
in the job queue and available
resources are examples of criteria
used.
TechEncy
clopedia
http://www
.techweb.c
om/encycl
opedia/def
ineterm?te
rm=sched
uling
serialization
delay
The time it takes in a
computer system to
transmit the bits of a
byte sequentially
over a single wire.
The time it takes in a computer system
to transmit the bits of a byte
sequentially over a single wire.
Merriam-
Webster
online
Dictionary
service class Collection of service
types required for a
specific service
offered.
Collection of service types required
for a specific service offered. Each
service class includes the attributes
and values that define the type or
quality of service associated with a
given class. For example, data
connectivity is a service class you
might define that includes the service
type data-bandwidth.
ÌTA/Jan
2001
shaping Adapt the traffic so
that it fits a
previously defined
bandwidth.
To adapt in shape so as to fit neatly
and closely (in this case to adapt the
traffic so that it fits a previously
defined bandwidth)
Merriam-
Webster
online
Dictionary
SLA service-level
agreement
service-level agreement. A service
contract between a customer and a
service provider that specifies the
forwarding service a customer should
receive.
ÌETF RFC
2475
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
stacker One of the two most
commonly used
compression
algorithms on
internetworking
devices.
The two most commonly used
compression algorithms on
internetworking devices are the
stacker compression and the
Predictor data compression
algorithms. The stacker algorithm
uses an encoded dictionary that
replaces a continuous stream of
characters with codes. The symbols
represented by the codes are stored
in memory in a dictionary-style list.
http://www
.cisco.com
/en/US/pro
ducts/hw/
modules/p
s2957/pro
ducts_mo
dule_instal
lation_gui
de_chapte
r09186a00
8007e5da.
html#xtoci
d2
starvation To suffer from a lack
of service.
To perish from lack of food or to suffer
extreme hunger (in this case from a
lack of service)
Merriam-
Webster
online
Dictionary
http://www
.m-
w.com/cgi-
bin/diction
ary
tail-drop Method for avoiding
congestion in which
packets are dropped
until the congestion
is eliminated and
the queue is no
longer full.
Method for avoiding congestion. Tail
drop treats all traffic equally and does
not differentiate between classes of
service. Queues fill during periods of
congestion. When the output queue is
full and tail drop is in effect, packets
are dropped until the congestion is
eliminated and the queue is no longer
full.
Cisco.com
http://www
.cisco.com
/en/US/pro
ducts/sw/i
osswrel/ps
1828/prod
ucts_confi
guration_g
uide_chap
ter09186a
00800ca5
9c.html
Tc Time interval Time interval. Also called the
measurement interval, it specifies the
time quantum in seconds per burst.
http://www
.cisco.com
/univercd/
cc/td/doc/
product/so
ftware/ios
122/122cg
cr/fqos_c/f
qcprt4/qcf
polsh.htm
TCP Transmission
Control Protocol.
Transport layer
protocol that
provides reliable
full-duplex data
transmission.
Transmission Control Protocol.
Connection-oriented transport layer
protocol that provides reliable full-
duplex data transmission. TCP is part
of the TCP/ÌP protocol stack.
ÌTA/Jan
2001
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
token bucket A token bucket is
used to manage a
device that
regulates the rate of
a flow.
A formal definition of a rate of
transfer. A token bucket has three
components: a burst size, a mean
rate, and a time interval (Tc). A token
bucket is used to manage a device
that regulates the rate of a flow.
ÌTA/Jan
2001
ToS type of service A field in an ÌP packet (ÌP datagram)
that is used for quality of service
(QoS).
TechEncy
clopedia
http://www
.techweb.c
om/encycl
opedia/def
ineterm?te
rm=tos&x
=30&y=12
trust
boundary
The trust boundary
is established by the
access device that
either discards or
trusts a marker in a
frame or packet.
When classifying traffic types in an
enterprise network, a trust boundary
must be established. The boundary is
established by the access device,
which either classifies traffic that it
allows into the network itself or trusts
classification that has already been
applied by an end station, such as an
ÌP phone.
Cisco.com
http://www
.cisco.com
/en/US/ab
out/ac123/
ac114/ac1
73/ac205/
about_cisc
o_packet_
feature091
86a00801
01513.htm
l
tunnel Secure
communication path
between two peers,
such as two routers.
Secure communication path between
two peers, such as two routers.
ÌTA/Jan
2001
UDP User Datagram
Protocol.
Connectionless
transport layer
protocol in the
TCP/ÌP protocol
stack.
User Datagram Protocol.
Connectionless transport layer
protocol in the TCP/ÌP protocol stack.
UDP is a simple protocol that
exchanges datagrams without
acknowledgments or guaranteed
delivery, requiring that error
processing and retransmission be
handled by other protocols. UDP is
defined in RFC 768.
ÌTA/Jan
2001
VC virtual circuit.
Logical circuit
created to ensure
reliable
communication
between two
network devices.
virtual circuit. Logical circuit created to
ensure reliable communication
between two network devices. A
virtual circuit is defined by a VPÌ/VCÌ
pair, and can be either permanent
(PVC) or switched (SVC). Virtual
circuits are used in Frame Relay and
X.25. Ìn ATM, a virtual circuit is called
a virtual channel. Sometimes
abbreviated VC.
ÌTA/Jan
2001
violating
traffic
Traffic not following
limits set for traffic
bandwidth.
To fail to show proper respect for (in
this case, not following limits set for
traffic bandwidth)
Merriam-
Webster
online
Dictionary
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
VÌP Versatile Ìnterface
Processor. Ìnterface
card used in Cisco
7000 and Cisco
7500 series routers.
Versatile Ìnterface Processor.
Ìnterface card used in Cisco 7000 and
Cisco 7500 series routers. The VÌP
provides multilayer switching and runs
Cisco ÌOS. The most recent version of
the VÌP is VÌP2.
ÌTA/Jan
2001
VLAN virtual LAN. Group
of devices on one or
more LANs that are
configured so that
they can
communicate as if
they were attached
to the same wire.
virtual LAN. Group of devices on one
or more LANs that are configured
(using management software) so that
they can communicate as if they were
attached to the same wire, when in
fact they are located on a number of
different LAN segments. Because
VLANs are based on logical instead of
physical connections, they are
extremely flexible.
ÌTA/Jan
2001
VoÌP Voice over ÌP. The
capability to carry
normal telephony-
style voice over an
ÌP-based internet
with POTS-like
functionality,
reliability, and voice
quality.
Voice over ÌP. The capability to carry
normal telephony-style voice over an
ÌP-based internet with POTS-like
functionality, reliability, and voice
quality. VoÌP enables a router to carry
voice traffic (for example, telephone
calls and faxes) over an ÌP network. Ìn
VoÌP, the DSP segments the voice
signal into frames, which then are
coupled in groups of two and stored in
voice packets. These voice packets
are transported using ÌP in
compliance with ÌTU-T specification
H.323.
ÌTA/Jan
2001
VPN Virtual Private
Network
Virtual Private Network. Enables ÌP
traffic to travel securely over a public
TCP/ÌP network by encrypting all
traffic from one network to another. A
VPN uses "tunneling" to encrypt all
information at the ÌP level.
ÌTA/Jan
2001
WAN wide-area network wide-area network. Data
communications network that serves
users across a broad geographic area
and often uses transmission devices
provided by common carriers. Frame
Relay, SMDS, and X.25 are examples
of WANs.
ÌTA/Jan
2001
WFQ weighted fair
queuing
weighted fair queuing. Congestion
management algorithm that identifies
conversations (in the form of traffic
streams), separates packets that
belong to each conversation, and
ensures that capacity is shared fairly
between these individual
conversations. WFQ is an automatic
way of stabilizing network behavior
during congestion and results in
increased performance and reduced
retransmission.
ÌTA/Jan
2001
Acronym or
Term
Mouseover
Acronym or Term
Source
for
Definition
AdditionaI
ExpIanation/
Course Context
WRED weighted random
early detection
weighted random early detection.
Queueing method that ensures that
high-precedence traffic has lower loss
rates than other traffic during times of
congestion.
ÌTA/Jan
2001
WRR weighted round
robin
weighted round robin. Packets are
assigned a class (real-time, file
transfer, etc.) and placed into the
queue for that class of service.
Packets are accessed round-robin
style, but classes can be given
priorities based on ¨weights¨ assigned
to the queues. For example, four
packets from a high-priority class
might be serviced, followed by two
from a middle-priority class and then
one from a low-priority class.
TechEncy
clopedia
http://www
.techweb.c
om/encycl
opedia/def
ineterm?te
rm=traffice
ngineering
methods
QOS
Lab Guide
Overview
Use the exercises here to complete the lab exercises Ior this course. The solutions inIormation
is Iound in the Lab Exercise Answer Key.
OutIine
This Lab Guide includes these exercises:
Lab Exercise 2-1: QoS Lab Setup and Initialization
Lab Exercise 2-2: Baseline QoS Measurement
Lab Exercise 3-1: ConIiguring QoS with AutoQoS
Lab Exercise 4-1: ClassiIication and Marking Using MQC
Lab Exercise 4-2: ClassiIication Using NBAR
Lab Exercise 4-3: ConIiguring QoS Pre-ClassiIy
Lab Exercise 4-4: LAN-Based Packet ClassiIication and Marking
Lab Exercise 5-1: ConIiguring Basic Queuing
Lab Exercise 5-2: ConIiguring LLQ
Lab Exercise 5-3: Queuing on Catalyst Switches
Lab Exercise 6-1: ConIiguring DSCP-Based WRED
Lab Exercise 7-1: ConIiguring Class-Based Policing
Lab Exercise 7-2: ConIiguring Class-Based Shaping
Lab Exercise 8-1: ConIiguring Class-Based Header Compression
Lab Exercise 8-2: ConIiguring LFI
Lab Exercise 2-1: QoS Lab Setup and
InitiaIization
Complete this lab initialization procedure to prepare your student workgroup pod prior to
completing any laboratory practice exercises.
Exercise Objective
In this exercise, you will prepare your student workgroup Ior use with the laboratory practice
exercises that accompany the Implementing Cisco Quality of Service (QOS) v2.0 course. AIter
completing this exercise, you will be able to meet these objectives:
ConIigure your workgroup routers Ior basic network connectivity
ConIigure your workgroup switch Ior basic network connectivity
VeriIy network connectivity using the Cisco IOS tools: ping and trace
VisuaI Objective
The Iollowing Iigures illustrate what you will accomplish in this exercise.
Figure 1: LogicaI Lab Backbone TopoIogy
As shown in Figure 1, the lab topology Ior the course is split into a number oI workgroups and
three separate backbones.
Each workgroup is designated to service two students and has been designed to interIace with
two traIIic generation backbones named, 'TraIIic Gen 1¨ and 'TraIIic Gen 2¨ and a shared
provider backbone named 'Provider.¨
Copyright © 2003, Cisco Systems, Ìnc. Lab Guide 3
Figure 2: PhysicaI Lab Workgroup TopoIogy
Figure 2 shows the physical topology oI a single workgroup and its connectivity into the three
lab backbones. Each workgroup consists oI two user-controlled Cisco 2610XM routers and one
user-controlled Cisco 2950T-24 workgroup switch. Each student workgroup connects to each
backbone as shown in Figure 2.
Although depicted as two diIIerent workgroup switches in Figure 2, each student workgroup
consists oI a single workgroup switch conIigured to support two diIIerent virtual LANs. In
Iigure two, the single workgroup switch has been depicted as two diIIerent switches to simpliIy
the diagram only. Notice that the same name has been used to identiIy the Cisco 2950T
indicating it is in Iact the same device.
TraIIic Ior each pod can bypass the high-speed service provider backbone (using the slow 384-
kbps link) or travel via the high-speed provider backbone itselI (using the Iast 768-kbps serial
link). TraIIic Ilow through both the slow and Iast serial links will be tested in the QOS v2.0
labs.
In Figure 3, the logical topology conIiguration oI each workgroup and the devices contained
within each oI the three laboratory backbones is shown. In the Provider Backbone in Figure 3,
each oI the backbone routers (SPNorth and SPSouth) contains a serial connection to each
workgroup.
The QoS lab uses the two routers called Pagent-1 and Pagent-2 to generate traIIic Irom
diIIerent applications including SQL, Napster, FTP, Citrix, HTTP, Outlook, and Kazaa. The
two routers called Callgen-1 and Callgen-2 are used in the lab to generate (G.711) VoIP traIIic.
Note: The SPNorth router, the SPSouth router, the core switch, and the traffic generation routers
(Pagent-1, Pagent-2, Callgen-1, and Callgen-2) are preconfigured and managed by the
instructor.
Figure 3: LogicaI Lab TopoIogy
Each Pagent and Callgen router is set up with connections to 8 VLANs (one Ior each lab
workgroup) as Iollows:
Pagent-1 and Callgen-1 are conIigured with VLANs 11 to 18.
Pagent-2 and Callgen-2 are conIigured with VLANs 21 to 28.
TraIIic Ilow to and Irom the Pagent and Callgen lab routers is designed to traverse the network
through each workgroup as Iollows:
Pagent-1/Callgen-1 (VLAN 11) sends traIIic to Pagent-2/Callgen-2 (VLAN 21) via pod 1.
The logical conIiguration oI each oI these VLANs is as Iollows:
Lab VLAN LogicaI Address Assignments
Workgroup Pod VLANs Assigned IP Subnets
1 11 and 21 10.1.1.0/24 (VLAN 11) and 10.3.1.0/24 (VLAN 21)
2 12 and 22 10.1.2.0/24 (VLAN 12) and 10.3.2.0/24 (VLAN 22)
3 13 and 23 10.1.3.0/24 (VLAN 13) and 10.3.3.0/24 (VLAN 23)
4 14 and 24 10.1.4.0/24 (VLAN 14) and 10.3.4.0/24 (VLAN 24)
5 15 and 25 10.1.5.0/24 (VLAN 15) and 10.3.5.0/24 (VLAN 25)
6 16 and 26 10.1.6.0/24 (VLAN 16) and 10.3.6.0/24 (VLAN 26)
7 17 and 27 10.1.7.0/24 (VLAN 17) and 10.3.7.0/24 (VLAN 27)
8 18 and 28 10.1.8.0/24 (VLAN 18) and 10.3.8.0/24 (VLAN 28)
Required Resources
These are the resources and equipment required to complete this exercise:
Lab topology conIigured Ior QOS
Student workgroup consisting oI two user-controlled Cisco 2610XM routers and one user-
controlled Cisco 2950T-24 workgroup switch
Classroom reIerence materials as Iollows:
QOS Student Guide
QOS Lab Guide
Student pod workstation with Telnet or console access to workstation pod devices
Command List
The commands used in this exercise are described in the table here.
QoS Lab Setup and InitiaIization Lab Router Commands
Command Description
hostname name To specify or modify the host name
enable secret password Password for users to enter enable mode
interface interfaceid Enter interface configuration mode and the physical interface
identification
(no) ip address ip~
address mask
To set a primary or secondary ÌP address for an interface
clock rate bps To configure the clock rate for the hardware connections on serial
interfaces
bandwidth kbps To set and communicate to higher-level protocols the current
bandwidth value for an interface
encapsulation
encapsulationtype
To set the encapsulation method used by the interface
show ip interface
(brief) (type)
(number)
To list a summary of an interface ÌP information and status
router ospf processid To configure an OSPF routing process
network ipaddress
wildcardmask area
areaid
To define the interfaces on which OSPF runs and to define the
area ÌD for those interfaces
show ip ospf neighbor To display OSPF-neighbor information on a per-interface basis
shutdown To disable an interface
copy running~config
startup~config
Save your entries in the configuration file
QoS Lab Setup and InitiaIization Lab Switch Commands
Command Description
hostname name To specify or modify the host name
enable secret password Password for users to enter enable mode
interface interface~id Enter interface configuration mode and the physical interface
identification
show ip interface
(brief) (type)
(number)
show interfaces
(interfaceid)
Displays the administrative and operational status of all interfaces
or a specified interface
copy running~config
startup~config
Job Aids
These job aids are available to help you complete the laboratory exercise:
Your assigned workgroup pod number provided by the instructor
Exercise Procedure
Step 1 ConIigure the hostname and passwords on both oI the workgroup routers in your
assigned workgroup pod as shown in the Iollowing table (where x is your assigned
workgroup pod number):
Hostname EnabIe Secret Password VTY Login Password
WGxR1 cisco cisco
WGxR2 cisco cisco
Step 2 ConIigure the IP address on the S0/0 and S0/1 and Fa0/0 interIaces oI the
workgroup routers in your assigned workgroup pod as shown in the Iollowing table:
Interface WGxR1 WGxR2
Fa0/0 10.1.x.1/24 10.3.x.2/24
S0/0 10.2.x.1/24 10.2.x.2/24
S0/1 10.4.x.1/24 10.5.x.2/24
Step 3 ConIigure the clock rate on the S0/0 serial interIace oI your WGxR1 router to 384
kbps.
Interface WGxR1 S0/0 cIock rate
S0/0 384000 bps
Note: Ìn the service provider backbone, each of the backbone routers (SPNorth, SPSouth)
contains a serial connection to each workgroup router. The following table lists the ÌP
addressing requirements of these connections. Both service provider routers are the DCE
with the clock rate configured by the instructor as 768 kbps.
Sy/x SPNorth IP Address SPSouth IP Address
S0/0 ÷ to pod 1 10.4.1.100 10.5.1.100
S0/1 ÷ to pod 2 10.4.2.100 10.5.2.100
S0/2 ÷ to pod 3 10.4.3.100 10.5.3.100
S0/3 ÷ to pod 4 10.4.4.100 10.5.4.100
S1/0 ÷ to pod 5 10.4.5.100 10.5.5.100
S1/1 ÷ to pod 6 10.4.6.100 10.5.6.100
S1/2 ÷ to pod 7 10.4.7.100 10.5.7.100
S1/3 ÷ to pod 8 10.4.8.100 10.5.8.100
Step 4 ConIigure the S0/0 and S0/1 serial interIaces oI your workgroup routers Ior PPP
encapsulation and set the bandwidth to match the clock rate conIigured in Step 3 oI
this lab exercise.
Step 5 Administratively enable the S0/0, S0/1, and Fa0/0 interIaces on both oI your
workgroup routers and veriIy that they are all in the up state (administratively up,
line protocol up).
II the Fa0/0 interIace is down, login to your workgroup switch to ensure the switch
port is also administratively enabled.
WGxRI=show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 I0.I.x.I YES NVRAM up up
Serial0/0 I0.?.x.I YES NVRAM up up
Serial0/I I0.4.x.I YES NVRAM up up
Virtual-AccessI unassigned YES unset up up
WGxR?=show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 I0.·.x.? YES NVRAM up up
Serial0/0 I0.?.x.? YES NVRAM up up
Serial0/I I0.S.x.? YES NVRAM up up
Step 6 ConIigure an OSPF routing process on your workgroup routers and place the S0/0,
S0/1, and Fa0/0 interIaces into OSPF area 0.
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
Step 7 VeriIy that both OSPF neighbors oI your workgroup routers are in the FULL state.
Each oI your workgroup routers should have a FULL neighbor relationship to the
service provider router and to the other workgroup router in your pod.
WGxRI=show ip ospf neighbor
Neighbor ID Pri State Dead Time Address
Interface
I0.I0.I0.I00 0 FULL/- 00.00.·I I0.4.x.I00
Serialy/z
I0.S.x.? 0 FULL/- 00.00.·8 I0.?.x.?
Serial0/0
WGxR?=show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
I0.I0.I0.?00 0 FULL/- 00.00.·I I0.S.x.I00
Serialy/z
I0.4.x.I 0 FULL/- 00.00.·· I0.?.x.I
Serial0/0
Step 8 VeriIy that the serial ports on both oI your workgroup routers (WGxR1 and
WGxR2) have their queuing strategy set to weighted Iair queuing (WFQ).
Step 9 ConIigure the hostname and password on the workgroup switch in your assigned
workgroup pod as shown in the Iollowing table:
Hostname EnabIe Secret Password
WGxS1 cisco
Step 10 ConIigure the VLANs (1 x and 2 x) on your workgroup switch by adding VLANs 1x
and 2x Irom within vlan database mode.
vlan database
vtp domain qos
vtp transparent
!
vlan 1x name vlan1x
vlan 2x name vlan2x
!
exit
Step 11 ConIigure 802.1Q trunking and access ports on the workgroup switch by
conIiguring the Fa0/1, Fa0/2, and Fa0/3 interIaces oI your workgroup switch as
Iollows:
Fa0/1 is an 802.1Q trunk connected to the core switch. Only VLAN 1x and 2x
should be allowed on the trunk.
Fa0/2 should be an access port in VLAN 1x connected to the WGxR1 router.
Fa0/3 should be an access port in VLAN 2x connected to the WGxR2 router.
interface FastEthernet0/I
description - to core sw
switchport trunk allowed vlan 1x,2x
no ip address
!
interface FastEthernet0/?
description - to WGxRI
switchport access vlan 1x
switchport mode access
no ip address
!
interface FastEthernet0/·
description - to WGxR?
switchport access vlan 2x
no ip address
Step 12 VeriIy that the Fa0/1, Fa0/2, and Fa0/3 interIaces on the workgroup switch are all
up. Administratively enable any interIaces in the shutdown state.
WGxSI=sh ip int brief
Interface IP-Address OK? Method Status
Protocol
VlanI unassigned YES manual administratively
down down
FastEthernet0/I unassigned YES unset up
up
FastEthernet0/? unassigned YES unset up
up
FastEthernet0/· unassigned YES unset up
up
FastEthernet0/4 unassigned YES unset down
down
]rest omitted¦
Note: Ìn the lab, there is no requirement to ping to or from the workgroup switch. The workgroup
switch will not need an ÌP address configured on Ìnterface VLAN1 and will not need an ÌP
default-gateway configuration.
Step 13 From your WGxS1 switch, use the show interIace Ia0/x switchport command to
veriIy that the Fa0/1 interIace 802.1Q trunking is on and only allow VLANs 1x and
2x on the trunk.
WGxSI=sh int fa 0/1 switchport
Name. Fa0/I
Switchport. Enabled
Administrative Mode: trunk
operational Mode: trunk
Administrative Trunking Fncapsulation: dot1q
operational Trunking Fncapsulation: dot1q
Negotiation of Trunking: on
Access Mode VLAN. I (default)
Trunking Native Mode VLAN. I (default)
Administrative private-vlan host-association. none
Administrative private-vlan mapping. none
Operational private-vlan. none
Trunking VLANs Fnabled: 1x,2x
Pruning VLANs Enabled. ?-I00I
Protected. false
Voice VLAN. none (Inactive)
Appliance trust. none
Step 14 VeriIy that the Fa0/2 interIace is in VLAN1x.
Name. Fa0/?
Switchport. Enabled
Administrative Mode: static access
operational Mode: static access
Administrative Trunking Encapsulation. dotIq
Operational Trunking Encapsulation. native
Negotiation of Trunking: off
Access Mode VLAN: 1x (VLAN001x)
Trunking VLANs Enabled. ALL
Protected. false
Step 15 VeriIy that the Fa0/3 interIace is in VLAN2x.
Name. Fa0/·
Switchport. Enabled
Administrative Mode: static access
operational Mode: static access
Administrative Trunking Encapsulation. dotIq
Operational Trunking Encapsulation. native
Negotiation of Trunking: off
Access Mode VLAN: 2x (VLAN002x)
Trunking VLANs Enabled. ALL
Protected. false
Step 16 From the WGxR1 router, perIorm the Iollowing pings to conIirm connectivity and
routing protocol operation:
Ping the SPNorth router (10.4.x.100)
WGxRI=ping 10.4.x.100
Type escape sequence to abort.
Sending S, I00-byte ICMP Echos to I0.4.x.I00, timeout is ?
seconds.
!!!!!
Success rate is I00 percent (S/S), round-trip min/avg/max ¬
4/4/4 ms
Ping the SPSouth router internet connection (10.10.10.200)
WGxRI=ping 10.10.10.200
Sending S, I00-byte ICMP Echos to I0.I0.I0.?00, timeout is ?
seconds.
!!!!!
4/4/8 ms
Ping the WGxR2 router (10.2.x.2)
WGxRI=ping 10.2.x.2
Sending S, I00-byte ICMP Echos to I0.?.x.?, timeout is ?
seconds.
!!!!!
I8/I8/I8 ms
Ping the Pagent-1 (10.1.x.10) and Callgen-1 (10.1.x.11) routers.
Sending S, I00-byte ICMP Echos to I0.I.x.I0, timeout is ?
seconds.
!!!!!
40/4I/S8 ms
Sending S, I00-byte ICMP Echos to I0.I.x.II, timeout is ?
seconds.
!!!!!
I/?/4 ms
Step 17 From the WGxR2 router, perIorm the Iollowing pings to conIirm connectivity and
routing protocol operation:
Ping the SPSouth router (10.5.x.100)
WGxR?=ping 10.5.x.100
Sending S, I00-byte ICMP Echos to I0.S.x.I00, timeout is ?
seconds.
!!!!!
4/4/4 ms
Ping the SPNorth router internet connection (10.10.10.100)
WGxR?=ping 10.10.10.100
Sending S, I00-byte ICMP Echos to I0.I0.I0.I00, timeout is ?
seconds.
!!!!!
4/S/8 ms
Ping the Pagent-? (I0.·.x.I0) and Callgen-? (I0.·.x.II)
routers.
Ping the Pagent-2 (10.3.x.10) and Callgen-2 (10.3.x.11) routers.
Sending S, I00-byte ICMP Echos to I0.·.x.I0, timeout is ?
seconds.
!!!!!
40/4I/S8 ms
Sending S, I00-byte ICMP Echos to I0.·.x.II, timeout is ?
seconds.
!!!!!
I/?/4 ms
Step 18 On the WGxR1 and WGxR2 routers, administratively disable (shut) the serial 0/0
interIace.
Step 19 From the WGxR1 router, Telnet to the Pagent-1 router (10.1.x.10) and perIorm a
trace to the Pagent-2 router (10.3.x.10) to conIirm the path Irom Pagent-1 to Pagent-
2 Ilows through your pod (via the SPNorth and SPSouth router). Use the diagram in
Figure 3 to veriIy your trace.
WGxRI=telnet 10.1.x.10
Trying I0.I.x.I0 ... Open
User Access Verification
Username. super
Password. bowl
pagent-I>trace 10.3.x.10
Tracing the route to I0.·.x.I0
I I0.I.x.I 88 msec 84 msec 80 msec
? I0.4.x.I00 44 msec S8 msec S8 msec
· I0.I0.I0.?00 48 msec S? msec 48 msec
4 I0.S.x.? 44 msec S? msec S? msec
S I0.·.x.I0 ·? msec * 44 msec
pagent-I>exit
]Connection to I0.I.I.I0 closed by foreign host¦
WGxRI=
Step 20 From the WGxR1 router, Telnet to the Callgen-1 (10.1.x.11) router and perIorm a
trace to the Callgen-2 router (10.3.x.11) to conIirm the path Irom Callgen-1 to
Callgen-2 Ilows through your pod (via the SPNorth and SPSouth router). Use the
diagram in Figure 3 to veriIy your trace.
WGxRI>telnet 10.1.x.11
Trying I0.I.x.II ... Open
Username. super
Password. bowl
callgen-I>trace 10.3.x.11
Tracing the route to I0.·.x.II
? I0.4.x.I00 44 msec S8 msec S8 msec
· I0.I0.I0.?00 48 msec S? msec 48 msec
4 I0.S.x.? 44 msec S? msec S? msec
S I0.·.x.II ·? msec * 44 msec
callgen-I>exit
]Connection to I0.I.x.I0 closed by foreign host¦
WGxRI=
Step 21 On the WGxR1 and WGxR2 routers, administratively enable (no shut) the serial 0/0
interIace.
Step 22 Telnet to the Pagent-1 router (10.1.x.10) and perIorm a trace to the Pagent-2 router
(10.3.x.10) to conIirm the path Irom Pagent-1 to Pagent-2 now Ilows through your
pod and via the slow 384-kbps serial connection between your WGxR1 and WGxR2
router. Use the diagram in Figure 3 to veriIy your trace.
WGxRI=telnet 10.1.x.10
Trying I0.I.x.I0 ... Open
Username. super
Password. bowl
pagent-I>trace 10.3.x.10
Tracing the route to I0.·.x.I0
I I0.I.x.I S8 msec S? msec 80 msec
? I0.?.x.? II8 msec ?S? msec 48 msec
· I0.·.x.I0 I?8 msec * I04 msec
pagent-I>exit
]Connection to I0.I.x.I0 closed by foreign host¦
WGxRI=
Step 23 Save your running conIigurations oI the workgroup routers and the workgroup
switch to the startup-conIig in NVRAM.
Step 24 NotiIy your instructor when you have completed this initial setup lab.
Exercise Verification
You have completed this exercise when you attain these results:
Pings Irom the WGxR1 router to the SPNorth, WGxR2, Pagent-1, and Callgen-1 routers
are successIul
Pings Irom the WGxR2 router to the SPSouth, Pagent-2, and Callgen-2 routers are
successIul
A trace Irom Pagent-1 router to Pagent-2 router Ilows through your pod (via the SPNorth
and SPSouth routers) with the S0/0 interIace in the shutdown state
A trace Irom Callgen-1 router to Callgen-2 router Ilows through your pod (via the SPNorth
and SPSouth routers) with the S0/0 interIace in the shutdown state
A trace Irom the Pagent-1 router to the Pagent-2 router Ilows through your pod 384-kbps
serial link with all WGxR1 and WGxR2 serial interIaces administratively enabled
Lab Exercise 2-2: BaseIine QoS Measurement
Complete this lab exercise to practice what you learned in the related lesson.
Exercise Objective
In this exercise, you will create a baseline measurement oI network traIIic Ior use in evaluating
the eIIectiveness oI applied QoS mechanisms. AIter completing this exercise, you will be able
to meet these objectives:
Clear interIace counters on Cisco routers and switches
IdentiIy interIace statistics, which are meaningIul in traIIic baselines
Use Cisco IOS monitoring commands and network connectivity tools (ping) to gather
network response time data
VisuaI Objective
The Iigure illustrates what you will accomplish in this exercise.
In this lab, when the connectivity is properly established Ior your pod, you will record traIIic
statistics without any QoS conIiguration on your workgroup routers or workgroup switch. This
record oI the workgroup traIIic statistics will Iorm a rough baseline QoS measurement Ior your
pod.
For this lab, no special tools such as QPM, will be used to monitor QoS statistics. Instead,
Cisco IOS show commands and extended pings are used to Iorm a rough baseline
measurement.
Company Background
E-Commerce University is one oI the most respected private universities in CaliIornia based on
its progressive educational oIIerings, which include a Master oI Science degree in E-Commerce
Administrations and Implementations. E-Commerce University has a northern and southern
campus. The northern campus is located in Seattle, Washington, and the southern campus is
located in Santa Monica, CaliIornia. Both the northern and southern campuses have populations
oI 500 students and a Iaculty staII oI 50 proIessors and administrators.
Customer Situation
The E-Commerce University network currently has limited bandwidth capacity on their 384-
kbps lease line PPP WAN link that connects the northern and southern campus and they do not
envision being able to increase bandwidth in the near Iuture. Both campuses also have a 786-
kbps Internet connection. The preIerred traIIic path between the E-Commerce University
campuses is the 384-kbps link as the 768-kbps link connects to the Internet and will have a high
path cost, even though it is a directly connected link with a higher bandwidth oI 768 kbps.
The University has recently implemented the Iollowing three new applications:
An IP telephony system between the northern and southern campus
An Oracle (SQL) student administrations database system
Wireless Internet access Ior the students and Iaculties
Some oI the other key applications currently running on the E-Commerce University network
that the University IT staII is aware oI include:
Faculty remote access (Citrix)
Outlook e-mail (Exchange)
Web server Ior accessing University InIormation (HTTP)
Online courseware transIer between the northern and southern campus (FTP)
Because the deployment oI these applications, the E-Commerce University has been
encountering increasingly serious problems with their network.
Users oI the Oracle (SQL) student administrations database system have been complaining
oI unacceptable response times. Their subsecond response time has now stretched to
multiple seconds in many cases and up to a minute in some cases.
User oI the new IP telephony devices are the most upset. The quality oI their calls is very
poor and their calls oIten just drop.
Customer Requirements
At this point, the E-Commerce University is most concerned about the low VoIP voice quality
and has called upon you (the new network engineer they hired in the last month) to perIorm a
baseline measurement oI the VoIP traIIic via the low speed 384-kbps lease line connection
between the northern and southern campus.
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
BaseIine QoS Measurement Lab Commands
Command Description
show ip interface
(brief) (type)
(number)
clear counters To clear the interface counters
show interfaces
(interfaceid)
copy running~config
startup~config
Job Aids
Exercise Procedure
Step 1 VeriIy that the S0/0 and S0/1 interIaces on both oI your workgroup routers (WGxR1
and WGxR2) routers are administratively enabled.
Step 2 Clear the interIace counters on both your workgroup routers using the clear counters
command.
Note: At this time, your instructor has not yet started the Pagent and Callgen router traffic
generations.
Step 3 From the WGxR1 workgroup router, perIorm an extended ping to the WGxR2 router
serial 0/0 interIace then record the ping response time in the table at the end oI the
lab. For the extended ping, use a repeat count oI 100 and a datagram size oI 160.
WGxRI=ping
Protocol ]ip¦.
Target IP address. 10.2.x.2
Repeat count ]S¦. 100
Datagram size ]I00¦. 160
Timeout in seconds ]?¦.
Extended commands ]n¦.
Sweep range of sizes ]n¦.
Sending I00, I80-byte ICMP Echos to I0.?.x.?, timeout is ?
seconds.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round~trip min/avg/max
= 8/8/13 ms
Step 4 Repeat the extended ping two more times and record your results in the table at the
end oI this lab.
Step 5 Repeat Steps 3 and 4, but ping Irom the WGxR2 to WGxR1 serial 0/0 interIace and
record the response time results in the table at the end oI this lab.
Step 6 From both oI your workgroup routers, issue the show interIaces serial 0/0 command
and record the highlighted stats below in the table at the end oI the lab.
WGxRI=show interfaces serial0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
Description. to WGxR?
Internet address is I0.?.·.I/?4
MTU IS00 bytes, BW 384 Kbit, DLY ?0000 usec,
reliability ?SS/?SS, txload I/?SS, rxload I/?SS
Encapsulation PPP, LCP Open
Open. CDPCP, IPCP, loopback not set
Last input 00.00.0·, output 00.00.0I, output hang never
Last clearing of "show interface" counters 00.00.I?
Input queue. 0/IS/0/0 (size/max/drops/flushes), Total output
drops: 0
Conversations 0/?I/·? (active/max active/max total)
Available Bandwidth ?88 kilobits/sec
S minute input rate 0 bits/sec, 0 packets/sec
S minute output rate 0 bits/sec, 0 packets/sec
· packets input, 4?9 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0
abort
3 packets output, I84 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD¬up DSR¬up DTR¬up RTS¬up CTS¬up
command.
Step 8 NotiIy your instructor when you are done with the above steps.
lab. For the extended ping, use a repeat count oI 100 and a datagram size oI 160.
Caution: Before initiating the extended ping, wait for the Pagent/Callgen traffic to run for at least 1
minute so that the traffic generation can stabilize.
WGxRI=ping
Protocol ]ip¦.
Target IP address. 10.2.x.2
seconds.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
= 12/62/220 ms
Caution: After the Pagent traffic generation has been started, it is important that the Pagent routers
not be used for network measurements using ping and trace, because the Pagent routers
maintain a very high CPU load in generating the traffic demands for the QoS labs.
end oI this lab.
Step 11 Repeat steps 9 and 10, but ping Irom the WGxR2 to WGxR1 serial 0/0 interIace and
Step 12 From both oI your workgroup routers, issue the show interIaces serial 0/0 command
WGxRI=show interfaces serial 0/0
Description. to wgxrI
Internet address is I0.?.x.I/?4
MTU IS00 bytes, BW 384 Kbit, DLY ?0000 usec,
Last input 00.00.0?, output 00.00.00, output hang never
Last clearing of "show interface" counters 00.0I.?0
drops: 1023
output queue: 0/1000/64/1023 (size/max
total/threshold/drops)
Conversations 0/·?/?S8 (active/max active/max total)
S minute input rate SI000 bits/sec, II8 packets/sec
S minute output rate I98000 bits/sec, ?II packets/sec
8S9S packets input, 800·44 bytes, 0 no buffer
abort
9418 packets output, 8?8?I? bytes, 0 underruns
Note: The traffic sent between Pagent-1 and Pagent-2 is set up such that the traffic rate varies
constantly and will be different between the Pagent-1 and Pagent-2. When the traffic rate
from Pagent-1 to Pagent-2 is high and increasing then the traffic rate from Pagent-2 to
Pagent-1 will be low and decreasing and vice versa. As a result, the drop rate on your
workgroup router serial 0/0 interface may be different between your workgroup R1 and R2
routers.
Note: For Callgen, both Callgen routers will generate VoÌP calls at a constant rate.
Step 13 Compare the resulting statistics with and without the Pagent and Callgen traIIic
generations enabled.
You should notice that many oI the pings would have a longer response time due to
congestion on the low bandwidth 384-kbps PPP serial link.
BaseIine QoS Measurement Lab ResuIts
The Iollowing Iour tables are used to record the results oI your lab testing in this exercise.
Record your extended ping results in the two tables below:
WGxR1 to WGxR2 QoS BaseIine ping ResuIts
Packet Size Without Pagent/CaIIgen With Pagent/CaIIgen
160 bytes min/avg/max min/avg/max
Extended ping 1
Extended ping 2
Extended ping 3
success rate % success rate %
Extended ping 1
Extended ping 2
Extended ping 3
WGxR2 to WGxR1 QoS BaseIine ping ResuIts
Extended ping 1
Extended ping 2
Extended ping 3
Extended ping 1
Extended ping 2
Extended ping 3
Record your WGxR1 show interIaces serial 0/0 results in the Iollowing table:
WGxR1 QoS BaseIine show interfaces ResuIts
Without Pagent/CaIIgen With Pagent/CaIIgen
Queuing Strategy
ReIiabiIity, TxIoad, RxIoad
TotaI Output Drops
Output Queue: size/max totaI
Output Queue: threshoId/drops
Packets Output
Drop % (CaIcuIated by you as:
TotaI Output Drop / Packets
Output)
WGxR2 QoS BaseIine show interfaces ResuIts
Queuing Strategy
TotaI Output Drops
Output Queue: threshoId/drops
Packets Output
Output)
You have successIully completed the QoS baseline measurement by recording ping and
interIace statistics both beIore and aIter network traIIic generation.
Lab Exercise 3-1: Configuring QoS with AutoQoS
Exercise Objective
In this exercise, you will conIigure QoS Ior VoIP on Cisco IOS routers and Catalyst switches
using AutoQoS. AIter completing this exercise, you will be able to meet these objectives:
ConIigure AutoQoS on Cisco IOS routers
ConIigure AutoQoS on the Catalyst 2950 workgroup switch
VisuaI Objective
From the baseline measurement results, the E-Commerce University IT staII has determined
that the drop rate and the latency oI the VoIP traIIic must be improved. At this point, the E-
Commerce University has called upon you (the new CCNA network engineer they hired in the
last month) to improve the voice quality as quickly as possible over the weekend.
By the way, the E-Commerce University network is built using Cisco Catalyst 2950 switches,
Cisco 2610XM routers, and Cisco Aironet Wireless Access Points.
Through Cisco online e-learning, you discovered the new AutoQoS Ior VoIP Ieature that
allows automated conIiguration oI quality oI service (QoS) on the network and provides a
means Ior simpliIying the implementation and provisioning oI QoS Ior VoIP traIIic.
Because you have only a limited amount oI time to implement a solution, you have decided to
go ahead and use AutoQoS and then test and compare the VoIP QoS results to see iI AutoQoS
can be used to solve problem.
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
Configuring QoS with AutoQoS Lab Router Commands
Command Description
show running~config To display the contents of the currently running configuration file
ip cef To enable Cisco Express Forwarding (CEF) on the router
identification
auto qos voip To configure the AutoQoS-VoÌP feature on an interface
show auto qos
(interface (interface
type))
To display the configurations created by the AutoQoS-VoÌP feature
on a specific interface or all interfaces
show ip interface
(brief) (type)
(number)
show interfaces
multilink (interface
id)
encapsulation
encapsulationtype
copy running~config
startup~config
Configuring QoS with AutoQoS Lab Switch Commands
Command Description
identification
auto qos voip To configure automatic quality of service (AutoQoS) for voice over
ÌP (VoÌP) within a QoS domain
show auto qos
(interface (interface
id))
Displays the automatic quality of service (AutoQoS) configuration
that is applied
copy running~config
startup~config
Job Aids
These job aids are available to help you complete the lab exercise:
Task 1: Configuring AutoQoS on Cisco IOS Routers
In this task, you will enable the AutoQoS Ior VoIP Ieature on your workgroup router low
bandwidth PPP serial interIace.
Exercise Procedure
Step 1 Display and examine the running conIiguration oI your WGxR1 router.
Step 2 Enable CEF on your WGxR1 router.
Step 3 Enable the AutoQoS Ior VoIP Ieature Ior traIIic on the S0/0 interIace oI WGxR1
only. Do not conIigure AutoQoS to trust diIIerentiated services code point (DSCP)
markings.
Step 4 Display and examine the resulting AutoQoS conIiguration aIter enabling AutoQoS.
The Iollowing example outputs are Irom WG1.
ip access-list extended AutoQoS-VoIP-RTCP
permit udp any any range I8·84 ·?I8I
!
ip access-list extended AutoQoS-VoIP-Control
permit tcp any any eq II?0 (· matches)
permit tcp any any range II000 II999
permit udp any any eq ?4?I
permit tcp any any eq ?4?8
permit tcp any any range ?000 ?00?
permit udp any any eq III9
permit udp any any eq S080
!
class-map match-any AutoQoS-VoIP-RTP-UnTrust
match protocol rtp audio
match access-group name AutoQoS-VoIP-RTCP
!
class-map match-any AutoQoS-VoIP-Control-UnTrust
match access-group name AutoQoS-VoIP-Control
!
class-map match-any AutoQoS-VoIP-Remark
match ip dscp ef
match ip dscp cs·
match ip dscp af·I
!
policy-map AutoQoS-Policy-UnTrust
class AutoQoS-VoIP-RTP-UnTrust
priority percent I0
set dscp ef
class AutoQoS-VoIP-Control-UnTrust
bandwidth percent S
set dscp af·I
class AutoQoS-VoIP-Remark
set dscp default
class class-default
fair-queue
Serial0/0 -
!
interface Serial0/0
no ip address
encapsulation ppp
no fair-queue
ppp multilink
multilink-group ?00II00II4
!
interface Multilink?00II00II4
bandwidth 384
ip address I0.?.I.I ?SS.?SS.?SS.0
service-policy output AutoQoS-Policy-UnTrust
ppp multilink
ppp multilink fragment-delay I0
ip rtp header-compression iphc-format
!
rmon event ····· log trap AutoQoS description "AutoQoS SNMP
traps for Voice Drops" owner AutoQoS
rmon alarm ····4 cbQosCMDropBitRate.II4S.II4I ·0 absolute
rising-threshold I ····· falling-threshold 0 owner AutoQoS
Step 5 Repeat Steps 1 through 4 Ior WGxR2.
Step 6 Issue the show ip interface brief command on WGxR1 and ensure the Multilink
interIace is up. The Multilink interIace is required Ior PPP multilink and interleaving
operation. Notice that the S0/0 IP address assignment is automatically moved to the
multilink interIace.
Protocol
FastEthernet0/0 I0.I.I.I YES NVRAM up
up
Serial0/0 unassigned YFS unset up
up
Serial0/I I0.4.I.I YES NVRAM
administratively down down
Virtual-AccessI unassigned YES unset up
up
Multilink2001100114 10.2.1.1 YFS unset up
up
Note: Because Callgen is used to generate the VoÌP traffic, the voice quality of the VoÌP Phone
calls cannot be tested directly. Therefore, after AutoQoS has been enabled, you will modify
the resulting QoS configurations to make the ping traffic (icmp echo and reply) to have the
same EF PHB (per-hop behavior) as the VoÌP traffic. This way, you can compare the
extended ping responses with AutoQoS enabled to before AutoQoS was enabled.
Step 7 On the WGxR1 router, modiIy the ip access-list extended AutoQoS-VoIP-RTCP to
include the ping traIIic (icmp echo and echo reply).
permit icmp any any echo
permit icmp any any echo~reply
Step 8 Repeat Step 7 Ior the WGxR2 router.
You have successIully enabled the AutoQoS Ior VoIP Ieature on both WGxR1 and
WGxR2
You have conIigured ping (ICMP echo and reply) to belong to the same traIIic class as
VoIP traIIic
Task 2: Configuring AutoQoS on the CataIyst 2950 Switch
In this task, you will enable the AutoQoS Ior VoIP Ieature on your workgroup Catalyst 2950
switch.
Exercise Procedure
Step 1 Display and examine the running conIiguration oI your WGxS1 switch.
Step 2 Enable the AutoQoS Ior VoIP Ieature Ior traIIic on the Fa0/1 interIace oI WGxS1 and
trust the CoS markings Irom the core switch.
Step 3 Display and examine the resulting AutoQoS conIiguration aIter enabling AutoQoS.
Notice that the 2950 is now conIigured Ior WRR queuing with queue 4 setup as the
expedite queue (weight ÷ 0). WRR queuing will be covered in the Congestion
Management module.
wrr-queue bandwidth ?0 I 80 0
no wrr-queue cos-map
wrr-queue cos-map I 0 I ? 4
wrr-queue cos-map · · 8 I
wrr-queue cos-map 4 S
mls qos map cos-dscp 0 8 I8 ?8 ·? 48 48 S8
!
mls qos trust cos
auto qos voip trust
You have successIully enabled the AutoQoS Ior VoIP Ieature on WGxS1
Task 3: QoS BaseIine with AutoQoS
In this task, you will use Cisco IOS monitoring commands and network connectivity tools
(ping) to gather network response time data. You will compare the results oI the traIIic
statistics oI the network baseline statistics captured in Lab Exercise 2-2 and the network
statistics aIter the application oI AutoQoS.
Exercise Procedure
Step 1 ReIer to Lab 2-2 and copy the baseline traIIic inIormation with the Pagent and
Callgen traIIic generation running into the tables at the end oI this lab.
serial 0/0 interIace then record the ping response time in the table at the end oI the lab.
For the extended ping, use a repeat count oI 100 and a datagram size oI 160.
WGxRI=ping
Protocol ]ip¦.
Target IP address. I0.?.x.?
Repeat count ]S¦. I00
seconds.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
= 28/49/89 ms
end oI this lab.
Step 4 Repeat Steps 2 and 3, but ping Irom the WGxR2 to WGxR1 serial 0/0 interIace and
command.
Step 6 Wait Ior the interIace counters to accumulate traIIic statistics Ior at least 1 minute.
Step 7 From both oI your workgroup routers, issue the show interIaces multilink command
WGxRI=show interfaces Multilink2001100114
MMultilink?00II00II4 is up, line protocol is up
Internet address is I0.?.x.?/?4
MTU IS00 bytes, BW 384 Kbit, DLY I00000 usec,
Encapsulation PPP, LCP Open, multilink Open
Open. IPCP, loopback not set
DTR is pulsed for ? seconds on reset
Last input 00.00.09, output never, output hang never
Last clearing of "show interface" counters 00.0I.IS
drops: 1415
output queue: 151/1000/64/1415/3541 (size/max
total/threshold/drops/interleaves)
Conversations ?I/·0/I?8 (active/max active/max total)
Reserved Conversations I/I (allocated/max allocated)
Available Bandwidth I kilobits/sec
S minute input rate 9000 bits/sec, I9 packets/sec
S minute output rate ·S000 bits/sec, ·I packets/sec
49?8 packets input, ?II884 bytes, 0 no buffer
abort
11486 packets output, I·S8?0I bytes, 0 underruns
Step 8 Compare the results oI the traIIic statistics Irom Lab 2-2 QoS Baseline Measurement
to the results Irom this lab.
Is the ping maximum response time shorter than beIore AutoQoS was enabled?
Explain. ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Is the drop rate higher or lower or about the same than beIore AutoQoS was
enabled? Explain. ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 9 Remove the AutoQoS conIiguration on your workgroup switch and workgroup
routers.
WGxSI(config)=int fa0/I
WGxSI(config-if)=no auto qos voip
WGxSI(config-if)=end
WGxSI=show auto qos
AutoQoS is disabled
WGxRI(config)=int s0/0
WGxRI(config-if)=no auto qos voip
WGxR?(config)=int s0/0
WGxR?(config-if)=no auto qos voip
Note: When removing AutoQoS from WGxR1 and WGxR2, the encapsulation on your serial
interfaces may be returned to HDLC, the Cisco default serial interface encapsulation. Be
sure to reconfigure your serial interfaces for PPP encapsulation on both WGxR1 and
WGxR2.
Step 10 On both oI your workgroup routers, issue the show ip interface brief command and
ensure the serial 0/0 interIace is up. The multilink interIace should be removed when
AutoQoS has been disabled.
WGxRI=sh ip int brief
Protocol
FastFthernet0/0 10.1.1.1 YFS NVRAM up
up
Serial0/0 10.2.x.1 YFS unset up
up
Serial0/I I0.4.I.I YES NVRAM administratively
down down
Virtual-AccessI unassigned YES unset up
up
Step 11 Save your running conIigurations oI the workgroup routers and the workgroup switch
to the startup-conIig in NVRAM.
Configuring QoS with AutoQoS Lab ResuIts
Record your extended ping results in the two tables below:
WGxR1 to WGxR2 AutoQoS ping ResuIts
Packet Size
Without AutoQoS
(From Lab 2-2)
With AutoQoS
(This Lab)
Extended ping 1
Extended ping 2
Extended ping 3
Extended ping 1
Extended ping 2
Extended ping 3
WGxR2 to WGxR1 AutoQoS ping ResuIts
Packet Size
Without AutoQoS
(From Lab 2-2)
With AutoQoS
(This Lab)
Extended ping 1
Extended ping 2
Extended ping 3
Extended ping 1
Extended ping 2
Extended ping 3
Record your WGxR1 show interIaces multilink results in the Iollowing table:
WGxR1 AutoQoS show interfaces ResuIts
Without AutoQoS
(From Lab 2-2)
show interface s0/0
With AutoQoS
(This Lab)
show interface muItiIink
Queuing Strategy
TotaI Output Drops
Output Queue:
threshoId/drop/interIeaves
Packets Output
Output)
WGxR2 AutoQoS show interfaces ResuIts
Without AutoQoS
(From Lab 2-2)
show interface s0/0
With AutoQoS
(This Lab)
Queuing Strategy
TotaI Output Drops
Output Queue:
Packets Output
Output)
You have successIully completed the QoS baseline measurement aIter enabling AutoQoS
by recording ping and interIace statistics.
You have compared the results oI the traIIic measurement to those Irom the QoS Baseline
Lab and correctly answered the questions contained within the lab.
You have successIully remove AutoQoS conIiguration Irom your workgroup routers and
switch.
Lab Exercise 4-1: CIassification and Marking
Using MQC
Exercise Objective
In this exercise, you will conIigure classiIication using Modular QoS command-line interIace
(CLI) (MQC) and marking using class-based marking. AIter completing this exercise, you will
be able to meet these objectives:
ConIigure an IP extended access-list matching speciIic traIIic Ior use in MQC classiIication
ConIigure MQC classiIication
ConIigure class-based marking
VisuaI Objective
From the AutoQoS results, the E-Commerce University IT staII has determined that the VoIP
voice quality is now satisIactory. Because you did such a great job so Iar, the E-Commerce
University is now calling upon you to also improve the response time oI the Oracle (SQL)
student administration database application over their spring break. Because AutoQoS only
works Ior voice traIIic currently, you decided to remove the AutoQoS conIigurations and to
implement the proper QoS mechanisms manually using MQC.
As you have learned in the Cisco QoS course, one oI the Iirst steps to implement QoS is to
properly classiIy and mark the traIIic. ThereIore, you decide the Iirst step now Ior you is to
implement the proper classiIication and marking.
To ease into the QoS implementation, you decide to Iirst approach the classiIication and
marking oI the applications you Ieel are the bulk oI the University traIIic (FTP and HTTP).
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
CIassification and Marking Using MQC Lab Commands
Command Description
access~list access
listnumber ¦deny |
permit} tcp src src
wildcard (operator
(port)) dest dest
wildcard (operator
(port))
To define an extended ÌP access list for Transmission Control
Protocol (TCP) based traffic
class~map classmap
name
To create a class map to be used for matching packets to a
specified class
match access~group
¦accessgroup | name
accessgroupname}
To configure the match criteria for a class map on the basis of the
specified access control list (ACL)
policy~map policymap
name
To create or modify a policy map that can be attached to one or
more interfaces
class ¦classname |
class~default¦
To specify the name of the class whose policy you want to create
or change or to specify the default class
set dscp dscpvalue To mark a packet by setting the differentiated services code point
(DSCP)
service~policy ¦input
| output} policymap
name
To attach a policy map to an input interface or virtual circuit (VC),
or an output interface or VC
show access~lists
(accesslistnumber |
accesslistname)
To display the contents of current access lists
show class~map (class
mapname)
To display all class maps and their matching criteria
show policy~map
(policymap)
To display the configuration of all classes for a specified service
policy map or all classes for all existing policy maps
show policy~map
interface interface
name (input | output)
(class classmapname)
To display the packet statistics of all classes that are configured
for all service policies either on the specified interface or
subinterface
copy running~config
startup~config
Save your entries in the configuration file.
Job Aids
Exercise Procedure
Step 1 Connect to the WGxR1 router. ConIigure an IP extended access-list to match all FTP
traIIic.
Step 2 On the WGxR1 router, conIigure a second IP extended access-list to match all HTTP
(WWW) traIIic.
Step 3 Display and veriIy your IP extended access-list conIiguration.
Extended IP access list I0I
I0 permit tcp any any eq ftp
?0 permit tcp any any eq ftp-data
Extended IP access list I0?
I0 permit tcp any any eq www
Step 4 Create two new class maps called, match-ftp and match-www to match the FTP and
WWW traIIic, respectively.
Step 5 Display and veriIy your class-map conIiguration.
Class Map match-any class-default (id 0)
Match any
Class Map match-all match~ftp (id I)
Match access-group I0I
Class Map match-all match~www (id ?)
Match access-group I0?
Step 6 Create a policy map on your workgroup WGxR1 router, named mark-apps, that
includes the two newly conIigured traIIic classes (match-Itp and match-www). Use
class-based marking to mark the FTP traIIic to AF 11 and the WWW traIIic to DSCP
0.
Step 7 Display and veriIy your policy-map conIiguration.
Policy Map mark~apps
Class match-ftp
set dscp afII
Class match-www
set dscp default
Step 8 Apply the policy map to the FastEthernet 0/0 interIace oI your WGxR1 router in the
inbound direction.
Step 9 Display and veriIy your service policy.
FastEthernet0/0
Service~policy input: mark~apps
Class-map. match-ftp (match-all)
S minute offered rate I000 bps, drop rate 0 bps
Match. access-group I0I
QoS Set
dscp af11
Packets marked 320
Class-map. match-www (match-all)
Match. access-group I0?
QoS Set
dscp default
Packets marked 172
Match. any
Step 10 How many packets have been matched and marked on WGxR1 Ior each oI the traIIic
class?
Class Itp ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class www ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class class-deIault ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 11 Repeat Steps 1 through 9 Ior workgroup router WGxR2.
Step 12 How many packets have been matched and marked on WGxR2 Ior each oI the traIIic
class?
Class Itp ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class www ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class class-deIault ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
You have correctly created MQC classiIication Ior FTP and HTTP traIIic.
You have correctly conIigured MQC marking to mark FTP traIIic as AF11 and HTTP
traIIic as DSCP 0.
You have correctly enabled MQC classiIication and marking by applying the service policy
to both workgroup routers.
Lab Exercise 4-2: CIassification Using NBAR
Exercise Objective
In this exercise, you will conIigure classiIication using network-based application recognition.
AIter completing this exercise, you will be able to meet these objectives:
Discover network applications and traIIic using NBAR protocol discovery
ConIigure classiIication oI discovered applications using NBAR classiIication
ConIigure class-based marking
VisuaI Objective
AIter studying your current classiIication and marking strategy, you realize that using extended
IP access lists cannot properly classiIy all the traIIic now running on the network. One issue is
that there are too many applications being classiIied into the class-deIault. ThereIore, you
decide to conIigure network-based application recognition (NBAR) Ior your classiIication
requirements. BeIore you conIigure protocol matching with NBAR, you decide Iirst to analyze
the network using NBAR protocol discovery to validate your assumptions about the traIIic
currently traversing the network. AIter all traIIic has been properly identiIied, you plan to
conIigure a new class-based marking policy to classiIy and mark the applications running on
the network.
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
CIassification and Marking Using NBAR Lab Commands
Command Description
no service~policy
¦input | output}
policymapname
To remove a service policy from an input or output interface
(no) ip nbar protocol~
discovery
To configure NBAR to discover traffic for all protocols known to
NBAR on a particular interface
show ip nbar protocol~
discovery (interface
interfacespec)
To display the statistics gathered by the NBAR protocol discovery
feature
clear ip nbar
protocol~discovery
Clear NBAR protocol discovery statistics
ip access~list
¦standard | extended}
accesslistname
To define an ÌP access list by name
permit tcp source
sourcewildcard
destination
destinationwildcard
(operator (port))
To set conditions to allow a packet to pass a named ÌP access list
permit udp source
sourcewildcard
destination
destinationwildcard
(operator (port))
To set conditions to allow a packet to pass a named ÌP access list
class~map classmap
name
specified class
match protocol
protocolname
specified protocol
match access~group
¦access~group | name
accessgroupname}
specified ACL
name
more interfaces
class ¦classname |
class~default¦
set dscp dscpvalue To mark a packet by setting the differentiated services code point
(DSCP)
service~policy ¦input
| output} policymap
name
To attach a policy map to an input interface or virtual circuit (VC),
or an output interface or VC
mapname)
show policy~map
(policymap)
show policy~map
interface interface
To display the packet statistics of all classes that are configured
for all service policies either on the specified interface or
subinterface
copy running~config
startup~config
Job Aids
Exercise Procedure
Step 1 Disable the existing inbound service policy on the FastEthernet 0/0 interIace oI your
WGxR1 router.
Step 2 VeriIy that Cisco Express Forwarding is enabled on your WGxR1 router.
Step 3 Enable NBAR protocol discovery on the FastEthernet 0/0 interIace oI your WGxR1
router.
Step 4 Clear the NBAR protocol discovery counters on WGxR1.
Step 6 Display the NBAR protocol discovery traIIic statistics oI all NBAR discovered
protocols.
FastEthernet0/0
Input Output
Protocol Packet Count Packet Count
Byte Count Byte Count
S minute bit rate (bps) S minute bit rate
(bps)
--------------- ------------------------ ------------------
------
sqlnet ISI 404
94?0 808I8
I000 ·000
citrix ?0I S4I
I·84? SIS49
I000 ·000
http 88 ?SS
I··S· S98·8
0 ·000
napster 98 ?I?
S880 S4I?I
0 ·000
]rest omitted¦
Step 7 In the space provided below, list the protocols discovered by NBAR protocol
discovery:
1. 2. 3.
4. 5. 6.
7. 8. 9.
10. 11.
Step 8 Disable NBAR protocol discovery Irom the FastEthernet 0/0 interIace on WGxR1.
Step 10 On the WGxR1 router, conIigure NBAR classiIication and MQC marking to classiIy
inbound traIIic on the FastEthernet 0/0 interIace and mark it as outlined in the table
below. Completion oI this lab step will require the conIiguration oI 5 new class maps
(one Ior each service class) and the conIiguration oI a policy map (called mark-nbar)
that marks traIIic in each class appropriately.
Note: Remember by default, a class map is set to match all. Ìf you are matching multiple protocols
into the same class, remember to use match-any instead of match-all.
CIass Name
(cIass-map name)
ProtocoI PHB
real-time rtp/rtcp EF
real-time icmp EF
mission-critical sqlnet
voice-control (port specific
tcp and udp)
AF 31
interactive citrix AF 21
bulk ftp AF 11
scavenger kazaa2 CS 1
scavenger napster CS 1
class-default all others BE
When using NBAR to match RTP packets, there is one limitation in that protocol
matching Ior RTP does not match control packets. This is somewhat oI an advantage
in that it is preIerred that voice bearer traIIic be separated Irom voice control traIIic as
each traIIic type receives diIIerent QoS treatment (EF Ior voice bearer and AF31 Ior
voice control).
Create the Iollowing named access list Ior matching RTCP traIIic:
ip access-list extended VoIP-RTCP
Match the named access-list VoIP-RTCP into the real-time traIIic class along with
the RTP and ICMP traIIic.
The mission-critical class should be conIigured to contain both the sqlnet traIIic and
voice-control traIIic. Use the Iollowing ACL to match voice control traIIic when
creating the mission-critical class on your router:
ip access-list extended Voice-Control
permit tcp any any eq II?0
Note: Recall that Ìnternet Control Message Protocol (ÌCMP) traffic has been placed in the real-time
class as a means of measuring QoS performance.
Class Map match-all bulk (id 8)
Match protocol ftp
Class Map match~any real-time (id S)
Match protocol rtp
Match protocol icmp
Match access-group name VoIP-RTCP
Class Map match~any mission-critical (id 8)
Match protocol sqlnet
Match access-group name Voice-Control
Class Map match-all interactive (id I)
Match protocol citrix
Class Map match~any scavenger (id 9)
Match protocol kazaa?
Match protocol napster
]rest omitted¦
Step 12 Display and veriIy your policy-map conIiguration.
Policy Map mark-nbar
Class real-time
set dscp ef
Class mission-critical
set dscp af·I
Class interactive
set dscp af?I
Class bulk
set dscp afII
Class scavenger
set dscp csI
Class class-default
set dscp default
Step 13 Apply the policy map to the FastEthernet 0/0 interIace oI your WGxR1 router in the
inbound direction.
Step 15 Display and veriIy your service policy on interIace FastEthernet 0/0.
FastEthernet0/0
Service~policy input: mark~nbar
Class-map. real-time (match-any)
Match. protocol rtp
4 packets, 8S8 bytes
S minute rate 0 bps
Match. protocol icmp
I packets, I0 bytes
S minute rate 0 bps
Match. access-group name AutoQoS-VoIP-RTCP
S·I packets, II448? bytes
S minute rate 4000 bps
QoS Set
dscp ef
Packets marked 542
Class-map. mission-critical (match-any)
Match. protocol sqlnet
··I packets, S0I94 bytes
S minute rate ·000 bps
Match. access-group name Voice-Control
·S packets, 4?·0 bytes
S minute rate ?000 bps
QoS Set
dscp af31
Packets marked 366
Class-map. interactive (match-all)
Match. protocol citrix
QoS Set
dscp af21
Packets marked 295
]rest omitted¦
Step 16 How many packets have been matched and marked Ior each oI the traIIic class?
Class real-time ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class mission-critical ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class interactive ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class bulk ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class scavenger ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class class-deIault ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Note: Ìf the real-time, mission-critical, and scavenger classes have no matches, verify your class-
map configuration to ensure they are set to match-any and not match-all.
Step 18 How many packets have been matched and marked Ior each oI the traIIic class?
Class real-time ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class mission-critical ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class interactive ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class bulk ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class scavenger ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Class class-deIault ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
You have properly conIigured NBAR protocol discovery to identiIy network applications.
You have correctly conIigured NBAR classiIication.
You have correctly conIigured class-based marking oI NBAR classiIied traIIic.
Lab Exercise 4-3: Configuring QoS Pre-CIassify
Exercise Objective
In this exercise, you will conIigure and examine QoS pre-classiIy. AIter completing this
exercise, you will be able to meet these objectives:
ConIigure QoS pre-classiIy on a Cisco IOS router using a GRE tunnel
Monitor QoS pre-classiIy conIigurations
VisuaI Objective
The E-Commerce University IT staII has decided to implement a generic routing encapsulation
(GRE) tunnel between the north and south campus via the existing 768-kbps Internet
connection. AIter the GRE tunnel is set up and working properly, IPSec will also be enabled
over the GRE tunnel. At this point, the E-Commerce University IT staII needs you to Iirst
conIigure and test the GRE tunnel (without IPSec). They university plans to send diIIerent
types oI traIIic over the tunnel and would like to be able to diIIerentiate between diIIerent
traIIic Ilows so that QoS can be applied. In this lab, you will conIigure and veriIy the qos pre-
classiIy Ieature Ior traIIic classiIication over a GRE tunnel.
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
Configuring VPN QoS Lab Commands
Command Description
identification
qos pre~classify To enable QoS preclassification
ip cef To enable Cisco Express Forwarding (CEF) on the router
(no) shutdown To disable an interface
show ip interface
(brief) (type)
(number)
copy running~config
startup~config
Job Aids
Exercise Procedure
Step 1 VeriIy the S0/0 and S0/1 interIaces oI your workgroup WGxR1 and WGxR2 routers
are UP.
Protocol
FastEthernet0/0 I0.·.x.? YES NVRAM up
up
Serial0/0 I0.?.x.? YES unset up
up
Serial0/I I0.S.x.? YES NVRAM up
up
Step 2 VeriIy CEF switching is still enabled on both workgroup routers in your pod.
Step 3 ConIigure a GRE tunnel between your WGxR1 and WGxR2 router via the service
provider core as Iollows:
! WGxRI
!
interface Tunnel0
ip unnumbered fastethernet0/0
tunnel source Serial0/I
tunnel destination I0.S.x.?
! WGxR?
!
interface Tunnel0
ip unnumbered fastethernet0/0
tunnel destination I0.4.x.I
Step 4 ConIigure a static route via the tunnel 0 interIace to the 10.1.x.0 or 10.3.x.0 subnet
on the respective WGxR router as Iollows:
! WGxRI
!
ip route I0.·.x.0 ?SS.?SS.?SS.0 Tunnel0
! WGxR?
!
ip route I0.I.x.0 ?SS.?SS.?SS.0 Tunnel0
Step 5 Display the tunnel interIace and veriIy it is UP and operational.
WGxR2#show interface tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Interface is unnumbered. Using address of FastFthernet0/0
(10.3.x.2)
MTU ISI4 bytes, BW 9 Kbit, DLY S00000 usec,
reliability ?SS/?SS, txload 8I/?SS, rxload I98/?SS
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.5.x.2 (Serial0/1), destination 10.4.x.1
Tunnel protocol/transport GRE/IP, key disabled, sequencing
disabled
Tunnel TTL ?SS
Checksumming of packets disabled, fast tunneling enabled
Last input 00.00.0·, output 00.00.04, output hang never
Last clearing of "show interface" counters never
drops. 0
Queueing strategy. fifo
Output queue. 0/0 (size/max)
S minute input rate ?S000 bits/sec, 9 packets/sec
S minute output rate ·9000 bits/sec, ?· packets/sec
8I88S packets input, I??S4S89 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0
throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0
ignored, 0 abort
?8?049 packets output, S4II4890 bytes, 0 underruns
Step 6 Telnet to the Callgen-1 (10.1.x.11) router and perIorm a trace to the Callgen-2
(10.3.x.11) router. VeriIy the path goes thru your GRE tunnel.
Callgen-I=trace 10.3.x.11
Tracing the route to I0.·.x.II
? I0.·.x.II I40 msec * 8 msec
Step 7 Telnet to the Callgen-2 router and perIorm a trace to the Callgen-1 router. VeriIy the
path goes through your GRE tunnel.
Callgen-?=trace 10.1.x.11
Tracing the route to I0.I.x.II
I I0.·.x.? 80 msec S8 msec 84 msec
? I0.I.x.II 80 msec * S8 msec
Step 8 Issue the show queue serial0/1 command to display the WFQ inIormation Ior the
serial 0/1 interIace.
WGxRI=show queue serial0/I
drops. 9?89
Queueing strategy. weighted fair
Output queue. 4?/I000/84/9?89 (size/max
Conversations I/·I/?S8 (active/max active/max total)
Available Bandwidth SI8 kilobits/sec
(depth/weight/total drops/no-buffer drops/interleaves)
4I/·?·84/9?89/0/0
Conversation 9S, linktype. ip, length. ?08
source. I0.S.8.?, destination. I0.4.8.I, id. 0xC?FA, ttl.
?SS, prot. 4I
Note: You may have to run the show queue command a few times until you catch an
active flow. Ìf you are not able to see packets in the queue after several attempts, log onto
your other workgroup router and repeat Step 8.
How many active Ilows does the router see? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Notice that when QoS pre-classiIy is not conIigured, the output interIace sees only one Ilow,
which is Protocol 47 (GRE).
Step 9 ConIigure QoS pre-classiIy Ieature on the tunnel interIace.
Step 10 Issue the show queue serial0/1 command again to display the WFQ inIormation Ior
the serial 0/1 interIace.
WGxRI=show queue serial0/I
drops. IIII9I
Output queue. ISI/I000/84/IIII9I (size/max
Conversations ?I/·I/?S8 (active/max active/max total)
Available Bandwidth SI8 kilobits/sec
I/·?·84/0/0/0
Conversation II9, linktype. ip, length. I?
source. I0.I.I.I0, destination. I0.·.I.I0, id. 0xFF4C, ttl.
?S4,
TOS. I04 prot. 8, source port I08·, destination port IS?I
I/·?·84/0/0/0
Conversation ?I?, linktype. ip, length. I98
source. I0.I.I.I0, destination. I0.·.I.I0, id. 0xE84?, ttl.
I?I,
TOS. I? prot. 8, source port II0?, destination port I494
I/·?·84/0/0/0
Conversation 84, linktype. ip, length. I9
source. I0.I.I.I0, destination. I0.·.I.I0, id. 0x908A, ttl.
I?8,
TOS. I84 prot. II, source port 49S90, destination port 4980?
<output omitted>
Note: You may have to run the show queue command a few times until you catch some
active flows.
What happens when QoS pre-classiIy is conIigured on the tunnel interIace?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Can WFQ now distinguish between diIIerent application Ilows? Or does WFQ still only see
one Ilow (protocol 47÷GRE)?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 11 On the WGxR1 and WGxR2 routers, remove the static route via the tunnel interIace.
You have successIully conIigured a tunnel interIace between WGxR1 and WGxR2 through
the service provider backbone
You have successIully enabled the QoS pre-classiIy Ieature on the tunnel interIace
You have successIully examined the diIIerence in traIIic Ilows with and without the QoS
pre-classiIy Ieature enabled
Lab Exercise 4-4: LAN-Based Packet
CIassification and Marking
Exercise Objective
In this exercise, you will conIigure LAN based classiIication and marking. AIter completing
this exercise, you will be able to meet these objectives:
ConIigure a trust boundary on a Catalyst 2950 switch to only trust Cisco IP Phones
ConIigure CoS-to-DSCP mapping on a Catalyst 2950 switch
ConIigure IP access lists and class-based marking on a Catalyst 2950 switch to mark traIIic
VeriIy the QoS markings Irom the workgroup switch using the workgroup routers
VisuaI Objective
Your research into classiIication and marking policy has you concerned that students might
inject their traIIic into the network with CoS and DSCP markings that are not in accordance
with the new QoS policy. Not Iorgetting the QoS requirements oI the Cisco IP Phones
connected in the wiring closet, you decide to establish a trust boundary that extends to these
phones.
In addition, you also wish to classiIy and mark traIIic as close to the source as possible.
Studying the deIault CoS to DSCP marking maps on your Catalyst 2950 switches, you discover
that CoS 5 (which is set in your IP Phone endpoints automatically) is currently mapped to
DSCP 40. You would like this to map to EF (DSCP 46) and decide to change the deIault CoS
to DSCP mapping in your Catalyst 2950 switches.
One more issue arises in that the network also contains IP voice gateway devices that generate
G.711 voice traIIic, but cannot mark CoS or DSCP. You will have to implement classiIication
and marking at your trust boundary using access lists to accommodate these voice gateways.
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
LAN Based Packet CIassification and Marking Lab Commands
Command Description
mls qos trust (cos |
device cisco~phone |
dscp)
Configure the port trust state
switchport priority
extend ¦cos value |
trust}
Sets a port priority for the incoming untagged frames or the priority
of frames received by the ÌP Phone connected to the specified port
mls qos map ¦cos~dscp
dscpI...dscp8 | dscp~
cos dscplist to cos}
Define the class of service (CoS)-to-DSCP map or DSCP-to-CoS
map
access~list access
listnumber ¦deny |
permit | remark}
¦source source
wildcard | host source
| any}
Configures a standard ÌP ACL
class~map classmap
name
Create a class map to be used for matching packets to the class
whose name you specify
match ¦access~group
aclindex | access~
group name aclname |
ip dscp dscplist}
Define the match criteria to classify traffic
name
Create or modify a policy map that can be attached to multiple
interfaces
class ¦classname |
class~default¦
set ip dscp newdscp Classify ÌP traffic by setting a DSCP value
service~policy input
policymapname
Apply a policy map defined by the poIicy-map command to the
input of a particular interface
show access~lists
(name | number)
Display ACLs configured on the switch
mapname)
Display QoS class maps
show policy~map
(policymapname)
Display QoS policy maps
show mls qos maps
(cos~dscp | dscp~cos)
Display QoS mapping information
show mls qos interface
(interfaceid)
Display QoS information at the interface level
copy running~config
startup~config
Job Aids
Exercise Procedure
Step 1 Assuming there is a Cisco IP Phone connected to your workgroup WGxS1 switch
FastEthernet 0/1 port, establish a trust boundary on your workgroup WGxS1 switch
FastEthernet 0/1 interIace by setting your workgroup WGxS1 switch FastEthernet
0/1 interIace to only trust cos Irom the Cisco IP Phone.
Note: Because there is not a Cisco ÌP Phone connected to your workgroup switch in the lab, all the
incoming frames will have the CoS value set to the default port CoS of 0 by your workgroup
switch.
Step 2 Display the deIault CoS-to-DSCP mapping on your workgroup WGxS1 switch.
Dscp-cos map.
dscp. 0 8 I0 I8 I8 ?4 ?8 ·? ·4 40 48 48 S8
---------------------------------------
cos. 0 I I ? ? · · 4 4 S S 8 I
Cos-dscp map.
cos. 0 I ? · 4 S 8 I
------------------------------
dscp. 0 8 I8 ?4 ·? 40 48 S8
What is the deIault mapping oI CoS 5?
CoS 5 ÷ DSCP ¸¸¸¸¸
What is the DSCP per-hop behavior (PHB) represented by the deIault mapping oI CoS 5 on the
Catalyst 2950? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 3 Notice Irom Step 2 that the Catalyst 2950 deIault CoS-to-DSCP mapping does not
map CoS 5 to DSCP 46.
On your WGxS1 switch, change the deIault CoS-to-DSCP mapping to map CoS 5 to DSCP 46
as the downstream devices are expecting voice (CoS 5) traIIic to be marked with DSCP 46
(EF). All other CoS-to-DSCP mappings can remain at their deIault values.
Step 4 Display and veriIy the new CoS-to-DSCP mapping on your workgroup WGxS1
switch. VeriIy CoS 5 is now being mapped to DSCP 46.
Dscp-cos map.
dscp. 0 8 I0 I8 I8 ?4 ?8 ·? ·4 40 48 48 S8
---------------------------------------
cos. 0 I I ? ? · · 4 4 S S 8 I
Cos-dscp map.
cos. 0 I ? · 4 5 8 I
------------------------------
dscp. 0 8 I8 ?4 ·? 46 48 S8
Step 5 Assuming the Callgen routers (10.1.x.11 and 10.3.x.11) are the voice gateways
described earlier and the Callgen routers are not marking voice traIIic with DSCP 46
(Expedited Forwarding |EF|).
On your WGxS1 switch, create a policy map called mark-callgen, which uses two
access lists and class-based marking to mark all the traIIic Irom the Callgen routers
(10.1.x.11 and 10.3.x.11) to DSCP 46 (EF). Name the two new service classes
callgen1 and callgen2.
Apply your class-based marking policy to the FastEtherent 0/1 interIace on your
WGxS1 switch in the inbound direction.
Step 6 Display and veriIy your IP access-list conIiguration.
Standard IP access list I
permit I0.I.x.II
Standard IP access list ?
permit I0.·.x.II
Match any
Class Map match-all callgenI (id ?)
Match access-group I
Class Map match-all callgen? (id ·)
Match access-group ?
Step 8 Display and veriIy the conIiguration oI your class-based marking policy.
Policy Map mark~callgen
class callgenI
set ip dscp 48
class callgen?
set ip dscp 48
Step 9 Display and veriIy that your service policy is properly applied to the Fa0/1 interIace
in the inbound direction and also veriIy the trust setting and the deIault CoS value.
FastEthernet0/I
Attached policy~map for Ingress: mark~callgen
trust state. not trusted
trust mode. trust cos
COS override. dis
default CoS: 0
pass-through. none
trust device: cisco~phone
Step 10 To veriIy that the Catalyst 2950 classiIication and marking conIiguration is working
correctly, you will conIigure a class map on your workgroup router to count marked
packets. These veriIication steps should be perIormed on both workgroup routers
WGxR1 and WGxR2.
Step 11 On WGxR1, conIigure a new class map called match-sw-ef to match DSCP 46
traIIic Irom the WGxS1 switch.
Step 12 On WGxR1, conIigure a second new class map called match-sw-be to match DSCP
0 traIIic Irom the WGxS1 switch.
Step 13 Display and veriIy the two new class maps conIigured on WGxR1.
Class Map match-all match-sw-ef (id 4)
Match ip dscp ef
Class Map match-all match-sw-be (id S)
Match ip dscp default
Match any
Step 14 ConIigure a new policy map called verify-mark on WGxR1, which contains the two
new traIIic classes, match-sw-eI and match-sw-be.
Step 15 Display and veriIy the policy-map conIiguration on WGxR1.
Policy Map verify-mark
Class match-sw-ef
Class match-sw-be
Step 16 Disable the existing inbound service policy on the FastEthernet 0/0 interIace oI
WGxR1.
Caution: Do not remove the actual policy map, which contains the real-time, mission-critical,
interactive, bulk, and scavenger traffic classes, as you will use this policy map in later labs.
Step 17 Apply the new verify-mark policy to the FastEthernet 0/0 interIace oI WGxR1 in
the inbound direction.
Step 18 Display and veriIy the policy map is being applied correctly on the FastEthernet 0/0
interIace.
FastEthernet0/0
Service~policy input: verify~mark
Class-map. match~sw~ef (match-all)
S minute offered rate 0 bps
Match. ip dscp ef
Class-map. match~sw~be (match-all)
S minute offered rate ?8000 bps
Match. ip dscp default
0 packets, 0 bytes
Match. any
How many packets have been matched Ior each oI the traIIic class?
Traffic CIass WGxR1 WGxR2
match-sw-ef
match-sw-be
default
Step 19 Repeat Steps 11 through 18 Ior router WGxR2.
Step 20 Remove the inbound service policy Irom the FastEthernet 0/0 interIace on both the
WGxR1 and WGxR2 routers.
You have properly conIigured a trust boundary on a the WGxS1 switch to only trust Cisco
IP Phones
You have properly conIigured the CoS-to-DSCP mapping on WGxS1 to map CoS 5 to
DSCP 46
You have correctly conIigured IP access lists and class-based marking on WGxS1 to mark
traIIic Irom the Callgen routers DSCP 46
You have correctly veriIied the QoS markings Irom WGxS1 by conIiguring a QoS policy
on WGxR1 and WGxR2 to count marked packets
Lab Exercise 5-1: Configuring Basic Queuing
Exercise Objective
In this exercise, you will conIigure WFQ on a router to improve QoS. AIter completing this
exercise, you will be able to meet these objectives:
ConIigure FIFO queuing on Cisco routers
ConIigure WFQ on Cisco routers
Use the proper show commands to monitor and veriIy the WFQ operation
VisuaI Objective
Once the proper classiIication and marking are implemented, the next step in completing the E-
Commerce University QoS policy is to implement queuing mechanisms. Being an adventurous
network engineer, and to gain a better understanding oI the various queuing mechanisms, you
decided to Iirst explore two oI the more basic queuing methods: FIFO and WFQ.
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
Configuring Basic Queuing Lab Commands
Command Description
show interfaces (type
number)
To display statistics for all interfaces configured on the router or
access server
identification
(no)fair~queue
(congestivediscard
threshold (dynamic
queues (reservable
queues)))
To enable WFQ for an interface
show queue interface
name interfacenumber
To display the contents of packets inside a queue for a particular
interface
copy running~config
startup~config
Job Aids
Exercise Procedure
Step 1 Knowing that the S0/0 interIace on WGxR1 is 384 kbps, what will be the deIault
queuing mechanism? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 2 VeriIy your answer by displaying the current queuing mechanism on the S0/0
interIace oI WGxR1.
Internet address is I0.?.I.I/?4
MTU IS00 bytes, BW ·84 Kbit, DLY ?0000 usec,
reliability ?SS/?SS, txload I·/?SS, rxload II0/?SS
Encapsulation HDLC, loopback not set
Keepalive set (I0 sec)
Last input 00.00.00, output 00.00.00, output hang never
Last clearing of "show interface" counters 00.0·.SI
drops. I·S8
Output queue. 0/I000/84/I·S8 (size/max
Conversations 0/·I/I?8 (active/max active/max total)
S minute input rate ?S8000 bits/sec, ?8I packets/sec
S minute output rate III000 bits/sec, III packets/sec
I89I4 packets input, 98S8IS8 bytes, 0 no buffer
Received ?8 broadcasts, 0 runts, 0 giants, 0 throttles
abort
44?9· packets output, ?I84?89 bytes, 0 underruns
Step 3 Disable WFQ on the serial 0/0 interIace oI the WGxR1 and WGxR2 routers.
Which queuing method is S0/0 using now aIter WFQ was disabled?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 4 Display the current queuing mechanism on the workgroup WGxR1 router S0/0
interIace to veriIy your answer.
Internet address is I0.?.8.I/?4
reliability ?SS/?SS, txload ?·9/?SS, rxload 48/?SS
Last clearing of "show interface" counters ?I.0I.49
drops. ·04I00S
Queueing strategy: fifo
Output queue. I8/40 (size/max)
S minute input rate I·000 bits/sec, ?0I packets/sec
S minute output rate ·80000 bits/sec, ·S· packets/sec
I9IS80·S packets input, I·S8I04I?9 bytes, 0 no buffer
I input errors, 0 CRC, I frame, 0 overrun, 0 ignored, 0
abort
?SSSSI0· packets output, ?8IIS??II9 bytes, 0 underruns
0 output errors, 0 collisions, S interface resets
Step 5 PerIorm an extended ping Irom WGxR1 to WGxR2 using a repeat count oI 100 and
a size oI 160 bytes and record the results in the table at the end oI this lab.
WGxRI=ping
Protocol ]ip¦.
Sending I00, I80-byte ICMP Echos to I0.?.I.?, timeout is ?
seconds.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
= 8/15/168 ms
end oI this lab.
Step 7 Repeat Steps 5 and 6, but ping Irom WGxR2 to WGxR1 serial 0/0 interIace and
Step 8 What are some disadvantages oI with using FIFO queuing Ior the voice and mission-
critical traIIic? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 9 Re-enable WFQ on the serial 0/0 interIace oI both WGxR1 and WGxR2. Use the
deIault congestion discard threshold and the deIault maximum conversations.
Step 10 Display the interIace statistics oI the serial 0/0 interIace.
reliability ?SS/?SS, txload ?4·/?SS, rxload 48/?SS
Last input 00.00.0I, output 00.00.00, output hang never
Last clearing of "show interface" counters I9.?9.·8
drops. ?8I8I90
Conversations ?I/?8/I?8 (active/max active/max total)
S minute input rate I·000 bits/sec, ?08 packets/sec
S minute output rate ·88000 bits/sec, ·4I packets/sec
II9I?09? packets input, I·040S·I?4 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttl
??.48.SS. %SYS-S-CONFIG_I. Configured from console by
consolees
abort
?·SS·094 packets output, ?8III8II8· bytes, 0 underruns
0 output errors, 0 collisions, · interface resets
Step 11 What is the deIault Congestion Discard Threshold (CDT)?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 12 What is the deIault number oI maximum conversations on the S0/0 interIace?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 13 Change the maximum number oI conversations on the S0/0 interIace oI WGxR1 and
WGxR2 to 1024.
Step 14 Display the interIace statistics oI the serial 0/0 interIace and veriIy that the
maximum conversations have been corrected changed.
reliability ?SS/?SS, txload ?4·/?SS, rxload 48/?SS
Last clearing of "show interface" counters I9.·?.4I
drops. ?889808
Output queue. I0I/I000/84/?889448 (size/max
S minute input rate I·000 bits/sec, ?II packets/sec
S minute output rate ·8I000 bits/sec, ·8I packets/sec
I80II990 packets input, I·0S88984· bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 thrott
??.S0.00. %SYS-S-CONFIG_I. Configured from console by
consoleles
abort
?·8?0090 packets output, ?8?8?9?I04 bytes, 0 underruns
Step 15 What is a beneIit oI increasing the maximum conversations?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 16 Clear the interIace counters on your WGxR1 and WGxR2 routers.
Step 17 Examine the active dynamic queues set up by WFQ. You may only see Ilows on
only one oI your workgroup routers because oI the traIIic Ilow patterns between the
Pagent-1 and Pagent-2 router.
drops. ·??I·4S
Available Bandwidth 288 kilobits/sec
I/32384/?8/0/0
Conversation 8S, linktype. ip, length. 44
source. I0.I.I.I0, destination. I0.·.I.I0, id. 0xFF4C, ttl.
?S4,
TOS. 0 prot. 8, source port I08·, destination port IS?I
?I/32384/4I8/0/0
Conversation 9I, linktype. ip, length. 9I
source. I0.I.I.I0, destination. I0.·.I.I0, id. 0xE84?, ttl.
I?I,
TOS. 0 prot. 8, source port II0?, destination port I494
8/32384/·S0/0/0
Conversation SI, linktype. ip, length. ?I9
source. I0.I.I.I0, destination. I0.·.I.I0, id. 0x908A, ttl.
I?8,
TOS. 0 prot. II, source port 49S90, destination port 4980?
How many packets have been dropped? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
What is the number oI active conservations? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
What is the number oI maximum active conservations? ¸¸¸¸¸¸¸¸¸¸¸¸¸
What is the maximum number oI total conservations? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸
What is the available bandwidth and how is it calculated?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
What is the signiIicance oI the weight in these conversations?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
What Iactor or Iactors can inIluence the weight? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
WGxRI=ping
Protocol ]ip¦.
seconds.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
= 12/57/192 ms
end oI this lab.
Step 20 Repeat Steps 18 and 19, but ping Irom the WGxR2 to WGxR1 serial 0/0 interIace
and record the response time results in the table at the end oI this lab.
Did the ping response time improve compared to when FIFO was the queuing
method? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
WGxR1 RTT Measurement Worksheet
Network Situation
Ping 1 RTT
(min/ave/max)
Ping 2 RTT
(min/ave/max)
Ping 3 RTT
(min/ave/max)
Before Pagnet / CaIIgen traffic
(from 2-2: BaseIine QoS
Measurement)
After Pagnet/CaIIgen traffic (from
2-2: BaseIine QoS Measurement)
After enabIing Auto-QoS (from 3-1:
Configuring QoS with AutoQoS)
FIFO (from 5-1: Configuring Basic
Queuing)
WFQ (from 5-1: Configuring Basic
Queuing)
Network Situation
Ping 1 RTT
(min/ave/max)
Ping 2 RTT
(min/ave/max)
Ping 3 RTT
(min/ave/max)
Measurement)
Queuing)
Queuing)
You have successIully conIigured FIFO queuing on WGxR1 and WGxR2
You have successIully conIigured WFQ on WGxR1 and WGxR2
You have examined WFQ router parameters and monitoring command output and
successIully answered the questions contained in this lab exercise
You have compared the round-trip response times Ior packets traversing a serial interIace
using FIFO queuing to an interIace using WFQ
Lab Exercise 5-2: Configuring LLQ
Exercise Objective
In this exercise, you will conIigure low-latency queuing (LLQ) on a router to improve QoS.
AIter completing this exercise, you will be able to meet these objectives:
ConIigure LLQ on a Cisco router to provide bandwidth guarantees
Use the proper show commands to monitor and veriIy the LLQ operation
VisuaI Objective
In Lab Exercise 5-1, you examined both FIFO queuing and WFQ.
FIFO is a Iirst-come-Iirst-serve queuing strategy. As such, FIFO does not classiIy traIIic into
diIIerent Ilows, or provide diIIerentiated treatment to packets. FIFO does not Iairly allocate
bandwidth among multiple Ilows. Some Ilows may receive more bandwidth because they
contain larger packets or they send more packets (aggressive Ilows). FIFO does not give
priority to voice traIIic or mission-critical traIIic, as it cannot diIIerentiate between packets
Irom diIIerent Ilows. ThereIore, iI FIFO is implemented on the serial WAN links, the
conIiguration will not meet the E-Commerce University requirements Ior the voice and Oracle
(SQL) traIIic.
AIter FIFO queuing, WFQ was enabled on the workgroup routers. With WFQ, packets are
automatically classiIied into a particular dynamic queue based on inIormation contained within
the protocol headers. WFQ automatically assigns a weight to the packets. The weight is based
on the IP precedence value and the size oI the packets. Higher IP precedence and smaller size
packets will receive better serviced than lower IP precedence and larger size packets. However,
WFQ does not provide any hard bandwidth guarantees to voice traIIic or to mission-critical
traIIic. From the traIIic measurement results (round-trip time |RTT| observations), it was
determined that WFQ provided too much latency Ior EF traIIic types. ThereIore, in order to
improve voice quality and the response time oI mission-critical traIIic, LLQ must be
implemented on the workgroup routers.
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
Configuring Queuing Hybrids Lab Commands
Command Description
class~map classmap
name
Create a class map to be used for matching packets to the class
whose name you specify
match ¦access~group
aclindex | access~
group name aclname |
ip dscp dscplist}
Define the match criteria to classify traffic
match (ip) dscp dscp
value
To identify a specific ÌP DSCP value as a match criterion
match protocol
protocolname
specified protocol
name
Create or modify a policy map that can be attached to multiple
interfaces
class ¦classname |
class~default¦
set ip dscp newdscp Classify ÌP traffic by setting a DSCP value
priority¦bandwidth~
kbps | percent
percentage} (burst)
To give priority to a class of traffic belonging to a policy map
bandwidth ¦bandwidth~
kbps | remaining
percent percentage |
percent percentage}
To specify or modify the bandwidth allocated for a class belonging
to a policy map
service~policy input
policymapname
Apply a policy map defined by the policy-map command to the
input of a particular interface
access~list access
listnumber ¦deny |
permit} tcp src src
wildcard (operator
(port)) dest dest
wildcard (operator
(port))
To define an extended ÌP access list for Transmission Control
Protocol (TCP) based traffic
show access~lists
(accesslistnumber |
accesslistname)
To display the contents of current access lists
mapname)
show policy~map
(policymap)
show policy~map
interface interface
To display the packet statistics of all classes that are configured for
all service policies either on the specified interface or subinterface
copy running~config
startup~config
Job Aids
Exercise Procedure
Step 1 Connect to your WGxR1 router and veriIy that the QoS policy map named mark-
nbar is still conIigured. Apply the existing mark-nbar policy map to the
FastEthernet 0/0 interIace in the inbound direction. II you do not have the mark-nbar
policy, it is shown below:
class-map match-any real-time
match protocol rtp
match protocol icmp
match access-group name VoIP-RTCP
class-map match-any mission-critical
match protocol sqlnet
match access-group name Voice-Control
class-map interactive
class-map bulk
match protocol ftp
class-map match-any scavenger
match protocol kazaa?
match protocol napster
!
policy-map mark-nbar
class real-time
set ip dscp ef
set ip dscp af·I
class interactive
set ip dscp af?I
class bulk
set ip dscp afII
class scavenger
set ip dscp csI
Step 2 At this point, what is the expected eIIect on traIIic Ilow out the low speed 384-kbps
serial link (S0/0) when the mark-nbar service-policy is applied on the FastEthernet
0/0 interIace oI WGxR1 router? Explain.
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 3 ConIigure Iive new class maps on your workgroup WGxR1 router as described on
the Iollowing table. When matching ICMP traIIic, use an extended ACL instead oI
NBAR as NBAR only matched transit traIIic.
CIass Name (cIass
map name)
Match Criteria
ef-traffic EF, ÌCMP echo and reply
af31-traffic AF 31
af21-traffic AF 21
af11-traffic AF 11
cs1-traffic CS 1
Step 4 Display and veriIy your extended IP access list Ior matching the ping traIIic.
Extended IP access list I00
I0 permit icmp any any echo-reply (I00 matches)
?0 permit icmp any any echo
Step 5 Display and veriIy the Iive new class maps conIigured on your workgroup WGxR1
router.
Class Map match-any ef-traffic (id I0)
Match dscp ef
Match access-group I00
Class Map match-all af?I-traffic (id I?)
Match dscp af?I
Class Map match-all af·I-traffic (id II)
Match dscp af·I
Class Map match-all afII-traffic (id I·)
Match dscp afII
Class Map match-all csI-traffic (id I4)
Match dscp csI
Step 6 ConIigure a new policy map called llq-policy on your workgroup WGxR1 router
where each traIIic class gets the Iollowing bandwidth guarantee.
Traffic CIass Bandwidth Guarantee
ef-traffic 168 kbps maximum
af31-traffic 40% of remaining bandwidth mininum
cs1-traffic 2% of remaining bandwidth mininum
class-default 25% of remaining bandwidth mininum
Step 7 Display and veriIy the llq-policy policy map on your workgroup WGxR1 router.
Policy Map llq~policy
Class ef-traffic
Strict Priority
Bandwidth I88 (kbps) Burst 4?00 (Bytes)
Class af·I-traffic
Class af?I-traffic
Bandwidth remaining ?0 (%) Max Threshold 84 (packets)
Class afII-traffic
Bandwidth remaining I· (%) Max Threshold 84 (packets)
Class csI-traffic
Bandwidth remaining ? (%) Max Threshold 84 (packets)
Class class-default
Bandwidth remaining ?S (%) Max Threshold 84 (packets)
Step 8 Apply the new llq-policy policy map on your workgroup WGxR1 router S0/0
interIace in the outbound direction.
Why must the policy be applied in the outbound direction and not the inbound
direction? Explain. ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 9 Repeat the above LLQ conIiguration, Steps 1 through 8, Ior the WGxR2 router.
Step 11 Display and veriIy the outbound service policy on your workgroup WGxR1 router
S0/0 interIace.
Serial0/0
Service-policy output. llq~policy
Class-map. ef~traffic (match-any)
··? packets, 884S? bytes
Match: dscp ef
··? packets, 884S? bytes
Match: access~group 100
0 packets, 0 bytes
S minute rate 0 bps
Queueing
Strict Priority
Output Queue. Conversation I·8
Class-map. af31~traffic (match-all)
I08I packets, I49·I4 bytes
Match. dscp af31
Queueing
Output Queue. Conversation I·I
I4S? packets, I??I00 bytes
Match. dscp af21
Queueing
SI0 packets, ·?499 bytes
Match. dscp af11
Queueing
Class-map. cs1~traffic (match-all)
89I packets, I9I??S bytes
Match. dscp cs1
Queueing
Output Queue. Conversation I40
Class-map. class~default (match-any)
?8·8 packets, 44?008 bytes
Match. any
Queueing
Output Queue. Conversation I4I
Which traIIic class or classes, iI any, still have drops? ¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 12 Display and veriIy the outbound service policy on your workgroup WGxR2 router
S0/0 interIace.
Which traIIic class or classes, iI any, still have drops? ¸¸¸¸¸¸¸¸¸¸¸¸¸
WGxRI=ping
Protocol ]ip¦.
seconds.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
= 8/17/68 ms
end oI this lab.
Step 15 Repeat Steps 13 and 14, but ping Irom the WGxR2 to WGxR1 serial 0/0 interIace
and record the response time results in the table at the end oI this lab.
Step 16 Compare the ping results to the results Irom the previous laboratory exercises (2-2:
Baseline QoS Measurement, 3-1: ConIiguring QoS with AutoQoS).
Comparing all the results, which QoS mechanism provided the best response time
Ior VoIP packets? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Network Situation
Ping 1 RTT
(min/ave/max)
Ping 2 RTT
(min/ave/max)
Ping 3 RTT
(min/ave/max)
Before Pagnet / CaIIgen traffic (from
After Pagnet/CaIIgen traffic (from 2-
2: BaseIine QoS Measurement)
Queuing)
Queuing)
LLQ resuIts from this Iab
Network Situation
Ping 1 RTT
(min/ave/max)
Ping 2 RTT
(min/ave/max)
Ping 3 RTT
(min/ave/max)
Queuing)
Queuing)
LLQ resuIts from this Iab
LLQ is properly conIigured on WGxR1 and WGxR2
The extended pings produced lower round-trip response time with LLQ than WFQ
Lab Exercise 5-3: Queuing on CataIyst Switches
Exercise Objective
In this exercise, you will conIigure the two queuing methods available on the Catalyst 2950
switch. AIter completing this exercise, you will be able to meet these objectives:
Examine queuing conIigurations resulting Irom the application oI AutoQoS on the Catalyst
2950 switch
ConIigure and monitor CoS-to-queue mapping on the Catalyst 2950 switch
ConIigure and monitor WRR queuing on the Catalyst 2950 switch
VisuaI Objective
AIter reviewing the AutoQoS output on the Catalyst 2950 switch, the E-Commerce University
IT staII has a Iew questions about the AutoQoS generated conIigurations. AIter meeting with
the IT staII and hopeIully being able to answer all their questions, the IT staII has decided to
change the deIault Catalyst 2950 queuing Irom PQ to weighted round robin (WRR) with an
expedite queue so that only voice (CoS 5) Irames will receive strict priority while giving Irames
with CoS 0 to 4 a lower weight than Irames with CoS 6 to 7.
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
Queuing on CataIyst Switches Lab Commands
Command Description
show wrr~queue cos~map Displays the mapping of the CoS priority queues (PQs)
wrr~queue bandwidth
weightI...weight~
Assigns weighted round-robin (WRR) weights to the four CoS
priority queues
no wrr~queue cos~map Sets the CoS map to default setting
wrr~queue cos~map quid
cosI...cosn
Assign CoS values to the CoS priority queues.
quid: The queue id of the CoS priority queue
cos1...cosn: The CoS values that are mapped to the queue id
mls qos map cos~dscp
dscpI...dscp8
Defines the CoS-to-DSCP map
mls qos trust (cos |
device cisco~phone |
dscp)
Configure the port trust state
show wrr~queue
bandwidth
Displays the WRR bandwidth allocation for the four CoS priority
queues
copy running~config
startup~config
Job Aids
Exercise Procedure
Step 1 In this lab, you will Iirst examine the deIault PQ on the Catalyst 2950 workgroup
switch. Then you will conIigure and examine WRR on the Catalyst 2950 workgroup
switch.
What is the deIault queuing mechanism on the Catalyst 2950 switch?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 2 Connect to your WGxS1 switch and display the CoS to Queue mapping. Your
output should look similar to the Iollowing:
CoS Value . 0 I ? · 4 S 8 I
Priority Queue. I I ? ? · · 4 4
How many output queues per interIace are available Ior the Catalyst 2950? ¸¸¸¸¸¸¸
Which queue has the highest priority? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 3 In Lab Exercise 3-1, ConIiguring QoS with AutoQoS, the AutoQoS Ior VoIP Ieature
was enabled on the Catalyst 2950 switch in your workgroup. By deIault, AutoQoS
enables queuing as shown in the Iollowing conIiguration:
WGxSI=show auto qos
!
mls qos trust cos
Step 4 What type oI queuing is enabled using the above conIiguration? ¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 5 From the 'wrr-queue bandwidth 20 1 80 0¨ command, why is the weight Ior queue
#4 equal to '0¨? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 6 What do the Iollowing commands accomplish?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 7 On the WGxS1 switch, implement WRR queuing as Iollows:
ConIigure a PQ that services all Irames marked CoS 5.
ConIigure WRR queue 3 to service all Irames marked CoS 6 and CoS 7 and
guarantee a bandwidth oI 70.
ConIigure WRR queue 1 to service all Irames marked CoS 0 CoS 4 and guarantee
a bandwidth oI 30.
WRR queue 2 is unused and should be conIigured as such.
Step 8 Display and veriIy the CoS to queue mapping has been correctly conIigured and the
Irames marked CoS 5 are services by the PQ.
CoS Value . 0 I ? · 4 5 8 I
Priority Queue. I I I I I 4 · ·
Step 9 Display and veriIy the weight setting Ior each queue.
WRR Queue. 1 2 3 4
bandwidth. 30 1 70 0
Step 10 ConIigure the FastEthernet 0/1 interIace on WGxS1 to trust the CoS marking.
Step 11 Ensure that DSCP EF is marked 46 Ior incoming Irames marked CoS 5.
Correctly described the eIIects oI the resulting AutoQoS conIigurations on the Catalyst
2950 switch.
Correctly conIigure WRR queuing on the Catalyst 2950 switch and enable queue #4 as the
expedite queue and map CoS 5 traIIic into the expedite queue
Lab Exercise 6-1: Configuring DSCP-Based
WRED
Exercise Objective
In this exercise, you will build a weighted random early detection (WRED) traIIic proIile given
a set oI parameters and conIigure DSCP-based WRED with explicit congestion notiIication
(ECN) support to match that traIIic proIile. AIter completing this exercise, you will be able to
ConIigure DSCP-Based CB-WRED
ConIigure DSCP-Based CB-WRED with ECN
Monitor DSCP-Based CB-WRED operations
VisuaI Objective
AIter LLQ was successIully implemented, the voice quality deIinitely improved. But aIter
monitoring the link utilization on the low-speed 384-kbps link Ior a week, it has been
determined that the average link utilization is low and must be improved.
You recall Irom the Cisco IOS documentation that global synchronization occurs as waves oI
congestion crest only to be Iollowed by troughs during which the transmission link is not Iully
utilized. Global synchronization oI TCP hosts can occur because packets are dropped all at
once. Global synchronization maniIests when multiple TCP hosts reduce their transmission
rates in response to packet dropping, and once congestion is reduced, the TCP hosts again
increase their transmission rates. The most important point is that the waves oI transmission
known as global synchronization result in signiIicant link under-utilization.
In order to reduce TCP global synchronization to improve link utilization, CB-WRED is
required to randomly drop packets beIore the soItware queue is Iull. In addition, DSCP-based
CB-WRED allows diIIerent WRED (drop) proIiles Ior diIIerent DSCP values.
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
DSCP-Based WRED with ECN Lab Commands
Command Description
name
more interfaces
class ¦classname |
class~default¦
random~detect dscp
dscpvalue min
threshold max
threshold (mark
probability
denominator)
To change the minimum and maximum packet thresholds for the
DSCP value
random~detect (dscp~
based | prec~based)
To enable WRED or distributed WRED (DWRED)
random~detect ecn To enable ECN
show policy~map
(policymap)
show policy~map
interface interface
mapname)
Display QoS class maps
copy running~config
startup~config
Job Aids
Exercise Procedure
Step 1 ModiIy the existing llq-policy map on the workgroup WGxR1 router and enable
DSCP-Based WRED Ior the aI11-traIIic, aI21-traIIic, aI31-traIIic, cs1-traIIic, and
the class-deIault traIIic classes with the Iollowing drop thresholds and drop
probabilities:
PHB Minimum
ThreshoId
Maximum
ThreshoId
Mark ProbabiIity
af11 26 40 1/10
af21 30 40 1/10
af31 34 40 1/10
cs1 22 40 1/10
Default (BE) 20 40 1/10
Complete the graph oI the traIIic proIile below Ior all 5 WRED classes. Be sure to indicate
each class and the mark probability denominator.
Based on the previous WRED proIiles, which traIIic class will start dropping packets Iirst?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
What does a mark probability oI 1/10 means?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Why would you not implement WRED Ior the eI-traIIic class?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 2 Display the llq-policy policy map and to veriIy the WRED conIigurations.
Policy Map llq-policy
Class ef~traffic
Strict Priority
Class af31~traffic
Bandwidth remaining 40 (%)
dscp min-threshold max-threshold mark-
probablity
---------------------------------------------------
-------
afII - - I/I0
afI? - - I/I0
afI· - - I/I0
af?I - - I/I0
af?? - - I/I0
af?· - - I/I0
af31 34 40 1/10
af·? - - I/I0
]output omitted¦
100%
Average
Queue
Size
Drop
ProbabiIity
20 22 26 30 34 40
100%
Average
Queue
Size
Drop
ProbabiIity
20 22 26 30 34 40
Class af21~traffic
Bandwidth remaining ?0 (%)
probablity
---------------------------------------------------
-------
afII - - I/I0
afI? - - I/I0
afI· - - I/I0
af21 30 40 1/10
af?? - - I/I0
af?· - - I/I0
]output omitted¦
Class af11~traffic
Bandwidth remaining I· (%)
probablity
---------------------------------------------------
-------
af11 26 40 1/10
afI? - - I/I0
afI· - - I/I0
]output omitted¦
Class cs1~traffic
Bandwidth remaining ? (%)
probablity
---------------------------------------------------
-------
afII - - I/I0
afI? - - I/I0
afI· - - I/I0
af?I - - I/I0
af?? - - I/I0
af?· - - I/I0
af·I - - I/I0
af·? - - I/I0
af·· - - I/I0
af4I - - I/I0
af4? - - I/I0
af4· - - I/I0
cs1 22 40 1/10
cs? - - I/I0
]output omitted¦
Class class~default
Bandwidth remaining ?S (%)
probablity
---------------------------------------------------
-------
]output omitted¦
ef - - I/I0
rsvp - - I/I0
default 20 40 1/10
Step 3 What is the deIault exponential weight constant? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Are all the drop thresholds and drop probability set correctly? ¸¸¸¸¸¸¸¸¸¸
Step 4 Clear the counters on all interIaces on the WGxR1 router.
Step 6 Display the output service policy on the S0/0 interIace.
Serial0/0
Service~policy output: llq~policy
Class-map. ef-traffic (match-any)
?998 packets, S994·I bytes
Match. dscp ef
?998 packets, S994·I bytes
S minute rate 4000 bps
Match. access-group I00
0 packets, 0 bytes
S minute rate 0 bps
Queueing
Strict Priority
(pkts matched/bytes matched) 8/I??4
Class-map. af·I-traffic (match-all)
?4I40 packets, I09I888 bytes
S minute offered rate I·000 bps, drop rate 0 bps
Match. dscp af·I
Queueing
Output Queue. Conversation I·I
(pkts matched/bytes matched) ?I8/I??·?
exponential weight. 9
mean queue depth. 0
dscp Transmitted Random drop Tail drop
Minimum Maximum Mark pkts/bytes pkts/bytes
pkts/bytes thresh thresh prob
afII 0/0 0/0 0/0
·? 40 I/I0
afI? 0/0 0/0 0/0
?8 40 I/I0
afI· 0/0 0/0 0/0
?4 40 I/I0
af?I 0/0 0/0 0/0
·? 40 I/I0
af?? 0/0 0/0 0/0
?8 40 I/I0
af?· 0/0 0/0 0/0
?4 40 I/I0
af31 24817/1101254 0/0 0/0
32 40 1/10
]output omitted¦
?ISIS packets, I?I8S9? bytes
Match. dscp af?I
Queueing
Bandwidth remaining ?0 (%)
(pkts matched/bytes matched) ·8I/II0·?
mean queue depth. 0
dscp Transmitted Random drop Tail drop
Minimum Maximum Mak
pkts/bytes pkts/bytes pkts/bytes
thresh thresh prob
afII 0/0 0/0 0/0
·? 40 I/I0
afI? 0/0 0/0 0/0
?8 40 I/I0
afI· 0/0 0/0 0/0
?4 40 I/I0
af21 27821/1229416 0/0 0/0
32 40 1/10
af?? 0/0 0/0 0/0
?8 40 I/I0
]output omitted¦
I?·?8 packets, S4·?8S bytes
Match. dscp afII
Queueing
(pkts matched/bytes matched) ?·?/I0?08
mean queue depth. 0
dscp Transmitted Random drop Tail drop Minimum
Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh
thresh prob
afII I?484/S49··I 0/0 0/0 ·?
40 I/I0
afI? 0/0 0/0 0/0 ?8
40 I/I0
afI· 0/0 0/0 0/0 ?4
40 I/I0
af21 0/0 0/0 0/0 32
40 1/10
]output omitted¦
Class-map. cs1~traffic (match-all)
SII4 packets, ?I?·08 bytes
S minute offered rate ·000 bps, drop rate 0 bps
Match. dscp csI
Queueing
Output Queue. Conversation I40
Bandwidth remaining ? (%)
(pkts matched/bytes matched) I0/·080
mean queue depth. 0
Maximum Mark
thresh prob
afII 0/0 0/0 0/0 ·?
40 I/I0
afI? 0/0 0/0 0/0 ?8
40 I/I0
afI· 0/0 0/0 0/0 ?4
40 I/I0
af?I 0/0 0/0 0/0 ·?
40 I/I0
af?? 0/0 0/0 0/0 ?8
40 I/I0
af?· 0/0 0/0 0/0 ?4
40 I/I0
af·I 0/0 0/0 0/0 ·?
40 I/I0
af·? 0/0 0/0 0/0 ?8
40 I/I0
af·· 0/0 0/0 0/0 ?4
40 I/I0
af4I 0/0 0/0 0/0 ·?
40 I/I0
af4? 0/0 0/0 0/0 ?8
40 I/I0
af4· 0/0 0/0 0/0 ?4
40 I/I0
cs1 5822/277060 0/0 0/0 22
40 1/10
]output omitted¦
Class-map. class~default (match-any)
II9·9 packets, ?0884S8 bytes
S minute offered rate 88000 bps, drop rate ?9000 bps
Match. any
Queueing
(pkts matched/bytes matched) I49S0/?S8888?
mean queue depth. 4·
Maximum Mark
thresh prob
]output omitted¦
csS 0/0 0/0 0/0 ·0
40 I/I0
cs6 6/504 0/0 0/0 32
40 1/10
csI 0/0 0/0 0/0 ·4
40 I/I0
ef 0/0 0/0 0/0 ·8
40 I/I0
rsvp 0/0 0/0 0/0 ·8
40 I/I0
default 4872/1481315 254/75741 10434/1136558 20
40 1/10
Do you see any drops Irom any oI the traIIic classes? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
II so, which one or ones?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Note: You may see drops on only one of the workgroup routers due to the varying traffic rate from
the Pagent routers.
How many aI31 packets have been transmitted within the aI31-traIIic class?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
How many cs1 packets have been transmitted within the cs1-traIIic class?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
The class-deIault traIIic class has transmitted packets marked with which DSCP
setting? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
What types oI packets are marked with CS 6 by the Cisco IOS soItware?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 7 Repeat Steps 1 through 7 Ior the WGxR2 router.
The deIault class has many dropped packets in it. Although WRED congestion
avoidance has been applied and is randomly dropping packets in this class, it may be
dropping packets unnecessarily. Ideally, the router should send traIIic without
dropping as the average queue size increases, but allow the end station to signal it to
slow down.
Step 8 Enable WRED ECN Ior the class-deIault traIIic class on the WGxR1 and WGxR2
routers.
Step 9 On WGxR1 and WGxR2, display the llq-policy policy map and veriIy the ECN
settings Ior the class-deIault traIIic class.
<output omitted>
Class class-default
probablity
--------------------------------------------------
--------
afII - - I/I0
afI? - - I/I0
afI· - - I/I0
af?I - - I/I0
af?? - - I/I0
af?· - - I/I0
af·I - - I/I0
af·? - - I/I0
af·· - - I/I0
af4I - - I/I0
af4? - - I/I0
af4· - - I/I0
csI - - I/I0
cs? - - I/I0
cs· - - I/I0
cs4 - - I/I0
csS - - I/I0
cs8 - - I/I0
csI - - I/I0
ef - - I/I0
rsvp - - I/I0
default ?0 40 I/I0
command.
Step 12 Display the output service policy on the serial 0/0 interIace on both WGxR1 and
WGxR2.
Serial0/0
<output omitted>
I·4SI packets, ?·?80·8 bytes
S minute offered rate 88000 bps, drop rate ··000 bps
Match. any
Queueing
(pkts matched/bytes matched) I88II/?8I8499
(depth/total drops/no-buffer drops) 0/II·98/0
mean queue depth. 0
Maximum Mark
thresh prob
afII 0/0 0/0 0/0 ·?
40 I/I0
afI? 0/0 0/0 0/0 ?8
40 I/I0
afI· 0/0 0/0 0/0 ?4
40 I/I0
af?I 0/0 0/0 0/0 ·?
40 I/I0
af?? 0/0 0/0 0/0 ?8
40 I/I0
af?· 0/0 0/0 0/0 ?4
40 I/I0
af·I 0/0 0/0 0/0 ·?
40 I/I0
af·? 0/0 0/0 0/0 ?8
40 I/I0
af·· 0/0 0/0 0/0 ?4
40 I/I0
af4I 0/0 0/0 0/0 ·?
40 I/I0
af4? 0/0 0/0 0/0 ?8
40 I/I0
af4· 0/0 0/0 0/0 ?4
40 I/I0
csI 0/0 0/0 0/0 ??
40 I/I0
cs? 0/0 0/0 0/0 ?4
40 I/I0
cs· 0/0 0/0 0/0 ?8
40 I/I0
cs4 0/0 0/0 0/0 ?8
40 I/I0
csS 0/0 0/0 0/0 ·0
40 I/I0
cs8 I/S88 0/0 0/0 ·?
40 I/I0
csI 0/0 0/0 0/0 ·4
40 I/I0
ef 0/0 0/0 0/0 ·8
40 I/I0
rsvp 0/0 0/0 0/0 ·8
40 I/I0
default S4II/I8?I80· 343/110564 II48?/I?4?888 ?0
40 I/I0
dscp ECN Mark
pkts/bytes
afII 0/0
afI? 0/0
afI· 0/0
af?I 0/0
af?? 0/0
af?· 0/0
af·I 0/0
af·? 0/0
af·· 0/0
af4I 0/0
af4? 0/0
af4· 0/0
csI 0/0
cs? 0/0
cs· 0/0
cs4 0/0
csS 0/0
cs8 0/0
csI 0/0
ef 0/0
rsvp 0/0
default 0/0
Is ECN enabled Ior the class-deIault traIIic class? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
What is the mean queue depth Ior the class-deIault traIIic class? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸
How many ECN marked packets are there Ior the class-deIault traIIic class iI any?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
No packets are marked ECN, yet there are many random WRED drops in the deIault
class. Explain. ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 13 On WGxR1, display the class map Ior the eI-traIIic service class.
Match dscp ef
Step 14 On WGxR1, remove ICMP packets Irom the EF service class by removing the
match access-group 100 Irom the eI-traIIic class map.
Step 15 On WGxR1, display the class map Ior the eI-traIIic service class and veriIy ICMP
(access-group 100) has been removed.
Match dscp ef
Step 16 Which traIIic class will the ICMP traIIic belong to now that it has been removed
Irom the EF service class? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 17 Repeat Steps 13 through 15 Ior WGxR2.
command.
lab. For the extended ping, use a repeat count oI 50, a datagram size oI 1500, and
use extended commands to set the ToS to 0x02.
WGxRI=ping
Protocol ]ip¦.
Target IP address.10.2.x.2
Extended commands ]n¦. y
Source address or interface.
Type of service ]0¦. 0x02
Set DF bit in IP header? ]no¦.
Validate reply data? ]no¦.
Data pattern ]0xABCD¦.
Loose, Strict, Record, Timestamp, Verbose]none¦.
Sending S0, IS00-byte ICMP Echos to I0.?.I.?, timeout is ?
seconds.
.!.!..!!.!.!!.!!.!..!..!!.!!.!.!..!!!.!!...!!..!.!
Success rate is 52 percent (26/50), round~trip min/avg/max =
84/397/802 ms
What does setting the ToS byte to 0x02 achieve? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 20 Display the output service policy on the serial 0/0 interIace Ior the class-deIault
service class only.
Serial0/0
I·80S packets, ?S8I48· bytes
S minute offered rate II000 bps, drop rate ?000 bps
Match. any
Queueing
(pkts matched/bytes matched) I·I88/?S80SIS
(depth/total drops/no-buffer drops) ?/48·/0
mean queue depth: 10
dscp Transmitted Random drop Tail drop Minimum Maximum
Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh
prob
afII 0/0 0/0 0/0 ·? 40
I/I0
afI? 0/0 0/0 0/0 ?8 40
I/I0
afI· 0/0 0/0 0/0 ?4 40
I/I0
af?I 0/0 0/0 0/0 ·? 40
I/I0
af?? 0/0 0/0 0/0 ?8 40
I/I0
af?· 0/0 0/0 0/0 ?4 40
I/I0
af·I 0/0 0/0 0/0 ·? 40
I/I0
af·? 0/0 0/0 0/0 ?8 40
I/I0
af·· 0/0 0/0 0/0 ?4 40
I/I0
af4I 0/0 0/0 0/0 ·? 40
I/I0
af4? 0/0 0/0 0/0 ?8 40
I/I0
af4· 0/0 0/0 0/0 ?4 40
I/I0
csI 0/0 0/0 0/0 ?? 40
I/I0
cs? 0/0 0/0 0/0 ?4 40
I/I0
cs· 0/0 0/0 0/0 ?8 40
I/I0
cs4 0/0 0/0 0/0 ?8 40
I/I0
csS 0/0 0/0 0/0 ·0 40
I/I0
cs8 9/IS8 0/0 0/0 ·? 40
I/I0
csI 0/0 0/0 0/0 ·4 40
I/I0
ef 0/0 0/0 0/0 ·8 40
I/I0
rsvp 0/0 0/0 0/0 ·8 40
I/I0
default I·I4I/?SS8848 308/50344 IIS/?I89I ?0 40
I/I0
dscp ECN Mark
pkts/bytes
afII 0/0
afI? 0/0
afI· 0/0
af?I 0/0
af?? 0/0
af?· 0/0
af·I 0/0
af·? 0/0
af·· 0/0
af4I 0/0
af4? 0/0
af4· 0/0
csI 0/0
cs? 0/0
cs· 0/0
cs4 0/0
csS 0/0
cs8 0/0
csI 0/0
ef 0/0
rsvp 0/0
default 6/9024
Do you see any ECN marked packets Ior the class-deIault now?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Note: You may only see ECN marked packets on one of the two workgroup routers.
Step 21 Return ICMP traIIic (match access-group 100) to the EF service class.
Step 22 Display the class map Ior the eI-traIIic service class and veriIy that ICMP traIIic is
now a member oI the EF service class.
Match dscp ef
You have successIully conIigured DSCP-based CB-WRED on WGxR1 and WGxR2 in all
service classes except Ior the EF service class
You have successIully conIigured WRED with ECN on the deIault class on WGxR1 and
WGxR2
You have successIully veriIied the operation oI DSCP-Based CB-WRED with ECN
Lab Exercise 7-1: Configuring CIass-Based
PoIicing
Exercise Objective
In this exercise, you will conIigure class-based policing to rate limit incoming packets on an
interIace. AIter completing this exercise, you will be able to meet these objectives:
ConIigure class-based policing
Monitor the operation oI class-based policing
VisuaI Objective
Because the wireless Internet access Ior the students and Iaculties have been implemented, you
also noticed that the peer-to-peer Iile sharing traIIic (particularly, Napster and Kazaa) are
constantly increasing. ThereIore, it is now required to police the Napster and Kazaa traIIic
using class-based policing inbound to the Fa0/0 interIace on the workgroup router.
For the Internet connection, most oI the traIIic Irom the E-Commerce University is http (web)
traIIic out to the Internet. The service provider is providing sub-rate access and is implementing
an input service policy to police E-Commerce University inbound traIIic.
Policing oI the http traIIic using class-based policing outbound to the S0/1 interIace on
workgroup router will be implemented to conserve bandwidth on the E-Commerce University
Internet connection.
This http policing policy in not placed inbound to the Fa0/0 interIace on the workgroup router
because intranet http traIIic will still be required to Ilow between the two E-Commerce
University campuses across their 384-kbps lease line connection (S0/0).
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
Configuring CIass-Based PoIicing Lab Commands
Command Description
name
more interfaces
class ¦classname |
class~default¦
police bps (burst
normal) (burstmax)
conform~action action
exceed~action action
(violate~action
action)
To configure traffic policing
class~map classmap
name
specified class
match protocol
protocolname
specified protocol
police cir percent
percent (bc conform
burstinmsec) (pir
percent percent)(be
peakburstinmsec)
To configure traffic policing on the basis of a percentage of
bandwidth available on an interface
show policy~map
(policymap)
show policy~map
interface interface
show policy~map
policymap class
classname
To display the configuration for the specified class of the specified
policy map
mapname)
copy running~config
startup~config
Job Aids
Exercise Procedure
Step 1 ModiIy the existing input service policy mark-nbar on the FastEthernet 0/0
interIace oI the WGxR1 and WGxR2 routers to police the scavenger traIIic class to a
maximum rate limit oI 8 kbps. All conIorming traIIic should be sent (transmitted),
and all exceeding traIIic should be dropped.
In this case, do you need to implement a single or dual token bucket?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Will this be a single- or dual-rate policing implementation?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 2 Display the mark-nbar policy map and veriIy the correct policing conIiguration.
Policy Map mark-nbar
Class real-time
set dscp ef
Class mission-critical
set dscp af·I
Class interactive
set dscp af?I
Class bulk
set dscp afII
Class scavenger
set dscp csI
conform~action transmit
exceed~action drop
What is the deIault value oI Bc in bytes and in bits? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
How is the deIault value oI Bc calculated by the Cisco IOS soItware?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Based on the deIault value oI Bc, what is the value oI Tc? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
command.
Step 5 Display the input service-policy on the FastEthernet 0/0 interIace oI your workgroup
routers Ior the scavenger class only.
FastEthernet0/0
Service-policy input: mark~nbar
Class~map: scavenger (match~any)
4S8I packets, I??I9?8 bytes
S minute offered rate 4I000 bps, drop rate ·S000 bps
Match: protocol kazaa2
IS?9 packets, 8?4944 bytes
S minute rate ??000 bps
Match: protocol napster
·0S8 packets, 80?98? bytes
QoS Set
dscp csI
Packets marked 4II9
police:
cir 8000 bps, bc 1500 bytes
conformed 1350 packets, 83499 bytes; actions:
transmit
exceeded 3369 packets, 1179763 bytes; actions:
drop
conformed 8000 bps, exceed 36000 bps
?0994 packets, ·89?0S· bytes
S minute offered rate I0I000 bps, drop rate 0 bps
Match. any
How many packets have been dropped in the scavenger traIIic class?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
What is the conIormed bit rate Ior the scavenger traIIic?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
What is the exceed bit rate Ior the scavenger traIIic?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 6 On the WGxR1 and WGxR2 routers, conIigure a new class map called web-
outbound and use NBAR to classiIy all HTTP traIIic into that traIIic class.
Step 7 Display the newly conIigured class map and veriIy its conIiguration.
Class Map match-all web-outbound (id I)
Match protocol http
Step 8 On the WGxR1 and WGxR2 routers, conIigure a new policy map called http-police
to police the web (http) traIIic to a CIR oI 50 percent oI the link bandwidth (use the
Cisco IOS soItware deIault Ior Bc and Be). All conIorming traIIic should be
transmitted (sent), and all exceeding traIIic should be remarked to CS1 then
transmitted (sent). All violating traIIic should be dropped.
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 9 Display the newly conIigured policy map and veriIy its conIiguration.
Policy Map http~police
Class web-outbound
police cir percent S0 be 0
exceed-action set-dscp-transmit csI
violate-action drop
Step 10 Apply the http-police policy map to the S0/1 interIace oI the WGxR1 and WGxR2
routers in the outbound direction. The http-police policy map is applied to the S0/1
interIace and not the tunnel interIace (Irom the QoS Pre-ClassiIy lab) because the
tunnel interIace is only used as a backup Ior the leased line connection between the
two E-Commerce University campuses.
Step 11 To test this lab, it will be necessary to administratively disable (shutdown) the S0/0
interIace on the WGxR1 and WGxR2 routers, to Iorce the Pagent http traIIic to Ilow
via the S0/1 link. Administratively disable the serial 0/0 interIace and clear the
interIace counters on both the WGxR1 and WGxR2 routers.
Step 13 Display the outbound service policy on the Serial 0/1 interIace.
Class-map. web~outbound (match-all)
IS4 packets, 409888 bytes
Match: protocol http
police:
cir 50 %
cir 384000 bps, bc 12000 bytes, be 1500 bytes
conformed 664 packets, ··?894 bytes, actions.
transmit
exceeded 40 packets, II9? bytes, actions.
set~dscp~transmit cs1
violated 50 packets, IS?00 bytes, actions.
drop
conformed I4000 bps, exceed 0 bps, violate 4000 bps
I?S· packets, 880IS0 bytes
Match. any
Are there any violating HTTP packets being dropped?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Are there any exceeding HTTP packets being remarked to CS1 then sent?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Are there any conIorming HTTP packets being sent?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Based on a CIR oI 50 percent, what is the CIR (in bps), Bc and Be (in bytes)
computed by the Cisco IOS soItware?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 14 Re-enable the serial 0/0 interIace on both the WGxR1 and WGxR2 routers.
You have correctly conIigured single-rate policing on the FastEthernet 0/0 interIace oI the
You have correctly conIigured percentage-based policing on the Serial 0/1 interIace oI the
You have veriIied the successIul operation oI your class-based policing conIiguration.
Shaping
Exercise Objective
In this exercise, you will conIigure class-based shaping to rate-limit outgoing packets on an
interIace. AIter completing this exercise, you will be able to meet these objectives:
ConIigure class-based shaping
Monitor the operation oI class-based shaping
VisuaI Objective
AIter successIully policing the Napster and Kazaa traIIic, it was decided by the E-Commerce
University IT staII to also shape the FTP traIIic across the 384-kbps lease line since the FTP
traIIic is also consuming a lot oI bandwidth at times. Class-based shaping will be used to apply
an upper bandwidth limit to the FTP traIIic class.
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
Configuring CIass-Based Shaping Lab Commands
Command Description
show policy~map
policymap class
classname
To display the configuration for the specified class of the specified
policy map
name
more interfaces
class ¦classname |
class~default¦
shape ¦average | peak}
cir (bc)(be)
To specify average or peak rate traffic shaping
show policy~map
(policymap)
show policy~map
interface interface
copy running~config
startup~config
Job Aids
Exercise Procedure
Step 1 VeriIy the existing policy map named llq-policy on the WGxR1 and WGxR2
routers, by displaying only the aI11-traIIic class. Recall Irom the classiIication and
marking lab exercise, all FTP traIIic is marked with AF11.
Class af11~traffic
dscp min-threshold max-threshold mark-probablity
----------------------------------------------------------
afII ?8 40 I/I0
afI? - - I/I0
afI· - - I/I0
af?I - - I/I0
af?? - - I/I0
af?· - - I/I0
af·I - - I/I0
af·? - - I/I0
af·· - - I/I0
af4I - - I/I0
af4? - - I/I0
af4· - - I/I0
csI - - I/I0
cs? - - I/I0
cs· - - I/I0
cs4 - - I/I0
csS - - I/I0
cs8 - - I/I0
csI - - I/I0
ef - - I/I0
rsvp - - I/I0
default - - I/I0
Step 2 On WGxR1 and WGxR2, modiIy the existing llq-policy map to shape the aI11-
traIIic class to an average rate oI 8 kbps. Allow the Cisco IOS soItware to
automatically calculate the Bc and Be value.
Step 3 VeriIy the existing llq-policy map and the shaping conIiguration on your workgroup
WGxR1 and WGxR2 routers by displaying only the aI11-traIIic class.
Class af11~traffic
probablity
--------------------------------------------------------
--
afII ?8 40 I/I0
afI? - - I/I0
afI· - - I/I0
]output omitted¦
ef - - I/I0
rsvp - - I/I0
default - - I/I0
Traffic Shaping
Step 4 VeriIy the shaping conIiguration on the existing output service policy map on the
Serail 0/0 interIace oI the WGxR1 and WGxR2 routers, by displaying only the aI11-
traIIic class.
Serial0/0
???9?· packets, I004IISI bytes
Match. dscp afII
Queueing
(pkts matched/bytes matched) I·IS8/8?I8I?
(depth/total drops/no-buffer drops) 0/0/0
mean queue depth. 0
dscp Transmitted Random drop Tail drop Minimum Maximum
Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh
prob
afII ???9?·/I004IISI 0/0 0/0 ?8 40 I/I0
afI? 0/0 0/0 0/0 ?8 40 I/I0
]output omitted¦
default 0/0 0/0 0/0 ?0 40 I/I0
]output omitted¦
Traffic Shaping
Target/Average Byte Sustain Fxcess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
8000/8000 ?000 8000 8000 1000 I000
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 ?88? II8008 0 0 no
What is the Bc and Be value which is automatically determined by the Cisco IOS
soItware?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
What is the committed time window (Tc) (time interval)?
¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
You have successIully conIigures average-rate shaping on the serial 0/0 interIace oI
WGxR1 and WGxR2 Ior the AF11 traIIic class.
You have veriIied the successIul operation oI your class-based shaping conIiguration.
Header Compression
Exercise Objective
In this exercise, you will conIigure and monitor class-based RTP header compression on a
PPP/FR link. AIter completing this exercise, you will be able to meet these objectives:
ConIigure class-based RTP header compression
Monitor the operation oI class-based RTP header compression
VisuaI Objective
One oI the E-Commerce University IT staII was reading a Voice over IP Cisco Press book and
realized that the IP/UDP/RTP header overhead Ior voice packet is very high. ThereIore, the IT
staII has decided to implement class-based RTP header compression to reduce the size oI the
packet headers and the associated overhead on the eI-traIIic class.
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
Configuring CIass-Based Header Compression Lab Commands
Command Description
name
more interfaces
class ¦classname |
class~default¦
compression header ip
(rtp | tcp)
To configure Real-Time Transport Protocol (RTP) or TCP ÌP
header compression for a specific class
show policy~map
(policymap)
show policy~map
interface interface
copy running~config
startup~config
Job Aids
Exercise Procedure
Step 1 ModiIy the existing llq-policy map on the WGxR1 and WGxR2 routers to enable
class-based RTP header compression on the eI-traIIic class.
Step 2 Display the llq-policy map (just display the eI-traIIic class) to veriIy the class-based
RTP header compression conIiguration on the eI-traIIic class.
Class ef~traffic
Strict Priority
compress:
header ip rtp
command.
Step 5 Display the output service policy on the workgroup routers S0/0 interIace (only
show the eI-traIIic class).
Serial0/0
Class~map: ef~traffic (match~any)
325 packets, 8S9·? bytes
Match: dscp ef
Match. access-group I00
0 packets, 0 bytes
S minute rate 0 bps
Queueing
Strict Priority
(pkts matched/bytes matched) S/8·0
compress:
header ip rtp
UDP/RTP compression:
Sent: 324 total, 321 compressed,
12135 bytes saved, 52441 bytes sent
1.23 efficiency improvement factor
99% hit ratio, five minute miss rate 0
misses/sec, 0 max
rate 2000 bps
How many RTP packets were sent? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
How many RTP packets were compressed? ¸¸¸¸¸¸¸¸¸
How many bytes were saved because oI RTP header compression? ¸¸¸¸¸¸¸¸¸¸
You have successIully conIigured class-based RTP header compression on the serial 0/0
interIace oI WGxR1 and WGxR2 Ior the eI-traIIic service class.
You have successIully veriIied the operation oI the class-based RTP header compression
operation.
Lab Exercise 8-2: Configuring LFI
Exercise Objective
In this exercise, you will conIigure and monitor Multilink PPP (MLP) with interleaving on a
PPP link. AIter completing this exercise, you will be able to meet these objectives:
ConIigure link Iragmentation and interleaving on PPP WAN Links
Monitor the operation oI link Iragmentation and interleaving
VisuaI Objective
AIter measuring voice packet delay and jitter over their slow WAN link, the E-Commerce IT
staII is concerned that the jitter is still too high. The IT staII asks you why there is too much
jitter and how it can be reduced. Being well educated by Cisco cell loss priorities (CLPs) in
QoS, you answer, 'The LLQ mechanism prioritized voice traIIic in the soItware queue, but the
hardware queue (Tx ring) always uses a FIFO scheduling mechanism. ThereIore, aIter packets
oI diIIerent applications leave the soItware queue, they will mix with other packets in the
hardware transmit queue (TxQ), even iI their soItware queue processing was expedited. Thus, a
voice packet may be immediately sent to the hardware tx-queue, where two large FTP packets
may still be waiting Ior transmission. The voice packet must wait until the FTP packets are
transmitted, thus producing an unacceptable delay in the voice path. Because links are variably
utilized, this delay varies with time and may produce unacceptable jitter in jitter-sensitive
applications such as voice.¨
Knowing that there will be no budget to upgrade the slow WAN link speed any time soon, you
oIIered to improve voice delay and jitter by implementing MLP with interleaving on the slow
WAN link.
Required Resources
QOS Student Guide
QOS Lab Guide
Command List
Configuring LFI Lab Commands
Command Description
identification
encapsulation
encapsulationtype
(no) ip address ip~
address mask
To set a primary or secondary ÌP address for an interface
bandwidth kbps To set and communicate to higher-level protocols the current
bandwidth value for an interface
interface multilink
multilinkbundle
number
To create a multilink bundle and enter multilink interface
configuration mode
ppp multilink To enable MLP on an interface
ppp multilink
interleave
Enables real-time packet interleaving
ppp multilink
fragment~delay
(Optional) Configures a maximum fragment delay. Ìf, for example,
you want a voice stream to have a maximum bound on delay of 20
ms and you specify 20 ms using this command, MLP will choose a
fragment size based on the configured value.
ppp multilink group
groupnumber
To restrict a physical link to joining only a designated multilink-
group interface
(no) service~policy
¦input | output}
policymapname
To attach a policy map to an input interface or VC, or an output
interface or VC
Job Aids
Exercise Procedure
Caution: The following steps must be performed in the order shown.
Step 1 Remove the IP address Irom the serial 0/0 interIace oI the WGxR1 router.
Step 2 Create a multilink virtual interIace (multilink 1) on the workgroup WGxR1 router.
Step 3 Set the bandwidth and IP address on the workgroup WGxR1 router multilink 1
interIace as Iollows:
Parameter VaIue
ÌP Address 10.2.x.1
Subnet Mask 255.255.255.0
bandwidth 384kbps
Step 4 Place the workgroup WGxR1 router S0/0 interIace into multilink-group 1.
Step 5 Repeat Steps 1 through 4 Ior the workgroup WGxR2 router, using the Iollowing
table Ior Step 3:
Parameter VaIue
ÌP Address 10.2.x.2
Subnet Mask 255.255.255.0
bandwidth 384kbps
Step 6 Display the running-conIig oI the S0/0 and the multilink 1 interIace to veriIy the
MLP conIiguration.
Current configuration . I88 bytes
!
interface Serial0/0
description to wgxrI
bandwidth ·84
no ip address
service-policy output llq-policy
encapsulation ppp
ppp multilink
multilink~group 1
end
Current configuration . II? bytes
!
interface MultilinkI
bandwidth 384
ip address 10.2.x.1 255.255.255.0
ppp multilink
multilink~group 1
end
MLP is enabled now but is Interleaving also enabled based on the above
conIiguration? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 7 Use the show ip interIace brieI command to veriIy that the multilink-group 1
interIace is UP, has the proper IP address and that the S0/0 interIace is UP.
Protocol
FastEthernet0/0 I0.I.I.I YES NVRAM up up
Serial0/0 unassigned YFS manual up up
Serial0/I I0.4.I.I YES NVRAM administratively
downdown
Multilink1 10.2.1.1 YFS manual up up
Step 8 Ping the multilink 1interIace oI WGxR2 Irom WGxR1.
WGxRI>ping I0.?.x.?
Sending S, I00-byte ICMP Echos to I0.?.x.?, timeout is ?
seconds.
!!!!!
4/I/8 ms
Step 9 Ping the multilink 1interIace oI WGxR1 Irom WGxR2.
WGxR?>ping I0.?.x.I
Sending S, I00-byte ICMP Echos to I0.?.x.I, timeout is ?
seconds.
!!!!!
4/I/8 ms
Step 10 Enter the show ip ospf neighbor command to veriIy the OSPF neighbor relationship
is now Iormed over the multilink interIace.
WGxR?=show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
I0.?.I.I 0 FULL/ - 00.00.·0 I0.?.I.I MultilinkI
Step 11 Enable PPP multilink interleaving on the multilink 1 interIace on both WGxR1 and
WGxR2. Use a Iragment-delay oI 10.
What is the unit oI the Iragment delay? ¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸
Step 12 Disable the output service policy on the S0/0 interIace oI the WGxR1 and WGxR2
routers.
Step 13 Enable the llq-policy on the multilink1 interIace in the outbound direction on
WGxR1 and WGxR2.
Note: Ensure that the OSPF neighbor state is established. You can use the show ip ospf
neighbor command to verify this.
command.
Step 16 What type oI queuing is the S0/0 interIace using now? ¸¸¸¸¸¸¸¸¸¸¸¸.
WGxRI=show interface serial0/0
Description. to wgIr?
reliability ?SS/?SS, txload I8/?SS, rxload I8/?SS
Encapsulation PPP, LCP Open, multilink Open, loopback not
set
Last input 00.00.0?, output 00.00.0?, output hang never
Last clearing of "show interface" counters 00.0S.·8
drops. 0
Queueing strategy: weighted fair (suspended, using FIFo)
FIFO output queue 0/40, 0 drops
S minute input rate ?S000 bits/sec, 9 packets/sec
S minute output rate ?S000 bits/sec, S packets/sec
·?I9 packets input, II?40I? bytes, 0 no buffer
abort
I84I packets output, II·?S·4 bytes, 0 underruns
Step 17 Display the multilink interIace and examine how many packets have been
interleaved?
MultilinkI is up, line protocol is up
Internet address is I0.?.x.I/?4
MTU IS00 bytes, BW ·84 Kbit, DLY I00000 usec,
reliability ?SS/?SS, txload I4S/?SS, rxload ·?/?SS
Encapsulation PPP, LCP Open, multilink open
Open. IPCP, loopback not set
DTR is pulsed for ? seconds on reset
Last input 00.00.0I, output never, output hang never
Last clearing of "show interface" counters 00.0I.?4
drops. ?9?I
Output queue.
9I/I000/84/?9?I/3030(size/maxtotal/threshold/drops/interleaves
)
Conversations S/8/I?8 (active/max active/max total)
Reserved Conversations S/S (allocated/max allocated)
Available Bandwidth ·? kilobits/sec
S minute input rate 49000 bits/sec, II? packets/sec
S minute output rate ?I9000 bits/sec, I8· packets/sec
I·8?8 packets input, 808884 bytes, 0 no buffer
abort
?44S8 packets output, ·I4094I bytes, 0 underruns
Step 18 Use the show ppp multilink command to examine the Iragment size in bytes
(calculated by the Cisco IOS soItware based on the Iragment delay oI 10 ms).
WGxRI=show ppp multilink
MultilinkI, bundle name is wgIr?
Bundle up for I8.SS.?4, I8·/?SS load
Receive buffer limit I?I9? bytes, frag timeout I000 ms
0/0 fragments/bytes in reassembly list
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
0x4IC9F received sequence, 0xI·9·8 sent sequence
Member links. I active, 0 inactive (max not set, min not
set)
Se0/0, since 0·.S4.·S, 480 weight, 472 frag size
You have successIully created a MLP interIace on WGxR1 and WGxR2.
You have successIully conIigured link Iragmentation and interleaving (LMI) over the
multilink 1 interIace on WGxR1 and WGxR2.
You have successIully veriIied the operation oI your LFI conIiguration.
Lab Exercise Answer Key
Lab Exercise 2-1: QoS Lab Setup and InitiaIization
When you complete this lab exercise, your router conIiguration will be similar to the Iollowing,
with diIIerences that are speciIic to your pod.
WG1R1
hostname WGIRI
!
enable secret S SISn4//SvbCjudYcBR·yNPJqI.ItT0
!
ip subnet-zero
!
interface FastEthernet0/0
ip address I0.I.I.I ?SS.?SS.?SS.0
duplex auto
speed auto
!
interface Serial0/0
bandwidth ·84
encapsulation ppp
clockrate ·84000
no fair-queue
!
interface Serial0/I
bandwidth I88
ip address I0.4.I.I ?SS.?SS.?SS.0
encapsulation ppp
!
router ospf I
log-adjacency-changes
network I0.0.0.0 0.?SS.?SS.?SS area 0
!
ip http server
ip classless
!
line con 0
line aux 0
line vty 0 4
password cisco
login
!
end
WG1R2
hostname WGIR?
!
enable secret S SIS0IqtSnKIz/sUIIRYMZIurfJPtpI
!
ip subnet-zero
!
ip address I0.·.I.? ?SS.?SS.?SS.0
duplex auto
speed auto
!
interface Serial0/0
bandwidth ·84
ip address I0.?.I.? ?SS.?SS.?SS.0
encapsulation ppp
no fair-queue
!
interface Serial0/I
bandwidth I88
ip address I0.S.I.? ?SS.?SS.?SS.0
encapsulation ppp
!
router ospf I
!
line con 0
line aux 0
line vty 0 4
password cisco
login
!
end
WG1S1
hostname WGISI
!
enable secret S SISYq48SE·tAlJjcYAP9qJpdmr0nu.
!
vlan II
name vlanII
!
vlan ?I
name vlan?I
ip subnet-zero
vtp domain qos
vtp mode transparent
!
switchport trunk allowed vlan II,?I
no ip address
!
switchport access vlan II
no ip address
!
switchport access vlan ?I
no ip address
!
interface VlanI
no ip address
no ip route-cache
shutdown
!
!
line con 0
line vty S IS
!
end
Lab Exercise 2-2: BaseIine QoS Measurement
SampIe WGxR1 to WGxR2 QoS BaseIine ping ResuIts
Extended ping 1 8/8/12 8/43/120
Extended ping 2 8/8/12 16/42/116
Extended ping 3 8/9/16 12/43/112
Extended ping 1 100% 100%
SampIe WGxR1 QoS BaseIine show interfaces ResuIts
Queuing Strategy WFQ (fair queue) WFQ (fair queue)
ReIiabiIity, TxIoad, RxIoad 255, 1, 1 255, 209, 39
TotaI Output Drops 0 1975
Output Queue: size/max totaI 0/1000 61/1000
Output Queue: threshoId/drops 64/0 64/1975
Packets Output 3001 131760
Output)
0/3001 = 0 1975/131760 = 1.5%
Lab Exercise 3-1: Configuring QoS with AutoQoS
Task 1: The Iollowing conIiguration is entered to enable AutoQoS on the WGxR1 and WGxR2
routers:
auto qos voip
permit icmp any any echo
permit icmp any any echo-reply
Task 2: The Iollowing conIiguration is entered to enable AutoQoS on the WGxS1 switch:
interface fastethernet 0/I
auto qos voip trust
Task 3: The Iollowing are the answers to the questions in this lab exercise:
Is the ping maximum response time shorter than beIore AutoQoS was enabled? Explain.
Yes, because ping was moved into the expedited forwarding class with VoIP traffic. The
minimum time may be higher because the traffic generation tools are generating traffic at
different data rates.
Is the drop rate higher or lower or about the same than beIore AutoQoS was enabled? Explain.
The drop rate is about the same because AutoQoS only affects the voice over IP traffic
and not the data traffic. The VoIP traffic load in the lab is minimal compared to the data.
The Iollowing are sample QoS Lab results:
SampIe WGxR1 to WGxR2 AutoQoS ping ResuIts
Packet Size
Without AutoQoS
(From Lab 2-2)
With AutoQoS
(This Lab)
160 bytes
min/avg/max
min/avg/max
Extended ping 1 8/43/120 32/54/88
Extended ping 2 16/42/116 32/53/88
Extended ping 3 12/43/112 32/54/88
SampIe WGxR1 AutoQoS show interfaces ResuIts
Without AutoQoS
(From Lab 2-2)
show interface s0/0
With AutoQoS
(This Lab)
Queuing Strategy WFQ (fair queue) WFQ (fair queue)
ReIiabiIity, TxIoad, RxIoad 255, 209, 39 255, 245, 41
TotaI Output Drops 1975 216
Output Queue: size/max totaI 61/1000 161/1000
Output Queue:
64/1975 64/216/8534
Packets Output 131760 20530
Output)
1975/131760 = 1.5% 216/20530=1.1%
Lab Exercise 4-1: CIassification and Marking Using MQC
access-list I0I permit tcp any any eq ftp
access-list I0I permit tcp any any eq ftp-data
access-list I0? permit tcp any any eq www
class-map match-all match-www
match access-group I0?
class-map match-all match-ftp
policy-map mark-apps
class match-ftp
set dscp afII
class match-www
set dscp default
service-policy input mark-apps
Lab Exercise 4-2: CIassification Using NBAR
WGIRI(config)=int fa 0/0
WGIRI(config-if)=no service-policy input mark-apps
WGIRI(config-if)=ip nbar protocol-discovery
NBAR should have discovered the Iollowing protocols:
HTTP citrix sqlnet
napster netbios FTP
exchange kazaa2 LDAP
RTP Unknown
!
!
class-map match-all bulk
match protocol ftp
match protocol rtp
match protocol icmp
class-map match-all interactive
class-map match-all default
match any
!
class real-time
set dscp ef
set dscp af·I
class interactive
set dscp af?I
class bulk
set dscp afII
class scavenger
set dscp csI
class class-default
set dscp default
!
service-policy input mark-nbar
Lab Exercise 4-3: Configuring QoS Pre-CIassify
WGxR1:
interface Tunnel0
ip unnumbered FastEthernet0/0
qos pre-classify
tunnel destination I0.S.x.?
!
ip route I0.·.x.0 ?SS.?SS.?SS.0 Tunnel0
WGxR2:
interface Tunnel0
qos pre-classify
tunnel destination I0.4.x.I
!
ip route I0.I.x.0 ?SS.?SS.?SS.0 Tunnel0
The Iollowing are the answers to the questions in this lab exercise:
What happens when QoS pre-classiIy is conIigured on the tunnel interIace?
The original packet headers are visible to the tunnel 0 interface and hence useable for
QoS manipulation.
Can WFQ now distinguish between diIIerent application Ilows? Or does WFQ still only see
one Ilow (protocol 47÷GRE)?
Multiple flows are now visible
Lab Exercise 4-4: LAN-Based Packet CIassification and Marking
class-map match-all callgen?
match access-group ?
class-map match-all callgenI
match access-group I
!
!
policy-map mark-callgen
class callgenI
set ip dscp 48
class callgen?
set ip dscp 48
!
!
service-policy input mark-callgen
mls qos trust device cisco-phone
mls qos trust cos
!
access-list I permit I0.I.I.II
access-list ? permit I0.·.I.II
Lab Exercise 5-1: Configuring Basic Queuing
SampIe WGxR1 RTT Measurement Worksheet
Network Situation
Ping 1 RTT
(min/ave/max)
Ping 2 RTT
(min/ave/max)
Ping 3 RTT
(min/ave/max)
Measurement)
8/8/12 8/8/12 8/9/16
8/43/120 16/42/116 12/43/112
32/54/88 32/53/88 32/54/88
Queuing)
28/122/265 44/129/228 28/131/249
Queuing)
12/46/128 16/48/188 12/43/121
Knowing that the S0/0 interIace on WGxR1 is 384 kbps, what will be the deIault queuing
mechanism?
Which queuing method is S0/0 using now aIter WFQ was disabled?
First In First Out (FIFO)
What are some disadvantages oI with using FIFO queuing Ior the voice and mission-critical
traIIic?
Smaller packets can suffer excessive delay and variable delay waiting in a FIFO queue
behind larger data packets. Aggressive flows can also starve fragile flow types like voice
and interactive traffic.
What is the deIault Congestion Discard Threshold (CDT)?
64
What is the deIault number oI maximum conversations on the S0/0 interIace?
128
What is a beneIit oI increasing the maximum conversations?
The probability that two distinct flows will be classified into the same dynamic queue is
reduced.
What is the available bandwidth and how is it calculated?
Available bandwidth in this case is 288 kbps. Available bandwidth is calculated as 75º of
the configured interface bandwidth.
What is the signiIicance oI the weight in these conversations?
Weight is used by WFQ to reduce the finish time of queued packets, making them appear
smaller than they are to WFQ. This results in faster dispatching of lower weighted
packets.
What Iactor(s) can inIluence the weight?
IP Precedence or DSCP Class Selector Markings can influence WFQ weight.
Lab Exercise 5-2: Configuring LLQ
access-list I00 permit icmp any any echo
access-list I00 permit icmp any any echo-reply
class-map match-any ef-traffic
match dscp ef
class-map match-all af?I-traffic
match dscp af?I
class-map match-all af·I-traffic
match dscp af·I
class-map match-all afII-traffic
match dscp afII
class-map match-all csI-traffic
match dscp csI
class-map match-all class-default
match any
!
policy-map llq-policy
class ef-traffic
priority I88
class af·I-traffic
bandwidth remaining percent 40
class af?I-traffic
bandwidth remaining percent ?0
class afII-traffic
bandwidth remaining percent I·
class csI-traffic
bandwidth remaining percent ?
class class-default
bandwidth remaining percent ?S
!
interface Serial0/0
SampIe WGxR1 RTT Measurement Worksheet
Network Situation
Ping 1 RTT
(min/ave/max)
Ping 2 RTT
(min/ave/max)
Ping 3 RTT
(min/ave/max)
8/8/12 8/8/12 8/9/16
8/43/120 16/42/116 12/43/112
32/54/88 32/53/88 32/54/88
Queuing)
28/122/265 44/129/228 28/131/249
Queuing)
12/46/128 16/48/188 12/43/121
LLQ resuIts from this Iab 8/17/72 8/17/56 8/19/77
Comparing all the results, which QoS mechanism provided the best response time Ior VoIP
packets?
Low Latency Queuing (LLQ)
Lab Exercise 5-3: Queuing on CataIyst Switches
wrr-queue bandwidth ·0 I I0 0
wrr-queue cos-map I 0 I ? · 4
wrr-queue cos-map · 8 I
What is the deIault queuing mechanism on the Catalyst 2950 switch?
Priority Queuing
How many output queues per interIace are available Ior the Catalyst 2950?
Four
Which queue has the highest priority?
Queue 4
What type oI queuing is enabled using the Iollowing conIiguration?
WGxSI=show auto qos
Initial configuration applied by AutoQoS.
!
mls qos trust cos
WRR with an Expedite Queue
From the 'wrr-queue bandwidth 20 1 80 0¨ command, why is the weight Ior queue #4 equal to
'0¨?
Setting the weight of queue 4 to 0 configures queue 4 as a strict priority queue, also
known as an expedite queue.
What do the Iollowing commands accomplish?
These commands map frames with CoS values to specific output queues.
Lab Exercise 6-1: Configuring DSCP-Based WRED
ConIiguration through Step 7:
class ef-traffic
priority I88
class af·I-traffic
random~detect dscp af31 34 40 10
class af?I-traffic
class afII-traffic
class csI-traffic
random~detect dscp cs1 22 40 10
class class-default
random~detect dscp 0 20 40 10
Based on the previous WRED proIiles, which traIIic class will start dropping packets Iirst?
Default (BE) class
What does a mark probability oI 1/10 means?
When the average queue size is at the maximum threshold, the router will be dropping
one out of every ten packets.
Why would you not implement WRED Ior the eI-traIIic class?
It is preferred that no packet dropping occurs in the EF traffic class.
What is the deIault exponential weight constant?
9
What types oI packets are marked with CS 6 by the Cisco IOS soItware?
Router control and routing protocol traffic
ConIiguration Ior remainder oI the lab:
class class-default
random~detect ecn
random-detect dscp 0 ?0 40 I0
100%
Average
Queue
Size
Drop
ProbabiIity
20 22 26 30 34 40
Minimum
ThreshoId
Maximum
ThreshoId
Mark
ProbabiIity
10%
100%
Average
Queue
Size
Drop
ProbabiIity
20 22 26 30 34 40
Minimum
ThreshoId
Maximum
ThreshoId
Mark
ProbabiIity
10%
No packets are marked ECN, yet there are many random WRED drops in the deIault class.
Explain.
The router will only set ECN if the transiting packets are marked such that the endpoints
are ECN capable.
Which traIIic class will the ICMP traIIic belong to now that it has been removed Irom the EF
service class?
Default (BE) service class
What does setting the ToS byte to 0x02 achieve?
It enables ECN in the packet by indicating that the endpoint is ECN capable.
Lab Exercise 7-1: Configuring CIass-Based PoIicing
ConIiguration in Step 2:
class real-time
set dscp ef
set dscp af·I
class interactive
set dscp af?I
class bulk
set dscp afII
class scavenger
set dscp csI
police cir 8000
conform~action transmit
exceed~action drop
ConIiguration Ior the remainder oI the lab:
class-map match-all web-outbound
match protocol http
policy-map http-police
class web-outbound
police cir percent S0
violate-action drop
Single Token Bucket
Will this be a single or dual-rate policing implementation?
Single Rate Policing
What is the deIault value oI Bc in bytes and in bits?
1500 bytes or 12,000 bits
How is the deIault value oI Bc calculated by the Cisco IOS soItware?
Cir / 32 or 1500 bytes, whichever is larger
Based on the deIault value oI Bc, what is the value oI Tc?
Tc÷Bc / CIR ÷ 12000/8000 ÷ 1/5s
Dual Token Bucket
Based on a CIR oI 50 percent, what is the CIR (in bps), Bc and Be(in bytes) calculated by the
Cisco IOS soItware?
CIR÷384000 bps, Bc÷12,000 bytes, Be÷1500 bytes
Lab Exercise 7-2: Configuring CIass-Based Shaping
policy~map llq~policy
class ef-traffic
priority I88
class af·I-traffic
random-detect dscp I0 ·4 40 I0
class af?I-traffic
class af11~traffic
random-detect dscp I0 ?8 40 I0
shape average 8000
class csI-traffic
random-detect dscp I0 ?? 40 I0
class class-default
random-detect ecn
What is the Bc and Be value which is automatically determined by the Cisco IOS soItware?
Bc÷8000 bps, Be÷8000 bps
What is the Tc (time interval)?
1 second
Lab Exercise 8-1: Configuring CIass-Based Header Compression
policy~map llq~policy
class ef~traffic
priority I88
compress header ip rtp
class af·I-traffic
class af?I-traffic
class afII-traffic
shape average 8000
class csI-traffic
class class-default
random-detect ecn
Lab Exercise 8-2: Configuring LFI
WGxR1:
bandwidth ·84
ip address I0.?.x.I ?SS.?SS.?SS.0
ppp multilink
multilink-group I
!
interface Serial0/0
bandwidth ·84
no ip address
encapsulation ppp
clockrate ·84000
ppp multilink
multilink-group I
WGxR2:
bandwidth ·84
ip address I0.?.x.? ?SS.?SS.?SS.0
ppp multilink
multilink-group I
!
interface Serial0/0
bandwidth ·84
no ip address
encapsulation ppp
ppp multilink
multilink-group I
What is the unit oI the Iragment delay?
milliseconds (ms)
What type oI queuing is the S0/0 interIace using now?
first-in, first-out (FIFO)
FinaI Workgroup Device Configurations
When you complete all lab exercises in this course, your workgroup devices will have the
Iollowing conIigurations, with diIIerences that are speciIic to your pod.
WG1R1:
hostname WGIRI
!
enable secret S SISn4//SvbCjudYcBR·yNPJqI.ItT0
!
ip subnet-zero
ip cef
!
match protocol ftp
match protocol rtp
match protocol icmp
match protocol http
match dscp ef
match dscp af?I
match dscp af·I
match dscp afII
match dscp csI
match any
class-map match-all match-sw-be
match dscp default
class-map match-all match-sw-ef
match dscp ef
!
class real-time
set dscp ef
set dscp af·I
class interactive
set dscp af?I
class bulk
set dscp afII
class scavenger
set dscp csI
police cir 8000
exceed-action drop
class class-default
set dscp default
class web-outbound
violate-action drop
class match-ftp
set dscp afII
class match-www
set dscp default
policy-map verify-mark
class match-sw-ef
class match-sw-be
class ef-traffic
priority I88
class af·I-traffic
class af?I-traffic
class afII-traffic
shape average 8000
class csI-traffic
class class-default
random-detect ecn
!
bandwidth ·84
ppp multilink
multilink-group I
!
interface Tunnel0
qos pre-classify
tunnel destination I0.S.I.?
!
ip address I0.I.I.I ?SS.?SS.?SS.0
duplex auto
speed auto
!
interface Serial0/0
bandwidth ·84
no ip address
encapsulation ppp
clockrate ·84000
ppp multilink
multilink-group I
!
interface Serial0/I
bandwidth I88
ip address I0.4.I.I ?SS.?SS.?SS.0
service-policy output http-police
encapsulation ppp
!
router ospf I
!
ip http server
ip classless
!
!
!
!
line con 0
line aux 0
line vty 0 4
password cisco
login
!
!
end
WG1R2:
hostname WGIR?
!
enable secret S SIS0IqtSnKIz/sUIIRYMZIurfJPtpI
!
ip subnet-zero
ip cef
!
match protocol ftp
match protocol rtp
match protocol icmp
match protocol http
match dscp ef
match dscp af?I
match dscp af·I
match dscp afII
match dscp csI
match any
class-map match-all match-sw-be
match dscp default
class-map match-all match-sw-ef
match dscp ef
!
class real-time
set dscp ef
set dscp af·I
class interactive
set dscp af?I
class bulk
set dscp afII
class scavenger
set dscp csI
police cir 8000
exceed-action drop
class class-default
set dscp default
class web-outbound
violate-action drop
class match-ftp
set dscp afII
class match-www
set dscp default
policy-map verify-mark
class match-sw-ef
class match-sw-be
class ef-traffic
priority I88
class af·I-traffic
class af?I-traffic
class afII-traffic
shape average 8000
class csI-traffic
class class-default
random-detect ecn
!
bandwidth ·84
ip address I0.?.I.? ?SS.?SS.?SS.0
ppp multilink
multilink-group I
!
interface Tunnel0
qos pre-classify
tunnel destination I0.4.I.I
!
ip address I0.·.I.? ?SS.?SS.?SS.0
duplex auto
speed auto
!
interface Serial0/0
bandwidth ·84
no ip address
encapsulation ppp
ppp multilink
multilink-group I
!
interface Serial0/I
bandwidth I88
ip address I0.S.I.? ?SS.?SS.?SS.0
service-policy output http-police
encapsulation ppp
!
router ospf I
!
ip http server
ip classless
!
!
!
!
line con 0
line aux 0
line vty 0 4
password cisco
login
!
!
end
WG1S1:
hostname WGISI
!
enable secret S SISYq48SE·tAlJjcYAP9qJpdmr0nu.
!
vlan II
name vlanII
!
vlan ?I
name vlan?I
wrr-queue bandwidth ·0 I I0 0
wrr-queue cos-map I 0 I ? · 4
wrr-queue cos-map · 8 I
!
class-map match-all callgen?
match access-group ?
class-map match-all callgenI
match access-group I
!
policy-map mark-callgen
class callgenI
set ip dscp 48
class callgen?
set ip dscp 48
!
ip subnet-zero
vtp domain qos
vtp mode transparent
!
switchport trunk allowed vlan II,?I
no ip address
service-policy input mark-callgen
mls qos trust device cisco-phone
mls qos trust cos
!
switchport access vlan II
no ip address
!
switchport access vlan ?I
no ip address
!
interface VlanI
no ip address
no ip route-cache
shutdown
!
access-list I permit I0.I.I.II
access-list ? permit I0.·.I.II
!
line con 0
line vty S IS
!
end

Implementing Cisco QoS

Uploaded by

Copyright:

Available Formats

Implementing Cisco QoS

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Implementing Cisco QoS

Uploaded by

Copyright:

Available Formats

QoS

Ìmplementing Cisco Quality of

You might also like