End-to-End QoS Network Design

By Tim Szigeti - CCIE No. 9794, Christina Hattingh

Publisher: Cisco Press

Pub Date: November 09, 2004
ISBN: 1-58705-176-1
Pages: 768
Table of
•
Contents
• Index

Best - pract ice QoS designs for prot ect ing voice, video, and crit ical dat a
while m it igat ing net work denial- of- service at t acks

Underst and t he service- level requirem ent s of voice, video, and dat a
applicat ions

Exam ine st rat egic QoS best pract ices, including Scavenger- class
QoS t act ics for DoS/ worm m it igat ion

Learn about QoS t ools and t he various int erdependencies and

caveat s of t hese t ools t hat can im pact design considerat ions

Learn how t o prot ect voice, video, and dat a t raffic using various QoS
m echanism s

Evaluat e design recom m endat ions for prot ect ing voice, video, and
m ult iple classes of dat a while m it igat ing DoS/ worm at t acks for t he
following net work infrast ruct ure archit ect ures: cam pus LAN, privat e
WAN, MPLS VPN, and I PSec VPN

Qualit y of Service ( QoS) has already proven it self as t he enabling

t echnology for t he convergence of voice, video, and dat a net works. As
business needs evolve, so do t he dem ands for QoS. The need t o prot ect
crit ical applicat ions via QoS m echanism s in business net works has
escalat ed over t he past few years, prim arily due t o t he increased
frequency and sophist icat ion of denial- of- service ( DoS) and worm
at t acks.

End- t o- End QoS Net work Design is a det ailed handbook for planning and
deploying QoS solut ions t o address current business needs. This book
goes beyond discussing available QoS t echnologies and considers det ailed
design exam ples t hat illust rat e where, when, and how t o deploy various
QoS feat ures t o provide validat ed and t est ed solut ions for voice, video,
and crit ical dat a over t he LAN, WAN, and VPN.

The book st art s wit h a brief background of net work infrast ruct ure
evolut ion and t he subsequent need for QoS. I t t hen goes on t o cover t he
various QoS feat ures and t ools current ly available and com m ent s on t heir
evolut ion and direct ion. The QoS requirem ent s of voice, int eract ive and
st ream ing video, and m ult iple classes of dat a applicat ions are present ed,
along wit h an overview of t he nat ure and effect s of various t ypes of DoS
and worm at t acks. QoS best - pract ice design principles are int roduced t o
show how QoS m echanism s can be st rat egically deployed end- t o- end t o
address applicat ion requirem ent s while m it igat ing net work at t acks. The
next sect ion focuses on how t hese st rat egic design principles are applied
t o cam pus LAN QoS design. Considerat ions and det ailed design
recom m endat ions specific t o t he access, dist ribut ion, and core layers of
an ent erprise cam pus net work are present ed. Privat e WAN QoS design is
discussed in t he following sect ion, where WAN- specific considerat ions and
det ailed QoS designs are present ed for leased- lines, Fram e Relay, ATM,
ATM- t o- FR Service I nt erworking, and I SDN net works. Branch- specific
designs include Cisco( r) SAFE recom m endat ions for using Net work- Based
Applicat ion Recognit ion ( NBAR) for known- worm ident ificat ion and
policing. The final sect ion covers Layer 3 VPN QoS design- for bot h MPLS
and I PSec VPNs. As businesses are m igrat ing t o VPNs t o m eet t heir wide-
area net working needs at lower cost s, considerat ions specific t o t hese
t opologies are required t o be reflect ed in t heir cust om er- edge QoS
designs. MPLS VPN QoS design is exam ined from bot h t he ent erprise and
service provider's perspect ives. Addit ionally, I PSec VPN QoS designs
cover sit e- t o- sit e and t eleworker cont ext s.

Whet her you are looking for an int roduct ion t o QoS principles and
pract ices or a QoS planning and deploym ent guide, t his book provides
you wit h t he expert advice you need t o design and im plem ent
com prehensive QoS solut ions.

This book is part of t he Net working Technology Series from Cisco Press,
which offers net working professionals valuable inform at ion for
const ruct ing efficient net works, underst anding new t echnologies, and
building successful careers.
 End-to-End QoS Network Design
By Tim Szigeti - CCIE No. 9794, Christina Hattingh

Publisher: Cisco Press

Pub Date: November 09, 2004
ISBN: 1-58705-176-1
Pages: 768
Table of
•
Contents
• Index

Copyright
About the Authors
About the Technical Editors
Acknowledgments
Icons Used in This Book
Command Syntax Conventions
Introduction
Who Should Read This Book?
Goals and Methods
How This Book Is Organized
Part I: Introduction to QoS
Chapter 1. Introduction to QoS
A Brief Historical Perspective
QoS Evolution
User Network Expectations
Understanding QoS
QoS Models
Introduction to the QoS Toolset
Simplifying QoS
If I Have AutoQoS, Why Should I Be Reading This Book?
The Continuing Evolution of QoS
Summary
Further Reading
Chapter 2. QoS Design Overview
QoS Requirements of VoIP
QoS Requirements of Video
QoS Requirements of Data
QoS Requirements of the Control Plane
Scavenger Class
DoS and Worm Mitigation Strategy Through Scavenger Class QoS
Principles of QoS Design
Summary
Further Reading
Part II: QoS Toolset
Chapter 3. Classification and Marking Tools
Classification Tools
Marking Tools
Summary
Further Reading
Chapter 4. Policing and Shaping Tools
Token Bucket Algorithms
Policers
Shapers
Further Reading
Chapter 5. Congestion-Management Tools
Understanding Scheduling and Queuing
Legacy Layer 3 Queuing Mechanisms
Currently Recommended Layer 3 Queuing Mechanisms
Layer 2 Queuing Tools
Tx-ring
PAK_priority
Summary
Further Reading
Chapter 6. Congestion-Avoidance Tools
Random Early Detection
Weighted Random Early Detection
DSCP-Based Weighted Random Early Detection
Explicit Congestion Notification
Summary
Further Reading
Chapter 7. Link-Specific Tools
Header-Compression Techniques
Link Fragmentation and Interleaving
Summary
Further Reading
Chapter 8. Bandwidth Reservation
RSVP Overview
MPLS Traffic Engineering
Scalability
RSVP-DiffServ Integration
Endpoints and Proxies
Summary
Further Reading
Chapter 9. Call Admission Control (CAC)
CAC Overview
CAC Defined
CAC Tool Categories
CallManager Locations CAC
Gatekeeper CAC
RSVP
Summary
Further Reading
Chapter 10. Catalyst QoS Tools
Generic Catalyst QoS Models
Catalyst 2950
 Catalyst 3550
Catalyst 2970, 3650, and 3750
Catalyst 4500
Catalyst 6500
Summary
Further Reading
Chapter 11. WLAN QoS Tools
QoS for Wireless LANs Versus QoS on Wired LANs
Upstream Versus Downstream QoS
IEEE 802.11 DCF
IEEE 802.11e EDCF
IEEE 802.1D Classes of Service
QoS Operation on Cisco APs
Configuring QoS on Cisco APs
Summary
Further Reading
Part III: LAN QoS Design
Chapter 12. Campus QoS Design
DoS/Worm-Mitigation Strategies
Call-Signaling TCP/UDP Ports in Use
Access-Edge Trust Models
Catalyst 2950 QoS Considerations and Design
Catalyst 3550 QoS Considerations and Design
Catalyst 2970/3560/3750 QoS Considerations and Design
Catalyst 4500-SupII+/III/IV/V QoS Considerations and Design
Catalyst 6500 QoS Considerations and Design
WAN Aggregator/Branch Router Handoff Considerations
Case Study: Campus QoS Design
Summary
Further Reading
Part IV: WAN QoS Design
Chapter 13. WAN Aggregator QoS Design
Where Is QoS Needed over the WAN?
WAN Edge QoS Design Considerations
WAN Edge Classification and Provisioning Models
WAN Edge Link-Specific QoS Design
Case Study: WAN Aggregation Router QoS Design
Summary
Further Reading
Chapter 14. Branch Router QoS Design
Branch WAN Edge QoS Design
Branch Router LAN Edge QoS Design
Case Study: Branch Router QoS Design
Summary
Further Reading
Part V: VPN QoS Design
Chapter 15. MPLS VPN QoS Design
Where Is QoS Needed over an MPLS VPN?
Customer Edge QoS Design Considerations
Provider-Edge QoS Considerations
 Core QoS Considerations
Case Study: MPLS VPN QoS Design (CE/PE/P Routers)
Summary
Further Reading
Chapter 16. IPSec VPN QoS Design
Site-to-Site V3PN QoS Considerations
Site-to-Site V3PN QoS Designs
Headend VPN Edge QoS Options for Site-to-Site V3PNs
Teleworker V3PN QoS Considerations
Teleworker V3PN QoS Designs
Case Study: IPSec VPN QoS Design
Summary
Further Reading
QoS "At-A-Glance" Summaries
Index
Copyright
En d- t o- En d QoS N e t w or k D e sign

Tim Sziget i, CCI E No. 9794, Christ ina Hat t ingh

Copyright © 2005 Cisco Syst em s, I nc.
Published by:
Cisco Pr ess
800 East 96t h St reet
I ndianapolis, I N 46240 USA

All right s reserved. No part of t his book m ay be reproduced or t ransm it t ed in any form or by any
m eans, elect ronic or m echanical, including phot ocopying, recording, or by any inform at ion
st orage and ret rieval syst em , wit hout writ t en perm ission from t he publisher, except for t he
inclusion of brief quot at ions in a review.

Print ed in t he Unit ed St at es of Am erica 1 2 3 4 5 6 7 8 9 0

First Print ing Oct ober 2004

Library of Congress Cat aloging- in- Publicat ion Num ber: 2003111984

Tr a de m a r k Ack n ow le dgm e n t s

All t erm s m ent ioned in t his book t hat are known t o be t radem arks or service m arks have been
appropriat ely capit alized. Cisco Press or Cisco Syst em s, I nc., cannot at t est t o t he accuracy of
t his inform at ion. Use of a t erm in t his book should not be regarded as affect ing t he validit y of
any t radem ark or service m ark.

W a r n in g a n d D iscla im e r

This book is designed t o provide inform at ion about Qualit y- of- Service net work design best -
pract ice recom m endat ions. Every effort has been m ade t o m ake t his book as com plet e and as
accurat e as possible, but no warrant y or fit ness is im plied.

The inform at ion is provided on an " as is" basis. The aut hors, Cisco Press, and Cisco Syst em s,
I nc., shall have neit her liabilit y nor responsibilit y t o any person or ent it y wit h respect t o any loss
or dam ages arising from t he inform at ion cont ained in t his book or from t he use of t he discs or
program s t hat m ay accom pany it .

The opinions expressed in t his book belong t o t he aut hor and are not necessarily t hose of Cisco
Syst em s, I nc.

Cor por a t e a n d Gove r n m e n t Sa le s

Cisco Press offers excellent discount s on t his book when ordered in quant it y for bulk purchases
or special sales.

For m ore inform at ion please cont act : U.S. Cor por a t e a n d Gove r n m e n t Sa le s 1- 800- 382- 3419
corpsales@pearsont echgroup.com
For sales out side t he U.S. please cont act : I n t e r n a t ion a l Sa le s int ernat ional@pearsoned.com

Fe e dba ck I n for m a t ion

At Cisco Press, our goal is t o creat e in- dept h t echnical books of t he highest qualit y and value.
Each book is craft ed wit h care and precision, undergoing rigorous developm ent t hat involves t he
unique expert ise of m em bers from t he professional t echnical com m unit y.

Readers' feedback is a nat ural cont inuat ion of t his process. I f you have any com m ent s regarding
how we could im prove t he qualit y of t his book or ot herwise alt er it t o bet t er suit your needs, you
can cont act us t hrough e- m ail at feedback@ciscopress.com . Please m ake sure t o include t he
book t it le and I SBN in your m essage.

We great ly appreciat e your assist ance.

Publisher John Wait

Edit or- in- Chief John Kane

Cisco Represent at ive Ant hony Wolfenden

Cisco Press Program Nannet t e M. Noble

Manager

Execut ive Edit or Christ opher Cleveland

Acquisit ions Edit or Michelle Grandin

Product ion Manager Pat rick Kanouse

Developm ent Edit or Howard A. Jones

Copy Edit or Krist a Hansing

Technical Edit ors Frank Knox

Anna To

Connie Varner

Team Coordinat or Tam m i Barnet t

Cover Designer Louisa Adair

Com posit ion Oct al Publishing, I nc.

I ndexer Eric Schroeder

Pr oofr eader Tonya Cupp

Cor por a t e H e a dqu a r t e r s

Cisco Syst em s, I nc.
170 West Tasm an Drive
San Jose, CA 95134- 1706
USA
w w w .cisco.com
Tel: 408 526- 4000
800 553- NETS ( 6387)
Fax: 408 526- 4100

Eu r ope a n H e a dqu a r t e r s
Cisco Syst em s I nt ernat ional BV
Haarlerbergpark
Haarlerbergw eg 13- 19
1101 CH Am st erdam
The Net herlands
www- europe.cisco.com
Tel: 31 0 20 357 1000
Fax: 31 0 20 357 1100

Am e r ica s H e a dqu a r t e r s
Cisco Syst em s, I nc.
170 West Tasm an Drive
San Jose, CA 95134- 1706
USA
w w w .cisco.com
Tel: 408 526- 7660
Fax: 408 527- 0883

Asia Pa cific H e a dqu a r t e r s

Cisco Syst em s, I nc.
Capit al Tow er
168 Robinson Road
# 22- 01 t o # 29- 01
Singapore 068912
w w w .cisco.com
Tel: + 65 6317 7777
Fax: + 65 6317 7799

Cisco Syst em s has m ore t han 200 offices in t he following count ries and regions. Addresses,
phone num bers, and fax num bers are list ed on t he Cisco.com W e b sit e a t
w w w .cisco.com / go/ office s.

Argent ina • Aust ralia • Aust ria • Belgium • Brazil• Bulgaria • Canada • Chile • China PRC • Colom bia
• Cost a Rica • Croat ia •
Czech Republic • Denm ark • Dubai, UAE • Finland • rance F • Germ any • Greece • Hong Kong SAR • Hungary • I ndia •
I ndonesia • I reland • I srael • I t aly • Japan • Kore
a • Luxem bourg • Malaysia • Mexico • The Net herland
s • New Zealand •
Norway • Peru • Philippines • Poland • Port ugal •uert P o Rico • Rom ania • Russia • Saudi Arabia • Scot
land • Singapore •
Slovakia • Slovenia • Sout h Africa • Spain • Sweden • Swit zerland • Taiwan • Thailand • Turkey • Ukrai
ne • Unit ed Kingdom •
Unit ed St at es • Venezuela • Viet nam • Zim babwe

Copyright © 2003 Cisco Syst em s, I nc. All right s reserved. COP, CCSP, t he Cisco Arrow logo, t he
Cisco Powered Net work m ark, t he Cisco Syst em s Verified logo, Cisco Unit y, Follow Me Browsing,
Form Share, iQ Net Readiness Scorecard, Net working Academ y, and Script Share are t radem arks
of Cisco Syst em s, I nc.; Changing t he Way We Work, Live, Play, and Learn, The Fast est Way t o
I ncrease Your I nt ernet Quot ient , and iQuick St udy are service m arks of Cisco Syst em s, I nc.; and
Aironet , ASI ST, BPX, Cat alyst , CCDA, CCDP, CCI E, CCNA, CCNP, Cisco, t he Cisco Cert ified
I nt ernet work Expert logo, Cisco I OS, t he Cisco I OS logo, Cisco Press, Cisco Syst em s, Cisco
Syst em s Capit al, t he Cisco Syst em s logo, Em powering t he I nt ernet Generat ion,
Ent erprise/ Solver, Et herChannel, Et herSwit ch, Fast St ep, GigaSt ack, I nt ernet Quot ient , I OS,
I P/ TV, iQ Expert ise, t he iQ logo, Light St ream , MGX, MI CA, t he Net workers logo, Net work
Regist rar, Packet , PK, Post - Rout ing, Pre- Rout ing, Rat eMUX, Regist rar SlideCast , SMARTnet ,
St rat aView Plus, St rat m , Swit chProbe, TeleRout er, TransPat h, and VCO are regist ered
t radem arks of Cisco Syst em s, I nc. and/ or it s affiliat es in t he U.S. and cert ain ot her count ries.

All ot her t radem arks m ent ioned in t his docum ent or Web sit e are t he propert y of t heir respect ive
owners. The use of t he word part ner does not im ply a part nership relat ionship bet ween Cisco
and any ot her com pany. ( 0303R)

Print ed in t he USA

Dedications
Tim : This book is obviously dedicat ed t o m y wife; ot herwise, of course, she'd kill m e. I t am uses
m e t o t hink t hat if ot hers are act ually reading t his, t hey probably t hink I 'm only j okingbut , alas,
t he Greek capacit y for vengeance is no laughing m at t er. I cancelled far t oo m any dat es, st ayed
in m y office and labs far t oo m any weekends, and st ared blankly int o space ( t hinking about
t hese designs) far t oo m any t im es ( while she was t alking t o m e) t o ever allow t he t hought of not
dedicat ing t his work t o her t o even cross m y t iny xeno- brain.

I know, I know, it 's not a work of lit erat ure or a collect ion of poet ry: I t 's j ust a t echnical
bookboring t o t ears for any not int erest ed in t he subj ect ( and probably j ust boring t o yawns for
t he rest ) . But , for what ever it 's wort h, I 'm dedicat ing it t o you, Lella. I love you wit h all m y
heart .

Ch r ist in a : To Robert Verkroost and Ria and Willie Hat t ingh, who unfailingly support m y various
forays int o t he publishing world.
About the Authors
Tim Szige t i, CCI E N o. 9 7 9 4 , at t ended t he Universit y of Brit ish Colum bia, where he m aj ored in
m anagem ent inform at ion syst em s. Aft er graduat ing, Tim j oined Cisco Syst em s and soon aft er
began t o specialize in Qualit y- of- Service t echnologies, support ing t echnical m arket ing init iat ives
for t he Cisco Class Dat a acquisit ion, which led t o t he Cisco QoS Policy Manager ( QPM) product .
Aft er support ing QPM t hrough several generat ions and serving as product m anager for t he Cisco
Qualit y of Service Device Manager ( QDM) product , Tim j oined t he Ent erprise Solut ions
Engineering t eam and led large- scale t est ing init iat ives of cam pus, WAN, and VPN QoS designs.
Tim now belongs t o t he newly form ed Technology Solut ions Engineering t eam wit hin t he Cisco
Cent ral Technical Market ing organizat ion. There, he cont inues t o define and drive st rat egic QoS
solut ions across Cisco t echnology groups and business unit s while working wit h m any Fort une
500 com paniesbot h ent erprise and service providersproviding QoS design expert ise.

Ch r ist in a H a t t in gh is a m em ber of t he t echnical st aff in t he Mult iservice Cust om er Edge

Business Unit of Cisco Syst em s. These product s, including t he Cisco 2600, 3600, and 3700
series access rout er plat form s, were som e of t he first Cisco plat form s t o converge voice and dat a
t raffic ont o an I P net work by offering TDM voice int erfaces, WAN int erfaces, and crit ical QoS
feat ures, while lat er int egrat ing call cont rol elem ent s int o t he rout er- based plat form it self. I n t his
role, she t rains Cisco sales st aff and advises cust om ers on voice net work deploym ent and
design.
About the Technical Editors
Fr a n k Kn ox has m ore t han 37 years of t elecom m unicat ions experience. During his career at
I BM, Frank held posit ions in field service, field support , service planning, and educat ion; his final
posit ion before ret irem ent was curriculum m anager for I BM's Net work Educat ion in Nort h
Am erica. Aft er leaving I BM, Frank held t he posit ion of net work engineering m anager for GTE
Direct ories, where he was responsible for t he com pany's voice and dat a net work design and
support . Concurrent wit h his work at I BM and GTE, Frank t aught as an adj unct professor for t he
Universit y of Dallas MBA program . For t he past six years, Frank has worked for Skyline
Com put er as a senior inst ruct or and consult ant ; he is current ly Skyline's chief t echnical officer
( CTO) . Frank holds t wo CCI E cert ificat ions ( R&S and SNA/ I P) ; he also has a m ast er's degree in
t elecom m unicat ions from Pace Universit y.

An n a To has worked wit h Cisco for m ore t han t hree years as a soft ware/ deploym ent engineer
on t he I TD QoS t eam . One of Anna's key t asks is t o prom ot e QoS deploym ent and increase t he
underst anding of QoS t echnology in t he field. Anna works on t he Modular QoS CLI ( MQC)
solut ion t eam t o bring consist ency in QoS configurat ion across various Cisco plat form s. I n
addit ion, Anna is involved wit h t he Aut oQoS proj ect t o sim plify QoS deploym ent .

Con n ie Va r n e r is a t echnical m arket ing engineer in t he Cisco Ent erprise Syst em s Engineering
group. She has ext ensive experience designing and t est ing large- scale net works based on
cust om er requirem ent s, in part based on four years of experience wit h t he Cisco Cust om er Proof
of Concept Labs. Connie specializes in QoS designs t hat m eet t he needs of converged dat a, voice
and video net works, and designs t hat involve I PSec VPNs.
Acknowledgments
Off t he t op, I 'd like t o t hank m y friend and co- worker Dave Bart on, whoalt hough he was
ext rem ely busy downing beers at Chicago's Navy Piergallant ly m anaged t o sic Bret t Bart ow ont o
m e, which got t he ball rolling on t his whole proj ect . ( Dave, did you m ake it back okay t o t he
hot el t hat night ?)

Many t hanks t o Todd Truit t , one of t he t op t alent s at Cisco, for invit ing m y collaborat ion on t he
original AVVI D QoS Design Guide, hiring m e ont o his design t eam , and recom m ending Christ ina
as a co- aut hor for t his proj ect . Do you ever get t ired of being right , Todd?

Thanks also t o Neil Anderson, Joel King, Ted Hannock, and St eve Ochm anski for guidance and
collaborat ion on I PSec V3PN designs. Thanks for let t ing m e leverage your excellent and t horough
work so t hat I did not t o have t o reinvent t he wheel on t hese designs.

Thank you, Mike Herbert , for your brilliant flash of using QoS for DoS/ worm m it igat ion via t he
Scavenger class. Though you derailed and post poned m any whit epapers and publicat ions
( including t his one) , you opened up a whole new scope of applicat ion for QoS t echnologiesand
we're all bet t er off for it .

Thank you, t oo, Alex Dolan, for building out m ult iple large- scale MPLS VPN t est beds for m e and
cont inually t weaking t hem t o suit m y m ood- of- t he- day. I don't know where your pat ience or
your good nat ure com es from , but t hey're m ost appreciat ed. Thanks, t oo, for nudging m e back
int o playing ice hockey. Next t im e I break a leg or chip a t oot h, I 'll t hink of you and grim ace.

Muchos gracias, Arlindo Callej as, for being m uch m ore t han m y awesom e lab adm inist rat or. You
always went out of your way for m e and got m e everyt hing I ever neededinst ant ly. Som et im es
I 'm afraid t o ask where you sourced t he gear you did. ( I 'm not sure whet her t hose 10GE
linecards " fell off t he back of a Cisco t ruck" or what , but t hey sure cam e in handy at j ust t he
right t im e.)

A round of applause is m erit ed by t he t echnical reviewers. Having done t his before m yself, I can
genuinely appreciat e t he t im e, effort , and painst aking at t ent ion t o det ail t hat goes int o t his
process. Frank, your com m ent s were right on and helped m ake t his a bet t er book. Anna, is t here
anyt hing you don't know about Cisco QoS? I 'm very t hankful you t ook t im e out of your
ext rem ely busy schedule, developing code while helping anyone and everyone on planet Eart h
( and som e nearby syst em s) t hat are having QoS problem s. And Connie, if you hadn't reviewed
t his work, I would not have subm it t ed it for publicat ion. You're sim ply t he best t echnical
reviewerand one of t he sharpest engineersI 've ever had t he pleasure of working wit h.

Thank you Howard Jones for your excellent edit ing and coordinat ing t he com plex cont ent review
and copy review processes. And t hank you, t oo, Pat rick Kanouse for m anaging t he product ion of
t his publicat ion and allowing m e t o m ake hundreds of last - m inut e edit s in t he galley- review
phase ( when edit s are t o be kept at a m inim um ) . How you put up wit h m e I 'll never know, but I
t ruly appreciat e your pat ience and desire t o help m ake t his book as correct and as current as
possible. Also t hank you Chris Cleveland for your fine recom m endat ions and guidance during t he
course of product ion.

I need t o ext end t hanks also t o Debbie Morrison, who is, in m y opinion, t he best t echnical
writ erperiod. Debbie, as I 've said over and over again, you polish m y ugly lit t le chunks of coal
int o beaut iful diam onds. I love how I can barely recognize m y own work once you've done your
m agic. I 'll t ruly m iss working wit h you now t hat you've gone on t o bigger and bet t er t hings. ( I 'm
so t errified of t he fut urewho's going t o m ake m e look good now?)

Bret t Bart ow, what can I say? This would never have happened wit hout you. Tim e and t im e
again, it seem ed t o fall by t he wayside, but your persist ence, perseverance, and pat ience kept it
all going. Thank you. You didn't back off, and I 'm glad for it . Your guidance has been uncanny,
and your vision has paid off. Thanks also t o your product ion t eam .

And last ly, t hank you, Christ ina. You m ade it fun. Right when I read your first draft of your first
chapt er, I knew you were t he best person t o em bark on t his proj ect wit h ( even t hough you writ e
like an engineer! ) . Thank you for sacrificing so m any weekends on t his ( t hank Robert for m e
t oo) . I know t his is only one of m any publishing proj ect s you're pursuing; all I ask is t hat you
save m e an aut ograph before you m ove t o Hawaii and st art on your best - seller!
Icons Used in This Book
Command Syntax Conventions
The convent ions used t o present com m and synt ax in t his book are t he sam e convent ions used in
t he Cisco I OS Com m and Reference. The Com m and Reference describes t hese convent ions as
follows:

Boldfa ce indicat es com m ands and keywords t hat are ent ered lit erally as shown. I n act ual
configurat ion exam ples and out put ( not general com m and synt ax) , boldface indicat es
com m ands t hat are input m anually by t he user ( such as a sh ow com m and) .

I t alics indicat es argum ent s for which you supply act ual values.

Vert ical bars ( | ) separat e alt ernat ive, m ut ually exclusive elem ent s.

Square bracket s [ ] indicat e opt ional elem ent s.

Braces { } indicat e a required choice.

Braces wit hin bracket s [ { } ] indicat e a required choice wit hin an opt ional elem ent .
Introduction
QoS is a m at uring t echnology, one t hat m any net working professionals, t o a great er or lesser
ext ent , are already fam iliar wit h. This is bot h a blessing and a curse. I t is a blessing because
m ore adm inist rat ors are enabling QoS on t heir net works, which allows for t he convergence of
voice, video, and dat a ont o a single I P net work, am ong ot her business advant ages. I t is a curse
because alm ost every individual wit h whom I 've ever discussed QoS designs has a slight ly
different opinion on how QoS should be enabled.

The result oft en has led t o confusing babble from t he cust om er's perspect ive, especially for
cust om ers seeking QoS design guidance for non- VoI P applicat ions. For exam ple, a cust om er
m ight ask t he local Cisco Syst em s engineer how best t o enable QoS for net works and receive
one answer. Lat er, t he cust om er m ight at t end an Execut ive Briefing session in San Jose and
receive a different answer ( even receiving m ult iple different answers wit hin t he sam e day from
different present ers) . Lat er, while at t ending a Net workers conference, t he cust om er m ight be
t old som et hing else ent irely. Finally, when t he cust om er get s hom e and picks up a Cisco Press
book, he or she m ight get st ill anot her st ory. Confused and frust rat ed, m any cust om ers decide
t o enable m inim al QoS, if any, despit e t he t out ed benefit s t hat t hey were sold on. Therefore, in
m y opinion, present ing such inconsist ent recom m endat ions is a m aj or disservice t o our
cust om ers and a considerable barrier t o t he widespread deploym ent of QoS.

The Cisco Technology Baseline com m it t ees were creat ed t o rem edy t he sit uat ion and help unify
various t echnologies across Cisco product s and plat form s. To t his end, a series of Technology
Baselines were developed int ernally by our leading expert s ( m any of whom likewise developed
t he relat ed I ETF RFCs and ot her st andards) t o which all Cisco product s and feat ures m ust
conform . Addit ionally, t hese docum ent s provide uniform , st rat egic recom m endat ions ( t hat can
be shared wit h cust om ers) t o help ensure t hat QoS recom m endat ions are unified and consist ent ,
for bot h ent erprises and service providers. Specific t o QoS, t he QoS Baseline st rict ly defines t he
Cisco st rat egic direct ion in QoS t echnologies from now int o t he foreseeable fut ure.

Thus, a unique feat ure of t his book is t hat it is t he first Cisco Press publicat ion t o present design
recom m endat ions t hat are com pliant wit h t he QoS Baseline.

Anot her huge advant age of t his publicat ion is t hat it is one of t he first docum ent s t o present a
det ailed, cohesive st rat egy t hat shows how QoS can ext end beyond it s t radit ional role ( of
priorit izing im port ant applicat ions) and be used t o provide deferent ial services t o DoS/ worm -
generat ed t raffic, t hus m it igat ing and cont aining t he collat eral dam age caused by such at t acks.
This is a fresh perspect ive and cont ext for a t echnology t hat m any considered baked and done.
Yet in such a role, t he crit ical int erdependency of Qualit y of Service, High- Availabilit y, and
Securit y t echnologies becom es m anifest and holist ically prom ot es t he " Self- Defending Net works"
business obj ect ive.

However, having a st rat egic direct ion and t act ical approaches for QoS designs is only half t he
solut ion. An im port ant m ot t o t hat I like t o em phasize is: " I n t heory, t heory and pract ice are t he
sam e." I t 's one t hing t o m ake a design recom m endat ion based on an assum pt ion t hat som et hing
" should work." I t 's som et hing com plet ely different t o m ake a design recom m endat ion t hat has
been verified in large- scale, com plex lab scenarios, such as provided by one of t he largest Cisco
labs: t he Ent erprise Solut ions Engineering t est beds in Research Triangle Park, Nort h Carolina.

Not wit hst anding, it should be not ed t hat designs present ed in t his book are not infallible. While
all due diligence has been done t o present working, t est ed configurat ionsincluding a rigorous
t echnical reviewing process by som e of t he sharpest Cisco QoS
engineershardware/ soft ware/ plat form - specific issues t hat didn't surface during our t est s m ay
nonet heless exist , as m ay issues int roduced in newer releases of hardware/ soft ware dat ing from
our t im e of t est ing.

Furt herm ore, t he recom m endat ions present ed in t his book are not t o be t aken as
com m andm ent s or dict at es ( " Thou shalt configure t his or t hat " ) , but are sim ply best - pract ice
design recom m endat ions t hat are t he result of ext ensive lab t est ing and cust om er deploym ent s.
They should be viewed as t em plat es t hat can be m odified and t weaked t o cust om er- specific
requirem ent s. Following t he 80/ 20 Paret o Rule, t hese design recom m endat ions should be viewed
as 80 percent of t he solut ion, t o which t he rem aining 20 percent is up t o each cust om er t o
com plet e and t ailor t o t heir individual needs and const raint s.

Here's an analogy of how t o view t hese design recom m endat ions: Given a business obj ect ive
( for exam ple, t o ham m er a nail int o a wall) , you will have cert ain t ools at your disposalt ools t hat
m ay or m ay not be opt im ally suit ed t o t he t ask ( let 's say, a ham m er and a banana) . Our lab
t est ing present s t he opt im al t ool t o use for t he given obj ect ive ( norm ally, a ham m er t est s bet t er
t han a banana, but you never knowI 've seen som e pret t y funky frozen bananas t hat m ight do
t he t rick) . I t 's st ill up t o t he cust om er t o pick t he t ool t hat best suit s t heir obj ect ives, sit uat ions,
and com fort levels. These recom m endat ions are not m andat es; t hey are sim ply suggest ions
based on ext ensive lab t est ing and cust om er deploym ent s.
Who Should Read This Book?
Som e m ight ask, " Why should I read t his book? Especially when I have Aut oQoS?"

Cert ainly, Aut oQoS- VoI P is an excellent t ool for cust om ers whose obj ect ive is enabling QoS for
VoI P ( only) on t heir cam pus and WAN infrast ruct ures, and Aut oQoS- Ent erprise is a fine t ool for
enabling basic WAN- edge QoS for voice, video, and m ult iple classes of dat a. For cust om ers who
have basic QoS needs and don't have t he t im e or desire t o learn or do m ore wit h QoS, Aut oQoS
is definit ely t he way t o go.

However, it 's im port ant t o rem em ber where Aut oQoS cam e from . Aut oQoS t ools are t he result of
QoS design guides t hat Cisco Technical Market ing Engineers ( including m yself) put t oget her
based on large- scale lab t est ing. Aut oQoS- VoI P is t he product of our first " AVVI D QoS Design
Guide," one of t he m ost popular and m ost downloaded t echnical whit epapers ever produced
wit hin Cisco. Aut oQoS- Ent erprise is t he result of t he QoS Baseline coupled wit h our second-
generat ion QoS Design Guide. This book represent s our t hird- generat ion QoS Design Guide. And
it is t he goal of t he aut hors t o drive t hese designs ( including DoS/ worm - m it igat ion st rat egies)
int o fut ure releases of Aut oQoS. So, basically, what you are reading is t he proposed blueprint for
t he next version of Aut oQoS.

When it com es t o any given t echnology, t here are really only t wo t ypes of people: t hose who are
int erest ed in t he t echnology and seek a t horough underst anding of t he relat ion of t he part s t o
t he whole, and t hose who j ust want t o " t urn it on" and walk away. The form er are t he ones who
will confident ly unleash t he t rue power of t he t echnology and push it t o it s lim it s; t he lat t er are
t he ones who are usually hesit ant , t im id, and conservat ive in t heir use of t he t echnology,
t ypically accom panied wit h m ediocre result s.

For exam ple, t here are t hose who enj oy looking under t he hood of a Ferrari and want t o know all
t he det ails about how t he engine generat es it s beaut iful purring and power, and t here are ot hers
who want only t o t urn it on, drive away, and look sexy. The form er group will drive m ore
confident ly, boldly unleashing t he engine's t rem endous power and, t hus, pushing t he car t o it s
lim it s.

This book is int ended for t he form er t ype of QoS net working professionalt hose looking for a
t horough underst anding of what m akes t hem m ove so fast , sound so good, and look so sexy as
t hey confident ly harness t heir t echnology.
Goals and Methods
The m ain goal of t his book is t o present t em plat es t hat address 80 percent or m ore of a
cust om er's requirem ent of QoS in a part icular cont ext and archit ect ure ( LAN, WAN, VPN) .
Addit ionally, t he rat ionales and considerat ions behind t he recom m endat ions are explained in
det ail so t hat as t weaking is required, net work adm inist rat ors are well inform ed of t he t rade- offs
involved.

A key approach t hat we've used t hroughout t his configurat ion- rich book is t o incorporat e inline
explanat ions of configurat ions. I n t his way, t he QoS- relevant com m ands are highlight ed and
det ailed line- by- line t o illust rat e t he funct ion of each elem ent and how t hese part s m ake up t he
whole solut ion.

To com plem ent t hese line- by- line design recom m endat ions, relat ed verificat ion com m ands are
det ailed. These verificat ion com m ands are present ed in cont ext wit h t he design exam ples, and
specific det ails of what t o look for in t he result ing out put are highlight ed. These verificat ion
exam ples are, t herefore, significant ly richer in relevance t han m ost such exam ples present ed in
Cisco docum ent at ion, and t hey allow net work adm inist rat ors t o confirm quickly whet her t he
recom m ended designs have been deployed correct ly.

Finally, each design chapt er has a case- st udy exam ple at t he end t hat t ies t oget her m any of t he
design elem ent s present ed in t he chapt er and present s a bigger- pict ure det ailed exam ple for t he
infrast ruct ure archit ect ure being discussed ( LAN/ WAN/ VPN) . These exam ples are indicat ive of
what can be expect ed in product ion environm ent s. Oft en t hese case- st udy exam ples span
several devices and, t hus, highlight crit ical int errelat ionships.
How This Book Is Organized
This book is divided int o t hree m ain part s: an int roduct ion and overview sect ion, a QoS t oolset
review sect ion, and ( t he heart of t he book) a QoS design sect ion.

Ch a pt e r 1 , " I n t r odu ct ion t o QoS," is an int roduct ion and brief hist ory of t he
developm ent of QoS t echnologies, showing where t hese cam e from and t he direct ion
t hey're headed in.

Ch a pt e r 2 , " QoS D e sign Ove r vie w ," is an overview of QoS design. I t begins by det ailing
t he service- level requirem ent s of voice, video, and dat a applicat ions, and it present s t he
Scavenger- class DoS/ worm - m it igat ion st rat egy and high- level QoS best pract ices t hat will
be det ailed in t he design chapt ers t o follow.

To set proper cont ext for t he design chapt ers, various QoS t ools are reviewed. This review is not
indent ed t o serve as feat ure docum ent at ion, but it supplem ent s Cisco docum ent at ion t o highlight
various int erdependancies or caveat s for t hese t ools t hat at t im es im pact t he recom m ended QoS
designs t hat follow. The QoS t oolset review sect ion, Chapt ers 3 t hrough 11 , covers t he following
t opics:

Ch a pt e r 3 , " Cla ssifica t ion a n d M a r k in g Tools" This chapt er reviews Layer 2 m arking
m echanism s ( such as 802.1Q/ p, Fram e Relay Discard Eligibilit y, ATM Cell Loss Priorit y, and
MPLS Experim ent al Values) and Layer 3 m arking m echanism s ( such as I P Precedence and
Different iat ed Services Code Point s) .

Ch a pt e r 4 , " Policin g a n d Sh a pin g Tools"This chapt er reviews t he t oken bucket

algorit hm , which is t he basis for m ost policers and shapers. Bot h t wo- rat e and t hree- rat e
policers are covered as are ATM and Fram e Relay t raffic shaping.

Ch a pt e r 5 , " Con ge st ion - M a n a ge m e n t Tools" This chapt er reviews t he evolut ion of

queuing m echanism s and focuses on Low- Lat ency Queuing and Class- Based Weight ed Fair
Queuing. This chapt er highlight s t he int eroperat ion and int erdependencies of t hese
m echanism s wit h ot her QoS m echanism s, such as link- fragm ent at ion and shaping t ools.

Ch a pt e r 6 , " Con ge st ion - Avoida n ce Tools" This chapt er reviews t he Weight ed Random
Early Det ect ion m echanism and shows how t his can be used t o provide Different iat ed
Services wit hin an ( RFC 2597) Assured Forwarding t raffic class. This chapt er also shows
how t his m echanism can be used t o set ( RFC 3168) I P Explicit Congest ion Not ificat ion bit s.

Ch a pt e r 7 , " Lin k - Spe cific Tools"This chapt er reviews header- com pression t echniques
( such as TCP and RTP header com pression) and link- fragm ent at ion and int erleaving
t echniques ( such as Mult ilink PPP Link Fragm ent at ion and I nt erleaving [ MLP LFI ] and Fram e
Relay fragm ent at ion [ FRF.12] ) .

Ch a pt e r 8 , " Ba n dw idt h Re se r va t ion " This chapt er reviews t he Resource Reservat ion
Prot ocol ( RSVP) and shows how it can be applied t o adm ission cont rol and MPLS Traffic
Engineering.

Ch a pt e r 9 , " Ca ll Adm ission Con t r ol ( CAC) " This chapt er reviews local, resource- based,
and m easurem ent - based call adm ission cont rol ( CAC) m echanism s, including t he use of
 RSVP for CAC. The t ools reviewed in previous chapt ers can prot ect voice from dat a, but
only CAC t ools can prot ect voice from voice.

Ch a pt e r 1 0 , " Ca t a lyst QoS Tools" This chapt er reviews t he m ain classificat ion, m arking,
m apping, policing, and queuing t ools available on t he current Cisco Cat alyst plat form s
( including t he Cat alyst 2950, 2970, 3550, 3560, 3570, 4500- Supervisors I I + t o V, and
Cat alyst 6500 Supervisor 2 and Supervisor 720) .

Ch a pt e r 1 1 , " W LAN QoS Tools"This chapt er reviews QoS m echanism s available for
wireless access point s, including t he 802.11e Enhanced Dist ribut ed Coordinat ion Funct ion
( EDCF) and t he QoS Basic Service Set ( QBSS) .

When t he QoS t oolset is reviewed, t he cont ext is set for t he det ailed design recom m endat ions
t hat follow. The next chapt erswhich com prise t he heart of t his bookcover t he QoS design
recom m endat ions for prot ect ing voice, video, and m ult iple classes of dat a while m it igat ing
DoS/ worm at t acks for t he following net work infrast ruct ure archit ect ures:

Ch a pt e r 1 2 , " Ca m pu s QoS D e sign "This design chapt er det ails access, dist ribut ion, and
core layer considerat ions and designs for Cisco Cat alyst 2950, 2970, 3550, 3560, 3570,
4500- Supervisors I I I - V, and Cat alyst 6500 Supervisor 2 and Supervisor 720 series
swit ches. Five separat e access- edge m odels are present ed, along wit h det ailed
queuing/ dropping recom m endat ions on a per- plat form basis. Plat form - unique feat ures,
such as t he Cat alyst 3550 per- Port / per- VLAN policing feat ure, t he Cat alyst 6500 PFC2
Dual- Rat e Policing feat ure, and t he PFC3 Per- User Microflow Policing feat ure, are
highlight ed in cont ext .

Ch a pt e r 1 3 , " W AN Aggr e ga t or QoS D e sign " This design chapt er det ails considerat ions
and designs for low- speed ( 768 kbps) , m edium - speed ( > 768 kbps and T1/ E1) , and
high- speed ( > T1/ E1) privat e WAN t opologies, such as leased lines, Fram e Relay, ATM,
ATM- t o- Fram e Relay service int erworking, and I SDN.

Ch a pt e r 1 4 , " Br a n ch Rou t e r QoS D e sign "This design chapt er det ails branch- specific
considerat ions and designs, such as unidirect ional applicat ions, and branch- t o- cam pus
t raffic classificat ion t hrough access list s and Net work- Based Applicat ion Recognit ion
( NBAR) . Branch- specific designs include Cisco SAFE recom m endat ions for using NBAR for
known worm ident ificat ion and policing.

Ch a pt e r 1 5 , " M PLS VPN QoS D e sign " This design chapt er det ails considerat ions and
designs for bot h ent erprises ( t hat are m apping int o MPLS VPN service- provider [ edge]
classes of service) and service providers ( t hat are provisioning edge and core classes of
service) . Service provider designs also include det ails on how t o provision MPLS DiffServ
Tunneling Modes ( Uniform , Short - Pipe, and Pipe) and an int roduct ion t o MPLS Traffic
Engineering ( dem onst rat ing per- cust om er t raffic engineering and per- cust om er/ per-
applicat ion t raffic engineering t hrough MPLS DiffServ Traffic Engineering) .

Ch a pt e r 1 6 , " I PSe c VPN QoS D e sign "This design chapt er det ails t he considerat ions and
designs for deploying sit e- t o- sit e I PSec VPNs and for t eleworker I PSec VPNs ( which
t raverse broadband m edia, such as cable and DSL) .

Appe n dix, " At - a - Gla n ce " QoS Su m m a r ie sSingle- page sum m aries of key QoS concept s
present ed t hroughout t his t he book for ready- reference, including

- QoS Tools

- The Cisco QoS Baseline

- QoS Best Pract ices

- Scavenger- Class QoS Design

- Cam pus QoS Design

- WAN QoS Design

- Branch QoS Design

- MPLS VPN QoS Design ( for Ent erprise Subscribers)

- MPLS VPN QoS Design ( for Service- Providers)

- I PSec VPN QoS Design

Part I: Introduction to QoS
Part I of t his book provides a brief background of t he evolut ion of QoS t echnologies and
overviews various current ly available QoS feat ures and t ools. The QoS requirem ent s of
voice, video, and m ult iple classes of dat a applicat ions are present ed, along wit h an
overview of t he nat ure and effect s of various t ypes of DoS and worm at t acks. QoS design
principles are int roduced t o show how QoS m echanism s can be st rat egically deployed t o
address applicat ion requirem ent s while m it igat ing such at t acks.

The chapt ers in t his part of t he book are as follows:

Chapt er 1 I nt roduct ion t o QoS

Chapt er 2 QoS Design Overview

Chapter 1. Introduction to QoS
This chapt er provides a brief hist ory of bot h voice and dat a net work evolut ion, illust rat ing t he
background of t he concept of Qualit y of Service ( QoS) . I t int roduces t he fundam ent al QoS
concept s of I nt Serv and DiffServ t o set t he st age for t he lat er discussion of individual QoS
m echanism s. The following t opics are int roduced and briefly discussed:

I nt Serv and DiffServ

QoS t ools cat egories

Modular QoS CLI

QoS Baseline

QoS classes

Aut om at ic QoS

A fair am ount has been writ t en in t he indust ry about qualit y of service ( QoS) , but it seldom is
explained why QoS has becom e a t opic of concern in m odern net works when it was som et hing
relat ively unheard of only a few years ago. I t is inst ruct ive t o review briefly a sm all am ount of
net working hist ory t hat put s QoS t echnology in perspect ive.
A Brief Historical Perspective
A cent ury ago, t he public swit ched t elephone net work ( PSTN) st art ed building out a worldwide,
circuit - swit ched net work. This net work consist ed of fixed- bandwidt h, dedicat ed circuit s and
ideally was suit ed t o carrying real- t im e t raffic, such as voice. Som e five decades lat er,
net working expert s from m ilit ary and educat ional environm ent s int roduced packet - swit ched
net works t o circum vent any single point s of failure, com m on in circuit - swit ched net works. Packet
swit ching chops t he inform at ion flow int o sm all chunks of dat a, which can be rout ed over
independent pat hs t o t he sam e dest inat ion, analogous t o t he operat ion of t he post al syst em .

The resiliency of packet - swit ched net works caused a shift t oward connect ionless com m unicat ion
prot ocols t hat can handle packet s t hat m ight arrive out of order. However, for m any dat a
applicat ions, t his was not only com plicat ed t o design around, but it also was insufficient in
m eet ing applicat ion needs. Thus, connect ion- orient ed prot ocols such as X.25 and Syst em s
Net work Archit ect ure ( SNA) , and lat er Fram e Relay and Asynchronous Transfer Mode ( ATM) ,
were developed. I n t hese prot ocols, a circuit ( perm anent or swit ched virt ual circuit , PVC or SVC)
is defined over t he underlying connect ionless packet - swit ched net work t o handle a session of
com m unicat ion bet ween t wo devices or endpoint s.

I n t heory, real- t im e com m unicat ions such as voice can use virt ual circuit s regardless of t he
underlying net working t echnology. Several universit ies conduct ed m any experim ent s t o t his
effect in t he 1970s. However, voice over virt ual circuit s did not becom e a com m ercial or pract ical
realit y unt il t he rout ers and swit ches used in packet - swit ched net works gained t he CPU and
m em ory power required t o drive packet st ream s at real- t im e speeds at cost - effect ive prices.

When processing power becam e available at affordable cost point s, ot her issues wit h carrying
real- t im e com m unicat ions over a packet - swit ched net work m anifest ed t hem selves. For exam ple,
when packet s are delayed or dropped en rout e because of buffer overflows or ot her m om ent ary
failures, t he int elligent prot ocols in t he seven- layer I nt ernat ional Organizat ion for
St andardizat ion ( I SO) m odel recover t he " session" t hrough t he use of error- det ect ion and
correct ion capabilit ies, such as t im eout s and ret ransm issions. Alt hough t hese recovery m et hods
work well for dat a applicat ions, t hey fall far short of sat isfying t he needs of real- t im e inform at ion
st ream s.

ATM was t he first general dat a- net working t echnology t o include a class of service concept at t he
lower layers of com m unicat ions t ransport prot ocolst hat is, offering different t reat m ent s for
different t ypes of t raffic ( prot ocols such as SNA already had t his concept at higher layers in t he
st ack) . ATM m inim izes lat ency by defining fixed- lengt h cells, which can be swit ched in hardware.
ATM also uses t he fam iliar concept s of PVCs and SVCs t o elim inat e rout ing delays by doing an
init ial connect ion set up, aft er which all ot her packet s t hat belong t o t he st ream can be forwarded
t o t he dest inat ion wit hout addit ional rout ing.

I t has been saidonly part ly facet iouslyt hat packet swit ching has been a 30- year failed
experim ent . The at t ribut es t hat t he ATM archit ect ure st rived for are none ot her t han t hose of t he
original circuit - swit ched PSTN: low lat ency, fixed circuit - based rout ing, predict able service levels,
and inform at ion- order preservat ion. Then why not j ust use t he PSTN? Opt ions for t ransm it t ing
dat a over t he voice net work m et wit h equally lim it ed success. The PSTN sim ply is not opt im ized
for dat a net works: The equipm ent is expensive, t he archit ect ure is rigid, t he bandwidt h
allocat ions are wast eful, and t he infrast ruct ure as a whole is ill suit ed t o applicat ions in which
sessions are short , variable, m ult ipoint , or connect ionless.
I n an effort t o find a m ore effect ive solut ion t o support a com binat ion of voice and dat a,
int egrat ed services offerings were int roduced. The t erm int egrat ed services ( as in I nt egrat ed
Services Digit al Net work [ I SDN] or t he I ETF I nt egrat ed Services [ I nt Serv] m odel) refers t o t he
m ixing of different t ypes of t raffic, such as voice, video, and dat a, over a single packet - swit ched
net work. I SDN, which is considered by som e t o be t he first foray int o an archit ect ure for
converged net works, defines how dat a prot ocols can be carried over a circuit - swit ched
infrast ruct ure t hat nat ively support s voice. The PSTN evolved slight ly wit h t he int roduct ion of
I SDN. However, wit h t he except ion of a handful of count ries in Europe, I SDN never really t ook
off. This was prim arily because of nont echnical reasons, such as t he pricing st rat egies t hat t he
providers adopt ed.

I n t he lat e 1990s, I P won out as t he t echnology of choice for converged net works because of it s
ease of use, ubiquit y, and advances in handling real- t im e t raffic.

The key enablers for I P net works t o converge successfully voice, video, and dat a over packet -
swit ched infrast ruct ures were QoS t echnologies. QoS allows for t he different iat ed t reat m ent of
dat a t raffic versus voice and ot her delay- sensit ive t raffic. I n ot her words, it allows t he net work
t o include a syst em of " m anaged unfairness." As QoS t echnologies evolved, increasing num bers
of ent erprises saw t he value of a single- net work infrast ruct ure and began planning t oward
deploying converged net works.
QoS Evolution
I P net works of t he m id- 1990s were invariably best - effort net works, and t he I nt ernet , as a whole,
rem ains so t oday. Privat ely owned ent erprise and service provider net works, t hough, have been
widely t ransform ed from best - effort m odels t o m ore com plex different iat ed services m odels,
m eaning t hat t he net work gives different applicat ions differing levels of service.

Figure 1- 1 shows t he broad st eps in t he evolut ion of QoS concept s since t he early 1990s.

Figu r e 1 - 1 . QoS Evolu t ion

The first at t em pt t o st andardize QoS cam e in t he m id- 1990s, when t he I nt ernet Engineering
Task Force ( I ETF) published t he I nt egrat ed Services Request For Com m ent s ( I nt Serv
RFCsst art ing wit h RFC 1633 in June 1994) . These RFCs cent ered on a signaling prot ocol called
t he Resource Reservat ion Prot ocol ( RSVP) . RSVP signals bandwidt h and lat ency requirem ent s for
each discret e session t o each node along a pat h ( logical circuit ) t hat packet s would t ake from t he
sending endpoint t o t he receiving endpoint . I nit ially, RSVP required every node t o heed it s
reservat ions, which was highly im pract ical over t he I nt ernet , on which servers, swit ches, and
rout ers of every descript ion, vint age, and vendor coexist .

To address t his challenge, anot her set of st andardst he DiffServ m odelem erged as a second
at t em pt at st andardizing QoS. The DiffServ m odel describes various behaviors t o be adopt ed by
each com pliant node. The nodes could use what ever feat ures ( propriet ary or ot herwise) were
available, as chosen by t he vendor, t o conform . Packet m arkings, such as I P Precedence ( I PP)
and it s successor, Different iat ed Services Code Point s ( DSCPs) , were defined along wit h specific
per- hop behaviors ( PHBs) for key t raffic t ypes.
As t he I nt Serv and DiffServ m odels have evolved, t he general popularit y of one m et hod versus
t he ot her has swung back and fort h ( as shown in Figure 1- 2 ) , and t heir coexist ence has becom e
an ever- increasing st ruggle, wit h com m it t ed advocat es on bot h sides. Today t he debat es over
t he advant ages of each cont inue wit hout a clear, indust ry- wide agreed- upon resolut ion. The
realizat ion has begun t hat neit her m et hod offers a com plet e solut ion and t hat elem ent s of bot h
should be com bined t o provide t he m ost general m et hod applicable t o t he widest range of t raffic
and applicat ion t ypes.

Figu r e 1 - 2 . I n t Se r v a n d D iffSe r v

A short definit ion of I nt Serv and DiffServ follows:

I nt Serv uses a flow- based concept coupled wit h a signaling prot ocol along t he packet pat h.
The signaling prot ocol guarant ees t hat adequat e resources are available ( at each hop) for
t he flow before adm it t ing t he flow ont o t he net work. I n init ial deploym ent s, t he I nt Serv
m odel suffered from scalabilit y issues because of t he m any flows t hat needed m anagem ent
on net work backbones.

DiffServ uses packet m arkings t o classify and t reat each packet independent ly. Alt hough
t his scales well ( which is probably why ent erprises and service providers deploy it m ore
frequent ly) , it offers no specific bandwidt h guarant ees t o packet s t hat belong t o a flow and,
t herefore, fails t o provide adm ission cont rol t o new flows.

Wit h no clear advant age t o eit her m odel, QoS m echanism s cont inue t o use a m ix of I nt Serv and
DiffServ t echnologies t o offer t he breadt h of services required on net works. I nt Serv and DiffServ
are discussed furt her in t he sect ion "QoS Models" lat er in t his chapt er.

I n t he lat e 1990s, QoS t echniques becam e m ore sophist icat ed and were adapt ed t o advanced
net working t echnologies, such as Mult iprot ocol Label Swit ching ( MPLS) and Virt ual Privat e
Net works ( VPNs) .

The m ost recent t rend in QoS is sim plificat ion and aut om at ion, wit h t he goal of sim ply and
efficient ly provisioning " int elligent " QoS on I P net works. When viewed as individual feat ures,
QoS t echnologies offer a m yriad of " nerd knobs" t hat can be t urned. I n t he hands of capable
adm inist rat ors, t hese can be used t o build very sophist icat ed net works. However, t hey also can
result in very com plex configurat ions. Many adm inist rat ors do not have t he t im e or t he desire t o
delve int o QoS t echnologies t o t his expert level and inst ead would prefer t o define high- level
policies and have t he net work sim ply " do t he right t hings" t o im plem ent t hem .
User Network Expectations
The percept ion of how t he net work behaves, or how well it behaves, depends on how you look at
it . End users, or consum ers, of t he net work m ight have a very different view of net work qualit y
of service t han t he st aff m anaging t he net work.

End User
An end user's percept ion of QoS is t ypically subj ect ive and relat ive, and not easily m easurable.

End users perceive t he net work qualit y t hrough t heir end device and have cert ain expect at ions
of appropriat e service levels. For exam ple, t ypical users expect a voice call on a st andard phone
t o be of t oll qualit y. Yet t hey do not expect t hat sam e qualit y level from a cell phone or a voice
call spoken int o a m icrophone on a personal com put er. This is t he general expect at ion,
regardless of t he fact t hat all t hree calls m ight be carried by t he sam e net work in t he sam e
m anner.

The end user has no concept of and t ypically very lit t le int erest in t he capabilit ies of t he
net works in bet weenunless, of course, t he qualit y of t he net work response is lacking. Therefore,
end users' percept ion of t he qualit y of t he service t hat t hey receive is based on previously
observed behavior on sim ilar devices ( exam ples include a PSTN phone call, a PBX phone call, a
bank t eller applicat ion, and t he refresh of a web page display) and t he cost of t he service ( which,
in an ent erprise net work, t he general end user perceives as $0) .

Information Technologies Management

I T m anagem ent perceives t he net work qualit y t hrough m anagem ent st at ist ics such as
t hroughput , usage, percent age of loss, and user com plaint s. Expect at ions and " qualit y problem s"
from an I T perspect ive t end t o be m ore absolut e and m easurable. ( For exam ple, t he one- way
lat ency of m ore t han 150 m s is unaccept able for a voice call, or a t ransact ion refresh t im e for a
bank t eller applicat ion m ust be fewer t han 5 seconds.)

Service providers form alize t hese expect at ions wit hin service- level agreem ent s ( SLAs) , which
clearly st at e t he accept able bounds of net work perform ance. Corporat e ent erprise net works
t ypically do not have such form al SLAs, but t hey nevert heless m anage t heir net works on som e
form of m easurem ent and m onit oring. Som e ent erprise net works indeed m ight use SLAs of
various levels of form alit y bet ween t he I T depart m ent and t he cust om er depart m ent s t hat t hey
serve.

User com plaint s m ight result even t hough t he net work m et t he SLA ( form al or ot herwise) . For
exam ple, t he packet loss st at ist ics over a cert ain period of t im e m ight be wit hin bounds, but t he
user whose file t ransfer session t im ed out or whose print j ob was lost during a period of
m om ent ary congest ion would m ost likely perceive it as a " net work problem ."
Understanding QoS
Appreciat ing what QoS t ools and m et hods do t o packet s in a net work is fundam ent al t o
appreciat ing t he effect of individual QoS t ools discussed in lat er chapt ers, and ult im at ely
underst anding t he net work designs and m et hods t hat const it ut e t he m at erial in t his book.

End-to-End QoS
Regardless of how it is m easured, QoS is a vit al elem ent in any converged net work. To ensure
t he highest level of qualit y, however, QoS m ust be im plem ent ed across all areas of t he net work.

QoS is described apt ly by an age- old cliché: I t 's only as st rong as t he weakest link. Opt im ally,
every device ( host , server, swit ch, or rout er) t hat handles t he packet along it s net work pat h
should em ploy QoS t o ensure t hat t he packet is not unduly delayed or lost bet ween t he
endpoint s. I t is a popular m yt h t hat QoS is applicable only t o slow- speed wide- area net works
( WANs) or t he I nt ernet . Test ing has shown t hat delay- sensit ive applicat ions, such as voice,
suffer qualit y loss when QoS is not enabled on cam pus devices, such as Cisco I P phones and
Cisco Cat alyst swit ches.

Figure 1- 3 shows t he segm ent s of t he net work where QoS m ust be deployed in t he t ypical I P
t elephony ent erprise net work and what QoS t echniques are com m on in each segm ent .

Figu r e 1 - 3 . En a blin g QoS in a n En t e r pr ise N e t w or k

[View full size image]

All Packets Are (Not) Equal

Net works wit hout QoS enabled are described as best - effort net works. Best - effort net work
designs t reat all packet s as equally im port ant . Such net works work well if t here is enough CPU,
m em ory, and bandwidt h t o handle im m ediat ely all t he packet s t raversing t he net work as t hey
arrive ( in ot her words, at line rat e) . However, because t his is rarely t he case, t he following
scenarios t end t o em erge:

User- based cont ent ion occurs when packet s from different users, user groups,
depart m ent s, or even ent erprises cont end for t he sam e net work resources.

Applicat ion- based cont ent ion occurs when different applicat ions from t he sam e user or user
group cont end wit h each ot her for lim it ed net work resources. These applicat ions m ight
have different service requirem ent s from t he net work, as illust rat ed in Figure 1- 4 .

Figu r e 1 - 4 . Applica t ion - Ba se d Con t e n t ion

To obt ain t he appropriat e levels of service from oft en scarce net work resources experiencing
cont ent ion, t he fundam ent al concept of QoS m ust be appliednam ely, t hat all packet s are not
equal. I n ot her words, t o resolve t he cont ent ion, packet s m ust be t reat ed wit h m anaged
unfairness ( eit her preferent ially or deferent ially) . I n ot her words, adm inist rat ive policies m ust be
defined and deployed t hroughout t he net work infrast ruct ure t o ensure t hat each node m akes
consist ent decisions about t he relat ive im port ance of an individual packet ( or flow) and adj ust s
it s packet - handling behavior accordingly.

This concept of unfairness applies equally t o t raffic for which higher levels of priorit y m ust be
m aint ained ( for exam ple, t o voice and video t raffic) and t raffic t hat is undesirable in t he net work
( denial- of- service [ DoS] or worm - generat ed t raffic, or even general web surfing t o dest inat ions
unrelat ed t o t he goals of t he ent erprise) . The lat t er cat egory of t raffic int roduces t he concept of
less t han best - effort service, also referred t o as Scavenger service ( based on an I nt ernet 2 draft
specificat ion) . Best - effort or bet t er service is provided t o all desirable t raffic on t he net work, but
t here is no sense in providing even best - effort service t o unwant ed t raffic. Such Scavenger
t raffic, if not dropped out right , is carried only when spare capacit y is available.

The Challenges of Converged Networks

The high- level goal of QoS t echnologies in a converged net work is t o abst ract t he fact t hat t here
is only one net work and t o m ake voice, video, and dat a convergence appear t ransparent t o t he
end users. To achieve t his goal, QoS t echnologies allow different t ypes of t raffic t o cont end
inequit ably for net work resources. Real- t im e applicat ions, such as voice or int eract ive video, can
be given priorit y or preferent ial services over generic dat a applicat ionsbut not t o t he point t hat
dat a applicat ions are st arving for bandwidt h.

QoS is defined as t he m easure of a syst em 's service availabilit y and t ransm ission qualit y. Service
availabilit y is a crucial foundat ion elem ent of QoS. Before any QoS can be im plem ent ed
successfully, t he net work infrast ruct ure should be designed t o be highly available. The t arget for
high availabilit y is 99.999 percent upt im e, wit h only 5 m inut es of downt im e perm it t ed per year.
The t ransm ission qualit y of t he net work is det erm ined by t he following fact ors:

Pa ck e t loss This is a com parat ive m easure of t he num ber of packet s fait hfully t ransm it t ed
and received t o t he t ot al num ber t ransm it t ed, expressed as a percent age. Packet loss in
t he cont ext of QoS does not relat e t o drops because of net work out ages or link flaps
( because t hese are a funct ion of a high- availabilit y net work design) , but inst ead relat es t o
drops because of net work congest ion.

D e la y ( or la t e n cy) This is t he finit e am ount of t im e t hat it t akes a packet t o reach t he

receiving endpoint aft er being t ransm it t ed from t he sending endpoint . I n t he case of voice,
t his equat es t o t he am ount of t im e t hat it t akes for speech t o leave t he speaker's m out h
and be heard by t he list ener's ear. This t im e period is t erm ed end- t o- end delay and is
com prised of t wo com ponent s: fixed net work delay and variable net work delay.

I n dat a net works carrying voice, fixed net work delay furt her is broken down int o t he
following:

- Pa ck e t iza t ion de la y The t im e required t o sam ple and encode voice or video
signals int o packet s.

- Se r ia liza t ion de la y The t im e required t o t ransm it t he packet bit s ont o t he physical

m edia, based on t he clocking rat e of t he int erface.

- Pr opa ga t ion de la y The t im e required for t he elect rical/ opt ical pulses t o t raverse
t he m edia en rout e t o t heir dest inat ion, based on t he laws of physics.

D e la y va r ia t ion ( or j it t e r ) Also known as int erpacket delay, t his is t he difference in t he

end- t o- end delay bet ween sequent ial packet s. For exam ple, if one packet requires 100 m s
t o t raverse t he net work from t he source endpoint t o t he dest inat ion endpoint , and t he
following packet requires 125 m s t o m ake t he sam e t rip, t he delay variat ion would be
calculat ed as 25 m s, as illust rat ed in Figure 1- 5 .

Figu r e 1 - 5 . D e la y Va r ia t ion
Each end st at ion in a VoI P or video over I P conversat ion has a j it t er buffer, which is used t o
sm oot h out t he variat ion in arrival t im es of dat a packet s t hat cont ain voice. Jit t er buffers can be
fixed or adapt ive.

I nst ant aneous changes in arrival t im es of packet s t hat exceed t he j it t er buffer's capabilit y t o
com pensat e result in j it t er buffer overruns and underruns.

- A j it t er buffer underrun occurs when t he arrival t im es of packet s increase t o t he point

t hat t he j it t er buffer has been exhaust ed and cont ains no packet s for t he digit al signal
processors ( DSP) t o process when it is t im e t o play t he next piece of voice or video,
result ing in clips.

- A j it t er buffer overrun occurs when packet s cont aining voice or video arrive fast er t han
t he j it t er buffer can accom m odat e. When t his happens, packet s are dropped when it is
t im e t o play t he voice or video sam ples, result ing in degraded voice qualit y.

Variable net work delay generally is caused by congest ion wit hin t he net work.
QoS Models
As briefly int roduced earlier, t here are t wo m odels for providing t he different iat ed levels of
net work service required in converged net works: I nt Serv and DiffServ.

IntServ Overview
Think of best - effort I P service in t erm s of t he regular m ail ( snail- m ail) service. The m ail is
delivered if and when it can be, but it also m ight be lost ( arriving at som e undet erm ined t im e in
t he fut ure or not at all) . By com parison, I nt Serv is analogous t o a cust om m ail service, such as
diplom at ic m ail or courier services, wit h cert ain param et ers regarding loss and delivery
guarant eed.

More specifically, I nt Serv is a specificat ion of t he following:

What t he sender is sending ( rat e, m axim um t ransm ission unit [ MTU] , and so on) , as
described by t he Transm ission Specificat ion ( TSpec)

What t he receiver needs ( bandwidt h, MTU, and so on) , as described by t he Receiver

Specificat ion ( RSpec)

How t he signaling is perform ed on t he net work by t he sender and receiver ( t hat is, t he use
of RSVP)

The fram ework of I nt Serv preserves t he end- t o- end sem ant ics of QoS for I P. Key endpoint s are
t he sender and receiver applicat ions t hat request a desired service from t he net work for a set of
flows, as defined by t he source address, dest inat ion address, t ransport prot ocol, source port ,
and dest inat ion port .

I nt Serv describes t hree m ain classes of service t hat an applicat ion can request :

Gu a r a n t e e d se r vice s ( RFC 2 2 1 2 ) Provides firm ( m at hem at ically provable) bounds on

end- t o- end packet - queuing delays, m aking it possible t o provide a service t hat guarant ees
bot h delay and bandwidt h

Con t r olle d loa d ( RFC 2 2 1 1 ) Provides t he applicat ion flow wit h a qualit y of service closely
approxim at ing t he QoS t hat t he sam e flow would receive from an unloaded net work
elem ent , but uses capacit y ( adm ission) cont rol t o ensure t hat t his service is received even
when t he net work elem ent is overloaded

Be st - e ffor t se r vice Provides no service guarant ees of any t ype

The advant ages of t he I nt Serv m odel include t he following:

Concept ual sim plicit y, facilit at ing t he int egrat ion wit h net work policy adm inist rat ion

Discret e per- flow QoS, m aking it archit ect urally suit able t o voice calls
 Call adm ission cont rol ( CAC) capabilit ies, which can indicat e t o endpoint s whet her t he
desired bandwidt h is available

The disadvant ages of t he I nt Serv m odel include t hese:

All net work elem ent s m ust m aint ain st at e and exchange signaling m essages on a per- flow
basis, which m ight require a significant am ount of bandwidt h on large net works.

Periodic refresh m essages are used, which m ight require prot ect ion from packet loss t o
keep t he session( s) int act .

All int erm ediat e nodes m ust im plem ent RSVP.

DiffServ Overview
Cont inuing t he analogy of m ail services, DiffServ can be com pared t o different t iers of m ail
service, such as regular, regist ered, priorit y, and express m ail. Each service offers part icular
param et ers of delivery, and t he piece of m ail is st am ped at each int erm ediat e handling point t o
ensure t hat it get s t he required service. However, t here is no specific connect ion bet ween t he
sender of t he piece of m ail and t he t reat m ent t hat t he m ail receives.

The prem ise of DiffServ is very sim ple: I t offers different net work service levels t o a packet ,
t hereby " enable[ ing] scalable service discrim inat ion in t he I nt ernet wit hout t he need for per- flow
st at e and signaling at every hop" ( RFC 2474) . Packet s of a part icular service belong t o a
part icular " class," and t he t reat m ent of each " class" is described by PHBs wit h which t he net work
node m ust com ply. Meaningful services can be const ruct ed by a com binat ion of t he following:

Set t ing a field in t he I P header upon net work ent ry or at a net work boundary ( I PP or
DSCPs)

Using t his field t o det erm ine t he nodes inside t he net work forward t he packet s

Condit ioning t he m arked packet s at net work boundaries in accordance wit h t he

requirem ent s or rules of each " class" or service

The essence of DiffServ is t he specificat ion of PHBs t hat an applicat ion can receive from t he
net work:

Ex pe dit e d for w a r din g ( RFC 3 2 4 6 , pr e viou sly RFC 2 5 9 8 ) Provides a st rict - priorit y
service ( com pare t his t o express m ail service)

Assu r e d for w a r din g ( RFC 2 5 9 7 ) Provides a qualified delivery guarant ee ( com pare t his
t o regist ered m ail service) and m akes t he provision for oversubscript ion t o t his service
( specifically, m arkdown and dropping schem es for excess t raffic)

Cla ss se le ct or s ( RFC 2 4 7 4 ) Provides code point s t hat can be used for backward
com pat ibilit y wit h I P Precedence m odels

Be st - e ffor t se r vice Provides a " delivery when possible" service ( com pare t his t o regular
m ail service)

DiffServ const ruct s services from t he PHBs by classifying packet s int o " classes" at t he edge, or
boundary, of t he net work and m arking t he packet s accordingly. Opt ionally, t he packet s can be
m et ered wit h policing or shaping t echniques. The core of t he net work im plem ent s t he PHBs and
uses t he packet m arkings t o m ake queuing and dropping decisions.

The DiffServ m odel include t hese advant ages:

Sca la bilit y No st at e or flow inform at ion is required t o be m aint ained.

Pe r for m a n ce The packet cont ent s need be inspect ed only once for classificat ion purposes.
At t hat t im e, t he packet is m arked and all subsequent QoS decisions are m ade on t he value
of a fixed field in t he packet header, reducing processing requirem ent s.

I n t e r ope r a bilit y All vendors already are running I P.

Fle x ibilit y The DiffServ m odel does not prescribe any part icular feat ure ( such as a queuing
t echnique) t o be im plem ent ed by a net work node. The node can use what ever feat ures
opt im ize it s hardware and archit ect ure, as long as it is consist ent wit h t he behavior
expect at ion defined in t he PHBs.

The disadvant ages of t he DiffServ m odel include t he following:

No end- t o- end bandwidt h reservat ions are present ; t herefore, guarant ees of services can
be im paired by net work nodes t hat do not im plem ent t he PHBs appropriat ely over
congest ed links or by nodes t hat are not engineered correct ly for t he expect ed t raffic
volum e of a specific class.

The lack of a per- flow/ per- session CAC m akes it possible for applicat ions t o congest each
ot her. ( For exam ple, if only enough bandwidt h for 10 voice calls exist s and an 11t h call is
perm it t ed, all 11 calls suffer call- qualit y det eriorat ion.)
Introduction to the QoS Toolset
A fair am ount of lit erat ure exist s on QoS concept s, t echnologies, and feat ures. The purpose of
t his book is not t o reit erat e in dept h how t hese t ools work, but rat her t o show how t hese t ools
int eract wit h each ot her and what com binat ion of t ools can be used t o achieve t he overall design
obj ect ives of a net work. However, t o lay t he cont ext for t he designs set fort h in t his book, a brief
overview of t he t oolset follows.

Generally, QoS t ools fall int o t he following cat egories:

Classificat ion and m arking t ools

Policing and shaping t ools

Congest ion- avoidance ( select ive dropping) t ools

Congest ion- m anagem ent ( queuing) t ools

Link- specific t ools

Figure 1- 6 illust rat es t he relat ionship and overall cohesiveness of different QoS t ools.

Figu r e 1 - 6 . QoS Toolse t

[View full size image]

Packet s or fram es ent ering a net work device m ust be analyzed t o det erm ine t he t reat m ent t hat
t hey should be given. This analysis is referred t o as classificat ion. Classificat ion is t he first QoS
funct ion t o occur for any given QoS policy, and it can occur repeat edly at various st ages of policy
enforcem ent . To reduce t he requirem ent for det ailed recursive classificat ion, it generally is
recom m ended t hat t raffic t ypes be classified as close t o t heir sources as possible and t hat t heir
packet s be m arked accordingly.

Marking est ablishes a dist inct t rust boundary t hat dem arcat es t he point where t he packet
m arkings are set properly and, t herefore, det ailed classificat ion ( Layer 4 t hrough 7 analysis) no
longer is required.

When packet s ent er a net work device, t hree generic m arking possibilit ies exist :

Packet s are unm arked.

Packet s are m arked, but t he m arkings are not t rust ed.

Packet s are m arked and t he m arkings are t rust ed.

I n t he first t wo scenarios, it is recom m ended t hat t he packet s be m arked or re- m arked.

Aft er m arking, t he next st ep is anot her classificat ion process based on packet m arkings. At t his
point , packet s m ight be discarded by a policer ( for exam ple, if t hey exceed an SLA) or a
congest ion- avoidance m echanism ( for exam ple, early dropping because buffers reached t he
m axim um lim it ) . Packet s t hat are not discarded are subj ect t o congest ion m anagem ent
( queuing) t o priorit ize and prot ect various t raffic t ypes when congest ion happens t o t he
t ransm ission link. Finally, t hese packet s are scheduled for t ransm ission on t he egress link, where
shaping m ight occur t o cont rol burst s and ensure t hat out going t raffic conform s t o any SLA t hat
is in effect on t he ingress of t he next hop.

Link- specific t ools usually are required only at WAN edges and include m echanism s for
com pression or fragm ent at ion t o reduce delay and j it t er.

Som e QoS t ools ( such as m arking and policing) can be applied in bot h t he ingress and egress
direct ions of t he t raffic flow on an int erface. Ot her t ools ( such as queuing) can be applied only in
t he egress direct ion ( wit h som e plat form - specific except ions) .

The QoS m echanism s ( prim arily DiffServ) described previously are applicable t o packet s already
adm it t ed t o t he net work. Such t ools are very effect ive in prot ect ing real- t im e ( voice) from non-
real- t im e ( dat a) t raffic, but t hey are com plet ely ineffect ive in prot ect ing real- t im e applicat ions
from ot her real- t im e applicat ions ( t hat is, prot ect ing voice t raffic from ot her voice t raffic) . Such
prot ect ion can be achieved only t hrough call adm ission cont rol ( CAC) m echanism s, which decide
whet her t o allow or disallow new packet st ream s ont o t he net work. I nt Serv m echanism s, such as
RSVP, can be used t o im plem ent discret e CAC.
Simplifying QoS
I n t he lat e 1990s, Cisco spent significant developm ent effort t o im plem ent an ext ensive QoS t ool
and feat ure set . The port folio of QoS m echanism s and opt ions becam e very rich and,
sim ult aneously, very com plicat ed t o deploy. During t he early 2000s, t he predom inant cust om er
feedback relat ing t o QoS was t he request t o sim plify QoS deploym ent . I n response t o t his
feedback, a series of QoS sim plificat ion and aut om at ion proj ect s was init iat ed. The result
included t he following:

The creat ion of a Modular QoS Com m and- Line I nt erface ( CLI )

The est ablishm ent of a QoS Baseline

Default behavior ( conform ing t o t he QoS Baseline)

Cross- plat form feat ure consist ency

Aut om at ic QoS ( Aut oQoS)

Modular QoS Command-Line Interface

The first st ep t oward sim plificat ion was t o m odularize t he configurat ion of QoS and m ake it
consist ent across plat form s. To t his end, a new configurat ion synt ax, t erm ed Modular QoS
Com m and- Line I nt erface ( MQC) , was int roduced in Cisco I OS Release 12.0( 5) T.

Three m ain com ponent s m ake up t he MQC:

cla ss- m a p A classificat ion filt er defined wit hin t he policy m ap t o ident ify t raffic for
preferent ial or deferent ial t reat m ent . Traffic can be ident ified by I PP or DSCP, nam ed or
num bered access cont rol list s ( ACLs) , Net work- Based Applicat ion Recognit ion ( NBAR) ,
Layer 2 param et ers ( CoS, FR DE, ATM cell loss priorit y [ CLP] , MPLS Experim ent al [ EXP]
value) , or a com binat ion of t hese.

policy- m a p A st at em ent t hat defines how each t raffic t ype, as ident ified by t he class
m ap( s) , should be serviced. Opt ions include m arking/ re- m arking, policing, shaping, low-
lat ency or class- based weight ed fair queuing, select ive dropping, and header com pression.

se r vice - policy A st at em ent t hat binds t he policy t o an int erface and specifies direct ion.

Exam ple 1- 1 dem onst rat es a sam ple MQC policy. This is j ust an exam ple of a possible
configurat ion; t he significance of t he com m ands used in t his exam ple is explained in subsequent
chapt ers.

Ex a m ple 1 - 1 . M QC Policy

Router(config)# class-map match-any CRITICAL-DATA

 Router(config-cmap)# match protocol http url "*customer*"
Router(config-cmap)# match protocol citrix
Router(config)# policy-map WAN-EDGE
Router(config-pmap)# class CRITICAL-DATA
Router(config-pmap-c)# bandwidth 1000
Router(config)# interface Serial 0/0
Router(config-if)# service-policy output WAN-EDGE

QoS Baseline
Alt hough MQC was a m aj or st ep in sim plifying QoS feat ures, it addressed only t he user int erface
elem ent of QoS deploym ent . Anot her fact or in t he com plexit y of QoS deploym ent is t he
inconsist ency of QoS feat ures across specific hardware plat form releases or soft ware releases.

I n 2002, a series of int ernal Cisco init iat ives, dubbed Technology Baselines, was launched t o
address t he inconsist ency of which feat ures exist on which plat form s. Specific t o QoS, t he QoS
Baseline is a st rat egic int ernal docum ent writ t en by Cisco's m ost qualified QoS expert s, each of
whom had cont ribut ed t o m ult iple QoS RFCs and so was best qualified t o int erpret t hese
st andards in addit ional det ail. The QoS Baseline was developed wit h t wo prim ary goals:

To docum ent which QoS feat ures are required on plat form s t hat are considered QoS-
enabled product s

To provide a gap analysis of which feat ures, deem ed im port ant by t he baseline, exist ed on
what plat form s

I n part , t he Cisco QoS Baseline is aim ed at producing higher- qualit y new product s, predict able
QoS feat ure set s across product s, and im proved consist ency of QoS feat ures across plat form s.
To t hat end, it provides engineers who are developing new product s wit h a reference list of QoS
feat ures t hat t hey m ust include and t est . For exist ing plat form s, it provides a gap analysis t hat is
used t o st eer product roadm aps t o achieve QoS baseline com pliance.

Beyond it s engineering influence, t he overall obj ect ive of t he QoS Baseline is t o unify QoS wit hin
Cisco: from service provider t o ent erprise, from engineering t o m arket ing. For exam ple, t he
concept of t raffic classificat ion inevit ably begs t he quest ion of how m any classes of t raffic t here
should be. MQC support s up t o 256 different t raffic classes wit hin a policy m ap. Alt hough adept
QoS adm inist rat ors m ight see t his as desirable, t hose who are new t o QoS and have no idea how
m any classes of t raffic t hey need in t heir net works m ight view it as daunt ing.

To address t he needs of t he bot h expert and casual QoS users, t he QoS Baseline defines a set of
class t em plat e recom m endat ions t hat can be eit her be im plem ent ed " as is" or cust om ized t o
individual needs. I t gives a st art ing point for net work design and im plem ent at ion, and it provides
a basis for com parable product t est ing and perform ance report ingbot h of which significant ly
sim plify t he im plem ent at ion of QoS in a net work.

The QoS Baseline defines up t o 11 classes of t raffic t hat are used in all Cisco design guides,
configurat ion exam ples, and t est ing suit es. The QoS Baseline does not dict at e t hat every
ent erprise deploy all t hese t raffic classes im m ediat ely. The set of 11 classes is designed t o
accom m odat e t he QoS needs of an ent erprise not only for t oday, but also for t he foreseeable
fut ure. Even if an ent erprise needs only a handful of t hese 11 classes t oday, following t he QoS
Baseline recom m endat ions will enable it t o sm oot hly im plem ent addit ional t raffic classes in t he
fut ure.
Table 1- 1 gives a sum m ary of t he QoS Baseline recom m endat ions.

Ta ble 1 - 1 . QoS Ba se lin e Re com m e n da t ion s

D SCP
Bin a r y
PH B D SCP Va lu e Re fe r e n ce I n t e n de d Pr ot ocols Con figu r a t ion

EF EF 101110 RFC 3246 I nt eract ive voice Adm ission cont rol =
RSVP
Queuing = priorit y

AF1 AF11 001010 RFC 2597 Bulk t ransfers, web, Queuing = rat e based
AF12 001100 general dat a service Act ive queue
AF13 001110 m anagem ent = DSCP-
based WRED

AF2 AF21 010010 RFC 2597 Dat abase access, Queuing = rat e based
AF22 010100 t ransact ion services, Act ive queue
AF23 010110 int eract ive t raffic, m anagem ent = DSCP-
preferred dat a service based WRED
AF3 AF31 011010 RFC 2597 Locally defined; Queuing = rat e based
AF32 011100 m ission- crit ical Act ive queue
AF33 011110 applicat ions m anagem ent = DSCP-
based WRED
AF4 AF41 100010 RFC 2597 I nt eract ive video and Adm ission cont rol =
AF42 100100 associat ed voice RSVP
AF43 100110 Queuing = rat e based
Act ive queue
m anagem ent =
DSCP- based WRED
I P rout ing Class 6 110000 RFC 2474 BGP, OSPF, and so on Queuing = rat e based
sect ion Sm all guarant eed
4.2.2 m inim um rat e
Act ive queue
m anagem ent = WRED
St ream ing Class 100000 RFC 2474 Oft en propriet ary Adm ission cont rol =
video Select or sect ion RSVP
4 4.2.2 Queuing = rat e based
Act ive queue
m anagem ent = WRED
Telephony Class 011000 RFC 2474 SI P, H.323, and so on Queuing = rat e based
signaling Select or sect ion Sm all guarant eed
( voice and 3 4.2.2 m inim um rat e
video) Act ive queue
m anagem ent = WRED
 D SCP
Bin a r y
PH B D SCP Va lu e Re fe r e n ce I n t e n de d Pr ot ocols Con figu r a t ion

Net work Class 010000 RFC 2474 SNMP Queuing = rat e based
m anagem ent Select or sect ion Sm all guarant eed
2 4.2.2 m inim um rat e
Act ive queue
m anagem ent = WRED
Scavenger I 2SS or 001000 I nt ernet 2 User- select ed service Queuing = rat e based
Class usage No bandwidt h
Select or guar ant ee
1 Act ive queue
m anagem ent = WRED
Ot her Default 000000 RFC 2474 Unspecified t raffic Queuing = rat e based
or Class sect ion 4.1 Minim al bandwidt h
Select or guar ant ee
0 Act ive queue
m anagem ent or
Per- flow fair queuing
Act ive queue
m anagem ent = WRED

Default Behavior
The next st ep in t he t rend t oward sim plificat ion was for t he net work nodes " t o do t he right
t hing." Through a series of changes in Cisco I OS Soft ware and select ed nonCisco I OS product s
( such as I P phones) , voice packet s now are m arked by default t o t he recom m ended value of
DSCP EF. These adj ust m ent s in t he default behavior elim inat e t he need for access list s and
explicit m arking configurat ions t hat were required in earlier soft ware releases. These changes
are discussed in m ore det ail in Chapt er 3, " Classificat ion and Marking Tools."

Cross-Platform Feature Consistency

An addit ional obj ect ive in t he sim plificat ion of QoS ( beyond synt ax and aut om at ion) is t o
im prove t he operat ional and sem ant ic feat ure consist ency across plat form s.

As part of t his effort , Cisco is consolidat ing and im proving t he QoS code bases of t he dist ribut ed
rout er archit ect ures ( such as t he Cisco 7500 series of rout ers) and t he nondist ribut ed rout er
fam ilies ( such as t he Cisco 7200 t o 1700 series rout ers) . This init iat ive is called Consist ent QoS
Behav ior code and should rem ove m ost ( if not all) of t he t radit ional QoS idiosyncrasies bet ween
t he dist ribut ed and nondist ribut ed plat form s.

Such proj ect s are ongoing, as t he applicat ion drivers for QoS cont inue t o dem and unique
feat ures for specific scenarios, but adm inist rat ors generally prefer QoS consist ency and
sim plicit y.

Automatic QoS
Aut om at ic QoS ( Aut oQoS) is essent ially an int elligent m acro t hat enables an adm inist rat or t o
ent er one or t wo sim ple Aut oQoS com m ands t o enable all t he appropriat e feat ures for t he
recom m ended QoS set t ings for an applicat ion on a specific int erface.

For exam ple, in it s first release, Aut oQoS VoI P would provide best - pract ice QoS configurat ions
for VoI P on Cisco Cat alyst swit ches and rout ers. By ent ering one global or one int erface
com m and ( depending on t he plat form ) , t he Aut oQoS VoI P m acro t hen would expand t hese
com m ands int o t he recom m ended VoI P QoS configurat ions ( com plet e wit h all t he calculat ed
param et ers and set t ings) for t he plat form and int erface on which t he Aut oQoS is applied.

Aut oQoS is available on bot h LAN and WAN Cisco Cat alyst swit ches and Cisco I OS rout ers. I n it s
init ial version, however, Aut oQoS applies only t o VoI P deploym ent s.

For cam pus Cat alyst swit ches, Aut oQoS perform s t he following aut om at ically:

Enforces a t rust boundary at Cisco I P phones

Enforces a t rust boundary on Cat alyst swit ch access port s and uplinks/ downlinks

Enables Cat alyst st rict priorit y queuing for voice and weight ed round- robin queuing for dat a
t raffic

Modifies queue adm ission crit eria ( such as CoS- t o- queue m apping)

Modifies queue sizes and queue weight s, where required

Modifies CoS- t o- DSCP and I P precedence- t o- DSCP m appings

For Cisco I OS rout ers, Aut oQoS is support ed on Fram e Relay, ATM, HDLC, Point - t o- Point Prot ocol
( PPP) , and Fram e Relay- t o- ATM links. I t perform s t he following aut om at ically:

Classifies and m arks VoI P bearer t raffic ( t o DSCP EF) and call- signaling t raffic ( originally t o
DSCP AF31, but m ore recent ly t o CS3)

Applies scheduling:

- Low- lat ency queuing ( LLQ) for voice

- Class- based weight ed fair queuing ( CBWFQ) for call signaling

- Fair queuing ( FQ) for all ot her t raffic

Enables Fram e Relay t raffic shaping wit h opt im al param et ers, if required

Enables Link Fragm ent at ion and I nt erleaving ( eit her MLPPP LFI or FRF.12) on slow links
( t hose less t han or equal t o 768 kbps) , if required

Enables I P RTP header com pression ( cRTP) , if required

Provides RMON alert s of VoI P packet s t hat are dropped

The first phase of Aut oQoS on t he Cisco I OS rout er plat form s is available in Cisco I OS Release
12.2( 15) T.

I n it s second releasefor Cisco I OS rout ers onlyAut oQoS Ent erprise det ect s and provisions for up
t o 10 ( of t he 11 QoS Baseline) t raffic classes. ( The only class t hat is not assigned aut om at ically
is Locally- Defined Mission- Crit ical because it is defined subj ect ively by net work adm inist rat ors
and varies from one ent erprise t o t he next .)

The Aut oQoS Ent erprise feat ure sim plifies QoS im plem ent at ion and speeds t he provisioning of
QoS for voice, video, and dat a over a Cisco net work. I t reduces hum an error and lowers t raining
cost s. Aut oQoS Ent erprise creat es class m aps and policy m aps on t he basis of Cisco experience
and best - pract ices m et hodology, such as t hat docum ent ed in t his book. Cust om ers also can use
exist ing Cisco I OS com m ands t o m odify t he configurat ions t hat aut om at ically are generat ed by
t he Aut oQoS Ent erprise feat ure, t o m eet specific requirem ent s.

The Aut oQoS Ent erprise feat ure consist s of t wo configurat ion phases, com plet ed in t he following
order:

1 . Au t odiscove r y ( da t a colle ct ion ) The aut odiscovery phase uses prot ocol discovery based
on Net work- Based Applicat ion Recognit ion ( NBAR) t o det ect t he applicat ions on t he
net work and perform st at ist ical analysis on t he net work t raffic.

2 . Au t oQoS t e m pla t e ge n e r a t ion a n d in st a lla t ion This phase generat es t em plat es from
t he dat a collect ed during t he aut odiscovery phase and inst alls t he t em plat es on t he
int erface. These t em plat es t hen are used as t he basis for creat ing t he class m aps and
policy m aps for t he net work. Aft er t he class m aps and policy m aps are creat ed, t hey are
inst alled on t he relevant int erface( s) .

Table 1- 2 shows t he classes of t raffic aut om at ically det ect ed and provisioned for by Aut oQoS
Ent erprise, com plet e wit h t heir QoS Baseline recom m ended m arkings.

Ta ble 1 - 2 . Au t oQoS En t e r pr ise Cla ss D e fin it ion s a n d M a r k in g

Au t oQoS Cla ss
Nam e Tr a ffic Type D SCP Va lu e

I P Rout ing Net work- cont rol t raffic, such as rout ing CS6
prot ocols
I nt eract ive Voice I nt eract ive voice- bearer t raffic EF

I nt eract ive Video I nt eract ive video- dat a t raffic AF41

St ream ing Video St ream ing m edia t raffic CS4

Telephony Signaling Telephony signaling and cont rol t raffic AF31 or CS3
Transact ional/ I nt eract ive Dat abase applicat ions t ransact ional in nat ure AF21

Net work Managem ent Net work- m anagem ent t raffic CS2

Bulk Dat a Bulk dat a t ransfers, web t raffic, general dat a AF11
service

Scavenger Casual ent ert ainm ent , rogue t raffic ( t raffic in CS1
t his cat egory is given less- t han best - effort
t reat m ent )

Best Effort Default class, all noncrit ical t raffic, HTTP, all 0
m iscellaneous t raffic
This second phase of Aut oQoS becam e available in Cisco I OS Release 12.3( 7) T.
If I Have AutoQoS, Why Should I Be Reading This
Book?
I t is im port ant t o keep in m ind not only t he evolut ion of QoS, but also, m ore specifically, t hat of
Aut oQoS.

I n t he lat e 1990s, crit ical QoS feat ures for enabling t he convergence of voice and dat a net works,
such as low- lat ency queuing ( LLQ) , Link Fragm ent at ion and I nt erleaving ( LFI ) , Cat alyst queuing,
and t rust were developed and released wit hin Cisco I OS and wit hin Cat alyst hardware/ soft ware.

Despit e t he recognit ion t hat t hese feat ures could enable net work convergence, m any cust om ers
were slow t o adopt and deploy t hese t echnologies. Mainly, t his was because t hey were at a loss
for how best t o deploy such QoS m echanism s t o achieve t he end- t o- end service levels t hat VoI P
required. Many " nerd- knobs" wit hin t he QoS t oolset could be t urned and t uned, and overall t he
t ools were com plex and disparat e, and required an in- dept h underst anding t o be used
effect ively.

To address t his barrier t o adopt ion, a sm all group of dedicat ed t echnical m arket ing engineers
wit hin a Cisco solut ions engineering t eam was t asked wit h figuring out how best t o deploy QoS
for converged voice and dat a net works and publishing a best - pract ices design guide t hat
cust om ers could use as a reference. To accom plish t his m andat e, t hey built t he largest
net working lab wit hin Cisco t o run ext ensive scale t est s of QoS feat ures on various hardware and
soft ware plat form s.

Unlike convent ional regression t est ing of QoS feat ures, t his t eam used a different approach:
They t est ed QoS feat ures not in isolat ion, but in conj unct ion wit h t he m any ot her feat ures t hat
t ypically would be deployed wit hin a large ent erprise environm ent . For exam ple, QoS t ools were
enabled sim ult aneously wit h availabilit y t ools, m ult icast t ools, and securit y and encrypt ion t ools.
The obj ect ive was t o m ake t he t est s as represent at ive of real- life ent erprise environm ent s as
possible.

The result s from t hese ext ensive t est s were sum m arized and published in lat e 1999 as t he QoS
Design Guide. This docum ent quickly becam e one of t he m ost downloaded t echnical docum ent s
ever published by Cisco. Cust om ers finally had not only t he t ools t o achieve convergence of t heir
voice and dat a net works, but also t he verified design guidance t o do so wit h confidence.

Nonet heless, at around 200 pages, t he configurat ion- rich QoS Design Guide was a serious read
t hat t ook a long t im e for m ost net work adm inist rat ors t o fully absorb. Furt herm ore, it indirect ly
highlight ed how difficult it was t o enable end- t o- end QoS across a single vendor's ( Cisco's)
product s. There were far t oo m any plat form - specific idiosyncrasies t o keep in m ind, as far as
m ost net work adm inist rat ors were concerned.

Thus, t o sim plify t he process, t he solut ions engineering t eam engaged wit h various t echnology
groups and business unit s wit hin Cisco t o drive t he aut om at ion of t hese best - pract ice
recom m endat ions. The response was very favorable, and t he result was Aut oQoS VoI P for t he
cam pus and WAN. Aut oQoS VoI P is a cross- plat form feat ure t hat is t arget ed t o cust om ers who
want t o deploy QoS for VoI P quickly and accurat ely, wit hout t he requirem ent of ext ensive
knowledge of QoS.

As wit h all t echnical papers, t he QoS Design Guide needed t o be updat ed and expanded aft er a
couple years. During t his t im e, cust om ers increasingly were st ruggling wit h how best t o deploy
QoS for videoconferencing and different t ypes of dat a applicat ions. Therefore, t he scope of t he
original design guide was expanded t o include t hese applicat ions, and a second version of t he
docum ent was released in August 2002. At t he t im e, all design guides originat ing from t he
solut ions engineering t eam were rebadged as Solut ion Reference Net work Designs ( SRNDs) , t o
set t hem apart from t he m any ( oft en unverified and not scale- t est ed) design guides available on
Cisco.com . Thus, t he second version of t his docum ent was t it led t he Ent erprise QoS SRND.

Short ly t hereaft er, t he QoS Baseline was com plet ed and released int ernally. Because t he QoS
Baseline conflict ed wit h som e of t he ( DSCP m arking) recom m endat ions published in t he QoS
SRND, it t ook precedence and required t he Ent erprise QoS SRND t o be rewrit t en t o be com pliant
wit h t he QoS Baseline. This caused changes in t he docum ent because t he m arking
recom m endat ions put forward in t he Ent erprise QoS SRND reflect ed t he best pract ices for an
ent erprise, but not necessarily for a service provider. As t he lines bet ween ent erprise and service
provider are not only blurring but also requiring a level of cooperat ion previously unprecedent ed
( as discussed in addit ional det ail in Chapt er 15, " MPLS VPN QoS Design" ) , it is im port ant for a
single set of m arking recom m endat ions t o be used for bot h ent erprise and service provider
design guides.

Following t his, Cisco I OS developm ent com bined t he best pract ices put forward in t he QoS
design guides wit h t he classificat ion and m arking recom m endat ions defined in t he QoS Baseline,
and released Aut oQoSEnt erprise for t he WAN. Aut oQoS Ent erprise, sim ilar t o Aut oQoS VoI P, is
t arget ed at cust om ers who want t o enable QoS for voice, video, and m ult iple classes of dat a
quickly and accurat ely over t heir WANs, wit hout requiring an ext ensive knowledge of QoS
configurat ion and operat ion.

So why is t his relevant ? This brief hist ory was given t o describe t he cycles required in Aut oQoS
evolut ion, illust rat ed in Figure 1- 7 .

Figu r e 1 - 7 . Au t oQoS Evolu t ion

Specifically, Aut oQoS evolut ion depends on t wo prerequisit es:

QoS feat ure developm ent

Verified net work design guides

The Continuing Evolution of QoS
As a t echnology, QoS is st ill evolving, wit h new feat ures cont inually being developed. Likewise,
t he role of QoS is evolving.

Specifically, following t he developm ent of advanced hardware policers wit hin t he Cat alyst
swit ching plat form s, such as per- port / per- VLAN policers, dual- rat e policers, and user- based
m icroflow policers, new cont ext s for t he use of QoS t ools have becom e possible. These include
t he use of QoS as a t echnology not only t o enable convergence, but also t o increase
securit yespecially in relat ion t o t he exponent ially increasing num ber of DoS and worm at t acks
experienced by cust om ers since 2000.

Therefore, t his book, which represent s t he t hird generat ion of t he Cisco QoS design guides,
det ails t he role of QoS t echnologies in prot ect ing voice, video, and crit ical dat a, and how t hese
t ools can be used t o m it igat e DoS and worm at t acks.

As QoS cont inues t o evolve, it is t he goal of t he aut hors t hat as net works increasingly adopt
t hese recom m ended designs, t hey will be aut om at ed t hrough a fut ure release of Aut oQoS.

Therefore, t he value in reading t his book is t o learn t he rat ionale behind t he best pract ices t hat
went int o Aut oQoS VoI P and Aut oQoS Ent erprise developm ent , and t o go beyond t hese cont ext s
and see t he next - generat ion st rat egic role of QoS t echnologies.
Summary
This chapt er briefly reviewed t he fundam ent al concept s of QoS, such as I nt Serv and DiffServ;
t he cat egories of QoS t ools t hat exist , and why t hey are cat egorized in t his way; t he Modular
QoS CLI t hat pulls t oget her t he use and configurat ion of various QoS t ools, m aking it clearer how
and where t hey int eract ; t he QoS Baseline; and Aut om at ic QoS Cisco init iat ives. This chapt er
also int roduced t he QoS Baseline 11 classes of t raffic, including t he less- t han best - effort
Scavenger class.

You are now ready t o get int o t he principles of QoS design and t hen review salient det ails of t he
QoS t oolset . Chapt er 2, " QoS Design Overview," int roduces QoS design principles and obj ect ives.
Chapt ers 3 t hrough 9 provide a m ore in- dept h discussion of t he various QoS t ool cat egories, t he
specific t ools in each, and how and where t hese should be applied. Chapt ers 10 t hrough 16
provide design exam ples of how t hese t ools are deployed in specific t ypes of net works. These
net work t ypes are included in t hese discussions:

LAN QoS design

WAN QoS design, covering bot h rem ot e office and WAN aggregat or designs

MPLS and I PSec VPN QoS design

The obj ect ive of t his book is not t o discuss every QoS feat ure in isolat ionplent y of m at erial
available in t he indust ry accom plishes t his. The goal inst ead is t o show how t hese t echniques are
used in a holist ic net work design t o achieve end- t o- end QoS for t he ent ire net work. Anot her
obj ect ive of t his book is t o show how t o deploy QoS not only for purposes such as m aint aining
voice qualit y for VoI P calls, but also t o show how QoS can be used t o achieve such goals as
prot ect ing t he net work against denial- of- service ( DoS) at t acks and m anaging t raffic flows t o
keep unwant ed t raffic ( such as copyright - infringing m usic file- sharing applicat ions) off t he
net work.
Further Reading
General

I P Qualit y of Service. Srinivas Vegesna. I ndianapolis: Cisco Press, 2001.

Cisco Cat alyst QoS: Qualit y of Service in Cam pus Net works. Michael Flannagan and Kevin
Turek. I ndianapolis: Cisco Press, 2003.

Cisco DQOS Exam Cert ificat ion Guide. Wendell Odom , Michael Cavanaugh. I ndianapolis:
Cisco Press, 2003.

Com m unicat ions Convergence.com : ht t p: / / www.cconvergence.com .

Com m Web Tech Library: ht t p: / / t echlibrary.com m web.com / dat a/ web/ cweb/ cweb_index.j sp
.

Cisco.com QoS page: ht t p: / / www.cisco.com / go/ qos .

IntServ

I nt Serv is described by a series of RFCs from t he I nt Serv I ETF working group.

RFC 1633, " I nt egrat ed Services in t he I nt ernet Archit ect ure: An Overview" :
ht t p: / / www.iet f.org/ rfc/ rfc1633.t xt .

RFC 2205, " Resource Reservat ion Prot ocol ( RSVP) Version 1 Funct ional Specificat ion" :
ht t p: / / www.iet f.org/ rfc/ rfc2205.t xt .

RFC 2210, " The Use of RSVP wit h I ETF I nt egrat ed Services" :
ht t p: / / www.iet f.org/ rfc/ rfc2210.t xt .

RFC 2211, " Specificat ion of t he Cont rolled- Load Net work Elem ent Service" :
ht t p: / / www.iet f.org/ rfc/ rfc2211.t xt .

RFC 2212, " Specificat ion of Guarant eed Qualit y of Service" :

ht t p: / / www.iet f.org/ rfc/ rfc2212.t xt .

RFC 2215, " General Charact erizat ion Param et ers for I nt egrat ed Service Net work
Elem ent s" : ht t p: / / www.iet f.org/ rfc/ rfc2215.t xt .

DiffServ

DiffServ is described by a series of RFCs from t he DiffServ I ETF working group.

RFC 2474, " Definit ion of t he Different iat ed Services Field ( DS Field) in t he I Pv4 and I Pv6
 Headers" : ht t p: / / www.iet f.org/ rfc/ rfc2474.t xt .

RFC 2475, " An Archit ect ure for Different iat ed Services" : ht t p: / / www.iet f.org/ rfc/ rfc2475.t xt
.

RFC 2597, " Assured Forwarding PHB Group" : ht t p: / / www.iet f.org/ rfc/ rfc2597.t xt .

RFC 2598, " An Expedit ed Forwarding PHB" : ht t p: / / www.iet f.org/ rfc/ rfc2598.t xt .

RFC 2697, " A Single Rat e Three Color Marker" : ht t p: / / www.iet f.org/ rfc/ rfc2697.t xt .

RFC 2698, " A Two Rat e Three Color Marker" : ht t p: / / www.iet f.org/ rfc/ rfc2698.t xt .

RFC 3168, " Explicit Congest ion Not ificat ion ( ECN) t o I P" :
ht t p: / / www.iet f.org/ rfc/ rfc3168.t xt .

RFC 3246, " An Expedit ed Forwarding PHB" ( replacing RFC 2598) :

ht t p: / / www.iet f.org/ rfc/ rfc3246.t xt .

AutoQoS

Aut oQoS VoI P for Cisco I OS rout er plat form s, Cisco I OS Release 12.2( 15) T docum ent at ion:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 15/ ft aut oq1.ht m
.

Aut oQoS Ent erprise for Cisco I OS rout er plat form s, Cisco I OS Release 12.3( 7) T docum ent at ion:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios123/ 123newft / 123t / 123t _7/ ft aut oq2.ht m
.

Aut oQoS VoI P, Cat alyst 2950, Cat alyst I OS version 12.1( 19) EA1:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 2950/ 12119ea1/ 2950scg/ swqos.ht m # 112541
.

Aut oQoS VoI P, Cat alyst 2970, Cat alyst I OS version 12.1( 19) EA1:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 2970/ 12119ea1/ 2970scg/ swqos.ht m # 123111
.

Aut oQoS VoI P, Cat alyst 3550, Cat alyst I OS version 12.1( 19) EA1:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ c3550/ 12119ea1/ 3550scg/ swqos.ht m # 1185065

Aut oQoS VoI P, Cat alyst 3750, Cat alyst I OS version 12.1( 19) EA1:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 3750/ 12119ea1/ 3750scg/ swqos.ht m # 123111
.

Aut oQoS VoI P, Cat alyst 4500, Cat alyst I OS version 12.2( 18) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 4000/ 12_2_18/ config/ qos.ht m # 1281380

Aut oQoS VoI P, Cat alyst 6500, Cat alyst Cat OS version 8.2:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 6000/ sw_8_2/ confg_gd/ aut oqos.ht m .
Chapter 2. QoS Design Overview
This chapt er provides an overview of t he QoS design and deploym ent process. This process
requires business- level obj ect ives of t he QoS im plem ent at ion t o be defined clearly and for t he
service- level requirem ent s of applicat ions t o be assigned preferent ial or deferent ial t reat m ent so
t hat t hey can be analyzed.

These ent erprise applicat ions wit h unique QoS requirem ent s are discussed in t his chapt er:

Voice

Call- Signaling

I nt eract ive- Video

St ream ing- Video

Best - Effort Dat a

Bulk Dat a

Transact ional Dat a

Mission- Crit ical Dat a

I P Rout ing t raffic

Net work- Managem ent t raffic

Scavenger t raffic

Addit ionally, key QoS design and deploym ent best pract ices t hat can sim plify and expedit e QoS
im plem ent at ions are present ed, including t hese:

Classificat ion and m arking principles

Policing and m arkdown principles

Queuing and dropping principles

DoS and worm m it igat ion principles

Deploym ent principles

More t han j ust a working knowledge of QoS t ools and synt ax is needed t o deploy end- t o- end
QoS in a holist ic m anner. First , it is vit al t o underst and t he service- level requirem ent s of t he
various applicat ions t hat require preferent ial ( or deferent ial) t reat m ent wit hin t he net work.
Addit ionally, a num ber of QoS design principles t hat ext ensive lab t est ing and cust om er
deploym ent s have helped shape can st ream line a QoS deploym ent and increase t he overall
cohesiveness of service levels across m ult iple plat form s.
This chapt er overviews t he QoS requirem ent s of VoI P, Video ( bot h I nt eract ive- Video and
St ream ing- Video) , and m ult iple classes of dat a. Wit hin t his discussion, t he QoS requirem ent s of
t he cont rol plane ( rout ing and m anagem ent t raffic) are considered. The Scavenger class is
exam ined in m ore det ail, and a st rat egy for m it igat ing DoS and worm at t acks is present ed.

Next , QoS design principles relat ing t o classificat ion, m arking, policing, queuing, and deploym ent
are discussed. These serve as guiding best pract ices in t he design chapt ers t o follow.
QoS Requirements of VoIP
VoI P deploym ent s require t he provisioning of explicit priorit y servicing for VoI P ( bearer st ream )
t raffic and a guarant eed bandwidt h service for Call- Signaling t raffic. These relat ed classes are
exam ined separat ely.

Voice (Bearer Traffic)

The following list sum m arizes t he key QoS requirem ent s and recom m endat ions for voice ( bearer
t raffic) :

Voice t raffic should be m arked t o DSCP EF per t he QoS Baseline and RFC 3246.

Loss should be no m ore t han 1 percent .

One- way lat ency ( m out h t o ear) should be no m ore t han 150 m s.

Average one- way j it t er should be t arget ed at less t han 30 m s.

A range of 21 t o 320 kbps of guarant eed priorit y bandwidt h is required per call ( depending
on t he sam pling rat e, t he VoI P codec, and Layer 2 m edia overhead) .

Voice qualit y direct ly is affect ed by all t hree QoS qualit y fact ors: loss, lat ency, and j it t er.

Loss

Loss causes voice clipping and skips. Packet loss concealm ent ( PLC) is a t echnique used t o m ask
t he effect s of lost or discarded VoI P packet s. The m et hod of PLC used depends upon t he t ype of
codec. A sim ple m et hod used by waveform codecs such as G.711 ( PLC for G.711 is defined in
G.711 Appendix I ) is t o replay t he last received sam ple wit h increasing at t enuat ion at each
repeat ; t he waveform does not change m uch from one sam ple t o t he next . This t echnique can
be effect ive at concealing t he loss of up t o 20 m s of sam ples.

The packet izat ion int erval det erm ines t he size of sam ples cont ained wit hin a single packet .
Assum ing a 20- m s ( default ) packet izat ion int erval, t he loss of t wo or m ore consecut ive packet s
result s in a not iceable degradat ion of voice qualit y. Therefore, assum ing a random dist ribut ion of
drops wit hin a single voice flow, a drop rat e of 1 percent in a voice st ream would result in a loss
t hat could not be concealed every 3 m inut es, on average. A 0.25 percent drop rat e would result
in a loss t hat could not be concealed once every 53 m inut es, on average.

N ot e
A decision t o use a 30- m s packet izat ion int erval, for a given probabilit y of packet loss,
could result in worse perceived call qualit y t han for 20 m s because PLC could not
effect ively conceal t he loss of a single packet .
Low- bit - rat e, fram e- based codecs, such as G.729 and G.723, use m ore sophist icat ed PLC
t echniques t hat can conceal up t o 30 t o 40 m s of loss wit h " t olerable" qualit y when t he available
hist ory used for t he int erpolat ion is st ill relevant .

Wit h fram e- based codecs, t he packet izat ion int erval det erm ines t he num ber of fram es carried in
a single packet . As wit h waveform - based codecs, if t he packet izat ion int erval is great er t han t he
loss t hat t he PLC algorit hm can int erpolat e for, PLC cannot effect ively conceal t he loss of a single
packet .

VoI P net works t ypically are designed for very close t o 0 percent VoI P packet loss, wit h t he only
act ual packet loss being due t o L2 bit errors or net work failures.

Latency

Lat ency can cause voice qualit y degradat ion if it is excessive. The goal com m only used in
designing net works t o support VoI P is t he t arget specified by I TU st andard G.114 ( which,
incident ally, is current ly under revision) : This st at es t hat 150 m s of one- way, end- t o- end ( from
m out h t o ear) delay ensures user sat isfact ion for t elephony applicat ions. A design should
apport ion t his budget t o t he various com ponent s of net work delay ( propagat ion delay t hrough
t he backbone, scheduling delay because of congest ion, and access link serializat ion delay) and
service delay ( because of VoI P gat eway codec and dej it t er buffer) .

Figure 2- 1 illust rat es t hese various elem ent s of VoI P lat ency ( and j it t er because som e delay
elem ent s are variable) .

Figu r e 2 - 1 . Ele m e n t s Affe ct in g VoI P La t e n cy a n d Jit t e r

[View full size image]

I f t he end- t o- end voice delay becom es t oo long, t he conversat ion begins t o sound like t wo
part ies t alking over a sat ellit e link or even a CB radio. The I TU G.114 st at es t hat a 150- m s one-
way ( m out h- t o- ear) delay budget is accept able for high voice qualit y, but lab t est ing has shown
t hat t here is a negligible difference in voice qualit y m ean opinion scores ( MOS) using net works
built wit h 200- m s delay budget s. Thus, Cisco recom m ends designing t o t he I TU st andard of 150
m s. I f const raint s exist and t his delay t arget cannot be m et , t he delay boundary can be
ext ended t o 200 m s wit hout significant im pact on voice qualit y.

N ot e
Cert ain organizat ions m ight view higher delays as accept able, but t he corresponding
reduct ion in VoI P qualit y m ust be t aken int o account when m aking such design
decisions.

Jitter

Jit t er buffers ( also known as playout buffers) are used t o change asynchronous packet arrivals
int o a synchronous st ream by t urning variable net work delays int o const ant delays at t he
dest inat ion end syst em s. The role of t he j it t er buffer is t o t rade off bet ween delay and t he
probabilit y of int errupt ed playout because of lat e packet s. Lat e or out - of- order packet s are
discar ded.

I f t he j it t er buffer is set eit her arbit rarily large or arbit rarily sm all, it im poses unnecessary
const raint s on t he charact erist ics of t he net work. A j it t er buffer set t oo large adds t o t he end- t o-
end delay, m eaning t hat less delay budget is available for t he net work; hence, t he net work
needs t o support a t ight er delay t arget t han pract ically necessary. I f a j it t er buffer is t oo sm all t o
accom m odat e t he net work j it t er, buffer underflows or overflows can occur. I n an underflow, t he
buffer is em pt y when t he codec needs t o play out a sam ple. I n an over- flow, t he j it t er buffer is
already full and anot her packet arrives; t hat next packet cannot be enqueued in t he j it t er buffer.
Bot h j it t er buffer underflows and overflows cause voice qualit y degradat ion.

Adapt ive j it t er buffers aim t o overcom e t hese issues by dynam ically t uning t he j it t er buffer size
t o t he lowest accept able value. Well- designed adapt ive j it t er buffer algorit hm s should not im pose
any unnecessary const raint s on t he net work design by doing t he following:

I nst ant ly increasing t he j it t er buffer size t o t he current m easured j it t er value following a

j it t er buffer overflow

Slowly decreasing t he j it t er buffer size when t he m easured j it t er is less t han t he current

j it t er buffer size

Using PLC t o int erpolat e for t he loss of a packet on a j it t er buffer underflow

When such adapt ive j it t er buffers are usedin t heoryyou can " engineer out " explicit considerat ions
of j it t er by account ing for worst - case per- hop delays. Advanced form ulas can be used t o arrive
at net work- specific design recom m endat ions for j it t er ( based on m axim um and m inim um per-
hop delays) . Alt ernat ively, because ext ensive lab t est ing has shown t hat voice qualit y degrades
significant ly when j it t er consist ent ly exceeds 30 m s, t his 30 m s value can be used as a j it t er
t arget .

Because of it s st rict service- level requirem ent s, VoI P is well suit ed t o t he expedit ed forwarding
per- hop behavior, defined in RFC 3246 ( form erly RFC 2598) . Therefore, it should be m arked t o
DSCP EF ( 46) and assigned st rict - priorit y servicing at each node, regardless of whet her such
servicing is done in hardware ( as in Cat alyst swit ches t hrough 1Px Qy T queuing, discussed in
m ore det ail in Chapt er 10, " Cat alyst QoS Tools" ) or in soft ware ( as in Cisco I OS rout ers t hrough
LLQ, discussed in m ore det ail in Chapt er 5, " Congest ion- Managem ent Tools" ) .

The bandwidt h t hat VoI P st ream s consum e ( in bit s per second) is calculat ed by adding t he VoI P
sam ple payload ( in byt es) t o t he 40- byt e I P, UDP, and RTP headers ( assum ing t hat cRTP is not
in use) , m ult iplying t his value by 8 ( t o convert it t o bit s) , and t hen m ult iplying again by t he
packet izat ion rat e ( default of 50 packet s per second) .

Table 2- 1 det ails t he bandwidt h per VoI P flow ( bot h G.711 and G.729) at a default packet izat ion
rat e of 50 packet s per second ( pps) and at a cust om packet izat ion rat e of 33 pps. This does not
include Layer 2 overhead and does not t ake int o account any possible com pression schem es,
such as Com pressed Real- Tim e Transport Prot ocol ( cRTP, discussed in det ail in Chapt er 7, " Link-
Specific Tools" ) .

Ta ble 2 - 1 . Voice Ba n dw idt h ( W it h ou t La ye r 2 Ove r h e a d)

Ba n dw idt h Pa ck e t iza t ion Voice Pa ck e t s Pe r Ba n dw idt h

Con su m pt ion I n t e r va l Pa yloa d Se con d Pe r
in Byt e s Con ve r sa t ion
G.711 20 m s 160 50 80 kbps

G.711 30 m s 240 33 74 kbps

G.729A 20 m s 20 50 24 kbps
G.729A 30 m s 30 33 19 kbps

For exam ple, assum e a G.711 VoI P codec at t he default packet izat ion rat e ( 50 pps) . A new VoI P
packet is generat ed every 20 m s ( 1 second / 50 pps) . The payload of each VoI P packet is 160
byt es; wit h t he I P, UDP, and RTP headers ( 20 + 8 + 12 byt es, respect ively) included, t his packet
becom e 200 byt es in lengt h. Convert ing bit s t o byt es requires m ult iplying by 8 and yields 1600
bps per packet . When m ult iplied by t he t ot al num ber of packet s per second ( 50 pps) , t his arrives
at t he Layer 3 bandwidt h requirem ent for uncom pressed G.711 VoI P: 80 kbps. This exam ple
calculat ion corresponds t o t he first row of Table 2- 1.

N ot e
The Service Param et ers m enu in Cisco CallManager Adm inist rat ion can be used t o
adj ust t he packet rat e. I t is possible t o configure t he sam pling rat e above 30 m s, but
t his usually result s in poor voice qualit y.

A m ore accurat e m et hod for provisioning VoI P is t o include t he Layer 2 overhead, which includes
pream bles, headers, flags, CRCs, and ATM cell padding. The am ount of overhead per VoI P call
depends on t he Layer 2 m edia used:
 802.1Q Et hernet adds ( up t o) 32 byt es of Layer 2 overhead ( when pream bles are
included) .

Point - t o- Point Prot ocol ( PPP) adds 12 byt es of Layer 2 overhead.

Mult ilink PPP ( MLP) adds 13 byt es of Layer 2 overhead.

Fram e Relay adds 4 byt es of Layer 2 overhead; Fram e Relay wit h FRF.12 adds 8 byt es.

ATM adds varying am ount s of overhead, depending on t he cell padding requirem ent s.

Table 2- 2 shows m ore accurat e bandwidt h- provisioning guidelines for voice because it includes
Layer 2 overhead.

Ta ble 2 - 2 . Voice Ba n dw idt h ( I n clu din g La ye r 2

Ove r h e a d)

Fr a m e
Re la y
Ba n dw idt h 8 0 2 .1 Q w it h
Con su m pt ion Et h e r n e t PPP M LP FRF.1 2 ATM

G.711 at 50 93 kbps 84 kbps 86 kbps 84 kbps 106 kbps

pps
G.711 at 33 83 kbps 77 kbps 78 kbps 77 kbps 84 kbps
pps

G.729A at 50 37 kbps 28 kbps 30 kbps 28 kbps 43 kbps

pps

G.729A at 33 27 kbps 21 kbps 22 kbps 21 kbps 28 kbps

pps

Call-Signaling Traffic
The following list sum m arizes t he key QoS requirem ent s and recom m endat ions for Call- Signaling
t raffic:

Call- Signaling t raffic should be m arked as DSCP CS3 per t he QoS Baseline ( during
m igrat ion, it also can be m arked t he legacy value of DSCP AF31) .

150 bps ( plus Layer 2 overhead) per phone of guarant eed bandwidt h is required for voice
cont rol t raffic; m ore m ay be required, depending on t he Call- Signaling prot ocol( s) in use.

Originally, Cisco I P Telephony equipm ent m arked Call- Signaling t raffic t o DSCP AF31. However,
t he assured forwarding classes, as defined in RFC 2597, were int ended for flows t hat could be
subj ect t o m arkdown and aggressive dropping of m arked- down values. Marking down and
aggressively dropping Call- Signaling could result in not iceable delay t o dial t one ( DDT) and
lengt hy call- set up t im es, bot h of which generally t ranslat e int o poor user experiences.

Therefore, t he QoS Baseline changed t he m arking recom m endat ion for Call- Signaling t raffic t o
DSCP CS3 because Class- Select or code point s, defined in RFC 2474, are not subj ect t o such
m arkdown and aggressive dropping as Assured Forwarding Per- Hop Behaviors are.

Som e Cisco I P Telephony product s already have begun t ransit ioning t o DSCP CS3 for Call-
Signaling m arking. I n t his int erim period, bot h code point s ( CS3 and AF31) should be reserved
for Call- Signaling m arking unt il t he t ransit ion is com plet e.

Most Cisco I P Telephony product s use t he Skinny Call- Cont rol Prot ocol ( SCCP) for Call- Signaling.
Skinny is a relat ively light weight prot ocol and, as such, requires only a m inim al am ount of
bandwidt h prot ect ion ( m ost of t he Cisco large- scale lab t est ing was done by provisioning only 2
percent for Call- Signaling t raffic over WAN and VPN links) . However, newer versions of
CallManager and SCCP have shown som e " bloat ing" in t his signaling prot ocol, so design
recom m endat ions have been adj ust ed t o m at ch ( m ost exam ples in t he design chapt ers t hat
follow have been adj ust ed t o allocat e 5 percent for Call- Signaling t raffic) . This is a norm al part of
QoS evolut ion: As applicat ions and prot ocols cont inue t o evolve, so do t he QoS designs required
t o accom m odat e t hem .

Ot her Call- Signaling prot ocols include ( but are not lim it ed t o) H.225 and H.245, t he Session
I nit iat ed Prot ocol ( SI P) , and t he Media Gat eway Cont rol Prot ocol ( MGCP) . Each Call- Signaling
prot ocol has unique TCP and UDP port s and t raffic pat t erns t hat should be t aken int o account
QoS Requirements of Video
Two m ain t ypes of video t raffic exist : I nt eract ive- Video ( videoconferencing) and St ream ing-
Video ( bot h unicast and m ult icast ) . Each t ype of video is exam ined separat ely.

Interactive-Video
When provisioning for I nt eract ive- Video ( video conferencing) t raffic, t he following guidelines are
r ecom m ended:

I nt eract ive- Video t raffic should be m arked t o DSCP AF41; excess videoconferencing t raffic
can be m arked down by a policer t o AF42 or AF43.

Loss should be no m ore t han 1 percent .

One- way lat ency should be no m ore t han 150 m s.

Jit t er should be no m ore t han 30 m s.

Assign I nt eract ive- Video t o eit her a preferent ial queue or a second priorit y queue ( when
support ed) ; when using Cisco I OS LLQ, overprovision t he m inim um - priorit y bandwidt h
guarant ee t o t he size of t he videoconferencing session plus 20 percent . ( For exam ple, a
384- kbps videoconferencing session requires 460 kbps of guarant eed priorit y bandwidt h.)

Because I P videoconferencing ( I P/ VC) includes a G.711 audio codec for voice, it has t he sam e
loss, delay, and delay- variat ion requirem ent s as voicebut t he t raffic pat t erns of
videoconferencing are radically different from t hose of voice.

For exam ple, videoconferencing t raffic has varying packet sizes and ext rem ely variable packet
rat es. These are illust rat ed in Figures 2- 2 and 2 - 3.

Figu r e 2 - 2 . Vide ocon fe r e n cin g Tr a ffic Pa ck e t - Size Br e a k dow n

 Figu r e 2 - 3 . Vide ocon fe r e n cin g Tr a ffic Ra t e s ( 3 8 4 - k bps Se ssion
Ex a m ple )

The videoconferencing rat e is t he sam pling rat e of t he video st ream , not t he act ual bandwidt h
t hat t he video call requires. I n ot her words, t he dat a payload of videoconferencing packet s is
filled wit h 384 kbps of voice plus video sam ples. I P, UDP, and RTP headers ( 40 byt es per packet ,
uncom pressed) need t o be included in I P/ VC bandwidt h provisioning, as does t he Layer 2
overhead of t he m edia in use. Because ( unlike VoI P) I P/ VC packet sizes and rat es vary, t he
header overhead percent age also varies, so an absolut e value of overhead cannot be calculat ed
accurat ely for all st ream s. However, t est ing has shown t hat a conservat ive rule of t hum b for
I P/ VC bandwidt h provisioning is t o assign an LLQ bandwidt h equivalent t o t he I P/ VC rat e plus 20
percent . For exam ple, a 384- kbps I P/ VC st ream adequat ely is provisioned wit h an LLQ of 460
k bps.

N ot e
 The Cisco LLQ algorit hm has been im plem ent ed t o include a default burst param et er
equivalent t o 200 m s of t raffic. Test ing has shown t hat t his burst param et er does not
require addit ional t uning for a single I P videoconferencing ( I P/ VC) st ream . For m ult iple
st ream s, t his burst param et er can be increased as required.

Streaming-Video
When addressing t he QoS needs of St ream ing- Video t raffic, t he following guidelines are
r ecom m ended:

St ream ing- Video ( whet her unicast or m ult icast ) should be m arked t o DSCP CS4, as
designat ed by t he QoS Baseline.

Loss should be no m ore t han 5 percent .

Lat ency should be no m ore t han 4 t o 5 seconds ( depending on t he video applicat ion's
buffering capabilit ies) .

There are no significant j it t er requirem ent s.

Guarant eed bandwidt h ( CBWFQ) requirem ent s depend on t he encoding form at and rat e of
t he video st ream .

St ream ing- Video is t ypically unidirect ional; t herefore, rem ot e branch rout ers m ight not
require provisioning for St ream ing- Video t raffic on t heir WAN or VPN edges ( in t he direct ion
of branch t o cam pus) .

Nonorganizat ional St ream ing- Video applicat ions ( eit her unicast or m ult icast ) , such as
ent ert ainm ent video cont ent , m ay be m arked as ScavengerDSCP CS1, provisioned in t he
Scavenger t raffic class and assigned a m inim al bandwidt h ( CBWFQ) percent age. For m ore
inform at ion, see t he " Scavenger Class" sect ion, lat er in t his chapt er.

St ream ing- Video applicat ions have m ore lenient QoS requirem ent s because t hey are not delay
sensit ive ( t he video can t ake several seconds t o cue up) and are largely not j it t er sensit ive
( because of applicat ion buffering) . However, St ream ing- Video m ight cont ain valuable cont ent ,
such as e- learning applicat ions or m ult icast com pany m eet ings, in which case it requires service
guarant ees.

The QoS Baseline recom m endat ion for St ream ing- Video m arking is DSCP CS4.

An int erest ing considerat ion wit h respect t o St ream ing- Video com es int o play when designing
WAN and VPN edge policies on branch rout ers: Because St ream ing- Video is generally
unidirect ional, a separat e class likely is not needed for t his t raffic class in t he branch- t o- cam pus
direct ion of t raffic flow.

Nonorganizat ional video cont ent ( or video t hat 's st rict ly ent ert ainm ent orient ed in nat ure, such
as m ovies, m usic videos, hum orous com m ercials, and so on) m ight be considered for Scavenger
service, m eaning t hat t hese st ream s will play if bandwidt h exist s, but t hey will be t he first t o go
during periods of congest ion.
QoS Requirements of Data
Hundreds of t housands of dat a applicat ions exist on t he I nt ernet , in all shapes and sizes. Som e
are TCP, ot hers are UDP; som e are delay sensit ive, ot hers are not ; som e are burst y in nat ure,
ot hers are st eady; som e are light weight , ot hers are bandwidt h hogst he list goes on.

Dat a t raffic charact erist ics vary from one applicat ion t o anot her, as illust rat ed in Figure 2- 4 ,
which com pares an ent erprise resource planning ( ERP) applicat ion ( Oracle) wit h anot her ( SAP) .

Figu r e 2 - 4 . D a t a Applica t ion D iffe r e n ce s

To m ake t he m at t er even m ore com plicat ed, it is crucial t o recognize t hat , j ust as applicat ions
vary one from anot her, even t he sam e applicat ion can vary significant ly from one v er sion t o
anot her.

A brief anecdot e speaks t o t his point : Aft er a sout hern California sem iconduct or com pany
provisioned QoS for Voice and Mission- Crit ical Dat a ( SAP R/ 3) , everyt hing went well for about six
m ont hs. At t hat point , users began com plaining of excessive delays in com plet ing basic
t ransact ions. Operat ions t hat previously required a second or less t o com plet e were t aking
significant ly longer. The applicat ion t eam s blam ed t he net working t eam s, claim ing t hat " QoS was
broken." Furt her invest igat ion produced t he inform at ion in t he following graph, shown in Figure
2 - 5.

Figu r e 2 - 5 . D a t a Applica t ion Ve r sion D iffe r e n ce s

[View full size image]

The Mission- Crit ical Dat a applicat ionin t his inst ance, SAPhad been upgraded from version 3.0F t o
4.6C. As a result , a basic order- ent ry t ransact ion required 35 t im es m ore t raffic t han t he original
version. Addit ional provisioning and policy t uning was required t o accom m odat e t he new version
of t he sam e applicat ion.

Given t his realit y, t he quest ion on how best t o provision QoS for dat a is a daunt ing one. Aft er
wrest ling wit h t his quest ion for several years, t he aut hors of t he QoS Baseline cam e up wit h four
m ain classes of dat a t raffic, according t o t heir general net working charact erist ics and
requirem ent s. These classes are Best - Effort , Bulk Dat a, Transact ional Dat a/ I nt eract ive Dat a and
( Locally- Defined) Mission- Crit ical Dat a. Each of t hese classes is exam ined in m ore det ail in t he
following sect ions.

Best-Effort Data
When addressing t he QoS needs of Best - Effort t raffic, t he following guidelines are
r ecom m ended:

Best - Effort t raffic should be m arked t o DSCP 0.

Adequat e bandwidt h should be assigned t o t he Best - Effort class as a whole because t he

m aj orit y of applicat ions default t o t his class. I t is recom m ended t o reserve at least 25
percent for Best - Effort t raffic.

The Best - Effort class is t he default class for all dat a t raffic. Only if an applicat ion has been
select ed for preferent ial or deferent ial t reat m ent is it rem oved from t he default class.

I n 2003, one Wall St reet financial com pany did an ext ensive st udy t o ident ify and cat egorize t he
num ber of different applicat ions on it s net works. I t found m ore t han 3000 discret e applicat ions
t raversing it s infrast ruct ure. Furt her research has shown t hat t his is not uncom m on for larger
ent erprises. Therefore, because ent erprises have several hundredif not t housands ofdat a
applicat ions running over t heir net works ( of which t he m aj orit y default t o t he Best - Effort class) ,
adequat e bandwidt h needs t o be provisioned for t his default class t o handle t he sheer volum e of
applicat ions t hat are included in it . Ot herwise, applicat ions t hat default t o t his class easily are
drowned out , t ypically result ing in an increased num ber of calls t o t he net working help desk from
frust rat ed users. I t is t herefore recom m ended t hat at least 25 percent of a link's bandwidt h be
reserved for t he default Best - Effort class.

Bulk Data
When addressing t he QoS needs of Bulk Dat a t raffic, t he following guidelines are recom m ended:

Bulk Dat a t raffic should be m arked t o DSCP AF11; excess Bulk Dat a t raffic can be m arked
down by a policer t o AF12 or AF13.

Bulk Dat a t raffic should have a m oderat e bandwidt h guarant ee but should be const rained
from dom inat ing a link.

The Bulk Dat a class is int ended for applicat ions t hat are relat ively nonint eract ive and not drop
sensit ive, and t hat t ypically span t heir operat ions over a long period of t im e as background
occurrences. Such applicat ions include FTP, e- m ail, backup operat ions, dat abase synchronizing
or replicat ing operat ions, video cont ent dist ribut ion, and any ot her t ype of applicat ion in which
users t ypically cannot proceed because t hey are wait ing for t he com plet ion of t he operat ion ( in
ot her words, a background operat ion) .

The advant age of provisioning m oderat e bandwidt h guarant ees t o Bulk Dat a applicat ions
( inst ead of applying policers t o t hem ) is t hat Bulk Dat a applicat ions dynam ically can t ake
advant age of unused bandwidt h and t hus can speed up t heir operat ions during nonpeak periods.
This, in t urn, reduces t he likelihood t hat t hey will bleed int o busy periods and absorb inordinat e
am ount s of bandwidt h for t heir non- t im e- sensit ive operat ions.

Transactional Data/Interactive Data

When addressing t he QoS needs of Transact ional Dat a and I nt eract ive Dat a t raffic, t he following
guidelines are recom m ended:

Transact ional Dat a t raffic should be m arked t o DSCP AF21; excess Transact ional Dat a
t raffic can be m arked down by a policer t o AF22 or AF23.

Transact ional Dat a t raffic should have an adequat e bandwidt h guarant ee for t he
int eract ive, foreground operat ions t hat it support s.

The Transact ional Dat a/ I nt eract ive Dat a class is a com binat ion of t wo sim ilar t ypes of
applicat ions: Transact ional Dat a client / server applicat ions and int eract ive m essaging
applicat ions. For t he sake of sim plicit y, t his class is referred t o as Transact ional Dat a only.

The response- t im e requirem ent separat es Transact ional Dat a client / server applicat ions from
generic client / server applicat ions. For exam ple, wit h Transact ional Dat a client / server
applicat ions ( such as SAP, PeopleSoft , and Oracle) , t he user wait s for t he operat ion t o com plet e
before proceeding ( in ot her words, t he t ransact ion is a foreground operat ion) . E- m ail is not
considered a Transact ional Dat a client / server applicat ion because m ost e- m ail operat ions happen
in t he background, and users usually do not not ice even delays of several hundred m illiseconds
in m ailspool operat ions.

Locally Defined Mission-Critical Data

When addressing t he QoS needs of Locally- Defined Mission- Crit ical Dat a t raffic, t he following
guidelines are recom m ended:

Locally- Defined Mission- Crit ical Dat a t raffic should be m arked t o DSCP AF31; excess
 Mission- Crit ical Dat a t raffic can be m arked down by a policer t o AF32 or AF33. However,
Cisco I P Telephony equipm ent current ly is using DSCP AF31 t o m ark Call- Signaling t raffic;
unt il all Cisco I PT product s m ark Call- Signaling t o DSCP CS3, a t em porary placeholder code
point , DSCP 25, can be used t o ident ify Locally- Defined Mission- Crit ical Dat a t raffic.

Locally- Defined Mission- Crit ical Dat a t raffic should have an adequat e bandwidt h guarant ee
for t he int eract ive, foreground operat ions t hat it support s.

The Locally- Defined Mission- Crit ical class is probably t he m ost m isunderst ood class specified in
t he QoS Baseline. Under t he QoS Baseline m odel, all t raffic classes ( wit h t he exclusion of
Scavenger and Best - Effort ) are considered " crit ical" t o t he ent erprise. The t erm locally defined is
used t o underscore t he purpose of t his class: for each ent erprise t o have a prem ium class of
service for a select subset of it s Transact ional Dat a applicat ions t hat have t he highest business
priorit y for it .

For exam ple, an ent erprise m ight have properly provisioned Oracle, SAP, BEA, and Siebel wit hin
it s Transact ional Dat a class. However, t he m aj orit y of it s revenue m ight com e from SAP, so it
m ight want t o give t his Transact ional Dat a applicat ion an even higher level of preference by
assigning it t o a dedicat ed class ( such as t he Locally- Defined Mission- Crit ical class) .

Because t he adm ission crit eria for t his class is nont echnical ( being det erm ined by business
relevance and organizat ional obj ect ives) , t he decision about which applicat ion( s) should be
assigned t o t his special class easily can becom e an organizat ionally and polit ically charged
debat e. I t is recom m ended t o assign as few applicat ions t o t his class ( from t he Transact ional
Dat a class) as possible. I n addit ion, it is recom m ended t hat execut ive endorsem ent for
applicat ion assignm ent s t o t he Locally- Defined Mission- Crit ical class be obt ained: The pot ent ial
for QoS deploym ent derailm ent exist s wit hout such an endorsem ent .

For t he sake of sim plicit y, t his class is referred t o sim ply as Mission- Crit ical Dat a.

Based on t hese definit ions, Table 2- 3 shows som e applicat ions and t heir generic net working
charact erist ics, which det erm ine what dat a applicat ion class t hey are best suit ed t o.

Ta ble 2 - 3 . D a t a Applica t ion s by Cla ss

Applica t ion Applica t ion / Tr a ffic Pa ck e t / M e ssa ge

Cla ss Ex a m ple Applica t ion s
I nt eract ive Telnet , Cit rix, Oracle Thin-
PHB: AF2 Client s, AOL I nst ant
Messenger, Yahoo! I nst ant
Messenger, PlaceWare
( Conference) , Net m eet ing
Whit eboard.
Transact ional SAP, PeopleSoft Vant ive,
PHB: AF2 OracleFinancials, I nt ernet
Procurem ent , B2B, Supply
Chain Managem ent ,
Applicat ion Server, Oracle
8i Dat abase, Ariba Buyer,
I 2, Siebel, E.piphany,
Broadvision, I BM Bus 2
Bus, Microsoft SQL, BEA
Pr ope r t ie s Size s
Highly int eract ive Average m essage
applicat ions wit h t ight size < 100 byt es.
user- feedback Max m essage size
requirem ent s. < 1 KB.
Transact ional applicat ions Depends on
t ypically use a applicat ion; could
client / server prot ocol be anywhere from
m odel. 1 KB t o 50 MB.
User- init iat ed, client - based
queries are followed by
server response. The query
response can consist of
m any m essages bet ween
Applica t ion Applica t ion / Tr a ffic Pa ck e t / M e ssa ge
Cla ss Ex a mMicrosoft
Bus, ple Applica
SQL,t ion
BEAs Pr opem
m any r t essages
ie s bet ween Size s
Syst em s, DLSw+ . client and server.
The query response can
consist of m any TCP and
FTP sessions running
sim ult aneously ( for
exam ple, HTTP- based
applicat ions) .

Bulk Dat abase syncs, net work- Long file t ransfers. Average m essage
PHB: AF1 based backups, Lot us Always invokes TCP size 64 KB or
Not es, Microsoft Out look, congest ion m anagem ent . gr eat er .
e- m ail download ( SMTP,
POP3, I MAP, Exchange) ,
video cont ent dist ribut ion,
large FTP file t ransfers.

Best - Effor t All noncrit ical t raffic, HTTP

PHB: Default web browsing, ot her
m iscellaneous t raffic.

DLSw+ Considerations
Som e ent erprises support legacy I BM equipm ent t hat requires dat a- link swit ching plus ( DLSw+ )
t o operat e across an ent erprise environm ent .

I n such cases, it is im port ant t o recognize t hat DLSw+ t raffic, by default , is m arked t o I P
Precedence 5 ( DSCP CS5) . This default m arking could int erfere wit h VoI P provisioning because
bot h DSCP EF and DSCP CS5 share t he sam e I P Precedence, 802.1Q/ p CoS, and MPLS EXP value
( of 5) . Therefore, it is recom m ended t o re- m ark DLSw+ t raffic away from t his default value of I P
Precedence 5.

Unfort unat ely, at t he t im e of writ ing, Cisco I OS does not support m arking DSCP values wit hin
t he DLSw+ peering st at em ent s; it support s only t he m arking of t ype of service ( ToS) values
using t he dlsw t os m a p com m and.

N ot e
To explain t his behavior from a hist orical perspect ive, when DLSw+ was developed,
ToS was a t erm loosely used t o refer t o t he first 3 bit s ( t he I P Precedence bit s) of t he
I P ToS byt e, as defined in RFC 791. For m any years, t hese were t ypically t he only bit s
of t he ToS byt e in use ( t he ot hers alm ost always were set t o 0) , so it seem ed t o m ake
sense at t he t im e.

However, wit h t he developm ent of newer st andards defining t he use of t he first 6 bit s
of t he I P ToS byt e for DiffServ m arkings ( RFC 2474) and t he last 2 bit s for I P explicit
congest ion not ificat ion ( RFC 3168) , using t he t erm ToS t o refer t o only t he first 3 bit s
( t he I P Precedence bit s) of t he I P ToS byt e has becom e increasingly inaccurat e.
However, m arking DLSw+ t o an I P Precedence/ class select or value could int erfere wit h ot her
QoS Baseline recom m ended m arkings. For exam ple, if DLSw+ is m arked t o I PP 1, it would be
t reat ed as Scavenger t raffic; if it is m arked t o I PP 2, it could int erfere wit h Net work- Managem ent
t raffic; if it is m arked t o I PP 3, it could int erfere wit h Call- Signaling; if it is m arked t o I PP 4, it
would be t reat ed as St ream ing- Video t raffic; and if it is m arked t o I PP 6 or 7, it could int erfere
wit h rout ing or Net work Cont rol t raffic.

Therefore, a t wo- st ep workaround is recom m ended for m arking DLSw+ t raffic:

St e p 1 . Disable nat ive DLSw+ ToS m arkings wit h t he dlsw t os disa ble com m and.

St e p 2 . I dent ify DLSw+ t raffic eit her wit h access list s ( m at ching t he DLSw+ TCP port s 1981
t o 1983 or 2065) or wit h t he m a t ch pr ot ocol dlsw com m and.

When DLSw+ t raffic is ident ified, it can be m arked as eit her Transact ional ( AF21) or Mission-
Crit ical Dat a ( DSCP 25) , depending on t he organizat ion's preference.
QoS Requirements of the Control Plane
Unless t he net work is up, QoS is irrelevant . Therefore, it is crit ical t o provision QoS for cont rol-
plane t raffic, which includes I P rout ing t raffic and net work m anagem ent .

IP Routing
When addressing t he QoS needs of I P rout ing t raffic, t he following guidelines are recom m ended:

I P rout ing t raffic should be m arked t o DSCP CS6; t his is default behavior on Cisco I OS
plat form s.

I nt erior gat eway prot ocols usually adequat ely are prot ect ed wit h t he Cisco I OS int ernal
PAK_priorit y m echanism . Ext erior gat eway prot ocols, such as BGP, are recom m ended t o
have an explicit class for I P rout ing wit h a m inim al bandwidt h guarant ee.

Cisco I OS aut om at ically m arks I P rout ing t raffic t o DSCP CS6.

By default , Cisco I OS Soft ware ( in accordance wit h RFC 791 and RFC 2474) m arks I nt erior
Gat eway Prot ocol ( I GP) t raffic ( such as Rout ing I nform at ion Prot ocol [ RI P and RI Pv2] , Open
Short est Pat h First [ OSPF] , and Enhanced I nt erior Gat eway Rout ing Prot ocol [ EI GRP] ) t o DSCP
CS6. However, Cisco I OS Soft ware also has an int ernal m echanism for grant ing priorit y t o
im port ant cont rol dat agram s as t hey are processed t hrough t he rout er. This m echanism is called
PAK_priorit y.

As dat agram s are processed t hough t he rout er and down t o t he int erfaces, t hey int ernally are
encapsulat ed wit h a sm all packet header, referred t o as t he PAKTYPE st ruct ure. Wit hin t he fields
of t his int ernal header is a PAK_priorit y flag t hat indicat es t he relat ive im port ance of cont rol
packet s t o t he rout er's int ernal processing syst em s. PAK_priorit y designat ion is a crit ical int ernal
Cisco I OS Soft ware operat ion and, as such, is not adm inist rat ively configurable in any way.

I t is im port ant t o not e t hat alt hough ext erior gat eway prot ocol ( EGP) t raffic, such as Border
Gat eway Prot ocol ( BGP) t raffic, is m arked by default t o DSCP CS6, it does not receive such
PAK_priorit y preferent ial t reat m ent and m ight need t o be prot ect ed explicit ly t o m aint ain peering
sessions.

N ot e
Addit ional inform at ion on PAK_priorit y can be found at
ht t p: / / www.cisco.com / warp/ public/ 105/ rt gupdat es.ht m l.

Network-Management
When addressing t he QoS needs of Net work- Managem ent t raffic, t he following guidelines are
r ecom m ended:

Net work- Managem ent t raffic should be m arked t o DSCP CS2.

Net work- Managem ent applicat ions should be prot ect ed explicit ly wit h a m inim al bandwidt h
guarant ee.

Net work- Managem ent t raffic is im port ant in perform ing t rend and capacit y analyses and
t roubleshoot ing. Therefore, a separat e m inim al bandwidt h queue can be provisioned for
Net work- Managem ent t raffic, which could include SNMP, NTP, Syslog, and NFS and ot her
m anagem ent applicat ions.
Scavenger Class
When addressing t he QoS t reat m ent of Scavenger t raffic, t he following guidelines are
r ecom m ended:

Scavenger t raffic should be m arked t o DSCP CS1.

Scavenger t raffic should be assigned t he lowest configurable queuing service; for inst ance,
in Cisco I OS, t his m eans assigning a CBWFQ of 1 percent t o Scavenger.

The Scavenger class is int ended t o provide deferent ial services, or less- t han best - effort services,
t o cert ain applicat ions. Applicat ions assigned t o t his class have lit t le or no cont ribut ion t o t he
organizat ional obj ect ives of t he ent erprise and are t ypically ent ert ainm ent orient ed in nat ure.
These include peer- t o- peer m edia- sharing applicat ions ( KaZaa, Morpheus, Groekst er, Napst er,
iMesh, and so on) , gam ing applicat ions ( Doom , Quake, Unreal Tournam ent , and so on) , and any
ent ert ainm ent video applicat ions.

Assigning Scavenger t raffic t o m inim al bandwidt h queue forces it t o be squelched t o virt ually
not hing during periods of congest ion, but it allows it t o be available if bandwidt h is not being
used for business purposes, such as m ight occur during off- peak hours.

The Scavenger class is a crit ical com ponent t o t he DoS and worm m it igat ion st rat egy, discussed
next .
DoS and Worm Mitigation Strategy Through Scavenger
Class QoS
Worm s are not hing new; t hey have been around in som e form since t he beginning of t he
I nt ernet and st eadily have been increasing in com plexit y, as shown in Figure 2- 6 .

Figu r e 2 - 6 . Bu sin e ss Se cu r it y Th r e a t Evolu t ion

[View full size image]

Part icularly since 2002, t here has been an exponent ial increase not only in t he frequency of DoS
and worm at t acks, but also in t heir relat ive sophist icat ion and scope of dam age. For exam ple,
m ore t han 994 new Win32 viruses and worm s were docum ent ed in t he first half of 2003, m ore
t han double t he 445 docum ent ed in t he first half of 2002. Som e of t hese m ore recent worm s are
shown in Figure 2- 7 .

Figu r e 2 - 7 . Re ce n t I n t e r n e t W or m s

[View full size image]

DoS or worm at t acks can be cat egorized int o t wo m ain classes:

Spoofin g a t t a ck s The at t acker pret ends t o provide a legit im at e service but provides false
inform at ion ( if any) t o t he request er.

Floodin g a t t a ck s The at t acker exponent ially generat es and propagat es t raffic unt il service
resources ( servers or net work infrast ruct ure) are overwhelm ed.

Spoofing at t acks best are addressed by aut hent icat ion and encrypt ion t echnologies; flooding
at t acks, on t he ot her hand, can be m it igat ed using QoS t echnologies.

The m aj orit y of flooding at t acks t arget PCs and servers, which, when infect ed, t arget ot her PCs
and servers, t hus m ult iplying t raffic flows. Net work devices t hem selves are not usually t he direct
t arget s of at t acks. But t he rapidly m ult iplying volum es of t raffic flows event ually drown t he CPU
and hardware resources of rout ers and swit ches in t heir pat hs, causing denial of service t o
legit im at e t raffic flows. The end result is t hat net work devices becom e indirect vict im s of t he
at t ack. This is illust rat ed in Figure 2- 8 .

Figu r e 2 - 8 . I m pa ct of a n I n t e r n e t W or m D ir e ct a n d Colla t e r a l D a m a ge

[View full size image]

A react ive approach t o m it igat ing such at t acks is t o reverse- engineer t he worm and set up
int rusion- det ect ion m echanism s or ACLs t o lim it it s propagat ion. However, t he increased
sophist icat ion and com plexit y of t oday's worm s m ake t hem harder t o ident ify from legit im at e
t raffic flows. This exacerbat es t he finit e t im e lag bet ween when a worm begins t o propagat e and
when t he following occurs:

Sufficient analysis has been perform ed t o underst and how t he worm operat es and what it s
net work charact erist ics are.

An appropriat e pat ch, plug, or ACL is dissem inat ed t o net work devices t hat m ight be in t he
pat h of t he worm . This t ask m ight be ham pered by t he at t ack it self because net work
devices m ight becom e unreachable for adm inist rat ion during t he at t acks.

These t im e lags m ight not seem long in absolut e t erm s, such as in m inut es, but t he relat ive
window of opport unit y for dam age is huge. For exam ple, in 2003, t he num ber of host s infect ed
wit h t he Slam m er worm ( a Sapphire worm variant ) doubled every 8.5 seconds on average,
infect ing m ore t han 75,000 host s in j ust 11 m inut es and perform ing scans of 55 m illion m ore
host s wit hin t he sam e t im e period.

N ot e
I nt erest ingly, a 2002 CSI / FBI report st at ed t hat t he m aj orit y of net work at t acks occur
from wit hin an organizat ion, t ypically by disgrunt led em ployees.

A proact ive approach t o m it igat ing DoS and worm flooding at t acks wit hin ent erprise net works is
t o respond im m ediat ely t o out - of- profile net work behavior indicat ive of a DoS or worm at t ack via
cam pus Access- Layer policers. Such policers can m et er t raffic rat es received from endpoint
devices and, when t hese exceed specified wat erm arks ( at which point t hey no longer are
considered norm al flows) , can m ark down excess t raffic t o t he Scavenger class m arking ( DSCP
CS1) .

I n t his respect , t he policers would be fairly " dum b." They would not be m at ching specific
net work charact erist ics of specific t ypes of at t acks, but t hey sim ply would be m et ering t raffic
volum es and responding t o abnorm ally high volum es as close t o t he source as possible. The
sim plicit y of t his approach negat es t he need for t he policers t o be program m ed wit h knowledge
of t he specific det ails of how t he at t ack is being generat ed or propagat ed. I t is precisely t his
" dum bness" of such Access- Layer policers t hat allows t hem t o m aint ain relevancy as worm s
m ut at e and becom e m ore com plex: The policers don't care how t he t raffic was generat ed or
what it looks like; all t hey care about is how m uch t raffic is being put ont o t he wire. Therefore,
t hey cont inue t o police even advanced worm s t hat cont inually change t he t act ics of how t raffic is
being generat ed.

For exam ple, in m ost ent erprises, it is quit e abnorm al ( wit hin a 95 percent st at ist ical confidence
int erval) for PCs t o generat e sust ained t raffic in excess of 5 percent of t heir link's capacit y. I n
t he case of a Fast Et hernet swit ch port , t his m eans t hat it would be unusual in m ost
organizat ions for an end user's PC t o generat e m ore t han 5 Mbps of uplink t raffic on a sust ained
basis.
 N ot e

I t is im port ant t o recognize t hat t his value ( 5 percent ) for norm al access- edge
ut ilizat ion by endpoint s is j ust an exam ple value. This value would likely vary from
indust ry vert ical t o vert ical, and from ent erprise t o ent erprise.

I t is im port ant t o recognize t hat what is being proposed is not t o police all t raffic t o 5 Mbps and
aut om at ically drop t he excess. I f t hat were t he case, t here would not be m uch reason for
deploying Fast Et hernet or Gigabit Et hernet swit ch port s t o endpoint devices because even
10BASE- T Et hernet swit ch port s would have m ore uplink capacit y t han a 5 Mbps policer- enforced
lim it . Furt herm ore, such an approach suprem ely would penalize legit im at e t raffic t hat exceeded
5 Mbps on a Fast Et hernet swit ch port .

A less draconian approach is t o couple Access- Layer policers wit h hardware and soft ware
( cam pus, WAN, and VPN) queuing policies, wit h bot h set s of policies provisioning for a less- t han
best - effort Scavenger class.

This would work by having Access- Layer policers m ark down out - of- profile t raffic t o DSCP CS1
( Scavenger) and t hen have all congest ion- m anagem ent policies ( whet her in Cat alyst hardware
or in Cisco I OS Soft ware) provision a less- t han best - effort service for any t raffic m arked t o DSCP
CS1.

Let 's exam ine how t his m ight work, for bot h legit im at e t raffic exceeding t he Access- Layer
policer's wat erm ark and illegit im at e excess t raffic ( t he result of a DoS or worm at t ack) .

I n t he form er case, im agine t hat t he PC generat es m ore t han 5 Mbps of t raffic, perhaps because
of a large file t ransfer or backup. Because t here is generally abundant capacit y wit hin t he
cam pus t o carry t he t raffic, congest ion ( under norm al operat ing condit ions) is rarely, if ever,
experienced. Typically, t he uplinks t o t he dist ribut ion and core layers of t he cam pus net work are
Gigabit Et hernet , which requires 1000 Mbps of t raffic from t he Access- Layer swit ch t o creat e
congest ion. I f t he t raffic was dest ined t o t he far side of a WAN or VPN link ( which are rarely
m ore t han 5 Mbps in speed) , dropping would occur even wit hout t he Access- Layer policer,
sim ply because of t he cam pus/ WAN speed m ism at ch and result ing bot t leneck. TCP's sliding-
windows m echanism event ually would find an opt im al speed ( less t han 5 Mbps) for t he file
t ransfer.

To m ake a long st ory short , Access- Layer policers t hat m ark down out - of- profile t raffic t o
Scavenger ( CS1) would not affect legit im at e t raffic, aside from t he obvious re- m arking. No
reordering or dropping would occur on such flows as a result of t hese policers ( t hat would not
have occurred anyway) .

I n t he lat t er case, t he effect of Access- Layer policers on t raffic caused by DoS or worm at t acks is
quit e different . As host s becom e infect ed and t raffic volum es m ult iply, congest ion m ight be
experienced even wit hin t he cam pus. I f j ust 11 end- user PCs on a single swit ch begin spawning
worm flows t o t heir m axim um Fast Et hernet link capacit ies, t he GE uplink from t he Access- Layer
swit ch t o t he Dist ribut ion- Layer swit ch will congest and queuing or reordering will engage. At
such a point , VoI P and crit ical dat a applicat ions, and even Best - Effort applicat ions, would gain
priorit y over worm - generat ed t raffic ( and Scavenger t raffic would be dropped t he m ost
aggressively) ; net work devices would rem ain accessible for adm inist rat ion of pat ches, plugs, and
ACLs required t o fully neut ralize t he specific at t ack.

WAN links also would be prot ect ed: VoI P, crit ical dat a, and even best - effort flows would cont inue
t o receive priorit y over any t raffic m arked down t o Scavenger/ CS1. This is a huge advant age
because generally WAN links are t he first t o be overwhelm ed by DoS and worm at t acks. The
bot t om line is t hat Access- Layer policers significant ly m it igat e net work t raffic generat ed by DoS
or worm at t acks.

I t is im port ant t o recognize t he dist inct ion bet ween m it igat ing an at t ack and prevent ing it
ent irely: The st rat egy being present ed does not guarant ee t hat no denial of service or worm
at t acks ever will happen, but it can reduce t he risk and im pact t hat such at t acks could have on
t he net work infrast ruct ure.
Principles of QoS Design
The richness of t he Cisco QoS t oolset allows for a m yriad of QoS design and deploym ent opt ions.
However, a few succinct design principles can help sim plify st rat egic QoS designs and lead t o an
expedit ed, cohesive, and holist ic end- t o- end deploym ent . Som e of t hese design principles are
sum m arized here; ot hers, which are LAN- , WAN- or VPN- specific, are covered in det ail in t heir
respect ive design chapt ers.

General QoS Design Principles

A good place t o begin is t o decide which com es first : t he cart or t he horse. The horse, in t his
cont ext , serves t o pull t he cart and is t he enabler for t his obj ect ive. Sim ilarly, QoS t echnologies
are sim ply t he enablers t o organizat ional obj ect ives. Therefore, t he way t o begin a QoS
deploym ent is not by glossing over t he QoS t oolset and picking à la cart e t ools t o deploy. I n
ot her words, do not enable QoS feat ures sim ply because t hey exist . I nst ead, st art from a high
level and clearly define t he organizat ional obj ect ives.

Som e quest ions for high- level considerat ion include t he following:

I s t he obj ect ive t o enable VoI P only?

I s video also required? I f so, what t ype( s) of video: int eract ive or st ream ing?

Are som e applicat ions considered m ission crit ical? I f so, what are t hey?

Does t he organizat ion want t o squelch cert ain t ypes of t raffic? I f so, what are t hey?

All t raffic classes specified in t he QoS Baseline m odel except onet he Locally- Defined, Mission-
Crit ical Dat a applicat ion classare det erm ined by obj ect ive net working charact erist ics. These
applicat ions, a subset of t he Transact ional Dat a class, are select ed for a dedicat ed, preferent ial
class of service because of t heir significant im pact on t he organizat ion's m ain business
obj ect ives.

This is usually a highly subj ect ive evaluat ion t hat can excit e considerable cont roversy and
disput e. An im port ant principle t o rem em ber when assigning applicat ions t o t he Mission- Crit ical
Dat a class is t hat as few applicat ions as possible should be assigned t o t he Locally- Defined
Mission- Crit ical class.

I f t oo m any applicat ions are assigned t o it , t he Mission- Crit ical Dat a class will dam pen, and
possibly even negat e, t he value of having a separat e class ( from Transact ional Dat a) . For
exam ple, if 10 applicat ions are assigned as Transact ional Dat a ( because of t heir int eract ive,
foreground net working charact erist ics) and all 10 are det erm ined t o be classified as Mission-
Crit ical Dat a, t he whole point of a separat e class for t hese applicat ions becom es m oot . However,
if only one or t wo of t he Transact ional Dat a applicat ions are assigned t o t he Mission- Crit ical Dat a
class, t he class will prove highly effect ive.

Relat ed t o t his point , it is recom m ended always t o seek execut ive endorsem ent of t he QoS
obj ect ives before design and deploym ent . By it s very nat ure, QoS is a syst em of m anaged
unfairness and, as such, alm ost always creat es polit ical and organizat ional repercussions when
im plem ent ed. To m inim ize t he effect s of such nont echnical obst acles t o deploym ent , which could
prevent t he QoS im plem ent at ion alt oget her, it is recom m ended t o address t hese polit ical and
organizat ional issues as early as possible and t o solicit execut ive endorsem ent whenever
possible.

As st at ed previously, it is not m andat ed t hat ent erprises deploy all 11 classes of t he QoS
Baseline m odel; t his m odel is designed t o be a forward- looking guide for considerat ion of t he
m any classes of t raffic t hat have unique QoS requirem ent s. Being aware of t his m odel can help
bring about a sm oot h expansion of QoS policies t o support addit ional applicat ions as fut ure
requirem ent s arise. However, at t he t im e of QoS deploym ent , t he organizat ion needs t o clearly
define how m any classes of t raffic are required t o m eet t he organizat ional obj ect ives.

This considerat ion should be t em pered wit h t he considerat ion of how m any classes of
applicat ions t he net working adm inist rat ion t eam feels com fort able wit h deploying and
support ing. Plat form - specific const raint s or service- provider const raint s also m ight com e int o
play when arriving at t he num ber of classes of service. At t his point , it also would be good t o
consider a m igrat ion st rat egy t o allow t he num ber of classes t o be expanded sm oot hly as fut ure
needs arise, as illust rat ed in Figure 2- 9 .

Figu r e 2 - 9 . Ex a m ple St r a t e gy for Ex pa n din g t h e N u m be r of Cla sse s of

Se r vice ove r Tim e

When t he num ber of classes of service has been det erm ined, t he det ails of t he required m arking,
policing, and queuing policies can be addressed. When deciding where t o enable such policies,
keep in m ind t hat QoS policies always should be perform ed in hardware inst ead of soft ware
whenever a choice exist s.

Cisco I OS rout ers perform QoS in soft ware, which places increm ent al loads on t he CPU
( depending on t he com plexit y and funct ionalit y of t he policy) . Cisco Cat alyst swit ches, on t he
ot her hand, perform QoS in dedicat ed hardware ASI CS and, as such, do not t ax t heir m ain CPUs
t o adm inist er QoS policies. This allows com plex policies t o be applied at line rat es at even 1-
Gbps or 10- Gigabit speeds.

Classification and Marking Principles

When it com es t o classifying and m arking t raffic, an unofficial Different iat ed Services design
principle is t o classify and m ark applicat ions as close t o t heir sources as t echnically and
adm inist rat ively feasible. This principle prom ot es end- t o- end Different iat ed Services and per- hop
behaviors ( PHBs) . Som et im es endpoint s can be t rust ed t o set CoS and DSCP m arkings correct ly,
but , in m ost cases, it is not a good idea t o t rust m arkings t hat users can set on t heir PCs ( or
ot her sim ilar devices) . This is because users easily could abuse provisioned QoS policies if
perm it t ed t o m ark t heir own t raffic. For exam ple, if DSCP EF receives priorit y services
t hroughout t he ent erprise, a user easily could configure t he PC t o m ark all t raffic t o DSCP EF
right on t he NI C, t hus hij acking net work- priorit y queues t o service t hat user's non- real- t im e
t raffic. Such abuse easily could ruin t he service qualit y of real- t im e applicat ions ( such as VoI P)
t hroughout t he ent erprise. For t his reason, t he clause " as close as ... adm inist rat ively feasible" is
included in t he design principle.

Following t his rule, it furt her is recom m ended t o use DSCP m arkings whenever possible because
t hese are end t o end, m ore granular, and m ore ext ensible t han Layer 2 m arkings. Layer 2
m arkings are lost when m edia changes ( such as at a LAN- t o- WAN or VPN edge) . An addit ional
const raint t o Layer 2 m arking is t hat t here is less m arking granularit y; for exam ple, 802.1Q/ p
CoS support s only 3 bit s ( values 0 t hrough 7) , as does MPLS EXP. Therefore, only ( up t o) eight
classes of t raffic can be support ed at Layer 2, and int erclass relat ive priorit y ( such as RFC 2597
assured- forwarding class m arkdown) is not support ed. On t he ot her hand, Layer 3 DSCP
m arkings allow for up t o 64 classes of t raffic, which is m ore t han enough for m ost ent erprise
requirem ent s for t he foreseeable fut ure.

Because t he line bet ween ent erprises and service providers is blurring and t he need for
int eroperabilit y and com plem ent ary QoS m arkings is crit ical, it is recom m ended t o follow
st andards- based DSCP PHB m arkings t o ensure int eroperabilit y and fut ure expansion. The QoS
Baseline m arking recom m endat ions are st andards based, m aking it easier for ent erprises
adopt ing t hese m arkings t o int erface wit h service provider classes of service. Net work m ergers
are also easier t o m anage when st andards- based DSCP m arkings are used, whet her t hese
m ergers are t he result of acquisit ions, part nerships, or st rat egic alliances.

Policing and Markdown Principles

There is lit t le sense in forwarding unwant ed t raffic only t o police and drop it at a subsequent
node. This is especially t he case when t he unwant ed t raffic is t he result of DoS or worm at t acks.
The overwhelm ing volum es of t raffic t hat such at t acks can creat e readily can drive net work
device processors t o t heir m axim um levels, causing net work out ages. Therefore, it is
recom m ended t o police t raffic flows as close t o t heir sources as possible. This principle applies t o
legit im at e flows also because DoS and worm - generat ed t raffic m ight be m asquerading under
legit im at e, well- known TCP and UDP port s, causing ext rem e am ount s of t raffic t o be poured ont o
t he net work infrast ruct ure. Such excesses should be m onit ored at t he source and m arked down
appropriat ely.

Whenever support ed, m arkdown should be done according t o st andards- based rules, such as
RFC 2597 ( " Assured Forwarding PHB Group" ) . I n ot her words, whenever support ed, t raffic
m arked t o AFx1 should be m arked down t o AFx2 or AFx3. For exam ple, in t he case of a single-
rat e policer, excess t raffic originally m arked AF11 should be m arked down t o AF12. I n t he case
of a dual- rat e policer ( as defined in RFC 2698) , excess t raffic originally m arked AF11 should be
m arked down t o AF12, and violat ing t raffic should be m arked down furt her t o AF13. Following
such m arkdowns, congest ion- m anagem ent policies, such as DSCP- based WRED, should be
configured t o drop AFx3 m ore aggressively t han AFx2, which, in t urn, is dropped m ore
aggressively t han AFx1.

However, at t he t im e of writ ing, Cisco Cat alyst swit ches do not perform DSCP- based WRED, so
t his st andards- based st rat egy cannot be im plem ent ed fully. As an alt ernat ive workaround,
single- rat e policers can be configured t o m ark down excess t raffic t o DSCP CS1 ( Scavenger) ;
dual- rat e policers can be configured t o m ark down excess t raffic t o AFx2, while m arking down
violat ing t raffic t o DSCP CS1. Such workarounds yield an overall sim ilar effect as t he st andards-
based policing m odel. However, when DSCP- based WRED is support ed on all rout ing and
swit ching plat form s, it would be m ore st andards com pliant t o m ark down assured- forwarding
classes by RFC 2597 rules.

Queuing and Dropping Principles

Crit ical applicat ions, such as VoI P, require service guarant ees regardless of net work condit ions.
The only way t o provide service guarant ees is t o enable queuing at any node t hat has t he
pot ent ial for congest ionregardless of how rarely, in fact , t his m ight occur. This principle applies
not only t o cam pus- t o- WAN or VPN edges, where speed m ism at ches are m ost pronounced, but
also t o cam pus int erlayer links ( where oversubscript ion rat ios creat e t he pot ent ial for
congest ion) . There is sim ply no ot her way t o guarant ee service levels t han t o enable queuing
wherever a speed m ism at ch exist s.

When provisioning queuing, som e best - pract ice rules of t hum b also apply. For exam ple, as
discussed previously, t he Best - Effort class is t he default class for all dat a t raffic. Only if an
applicat ion has been select ed for preferent ial or deferent ial t reat m ent is it rem oved from t he
default class. Because m any ent erprises have several hundred, if not t housands of, dat a
applicat ions running over t heir net works, adequat e bandwidt h m ust be provisioned for t his class
as a whole t o handle t he sheer volum e of applicat ions t hat default t o it . Therefore, it is
recom m ended t hat at least 25 percent of a link's bandwidt h be reserved for t he default Best -
Effort class.

Anot her class of t raffic t hat requires special considerat ion when provisioning queuing is t he Real-
Tim e or St rict - Priorit y class ( which corresponds t o RFC 3246, " An Expedit ed Forwarding Per- Hop
Behavior" ) . The am ount of bandwidt h assigned t o t he Real- Tim e queuing class is variable.
However, if t oo m uch t raffic is assigned for st rict - priorit y queuing, t he overall effect is a
dam pening of QoS funct ionalit y for non- real- t im e applicat ions.

The goal of convergence cannot be overem phasized: t o enable voice, video, and dat a t o coexist
t ransparent ly on a single net work. When real- t im e applicat ions ( such as Voice or I nt eract ive-
Video) dom inat e a link ( especially a WAN/ VPN link) , dat a applicat ions will fluct uat e significant ly
in t heir response t im es, dest roying t he t ransparency of t he " converged" net work.

Cisco Technical Market ing t est ing has shown a significant decrease in dat a applicat ion response
t im es when real- t im e t raffic exceeds one- t hird of a link's bandwidt h capacit y. Ext ensive t est ing
and cust om er deploym ent s have shown t hat a general best queuing pract ice is t o lim it t he
am ount of st rict - priorit y queuing t o 33 percent of a link's capacit y. This st rict - priorit y queuing
rule is a conservat ive and safe design rat io for m erging real- t im e applicat ions wit h dat a
applicat ions.

Cisco I OS Soft ware allows t he abst ract ion ( and, t hus, configurat ion) of m ult iple ( st rict - priorit y)
low- lat ency queues. I n such a m ult iple- LLQ cont ext , t his design principle applies t o t he sum of
all LLQs: They should be wit hin one- t hird of a link's capacit y.
 N ot e
This st rict - priorit y queuing rule ( lim it t o 33 percent ) is sim ply a best - pract ice design
recom m endat ion; it is not a m andat e. I n som e cases, specific business obj ect ives
cannot be m et while holding t o t his recom m endat ion. I n such cases, ent erprises m ust
provision according t o t heir det ailed requirem ent s and const raint s. However, it is
im port ant t o recognize t he t rade- offs involved wit h overprovisioning st rict - priorit y
t raffic wit h respect t o t he negat ive perform ance im pact on response t im es in non- real-
t im e applicat ions.

Whenever a Scavenger queuing class is enabled, it should be assigned a m inim al am ount of

bandwidt h. On som e plat form s, queuing dist inct ions bet ween Bulk Dat a and Scavenger class
t raffic flows cannot be m ade because queuing assignm ent s are det erm ined by CoS values, and
t hese applicat ions share t he sam e CoS value of 1. I n such cases, t he Scavenger/ Bulk Dat a
queuing class can be assigned a bandwidt h percent age of 5. I f Scavenger and Bulk t raffic can be
assigned uniquely t o different queues, t he Scavenger queue should be assigned a bandwidt h
percent age of 1.

The Real- Tim e, Best - Effort , and Scavenger classes queuing best - pract ice principles are
illust rat ed in Figure 12- 10.

Figu r e 2 - 1 0 . Re a l- Tim e , Be st - Effor t , a n d Sca ve n ge r Qu e u in g Ru le s

Som e plat form s support different queuing st ruct ures t han ot hers. To ensure consist ent PHBs,
configure consist ent queuing policies according t o plat form capabilit ies.

For exam ple, on a plat form t hat support s only four queues wit h CoS- based adm ission ( such as a
Cat alyst swit ch) , a basic queuing policy could be as follows:

Real- Tim e ( 33 percent )

Crit ical Dat a

 Best - Effort ( 25 percent )

Scavenger/ Bulk( < 5 percent )

However, on a plat form t hat support s a full QoS Baseline queuing m odel, t he queuing policies
can be expanded, yet in such a way t hat t hey provide consist ent servicing t o Real- Tim e, Best -
Effort , and Scavenger class t raffic. For exam ple, on a plat form t hat support s 11 queues wit h
DSCP- based adm ission ( such as a Cisco I OS rout er) , an advanced queuing policy could be as
follows:

Voice ( 18 percent )

I nt eract ive- Video ( 15 percent )

I nt ernet work Cont rol

Call- Signaling

Mission- Crit ical Dat a

Transact ional Dat a

Net work- Managem ent

St ream ing- Video Cont rol

Best - Effort ( 25 percent )

Bulk Dat a ( 4 percent )

Scavenger ( 1 percent )

Figure 2- 11 illust rat es t he int errelat ionship bet ween t hese com pat ible queuing m odels.

Figu r e 2 - 1 1 . Com pa t ible 4 - Cla ss a n d 1 1 - Cla ss Qu e u in g M ode ls

Follow in g Re a l- Tim e , Be st - Effor t , a n d Sca ve n ge r Cla ss Qu e u in g Ru le s
I n t his m anner, t raffic will receive com pat ible queuing at each node, regardless of plat form
capabilit ieswhich is t he overall obj ect ive of DiffServ per- hop behavior definit ions.

Whenever support ed, it is recom m ended t o enable WRED ( preferably DSCP- based WRED) on all
TCP flows. I n t his m anner, WRED congest ion avoidance will prevent TCP global synchronizat ion
and will increase overall t hroughput and link efficiency. Enabling WRED on UDP flows is opt ional.

DoS and Worm Mitigation Principles

Whenever part of t he organizat ion's obj ect ives is t o m it igat e DoS and worm at t acks t hrough
Scavenger- class QoS, t he following best pract ices apply.

First , t he net work adm inist rat ors need t o profile applicat ions t o det erm ine what const it ut es
norm al versus abnorm al flows, wit hin a 95 percent confidence int erval. Thresholds different iat ing
norm al and abnorm al flows vary from ent erprise t o ent erprise and from applicat ion t o
applicat ion. Caut ion m ust be ext ended not t o overscrut inize t raffic behavior because t his could
be t im e and resource exhaust ive and easily could change from one day t o t he next . Rem em ber,
t he present ed Scavenger- class st rat egy will not apply a penalt y t o legit im at e t raffic flows t hat
exceed t hresholds ( aside from re- m arking) ; only sust ained, abnorm al st ream s generat ed
sim ult aneously by m ult iple host s ( highly indicat ive of DoS and worm at t acks) are subj ect t o
aggressive dropping, and only aft er legit im at e t raffic has been serviced.

To cont ain such abnorm al flows, it is recom m ended t o deploy cam pus Access- Edge policers t o
re- m ark abnorm al t raffic t o Scavenger ( DSCP CS1) . Addit ionally, whenever Cat alyst 6500s wit h
Supervisor 720s are deployed in t he dist ribut ion layer, it is recom m ended t o deploy a second
line of policing defense, at t he dist ribut ion layer via per- user m icroflow policing.

To com plem ent t hese re- m arking policies, it is necessary t o enforce end- t o- end Scavenger- class
queuing policies, where flows m arked as Scavenger will receive a less- t han best - effort service
whenever congest ion occurs.

I t is im port ant t o not e t hat even when Scavenger- class QoS has been deployed end t o end, t his
st rat egy only m it igat es DoS and worm at t acks and does not prevent t hem or rem ove t hem
ent irely. Therefore, it is crit ical t o overlay securit y, firewall, int rusion det ect ion, and ident it y
syst em s, along wit h Cisco Guard and Cisco Securit y Agent solut ions, on t op of t he QoS- enabled
net work infrast ruct ure.

Deployment Principles
Aft er t he QoS designs have been finalized, it is vit al t hat t he net working t eam t horoughly
underst and t he QoS feat ures and synt ax before enabling feat ures on product ion net works. Such
knowledge is crit ical for bot h deploym ent and t roubleshoot ing QoS- relat ed issues.

Furt herm ore, it is a general best pract ice t o schedule proof- of- concept ( PoC) t est s t o verify t hat
t he hardware and soft ware plat form s in product ion support t he required QoS feat ures in
com binat ion wit h all t he ot her feat ures t hat t hey current ly are running. Rem em ber, in t heory,
t heory and pract ice are t he sam e. I n ot her words, t here is no subst it ut e for t est ing.

When t est ing has validat ed t he designs, it is recom m ended t o schedule net work downt im e t o
deploy QoS feat ures. Alt hough QoS is required end t o end, it does not have t o be deployed end
t o end at a single inst ance. A pilot net work segm ent can be select ed for an init ial deploym ent ,
and, pending observat ion, t he deploym ent can be expanded in st ages t o encom pass t he ent ire
ent erprise. A rollback st rat egy always is recom m ended, t o address unexpect ed issues t hat arise
from t he QoS deploym ent .
Summary
This chapt er began by reviewing t he QoS requirem ent s of voice, video, and dat a applicat ions.

Voice requires 150- m s one- way, end- t o- end ( m out h- t o- ear) delay; 30 m s of one- way j it t er; and
no m ore t han 1 percent packet loss. Voice should receive st rict - priorit y servicing, and t he
am ount of priorit y bandwidt h assigned for it should t ake int o account t he VoI P codec; t he
packet izat ion rat e; I P, UDP, and RTP headers ( com pressed or not ) ; and Layer 2 overhead.
Addit ionally, provisioning QoS for I P Telephony requires t hat a m inim al am ount of guarant eed
bandwidt h be allocat ed t o Call- Signaling t raffic.

Video com es in t wo flavors: I nt eract ive- Video and St ream ing- Video. I nt eract ive- Video has t he
sam e service- level requirem ent s as VoI P because em bedded wit hin t he video st ream is a voice
call. St ream ing- Video has m uch laxer requirem ent s because of a high am ount of buffering t hat
has been built int o t he applicat ions.

Cont rol plane requirem ent s, such as provisioning m oderat e bandwidt h guarant ees for I P rout ing
prot ocols and net work- m anagem ent prot ocols, should not be overlooked.

Dat a com es all shapes and sizes but generally can be classified int o four m ain classes: Best -
Effort ( t he default class) , Bulk Dat a ( nonint eract ive background flows) , Transact ional/ I nt eract ive
( int eract ive, foreground flows) , and Mission- Crit ical Dat a. Mission- Crit ical Dat a applicat ions are
locally defined, m eaning t hat each organizat ion m ust det erm ine t he select few Transact ional
Dat a applicat ions t hat cont ribut e t he m ost significant ly t o it s overall business obj ect ives.

A less- t han best - effort Scavenger class of t raffic was int roduced, and a st rat egy for using t his
class for DoS and worm m it igat ion was present ed. Specifically, flows can be m onit ored at t he
cam pus Access- Edge, and out - of- profile flows can be m arked down t o t he Scavenger m arking ( of
DSCP CS1) . To com plem ent t hese policers, queues providing a less- t han best - effort Scavenger
service during periods of congest ion are deployed in t he LAN, WAN, and VPN.

The chapt er concluded wit h a set of general best - pract ice principles relat ing t o QoS planning,
classificat ion, m arking, policing, queuing, and deploym ent . These best pract ices include t he
following:

Clearly defining t he organizat ion's business obj ect ives t o be addressed by QoS

Select ing an appropriat e num ber of service classes t o m eet t hese business obj ect ives

Solicit ing execut ive endorsem ent , whenever possible, of t he t raffic classificat ions, especially
when det erm ining any m ission- crit ical applicat ions

Perform ing QoS funct ions in ( Cat alyst swit ch) hardware inst ead of ( Cisco I OS rout er)
soft ware, whenever possible

Classifying t raffic as close t o t he source as adm inist rat ively feasible, preferably at Layer 3
wit h st andards- based DSCP m arkings

Policing t raffic as close t o t he source as possible, following st andards- based rules ( such as
RFC 2597, " Assured Forwarding Markdown" ) , whenever possible
Provisioning at least one- quart er of a link t o service Best - Effort t raffic

Provisioning no m ore t han one- t hird of a link t o service real- t im e and st rict - priorit y t raffic

Provisioning a less- t han best - effort Scavenger queue, which should be assigned as low of a
bandwidt h allocat ion as possible

Underst anding and t horoughly t est ing desired QoS feat ures in conj unct ion wit h feat ures
already enabled on t he product ion net work

Deploying end- t o- end QoS in st ages during scheduled net work downt im e, wit h a
recom m ended rollback st rat egy
Further Reading
St andar ds:

RFC 791, " I nt ernet Prot ocol Specificat ion" : ht t p: / / www.iet f.org/ rfc/ rfc791 .

RFC 2474, " Definit ion of t he Different iat ed Services Field ( DS Field) in t he I Pv4 and I Pv6
Headers" : ht t p: / / www.iet f.org/ rfc/ rfc2474 .

RFC 2597, " Assured Forwarding PHB Group" : ht t p: / / www.iet f.org/ rfc/ rfc2597 .

RFC 2697, " A Single Rat e Three Color Marker" : ht t p: / / www.iet f.org/ rfc/ rfc2697 .

RFC 2698, " A Two Rat e Three Color Marker" : ht t p: / / www.iet f.org/ rfc/ rfc2698 .

RFC 3168, " The Addit ion of Explicit Congest ion Not ificat ion ( ECN) t o I P" :
ht t p: / / www.iet f.org/ rfc/ rfc3168 .

RFC 3246, " An Expedit ed Forwarding PHB ( Per- Hop Behavior) " :
ht t p: / / www.iet f.org/ rfc/ rfc3246 .

Cisco docum ent at ion:

Cisco I OS QoS Configurat ion Guide, Cisco I OS version 12.3:

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios123/ 123cgcr/ qos_vcg.ht m .

Cisco I OS Configurat ion GuideConfiguring Dat a Link Swit ching Plus, Cisco I OS version 12.3:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fibm _c/ bcfpart 2/ bcfdlsw.ht
.

Underst anding how rout ing updat es and Layer 2 cont rol packet s are queued on an int erface wit h a QoS
service policy ( PAK_priorit y) : ht t p: / / www.cisco.com / warp/ public/ 105/ rt gupdat es.ht m l .
Part II: QoS Toolset
Part I I of t his book provides cont ext for t he design chapt ers t hat follow by present ing a
brief overview of Cisco QoS t ools. Part icular em phasis is placed on t ool- specific
idiosyncrasies and t ool- int eract ion caveat s ( m any of which are not included in I OS
docum ent at ion) . A basic underst anding and fam iliarit y of t hese QoS t ools is assum ed.

The chapt ers in t his part of t he book are as follows:

Chapt er 3 Classificat ion and Marking Tools

Chapt er 4 Policing and Shaping Tools

Chapt er 5 Congest ion- Managem ent Tools

Chapt er 6 Congest ion- Avoidance Tools

Chapt er 7 Link- Specific Tools

Chapt er 8 Bandwidt h Reservat ion

Chapt er 9 Call Adm ission Cont rol ( CAC)

Chapt er 10 Cat alyst QoS Tools

Chapt er 11 WLAN QoS Tools

Chapter 3. Classification and Marking
Tools
This chapt er includes t he following t opics:

Classificat ion and m arking

Discussion of Layer 2 and Layer 3 m arking fields and how t hese t ranslat e t o each ot her

Packet m arking in different t echnologies, such as I P, MPLS, ATM, Fram e Relay, and
Et hernet

Class- based classificat ion and m arking t echniques and ot her m echanism s t o achieve t hese
result s

The first st ep in defining a Qualit y- of- Service ( QoS) policy is t o ident ify t he t raffic t hat is t o be
t reat ed different ly ( eit her preferent ially or different ially) . This is accom plished t hrough
classificat ion and m arking.

Alt hough t he t erm s classificat ion and m arking oft en are used int erchangeably, t he t erm s
represent dist inct and different act ions t hat work t oget her but also can be used independent ly.

Classificat ion t ools sort packet s int o different t raffic t ypes, t o which different policies t hen
can be applied. The classificat ion of packet s norm ally occurs at each node in t he net work
but is not required t o be done everywhere. Classificat ion of packet s can happen wit hout
m ar k ing.

Marking ( or re- m arking) t ypically est ablishes a t rust boundary on which scheduling t ools
lat er depend. The net work edge where m arkings are accept ed ( or rej ect ed) is referred t o as
t he t rust - boundary. Marking also can be used in ot her locat ions in t he net work, as
necessary, and is not always used solely for purposes of classificat ion.

As wit h t he general t erm s classificat ion and m arking , t here is a difference in t he act ion t hat t he
act ual t ools, nam ed classifiers and m arkers, t ake on t raffic.

Cla ssifie r s I nspect one or m ore fields in a packet t o ident ify t he t ype of t raffic t hat t he
packet is carrying. Aft er being ident ified, t he t raffic is direct ed t o t he applicable policy-
enforcem ent m echanism for t hat t raffic t ype, where it receives predefined t reat m ent ( eit her
preferent ial or deferent ial) . Such t reat m ent can include m arking and re- m arking, queuing,
policing, shaping, or any com binat ion of t hese ( and ot her) act ions.

M a r k e r s Writ e a field wit hin t he packet , fram e, cell, or label t o preserve t he classificat ion
decision t hat was reached at t he t rust boundary. By m arking t raffic at t he t rust boundary
edge, subsequent nodes do not have t o perform t he sam e in- dept h classificat ion and
analysis t o det erm ine how t o t reat t he packet .
Classification Tools
Classificat ion t ools exam ine any of t he following crit eria t o ident ify a flow and assign it for
preferent ial or deferent ial t reat m ent :

La ye r 1 ( L1 ) pa r a m e t e r s Physical int erface, subint erface, PVC, or port

La ye r 2 ( L2 ) pa r a m e t e r s MAC address, 802.1Q/ p class of service ( CoS) bit s, VLAN

ident ificat ion, experim ent al bit s ( MPLS EXP) , ATM cell loss priorit y ( CLP) , and Fram e Relay
discard eligible ( DE) bit s

La ye r 3 ( L3 ) pa r a m e t e r s I P Precedence, DiffServ code point ( DSCP) , source/ dest inat ion

I P address

La ye r 4 ( L4 ) pa r a m e t e r s TCP or User Dat agram Prot ocol ( UDP) port s

La ye r 7 ( L7 ) pa r a m e t e r s Applicat ion signat ures and uniform resource locat ors ( URLs) in
packet headers or payload

Figure 3- 1 shows t he progressive dept h at which a fram e or packet m ay be exam ined t o m ake a
classificat ion decision. I t is not shown t o scale because of space lim it at ions.

Figu r e 3 - 1 . Fr a m e / Pa ck e t Cla ssifica t ion Fie lds

N ot e
Figure 3- 1 is int ended t o represent only t he com parisons of dat a- link, net work,
t ransport , and applicat ion layer QoS filt ering crit eria and, t herefore, m any fields have
been om it t ed and t he diagram is not t o scale.

Only aft er t raffic is posit ively ident ified can policies be applied t o it . Therefore, best - pract ice
design recom m endat ions are t o ident ify and m ark t raffic ( wit h DSCP values) as close t o t he
source of t he t raffic as possible, t ypically in t he wiring closet or wit hin t he t rust ed devices ( such
as I P phones) t hem selves. I f m arkings and t rust s are set correct ly, t he int erm ediat e hops do not
have t o repeat t he sam e in- dept h classificat ion. I nst ead, t hey can adm inist er QoS policies ( such
as scheduling) based on t he previously set m arkings, which appear close t o t he beginning of t he
fram e or packet .

Modular QoS Command-Line Interface Class Maps

The principle t ool for QoS classificat ion wit hin Cisco I OS t oday is m odular QoS CLI ( MQC) based
class m aps. Class m aps ident ify t raffic flows using a wide array of filt ering crit eria, which are
individually defined by m a t ch st at em ent s wit hin t he class m ap. Mult iple m a t ch st at em ent s can
be defined under a single class m ap. When m ult iple m at ch st at em ent s are used, t he class m ap
can be specified as follows:

m a t ch - a ll A logical AND operand, m eaning t hat all m a t ch st at em ent s m ust be t rue at t he

sam e t im e for t he class m ap condit ion t o be t rue

m a t ch - a n y A logical OR operand, m eaning t hat any of t he m a t ch st at em ent s can be t rue

for t he class m ap condit ion t o be t rue

I ncluding m a t ch - a n y or m a t ch - a ll when defining a class m ap is opt ional, but it is im port ant t o

not e t hat if neit her is specified, t he default behavior is m a t ch - a ll. For exam ple, if cla ss- m a p
FOO is ent ered, t he Cisco I OS parser act ually expands t his t o cla ss- m a p m a t ch - a ll FOO wit hin
t he configurat ion. Exam ple 3- 1 illust rat es t he m at ching crit eria available wit hin MQC class- m aps.

Ex a m ple 3 - 1 . m a t ch - a ll as Default Cisco I OS Behavior

Router(config) class-map FOO

Router(config-cmap)#match ?
access-group Access group
any Any packets
class-map Class map
cos IEEE 802.1Q/ISL class of service/user priority values
destination-address Destination address
input-interface Select an input interface to match
ip IP specific values
mpls Multi Protocol Label Switching specific values
not Negate this match result
protocol Protocol
qos-group Qos-group
source-address Source address

Alt hough t he sequence in which class m aps are defined wit hin t he configurat ion is unim port ant ,
t he sequence of classes wit hin a policy m ap is im port ant . This is because, as wit h access list
( ACL) logic, policy m aps apply t he First - True- Mat ch rule, m eaning t hat t he classes exam ine a
packet unt il a m at ch is found. When a m at ch is found, t he classificat ion process finishes and no
furt her class m aps are checked. I f no m at ches are found, t he packet ends up in an im plicit class
default , which essent ially m eans " everyt hing else."

For exam ple, consider t he service policy shown in Exam ple 3- 2 t hat illust rat es t he classificat ion
of t wo classes of t raffic: VOI CE for voice t raffic and FAX- RELAY for fax t raffic. The sequence of
cla ss- m a p FAX- RELAY and cla ss- m a p VOI CE wit hin t he global configurat ion does not m at t er
t o t he classificat ion funct ionalit y; t hese can be ent ered in any order. The assum pt ion in t his
exam ple is t hat bot h voice t raffic and fax- relay t raffic are m arked t o DSCP EF at t heir respect ive
sources. Therefore, t he quest ion is how t o t reat t hese t wo t raffic t ypes different ly because t hey
are m arked t he sam e.

The policy m ap shown in Exam ple 3- 2 is unusual, alt hough valid, in t wo respect s:

M u lt iple pr ior it y cla sse s Bot h voice and fax t raffic m ust be priorit ized ( as covered in
Chapt er 5, " Congest ion- Managem ent Tools," a lat er chapt er on queuing) . Typically, bot h
t hese t raffic classes would be handled by a single class definit ion, but in t his case, t he
desire was t o cont rol st rict ly t he bandwidt h used by each class of t raffic. This required t wo
different priorit y class definit ions.

Police st a t e m e n t s in t h e pr ior it y cla sse s Norm ally, priorit y class t raffic is not explicit ly
policed, as I OS has an im plicit policer, which is discussed in addit ional det ail in Chapt er 5,
" Congest ion- Managem ent Tools," t o prevent t he st arvat ion of ot her queues. However, t his
exam ple shows how a service- level agreem ent ( SLA) can be st rict ly enforced so t hat
different classes of t raffic cannot exceed t he agreed- upon bandwidt h allocat ion.

Ex a m ple 3 - 2 . Cla ss D e fin it ion Se qu e n ce in Policy M a p

Router#show run
class-map match-all FAX-RELAY
match ip dscp ef
class-map match-all VOICE
match protocol rtp audio
!
policy-map VOICE-AND-FAX
class VOICE
priority 216
police cir 216000
class FAX-RELAY
priority 64
police cir 64000
class class-default
fair-queue

The policy m ap VOI CE- AND- FAX provides t he answer t hrough careful ordering of t he classes
wit hin it . First , all packet s are checked against t he class VOI CE, which perform s Net work- Based
Applicat ion Recognit ion ( NBAR) classificat ion t o ident ify whet her t he t raffic is Real- Tim e Prot ocol
audio ( in ot her words, voice) . Only t raffic t hat fails t his exam inat ion is checked against t he
second class under t he policy m ap ( t he class FAX- RELAY) .

The class FAX- RELAY checks whet her t he packet 's DSCP value is EF. Because only t wo t ypes of
t raffic can have DSCP values of EF ( voice and fax- relay) and voice has already been filt ered out ,
any rem aining t raffic t hat m at ches t hese crit eria m ust be fax- relay. Fax- relay t raffic t hen is
adm inist rat ively assigned a slight ly different t reat m ent . The det ails of t he t reat m ent in t his
exam ple are irrelevant . The em phasis is on how t he ordering of t he classes wit hin policy m aps
can offer m ore granular classificat ion opt ions because of t he First - True- Mat ch logic t hat policy
m aps em ploy. I f t he sequence of t hese t wo st at em ent s were reversed, t he policy would work
very different ly: No t raffic would ever show against t he VOI CE class because bot h voice and fax-
relay t raffic would be m at ched on DSCP EF and would be assigned t o t he FAX- RELAY class. All
ot her t raffic would fall int o t he im plicit class- default class. Figure 3- 2 shows t he decision
hierarchy for each packet exam ined by t he policy m ap VOI CE- AND- FAX.

Figu r e 3 - 2 . Cla ssifica t ion D e cision s by Policy M a p VOI CE- AN D - FAX

I t is im port ant t o not e t hat class m ap and policy m ap nam es ( sim ilar t o ACL nam es) are case
sensit ive t o t he Cisco I OS. Thus, cla ss- m a p foo is different from cla ss- m a p Foo, which is
different from cla ss- m a p FOO. Therefore, it is very im port ant t hat t he class m ap nam es and
cases m at ch exact ly t o t he class nam es called out under policy m aps. I n t his book, such nam es
are shown in uppercase let t ers t o clearly dist inguish t hem from Cisco I OS com m ands. This is
ent irely an adm inist rat ive preference.

Network-Based Application Recognition

Alt hough t he m aj orit y of dat a applicat ions can be ident ified using Layer 3 or Layer 4 crit eria
( such as discret e I P addresses or well- known TCP/ UDP port s) , som e applicat ions cannot be
ident ified by such crit eria alone. This m ight be because of legacy lim it at ions, but m ore likely it is
by deliberat e design. For exam ple, peer- t o- peer m edia- sharing applicat ions ( such as KaZaa,
Morpheus, and Napst er) deliberat ely negot iat e port s dynam ically wit h t he obj ect ive of
penet rat ing firewalls.

When Layer 3 or 4 param et ers are insufficient t o posit ively ident ify an applicat ion, NBAR is a
viable alt ernat ive solut ion.

NBAR is t he m ost sophist icat ed classifier in t he Cisco I OS t ool suit e. NBAR can recognize packet s
on a com plex com binat ion of fields and at t ribut es. However, it is im port ant t o recognize t hat
NBAR is m erely a classifier , not hing m ore. NBAR can ident ify packet s t hat belong t o a cert ain
t raffic st ream by perform ing deep- packet inspect ion, but it is up t o t he policy m ap t o det erm ine
what should be done wit h t hese packet s aft er t hey have been ident ified ( in ot her words, whet her
t hey should be m arked, policed, dropped, and so on) .

NBAR's deep- packet classificat ion exam ines t he dat a payload of st at eless prot ocols and ident ifies
applicat ion layer prot ocols by m at ching t hem against a Prot ocol Descript ion Language Module
( PDLM) , which is essent ially an applicat ion signat ure. Cisco I OS soft ware support s 98 prot ocols
via PDLMs as of I OS 12.3. Furt herm ore, because PDLMs are m odular, t hey can be added t o a
syst em wit hout requiring a Cisco I OS upgrade.

NBAR is dependent on Cisco Express Forwarding ( CEF) and perform s deep- packet classificat ion
only on t he first packet of a packet st ream . The rem ainder of t he packet s belonging t o t he
st ream t hen are CEF- swit ched. CEF is one of t he packet - forwarding m echanism s wit hin t he Cisco
I OS Soft ware; t here are also fast - and process- swit ching forwarding pat hs.

N ot e
The NBAR classifier is t riggered by t he m a t ch pr ot ocol com m and wit hin a class m ap
definit ion. I t is a m ore CPU- int ensive classifier t han classifiers t hat m at ch t raffic by
DSCPs or ACLs.

NBAR Protocol Classification

NBAR can classify packet s based on Layer 4 t hrough Layer 7 prot ocols, which dynam ically assign
TCP/ UDP port s. By looking beyond t he TCP/ UDP port num bers of a packet ( known as subport
classificat ion) , NBAR exam ines t he packet payload it self and classifies packet s on t he payload
cont ent , such as t ransact ion ident ifiers, m essage t ypes, or ot her sim ilar dat a. For exam ple, HTTP
t raffic can be classified by URLs or Mult ipurpose I nt ernet Mail Ext ension ( MI ME) t ypes using
regular expressions wit hin t he CLI .

NBAR also can classify Cit rix I ndependent Com put ing Archit ect ure ( I CA) t raffic and can perform
subport classificat ion of Cit rix t raffic based on Cit rix published applicat ions. Request s from Cit rix
I CA client s can be m onit ored for a published applicat ion t hat is dest ined for a Cit rix I CA m ast er
browser. Aft er receiving t he client request s t o t he published applicat ion, t he Cit rix I CA m ast er
browser direct s t he client t o t he server wit h t he m ost available m em ory. The Cit rix I CA client
t hen connect s t o t his Cit rix I CA server for t he applicat ion.

A sum m ary of prot ocols t hat NBAR can use for classificat ion follows. Because new capabilit ies
are added all t he t im e, t his is not an exhaust ive list . Not all NBAR classificat ion involves st at eful
inspect ion, and not all m a t ch pr ot ocol com m ands t rigger NBAR.

St at efully inspect ed prot ocols include t he following:

FTP Oracle SQL* NET
Exchange SunRPC

HTTP ( URL and TFTP

MI ME)

Net Show St ream Works

RealAudio VDOLiv e

r - com m ands

St at ic prot ocols include t he following:

Ext erior Gat eway Prot ocol ( EGP) NNTP

Generic Rout ing Encapsulat ion ( GRE) Not es

I CMP Net work Tim e Prot ocol ( NTP)

I PinI P PCAnywhere

I PSec POP3
EI GRP Point - t o- Point Tunneling Prot ocol ( PPTP)

BGP RI P

CU- SeeMe Resource Reservat ion Prot ocol ( RSVP)

DHCP/ BOOTP Secure FTP ( SFTP)

Dom ain Nam e Syst em ( DNS) SHTTP

Finger SI MAP

Gopher SI RC

HTTP SLDAP

Secure HTTP ( HTTP) SNNTP

I nt ernet Message Access Prot ocol SMTP

( I MPA)
I nt ernet Relay Chat ( I RC) SNMP

Ker ber os SOCKS

Layer 2 Tunnel Prot ocol ( L2TP) SPOP3

LDAP Secure Shell ( SSH)

MS- PPTP Secure Telnet ( STELNET)

MS- SQLServer Syslog

Net BI OS Telnet

Net work File Syst em ( NFS) X Window Syst em

Exam ple 3- 3 shows t he CLI of som e NBAR classificat ion configurat ions.
Ex a m ple 3 - 3 . N BAR Cla ssifica t ion Ex a m ple s

Router(config)# class-map match-any ERP

Router(config-cmap)# match protocol sqlnet
Router(config-cmap)# match protocol ftp
Router(config-cmap)# match protocol telnet

Router(config)# class-map match-any AUDIO-VIDEO

Router(config-cmap)# match protocol http mime "*/audio/*"
Router(config-cmap)# match protocol http mime "*/video/*"

Router(config)# class-map match-any WEB-IMAGES

Router(config-cmap)# match protocol http url "*.gif"
Router(config-cmap)# match protocol http url "*.jpg|*.jpeg"

Exam ple 3- 3 defines t hree different class m aps. The first one, t he class m ap ERP, inst ruct s t he
classifier ( NBAR) t o pick t raffic of any of t he prot ocols list ed in t he subsequent st at em ent s, which
include SQLNET, FTP, or Telnet t raffic. I n t he class m ap AUDI O- VI DEO, t he classifier is looking
for MI ME t raffic of part icular t ypesaudio and video, in t his case. The last class m ap, WEB-
I MAGES, is filt ering out HTTP t raffic for pict ure ( GI F or JPEG) cont ent .

I n addit ion t o classificat ion, NBAR can perform prot ocol discovery using t he sniffing capabilit ies
of it s classificat ion engine. Even if NBAR is not required for QoS policy classificat ion, it s prot ocol-
discovery m ode can provide valuable inform at ion about t raffic present on t he net work and how
m uch bandwidt h each t raffic t ype is using. Such inform at ion can be used in bandwidt h
provisioning exercises or for capacit y planning. An exam ple out put of NBAR's prot ocol- discovery
m ode is shown in Exam ple 3- 4.

Ex a m ple 3 - 4 . N BAR Pr ot ocol D iscove r y

Router#show ip nbar protocol-discovery stats byte-rate FastEthernet1/0

Input Output
Protocol 30second bit rate 30second bit rate
(bps) (bps)
-------------- ------------------ ------------------
telnet 368000 0
ftp 163000 0
http 163000 0
unknown 614000 0
Total 1308000 0

NBAR RTP Payload Classification

St at eful ident ificat ion of real- t im e audio and video t raffic can different iat e and classify t raffic on
t he basis of audio and video codec fields wit hin t he Real- Tim e Transport Prot ocol ( RTP) payload
of t he packet . Alt hough m ost voice classificat ion is done in coarser granularit y ( by m erely
separat ing signaling t raffic from speech pat h [ m edia] t raffic) and net work access oft en is allowed
or denied based on t he originat ing port or I P address, som et im es t raffic is desired t o be
classified by codec. One inst ance in which t his is useful is at t he t rust boundary bet ween an
ent erprise and a service provider net work where t he SLA is, for exam ple, for G.729 and G.711
t raffic only. I n t his inst ance, NBAR can be used t o ensure t hat voice calls of ot her codecs are not
allowed ont o t he net work.

The sam e m echanism s can be used if codecs of different bandwidt h needs m ust be filt ered out ,
for exam ple, t o ensure t hat call adm ission cont rol ( CAC) in t he net work is not broken. I n t his
case, low- bandwidt h codecs such as G.729 and G.723 can be separat ed from G.711 t raffic.

Filt ering t raffic by codec can be done by inspect ing t he payload t ype ( PT) field wit hin t he RTP
header, as defined by t he following:

RFC 1889: " RTP: A Transport Prot ocol for Real- Tim e Applicat ions"

RFC 1890: " RTP Profile for Audio and Video Conferences wit h Minim al Cont rol"

The com m and t o configure t his is as follows:

match protocol rtp [audio | video | payload-type payload-string]

Here, t he following is t rue:

a u d io Specifies m at ching by payload- t ype values 0 t o 23

vide o Specifies m at ching by payload- t ype values 24 t o 33

pa yloa d- t ype Specifies m at ching by payload- t ype value, for m ore granular m at ching

For exam ple, t he following com m and inst ruct s NBAR t o m at ch RTP t raffic wit h t he payload t ypes
0, 1, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, or 64:

match protocol rtp payload-type "0, 1, 4 - 0x10, 10001b - 10010b, 64"

As shown in t he exam ple, t he param et ers t o t he m a t ch pr ot ocol st at em ent can be given in

decim al, hexadecim al ( t he 0x not at ion) , or binary ( t he 10001b not at ion) num bers. I ndividual
num bers separat ed by com m as can be specified, and ranges of num bers can be used, as in t he
case of 4 0x10, which m eans a decim al value of 4 t o a hexadecim al value of 10 ( which equat es
t o a decim al value of 16) . Therefore, all RTP payload t ypes bet ween 4 and 16 are m at ched for
t his part of t he st at em ent . Sim ilarly, t he binary range 10001b t o 10010b equat es t o 17 t o 18 in
decim al.
Marking Tools
The m ain m arking t ools used t oday are class- based m arking and m arking using class- based
policing. Som e legacy m arking t echniques include com m it t ed access rat e ( CAR) and policy- based
rout ing ( PBR) . Voice gat eway packet m arking is anot her opt ion for I P t elephony applicat ions.

Class-Based Marking
Class- based m arking, int roduced in Cisco I OS Soft ware Release 12.1( 2) T, is an MQC- based
synt ax t hat uses t he se t com m and wit hin a policy m ap t o m ark packet s, fram es, cells, or labels.
Class- based m arking was CEF dependent in early Cisco I OS releases ( j ust aft er it s int roduct ion) ,
but t his lim it at ion was list ed in subsequent releases soon aft erward. I f you are using one of t he
init ial releases, ip ce f m ust be enabled in t he global configurat ion before using se t com m ands.

Ex a m ple 3 - 5 . Cla ss- Ba se d M a r k in g Opt ion s

Router(config)#policy-map CB-MARKING
Router(config-pmap)#class FOO
Router(config-pmap-c)#set ?
atm-clp Set ATM CLP bit to 1
cos Set IEEE 802.1Q/ISL class of service/user priority
discard-class Discard behavior identifier
dscp Set DSCP in IP(v4) and IPv6 packets
fr-de Set FR DE bit to 1
ip Set IP specific values
mpls Set MPLS specific values
precedence Set precedence in IP(v4) and IPv6 packets
qos-group Set QoS Group

I t is im port ant t o rem em ber t hat class- based m arking occurs aft er classificat ion of t he packet ( in
ot her words, se t happens aft er t he m at ch crit eria) . Thus, if used on an out put policy, t he packet
m arking applied can be used by t he next - hop node t o classify t he packet but cannot be used on
t his node for classificat ion purposes. On t he ot her hand, if class- based m arking is used on an
ingress int erface as an input policy, t he m arking applied t o t he packet can be used on t he sam e
device on it s egress int erface for classificat ion purposes.

Anot her point t o not e for out put policies is t hat bot h classificat ion and m arking can happen aft er
t unnel encapsulat ion, depending on where t he service policy is at t ached. Therefore, if a policy is
at t ached t o a GRE or I PSec t unnel int erface, t he m arking is applied t o t he original inner packet
header. I n m ost cases, t his m arking aut om at ically is copied t o t he t unnel header. On t he ot her
hand, if t he policy is at t ached t o t he physical int erface, only t he t unnel header ( t he out er
header) is m arked and t he inner packet header is left unchanged.

As an alt ernat ive, QoS preclassificat ion, discussed lat er in t his chapt er in t he sect ion t it led " Layer
3 Tunnel Marking Tools ," can be used t o ensure t hat classificat ion of t he packet happens on t he
inner packet header and not t he t unnel header values.

Class-Based Policing
Policing and ot her rat e- lim it ing t ools ( which are discussed in m ore det ail in Chapt er 4 , " Policing
and Shaping Tools" ) const it ut e one of t he ways t hat packet s can be m arked. I nst ead of j ust
m arking every packet of a cert ain t ype as a part icular value, a policer generally can re- m ark ( or
even drop) packet s t hat violat e an SLA. The following com m and shows t he synt ax for a rat e-
lim it er t hat t ransm it s packet s if t hey conform t o a specified rat e, re- m arks packet s if t hey
exceed t he rat e, and drops packet s if t hey violat e t he rat e.

police cir 1000000 bc 1000 pir 1000000 be 1000 conform-action transmit

exceed-action set-clp-transmit violate-action drop

Class- based policing can set t he I P Precedence, DSCP, MPLS EXP, Fram e Relay DE, or ATM CLP
of a packet based on rat e- lim it ing m easurem ent s, as shown in Exam ple 3- 6 .

Ex a m ple 3 - 6 . Re - M a r k in g Opt ion s for t h e Cla ss- Ba se d Police r

Router(config)#policy-map CB-POLICING
Router(config-pmap)#class FOO
lab-2691(config-pmap-c)#police 8000 conform-action ?
drop drop packet
exceed-action action when rate is within conform and
conform + exceed burst
set-clp-transmit set atm clp and send it
set-discard-class-transmit set discard-class and send it
set-dscp-transmit set dscp and send it
set-frde-transmit set FR DE and send it
set-mpls-exp-imposition-transmit set exp at tag imposition and send it
set-mpls-exp-topmost-transmit set exp on topmost label and send it
set-prec-transmit rewrite packet precedence and send it
set-qos-transmit set qos-group and send it
transmit transmit packet

Committed Access Rate

As wit h class- based policing, com m it t ed access rat e ( CAR) can be used t o set or change packet
m arkings. However, CAR is an older Cisco I OS policer t ool t hat generally is not int egrat ed wit h
t he MQC synt ax and can yield undesirable result s if used in conj unct ion wit h service policies.
Therefore, CAR is no longer a recom m ended policer.

Policy-Based Routing
Policy- based rout ing ( PBR) also is an older, non- MQC t ool t hat can perform lim it ed t raffic
m arking. Alt hough packet m arking is not t he m aj or funct ion of PBR, it can be used for writ ing I P
Precedence for packet s t hat m at ch specific crit eria.
Voice Gateway Packet Marking
For voice t raffic originat ing on a Cisco voice gat eway rout er, H.323, Media Gat eway Cont rol
Prot ocol ( MGCP) , and Session I nit iat ion Prot ocol ( SI P) t raffic can be m arked by t he source
gat eway. For a long t im e, only I P Precedence m arking was available for VoI P dial peers, and t his
only for m edia ( voice) packet s. I n early releases, ACLs were required t o m ark call- signaling
packet s in conj unct ion wit h class- based m arking.

Cisco I OS Soft ware Release 12.2( 2) T int roduced t he capabilit y t o m ark voice- sourced packet s on
t he voice gat eway wit h DSCPs, t oget her wit h t he capabilit y t o m ark signaling packet s separat e
from m edia packet s and t o m ark voice t raffic t hat did not use dial peers ( such as MGCP) . The
following com m ands were int roduced as part of t he sim plificat ion of QoS. They are used for
m arking t he voice t raffic at it s source, which is m ore efficient and easier t o m anage t han
m anually m arking such t raffic on t he nearest net work edge.

H.323 and SI P use a VoI P dial peer com m and t o m ark signaling or m edia packet s:

ip qos dscp [af11-af43 | cs1-cs7 | default | ef | num_0-63] [media | signaling]

MGCP uses a global gat eway com m and t o m ark signaling or m edia packet s:

mgcp ip-tos [rtp | signaling] precedence [0-7]

mgcp ip qos dscp [af11-af43 | cs1-cs7 | default | ef | num_0-63] [media | signaling

Anot her m ove t oward sim plificat ion in Cisco I OS Soft ware Release 12.2( 2) T was t o m ark voice
and call signaling by default wit h t he appropriat e DSCPs. This renders explicit m arking
unnecessary unless m arkings ot her t han t he recom m ended values are desired.

Voice gat eway packet - m arking feat ures are det ailed in Table 3- 1 .

Up t o 12.1.5T
and 12.2 m ainline

SI P, H.323

Dial peer for m edia

PBR, ACL, CB m arking for signaling

Yes

Dial peer, PBR: No

CB m arking: Yes

Media: 0
Signaling: 0

12.2.2T and lat er

SI P, H.323
Dial peer for m edia and
signaling m arking

Yes

Yes

Media: 0
Signaling: 0

12.1.5XM and
12.2.2T and lat er

MGCP

m gcp ip t os for m edia and

signaling

Yes

No

Media: 5
Signaling: 3

12.2.11T and lat er

SI P, H.323

Dial peer for m edia and

signaling m arking

Yes

Yes

Media: 5, EF
Signaling: 3,
AF31

12.2.11T and lat er

MGCP

m gcp ip qos dscp for m edia

and signaling

Yes

Yes

Media: 5, EF
Signaling: 3,
AF31

Ta ble 3 - 1 . Voice Ga t e w a y Pa ck e t M a r k in g Fe a t u r e Su m m a r y
by Cisco I OS Re le a se
 Cisco I OS QoS M a r k in g IP D e fa u lt
Re le a se Pr ot ocol Tools P D SCP M a r k in g

At t he sam e t im e, changes were m ade t o t he Cisco I P phones and Cisco CallManager t o m ark, by
default , voice m edia and signaling packet s sourced by t hese devices. The default m arkings are
list ed in Table 3- 2 .

Media

EF

Signaling

AF31 or CS3

Ta ble 3 - 2 . I P Ph on e a n d Cisco Ca llM a n a ge r D e fa u lt Voice

a n d Sign a lin g M a r k in g Su m m a r y

D SCP I PP 8 0 2 .1 Q/ p CoS

Layer 2 Marking Fields

Several cell, fram e, or packet fields can be used t o carry m arkings, including t he following:

La ye r 2 m a r k in g fie lds 802.1Q/ p CoS bit s, MPLS EXP, ATM CLP, and Fram e Relay DE bit s

La ye r 3 m a r k in g fie lds I P Precedence or DSCP

Because Cisco Cat alyst swit ches perform scheduling based on Layer 2 802.1Q/ p CoS m arkings, it
is im port ant t hat Et hernet fram es be correct ly m arked in cam pus or branch LANs. However,
Layer 2 m arkings ( Et hernet or ot herwise) are seldom of end- t o- end significance. This is because
Layer 2 m arkings are lost whenever t he Layer 2 m edia changes ( for exam ple, from Et hernet t o
WAN m edia) . I n addit ion, care should be t aken t hat Layer 2 m arkings are t ranslat ed t o and from
Layer 3 m arkings t o ensure consist ent end- t o- end QoS for t he fram e or packet , regardless of
where it m ight t ravel in t he net work.

Ethernet 802.1Q/p

Et hernet fram es can be m arked wit h t heir relat ive im port ance at Layer 2 by set t ing t he 802.1p
User Priorit y bit s ( CoS) of t he 802.1Q header, as shown in Figure 3- 3 .
 Figu r e 3 - 3 . Et h e r n e t Fr a m e 8 0 2 .1 Q/ p CoS Fie ld

Only 3 bit s are available for 802.1p m arking. Therefore, only eight classes of service ( 0 t hrough
7) can be m arked on Layer 2 Et hernet fram es. These CoS values are ident ical t o I P Precedence
values and t ypically are assigned according t o Table 3- 3 .

Reser v ed

Reser v ed

Voice

Videoconferencing

Call signaling

High- priorit y dat a

Medium - priorit y dat a

Best - effort dat a

Ta ble 3 - 3 . CoS/ I P Pr e ce de n ce Va lu e s by Applica t ion

Type s

CoS Va lu e Applica t ion

The possible values of t he 802.1Q/ p CoS bit s are t he sam e as t hose for I P Precedence. Because
t he field lengt h is t he sam e, I P Precedence can readily be m apped one t o one int o and out of
802.1Q/ p CoS values. However, DSCP values ( which are 6 bit s) cannot be m aint ained at t he
sam e granularit y when m apped int o and out of 802.1Q/ p CoS values because som e inform at ion
is lost in t he t ranslat ions.

Ethernet 802.1Q Tunnels

The Cisco Cat alyst 3550 swit ches offer an 802.1Q t unneling feat ure t hat enables service
providers t o provide Layer 2 VPN t unnels by double- t agging Et hernet fram es. As a t unneling
t echnology, t his encapsulat es t raffic from m ult iple VLANs of one cust om er wit h a single service
provider t ag. I t preserves t he cust om er VLAN t ag over t he service provider net work so t hat t he
service provider can offer a large num ber of VLANs t o m any cust om ers.

Because of t he double- t agging of Et hernet fram es in 802.1Q t unneling, t he CoS value of t he

inner fram e is not visible t o QoS feat ures in t he service provider net work. Because t he CoS value
from t he inner fram e current ly is not copied t o t he out er fram e when t he t unnel is ent ered, t he
only form of QoS t hat t he service provider can provide for cust om er t raffic is QoS on t he ingress
port , as shown in Exam ple 3- 7 ( for a Cisco 3550 swit ch) .

Ex a m ple 3 - 7 . Se t t in g QoS on a n I n gr e ss Por t of Cisco 3 5 5 0 Sw it ch

Switchport(config)#interface fastethernet0/1
Switchport(config-if)#mls qos cos 5
! Sets 802.1Q CoS to 5 on outer frame
Switchport(config-if)#mls qos cos override
! Overrides any existing CoS value on the outer frame

Layer 2 prot ocol packet s can be given high priorit y by using t he l2 pr ot ocol- t u n n e l cos global
com m and.

Frame-Relay Discard Eligible Bit

The Fram e Relay DE bit in t he address field of a Fram e Relay fram e is used t o indicat e which
packet s are less im port ant and, t herefore, eligible t o be dropped before ot hers if congest ion
occurs wit hin a Fram e Relay cloud. As it s nam e im plies, t he Fram e Relay DE bit is a single bit
t hat can represent only one of t wo set t ings: 0 or 1. I f congest ion occurs in a Fram e Relay
net work, fram es wit h t he DE bit set at 1 are discarded before fram es wit h t he DE bit set at 0.

Tradit ionally, Cisco I OS rout ers could not cont rol t he Fram e Relay DE bit . The default Fram e
Relay DE set t ing was 0, and only t he Fram e Relay swit ch on t he service provider net work ent ry
point could set t his bit t o 1 if t he CI R was violat ed. However, t he class- based m arking feat ure
was enhanced in Cisco I OS Soft ware Release 12.2( 2) T t o allow t he rout er t o cont rol t his bit ; it
provided t he opt ion of set t ing t he bit t o 1 before t raffic exit s t he rout er, and it support ed t he
capabilit y t o read t he bit upon t raffic ingress. Therefore, alt hough t he Fram e Relay DE bit is a
fairly crude m arking opt ion, it can be used in a Fram e Relay net work t o indicat e high- priorit y
t raffic ( DE bit 0, t he default value) and lower- priorit y t raffic ( DE bit 1) , which can be dropped
should congest ion occur. The following is an exam ple of how t he Fram e Relay DE bit can be set
wit h class- based m arking on t raffic t hat previously was ident ified as out - of- cont ract .
 N ot e
I n older Cisco I OS releases, class- based m arking is dependent on CEF. Therefore,
whenever MQC se t com m ands are t o be used, ip ce f already m ust be enabled wit hin
t he configurat ion. I n lat er Cisco I OS releases, t his rest rict ion has been lift ed.

Exam ple 3- 8 shows how t he Fram e Relay DE bit can be set inside a service policy.

Ex a m ple 3 - 8 . Se t t in g t h e Fr a m e Re la y D E Bit

Router#show run
policy-map SET-FR-DE
class OUT-OF-SLA
set fr-de
class class-default
fair-queue

ATM Cell-Loss Priority Bit

The purpose of t he ATM CLP bit is exact ly t he sam e as t hat of t he Fram e Relay DE bit . I t is a
binary field wit h t wo values: 0 ( t he default ) , which indicat es higher- priorit y t raffic, and 1, for
cells carrying lower- priorit y t raffic t hat is eligible t o be dropped if congest ion is encount ered.

Alt hough t he capabilit y t o set t he CLP bit has been available in a policy m ap since Cisco I OS
Soft ware Release 12.1.5T wit h t he int roduct ion of class- based m arking, it is im port ant t o not e
t hat not all ATM int erface drivers allow t his capabilit y. The Cisco 7200 ATM port adapt ers ( PAs)
have long had t his capabilit y. The Cisco 2600/ 3600/ 3700 ATM int erfaces im plem ent ed t his
capabilit y in Cisco I OS Soft ware Release 12.2.1( 1) T, and t he digit al subscriber line ( DSL)
int erfaces ( ADSL and G.SHDSL) require Cisco I OS Soft ware Release 12.2.8YN or lat er t o achieve
t his feat ure. Exam ple 3- 9 shows how t he ATM CLP bit can be set wit h class- based m arking on
t raffic t hat previously was ident ified as out - of- cont ract .

Ex a m ple 3 - 9 . M a r k in g w it h ATM - CLP

Router# show run

policy-map SET-ATM-CLP
class OUT-OF-SLA
set atm-clp
class class-default
fair-queue

MPLS Experimental Bits

MPLS is a t unneling t echnology t hat envelops an I P packet wit h an MPLS label t hat has it s own
field definit ions for rout ing and QoS. More t han one MPLS label can be used t o envelop a packet .
Typically, t wo labels are used in m ost MPLS VPN scenarios. I n som e scenarios, t hree labels are
used. MPLS labels cont ain 3 bit s for CoS m arking. These bit s are referred t o as t he MPLS EXP
bit s.

The possible values of t he MPLS EXP bit s for CoS are t he sam e as t hose for 802.1Q/ p CoS and I P
Precedence. Because of t he sam e lengt h t ranslat ions ( 3 bit s t o/ from 6 bit s) explained earlier for
802.1Q/ p CoS, I P Precedence ( which are 3 bit s) readily can be m apped int o and out of MPLS EXP
values, but DSCP values ( which are 6 bit s) cannot be m aint ained at t he sam e granularit y. Figure
3 - 4 shows t he MPLS EXP bit s wit hin an MPLS label.

Figu r e 3 - 4 . M PLS EXP Bit s W it h in a n M PLS La be l

As of Cisco I OS Soft ware Release 12.1( 5) T, t he MPLS EXP bit s can be read ( m a t ch com m and
wit hin a class m ap) and writ t en ( se t com m and wit hin a policy m ap) using MQC. When a packet
ent ers t he MPLS net work at t he provider edge ( PE) rout er, t he I P Precedence of t he packet ( by
default ) aut om at ically is copied t o t he MPLS EXP field in t he MPLS header. No explicit act ion is
t ypically necessary t o m ark MPLS EXP values, unless t he values require re- m arking because of
adm inist rat ive policies.

I n t heory, upon exit ing t he MPLS net work, t he original I P packet re- em erges unchanged wit h it s
I P header t ype of service ( ToS) field int act . Again, no explicit act ion needs t o be t aken unless t he
value requires re- m arking. While inside t he MPLS net work, t he packet 's ToS field ( I P Precedence
or DSCP) is irrelevant because t he MPLS EXP bit s are used t o det erm ine t he QoS t reat m ent of
t he packet wit hin t he MPLS cloud, as shown in Figure 3- 5 .

Figu r e 3 - 5 . Re la t ion sh ip of I P a n d M PLS Pa ck e t M a r k in g

I n MPLS t unneling scenarios ( furt her discussed in Chapt er 16 , " I PSec VPN QoS Design" ) , t here
can be m ult iple MPLS headers on a packet . To accom m odat e m arking of all or som e of t hese
headers, t here are t wo opt ions on t he se t m pls e x pe r im e n t a l com m and:

se t m pls e x pe r im e n t a l im posit ion Set s a specific value on all labels t hat are pushed
ont o t he packet

se t m pls e x pe r im e n t a l t opm ost Set s a specific value only on t he t opm ost MPLS label on
t he packet

I n pract ice, however, som e service providers current ly re- m ark t he I P Precedence or ToS fields
of packet s t raversing t heir MPLS Virt ual Privat e Net works ( VPN) t o enforce SLAs. Three m ain
t unneling m odes are used for m apping Layer 3 ( I P Precedence/ DSCP) m arkings t o and from
MPLS EXP values: uniform m ode, short - pipe m ode, and pipe m ode. These m odes are discussed
in det ail in Chapt er 16 .

Layer 3 Marking Fields

Layer 3 packet m arking wit h I P Precedence and DSCPs is t he m ost widely deployed m arking
opt ion because Layer 3 packet m arkings have end- t o- end net work significance and easily can be
t ranslat ed t o t he Layer 2 fram e m arkings previously discussed.

As wit h Layer 2 t unneling, Layer 3 t unneling t echnologies pose a challenge in preserving packet
m arkings by enveloping t he packet wit h a new header/ packet . Som e t echnologies aut om at ically
copy t he inner packet ToS field t o t he out er header packet , whereas ot hers do not .

IP Type of Service and IP Precedence

The second byt e in an I Pv4 packet is t he t ype of service ( ToS) byt e. The first 3 bit s ( by
t hem selves) are referred t o as t he I P Precedence bit s, as shown in Figure 3- 6 .
 Figu r e 3 - 6 . I Pv4 Type of Se r vice Byt e ( I P Pr e ce de n ce Bit s a n d D SCP)

The I P Precedence bit s, sim ilar t o t he 802.1Q/ p CoS bit s and t he MPLS EXP bit s, allow for only
eight values of m arking ( 0 t hrough 7) . Because values 6 and 7 generally are reserved for
net work cont rol t raffic ( such as rout ing) and value 0 is t he default m arking value, really only five
rem aining values can be used t o different iat e non- best - effort t raffic. Of t hese five rem aining
values, however, t he following is t rue:

I P Precedence value 5 is recom m ended for voice.

I P Precedence value 4 is shared by videoconferencing and st ream ing video.

I P Precedence value 3 is recom m ended for call signaling.

This leaves only t wo m arking values ( I P Precedence 1 and 2) available for all dat a applicat ion
m arking opt ions. Thus, m any ent erprises find I P Precedence m arking t o be overly rest rict ive and
favor inst ead t he 6- bit / 64- value DSCP m arking m odel.

N ot e
I n t his book, I P Precedence is viewed as a legacy t echnology, and all Layer 3 m arking
recom m endat ions are based on DSCP only ( unless specific const raint s exist ) .

Differentiated Services Code Points

As shown in Figure 3- 6 , DSCPs use t he sam e 3 bit s as I P Precedence and com bine t hese wit h
t he next 3 bit s of t he ToS byt e t o provide a 6- bit field for QoS m arking. Thus, DSCP values range
from 0 ( 000000) t o 63 ( 111111) . This range provides unprecedent ed richness in m arking
granularit y.

DSCP values can be expressed in num eric form or by special keyword nam es, called per- hop
behav ior s ( PHB) . Three defined classes of DSCP PHBs exist : Best - Effort ( BE or DSCP 0) , Assured
Forwarding ( AFxy) , and Expedit ed Forwarding ( EF) . I n addit ion t o t hese t hree defined PHBs,
Class- Select or ( CSx) codepoint s have been defined t o be backward com pat ible wit h I P
Precedence ( in ot her words, CS1 t hrough CS7 are ident ical t o I P Precedence values 1 t hrough
7) . The RFCs describing t hese PHBs are 2547, 2597, and 3246.

RFC 2597 defines four Assured Forwarding classes, denot ed by t he let t ers AF followed by t wo
digit s. The first digit denot es t he AF class and can range from 1 t hrough 4. ( I ncident ally, t hese
values correspond t o t he t hree m ost significant bit s of t he codepoint , or t he I PP value t hat t he
codepoint falls under.) The second digit refers t o t he level of drop preference wit hin each AF
class and can range from 1 ( lowest drop preference) t o 3 ( highest drop preference) . For
exam ple, during periods of congest ion ( on an RFC 2597com pliant node) , AF33 would be dropped
m ore oft en ( st at ist ically) t han AF32, which, in t urn, would be dropped m ore oft en ( st at ist ically)
t han AF31. Figure 3- 7 shows t he Assured Forwarding PHB encoding schem e.

Figu r e 3 - 7 . D iffSe r v Assu r e d For w a r din g PH B En codin g Sch e m e

Figure 3- 8 shows a sum m ary of PHBs along wit h t heir decim al and binary equivalent s.

Figu r e 3 - 8 . D iffSe r v PH Bs w it h D e cim a l a n d Bin a r y Equ iva le n t s

Layer 3 Tunnel Marking Tools

Cisco rout ers offer a variet y of t unneling feat ures, such as GRE, I PSec, and L2TP, which enable
service providers t o provide Layer 3 VPN t unnels by enveloping one I P packet wit hin anot her.
Such encapsulat ion m asks t he original header inform at ion t o provide feat ures such as privacy,
encrypt ion, and address preservat ion. Tunneling t echnologies also are used t o carry non- I P
prot ocols over an I P backbone.
A wide range of packet header layout s wit h t unneling t echnologies exist , but t he prim ary
charact erist ic t hat t hey have in com m on is t hat t he original I P header is enveloped in an out er
header packet . While in t he t unnel, only t he out er I P header's ToS byt e is exam ined t o
det erm ine what QoS policies should be applied t o t he packet . The ToS byt e from t he inner
packet m ight or m ight not be copied aut om at ically t o t he out er header packet . I f it is not copied
aut om at ically, explicit com m ands are required t o copy t he ToS byt e ( or t o set t he out er header
ToS byt e, independent of t he inner packet 's ToS values) .

Som e exam ple packet header layout s of GRE and I PSec packet s are shown in Figure 3- 9 .

Figu r e 3 - 9 . L3 Tu n n e l Pa ck e t La you t Ex a m ple s

Three m et hods provide QoS m arking for Layer 3 t unnels: QoS preclassificat ion ( QoS for VPNs
feat ure) , ToS copying/ reflect ion, and independent header- packet m arking. Each is discussed in
m ore det ail in t he following sect ions.

QoS Preclassify

The QoS preclassify feat ure was int roduced in Cisco I OS Soft ware Release 12.1( 5) T on Cisco
7100 and 7200 series rout ers and in Cisco I OS Soft ware Release 12.2( 2) T for lower- end rout ers.
This com m and creat es a clone of t he inner packet header ( st rict ly for int ernal rout er processing)
before t he packet is enveloped. Upon egress, t he rout er com pares t he cloned header against any
policies applied t o t he egress int erface ( because it no longer can read inform at ion from t he
original packet header because it is enveloped) . Then t he applicable policies are serviced on t he
packet flow, and t he clone is discarded. An advant age of t he QoS preclassify feat ure is t hat not
only is t he ToS byt e of t he inner header used for QoS classificat ion purposes, but ot her
I P/ TCP/ UDP header param et ers such as source/ dest inat ion I P addresses and source/ dest inat ion
port s can be used.

St rict ly speaking, t he QoS preclassify feat ure is only a classificat ion feat ure. I t s m arking
funct ionalit y is only t ransient , in t he sense t hat it m akes a copy of t he inner packet header and
it s m arkings, but t his header never is t ransm it t ed as part of t he packet .

Exam ples of t he qos pr e - cla ssifica t ion com m and for various t ypes of t unnels are shown in
Exam ple 3- 10 .

Ex a m ple 3 - 1 0 . QoS Pr e cla ssifica t ion Ex a m ple s

 GRE 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-X
Router(config-crypto-map)# qos pre-classify

ToS Reflection

QoS m arking for t unnels also can be achieved by copying t he ToS byt e from t he inner header t o
t he out er header. This is done by default on m ost plat form s for I PSec and GRE t unnels. For
L2TP, t he l2 t p t os r e fle ct com m and can be used.

Independent Header-Packet Marking

Anot her opt ion is t o m ark t he t unnel header explicit ly as any ot her packet would be m arked. This
m ight be t he least useful of t he t unnel- m arking m et hods because t he charact erist ics for QoS
t reat m ent alm ost always are associat ed wit h t he inner packet . Nevert heless, it is possible t o
m ark t he t unnel header independent ly wit h I P Precedence or DSCPs.

Translating Layer 2 and Layer 3 Packet Markings

The Layer 2 and Layer 3 m arking fields discussed in t he previous sect ions are sum m arized in
Table 3- 4 .

Et hernet

802.1Q/ p

0 to 7

Fram e Relay

DE bit

0 to 1

ATM
2

CLP bit

0 to 1

MPLS

EXP

0 to 7

IP

I P Precedence

0 to 7

IP

DSCP

0 t o 63

Ta ble 3 - 4 . L2 a n d L3 M a r k in g Opt ion s Su m m a r y

Fie ld W idt h
Te ch n ology La ye r M a r k in g Fie ld ( Bit s) Va lu e Ra n ge

I t is im port ant t o rem em ber t hat several t echnologies change packet headers or wrap one
packet int o anot her out er packet so t hat one packet or fram e becom es t he payload of t he next .
When t his happens, packet m arking is lost unless it explicit ly is carried forward t o t he new
packet ( or fram e) header. These repacket izat ion changes occur when a dat a segm ent crosses a
Layer 3 or Layer 2 t echnology boundary or when t unneling t echnologies are used. To preserve
packet m arkings end t o end, t here is oft en t he need t o t ranslat e one t ype of m arking t o anot her
at a net work boundary ( for exam ple, LAN t o WAN edge) or t echnology boundary ( for exam ple,
t he st art of an encrypt ion t unnel bet ween t wo sit es) .

Som e exam ples include t hese:

 VoI P ove r Fr a m e Re la y A t ranslat ion from Layer 3 t o Layer 2 in which a VoI P packet is
enveloped wit hin a Fram e Relay fram e. The Fram e Relay fram e header m arking field ( DE
bit ) is 0 unless it is m arked explicit ly.

Recom m endat ion: Leave t he voice packet 's DE bit as 0, but consider m arking low- priorit y
dat a packet s sharing t he sam e congest ion point s wit h DE bit 1.

VoI P ove r ATM A t ranslat ion from Layer 3 t o Layer 2 t ranslat ion in which a VoI P packet is
enveloped wit hin m ult iple ATM cells ( t ypically AAL5) . The ATM cell header m arking field
( CLP) should be clear.

Recom m endat ion: Leave t he voice packet 's ATM CLP as 0, but consider m arking low-
priorit y dat a packet s t hat share t he sam e congest ion point s wit h CLP 1.

VoI P ove r Et h e r n e t t o VoI P ove r a W AN A t ranslat ion from Layer 2 t o Layer 3 in which
VoI P on a LAN segm ent carries an 802.1Q/ p packet header m arking. When t he packet hit s
a rout er and heads out over t he WAN, t he Layer 3 I P packet cont aining t he voice payload
m ight or m ight not be m arked appropriat ely, depending on t he configurat ion and
capabilit ies of t he swit ch, rout er, or I P phone.

Recom m endat ion: Configure t hat LAN swit ch t o convert 802.1Q/ p m arking t o DSCPs if t he
packet is handed off t o a Layer 3 segm ent . I f t he swit ch is not capable of such m apping,
perform t he m apping from Layer 2 t o Layer 3 on t he rout er's LAN edge. A m apping from
Layer 3 t o Layer 2 also m ight be needed on rem ot e- branch rout ers t o rest ore lost CoS
m appings for VoI P Et hernet fram es ent ering t he branch from t he WAN.

VoI P ove r M PLS A t ranslat ion of Layer 3 t o Layer 2. As wit h ot her t unneling t echnologies,
MPLS envelops t he I P packet wit h anot her header ( MPLS label) . On t unnel ent ry, t he I P
packet 's ToS field is m apped t o t he MPLS EXP bit s by default .

Recom m endat ion: Ensure t hat t he default m apping feat ure has been im plem ent ed in t he
Cisco I OS soft ware release and plat form ; ot herwise, m ark t he MPLS EXP field explicit ly.
Keep in m ind t hat t he MPLS EXP field is only 3 bit s long, so I P Precedence will t ranslat e
correct ly, but DSCPs will lose granularit y in t he t ranslat ion( s) . Many ent erprise net works do
not have cont rol over t he MPLS backbone t hey m ight use. I f so, work wit h t he service
provider offering t he MPLS net work t o ensure t hat t he net work is configured correct ly.

Tu n n e l t e ch n ologie s su ch a s L2 TP, I PSe c, a n d GRE A t ranslat ion of Layer 3 t o Layer 3.

These t echnologies wrap an I P packet inside anot her I P packet by put t ing a t unnel header
in t he front of t he packet . Aside from t he fact t hat t here are bandwidt h provisioning
im plicat ions wit h such addit ional overhead, t his m asks t he packet header m arking of t he
inner packet . Not e t hat t his sit uat ion is pot ent ially problem at ic only upon ent ering t he
t unnel because a new packet header is added t o t he exist ing packet . Upon exit ing t he
t unnel, t he original packet re- em erges wit h it s m arking int act , so no ext ra act ion or caut ion
is necessary.

Recom m endat ion: Use t he QoS preclassify feat ure t o ensure t hat packet classificat ion
happens on t he inner packet .

802.1Q/p to and from DSCP

Figure 3- 10 shows an exam ple of how Layer 2 ( 802.1Q/ p CoS) m arkings can be t ranslat ed t o
Layer 3 ( DSCP) m arkings using class- based m arking. I n t his exam ple, CoS 5 is m apped t o and
from DSCP EF, and CoS 3 is m apped t o and from DSCP CS3. ( These are t he t ypical values used
for voice and call signaling for I P t elephony.) Cisco I P phones m ark voice packet s t o CoS 5 and
DSCP EF, and call signaling packet s t o CoS 3 and DSCP CS3 or AF31 aut om at ically and by
default ( rendering such m apping of Layer 2 t o Layer 3 unnecessary, in m ost cases) .

Figu r e 3 - 1 0 . LAN - t o- W AN M a ppin g of CoS a n d D SCP

N ot e
Et hernet 802.1Q/ p is t he only Layer 2 m arking t echnology t hat m ight require
bidirect ional m appings ( Layer 2 t o Layer 3 and Layer 3 t o Layer 2) . Cisco Cat alyst
swit ches ( including t hose at rem ot e branch locat ions) assign scheduling based on
Layer 2 802.1p CoS m arkings, which are lost when t he packet s t raverse a WAN m edia.
All ot her Layer 2 m arking opt ions are applicable t o t he WAN/ VPN t ransit cloud only and
lose t heir relevance aft er t he fram e is received at t he rem ot e branch. Because of t his,
and because t he underlying Layer 3 m arkings are preserved t hrough t he t ransit cloud,
a second m apping is rarely necessary wit h Fram e Relay DE, ATM CLP, and MPLS EXP
m arkings.

Exam ple 3- 11 shows how t he policy m aps in Figure 3- 10 can be applied t o out going Voice VLAN
and Dat a VLAN Fast Et hernet 802.1Q subint erfaces on t he rout er.

Ex a m ple 3 - 1 1 . Applyin g L3 - t o- L2 M a r k in g on LAN I n t e r fa ce

Router#sh run
interface FastEthernet0/1
no ip address
full-duplex
!
interface FastEthernet0/1.100
description Voice-VLAN
encapsulation dot1Q 100
ip address 10.6.0.129 255.255.255.192
 service-policy input COS-TO-DSCP
service-policy output DSCP-TO-COS
!
interface FastEthernet0/1.500
description DATA-VLAN
encapsulation dot1Q 500
ip address 10.6.0.1 255.255.255.128
service-policy input COS-TO-DSCP
service-policy output DSCP-TO-COS
!

DSCP to Frame Relay DE Bit

Figure 3- 11 shows an exam ple of using t he Fram e Relay DE bit t o preserve som e level of priorit y
in t he Fram e Relay cloud. Wit hin t his ent erprise, scavenger t raffic is m arked t o DSCP CS1. I f
congest ion occurs wit hin t he Fram e Relay cloud, such t raffic should be t he first t o be dropped.
On t he rout er's egress int erface, all fram es carrying scavenger t raffic are t o have t heir Fram e
Relay DE bit s set t o 1. Furt herm ore, all ot her t raffic is rat e lim it ed, and fram es of t raffic t hat
exceed t his lim it also have t heir Fram e Relay DE set t o 1.

Figu r e 3 - 1 1 . Tr a ffic Pr ior it y M a r k in g w it h Fr a m e Re la y D E Bit s

DSCP to ATM CLP Bit

Figure 3- 12 shows an exam ple of using t he ATM- CLP bit t o preserve som e level of priorit y in t he
ATM cloud. As in t he previous exam ple, scavenger t raffic is m arked t o DSCP CS1. I f congest ion
occurs wit hin t he ATM cloud, such t raffic should be t he first t o be dropped. On t he rout er's
egress int erface, all fram es carrying scavenger t raffic are t o have t heir ATM CLP bit s set t o 1.
Furt herm ore, all ot her t raffic is being rat e lim it ed, and cells of t raffic t hat exceed t his lim it also
have t heir ATM CLP bit s set t o 1.

Figu r e 3 - 1 2 . Tr a ffic Pr ior it y M a r k in g w it h ATM CLP Bit s

DSCP to MPLS EXP Bits

Figure 3- 13 shows an exam ple of m apping DSCPs t o MPLS EXPs. This m ight be needed when
MPLS VPN service providers offer various levels of service based on MPLS EXP m arkings.
Current ly, t hough, m ost service providers base t heir adm ission t o various levels of service by
exam ining t he DSCP m arkings of packet s offered t o t hem from t heir ent erprise cust om er edge
( CE) rout ers. I n t his exam ple, t he service provider is offering t hree levels of service: Realt im e
( as adm it t ed by MPLS EXP value 5) , Business- Dat a ( as adm it t ed by MPLS EXP value 3) , and Best
Effort ( everyt hing else) . The CE- t o- PE link in t his exam ple is a T1 and, as such, has no
serializat ion issues ( which are discussed in great er det ail lat er) . The ent erprise cust om er want s
bot h voice and call- signaling t raffic t o be adm it t ed t o t he service provider's Realt im e class.
Therefore, t he cust om er m aps bot h DSCP EF and DSCP AF31 t o MPLS EXP 5.

Figu r e 3 - 1 3 . Tr a ffic Pr ior it y M a r k in g w it h M PLS EXP Bit s

By default , voice aut om at ically would have been m apped from DSCP EF t o MPLS EXP 5.
However, call signaling would have been m apped t o MPLS EXP 3 by default . Furt herm ore, t he
ent erprise cust om er has t ransact ional dat a m arked t o DSCP AF21 and bulk dat a m arked t o DSCP
AF11, which, by default , would be m apped t o MPLS EXP 2 and 1, respect ively. The ent erprise
cust om er want s bot h of t hese t o be adm it t ed t o t he service provider's Business- Dat a class. To
accom plish t his, t he ent erprise cust om er m anually m aps DSCP AF21 and AF11 t o MPLS EXP 3.
Everyt hing else is m arked t o MPLS EXP 0.

Figure 3- 13 illust rat es how and where t he m apping of t he DSCP t o MPLS EXP value could occur,
in t he case of a service- provider m anaged CE scenario: specifically, under a Pipe Mode wit h
Explicit Null LSP configurat ion ( for m ore det ail on t his design opt ion, refer t o Chapt er 15 " MPLS
VPN QoS Design" ) .

However, in m ost scenarios, ent erprise cust om ers have no cont rol or visibilit y int o t he MPLS
backbone, which t ypically is owned and m anaged by t he service provider.

IP Precedence to ATM/Frame Relay PVCs (PVC Bundling)

Under som e circum st ances, m ult iple perm anent virt ual circuit ( PVC) m odels m ight be
econom ically at t ract ive t o ent erprise cust om ers. Such m ult iple- PVC m odels offer ent erprise
cust om ers m ore granular levels of service across ATM or Fram e Relay clouds t han sim ple CLP or
DE bit m arkings alone. When m ult iple PVCs exist , ent erprises can use PVC bundles t o assign
relat ive t raffic priorit ies over t hese WAN t opologies.

N ot e
Alt hough bundling is widely deployed, it is an aging and inefficient QoS t echnology. At
t he t im e of t his writ ing, it support s only I P Precedence, not DSCP. Bundling is
inefficient because lower- priorit y applicat ions never gain access t o any excess
bandwidt h t hat m ight exist on higher- priorit y PVCs. Therefore, any unused bandwidt h
on t hese PVCs is wast ed.

An exam ple of bundling is out lined in Figure 3- 14 . An ent erprise has purchased four separat e
ATM PVCs wit h varying levels of ATM QoS. I t want s voice ( I P Precedence 5) t o be assigned t o a
dedicat ed variable bit rat e real- t im e ( VBR- rt ) PVC, video ( I P Precedence 4) and call signaling ( I P
Precedence 3) t o be assigned t o a variable bit rat e non- real- t im e ( VBR- nrt ) PVC, t ransact ional
dat a ( I P Precedence 2) and bulk dat a ( I P Precedence 1) t o be assigned t o an available bit rat e
( ABR) PVC, and everyt hing else t o be assigned t o an unspecified bit rat e ( UBR) PVC.

Figu r e 3 - 1 4 . I P Pr e ce de n ce t o ATM PVC Bu n dle Ex a m ple

[View full size image]

A sam ple ATM PVC bundling configurat ion t hat corresponds t o t he exam ple is shown in Exam ple
3- 12 .

I P Precedence- t o- ATM VC bundling has been a Cisco I OS feat ure for several years. Bundling
funct ionalit y for Fram e Relay PVCs was int roduced in Cisco I OS Soft ware Release 12.2.1( 3) T.
Mapping I P Precedence m arkings t o ATM VCs provides t ruer levels of service because of t he ATM
service class at t ribut es t hat define t he ATM PVCs. Fram e Relay PVCs have no int rinsic service
class at t ribut es associat ed wit h t hem , but t hey do offer t he capabilit y t o guarant ee bandwidt h t o
a part icular class of t raffic across t he backbone.

Ex a m ple 3 - 1 2 . Sa m ple ATM PVC Bu n dlin g Con figu r a t ion

Router# show run

vc-class atm VOICE-PVC-256
vbr-rt 256 256
tx-ring-limit 3
precedence 5
no bump traffic
protect group
!
vc-class atm VIDEO-PVC-256
vbr-nrt 256 256
tx-ring-limit 3
precedence 4-3
no bump traffic
protect group
!
vc-class atm BUSINESS-DATA-PVC-512
abr 512 512
precedence 2-1
no bump traffic
protect group
!
vc-class atm BEST-EFFORT-PVC-512
ubr 512
tx-ring-limit 3
precedence other

VC bundling offers QoS by separat ing classes of t raffic over individual PVCs. Therefore, it is
im port ant t o rem em ber t hat ot her QoS t ools t arget ed at priorit izing different t ypes of t raffic on
t he sam e VC, such as LLQ, do not readily apply here. Also, PVC bundles do not offer bandwidt h-
sharing arrangem ent s ( such as Mult ilink Point - t o- Point Prot ocol [ MLP] and Fram e Relay m ult ilink
bundling) because t hey dedicat e a part icular PVC t o a given class of t raffic. I f t hat class does not
use it s bandwidt h allocat ion, it cannot be reallocat ed t o ot her t ypes of t raffic. I f bandwidt h-
sharing feat ures are required, Mult ilink PPP over ATM ( MLPoATM) or Mult ilink PPP over Fram e
Relay ( MLPoFR) bundles m ust be used in conj unct ion wit h MQC- based LLQ/ CBWFQ policies.

Table Map Feature

Alt hough t he se t com m and can be used individually, as discussed in t he previous sect ions, t o
t ranslat e a packet m arking from one t ype t o anot her, t his m ight be cum bersom e in t he
configurat ion if t he sam e t ranslat ion is required in m any places. To ease t he configurat ion of
t ranslat ing packet m arkings, t he t a ble m a p feat ure can be used. The com m and synt ax is as
follows:

table-map table-map-name map from from-value to to-value

[default default-action-or-value]

This can be used on t he se t com m and as shown in Exam ple 3- 13 .

Ex a m ple 3 - 1 3 . Con figu r in g t h e Ta ble M a p Fe a t u r e

Router(config)#table-map table1
Router(config-tablemap)#map from 2 to 1
Router(config)#policy-map CB-marking
Router(config-pmap)#class FOO
Router(config-pmap-c)#set mpls experimental topmost qos-group table table1

Exam ple 3- 14 shows a num ber of se t com m and exam ples using t he t able m ap feat ure t o
t ranslat e from one t ype of packet m arking t o anot her.

Ex a m ple 3 - 1 4 . Use of t h e Ta ble M a p Fe a t u r e

set precedence cos table table-map-name

set dscp cos table table-map-name
set cos precedence table table-map-name
set cos dscp table table-map-name
set qos-group precedence table table-map-name
set qos-group dscp table table-map-name
set mpls experimental topmost qos-group table table-map-name
set mpls experimental imposition precedence table table-map-name
set mpls experimental imposition dscp table table-map-name
set qos-group mpls exp topmost table table-map-name
set precedence qos-group table table-map-name
set dscp qos-group table table-map-name
Summary
This chapt er exam ined classificat ion and m arking feat ures and t ools. Classificat ion is t he act ion
of inspect ing a packet ( cert ain fields wit hin t he packet ) t o det erm ine what t ype of packet or
t raffic it is. This det erm inat ion is used t o guide t he t reat m ent t hat t he packet ( and ot her packet s
of t he sam e t raffic t ype or st ream ) will receive from t he node and t he net work.

Marking is t he act ion of changing a field wit hin t he packet header t o not e t he det erm inat ion
reached by t he classifier. The various ways of doing packet m arking at L2 and L3 up t o L7 were
illust rat ed, and ways t o t ranslat e one t ype of m arking t o anot her were discussed.

The t reat m ent of t he packet , which is based on t he classificat ion and m arking result s, includes
capabilit ies such as policing, shaping, and queuing. Policing and shaping are discussed in
Chapt er 4, " Policing and Shaping Tools," and queuing is discussed in Chapt er 5, " Congest ion-
Managem ent Tools."
Further Reading
General

Class- based m arking:

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fqos_c/ fqcprt 1/ qcfcbm rk.ht

Class- based policing ( Cisco I OS Soft ware Release 12.2.2T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fqos_c/ fqcprt 4/ qcfpoli.ht m

Fram e Relay DE bit m arking ( Cisco I OS Soft ware Release 12.2.2T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ cbpm ark2.ht m
.

Enhanced packet m arking ( Cisco I OS Soft ware Release 12.2.1[ 3] T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft enpkm k.ht

Packet classificat ion based on Layer 3 packet lengt h ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft m chpkt .ht

Packet classificat ion using t he Fram e Relay DLCI num ber ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft pcdlci.ht m

DiffServ

DiffServ for end- t o- end qualit y of service ( Cisco I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt dfsv.ht m

Classifying VoI P signaling and m edia wit h DSCP for QoS ( Cisco I OS Soft ware Release 12.2.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ ft _dscp.ht m

Cont rol plane DSCP support for RSVP ( Cisco I OS Soft ware Release 12.2.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ dscprsvp.ht m
.

Voice Gat eway Packet Marking ( Cisco I OS Soft ware Release 12.2.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ ft _dscp.ht m

L2 Protocol Tunneling

Cat alyst 3550 I OS ( Cisco I OS Soft ware Release 12.1.14EA1) docum ent at ion:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ c3550/ 12114ea1/ 3550scg/ swt unnel.ht m

Cat alyst 3550 802.1Q Tunneling Configurat ion Guide:

ht t p: / / wwwin.cisco.com / eag/ dsbu/ solut ions/ docum ent s/ 06_802.1Q% 20Tunneling% 20Config% 20Guide
.
 L2TP I P ToS reflect com m and I OS ( Cisco I OS Soft ware Release 12.3) docum ent at ion:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios123/ 123cgcr/ dial_r/ dia_l1g.ht m # 11310

VPN

Qualit y of service for Virt ual Privat e Net works ( Cisco I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt qosvpn.ht m
.

Qualit y of service for Virt ual Privat e Net works ( Cisco I OS Soft ware Release 12.2.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ ft qosvpn.ht m
.

NBAR

Net work- Based Applicat ion Recognit ion and Dist ribut ed Net work- Based Applicat ion Recognit ion ( Cisco
I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ dt nbarad.ht m
.

NBAR RTP Payload Classificat ion ( Cisco I OS Soft ware Release 12.2.8T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ dt nbarad.ht m
.

Net work- Based Applicat ion Recognit ion Prot ocol Discovery Managem ent I nform at ion Base ( Cisco I OS
Soft ware Release 12.2.1[ 5] T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 15/ ft pdm ib.ht m
.

MPLS

MPLS class of service enhancem ent s ( Cisco I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ m ct 1214t .ht m
.

MPLS QoS m ult i- VC m ode for PA- A3 ( Cisco I OS Soft ware Release 12.2.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ cos1221t .ht m
.

DiffServ- aware MPLS t raffic engineering ( DS- TE) ( Cisco I OS Soft ware Release 12.2.4T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 4/ ft _ds_t e.ht m

MPLS DiffServ- aware t raffic engineering ( DS- TE) over ATM ( Cisco I OS Soft ware Release 12.2.8T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ ft _ds_t e.ht m

IPATM/Frame Relay Bundles

I P t o ATM class of service ( Cisco I OS Soft ware Release 12.0.3T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 3/ ipat m cs2.ht m
 .

I P t o ATM CoS, per VC WFQ and CBWFQ ( Cisco I OS Soft ware Release 12.0.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 5/ ipat m 3.ht m

I P t o ATM class of service m apping for SVC bundles ( Cisco I OS Soft ware Release 12.2.4T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 4/ ft svbund.ht m
.

MPLS EXP t o ATM VC bundling ( Cisco I OS Soft ware Release 12.2.8T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ ft m pls.ht m

Fram e Relay PVC bundles wit h QoS support for I P and MPLS ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft _frbnd.ht m
.

MPLS EXP t o Fram e Relay VC bundling ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft _frbnd.ht m
.

Level 2 to Level 3 Packet-Marking Translation

Enhanced packet m arking ( Cisco I OS Soft ware Release 12.2.1[ 3] T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft enpkm k.ht
.
Chapter 4. Policing and Shaping Tools
This chapt er includes t he following t opics:

Policing, shaping, and t he differences bet ween t he int ent and operat ion of t hese t echniques

Policing t ools such as com m it t ed access rat e ( CAR) and class- based policing

Advanced policing t opics, such as t he single- rat e and t wo- rat e t hree- color policers, and
hierarchical, m ult iact ion, color- aware, and percent age- based policing

Shaping t ools such as ATM and Fram e Relay t raffic shaping ( FRTS) , generic t raffic shaping
( GTS) , and class- based shaping

Policers and shapers are t he oldest form s of QoS m echanism s. These t ools have sim ilar
obj ect ivesnam ely, t o ident ify and respond t o t raffic violat ions. Policers and shapers usually
ident ify t raffic violat ions in an ident ical m anner. However, t hey differ in how t hey respond t o t he
violat ions.

Policers perform inst ant aneous checks for t raffic violat ions and t ake im m ediat e prescribed
act ions when such violat ions occur. For exam ple, a policer can det erm ine whet her t he offered
load is in excess of t he defined t raffic rat e and t hen can re- m ark or drop t he out - of- cont ract
t raffic. Figure 4- 1 shows only a dropping act ion t aken by t he policer, alt hough ot her t ypes of
act ions ( for exam ple, re- m arking t he packet or sim ply t ransm it t ing it ) are also possible.

Figu r e 4 - 1 . Ge n e r ic Policin g Ve r su s Sh a pin g

Shapers are t raffic- sm oot hing t ools t hat work in conj unct ion wit h queuing m echanism s. The
obj ect ive of a shaper is t o send all t he t raffic offered t o an int erface, but t o sm oot h it out so t hat
it never exceeds a given rat e. Shapers usually are em ployed t o m eet service- level agreem ent s
( SLA) or t o com pensat e for nonbroadcast , m ult iple- access idiosyncrasies. I f t he offered t raffic
m om ent arily exceeds t he defined rat e, t he excess t raffic is buffered and delayed unt il t he offered
t raffic once again dips below t he defined rat e.

Figure 4- 1 illust rat es t he difference bet ween policing and shaping. Bot h m echanism s m easure
t raffic against a given t raffic rat e.

Table 4- 1 com pares t he charact erist ics of policing and shaping t ools.

Ta ble 4 - 1 . Com pa r ison s Be t w e e n Police r s a n d Sh a pe r s

Police r Sh a p e r
Causes TCP resends as t raffic is dropped Typically delays ( rat her t han drops) t raffic;
involves fewer TCP resends

I nflexible and inadapt able; m akes Can adapt t o net work congest ion by queuing
inst ant aneous packet drop decisions excess t raffic

An ingress or egress int erface t ool Typically an egress int erface t ool
Rat e lim it ing wit hout buffering Rat e lim it ing wit h buffering
Alt hough policing and shaping t ools are not em ployed direct ly t o provide QoS for real- t im e
packet s ( such as voice and int eract ive video) , t hey do regulat e and st abilize t raffic flows so t hat
service guarant ees can be m ade for such real- t im e applicat ions. Wit hout policers and shapers,
unexpect ed burst s in dat a t raffic could affect t he j it t er and lat ency t hresholds adversely for real-
t im e t raffic.

Also of not e is t hat policers and shapers can work in t andem ; t hey are not m ut ually exclusive
t ools.
Token Bucket Algorithms
Cisco I OS policers and shapers are m odeled aft er t oken bucket algorit hm s. Essent ially, t oken
bucket algorit hm s are m et ering engines t hat keep t rack of how m uch t raffic can be sent t o
conform t o t he specified t raffic rat es. A t oken perm it s t he algorit hm t o send a single bit ( or, in
som e cases, a byt e) of t raffic. These t okens are grant ed at t he beginning of som e t im e
increm ent , t ypically every second, according t o t he specified rat e referred t o as t he com m it t ed
inform at ion rat e ( CI R) . The CI R is t he access bit rat e cont ract ed wit h a service provider or t he
service level t o be m aint ained.

For exam ple, if t he CI R is set t o 8000 bps, t hen 8000 t okens are placed in a " bucket " at t he
beginning of t he t im e period. ( Not e t hat t his descript ion represent s a sim plified view of t he
algorit hm and m ight not be st rict ly t rue in all cases, but it illust rat es t he general operat ion of t he
policing m echanism .) Each t im e a bit of t raffic is offered t o t he policer, t he bucket is checked for
t okens. I f t here are t okens in t he bucket , t he t raffic is passed. One t oken is rem oved from t he
bucket for each bit of t raffic t hat is passed. Therefore, t raffic is viewed t o conform t he rat e, and
t he specified act ion for conform ing t raffic is t aken. ( Typically, t he conform ing t raffic is
t ransm it t ed.) When t he bucket runs out of t okens, any addit ional offered t raffic is viewed t o
exceed t he rat e, and t he exceed act ion is t aken. ( The exceeding t raffic t ypically eit her is re-
m arked or is dropped.)

N ot e
At t he end of t he second, t here m ight be unused t okens. The handling of t he unused
t okens is a key different iat or am ong policers. This is discussed in t he " Policers" sect ion
lat er in t his chapt er.

Because t he clock rat e of t he int erface cannot change t o enforce a policy, t he only way t hat a
rat e lim it can be im posed on an int erface is t o use t im e- division m ult iplexing ( TDM) . Wit h TDM,
when a rat e lim it ( or CI R) is im posed on an int erface, t he lim it ed t raffic is allocat ed a subsecond
t im e slice during which it can be sent . This subsecond t im e slice is referred t o as t he int erval ( or
Tc) . For exam ple, if an 8- kbps CI R is im posed on a 64- kbps link, t raffic can be sent for an
int erval of 125 m s ( 64,000 bps / 8000 bit s) .

The ent ire am ount of t he CI R ( 8000 bit s) could be sent at once, but t hen t he algorit hm would
have t o wait 875 m s before it could send any m ore dat a ( t o im pose t he rat e lim it ) . Such an
int erpacket delay likely would be viewed as excessive. Therefore, t o sm oot h out t he flow over
each second, t he CI R is divided int o sm aller unit s, referred t o as t he com m it t ed burst ( Bc) ,
which is t he sust ained num ber of bit s t hat can be t ransm it t ed per int erval. These sm aller unit s
are sent over m ult iple inst ances during a single second. Cont inuing wit h t he previous exam ple, if
t he Bc is set t o 1000, each com m it t ed burst can t ake only 15.6 m s ( 1000 bit s / 64,000 bps) t o
send t raffic out t he int erface at t he clock rat e. The algorit hm wait s 109.4 m s ( 125 m s 15.6 m s)
and sends anot her 15.6 m s of dat a. This process is repeat ed a t ot al of eight t im es during t he
second.

Therefore, t he t oken bucket algorit hm is as follows:

CI R = Bc / Tc

Cisco I OS Soft ware does not perm it t he explicit definit ion of t he int erval. I nst ead, it t akes t he
CI R and Bc as argum ent s from which t he int erval and t he num ber of burst s per second are
derived. For exam ple, if t he CI R is 8000 and t he Bc is set t o 4000, t wo burst s occur per second
( Tc = 500 m s) . I f t he Bc is set t o 2000, four burst s occur per second ( Tc = 250 m s) . I f t he Bc is
set t o 1000, eight burst s occur per second ( Tc = 125 m s) .

The preceding exam ple illust rat es t he operat ion of t he feat ure from a t heoret ical perspect ive.
From a pract ical perspect ive, when im plem ent ing net works, Tc should not exceed 125 m s.
Short er int ervals can be configured and are necessary t o lim it j it t er in real- t im e t raffic, but
longer int ervals are not pract ical for m ost net works because t he int erpacket delay becom es t oo
large.

The earliest policers all use a single- rat e t wo- color m arker/ policer m odel wit h a single t oken
bucket algorit hm . I n t his m odel, t raffic is ident ified as one of t wo st at es ( colors) : conform ing t o
or exceeding t he CI R. Marking and dropping act ions are perform ed on each of t hese t wo st at es
of t raffic. This t ype of m arker/ policer is fairly crude and is illust rat ed in Figure 4- 2 .

Figu r e 4 - 2 . Sin gle - Ra t e Tw o- Color Police r Effe ct on Tr a ffic Flow ( Sin gle
Tok e n Bu ck e t Police r )

Alt hough a policer can be deployed at ingress or egress int erfaces, it oft en is deployed at t he
net work edge on t raffic ingress. I f packet s will be dropped, t here is lit t le point in spending
valuable CPU cycles rout ing and processing t hese packet s. However, policers also oft en are
deployed at t he t raffic egress int erface t o cont rol bandwidt h used or are allocat ed t o a part icular
class of t raffic. This bandwidt h decision oft en is not m ade unt il t he packet s reach t he egress
int erface.
Policers
As m ent ioned before, policers det erm ine whet her each packet conform s or exceeds ( or,
opt ionally, violat es) t o t he t raffic configured policies and t ake t he prescribed act ion. The act ion
t aken can include dropping or re- m arking t he packet . Conform ing t raffic is t raffic t hat falls wit hin
t he rat e configured for t he policer. Exceeding t raffic is t raffic t hat is above t he policer rat e but
st ill wit hin t he burst param et ers specified. Violat ing t raffic is t raffic t hat is above bot h t he
configured t raffic rat e and t he burst param et ers.

How t raffic is separat ed, where it is policed, and why are im port ant quest ions t o keep in m ind in
t he overall net work QoS design. I t is not product ive, for exam ple, t o police DSCP EF ( t ypically
voice) t raffic or call- signaling t raffic because t he incom ing rat es of t hese t raffic t ypes do not
t olerat e packet loss and delay. I nst ead, t he m axim um rat es of t hese t raffic t ypes should be
cont rolled at t heir origin by call adm ission cont rol m echanism s ( which are discussed in Chapt er
9, "Call Adm ission Cont rol [ CAC] " ) so t hat excessive real- t im e t raffic is not allowed ont o t he
net work.

Policers as Markers
I f none of t he configured act ions for conform or exceed includes a drop funct ion, t he operat ion of
t he policer becom es t hat of a condit ional m arker. This is why t he t erm s m arker and policer oft en
are used int erchangeably, as t hey are in t his chapt er.

Re- m arking packet s wit h a policer should be done wit h care, keeping in m ind t he overall policies
of t he net work. Packet s t ypically are m arked as close t o t he source as t echnically and
adm inist rat ively feasible ( eit her at t he source it self, if t rust ed, or at a net work t rust boundary) .
I n t hese locat ions, t he t raffic t ypically is m arked by applicat ion: voice, call signaling, video, high-
priorit y dat a, and so on. This can be t hought of as a vert ical separat ion of t raffic.

A policer, however, has no direct knowledge of applicat ions and m arks t raffic ( if configured t o
perform m arking) based on t he t raffic rat e. This can be t hought of as a horizont al separat ion of
t raffic. A policer could have indirect knowledge of an applicat ion by virt ue of t he class where t he
policer is appliedin t his configurat ion, t he applicat ion already has been separat ed from ot her
t raffic int o it s own horizont al class. The policer it self, however, does not look at t he class; it
looks at only t he t raffic rat e for t he t raffic flowing t hrough it .

Committed Access Rate

CAR is t he oldest policing t ool offered in t he Cisco I OS Soft ware and is included in t his chapt er
prim arily for hist orical reasons. However, t he Cisco 7300 plat form s st ill use CAR in cert ain
configurat ions. RFC- com pliant policers are available in newer releases of t he Cisco I OS Soft ware,
so CAR is not generally recom m ended for QoS deploym ent s.

I n addit ion t o packet - drop capabilit ies, CAR can classify and m ark packet s using I PP, DSCPs, and
QoS group set t ings. Exam ple 4- 1 illust rat es how t o use CAR rat e lim it ing on applicat ions such as
web and FTP t raffic, t o ensure available capacit y for ot her t raffic.
Ex a m ple 4 - 1 . CAR Policin g Ex a m ple

Router# sh run
interface Hssi0/0/0
description 45Mbps to Router2
rate-limit input access-group 101 20000000 24000 32000
conform-action set-prec-transmit 2 exceed-action set-prec-transmit 0
rate-limit input access-group 102 10000000 24000 32000
conform-action set-prec-transmit 2 exceed-action drop
rate-limit input 8000000 16000 24000 conform-action set-prec-transmit 5
exceed-action drop
ip address 200.200.14.250 255.255.255.252

access-list 101 permit tcp any any eq www

access-list 102 permit tcp any any eq ftp

Access list 101 defines and m at ches web ( WWW) t raffic. The first r a t e - lim it st at em ent works on
t raffic m at ched by t his access list :

rate-limit input access-group 101 20000000 24000 32000

conform-action set-prec-transmit 2 exceed-action set-prec-transmit 0

I t lim it s t he rat e of web t raffic t o 20 Mbps, wit h a norm al burst size of 24,000 byt es and an
excess burst size of 32,000 byt es. Traffic t hat conform s t o t he rat e ( less t han 20 Mbps) is
m arked wit h an I P Precedence of 2; t raffic t hat exceeds t he rat e is m arked wit h an I P
Precedence of 0. No t raffic is dropped by t his st at em ent .

Access list 102 defines and m at ches FTP t raffic. The second r a t e - lim it st at em ent works on
t raffic m at ched by t his access list :

rate-limit input access-group 102 10000000 24000 32000

conform-action set-prec-transmit 2 exceed-action drop

I t lim it s t he rat e of FTP t raffic t o 10 Mbps, wit h a norm al burst size of 24,000 byt es and an
excess burst size of 32,000 byt es. Traffic t hat conform s t o t he rat e ( less t han 10 Mbps) is
m arked wit h an I P Precedence of 2; t raffic t hat exceeds t he rat e is dropped.

The t hird r a t e - lim it st at em ent works on rem aining t raffic:

rate-limit input 8000000 16000 24000 conform-action set-prec-transmit 5

exceed-action drop

I t lim it s t his t raffic t o 8 Mbps, wit h a norm al burst size of 16,000 byt es and an excess burst size
of 24,000 byt es. Traffic t hat conform s t o t he rat e ( less t han 8 Mbps) is m arked wit h an I P
Precedence of 5; t raffic t hat exceeds t he rat e is dropped.

Class-Based Policing
Configuring class- based policing using t he MQC synt ax is an easy way t o act ivat e policing for
only cert ain classes of t raffic. Wit h class- based policing, class definit ions represent applicat ion
separat ion, and policing is perform ed only on t he classes configured in t he policy m ap. This
generally includes AF and BE classes in which t he drop priorit y is increased on out - of- cont ract
t raffic ( for inst ance, re- m arking from AF21 t o AF22 or AF23) or t he t raffic is dropped out right .

Traffic in classes t hat are not policed cont ends for bandwidt h availabilit y along wit h all ot her
t raffic on t he int erface. When no congest ion exist s, all t raffic is t ransm it t ed. When congest ion is
experienced, packet s can be dropped out of nonpoliced classes as well as policed classes.

Class- based policing uses class m aps and policy m aps. A class m ap ident ifies t he t raffic t o be
policed ( or t he policer can be applied t o class- default t o police everyt hing) . The policy m ap t hen
det ails t he CI R, Bc, and ot her policing param et ers, including t he conform and exceed act ions t o
be t aken.

Class- based policing was int roduced in Cisco I OS Soft ware Release 12.1( 5) T. Enhancem ent s
were m ade in Cisco I OS Soft ware Release 12.2( 2) T. Class- based policing is support ed in t he CEF
pat h and in t he fast - and process- swit ching pat hs. The policer can be specified at t he int erface,
subint erface, or even ATM/ Fram e Relay PVC levels. Class- based policing works on bot h unicast
and m ult icast packet s.

Class-Based Policing Benefits

Class- based policing is t he current ly recom m ended t ool for policing. I t s m aj or advant ages over
CAR are sum m arized here:

Class- based policing is com pliant wit h DiffServ RFCs ( CAR is not ) .

Policing feat ure enhancem ent s ( such as percent age- based bandwidt h specificat ion and
hierarchical policing) are m ade only t o t he class- based policing feat ures, not t o CAR.

CAR does not exist wit hin t he MQC synt ax. Therefore, it s st at ist ics cannot be t ied back t o
t he policy st at ist ics shown by t he sh ow policy in t e r fa ce com m and.

Class- based policing st at ist ics are available in t he CI SCO- CLASS- BASED- QOS- MI B, offering
enhanced net work m anagem ent and m onit oring capabilit y.

The granularit y of classificat ion for class- based policing is far superior t o t hat available for
CAR. For exam ple, NBAR can be used wit h class- based policing but not wit h CAR.

Single-Rate Three-Color Marker/Policer

An im provem ent t o t he single- rat e t wo- color m arker/ policer algorit hm is based on RFC 2697,
which det ails t he logic of a single- rat e t hree- color m arker.

The single- rat e t hree- color m arker/ policer uses an algorit hm wit h t wo t oken bucket s. Any
unused t okens in t he first bucket are placed in a second t oken bucket t o be used as credit s lat er
for t em porary burst s t hat m ight exceed t he CI R. The allowance of t okens placed in t his second
bucket is called t he excess burst ( Be) , and t his num ber of t okens is placed in t he bucket when Bc
is full. When t he Bc is not full, t he second bucket cont ains t he unused t okens. The Be is t he
m axim um num ber of bit s t hat can exceed t he burst size.

This t wo t oken bucket m echanism allows t hree possible t raffic condit ions t o be ident ified ( hence
t he t erm t hree- color) . Traffic can be ident ified as follows:

Con for m To t he CI R

Ex ce e d The CI R wit hin t he excess burst allowance credit s

Viola t e Beyond bot h t he CI R and any excess burst allowance credit s

For t hese rat e- based decisions, t he following act ions can be specified:

Con for m Opt ionally re- m ark and t ransm it

Ex ce e d Drop or opt ionally re- m ark and t ransm it

Viola t e Drop or opt ionally re- m ark and t ransm it

Policing is used not only t o drop out - of- profile packet s, but also t o re- m ark t hem , t hus indicat ing
t o downst ream dropping m echanism s t hat t hey should be dropped ahead of t he in- profile
packet s.

The single- rat e t hree- color m arker uses t he following definit ions wit hin t he RFC:

CI R Com m it t ed inform at ion rat e, t he policed rat e

CBS Com m it t ed burst size, t he m axim um size of t he first t oken bucket

EBS Excess burst size, t he m axim um size of t he second t oken bucket

Tc Token count of CBS, t he inst ant aneous num ber of t okens left in t he CBS bucket ( Do not
confuse t he t erm Tc here wit h t he earlier use of Tc in t he cont ext of t im e elapsed for
policing or shaping t raffic int ervals.)

T e Token count of EBS, t he inst ant aneous num ber of t okens left in t he EBS bucket .

B Byt e size of offered packet

Figure 4- 3 illust rat es t he logical flow of t he single- rat e t hree- color m arker/ policer ( t wo t oken
bucket ) algorit hm .

Figu r e 4 - 3 . RFC 2 6 9 7 Sin gle - Ra t e Th r e e - Color Police r Logic ( Tw o

Tok e n Bu ck e t Algor it h m )
The single- rat e t hree- color policer's t olerance of t em porary burst s, shown in Figure 4- 4 , result s
in fewer TCP ret ransm issions and, t hus, m ore efficient bandwidt h ut ilizat ion. Furt herm ore, it is a
highly suit able t ool for m arking according t o RFC 2597 AF classes, which have t hree " colors" ( or
drop preferences) defined per class ( AFx 1, AFx 2, and AFx 3) .

Figu r e 4 - 4 . RFC 2 6 9 7 Sin gle - Ra t e Th r e e - Color Police r Effe ct on Tr a ffic

Flow ( Tw o Tok e n Bu ck e t Police r )
Tem porary burst s ( shown shaded above t he line in t he graph on t he right in Figure 4- 4 ) are
perm it t ed in excess of t he CI R only if unused t oken credit s ( shown shaded below t he line in t he
graph) have been accum ulat ed. Ot herwise, t his t raffic is dropped.

Exam ple 4- 2 shows t he configurat ion t o police t raffic in class- default t o a CI R of 256 kbps, wit h a
Bc of 8000 byt es and a Be of 8000 byt es. Not e t hat , for t his policer, t he CI R is defined in bit s per
second, but Bc and Be are defined in byt es.

Ex a m ple 4 - 2 . Cla ss D e fa u lt Policin g Ex a m ple

Router# sh run
policy-map RFC2697-POLICER
class class-default
police cir 256000 bc 8000 be 8000
conform-action set-dscp-transmit af31
exceed-action set-dscp-transmit af32
violate-action set-dscp-transmit af33

Two-Rate Three-Color Marker/Policer

The single- rat e t hree- color m arker/ policer was a significant im provem ent for policers, in t hat it
m ade allowance for t em porary t raffic burst s ( as long as t he overall average t ransm it t ed rat e was
equal t o or below t he CI R) . However, t he variat ion in t he num ber of accum ulat ed excess burst
credit s could cause a degree of unpredict abilit y in t raffic flows. To im prove on t his, a t wo- rat e
t hree- color m arker/ policer was defined in RFC 2698. This policer addresses t he peak inform at ion
rat e ( PI R) , which is unpredict able in t he RFC 2697 m odel. Furt herm ore, t he t wo- rat e t hree- color
m arker/ policer allows for a sust ainable excess burst ( negat ing t he need t o accum ulat e credit s t o
accom m odat e t em porary burst s) and allows for different act ions for t he t raffic exceeding t he
different burst values.
The t wo- rat e t hree- color m arker/ policer was int roduced in Cisco I OS Soft ware Release 12.2( 4) T
and uses t he following param et ers t o m et er t he t raffic st ream :

PI R Peak inform at ion rat e, t he m axim um rat e t hat t raffic ever is allowed

PBS Peak burst size, t he m axim um size of t he first t oken bucket

CI R Com m it t ed inform at ion rat e, t he policed rat e

CBS Com m it t ed burst size, t he m axim um size of t he second t oken bucket

Tp Token count of CBS, t he inst ant aneous num ber of t okens left in t he PBS bucket

Tc Token count of EBS, t he inst ant aneous num ber of t okens left in t he CBS bucket

B Byt e size of offered packet

The t wo- rat e t hree- color policer also uses an algorit hm wit h t wo t oken bucket s, but t he logic
varies slight ly. I nst ead of t ransferring unused t okens from one bucket t o anot her, t his policer
has t wo separat e bucket s t hat are filled each second wit h t wo separat e t oken rat es. The first
bucket is filled wit h t he PI R num ber of t okens and t he second bucket is filled wit h t he CI R
num ber of t okens. I n t his m odel, t he Be works t he sam e as t he Bc, except for t he PBS bucket
( not t he CBS bucket ) . This m eans t hat Be represent s t he peak lim it of t raffic t hat can be sent
during a subsecond int erval.

The logic varies furt her in t hat t he init ial check is t o see whet her t he t raffic is wit hin t he PI R.
Only t hen is t he t raffic com pared against t he CI R. ( I n ot her words, a violat e condit ion is checked
for first , t hen an exceed condit ion, and finally a conform condit ion, which is t he reverse of t he
logic of t he previous m odel.) This logic is illust rat ed in Figure 4- 5 .

Figu r e 4 - 5 . RFC 2 6 9 8 Tw o- Ra t e Th r e e - Color Police r Logic ( Tw o Tok e n

Bu ck e t Algor it h m )
The t wo- rat e t hree- color m arker allows for sust ainable excess burst s ( and is not dependent on
accum ulat ing credit s) and has a hard- t op peak lim it , as shown in Figure 4- 6 .

Figu r e 4 - 6 . RFC 2 6 9 8 Tw o- Ra t e Th r e e - Color Police r Effe ct on Tr a ffic

Flow ( Tw o Tok e n Bu ck e t Police r )
Sust ained excess burst s ( shown shaded) are perm it t ed in excess of t he CI R ( no accum ulat ion of
unused t oken credit s is necessary) , but only unt il t he PI R is reached.

Exam ple 4- 3 shows t he configurat ion t o police t raffic on class- default t o a CI R of 8000 bps, a Bc
of 1000 byt es, a Be of 2000 byt es, and a PI R of 10000 bps. Not e t hat , for t his policer, CI R and
PI R are defined in bit s per second, but Bc and Be are defined in byt es.

Ex a m ple 4 - 3 . Tw o- Ra t e Th r e e - Color Police r Ex a m ple

Router# sh run
policy-map RFC2698-POLICER
class class-default
police cir 8000 bc 1000 pir 10000 be 2000
conform-action set-dscp-transmit af31
exceed-action set-dscp-transmit af32
violate-action set-dscp-transmit af32

Hierarchical Policing

I t is advant ageous t o police som e applicat ions at m ult iple levels. For exam ple, it m ight be
desirable t o lim it all TCP t raffic t o 10 Mbps, while at t he sam e t im e lim it ing FTP t raffic ( which is a
subset of TCP t raffic) t o no m ore t han 1.5 Mbps. To achieve t his nest ed policing requirem ent ,
hierarchical policing can be used. Two- level hierarchical policing was int roduced in Cisco I OS
Soft ware Release 12.1( 5) T. Lat er, in Release 12.2.1( 3) T, t hree- level hierarchical policing was
int roduced for t he 7200 and 7500 plat form s.

The policer at t he second level in t he hierarchy act s on packet s t ransm it t ed or m arked by t he

policer at t he first level. Therefore, t he second level does not see any packet s t hat t he first level
drops. The sum of packet s t hat t he lower- level policers see is equal t o t he sum of packet s t hat
t he higher- level policer t ransm it s or m arks. This feat ure support s up t o t hree nest ed levels.

Exam ple 4- 4 shows t he configurat ion for t he nest ed, t wo- level, hierarchical policing of TCP and
FTP t raffic.

Ex a m ple 4 - 4 . N e st e d, H ie r a r ch ica l Policin g Ex a m ple

Router# sh run
policy-map FTP-POLICER
class FTP
police cir 1500000
conform-action transmit
exceed-action drop
!
policy-map TCP-POLICER
class TCP
police cir 10000000
conform-action transmit
exceed-action drop
service-policy FTP-POLICER
Multiaction Policing

At t im es, packet s need t o be m arked at bot h Layer 2 and Layer 3. To accom m odat e such a
requirem ent , a m ult iact ion policer was int roduced in Cisco I OS Soft ware Release 12.2( 8) T. The
com m ands in Exam ple 4- 5 illust rat e t he configurat ion.

Ex a m ple 4 - 5 . M u lt ia ct ion Police r CLI

Router(config)# policy-map MULTIACTION-POLICER

Router(config-pmap)# class class-default
(config-pmap-c)#police cir [bc] [be] ?
conform-action action1
conform-action action2
conform-action action3
conform-action action4

exceed-action action1
exceed-action action2
exceed-action action3
exceed-action action4

violate-action action1
violate-action action2

For each t ype of t raffic, such as t he conform ing t raffic, m ult iple act ions can be specified. The
sam e is t rue for t he exceeding t raffic and t he violat ing t raffic. Exam ple 4- 6 illust rat es how t o
m ark exceeding t raffic wit h bot h I P Precedence 4 ( at Layer 3) and t he Fram e Relay DE bit ( at
Layer 2) .

Ex a m ple 4 - 6 . M u lt ia ct ion Police r Ex a m ple

Router# sh run
policy-map MULTIACTION-POLICER
class class-default
police cir 10000 pir 2000000
conform-action transmit
exceed-action set-prec-transmit 4
exceed-action set-frde
violate-action set-prec-transmit 2
violate-action set-frde-transmit

Exam ple 4- 7 shows how a packet can be m arked wit h DSCP AF31 ( at Layer 3) and MPLS 3 ( at
Layer 2) at t he sam e t im e.
Ex a m ple 4 - 7 . M u lt ia ct ion Police r Ex a m ple

Router# sh run
policy-map MULTIACTION-POLICER2
class class-default
police cir 10000
conform-action set-dscp-transmit af31
conform-action set-mpls-exp-topmost-transmit 3

Color-Aware Policing

RFC 2697 and RFC 2698 describe t hree- color policers, m eaning t hat t he packet s can be colored
t o t hree separat e values t o indicat e whet her t hey conform t o, exceed, or violat e t he policing
condit ions. The single- rat e t hree- color m arker and t he t wo- rat e t hree- color m arker init ially were
im plem ent ed ( in Cisco I OS Soft ware Releases 12.2[ 2] T and 12.2[ 4] T, respect ively) t o operat e in
color- blind m ode. This m eans t hat t he policer assum es t hat t he packet st ream previously was
uncolored. The RFCs also define a color- aware m ode, which m eans t hat t he policer assum es t hat
som e preceding ent it y already has colored t he packet st ream . At t he t im e of t his writ ing, t he
color- aware m ode is available only in Cisco I OS Soft ware Release 12.0.26S; it is not yet
available in any 12.2T release.

Table 4- 2 shows t he t wo- rat e policer decisions for color- blind versus color- aware m odes. The
num ber of byt es in t he packet under considerat ion is indicat ed by pkt - lengt h.

Ta ble 4 - 2 . Color - Blin d Ve r su s Color - Aw a r e Policin g M ode s for t h e Tw o-

Ra t e Police r

Color Blin d Color Aw a r e

I f ( pkt - lengt h > PI R + PBS) , m ark t he packet I f t he packet already is m arked as violat ing
as violat ing. OR
( pkt - lengt h > PI R + PBS) ,
m ark t he packet as violat ing.

I f ( pkt - lengt h < PI R + PBS) AND ( pkt - lengt h >
CI R + CBS) , m ark t he packet as exceeding.
Ot herwise, m ark t he packet as conform ing.
I f t he packet already is m arked as exceeding
OR
( ( pkt - lengt h < PI R + PBS) AND ( pkt - lengt h >
CI R + CBS) ) ,
m ark t he packet as exceeding.
Ot herwise, m ark t he packet as conform ing.

Percentage-Based Policing

Most net works cont ain a wide array of int erfaces wit h different bandwidt hs. I f absolut e
bandwidt h rat es are used in policing policies, t he policy m ust be re- ent ered for each different
int erface size. This reduces policy m odularit y and m akes policy m anagem ent m ore cum bersom e
across t he ent erprise. I t oft en is desirable t o have an overall net work policy in which, for
exam ple, FTP t raffic is not t o exceed 10 percent of t he bandwidt h on any int erfaceregardless of
absolut e speed. This can be achieved using percent ages in t he policing st at em ent s. Thus, a
single policy can be reused across m any int erfaces in t he net work.

The com m and for t his is as follows:

police cir percent xx

police cir percent xx pir percent xx

Only t he CI R and PI R values can be specified wit h percent , not t he burst sizes; t he burst sizes
are configured in unit s of m illiseconds. I f t he CI R is configured in percent , t he PI R also m ust be.
When t he service- policy is at t ached t o an int erface, t he CI R ( and PI R, if configured) is
det erm ined as a percent age of t he int erface bandwidt h. I f t he int erface bandwidt h is changed,
t he CI R and PI R values and burst sizes aut om at ically are recalculat ed using t he new int erface
bandwidt h value. For subint erfaces, t he bandwidt h of t he m ain int erface is used for t he
calculat ion. For ATM, t he VC bandwidt h is used; for Fram e Relay, t he CI R value of t he PVC is
used.

I f t he percent feat ure is used in a second- or t hird- level policy, t he bandwidt h of t he lower- level
policy st at em ent is det erm ined by t he configurat ion of t he higher or parent level. Table 4- 3
sum m arizes t his decision process.

Ta ble 4 - 3 . CI R/ PI R Policin g Be h a vior Ba se d on Pe r ce n t a ge s

Con figu r a t ion D e cision

CI R and PI R
configured
I f t he conform act ion is drop, t he bandwidt h is 0. ( This is m ost likely
not a pract ically useful configurat ion, but it is nevert heless t he result
of t he police st at em ent if t his should be configured.)

I f t he exceed act ion is drop, t he CI R specificat ion is used as t he

bandwidt h.

I f t he violat e act ion is drop, t he PI R specificat ion is used as t he

bandwidt h.

CI R configured

I f t he conform act ion is drop, t he bandwidt h is 0. ( This is m ost likely

not a pract ically useful configurat ion, but it is nevert heless t he result
of t he police st at em ent if t his should be configured.)

I f t he exceed act ion is drop, t he CI R specificat ion is used as t he

bandwidt h.

I f t he violat e act ion is drop, t he CI R specificat ion is used as t he

bandwidt h.
 Con figu r a t ion D e cision
Neit her CI R nor
PI R configured
I f t his is a second- or t hird- level policy, t he rat e is det erm ined by t he
parent class.

I f t his is a first level policy, t he int erface of t he PVC bandwidt h is

used.

Defaults

The burst param et ers and act ions of t he policer are opt ional. The default conform act ion is t o
t ransm it t he packet , and t he default exceed act ion is t o drop t he packet . The default violat e
opt ion is t he sam e as t he exceed act ion. The default burst values are 250 m s of t he specified
t raffic rat e.
Shapers
Sim ilar t o policers, shapers m et er t he t ransm ission rat e of packet s t hrough a net work. However,
unlike policers, shapers delay ( inst ead of drop or re- m ark) packet s t hat exceed t he CI R. Such
delaying sm oot hes out burst s in t raffic flows and allows for conform ance t o SLAs, as shown in
Figure 4- 7 .

Figu r e 4 - 7 . Ge n e r ic Tr a ffic Sh a pin g Effe ct on Tr a ffic Flow

Shaping is crucial on nonbroadcast m ult iaccess ( NBMA) t opologies, such as ATM and Fram e
Relay, in which pot ent ial speed m ism at ches exist .

I n Figure 4- 8 , a t raffic shaper is used in t he following sit uat ions:

A lin e spe e d m ism a t ch I n t his case, t he cent ral sit e has a T1 link, but t he rem ot e sit e has
only a 64- kbps link. Wit hout t raffic shaping, fram es and cells could accum ulat e and drop in
t he carrier's cloud.

Re m ot e t o ce n t r a l sit e a ggr e ga t e ove r su bscr ipt ion I n t his case, if bot h rem ot e sit es
begin t ransm it t ing at t he sam e t im e, m ult iple rem ot e sit es ( each wit h T1 links) begin
sending at line rat es back t o a cent ral sit e ( which has only a single T1 link) , t hereby
oversubscribing t he cent ral T1 and again causing drops wit hin t he carrier's cloud.

SLA e n for ce m e n t The ent erprise has cont ract ed for a 64- kbps CI R from it s carrier, and
t he carrier offers no service guarant ees for t raffic exceeding t his rat e. Service guarant ees
are crit ical when planning I P t elephony or I P videoconferencing deploym ent s.

Figu r e 4 - 8 . N BM A Sce n a r ios Re qu ir in g Tr a ffic Sh a pin g

Because shaping involves buffering, various scheduling t echniques can be used when t he
shaping buffer st art s filling. These scheduling t echniques are discussed in m ore det ail in Chapt er
5 , " Congest ion- Managem ent Tools."

Shaping Algorithms
Sim ilar t o policers, shapers use t oken bucket algorit hm s. By default , som e shapers set t he Bc t o
equal CI R/ 8, which yields an int erval ( Tc) of 125 m s. Alt hough t his int erval value m ight be
adequat e for dat a applicat ions, it int roduces unnecessary int erpacket delays for real- t im e
net works. Consider t he exam ple shown in Figure 4- 9 .

Figu r e 4 - 9 . Sh a pin g Be h a vior w it h D e fa u lt Bc Va lu e s

[View full size image]

A shaper uses t he CI R, Bc, and Be t o sm oot h a t raffic st ream t o a specified rat e. I t achieves t he
given CI R by dividing t he line speed of t he int erface int o equal- lengt h t im e slot s ( int ervals, or
Tc) . Then it sends a sm aller port ion ( Bc) of t he t raffic during each t im e slot .

The t im e slot size is governed by t he Bc param et er ( Tc = Bc/ CI R) . I n Figure 4- 9 , a line rat e of

128 kbps is shaped t o 64 kbps. For Fram e Relay t raffic shaping, t he Bc, by default , is one eight h
of t he CI R ( or 8 kbps) . Each second is divided int o eight t im e slot s of 125 m s each, and t he
shaped rat e of 64,000 bps is divided int o eight burst s of 8000 bps each ( Bc) . Each burst t akes
62.5 m s t o t ransm it ( at a 128- kbps line rat e) , so t he shaper t ransm it s inform at ion for t he first
62.5 m s of each 125- m s t im e slot and is silent for t he rem aining 62.5 m s of t he t im e slot . Over
t he span of a second, t his achieves t he average rat e of CI R.

The Be value is used t o det erm ine t he peak rat e of sending and is calculat ed as follows:

Peak Rat e = CI R ( 1+ Be / Bc)

Peak- rat e shaping allows t he rout er t o burst higher t han average- rat e shaping. However, when
peak- rat e shaping is enabled, any t raffic t hat exceeds t he CI R could be dropped if t he net work
becom es congest ed.

The design goal for one- way lat ency across a real- t im e net work is 150 m s ( per t he G.114
specificat ion for voice end- t o- end delay) , and t he j it t er t arget is less t han 10 m s per hop.
I nt roducing up t o 125 m s of shaping delays at a single hop dest roys VoI P qualit y. Therefore, it is
recom m ended t hat shaped int erfaces carrying real- t im e t raffic be shaped t o 10- m s int ervals
( Tc) . Because t he Tc cannot be adm inist ered direct ly by Cisco I OS com m ands, Bc t uning is
required t o affect Tc indirect ly. This int erval value can be achieved ( rem em ber, Tc = Bc / CI R)
by set t ing t he Bc equal t o CI R/ 100, which result s in a Tc value of 10 m s. The recom m ended
value for Bc on an 64- kbps int erface/ PVC carrying real- t im e t raffic is, t herefore, 64,000 / 100,
which equals 640 bit s and represent s 10 m s of t ransm ission on a 64- kbps line.

Shaping on ATM and Frame Relay Networks

ATM and Fram e Relay are NBMA t opologies t hat have inherent and specific requirem ent s for
t raffic shaping. Therefore, t hese t opologies have cust om ized shaping t ools t hat are not available
t o ot her t opologies. These cust om - shaping t ools include ATM t raffic cont ract s and Fram e Relay
t raffic shaping.

ATM Traffic Contracts

I n ATM, shaping is an int egral part of t he PVC specificat ion. This is because ATM achieves
different QoS levels by configuring different PVC t raffic cont ract s, such as real- t im e variable bit
rat e ( VBR- RT) , non- realt im e variable bit rat e ( VBR- NRT) , available bit rat e ( ABR) , and
unspecified bit rat e ( UBR) . The ATM t raffic cont ract shaping com m ands are sum m arized in Table
4- 4 .

Rout er( config- if- at m - vc) # a br out put - pcr out put - m cr

Configures t he ABR

Rout er( config- if- at m - vc) # u br out put - pcr

Configures t he UBR

Rout er( config- if- at m - vc) # u br + out put - pcr out put - m cr

Configures t he UBR wit h a m inim um guarant eed rat e

Rout er( config- if- at m - vc) # vbr - n r t out put - pcr out put - scr out put - m bs

Configures t he non- realt im e VBR

Rout er( config- if- at m - vc) # vbr - r t peak- rat e average- rat e burst

Configures t he real- t im e VBR

Ta ble 4 - 4 . ATM Tr a ffic Con t r a ct PVC Pa r a m e t e r

Con figu r a t ion Com m a n ds

Com m a n d Pu r pose

The - pcr and - m cr argum ent s are t he peak cell rat e and m inim um cell rat e, respect ively. The -
scr and - m bs argum ent s are t he sust ainable cell rat e and m axim um burst size, respect ively.

The param et ers specified on t he ATM PVC configurat ion det erm ine t he shaped average or peak
rat es, as well as t he burst param et ers, as shown in Exam ple 4- 8 .

Ex a m ple 4 - 8 . ATM PVC Con figu r a t ion

Router# sh run
interface ATM3/0.1 point-to-point
description OC3 Link to Site-B
ip address 10.2.12.1 255.255.255.252
pvc 0/12
vbr-nrt 149760 149760
General Cisco I OS shaping t ools, such as generic t raffic shaping and class- based shaping, are
not support ed on ATM int erfaces, including digit al subscriber line ( DSL) .

Frame Relay Traffic Shaping

Traffic shaping is im perat ive for Fram e Relay PVCs if QoS guarant ees are required over t hem .
The init ial shaping m echanism developed for Fram e Relay int erfaces was Fram e Relay t raffic
shaping ( FRTS) . Exam ple 4- 9 shows a sam ple configurat ion of FRTS.

Ex a m ple 4 - 9 . Fr a m e Re la y Tr a ffic Sh a pin g

Router# sh run
interface Serial0/1
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial0/1.50 point-to-point
description FR Link to BRANCH#50
bandwidth 1536
ip address 10.200.50.1 255.255.255.252
frame-relay interface-dlci 150
class FRTS-1536
!
map-class frame-relay FRTS-1536
frame-relay cir 1536000
frame-relay bc 15360
frame-relay be 0
frame-relay mincir 1536000
no frame-relay adaptive-shaping

I n line wit h t he previously discussed shaping recom m endat ions, t he Bc is set t o CI R/ 100. The Be
is set t o 0 t o prevent any excess burst ing. The problem wit h provisioning t he Be in real- t im e
net works is t hat it can creat e buffering delays wit hin a Fram e Relay net work ( because t he
receiving side can " pull" t he t raffic from a circuit only at t he rat e of Bc, not Bc + Be) . To rem ove
t he pot ent ial for buffering delays, t he recom m endat ion is t o set t he Be t o 0.

Fram e Relay also has t he capabilit y t o adapt t o explicit congest ion not ices, eit her in t he forward
direct ion t hrough forward explicit congest ion not ificat ions ( FECNs) or in t he reverse direct ion
t hrough backward explicit congest ion not ificat ions ( BECNs) . Adapt ive t raffic shaping even can be
t riggered by ot her not ificat ions, such as foresight or int erface congest ion ( as of Cisco I OS
Soft ware Release 12.2[ 4] T) . When adapt ive shaping is enabled and congest ion not ificat ions have
been received, t he FRTS engine rat es down t he flow t o t he m inim um CI R ( m inCI R) , which, by
default , is CI R/ 2. Because such congest ion adapt at ion int roduces variat ions in t ransm ission rat es
and, t hus, service levels, t he recom m endat ion is t o disable adapt ive shaping in net works
carrying real- t im e t raffic.

Class-Based Frame Relay Traffic Shaping

I n Cisco I OS Soft ware Release 12.2( 13) T, FRTS funct ionalit y was m igrat ed int o t he MQC synt ax
using class- based shaping com m ands. This is t he current ly recom m ended m et hod for configuring
t raffic shaping on Fram e Relay dat a- link connect ion ident ifiers ( DLCI s) . Translat ing Exam ple 4- 9
int o t he class- based FRTS synt ax yields t he result s shown in Exam ple 4- 10 .

Ex a m ple 4 - 1 0 . Fr a m e Re la y Tr a ffic Sh a pin g Usin g Cla ss- Ba se d Syn t a x

Router# sh run
policy-map CB-FRTS-1536
class class-default
shape average 1536000 15360 0
!
...
!
interface Serial0/1
no ip address
encapsulation frame-relay
!
interface Serial0/1.50 point-to-point
description FR Link to BRANCH#50
bandwidth 1536
ip address 10.200.50.1 255.255.255.252
frame-relay interface-dlci 150
class FRTS-1536
!
...
!
map-class frame-relay FRTS-1536
service-policy output CB-FRTS-1536

The class- based FRTS configurat ion ret ains rem nant s of FRTS, such as t he need t o associat e t he
DLCI t o a Fram e Relay m ap class and t hen at t ach t he class- based FRTS policy t o t his m ap class.

Frame Relay Voice-Adaptive Traffic Shaping

Support ing voice t raffic wit h predict able QoS on a Fram e Relay PVC requires t raffic shaping t o be
deployed on t he PVC and shaped st rict ly t o t he CI R. This is because any t raffic in excess of t he
CI R could be m arked as Fram e Relay DE- bit 1 and could be dropped by t he Fram e Relay
backbone net work during congest ion ( because it violat es t he SLA) . Many cust om er edge
net works, however, are designed and configured t o oversubscribe t he CI R because t he backbone
net work seldom exhibit s congest ion and, if it does, t he higher- layer prot ocols t ake care of
recovering t he session. Voice t raffic cannot be t reat ed in t he sam e m anner because t he QoS for
voice needs t o be predict able and guarant eed.

The Fram e Relay backbone net work does not know which fram es cont ain voice and which
cont ain dat a. Therefore, if any t raffic violat es t he CI R, t he backbone swit ch does not know how
t o drop only dat a and not t o drop voiceeven if t he voice t raffic by it self is below t he cont ract ed
SLA rat e. This necessit at es shaping st rict ly t o t he CI R t o ensure t hat voice t raffic is prot ect ed.
Adapt ive shaping ( t hrough BECNs, FECNs, and ot her not ificat ion m echanism s) cannot resolve
t his problem because by t he t im e t he shaper receives t he congest ion not ices and react s t o t hem ,
m any voice packet s m ight already have been delayed or dropped. Therefore, t o address t he
needs of voice t raffic in a Fram e Relay net work, t he Fram e Relay voice- adapt ive t raffic shaping
( FR- VATS) feat ure was int roduced in Cisco I OS Soft ware Release 12.2( 15) T.
FR- VATS m onit ors t he Fram e Relay PVC. When voice act ivit y is present , it aut om at ically shapes
t o t he CI R ( which, in t his specific case, is configured as t he m inCI R) . However, if no voice is
present , it allows t he t raffic t o burst t o t he line rat e ( which, in t his specific case, is configured as
t he CI R) . This unique feat ure det erm ines t he presence of voice based on packet s ent ering a
priorit y class or low- lat ency queue ( a scheduling feat ure t hat is discussed in Chapt er 5 ) . I t t hen
aut om at ically det erm ines whet her t o shape t he t raffic t o m inCI R ( voice present ) or not ( no voice
present ) . Sim ilarly, FR- VATS aut om at ically engages Fram e Relay fragm ent at ion ( FRF.12) on
links less t han 768 kbps when voice packet s are present , t o prevent unnecessary serializat ion
delays. ( FRF.12 is discussed in m ore det ail in Chapt er 7 , " Link- Specific Tools." )

Because FR- VATS aut om at ically det ect s t he presence of voice, t here could be som e brief qualit y
degradat ion in t he first couple of seconds of t he first voice call m ade across a PVC. This occurs
while t he int erfaces com prising t he PVC reconfigure t hem selves t o shape t o t he m inCI R and
em pt y out t heir buffers. FR- VATS is not a predict ive algorit hm . The change in behavior is
t riggered by voice packet s flowing across t he PVC.

The FR- VATS deact ivat ion period is t unable and, by default , is set t o 30 seconds. I f t uned, t his
t im er should be set so t hat t he feat ure will not t urn off frequent ly during norm al business use
( for exam ple, bet ween every t wo calls) . The feat ure works bet t er on PVCs t hat always have at
least one voice call present during dayt im e use and relinquish shaping only at night .

Exam ple 4- 11 shows a configurat ion of FR- VATS.

Ex a m ple 4 - 1 1 . FR- VATS Con figu r a t ion

Router# sh run
policy-map FR-VATS-768
class class-default
shape average 768600 3648 0 sets CIR to 768 kbps and Bc to minCIR/100
shape adaptive 364800 sets the minCIR to 364.8kbps
shape fr-voice-adapt deactivation 30 enables default FR VATS deactivation timer
!
...
!
interface Serial0/1
no ip address
encapsulation frame-relay
serial restart_delay 0
frame-relay fragmentation voice-adaptive deactivation 30 enables FR Voice
Adaptive Fragmentation (sub-component of FR VATS)
!
interface Serial0/1.50 point-to-point
description FR Link to BRANCH#50
bandwidth 768
ip address 10.200.50.1 255.255.255.252
frame-relay interface-dlci 150
class FRTS-768 applies the FR map-class to the DLCI
!
...
!
map-class frame-relay FRTS-768
service-policy output FR-VATS-768
frame-relay fragment 480 sets fragment size for 384 kbps (minCIR) link
!
Generic Traffic Shaping
Generic t raffic shaping ( GTS) is t he oldest shaping t ool in t he Cisco I OS Soft ware and is included
in t his chapt er for hist orical reasons only. I t was int roduced in Cisco I OS Soft ware Release 11.2
and is enabled using t he t r a ffic- sh a pe r a t e com m and. This feat ure is not recom m ended for use
in QoS deploym ent s because it lacks m any of t he RFC- com pliant feat ures cont ained in t he class-
based shaping t ools discussed in t his chapt er. I nst ead, class- based shaping should be used
wherever possible. I n older I OS releases for Fram e Relay int erfaces, FRTS should be used.

Class-Based Shaping
Class- based shaping ( available wit hin t he MQC synt ax) uses class m aps and policy m aps. A class
m ap ident ifies t he t raffic t o be shaped ( or t he shaper can be applied t o class- default t o shape
everyt hing) . The policy m ap t hen det ails t he CI R, Bc, Be, and ot her shaping param et ers.

Class- based shaping was int roduced in Cisco I OS Soft ware Release 12.1( 2) T. Concept ually, it
was a m igrat ion of GTS int o t he MQC synt ax. However, t he class- based shaping code is different
from GTS. This feat ure should not be assum ed t o behave in exact ly t he sam e m anner as GTS.

The com m and t o configure class- based shaping follows:

shape [average | peak] [cir] [burst_size [excess_burst_size]]

Exam ple 4- 12 uses class- based shaping on a T1 int erface t o shape t o 768- kbps CI R wit h t he Bc
set t o t he recom m ended value for real- t im e net works ( CI R/ 100 and Be set t o 0) .

Ex a m ple 4 - 1 2 . Cla ss- Ba se d Sh a pin g on a T1 I n t e r fa ce

Router# sh run
policy-map CBS-768
class class-default
shape average 768000 7680 0

Hierarchical Class-Based Shaping

As wit h hierarchical policing, som et im es shaping policies need t o shape aggregat e levels and
provide addit ional QoS funct ions on sublevels of t raffic. Hierarchical shaping was int roduced in
Cisco I OS Soft ware Release 12.1( 2) T.

For exam ple, consider t he case of a service provider t hat want s t o shape a cust om er's aggregat e
t raffic t o 384,000 and, wit hin t hat , want s t o provide a bandwidt h guarant ee of 200 kbps for
t ransact ional dat a and a bandwidt h guarant ee of 100 kbps for bulk dat a. This can be achieved
wit h a nest ed, or hierarchical, shaping policy, as shown in Exam ple 4- 13 .

Ex a m ple 4 - 1 3 . H ie r a r ch ica l Cla ss- Ba se d Sh a pin g

 Router# sh run
policy-map CUSTOMER1-SHAPING-AND-QUEUING-POLICY parent policy
class CUSTOMER1-TRAFFIC
shape average 384000
service-policy CUSTOMER1-QUEUING-POLICIES includes the child policy
!
policy-map CUSTOMER1-QUEUING-POLICIES child policy
class CUSTOMER1-TRANSACTIONAL-DATA
bandwidth 200
class CUSTOMER1-BULK-DATA
bandwidth 100
!

Percentage-Based Shaping

As wit h policing, shaping can be st at ed as a percent age of bandwidt h inst ead of absolut e
bandwidt h. This feat ure enhancem ent was int roduced in Cisco I OS Soft ware Release 12.2( 13) T
and is enabled wit h t he following com m and:

shape [average | peak] percent xx

Burst sizes cannot be configured using percent ages, but t hey can be specified in t erm s of
m illiseconds on t he com m and. When a percent age configurat ion is used for average or peak
shaping rat es, t he default burst sizes aut om at ically are assigned and can be seen using t he
sh ow policy in t e r fa ce com m and, as shown in Exam ple 4- 14 . When t he service policy is
at t ached t o an int erface, t he CI R value is det erm ined from t he int erface bandwidt h in
conj unct ion wit h t he configured CI R percent value.

Ex a m ple 4 - 1 4 . Pe r ce n t - Ba se d Sh a pin g

Router#show policy-map interface fastEthernet 0/1 output

FastEthernet0/1
Service-policy output: ex-shape
Class-map: example (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 101
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
80 (%) 0 (ms) 0 (ms)
80000000/80000000 500000 2000000 2000000 25 250000
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 0 0 0 0 no
Class-map: class-default (match-any)
15 packets, 1225 bytes
 5 minute offered rate 0 bps, drop rate 0 bps
Match: any

Distributed Traffic Shaping

On dist ribut ed plat form s, such as t he Cisco 7500 VI P, class- based shaping is not support ed.
I nst ead, a count erpart feat ure, dist ribut ed t raffic shaping ( DTS) , is used.

Alt hough DTS on t he Cisco 7500 is very sim ilar t o class- based shaping on nondist ribut ed
plat form s, t here are t wo m ain differences t o keep in m ind. The first is t hat , wit h DTS, t he CI R
m ust be defined in m ult iples of 8000. The second is t hat t he Cisco 7500 VI P requires t he int erval
( Tc) t o be defined in increm ent s of 4 m s. Because t he t arget int erval for all plat form s is 10 m s,
which is not evenly divisible by 4 m s, t he recom m endat ion for Cisco 7500 VI P is t o use an
int erval of 8 m s. The int erval can be set t o 8 m s by defining t he burst using t he following
form ula:

Bc = CI R / 125

Det ailed exam ples of DTS in WAN environm ent s are provided in Chapt er 13 , " WAN Aggregat or
QoS Design." The behavior of t raffic shaping for t he 7500 plat form s current ly is being reworked,
but t he previous funct ionalit y exist s in Cisco I OS Soft ware releases up t o 12.3 m ainline and
12.3T.
Further Reading
DiffServ Policing Standards

RFC 2697, " A Single Rat e Three Color Marker" : ht t p: / / www.iet f.org/ rfc/ rfc2697 .

RFC 2698, " A Two Rat e Three Color Marker" : ht t p: / / www.iet f.org/ rfc/ rfc2698 .

Policing

Traffic policing ( 12.1.5T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt poli.ht m

Traffic policing enhancem ent s ( 12.2.2T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ ft poli.ht m

Two- rat e policer ( 12.2.4T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 4/ ft 2rt plc.ht m

Policer enhancem ent m ult iple act ions ( 12.2.8T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ ft polenh.ht m

Percent age- based policing and shaping ( 12.2.13T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft pct pol.ht m

Color- aware policer ( 12.0.26S) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120lim it / 120s/ 120s26/ 12
.

ATM PVC Traffic Parameters

Configuring ATM t raffic param et ers:

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fwan_c/ wcfat m .ht m # 1001
.

Frame Relay Traffic Shaping

Adapt ive Fram e Relay t raffic shaping for int erface congest ion ( 12.2.4T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 4/ ft _afrt s.ht m

MQC- based Fram e Relay t raffic shaping ( 12.2.13T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ frqosm qc.ht
.
 Percent age- based policing and shaping ( 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft pct pol.ht m

Fram e Relay queuing and fragm ent at ion at t he int erface ( 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ frfrint q.ht m

Fram e Relay voice- adapt ive t raffic shaping and fragm ent at ion ( 12.2.15T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 15/ ft _vat s.ht m

Traffic Shaping

Generic t raffic shaping ( 11.2) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios112/ 112cg_cr/ 1rbook/ 1rsysm gt .ht m # 23
.

Class- based shaping ( 12.1.2T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 2/ clsbsshp.ht m

Dist ribut ed t raffic shaping ( 12.1.5T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt dt s.ht m
Chapter 5. Congestion-Management
Tools
This chapt er includes t he following t opics:

Scheduling and queuing

Legacy Layer 3 m echanism s

Current ly recom m ended Layer 3 m echanism s

Layer 2 queuing t ools

Tx- ring

PAK_priorit y

Of all t he m echanism s wit hin t he QoS t oolset , congest ion- m anagem ent t ools provide t he m ost
significant im pact on applicat ion service levels. Congest ion- m anagem ent t ools, also known as
queuing t ools, apply t o int erfaces t hat m ay experience congest ion. This could be t he case in
eit her a WAN or a LAN environm ent ( alt hough LAN queuing t ools are discussed in Chapt er 10,
" Cat alyst QoS Tools" ) because speed m ism at ches can occur in eit her set t ing. Whenever packet s
ent er a device fast er t han t hey can exit it , t he pot ent ial for congest ion exist s and queuing t ools
apply.

I t is im port ant t o recognize t hat queuing t ools are act ivat ed only when congest ion exist s on an
int erface. When no congest ion exist s on an int erface, packet s are sent out over t he int erface as
soon as t hey arrive. However, when congest ion occurs, packet s m ust be buffered, or queued, t o
m it igat e dropping.

Packet m arkings at eit her Layer 2 or Layer 3, or t he absence of a m arking on a packet , influence
queuing policies so t hat t he rout er can reorder packet s before t ransm ission. Therefore, queuing
policies are usually com plem ent ary and depend on classificat ion and m arking policies wit hin
converged net works.

This chapt er exam ines t he difference bet ween scheduling and queuing, and t he different OSI
layers where queuing m ight occur. Legacy Layer 3 queuing algorit hm s are reviewed t o provide
cont ext for t he m ore recent queuing algorit hm s, such as Class- Based Weight ed Fair Queuing
( CBWFQ) and Low- Lat ency Queuing ( LLQ) , t hat evolved from t hem . LLQ and CBWFQ are
exam ined in det ail because t hese are t he principal recom m ended queuing m echanism s for
converged net works in which different t raffic t ypes such as voice, video, and dat a all share t he
sam e t ransm ission m edia.

Lower- level queuing algorit hm s, such as Layer 2 m echanism s and t he Tx- ring, also are discussed
because t hese t ools have an im pact on successful end- t o- end QoS design. Finally, t he int ernal
Cisco I OS m echanism for prot ect ing rout ing and cont rol packet s ( PAK_priorit y) wit hin t he rout er
is int roduced.
Understanding Scheduling and Queuing
The phrase scheduling t ools refers t o t he set of feat ures t hat det erm ines how a fram e, cell, or
packet exit s a device. Whenever packet s ent er a device fast er t han t hey can exit it , as is t he
case wit h int erface speed m ism at ches ( for exam ple, Fast Et hernet t raffic heading t o a serial WAN
int erface) , a point of pot ent ial congest ion, or a bot t leneck, occurs. Devices have buffers t hat
allow for t em porarily st oring and subsequent scheduling of t hese backed- up packet s. This
process com m only is referred t o as queuing. As t hese buffers ( or queues) fill, packet s can be
reordered so t hat higher- priorit y packet s exit t he device sooner t han lower- priorit y ones. Figure
5 - 1 shows a general exam ple of queuing.

Figu r e 5 - 1 . Ge n e r ic Qu e u in g Ex a m ple

Concept ually, queuing and scheduling are com plem ent ary but int ert wined processes. These
t erm s quit e oft en are incorrect ly used int erchangeably:

Queuing is t he logic of ordering packet s in linked out put buffers. I t is im port ant t o
recognize t hat queuing processes are engaged only when t he int erface is experiencing
congest ion and are deact ivat ed short ly aft er t he int erface congest ion clears.

Scheduling is t he process of deciding which packet t o t ransm it next . Scheduling occurs

when t he int erface is experiencing congest ion, but also ( unlike queuing) when t he int erface
is not experiencing congest ion ( t hat is, t here is st ill a decision, albeit a sim ple one, of which
packet should be t ransm it t ed next , even if t here is no congest ion on t he int erface) . I f t here
is no congest ion on t he int erface, packet s are t ransm it t ed as t hey arrive. I f t he int erface is
experiencing congest ion, queuing algorit hm s are engaged. However, t he scheduler st ill has
t o decide which queue t o service next . This decision is m ade using various t ypes of
scheduling logic algorit hm s:

- St r ict pr ior it y The lower- priorit y queues are served only if t he higher- priorit y
queues are com plet ely em pt y. This t ype of scheduling exhibit s t he pot ent ial t o st arve
t raffic in lower- priorit y queues.

- Rou n d- r obin Queues are served in a sequence. Alt hough t hey never st arve t raffic,
 round- robin schedulers exhibit t he pot ent ial t o cause unpredict able delay in queues
t hat hold real- t im e, delay- sensit ive t raffic t hat requires a m ore st rict priorit y-
scheduling algorit hm .

- W e igh t e d fa ir Packet s in t he queues are weight ed, t ypically by I P precedence, so

t hat som e queues are served m ore frequent ly t han ot hers. Alt hough t his solves t he
downsides of bot h t he st rict priorit y and round- robin algorit hm s, it does not provide
t he bandwidt h guarant ee t hat real- t im e flows require. The result ing bandwidt h per
flow inst ant aneously varies based on t he num ber of flows present and t he weight s of
each of t he ot her flows.

The buffer space ( or m em ory) for queues is finit e in capacit y and act s very m uch like a funnel
for wat er t hat is being poured int o a sm all opening. I f wat er cont inually is ent ering t he funnel
m uch fast er t han it exit s, event ually t he funnel begins t o overflow from t he t op. When queuing
buffers begin overflowing, packet s m ight be dropped eit her as t hey arrive ( t ail drop) or
select ively, before all buffers are filled. Select ive dropping of packet s when t he queues are filling
is referred t o as congest ion avoidance. Congest ion- avoidance m echanism s work best wit h TCP-
based applicat ions because select ive dropping of packet s causes t he TCP windowing m echanism s
t o t hrot t le back and adj ust t he rat e of flows t o m anageable rat es.

Congest ion- avoidance m echanism s are com plem ent ary t o queuing algorit hm s and are discussed
in m ore det ail in Chapt er 6, " Congest ion- Avoidance Tools." The relat ionship bet ween congest ion-
m anagem ent t ools ( or scheduling algorit hm s) and congest ion- avoidance t ools ( or select ive-
dropping algorit hm s) is as follows: Wit h congest ion m anagem ent , t he scheduling algorit hm s
m anage t he front of a queue; wit h congest ion avoidance, t he m echanism s m anage t he t ail of a
queue.

Congest ion- m anagem ent and congest ion- avoidance t ools em ployed in converged net works
include t hese:

Low - La t e n cy Qu e u in g ( LLQ) Congest ion m anagem ent

Cla ss- Ba se d W e igh t e d Fa ir Qu e u in g ( CBW FQ) Congest ion m anagem ent

W e igh t e d Ra n dom Ea r ly D e t e ct ion ( W RED ) Congest ion avoidance

LLQ and CBWFQ are discussed in det ail in t his chapt er. WRED is covered in Chapt er 6.

To underst and queuing, you first m ust underst and t he various levels of queuing and how
queuing has evolved. A fundam ent al concept in Cisco I OS queuing is t hat queuing is perform ed
at m ult iple layers of t he OSI m odel.

Layer 3 queuing subsyst em s operat e at t he net work layer and are applied t o Layer 3 packet s at
a logical level. Because Cisco I OS Layer 3 queuing subsyst em s are independent of t he egress
int erface t ype, t hey can be applied t o Asynchronous Transfer Mode ( ATM) , Fram e Relay, High-
Level Dat a Link Cont rol ( HDLC) , Point - t o- Point Prot ocol ( PPP) , Mult ilink Point - t o- Point Prot ocol
( MLP) , or t unnel int erfaces. I t is im port ant t o recognize t hat Layer 3 queuing t ypically considers
only t he I P overhead in it s bandwidt h provisioning. Layer 2 overhead such as t he ATM cell t ax is
not fact ored int o t he equat ion and, t herefore, m ust be provisioned explicit ly for drop- sensit ive
applicat ions such as Voice over I P ( VoI P) .

Layer 2 queuing subsyst em s accom m odat e m edia- specific requirem ent s and idiosyncrasies. For
exam ple, ATM and Fram e Relay m edia support m ult iple Layer 2 logical int erfaces ( for exam ple,
PVCs and DLCI s) per physical int erface and require special scheduling t o accom m odat e such
circuit s. Layer 2 m edia- specific shapers, such as Fram e Relay t raffic shaping, also int eract wit h
queuing, in t hat t he shapers det erm ine t he out put rat e of packet s ont o t he int erface and,
t herefore, push packet s arriving t oo fast back int o t he queues. When t he Layer 2 queues fill up,
t hey, in t urn, push back packet s int o t he Layer 3 queues. Fragm ent at ion and int erleaving also
are perform ed wit hin Layer 2 queuing subsyst em s.

A final queue, usually referred t o as a t ransm it ring ( or Tx- ring) , is locat ed wit hin t he device
driver it self. Tx- rings are m edia and hardware dependent and can operat e quit e different ly on
different rout ers, cards, and m odules. The purpose of t he Tx- ring is t o ensure t hat t here is
always a packet ready t o be placed ont o t he m edia, wit h t he obj ect ive of driving int erface
ut ilizat ion t o 100 percent . Furt herm ore, t he Tx- ring indicat es t o t he queuing algorit hm s whet her
t he int erface is congest ed. ( I f t he Tx- ring is full, t he int erface is congest ed.) When t he Tx- ring
lim it is reached, queuing algorit hm s engage. Som e int erfaces report t he lengt h of t he Tx- ring in
packet s. Ot her int erfaces, such as ATM, report t he lengt h in part icles. ( Part icle lengt h is variable
but is set t o 576 byt es for m ost ATM port adapt ors.)

I t is im port ant t o not e t hat not all t hree levels of queuing are always present .
Legacy Layer 3 Queuing Mechanisms
There is a long hist ory of queuing algorit hm s in Cisco I OS Soft ware, not all of which are covered
in t his chapt er because t hey are not applicable t o QoS deploym ent for converged net works.
Newer queuing and scheduling algorit hm s are sim ply com binat ions and enhancem ent s of older
queuing algorit hm s. For a hist orical perspect ive and an underst anding of why t hese m echanism s
are insufficient for t oday's converged net works, it is helpful t o review som e of t hese legacy
queuing t echniques. The t hree basic legacy queuing t ypes ( beyond sim ple FI FO) are t hese:

Priorit y queuing ( PQ)

Cust om queuing ( CQ)

Weight ed Fair Queuing ( WFQ)

From t hese t hree basic algorit hm s, com binat ions and enhancem ent s were developed. These
newer queuing m echanism s sought t o com bine t he best feat ures of t he basic algorit hm s and, at
t he sam e t im e, t o m inim ize t heir drawbacks. These enhanced queuing algorit hm s include t he
following:

I P RTP priorit y queuing ( PQ- WFQ) . This was a t ransient m et hod and soon was superceded
by low- lat ency queuing.

CBWFQ

LLQ

Table 5- 1 com pares t he at t ribut es of t he different algorit hm s and t heir suit abilit y t o handling
real- t im e, delay- sensit ive t raffic, such as voice. This t raffic requires t wo t hings from a
queuing/ scheduling algorit hm :

An absolut e bandwidt h guarant ee

A delay guarant ee

Cla ssifica t ion

Per int erface

Per prot ocol, per int erface

Per prot ocol, per int erface

I P prec, RSVP, RTP Reserve, prot ocol, port

RTP port for PQ; I P prec for WFQ

Class- based classificat ion

Class- based classificat ion

N u m be r of qu e u e s

16

Per flow

1 PQ + WFQ

Up t o 256 classes

1 PQ + CBWFQ

Sch e du lin g

FI FO

St rict priorit y

Round robin

Weight ed fair ( based on I P prec)

PQ: St rict

W FQ: W e igh t e d fa ir ( ba se d on I P pr e c)

Weight ed fair ( based on bandwidt h)

PQ: St rict

CBW FQ: W e igh t e d fa ir ( ba se d on ba n dw idt h )

D e la y gu a r a n t e e
No

Yes for t raffic in highest - priorit y queue only

No

No

Yes for PQ t raffic

No

Yes for PQ t raffic

Ba n dw idt h gu a r a n t e e

No

No

Yes

No

Yes for PQ t raffic

Yes

Yes

Re com m e n de d for voice

No

No

No

No

No

No

Yes

Ta ble 5 - 1 . Qu e u in g Algor it h m Com pa r iso

FI FO PQ CQ W FQ PQ- W FQ CBW FQ LLQ

Priority Queuing
The oldest queuing algorit hm is PQ, which consist s of only four queues ( high, m edium ,
norm al/ default , and low) . The scheduler begins by em pt ying t he high queue and begins t o
service lower queues only when upper queues are com plet ely em pt y. This basic algorit hm
proved very successful in handling real- t im e t raffic, but it posed st arvat ion possibilit ies t o lower-
priorit y t raffic flows.

Custom Queuing
CQ addressed t he concern of t raffic st arvat ion, com m on in PQ scenarios. By int roducing a round-
robin scheduler t hat was based on byt e count s, not only did cust om queuing prevent bandwidt h
st arvat ion, but it also becam e t he first queuing m echanism t o provide bandwidt h guarant ees .
Alt hough cust om queuing ( which support s up t o 16 dist inct queues) int roduced a fairness t hat
PQ did not have, it lost t he capabilit y t o provide st rict priorit y t o real- t im e flows.

Weighted Fair Queuing

WFQ was developed t o expand on t he principle of fairness t hat CQ broached.

The fair- queuing algorit hm wit hin WFQ sim ply divides t he int erface's bandwidt h by t he num ber
of flows, ensuring an equit able dist ribut ion of bandwidt h for all applicat ions.

By adding a fixed weight ( based on t he packet 's I PP value) t o t he calculat ion, WFQ int roduced a
m et hod for m oderat ely skewing bandwidt h allot m ent s by favoring higher- priorit y flows ( priorit y
being a funct ion of I PP m arking) . Alt hough such skewing preferred cert ain flows over ot hers,
WFQ lost CQ's capabilit y t o provide bandwidt h guarant ees because bandwidt h allocat ions
cont inuously changed as flows were added or ended.

IP RTP Priority Queuing

I P RTP priorit y ( PQ- WFQ) was a t ransient feat ure in t he st ep- by- st ep evolut ion of developing
QoS m echanism s for voice.

I P RTP priorit y queuing was int roduced bet ween WFQ and LLQ in Cisco I OS Soft ware Release
12.0( 5) T for int erfaces and MLP links, and in Cisco I OS Soft ware Release 12.0( 7) T for Fram e
Relay. LLQ was int roduced soon aft erward in Cisco I OS Soft ware Release 12.0( 7) T for int erfaces
and MLPPP links, and in Cisco I OS Soft ware Release 12.1( 2) T for Fram e Relay. Therefore, t he
only legit im at e current uses for I P RTP priorit y queuing are on rout ers t hat handle voice t raffic
and t hat are running code levels bet ween t hese t wo releases. LLQ should be used in all ot her
cases.
Currently Recommended Layer 3 Queuing Mechanisms
Each of t he previously described Layer 3 queuing t ools had serious short com ings in handling t he
t raffic m ix required by converged net works. Eit her t hey handled dat a fairly well or could
priorit ize real- t im e applicat ions, such as voice. But none of t hese t ools was capable of handling
bot h t ypes of t raffic efficient ly. Therefore, enhanced algorit hm s were developed t o leverage t he
st rengt hs of each t ype of legacy algorit hm and, at t he sam e t im e, t o m inim ize t heir weaknesses.

This sect ion provides an overview of t he hybrid queuing m echanism s used t oday for Layer 3:
CBWFQ and LLQ.

Class-Based Weighted Fair Queuing

CBWFQ, int roduced in Cisco I OS Soft ware Release 12.0( 5) T, is a hybrid queuing algorit hm t hat
com bines t he capabilit y t o guarant ee bandwidt h ( from CQ) wit h t he capabilit y t o dynam ically
ensure fairness t o ot her flows wit hin a class of t raffic ( from WFQ) .

CBWFQ enables t he creat ion of up t o 256 classes of t raffic, each wit h it s own reserved queue.
Each queue is serviced based on t he bandwidt h assigned t o each class.

A m aj or difference bet ween WFQ and CBWFQ is t hat , wit h WFQ, t he bandwidt h of t he flow is
calculat ed inst ant aneously; but wit h CBWFQ, a m inim um bandwidt h explicit ly is defined and
enforced. Addit ionally, CBWFQ uses Modular QoS CLI ( MQC) based class m aps for classificat ion,
which provide t he richest and m ost granular recognit ion crit eria wit hin t he Cisco I OS QoS
t oolset . When class m aps are com bined wit h CBWFQ bandwidt h st at em ent s, m inim um -
bandwidt h guarant ees can be provisioned for alm ost any applicat ion.

Exam ple 5- 1 shows t wo applicat ions of CBWFQ. First , a m inim um bandwidt h guarant ee is given
t o t he MI SSI ON- CRI TI CAL- DATA class. Second, all ot her t raffic ( which falls int o class- default ) is
fair queued.

Ex a m ple 5 - 1 . CBW FQ Policy for M u lt iple Le ve ls of D a t a

policy-map WAN-EDGE
class MISSION-CRITICAL-DATA
bandwidth percent 20 sets the bandwidth for this class to 20%
class class-default
fair-queue sets WFQ as the queuing algorithm for unclassified traffic

N ot e
The pe r ce n t keyword was added in Cisco I OS Soft ware Release 12.0( 7) T, allowing
bandwidt h t o be allocat ed as relat ive percent ages of t he link, or shaping rat e, inst ead
 of in absolut e values ( in kilobit s per second) . The pe r ce n t keyword increases CBWFQ
policy m odularit y because t he sam e policies can be applied t o m any int erfaces,
regardless of t heir link speeds. Addit ionally, t he pe r ce n t keyword m akes fut ure
expansion easier t o m anage because t he relat ive bandwidt h allocat ions aut om at ically
will increase as t he link speeds t hem selves increase.

CBWFQ is a highly efficient algorit hm for dat a applicat ions, but it lacks t he capabilit y t o provide
st rict - priorit y servicing t o real- t im e applicat ions, such as voice or int eract ive video. This is
because it provides a bandwidt h guarant ee but not a lat ency guarant ee. Therefore, t o service
such real- t im e applicat ions, a st rict - priorit y queue was added t o t he CBWFQ algorit hm ; t he
result ing algorit hm was nam ed low- lat ency queuing.

Low-Latency Queuing
LLQ is an enhanced com binat ion of all t hree legacy queuing algorit hm s: PQ, CQ, and WFQ. I t
was int roduced in Cisco I OS Soft ware Release 12.0( 7) T.

LLQ is essent ially CBWFQ com bined wit h a st rict PQ. Traffic assigned t o t he st rict priorit y queue,
using t he pr ior it y com m and, is serviced up t o it s assigned bandwidt h before all ot her CBWFQ
queues are serviced.

N ot e
The original nam e for t he LLQ algorit hm was PQ- CBWFQ. Alt hough t his nam e was
t echnically correct , it was obviously clum sy from a m arket ing perspect ive. Hence, t he
algorit hm was renam ed LLQ.

LLQ also has an im plicit ly defined burst param et er ( added in Cisco I OS Soft ware Release
12.1[ 3] T) t hat accom m odat es t em porary burst s of real- t im e t raffic. By default , LLQs are
provisioned t o prot ect burst s up t o 200 m s, defined in byt es. The burst param et er becom es
significant in cert ain int eract ive video scenarios ( which are discussed in m ore det ail in Chapt er
13 , " WAN Aggregat or QoS Design" ) .

I n Exam ple 5- 2, up t o one- t hird of t he link's ( or shaper's) bandwidt h is assigned for st rict
priorit y t reat m ent of voice.

Ex a m ple 5 - 2 . LLQ for VoI P a n d M u lt iple Le ve ls of D a t a

policy-map WAN-EDGE
class VOICE
priority percent 33 sets the LLQ bandwidth to 33%
class CALL-SIGNALING
bandwidth percent 2
class MISSION-CRITICAL-DATA
bandwidth percent 20
 class class-default
fair-queue

N ot e
The pe r ce n t keyword was added t o t he LLQ pr ior it y com m and in Cisco I OS Soft ware
Release 12.2( 2) T.

The next sect ions discuss furt her det ails about LLQ, such as it s operat ion, t he im plicit policing
done by t he queuing algorit hm , bandwidt h provisioning, and t he lesser- known int eract ions
bet ween LLQ, I PSec, cRTP, and LFI , and bundling t echnologies such as ATM, MLP, and Fram e
Relay bundles.

LLQ Operation

LLQ is designed exclusively for converged net works t hat carry voice and int eract ive video. I t
cont ains t wo com ponent s, a PQ for t he real- t im e sensit ive t raffic and a class- based com plex of
queues ( CBWFQ) . The PQ is t he opt im al queueing m echanism for real- t im e t raffic, whereas
CBWFQ is t he best queuing algorit hm for dat a applicat ions. Converged net works require LLQ t o
be configured so t hat voice, int eract ive video, and dat a all are given t he service levels t hey
require.

The Layer 3 queuing subsyst em for LLQ is shown on t he left side of Figure 5- 2 . I n t his
illust rat ion, voice t raffic is classified and placed in t he PQ. When t raffic is present in t he PQ, it is
serviced wit h exhaust ive priorit y t reat m ent up t o t he bandwidt h m axim um configured for t he
priorit y class ( t hat is, voice is sent out first unt il no m ore voice is present or t he bandwidt h
assigned is exceeded) . The L2 subsyst em is discussed lat er in t his chapt er.

Figu r e 5 - 2 . LLQ Ope r a t ion Logic

LLQ Policing

The t hreat posed by any st rict priorit y- scheduling algorit hm is t hat it could st arve lower- priorit y
t raffic. To prevent t his, t he LLQ m echanism has a built - in policer. This policer ( like t he queuing
algorit hm it self) engages only when t he int erface is experiencing congest ion. Therefore, it is
im port ant t o provision t he priorit y classes properly. I f t he t ot al am ount of priorit y class
bandwidt h provisioned is lower t han t he t ot al am ount of voice t raffic offered t o t he PQ ( including
t he Layer 2 overhead) , t he excess voice t raffic m ight be dropped ( by t he LLQ policer) . As wit h
any ot her policer, LLQ's policer, when engaged, drops t raffic indiscrim inat ely and affect s t he
qualit y of all voice calls act ive on t he int erface ( not j ust t he last one t o go t hrough) . St rat egies
t o accom m odat e t his behavior of LLQ are discussed in m ore det ail in Chapt er 9, " Call Adm ission
Cont rol ( CAC) ." I n earlier Cisco I OS Releases, t he PQ of LLQ policed st rict ly t o t he bandwidt h
assigned, regardless of t raffic present or absent in ot her classes. I n lat er releases, t his operat ion
changed t o police st rict ly only if t he int erface was congest edt hat is if ot her classes were
underut ilized, PQ t raffic would be allowed t o exceed it s bandwidt h wit hout dropping packet s.

Anot her benefit provided by t he im plicit policer wit hin t he LLQ m echanism is t he capabilit y t o use
TDM for t he single st rict - priorit y queue. TDM abst ract s t he fact t hat only a single st rict - priorit y
queue exist s and allows for t he configurat ion and servicing of " m ult iple" low- lat ency queues.

I n Exam ple 5- 3, separat e priorit y classes on a dual- T1 MLP link are assigned for voice and
videoconferencing. Each priorit y class is policed ( t o 540 kbps for voice and 460 kbps for video) .
Under t he hood, however, t here is only a single 1- Mbps PQ ( 540 kbps + 460 kbps) , which is t im e
shared bet ween t hese t wo applicat ions by t he im plicit policer.

Ex a m ple 5 - 3 . LLQ Policy for VoI P, I n t e r a ct ive Vide o, a n d M u lt iple

Le ve ls of D a t a

policy-map WAN-EDGE
class VOICE
 priority 540 creates a LLQ of 540 kbps
class INTERACTIVE-VIDEO
priority 460 creates a "second" LLQ of 460 kbps
class CALL-SIGNALING
bandwidth percent 2
class MISSION-CRITICAL-DATA
bandwidth percent 20
class class-default
fair-queue

Bandwidth Provisioning

Most applicat ions default t o t he best - effort default class. Because ent erprises have hundreds, if
not t housands, of applicat ions on t heir net works, it is a general best pract ice t o provision at least
25 percent of a link's bandwidt h for " class- default ." This recom m endat ion has been coded int o
older Cisco I OS Soft ware releases for t he lower- end plat form s ( Cisco 7200 and below) . I f
present , t his rest rict ion can be overridden m anually ( using t he m a x - r e se r ve d- ba n dw idt h
int erface com m and) .

A sim ilar considerat ion m ust be given t o t he sum of all t raffic assigned for all priorit y classes. I t
is im port ant t o rem em ber t he goal of convergence: t o allow voice, video, and dat a t o coexist
t r anspar ent ly on a single net work. I f real- t im e applicat ions dom inat e a net work, as in t he case of
a dom inant ly provisioned LLQ ( in which t he priorit y classes have t he lion's share of t he
bandwidt h) , dat a applicat ions m ight fluct uat e significant ly in t heir net work response t im es when
voice/ videoconference calls are m ade. This dest roys t he t ransparency of t he converged net work.
User feedback consist ent ly has reflect ed t hat m ost users prefer consist ent ( even if m oderat ely
slower) applicat ion response t im es over varying response t im es ( as would occur if LLQs
dom inat ed WAN links) . Cisco Technical Market ing t est ing has revealed a conservat ive rule of
t hum b for priorit y class provisioning, which is t o lim it t he sum of all priorit y class t raffic t o no
m ore t han 33 percent of t he WAN link's capacit y. This 33 percent LLQ rule has been deployed
widely and successfully.

Figure 5- 3 illust rat es t hese bandwidt h- provisioning recom m endat ionsnam ely, t hat t he aggregat e
bandwidt h of all priorit y classes should be no m ore t han 33 percent of t he link's capacit y and
t hat all bandwidt h guarant ees wit hin LLQ should be no m ore t han 75 percent of t he link capacit y.

Figu r e 5 - 3 . LLQ Ba n dw idt h Pr ovision in g

Because of t he policing funct ion wit hin LLQ, it is im port ant t o accurat ely provision bandwidt h
required for voice calls. LLQ is a Layer 3 queuing m echanism and, as such, account s for only
Layer 3 packet bandwidt h. ( I t does not t ake Layer 2 headers int o account .) Furt herm ore, t he
Layer 3 bandwidt h required by a voice call is det erm ined by a num ber of fact ors. These fact ors
include t he codec used, t he sam pling size, and t he com pression t echniques, such as cRTP ( also
known as RTP header com pression) . Cisco has provided a voice bandwidt h calculat or t o
det erm ine t he correct bandwidt h t o provision in LLQ for voice calls. The calculat or is locat ed on
t he web at ht t p: / / t ools.cisco.com / Support / VBC/ j sp/ Codec_Calc1.j sp.

When t he percent age- rem aining ( ba n dw idt h r e m a in in g pe r ce n t ) form of LLQ configurat ion is
used, t he 75 percent rule no longer applies. This is because t he rem aining percent st at em ent
refers t o t he inst ant aneous residual bandwidt h, aft er t he PQ ( priorit y classes) has been serviced,
on t he int erface. I n Exam ple 5- 4, up t o 33 percent of t he link can be dedicat ed for voice t raffic.
Aft er voice t raffic has been serviced, however, all rem aining bandwidt h is divided equally
bet ween t he MI SSI ON- CRI TI CAL- DATA class and t he default class.

Ex a m ple 5 - 4 . LLQ Policy for VoI P a n d M u lt iple Le ve ls of D a t a Usin g

Re m a in in g Pe r ce n t a ge Alloca t ion s

policy-map WAN-EDGE
class VOICE
priority percent 33
class MISSION-CRITICAL-DATA
bandwidth remaining percent 50
class class-default
bandwidth remaining percent 50

LLQ and IPSec

Encrypt ing a link t hat carries different classes of t raffic and em ploys LLQ has several
im plicat ions:
 Encrypt ion happens before queuing. Therefore, classificat ion of all t raffic m ust be carefully
considered, and inner and out er headers m ust be m arked appropriat ely t o ensure correct
classificat ion for egress queuing purposes.

Encrypt ion changes packet sizes because it adds headers t o t he packet and t hus affect s
bandwidt h allocat ion for bot h voice and dat a t raffic. The effect is m uch m ore significant for
voice because t he packet s are relat ively sm all, m aking t he relat ive overhead of t he new
headers far great er. Figure 5- 4 illust rat es how t unneling and encrypt ion overhead can m ore
t han double t he Layer 3 bandwidt h required for a voice packet .

Figu r e 5 - 4 . G.7 2 9 Voice Ba n dw idt h w it h GRE a n d I PSe c

[View full size image]

The bot t leneck wit hin t he net work node t hat applies t he encrypt ion pot ent ially m oves from
t he egress int erface t o t he encrypt ion engine. On m ost rout ers t hat have encrypt ion
accelerat ors, t he com bined t hroughput of egress int erfaces t hat can be support ed far
exceeds t he t hroughput of t he encrypt ion engines. Therefore, encrypt ion for t raffic m ust be
engineered carefully, especially if converged t raffic is sent t hrough an encrypt ed t unnel.

I f encrypt ion is used, especially on t he lower- end rout er plat form s, hardware accelerat ors should
be used. I f t he egress int erface t hroughput exceeds t he t hroughput of t he encrypt ion engine,
packet s m ight heap up wait ing t o ent er t he crypt o engine; t herefore, LLQ m ust be applied on t he
I PSec engine ent rance inst ead of t he egress int erface, as illust rat ed in Figure 5- 5 . This is a
feat ure nam ed LLQ Before Crypt o t hat becam e available in Cisco I OS Soft ware Release
12.2( 13) T.

Figu r e 5 - 5 . LLQ for I PSe c En cr ypt ion En gin e s

LLQ and cRTP

Tradit ionally, packet - com pression t echniques occurred at Layer 2 and, t herefore, were not
visible t o t he LLQ algorit hm at Layer 3. LLQ priorit y class bandwidt h t hus requires careful
provisioning t o reflect t he act ual bandwidt h required, aft er com pression but inclusive of Layer 2
overhead.

Typical Layer 2 dat a- com pression t echniques, such as FRF.9 or PPP STAC com pression, t end t o
have only a m ild effect on voice packet s. This is because codec com pression, such as G.729,
already does very t ight com pression. Lit t le or no repet it ive pat t erns can be opt im ized by
applying yet anot her generic com pression t echnique.

At 40 byt es, t he st andard I P/ RTP/ UDP header overhead of a voice packet is quit e subst ant ial,
especially when com pared t o t he relat ively sm all size of t he payloads ( 20 byt es for G.729 t o 160
byt es for G.711) . RTP header com pression ( or cRTP) , which is discussed in great er det ail in
Chapt er 7, " Link- Specific Tools," can reduce t he overhead requirem ent s of voice packet s from 40
byt es t o bet ween 2 and 5 byt es.

A new feat ure in Cisco I OS Soft ware Release 12.2( 13) T allows cRTP t o be configured wit hin t he
MQC synt ax and perform ed in t he CEF swit ch pat h. Class- based cRTP also im proves t he feedback
m echanism t o t he LLQ policing engine.

LLQ and LFI

Link Fragm ent at ion and I nt erleaving ( LFI ) is a QoS t echnique t o m inim ize serializat ion delay on
slow ( t ypically less t han 768- kbps) WAN links. Essent ially, LFI t ools chop large dat a packet s int o
sm aller ones and int erleave t hese dat a packet fragm ent s wit h voice packet s. LFI t echniques are
discussed in m ore det ail in Chapt er 7, " Link- Specific Tools," but t hey have an im port ant
relat ionship wit h t he LLQ m echanism t hat bears point ing out at t his t im e.

As shown in Figure 5- 2 , packet s t hat are assigned t o t he PQ inside LLQ m ight escape t he
fragm ent at ion engine ( t he fragm ent at ion engine is represent ed by t he box labeled fragm ent ) .
Therefore, t raffic wit h large packet sizes ( such as int eract ive video) should not be assigned t o
priorit y classes on slow- speed links ( t ypically less t han 768 kbps) . For exam ple, if one priorit y
class is assigned t o VoI P and anot her is assigned t o int eract ive video on a 512- kbps link,
whenever a 1500- byt e video packet is scheduled for t ransm ission, it will require 23 m s t o
serialize ( ( 1500 x 8) / 512,000) . This exceeds t he per- hop lat ency t arget for voice ( 10 m s) and
nearly consum es t he ent ire one- way j it t er allowance t arget of 30 m s. I f a second 1500- byt e
I P/ VC packet also is scheduled for t ransm ission, voice conversat ions audibly will becom e
degraded. Therefore, voice and int eract ive video never should be assigned dual- LLQ policies on
link speeds less t han 768 kbps.
LLQ and ATM PVC Bundles

When different t raffic t ypes are converged on a single ATM PVC, t he norm al LLQ operat ion for
any int erface or PVC applies. However, when PVCs are bundled t oget her, special considerat ions
m ust be t aken, and t hese are discussed furt her in t his sect ion.

ATM PVC bundles ( previously discussed in Chapt er 3, " Classificat ion and Marking Tools," do not
require LLQ. Rem em ber t hat ATM PVC bundles use m ult iple PVCs t o provide different classes of
service over t he net work backbone. Each PVC is dedicat ed t o a part icular class of t raffic. The
very nat ure of LLQ is t o separat e different classes of t raffic on t he sam e egress int erface ( or
PVC) . ATM PVC bundling does j ust t he opposit e: I t separat es different classes of t raffic ont o
separat e, dedicat ed egress int erfaces ( or PVCs) . For t his reason, LLQ is not support ed ( or
needed) on ATM PVC bundles.

For ATM PVC bundles, keep t he following point s in m ind:

LLQ is not support ed.

LFI is not support ed.

cRTP is not support ed.

No packet reordering occurs.

All VCs m ust exist on a single physical int erface.

There is no bandwidt h sharing. Each PVC is dedicat ed t o t raffic of a part icular t ype, and
unused bandwidt h cannot be used by t raffic of ot her classes.

Tx- rings should be set t o t heir default .

LLQ and MLP/Frame Relay Bundles

Ot her bundling t echniques have different QoS charact erist ics: in part icular, MLP and Fram e Relay
bundles. These t ools aggregat e bandwidt h across m ult iple physical int erfaces and bind t hem
t oget her as a larger logical int erface. These t ools offer addit ional flexibilit y, especially wit h
respect t o ease of expansion: They sim plify m anagem ent t o a large degree.

I nt erfaces bundled in t his m anner have t he following QoS requirem ent s:

LLQ is support ed ( and required) .

LFI is support ed if t he aggregat e bandwidt h of t he bundle is st ill below 768 kbps. ( This is
likely not required because bundling m ost oft en allows bandwidt hs above 768 kbps so t hat
LFI is no longer necessary.)

cRTP is support ed.

Packet reordering occurs.

Mult iple physical int erfaces are bound t oget her.

 There is bandwidt h sharing across t he aggregat e bandwidt h of all t he links in t he bundle.

Tx- rings should be set t o a m inim al value, such as 3.

Figure 5- 6 shows t his principle in an MLP bundle aggregat ing several ATM PVCs spread across
m ult iple DSL int erfaces. The DSL int erfaces are t erm inat ed by t he DSLAM equipm ent in t he
net work, and t he bundled PVCs are delivered on a high- speed ATM int erface, such as an OC- 3,
at t he aggregat ion sit e. I n t his case, LLQ is applied at t he MLP bundle int erface, not t o t he act ual
physical int erfaces.

Figu r e 5 - 6 . M LP PVC Bu n dlin g

[View full size image]

LLQ and VoFR

Voice over Fram e Relay ( VoFR) is an older t echnique of t ransport ing voice t raffic over Fram e
Relay net works. I t exist ed before VoI P becam e im plem ent ed widely. VoFR is a pure Layer 2
m et hod of t ransport ing voice and, for t he m ost part , has been replaced by VoI P in com binat ion
wit h LLQ.

Cisco I OS Soft ware t radit ionally has priorit ized VoFR packet s by default int o t he sam e PQ t hat is
used by LLQ priorit y classes. The bandwidt h allot t ed t o VoFR packet s is assigned by t he voice-
bandwidt h st at em ent in t he Fram e Relay m ap class. VoFR packet s are funneled int o t he PQ of
t he LLQ algorit hm .

N ot e
Care m ust be t aken t o never put VoFR and VoI P t raffic on t he sam e Fram e Relay DLCI
on slow speed links t hat require fragm ent at ion and int erleaving ( t hat is, less t han or
equal t o 768 kbps) . This is because VoFR and VoI P require different fragm ent at ion
st andards ( FRF.11 and FRF.12, respect ively) . I f bot h VoFR and VoI P are configured on
t he sam e DLCI wit h fragm ent at ion for each enabled, FRF.11 overrides FRF.12 and
disables t he int erleaving schem e t hat VoI P packet s require. Obviously t hen, t he qualit y
of VoI P will det eriorat e significant ly.
Layer 2 Queuing Tools
Layer 2 queuing t ools are required t o resolve t he priorit izat ion issues generat ed by m ult iple
logical int erfaces ( such as Fram e Relay DLCI s and ATM PVCs) as t hey cont end for t he scheduling
of a single physical parent int erface. These include t he following:

Fram e Relay Dual- FI FO

PVC I nt erface Priorit y Queuing ( PI PQ)

Frame Relay Dual-FIFO

On t he low- end rout er non- dist ribut ed plat form s ( Cisco 7200 and lower) , Fram e Relay em ploys a
dual- FI FO queuing t echnique t hat aut om at ically is invoked at t he int erface level when FRF.12,
which is discussed in det ail in Chapt er 7, is configured. FRF.12 depends on Fram e Relay t raffic
shaping ( FRTS) or class- based FRTS being enabled.

I n a Fram e Relay environm ent , t he Tx- ring does not direct ly provide back pressure t o t he Layer
3 queuing algorit hm . I nst ead, when t he Tx- ring is full, it provides back pressure t o t he shaper
( FRTS or CB- FRTS) , which, in t urn, signals t he Layer 3 queuing syst em ( LLQ) t o engage.
Because t he FRTS m echanism does not t ake int o account Fram e Relay headers and cyclic
redundancy checks ( CRCs) in it s calculat ions, it generally is recom m ended t hat you shape t o 95
percent of CI R on Fram e Relay circuit s up t o T1/ E1 speeds. This, in t urn, engages t he LLQ
algorit hm slight ly earlier and im proves perform ance for real- t im e t raffic.

Traffic from each PQ for each DLCI is funneled int o t he high- priorit y, dual- FI FO int erface queue;
all t raffic from t he CBWFQ queues from t he DLCI s is assigned t o t he lower- priorit y, dual- FI FO
int erface queue. Thus, t he dual- FI FO Layer 2 queues ensure t hat t he " priorit y" class t raffic from
one DLCI is not delayed by CBWFQ t raffic from anot her DLCI . Fram e Relay Layer 3 and Layer 2
queuing and shaping logic is illust rat ed in Figure 5- 7 .

Figu r e 5 - 7 . LLQ on Fr a m e Re la y PVCs w it h FRTS a n d D u a l- FI FO

PVC Interface Priority Queuing
Traffic of different im port ance levels som et im es is separat ed ont o different PVCs for
m anagem ent or ot her net work design reasons. I n such designs, all t raffic on t he priorit y PVC
should overt ake all t raffic on lower- priorit y PVCs when cont ending for a single egress int erface.
PVC int erface priorit y queuing ( PI PQ) is t he Layer 2 queuing m echanism t hat accom plishes t his
reordering. I t t ypically is found in service provider scenarios where dedicat ed PVCs are used t o
provide priorit y services.

PI PQ defines four queues at t he int erface level. Each PVC on t he int erface can be assigned t o one
of four priorit ies. As wit h all PQ t echniques, t he higher- priorit y queues have exhaust ive priorit y
over t he lower- priorit y ones and can t herefore pot ent ially st arve t hem . The operat ion of PI PQ is
illust rat ed in Figure 5- 8 .

Figu r e 5 - 8 . PVC I n t e r fa ce Pr ior it y Qu e u in g ( PI PQ) for Fr a m e Re la y

[View full size image]

I n Figure 5- 8 , DLCI s 101 and 102 are designat ed as high priorit y, while DLCI s 103, 104, and
105 are m apped t o t he m edium , norm al, and low queues, respect ively. Traffic on DLCI s 101 and
102 will, t herefore, have priorit y over any of t he ot her PVCs, and DLCI 105 will be capable of
sending t raffic only if none of t he ot her PVCs has a fram e ready t o be t ransm it t ed.

A pract ical applicat ion for t his queuing t echnique is t o place voice t raffic on DLCI 101, a financial
t icker on DLCI 102, and various levels of dat a t raffic on t he ot her t hree PVCs. Exam ple 5- 5
shows t he configurat ion of PI PQ for DLCI 101.

Ex a m ple 5 - 5 . Fr a m e Re la y PI PQ Ex a m ple

interface serial0.101
frame-relay interface-queue priority 10 20 30 40
frame-relay interface-dlci 101
class HIGH-PVC

map-class frame-relay HIGH-PVC

frame-relay interface-queue priority high
Tx-ring
The Tx- ring is a final FI FO queue t hat holds fram es t o be placed im m ediat ely on t he physical
int erface. I t s purpose is t o ensure t hat a fram e always will be available when t he int erface is
ready t o t ransm it t raffic so t hat link ut ilizat ion will be driven t o 100 percent of capacit y.

The placem ent of t he Tx- ring is shown on t he right of Figures 5- 2 and 5 - 7. The size of t he Tx-
ring depends on t he hardware, soft ware, Layer 2 m edia, and queuing algorit hm configured on
t he int erface. I t is a general best pract ice t o set t he Tx- ring t o a value of 3 on slow- link
int erfaces ( less t han or equal t o 768 kbps) .

The Tx- ring is especially im port ant on ATM links ( including DSL) , in which each PVC has a
dedicat ed driver- level queue ( Tx- ring) t o ensure adherence t o t he ATM class- of- service t raffic
cont ract of t he PVC. Default ATM Tx- rings are t ypically deep, cont aining 64 or m ore part icles
( t ypically, each part icle is 576 byt es) t o ensure t hat enough part icles exist in t he buffer t o drive
t he PVC t o it s full bandwidt h ut ilizat ion. A shallow Tx- ring increases t he num ber of int errupt s and
t he wait st at es bet ween t he driver and t he m ain CPU. Packet s are downloaded from t he Layer 3
queues t o t he driver for t ransm ission, which is usually subopt im al at higher speeds.

On t he ot her hand, a deep Tx- ring can im pact voice qualit y. For exam ple, assum e t hat a 50-
packet burst of dat a passes t hrough t he LLQ syst em and int o t he FI FO Tx- ring. A voice packet
t hen arrives and is packet num ber 51 for t ransm ission. The LLQ no longer has t he opport unit y t o
priorit ize it over t he dat a packet s. A shallow Tx- ring pushes packet s back int o LLQ, where
priorit izat ion and packet reordering can be accom plished before t he packet s are downloaded t o
t he driver. Once in t he driver level, t he packet s have a very short wait t im e unt il t ransm ission.

Thus, t he t uning of t he Tx- ring is a com prom ise bet ween opt im izing real- t im e packet delays and
achieving m axim um CPU efficiency. The higher t he bandwidt h of t he PVC is, t he deeper t he Tx-
ring can be set wit hout adversely affect ing voice qualit y. For slow links ( less t han or equal t o 768
kbps) , however, a Tx- ring of 3 is recom m ended t o m aint ain voice qualit y.
PAK_priority
Cert ain t raffic t ypes, such as Layer 2 keepalives and Layer 3 rout ing prot ocol m essages, are
absolut ely crit ical t o m aint aining net work st abilit y. Therefore, it is vit al t o underst and how t he
Cisco I OS Soft ware handles t hese t raffic t ypes, especially when provisioning WAN links t hat
m ight experience sust ained periods of congest ion.

By default , Cisco I OS Soft ware ( in accordance wit h RFC 791 and RFC 2474) m arks I nt erior
Gat eway Prot ocol ( I GP) t raffic ( such as Rout ing I nform at ion Prot ocol [ RI P/ RI Pv2] , Open Short est
Pat h First [ OSPF] , and Enhanced I nt erior Gat eway Rout ing Prot ocol [ EI GRP] ) t o I PP6/ CS6. These
precedence values specify PHBs for t hese cont rol packet s as t hey pass t hrough t he net work.
However, Cisco I OS Soft ware also has an int ernal m echanism for grant ing priorit y t o im port ant
cont rol dat agram s as t hey are processed t hrough t he rout er. This m echanism is called
PAK_priorit y.

As dat agram s are processed t hough t he rout er and down t o t he int erfaces, t hey are
encapsulat ed int ernally wit h a sm all packet header, referred t o by an int ernal label. Wit hin t he
fields of t his label is a PAK_priorit y flag t hat indicat es t he relat ive im port ance of cont rol packet s
t o t he rout er's int ernal processing syst em s. PAK_priorit y designat ion is a crit ical int ernal Cisco
I OS Soft ware operat ion and, as such, is not adm inist rat ively configurable in any way.

The default int ernal t reat m ent of PAK_priorit y dat agram s varies slight ly bet ween dist ribut ed
plat form s and nondist ribut ed plat form s when MQC policies are bound t o t he out going int erfaces.

Dist ribut ed plat form s place t he PAK_priorit y dat agram s int o t he class- default queue and
use t he PAK_priorit y flag t o avoid dropping t he packet s.

Nondist ribut ed plat form s place PAK_priorit y dat agram s int o a separat e and dedicat ed set of
queues ( 257263) from t he class- default , and m ark t hem wit h a special weight value
( 1024) .

As not ed previously, I GPs are not only m arked I PP6/ CS6, but t hey also receive PAK_priorit y
t reat m ent wit hin t he rout ers. For rout ing packet s t hat are not m arked wit h I PP6/ CS6, special
bandwidt h considerat ions should be given.

Addit ionally, several non- I P cont rol packet s, including t he following, receive PAK_priorit y:

I nt erm ediat e Syst em - t o- I nt erm ediat e Syst em ( I S- I S) rout ing prot ocol m essages

Point - t o- Point Prot ocol ( PPP) keepalives on serial and Packet over SONET ( POS) int erfaces

High- Level Dat a Link Cont rol ( HDLC) keepalives on serial and POS int erfaces

ATM operat ion, adm inist rat ion, and m aint enance ( OAM) and Address Resolut ion Prot ocol
( ARP) cells

Fram e Relay Local Managem ent I nt erface ( LMI ) m essages

Summary
Congest ion- m anagem ent t ools were overviewed in t his chapt er, wit h an em phasis on t he LLQ
algorit hm , because t his is t he principal recom m ended Cisco I OS queuing t ool for converged
net works.

The operat ion of t he LLQ algorit hm is im port ant t o underst and because it direct ly im pact s QoS
design recom m endat ions. Addit ionally, t he int erdependence of t he QoS t oolset is highlight ed
because congest ion- m anagem ent t ools are shown t o be com plem ent ary t o classificat ion and
m arking t ools, policing and shaping t ools, congest ion- avoidance t ools, and link- efficiency
m echanism s.

Alt hough m ost queuing policies occur at Layer 3, it is im port ant t o consider any im pact s t hat
lower levels of queuing, such as Fram e Relay Dual- FI FO, Tx- ring, and PAK_priorit y, m ay have on
t he overall net work design.
Further Reading
Layer 3 Queuing

Configuring priorit y queuing:

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fqos_c/ fqcprt 2/ qcfpq.ht m
.

Configuring cust om queuing:

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fqos_c/ fqcprt 2/ qcfcq.ht m

Configuring weight ed fair queuing:

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fqos_c/ fqcprt 2/ qcfwfq.ht m
.

I P RTP priorit y ( Cisco I OS Soft ware Release 12.0.5T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 5/ iprt p.ht m

Class- based weight ed fair queuing ( Cisco I OS Soft ware Release 12.0.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 5/ cbwfq.ht m

Low- lat ency queuing ( Cisco I OS Soft ware Release 12.0.7T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 7/ pqcbwfq.ht m
.

Low- lat ency queuing for Fram e Relay ( Cisco I OS Soft ware Release 12.1.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 2/ dt frpqfq.ht m
.

Configuring burst size in low- lat ency queuing ( Cisco I OS Soft ware release 12.1.3T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 3/ dt cfgbst .ht m
.

RSVP support for low- lat ency queuing ( Cisco I OS Soft ware Release 12.1.3T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 3/ rsvp_llq.ht m
.

Dist ribut ed low- lat ency queuing ( Cisco I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt llqvip.ht m
.

Low- lat ency queuing wit h priorit y percent age support ( Cisco I OS Soft ware Release 12.2.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ ft llqpct .ht m

Low- lat ency queuing ( LLQ) for I PSec encrypt ion engines ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ llqfm .ht m

Layer 2 Queuing
 Voice over Fram e Relay Queuing Enhancem ent ( Cisco I OS Soft ware Release 12.0.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 5/ vofrque.ht m

Fram e Relay I P RTP Priorit y ( Cisco I OS Soft ware Release 12.0.7T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 7/ friprt p.ht m

Fram e Relay PVC int erface priorit y queuing ( Cisco I OS Soft ware Release 12.1.1T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 1/ dt frpipq.ht m

Mult ilink Fram e Relay ( FRF.16) ( Cisco I OS Soft ware release 12.2.8T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ ft _m fr.ht m

Enhanced Voice and QoS for ADSL and G.SHDSL ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122lim it / 122y/ 122yn8/ ft _
.

Fram e Relay queuing and fragm ent at ion at t he I nt erface ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ frfrint q.ht m

Mult iclass m ult ilink PPP ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft m m lppp.h

Fram e Relay PVC int erface priorit y queueing ( Cisco I OS Soft ware Release 12.1.1T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 1/ dt frpipq.ht m

Tx-ring

Underst anding and Tuning t x- ring- lim it value:

ht t p: / / www.cisco.com / en/ US/ t ech/ t k39/ t k824/ t echnologies_t ech_not e09186a00800fbafc.sht m l
.

PAK_priority

How rout ing updat es and Layer 2 cont rol packet s are queued on an int erface wit h a QoS
service policy: ht t p: / / www.cisco.com / warp/ public/ 105/ rt gupdat es.ht m l .
Chapter 6. Congestion-Avoidance Tools
This chapt er includes t he following t opics:

Random Early Det ect ion

Weight ed Random Early Det ect ion

DSCP- Based Weight ed Random Early Det ect ion

Explicit congest ion not ificat ion

Congest ion- avoidance m echanism s, such as Weight ed Random Early Det ect ion ( WRED) , are
com plem ent ary t o ( and dependent on) queuing algorit hm s. Queuing/ scheduling algorit hm s
m anage t he front of a queue, whereas congest ion- avoidance m echanism s m anage t he t ail of a
queue.

Congest ion- avoidance QoS t ools are designed t o handle TCP- based dat a t raffic. TCP has built - in
flow- cont rol m echanism s t hat operat e by increasing t he t ransm ission rat es of t raffic flows ( even
t hough bounded by buffers and window sizes) unt il packet loss occurs. At t his point , TCP
abrupt ly squelches t he t ransm ission rat e and gradually begins t o ram p t he t ransm ission rat es
higher again. This behavior m akes a st rong case against t he st at em ent " QoS isn't necessary;
j ust t hrow m ore bandwidt h at it ." I f left unchecked, lengt hy TCP sessions ( as are t ypical wit h
bulk dat a and scavenger applicat ions) can consum e any and all available bandwidt h, sim ply
because of t he nat ure of TCP.

When no congest ion- avoidance algorit hm s are enabled on an int erface, t he int erface is said t o
t ail drop. That is, aft er t he queuing buffers have filled, all ot her packet s are dropped as t hey
arrive.

I n a const rict ed channel, such as in a WAN or a VPN, all t he TCP connect ions event ually
synchronize wit h each ot her as t hey com pet e for t he channel. Wit hout congest ion- avoidance
m echanism s, t hey all ram p up t oget her, lose packet s t oget her, and back off t oget her. This
behavior is referred t o as global synchronizat ion. I n effect , waves of TCP t raffic flow t hrough t he
net work nodes, wit h packet s overflowing t he buffers at each wave peak and lulls in t raffic
bet ween t he waves.

Figure 6- 1 illust rat es TCP global synchronizat ion behavior at t ribut able t o t ail- dropping and t he
subopt im al effect t hat t his behavior has on bandwidt h ut ilizat ion.

Figu r e 6 - 1 . TCP Globa l Syn ch r on iza t ion

This chapt er looks at several variat ions of t he Random Early Det ect ion QoS t ool, which st rives t o
com bat t his global synchronizat ion behavior exhibit ed by TCP t raffic. Explicit congest ion
not ificat ion is anot her t ool t hat can be em ployed t o im prove bandwidt h ut ilizat ion of TCP t raffic.
The operat ion and configurat ion of t hese t ools are discussed in t he following sect ions.
Random Early Detection
Random Early Det ect ion ( RED) count ers t he effect s of TCP global synchronizat ion by random ly
dropping packet s before t he queues fill t o capacit y. Random ly dropping packet s inst ead of
dropping t hem all at once, as is done in a t ail drop, avoids global synchronizat ion of TCP
st ream s.

I nst ead of wait ing for queuing buffers t o fill before dropping packet s, RED causes t he rout er t o
m onit or t he buffer dept h and perform early discards ( drops) on random packet s when t he
m inim um defined queue t hreshold has been exceeded.

RED drops occur wit hin t he operat ional bounds of TCP ret ry t im ers, which slow t he t ransm ission
rat es of t he sessions but prevent t hem from st art ing slow. Thus, RED opt im izes net work
t hroughput of TCP sessions.

Because UDP does not have any ret ry logic, congest ion- avoidance t echniques such as RED ( and
variant s) do not apply t o UDP- based t raffic.

The Cisco I OS Soft ware does not support RED; it support s only Weight ed RED ( WRED) . I t is
im port ant t o not e t hat t he r a n dom - de t e ct Cisco I OS soft ware CLI com m and enables WRED.
However, if all t he packet s assigned t o an int erface or class have t he sam e I PP or DSCP
m arkings, t he effect ive policy is sim ply RED.
Weighted Random Early Detection
WRED is an enhancem ent t o RED t hat enables a degree of influence over t he " random ness" of
t he select ion of packet s t o be dropped. WRED fact ors t he weight , or I PP, of t he packet int o t he
drop- select ion process.

Wit hin t he WRED algorit hm , a m inim um t hreshold for a given I PP value det erm ines t he queue
dept h at which packet s of t hat I PP value begin t o be random ly dropped. The m axim um t hreshold
det erm ines t he queue dept h at which all packet s of t hat I PP value are dropped. These t hresholds
are t unable, as is t he m ark probabilit y denom inat or, which det erm ines how aggressively t he
packet s of a given I PP value are dropped. ( For exam ple, a m ark probabilit y denom inat or value of
10 indicat es t hat up t o 1 in 10 packet s of a cert ain precedence value will be dropped
random lyt he m axim um rat e of 1 in 10 happens at t he m axim um t hreshold, and t he drop rat e is
linear up t o t his m axim um , as shown in Figure 6- 2 .)

Figu r e 6 - 2 . W e igh t e d Ra n dom Ea r ly D e t e ct ion

[View full size image]

By default , WRED drops packet s wit h lower I PP values sooner t han packet s wit h higher I PP
values. A sim plified illust rat ion of WRED operat ion is shown in Figure 6- 2 .

WRED can be configured as an int erface com m and, but it is recom m ended t hat it be configured
wit hin t he MQC synt ax because t his im proves granularit y, m odularit y, and m anageabilit y of t he
WRED algorit hm .

As previously not ed, WRED is dependent on queuing. Therefore, before WRED can be enabled on
a class of t raffic, a queuing opt ion ( usually eit her bandwidt h or fair- queue) m ust be enabled on
t he class. Exam ple 6- 1 shows an exam ple of a WRED configurat ion applied t o t he default t raffic
class.
Ex a m ple 6 - 1 . W RED Policy M a p

class class-default
fair-queue
random-detect enables WRED
DSCP-Based Weighted Random Early Detection
DSCP- based WRED was int roduced in Cisco I OS Soft ware Release 12.1( 5) T. DSCP- based WRED
configures t he WRED algorit hm t o use t he AF drop- preference values ( as defined in RFC 2597) of
a packet 's DSCP m arkings t o influence it s drop probabilit y as queues fill. Rem em ber t hat t he
second digit of an AF codepoint indicat es drop preference and can range from 1 ( lowest drop
preference) t o 3 ( highest drop preference) . For exam ple, if DSCP- based WRED is enabled on an
int erface, AF23 would be dropped m ore oft en ( st at ist ically) t han AF22, which, in t urn, would be
dropped m ore oft en ( st at ist ically) t han AF21.

Figure 6- 3 illust rat es a sim plified ( 3 PHB) exam ple of DSCP- based WRED.

Figu r e 6 - 3 . D SCP- Ba se d W RED for AF2 1 , AF2 2 , a n d AF2 3

[View full size image]

The default DSCP- based WRED configurat ion can be enabled using t he dscp- ba se d keyword of
t he r a n dom - de t e ct com m and, as shown in Exam ple 6- 2.

Ex a m ple 6 - 2 . D SCP- Ba se d W RED Policy M a p

class class-default
fair-queue
random-detect dscp-based enables (RFC 2597) DSCP-based WRED

As wit h WRED, DSCP- based WRED t hresholds and m ark probabilit y denom inat ors are t unable on
a per- codepoint basis. I n Exam ple 6- 3, t he m inim um t hreshold is set t o begin dropping AF11-
m arked packet s at 5 ( t hat is, as soon as t he queue dept h reaches five packet s, WRED will
random ly begin dropping AF11 packet s) . The m axim um t hreshold for AF11 ( at which all AF11-
m arked packet s will be dropped) is set t o 20 packet s in Exam ple 6- 3. The m ark probabilit y
denom inat or is set t o 8 ( m eaning t hat , bet ween t hese t wo t hresholds, up t o 1 in 8 packet s
m arked wit h AF11 will be dropped, and at t he m axim um t hreshold of 20, exact ly 1 in 8 packet s
will be droppedabove t he m axim um t hreshold of 20, all packet s m arked wit h AF11 will be
dr opped) .

Ex a m ple 6 - 3 . D SCP- Ba se d W RED Con figu r a t ion D r oppin g AF1 1 pa ck e t s

Router(config)#policy-map DSCP-WRED
Router(config-pmap)#class class-default
Router(config-pmap-c)#random-detect dscp af11 5 20 8
Explicit Congestion Notification
Tradit ionally, t he only way t o inform sending host s t hat t here was congest ion on t he net work so
t hat t he host s would slow t heir t ransm ission rat es was t o drop TCP packet s.

RFC 3168, however, defined a new and m ore efficient way for t he net work t o com m unicat e
congest ion t o sending host s: adding explicit congest ion not ificat ion ( ECN) t o I P. By m arking t he
final 2 bit s of t he ToS byt e of t he I P header, devices can com m unicat e t o each ot her and t o
endpoint s t hat t hey are experiencing congest ion. These t wo bit s have been defined as follows:

ECN - Ca pa ble Tr a n spor t ( ECT) bit This bit indicat es whet her t he device support s ECN.

Con ge st ion Ex pe r ie n ce d ( CE) bit This bit ( in conj unct ion wit h t he ECT bit ) indicat es
whet her congest ion was experienced en rout e.

Figure 6- 4 shows t he locat ion of t he ECN bit s in t he TOS byt e of an I P packet header.

Figu r e 6 - 4 . I P ToS Byt e ECN Bit s

During periods of congest ion, WRED ( and DSCP- based WRED) drops packet s when t he average
queue lengt h exceeds a specific t hreshold value. ECN is an ext ension t o WRED, in t hat ECN
m arks packet s inst ead of dropping t hem , t o com m unicat e t he exist ence of congest ion when t he
average queue lengt h exceeds a specific t hreshold value. Rout ers configured wit h t he WRED ECN
feat ure, int roduced in Cisco I OS Soft ware Release 12.2( 8) T, use t his m arking as a signal t hat t he
net work is congest ed. This way, TCP t ransm ission rat es can be cont rolled wit hout dropping
packet s, or at least wit h dropping far fewer packet s.

Table 6- 1 list s t he ECN bit com binat ions and t heir m eanings.

Ta ble 6 - 1 . ECN Bit Com bin a t ion s

 ECT Bit CE Bit Com bin a t ion I n dica t e s
0 0 Not ECN- capable

0 1 Endpoint s of t he t ransport prot ocol are ECN-

capable

1 0 Endpoint s of t he t ransport prot ocol are ECN-

capable
1 1 Congest ion experienced

The bit - set t ing com binat ions have t he following m eanings:

The ECN field com binat ion 00 indicat es t hat a packet is not using ECN.

The ECN field com binat ions 01 and 10, which are called ECT( 1) and ECT( 0) , respect ively,
are set by t he dat a sender t o indicat e t hat t he endpoint s of t he t ransport prot ocol are ECN-
capable. Rout ers t reat t hese t wo field com binat ions ident ically. Dat a senders can use eit her
or bot h of t hese com binat ions.

The ECN field com binat ion 11 indicat es congest ion t o t he endpoint s. Packet s arriving int o a
full queue of a rout er are dropped.

WRED ECN t akes t he following act ions, depending on t he ECN bit set t ings:

I f t he num ber of packet s in t he queue is below t he m inim um t hreshold, packet s are

t ransm it t ed. This happens whet her or not ECN is enabled. This t reat m ent is ident ical t o t he
t reat m ent t hat a packet receives when only WRED is being used on t he net work.

I f t he num ber of packet s in t he queue is bet ween t he m inim um t hreshold and t he

m axim um t hreshold, one of t he following t hree scenarios can occur:

- I f t he ECN field on t he packet indicat es t hat t he endpoint s are ECN- capable ( t hat is,
t he ECT bit is set t o 1 and t he CE bit is set t o 0, or t he ECT bit is set t o 0 and t he CE
bit is set t o 1) and t he WRED algorit hm det erm ines t hat t he packet should be
dropped based on t he drop probabilit y, t he ECT and CE bit s for t he packet are
changed t o 1 and t he packet is t ransm it t ed. This happens because ECN is enabled,
and t he packet get s m arked inst ead of dropped.

- I f t he ECN field on t he packet indicat es t hat neit her endpoint is ECN- capable ( t hat
is, t he ECT bit is set t o 0 and t he CE bit is set t o 0) , t he packet can be dropped based
on t he WRED drop probabilit y. This is t he ident ical t reat m ent t hat a packet receives
when WRED is enabled wit hout ECN configured on t he rout er.

- I f t he ECN field on t he packet indicat es t hat t he net work is experiencing congest ion
( t hat is, bot h t he ECT bit and t he CE bit are set t o 1) , t he packet is t ransm it t ed. No
furt her m arking is required.

I f t he num ber of packet s in t he queue is above t he m axim um t hreshold, all packet s are
dropped and t he drop probabilit y is 1. This is t he ident ical t reat m ent t hat a packet receives
when WRED is enabled wit hout ECN configured on t he rout er, and t he packet flow exceeds
it s m axim um t hreshold.
WRED ECN is enabled wit h t he e cn keyword on t he r a n dom - de t e ct com m and. W RED ECN
cannot be enabled by it self and m ust be used in conj unct ion wit h WRED or DSCP- based WRED
( as is shown in Exam ple 6- 4) .

Ex a m ple 6 - 4 . W RED - ECN Policy M a p Ex a m ple

Router#sh run
class class-default
fair-queue
random-detect dscp-based
random-detect ecn enables (RFC 3168) ECN-based WRED
Summary
Congest ion- avoidance t ools such as WRED variat ions and ECN were overviewed in t his chapt er.

WRED is used t o drop packet s random ly ( based on configured param et ers t hat cont rol t he drop
probabilit ies) from a TCP session in t he net work t o opt im ize bandwidt h ut ilizat ion of TCP t raffic.
The global synchronizat ion problem of unguarded TCP sessions was discussed, and t he chapt er
showed how WRED can be used t o com bat t his behavior.

ECN is a newer congest ion- avoidance t ool, and it s operat ion and configurat ion was discussed
briefly.
Further Reading
DiffServ Standards Relating to WRED

RFC 2597, " An Assured Forwarding PHB Group" : ht t p: / / www.iet f.org/ rfc/ rfc2597.t xt .

RFC 3168, " The Addit ion of Explicit Congest ion Not ificat ion ( ECN) t o I P" :
ht t p: / / www.iet f.org/ rfc/ rfc3168.t xt .

Cisco IOS WRED Documentation

MQC- based WRED ( Cisco I OS Soft ware Release 12.0.5T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 5/ cbwfq.ht m

DiffServ- com pliant Weight ed Random Early Det ect ion ( Cisco I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt dswred.ht m
.

Dist ribut ed class- based weight ed fair queuing and dist ribut ed Weight ed Random Early Det ect ion ( Cisco
I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt cbwred.ht m
.

WREDexplicit congest ion not ificat ion ( Cisco I OS Soft ware Release 12.2.8T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ ft wrdecn.ht m
.
Chapter 7. Link-Specific Tools
This chapt er discusses link- specific QoS t ools needed on links of a specific t ype such as Fram e
Relay or MLP, including t he following t opics:

RTP header com pression

Link Fragm ent at ion and I nt erleaving

Link- specific t ools refer t o m echanism s t hat are enabled in a point - t o- point m anner on bot h ends
of WAN links. These t ools com bine Layer 2 and Layer 3 feat ures in t heir funct ionalit y. This
chapt er covers t wo t ypes of link- specific t ools:

H e a de r - com pr e ssion t e ch n iqu e s These m echanism s can reduce bandwidt h

requirem ent s for bot h voice and dat a t raffic.

Lin k Fr a gm e n t a t ion a n d I n t e r le a vin g t ools These m echanism s m inim ize serializat ion
delays com m on t o slow- speed WAN links.

The link- specific t ools frequent ly are cat egorized as QoS t ools because t hey oft en are used in
conj unct ion wit h ot her QoS t echniques, as discussed in t his chapt er. However, bot h t ools have
applicat ion out side t he realm of QoS and were developed originally as generic Cisco I OS
Soft ware feat ures, not specifically as QoS t ools. This chapt er lim it s t he discussion t o how t hese
t echniques are applied t o im prove t he QoS of t he net work.

The first half of t his chapt er looks at header- com pression t echniques, which are a suit e of
feat ures t hat reduce t he size of t he I P packet header. For large dat a packet s, t he rat io of t he
header byt es t o t he payload byt es is usually not significant , and header com pression is seldom a
com pelling feat ure. But for short voice packet s, t he I P ( and UDP and RTP) headers can t riple t he
size of t he packet and, t herefore, t he bandwidt h required for a voice call. These ext ra byt es also
cont ribut e t o increased delay, so reducing t he size of t he header can provide significant savings.
Alt hough t he focus of t he following sect ions is on RTP header com pression, t hese sect ions also
exam ine dependencies t hat t his feat ure has on relat ed feat ures, such as TCP header
com pression.

The last half of t he chapt er explores Link Fragm ent at ion and I nt erleaving. On links of 768 kbps
or higher, t his t echnique has lit t le t o no value. However, on slow WAN links, t ransm it t ing a
1500- byt e dat a packet can t ake long enough t hat it incurs undue delay in a voice packet t hat
wait s behind it t o be t ransm it t ed. I n t hese sit uat ions, it m akes sense t o divide t he dat a packet
int o sm aller segm ent s so t hat a sm all voice packet can be int erleaved in bet ween t he segm ent s
of a large dat a packet . This bounds t he delay incurred on a voice packet .
Header-Compression Techniques
One of t he key drivers t o m any VoI P deploym ent s is t he financially at t ract ive bandwidt h savings
t hey deliver. For exam ple, a regular TDM voice call requires a fixed allocat ion of 64 kbps of
bandwidt h, whereas a com parable qualit y VoI P call can be reduced t o approxim at ely 12 kbps.
Two t ypes of com pression are perform ed on voice packet s t o achieve such bandwidt h
reduct ions:

Payload com pression, t hrough codecs such as G.729

Header com pression, t hrough feat ures such as RTP header com pression ( also known as
Com pressed RTP or cRTP )

G.729 voice com pression enables a 64- kbps TDM voice call t o be reduced t o 8 kbpsa savings of a
fact or of 8. The com pressed speech sam ples are carried in VoI P using RTP packet s wit h 20 byt es
of payload per packet ( by default ) . RTP header com pression ( cRTP) is a m et hod for m aking RTP
packet headers sm aller so t hat VoI P bandwidt h is used m ore efficient ly. cRTP com presses t he
40- byt e I P/ UDP/ RTP header of a VoI P packet down t o 2 t o 5 byt es per packet . This reduces t he
L3 bandwidt h required for a G.729 VoI P call t o less t han 12 kbps, as illust rat ed in Figure 7- 1 .

Figu r e 7 - 1 . RTP H e a de r Com pr e ssion ( cRTP)

[View full size image]

Related Standards
Header- com pression t echniques are described by several st andards. The first header-
com pression schem e was developed by Van Jacobson t o com press I P/ TCP headers over slow-
speed serial links. An im provem ent t o t his m et hod was offered by t he I P header com pression
( I PHC) schem e, wit h an RTP com pression ext ension designed t o handle any I P packet . The m ost
recent addit ion t o t he header- com pression port folio is robust header com pression ( ROHC) , which
is a schem e designed for unreliable, high- lat ency m obile links, in which bandwidt h is very scarce
and t he links are prone t o error ( cRTP over sat ellit e links, a Cisco I OS 12.3[ 2] T feat ure, is based
on t he ROHC com pression schem e) .

The various I ETF RFCs pert aining t o header- com pression t echniques are list ed here:

RFC 1 1 4 4 " Com presses TCP/ I P Headers for Low- Speed Serial Links"

RFC 2 5 0 7 " I P Header Com pression"

RFC 2 5 0 8 " Com pressing I P/ UDP/ RTP Headers for Low- Speed Serial Links"

RFC 2 5 0 9 " I P Header Com pression over PPP"

RFC 3 0 9 5 " Robust Header Com pression ( ROHC) "

This is t he fram ework and four profiles: RTP, UDP, ESP, and uncom pressed. There is also a
Fram e Relay st andard t hat describes t he use of cRTP on Fram e Relay PVCs: " FRF.20: Fram e
Relay I P Header Com pression I m plem ent at ion Agreem ent ." This st andard describes how I P
packet s com pressed by cRTP should be represent ed in t he Fram e Relay fram e t hat t ransport s
t hem .

TCP Header Compression

As t he nam e im plies, TCP header com pression ( cTCP) is a m et hod of com pressing t he headers of
TCP/ I P segm ent s. However, header com pression is m uch less advant ageous, in t erm s of t he
percent age of bandwidt h savings, on 1500- byt e dat a packet s t han cRTP is on sm all 20- byt e
voice packet s.

TCP header com pression was m ore relevant in t he era when hom e and rem ot e office connect ions
ranged from 9.6 t o 19.2 kbps. Alt hough such scenarios are rarely t he case t oday, it is im port ant
t o not e t hat t he RFCs st at e t hat TCP header com pression m ust be enabled aut om at ically
whenever cRTP is enabled. This is t he case wit h Cisco's im plem ent at ions of cRTP over PPP links.

RTP Header Compression

The capabilit y t o support cRTP t o gain bandwidt h savings for voice st ream s on slow links is of
param ount im port ance t o privat e and public VoI P net works. Therefore, cRTP is a key QoS
t echnique in converged net works wit h slow- speed edge links. Wit hout cRTP, VoI P service on links
slower t han about 128 kbps becom es unpract ical. Even wit h cRTP, care m ust be t aken in t he
net work design t hat accept able voice qualit y can be m aint ained.

cRTP has t he following QoS net work design im plicat ions:

I t changes t he packet header and, t herefore, m ust be decom pressed before rout ing can
t ake place. This m akes cRTP a hop- by- hop prot ocol, wit h decom pression and
 recom pression occurring in every rout ing node in which t he feat ure is enabled.

I t changes t he bandwidt h required for a voice call and, t herefore, affect s provisioning and
engineering of queuing, policing, shaping, and call adm ission cont rol policies.

I t is a com pression algorit hm and, t herefore, CPU int ensive. When cRTP is enabled on a
rout er, care m ust be t aken so t hat t he plat form has enough CPU power t o perform t his t ask
for t he m axim um num ber of calls t hat m ight t raverse it , and st ill have enough CPU for t he
ot her dat a t raffic and rout ing t asks t hat t he CPU m ust perform . Proof- of- concept t est ing for
cRTP- enabled configurat ions is st rongly encouraged.

The use of cRTP is dependent on t he underlying Layer 2 prot ocol.

Because cRTP essent ially suppresses t he Layer 3 and higher headers, it can be used only on
point - t o- point Layer 2 connect ions or links; it cannot be used on broadcast m edia such as
Et hernet and cable, where reading t he packet header is crit ical for t he dest inat ion node t o
recognize t hat it is t he int ended recipient of t he fram e. Alt hough t he RFCs describe t he act ual
algorit hm s t hat header com pression prot ocols use, t he prot ocols are not as m uch " com pression"
prot ocols as t hey are " suppression" prot ocols. For exam ple, cRTP works by keeping t he header
cont ext ( for exam ple, t he current values of all t he fields in t he header) in bot h t he sender and
receiver nodes' m em ory. Com pression is based on t he principle t hat few fields ( ot her t han
sequence num bers) in t he headers change in subsequent packet s t hat belong t o t he sam e flow.
cRTP sim ply om it s t he t ransm ission of header fields t hat have not changed, t ransm it t ing inst ead
a reference num ber or point er so t hat t he receiving node can index it s m em ory t o find t he act ual
values of header fields.

During a voice conversat ion, cRTP does not com press all packet s. When t he RTP st ream st art s
up, a few packet s have full headers unt il t he com pression cont ext s bet ween t he sender and
receiver are est ablished. Aft er t hat , all packet s should be com pressed. A full header in t he
m iddle of a conversat ion is very rare but could be t riggered by event s such as t hese:

An event change wit hin t he flow cannot be com m unicat ed in t he com pressed header.

One of t he sam ples is t oo large t o be encoded in t he com pressed header.

An error packet was received, forcing a resynchronizat ion of cont ext s. I t is im port ant t o
rem em ber t hat a few packet s at t he st art of t he flow always have full headers, and t he
occasional com m unicat ion of som e field changes also requires full packet s wit h headers.
Nonet heless, t he average cRTP st ream has a 2- t o 5- byt e header.

Compression Formats
The com pression form at s t hat cRTP uses have changed over t he years. To achieve backward
com pat ibilit y, t hese are im plem ent ed as different opt ions on t he int erface com m and, as follows:

ip rtp header-compression [passive | iphc-format | ietf-format] [periodic-refresh]

The pa ssive opt ion m eans t hat t he soft ware wait s unt il it receives a com pressed packet before
engaging header com pression on out going RTP packet s. This is a legacy com m and from t he
Serial Line I P ( SLI P) prot ocol and is used m ainly for dialer sit uat ions. PPP negot iat es t he use of
h e a de r - com pr e ssion regardless of whet her t he pa ssive opt ion is used.
 N ot e
The use of t he pa ssive keyword wit h PPP as t he underlying L2 prot ocol recent ly has
been disabled t o prevent confusion.

The I PHC and I ETF form at s are discussed in t he following sect ions. The pe r iodic- r e fr e sh opt ion
was int roduced in Cisco I OS 12.3( 2) T Soft ware as part of t he robust cRTP over sat ellit e links
feat ure. I t allows a full header t o be resent periodically ( configurable) t o ensure t hat
com pression cont inues t o funct ion over high- loss links.

Cisco Proprietary Format

The original form at of cRTP im plem ent at ion wit hin Cisco I OS was t he Cisco propriet ary version
t hat com presses packet s only recognized as RTP. RTP packet s are recognized by ensuring t hat
t he dest inat ion port num ber is even and wit hin t he range of 16385 t o 32767 ( for audio st ream s)
or 49152 t o 65535 ( for video st ream s) . The original form at of cRTP allows only up t o 256
cont ext s.

IP Header Compression Format

The I P header com pression ( I PHC) form at was t he init ial Cisco I OS im plem ent at ion of RFC 2507
and RFC 2508. RFC 2507 specifies t he form at for TCP and UDP com pression, and RFC 2508
specifies ext ensions t o RFC 2507specifically, t o com press RTP packet headers. I n I PHC form at
over PPP links, TCP and RTP com pression are inseparable, as described by RFC 2509, which
specifies t he PPP negot iat ion for header com pression. RFC 2509 st at es t hat on PPP, it is
im possible t o negot iat e one t ype of com pression ( cTCP or cRTP) wit hout t he ot her. Thus, when
enabling cRTP on a PPP int erface, cTCP also aut om at ically is enabled. RFC 2509bis (b is indicat es
a st andards updat e t o t he original RFC 2509) decouples cRTP from cTCP but is not yet ( fully)
im plem ent ed wit hin Cisco I OS.

However, use of class- based cRTP wit hin t he MQC const ruct can achieve t he decoupling of cTCP
and cRTP. This is discussed wit h addit ional det ails lat er in t his chapt er. I PHC form at com presses
all TCP and UDP packet s. Packet s t hat m at ch RTP crit eria are com pressed using t he com pressed
RTP form at , while ot her packet s are com pressed using t he com pressed non- TCP form at . The
com pressed UDP form at is used t o com press only RTP packet s t hat do not fit int o t he
com pressed RTP t em plat e. These form at s, and t he differences bet ween t hem , are discussed in
RFCs 2507 and 2508, as follows:

Com pr e sse d TCP The fram e cont ains a dat agram wit h a com pressed header wit h t he
form at specified in RFC 2507 Sect ion 6a.

Com pr e sse d TCP- N OD ELTA The fram e cont ains a dat agram wit h a com pressed header
wit h t he form at specified in RFC 2507 Sect ion 6b.

Com pr e sse d n on - TCP The fram e cont ains a dat agram wit h a com pressed header wit h t he
form at specified in eit her Sect ion 6c or Sect ion 6d of RFC 2507.

Com pr e sse d RTP- 8 The fram e cont ains a dat agram wit h a com pressed header wit h t he
form at specified in RFC 2508 Sect ion 3.3.2, using an 8- bit cont ext ident ifier.

Com pr e sse d RTP- 1 6 The fram e cont ains a dat agram wit h a com pressed header wit h t he
form at specified in RFC 2508 Sect ion 3.3.2, using a 16- bit cont ext ident ifier.
 Com pr e sse d UD P- 8 The fram e cont ains a dat agram wit h a com pressed header wit h t he
form at specified in RFC 2508 Sect ion 3.3.3, using an 8- bit cont ext ident ifier.

Com pr e sse d UD P- 1 6 The fram e cont ains a dat agram wit h a com pressed header wit h t he
form at specified in RFC 2508 Sect ion 3.3.3, using a 16- bit cont ext ident ifier.

IETF Format

The init ial Cisco I OS Soft ware im plem ent at ions of RFCs 2508 and 2509 were not in perfect
com pliance wit h t he st andards. I ETF form at , t he m ost recent ly int roduced opt ion ( Cisco I OS
12.3[ 2] T) for cRTP, at t em pt s t o address all of t hese incom pat ibilit ies and t o m at ch t he RFCs as
closely as possible. I n I ETF form at , as wit h I PHC form at , cTCP and cRTP are inseparable for PPP
links. All TCP and UDP packet s are com pressed, but only packet s recognized as RTP are
com pressed using t he m ore efficient com pressed RTP form at . However, t he rest rict ion of
recognizing only RTP st ream s on cert ain port ranges for com pression has been rem oved, and
cRTP uses any even port over 1024 when t he ie t f- for m a t keyword is used.

Layer 2 Encapsulation Protocol Support

The previous sect ions discussed t he st andards and form at s t hat govern cRTP in general. Anot her
dependency of cRTP is on t he specific L2 link and t he prot ocol encapsulat ion configured for t his
link.

The RFCs t end t o discuss only PPP links, yet cRTP is support ed over point - t o- point links wit h
HDLC, PPP, Fram e Relay, and ATM encapsulat ions. The im plem ent at ions over Fram e Relay and
HDLC are propriet ary, while t hose over PPP are st andards com pliant wit h t he RFCs discussed
previously. cRTP on ATM is support ed only via PPP or MLP over ATM ( PPPoA or MLPoATM,
respect ively) .

As m ent ioned earlier, cRTP cannot be support ed on broadcast Layer 2 m edia such as Et hernet or
cable. cRTP works only on point - t o- point connect ions in which t here is a single possible
dest inat ion for t he packet .

The following sect ions provide addit ional det ails about t he im plem ent at ion of cRTP on each of t he
link encapsulat ion t ypes where it is support ed.

HDLC

cRTP is im plem ent ed over HDLC links in it s propriet ary version; HDLC it self is a Cisco- propriet ary
prot ocol. Cisco form at com pression is t he default , yet I PHC form at also is support ed wit hin t he
CLI . Because t he cRTP im plem ent at ion over HDLC is propriet ary, cTCP and cRTP can be
cont rolled independent ly ( for inst ance, t he im plem ent at ion does not have t o conform t o RFC
2509) .On HDLC links, header com pression is configured on t he int erface using t hese com m ands:

ip tcp header-compression [passive | iphc-format | ietf-format]

ip rtp header-compression [passive | iphc-format | ietf-format]
ip tcp compression-connections [3-256]
ip rtp compression-connections [3-1000]

The first t wo com m ands t urn on cTCP and cRTP, respect ively, as discussed earlier. The
com pr e ssion - con n e ct ion s com m ands st at e t he m axim um num ber of cTCP or cRTP sessions
t hat are possible over t his link. I t is im port ant for t his num ber t o m at ch on bot h sides of t he link,
and it should be configured carefully because t his governs t he am ount of m em ory set aside t o
keep t he session cont ext s t o com press/ decom press t he headers. The default s and support ed
ranges have changed over t im e, so check t he Cisco I OS docum ent at ion for t he soft ware release
t hat you are running for t he correct values.

PPP

The default cRTP form at for PPP is I PHC form at . PPP negot iat es t he use of header com pression
regardless of whet her t he pa ssive opt ion is used ( addit ionally, t he use of pa ssive wit h PPP
recent ly has been disabled, t o prevent confusion) . For I PHC form at and I ETF form at , t urning on
eit her cTCP or cRTP aut om at ically also enables t he ot her t ype.

On PPP links, header com pression is configured at t he int erface using t he sam e com m ands as
given previously for HDLC.

ATM

cRTP is not support ed over nat ive ATM because no st andard describes such an im plem ent at ion.
However, a new feat ure in Cisco I OS 12.2( 2) T int roduced cRTP over ATM t hrough PPP over ATM
( PPPoATM) and MLP over ATM ( MLPoATM) . The init ial feat ure release applied t o general ATM
int erfaces; DSL int erface support for t his feat ure followed in Release 12.3( 2) T. cRTP over ATM is
configured t hrough PPP using a virt ual t em plat e. Virt ual t em plat es frequent ly are used wit h PPP
and MLP configurat ions. They provide a way t o specify a t em plat e configurat ion only once and
t hen apply t hat t em plat e t o m ult iple links, virt ual circuit s, or int erfaces. This sim plifies t he
m aint enance of t he configurat ion if t here are m any links wit h sim ilar charact erist ics.

Any of t he configurat ions given in Exam ple 7- 1 can be used for cRTP over ATM links.

Ex a m ple 7 - 1 . cRTP Con figu r a t ion for ATM Lin k s

Router#sh run
interface ATM6/1.1 point-to-point
pvc 0/50
encapsulation aal5mux ppp Virtual-Template1
or
interface ATM6/1.1 point-to-point
pvc 0/50
encapsulation aal5snap
protocol ppp Virtual-Template1
or
interface ATM6/1.1 point-to-point
pvc 0/50
encapsulation aal5ciscoppp Virtual-Template1
Coupled with:
!
interface Virtual-Template1
bandwidth 768
ip address 10.200.60.1 255.255.255.252
ip rtp header-compression [passive | iphc-format | ietf-format] [periodic-refresh]
The cRTP configurat ion ( t he highlight ed t ext in t he exam ple) is t he general cRTP com m and
discussed in an earlier sect ion. Here is it specified wit hin t he t em plat e Virt ual- Tem plat e1, which
is, in t urn, applied t o t he ATM PVCs in t he exam ple.

Frame Relay

cRTP has been support ed on Fram e Relay links since t he m id- 1990s because t his encapsulat ion
is used so frequent ly on slow- speed access links t o rem ot e offices. The use of cRTP on Fram e
Relay has only m ore recent ly been st andardized as FRF.20 ( June 2001) .

The im plem ent at ion of cRTP on Cisco Fram e Relay PVCs is current ly st ill propriet ary and will
rem ain so unt il Cisco im plem ent s FRF.20. The current im plem ent at ion is very close t o t he FRF.20
st andard but is not exact ly t he sam e. cRTP is not support ed on I ETF PVCs because t his support
will require FRF.20 com pliance. The fact t hat t his is current ly a propriet ary im plem ent at ion also
m eans t hat cTCP and cRTP can be cont rolled independent ly.

cRTP on PPP over Fram e Relay ( PPPoFR) and MLP over Fram e Relay ( MLPoFR) are st andards
com pliant ; t his is t he sam e as wit h t he PPP im plem ent at ions discussed earlier in t his chapt er.
Therefore, cRTP on PPPoFR is support ed on bot h Cisco and I ETF PVCs. I f a st andards- com pliant
im plem ent at ion of cRTP on Fram e Relay is required for a net work design, t his form of cRTP
should be used.

Alt hough t here are m any ways t o configure cRTP on Fram e Relay links, t he m ost com m on
m et hod is shown in Exam ple 7- 2 .

Ex a m ple 7 - 2 . Com m on cRTP Con figu r a t ion

Router#sh run
interface Serial 2/0
encapsulation frame-relay
!
interface Serial 2/0.100 point-to-point
encapsulation frame-relay
ip address 192.168.0.1 255.255.255.0
frame-relay interface-dlci 100
frame-relay ip rtp header-compression

The form at of t he cRTP com m and is different for Fram e Relay t han t he com m ands discussed
previously. The opt ions on t his com m and include only t he pa ssive and pe r iodic- r e fr e sh
param et ers. As discussed earlier, t he I ETF form at of cRTP does not apply t o Fram e Relay links.

Frame Relay and ATM Service Interworking

I f Fram e Relay- t o- ATM int erworking ( FRF.5 or FRF.8) is used in a net work and cRTP is required
as well, PPP m ust be used over t he ent ire link ( for exam ple, PPPoATM t o PPPoFR, or MLPoATM t o
MLPoFR) . cRTP is support ed over such int erworked links as of Cisco I OS Soft ware Release
12.2( 2) T.

Summary of cRTP Formats and Protocol Encapsulations

Table 7- 1 sum m arizes t he different form at s of cTCP and cRTP t hat can be used wit h different
Layer 2 link encapsulat ions. The t able also gives im port ant perform ance inform at ion in t he
Swit ching Pat h colum ns. As m ent ioned earlier, cRTP is CPU int ensive; if it is process- swit ched, it
is significant ly m ore so. cRTP was im plem ent ed in t he fast and CEF swit ching pat hs several years
ago, but for older releases of Cisco I OS Soft ware, it is im port ant t o check t hat t his is not
process- swit ched before t urning on t he feat ure. I f it is process- swit ched, upgrade t o a Cisco I OS
release in which cRTP is support ed in t he fast or CEF pat hs.

HDLC

Yes

Yes

Yes

12.3.2T

Yes

Yes

Yes

12.1.5T

PPP

Yes

Yes

12.3.2T

Yes

Yes

Yes

12.1.5T

MLPPP

Yes

Yes

12.3.2T

Yes

Yes

Yes
12.1.5T

Fram e Relay

Yes

Yes

Yes

Yes

Yes

12.1.5T

PPPoFR

Yes

Yes

12.3.2T

Yes

Yes

Yes

12.2.2T

MLPoFR

Yes

Yes

12.3.2T

Yes

Yes

Yes

12.2.2T

PPPoATM

Yes
Yes

12.3.2T

Yes

Yes

Yes

12.2.2T

MLPoATM

Yes

Yes

12.3.2T

Yes

Yes

Yes

12.2.2T

Ta ble 7 - 1 . cRTP For m a t a n d En ca psu la t ion Opt ion s

Com pr e ssion For m a t s Sw it ch in g Pa t h

TCP RTP I PH C I ETF

En ca psu la t ion Or igin a l Or igin a l For m a t For m a t Pr oce ss Fa st CEF dCEF

Class-Based Header Compression

I n Cisco I OS Soft ware Release 12.2( 13) T, cRTP was m ade available wit hin t he MQC synt ax,
allowing it t o be configured on a per- class basis. Class- based cRTP t hus im proves t he granularit y
of what t raffic is t o be com pressed, which is a feat ure oft en needed t o work around t he RFC
2509's requirem ent t hat cTCP and cRTP m ust be negot iat ed t oget her for PPP links. Furt herm ore,
class- based cRTP includes cRTP st at ist ics for out bound packet s wit hin t he out put of t he sh ow
policy- m a p in t e r fa ce com m and, t hus im proving it s m anageabilit y. Sam ple out put for t his
com m and is shown in Exam ple 7- 3 . For com pression st at ist ics on inbound packet s, t he sh ow ip
r t p h e a de r - com pr e ssion com m and can be used.

Ex a m ple 7 - 3 . cRTP St a t ist ics

 Router#show policy-map interface Serial 4/1
Serial4/1
Service-policy output:p1
Class-map:class-default (match-any)
1005 packets, 64320 bytes
30 second offered rate 16000 bps, drop rate 0 bps
Match:any
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

On RFC- com pliant soft ware, if cRTP is act ivat ed on a cert ain class of t raffic wit hin a service
policy, bot h cTCP and cRTP are applied for t he class of t raffic ( based on t he st andards discussed
previously in t his chapt er) . However, because TCP and RTP t raffic are separat ed out int o
different classes by t he classificat ion crit eria, usually no TCP t raffic is present in t he class where
cRTP is enabled. Conversely, t here is t ypically no RTP t raffic in a TCP t raffic class. Therefore,
cRTP effect ively can be decoupled from cTCP wit hin t he MQC synt ax st ruct ure. Such decoupling
of t he aut om at ic enabling of cTCP whenever cRTP is act ivat ed oft en is desired for t hese reasons:

Header- com pression rat ios on TCP t raffic are sm all, result ing in nom inal bandwidt h savings.

Com pression algorit hm s are CPU int ensive and should be enabled carefully t o provide t he
great est bandwidt h ret urns for t he increased CPU cost ( for exam ple, on VoI P, not dat a) .

Dat a t raffic is not real- t im e sensit ive, and header com pression does not provide significant
savings on packet s wit h large payloads. Therefore, cTCP provides negligible packet - t ransm ission
perform ance im provem ent s. The m at ch crit eria wit hin t he class m aps det erm ine what t raffic is
given t o t he com pressor. Decom pression, on t he ot her hand, is not cont rolled by class m aps;
cRTP decom presses all packet s t hat arrive com pressed from t he ot her side of t he link.

The default m ode for cRTP inside an MQC class is I PHC form at for all encapsulat ions t hat support
it , including ATM, PPP, and HDLC. For Fram e Relay links, in which I PHC form at is unavailable, t he
original ( Cisco propriet ary) form at is used as t he default . Exam ple 7- 4 shows a cRTP
configurat ion inside an MQC class.

Ex a m ple 7 - 4 . M QC- Ba se d cRTP Con figu r a t ion

Router#sh run
policy-map CB-CRTP
class VOIP
compression header ip rtp
priority 200
class class-default
fair-queue
I n a sim ilar m anner, com pr e ssion h e a de r ip t cp can be used for a dat a t raffic class.

The int erface configurat ion for enabling header com pression is m ut ually exclusive wit h class-
based cRTP. The I PHC form at and pa ssive opt ions are aut oconfigured based on t he int erface
encapsulat ion and do not appear as being configurable, as shown in Exam ple 7- 5 . The num ber
of concurrent connect ions also is aut oconfigured and calculat ed based on t he sum of t he
bandwidt hs allocat ed t o t he classes t hat have header com pression configured ( one connect ion
per 4 kbps of bandwidt h available) . This m ust be t he sam e on bot h ends of t he link.

Ex a m ple 7 - 5 . Cla ss- Ba se d cRTP Con figu r a t ion

Router(config-pmap-c)#compression header ip ?
rtp configure rtp header compression
tcp configure tcp header compression

Advanced Topics on cRTP

Several ot her Cisco I OS feat ures should be considered in conj unct ion wit h cRTP when designing
converged net works. These are discussed in t he following sect ions.

Tunnels

Alt hough cRTP is an act ion t hat works on Layer 3 headers and up, it can be viewed as a Layer 2
funct ion because it is applied t o t he packet j ust before it exit s t he egress int erface. Therefore,
when t unnel configurat ions ( for exam ple, GRE, MPLS, and I PSec) are used, cRTP ceases t o work.
( The feat ure can be configured, but t he packet s no longer are com pressed.) This is because cRTP
sees t he packet j ust before it is t ransm it t ed on t he egress int erface, aft er t he t unnel I P headers
have been applied. The cRTP com pressor no longer can recognize t he encapsulat ed packet as an
RTP packet and, t hus, does not com press it .

RSVP

RSVP is a Layer 3 bandwidt h- reservat ion prot ocol and generally act s on t he Layer 3 packet size
and bandwidt h requirem ent s. Therefore, if cRTP is used on a specific voice st ream and RSVP is
used t o provide t he call adm ission cont rol for t hat sam e st ream , an over- reservat ion of
bandwidt h will be m ade for t he call because, unt il recent ly, RSVP did not t ake t he bandwidt h
savings afforded by cRTP int o account in it s reservat ions.

As of Cisco I OS Soft ware Release 12.2( 15) T, a feedback m echanism bet ween cRTP and RSVP
has been im plem ent ed so t hat RSVP is cognizant of cRTP and adj ust s it s reservat ions
appropriat ely.

RSVP and call adm ission cont rol t echnologies are covered in Chapt er 8 , " Bandwidt h
Reservat ion," and Chapt er 9 , " Call Adm ission Cont rol ( CAC) ."

LLQ, Policing, and Shaping

LLQ, class- based shaping, and class- based ( egress ) policing all t ake header com pression int o
account as of Cisco I OS Soft ware Release 12.2( 2) T. This m eans t hat class bandwidt h can be
configured based on com pressed packet s. However, keep in m ind t hat decom pression occurs on
ingress, before any of t he input QoS feat ures are act ivat ed. Therefore, any ingress policing
policies are applied against uncom pressed packet s; bandwidt h policing lim it s should be fact ored
accordingly.

Hardware Compression

cRTP is support ed only on Cisco PVCs, not on I ETF PVCs ( unless PPPoFR/ MLPoFR is used) . Unt il
Cisco I OS Soft ware Release 12.1( 5) T, Fram e Relay hardware com pression ( FRF.9) was
support ed on only I ETF PVCs, m aking it difficult t o use t he opt im al com pression for all t raffic,
which is FRF.9 STAC ( STAC is t he nam e of t he com pany t hat first wrot e t he algorit hm ) for dat a
t raffic and cRTP for voice. As of 12.1( 5) T, FRF.9 hardware com pression also is allowed on Cisco
PVCs. Under such a configurat ion, voice t raffic bypasses t he STAC com pressor and is
com pressed by a com binat ion of cRTP and t he codec, providing bet t er com pression rat ios for
voice t raffic t han STAC com pression would.

Performance

Com pression t echniques, such as cRTP, m inim ize bandwidt h requirem ent s and are highly useful
on slow- speed links. Because of t he addit ional CPU loads t hese com pression t echniques require,
t hey need t o be used wit h caut ion, especially on WAN aggregat ion rout ers t hat at t ach t o m any
rem ot e sit es.

I n Cisco I OS 12.0, 12.0T, and 12.1 Soft ware, cRTP was process- swit ched, which rendered it
pract ically unusable for real net works. I n several Cisco I OS releases, bet ween 12.0( 7) T and
12.1( 2) T, cRTP was im plem ent ed in t he fast and Cisco Express Forwarding ( CEF) pat hs, which
dram at ically im proved it s scalabilit y. Nonet heless, cRTP rem ains one of t he m ost CPU- int ensive
QoS feat ures and should be enabled wit h a careful eye on CPU levels, especially on large- scale
WAN aggregat ion rout ers.

Perform ance is affect ed posit ively by t he support of class- based cRTP because t he t raffic t hat is
com pressed now can be filt ered m ore granularly t han before. Furt herm ore, wit h class- based
cRTP, cTCP use can be avoided, furt her im proving processing efficiency.

When t he CPU of t he node- com pressing RTP t raffic runs at reasonable levels ( for inst ance, t he
t arget 70 percent ) , cRTP does not im pact delay or voice qualit y in any adverse m anner.
Link Fragmentation and Interleaving
A problem wit h slow- speed WAN circuit s, wit h respect t o voice, is t hat large dat a packet s t ake an
excessively long t im e t o be t ransm it t ed ont o t he wire. This delay is referred t o as serializat ion
delay, and it easily can cause a VoI P packet t o exceed it s delay or j it t er t olerance. Two m ain
t ools can be used t o m it igat e serializat ion delay on slow links: Mult ilink PPP Link- Fragm ent at ion
and I nt erleaving ( MLP LFI ) and Fram e Relay Fragm ent at ion and I nt erleaving ( FRF.12) .

I n t he cont ext of link- efficiency m echanism s, slow- speed links are defined as WAN links wit h
clock speeds of 768 kbps or less. To offset link- specific delays, larger dat a packet s can be
fragm ent ed and sm aller voice packet s can be int erleaved wit h t he fragm ent s, as shown in Figure
7 - 2. This helps reduce t he variat ion in delay caused by a periodic dat a packet t hat arrives at t he
egress int erface j ust before a voice packet does and, t herefore, has st art ed t ransm ission
already, causing t he voice packet s t o have t o wait unt il t he int erface becom es free before being
t ransm it t ed it self. Sophist icat ed queuing t echniques such as LLQ do not help for t his problem
because t his is t he result of serializat ion delay or t he elapsed t im e t hat it t akes t o t ransm it a
packet on t he int erface. Any subsequent packet m ust wait for t he int erface t o becom e free
before st art ing it s own t ransm ission.

Figu r e 7 - 2 . LFI Ope r a t ion on Slow - Spe e d Lin k s

LFI t ools work at Layer 2 and operat e on packet s t hat already have exit ed t he Layer 3 queuing
subsyst em ( LLQ/ CBWFQ) . As m ent ioned in Chapt er 5, " Congest ion- Managem ent Tools," on PPP
links, only packet s t hat are not assigned t o t he PQ of LLQ are fragm ent ed. This present s an
im port ant const raint when provisioning for voice and int eract ive video on slow- speed links:
Because large video packet s assigned t o t he PQ of t he LLQ algorit hm are not fragm ent ed and
easily could dest roy voice qualit y, it is not recom m ended t o provision bot h voice and int eract ive
video t hrough LLQs on slow- speed links ( for inst ance, t hose less t han 768 kbps) .
Table 7- 2 shows t he serializat ion delays of various packet sizes on different link speeds.

Ta ble 7 - 2 . Se r ia liza t ion D e la y by Pa ck e t Size a n d Lin k Spe e d

64 128 256 512

1 Byt e Byt e s Byt e s Byt e s Byt e s 1 0 2 4 Byt e s 1 5 0 0 Byt e s

5 6 k bps 143 m s 9 ms 18 m s 36 m s 72 m s 144 m s 214 m s

6 4 k bps 125 m s 8 ms 16 m s 32 m s 64 m s 128 m s 187 m s

1 2 8 k bps 62.5 m s 4 ms 8 ms 16 m s 32 m s 64 m s 93 m s
2 5 6 k bps 31 m s 2 ms 4 ms 8 ms 16 m s 32 m s 46 m s

5 1 2 k bps 15.5 m s 1 ms 2 ms 4 ms 8 ms 16 m s 23 m s

7 6 8 k bps 10 m s 640 m s 1.28 m s 2.56 m s 5.1 m s 10.2 m s 15 m s

1 5 3 6 k bps 5 m s 320 m s 640 m s 1.28 m s 2.56 m s 5.12 m s 7.5 m s

Alt hough m axim um t ransm ission unit ( MTU) size const raint s t heoret ically can be used t o achieve
t he sam e purpose as LFI , t his is seldom pract ical because MTU size set t ings affect Layer 3
packet s and are t herefore visible t o t he end syst em s. Many end- user server and deskt op
applicat ions do not handle MTU size changes elegant ly, and even if t hey do, it is im pract ical t o
change t he MTU size on all t he servers and user applicat ions in t he net work.

Layer 2 LFI m echanism s are t ransparent t o t he Layer 3 I P applicat ions, perform ing LFI wit hin t he
net work infrast ruct ure only where necessary. Layer 3 packet s are reassem bled at t he Layer 2
m edia edges ( requiring LFI ) , and end syst em s see norm al 1500- byt e I P packet s.

Fragment Sizes
As a general guideline, a per- hop serializat ion delay t arget wit hin t he ent erprise is sm aller t han
or equal t o 10 m s. Wit hin an SP cont ext , t his t arget m ight be even t ight er.

The following form ula can be used t o det erm ine t he m axim um fragm ent size ( in byt es) for a
given j it t er t arget and link speed:

Fragm ent Size = ( Maxim um Allowed Jit t er in m illiseconds [ t ypically 10 m s] ) * ( Link Speed
in kbps) / 8

Alt ernat ively, Table 7- 3 shows t he recom m ended fragm ent sizes t o achieve a 10- m s m axim um
serializat ion delay for different speed links.

Ta ble 7 - 3 . M a x im u m Fr a gm e n t Size s for 1 0 - m s

Se r ia liza t ion D e la ys
 Re a l- Tim e Pa ck e t I n t e r va l
10 ms

5 6 k bps 70 byt es

6 4 k bps 80 byt es

1 2 8 k bps 160 byt es

2 5 6 k bps 320 byt es

Lin k
or 5 1 2 k bps 640 byt es
Vir t u a l 7 6 8 k bps 960 byt es
Cir cu it
Spe e d 1 5 3 6 k bps 1920 byt es[ * ]

[*] Enabling LFI is superfluous whenever the resulting fragment sizes exceed the MTU of Ethernet (1500 bytes).

The 768- kbps value t o det erm ine when LFI t ools are required on a link is derived from t he
preceding form ula. However, all result ing fragm ent sizes t hat are larger t han t he MTU of
Et hernet ( 1500 byt es) are shaded in Table 7- 3, indicat ing t hat no explicit LFI t ool is needed t o
achieve t he 10- m s serializat ion delay t arget in t he given scenario.

Multilink PPP LFI

Mult ilink PPP Link Fragm ent at ion and I nt erleaving ( MLP LFI ) is a very flexible LFI schem e t hat
can be applied over a single leased line or m ult iple leased lines, MLP Bundles, I SDN, Fram e
Relay circuit s ( t hrough MLPoFR) , ATM PVCs ( t hrough MLPoATM) , and ATM- t o- Fram e Relay
Service I nt erworking ( t hrough MLPoFR t o MLPoATM SI W) .

When configuring MLP LFI , t he only param et er needed is t he m axim um serializat ion delay in
m illiseconds, which is recom m ended t o be set t o 10 m s. The soft ware aut om at ically calculat es
t he fragm ent sizes. A sam ple MLP LFI configurat ion is shown in Exam ple 7- 6.

Ex a m ple 7 - 6 . M LP LFI Con figu r a t ion

Router#sh run
interface Multilink1
description 768kbps Leased-Line to RBR-3745-Left
ip address 10.1.112.1 255.255.255.252
ppp multilink
ppp multilink fragment delay 10
ppp multilink interleave
ppp multilink group 1
!
...
!
interface Serial1/0
bandwidth 786
no ip address
encapsulation ppp
 load-interval 30
ppp multilink
ppp multilink group 1
!

Multiclass Multilink PPP

A lim it at ion of t he original im plem ent at ion of MLP was t hat only fragm ent s would receive an MLP
header ( packet s t hat were sm aller t han t he fragm ent size would be encapsulat ed in a PPP
header) . Because PPP had no sequencing or reordering capabilit ies, t his present ed reordering
lim it at ions when cRTP ( which depends on com pressed packet s arriving in order) was used in
conj unct ion wit h MLP bundles over m ult iple lines, including I SDN. This issue was fixed in Cisco
I OS Soft ware Release 12.2( 13) T wit h t he int roduct ion of t he Mult iclass Mult ilink PPP feat ure
( MCMP) . MCMP encapsulat es bot h fragm ent s and sm aller packet s wit h ( sequenced) MLP headers
and reassem bles all packet s in order before decom pression. An exam ple MCMP configurat ion for
an I SDN int erface is shown in Exam ple 7- 7.

Ex a m ple 7 - 7 . M CM P Con figu r a t ion for a n I SD N I n t e r fa ce

Router#sh run
interface BRI0/0
encapsulation ppp
dialer pool-member 1
!
interface Dialer1
encapsulation ppp
dialer pool 1
dialer remote-name routerB-dialer1
dialer-group 1
dialer string 12345678
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
ppp multilink links minimum 2
ppp multilink multiclass

The ppp m u lt ilin k fr a gm e n t - de la y 1 0 com m and inst ruct s t he Cisco I OS Soft ware t o fragm ent
so t hat no m ore t han 10- m s delay result s. The soft ware calculat es t he appropriat e fragm ent size
( in byt es) aut om at ically. I t is im port ant t o add t he ppp m u lt ilin k in t e r le a ve st at em ent as well.
Alt hough t his is a separat e com m and, doing fragm ent at ion wit hout t urning on int erleaving has
no QoS benefit . Bot h feat ures m ust be t urned on t o achieve t he desired operat ion.

Frame-Relay Fragmentation
Fram e- Relay fragm ent at ion, which is defined as FRF.12 for VoI P, operat es in a m anner very
sim ilar t o t hat of MLP LFI . One im port ant except ion, however, is t hat t he configurat ion of FRF.12
requires t he m axim um fragm ent size t o be calculat ed beforehand and supplied as a param et er
t o t he com m and.

The following sect ions discuss several t opics t hat are im port ant t o keep in m ind when
configuring fragm ent at ion:

Which PVCs t o fragm ent

Which configurat ion governs t hat rat e t hat should be used t o det erm ine fragm ent size

The differences bet ween FRF.11 and FRF.12 fragm ent at ion

Which PVCs to Fragment

The purpose of LFI is t o break up dat a fram es t hat share t he sam e t ransm ission int erface as
voice packet s. I f a PVC carries only voice t raffic, t here is no benefit t o t urning on eit her queuing
or LFI . However, if ot her PVCs t hat share t he sam e physical egress int erface carry dat a t raffic,
t hese PVCs should be fragm ent ed. This is because t raffic from all t he PVCs com es t oget her at
t he physical int erface level, and dat a t raffic from one PVC could int erfere wit h t he delay of a
voice packet from anot her PVC. Also, as discussed in Chapt er 5, enabling FRF.12 aut om at ically
engages t he L2 Dual- FI FO Fram e Relay int erface queuing subsyst em on t he low- end rout er
plat form s.

Enabling FRF.12 on a Fram e Relay PVC requires t he configurat ion of a m ap class t hat is bound t o
t he DLCI . A sam ple is shown in Exam ple 7- 8.

Ex a m ple 7 - 8 . FRF.1 2 LFI Con figu r a t ion

Router# sh run
interface Serial2/0
no ip address
encapsulation frame-relay
!
interface Serial2/0.12 point-to-point
ip address 10.1.121.1 255.255.255.252
description 768kbps FR Circuit to RBR-3745-Left
frame-relay interface-dlci 102
class FR-MAP-CLASS-768
!
...
!
map-class frame-relay FR-MAP-CLASS-768
frame-relay fragment 960

Unlike t he fragm ent at ion com m and for PPP t hat was discussed in an earlier sect ion, t he fr a m e -
r e la y com m and expect s a byt e count as t he argum ent , given as 960 byt es in Exam ple 7- 8.
Therefore, it is up t o t he syst em adm inist rat or t o calculat e t he appropriat e fragm ent lengt h t o
achieve a delay t hat does not exceed 10 m s. Use t he inform at ion given in Table 7- 3 for t his
calculat ion. Also, on Fram e Relay links, t he fr a m e - r e la y fr a gm e n t com m and aut om at ically
enables bot h fragm ent at ion and int erleaving; no separat e com m and for int erleaving is
necessary.
I n older Cisco I OS releases, fragm ent at ion m ust be t urned on explicit ly for each individual PVC,
so it is up t o t he syst em s adm inist rat or t o ensure t hat all PVCs t hat share t he int erface are
fragm ent ed ( when necessary, as dict at ed by t he speed of t he PVC) . I n Cisco I OS Soft ware
Release 12.2( 13) T, a m ore convenient feat ure was int roduced t hat allows CLI at t he Fram e Relay
int erface level t o aut om at ically fragm ent all PVCs on t hat int erface. A configurat ion of physical
int erface- level fragm ent at ion is shown in Exam ple 7- 9.

Ex a m ple 7 - 9 . I n t e r fa ce - Le ve l Fr a gm e n t a t ion

Router#sh run
interface serial 0/0
encapsulate frame-relay
frame-relay fragment 960

N ot e
For ATM, only t he PVC t hat carries com bined voice and dat a t raffic on t he sam e VC
needs t o be fragm ent ed. ATM inherent ly int erleaves cells from different PVCs,
regardless of what payload t hey cont ain.

The Rate That Governs Fragmentation

Alt hough link speed is used as t he short hand t erm for det erm ining t he t hreshold for LFI , t he
shaping rat e ( CI R) of a Fram e Relay PVC, not t he physical port speed, really det erm ines t he
fragm ent at ion requirem ent . For exam ple, a 64- kbps PVC on a physical T1 link requires large
dat a packet s be fragm ent ed t o 80 byt es t o m eet t he 10- m s delay t arget . This is because t he
shaper, not t he clock rat e of t he physical int erface, det erm ines how long a packet will be held up
in t he queues before t ransm ission can occur on t he egress int erface.

FRF.11.1 and FRF.12 Fragmentation

For net works t hat are m igrat ing from VoFR t o VoI P, it m ust be kept in m ind t hat Fram e Relay LFI
act ually is covered by t wo different st andards:

FRF.11.1 Annex- C ( VoFR)

FRF.12 ( VoI P)

A com m on m isconcept ion holds t hat FRF.12 fragm ent at ion is used t o support Voice over Fram e
Relay ( VoFR) , and t here is a general unawareness t hat FRF.11 also specifies a fragm ent at ion
schem e. This causes som e m isunderst andings about fragm ent at ion for VoFR and VoI PoFR
regarding when and how t hese t wo voice t echnologies can be used in t he sam e net work:
 FRF.1 1 a n d FRF.1 2 ca n r u n on t h e sa m e PVC This is not t rue. PVC runs eit her FRF.11
or FRF.12, never bot h. They are m ut ually exclusive.

- I f t he PVC is configured for VoFR, it uses FRF.11. I f fragm ent at ion is t urned on for
t his PVC, it uses FRF.11 Annex- C ( or t he Cisco derivat ive of t his) for t he
fragm ent at ion headers.

- I f t he PVC is not configured for VoFR, it uses FRF.3.1 dat a encapsulat ion. I f
fragm ent at ion is t urned on for t his PVC, it uses FRF.12 for t he fragm ent at ion
headers. Because VoI P is a Layer 3 t echnology, which is t ransparent t o Layer 2
Fram e Relay, PVCs carrying VoI P use FRF.12 fragm ent at ion.

FRF.1 2 is u se d for VoFR This is part ly t rue. FRF.12 predom inant ly is used for VoI P.
FRF.12 in a VoFR configurat ion is used only t o fragm ent dat a PVCs t hat share an int erface
wit h a VoFR PVC. FRF.12 never is used on a VoFR PVC it self.

The fragm ent at ion schem e/ st andard being used does not m at t er from a CLI point of view. I n all
cases, t he m ap class com m and fr a m e - r e la y fr a gm e n t x x x is used. The soft ware aut om at ically
uses t he appropriat e fragm ent header t ype, based on how t he DLCI is configured. However, t he
fragm ent at ion schem e/ st andard being used does m at t er t o t he voice net work design:

vofr PVCs will not int erwork wit h vofr cisco PVCs.

VoI P and VoFR cannot be support ed on t he sam e PVC if t he speed is such t hat
fragm ent at ion is required. ( VoFR will be fine, but VoI P voice qualit y will be im paired
because VoI P packet s cannot be int erleaved bet ween fragm ent s of large dat a packet s.)

VoI P and VoFR can be support ed on different PVCs on t he sam e int erface when
fragm ent at ion is required.

FRF.12 ( VoI P) fragm ent s voice packet s if t he fragm ent at ion size is set sm aller t han t he voice
packet size; FRF.11 Annex- C ( VoFR) does not fragm ent voice, no m at t er what fragm ent at ion size
is configured.

LFI for Frame Relay/ATM Service Interworking

Fram e Relay and ATM net works can be int erworked in t wo ways:

FRF.5: net work int erworking

FRF.8: service int erworking

Essent ially, FRF.5 is a t unneling prot ocol, encapsulat ing an int act Fram e Relay fram e int o ATM
cells and producing an unchanged Fram e Relay fram e again on t he far side of t he net work.
FRF.8, on t he ot her hand, is a t rue conversion of t he payload of t he Fram e Relay fram e int o t he
payload of an ATM cell, and it delivers ATM on t he far side of t he net work.

Alt hough FRF.5 is not widely used, it can support FRF.12 because t he Fram e Relay fram e never
is changed or dist urbed; it m erely is encapsulat ed or t unneled across ATM.

Wit h FRF.8 int erworking, a m uch m ore com m on m et hod in backbone net works, FRF.12 cannot
be used because t here is no m eans of convert ing t hat t o an equivalent ATM schem e. The only
way t hat LFI can be support ed end- t o- end on Fram e Relay/ ATM net works using FRF.8 is t o use
MLPoFR and MLPoATM and t o use MLP LFI over bot h segm ent s of t he net work.

FRF.8 service int erworking is a Fram e Relay Forum st andard for connect ing Fram e Relay
net works wit h ATM net works. Service int erworking provides a st andards- based solut ion for
service providers, ent erprises, and end users. I n service int erworking t ranslat ion m ode, Fram e
Relay PVCs are m apped t o ATM PVCs wit hout t he need for sym m et ric t opologies; t he pat hs can
t erm inat e on t he ATM side. FRF.8 support s t wo m odes of operat ion of t he int erworking funct ion
for upper- layer user prot ocol encapsulat ion:

Tr a n sla t ion m ode Maps bet ween ATM and Fram e Relay encapsulat ion. I t also support s
t he int erworking of rout ed or bridged prot ocols.

Tr a n spa r e n t m ode Does not m ap encapsulat ions, but sends t hem unalt ered. This m ode is
used when t ranslat ion is im pract ical because encapsulat ion m et hods do not conform t o t he
support ed st andards for service int erworking.

MLP for LFI on ATM and Fram e Relay service int erworking net works is support ed for t ransparent -
m ode VCs and t ranslat ional- m ode VCs t hat support PPP t ranslat ion ( FRF 8.1) .

To m ake MLPoFR and MLPoATM int erworking possible, t he int erworking swit ch m ust be
configured in t ransparent m ode, and t he end rout ers m ust be capable of recognizing bot h
MLPoFR and MLPoATM headers. This is enabled wit h t he fr a m e - r e la y in t e r fa ce - dlci dlci ppp
and pr ot ocol ppp com m ands for Fram e Relay and ATM, respect ively.

When a fram e is sent from t he Fram e Relay side of a connect ion from ATM t o Fram e Relay
service int erworking, t he following should happen t o m ake int erworking possible:

The sending rout er encapsulat es a packet in t he MLPoFR header.

I n t ransparent m ode, t he carrier swit ch st rips off t he 2- byt e Fram e Relay DLCI field and
sends t he rest of t he packet t o it s ATM int erface.

The receiving rout er exam ines t he header of t he received packet . I f t he first 2 byt es of t he
received packet are 0x03cf, it t reat s it as a legal MLPoATM packet and sends it t o t he MLP
layer for furt her processing.

When an ATM cell is sent from t he ATM side of an ATM t o t he Fram e Relay service int erworking
connect ion, t he following should happen t o m ake int erworking possible:

The sending rout er encapsulat es a packet in t he MLPoATM header.

I n t ransparent m ode, t he carrier swit ch prepends t he 2- byt e Fram e Relay DLCI field t o t he
received packet and sends t he packet t o it s Fram e Relay int erface.

The receiving rout er exam ines t he header of t he received packet . I f t he first 4 byt es aft er
t he 2- byt e DLCI field of t he received packet are 0xfefe03cf, it t reat s it as a legal MLPoFR
packet and sends it t o t he MLP layer for furt her processing.

A new st andard for ATM t o Fram e Relay service int erworking, FRF.8.1, support s MLP over ATM
and Fram e Relay service int erworking, but it can be years before all swit ches are updat ed t o t he
new st andard.

IPSec Prefragmentation
A feat ure called prefragm ent at ion for I PSec VPNs was int roduced in Cisco I OS Soft ware Release
12.2( 13) T. This oft en m ist akenly is t hought t o be an LFI feat ure, but , st rict ly speaking, it is not .
I t does not do LFI , as discussed in t his chapt er, and it s purpose is not t o cont ain delay of high-
priorit y packet s held up behind lower- priorit y packet s on slow- speed links.

The prefragm ent at ion for I PSec VPNs feat ure breaks up dat a packet s int o t wo segm ent s. This is
done because a 1500- byt e I P packet exceeds t he 1500- byt e MTU size of t he net work when I PSec
headers are added ont o it , and packet s exceeding t he MTU size t ypically are dropped. This can
be fixed by set t ing t he applicat ion MTU size t o 1400 byt es ( or less) . However, as explained
earlier, changing MTU sizes in a net work is cum bersom e, at best , and generally difficult t o
m anage. Therefore, t his feat ure was developed t o aut om at ically segm ent I PSec fram es of m ore
t han 1500 byt es int o t wo so t hat MTU sizes do not need t o be adj ust ed on t he end- host
applicat ions t o be usable over an I PSec VPN.

As m ent ioned before, t his feat ure is not t o be considered a QoS m echanism for serializat ion
reduct ion and t uning purposes. A sim ilar feat ure for cable/ DSL links ( t ypically a voice VPN) ,
called adj ust ed m axim um segm ent size, can be t urned on wit h t he com m and ip t cp a dj u st -
m ss. I t is recom m ended t hat t his be configured t o 542 on bot h t he out side and inside int erfaces
of a cable or DSL device.
Summary
This chapt er covered t he link- specific t ools header com pression ( cRTP) and Link Fragm ent at ion
and I nt erleaving ( LFI ) . The form er t ypically is used t o cont ain bandwidt h use on low- speed links,
while t he lat t er is used t o segm ent large dat a packet s so t hat a sm all voice packet does not have
t o wait excessively long for t he int erface t o free up.

The different st andards governing header com pression were discussed, along wit h t he
dependencies am ong t he various m echanism s and t he com m ands t o t urn on t he feat ure for
different t ypes of link encapsulat ions.

The last half of t he chapt er discussed LFI m echanism s for Fram e Relay, PPP, and ATM links. I t
also covered how t o apply LFI for net works in which bot h Fram e Relay and ATM exist and how
t ranslat ions bet ween t he t wo are done by a carrier net work.
Further Reading
General

Configuring broadband access: PPP and rout ed bridge encapsulat ion configuring PPP over ATM:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fwan_c/ wcfppp.ht m

Enhanced voice and QoS for ADSL and G.SHDSL ( 12.3.2T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios123/ 123newft / 123t / 123t _2/ gt evqos.ht m
.

IETF Standards

RFC 1141, " I ncrem ent al Updat ing of t he I nt ernet Checksum " : ht t p: / / wwwin-
eng.cisco.com / RFC/ RFC/ rfc1141.t xt .

RFC 1624, " Com put at ion of t he I nt ernet Checksum via I ncrem ent al Updat e" : ht t p: / / wwwin-
eng.cisco.com / RFC/ RFC/ rfc1624.t xt .

RFC 1144, " Com pressing TCP/ I P Headers for Low- Speed Serial Links" : ht t p: / / wwwin-
eng.cisco.com / RFC/ RFC/ rfc1144.t xt .

RFC 2507, " I P Header Com pression" : ht t p: / / wwwin- eng.cisco.com / RFC/ RFC/ rfc2507.t xt .

RFC 2508, " Com pressing I P/ UDP/ RTP Headers for Low- Speed Serial Links" : ht t p: / / wwwin-
eng.cisco.com / RFC/ RFC/ rfc2508.t xt .

RFC 1889, " RTP: A Transport Prot ocol for Real- Tim e Applicat ions" : ht t p: / / wwwin-
eng.cisco.com / RFC/ RFC/ rfc1889.t xt .

RFC 2509, " I P Header Com pression over PPP" : ht t p: / / wwwin-

eng.cisco.com / RFC/ RFC/ rfc2509.t xt .

RFC 3095, " Robust Header Com pression ( ROHC) : Fram ework and Four Profiles: RTP, UDP,
ESP, and Uncom pressed" : ht t p: / / wwwin- eng.cisco.com / RFC/ RFC/ rfc3095.t xt .

Frame Relay Forum Standards

Fram e Relay/ ATM PVC Net work I nt erworking I m plem ent at ion Agreem ent FRF.5:
ht t p: / / www.frforum .com / 5000/ Approved/ FRF.5/ frf.5.pdf .

Fram e Relay/ ATM PVC Service I nt erworking I m plem ent at ion Agreem ent , FRF.8.1:
ht t p: / / www.frforum .com / 5000/ Approved/ FRF.8/ FRF.8.1.pdf .

Dat a Com pression over Fram e Relay I m plem ent at ion Agreem ent , FRF.9:
ht t p: / / www.frforum .com / 5000/ Approved/ FRF.9/ frf9.pdf .
 Voice over Fram e Relay I m plem ent at ion Agreem ent , FRF.11:
ht t p: / / www.frforum .com / 5000/ Approved/ FRF.11/ frf_11.1.pdf .

Fram e Relay Fragm ent at ion I m plem ent at ion Agreem ent FRF.12:
ht t p: / / www.frforum .com / 5000/ Approved/ FRF.12/ frf12.pdf .

Fram e Relay I P Header Com pression I m plem ent at ion Agreem ent , FRF.20:
ht t p: / / www.frforum .com / 5000/ Approved/ FRF.20/ FRF.20.pdf .

Header Compression

Express RTP and TCP header com pression ( Cisco I OS Soft ware Release 12.0.7T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 7/ rt pfast .ht m

Fram e Relay header com pression com pat ibilit y enhancem ent s ( Cisco I OS Soft ware Release 12.1.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 2/ dt frhccc.ht m

Dist ribut ed Com pressed Real- Tim e Transport Prot ocol ( Cisco I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt dcrt p.ht m

I P RTP coa le sce com m and ( Cisco I OS Soft ware Release 12.2.11T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 11/ ft iprt pc.ht m

Class- based RTP and TCP header com pression ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft hdrcm p.ht
.

RSVP support for RTP header com pression ( Cisco I OS Soft ware Release 12.2.15T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 15/ ft rsvpcf.ht m

RTP header com pression over sat ellit e links ( Cisco I OS Soft ware Release 12.3.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios123/ 123newft / 123t / 123t _2/ ft crt prf.ht m

Link Fragmentation and Interleaving

MLP int erleaving and queuing for real- t im e t raffic ( Cisco I OS Soft ware Release 12.0) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 12cgcr/ dial_c/ dcppp.ht m # 4550

FRF.12 ( Cisco I OS Soft ware Release 12.0.4T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 4/ 120t vofr/ inde
.

FRF.12 support on swit ched Fram e Relay PVCs ( Cisco I OS Soft ware Release 12.1.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 2/ dt fragsw.ht m

Link Fragm ent at ion and I nt erleaving for Fram e Relay and ATM virt ual circuit s ( Cisco I OS Soft ware Relea
12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt lfifra.ht m

Fram e Relay fragm ent at ion wit h hardware com pression ( Cisco I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt frfwhc.ht m

Versat ile int erface processor- based dist ribut ed FRF.12 ( Cisco I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt vofrv.ht m
Dist ribut ed Link Fragm ent at ion and I nt erleaving for Fram e Relay and ATM int erfaces ( Cisco I OS Soft war
Release 12.2.4T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 4/ ft dlfi.ht m

Dist ribut ed Link Fragm ent at ion and I nt erleaving over leased lines ( Cisco I OS Soft ware Release 12.2.8T)
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ ft dlfi2.ht m

Fram e Relay queuing and fragm ent at ion at t he int erface ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ frfrint q.ht m

Prefragm ent at ion for I PSec VPNs ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft prefrg.ht m

Mult iclass Mult ilink PPP ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft m m lppp.h
Chapter 8. Bandwidth Reservation
This chapt er includes t he following t opics:

RSVP as a call adm ission cont rol m echanism

RSVP and LLQ

RSVP and MPLS t raffic engineering

Scalabilit y

RSVP- DiffServ int egrat ion

Endpoint s and proxies

The QoS t ools discussed so far in t his book, including m arking, queuing, policing, and shaping
m echanism s, prim arily have been DiffServ t ools. DiffServ m echanism s provide bandwidt h
guarant ees ( at various level of rigidit y) , but none of t hem provides bandwidt h r eser vat ions.
Guar ant eed im plies t hat t he bandwidt h will be t here when needed, but it is not set aside ( or
reserved) for a specific applicat ion or flow. Reser v ed, on t he ot her hand, im plies t hat a flow of
packet s can be recognized and t hat a cert ain am ount of bandwidt h has been agreed t o be set
aside for t hat flow.

I nt roduced in Cisco I OS Soft ware Release 11.2, roughly coinciding wit h t he dat e of m any of t he
relevant RFCs ( sum m arized for reference at t he end of t his chapt er) , RSVP is one of t he oldest
Cisco I OS QoS t ools. The developm ent and im plem ent at ion of RSVP precede t he era of
converged voice and dat a net works, yet t he purpose of RSVP was always in line wit h t hese lat er
t rends: t o provide predict able lat ency and bandwidt h guarant ees for t im e- sensit ive applicat ions.
RFC 2205 defines RSVP as follows:

[ RSVP is] a resource reservat ion set up prot ocol designed for an int egrat ed services I nt ernet
[ RFC 1633] . The RSVP prot ocol is used by a host t o request specific qualit ies of service
from t he net work for part icular applicat ion dat a st ream s or flows. RSVP is also used by
rout ers t o deliver qualit y- of- service ( QoS) request s t o all nodes along t he pat h( s) of t he
flows and t o est ablish and m aint ain st at e t o provide t he request ed service. RSVP request s
will generally result in resources being reserved in each node along t he dat a pat h.

RSVP differs from ot her QoS t ools in t he following ways:

I t is a signaling prot ocol.

I t reserves resources ( bandwidt h) .

A full im plem ent at ion requires all nodes in t he net work t o do t he following:

- Underst and t he RSVP prot ocol

- I m plem ent a way t o reserve resources on t hat node

RSVP Overview
RSVP is a per- flow prot ocol t hat request s a bandwidt h reservat ion from every node in t he pat h of
t he flow. I n it s sim plest form , RSVP is a unidirect ional prot ocol, so if a bidirect ional reservat ion is
required for a flow, bot h endpoint s m ust init iat e a request for a reservat ion.

Basic RSVP prot ocol operat ion is shown in Figure 8- 1 and it s configurat ion in Exam ple 8- 1. The
endpoint s, or ot her net work devices on behalf of t he endpoint s, send unicast signaling m essages
t o est ablish t he reservat ion: An RSVP PATH m essage t ravels out bound request ing t he
reservat ion, and an RSVP RESV is ret urned confirm ing ( or not ) t hat t he reservat ion was
est ablished. The flow can be signaled by an end st at ion ( such as Endpoint B in Figure 8- 1 ) or by
a rout er ( such as t hat on behalf of Endpoint A, which is not capable of RSVP signaling) . Every
RSVP- enabled rout er in t he pat h of t he flow sees t he PATH and RESV m essages and allocat es t he
appropriat e queue space for t he given flow.

Figu r e 8 - 1 . Ba sic RSVP Pr ot ocol Ope r a t ion

[View full size image]

I n sum m ary, t he following is t rue of RSVP:

I t is a prot ocol t o signal QoS inform at ion t o m ake a reservat ion of bandwidt h.

I t can m ake resource reservat ions for bot h unicast and m ult icast applicat ions.

I t is receiver orient ed. ( I n ot her words, t he receiver of a dat a flow init iat es and m aint ains
t he resource reservat ion used for t hat flow.)

I t m aint ains st at e in rout ers and host s.

I t is not a rout ing prot ocol, but it depends on rout ing prot ocols t o det erm ine t he pat h of t he
flow.

I t support s bot h I Pv4 and I Pv6.

Ex a m ple 8 - 1 . RSVP Con figu r a t ion

Router(config)#interface serial 0/1

 Router(config-if)#ip rsvp bandwidth 1008 84

RSVP Service Types

The RSVP prot ocol defines t wo dist inct service t ypes: cont rolled load and guarant eed load. Each
is discussed in m ore det ail in t he following sect ions.

Controlled Load

The cont rolled load service is described by RFC 2211. I t provides t he flow wit h soft QoS ( not
m at hem at ically bounded, which m eans t hat t here is no quant it at ive m easure t hat says t he QoS
provided is wit hin, as in a 50- m s delayinst ead, it provides an approxim at e or qualit at ive
guarant ee, which m eans t hat t he QoS provided is at least as good as t he packet would have
got t en ot herwise) , approxim at ing t he service t hat t he sam e flow would receive from an unloaded
net work. The cont rolled load service uses adm ission cont rol t o ensure t hat t he service is
received even when t he net work elem ent is overloaded. The cont rolled load service includes no
quant it at ive guarant ees, and it can be t hought of as sim ple priorit y service wit h adm ission
cont rol. I t allows applicat ions t o have low delay and high t hroughput even during t im es of
congest ion. For exam ple, adapt ive real- t im e applicat ions, such as playback of a recorded
conference, can use t his kind of service.

To ensure t hat t hese condit ions are m et , client s request ing cont rolled load service provide t he
net work nodes wit h an est im at ion of t he dat a t raffic t hey will generat e, which is described in t he
t raffic specificat ion ( or TSpec) . The TSpec is one of t he param et ers in t he RSVP request , as
covered in Chapt er 1, " I nt roduct ion t o QoS."

Guaranteed Load

The guarant eed load service is described in RFC 2212. I t provides t he flow wit h firm bounds
( m at hem at ically provable, which m eans t hat explicit , m easurable bounds on t he QoS provided t o
t he packet are specified) on end- t o- end delays by guarant eeing bandwidt h. Achieving a bounded
delay requires t hat every node in t he pat h support s guarant eed service or adequat ely m im ics
guarant eed service. Guarant eed service allows applicat ions t o reserve bandwidt h t o m eet t heir
requirem ent s. Guarant eed service is invoked by specifying t he t raffic ( TSpec) and t he desired
service ( RSpec) t o t he net work.

Admission Control
I n addit ion t o providing bandwidt h reservat ion t o guarant ee QoS for a flow, RSVP serves anot her
purpose of prim e im port ance t o real- t im e flows: call adm ission cont rol ( CAC) . DiffServ t ools are
highly capable of prot ect ing voice from dat a ( or video from dat a) , but t hey fall com plet ely short
at prot ect ing voice from voice ( or int eract ive video from int eract ive video) . For exam ple, if only
enough bandwidt h is set aside in LLQ for t wo VoI P calls, and a t hird call goes t hrough, t he
qualit y of all t hree calls will det eriorat e if only DiffServ t ools are used ( wit hout any CAC) .
However, if a bandwidt h reservat ion is request ed before a flow is adm it t ed ont o t he net work, t he
originat ing node has t he opt ion t o redirect or rej ect t he flow if t he reservat ion fails ( because of
insufficient bandwidt h availabilit y) . To voice and int eract ive video t raffic, t he CAC funct ionalit y of
RSVP is arguably m ore crit ical t han t he bandwidt h reservat ion funct ionalit y ( which could be
engineered wit h DiffServ) . CAC t hrough RSVP is discussed in m ore dept h in Chapt er 9, " Call
Adm ission Cont rol ( CAC) ."

RSVP and LLQ

RSVP provides adm ission cont rol. However, t o im plem ent t he bandwidt h and delay guarant ees
t hat RSVP provides for voice t raffic, RSVP m ust work t oget her wit h LLQ.

The RSVP support for t he LLQ feat ure ( int roduced in Cisco I OS Soft ware Release 12.1[ 3] T)
allows RSVP t o classify voice flows and queue t hem int o t he priorit y queue ( PQ) wit hin t he LLQ
syst em while sim ult aneously providing reservat ions for non- voice flows t hrough CBWFQ. The
logical flow of t his feat ure is illust rat ed in Figure 8- 2 .

Figu r e 8 - 2 . RSVP a n d LLQ Logic

[View full size image]

I n addit ion t o having RSVP enabled on relevant int erfaces, t his feat ure requires t hat t raffic
direct ed t o t he PQ of LLQ be ident ified. A built - in voice- like profile can be select ed as an opt ion;
in t hat case, any voice t raffic generat ed by Cisco I OS devices aut om at ically is assigned t o t he
LLQ. Addit ionally, t his opt ion direct s voice t raffic from RSVP- enabled applicat ions, such as
Microsoft Net Meet ing, t o be assigned t o t he PQ wit hin LLQ. Voice- like t raffic m eans t hat t he
t raffic flows adhere t o cert ain given arrival rat e and packet size param et ers t hat are derived
from real voice flows.

To select t he built - in voice- like profile for RSVP t o classify t raffic int o t he PQ of LLQ, use t he
following com m and:

Router(config)#ip rsvp pq-profile voice-like

MPLS Traffic Engineering
The first m aj or deploym ent of RSVP t echnology cam e wit h Mult iprot ocol Label Swit ching ( MPLS)
t raffic engineering ( TE) . MPLS t raffic engineering aut om at ically est ablishes and m aint ains label-
swit ched pat hs ( LSPs) across t he backbone by using RSVP t o est ablish and guarant ee " t unnels"
of predict able bandwidt h. RSVP operat es at each LSP hop and is used t o signal and m aint ain
LSPs based on t he MPLS TE calculat ed pat h. MPLS TE uses principles from RFC 2205 ( basic
RSVP) and RFC 3209 ( TE ext ensions for RSVP) t o accom plish t his obj ect ive. RSVP used for MPLS
TE is illust rat ed in Figure 8- 3 . I n t his figure, t he PATH m essage request s, for exam ple, 40 Mbps
of bandwidt h along t he pat h. The RESV m essage est ablishes t he bandwidt h at each hop and
provides t he label t o use.

Figu r e 8 - 3 . M PLS TE PATH Se t u p w it h RSVP

Scalability
Discussions about RSVP oft en are speckled by com m ent s about scalabilit y. Scalabilit y concerns
around RSVP argue t hat it does not scale well because it keeps per- flow st at e in every node, and
because t he PATH/ RESV and refresh m essages t ravel per flow bet ween every t wo nodes involved
in t he pat h t o keep t he ent ire pat h open and funct ioning correct ly. For t his reason, various
scalabilit y enhancem ent s have been int roduced int o t he Cisco I OS Soft ware, including t he
following:

Con t r ol pla n e pr ior it y Ensures t hat t he RSVP cont rol m essages are not dropped or unduly
delayed, which would cause addit ional m essaging t o t ear down t he pat h and re- est ablish it

Re fr e sh r e du ct ion Sum m arizes t he refresh inform at ion for all flows on an int erface in a
single m essage inst ead of sending individual m essages per flow
RSVP-DiffServ Integration
RSVP- DiffServ int egrat ion provides a t ranslat ion bet ween RSVP and DiffServ t echnologies t hat is
int ended t o leverage t he st rengt hs of each m odel. RSVP is used for bandwidt h reservat ion at t he
edge of t he net work ( where t here are fewer flows and t he m ost bandwidt h const raint s) , but
DiffServ is used over t he backbone net work so t hat t he backbone rout ers do not have t o keep
per- flow st at es. This t opology is shown in Figure 8- 4 .

Figu r e 8 - 4 . RSVP- D iffSe r v I n t e gr a t ion

[View full size image]

Endpoints and Proxies
Alt hough RSVP as a specificat ion is int ended for use along t he ent ire pat h bet ween t he sender
and t he receiver, t his requires t he im plem ent at ion of RSVP in all endpoint s. Most devices and
applicat ions do not com ply wit h t his requirem ent . Addit ionally, m ost endpoint s are connect ed t o
LANs in which bandwidt h is usually plent iful and bandwidt h bot t lenecks do not occur; only if t he
flow t raverses t he WAN edge rout er or I SP uplink is congest ed t ypically encount ered in t he pat h
of t he flow.
Summary
This chapt er covered RSVP as one of t he key I nt Serv m echanism s in a QoS t oolset t hat is largely
DiffServ orient ed. RSVP provides a per- flow specificat ion of QoS t hrough various param et ers and
serves as bot h a call adm ission cont rol m echanism ( allowing or denying a flow access t o t he
net work) and a bandwidt h- reservat ion m echanism . This chapt er focused prim arily on t he
bandwidt h reservat ion aspect of RSVP.

The int eract ions bet ween RSVP and ot her QoS t ools such as LLQ were discussed, along wit h
scalabilit y and RSVP- DiffServ int egrat ion in net works t hat are not exclusively I nt Serv nor
exclusively DiffServ, but t hat inst ead use som e of t he concept s of bot h worlds. Addit ionally, for
device endpoint s t hat are not capable of RSVP, proxies were discussed t o show how net works
wit h RSVP can be built even for t hese devices.

Chapt er 9 explores RSVP's call adm ission cont rol capabilit ies furt her.
Further Reading
Standards

RFC 2205, " Resource Reservat ion Prot ocol ( RSVP) Version 1 Funct ional Specificat ion" :
ht t p: / / www.iet f.org/ rfc/ rfc2205.t xt .

RFC 2206, " RSVP Managem ent I nform at ion Base Using SMI v2" :
ht t p: / / www.iet f.org/ rfc/ rfc2206.t xt .

RFC 2207, " RSVP Ext ensions for I PSec Dat a Flows" : ht t p: / / www.iet f.org/ rfc/ rfc2207.t xt .

RFC 2208, " Resource ReSerVat ion Prot ocol ( RSVP) Version 1 Applicabilit y St at em ent : Som e
Guidelines on Deploym ent " : ht t p: / / www.iet f.org/ rfc/ rfc2208.t xt .

RFC 2209, " Resource ReSerVat ion Prot ocol ( RSVP) Version 1 Message Processing Rules" :
ht t p: / / www.iet f.org/ rfc/ rfc2209.t xt .

RFC 2210, " The Use of RSVP wit h I ETF I nt egrat ed Services" :
ht t p: / / www.iet f.org/ rfc/ rfc2210.t xt .

RFC 2211, " Specificat ion of t he Cont rolled- Load Net work Elem ent Service" :
ht t p: / / www.iet f.org/ rfc/ rfc2211.t xt .

RFC 2212, " Specificat ion of Guarant eed Qualit y of Service" :

ht t p: / / www.iet f.org/ rfc/ rfc2212.t xt .

RFC 2747, " RSVP Crypt ographic Aut hent icat ion" : ht t p: / / www.iet f.org/ rfc/ rfc2747.t xt .

RFC 2961, " RSVP Refresh Overhead Reduct ion Ext ensions" :
ht t p: / / www.iet f.org/ rfc/ rfc2961.t xt .

RFC 2998, " A Fram ework for I nt egrat ed Services Operat ion over DiffServ Net works" :
ht t p: / / www.iet f.org/ rfc/ rfc2998.t xt .

RFC 3175, " Aggregat ion of RSVP for I Pv4 and I Pv6 Reservat ions" :
ht t p: / / www.iet f.org/ rfc/ rfc3175.t xt .

RFC 3209, " RSVP- TE: Ext ensions t o RSVP for LSP Tunnels" :
ht t p: / / www.iet f.org/ rfc/ rfc3209.t xt .

Cisco IOS Documentation

General:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios123/ 123cgcr/ qos_r/ qos_i1g.ht m # 11005
.

RSVP support for low- lat ency queuing ( Cisco I OS Soft ware Release 12.1.3T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 3/ rsvp_llq.ht m

Mult im edia Conference Manager wit h Voice Gat eway I m age wit h RSVP t o ATM SVC Mapping ( Cisco I OS
Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt _m cm 5t .ht
.

RSVP support for Fram e Relay ( Cisco I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ rsvp_fr.ht m

VoI P call adm ission cont rol using RSVP ( Cisco I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt 4t rsvp.ht m

RSVP scalabilit y enhancem ent s ( Cisco I OS Soft ware Release 12.2.2T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ rsvpscal.ht m

RSVP support for ATM/ PVCs ( Cisco I OS Soft ware Release 12.2.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ rsvp_at m .ht m

MPLS DiffServ- aware Traffic Engineering ( DS- TE) over ATM ( Cisco I OS Soft ware Release 12.2.8T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ ft _ds_t e.ht m

RSVP refresh reduct ion and reliable m essaging ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft rsvpre.ht m

RSVP local policy support ( Cisco I OS Soft ware Release 12.2.13T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft rsvplp.ht m

RSVP support for RTP header com pression, phase 1 ( Cisco I OS Soft ware Release 12.2.15T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 15/ ft rsvpcf.ht m

RSVP m essage aut hent icat ion ( Cisco I OS Soft ware Release 12.2.15T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 15/ ft rsvpm a.ht
.
Chapter 9. Call Admission Control (CAC)
This chapt er discusses t he Call Adm ission Cont rol ( CAC) QoS capabilit ies, and includes t he
following t opics:

Definit ion of CAC

Resource Reservat ions Prot ocol ( RSVP)

Cisco CallManager CAC t echniques

H.323 gat ekeeper CAC t ools

Cisco I OS CAC t ools ot her t han RSVP

Call adm ission cont rol ( CAC) m echanism s are crit ical t o ensuring overall qualit y for all t raffic
t ypes t hat t raverse converged net works, part icularly for prot ect ing voice from ot her voice t raffic,
and int eract ive video from ot her int eract ive video t raffic.

All t he QoS m echanism s discussed so far have dealt wit h how t o t reat t raffic already adm it t ed t o
t he net work. CAC is t he first t oolset t hat addresses how t o keep t raffic off t he net work
( adm ission) when t here are not enough resources t o carry t he packet s. CAC usually does not
apply t o dat a t raffic because packet s sim ply can be dropped or delayed when t he net work
becom es congest ed or oversubscribed. Real- t im e t raffic can be neit her dropped nor delayed
while preserving voice or video qualit y at t he sam e t im e. Therefore, t his kind of t raffic should be
adm it t ed t o t he net work only if it can be carried in a m anner t hat will provide t he required
qualit y.

CAC is an ext ensive t opic in it s own right and encroaches upon ot her areas beyond t he scope of
t his book, such as call- rout ing algorit hm s ( dialing plans) and call priorit y and preem pt ion
capabilit ies, which t ypically involve m ore end- user knowledge t han t he infrast ruct ure of t he
net work has. A call agent or call server t ypically m akes t hese t ypes of decisions. On t he ot her
hand, t he net work infrast ruct ure is t he only part of t he net work t hat has t he knowledge of exact
resource availabilit y, such as link st at us, bandwidt h availabilit y, and t raffic congest ion point s, so
t he infrast ruct ure is t he right place for t he basic CAC ( adm it or deny) decisions. When a call is
not adm it t ed, t he call agent or call server can m ake alt ernat ive rout ing decisionsin ot her words,
t he call can be redirect ed t o t he PSTN.

The scope of t he CAC discussion in t his chapt er is t o provide an overview of t he basic CAC
m echanism s and t o underscore t heir im port ance in QoS design for converged net works. This
chapt er exam ines t he t hree m ost com m on m et hodsRSVP, CallManager locat ions, and H.323
gat ekeeper CACand provides a brief overview of ot her Cisco I OSbased t echniques t hat can be
used for aspect s of CAC.
CAC Overview
As discussed in Chapt er 5, " Congest ion- Managem ent Tools," and Chapt er 6, " Congest ion-
Avoidance Tools," dat a applicat ions are cont rolled by resolving congest ion in t he net work inst ead
of applying adm ission policies. I f dat a applicat ions encount er congest ion, packet s t ypically are
dropped. Prot ocols such as TCP have inherent det ect ion, recovery, and ret ransm ission logic,
which ensures t hat t he session is recovered for t he end user. Congest ion- m anagem ent policies
cannot be applied t o real- t im e applicat ions, such as voice and video- conferencing, and st ill
m aint ain predict able qualit y. When t he packet s t hat belong t o t hese applicat ions are adm it t ed
ont o t he net work, t hey cannot be dropped. Tradit ional TDM applicat ions such as voice, m odem ,
fax, and video calls assum e t hat bandwidt h is available and do not recover from lost inform at ion.
Because inform at ion arrival is so t im e sensit ive, t here is no point in building error- det ect ion and
recovery m echanism s, such as ret ransm ission logic, int o t hese real- t im e prot ocols. I f t he packet
cannot be delivered wit hin a sm all window of t im e, it m ight as well never arrive. " Bet t er lat e
t han never" does not apply t o real- t im e flows.
CAC Defined
By definit ion, net work bandwidt h is finit e, and point s of congest ion do occur. Bot h real- t im e and
non- real- t im e t raffic t ypes encount er t his congest ion. I f packet s cannot be dropped t o resolve
congest ion, packet flows t hat cause congest ion should not be allowed ont o t he net work. This
m akes t he case for t he deploym ent of CAC t oolst hese are, in essence, t he congest ion- avoidance
m echanism s for real- t im e applicat ions. Aft er it is adm it t ed, a real- t im e flow such as a voice call
m ust be carried; if t here aren't sufficient bandwidt h resources t o carry t he flow wit hin t he delay
and loss bounds of t he applicat ion, t he flow m ust be rej ect ed or redirect ed before it is adm it t ed
int o t he net work.

Anot her way t o look at CAC is t hat m ost of t he QoS t ools discussed t hus far in t his book st rive t o
prot ect voice t raffic from dat a t raffic. CAC t ools prot ect voice t raffic from ot her voice t raffic ( and
int eract ive video from int eract ive video) . For exam ple, if t here is sufficient bandwidt h
provisioned t hrough LLQ t o carry only t wo calls across a link, adm it t ing a t hird call will cause
packet drops and will im pair t he voice qualit y of all t hree calls in progress. Such scenarios
necessit at e t he use of CAC t o ensure t hat no m ore real- t im e flows are adm it t ed int o t he net work
beyond what t he QoS engineering of t he nodes allows. This is illust rat ed in Figure 9- 1 .

Figu r e 9 - 1 . Pr ot e ct in g Voice fr om Voice

[View full size image]

Form ally defined, CAC is a det erm inist ic decision before call est ablishm ent on whet her t he
net work resources are available t o provide t he required QoS t o t he new call. CAC feat ures allow
VoI P syst em s t o m ake an inform ed decision before adm it t ing a new call, based on t he condit ion
of t he net work. I f t he call is not adm it t ed, t he call can be given t he reorder ( or overflow) t one or
a recorded announcem ent can inform t he caller t hat t he net work is t oo busy t o com plet e t he call
at t em pt . The caller m ust t ry again lat er, or t he call can be redirect ed t o anot her VoI P rout e, or
t he call can be redirect ed t hrough t he PSTN.
CAC Tool Categories
Three broad cat egories of CAC t ools exist :

Loca l The node m akes an adm ission decision based on local inform at ion or condit ions at
t he node.

M e a su r e m e n t - ba se d A decision on adm it t ing a new flow is reached based on a

com binat ion of configurat ion inform at ion and report ed inform at ion of ot her ent it ies ( such as
calls, sessions, flows, bandwidt h, m em ory use, and t im e slot s) .

Re se r va t ion - ba se d Reservat ion of resources is perform ed before adm it t ing t he new flow.

Each of t hese cat egories of t ools is discussed in t he following sect ions.

Local CAC Tools

Local CAC m echanism s perform a voice gat eway rout er funct ion and t ypically funct ion at t he
out going gat eway. The CAC decision is based on nodal inform at ion such as t he st at e of t he
out going LAN/ WAN link t hat t he voice call would t raverse if it were allowed t o proceed. Clearly, if
t he local packet net work link is down, t here is no point in execut ing com plex decision logic based
on t he st at e of t he rest of t he net work ( because t hat net work is unreachable) . Ot her local
m echanism s include configurat ion it em s t o disallow m ore t han a fixed num ber of calls. I f t he
net work designer already knows t hat no m ore t han five calls will fit across t he out going WAN
link's LLQ configurat ion because of bandwidt h lim it at ions, it would be an obvious choice t o
configure t he local gat eway node t o not allow m ore t han five sim ult aneous calls. The following
Cisco I OS feat ures or net work design t echniques fall in t he local CAC m echanism s cat egory:

Physical DS0 lim it at ion

Max- connect ions

Voice- bandwidt h

Trunk condit ioning

Local voice busyout ( LVBO)

Measurement-Based CAC Tools

Measurem ent - based CAC t echniques look ahead int o t he packet net work t o gauge t he st at e of
t he net work t o det erm ine whet her t o allow a new call. This usually im plies sending probes t o t he
dest inat ion I P address ( which could be t he t erm inat ing gat eway or endpoint , or anot her device in
bet ween) . The probe ret urns som e m easured inform at ion on t he condit ions t hat it found while
t raversing t he net work t o t he out going ( sending) gat eway or endpoint . Typically, loss and delay
charact erist ics are t he int erest ing elem ent s of inform at ion for voice CAC decisions. The out going
device t hen uses t his inform at ion in com binat ion wit h configured inform at ion t o decide whet her
t he net work condit ions exceed a given or configured t hreshold. The following Cisco I OS feat ures
or net work design t echniques fall in t he m easurem ent - based CAC m echanism s cat egory, and
bot h use Service Assurance Agent ( SAA) probes:

Advanced voice busyout ( AVBO)

PSTN fallback

Resource-Based CAC Tools

Two t ypes of resource- based m echanism s exist : t hose t hat calculat e needed or available
resources, and t hose t hat reserve resources for t he call. Resources of int erest include link
bandwidt h, DSP availabilit y and DS0 t im e slot s on t he connect ing TDM t runks t o a voice
gat eway, CPU power, and m em ory. Several of t hese resources could be const rained at any
nodes or m ult iple nodes t hat t he call t raverses t o it s dest inat ion. The following feat ures or
net work design t echniques fall in t his cat egory:

Gat ekeeper resource act ivit y indicat or ( RAI )

Gat ekeeper zone bandwidt h

Cisco CallManager Locat ions CAC

RSVP
CallManager Locations CAC
Most of t he feat ures m ent ioned in t he previous sect ion are Cisco I OS feat ures and pert ain t o
em ploying CAC when Cisco I OS voice gat eway rout ers connect t radit ional t elephony equipm ent
int o an I P net work. Much of t he voice t raffic in VoI P net works, however, originat es from I P
phones, not from gat eways, and none of t hese feat ures ( ot her t han pot ent ially RSVP) applies t o
t raffic from t hese devices.

Therefore, Cisco CallManager has addit ional CAC feat ures t o cover t he m anagem ent of I P phone
net work deploym ent s. These feat ures are not m ut ually exclusive. Alt hough CallManager
Locat ions CAC is deployed in t he overall net work t o m anage VoI P bandwidt h availabilit y for bot h
I P phones and voice gat eways, a feat ure such as local or advanced voice busyout can be
deployed at t he sam e t im e on t he voice gat eway t o push back calls int o t he PBX or rerout e
t hough t he PSTN if I P net work condit ions do not allow t heir ent ry int o t he VoI P net work.

CallManager Locat ions CAC is used in a cent ralized deploym ent m odel ( cent ralized Call- Manager
m anaging phones in bot h cent ral and rem ot e locat ions) and is based on t he prem ise t hat
bandwidt h is const rained bet ween locat ions or sit es in t he net work. Therefore, only a cert ain
num ber of calls, regardless of t heir originat ion on an I P phone or gat eway, can be allowed int o
or out of a sit e at any one t im e, as shown in Figure 9- 2 . The prem ise of t his t ool includes an
assum pt ion t hat t he bandwidt h wit hin a locat ion is unlim it ed and t hat const raint s exist only
bet ween different locat ions.

Figu r e 9 - 2 . Ca llM a n a ge r Loca t ion s CAC

[View full size image]

Looking at t he configurat ion given in Figure 9- 2 , Locat ion 2 has WAN bandwidt h of 128 kbps
available for voice t raffic. This does not indicat e t he t ot al bandwidt h int o t hat sit e, but j ust t he
bandwidt h available for voice, as configured int o t he CallManager at Locat ion 1. I t can represent
50 percent of t he t ot al bandwidt h int o t he sit e and should be correlat ed t o t he am ount of
bandwidt h set aside in t he LLQ priorit y class for Locat ion 2.

The t erm correlat ed is used inst ead of m at ched because CallManager t akes int o account only t he
uncom pressed Layer 3 bandwidt h of a call int o it s call- count ing CAC algorit hm . On t he ot her
hand, LLQ, as discussed in Chapt er 5, also m ust account for various ot her fact ors, such as cRTP,
t hat affect t he bandwidt h required for a voice call and m ust m ake provision for t he call- signaling
bandwidt h.

The CallManager Locat ions CAC feat ure works in conj unct ion wit h CallManager regions ( a feat ure
t hat cont rols codec select ion bet ween devices t hat want t o com m unicat e) , so bandwidt h-
const rained links bet ween sit es t ypically are configured t o use t he G.729 codec and a count ing
m echanism wit hin CallManager lim it s t he num ber of calls int o or out of each sit e. I P phones and
voice gat eways are associat ed wit h bot h a region ( for codec select ion) and a locat ion ( for CAC
purposes) in t he CallManager configurat ion. For every call set up, CallManager looks at t he
source and dest inat ion locat ions of t he call and m akes a CAC decision t o allow or deny t he new
call, based on how m any calls are already act ive bet ween t he sam e t wo locat ions and t he codecs
involved in t he calls. Calls confined wit hin a locat ion are not subj ect t o CAC; as det erm ined by
t he regions feat ure, t hese calls t ypically use t he G.711 codec.

Exam ining t he exam ple configurat ion in Figure 9- 2 once m ore, Locat ion 2 has 128 kbps of
bandwidt h available for voice. I f t he CallManager regions feat ure is configured so t hat any call
int o or out of Locat ion 2 uses t he G.729 codec, 24 kbps of bandwidt h are required per call, and
CallManager's locat ions CAC algorit hm will allow a m axim um of 5 ( 128 / 24) sim ult aneous calls
t o Locat ion 2.

CallManager Locat ions CAC is a heavily deployed feat ure and is essent ial for a cent ralized
deploym ent in which som e I P phones or gat eways are separat ed from each ot her by WAN
segm ent s of lim it ed bandwidt h. CallManager locat ions should be configured so t hat calls bet ween
sit es do not oversubscribe t he bandwidt h allocat ed t o t he VoI P LLQ in t he WAN rout ers.
CallManager Locat ions CAC is a sim ple call- count ing m echanism and is unaware of t he t opology
or st at e of t he net work connect ions. I t allows a configured am ount of bandwidt h ( for exam ple,
200 kbps) bet ween t wo sit es. For every call, it subt ract s a fixed am ount based on t he codec
select ed by t he regions feat ure. Thus, locat ions CAC works well only for hub- and- spoke
t opologies. I t is also unaware of L2 prot ocol overheads ( it calculat es purely L3 bandwidt h
required) and bandwidt h- alt ering feat ures, such as cRTP and t unneling t echnologies such as GRE
and I PSec.
Gatekeeper CAC
Gat ekeepers ( GK) oft en are used t o arbit rat e bandwidt h in bot h CallManager and t radit ional t oll-
bypass net works. As wit h CallManager Locat ions CAC, gat ekeepers em ploy a call- count ing
m echanism ( based on codec per call) bet ween sit es ( zones) , t rack bandwidt h at an L3 level, and
are also unaware of t he net work t opology. Thus, gat ekeeper call adm ission cont rol ( GK CAC)
generally solves t he sam e problem as CallManager Locat ions CAC and suffers from t he sam e
drawbacks. GK CAC is applicable t o a wider set of devices t han Call- Manager Locat ions CAC,
t hough: GK CAC can be used t o arbit rat e bandwidt h bet ween any t wo devices t hat regist er wit h
t he GK, whereas CallManager Locat ions CAC can be used only bet ween I P phones and voice
gat eways wit hin CallManager's m anagem ent area. GK CAC in CallManager net works is used
prim arily in dist ribut ed deploym ent m odels t o provide CAC on t he int erclust er t runks or t he
connect ions bet ween t he CallManager clust ers, as shown in Figure 9- 3 .

Figu r e 9 - 3 . Ga t e k e e pe r CAC in Ca llM a n a ge r N e t w or k s

[View full size image]

GK CAC also oft en is deployed in videoconferencing net works t o arbit rat e bandwidt h am ong
video endpoint s, gat eways, and MCUs. Unlike CallManager Locat ions CAC, t he bandwidt h
subt ract ed per call is not fixed based purely on t he codec ( CallManager Locat ions CAC handles
only G.729 and G.711 calls) ; inst ead, t he bandwidt h needed for t he call is request ed from t he
GK as part of t he H.225 adm issions request t raveling from t he endpoint or gat eway t o t he GK.
RSVP
RSVP's use in providing QoS for real- t im e flows has a checkered past in t he indust ry, in t he I ETF,
and in Cisco I OS im plem ent at ion. However, RSVP is looking increasingly prom ising as t he only
t echnology t hat can provide t rue real- t im e com m unicat ions CAC for com plex net work t opologies
and varying t raffic pat t erns. Fact ors t hat have cont ribut ed t o RSVP's spot t y deploym ent t o
provide QoS for real- t im e t raffic include t he following ( m ost of which have been resolved) :

St a t e - m a ch in e syn ch r on iza t ion RSVP provides benefit t o voice calls only if it s st at e

m achine and t hat of t he call set up flow are synchronized t o provide an RSVP reservat ion for
t he call before t he dest inat ion part y's phone rings. This is referred t o as prering CAC. This
synchronizat ion is now in place for H.323 as of Cisco I OS Soft ware Release 12.1.5T, and for
SI P and MGCP as of Cisco I OS Soft ware Release 12.2.8T. The synchronized call set up logic
for H.323 is shown in Figure 9- 4 .

Figu r e 9 - 4 . H .3 2 3 : RSVP Syn ch r on ize d Ca ll Se t u p

[View full size image]

The flow shown in Figure 9- 4 depict s only t he RSVP m essages bet ween t he t wo com m unicat ing
endpoint s. As discussed in Chapt er 8, " Bandwidt h Reservat ion," t he RSVP m essages act ually
t ravel bet ween each t wo nodes in t he net work connect ing t wo endpoint s t oget her; each node
m akes a decision on whet her t o m ake or deny t he request ed reservat ion. The flow in Figure 9- 4
shows only t he end result of t he RSVP m essages having t raversed all t he nodes bet ween t he t wo
endpoint s.

Sca la bilit y These concerns have been addressed wit h t he scalabilit y im provem ent and
 RSVP- DiffServ I nt egrat ion feat ures discussed in t he previous chapt er.

I n t e r ope r a bilit y w it h ot h e r QoS fe a t u r e s Various im provem ent s have been m ade t o

RSVP in recent Cisco I OS releases, including cont rol plane priorit izat ion in Release 12.2.2T
and feedback wit h cRTP in Release 12.2.15T, t o ensure t hat an accurat e am ount of
bandwidt h is reserved and t hat RSVP works seam lessly wit h t he ot her QoS t ools.

Se cu r it y To guard against rogue applicat ions init iat ing reservat ions, eit her for calls t hat
should not be allowed ont o t he net work or for denial- of- service purposes, RSVP was
enhanced in Cisco I OS Release 12.2.15T. I t now does aut hent icat ion checks on RSVP
m essaging t o ensure t hat m essages request ing bandwidt h are sourced by legit im at e
endpoint s or nodes and t hat t he request s are for legit im at e purposes.

La ck of e n dpoin t im ple m e n t a t ion The only rem aining fact or t hat keeps RSVP from wide
deploym ent for CAC purposes is it s lack of support on I P phones, Call- Manager, and ot her
voice applicat ions ( for exam ple, Unit y voicem ail) plat form s. However, at t he t im e of
writ ing, developm ent has already begun on RSVP proxy solut ions in Cisco I OS t hat will
init iat e and broker RSVP reservat ion across bandwidt h- const rained segm ent s of t he
net work on behalf of endpoint s such as I P phones. These Cisco I OS developm ent s also are
t arget ed t o address scalabilit y concerns so t hat RSVP reservat ions are m ade only for
segm ent s of t he net work in which t hey are necessary and do not burden t he ent ire net work
and every call wit h a reservat ion.

RSVP addresses m any of t he short com ings of t he ot her m ore narrowly focused CAC
m echanism s:

On ly r e se r va t ion s m e ch a n ism The ot her CAC t echniques are call- count ing t echniques
t hat cannot guarant ee bandwidt h. RSVP is t he only reservat ions m echanism .

N e t w or k t opology a w a r e n e ss RSVP is t he only CAC t echnology t hat can negot iat e a pat h
t hrough any net work t opology and st ill guarant ee bandwidt h on every leg t hat t he call
follows, wherever t he rout ing prot ocols m ight point t o t hat pat h. The ot her CAC
m echanism s assum e sim pler hub- and- spoke t opologies wit hout alt ernat e rout ing
capabilit ies or redundant links or pat hst hey can prot ect only a virt ual " leg" bet ween t wo
sit es or locat ions and cannot t ake int o account t hat som e backbone net work segm ent s
cont ain aggregat ions of calls from several sit es. Wit h t hese m echanism s, it is st ill possible
t o oversubscribe a segm ent , even if all sit es are wit hin t heir individual CAC allocat ions.

N e t w or k st a t e a w a r e n e ss I f m ult iple links are bound t oget her wit h t echnologies such as
MLP bundling, RSVP can react t o link failures wit hin t he bundle and, t herefore, com pensat e
for t em porary loss of bandwidt h availabilit y in t he affect ed net work segm ent . The call-
count ing CAC m echanism s allow bandwidt h oversubscript ion when failures in t he net work
cause less bandwidt h t han st at ically configured t o be available for a period of t im e.

Accom m oda t ion of ba n dw idt h ch a n ge s I n Cisco I OS Soft ware Release 12.2.2T and
lat er, RSVP dynam ically can adj ust t he bandwidt h allocat ed t o a session or flow if a higher-
layer applicat ion request s it .

Fr e e m ix of diffe r e n t ba n dw idt h r e qu e st s GK CAC and RSVP can do appropriat e CAC

for m ixes of voice and video calls, each pot ent ially of a varying bandwidt h size. The
count ing m echanism s, such as CallManager Locat ions CAC and GK CAC, discussed earlier,
fall short of prot ect ing net work segm ent s t hat aggregat e calls from various sit es. The
com plexit y of bandwidt h arbit rat ion in m ixed voice and video net works requires CAC
beyond t he capabilit ies of st at ic call count ingonly RSVP t ruly can prot ect t hese
environm ent s.
Example of VoIP CAC Through RSVP
The VoI P call adm ission cont rol using RSVP feat ure ( Cisco I OS Soft ware Release 12.1[ 5] T)
synchronizes RSVP signaling wit h H.323 Version 2 signaling t o ensure t hat t he bandwidt h
reservat ion is est ablished in bot h direct ions before a call m oves t o t he alert ing phase ( ringing) .
This ensures t hat t he called part y's phone rings only aft er t he resources for t he call have been
reserved. Using RSVP- based adm ission cont rol, VoI P applicat ions can reserve net work bandwidt h
and react appropriat ely if bandwidt h reservat ion fails.

Synchronized RSVP is at t em pt ed for an I P call when t he request ed QoS for t he associat ed dial
peer is set t o cont rolled- load or guarant eed- delay, as long as RSVP has been enabled for t he
int erface by using t he ip r svp ba n dw idt h com m and. I f t he request ed QoS level is set t o t he
default of best effort or RSVP is not enabled, bandwidt h reservat ion is not at t em pt ed. Before
Cisco I OS Soft ware Release 12.1( 5) T, VoI P gat eways used H.323 Version 1 ( slow connect )
procedures when init iat ing calls t hat require bandwidt h reservat ion. The VoI P CAC t hrough RSVP
feat ure ( which is enabled by default ) allows gat eways t o use H.323 Version 2 ( fast connect ) for
all calls, including t hose t hat require RSVP. To enable backward com pat ibilit y, com m ands are
available t o force t he originat ing gat eway t o init iat e calls using slow connect procedures.

I f RSVP reservat ion is at t em pt ed but fails, t he accept able QoS for t he dial peer det erm ines t he
out com e of t he call. When t he accept able QoS is configured for best effort , t he call set up
proceeds, but wit hout any bandwidt h reservat ion in place. When t he accept able QoS on eit her
gat eway is configured for ot her t han best effort and t he RSVP reservat ion fails, t he call is
released. The request ed QoS and accept able QoS are configured t hrough Cisco I OS Soft ware by
using t he r e q- qos and a cc- qos dial- peer configurat ion com m ands, respect ively.

Table 9- 1 sum m arizes t he result s of nine call- set up scenarios using fast connect , based on t he
QoS levels configured in t he VoI P dial peers at t he originat ing and t erm inat ing gat eways. This
t able does not include cases in which t he request ed QoS is best effort and t he accept able QoS is
ot her t han best effort because t hose configurat ions are considered invalid. The following
convent ion is used in t he Request ed QoS and Accept able QoS colum ns t o indicat e t he
configurat ion for t he scenario:

CL: Cont rolled load

GD: Guarant eed delay

BE: Best effort

Ta ble 9 - 1 . Ca ll Re su lt s Ba se d on Con figu r e d QoS Le ve ls

Or igin a t in g Ga t e w a y Te r m in a t in g Ga t e w a y
Re qu e st e d QoS Acce pt a ble Re qu e st e d Acce pt a ble
QoS QoS QoS Re su lt s

1 CL or GD CL or GD CL or GD CL or GD Call proceeds only if bot h

RSVP reservat ions succeed.

2 CL or GD CL or GD CL or GD BE Call proceeds only if bot h

RSVP reservat ions succeed.
3 CL or GD CL or GD BE Call is released.
 Or igin a t in g Ga t e w a y Te r m in a t in g Ga t e w a y
Re qu e st e d QoS Acce pt a ble Re qu e st e d Acce pt a ble
QoS QoS QoS Re su lt s

4 CL or GD BE CL or GD CL or GD Call proceeds only if bot h

RSVP reservat ions succeed.

5 CL or GD BE CL or GD BE Call proceeds regardless of

RSVP result s. I f RSVP
reservat ion fails, call
receives best - effort service.
6 CL or GD BE BE BE Call proceeds wit h best -
effort service.
7 BE BE CL or GD CL or GD Call is released.

8 BE BE CL or GD BE Call proceeds wit h best -

effort service.

9 BE BE BE BE Call proceeds wit h best -

effort service.

The following exam ple, illust rat ed in Figure 9- 5 , shows how calls can be m ade in eit her direct ion
bet ween Gat eway A and Gat eway B, which are connect ed t o POTS phones, wit h phone num bers
711 and 712, respect ively. The request ed QoS indicat es t hat RSVP set up m ust com plet e before
t he dest inat ion phone rings. The accept able QoS indicat es t hat t he call is released if t he RSVP
set up fails or does not com plet e wit hin t he allot t ed t im e. Exam ple 9- 1 gives t he configurat ion for
Gat eway A; Exam ple 9- 2 gives t he configurat ion for Gat eway B.

Figu r e 9 - 5 . RSVP CAC Syn ch r on iza t ion Ex a m ple

[View full size image]

Ex a m ple 9 - 1 . Ga t e w a y A Con figu r a t ion

Router# sh run
call rsvp-sync
call rsvp-sync resv-timer 15
!
interface Ethernet0/0
ip address 10.10.107.107 10.255.255.255
service-policy VOIP-LLQ
ip rsvp bandwidth 1000 1000
!
voice-port 3/0/0
 !
dial-peer voice 712 voip
destination-pattern 712
session target ipv4:10.10.107.108
req-qos controlled-load
acc-qos controlled-load
!
dial-peer voice 711 pots
destination-pattern 711
port 3/0/0

Ex a m ple 9 - 2 . Ga t e w a y B Con figu r a t ion

Router# sh run
call rsvp-sync
call rsvp-sync resv-timer 15
!
interface Ethernet0/0
ip address 10.10.107.108 10.255.255.255
service-policy VOIP-LLQ
ip rsvp bandwidth 1000 1000
!
voice-port 2/0/0
!
dial-peer voice 711 voip
destination-pattern 711
session target ipv4:10.10.107.107
req-qos controlled-load
acc-qos controlled-load
!
dial-peer voice 712 pots
destination-pattern 712
port 2/0/0
Summary
This chapt er gave a brief overview of call adm ission cont rol ( CAC) t echniques, t he QoS t ools
designed t o keep excess real- t im e t raffic off t he net work when t here isn't bandwidt h t o carry it .
Packet s cannot be dropped sum m arily ( as is done wit h dat a t raffic) t o m anage congest ion in t he
net work, so an inform ed adm ission decision m ust be m ade before allowing a real- t im e ( t ypically
voice or video) call ont o t he net work.

CAC is a broad subj ect , and only a high- level overview was discussed here, wit h part icular
em phasis on t he m ost com m on CAC t echniques, including Cisco CallManager Locat ions CAC,
gat ekeeper CAC, and RSVP. RSVP is not deployed widely for CAC in net works t oday; however, as
support for it increases in m ore endpoint s, t his is likely t o becom e t he m ore prevalent form of
CAC over t im e because it solves m any of t he short com ings of t he ot her t echniques discussed in
t his chapt er.
Further Reading
General

Davidson, Jonat han, et al. Deploying Cisco Voice over I P Solut ions . I ndianapolis: Cisco Press, 2001.

VoI P call adm ission cont rol:

ht t p: / / www.cisco.com / en/ US/ t ech/ t k652/ t k701/ t echnologies_whit e_paper09186a00800da467.sht m l

CallManager call adm ission cont rol:

ht t p: / / www.cisco.com / en/ US/ product s/ sw/ voicesw/ ps556/ product s_adm inist rat ion_guide_chapt er0918
.

RFC 2543, " SI P: Session I nit iat ion Prot ocol" : ht t p: / / www.iet f.org/ rfc/ rfc2543.t xt .

Cisco IOS Documentation

Local voice busyout ( Cisco I OS Soft ware Release 12.0.3T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 3/ busyfm .ht m

Busyout m onit or on Cisco 2600 and 3600 series rout ers ( Cisco I OS Soft ware Release 12.0.7T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 7/ busy_t 7.ht m

Voice busyout enhancem ent s ( Cisco I OS Soft ware Release 12.1.2T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 2/ dt _boenh.ht m

Advanced voice busyout ( Cisco I OS Soft ware Release 12.1.3T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 3/ dt _avbo.ht m

PSTN fallback ( Cisco I OS Soft ware Release 12.1.3T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 3/ dt pst nfb.ht m

7200/ 7500 ( Cisco I OS Soft ware Release 12.2.4T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 4/ ft pst n4t .ht m

RSVP support for low- lat ency queuing ( Cisco I OS Soft ware Release 12.1.3T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 3/ rsvp_llq.ht m

RSVP support for Fram e Relay ( Cisco I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ rsvp_fr.ht m

VoI P call adm ission cont rol using RSVP ( Cisco I OS Soft ware Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt 4t rsvp.ht m

Cont rol plane DSCP support for RSVP ( Cisco I OS Soft ware Release 12.2.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ dscprsvp.ht m

Advanced voice busyout ( Cisco I OS Soft ware Release 12.2.4T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122lim it / 122x/ 122xa/ 122
.

Call adm ission cont rol for H.323 VoI P gat eways ( Cisco I OS Soft ware Release 12.2.4T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122lim it / 122x/ 122xa/ 122
.

Call adm ission cont rol for H.323 VoI P gat eways ( Cisco I OS Soft ware Release 12.2.8T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ ft _cac7x.ht m

SI P gat eway support of RSVP and TEL URL ( Cisco I OS Soft ware Release 12.2.8T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122lim it / 122x/ 122xb/ 122
.

MGCP VoI P call adm ission cont rol ( Cisco I OS Soft ware Release 12.2.8T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ ft _04m ac.ht m

Call adm ission cont rol for H.323 VoI P gat eways ( Cisco I OS Soft ware Release 12.2.11T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 11/ ft cac58.ht m

Enhanced feat ures for local and advanced voice busyout ( Cisco I OS Soft ware Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft _lavbo.ht m

RSVP support for RTP header com pression, phase 1 ( Cisco I OS Soft ware Release 12.2.15T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 15/ ft rsvpcf.ht m

Measurem ent - based call adm ission cont rol for SI P ( Cisco I OS Soft ware Release 12.2.15T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 15/ ft cacsip.ht m
Chapter 10. Catalyst QoS Tools
This chapt er discusses t he following Cat alyst QoS t ools:

Classificat ion and m arking t ools

Mapping t ools

Policing and m arkdown t ools

Queuing t ools

These t ools are considered on a plat form - specific basis on t he following fam ilies of swit ches:

Cat alyst 2950

Cat alyst 2970

Cat alyst 3550

Cat alyst 3560

Cat alyst 3750

Cat alyst 4550 ( Supervisors I I + t hrough V)

Cat alyst 6500 ( Supervisor 2 and Supervisor 720)

Most of t he QoS t ools discussed t o t his point were covered in t he cont ext of Cisco I OS Soft ware
feat ures. As such, t hese feat ures ent ail a CPU t ax when t hey are im plem ent ed, and som e t ools
require m ore CPU cycles t han ot hers. The CPU overhead required increases wit h t he line rat es of
t he m edia t o which t he policies are applied.

I n a LAN swit ching environm ent , QoS policies st ill are required. ( The fallacy of why sim ply
" t hrowing m ore bandwidt h at it " won't solve cam pus QoS issues is discussed in m ore det ail in
t his chapt er's sect ion discussing cam pus QoS design.) I m plem ent ing such policies in soft ware at
Fast Et hernet , Gigabit Et hernet , and 10- GE speeds would j ust about m elt any Cisco box.
Therefore, Cisco has port ed QoS logic from Cisco I OS Soft ware t o hardware ASI Cs t o provision
QoS policies at line rat es wit hin cam pus environm ent s.

The port ing of QoS from soft ware t o hardware has m any advant ages from a design perspect ive,
but it also has som e caveat s ( which are discussed lat er) . Som e of t hese design advant ages
include t he following:

Classificat ion and m arking can be offloaded from rout ers and m oved as close t o t he source
host s as adm inist rat ively possible. This not only ext ends t he DiffServ dom ain, but it also
enables rout ers t o use t heir CPU cycles m ore effect ively and efficient ly.

Trust boundaries can be defined and enforced.

 Policing can be perform ed right at t he source. This includes bot h RFC 2597 AF m arkdown
policing ( such as m arking down out - of- cont ract AF11 t raffic t o AF12, or even AF13) or
sim ply policing t o drop unwant ed t raffic.

I ncreased policing opt ions, such as per- port / per- VLAN policing and m icroflow policing.

Real- t im e applicat ions, such as voice, can be guarant eed wit hin cam pus environm ent s
because of preferent ial/ priorit y hardware queuing.

Congest ion can be avoided wit hin t he cam pus, using WRED or sim ilar t ools.

The m ain caveat t hat arises from t he port ing of soft ware QoS t o hardware is t hat QoS feat ures
becom e hardware specifict hat is, t hey can vary from plat form t o plat form , and even from line
card t o line card. This increases t he com plexit y of configuring and m anaging cam pus QoS
because m any idiosyncrasies need t o be kept in m ind for each plat form or line card. This caveat
furt her is exacerbat ed by t he fact t hat som e plat form s require Cat OS, ot hers require Cisco I OS,
and st ill ot hers ( such as t he Cat alyst 6500) can be configured using eit her. To address t his issue,
com m on synt axes, such as t he MQC from Cisco I OS, and com m and m acros, such as Aut oQoS,
are cont inuing t o be developed t o m ake QoS m ore consist ent and easier t o deploy across
Cat alyst plat form s.

This chapt er first looks at generic QoS m odels across t he Cat alyst plat form fam ilies and t hen
exam ines t he m ost current ly relevant Cat alyst plat form s.
Generic Catalyst QoS Models
Plat form idiosyncrasies aside for a m om ent , m ost Cat alyst plat form s follow t he high- level generic
QoS m odel shown in Figure 10- 1.

Figu r e 1 0 - 1 . Ge n e r ic Ca t a lyst QoS M ode l

[View full size image]

The generic Cat alyst QoS funct ions of classificat ion and m arking, policing and m arking, and
scheduling ( congest ion m anagem ent and congest ion avoidance) are exam ined in t he following
sect ions.

Classification, Marking, and Mapping

On m ost Cat alyst plat form s ( ot her t han t he Cat alyst 2950) , QoS is disabled by default and m ust
be enabled globally before any funct ion, including classificat ion, occurs.

During QoS processing in Cat alyst swit ches, all packet s are represent ed wit h an I nt ernal DSCP
value. This applies even t o non- I P packet s because non- I P packet s have t heir I nt ernal DSCP
generat ed by t heir CoS values ( coupled wit h t he CoS- t o- DSCP m apping t able set t ings) or are
assigned t he default I nt ernal DSCP value of 0. This I nt ernal DSCP value is derived from , am ong
ot her crit eria, t he t rust st at e of t he port . The t rust st at es can be set t o t he following:

Tr u st D SCP The I nt ernal DSCP is set according t o t he received DSCP values.

Tr u st I P Pr e ce de n ce The I nt ernal DSCP is set based on t he received I P Precedence

values, t hrough a default or m odified I PP- t o- DSCP m apping.

Tr u st CoS The I nt ernal DSCP is set based on t he received CoS values, t hrough a default or
m odified CoS- t o- DSCP m apping.
 Un t r u st e d The received CoS is set or reset t o t he default value ( t ypically 0) , and t he
I nt ernal DSCP value is set t hrough a default or m odified CoS- t o- DSCP m apping ( which,
likewise, t ypically result s in an I nt ernal DSCP m arking of 0) .

Trust boundaries also can be ext ended t o devices such as I P phones so t hat t he swit ch will t rust
t he m arkings t hat t he I P phone has set . I P phones m ark Voice t raffic t o CoS 5 and DSCP EF, and
Call- Signaling t raffic t o CoS 3 and DSCP AF31 ( or CS3 on newer soft ware releases) .

Modifiable CoS- t o- DSCP m aps provide net work adm inist rat ors granularit y in t hese m appings. For
exam ple, by default , t he 3 CoS bit s are used as t he t hree m ost significant bit s wit hin t he DSCP
( CoS 5 m aps t o DSCP 40, which is CS5 and not EF) . But when a t hird- part y I PT device doesn't
m ark Voice t raffic wit h CoS and DSCP ( as Cisco I P phones do) , t he adm inist rat or can chose t o
m odify t his m apping t able t o correct ly m ap voice from CoS 5 t o DSCP 46 ( EF) right at t he access
swit ch.

I n addit ion t o CoS- t o- DSCP m aps and I PP- t o- DSCP m aps, DSCP values t hem selves can be
m apped t o alt ernat e DSCP values, using DSCP m ut at ion m aps. Such DSCP- t o- DSCP m ut at ion
m aps are useful on t he borders of t wo different DiffServ dom ains.

Classificat ion also can be perform ed explicit ly using access cont rol list s ( ACLs) , which are
com prised of access cont rol ent ries ( ACEs) . Two m ain ACL t ypes exist : I P and MAC. I P ACLs
usually can use Layer 3 ( source or dest inat ion addresses) or Layer 4 ( TCP/ UDP port s/ ranges) for
classificat ion purposes. The hardware processes each ACE of an ACL for a " first - t rue- m at ch" rule.
Therefore, it is recom m ended t o order t he ACEs t o have t he m ost com m on m at ches closer t o t he
t op of t he ACL t o opt im ize processing.

Figure 10- 2 shows a generic Cat alyst classificat ion m odel. Som e plat form s, such as t he Cat alyst
6500, expand on t his m odel, but t he m ain logic rem ains t he sam e.

Figu r e 1 0 - 2 . Ge n e r ic Ca t a lyst Cla ssifica t ion , M a r k in g, a n d M a ppin g

M ode l

[View full size image]

Policing and Markdown
Three t ypes of policing are support ed on Cat alyst plat form s:

I n dividu a l policin g Applies bandwidt h const raint t o each int erface

Aggr e ga t e policin g Applies a bandwidt h lim it const raint am ong all int erfaces

M icr oflow policin g ( Ca t a lyst 6 5 0 0 on ly) Applies a bandwidt h lim it const raint t o each
flow

As in Cisco I OS, Cat alyst policers are based on t oken- bucket algorit hm s t o det erm ine in- profile
and out - of- profile t raffic. Out - of- profile t raffic can be eit her dropped or m arked down. Traffic
t hat is out - of- profile and m arked down has bot h t he DSCP and I nt ernal DSCP m arked down t o
t he new value. Figure 10- 3 shows a generic Cat alyst policing m odel.

Figu r e 1 0 - 3 . Ge n e r ic Ca t a lyst Policin g a n d M a r k dow n M ode l

Queuing and Dropping
So far, Cat alyst QoS m ight seem rem arkably sim ilar t o Cisco I OS QoS. However, when it com es
t o queuing, t he approaches differ t o t he point t hat confusion oft en set s in.

I n Cat alyst QoS, congest ion m anagem ent ( queuing) is perform ed t hrough a set num ber of
queues, and congest ion avoidance ( select ive dropping) is perform ed t hrough a set num ber of
t hresholds per queue. I n it s m ost basic form , t he num ber of queues ( Q) and t hresholds ( T) can
be expressed as x Qy T. Consider a basic exam ple using t wo queues wit h t wo t hresholds each
( 2Q2T) .

I n t his Cat alyst queuing m odel, t he buffer space for queuing for each line card's port is allocat ed
am ong t wo separat e queues: Eight y percent of t he buffer space ( by default ) is assigned t o t he
first queue, and t he rem aining 20 percent is assigned t o t he second queue. This buffer allocat ion
is depict ed in Figure 10- 4.

Figu r e 1 0 - 4 . Ba sic Ca t a lyst Qu e u in g: 2 Q2 T Ex a m ple Bu ffe r Alloca t ion

Then t wo t hresholds are defined in each queue. By default , t hese t hresholds are at 80 percent of
t he queue's dept h and 100 percent of t he queue's dept h ( t he t ail) . These t hresholds are shown
in Figure 10- 5.

Figu r e 1 0 - 5 . Ba sic Ca t a lyst Qu e u in g: 2 Q2 T Ex a m ple D e fa u lt Th r e sh olds

On all Cat alyst plat form s, CoS- t o- t ransm it queue m appings are used t o assign packet s t o
t ransm it queues ( alt hough on som e plat form s, cert ain versions of soft ware allow t he opt ion t o
configure DSCP- t o- t ransm it queue m appings) . Cont inuing t his basic exam ple, CoS values 0
t hrough 4 are assigned t o t he first queue, while CoS values 5 t hrough 7 are assigned t o t he
second queue. This is shown in Figure 10- 6.

Figu r e 1 0 - 6 . Ba sic Ca t a lyst Qu e u in g: 2 Q2 T Ex a m ple CoS- t o- Qu e u e

M a ppin gs

Addit ionally, congest ion m anagem ent is overlaid t o t he queuing m odel so t hat each CoS value
( or DSCP value, if t he plat form / soft ware support s it ) can be rest rict ed t o a cert ain t hreshold. For
exam ple, CoS values 0 and 1 can be rest rict ed t o t he first - queue first - t hreshold ( 1Q1T) . I f t he
queue fills past t his t hreshold, all packet s wit h a CoS value of 0 and 1 will be dropped. Thus, t he
rem ainder of t he first queue ( 1Q2T) is reserved exclusively t o hold only packet s wit h CoS values
of 2, 3, and 4. Sim ilarly, CoS values of 6 and 7 are rest rict ed t o t he second queue's first
t hreshold ( 2Q1T) , while t he rem ainder of t he second queue ( 2Q2T) is explicit ly reserved for CoS
5. This is shown in Figure 10- 7.

Figu r e 1 0 - 7 . Ba sic Ca t a lyst Qu e u in g: 2 Q2 T Ex a m ple CoS- t o- Th r e sh old

M a ppin gs

[View full size image]

Now t hat CoS values have been m apped t o bot h queues and t hresholds, t he scheduling ( in t he
event of congest ion) is perform ed on t his m odel by a weight ed round- robin algorit hm . Such an
algorit hm favors servicing t he second queue ( higher CoS values) over servicing t he lower queue.
Usually t hese servicing weight s ( and t he queue sizes) can be overridden from t heir default
values.

I n t his m anner, preferent ial service can be offered t o voice and net work cont rol packet s. Yet , no
st rict priorit y servicing is provided t o voice, as wit h Cisco I OS LLQ. An im provem ent on t he x Qy T
Cat alyst queuing m odel is t he 1Px Qy T m odel, in which a ( t ypically single) st rict - priorit y queue is
added t o t he m odel.

As m ent ioned previously, queues 1 and 2 are serviced by a WRR scheduler, but if any act ivit y is
det ect ed in t he priorit y queue, t he WRR scheduler is int errupt ed, t he st rict - priorit y t raffic is
serviced exhaust ively, and t he WRR scheduler resum es servicing queues 1 and 2.

An exam ple 1P2Q2T m odel, com plet e wit h CoS- t o- queue and t hreshold m appings, is shown in
Figure 10- 8. I n t his exam ple, t he first queue is allocat ed 70 percent of t he buffer space, t he
second is allocat ed 15 percent , and t he st rict priorit y also is allocat ed 15 percent , by default .

Figu r e 1 0 - 8 . Ba sic Ca t a lyst Qu e u in g: 1 P2 Q2 T Ex a m ple

 [View full size image]

All ( new) Cat alyst plat form s and line cards have som e variat ions of eit her t he x Qy T hardware
queuing m odel or ( m ore likely) t he newer 1Px Qy T hardware queuing m odel.

Wit h t he generic Cat alyst QoS m odels have been laid out , it is t im e t o exam ine som e plat form -
specific applicat ions ( and idiosyncrasies) of t hese m odels. Only t he current - generat ion swit ches
( at t he t im e of writ ing) , including t he Cat alyst 2950, 3550, 3560, 3750, 4500 ( Supervisors I I +
t hrough V) , and t he Cat alyst 6500 Supervisor 2 and Supervisor 720 are discussed here.

N ot e
This chapt er provides an overview of Cat alyst QoS t ools only t o lay a cont ext for t he
design chapt ers t o follow. As such, som e plat form s have been om it t ed from t he scope
of discussion. For a com prehensive discussion of QoS feat ures on swit ches not included
in t his list , such as t he Cat alyst 2900XL, 3500XL, 4000- Cat OS, and 5000 series
swit ches, refer t o Cisco docum ent at ion at
ht t p: / / www.cisco.com / univercd/ hom e/ hom e.ht m or t o t he Cisco Press book Cisco
Cat alyst QoS: Qualit y of Service in Cam pus Net works, by Mike Flannagan, Richard
Froom , and Kevin Turek.

N ot e
Not every QoS feat ure t hat t hese plat form s support is discussed in t his chapt er; t he
t ext is concerned only wit h t he feat ures t hat are m ost relevant t o Chapt er 12, " Cam pus
QoS Design." All feat ure discussions in t his chapt er are based on hardware/ soft ware
feat ure set s available at t he t im e of writ ing. Refer t o Cisco Cat alyst docum ent at ion for
t he lat est updat es on t hese plat form s and feat ures.
Catalyst 2950
The Cat alyst 2950, shown in Figure 10- 9, support s only Layer 2 forwarding, m aking it a good
candidat e for a low- end access swit ch. The m ain difference bet ween t he Cat alyst 2950 and t he
Cat alyst 3550 is t hat t he 3550 support s Layer 3 forwarding ( I P rout ing) and t hus can funct ion as
a dist ribut ion layer swit ch. Ot her t han t hat , t he plat form s are rem arkably sim ilar. Bot h use t he
sam e Cisco I OS code base and have a virt ually ident ical QoS feat ure set ( wit h t he 3500 boast ing
a few addit ional QoS feat ures) .

Figu r e 1 0 - 9 . Cisco Ca t a lyst 2 9 5 0 Se r ie s

Two Cisco I OS soft ware im ages are support ed on t he 2950: t he St andard I m age ( SI ) and t he
Enhanced I m age ( EI ) . The full 2950 QoS feat ure set ( including classificat ion, policing, and
m arking; m apping, queuing, and scheduling; and Aut oQoS) is available as part of t he Enhanced
I m age. Therefore, it is recom m ended t o use t he EI on t he 2950 wit hin a QoS- enabled cam pus
design. For t he rem ainder of t his discussion, it is assum ed t hat t he Cat alyst 2950 is running an
Enhanced I m age.

Catalyst 2950 Classification, Marking, and Mapping

Two m et hods of classificat ion are available on t he 2950: on a physical int erface basis ( no
support exist s for VLAN- based classificat ion) and on an MQC/ ACL basis.

By default , physical int erfaces are unt rust ed, but t hey can be configured t o t rust CoS or t o t rust
DSCP. At t he t im e of writ ing, t he 2950 does not support t he full DSCP range; it support s only t he
following values: 0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48, and 56.

Trust boundaries can be ext ended t o I P phones t hat are connect ed t o t he int erface. The swit ch
uses Cisco Discovery Prot ocol ( CDP) t o det ect t he presence of I P phones.
 N ot e
I n t he fut ure, digit al cert ificat es will be exchanged bet ween t he swit ch and t he I P
phone t o verify t hat an I P phone indeed is connect ed t o t he swit ch and is not a hacker
spoofing CDP.

I n Exam ple 10- 1, t rust is set for CoS, and t he t rust boundary has been ext ended t o any
connect ed I P phones. The r a n ge keyword is used t o configure m ult iple int erfaces at once.

Ex a m ple 1 0 - 1 . Con figu r in g Tr u st a n d Tr u st Ex t e n sion s on a Ca t a lyst

2950

CAT2950(config)#interface range FastEthernet 0/12 - 24

CAT2950(config-if-range)#mls qos trust cos
CAT2950(config-if-range)#mls qos trust device cisco-phone

MQC- based class m aps and policy m aps also can be used wit h ACLs t o m ark t raffic on ingress on
t he 2950. ACLs support ed are st andard I P ACLs, ext ended I P ACLs, and Layer 2 MAC ACLs.

I n Exam ple 10- 2, an access list ident ifies UDP t raffic sourced from an I P/ TV server
( 10.200.200.200) . A class m ap references t his ACL and applies a m arking policy t o t raffic t hat
m at ches t his crit erion, m arking t hese flows t o DSCP CS4 ( 32.)

Ex a m ple 1 0 - 2 . Con figu r in g M QC/ ACL Cla ssifica t ion on t h e Ca t a lyst

2950

CAT2950(config)#access-list 100 permit udp 10.200.200.200 255.255.255.255 any

CAT2950(config)#class-map IPTV
CAT2950(config-cmap)#match access-group 100
CAT2950(config-cmap)#exit
CAT2950(config)#policy-map MARK-IPTV-DSCP-CS4
CAT2950(config-pmap)#class IPTV
CAT2950(config-pmap-c)#set ip dscp 32
CAT2950(config-pmap-c)#interface FastEthernet 0/1
CAT2950(config-if)#service-policy input MARK-IPTV-DSCP-CS4

The default CoS- t o- DSCP m ap for t he Cat alyst 2950 is shown in Table 10- 1 . This default CoS- t o-
DSCP m apping is act ually t he sam e across all Cat alyst plat form s: The CoS bit s are com bined
wit h t hree t railing zeros ( in binary) t o form t he default DSCP value ( in decim al, t he equivalent
conversion is achieved by m ult iplying t he CoS value by 8) .
 Ta ble 1 0 - 1 . Cisco Ca t a lyst
Pla t for m s D e fa u lt CoS- t o- D SCP
Map

CoS 0 1 2 3 4 5 6 7
Va lu e

D SCP 0 8 16 24 32 40 48 56
Va lu e

The default DSCP- t o- CoS m apping t able for t he 2950 is shown in Table 10- 2 . Not ice t hat not all
DSCP values are included or support ed on t he Cat alyst 2950.

Ta ble 1 0 - 2 . Ca t a lyst 2 9 5 0 D e fa u lt D SCP- t o- CoS

Map

D SCP 0 8, 16, 24, 32, 40, 48 56

Va lu e s 10 18 26 34 46
CoS 0 1 2 3 4 5 6 7
Va lu e s

These m apping values can be m odified away from t he default set t ings. As shown in Exam ple 10-
3, CoS 5 is m apped t o DSCP 46 ( EF) , and DSCP CS1 ( 8) is m apped t o CoS 0. I n t he first m ap
( CoS t o DSCP) , eight separat e values m ust be supplied ( in order) t hat are t o correspond t o t he
CoS values of 0 t hrough 7. Not ice t hat t he sixt h value ( corresponding t o CoS 5) is m odified away
from t he default ( 40) and explicit ly is set t o 46 ( DSCP EF) . Wit h t he second m apping, up t o 13
DSCP values ( separat ed by spaces) can be m apped t o a CoS value, which follows t he t o
keyword.

Ex a m ple 1 0 - 3 . Con figu r in g M a ppin g M odifica t ion s on t h e Ca t a lyst 2 9 5 0

CAT2950(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56

CAT2950(config)#mls qos map dscp-cos 8 to 0

Catalyst 2950 Policing and Markdown

Policing can be applied only on ingress on t he Cat alyst 2950. The Cat alyst 2950 support s only
individual policing. Only 60 policers are support ed on Gigabit Et hernet port s, only 6 policers are
support ed on Fast Et hernet port s on t he 2950, and granularit y for average burst is lim it ed t o 8-
Mbps increm ent s for Gigabit Et hernet port s and 1- Mbps increm ent s for Fast Et hernet port s.

I n Exam ple 10- 4, all t raffic offered t o an int erface range ( Fast Et hernet 0/ 2 t hrough 0/ 4) is
policed t o 25 Mbps, beyond which it is dropped.
Ex a m ple 1 0 - 4 . Con figu r in g I n dividu a l Policin g on t h e Ca t a lyst 2 9 5 0

CAT2950(config)#access-list 1 permit any

CAT2950(config)#class-map ANY
CAT2950(config-cmap)#match access-group 1
CAT2950(config-cmap)#exit
CAT2950(config)#policy-map POLICE-TO-25MBS
CAT2950(config-pmap)#class ANY
CAT2950(config-pmap-c)#police 25000000 16384 exceed-action drop
CAT2950(config)#interface range FastEthernet 0/2 - 4
CAT2950(config-if-range)#service-policy input POLICE-TO-25MBS

Catalyst 2950 Queuing

The Cat alyst 2950 support s four egress queues but no drop t hresholds ( besides t he t ail of t he
queue) . These queues can be configured t o schedule using one of t wo algorit hm s: weight ed
round- robin ( WRR) scheduling ( 4Q1T) or st rict - priorit y scheduling ( 1P3Q1T) . The default
scheduling algorit hm is st rict priorit y.

Scheduling weight s per queue are set by t he w r r - qu e u e ba n dw idt h weight 1 weight 2 weight 3
weight 4 com m and, wit h weight s 1 t hrough 4 represent ing t he weight s for each queue,
respect ively. The approxim at e bandwidt h allocat ion per queue is t he queue's weight divided by
t he sum of all weight s. When t he weight for queue 4 ( weight 4) is set t o 0, t he scheduler is
operat ing in st rict - priorit y fashion, wit h queue4 enabled as t he expedit e queue.

I n Exam ple 10- 5, t he scheduler is operat ing in st rict - priorit y m ode, wit h queue 4 as t he expedit e
queue ( configured by set t ing weight 4 t o equal 0) . The rem aining bandwidt h is divided am ong
queue 1 ( 25 percent ) , queue 2 ( 20 percent ) , and queue 3 ( 55 percent ) . These percent ages are
derived from t he weight of t he queue divided by t he sum of all weight s ( 5 / [ 5 + 4 + 11] ) and ( 4
/ [ 5 + 4 + 11] ) and ( 11 / [ 5 + 4 + 11] ) , respect ively.

Ex a m ple 1 0 - 5 . Con figu r in g t h e Ex pe dit e Qu e u e a n d W RR Pr ior it y on

t h e Ca t a lyst 2 9 5 0

CAT2950(config)#wrr-queue bandwidth 5 4 11 0

Finally, CoS values m ust be assigned t o t he desired queues. By default , CoS 0 and 1 are
assigned t o queue 1, CoS 2 and 3 are assigned t o queue 2, CoS 4 and 5 are assigned t o queue
3, and CoS 6 and 7 are assigned t o queue 4. Usually, however, it is desirable t o send only CoS 5
( voice) t o t he expedit e queue ( queue 4) , reassigning CoS 6 and 7 t o queue 3. This m odificat ion
of t he CoS- t o- queue m apping can be m ade wit h t he w r r - qu e u e cos- m a p com m and, as shown
in Exam ple 10- 6.

Ex a m ple 1 0 - 6 . Con figu r in g CoS- t o- Qu e u e M a ppin g on t h e Ca t a lyst

2950
Catalyst 3550
The Cat alyst 3550, shown in Figure 10- 10 , is found in bot h t he access layer and t he dist ribut ion
layer as it support s I P rout ing. Many of t he 3550's QoS feat ures and synt ax are ident ical t o t he
2950, but a few idiosyncrasies and ext ra feat ures are unique t o t he 3550.

Figu r e 1 0 - 1 0 . Cisco Ca t a lyst 3 5 5 0 Se r ie s

For exam ple, by default , QoS is disabled on t he 3550 and m ust be enabled m anually for any
classificat ion or queuing t o occur. Furt herm ore, enabling QoS on t he 3550 on som e versions of
soft ware requires disabling I EEE 802.3X flow cont rol on all int erfaces, as shown in Exam ple 10- 7
.

Ex a m ple 1 0 - 7 . En a blin g QoS Globa lly on a Ca t a lyst 3 5 5 0

CAT3550(config)#interface range FastEthernet 0/1 - 24

CAT3550(config-if-range)#flowcontrol receive off ! Disables flowcontrol
CAT3550(config-if-range)#flowcontrol send off ! Disables flowcontrol
CAT3550(config-if-range)#exit
CAT3550(config)#mls qos ! Enables QoS globally

When flow cont rol has been disabled on all int erfaces and QoS has been enabled globally, all
ot her QoS feat ures becom e available.

Feat ures and synt ax t hat are ident ical t o t he 2950 are not repeat ed in t he following sect ions;
only feat ures and synt ax t hat are unique t o t he 3550 are det ailed in t he following exam ples.
Catalyst 3550 Classification, Marking, and Mapping
Classificat ion on a per- port level and a per- port , per- VLAN basis is support ed on t he Cat alyst
3550. Classificat ion also can be perform ed t hrough port t rust st at es or t hrough MQC and ACLs.
As wit h t he 2950, support ed ACL t ypes are I P st andard, I P ext ended, or a MAC ACL.

Sim ilar t o t he 2950, t he 3550 can t rust CoS or DSCP and also lim it s t rust t o select devices, as a
Cisco I P phone does. Furt herm ore, t he 3550 support s t he capabilit y t o t rust I P Precedence,
which m ight be required when int erfacing wit h t hird- part y I P Telephony devices. Exam ple 10- 8
shows how t o enable I P Precedence t rust on a 3550.

Ex a m ple 1 0 - 8 . Con figu r in g I P Pr e ce de n ce Tr u st on a Ca t a lyst 3 5 5 0

CAT3550(config)#interface range FastEthernet 0/1 - 24

CAT3550(config-if-range)#mls qos trust ip-precedence

Classificat ion t hrough MQC and ACLs is ident ical t o t hat for t he 2950.

The default CoS- t o- DSCP m ap on t he 3550 is t he sam e as on all Cat alyst plat form s ( previously
shown in Table 10- 1 ) . The default DSCP- t o- CoS m aps, shown in Table 10- 3 , are slight ly
different on t he 3550 t han t he 2950 because t he full DSCP range is support ed on t he 3550.

D SCP Va lu e

0 to 7

8 t o 15

16 t o 23

24 t o 31

32 t o 39

40 t o 47

48 t o 55

56 t o 63

CoS Va lu e

5
6

Ta ble
10-3.
Ca t a lyst
3500
Defa ult
D SCP-
t o- CoS
Map

Addit ionally, t he 3550 support s an I P Precedence- t o- DSCP m ap, which is essent ially ident ical t o
t he CoS- t o- DSCP m ap, wit h t he except ion t hat CoS values are replaced wit h I P Precedence
values.

Mapping m odificat ions can be configured ident ically t o t hose on t he 2950.

A new t ype of m apping, DSCP- t o- DSCP m apping, can be configured on a Cat alyst 3550. These
m aps, known as DSCP m ut at ion m aps, j oin aut onom ous DiffServ dom ains. Alt hough all m aps
except DSCP m ut at ion m aps are defined globally, DSCP m ut at ion m aps are applied on a per-
int erface basis ( specifically, on t he int erface t hat serves as t he border bet ween DiffServ
dom ains) . Act ually, m ore t han one DSCP m ut at ion m ap can be defined when m ore t han t wo
aut onom ous DiffServ dom ains are being j oined on a single 3550.

I n Exam ple 10- 11 , PHBs AF21, AF22, and AF23 from one DiffServ dom ain are m apped t o AF11,
AF12, and AF13 in t he adj oining DiffServ dom ain. The int erface j oining t hese DiffServ dom ains is
Gigabit 0/ 3.

Figu r e 1 0 - 1 1 . D SCP M u t a t ion Applica t ion Ex a m ple

[View full size image]

The configurat ion required for such m apping on t he border 3550 in DiffServ dom ain 1 is shown
in Exam ple 10- 9 .

Ex a m ple 1 0 - 9 . Con figu r in g D SCP M u t a t ion on a Ca t a lyst 3 5 5 0

 CAT3550(config)#mls qos map dscp-mutation DIFFSERV1-TO-DIFFSERV2 18 to 10
CAT3550(config)#mls qos map dscp-mutation DIFFSERV1-TO-DIFFSERV2 20 to 12
CAT3550(config)#mls qos map dscp-mutation DIFFSERV1-TO-DIFFSERV2 22 to 14
CAT3550(config)#int gig 0/3
CAT3550(config-if)#mls qos trust dscp
CAT3550(config-if)#mls qos dscp-mutation DIFFSERV1-TO-DIFFSERV2

A com plem ent ary policy would be required on t he border swit ch for t he second DiffServ dom ain
t o m ap in t he reverse direct ion.

Catalyst 3550 Policing and Markdown

The 3550 support s not only ingress policing, but also egress policing on it s int erfaces.
Furt herm ore, policers can be defined as individual policers or as aggregat e policers. Aggregat e
policers are applied not t o discret e flows, but cum ulat ively t o all m at ched t raffic flows. The
aggregat e rat es for such a policer are defined globally.

The 3550 support s 128 policers on Gigabit Et hernet port s and 8 policers on Fast Et hernet port s.
Only one policer can be applied t o a packet per direct ion, and only eight policers can be defined
on an egress port .

Configuring an individual policer is slight ly different on a 3550 t han on a 2950. This is because a
policed- DSCP m ap is required t o det erm ine t he value down t o which an out - of- profile DSCP
value is t o be m arked.

I n Exam ple 10- 10 , individual Bulk Dat a t raffic flows ( m arked on a dat a cent er server connect ed
t o Fast Et hernet 0/ 12) in excess of 10 Mbps are m arked down from AF11 ( DSCP 10) t o AF12
( DSCP 12) .

Ex a m ple 1 0 - 1 0 . Con figu r in g a n I n dividu a l Police r on a Ca t a lyst 3 5 5 0

CAT3550(config)#mls qos map policed-dscp 10 to 12

CAT3550(config)#class-map match-any BULK
CAT3550(config-cmap)#match ip dscp af11
CAT3550(config)#policy-map BULK-MARKDOWN
CAT3550(config-pmap)#class BULK
CAT3550(config-pmap-c)#police 10000000 8000 exceed-action policed-dscp-transmit
CAT3550(config-pmap-c)#interface fa 0/12
CAT3550(config-if)#service-policy input BULK-MARKDOWN

The Cat alyst 3550 is t he only swit ch ( at t he t im e of writ ing) t o support per- port / per- VLAN
policing ( in t he ingress direct ion) . Per- port / per- VLAN policing requires an addit ional class m ap t o
be defined wit h a m a t ch - a ll clause and t wo m a t ch st at em ent s: one for t he VLAN t o be m at ched
and t he ot her for t he class m ap t o apply. For exam ple, if t he preceding Bulk Dat a policing policy
is t o be applied only on VLAN 10, t he per- port / per- VLAN policy would look like Exam ple 10- 11 .

Ex a m ple 1 0 - 1 1 . Con figu r in g a Pe r - Por t , Pe r - VLAN I n dividu a l Police r on

a Ca t a lyst 3 5 5 0

CAT3550(config)#mls qos map policed-dscp 10 to 12

CAT3550(config)#class-map match-any BULK
CAT3550(config-cmap)#match ip dscp af11
CAT3550(config-cmap)#class-map match-all VLAN10-BULK
CAT3550(config-cmap)#match vlan 10
CAT3550(config-cmap)#match class-map BULK
CAT3550(config-cmap)#policy-map VLAN10-BULK-MARKDOWN
CAT3550(config-pmap)#class VLAN10-BULK
CAT3550(config-pmap-c)#police 10000000 8000 exceed-action policed-dscp-transmit
CAT3550(config-pmap-c)#interface fa 0/12
CAT3550(config-if)#service-policy input VLAN10-BULK-MARKDOWN

I n addit ion t o individual policers, an aggregat e policer can be applied t o an access- t o- dist ribut ion
uplink on egress t o m ark down cum ulat ively out - of- profile t raffic. Building on t he previous
exam ple, all Bulk Dat a t raffic in excess of 100 Mbps ( regardless of how m any flows are involved)
is m arked down t o AF12 on t he Gigabit 0/ 2 uplink. The policed- DSCP m ap does not need t o be
redefined, but it can be leveraged by bot h individual and aggregat e policers, as shown in
Exam ple 10- 12 .

Ex a m ple 1 0 - 1 2 . Con figu r in g a n Aggr e ga t e Police r on a Ca t a lyst 3 5 5 0

CAT3550(config-if)#mls qos aggregate-policer BULK-MARKDOWN-AGG 1000000000 8000

exceed-action policed-dscp-transmit
CAT3550(config)#policy-map BULK-MARKDOWN-AGG
CAT3550(config-pmap)#class BULK
CAT3550(config-pmap-c)#police aggregate BULK-MARKDOWN-AGG
CAT3550(config-pmap-c)#int gig 0/2
CAT3550(config-if)#service-policy output BULK-MARKDOWN-AGG

Catalyst 3550 Queuing and Dropping

The 3550 has four egress queues, one of which ( queue 4) can be configured as a st rict - priorit y
queue t hat ( unlike t he 2950) is not enabled by default but t hat needs t o be enabled on a per-
int erface basis wit h t he pr ior it y- qu e u e ou t com m and. An exam ple of enabling t he st rict - priorit y
queue on a Gigabit Et hernet uplink is shown in Exam ple 10- 13 .

Ex a m ple 1 0 - 1 3 . Con figu r in g a St r ict - Pr ior it y Qu e u e on a Ca t a lyst 3 5 5 0

CAT3550(config)#int gig 0/1

CAT3550(config-if)#priority-queue out

As wit h t he 2950, weight s can be configured t o allocat e bandwidt h t o each queue by t he

weight ed round- robin scheduler. The synt ax is ident ical t o t hat of t he 2950, except t hat if a
st rict - priorit y queue has been enabled on an int erface, t he value for weight 4 sim ply is ignored.

N ot e
Queue lim it s also can be t uned away from default s using t he w r r - qu e u e qu e u e - lim it
com m and. The default queue lim it s are such t hat each queue is assigned 25 percent of
t he available buffer space.

I t should be not ed t hat when t he queue lim it s are m odified, t he queue t em porarily is
shut down during t he hardware reconfigurat ion, and t he swit ch m ay drop newly arrived
packet s dest ined t o t he queue.

CoS values are assigned t o t heir respect ive queues using t he w r r - qu e u e cos- m a p com m and. A
difference bet ween t he Cat alyst 3550 and t he 2950 is t hat t he CoS- t o- queue m aps are defined
on a per- int erface basis on t he 3550 ( not globally, as on a Cat alyst 2950) .

By default , CoS 0 and 1 are assigned t o queue 1, CoS 2 and 3 are assigned t o queue 2, CoS 4
and 5 are assigned t o queue 3, and CoS 6 and 7 are assigned t o queue 4. Usually, it is desirable
t o send only CoS 5 ( voice) t o t he expedit e queue ( queue 4) and t o reassign CoS 6 and 7 t o
queue 3. This m odificat ion of t he CoS- t o- queue m apping can be m ade wit h t he w r r - qu e u e cos-
m a p int erface com m and on t he 3550, as shown in Exam ple 10- 14 .

A QoS feat ure t hat t he 3550 enj oys t hat t he 2950 does not is t he capabilit y t o support
configurable drop t hresholds per queue on Gigabit Et hernet port s. Therefore, Cat alyst 3550
Gigabit Et hernet port s can be configured t o operat e in a 4Q2T or 1P3Q2T m anner, while Cat alyst
3550 Fast Et hernet port s can be configured t o operat e in a 4Q1T or 1P3Q1T m anner.

Ex a m ple 1 0 - 1 4 . Con figu r in g CoS- t o- Qu e u e M a ppin g on t h e Ca t a lyst

3550

CAT3550(config)#int gig 0/1

CAT3550(config-if)#wrr-queue cos-map 4 5 ! Assigns CoS 5 to queue 4
CAT3550(config-if)#wrr-queue cos-map 3 6 7 ! Reassigns CoS 6 and 7 to queue 3

These drop t hresholds can be configured in one of t wo ways: t ail drop or WRED.

Tail drop is t he default congest ion- avoidance t echnique on Gigabit - capable Et hernet port s. Wit h
t ail drop, packet s are queued unt il t he t hresholds are exceeded. Specifically, all packet s wit h
DSCPs assigned t o t he first t hreshold are dropped unt il t he t hreshold no longer is exceeded.
However, packet s assigned t o t he second t hreshold cont inue t o be queued and sent as long as
t he second t hreshold is not exceeded.

You can m odify t he t wo t ail- drop t hreshold percent ages assigned t o t he four egress queues by
using t he w r r - qu e u e t h r e sh old int erface configurat ion com m and. Each t hreshold value is a
percent age of t he t ot al num ber of allocat ed queue descript ors for t he queue. The default
t hreshold is 100 percent for t hresholds 1 and 2.

Alt ernat ely, you can enable WRED and configure t he t wo t hreshold percent ages assigned t o t he
four egress queues on a Gigabit - capable Et hernet port by using t he w r r - qu e u e r a n dom - de t e ct
m a x - t h r e sh old int erface configurat ion com m and. Each t hreshold percent age represent s where
WRED st art s t o random ly drop packet s. Aft er a t hreshold is exceeded, WRED random ly begins t o
drop packet s assigned t o t his t hreshold. As t he queue lim it is approached, WRED cont inues t o
drop m ore packet s. When t he queue lim it is reached, WRED drops all packet s assigned t o t he
t hreshold. By default , WRED is disabled.

I f you use WRED t hresholds, you cannot use t ail drop, and vice versa. I f WRED is disabled, t ail
drop aut om at ically is enabled wit h t he previous configurat ion.

You m odify t he DSCP- t o- t hreshold m ap t o det erm ine which DSCPs are m apped t o which
t hreshold I D by using t he w r r - qu e u e dscp- m a p int erface configurat ion com m and. By default ,
all DSCPs are m apped t o t hreshold 1; when t his t hreshold is exceeded, all t he packet s random ly
are dropped.

I n Exam ple 10- 15 , WRED is enabled on t he t hree rem aining queues ( because queue 4
previously was enabled as t he expedit e/ st rict - priorit y queue) . The first t hreshold for each
rem aining queue is set t o 40 percent , and t he second t hreshold is set t o 100 percent ( t he t ail of
t he queue) . DSCP values of AF12, AF22, AF32, and AF42 ( 12, 20, 28, and 36, respect ively) are
m apped t o t he first t hresholds. All ot her relevant DSCPs have been m apped t o t he second
t hreshold. Because t he com m and allows only eight DSCP values t o be m apped t o a t hreshold per
com m and, a second ent ry is needed t o m ap values DSCP values CS6 ( 48) and CS7 ( 56) t o t he
second t hreshold.

Ex a m ple 1 0 - 1 5 . Con figu r in g W RED Th r e sh olds a n d D SCP- t o- Th r e sh old

M a ps on a Ca t a lyst 3 5 5 0 Giga bit Et h e r n e t I n t e r fa ce

CAT3550(config)#int gig 0/1

CAT3550(config-if)#wrr-queue random-detect max-threshold 1 40 100
CAT3550(config-if)#wrr-queue random-detect max-threshold 2 40 100
CAT3550(config-if)#wrr-queue random-detect max-threshold 3 40 100
CAT3550(config-if)#wrr-queue dscp-map 1 12 20 28 36
CAT3550(config-if)#wrr-queue dscp-map 2 8 10 16 18 24 26 32 34
CAT3550(config-if)#wrr-queue dscp-map 2 48 56
Catalyst 2970, 3650, and 3750
The Cisco Cat alyst 2970 series swit ches are ent ry- level Gigabit Et hernet swit ches t hat deliver
wire- speed int elligent services for sm all and m edium businesses and ent erprise branch offices.

The Cat alyst 2970 is available wit h Enhanced I m age ( EI ) Cisco I OS Soft ware, which support s a
rich QoS feat ures set . Addit ionally, t he 2970 support s ident it y- based net work services,
enhancing t he securit y of converged voice, video, and dat a net works, as in VoI P.

The Cisco Cat alyst 3560 series swit ches is a line of fixed configurat ion, ent erprise- class, I EEE
802.3af, and Cisco prest andard Power over Et hernet ( PoE) swit ches. The Cat alyst 3560 fit s well
in sm all ent erprise wiring closet s or branch office environm ent s t hat are using t heir LAN
infrast ruct ure for t he deploym ent of I P phones, wireless access point s, video surveillance,
building m anagem ent syst em s, and rem ot e video kiosks. While t he Cat alyst 3560 support s I P
Rout ing, it is bet t er suit ed t o t he access layer ( when L3 is deployed t o t he wiring closet ) t han t he
dist ribut ion layer because it s inline power capabilit ies are rarely required at t he dist ribut ion
layer.

The Cisco Cat alyst 3750 series swit ches represent t he next st ep in t he evolut ion of deskt op
swit ches and feat ure Cisco St ackWise t echnology. Cisco St ackWise t echnology unit es up t o nine
individual Cisco Cat alyst 3750 swit ches int o a single logical unit , using special st ack- int erconnect
cables and st acking soft ware ( t he st ack int erconnect is 32 Gbps) . The st ack behaves as a single
swit ching unit t hat is m anaged by a m ast er swit ch elect ed from one of t he m em ber swit ches.
The m ast er swit ch aut om at ically creat es and updat es all t he swit ching and opt ional rout ing
t ables. A working st ack can accept new m em bers or delet e old ones wit hout service int errupt ion.
Thus equipped, t he Cat alyst 3750 is opt im ized for high- densit y Gigabit Et hernet deploym ent s
and is suit able for access and dist ribut ion layer deploym ent s, or even sm all- net work core- layer
requirem ent s.

The Cat alyst 3560 and 3750 series swit ches are available in t he St andard Mult ilayer Soft ware
I m age ( SMI ) or t he Enhanced Mult ilayer Soft ware I m age ( EMI ) . The SMI feat ure set includes all
support ed QoS t ools and basic st at ic and RI P rout ing funct ionalit y. The EMI provides a richer set
of ent erprise- class feat ures, including advanced hardware- based I P unicast and m ult icast
r out ing.

From a QoS perspect ive, t he Cat alyst 2970, 3560, and 3750 are ident ical and are considered
t oget her in t his discussion. The Cat alyst 2970 and 3750 swit ches are shown in Figure 10- 12.

Figu r e 1 0 - 1 2 . Cisco Ca t a lyst 2 9 7 0 a n d 3 7 5 0 Se r ie s Sw it ch e s

By default , QoS is disabled on t he 2970/ 3560/ 3750 plat form s and m ust be enabled explicit ly
wit h t he global m ls qos com m and.

Catalyst 2970/3560/3750 Classification, Marking, and Mapping

The Cat alyst 2970/ 3560/ 3750 share m any com m on QoS feat ures and synt ax wit h t he Cat alyst
3550. Wherever feat ure funct ionalit y and synt ax are ident ical t o t hose of t he 3550, det ails and
configurat ion exam ples are not repeat ed in t his sect ion.

Trust st at es and MQC/ ACL classificat ion and m arking on t he Cat alyst 2970/ 3560/ 3750 are
ident ical in funct ion and synt ax t o t he 3550.

All Cat alyst 2970/ 3560/ 3750 default CoS- t o- DSCP, I P Precedence- t o- DSCP, and DSCP- t o- CoS
m aps are ident ical t o t hose for t he 3550, as are m apping funct ions and synt ax ( including DSCP
m ut at ion) .

Catalyst 2970/3560/3750 Policing and Markdown

Policing and m arkdown funct ionalit y and synt ax on t he 2970/ 3560/ 3750 are ident ical t o t hose of
t he 3550, wit h t he except ion t hat t he 2970/ 3560/ 3750 current ly do not support per- Port / per-
VLAN policing.

The 2970/ 3560/ 3750 support 64 policers per int erface. However, whereas t he configurable lim it
on t he num ber of policers per int erface is 64, t he m axim um num ber of policers per port ASI C is
256. This lim it present t he opt ions in t he following list .

On a 24- port 10/ 100 + 2 Sm all Form - Fact or Pluggable ( SFP) m odules chassis, t here is one
port ASI C. This m eans t hat t hat t he 256 policers m ust be shared am ong 26 port s, wit h any
1 port having a m axim um of 64 policers. However, if you configure four port s wit h 64
policers each, t here will be no m ore policers left for any ot her port s on t he chassis.

On a 48- port 10/ 100 + 4 SFP chassis, t here are t wo port ASI Cs. This m eans t hat you have
t wo " set s" of 24 10/ 100 + 2 SFP port s int ernal t o t he swit ch. Each " set " of port s support s a
t ot al of 256 policers. So, once again, t he m axim um policers on a port is 64, but t he
m axim um for each ASI C is 256.

These considerat ions should be kept in m ind when designing for policing needs using t he
Cat alyst 2970/ 3560/ 3750 swit ch.
Catalyst 2970/3560/3750 Queuing and Dropping
Up t o t his point in t he discussion, t he Cat alyst 2970, 3560 and 3750 series swit ches have been
shown t o be rem arkably ident ical t o t he Cat alyst 3550 in t erm s of QoS feat ures, funct ionalit y,
and synt ax. However, t he plat form s differ significant ly when it com es t o queuing.

The first m aj or difference in queuing bet ween t he plat form s is t hat t he 2970/ 3560/ 3750 support
ingress scheduling. However, ingress scheduling rarely is required because it provides benefit s
only if t he ( com bined) input rat es from any port s exceed t he swit ching fabric rat e of t he swit ch.
This is ext rem ely rare in m ost cam pus environm ent s.

The Cat alyst 2970/ 3560/ 3750 also support s four egress queues, one of which can be configured
as an expedit e/ priorit y queue t hrough t he pr ior it y- qu e u e ou t int erface com m and. I ncident ally,
on t he Cat alyst 2970/ 3560/ 3750, queue 1, not queue 4 ( as on t he 3550 and 2950) is used as an
expedit e queue ( when configured) .

Nonpriorit y queues are serviced t hrough a shaped round- robin ( SRR) algorit hm t hat can be
configured t o operat e in one of t wo m odes: shaped or sharing.

Act ually, bot h t he ingress and egress queues are serviced by SRR, which det erm ines t he rat e at
which packet s are sent . On t he ingress queues, SRR sends packet s t o t he st ack ring. On t he
egress queues, SRR sends packet s t o t he egress int erface. For ingress queues, sharing is t he
default m ode and is t he only m ode support ed.

I n shaped m ode, t he egress queues are guarant eed a percent age of t he bandwidt h and are rat e
lim it ed t o t hat am ount . Shaped t raffic does not use m ore t han t he allocat ed bandwidt h even if
t he link is idle. Shaping provides a m ore even flow of t raffic over t im e and reduces t he peaks
and valleys of burst y t raffic. Wit h shaping, t he absolut e value of each weight is used t o com put e
t he bandwidt h available for t he queues.

I n shared m ode, t he queues share t he bandwidt h am ong t hem according t o t he configured

weight s. The bandwidt h is guarant eed at t his level but is not lim it ed t o it . For exam ple, if a
queue is em pt y and no longer requires a share of t he link, t he rem aining queues can expand int o
t he unused bandwidt h and can share it am ong t hem . Wit h sharing, t he rat io of t he weight s
det erm ines t he frequency of dequeuing; t he absolut e values are m eaningless.

Addit ionally, bot h t he ingress and egress queues use an enhanced version of t he t ail- drop
congest ion- avoidance m echanism called weight ed t ail drop ( WTD) . As a fram e is enqueued t o a
part icular queue, WTD uses t he fram e's assigned CoS value or DSCP value t o assign it t o
different t hresholds. I f t he t hreshold is exceeded for t hat CoS or DSCP value, t he swit ch drops
t he fram e. Each queue support s ( up t o) t hree WTD t hresholds: Two are configurable ( explicit
WTD t hresholds) , and t he t hird is nonconfigurable ( im plicit WTD t hreshold) and is preset t o t he
queue- full st at e ( 100 percent ) .

Thus, Cat alyst 2970/ 3560/ 3750 swit ches can be configured t o operat e in 4Q3T m ode or 1P3Q3T
m ode. The Cat alyst 2970/ 3560/ 3750 also support s t wo queue set s, m eaning t hat different
int erfaces can be configured t o operat e in different queuing m anners. For exam ple, som e
int erfaces m ight be configured t o operat e in 4Q3T, and ot hers m ight be configured t o operat e in
1P3Q3T, depending on which queue set I D ( qset - id) t hey are assigned t o.

The allocat ed m em ory assigned t o each queue can be m odified ( from t he default 25 percent per
queue) by using t he m ls qos qu e u e - se t ou t pu t qset - id bu ffe r s allocat ion1 ... allocat ion4
global configurat ion com m and. The sum of all t he allocat ed buffers represent s t he reserved pool,
and t he rem aining buffers are part of t he com m on pool.

The Cat alyst 2970/ 3560/ 3750 swit ches use a buffer- allocat ion schem e t o reserve a m inim um
num ber of buffers for each egress queue, t o prevent any queue or port from consum ing all t he
buffers and depriving ot her queues, and t o det erm ine whet her t o grant buffer space t o a
request ing queue. The swit ch det erm ines whet her t he t arget queue has not consum ed m ore
buffers t han it s reserved am ount ( under lim it ) , whet her it has consum ed all of it s m axim um
buffers ( over lim it ) , or whet her t he com m on pool is em pt y ( no free buffers) or not em pt y ( free
buffers) . I f t he queue is not over lim it , t he swit ch can allocat e buffer space from t he reserved
pool or from t he com m on pool ( if it is not em pt y) . I f t here are no free buffers in t he com m on
pool, or if t he queue is over lim it , t he swit ch drops t he fram e.

You guarant ee t he availabilit y of buffers, set drop t hresholds, and configure t he m axim um
m em ory allocat ion for a queue set by using t he following global configurat ion com m and:

mls qos queue-set output qset-id threshold queue-id drop-threshold1

drop-threshold2 reserved-threshold maximum-threshold

Each t hreshold value is a percent age of t he queue's allocat ed m em ory.

I n Exam ple 10- 16, queue set 1 has buffers allot t ed am ong queues 1 t hrough 4 by t he
percent ages 35, 30, 25, and 10. I f 400 buffers are available, t his would t ranslat e t o an allocat ion
of 140, 120, 100, and 40 buffers t o queues 1 t hrough 4, respect ively. Also, WTD t hresholds on
queues 2 t hrough 4 have been set t o 40 percent of t he buffer dept h and 100 percent of t he
buffer dept hs. Each queue has it s buffer allocat ion fully reserved ( 100 percent ) and has it s
m axim um m em ory t hreshold also set t o 100 percent . Addit ionally, each queue has it s reserved
t hreshold ( an am ount of m em ory t o be guarant eed or reserved for t he queuet he range is 1 t o
100 percent ) set t o 100 percent . Furt herm ore, each queue has it s m axim um t hreshold ( which
enables a queue in t he full condit ion t o obt ain m ore buffers t han are reserved for it and is t he
m axim um m em ory t hat t he queue can have before t he packet s are droppedt he range is 1 t o 400
percent ) set t o 100 percent .

Finally, Fast Et hernet 0/ 1 on t he swit ch t hat has been designat ed as st ack m em ber 2 is assigned
t o queue set 1, and queue 1 ( of queue set 1) is defined as an expedit e/ priorit y queue.

Ex a m ple 1 0 - 1 6 . Con figu r in g Pe r - Qu e u e Bu ffe r Alloca t ion s a n d

Th r e sh olds on a Ca t a lyst 2 9 7 0 / 3 5 6 0 / 3 7 5 0

CAT3750(config)#mls qos queue-set output 1 buffers 35 30 25 10

CAT3750(config)#mls qos queue-set output 1 threshold 2 40 100 100 100
CAT3750(config)#int fa 2/0/1
CAT3750(config-if)#queue-set 1
CAT3750(config-if)#priority-queue out

Sim ilar t o WRR, SRR allows t he weight s assigned t o each queue t o be m odified. The rat io of
t hese weight s det erm ines t he frequency by which t he SRR scheduler sends packet s out from
each queue. Shaping weight s sm oot h or rat e lim it burst y or dom ineering flows. The inverse rat io
( 1/ weight ) det erm ines t he shaping bandwidt h for each queue. For exam ple, if a queue is t o be
lim it ed t o 10 percent , t he shaping weight for t hat queue is set t o 10. A shaping weight of 0
m eans t hat t he queue is operat ing in sharing m ode. Shaped m ode overrides shared m ode.

I n shared m ode, t he queues share t he bandwidt h am ong t hem according t o t he configured

weight s. The bandwidt h is guarant eed at t his level but is not lim it ed t o it . For exam ple, if a
queue em pt ies and does not require a share of t he link, t he rem aining queues can expand int o
t he unused bandwidt h and share it am ong t hem . Wit h sharing, t he rat io of t he weight s
det erm ines t he frequency of dequeuing; t he absolut e values are m eaningless.

I f an expedit e queue has been configured, t his st rict - priorit y designat ion overrides any SRR
weight s for queue 1.

I n Exam ple 10- 17, t he queues are assigned 35 percent , 30 percent , 25 percent , and 10 percent
shared bandwidt h allocat ions. But , in act ualit y, queue 1's bandwidt h allocat ion is ignored
because it is configured as a st rict - priorit y queue. Queues 2 and 3 are operat ing in shared m ode
( because t heir shaped weight is set t o 0) . Queue 4 is operat ing in shaped m ode ( shaped weight
overrides shared weight ) and is lim it ed t o no m ore t han 10 percent of t he bandwidt h, regardless
of whet her m ore is available.

Ex a m ple 1 0 - 1 7 . Con figu r in g SRR Sh a pin g a n d Sh a r in g W e igh t s on a

Ca t a lyst 2 9 7 0 / 3 5 6 0 / 3 7 5 0

CAT3750(config)#int gig 1/0/4

CAT3750(config-if)#srr-queue bandwidth share 35 30 25 10
CAT3750(config-if)#srr queue bandwidth shape 0 0 0 10
CAT3750(config-if)#queue-set 1
CAT3750(config-if)#priority-queue out

Finally, t he Cat alyst 2970/ 3560/ 3750 swit ches allow packet s t o be assigned t o queues eit her by
CoS values or by DSCP values, using CoS- t o- queue/ t hreshold m aps or DSCP- t o- queue/ t hreshold
m aps.

I n Exam ple 10- 18, DSCP EF ( 46) is assigned t o queue 1 ( t he expedit e queue) . DSCP CS7 ( 56)
and CS6 ( 48) are assigned t o queue 2 t hreshold 2, and DSCP AF31 ( 26) and DSCP CS3 are
assigned t o queue 2 t hreshold 1. DSCP 0 is assigned t o queue 3. Bulk ( DSCP AF1110) is
assigned t o queue 4 t hreshold 2, while Scavenger ( DSCP CS18) t raffic is assigned t o queue 4
t hreshold 1.

Ex a m ple 1 0 - 1 8 . Assign in g D SCP Va lu e s t o Qu e u e s/ Th r e sh olds on a

Ca t a lyst 2 9 7 0 / 3 5 6 0 / 3 7 5 0

CAT3750(config)#mls qos srr-queue output dscp-map queue 1 threshold 1 46

CAT3750(config)#mls qos srr-queue output dscp-map queue 2 threshold 2 48 56
CAT3750(config)#mls qos srr-queue output dscp-map queue 2 threshold 1 24 26
CAT3750(config)#mls qos srr-queue output dscp-map queue 3 threshold 2 0
CAT3750(config)#mls qos srr-queue output dscp-map queue 4 threshold 2 10
CAT3750(config)#mls qos srr-queue output dscp-map queue 4 threshold 1 8
Catalyst 4500
The Cisco Cat alyst 4500, shown in Figure 10- 13, finds it s niche bet ween deskt op swit ches and
t he flagship Cat alyst 6500. As such, it can be found in t he access layer, t he dist ribut ion layer,
and even t he core layer in m idsize net works. Service providers also ut ilize t he Cat alyst 4500
because of it s support of m et ro Et hernet opt ions com bined wit h it s resiliency/ failover opt ions.

Figu r e 1 0 - 1 3 . Cisco Ca t a lyst 4 5 0 0 Se r ie s

[View full size image]

QoS support for t he Cat alyst 4000 Supervisor I and I I cards ( running Cat OS) was quit e lim it ed
and, as such, is om it t ed from t his discussion. However, t he Cat alyst 4500 Supervisors I I +
t hrough V ( running Cisco I OS) boast a m uch richer QoS t oolset and are exam ined furt her.

Many of t he QoS com m ands on t he 4500 are sim ilar t o t hose on t he swit ches previously
discussed, wit h t he except ion of om it t ing t he m ls keyword at t he beginning of t he st at em ent .

For exam ple, by default , QoS is disabled on t he 4500 and m ust be enabled wit h t he global
com m and qos ( whereas, on previously discussed plat form s, t his com m and would have been m ls
qos) . When QoS is disabled, t he port int erface t rust st at es default t o Trust DSCP. When QoS is
enabled, t his t rust st at e changes t o Unt rust ed, and ( wit h no ot her QoS param et ers explicit ly
defined) all egress t raffic is m arked t o CoS 0 and DSCP 0. I ncident ally, QoS can be disabled on a
per- int erface basis using t he int erface com m and n o qos ( see Exam ple 10- 19) .

Ex a m ple 1 0 - 1 9 . En a blin g QoS on a Ca t a lyst 4 5 0 0

CAT4500(config)#qos

QoS policies can be applied t o individual port s or t o VLANs. MQC policies can be applied t o VLANs
by at t aching t he se r vice - policy st at em ent t o t he VLAN int erface and configuring all port s
belonging t o t he VLAN t o use VLAN- based QoS ( using t he qos vla n - ba se d int erface com m and) .
I f t he int erface is configured t o use VLAN- based QoS, t he t raffic received or sent t hrough t he
int erface is classified, policed, and m arked according t o t he policy m ap at t ached t o t he VLAN
( configured on t he VLAN int erface) t o which t he packet belongs. I f no policy m ap is at t ached t o
t he VLAN t o which t he packet belongs, t he policy m ap at t ached t o t he int erface is used.
Furt herm ore, VLAN- based policies supercede any policies configured on individual port s if t he
port has been assigned t o operat e in VLAN- based QoS m ode.

Catalyst 4500 Classification, Marking, and Mapping

The Cat alyst 4500 can be configured t o t rust CoS or DSCP. Addit ionally, it can be configured t o
select ively t rust a device, such as an I P phone ( t hrough CDP det ect ion) . Configuring t rust s is
very sim ilar t o previously discussed synt axes, but wit hout t he m ls keyword. Refer t o Exam ple
10- 20.

Ex a m ple 1 0 - 2 0 . En a blin g QoS on a Ca t a lyst 4 5 0 0

CAT4500(config)#interface range fa 2/1 - 48

CAT4500(config-if-range)#qos trust cos
CAT4500(config-if-range)#qos trust device cisco-phone

The configurat ion of MQC/ ACLbased classificat ion is t he sam e as in previously discussed
exam ples. However, if t he se t com m and is used in a policy m ap for m arking, I P rout ing
( disabled by default ) m ust be enabled on t he 4500. At a m inim um , t his requires enabling I P
rout ing and set t ing a default rout e t o a next - hop device capable of forwarding.

CoS- t o- DSCP m aps are t he sam e as on all Cat alyst swit ches ( shown in Table 10- 1 ) . DSCP- t o-
CoS m aps are ident ical t o t he Cisco 3550 and 3750 DSCP- t o- CoS m aps ( shown in Table 10- 3 )
because t he 4500 also support s t he full DSCP range of values ( 0 t o 63) .

As always, t hese m apping values can be m odified away from t he default set t ings. The synt ax is
again sim ilar, wit hout t he m ls keyword.

As shown in Exam ple 10- 21, CoS 5 is m apped t o DSCP 46 ( EF) , and DSCP CS1 ( 8) is m apped t o
CoS 0. I n t he first m ap ( CoS- t o- DSCP) , eight separat e values m ust be supplied ( in order) t hat
are t o correspond t o t he CoS values of 0 t hrough 7. Not ice t hat t he sixt h value ( corresponding t o
CoS 5) is m odified away from t he default ( 40) and explicit ly is set t o 46 ( DSCP EF) . Wit h t he
second m apping, up t o eight DSCP values ( separat ed by spaces) can be m apped t o a CoS value,
which follows t he t o keyword.

Ex a m ple 1 0 - 2 1 . Con figu r in g M a ppin g M odifica t ion s on t h e Ca t a lyst

4500

CAT4500(config)#qos map cos-dscp 0 8 16 24 32 46 48 56

CAT4500(config)#qos map dscp-cos 8 to 0

DSCP m ut at ion current ly is not support ed on t he Cat alyst 4500.

Catalyst 4500 Policing and Markdown
The Cat alyst 4500 support s individual and aggregat e policers, as well as port - based and VLAN-
based policing, in bot h t he ingress and egress direct ions.

The swit ch lim it s t he num ber of input policers and out put policers t o 1024 each. But in act ualit y,
because t he soft ware reserves four input policers and four out put policers for null processing,
t his leaves 1020 policers available for input policing and 1020 policers available for out put
pr ocessing.

The Cat alyst 4500 has a handy synt ax for defining bit rat es: I t uses t he prefixes k for kilo, m for
m ega, and g for giga. I nst ead of get t ing lost in zeros, a value such as 1,250,000,000 bps can be
expressed as 1.25 Gbps. This synt ax alt ernat ive can reduce configurat ion errors int roduced by
t ypos.

I n Exam ple 10- 22, individual Bulk Dat a t raffic flows ( m arked on a dat a cent er server connect ed
t o Fast Et hernet 2/ 12) in excess of 10 Mbps are m arked down from AF11 ( 10) t o AF12 ( 12) .

Ex a m ple 1 0 - 2 2 . Con figu r in g a n I n dividu a l Police r on a Ca t a lyst 4 5 0 0

CAT4500(config)#qos map dscp policed 10 to dscp 12

CAT4500(config)#class-map match-any BULK
CAT4500(config-cmap)# match ip dscp af11
CAT4500(config-cmap)#policy-map BULK-MARKDOWN
CAT4500(config-pmap)# class BULK
CAT4500(config-pmap-c)#police 10 mbps 8000 conform-action transmit
exceed-action policed-dscp-transmit
CAT4500(config-pmap-c)#int fa 2/12
CAT4500(config-if)#service-policy input BULK-MARKDOWN

I n addit ion t o individual policers, an aggregat e policer can be applied t o a Cat alyst 4500 access-
t o- dist ribut ion uplink t o m ark down cum ulat ively out - of- profile t raffic.

Building on t he previous exam ple, all Bulk Dat a t raffic in excess of 100 Mbps ( regardless of how
m any flows are involved) is m arked down t o AF12 on t he Gigabit 1/ 1 uplink. The policed- DSCP
m ap does not need t o be redefined, but bot h individual and aggregat e policers can leverage it .
Refer t o Figure 10- 23.

Ex a m ple 1 0 - 2 3 . Con figu r in g a n Aggr e ga t e Police r on a Ca t a lyst 4 5 0 0

CAT4500(config)#qos aggregate-policer BULK-MARKDOWN 100 mbps

8000 conform transmit exceed-action policed-dscp-transmit
CAT4500(config)#policy-map BULK-MARKDOWN-AGG
CAT4500(config-pmap)#class BULK
CAT4500(config-pmap-c)# police aggregate BULK-MARKDOWN-AGG
CAT4500(config-pmap-c)#int gig 1/1
CAT4500(config-if)# service-policy output BULK-MARKDOWN-AGG
Catalyst 4500 Queuing and Dropping
The Cat alyst 4500 support s four egress queues, one of which can be configured as a priorit y
queue. No t hresholds ( ot her t han t he t ail of t he queue) are configurable ( at t he t im e of writ ing) ,
allowing t he 4500 t o be configured t hrough a 4Q1T or 1P3Q1T m odel.

On t he Cat alyst 4500, Gigabit Et hernet int erfaces em ploy a queue size of 1920 packet s, and Fast
Et hernet int erfaces use a queue size of 240 packet s.

Only queue 3 can be configured as a priorit y queue.

By default , nonpriorit y queues are scheduled in a round- robin m anner and share bandwidt h
equally am ong t hem . However, bandwidt h allocat ions can be configured explicit ly on t he
following port s:

Uplink port s on supervisor engines

Port s on t he WS- X4306- GB line card

The t wo 1000BASE- X port s on t he WS- X4232- GB- RJ line card

The first t wo port s on t he WS- X4418- GB line card

The t wo 1000BASE- X port s on t he WS- X4412- 2GB- TX line card

Minim um bandwidt h allocat ions can be defined in absolut e kbps ( again, t he k , m , and g prefixes
can be used t o define t he rat e in bit s per second) . Alt ernat ively, m inim um bandwidt h allocat ions
also can be expressed as percent ages.

Com plem ent arily, each t ransm it queue can be configured t o t ransm it a m axim um rat e using t he
sh a p e com m and. This com m and enables you t o specify t he m axim um rat e of t raffic t hat t he
queue services. Any t raffic t hat exceeds t he configured shape rat e is queued and t ransm it t ed at
t he configured rat e. I f t he burst of t raffic exceeds t he size of t he queue, packet s are dropped t o
m aint ain t ransm ission at t he configured shape rat e. As wit h t he bandwidt h com m and, t he
shaped rat e can be expressed in absolut e bit s per second ( t he k , m , and g prefixes can be used
t o define t he rat e in bit s per second) or as a percent age.

I n Exam ple 10- 24, queue 3 is assigned t o be a st rict - priorit y queue. Queue 1 is assigned 30
percent of t he available bandwidt h ( aft er t he priorit y queue has been fully serviced) , and queue
2 is assigned 25 percent . Queue 4 is assigned t o be shaped t o 10 percent .

Ex a m ple 1 0 - 2 4 . Con figu r in g a Pr ior it y Qu e u e a n d Ba n dw idt h

Alloca t ion s on a Ca t a lyst 4 5 0 0

CAT4500(config)#int gig 1/1

CAT4500(config-if)#tx-queue 1
CAT4500(config-if-tx-queue)#bandwidth percent 30
CAT4500(config-if-tx-queue)#tx-queue 2
CAT4500(config-if-tx-queue)#bandwidth percent 25
CAT4500(config-if-range)#tx-queue 3
CAT4500(config-if-tx-queue)#priority high
 CAT4500(config-if-tx-queue)#tx-queue 4
CAT4500(config-if-tx-queue)#shape percent 10

The Cat alyst 4500 support s DSCP- t o- queue m aps, wit h t he default DSCP- t o- queue assignm ent
shown in Table 10- 4 .

Ta ble 1 0 - 4 . Ca t a lyst
4 5 0 0 D e fa u lt D SCP- t o-
Qu e u e M a ps

D SCP Va lu e Tr a n sm it
Qu e u e
DSCP 0- 15 Queue 1

DSCP 16- 31 Queue 2

DSCP 32- 47 Queue 3

DSCP 48- 63 Queue 4

These assignm ent s can be m odified wit h t he qos m a p dscp dscp t o t x - qu e u e queue com m and.
Up t o eight DSCP values ( separat ed by spaces) can be assigned t o a queue in a single com m and.

Cont inuing from Exam ple 10- 24, queue 1 carries Mission- Crit ical t raffic, such as Net work- Cont rol
( CS7/ 56) , Rout ing ( CS6/ 48) , Call- Signaling ( AF31/ 26) , Transact ional Dat a ( AF21/ 18) , and
Net work- Managem ent ( CS2/ 16) . Voice ( EF/ 46) is m apped t o priorit y queue 3. Queue 2 is
assigned as a Best - Effort queue ( DSCP 0) . Less- t han- best - effort t raffic, such as Bulk Dat a
( AF11/ AF12, which are DSCP 10 and 12, respect ively) and Scavenger ( CS1/ 8) t raffic, is assigned
t o queue 4.

Ex a m ple 1 0 - 2 5 . Con figu r in g D SCP- t o- Qu e u e Assign m e n t s on a Ca t a lyst

4500

CAT4500(config)#qos map dscp 56 48 26 18 16 to tx-queue 1

CAT4500(config)#qos map dscp 0 to tx-queue 2
CAT4500(config)#qos map dscp 46 to tx-queue 3
CAT4500(config)#qos map dscp 8 10 12 to tx-queue 4

As previously not ed, t he Cat alyst 4500 does not ( yet ) support drop t hresholds, but it does
support a congest ion- avoidance feat ure called dynam ic buffer lim it ing ( DBL) .

DBL t racks t he queue lengt h for each t raffic flow in t he swit ch. When t he queue lengt h of a flow
exceeds it s lim it , DBL drops packet s or set s t he explicit congest ion not ificat ion ( ECN) bit s in t he
packet headers. ECN bit s, based on RFC 3168, were covered in Chapt er 6, " Congest ion-
Avoidance Tools."
DBL classifies flows in t wo cat egories, adapt ive and aggressive. Adapt ive flows reduce t he rat e of
packet t ransm ission aft er it receives congest ion not ificat ion. Aggressive flows do not t ake
correct ive act ion in response t o congest ion not ificat ion.

Queue lengt h is m easured by t he num ber of packet s. The num ber of packet s in t he queue
det erm ines t he am ount of buffer space t hat a flow is given. When a flow has a high queue
lengt h, t he com put ed value is lowered. This enables new incom ing flows t o receive buffer space
in t he queue. This allows all flows t o get a proport ional share of packet s t hrough t he queue.

DBL, wit h ECN not ificat ion, can be enabled globally using t he com m and in Exam ple 10- 26.

Ex a m ple 1 0 - 2 6 . Con figu r in g D BL w it h ECN on a Ca t a lyst 4 5 0 0

CAT4500(config)#qos dbl exceed-action ecn

Catalyst 6500
The Cat alyst 6500, shown in Figure 10- 14 , is indisput ably Cisco's m ain swit ch and, as such,
boast s t he richest feat ure set s, not only in QoS, but in all services, such as high availabilit y,
m ult icast , securit y, and m anagem ent . I t is t he preferred swit ch in large ent erprise environm ent s
at all layers: access, dist ribut ion, and core. Addit ionally, t he Cat alyst 6500 is very prevalent in
service provider environm ent s. I n t he cont ext of our discussions, " Cat alyst 6500 " is used t o
refer t o Cat alyst 6500s wit h Supervisor 2 ( PFC2) and Cat alyst 6500s wit h Supervisor 720 ( PFC3)
because t hese are t he current versions of supervisor hardware at t he t im e of writ ing.

Figu r e 1 0 - 1 4 . Cisco Ca t a lyst 6 5 0 0 Se r ie s

[View full size image]

Hardware QoS on t he Cat alyst 6500 is perform ed principally wit hin t he Policy Feat ure Card
( PFC) , which is now in it s t hird generat ion ( wit h each successive generat ion of PFC having
progressively richer QoS feat uresrefer t o Cisco Cat alyst 6500 docum ent at ion for com plet e
det ails) .

The PFC is responsible for classificat ion, m arking, m apping, and policing. I ndividual line cards
perform t he queuing and dropping funct ions. Thus, m ult iple com binat ions of queues and
t hresholds ( varying by line card) can exist for 6500 swit ches.

On t he Cat alyst 6500, PFC QoS can be configured in one of t wo ways:

H ybr id m ode This m ode uses t he Cat alyst Operat ing Syst em ( Cat OS) t o configure t he
Supervisor and PFC. The Layer 3 forwarding engine ( t he Mult ilayer Swit ch Feat ure Card, or
MSFC) t hen is configured using Cisco I OS. The t erm hybrid is used t o convey t hat t wo
operat ing syst em s ( and t wo independent consoles) are used t o m anage t he Cat alyst 6500.

N a t ive m ode This m ode uses a single im age of Cisco I OS t o configure t he Supervisor +
PFC, along wit h t he MSFC. Only a single console is required t o m anage t he Cat alyst 6500.

N ot e
For t he QoS feat ures discussed in t his chapt er, bot h t he Cat OS and Cisco I OS
 com m ands are shown in t he exam ples.

I n bot h cases, QoS is disabled by default and needs t o be globally enabled, as shown in Exam ple
10- 27 .

Ex a m ple 1 0 - 2 7 . En a blin g QoS Globa lly on t h e Ca t a lyst 6 5 0 0 ( Ca t OS

a n d Cisco I OS)

CAT6500-CATOS> (enable) set qos enable

QoS is enabled.

CAT6500-CATOS> (enable)

CAT6500-IOS(config)#mls qos
CAT6500-IOS(config)#

QoS policies on t he 6500 can be applied at t he individual port level or on a per- VLAN basis ( but ,
by default , all port s are configured for port - based QoS) . This im plies t hat all classificat ion
policies, and m arking and policing, configured for t he port are applicable only t o t he port t o
which t hey are applied. Conversely, VLAN- based QoS enables t he adm inist rat or t o apply a
uniform policy t o all port s configured for a specific VLAN. VLAN- based QoS m ight be preferred in
cert ain sit uat ions, such as when voice VLANs have been deployed for I P Telephony
environm ent s. To alt er t he port policy from t he default port - based QoS set t ing t o VLAN- based
QoS, use t he com m ands shown in Exam ple 10- 28 .

Ex a m ple 1 0 - 2 8 . Con figu r in g VLAN - Ba se d QoS on t h e Ca t a lyst 6 5 0 0

( Ca t OS a n d Cisco I OS)

CAT6500-CATOS> (enable) set port qos 3/1 vlan-based

Qos interface is set to vlan-based for ports 3/1
CAT6500-CATOS> (enable)

CAT6500-IOS(config)#interface FastEthernet3/1
CAT6500-IOS(config-if)#mls qos vlan-based

When VLAN- based QoS has been enabled, service- policy st at em ent s are at t ached t o t he VLAN
int erfaces, which t hen apply t o all port s assigned t o t he VLAN.

Catalyst 6500 Classification, Marking, and Mapping

All Cat alyst 6500 line cards support t he t rust ing of CoS m arkings. However, not all of t hem
support DSCP t rust or I P Precedence t rust ( refer t o Cisco Cat alyst 6500 docum ent at ion for
com plet e det ails) .
By default , when QoS is enabled globally on t he 6500, t he t rust st at e of all ingress port s is
unt rust ed. I n Exam ple 10- 29 , t he default t rust st at e is changed from Unt rust ed t o Trust CoS.

Ex a m ple 1 0 - 2 9 . Con figu r in g Tr u st on t h e Ca t a lyst 6 5 0 0 ( Ca t OS a n d

Cisco I OS)

CAT6500-CATOS> (enable) set port qos 3/1 trust trust-cos

Port 3/1 qos set to trust-cos
CAT6500-CATOS> (enable)

CAT6500-IOS(config)#interface FastEthernet3/1
CAT6500-IOS(config-if)#mls qos trust cos
CAT6500-IOS(config-if)#

N ot e
Under som e circum st ances, t he adm inist rat or m ust perform addit ional configurat ion
st eps beyond what is not ed in t he preceding com m ands. For exam ple, t he WS-
X6224/ 6248 and WS- X6324/ 6348 line cards have hardware rest rict ions t hat prevent
t hem from passing CoS values t o t he swit ching engine. Alt hough t he line cards
recognize t he arriving CoS and use t hat value for input scheduling, when t he fram e
header is passed t o t he swit ching engine for forwarding, t he CoS value for t he fram e is
not preserved and is rewrit t en t o 0. Therefore, it is necessary t o configure addit ional
com m ands, as shown in Exam ple 10- 30 .

Ex a m ple 1 0 - 3 0 . Alt e r n a t e Tr u st Con figu r a t ion on t h e Ca t a lyst 6 5 0 0

( Ca t OS)

CAT6500-CATOS> (enable) set port qos 3/1 trust trust-cos

Trust type trust-cos not supported on this port.
Receive thresholds are enabled on port 3/1.
Port 3/1 qos set to untrusted.
CAT6500-CATOS> (enable) set qos acl ip TRUSTCOS trust-cos any
Warning: ACL trust-cos should only be used with ports that are also
configured with port trust=trust-cos.
TRUSTCOS editbuffer modified. Use 'commit' command to apply changes.
CAT6500-CATOS> (enable) commit qos acl TRUSTCOS
QoS ACL 'TRUSTCOS' successfully committed.
CAT6500-CATOS> (enable) set qos acl map TRUSTCOS 3/1
ACL TRUSTCOS is successfully mapped to port 3/1.
The old ACL mapping is replaced by the new one.
CAT6500-CATOS> (enable)

The PFC also can be configured t o ident ify and m ark flows t o specific DSCP values by eit her
Layer 3 or Layer 4 param et ers, and defined in access list s. This is shown in Exam ple 10- 31 , in
which TCP t raffic wit hin t he dest inat ion port range of 9000 t o 9005 is m arked as Transact ional
Dat a ( DSCP AF21 or 18) .

Ex a m ple 1 0 - 3 1 . ACL- Ba se d Cla ssifica t ion a n d M a r k in g on t h e Ca t a lyst

6 5 0 0 ( Ca t OS a n d Cisco I OS)

CAT6500-CATOS> (enable) set qos acl ip TRANSACTIONAL-DATA dscp 18

tcp any any range 9000 9005
TRANSACTIONAL-DATA editbuffer modified. Use 'commit' command to apply changes.
CAT6500-CATOS> (enable) commit qos acl TRANSACTIONAL-DATA
QoS ACL 'TRANSACTIONAL-DATA' successfully committed.
CAT6500-CATOS> (enable) set qos acl map TRANSACTIONAL-DATA 3/1
ACL TRANSACTIONAL-DATA is successfully mapped to port 3/1.
The old ACL mapping is replaced by the new one.
CAT6500-CATOS> (enable)

CAT6500-IOS(config)#access-list 100 permit tcp any any range 9000 9005

CAT6500-IOS(config)#class-map TRANSACTIONAL-DATA
CAT6500-IOS(config-cmap)#match access-group 100
CAT6500-IOS(config-cmap)#policy-map ACCESS-MARKING
CAT6500-IOS(config-pmap)#class TRANSACTIONAL-DATA
CAT6500-IOS(config-pmap-c)#set dscp af21
CAT6500-IOS(config-pmap-c)#interface FastEthernet 3/1
CAT6500-IOS(config-if)#service-policy input ACCESS-MARKING

The default CoS- t o- DSCP m aps, I P Precedence- t o- DSCP m aps, and DSCP- t o- CoS m aps are t he
sam e as have been discussed on previous swit ches ( except for t he Cat alyst 2950, which does
not support t he full DSCP range at t he t im e of writ ing) .

CoS- t o- DSCP m aps can be overwrit t en from t he default s using t he synt axes shown. I n bot h
cases, eight DSCP values m ust be supplied t hat correspond t o CoS values 0 t hrough 7,
respect ively. I n Exam ple 10- 32 , CoS 5 is m apped t o DSCP EF ( 46) , CoS 4 is m apped t o DSCP
AF41 ( 34) , and CoS 3 is m apped t o DSCP AF31 ( 26) .

Ex a m ple 1 0 - 3 2 . CoS- t o- D SCP M a ppin g M odifica t ion on t h e Ca t a lyst

6 5 0 0 ( Ca t OS a n d Cisco I OS)

CAT6500-CATOS> (enable) set qos cos-dscp 0 8 16 26 34 46 48 56

QoS cos-dscp-map set successfully.
CAT6500-CATOS> (enable)

CAT6500-IOS(config)#mls qos map cos-dscp 0 8 16 26 34 46 48 56

CAT6500-IOS(config)#

I P Precedence- t o- DSCP m aps use ident ical synt ax, except t hat t he cos keyword is replaced wit h
ip p r e c ( Cat OS) and ip- pr e c ( Cisco I OS) .

Default DSCP- t o- CoS m odificat ions can be configured, as shown in Exam ple 10- 33 . I n t his
exam ple, DSCP values CS1 ( 8) t hrough DSCP 15 are rem apped t o CoS 0.
Ex a m ple 1 0 - 3 3 . D SCP- t o- CoS M a ppin g M odifica t ion on t h e Ca t a lyst
6 5 0 0 ( Ca t OS a n d Cisco I OS)

CAT6500-CATOS> (enable) set qos dscp-cos-map 8-15:0

QoS dscp-cos-map set successfully.
CAT6500-CATOS> (enable)

CAT6500-IOS(config)#mls qos map dscp-cos 8 9 10 11 12 13 14 15 to 0

CAT6500-IOS(config)#

DSCP- t o- DSCP m aps, or DSCP m ut at ion m aps, also can be configured explicit ly on t he Cat alyst
6500, but DSCP m ut at ion current ly is in nat ive I OS m ode only. Up t o 15 DSCP m ut at ion m aps
can be configured on t he Cat alyst 6500. The com m ands t o configure DSCP m ut at ion m aps on
t he 6500 are ident ical t o t hose used in t he exam ples of DSCP m ut at ion previously discussed in
t his chapt er.

Catalyst 6500 Policing and Markdown

The Cat alyst 6500 support s t wo m ain t ypes of policers: m icroflow and aggregat e. Bot h m icroflow
and aggregat e policers can be configured on a per- port or per- VLAN basis. The Cat alyst 6500
support s 63 m icroflow and 1023 aggregat e policers.

Microflow policers differ from individual policers ( which lim it t raffic on a per- int erface basis) , in
t hat t hey lim it t raffic on a per- flow basis. A flow is defined by a socket ( source/ dest inat ion
address pairing com bined wit h an ident ical Layer 4 prot ocol and t he source/ dest inat ion port
pairing) . However, m icroflow policers can be configured t o use only t he source or only t he
dest inat ion addresses for policing purposes.

N ot e
By default , m icroflow policers affect only t raffic rout ed by t he MSFC. To enable
m icroflow policing of bridged t raffic, eit her t he Cat OS se t qos br idge d- m icr oflow -
policin g e n a ble global com m and or t he Cisco I OS m ls qos br idge d int erface
com m and m ust be used.

The com m ands t o configure m icroflow policing on t he Cat alyst 6500 are shown in Exam ple 10- 34
, where no single flow is perm it t ed t o exceed 1 Mbps. I n Cat OS, t his requires a m icroflow policer
t o be defined and referenced by an ACL. The ACL, in t urn, is com m it t ed and m apped t o t he
int erface. I n Cisco I OS, an MQC policy is defined wit h t he police flow keywords and is at t ached
t o an int erface. Not ice in Exam ple 10- 34 t hat policing rat es m ight be adj ust ed m arginally
because of hardware granularit y rest rict ions.

Aggregat e policers can be defined on a per- int erface basis. Alt ernat ively, you can define nam ed
aggregat e policers t hat can be applied t o m ult iple int erfaces.

Ex a m ple 1 0 - 3 4 . Con figu r in g M icr oflow Policin g on t h e Ca t a lyst 6 5 0 0

( Ca t OS a n d Cisco I OS)
 CAT6500-CATOS> (enable) set qos policer microflow ONE-MEG-FLOWS
rate 1000 burst 8 drop
QoS policer for microflow ONE-MEG-FLOWS created successfully.
Rate is set to 992 and burst is set to 8 in hardware due to hardware granularity.
CAT6500-CATOS> (enable) set qos acl ip ONE-MEG-FLOW-ACL dscp 0
microflow ONE-MEG-FLOWS ip any any
ONE-MEG-FLOW-ACL editbuffer modified. Use 'commit' command to apply changes.
CAT6500-CATOS> (enable) commit qos acl ONE-MEG-FLOW-ACL
QoS ACL 'ONE-MEG-FLOW-ACL' successfully committed.
CAT6500-CATOS> (enable) set qos acl map ONE-MEG-FLOW-ACL 3/1
ACL ONE-MEG-FLOW-ACL is successfully mapped to port 3/1.
CAT6500-CATOS> (enable)

CAT6500-IOS(config)#access-list 1 permit any

CAT6500-IOS(config)#class-map ANY
CAT6500-IOS(config-cmap)#match access-group 1
CAT6500-IOS(config-cmap)#policy-map MICROFLOW
CAT6500-IOS(config-pmap)#class ANY
CAT6500-IOS(config-pmap-c)#police flow 1000000 8000 conform transmit
exceed-action drop
CAT6500-IOS(config-pmap-c)#interface FastEthernet 3/1
CAT6500-IOS(config-if)#service-policy input MICROFLOW

Furt herm ore, aggregat e policers on t he PFC2 or PFC3 support t he added funct ionalit y of dual-
rat e policing, as defined in RFC 2698 and overviewed in Chapt er 4 , " Policing and Shaping
Tools," under t he " Two- Rat e Three- Color Marker " sect ion. Dual- rat e policers require defining not
only a CI R, but also a PI R. However, t he out - of- profile PI R act ion ( violat e) cannot be less severe
t han t he out - of- profile CI R act ion ( exceed) . For inst ance, if t he exceed act ion is t o m ark down,
t he violat e act ion cannot be t o t ransm it .

I n Exam ple 10- 35 , FTP t raffic is t ransm it t ed wit h DSCP AF11 ( DSCP 10) if it is less t han 1 Mbps.
Any FTP t raffic over 1 Mbps but less t han 2 Mbps is m arked down t o AF12 ( DSCP 12) . Any FTP
t raffic in excess of 2 Mbps is m arked down furt her t o AF13 ( DSCP 14) . The aggregat e policing
policy is applied t o VLAN 10 as a whole.

Ex a m ple 1 0 - 3 5 . Con figu r in g D u a l- Ra t e Aggr e ga t e Police r s on t h e

Ca t a lyst 6 5 0 0 ( Ca t OS a n d Cisco I OS)

CAT6500-CATOS> (enable) set qos policed-dscp-map normal 10:12

CAT6500-CATOS> (enable) set qos policed-dscp-map excess 10:14
CAT6500-CATOS> (enable) set qos policer aggregate FTP-POLICER
rate 1000 policed-dscp erate 2000 policed-dscp burst 8 eburst 8
QoS policer for aggregate FTP-POLICER created successfully.
Rate is set to 992 and erate is set 1984 and burst is set to 8
and eburst is set to 8 in hardware due to hardware granularity.
CAT6500-CATOS> (enable) set qos acl ip FTP-ACL dscp 10 aggregate FTP-POLICER
tcp any any eq ftp
FTP-ACL editbuffer modified. Use 'commit' command to apply changes.
CAT6500-CATOS> (enable) set qos acl ip FTP-ACL dscp 10 aggregate FTP-POLICER
tcp any any eq ftp-data
 FTP-ACL editbuffer modified. Use 'commit' command to apply changes.
CAT6500-CATOS> (enable) commit qos acl FTP-ACL
QoS ACL 'FTP-ACL' successfully committed.
CAT6500-CATOS> (enable) set qos acl map FTP-ACL 10
ACL FTP-ACL is successfully mapped to vlan 10.
CAT6500-CATOS> (enable)

CAT6500-IOS(config)#mls qos map policed-dscp normal-burst 10 to 12

CAT6500-IOS(config)#mls qos map policed-dscp max-burst 10 to 14
CAT6500-IOS(config)#mls qos aggregate-policer FTP-AGG-POLICER 1000000 pir 2000000
conform-action set-dscp-transmit 10 exceed-action policed-dscp-transmit
violate-action policed-dscp-transmit
CAT6500-IOS(config)#access-list 100 permit tcp any any eq ftp
CAT6500-IOS(config)#access-list 100 permit tcp any any eq ftp-data
CAT6500-IOS(config)#class-map FTP
CAT6500-IOS(config-cmap)#match access-group 100
CAT6500-IOS(config-cmap)#policy-map FTP-MQC-POLICER
CAT6500-IOS(config-pmap)#class FTP
CAT6500-IOS(config-pmap-c)#police aggregate FTP-AGG-POLICER
CAT6500-IOS(config-pmap-c)#interface vlan 10
CAT6500-IOS(config-if)#service-policy input FTP-MQC-POLICER

Microflow and aggregat e policers are not m ut ually exclusive. For exam ple, you could creat e a
m icroflow policer wit h a bandwidt h lim it suit able for individuals in a group, and you could creat e
a nam ed aggregat e policer wit h bandwidt h lim it s suit able for t he group as a whole. You could
include bot h policers in policy m ap classes t hat m at ch t he group's t raffic. The com binat ion would
affect individual flows separat ely and t he group aggregat ely.

Catalyst 6500 Queuing and Dropping

As m ent ioned, queuing and t hreshold support on Cat alyst 6500 varies from line card t o line card.
To check t he queuing st ruct ure of t he line card or port in quest ion, use t he com m ands in
Exam ple 10- 36 .

Ex a m ple 1 0 - 3 6 . Qu e u e St r u ct u r e Ve r ifica t ion on t h e Ca t a lyst 6 5 0 0

( Ca t OS a n d Cisco I OS)

CAT6500-CATOS> (enable) show port capabilities 1/1

Model WS-X6K-SUP1A-2GE
Port 1/1
Type 1000BaseSX
Speed 1000
Duplex full
Trunk encap type 802.1Q,ISL
Trunk mode on,off,desirable,auto,nonegotiate
Channel yes
Broadcast suppression percentage(0-100)
Flow control receive-(off,on,desired),send-(off,on,desired)
Security yes
Dot1x yes
Membership static,dynamic
 Fast start yes
QOS scheduling rx-(1p1q4t),tx-(1p2q2t)

CAT6500-CATOS> (enable)
CAT6500-IOS#show queueing interface gig 1/1
Interface GigabitEthernet1/1 queueing strategy: Weighted Round-Robin
Port QoS is enabled
Trust state: trust DSCP
Extend trust state: not trusted [COS = 0]
Default COS is 0
Queueing Mode In Tx direction: mode-cos
Transmit queues [type = 1p2q2t]:
...
CAT6500-IOS#

The com m ands display som e of t he following queue st ruct ures:

2 q2 t indicat es t wo st andard queues, each wit h t wo configurable t ail- drop t hresholds.

1 p2 q1 t indicat es t he following:

- One st rict - priorit y queue

- Two st andard queues, each wit h one WRED- drop t hreshold

- One nonconfigurable ( 100 percent ) t ail- drop t hreshold

1 p2 q2 t indicat es t he following:

- One st rict - priorit y queue

- Two st andard queues, each wit h t wo configurable WRED- drop t hresholds

1 p3 q1 t indicat es t he following:

- One st rict - priorit y queue

- Three st andard queues, each wit h one t hreshold configurable as eit her WRED drop
or t ail drop

- One nonconfigurable ( 100 percent ) t ail- drop t hreshold

1 p3 q8 t indicat es t he following:

- One st rict - priorit y queue

- Three st andard queues, each wit h eight t hresholds, wit h each t hreshold
configurable as eit her WRED drop or t ail drop

1 p7 q8 t indicat es t he following:
 - One st rict - priorit y queue

- Seven st andard queues, each wit h eight t hresholds, wit h each t hreshold
configurable as eit her WRED drop or t ail drop

For port t ypes wit h a st rict - priorit y queue, t he swit ch services t raffic in t he st rict - priorit y
t ransm it queue before servicing t he st andard queues. When t he swit ch is servicing a st andard
queue, aft er t ransm it t ing a packet , it checks for t raffic in t he st rict - priorit y queue. I f t he swit ch
det ect s t raffic in t he st rict - priorit y queue, it suspends it s service of t he st andard queue and
com plet es service of all t raffic in t he st rict - priorit y queue before ret urning t o t he st andard
queue.

Cat alyst 6500 PFC QoS schedules t raffic t hrough t he t ransm it queues based on Layer 2 CoS
values. I n t he default configurat ion, PFC QoS assigns all t raffic wit h CoS 5 t o t he st rict - priorit y
queue ( if present ) ; PFC QoS assigns all ot her t raffic t o st andard queues. I n t he absence of a
st rict - priorit y queue, PFC QoS assigns all t raffic t o t he st andard queues.

N ot e
The default queue sizes, t hresholds definit ions, and bandwidt h allocat ion rat ios are
usually adequat e for m ost cases. I n t he rare event t hat t hese need t o be t uned,
experienced adm inist rat ors should refer t o Cisco Cat alyst 6500 docum ent at ion for
default values for t hreshold percent ages, queue sizes, and bandwidt h- allocat ion rat ios
for each queuing st ruct ure.

Keep t hese point s in m ind when configuring CoS t o queue/ t hreshold assignm ent s and
param et ers:

Num ber 1 is t he lowest - priorit y st andard queue.

Higher- num bered queues are higher- priorit y st andard queues.

When you configure m ult iple- t hreshold st andard queues, not e t he following:

The first percent age t hat you ent er set s t he lowest - priorit y t hreshold.

The second percent age t hat you ent er set s t he next highest - priorit y t hreshold.

The last percent age t hat you ent er set s t he highest - priorit y t hreshold.

The percent ages range from 1 t o 100. A value of 10 indicat es a t hreshold when t he buffer
is 10 percent full.

Always set highest - num bered t hreshold t o 100 percent .

When configuring t he WRED- drop t hresholds, not e t he following:

Each WRED- drop t hreshold has a low- WRED and a high- WRED value.

Low- WRED and high- WRED values are a percent age of t he queue capacit y ( t he range is
from 1 t o 100) .
 The low- WRED value is t he t raffic level under which no t raffic is dropped. The low- WRED
value m ust be lower t han t he high- WRED value.

The high- WRED value is t he t raffic level above which all t raffic is dropped.

Traffic in t he queue bet ween t he low- and high- WRED values has an increasing chance of
being dropped as t he queue fills.

I n t he 1P2Q2T m odel shown in Exam ple 10- 37 , Scavenger t raffic ( CoS 1) is m apped t o t he first
st andard queue, first t hreshold; Best - Effort t raffic ( CoS 0) is m apped t o t he first queue, second
t hreshold; Transact ional Dat a, Net work- Managem ent t raffic ( CoS 2) , and Video ( CoS 4) are
m apped t o t he second queue, first t hreshold; Call- Signaling and Net work- Cont rol t raffic ( CoS
values 3, 6, and 7) are m apped t o t he second queue, second t hreshold. Voice ( CoS 5) is m apped
t o t he priorit y queue.

Ex a m ple 1 0 - 3 7 . Con figu r in g CoS- t o- Qu e u e / Th r e sh old Assign m e n t s on

t h e Ca t a lyst 6 5 0 0 ( Ca t OS a n d Cisco I OS)

CAT6500-CATOS> (enable) set qos map 1p2q2t tx 1 1 cos 1

QoS tx priority queue and threshold mapped to cos successfully.
CAT6500-CATOS> (enable) set qos map 1p2q2t tx 1 2 cos 0
QoS tx priority queue and threshold mapped to cos successfully.
CAT6500-CATOS> (enable) set qos map 1p2q2t tx 2 1 cos 2,4
QoS tx priority queue and threshold mapped to cos successfully.
CAT6500-CATOS> (enable) set qos map 1p2q2t tx 2 2 cos 3,6,7
QoS tx priority queue and threshold mapped to cos successfully.
CAT6500-CATOS> (enable) set qos map 1p2q2t tx 3 1 cos 5
QoS tx priority queue and threshold mapped to cos successfully.
CAT6500-CATOS> (enable)

CAT6500-IOS(config)# interface GigabitEthernet2/1

CAT6500-IOS(config-if)#wrr-queue cos-map 1 1 1
cos-map configured on: Gi2/1 Gi2/2 Gi2/3 Gi2/4 Gi2/5 Gi2/6 Gi2/7 Gi2/8
CAT6500-IOS(config-if)#wrr-queue cos-map 1 2 0
cos-map configured on: Gi2/1 Gi2/2 Gi2/3 Gi2/4 Gi2/5 Gi2/6 Gi2/7 Gi2/8
CAT6500-IOS(config-if)#wrr-queue cos-map 2 1 2 4
cos-map configured on: Gi2/1 Gi2/2 Gi2/3 Gi2/4 Gi2/5 Gi2/6 Gi2/7 Gi2/8
CAT6500-IOS(config-if)#wrr-queue cos-map 2 2 3 6 7
cos-map configured on: Gi2/1 Gi2/2 Gi2/3 Gi2/4 Gi2/5 Gi2/6 Gi2/7 Gi2/8
CAT6500-IOS(config-if)#priority-queue cos-map 1 5
cos-map configured on: Gi2/1 Gi2/2 Gi2/3 Gi2/4 Gi2/5 Gi2/6 Gi2/7 Gi2/8
CAT6500-IOS(config-if)#

N ot e
Not ice t hat alt hough t he num ber of t he priorit y queue in Cat OS will be 3 ( or higher) , in
Cisco I OS, t he priorit y queue num ber when using t he pr ior it y- qu e u e cos- m a p
int erface com m and is always 1.
I t cannot be st ressed enough t hat t his chapt er is by no m eans a t horough discussion on Cat alyst
QoS; it is m erely an overview t o provide adequat e cont ext for t he design chapt ers t o follow. For
a com plet e discussion of Cat alyst QoS, refer t o Cisco Cat alyst QoS docum ent at ion and also t he
Cisco Press book Cisco Cat alyst QoS: Qualit y of Service in Cam pus Net works , by Michael
Flannagan, Richard Froom , and Kevin Turek.
Summary
For QoS feat ures t o be available at line rat es in cam pus environm ent s, t hey have t o be done in
hardware. Port ing QoS feat ures t o hardware present s m any advant ages, such as t he capabilit y
t o m ark and police at t he t raffic sources, and t he enforcem ent of t rust boundaries and queuing
at ( m om ent arily) congest ed uplinks and downlinks. However, port ing QoS funct ionalit y int o
hardware also present s an undesired caveat from a configurat ion and m anagem ent perspect ive:
As hardware varies, QoS also does in funct ionalit y and configurat ion, leading t o significant
com plexit y in m anaging cam pus QoS. To address t his caveat , t ools such as MQC and Aut oQoS
are cont inuing t o be developed t o sim plify cam pus QoS.

This chapt er exam ined basic Cat alyst QoS m odels, which, for t he m ost part , can be broken down
int o t hree m ain areas:

Cla ssifica t ion , m a r k in g, a n d m a ppin g These operat ions are responsible for generat ing
t he I nt ernal DSCP value by which all subsequent QoS funct ions will be referenced. These
values m ay be generat ed by t he configured t rust st at es ( u n t r u st e d , t r u st - cos, t r u st -
ip p r e c, or t r u st - dscp) , explicit m arking policies, or m apping funct ions.

Policin g a n d m a r k dow n These funct ions m onit or t raffic flows as t o whet her t hey are in
profile or out of profile. Markdown act ions can be assigned t o out - of- profile t raffic
( alt ernat ively, out - of- profile t raffic can be dropped) . Cat alyst plat form s support individual,
aggregat e, or m icroflow ( 6500 only) policers.

Qu e u in g a n d dr oppin g Hardware queuing m odels, such as x Qy T or x Py QzT m odels, were

exam ined from bot h congest ion- m anagem ent and congest ion- avoidance funct ionalit y
per spect ives.

Having laid a fram ework for a generic Cat alyst QoS m odel, t he m odel was applied t o each of t he
m ain Cat alyst plat form s ( at t he t im e of writ ing) , including t he Cat alyst 2950, 2970, 3550, 3560,
3750, 4500, and 6500. Configurat ion synt ax and idiosyncrasies were addressed t o lay a basic
cont ext for t he design discussions t o follow.

Table 10- 5 shows a sum m ary of t he QoS feat ures support ed by Cat alyst plat form s.

Ta ble 1 0 - 5 . Su m m a r y of QoS Fe a t u r e s Su ppor t e d by Ca t a lyst Pla t for m s

Ca t a lyst Ca t a lyst Ca t a lyst Ca t a lyst

Pla t for m / Fe a t u r e 2 9 5 0 3550 2970/ 3560/ 3750 4500 Ca t a lyst 6 5 0 0

QoS on by default ? Yes No No No No

Default t rust ( wit h Unt r ust ed Unt r ust ed Unt r ust ed Unt r ust ed Unt r ust ed
QoS enabled)

Port - based QoS Yes Yes Yes Yes Yes

VLAN- based QoS No Yes No Yes Yes

 Ca t a lyst Ca t a lyst Ca t a lyst Ca t a lyst
Pla t for m / Fe a t u r e 2 9 5 0 3550 2970/ 3560/ 3750 4500 Ca t a lyst 6 5 0 0

Full DSCP- CoS No Yes Yes Yes Yes

m aps

DSCP m ut at ion No Yes Yes No Yes

I ngress policing Yes Yes Yes Yes Yes

Egress policing No Yes Yes Yes Yes

Aggregat e policing No Yes Yes Yes Yes

Dual- rat e policing No No No No Yes

Microflow policing No No No No Yes

Per- user m icroflow No No No No PFC3 only

policing
Policers per port 6 per 8 per 64 per port ; 256 1020 per 1023 per port
10/ 100 10/ 100 per- port ASI C port
port s; 60 por t s;
per GE 128 per
por t s GE port s
Minim um policing 1 Mbps 8 kbps 8 kbps 32 kbps 32 kbps
rat e/ granularit y

Queuing st ruct ures 4Q1T or 10/ 100 4Q3T or 1P3Q3T 4Q1T or ( Line- card
1P3Q1T por t s: 1P3Q1T dependent )
4Q1T or 2Q2T
1P3Q1T 1P2Q1T
GE port s: 1P2Q2T
4Q2T or 1P3Q1T
1P3Q2T 1P3Q8T
1P7Q8T
Priorit y queue Q4 Q4 Q1 Q3 ( Line- card
dependent )
2Q2T: None
1P2Q1T: Q3
1P2Q2T: Q3
1P3Q1T: Q4
1P3Q8T: Q4
1P7Q8T: Q8
WTD No No Yes No No

WRED No Yes No No ( Line- card

dependent )
2Q2T: No
1P2Q1T: Yes
1P2Q2T: Yes
1P3Q1T: Yes
1P3Q8T: Yes
1P7Q8T: Yes
DBL No No No Yes No
 Ca t a lyst Ca t a lyst Ca t a lyst Ca t a lyst
Pla t for m / Fe a t u r e 2 9 5 0 3550 2970/ 3560/ 3750 4500 Ca t a lyst 6 5 0 0

Aut oQoS Yes Yes Yes Yes Cat OS: Yes

Cisco I OS: No

N ot e
" Cat alyst 4500 " refers t o Cat alyst 4500 wit h Sup3- 5 running Cisco I OS; " Cat alyst
6500" refers t o Cat alyst 6500 wit h PFC2 ( Supervisor 2) or PFC3 ( Supervisor 720)
running eit her Cat OS or Cisco I OS. All values were current at t he t im e of writ ing; check
t he Cisco plat form docum ent at ion for t he lat est inform at ion at
ht t p: / / www.cisco.com / univercd/ hom e/ hom e.ht m .
Further Reading
Books:

Flannagan, Micheal, Richard Froom , and Kevin Turek. Cisco Cat alyst QoS: Qualit y of
Service in Cam pus Net works . I ndianapolis: Cisco Press, 2003.

Cisco Cat alyst docum ent at ion:

Configuring QoS on t he Cat alyst 2950 ( Cisco I OS Release 12.1[ 19] EA1) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 2950/ 12119ea1/ 2950scg/ swqos.ht m
.

Configuring QoS on t he Cat alyst 3550 ( Cisco I OS Release 12.1[ 19] EA1) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ c3550/ 12119ea1/ 3550scg/ swqos.ht m .

Configuring QoS on t he Cat alyst 3560 ( Cisco I OS Release 12.2[ 20] SE) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 3560/ 12220se/ 3560scg/ swqos.ht m .

Configuring QoS on t he Cat alyst 3750 ( Cisco I OS Release 12.1[ 19] EA1) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 3750/ 12119ea1/ 3750scg/ swqos.ht m
.

Configuring QoS on t he Cat alyst 4500 ( Cisco I OS Release 12.1[ 20] EW)
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 4000/ 12_1_20/ config/ qos.ht m .

Configuring QoS on t he Cat alyst 6500 ( Cisco I OS Release 12.2[ 17a] SX1) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 6000/ 122sx/ swcg/ qos.ht m .

Configuring QoS on t he Cat alyst 6500 ( Cisco Cat OS Release 8.2) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 6000/ sw_8_2/ confg_gd/ qos.ht m .
Chapter 11. WLAN QoS Tools
This chapt er discusses wireless LAN QoS t ools, including t he following:

I EEE 802.11 Dist ribut ed Coordinat ion Funct ion ( DCF)

I EEE 802.11 Enhanced Dist ribut ed Coordinat ion Funct ion ( EDCF)

I EEE 802.11 QoS basic service set ( QBSS)

I EEE 802.1D classes of service

I n t he past , WLANs m ainly were used t o t ransport low- bandwidt h dat a- applicat ion t raffic. Today,
wit h t he expansion of WLANs int o ent erprises, sm all businesses, m obile " hot spot s," and hom e
environm ent s, WLANs are used t o t ransport high- bandwidt h dat a applicat ions in conj unct ion wit h
t im e- sensit ive m ult im edia applicat ions. These evolving requirem ent s have led t o t he necessit y
for wireless QoS t ools.

However, unique challenges are present ed wit h t he use of radio waves as a t ransm ission
m edium . For exam ple, radio waves are a shared, half- duplex m edium t hat m ight not always be
fully cont rolled ( because signals are subj ect t o int erference) .

Several vendors support propriet ary wireless QoS schem es for voice applicat ions. However, a
unified approach t o wireless QoS would speed up t he rat e of wireless QoS adopt ion and would
provide QoS support for t im e- sensit ive applicat ions in m ult ivendor wireless environm ent s. The
I EEE 802.11e working group wit hin t he I EEE 802.11 st andards com m it t ee is defining a wireless
QoS st andard t hat was finalized in m id- 2004. Ot her groups, including t he WiFi Alliance, are also
draft ing st andards for wireless QoS.

Cisco Aironet product s support QoS based on t he I EEE 802.11e draft st andard specificat ions as
of Novem ber 2002. Cisco I OS Soft ware Release 12.2( 4) JA for t he Cisco Aironet 1100 Series and
Cisco Aironet VxWorks Release 12.00T for Cisco Aironet 1200, 350, and 340 Series product s
support I EEE 802.11e Enhanced Dist ribut ed Coordinat ion Funct ion ( EDCF) based wireless QoS.

An exam ple deploym ent of wireless QoS wit hin a Cisco Aironet environm ent is shown in Figure
11- 1 .

Figu r e 1 1 - 1 . Cisco W ir e le ss QoS D e ploym e n t Ex a m ple

QoS for Wireless LANs Versus QoS on Wired LANs
The QoS im plem ent at ion for wireless LANs differs from QoS im plem ent at ions on ot her ( wired)
Cisco devices. Wit h QoS enabled, wireless access point s ( APs) perform t he following QoS
funct ions:

They priorit ize packet s based on DSCP value, client t ype ( such as a wireless phone) , or t he
priorit y value in t he 802.1q or 802.1p t ag; however, t hey do not classify packet s.

They support m apping by assigning I P DSCP, Precedence, or Prot ocol values t o Layer 2 CoS
values; t hey do not const ruct int ernal DSCP values.

They support EDCF ( which is discussed in m ore det ail in t he sect ion t it led " I EEE 802.11e
EDCF" ) , such as queuing on t he ( downst ream ) radio egress port only.

They support only FI FO queuing on t he ( upst ream ) Et hernet egress port .

They support only 802.1Q/ P t agged packet s. Access point s do not support I SL.

They support only t he MQC policy- m a p se t cos act ion.

They priorit ize t he t raffic from voice client s ( such as Sym bol phones) over t raffic from ot her
client s when t he QoS Elem ent for Wireless Phones ( which is discussed lat er in t his chapt er
in t he sect ion t it led "QoS Basic Service Set I nform at ion Elem ent " ) feat ure is enabled.

They support Spect ralink phones using t he cla ss- m a p I P pr ot ocol clause wit h t he
prot ocol value set t o 119.

Just as in ot her m edia, you m ight not not ice t he effect s of QoS on a light ly loaded wireless LAN
( WLAN) . The benefit s of QoS becom e m ore obvious as t he load on t he wireless LAN increases,
keeping t he lat ency, j it t er, and loss for select ed t raffic t ypes wit hin an accept able range.

QoS on t he wireless LAN focuses on downst ream priorit izat ion from t he access point .
Upstream Versus Downstream QoS
Com m unicat ion st ream s in a WLAN environm ent are over eit her Et hernet or radio m edia.
Furt herm ore, t he flows occur in eit her t he upst ream or downst ream direct ion, as shown in Figure
11- 2 .

Figu r e 1 1 - 2 . Et h e r n e t / Ra dio Upst r e a m / D ow n st r e a m Flow s

Et hernet downst ream refers t o t raffic leaving t he swit ch/ rout er t raveling t o t he access point
( AP) . QoS m ay be applied at t his point t o priorit ize and rat e- lim it t raffic t o t he AP.

Radio downst ream QoS refers t o t he t raffic leaving t he AP and t raveling t o t he WLAN client s.
Radio downst ream QoS is t he prim ary focus of t his chapt er.

Radio upst ream QoS refers t o t raffic leaving t he WLAN client s and t raveling t o t he AP. No vendor
support is current ly available for radio upst ream QoS feat ures for WLAN client s. This support is
specified in t he 802.11e draft but has not yet been im plem ent ed. By providing downst ream
priorit izat ion from t he AP, upst ream client t raffic is t reat ed as best effort . A client m ust com pet e
wit h ot her client s for ( upst ream ) t ransm ission and also m ust com pet e wit h best - effort
( downst ream ) t ransm ission from t he AP because of t he half- duplex nat ure of WLAN radio. Under
cert ain load condit ions, a client can experience upst ream congest ion, and t he perform ance of
QoS sensit ive applicat ions m ight be unaccept able, despit e t he downst ream QoS feat ures on t he
AP.

Et hernet upst ream refers t o t raffic leaving t he AP t raveling t o t he swit ch. The AP classifies t raffic
from t he AP t o t he upst ream net work according t o t he t raffic classificat ion. However, only FI FO
queuing is support ed ( which is adequat e for alm ost all cases) at t his point .
IEEE 802.11 DCF
Dat a fram es in 802.11 are sent using t he Dist ribut ed Coordinat ion Funct ion ( DCF) . The DCF is
com posed of t wo m ain com ponent s:

I nt erfram e spaces ( I FS)

Random backoffs/ cont ent ion windows ( CW)

DCF is used in 802.11 net works t o m anage access t o t he RF m edium . A baseline underst anding
of DCF is necessary t o provide cont ext in underst anding and deploying 802.11e- based Enhanced
Dist ribut ed Coordinat ion Funct ion ( EDCF) .

Interframe Spaces
I nt erfram e Spaces, shown in Figure 11- 3, allow 802.11 t o cont rol which t raffic get s first access
t o t he channel when carrier sense declares t he channel t o be free.

Figu r e 1 1 - 3 . I EEE 8 0 2 .1 1 D CF I n t e r fr a m e Spa ce s

[View full size image]

802.11 current ly defines t hree int erfram e spaces:

Short int erfram e spaces ( SI FS) , which are 10 m long

Point int erfram e spaces ( PI FS) , which are 30 m long ( SI FS + 1 [ 20 m ] slot t im e = 30 m )

Dist ribut ed int erfram e spaces ( DI FS) , which are 50 m long ( SI FS + 2 [ 20 m ] slot t im es = 50
m )

SIFS
I m port ant fram es ( such as acknowledgm ent s) await t he SI FS before t ransm it t ing. There is no
random backoff when using t he SI FS because fram es using t he SI FS are used when m ult iple
st at ions would not be t rying t o send fram es at t he sam e t im e. The SI FS provide a short and
det erm inist ic delay for packet s t hat m ust go t hrough as soon as possible. SI FS are not available
for use by dat a fram es; only 802.11 m anagem ent and cont rol fram es use SI FS.

PIFS

An opt ional port ion of t he 802.11 st andard defines priorit y m echanism s for t raffic via PI FS. No
random backoff m echanism s are associat ed wit h PI FS because it relies solely on a polling
m echanism t o cont rol which st at ion m ay t ransm it . The opt ion has not been adopt ed widely
because of t he associat ed overhead and lack of flexibilit y in it s applicat ion.

DIFS

Dat a fram es m ust wait out t he DI FS before beginning t he random backoff procedure, which is
part of t he DCF. This longer wait ensures t hat t raffic using SI FS or PI FS t im ing always get s an
opport unit y t o send before any t raffic using t he DI FS at t em pt s t o send. ( I n ot her words,
m anagem ent or priorit y t raffic always get s t o send before generic dat a.)

Random Backoffs/Contention Windows

When a dat a fram e using DCF ( shown in Figure 11- 4) is ready t o be sent , t he sending st at ion
goes t hrough t he following st eps:

1 . A random backoff num ber bet ween 0 and a m inim um cont ent ion window ( CWm in) is
generat ed.

2 . The st at ion wait s unt il t he channel is free for a DI FS int erval.

3 . I f t he channel is st ill free, t he random backoff num ber is decrem ent ed once for every slot
t im e ( 20 m ) t hat t he channel rem ains free.

4 . I f t he channel becom es busy ( for exam ple, if anot her st at ion get s t o 0 before your st at ion) ,
t he decrem ent ing of t he random backoff num ber st ops and st eps 2 t hrough 4 are repeat ed.

5 . I f t he channel rem ains free unt il t he random backoff num ber reaches 0, t he fram e m ay be
sent .

Figu r e 1 1 - 4 . I EEE 8 0 2 .1 1 D CF Tr a n sm ission Ex a m ple

[View full size image]

Figure 11- 4 shows a sim plified exam ple of how t he DCF process works. ( I n t his sim plified DCF
exam ple, no acknowledgm ent s are shown and no fragm ent at ion occurs.)

The DCF st eps illust rat ed in Figure 11- 4 work as follows:

1 . St at ion A successfully sends a fram e, and t hree ot her st at ions also want t o send fram es but
m ust defer t o St at ion A's t raffic.

2 . When St at ion A com plet es t ransm ission, all t he st at ions m ust st ill defer t o t he DI FS. When
t he DI FS is com plet e, st at ions t hat want t o send a fram e can begin decrem ent ing t heir
backoff count ers ( decrem ent ing by one for every slot t im e t hat passes) . I f t heir backoff
count ers reach 0 and t he wire is available, t hey m ay send t heir fram e.

3 . St at ion B's backoff count er reaches 0 before St at ions C and D, so St at ion B begins
t ransm it t ing it s fram e.

4 . When St at ions C and D det ect t hat St at ion B is t ransm it t ing, t hey m ust st op decrem ent ing
t heir backoff count ers and again defer unt il t he fram e is t ransm it t ed and a DI FS has passed.

5 . During t he t im e t hat St at ion B is t ransm it t ing a fram e, St at ion E get s a fram e t o t ransm it ,
but because St at ion B is sending a fram e, St at ion E m ust defer in t he sam e m anner as
St at ions C and D.

6 . When St at ion B com plet es t ransm ission and t he DI FS has passed, st at ions wit h fram es t o
send begin decrem ent ing t heir backoff count ers again. I n t his case, St at ion D's backoff
count er reaches 0 first , and t he st at ion begins t ransm ission of it s fram e.

7 . The process cont inues as t raffic arrives on different st at ions.

CWmin, CWmax, and Retries

DCF uses a cont ent ion window ( CW) t o cont rol t he size of t he random backoff. The cont ent ion
window is defined by t wo param et ers:

CWm in

CWm ax

The random num ber used in t he random backoff is init ially a num ber bet ween 0 and CWm in. I f
t he init ial random backoff expires wit hout successfully sending t he fram e, t he st at ion or AP
increm ent s t he ret ry count er and doubles t he value of t he random backoff window size. This
doubling in size cont inues unt il t he size equals CWm ax. The ret ries cont inue unt il t he m axim um
ret ries or Tim e- To- Live ( TTL) is reached. This process of doubling t he backoff window oft en is
referred t o as a binary exponent ial backoff; it is illust rat ed in Figure 11- 5.

Figu r e 1 1 - 5 . I EEE 8 0 2 .1 1 Ra n dom Ba ck off Ra n ge s w it h Re t r ie s

IEEE 802.11e EDCF
The current I EEE 802.11e draft describes an Enhanced Dist ribut ed Coordinat ion Funct ion
( EDCF) . EDCF is an enhancem ent of DCF, previously described. The m ain enhancem ent is t he
adj ust m ent of variable CWm in and CWm ax random backoff values based upon t raffic
classificat ion. This feat ure is support ed in current Cisco Aironet soft ware.

Figure 11- 6 shows t he principle behind different CWm in values per t raffic classificat ion. All t raffic
wait s t he sam e DI FS, but t he CWm in value used t o generat e t he random backoff num ber
depends upon t he t raffic classificat ion. High- priorit y t raffic has a sm aller CWm in value, grant ing
it a short er random backoff value, whereas best - effort t raffic has a larger CWm in value t hat ( on
average) generat es a longer random backoff value.

Figu r e 1 1 - 6 . I EEE 8 0 2 .1 1 e ED CF Ra n dom Ba ck off by Tr a ffic

Cla ssifica t ion

[View full size image]

Figure 11- 7 illust rat es how different CWm in values ( by t raffic class) im pact t raffic priorit y over
t he WLAN.

Figu r e 1 1 - 7 . I EEE 8 0 2 .1 1 e ED CF Ope r a t ion Ex a m ple

[View full size image]

The process illust rat ed in Figure 11- 7 follows t his sequence:

1 . While St at ion X is t ransm it t ing it s fram e, t hree ot her st at ions det erm ine t hat t hey also
m ust send fram es. Each st at ion defers ( because a fram e already was being t ransm it t ed) ,
and each st at ion generat es a random backoff num ber.

2 . St at ions Voice 1 and Voice 2 have t he t raffic classificat ion of voice, so t hey use an init ial
CWm in of 3 and, t herefore, generat e short random backoff values. Best Effort 1 and Best
Effort 2 generat e longer random backoff t im es because t heir CWm in value is 31.

3 . Voice 1 has t he short est random backoff t im e and, t herefore, st art s t ransm it t ing first .
When Voice 1 st art s t ransm it t ing, all ot her st at ions defer. While Voice 1 st at ion is
t ransm it t ing, st at ion Voice 3 finds t hat it , t oo, needs t o send a fram e and generat es a
random backoff num ber. However, st at ion Voice 3 defers t ransm ission because of st at ion
Voice 1's t ransm ission.

4 . When st at ion Voice 1 finishes t ransm it t ing, all st at ions await t he DI FS and t hen begin
decrem ent ing t heir random backoff count ers again.

5 . St at ion Voice 2 com plet es decrem ent ing it s random backoff count er first and begins
t ransm ission. All ot her st at ions defer.

6 . When St at ion Voice 2 has finished t ransm it t ing, all st at ions wait t he DI FS and t hen begin
decrem ent ing t heir random backoff count ers again.

7 . Best Effort 2 com plet es decrem ent ing it s random backoff count er first and begins
t ransm ission. All ot her st at ions defer. This happens even t hough t here is a voice st at ion
wait ing t o t ransm it . This shows t hat best - effort t raffic is not st arved by voice t raffic
because t he process of random backoff decrem ent ing event ually brings t he best - effort
backoff value down t o sim ilar values as init ially generat ed by high- priorit y t raffic.
Addit ionally, t he random process occasionally generat es a sm all random backoff num ber
for best - effort t raffic.

8 . When Best Effort 2 finishes t ransm it t ing, all st at ions await t he DI FS and t hen begin
decrem ent ing t heir random backoff count ers again.

9 . St at ion Voice 3 com plet es decrem ent ing it s random backoff count er first and begins
t ransm ission. All ot her st at ions defer.

1 0 . The process cont inues as ot her t raffic ent ers t he syst em .

The overall im pact of t he different CWm in and CWm ax values is st at ist ical in nat ure. I t is
som et im es sim pler t o com pare t wo exam ples and show t he im pact of t hese different values in
t he average t im es t hat should be generat ed by t he random backoff count ers.

I f Voice and Best Effort are com pared, t hese t raffic cat egories have default defined CWm in
values of 2 and 5, and CWm ax values of 8 and 10, respect ively. Each class of t raffic can have a
different fixed slot t im e, which specifies t he fixed slot backoff int erval ( 0 t o 20) . The default
values for t hese param et ers for each t raffic class are shown in Table 11- 1 .

Ta ble 1 1 - 1 . Cisco Acce ss Poin t s I EEE 8 0 2 .1 1 e ED CF CW m in , CW m a x ,

a n d Fix e d Slot Tim e D e fa u lt Va lu e s ( Cisco I OS 1 2 .2 [ 1 5 ] JA)

CW m in ( M in CW m a x ( M a x
Con t e n t ion Con t e n t ion
Cla ss of Se r vice W in dow ) W in dow ) Fix e d Slot Tim e

Best Effort 5 10 6

Back gr ound 5 10 2
Video < 100 m s Lat ency 4 5 1

Voice < 100 m s Lat ency 3 4 1

From Table 11- 1 , you can see t hat t hat if t wo st at ions were cont ending t o t ransm it voice and
best - effort dat a at t he sam e t im e, t he st at ion t ransm it t ing voice would back off t o a random
value bet ween 3 and 4 ( Voice CWm in and CWm ax) , while t he st at ion t ransm it t ing dat e would
back off t o a value bet ween 5 and 10 ( Best Effort CWm in and CWm ax) . Therefore, t he voice
fram e would be t ransm it t ed before t he dat a fram e.

N ot e
Wit hin EDCF, voice st at ist ically is t ransm it t ed before best - effort dat a. However, voice
m ight not be serviced ahead of dat a in every case because of t he random elem ent of
t he algorit hm . Thus, alt hough EDCF does provide a m echanism for preferent ially
servicing voice, it is im port ant t o not e t hat t his is not a st rict - priorit y m echanism .

The average m axim um random backoff value gives an indicat ion of how quickly and how large
t he random backoff count ers can grow in t he event of a ret ransm ission. Traffic classes wit h t he
sm allest average m axim um values behave t he m ost aggressively.

No m at t er how m any t im es it has ret ried, voice's random backoff delay should not , on average,
be above t hat of t he m inim um delay of best - effort t raffic. This m eans t hat t he average worst -
case backoff delay for voice t raffic would be t he sam e as t he average best case for best - effort
t raffic.

N ot e
 I n t his EDCF operat ion exam ple, all WLAN client s are t reat ed equally for upst ream
t ransm ission ( from t he WLAN client s t o t he AP) .

QoS Basic Service Set Information Element

The WLAN infrast ruct ure devices ( such as APs) advert ise QoS param et ers. WLAN client s wit h
QoS requirem ent s use t hese advert ised QoS param et ers t o det erm ine t he best AP wit h which t o
associat e.

Cisco Aironet soft ware support s t he QoS basic service set ( QBSS) , which is based on I EEE
802.11e draft version 3.3.

Figure 11- 8 shows t he QBSS inform at ion elem ent ( I E) advert ised by a Cisco AP. The Channel
Ut ilizat ion field indicat es t he port ion of available bandwidt h current ly used t o t ransport dat a
wit hin t he WLAN. The Fram e Loss Rat e field indicat es t he port ion of t ransm it t ed fram es t hat
requires ret ransm ission or is discarded as undeliverable.

Figu r e 1 1 - 8 . I EEE 8 0 2 .1 1 e D r a ft Ve r sion 3 .3 : QBSS I E I m ple m e n t a t ion

Enabling I EEE 802.11 QBSS adds inform at ion t o t he access point beacons and probe responses.
This inform at ion helps som e 802.11 phones m ake int elligent choices about t he access point wit h
which t hey should associat e. Som e phones do not associat e wit h an access point wit hout t his
addit ional inform at ion. The QBSS can be enabled t hrough t he Cisco I OS CLI ( as shown in
Exam ple 11- 1) or by t he web GUI ( as shown in Figure 11- 11) .

Ex a m ple 1 1 - 1 . En a blin g I EEE 8 0 2 .1 1 E QBSS Th r ou gh Cisco I OS CLI on

a Cisco Air on e t 1 1 0 0 AP

AP1100(config)#dot11 phone
IEEE 802.1D Classes of Service
I EEE 802.11e classes of service borrow t he classes originally defined in I EEE 802.1D, as
illust rat ed in Table 11- 2 .

Ta ble 1 1 - 2 . I EEE 8 0 2 .1 D Cla sse s of Se r vice

u se r _ pr ior it y Abbr e v ia t ion Tr a ffic Type

1 BK Back gr ound

2 Spare

0 ( default ) BE Best effort

3 EE Excellent effort

4 CL Cont rolled load

5 VI " Video," < 100 m s lat ency and j it t er

6 VO " Voice," < 10 m s lat ency and j it t er

7 NC Net work cont rol

Com pat ibilit y issues are present ed wit h t he use of t hese 802.1D classes of service wit h respect
t o Cisco default s.

For exam ple, Cisco t elephony devices, such as I P phones, follow t he I ETF recom m endat ions ( RFC
3268) of m arking real- t im e t raffic ( voice) t o DSCP EF. The sim plest m apping from ( 6- bit ) DSCP
values t o ( 3- bit ) I P Precedence, CoS, or even MPLS EXP values is t o use t he t hree m ost
significant bit s of t he DSCP for t he I P Precedence/ CoS/ MPLS EXP values. This would m ap DSCP
EF t o CoS 5, which is what Cisco devices do. However, according t o t he ( aging) I EEE 802.1D
st andard, voice should be m apped t o CoS 6. To com pensat e for t his seem ing inconsist ency
bet ween st andards, Cisco Aironet soft ware ( by default when QoS is enabled) m aps I EEE
802.1Q/ p CoS 5 t o I EEE 802.11e CoS 6 so t hat voice t raffic is given highest priorit y over t he
WLAN.
QoS Operation on Cisco APs
When you enable QoS, t he access point queues packet s based on t he Layer 2 class of service
value for each packet . The access point applies QoS policies in t his order:

Pa ck e t s a lr e a dy cla ssifie d. When t he access point receives packet s from a QoS- enabled
swit ch or rout er t hat already has classified t he packet s wit h nonzero 802.1Q/ P user_priorit y
values, t he access point uses t hat classificat ion and does not apply ot her QoS policy rules
t o t he packet s. An exist ing classificat ion t akes precedence over all ot her policies on t he
access point .

N ot e
Even if you have not configured a QoS policy, t he access point always honors t agged
802.1P packet s t hat it receives over t he radio int erface.

QoS Ele m e n t for W ir e le ss Ph on e s se t t in g. I f you enable t he QoS Elem ent for Wireless
Phones set t ing, t raffic from voice client s t akes priorit y over ot her t raffic, regardless of ot her
policy set t ings. The QoS Elem ent for Wireless Phones set t ing t akes precedence over ot her
policies, second only t o previously assigned packet classificat ions.

Policie s you cr e a t e on t h e a cce ss poin t . QoS policies t hat you creat e and apply t o
VLANs or t o t he access point int erfaces are t hird in precedence aft er previously classified
packet s and t he QoS Elem ent for Wireless Phones set t ing.

D e fa u lt cla ssifica t ion for a ll pa ck e t s on VLAN . I f you set a default classificat ion for all
packet s on a VLAN, t hat policy is fourt h in t he precedence list .
Configuring QoS on Cisco APs
QoS is disabled by default ; however, t he radio int erface always honors t agged 802.1P packet s
even when you haven't configured a QoS policy. QoS can be configured t hrough eit her t he Cisco
I OS ( MQC) CLI or t he web- int erface configurat ion ut ilit y provided by t he AP soft ware.

The Cisco I OS MQC CLI provides a very fam iliar synt ax for QoS configurat ion on Cisco APs. I n
Exam ple 11- 2, DSCP EF is m apped t o I EEE 802.1D CoS 6 ( t he I EEE definit ion for voice CoS) and
is applied t o t he I EEE 802.11B radio int erface ( because t his m apping already is enabled by
default , t his part of t he policy is act ually m oot and is provided for synt ax exam ple purposes
only) .

Furt herm ore, t he CWm in and CWm ax values for t he Best Effort and Background classes have
been t uned ( away from t he default s shown in Table 11- 1 ) t o assign Background t raffic a
significant ly less- t han best - effort service ( com pat ible t o t he Scavenger service) . Specifically,
Best - Effort ( Traffic Class 0) is set wit h a CWm in of 5 and a CWm ax of 8, and Background t raffic
( Traffic Class 1) is set t o a CWm in of 9 and a CWm ax of 10.

Ex a m ple 1 1 - 2 . Con figu r in g QoS on a Cisco Air on e t 1 1 0 0 AP

AP1100(config)#class-map match-all VOICE

AP1100(config-cmap)# match ip dscp ef ! Matches voice by DSCP EF
AP1100(config-cmap)#policy-map AP-DOWNSTREAM
AP1100(config-pmap)# class VOICE
AP1100(config-pmap-c)# set cos 6 ! Sets IEEE 802.11e CoS for voice
AP1100(config-pmap-c)#interface Dot11Radio0
AP1100(config-if)# traffic-class best-effort cw-min 5 cw-max 8 fixed-slot 2
AP1100(config-if)# traffic-class background cw-min 9 cw-max 10 fixed-slot 6
AP1100(config-if)# service-policy output AP-DOWNSTREAM

Alt ernat ively, QoS for APs can be configured from t he web GUI . From t he hom e page, choose
Se r vice s > QoS t o bring up t he m ain QoS configurat ion screen, shown in Figure 11- 9.

Figu r e 1 1 - 9 . Cisco Air on e t Soft w a r e W e b- Ba se d Con figu r a t or : QoS

M a in Scr e e n

[View full size image]

CWm in and CWm ax values for each of t he four queues can be adj ust ed from t he 802.11B Access
Cat egories t ab ( see Figure 11- 10) .

Figu r e 1 1 - 1 0 . Cisco Air on e t Soft w a r e W e b- Ba se d Con figu r a t or :

8 0 2 .1 1 B Acce ss Ca t e gor ie s Scr e e n

[View full size image]

Advanced opt ions, such as enabling t he QBSS inform at ion elem ent and disabling t he default
AVVI D priorit y m apping ( of 802.1Q/ p CoS 5 t o I EEE 802.11e CoS 6) , can be select ed from t he
Advanced screen, shown in Figure 11- 11.

Figu r e 1 1 - 1 1 . Cisco Air on e t Soft w a r e W e b- Ba se d Con figu r a t or : QoS

Adva n ce d Scr e e n

[View full size image]

N ot e
The opt ion for m apping I EEE 802.1Q/ p Et hernet packet s m arked wit h CoS 5 t o I EEE
802.11e CoS 6 ( shown in t he Advanced screen) is enabled by default . This enables
sim pler int egrat ion wit h exist ing AVVI D net works already using 802.1Q/ p CoS 5 t o
ident ify voice t raffic. This opt ion also can be disabled ( if necessary) t hrough t he Cisco
I OS CLI wit h t he n o dot 1 1 pr ior it y- m a p a vvid com m and.
Summary
As WLANs cont inue t o proliferat e int o ent erprises, int o sm all/ m edium businesses, int o m obile
hot spot s, and even wit hin hom e net works, t heir use is expanding rapidly t o carry m ult iservice
t raffic, including t im e- sensit ive/ int eract ive applicat ions such as wireless VoI P and video.

To ensure t hat t he WLAN does not becom e t he weakest link in an end- t o- end QoS chain,
st andards bodies such as t he I EEE 802.11e working group are form alizing specificat ions t o
deliver granular service levels across WLAN m edia.

This chapt er overviewed I EEE 802.11 DCF operat ion, including t he funct ion of int erfram e spaces
and cont ent ion windows. Building on t his review, I EEE 802.11e EDCF was int roduced; it allows
for cont ent ion window variance for different t raffic classes. EDCF operat ion was exam ined t o
dem onst rat e how cont ent ion window variance t ranslat es int o relat ive t raffic class priorit ies on
t he WLAN. The I EEE 802.1e QBSS inform at ion elem ent also was covered in brief.

Cisco AP soft ware QoS operat ion and configurat ion was int roduced, including t he Cisco I OS MQC
CLI for AP QoS and t he web- based GUI screens required t o set wireless access- point QoS.
Further Reading

I EEE 802.11 working group: ht t p: / / www.ieee802.org/ 11/ .

I EEE 802.11e st at us: ht t p: / / grouper.ieee.org/ groups/ 802/ 11/ Report s/ t ge_updat e.ht m .

I EEE 802.11e WLAN QoS: ht t p: / / www.eecs.um ich.edu/ ~ shchoi/ My_Papers_Published/ Conferences/ 02- E
.

I EEE 802.11e cont ent ion- based channel access ( EDCF) perform ance evaluat ion:
ht t p: / / pat h.berkeley.edu/ dsrc/ reading/ 03- I CC- EDCF.pdf .

Configuring QoS for WLANs: Cisco I OS Soft ware 12.2.15JA docum ent at ion:
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / wireless/ airo1100/ accsspt s/ i12215j a/ i12215sc/ s15qo
.
Part III: LAN QoS Design
Part I I I of t his book provides an in- dept h discussion of QoS considerat ions and designs for
t he access, dist ribut ion, and core layers of an ent erprise cam pus net work. Det ailed QoS
designs for t he Cisco Cat alyst 2950, 2970, 3550, 3560, 3750, 4500, and 6500 swit ch
plat form s are present ed.

The chapt er in t his part of t he book is as follows:

Chapt er 12 Cam pus QoS Design

Chapter 12. Campus QoS Design
This chapt er discusses QoS considerat ions and design principles for t he access, dist ribut ion, and
core layers of an ent erprise cam pus net work. These include access edge m odels for t rust ed,
unt rust ed, and condit ionally t rust ed endpoint s, along wit h queuing m odels t hat vary on a per-
plat form or per- line card basis.

Det ailed QoS designs for t he following Cat alyst swit ch plat form s are present ed:

Cat alyst 2950

Cat alyst 2970

Cat alyst 3550

Cat alyst 3560

Cat alyst 3750

Cat alyst 4500 ( Supervisors I I + t hrough V)

Cat alyst 6500 ( Supervisor 2/ PFC2 and Supervisor 720/ PFC3)

The case for QoS in WANs and VPNs is, for t he m ost part , self evident sim ply because of t he low-
bandwidt h links involved com pared t o t he high- bandwidt h requirem ent s of m ost applicat ions.
However, in Gigabit and Ten Gigabit cam pus LAN environm ent s, bandwidt h is so plent iful t hat
som et im es t he need for QoS is overlooked or out right challenged.

This is oft en t he case when net work adm inist rat ors equat e QoS wit h queuing only. But , as has
been shown, t he QoS t oolset ext ends considerably beyond j ust queuing t ools. I n addit ion t o
queuing, classificat ion, m arking, and policing are all im port ant QoS funct ions t hat are perform ed
opt im ally wit hin t he cam pus net work, part icularly at t he access- layer ingress edge ( access
edge) .

Three im port ant QoS design principles com e int o play t o m ake t he case for deploying cam pus
QoS policies.

The first is t hat applicat ions should be classified and m arked as close t o t heir sources as
t echnically and adm inist rat ively feasible. This principle prom ot es end- t o- end Different iat ed
Services and Per- Hop Behaviors.

Som et im es endpoint s can be t rust ed t o set CoS and DSCP m arkings correct ly, but , in m ost ,
cases it is not a good idea t o t rust m arkings t hat users can set on t heir PCs ( or ot her sim ilar
devices) . This is because users easily could abuse provisioned QoS policies if perm it t ed t o m ark
t heir own t raffic. For exam ple, if DSCP EF received priorit y services t hroughout t he ent erprise, a
user could configure his PC t o m ark all his t raffic t o DSCP EF right on t he NI C, t hus hij acking
net work priorit y queues t o service non- real- t im e t raffic. Such abuse could ruin t he service
qualit y of Real- Tim e applicat ions ( such as VoI P) t hroughout t he ent erprise. For t his reason, t he
clause " as close as . . . adm inist rat ively feasible" is included in t he design principle.

A second im port ant QoS design principle relat ing t o access- edge QoS design is t hat unwant ed
t raffic flows should be policed as close t o t heir sources as possible. There is lit t le sense in
forwarding unwant ed t raffic only t o police and drop it at a subsequent node. This is especially
t he case when t he unwant ed t raffic is t he result of DoS or worm at t acks. The overwhelm ing
volum es of t raffic t hat such at t acks creat e can readily drive net work device processors t o t heir
m axim um levels, causing net work out ages.

The t hird im port ant design principle is t hat QoS always should be perform ed in hardware rat her
t han soft ware when a choice exist s. Cisco I OS rout ers perform QoS in soft ware, which places
addit ional t axes on t he CPU ( depending on t he com plexit y and funct ionalit y of t he policy) . Cisco
Cat alyst swit ches, on t he ot her hand, perform QoS in dedicat ed hardware ASI CS and, as such,
do not t ax t heir m ain CPUs t o adm inist er QoS policies. Therefore, com plex QoS policies can be
applied at Gigabit and Ten Gigabit Et hernet line speeds in t hese swit ches.

For t hese reasons, QoS policies, such as classificat ion and m arking policies t o est ablish and
enforce t rust boundaries, as well as policers t o prot ect against undesired flows, should be
enabled at t he access edge of t he LAN. However, t he need for queuing in t he cam pus should not
be dism issed.

Som e st udies have shown t hat 95 percent of t he t im e, cam pus access- layer links are ut ilized at
less t han 5 percent of t heir capacit y. Such underut ilizat ion perm it s cam pus net works t o be
designed t o accom m odat e oversubscript ion am ong access, dist ribut ion, and core layers.
Oversubscript ion allows for uplinks t o be ut ilized m ore efficient ly and, m ore im port ant , reduces
t he overall cost t o build t he cam pus net work. Som e t ypical values for cam pus oversubscript ion
are 20: 1 for t he access- t o- dist ribut ion layers and 4: 1 for t he dist ribut ion- t o- core layers, as
shown in Figure 12- 1.

Figu r e 1 2 - 1 . Typica l Ca m pu s Ove r su bscr ipt ion Ra t ios

Under norm al operat ing condit ions, it is quit e rare for cam pus net works t o experience congest ion
and, t hus, have a need for queuing. When congest ion does occur, it is usually m om ent ary and
not sust ained, as at a WAN edge.

Nonet heless, crit ical applicat ions, such as VoI P, require service guarant ees regardless of net work
condit ions. The only way t o provide service guarant ees is t o enable queuing at any node t hat has
t he pot ent ial for congest ionregardless of how rarely t his act ually m ight occur. Because of t he
oversubscript ion rat ios j ust discussed, t he pot ent ial for congest ion exist s in cam pus uplinks.
Furt herm ore, t he pot ent ial for congest ion also exist s in cam pus downlinks because of
m ism at ches ( such as Gigabit Et hernet t oFast Et hernet links) . I n bot h cases, t he only way t o
ensure service guarant ees in t he event of congest ion is t o enable queuing at t hese point s.

So far, t his discussion for enabling queuing wit hin t he cam pus has revolved around net work
requirem ent s under norm al operat ing condit ions. However, probably t he st rongest case for
enabling QoS wit hin t he cam pus is t o consider what happens under abnorm al net work
condit ions, such as a DoS or worm at t ack. During such condit ions, net work t raffic increases
exponent ially unt il links are ut ilized fully. Wit hout QoS, applicat ions are drowned out by t he
worm - generat ed t raffic, causing DoS t hrough unavailabilit y. On t he ot her hand, when QoS
policies are enabled wit hin t he cam pus ( as det ailed lat er in t his chapt er) , VoI P, crit ical
applicat ions, and even Best - Effort t raffic is prot ect ed and serviced if a worm at t ack occurs, t hus
m aint aining t he net work's availabilit y.

I n such worst - case scenarios, t he int rinsic int erdependencies of net work QoS, high- availabilit y,
and securit y are clearly m anifest .

So where is QoS required in t he cam pus?

Access swit ches require t he following QoS policies:

Appropriat e ( endpoint - dependent ) t rust policies

Classificat ion and m arking policies

Policing and m arkdown policies

Queuing policies

Dist ribut ion and core swit ches require t he following:

DSCP- t rust policies

Queuing policies

Opt ionally, per- user m icroflow policing policies ( on dist ribut ion- layer Cat alyst 6500s wit h
Supervisor 720s only)

Figure 12- 2 sum m arizes t hese recom m endat ions.

Figu r e 1 2 - 2 . W h e r e QoS I s Re qu ir e d W it h in t h e Ca m pu s
Som e im port ant considerat ions t o keep in m ind when defining cam pus QoS designs follow:

DoS/ worm - m it igat ion st rat egies

Call- signaling TCP/ UDP port s in use

Access- edge t rust m odels

WAN aggregat or and branch rout er connect ions

Each of t hese concerns is discussed in t he following sect ions.

DoS/Worm-Mitigation Strategies
A proact ive approach t o m it igat ing DoS/ worm flooding at t acks wit hin cam pus environm ent s is t o
respond im m ediat ely t o out - of- profile net work behavior t hat indicat es a DoS or worm at t ack
using access- layer policers. Such policers could m et er t raffic rat es received from endpoint
devices, and when t hese exceed specified wat erm arks ( at which point t hey no longer are
considered norm al flows) , t hese policers could m ark down excess t raffic.

I n t his respect , t he policers would be fairly " dum b." They would not be m at ching specific
net work charact erist ics of specific t ypes of at t acks, but t hey sim ply would be m et ering t raffic
volum es and responding t o abnorm ally high volum es as close t o t he source as possible. The
sim plicit y of t his approach negat es t he need for t he policers t o be program m ed wit h knowledge
of t he specific det ails of how t he at t ack is being generat ed or propagat ed.

I t is precisely t his " dum bness" of such access- layer policers t hat enables t hem t o m aint ain
relevancy as worm s m ut at e and becom e m ore com plex: The policers don't care how t he t raffic
was generat ed, what it looks like, or what port it is being served onall t hey care about is how
m uch t raffic is being put ont o t he wire. Therefore, t hey cont inue t o police even advanced worm s
t hat cont inually change t he t act ics of how t raffic is being generat ed.

For exam ple, in m ost ent erprises, it is abnorm al ( wit hin a 95- percent st at ist ical confidence
int erval) for PCs t o generat e sust ained t raffic in excess of 5 percent of t heir link's capacit y. I n
t he case of a Fast Et hernet swit ch port , t his would m ean t hat it would be unusual in m ost
organizat ions for an end user's PC t o generat e m ore t han 5 Mbps of uplink t raffic on a sust ained
basis.

N ot e

I t is im port ant t o recognize t hat t his value ( 5 percent ) for norm al access- edge
ut ilizat ion by endpoint s is j ust an exam ple value. This value likely varies from indust ry
vert ical t o vert ical, and from ent erprise t o ent erprise. To keep t hings sim ple, t his 5-
percent value is being used in t he exam ples present ed in t his design chapt er.

I t is im port ant t o recognize t hat what is being proposed is not policing all t raffic t o 5 Mbps and
aut om at ically dropping t he excess. I f t hat was t he case, t here would not be m uch reason t o
deploy Fast Et hernet or Gigabit Et hernet swit ch port s t o endpoint devices because even 10BASE-
T Et hernet swit ch port s would have m ore uplink capacit y t han a 5 Mbps policer- enforced lim it .
Furt herm ore, such an approach suprem ely would penalize legit im at e t raffic t hat did exceed 5
Mbps on an FE swit ch port .

A less draconian approach is t o couple access- layer policers wit h hardware and soft ware
( cam pus, WAN, VPN) queuing polices, wit h bot h set s of policies provisioning for a less- t han best -
effort Scavenger class.

This could work by having access- layer policers m ark down out - of- profile t raffic t o DSCP CS1
( Scavenger) and t hen have all congest ion- m anagem ent policies ( whet her in Cat alyst hardware
or in Cisco I OS Soft ware) provision a less- t han best - effort service for any t raffic m arked t o CS1
during periods of congest ion.

Scavenger-Class QoS Operation

This sect ion exam ines how t he Scavenger- class QoS st rat egy for DoS/ worm m it igat ion m ight
work, bot h for legit im at e t raffic t hat exceeds t he access- layer policer's wat erm ark and also in
t he case of illegit im at e excess t raffic ( t he result of a DoS or worm at t ack) .

I n t he form er case, im agine t hat t he PC generat es m ore t han 5 Mbps of t rafficperhaps because
of a large file t ransfer or backup. Wit hin t he cam pus, t here is generally abundant capacit y t o
carry t he t raffic, so congest ion ( under norm al operat ing condit ions) is rarely, if ever,
experienced. This is usually t he case because t he uplinks t o t he dist ribut ion and core layers of
t he cam pus net work are t ypically Gigabit Et hernet and would require ( at least ) 1000 Mbps of
t raffic from t he access- layer swit ch t o experience congest ion.

I f t he t raffic were dest ined for t he far side of a WAN or VPN link ( t hese are rarely great er t han 5
Mbps in speed) , dropping would occur even wit hout t he access- layer policer sim ply because of
bot t lenecks result ing from t he cam pus/ WAN speed m ism at ch. TCP's sliding windows m echanism
event ually would find an opt im al speed ( less t han 5 Mbps) for t he file t ransfer.

To sum m arize, access- layer policers t hat m ark down out - of- profile t raffic t o Scavenger ( CS1)
would not affect legit im at e t raffic, aside from t he obvious re- m arking. No reordering or dropping
would occur on such flows as a result of t hese policers ( t hat would not have occurred anyway) .

I n t he lat t er case, t he effect of access- layer policers on t raffic caused by DoS or worm at t acks is
quit e different . As host s becom e infect ed and t raffic volum es m ult iply, congest ion m ight be
experienced even wit hin t he cam pus. I f j ust 11 end- user PCs on a single swit ch begin spawning
worm flows t o t heir m axim um Fast Et hernet link capacit ies, a GE uplink from t he access- layer
swit ch t o t he dist ribut ion- layer swit ch will becom e congest ed, and queuing and reordering will
engage. At such a point , VoI P and crit ical dat a applicat ionsand even Best - Effort
applicat ionswould gain priorit y over worm - generat ed t raffic ( because t his Scavenger- m arked
t raffic would be dropped t he m ost aggressively) ; net work devices would rem ain accessible for
t he adm inist rat ion of pat ches, plugs, and ACLs required t o fully neut ralize t he specific at t ack.

WAN links also would be prot ect ed: VoI P, Crit ical Dat a, and even Best - Effort flows would
cont inue t o receive priorit y over any t raffic m arked down t o Scavenger/ CS1. This is a huge
advant age because generally WAN links are t he first t o be overwhelm ed by DoS/ worm at t acks.

The bot t om line is t hat access- layer policers significant ly will m it igat e net work t raffic generat ed
by DoS or worm at t acks.

I t is im port ant t o recognize t he dist inct ion bet ween m it igat ing an at t ack and prevent ing it
ent irely: The st rat egy being present ed will not guarant ee t hat no DoS or worm at t acks ever will
happen; it only reduces t he risk and im pact t hat such at t acks could have on t he cam pus net work
infrast ruct ure and t hen, by ext ension, t he WAN and VPN net work infrast ruct ure.
Call-Signaling TCP/UDP Ports in Use
I n t his design chapt er, t o keep t he exam ples relat ively sim ple, only Skinny Call Cont rol Prot ocol
( SCCP) port s ( TCP port s 20002002) are used t o ident ify call- signaling prot ocols.

However, SCCP is by no m eans t he only call- signaling prot ocol used in I P Telephony
environm ent s. Table 12- 1 shows m any of t he TCP/ UDP port s used in a Cisco CallManager
envir onm ent .

DTC

TCP 135

CallManagers in t he sam e clust er

SSH

TCP 22

Secure Shell client

Telnet

TCP 23

Telnet client

DNS
UDP 53

DNS servers

DHCP

UDP 68

UDP 67

DHCP server

DHCP

UDP 68

UDP 67

DHCP client

TFTP

UDP 69

Dynam ic port s used aft er init ial connect

HTTP

TCP 80
Adm inist rat or/ user web browsers

CCMAdm in and CCMUser pages

OSI ( DAP, DSP, DI SP)

TCP or UDP 120

DCD Direct ory

NTP

UDP 123

WI NS

UDP 137 t o 139

WI NS Server

Windows I nt ernet Nam e Service

SNMP

UDP 161

SNMP Trap
UDP 162

LDAP

TCP 389

TCP 389

Direct ory Services

When int egrat ed wit h Corporat e Direct ory

HTTPS/ SSL

TCP 443

SMB

TCP 445

TCP 445

CallManagers in t he sam e clust er

Syslog

TCP 514
UDP 514

Syslog service

RMI

TCP 1099 t o 1129

RMI Service At t endant Console

MS SQL

TCP 1433

TCP 1433

CallManagers in t he sam e clust er

H.323 RAS

TCP 1719

Gat ekeeper RAS

CallManager earlier t han 3.3, Cisco Conference Connect ion

H.323 RAS

TCP 1024 t o 4999

TCP 1719

Gat ekeeper RAS

CallManager 3.3
H.323, H.225

TCP 1720

TCP 1720

H.323 gat eways, anonym ous device Cisco Conference Connect ion, non- Gat ekeeper- cont rolled
H.323 t runk

H.323, H.225/ I CT

TCP 1024 t o 4999

CallManager Gat ekeeper- cont rolled H.323 t runks

CallManager 3.3

H.323, H.245

TCP 1024 t o 4999

TCP 1024 t o 4999

CallManager H.323 gat eways, anonym ous device, H.323 t runks

H.323, H.245

TCP 11000 t o 11999

Cisco I OS H.323 gat eways, Cisco Conference Connect ion

SCCP
TCP 2000

Skinny Client s ( I P phones)

Skinny Gat eway ( Analog)

TCP 2001

Analog Skinny Gat eway

Skinny Gat eway ( Digit al)

TCP 2002

Digit al Skinny Gat eway

MGCP Cont rol

UDP 2427

MGCP Gat eway Cont rol

MGCP Backhaul

TCP 2428
MGCP Gat eways Backhaul

RTS Serv

2500

Cisco Ext ended Service

TCP 2551

Act ive/ backup det erm inat ion

Cisco Ext ended Service

TCP 2552

DB change not ificat ion

RI S Dat a Collect or

TCP 2555

I nt er- RI S com m unicat ion

RI S Dat a Collect or

TCP 2556

Used by client s ( I I S) t o com m unicat e wit h RI S

CTI / QBE

TCP 2748

TAPI / JTAPI applicat ions

Connect s wit h CTI Manager; used by I VR, CCC, PA, Cisco Soft Phone, CRS, I CD, I PCC, I PMA,
At t endant Console, and any ot her applicat ion t hat ut ilizes t he TAPI or JTAPI plug- in; TSP

I PMA Service

TCP 2912

I PMA Assist ant Console

Media St ream ing Applicat ion

UDP 3001

Change not ificat ion

SCCP
TCP 3224

Media resources

Conference bridges, Xcoders

MS Term inal Services

TCP 3389

Windows Term inal Services

Ent ercept HI D Agent

TCP 5000

Host I nt rusion Det ect ion Console

CallManager SI P

TCP/ UDP 5060

TCP 5060

SI P Trunk default port

Can use TCP 1024 t o 65,535

VNC HTTP Helper

TCP 580x
Rem ot e cont rol

VNC Display

TCP 690x

Virt ual Net work Com put er Display

Rem ot e cont rol

CallManager Change Not ificat ion

TCP 7727

CallManager change not ificat ion, Cisco dat abase layer m onit or, Cisco TFTP, Cisco I P m edia
st ream ing, Cisco TCD, Cisco MOH

Real- t im e change not ificat ion

I PMA Service

TCP 8001

I P Manager Assist ant

Change not ificat ion

I CCS

TCP 8002

TCP 8002
CallManagers in t he sam e clust er

I nt raclust er com m unicat ion

CTI M

TCP 8003

Cisco Tom cat

TCP 8007

Web request s

Cisco Tom cat

TCP 8009

Web request s

Cisco Tom cat

TCP 8111

I I S, web request s t o I PMA worker t hread

Cisco Tom cat

TCP 8222

I I S, web request s t o EM applicat ion worker t hread

Cisco Tom cat

TCP 8333

I I S, web request s t o WebDialer applicat ion worker t hread

DC Direct ory

TCP 8404

Em bedded Direct ory Services

Used for Direct ory services, applicat ion aut hent icat ion/ configurat ion, Soft Phone direct ory, user
direct ory

Cisco Tom cat

TCP 8444

I I S, web request s t o EM service worker t hread

Cisco Tom cat

TCP 8555
I I S, web request s t o Apache SOAP worker t hread

Cisco Tom cat

TCP 8998

Web request s

Cisco Tom cat

TCP 9007

I I S, web request s t o CAR worker t hread

RTP

UDP 16384 t o 32767

UDP 16384 t o 32767

Voice m edia

I P I VR m edia, CCC I VR m edia, Cisco Soft Phone, Media St ream ing Applicat ion

Cisco SNMP Trap Agent

UDP 61441

Cisco Alarm I nt erface

Receives som e SNMP alarm in XML form at

Ta ble 1 2 - 1 . Ex a m ple TD P/ UD P Por t s Use d in a Cisco Ca llM a n a ge r

En vir on m e n t

Re m ot e
Re m ot e Ca llM a n a ge r D e vice
Sou r ce D e st in a t ion Ca llM a n a ge r D e st in a t ion Re m ot e
Pr ot ocol Por t Por t Sou r ce Por t Por t D e vice s N ot e s

All relevant call- signaling port s t hat are required for a given I PT environm ent are recom m ended
t o be included in t he access list s t hat ident ify call- signaling prot ocols. Furt herm ore, firewalls
prot ect ing CallManagers should enable addit ional port s t o provide t he supplem ent ary services
t hat CallManagers provide or require.
Access-Edge Trust Models
A prim ary funct ion of access- edge policies is t o est ablish and enforce t rust boundaries. A t rust
boundary is t he point wit hin t he net work where m arkings ( such as CoS or DSCP) begin t o be
accept ed. Previously set m arkings are overridden ( as required) at t he t rust boundary.

The design obj ect ive relat ing t o t rust boundaries is t o enforce t hese as close t o t he endpoint s as
t echnically and adm inist rat ively possible. This is illust rat ed in Figure 12- 3.

Figu r e 1 2 - 3 . Est a blish in g Tr u st Bou n da r ie s

The definit ion of t he t rust boundary depends on t he capabilit ies of t he endpoint s t hat are being
connect ed t o t he access edge of t he LAN. Three m ain cat egories of endpoint s exist , as t hey
relat e t o t rust boundaries:

Trust ed endpoint s

Unt rust ed endpoint s

Condit ionally t rust ed endpoint s

Each of t hese cat egories of endpoint s is discussed in det ail in t he following sect ions.

Trusted Endpoint Models

Trust ed endpoint s have t he capabilit ies and int elligence t o m ark applicat ion t raffic t o t he
appropriat e CoS and DSCP values. Trust ed endpoint s also possess t he capabilit y t o re- m ark
t raffic t hat previously was m arked by an unt rust ed device. For t he m ost part , t rust ed endpoint s
are not m obile devicest he swit ch port t hat t hey are plugged int o generally does not change.
 N ot e
I P phones, which oft en change swit ch port s as users m ove, m ore appropriat ely are
included in t he cat egory of condit ionally t rust ed endpoint s.

Exam ples of t rust ed endpoint s include t hese:

An a log ga t e w a ys These devices are deployed t o connect analog devices ( such as fax
m achines, m odem s, TDD/ TTYs, and analog phones) t o t he VoI P net work so t hat t he analog
signals can be packet ized and t ransm it t ed over t he I P net work. Exam ples of analog
gat eways include t hese:

- The NM- 1V and NM2- V net work m odules, which support eit her High- Densit y or Low-
Densit y Voice/ Fax I nt erface Cards or VI Cs

- The Cisco Com m unicat ion Media Module ( CMM) line card

- The Cat alyst 6500 Analog I nt erface Module ( WS- X6624- FXS)

- The Cisco VG224 and VG248 Cisco I OSbased voice gat eways

- The Cisco ATA 186/ 188 Analog Telephony Adapt ors

I P con fe r e n cin g st a t ion s These devices are designed for m eet ing- room VoI P
conferencing. Essent ially, t hey are specialized I P phones wit h 360° m icrophones and
advanced speakerphones. Exam ples of such devices include t he Cisco 7935 and 7936.

Vide ocon fe r e n cin g ga t e w a ys a n d syst e m s These devices t ransm it int eract ive video
across t he I P net work. Exam ples of such devices capable of set t ing DSCP m arkings include
t he Cisco I P/ VC 3511, 3521, 3526, and 3540 videoconferencing gat eways and syst em s.

Vide o su r ve illa n ce u n it s These ( t hird- part y) devices are used for securit y and rem ot e-
m onit oring purposes over an I P ( as opposed t o a closed- circuit ) net work. These m ight
support DSCP m arking, in which case t hey can be considered t rust ed endpoint s.

Se r ve r s Cert ain servers, wit hin t he dat a cent er or ot herwise, m ight be capable of correct ly
m arking t heir t raffic on t heir NI Cs. I n such cases, t he net work adm inist rat or can choose t o
t rust such m arkings. However, enforcing such a t rust boundary requires cooperat ion
bet ween net work adm inist rat ors and syst em or server adm inist rat ors, an alliance t hat is
oft en fragile, at best , and usually involves considerable finger point ing. Addit ionally,
net work adm inist rat ors should bear in m ind t hat t he m aj orit y of DoS/ worm at t acks t arget
servers. I nfect ed servers not only m ight spew profuse am ount s of t raffic ont o t he net work,
but , in such cases, t hey m ight do so wit h t rust ed m arkings. There's no hard- and- fast rule
t hat will apply t o every sit uat ion. Som e adm inist rat ors prefer t o t rust cert ain servers, like
Cisco CallManagers, due t o t he large num ber of port s t hat m ay be in use t o provide
services ( refer t o Table 12- 1 ) rat her t han adm inist er com plex access list s. I n eit her case,
consider t he t radeoffs involved when deciding whet her or not t o t rust a server.

W ir e le ss a cce ss poin t s Som e wireless APs have t he capabilit y t o m ark or re- m ark 802.1p
CoS or DSCP values and, t herefore, qualify as t rust ed endpoint s. Exam ples include Cisco
Aironet 350, 1100, and 1200 series APs.
 W ir e le ss I P ph on e s Mobile wireless I P phones can m ark DSCP values for VoI P and Call
Signaling and pass t hese on t o t he wireless AP t hey are associat ed wit h. Exam ples include
t he Cisco 7920G wireless I P phone.

When t rust ed endpoint s are connect ed t o a swit ch port , t ypically all t hat is required is enabling
t he following int erface com m and: m ls qos t r u st dscp .

Opt ionally, if t he t raffic rat e of t he t rust ed applicat ion is known, t he net work adm inist rat or could
apply an access- layer policer t o prot ect against out - of- profile rat es, in case t he t rust ed endpoint
som ehow is com prom ised. For exam ple, consider t he case of an I P videoconferencing st at ion
t hat t ransm it s 384 kbps of video ( not including Layers 2 t hrough 4 overhead) and correct ly
m arks t his t raffic t o DSCP AF41. An access- edge ingress policer could be applied t o t he swit ch
port t hat t his I P/ VC st at ion is connect ed t o and could be configured t o t rust up t o 500 kbps
( allowing for Layers 2 t hrough 4 overhead and policer granularit y) of I nt eract ive- Video t raffic
( m arked AF41) ; excess t raffic could be m arked t o CS1. Such a policy would prevent net work
abuse if anot her device was insert ed int o t he pat h ( perhaps t hrough a hub) or if t he t rust ed
endpoint it self becam e com prom ised.

Untrusted Endpoint Models

As previously m ent ioned, t rust ing end users and t heir PCs is generally a bad idea because newer
operat ing syst em s such as Windows XP and Linux m ake it relat ively easy t o set CoS or DSCP
m arkings on PC NI Cs. Such m arkings can be set deliberat ely or even inadvert ent ly. I n eit her
case, im properly set QoS m arkings could affect t he service levels of m ult iple users wit hin t he
ent erprise and m ake t roubleshoot ing a night m are. Also, m arking applicat ion t raffic on server
NI Cs has disadvant ages ( discussed in t he previous sect ion) t hat m ight m ake it preferable t o
t reat t hese as unt rust ed devices.

Alt hough client PCs and dat a cent er servers are relat ed and com plim ent ary, t hey also have
unique considerat ions t hat affect t heir classificat ion and m arking policies, so t hey are exam ined
individually next .

Untrusted PC with SoftPhone Model

I t generally is recom m ended not t o t rust end- user PC t raffic. However, som e PCs m ight be
running applicat ions t hat crit ically require QoS t reat m ent . A classic exam ple is a PC running
Cisco I P Soft Phone. I n such a case, t he crit ical applicat ion would need t o be ident ified t hrough
access list s and m arked or re- m arked at t he access edge. Re- m arking can be done wit h eit her
t he MLS QoS se t ip dscp com m and or wit h a policer.

N ot e
I n t his cont ext , Soft Phone can be used t o refer t o any PC- based I P t elephony
applicat ion.

A policer is recom m ended in t his case because lim it s on t he am ount of t raffic being m arked
could be im posed ( again, t o prevent abuse) . Soft Phones can use regular G.711 codecs ( in which
case, 128 kbps is adequat e) , or t hey can be configured t o use a G.722 ( wide codec, in which
case 320 kbps is required) . The t ight er t he policer is, t he bet t er ( provided t hat adequat e
bandwidt h has been allocat ed for t he applicat ion's requirem ent s) .

Addit ionally, t he UDP port s used by Soft Phone can be defined explicit ly wit hin t he applicat ion
( inst ead of sim ply picking random port s wit hin t he UDP range of 16,383 t o 32,767) . This is
recom m ended, because t his would allow for a m ore granular access list t o m at ch legit im at e
Soft Phone t raffic, t hereby t ight ening t he overall securit y of t he policy.

Figure 12- 4 illust rat es t he logic of such an access- edge policer m arking Soft Phone t raffic from an
unt rust ed PC endpoint .

Figu r e 1 2 - 4 . Un t r u st e d En dpoin t Policin g: PC w it h Soft Ph on e Ex a m ple

[View full size image]

The synt ax for im plem ent ing such a policer m ight vary slight ly from plat form t o plat form , as is
det ailed in t he com ing plat form - specific sect ions.

Untrusted Server Model

As wit h PCs, servers are subj ect t o at t ack and infect ion by worm s and viruses and also should be
policed for t he am ount s of t raffic t hey adm it ont o t he net work. Grant ed, t he values are m uch
great er t han wit h PC endpoint s, and it is up t o net work adm inist rat ors t o profile t raffic pat t erns
from servers t o baseline what is norm al and abnorm al behavior.

As an exam ple, assum e t hat a single server is running m ult iple applicat ionsin t his case, SAP
( TCP port s 3200 t o 3203 and also 3600) , Lot us Not es ( TCP port 1352) , and I MAP ( TCP port s 143
and 220) . SAP is considered a Mission- Crit ical applicat ion and ( unt il Call Signaling m arking on I P
Telephony equipm ent fully m igrat es from DSCP AF31 t o CS3) should be m arked t o DSCP 25.
Lot us Not es is classed as a Transact ional Dat a applicat ion and should be m arked t o DSCP AF21;
I MAP is considered a Bulk Dat a applicat ion and should be m arked t o DSCP AF11.

Applicat ion baselining has shown t hat , 95 percent of t he t im e, t he t raffic rat es for SAP, Lot us
Not es, and I MAP are less t han 15 Mbps, 35 Mbps, and 50 Mbps, respect ively. No ot her t raffic
should em anat e from t he server; t o ensure t his, a final policer t o cat ch any ot her t ype t raffic is
included. Rem em ber, if legit im at e t raffic t em porarily exceeds t hese values, no dropping or
reordering of packet s will occur. However, if t his server becom es infect ed and begins sending
sust ained t raffic in excess of t hese norm al rat es, t he excess would be subj ect t o aggressive
dropping in t he event of link congest ion. Figure 12- 5 shows t he logic of such a policer.
 Figu r e 1 2 - 5 . Un t r u st e d En dpoin t Policin g: M u lt ia pplica t ion Se r ve r
Ex a m ple

[View full size image]

One of t he crit ical concerns in deploying QoS designs for unt rust ed servers is t o rem em ber t hat
t he applicat ions usually are ident ified by source port s, not dest inat ion port s ( as is t he case wit h
client - t o- server access list s) .

Thus, t he access list s for server- t o- client t raffic becom es t his:

permit [ tcp | udp ] any [ eq | range ] any

inst ead of t he access list for client - t o- server t raffic:

permit [ tcp | udp ] any any [ eq | range ]

This is a subt le but crit ical difference.

Conditionally Trusted Endpoint(s) Models

One of t he m ain business advant ages of I P Telephony is t he sim plicit y and relat ed cost savings
of user adds, m oves, and changes. To m ove, all a user has t o do is pick up t he I P phone; plug it
int o t he new locat ion. To m ove, all a user has t o do is pick up t he I P phone, plug it int o t he new
locat ion, and carry on business as usual. I f t he infrast ruct ure support s inline power, it is lit erally
a m at t er of unplugging a single RJ- 45 cable and plugging it in at t he new locat ion.

I P phones are t rust ed devices; PCs are not . This present s a problem when it com es t o
provisioning t rust in a m obile environm ent . Consider t he following exam ple: Port A is configured
t o t rust t he endpoint connect ed t o it , which init ially is an I P phone. Port B is configured not t o
t rust t he endpoint connect ed t o it , which init ially is a PC. As t he result of a m ove, t hese
endpoint s end up plugged int o t he opposit e port s. This breaks t he VoI P qualit y of calls m ade
from t he I P phone ( now plugged int o unt rust ed Port B) and opens t he net work for unint ent ional
or deliberat e abuse of provisioned QoS by t he PC ( now plugged int o t he t rust ed Port A) .

One solut ion is t o place a call t o t he net working help desk when t he m ove is scheduled so t hat
t he swit ch port s can be reconfigured t o t rust or unt rust t he endpoint s, as required. However, t his
approach would dam pen t he m obilit y business advant age of I P Telephony because m anual
net work adm inist rat ion t hen would be required t o com plet e t he m ove.

Anot her solut ion is t o have an int elligent exchange of inform at ion bet ween t he swit ch and t he
devices plugged int o t he port s. I f t he swit ch discovers a device t hat is " t rust wort hy," it can
ext end t rust t o it dynam ically; if not , it will not ext end t hat t rust .

Cisco I P phones use t he lat t er solut ion. I n t he current Cisco im plem ent at ion, t he int elligent
exchange of inform at ion is perform ed t hrough t he Cisco Discovery Prot ocol ( CDP) . Figure 12- 6
shows a condit ional t rust - boundary ext ension grant ed t o an I P phone t hat has passed a CDP
exchange.

Figu r e 1 2 - 6 . Con dit ion a lly Tr u st e d En dpoin t : I P Ph on e Tr u st Bou n da r y

Ex t e n sion a n d Ope r a t ion

[View full size image]

CDP is a light weight , propriet ary prot ocol engineered t o perform neighbor discovery. I t never
was int ended as a securit y or aut hent icat ion prot ocol. Therefore, t o im prove t he securit y of
condit ional t rust ext ension, t he next generat ion of Cisco I P Telephony product s will incorporat e
t he use of advanced prot ocols, such as 802.1x and Ext ensible Aut hent icat ion Prot ocols ( EAP) ,
com bined wit h digit al cert ificat es, t o perform aut hent icat ion.

Cisco 7 9 0 2 G The 7902G is an ent ry- level I P phone t hat addresses t he voice-
com m unicat ion needs of areas where only a m inim al am ount of feat ures is required, such
 as lobbies, hallways, and break room s. These phones probably would not be m oved. The
7902G has only a single 10BASE- T Et hernet port on t he back of t he phone; t herefore, t here
is no hardware support t o connect a PC t o it .

Cisco 7 9 0 5 G The 7905G is a basic I P phone t hat addresses t he voice- com m unicat ion
needs of a cubicle worker who conduct s low t o m edium t elephone t raffic. The Cisco 7905G
has only a single 10BASE- T Et hernet port on t he back of t he phone; t herefore, t here is no
hardware support t o connect a PC t o it .

Cisco 7 9 1 0 G a n d 7 9 1 0 G+ SW The 7910G and 7910G+ SW I P phones address t he voice-

com m unicat ion needs associat ed wit h a recept ion area, lab, m anufact uring floor, or
em ployee wit h a m inim al am ount of t elephone t raffic. The only difference bet ween t he
Cisco 7910G and t he Cisco 7910G+ SW is t hat t he form er has a single 10BASE- T Et hernet
port ( t herefore, t here is no hardware support t o connect a PC t o it ) , and t he lat t er has t wo
10/ 100BASE- T Et hernet port s, which allow a PC t o be connect ed t o t he I P phone.

Cisco 7 9 1 2 G The 7912G is a basic I P phone t hat addresses t he voice- com m unicat ion
needs of a cubicle worker who conduct s low t o m edium t elephone t raffic. The 7912G
support s inline power and an int egrat ed 10/ 100 Et hernet swit ch for connect ing a PC. The
swit ch used in t he 7912G has t he capabilit y t o m ark CoS and DSCP of Voice and Call
Signaling t raffic t hat originat es from t he I P phone, but t he Cisco 7912G does not have t he
capabilit y t o re- m ark CoS values of PC- generat ed t raffic.

Cisco 7 9 4 0 G The 7940G I P phone is suit ed best for an em ployee in a basic office cubicle
environm ent a t ransact ion- t ype worker, for exam plewho conduct s a m edium am ount of
business by t elephone. The 7940G support s inline power and has an int egrat ed 10/ 100
Et hernet swit ch for connect ing a PC.

Cisco 7 9 6 0 G The 7960G is designed t o m eet t he com m unicat ion needs of a professional
worker in an enclosed office environm ent an em ployee who experiences a high am ount of
phone t raffic in t he course of a business day. The 7960G support s inline power and has an
int egrat ed 10/ 100 Et hernet swit ch for connect ing a PC.

Cisco 7 9 7 0 G The 7970G not only addresses t he needs of t he execut ive or m aj or decision
m aker, but also brings net work dat a and applicat ions t o users wit hout PCs. This I P phone
includes a backlit , high- resolut ion color t ouch- screen display. Current ly, Cisco 7970G is t he
only Cisco I P phone t hat support s bot h Cisco prest andard Power over Et hernet ( PoE) and
t he I EEE 802.3af PoE. The 7970G has an int egrat ed 10/ 100 Et hernet swit ch for connect ing
a PC.

All t hese I P phones have t he capabilit y t o m ark 802.1Q/ p CoS values for bot h VoI P and Call
Signaling ( default values are 5 and 3, respect ively) . Furt herm ore, t hey have t he capabilit y t o
m ark DSCP values for bot h VoI P and Call Signaling ( current default s are EF and AF31,
respect ively; fut ure soft ware releases will change t hese values t o EF and CS3, respect ively) .

I P phone m odels 7902G, 7905G, and 7910G lack t he hardware t o connect ing a PC behind t he I P
phone. All ot her I P phone m odels from t he preceding list ( except t he 7912G) have t he hardware
support t o connect a PC behind t he I P phone and also support 802.1Q/ p CoS re- m arking of
t agged packet s t hat originat e from such PCs.

The 10/ 100 Et hernet swit ch built int o t he 7912G does not have t he support t o re- m ark CoS
values t hat m ight have been set by a PC, as illust rat ed in Figure 12- 7. This re- m arking lim it at ion
represent s a pot ent ial securit y hole for ent erprises deploying t hese I P phones. However, t his
hole can be plugged, for t he m ost part , wit h access- edge policers, as will be det ailed in t his
chapt er. I t is im port ant t o not e t hat if 7912G I P phones are deployed t o users t hat m ove
locat ions, all user swit ch port s wit hin t he ent erprise should have access- edge policers set on
t hem t o ensure m obilit y and securit y if a 7912G user m oves t he phones t o anot her port .
 Figu r e 1 2 - 7 . Con dit ion a lly Tr u st e d En dpoin t : 7 9 1 2 G I P Ph on e Tr u st
Bou n da r y Ex t e n sion a n d Ope r a t ion

[View full size image]

Conditionally Trusted IP Phone + PC: Basic Model

I n t his m odel, t rust ( of CoS m arkings) is ext ended t o CDP- verified I P phones. An addit ional layer
of prot ect ion can be offered by access- edge policers. As st at ed previously, t he t ight er t he
policers are, t he bet t er, provided t hat adequat e bandwidt h is perm it t ed for legit im at e
applicat ions. The m ost granular policing can be achieved by t he use of per- port or per- VLAN
policers.

N ot e
At t he t im e of t his writ ing, only t he Cat alyst 3550 fam ily support s per- port and per-
VLAN policing as a feat ure. Ot her plat form s already have com m it t ed t o support ing t his
feat ure in t he near fut ure. For plat form s t hat do not yet support t his feat ure,
equivalent logic can be achieved by including subnet inform at ion wit hin t he access list s
being referenced by t he class m aps. Such exam ples are provided lat er in t his chapt er.

For exam ple, t he peak am ount s of legit im at e t raffic originat ing from t he voice VLAN ( VVLAN) are
as follows:

128 kbps for Voice t raffic ( m arked CoS 5/ DSCP EFt his is 320 kbps, in t he case of G.722
codecs)
 32 kbps for Call- Signaling t raffic ( m arked CoS 3/ DSCP AF31 or CS3)

32 kbps of Best - Effort services t raffic ( m arked CoS 0)

No ot her t raffic should originat e from t he VVLAN, so t he policer could be configured t o re- m ark
anyt hing else from t he VVLAN ( because such t raffic would be considered illegit im at e and
indicat ive of an at t ack) .

These policers t hen could be com bined wit h a policer t o m et er t raffic from t he dat a VLAN
( DVLAN) , m arking down t raffic in excess of 5 percent ( 5 Mbps for FE port s) t o Scavenger/ CS1.

Figure 12- 8 illust rat es t he logic of t hese policers.

Figu r e 1 2 - 8 . Con dit ion a lly Tr u st e d En dpoin t Policin g: I P Ph on e + PC

( Ba sic M ode l)

[View full size image]

Conditionally Trusted IP Phone + PC: Advanced Model

Building on t he previous m odel, addit ional m arking and policing can be added for PC- based
videoconferencing and m ult iple levels of dat a applicat ions.

Deskt op videoconferencing applicat ions use t he sam e UDP port range, by default , as does
Soft Phone. I f t he UDP port s t hat t he deskt op videoconferencing applicat ion uses can be defined
explicit ly wit hin t he applicat ion, as wit h Soft Phone, t wo policers can be used: one for I P/ VC and
anot her for Soft Phone. Ot herwise, a single policer covering t he UDP port range of 16,384 t o
32,767 is required. This policer would be provisioned for t he worst - case scenario of legit im at e
t raffic. I n t his case, t his would be t he videoconferencing applicat ion's requirem ent of 500 kbps
( for a 384- kbps deskt op I P/ VC applicat ion) , as com pared t o Soft Phone's requirem ent of 128
kbps ( or 320 kbps for G.722 codecs) .

Addit ional dat a VLAN policers can be added t o m et er Mission- Crit ical, Transact ional, and Bulk
Dat a flows. Each of t hese classes can be policed on ingress t o t he swit ch port t o an in- profile
am ount , such as 5 percent each.
 N ot e
Because Mission- Crit ical and Transact ional Dat a applicat ions are int eract ive foreground
applicat ions t hat require user input , it is highly unlikely t hat bot h of t hese t ypes of
applicat ions will be generat ing 5 Mbps each sim ult aneously from a client PC. However,
in t he rare case t hat t hey are, t hese flows are policed furt her by any per- user
m icroflow policing policies t hat are deployed on dist ribut ion- layer Cat alyst 6500
Supervisor 720s ( PFC3s) , as det ailed lat er in t his chapt er.

Anot her fact or t o keep in m ind is t hat cert ain Cat alyst plat form s allow only up t o eight policers
per Fast Et hernet port . Therefore, t he m odel present ed here is m ade t o conform t o t his
const raint , t o m ake it m ore generic and m odular. For t his reason, a separat e policer has not
been defined for Call- Signaling t raffic from Soft Phone, but an access list t o ident ify such t raffic
could be included wit hin t he Mission- Crit ical Dat a access list s, which is det ailed in t he
configurat ion exam ples present ed lat er in t his chapt er.

Figure 12- 9 illust rat es t he logic of t hese advanced policers.

Figu r e 1 2 - 9 . Con dit ion a lly Tr u st e d En dpoin t Policin g: I P Ph on e + PC

( Adva n ce d M ode l)

[View full size image]

Catalyst 2950 QoS Considerations and Design
The Cat alyst 2950 does not support Layer 3 forwarding and, as such, is applicable only as a
( low- end) access- layer swit ch. Figure 12- 10 shows t he QoS design opt ions for a Cat alyst 2950.

Figu r e 1 2 - 1 0 . Acce ss- La ye r Ca t a lyst 2 9 5 0 QoS D e sign

I t is recom m ended t o use t he Enhanced I m age ( EI ) versions of Cisco I OS Soft ware on t hese
plat form s because t hese offer addit ional QoS feat ures, such as MQC/ ACL classificat ion opt ions,
policing and m arkdown funct ions, m apping t ables, and Aut oQoS.

Catalyst 2950: Trusted Endpoint Model

Configuring a Cat alyst 2950 cam pus t o t rust an endpoint is fairly st raight forward, as shown in
Exam ple 12- 1 . The t rust ed endpoint should be assigned eit her t he voice VLAN ( VVLAN) or t he
dat a VLAN ( DVLAN) wit h t he appropriat e swit ch port com m ands.

Ex a m ple 1 2 - 1 . Ca t a lyst 2 9 5 0 : Tr u st e d En dpoin t Ex a m ple

CAT2950(config)#interface FastEthernet0/1
CAT2950(config-if)#mls qos trust dscp

Cat alyst MLS QoS verificat ion com m and:

sh ow m ls qos in t e r fa ce

Catalyst MLS QoS Verification Command: show mls qos interface

The sh ow m ls qos in t e r fa ce verificat ion com m and report s t he configured t rust st at e and t he
current operat ing t rust m ode of a swit ch port int erface.

I n Exam ple 12- 2 , t he com m and verifies t hat int erface Fast Et hernet 0/ 1 correct ly is t rust ing t he
DSCP values of t he endpoint t o which it is connect ed.

Ex a m ple 1 2 - 2 . sh ow m ls qos in t e r fa ce Verificat ion of a Swit ch Port

Connect ed t o a Trust ed Endpoint

CAT2950#show mls qos interface FastEthernet0/1

FastEthernet0/1
trust state: trust dscp ! Configured trust state is to trust DSCP
trust mode: trust dscp ! Current operating mode is to trust DSCP
COS override: dis
default COS: 0
pass-through: none
trust device: none
CAT2950#

Catalyst 2950: Untrusted PC with SoftPhone Model

The Cat alyst 2950 does not support t he r a n ge keyword wit hin an ACL when t he ACL is being
referenced by an MQC class m ap. Therefore, a policy t o m ark UDP flows in t he port range of
16,384 t hrough 32,767 cannot be configured on t he Cat alyst 2950.

A possible workaround t o t his lim it at ion is t o preset t he port ( s) t o be used by Soft Phone wit hin
t he applicat ion it self. I n such a case, t hese port s would have t o be m at ched discret ely by ACL
ent ries on t he Cat alyst 2950. Furt herm ore, each port being used for Call- Signaling also would
require a discret e ACL ent ry.

However, even when all t hese port s are but t oned down and discret e ACLs are configured on t he
Cat alyst 2950 t o m at ch t hem , anot her lim it at ion of t he swit ch com es int o play. Specifically, t he
Cat alyst 2950 can support policing in only 1- Mbps increm ent s on Fast Et hernet port s. Such lax
policing leaves a fairly large hole t o allow unaut horized t raffic t hat is m im icking Voice or Call-
Signaling t o be adm it t ed ont o t he net work.

Because of t hese lim it at ions, it is not recom m ended t o use a Cat alyst 2950 t o support an
unt rust ed PC running Soft Phone.

Catalyst 2950: Untrusted Server Model

For t he m ost part , t he Cat alyst 2950 can support t he Unt rust ed Mult iapplicat ion Server m odel,
illust rat ed in Figure 12- 5 . Only t he final elem ent of t he logical m odelnam ely, t he policing of all
ot her t raffic t o 1 Mbps ( re- m arking t raffic in excess of t his lim it t o CS1) is not support ed on t he
Cat alyst 2950.

These m ain plat form - specific caveat s should be kept in m ind when deploying t his m odel on t he
Cat alyst 2950:

Nonst andard DSCP values are not support ed; t herefore, Mission- Crit ical Dat a t raffic cannot
 be m arked t o DSCP 25 on Cat alyst 2950s ( a t em porary recom m endat ion during t he int erim
of t he Cisco Call- Signaling m arking m igrat ion from AF31 t o CS3) . Such applicat ion t raffic
alt ernat ively can be m arked t o t he m ore general class of Transact ional Dat a ( AF21) , of
which it is a subset .

The m ls qos cos ove r r ide in t e r fa ce com m and m ust be used t o ensure t hat unt rust ed
CoS values explicit ly are set t o 0 ( default ) .

The r a n ge keyword cannot be used in t he ACLs being referenced by t he class m aps; server
port s should be defined explicit ly wit h a separat e access cont rol ent ry ( ACE) per TCP/ UDP
por t .

User- defined m asks m ust be consist ent for all ACLs being referenced by class m aps. ( I f
filt ering is being done against TCP/ UDP port s, all ACEs should be set t o filt er by TCP/ UDP
port s inst ead of som e ACEs filt ering by port s and ot hers by subnet or host addresses.)

Syst em - defined m asks ( such as pe r m it ip a n y a n y ) cannot be used in conj unct ion wit h
user- defined m asks ( such as pe r m it t cp a n y a n y e q 3 2 0 0 ) wit hin t he sam e policy m ap.
Therefore, if som e t raffic is being m at ched against TCP/ UDP port s, a final ACL cannot be
used t o m at ch all ot her t raffic t hrough a pe r m it ip a n y a n y st at em ent .

The Cat alyst 2950 I OS im plem ent at ion of MQC's class- default current ly does not funct ion
com pat ibly wit h m ainline Cisco I OS. The QoS feat ures and act ions defined wit hin class-
default should be applied t o all ot her t raffic t hat is not m at ched explicit ly by a class m ap,
but t est ing has shown t hat t his is not t he case.

N ot e
These lim it at ions are based on t est ing perform ed using Cat alyst 2950 I OS 12.1( 19) EA1
versions a t hrough c and 12.1( 20) EA1. Addit ional inform at ion on t hese caveat s can be found
at

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 2950/ 12119ea1/ 2950scg/ swacl.ht m

and

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 2950/ 12119ea1/ 2950scg/ swqos.ht m
.

Exam ple 12- 3 det ails t he Cat alyst 2950 configurat ion t o support t he Unt rust ed Mult iapplicat ion
Server m odel ( illust rat ed in Figure 12- 5 ) .

Ex a m ple 1 2 - 3 . Ca t a lyst 2 9 5 0 : Un t r u st e d M u lt ia pplica t ion Se r ve r

Ex a m ple

CAT2950(config)#class-map SAP
CAT2950(config-cmap)# match access-group name SAP
CAT2950(config-cmap)#class-map LOTUS
CAT2950(config-cmap)# match access-group name LOTUS
CAT2950(config-cmap)#class-map IMAP
CAT2950(config-cmap)# match access-group name IMAP
CAT2950(config-cmap)#exit
CAT2950(config)#
CAT2950(config)#policy-map UNTRUSTED-SERVER
CAT2950(config-pmap)# class SAP
CAT2950(config-pmap-c)# set ip dscp 18 ! DSCP 25 is not supported
CAT2950(config-pmap-c)# police 15000000 8192 exceed-action dscp 8
! Out-of-profile Mission-Critical is marked down to Scavenger (CS1)
CAT2950(config-pmap-c)# class LOTUS
CAT2950(config-pmap-c)# set ip dscp 18 ! Transactional Data is marked AF21
CAT2950(config-pmap-c)# police 35000000 8192 exceed-action dscp 8
! Out-of-profile Transactional Data is marked down to Scavenger (CS1)
CAT2950(config-pmap-c)# class IMAP
CAT2950(config-pmap-c)# set ip dscp 10 ! Bulk Data is marked AF11
CAT2950(config-pmap-c)# police 50000000 8192 exceed-action dscp 8
! Out-of-profile Bulk Data is marked down to Scavenger (CS1)
CAT2950(config-pmap-c)# exit
CAT2950(config-pmap)# exit
CAT2950(config)#
CAT2950(config)#interface FastEthernet0/1
CAT2950(config-if)# mls qos cos override ! Untrusted CoS is remarked to 0
CAT2950(config-if)# service-policy input UNTRUSTED-SERVER
CAT2950(config-if)#exit
CAT2950(config)#
CAT2950(config)#ip access-list extended SAP
CAT2950(config-ext-nacl)# permit tcp any eq 3200 any
CAT2950(config-ext-nacl)# permit tcp any eq 3201 any
CAT2950(config-ext-nacl)# permit tcp any eq 3202 any
CAT2950(config-ext-nacl)# permit tcp any eq 3203 any
CAT2950(config-ext-nacl)# permit tcp any eq 3600 any
CAT2950(config-ext-nacl)#
CAT2950(config-ext-nacl)#ip access-list extended LOTUS
CAT2950(config-ext-nacl)# permit tcp any eq 1352 any
CAT2950(config-ext-nacl)#
CAT2950(config-ext-nacl)#ip access-list extended IMAP
CAT2950(config-ext-nacl)# permit tcp any eq 143 any
CAT2950(config-ext-nacl)# permit tcp any eq 220 any
CAT2950(config-ext-nacl)#end
CAT2950#

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos in t e r fa ce

sh ow m ls qos in t e r fa ce police r s

sh ow cla ss- m a p

sh ow policy- m a p

sh ow m ls m a sk s qos

Catalyst MLS QoS Verification Command: show mls qos interface policers

The sh ow m ls qos in t e r fa ce police r s verificat ion com m and report s all configured policers
at t ached t o t he specified int erface.

I n Exam ple 12- 4 , t he policers defined for Mission- Crit ical, Transact ional, and Bulk Dat a t hat are
applied t o Fast Et hernet 0/ 1 are confirm ed.

Ex a m ple 1 2 - 4 . sh ow m ls qos in t e r fa ce police r s Verificat ion of a Swit ch

Port Connect ed t o an Unt rust ed Mult iapplicat ion Server

CAT2950#show mls qos interface FastEthernet0/1 policers

FastEthernet0/1
policymap=UNTRUSTED-SERVER
type=Single rate=15000000, burst=8192 ! Mission-Critical Data Policer
type=Single rate=35000000, burst=8192 ! Transactional Data Policer
type=Single rate=50000000, burst=8192 ! Bulk Data Policer
CAT2950#

Catalyst MLS QoS Verification Commands: show class-map and show policy-map

The sh ow cla ss- m a p and sh ow policy- m a p verificat ion com m ands report t he class m ap and
policy m aps t hat have been configured globally ( regardless of whet her t hey've been applied t o
an int erface) .

I n Exam ple 12- 5 , t he class m aps for SAP, LOTUS, and I MAP are displayed, as is t he policy m ap
UNTRUSTED- SERVER t hat is referencing t hese.

Ex a m ple 1 2 - 5 . sh ow cla ss- m a p and sh ow policy- m a p Verificat ion of a

Swit ch Connect ed t o an Unt rust ed Mult iapplicat ion Server

CAT2950#show class-map
Class Map match-all SAP (id 1)
Match access-group name SAP
Class Map match-all LOTUS (id 2)
Match access-group name LOTUS
Class Map match-all IMAP (id 3)
Match access-group name IMAP
Class Map match-any class-default (id 0)
Match any
CAT2950#show policy-map
Policy Map UNTRUSTED-SERVER
class SAP
set ip dscp 18
police 15000000 8192 exceed-action dscp 8
class LOTUS
set ip dscp 18
police 35000000 8192 exceed-action dscp 8
class IMAP
set ip dscp 10
police 50000000 8192 exceed-action dscp 8
CAT2950#
Catalyst MLS QoS Verification Command: show mls masks qos

The sh ow m ls m a sk s qos verificat ion com m and is helpful in keeping t rack of t he num ber of
user- defined or syst em - defined m asks t hat are being applied by ACEs t hat are referenced by
MQC class m aps.

I n Exam ple 12- 6 , t he ACEs being referenced by QoS policies are using I P prot ocol m asks,
including ( TCP/ UDP) source port s.

Ex a m ple 1 2 - 6 . sh ow m ls m a sk s qos Verificat ion of a Swit ch Connect ed t o

an Unt rust ed Mult iapplicat ion Server

CAT2950#show mls masks qos

Mask1
Type : qos
Fields : ip-proto, src-port
Policymap : UNTRUSTED-SERVER
Interfaces : Fa0/1
CAT2950#

Catalyst 2950: Conditionally Trusted IP Phone + PC: Basic Model

When configuring an access swit ch t o t rust or condit ionally t rust CoS, t he default m apping for
CoS 5 should be adj ust ed t o point t o DSCP EF ( 46) inst ead of DSCP CS5 ( 40) . This m odificat ion
is shown in Exam ple 12- 7 .

Ex a m ple 1 2 - 7 . Ca t a lyst 2 9 5 0 : CoS- t o- D SCP M a r k in g M odifica t ion for

Voice

CAT2950(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56 ! Maps CoS 5 to EF

CAT2950(config)#

N ot e
Adj ust ing t he default CoS- t o- DSCP m apping for Call Signaling ( which form erly was
m apped from CoS 3 t o DSCP AF31/ 26) no longer is required. This is because t he
default m apping of CoS 3 point s t o DSCP CS3 ( 24) , which is t he Call- Signaling m arking
t hat all Cisco I P Telephony devices m arkings will m igrat e t o.

Cat alyst MLS QoS verificat ion com m ands:

 sh ow m ls qos m a p

sh ow m ls qos m a p cos- dscp

sh ow m ls qos m a p dscp- cos

Catalyst MLS QoS Verification Command: show mls qos map [cos-dscp | dscp-cos]

The sh ow m ls qos m a p verificat ion com m and ret urns t he DSCP- t o- CoS and CoS- t o- DSCP
m appings. These m appings can be eit her t he default m appings or m anually configured overrides.

I n Exam ple 12- 8 , t he default m apping for CoS 5 ( DSCP CS5) has been m odified t o point t o
DSCP EF inst ead.

Ex a m ple 1 2 - 8 . sh ow m ls qos m a p Verificat ion for a Cat alyst 2950 Swit ch

CAT2950#show mls qos map

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

Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 46 48 56 ! CoS 5 is now mapped to DSCP EF
CAT2950#

The Cat alyst 2950's hardware policers lack t he granularit y t o im plem ent t he Condit ionally
Trust ed I P Phone + PC: Basic m odel, illust rat ed in Figure 12- 8 . However, t hey can im plem ent a
sim plified version of t his m odel, shown in Figure 12- 11 .

Figu r e 1 2 - 1 1 . Ca t a lyst 2 9 5 0 : Con dit ion a lly Tr u st e d En dpoin t Policin g:

I P Ph on e + PC ( Ba sic M ode l)

[View full size image]

I t should be kept in m ind t hat t he coarse granularit y of t he Cat alyst 2950's policers ( which are
configured in 1 Mbps m inim um increm ent s on Fast Et hernet int erfaces) pot ent ially could allow up
t o 1 Mbps of t raffic m im icking legit im at e voice t raffic per condit ionally t rust ed swit ch port .
Exam ple 12- 9 shows t he configurat ion for configuring a swit ch port t o condit ionally t rust an I P
phone t hat has a PC connect ed t o it .

Ex a m ple 1 2 - 9 . Ca t a lyst 2 9 5 0 : Con dit ion a lly Tr u st e d I P Ph on e + PC:

Ba sic M ode l Ex a m ple

CAT2950(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56 ! Maps CoS 5 to EF

CAT2950(config)#
CAT2950(config)#class-map VVLAN-ANY
CAT2950(config-cmap)# match access-group name VVLAN-ANY
CAT2950(config-cmap)#class-map DVLAN-ANY
CAT2950(config-cmap)# match access-group name DVLAN-ANY
CAT2950(config-cmap)#exit
CAT2950(config)#
CAT2950(config)#policy-map IPPHONE+PC
CAT2950(config-pmap)# class VVLAN-ANY
CAT2950(config-pmap-c)# police 1000000 8192 exceed-action drop
! Out-of-profile traffic from the VVLAN is dropped
CAT2950(config-pmap-c)# class DVLAN-ANY
CAT2950(config-pmap-c)# set ip dscp 0
! Optional remarking in case trust is compromised
CAT2950(config-pmap-c)# police 5000000 8192 exceed-action dscp 8
! Out-of-profile data traffic is marked down to Scavenger
CAT2950(config-pmap-c)#exit
CAT2950(config-pmap)#exit
CAT2950(config)#
CAT2950(config)#
CAT2950(config)#interface FastEthernet0/1
CAT2950(config-if)# switchport access vlan 10! DVLAN
CAT2950(config-if)# switchport voice vlan 110! VVLAN
CAT2950(config-if)# mls qos trust device cisco-phone ! Conditional trust
CAT2950(config-if)# mls qos trust cos ! Trust CoS from IP Phone
CAT2950(config-if)# service-policy input IPPHONE+PC ! Policing policy
CAT2950(config-if)#exit
CAT2950(config)#
CAT2950(config)#ip access-list standard VVLAN-ANY
CAT2950(config-std-nacl)# permit 10.1.110.0 0.0.0.255 ! VVLAN subnet
CAT2950(config-std-nacl)#
CAT2950(config-std-nacl)#ip access-list standard DVLAN-ANY
CAT2950(config-std-nacl)# permit 10.1.10.0 0.0.0.255 ! DVLAN subnet
CAT2950(config-std-nacl)#end
CAT2950#

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos in t e r fa ce

sh ow m ls qos in t e r fa ce police r s

sh ow m ls qos m a p

sh ow cla ss- m a p
 sh ow policy- m a p

sh ow m ls m a sk s qos

Catalyst 2950: Conditionally Trusted IP Phone + PC: Advanced Model

Because of t he previously discussed caveat s and lim it at ions of t he Cat alyst 2950 ( including t he
m axim um num ber of policers support ed per FE int erface, t he overly coarse policer granularit y,
t he incapabilit y t o m ix user- defined m asks wit h syst em - defined m asks, and ot her const raint s) ,
t he Condit ionally Trust ed I P Phone + PC: Advanced m odel, shown in Figure 12- 9 , cannot be
support ed on t his plat form .

Catalyst 2950: Queuing

The Cat alyst 2950 can be configured t o operat e in a 4Q1T m ode or in a 1P3Q1T m ode ( wit h
queue 4 being configured as a st rict - priorit y queue) ; t he 1P3Q1T m ode is recom m ended for
converged net works.

The st rict - priorit y queue is enabled by configuring t he fourt h queue's weight param et er, as
defined in t he w r r - qu e u e ba n dw idt h com m and, t o be 0 ( as shown in Exam ple 12- 10 ) .

The rem aining bandwidt h is allocat ed t o t he ot her queues according t o t heir defined weight s. To
allocat e rem aining bandwidt hs of 5 percent , 25 percent , and 70 percent t o queues 1, 2, and 3,
weight s of 5, 25, and 70 can be assigned t o t hese queues, respect ively. The logic of t hese
bandwidt h allocat ions recom m endat ions is discussed in m ore det ail m om ent arily.

N ot e
The absolut e values assigned t o t hese queue weight s are m eaningless, as t hese
weight s are ent irely relat ive. Therefore, t hese weight s can be reduced by dividing each
weight by t he lowest com m on denom inat or ( in t his case, 5) t o arrive at queue weight s
of 1, 5, and 14 for queues 1, 2, and 3, respect ively.

Reduct ion is st rict ly opt ional and m akes no difference t o t he servicing of t he queues.
Many net work adm inist rat ors t end t o prefer defining bandwidt h allocat ion rat ios as
percent ages, so bandwidt h weight rat ios are not reduced in t his design chapt er.

So far, cam pus QoS designs have been present ed for t he first half of t he DoS/ worm - m it igat ion
st rat egy discussed at t he beginning of t his chapt ernam ely, designs for access- layer policers t o
m ark down out - of- profile t raffic t o t he Scavenger class PHB of CS1.

The second vit al com ponent of t his st rat egy is t o m ap Scavenger class t raffic int o a less- t han
best - effort queuing st ruct ure, ensuring t hat all ot her t raffic will be serviced ahead of it in t he
event of congest ion.

The Cat alyst 2950, like m ost Cat alyst plat form s, support s t he m apping of CoS values int o
queues. The CoS value t hat corresponds t o Scavenger ( DSCP CS1) is CoS 1; t his CoS value is
shared wit h Bulk Dat a ( DSCP AF11) . Therefore, a sm all am ount of bandwidt h ( 5 percent ) is
allocat ed t o t he less- t han- best - effort queue: Q1. Q1 t hus services legit im at e Bulk Dat a t raffic
but const rains out - of- profile Scavenger t rafficwhich could be t he result of a DoS/ worm at t ackt o a
sm all am ount ( less t han 5 percent ) , in t he event of congest ion.
The next queue, Q2, t hen is assigned t o service Best - Effort t raffic. A previously discussed design
principle regarding Best - Effort bandwidt h allocat ion is t o allocat e approxim at ely 25 percent of a
link's bandwidt h t o service Best - Effort t raffic. I n t his m anner, t he sheer volum e of t raffic t hat
default s t o Best - Effort cont inues t o get adequat e bandwidt h, bot h in t he event of m om ent ary
cam pus congest ion ( because of burst s in t he am ount of legit im at e t raffic) and even in t he case
of a DoS/ worm at t ack.

Preferent ial applicat ions, such as Transact ional Dat a, Mission- Crit ical Dat a, Call- Signaling,
Net work and I nt ernet work Cont rol and Managem ent , and bot h I nt eract ive- and St ream ing- Video,
are serviced by Q3. Q3 is allocat ed 70 percent of t he rem aining bandwidt h ( aft er t he PQ has
serviced it s Voice t raffic) .

Figure 12- 12 illust rat es t he recom m ended 1P3Q1T queuing m odel for t he Cat alyst 2950, along
wit h CoS- t o- queue assignm ent s.

Figu r e 1 2 - 1 2 . Ca t a lyst 2 9 5 0 1 P3 Q1 T Qu e u in g M ode l

[View full size image]

The configurat ion of t he priorit y queue ( Q4) and t he bandwidt h allocat ions for t he rem aining
queues ( Q1, Q2, and Q3) are shown in Exam ple 12- 10 .

Ex a m ple 1 2 - 1 0 . Ca t a lyst 2 9 5 0 Sch e du lin g Con figu r a t ion : 1 P3 Q1 T

Ex a m ple

CAT2950(config)#wrr-queue bandwidth 5 25 70 0 ! Q1-5%, Q2-25%, Q3-70%, Q4=PQ

CAT2950(config)#

Cat alyst MLS QoS verificat ion com m and:

 sh ow w r r - qu e u e ba n dw idt h

Catalyst MLS QoS Verification Command: show wrr-queue bandwidth

The sh ow w r r - qu e u e ba n dw idt h verificat ion com m and displays t he weight s t hat have been
assigned t o t he queues. I f t he com m and ret urns a value of 0 for t he weight of t he fourt h queue,
t his indicat es t hat t he scheduler is operat ing in 1P3Q1T m ode, wit h Q4 being t he st rict - priorit y
queue.

I n Exam ple 12- 11 , t he scheduler has been configured for 1P3Q1T queuing: Q1 get s 5 percent of
t he rem aining bandwidt h ( aft er t he priorit y queue has been fully serviced) , Q2 get s 25 percent ,
and Q3 get s 70 percent .

Ex a m ple 1 2 - 1 1 . sh ow w r r - qu e u e ba n dw idt h Verificat ion for a Cat alyst

2950 Swit ch

CAT2950#show wrr-queue bandwidth

WRR Queue : 1 2 3 4
Bandwidth : 5 25 70 0 ! Q1 gets 5%, Q2 gets 25%, Q3 gets 70%, Q4 is PQ
CAT2950#

Exam ple 12- 12 shows t he CoS- t o- queue m apping configurat ion for t he Cat alyst 2950.

Ex a m ple 1 2 - 1 2 . Ca t a lyst 2 9 5 0 CoS- t o- Qu e u e M a ppin g Ex a m ple

CAT2950(config)#wrr-queue cos-map 1 1 ! Scavenger/Bulk is assigned to Q1

CAT2950(config)#wrr-queue cos-map 2 0 ! Best Effort is assigned to Q2
CAT2950(config)#wrr-queue cos-map 3 2 3 4 6 7 ! CoS 2,3,4,6,7 are assigned to Q3
CAT2950(config)#wrr-queue cos-map 4 5 ! VoIP is assigned to Q4 (PQ)
CAT2950(config)#

Cat alyst MLS QoS verificat ion com m and:

sh ow w r r - qu e u e cos- m a p

Catalyst MLS QoS Verification Command: show wrr-queue cos-map

The sh ow w r r - qu e u e cos- m a p verificat ion com m and displays t he queue t o which each CoS
value has been assigned.

I n Exam ple 12- 13 , CoS 0 ( Best - Effort ) is assigned t o Q2 and CoS 1 ( Scavenger) has been
assigned t o Q1. CoS values 2, 3, 4, 6, and 7 have all been assigned t o Q3; CoS 5 ( Voice) has
been assigned t o t he priorit y queue, Q4.

Ex a m ple 1 2 - 1 3 . sh ow w r r - qu e u e cos- m a p Verificat ion for a Cat alyst 2950

Swit ch
CAT2950#show wrr-queue cos-map
CoS Value : 0 1 2 3 4 5 6 7
Priority Queue : 2 1 3 3 3 4 3 3
CAT2950#
Catalyst 3550 QoS Considerations and Design
The Cat alyst 3550 support s I P rout ing and, t hus, can be found in eit her t he access or dist ribut ion
layer of t he cam pus.

As for QoS, t he Cat alyst 3550 support s a richer feat ure set t han t he Cat alyst 2950, including an
advanced policing feat ure t hat is ideal for out - of- profile policing, nam ely per- port / per- VLAN
policing. The access- layer design opt ions and dist ribut ion- layer design recom m endat ions for a
Cat alyst 3550 are shown in Figures 12- 13 and 12- 14 , respect ively.

Figu r e 1 2 - 1 3 . Acce ss- La ye r Ca t a lyst 3 5 5 0 QoS D e sign

[View full size image]

Figu r e 1 2 - 1 4 . D ist r ibu t ion - La ye r Ca t a lyst 3 5 5 0 QoS D e sign

An im port ant point t o rem em ber about t he Cat alyst 3550 is t hat QoS is disabled by default and
m ust be enabled globally for configured policies t o becom e effect ive. While QoS is disabled, all
fram es and packet s are passed t hrough t he swit ch unalt ered ( which is equivalent t o a t rust CoS
and t rust DSCP st at e on all port s) . When QoS is enabled globally, however, all DSCP and CoS
values ( by default ) are set t o 0 ( which is equivalent t o an unt rust ed st at e on all port s) . Exam ple
12- 14 shows how t o verify whet her QoS has been enabled not and also how it can be enabled
globally.

Ex a m ple 1 2 - 1 4 . En a blin g QoS Globa lly on t h e Ca t a lyst 3 5 5 0

CAT3550#show mls qos

QoS is disabled ! By default QoS is disabled
CAT3550#
CAT3550#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
CAT3550(config)#mls qos ! Enables QoS globally for the Cat3550
CAT3550(config)#exit
CAT3550#

CAT3550#show mls qos

QoS is enabled ! Verifies that QoS is enabled globally
CAT3550#

N ot e
Depending on t he soft ware version, enabling QoS in t he Cat alyst 3550 m ight require
I EEE 802.3 x flow cont rol t o be disabled on all int erfaces ( if it is enabled) . Flow cont rol
can be disabled on an int erface or int erface range by using t he int erface configurat ion
com m ands flow con t r ol r e ce ive off and flow con t r ol se n d off . Check t he Cat alyst
3550 I OS docum ent at ion ( QoS chapt er) t o verify whet her t his is a requirem ent for t he
version of soft ware in use.

Catalyst 3550: Trusted Endpoint Model

Configuring a Cat alyst 3550 swit ch port t o t rust an endpoint is ident ical t o configuring a Cat alyst
2950 ( provided t hat QoS has been enabled globally on t he Cat alyst 3550) . I t is shown in
Exam ple 12- 15 .

Ex a m ple 1 2 - 1 5 . Ca t a lyst 3 5 5 0 : Tr u st e d En dpoin t Ex a m ple

CAT3550(config)#interface FastEthernet0/1
CAT3550(config-if)#mls qos trust dscp

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos
 sh ow m ls qos in t e r fa ce

Catalyst 3550: Untrusted PC with SoftPhone Model

Unlike t he Cat alyst 2950, t he Cat alyst 3550 has all t he necessary QoS feat ures t o support and
enforce t he Unt rust ed PC wit h Soft Phone m odel, as illust rat ed in Figure 12- 4 . Exam ple 12- 16
shows t he Cat alyst 3550 configurat ion for t his access edge m odel.

Ex a m ple 1 2 - 1 6 . Ca t a lyst 3 5 5 0 : Un t r u st e d PC w it h Soft Ph on e Ex a m ple

CAT3550(config)#mls qos map policed-dscp 0 24 46 to 8

! Excess traffic marked 0 or CS3 or EF will be remarked to CS1
CAT3550(config)#
CAT3550(config)#class-map match-all SOFTPHONE-VOICE
CAT3550(config-cmap)# match access-group name SOFTPHONE-VOICE
CAT3550(config-cmap)#class-map match-all SOFTPHONE-SIGNALING
CAT3550(config-cmap)# match access-group name SOFTPHONE-SIGNALING
CAT3550(config-cmap)#exit
CAT3550(config)#
CAT3550(config)#policy-map SOFTPHONE-PC
CAT3550(config-pmap)#class SOFTPHONE-VOICE
CAT3550(config-pmap-c)# set ip dscp 46 ! Softphone VoIP is marked to DSCP EF
CAT3550(config-pmap-c)# police 128000 8000 exceed-action policed-dscp-transmit
! Out-of-profile SoftPhone voice traffic is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)#class SOFTPHONE-SIGNALING
CAT3550(config-pmap-c)# set ip dscp 24 ! Signaling is marked to DSCP CS3
CAT3550(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Signaling traffic is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)#class class-default
CAT3550(config-pmap-c)# set ip dscp 0
CAT3550(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile data traffic is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)# exit
CAT3550(config-pmap)#exit
CAT3550(config)#
CAT3550(config)#interface FastEthernet0/1
CAT3550(config-if)# service-policy input SOFTPHONE-PC ! Applies policy to int
CAT3550(config-if)#exit
CAT3550(config)#
CAT3550(config)#ip access-list extended SOFTPHONE-VOICE
CAT3550(config-ext-nacl)# permit udp any any range 16384 32767 ! VoIP ports
CAT3550(config-ext-nacl)#
CAT3550(config-ext-nacl)#ip access-list extended SOFTPHONE-SIGNALING
CAT3550(config-ext-nacl)# permit tcp any any range 2000 2002 ! SCCP ports
CAT3550(config-ext-nacl)#end
CAT3550#

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos
 sh ow m ls qos m a p

sh ow m ls qos in t e r fa ce

sh ow m ls qos in t e r fa ce police r s

sh ow m ls qos st a t ist ics

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce

Catalyst MLS QoS Verification Command: show mls qos interface statistics

The sh ow m ls qos in t e r fa ce st a t ist ics verificat ion com m and report s dynam ic count ers for a
given policy, including how m any packet s were classified and policed by t he policy.

I n Exam ple 12- 17 , unt rust ed packet s from t he PC are classified and policed according t o t he
lim it s shown in Figure 12- 4 for t he Unt rust ed PC wit h Soft Phone access- edge endpoint policing
m odel.

Ex a m ple 1 2 - 1 7 . sh ow m ls qos in t e r fa ce st a t ist ics Verificat ion of a

Cat alyst 3550 Swit ch Port Connect ed t o an Unt rust ed PC wit h Soft Phone

CAT3550#show mls qos interface FastEthernet0/1 statistics

FastEthernet0/1
Ingress
dscp: incoming no_change classified policed dropped (in bytes)
Others: 1275410698 31426318 1243984380 1674978822 0
Egress
dscp: incoming no_change classified policed dropped (in bytes)
Others: 7271494 n/a n/a 0 0
CAT3550#

Catalyst MLS QoS Verification Command: show policy interface

The sh ow policy in t e r fa ce verificat ion com m and displays t he policy m aps ( and relat ed classes)
t hat are at t ached t o a given int erface.

I n Exam ple 12- 18 , a sum m ary of t he unt rust ed PC wit h Soft Phone policing policy is shown as
applied t o Fast Et hernet 0/ 1.

Ex a m ple 1 2 - 1 8 . sh ow policy in t e r fa ce Verificat ion of a Cat alyst 3550

Swit ch Port Connect ed t o an Unt rust ed PC wit h Soft Phone

CAT3550#show policy interface FastEthernet0/1

FastEthernet0/1
service-policy input: SOFTPHONE-PC
 class-map: SOFTPHONE-VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
match: access-group name SOFTPHONE-VOICEqm_police_inform_feature:
CLASS_SHOW
class-map: SOFTPHONE-SIGNALING (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
match: access-group name SOFTPHONE-SIGNALINGqm_police_inform_feature:
CLASS_SHOW
class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
match: any
0 packets, 0 bytes
5 minute rate 0 bpsqm_police_inform_feature: CLASS_SHOW
CAT3550#

N ot e
At t he t im e of t his writ ing, t he count ers report ed by t he sh ow policy in t e r fa ce
com m and on t he Cat alyst 3550 are not being increm ent ed, as is t he case wit h t he
m ainline Cisco I OS version of t his com m and. This has been report ed as a bug. I n ot her
words, all count ers current ly are frozen at zero; however, when t his bug is fixed, t hey
should increm ent dynam ically. Cat alyst 3550 I OS versions t est ed and affect ed wit h t his
bug include 12.1( 19) EA1 a t hrough c and 12.1( 20) EA1.

Catalyst 3550: Untrusted Server Model

The Cat alyst 3550 fully support s t he Unt rust ed Mult iapplicat ion Server m odel, depict ed in Figure
12- 5 . Exam ple 12- 19 shows t he configurat ion for t his m odel.

Ex a m ple 1 2 - 1 9 . Ca t a lyst 3 5 5 0 : Un t r u st e d M u lt ia pplica t ion Se r ve r

Ex a m ple

CAT3550(config)#mls qos map policed-dscp 0 10 18 25 to 8

! Excess traffic marked 0 or AF11 or AF21 or DSCP 25 will be remarked to CS1
CAT3550(config)#
CAT3550(config)#class-map SAP
CAT3550(config-cmap)# match access-group name SAP
CAT3550(config-cmap)#class-map LOTUS
CAT3550(config-cmap)# match access-group name LOTUS
CAT3550(config-cmap)#class-map IMAP
CAT3550(config-cmap)# match access-group name IMAP
CAT3550(config-cmap)#exit
CAT3550(config)#
CAT3550(config)#policy-map UNTRUSTED-SERVER
CAT3550(config-pmap)#class SAP
CAT3550(config-pmap-c)# set ip dscp 25 ! SAP is marked as Mission-Critical
CAT3550(config-pmap-c)# police 15000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile SAP is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)#class LOTUS
CAT3550(config-pmap-c)# set ip dscp 18 ! Lotus is marked as Transactional
CAT3550(config-pmap-c)# police 35000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile LOTUS is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)#class IMAP
CAT3550(config-pmap-c)# set ip dscp 10 ! IMAP is marked as Bulk Data
CAT3550(config-pmap-c)# police 50000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile IMAP is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)#class class-default
CAT3550(config-pmap-c)# set ip dscp 0
CAT3550(config-pmap-c)# police 1000000 8000 exceed-action policed-dscp-transmit
! Excess data traffic is marked to Scavenger (CS1)
CAT3550(config-pmap-c)# exit
CAT3550(config-pmap)#exit
CAT3550(config)#
CAT3550(config)#interface FastEthernet0/1
CAT3550(config-if)# service-policy input UNTRUSTED-SERVER
CAT3550(config-if)#exit
CAT3550(config)#
CAT3550(config)#ip access-list extended SAP
CAT3550(config-ext-nacl)# permit tcp any range 3200 3203 any
CAT3550(config-ext-nacl)# permit tcp any eq 3600 any
CAT3550(config-ext-nacl)#
CAT3550(config-ext-nacl)#ip access-list extended LOTUS
CAT3550(config-ext-nacl)#permit tcp any eq 1352 any
CAT3550(config-ext-nacl)#
CAT3550(config-ext-nacl)#ip access-list extended IMAP
CAT3550(config-ext-nacl)#permit tcp any eq 143 any
CAT3550(config-ext-nacl)#permit tcp any eq 220 any
CAT3550(config-ext-nacl)#end
CAT3550#

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos

sh ow m ls qos m a p

sh ow m ls qos in t e r fa ce

sh ow m ls qos in t e r fa ce police r s

sh ow m ls qos st a t ist ics

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce
Catalyst 3550: Conditionally Trusted IP Phone + PC: Basic Model
The Cat alyst 3550's support of per- port and per- VLAN policing gives it a dist inct advant age over
ot her plat form s when provisioning a ( basic or advanced) Condit ionally Trust ed Endpoint m odel.
This is because per- port / per- VLAN policies can be provisioned wit hout having t o ent er subnet -
specific inform at ion for each swit ch. This m akes such policies m ore m odular and port able.

I n Exam ple 12- 20 , VLAN 10 is t he DVLAN and VLAN 110 is t he VVLAN.

Ex a m ple 1 2 - 2 0 . Ca t a lyst 3 5 5 0 : Con dit ion a lly Tr u st e d I P Ph on e + PC:

Ba sic M ode l Ex a m ple

CAT3550(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56

! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF
CAT3550(config)#mls qos map policed-dscp 0 24 to 8
! Excess DVLAN & VVLAN traffic will be remarked to Scavenger (CS1)
CAT3550(config)#
CAT3550(config)#
CAT3550(config)#class-map match-all VOICE
CAT3550(config-cmap)# match ip dscp 46 ! DSCP EF (voice)
CAT3550(config-cmap)#class-map match-any CALL-SIGNALING ! Need 'match-any' here
CAT3550(config-cmap)# match ip dscp 26 ! DSCP AF31 (old Call-Signaling)
CAT3550(config-cmap)# match ip dscp 24 ! DSCP CS3 (new Call-Signaling)
CAT3550(config-cmap)#
CAT3550(config-cmap)#class-map match-all VVLAN-VOICE
CAT3550(config-cmap)# match vlan 110 ! VLAN 110 is VVLAN
CAT3550(config-cmap)# match class-map VOICE ! Matches VVLAN DSCP EF
CAT3550(config-cmap)#
CAT3550(config-cmap)#class-map match-all VVLAN-CALL-SIGNALING
CAT3550(config-cmap)# match vlan 110 ! VLAN 110 is VVLAN
CAT3550(config-cmap)# match class-map CALL-SIGNALING !Matches VVLAN AF31/CS3
CAT3550(config-cmap)#
CAT3550(config-cmap)#class-map match-all ANY
CAT3550(config-cmap)# match access-group name ANY ! Workaround ACL
CAT3550(config-cmap)#
CAT3550(config-cmap)#class-map match-all VVLAN-ANY
CAT3550(config-cmap)# match vlan 110 ! VLAN 110 is VVLAN
CAT3550(config-cmap)# match class-map ANY ! Matches any other VVLAN traffic
CAT3550(config-cmap)#
CAT3550(config-cmap)#class-map match-all DVLAN-ANY
CAT3550(config-cmap)# match vlan 10 ! VLAN 10 is DVLAN
CAT3550(config-cmap)# match class-map ANY ! Matches all DVLAN traffic
CAT3550(config-cmap)#
CAT3550(config-cmap)#policy-map IPPHONE+PC-BASIC
CAT3550(config-pmap)#class VVLAN-VOICE
CAT3550(config-pmap-c)# set ip dscp 46 ! DSCP EF (Voice)
CAT3550(config-pmap-c)# police 128000 8000 exceed-action drop
! Only one voice call is permitted per switchport VVLAN
CAT3550(config-pmap-c)#class VVLAN-CALL-SIGNALING
CAT3550(config-pmap-c)# set ip dscp 24 ! DSCP CS3 (Call-Signaling)
CAT3550(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Call-Signaling is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)#class VVLAN-ANY
CAT3550(config-pmap-c)# set ip dscp 0
CAT3550(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
! Unauthorized VVLAN traffic is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)#class DVLAN-ANY
CAT3550(config-pmap-c)# set ip dscp 0
CAT3550(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile data traffic is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)# exit
CAT3550(config-pmap)#exit
CAT3550(config)#
CAT3550(config)#interface FastEthernet0/1
CAT3550(config-if)# switchport access vlan 10 ! DVLAN
CAT3550(config-if)# switchport voice vlan 110 ! VVLAN
CAT3550(config-if)# mls qos trust device cisco-phone ! Conditional Trust
CAT3550(config-if)# service-policy input IPPHONE+PC-BASIC ! Attaches policy
CAT3550(config-if)#exit
CAT3550(config)#
CAT3550(config)#
CAT3550(config)#ip access-list standard ANY ! Workaround ACL
CAT3550(config-std-nacl)# permit any
CAT3550(config-std-nacl)#end
CAT3550#

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos

sh ow m ls qos m a p

sh ow m ls qos in t e r fa ce

sh ow m ls qos in t e r fa ce police r s

sh ow m ls qos st a t ist ics

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce

N ot e
Alt hough Cat alyst 3550 I OS synt ax support s t he m a t ch a n y crit eria wit hin a class m ap
( which t he parser allows t o be configured in conj unct ion wit h a per- VLAN policy) ,
t est ing wit h t he Cat alyst 3500 I OS versions list ed previously has shown t hat t here is a
bug wit h t his funct ion because it does not m at ch any ot her t raffic on a per- VLAN basis.
Therefore, an explicit access list nam ed ANY has been used in Exam ple 12- 20 as a
workaround t o t his issue. Once t his issue has been resolved, it is sim pler t o use t he
m a t ch - a n y keyword wit hin t he class- m aps ( rat her t han t he workaround ACL) .
Catalyst 3550: Conditionally Trusted IP Phone + PC: Advanced Model
The Condit ionally Trust ed I P Phone + PC: Advanced m odel builds on t he basic m odel by
including policers for PC- based videoconferencing ( and PC Soft Phone) , Mission- Crit ical,
Transact ional, and Bulk Dat a applicat ions. This m odel is depict ed in Figure 12- 9 . The Cat alyst
3550 can support eight policers per 10/ 100 Et hernet port and can support t his advanced m odel.

Exam ple 12- 21 shows t he Cat alyst 3550 configurat ion for t he Condit ionally Trust ed I P Phone +
PC: Advanced m odel. I n t his exam ple, t he sam e server- t o- client applicat ions are used as in t he
unt rust ed m ult iapplicat ion server exam ple. However, not ice t hat t he source and dest inat ion
port s are reversed for t he client - t o- server direct ion of t raffic flow. Also, because of t he lim it of
t he num ber of policers per Fast Et hernet port ( eight ) , t here is no explicit policer for Soft Phone
Call- Signaling t raffic; t o work around t his lim it at ion, Soft Phone Call- Signaling t raffic is included
in t he Mission- Crit ical Dat a applicat ions access list .

Ex a m ple 1 2 - 2 1 . Ca t a lyst 3 5 5 0 : Con dit ion a lly Tr u st e d I P Ph on e + PC:

Adva n ce d M ode l Ex a m ple

CAT3550(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56

! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF
CAT3550(config)#mls qos map policed-dscp 0 10 18 24 25 34 to 8
! Excess DVLAN traffic marked 0, AF11, AF21, CS3, DSCP 25,
! and AF41 will be remarked to Scavenger (CS1)
CAT3550(config)#
CAT3550(config)#class-map match-all VOICE
CAT3550(config-cmap)# match ip dscp 46 ! DSCP EF (voice)
CAT3550(config-cmap)#class-map match-any CALL-SIGNALING ! Need 'match-any' here
CAT3550(config-cmap)# match ip dscp 26 ! DSCP AF31 (old Call-Signaling)
CAT3550(config-cmap)# match ip dscp 24 ! DSCP CS3 (new Call-Signaling)
CAT3550(config-cmap)#class-map match-all PC-VIDEO
CAT3550(config-cmap)# match access-group name PC-VIDEO
CAT3550(config-cmap)#class-map match-all MISSION-CRITICAL-DATA
CAT3550(config-cmap)# match access-group name MISSION-CRITICAL-DATA
CAT3550(config-cmap)#class-map match-all TRANSACTIONAL-DATA
CAT3550(config-cmap)# match access-group name TRANSACTIONAL-DATA
CAT3550(config-cmap)#class-map match-all BULK-DATA
CAT3550(config-cmap)# match access-group name BULK-DATA
CAT3550(config-cmap)#class-map match-all ANY
CAT3550(config-cmap)# match access-group name ANY ! Workaround ACL
CAT3550(config-cmap)#
CAT3550(config-cmap)#class-map match-all VVLAN-VOICE
CAT3550(config-cmap)# match vlan 110 ! VLAN 110 is VVLAN
CAT3550(config-cmap)# match class-map VOICE ! Matches VVLAN DSCP EF
CAT3550(config-cmap)#class-map match-all VVLAN-CALL-SIGNALING
CAT3550(config-cmap)# match vlan 110 ! VLAN 110 is VVLAN
CAT3550(config-cmap)# match class-map CALL-SIGNALING ! Matches VVLAN AF31/CS3
CAT3550(config-cmap)#class-map match-all VVLAN-ANY
CAT3550(config-cmap)# match vlan 110 ! VLAN 110 is VVLAN
CAT3550(config-cmap)# match class-map ANY ! Matches any other VVLAN traffic
CAT3550(config-cmap)#
CAT3550(config-cmap)#
CAT3550(config-cmap)#class-map match-all DVLAN-PC-VIDEO
CAT3550(config-cmap)# match vlan 10 ! VLAN 10 is DVLAN
CAT3550(config-cmap)# match class-map PC-VIDEO ! Matches PC-Video class-map
CAT3550(config-cmap)#
CAT3550(config-cmap)#class-map match-all DVLAN-MISSION-CRITICAL-DATA
CAT3550(config-cmap)# match vlan 10 ! VLAN 10 is DVLAN
CAT3550(config-cmap)# ! Matches MCD class-map
CAT3550(config-cmap)#
CAT3550(config-cmap)#class-map match-all DVLAN-TRANSACTIONAL-DATA
CAT3550(config-cmap)# match vlan 10 ! VLAN 10 is DVLAN
CAT3550(config-cmap)# match class-map TRANSACTIONAL-DATA ! Matches TD class-map
CAT3550(config-cmap)#
CAT3550(config-cmap)#class-map match-all DVLAN-BULK-DATA
CAT3550(config-cmap)# match vlan 10 ! VLAN 10 is DVLAN
CAT3550(config-cmap)# ! Matches Bulk Data class-map
CAT3550(config-cmap)#
CAT3550(config-cmap)#class-map match-all DVLAN-ANY
CAT3550(config-cmap)# match vlan 10 ! VLAN 10 is DVLAN
CAT3550(config-cmap)# match class-map ANY ! Matches all other DVLAN traffic
CAT3550(config-cmap)#
CAT3550(config-cmap)#
CAT3550(config-cmap)#policy-map IPPHONE+PC-ADVANCED
CAT3550(config-pmap)# class VVLAN-VOICE
CAT3550(config-pmap-c)# set ip dscp 46 ! DSCP EF (Voice)
CAT3550(config-pmap-c)# police 128000 8000 exceed-action drop
! Only one voice call is permitted per switchport VVLAN
CAT3550(config-pmap-c)#class VVLAN-CALL-SIGNALING
CAT3550(config-pmap-c)# set ip dscp 24 ! DSCP CS3 (Call-Signaling)
CAT3550(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Call-Signaling is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)#class VVLAN-ANY
CAT3550(config-pmap-c)# set ip dscp 0
CAT3550(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
! Unauthorized VVLAN traffic is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)#class DVLAN-PC-VIDEO
CAT3550(config-pmap-c)# set ip dscp 34 ! DSCP AF41 (Interactive-Video)
CAT3550(config-pmap-c)# police 500000 8000 exceed-action policed-dscp-transmit
! Only one IP/VC stream will be permitted per switchport
CAT3550(config-pmap-c)#class DVLAN-MISSION-CRITICAL-DATA
CAT3550(config-pmap-c)# set ip dscp 25 ! Interim Mission-Critical Data
CAT3550(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Mission-Critical Data is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)#class DVLAN-TRANSACTIONAL-DATA
CAT3550(config-pmap-c)# set ip dscp 18 ! DSCP AF21 (Transactional Data)
CAT3550(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Transactional Data is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)#class DVLAN-BULK-DATA
CAT3550(config-pmap-c)# set ip dscp 10 ! DSCP AF11 (Bulk Data)
CAT3550(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Bulk Data is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)#class DVLAN-ANY
CAT3550(config-pmap-c)# set ip dscp 0
CAT3550(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile data traffic is marked down to Scavenger (CS1)
CAT3550(config-pmap-c)# exit
CAT3550(config-pmap)#exit
CAT3550(config)#
CAT3550(config)#interface FastEthernet0/1
CAT3550(config-if)# switchport access vlan 10 ! DVLAN
CAT3550(config-if)# switchport voice vlan 110 ! VVLAN
CAT3550(config-if)# mls qos trust device cisco-phone ! Conditional Trust
CAT3550(config-if)# service-policy input IPPHONE+PC-ADVANCED! Attaches policy
CAT3550(config-if)#exit
CAT3550(config)#
CAT3550(config)#ip access-list standard ANY ! Workaround ACL
CAT3550(config-std-nacl)# permit any
CAT3550(config-std-nacl)#
CAT3550(config-std-nacl)#ip access-list extended PC-VIDEO ! IP/VC or SoftPhone
CAT3550(config-ext-nacl)# permit udp any any range 16384 32767
CAT3550(config-ext-nacl)#
CAT3550(config-ext-nacl)#ip access-list extended MISSION-CRITICAL-DATA
CAT3550(config-ext-nacl)# permit tcp any any range 3200 3203 ! SAP
CAT3550(config-ext-nacl)# permit tcp any any eq 3600 ! SAP
CAT3550(config-ext-nacl)# permit tcp any any range 2000 2002 ! SoftPhone SCCP
CAT3550(config-ext-nacl)#
CAT3550(config-ext-nacl)#ip access-list extended TRANSACTIONAL-DATA
CAT3550(config-ext-nacl)# permit tcp any any eq 1352 ! Lotus
CAT3550(config-ext-nacl)#
CAT3550(config-ext-nacl)#ip access-list extended BULK-DATA
CAT3550(config-ext-nacl)# permit tcp any any eq 143 ! IMAP
CAT3550(config-ext-nacl)# permit tcp any any eq 220 ! IMAP
CAT3550(config-ext-nacl)#end
CAT3550#

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos

sh ow m ls qos m a p

sh ow m ls qos in t e r fa ce

sh ow m ls qos in t e r fa ce police r s

sh ow m ls qos st a t ist ics

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce

Catalyst 3550: Queuing and Dropping

Like t he Cat alyst 2950, t he Cat alyst 3550 support s a 1P3Q1T queuing m odel for all port s.
Gigabit Et hernet port s have t he addit ional opt ion of being configured as 1P3Q2T, wit h eit her t ail-
drop or WRED t hresholds. However, unlike t he Cat alyst 2950, t he Cat alyst 3550 queuing
param et ers are set on a per- int erface basis, not globally. Nonet heless, uniform queuing policies
can be deployed expedit iously using t he in t e r fa ce r a n ge configurat ion com m and.

The st rict - priorit y queue is enabled on a per- int erface basis on t he Cat alyst 3550 wit h t he
pr ior it y- qu e u e ou t int erface com m and. Bandwidt h is allocat ed am ong t he rem aining queues
using t he w r r - qu e u e ba n dw idt h com m and. A t wist wit h t he Cat alyst 3550 is t hat queue 4's
WRR weight is set t o 1 ( indicat ing t hat it does not part icipat e in t he WRR scheduler because it is
configured as a st rict - priorit y queue) inst ead of 0 ( as is t he case on t he Cat alyst 2950) .
Recom m ended rem aining bandwidt h allocat ions ( aft er t he PQ has been serviced fully) are 5
percent for t he Scavenger queue ( Q1) , 25 percent for t he Best - Effort queue ( Q2) , and 70
percent for t he preferent ial applicat ion queue ( Q3) .

Following t his, CoS 1 ( Scavenger/ Bulk Dat a) would be assigned t o Q1; CoS 0 ( Best - Effort ) would
be assigned t o Q2; CoS values 2 ( Transact ional Dat a and Net work- Managem ent ) , 3 ( Call-
Signaling and Mission- Crit ical Dat a) , 4 ( I nt eract ive- and St ream ing- Video) , 6 ( I nt ernet work
Cont rol) , and 7 ( Net work Cont rol/ Spanning- Tree) would be assigned t o Q3; and CoS 5 ( voice)
would be assigned t o t he st rict - priorit y Q4. These assignm ent s and allocat ions are illust rat ed in
Figure 12- 15 ( t he t hresholds shown in Q1 and Q3 are discussed short ly) .

Figu r e 1 2 - 1 5 . Ca t a lyst 3 5 5 0 1 P3 Q2 T Qu e u in g M ode l

[View full size image]

Exam ple 12- 22 shows t he int erface- m ode configurat ion com m ands t o configure t his 1P3Q1T
queuing m odel, for eit her Fast Et hernet or Gigabit Et hernet Cat alyst 3550 int erfaces.

Ex a m ple 1 2 - 2 2 . Ca t a lyst 3 5 5 0 Fa st Et h e r n e t a n d Giga bit Et h e r n e t

I n t e r fa ce Qu e u in g Con figu r a t ion : 1 P3 Q1 T Ex a m ple

CAT3550(config)#interface range FastEthernet0/1 - 48

CAT3550(config-if)# wrr-queue bandwidth 5 25 70 1 ! Q1-5% Q2-25% Q3-70% Q4=PQ
CAT3550(config-if)# wrr-queue cos-map 1 1 ! Assigns Scavenger to Q1
CAT3550(config-if)# wrr-queue cos-map 2 0 ! Assigns Best Effort to Q2
CAT3550(config-if)# wrr-queue cos-map 3 2 3 4 6 7 ! Assigns CoS 2,3,4,6,7 to Q3
CAT3550(config-if)# wrr-queue cos-map 4 5 ! Assigns VoIP to Q4 (PQ)
CAT3550(config-if)# priority-queue out ! Enables Q4 as PQ
CAT3550(config-if)#end
CAT3550#

Cat alyst MLS QoS verificat ion com m and:

sh ow m ls qos in t e r fa ce qu e u e in g

The Cat alyst 3550 offers som e advanced " nerd- knob" queuing opt ions on 10/ 100 int erfaces,
such as t uning m inim um reserve t hresholds. However, t est ing has shown t hat such t uning
m akes a highly negligible difference, at best . Therefore, t uning m inim um reserve t hresholds is
recom m ended only for advanced net work adm inist rat ors or when using aut om at ed t ools, such as
Aut oQoS.

Som e advanced nerd knobs also exist for Gigabit Et hernet int erfaces. A couple of t hese
advanced t uning opt ions include queue- lim it t uning and t he enabling of WRED t hresholds for
1P3Q2T operat ion. I n t he event of DoS or worm at t acks, t he Gigabit Et hernet uplinks m ay
becom e congest ed, so it is wort hwhile t o exam ine t hese advanced opt ions.

I n Exam ple 12- 23 , t he queue lim it s for bot h Gigabit Et hernet int erfaces are t uned t o correspond
t o t he WRR weight s of t he queues ( t he bandwidt h allocat ions) . This is achieved wit h t he w r r -
qu e u e qu e u e - lim it int erface com m and. However, unlike t he WRR weight bandwidt h rat io for
Q4 ( which is set t o 1 t o indicat e t hat Q4 is a PQ) , t he queue lim it for Q4 needs t o be set
explicit ly t o a m ore represent at ive value, such as 30 percent .

N ot e
The default queue lim it s are such t hat each queue is assigned 25 percent of t he
available buffer space. I t should be not ed t hat when t he queue lim it s are m odified, t he
queue t em porarily is shut down during t he hardware reconfigurat ion, and t he swit ch
m ight drop newly arrived packet s dest ined t o t he queue. Thus, it is advisable not t o
t une t he queue lim it s on Cat alyst 3550 swit ches already in product ion net works unless
downt im e has been scheduled.

Addit ionally, WRED is enabled on each ( nonpriorit y) queue. This allows for t he preferent ial
t reat m ent of Bulk Dat a ( DSCP AF11) over Scavenger ( CS1) wit hin Q1, as well as t he pr efer ent ial
t reat m ent of int ernet working or net working prot ocols ( DSCP CS6 and CS7, respect ively) over all
ot her applicat ions assigned t o Q3. Even t hough Q2 has only Best - Effort t raffic assigned t o it ,
enabling WRED on t his queue increases t he efficiency of TCP applicat ions wit hin t his queue
during periods of congest ion.

A low WRED t hreshold, such as 40 percent , can be set for Q1 t o aggressively drop Scavenger
t raffic t o preferent ially service Bulk Dat a. The WRED t hresholds for Q2 and Q3 can be set t o
higher levels, such as 80 percent .

By default , all DSCP values are m apped t o t he first WRED t hreshold of whichever queue t heir
CoS values are assigned t o. Therefore, only DSCP values t hat are t o be m apped t o t he second
WRED t hresholds ( of t heir respect ive queues) need t o be configured m anually. I n t his case, Bulk
Dat a ( DSCP AF11/ 10) , I nt ernet work Cont rol ( DSCP CS6/ 48) , and Net work Cont rol ( DSCP
CS7/ 56) all need t o be m apped explicit ly t o t he second WRED t hreshold using t he w r r - qu e u e
dscp- m a p int erface configurat ion com m and.
 N ot e
Net work Cont rol t raffic in t he cam pus prim arily refers t o Spanning Tree Prot ocol ( STP)
t raffic, such as bridge prot ocol dat a unit s ( BPDUs) . Alt hough t hese Layer 2 Et hernet
fram es are m arked CoS 7, t hey ( obviously) do not have any capabilit ies t o carry Layer
3 DSCP m arkings. Thus, it m ight seem m oot t o m ap DSCP CS7 ( 56) t o a higher WRED
t hreshold. However, it should be kept in m ind t hat Cat alyst swit ches generat e int ernal
DSCP values for all fram es ( regardless of whet her t hey are carrying I P) . These int ernal
DSCP values are used for QoS decisions, such as WRED, in t his case. Therefore,
because STP BPDU fram es ( m arked CoS 7) generat e an int ernal DSCP value of 56,
m apping DSCP 56 t o t he second t hreshold of Q3 provides preferent ial t reat m ent for
t hese im port ant Layer 2 fram es.

Exam ple 12- 23 shows t he configurat ion for t hese t uning opt ions, which are available only on
Gigabit Et hernet int erfaces on t he Cat alyst 3550.

Ex a m ple 1 2 - 2 3 . Ca t a lyst 3 5 5 0 Giga bit Et h e r n e t I n t e r fa ce Qu e u in g a n d

D r oppin g Con figu r a t ion : 1 P3 Q2 T Ex a m ple

CAT3550(config)#interface range GigabitEthernet 0/1 2

CAT3550(config-if-range)# wrr-queue bandwidth 5 25 70 1
! Q1 gets 5% BW, Q2 gets 25% BW, Q3 gets 70% BW, Q4 is the PQ
CAT3550(config-if-range)# wrr-queue queue-limit 5 25 40 30
! Tunes buffers to 5% for Q1, 25% for Q2, 40% for Q3 and 30% for Q4
CAT3550(config-if-range)# wrr-queue random-detect max-threshold 1 40 100
! Sets Q1 WRED threshold 1 to 40% and threshold 2 to 100%
CAT3550(config-if-range)# wrr-queue random-detect max-threshold 2 80 100
! Sets Q2 WRED threshold 1 to 80% and threshold 2 to 100%
CAT3550(config-if-range)# wrr-queue random-detect max-threshold 3 80 100
! Sets Q3 WRED threshold 1 to 80% and threshold 2 to 100%
CAT3550(config-if-range)# wrr-queue cos-map 1 1 ! Assigns Scavenger to Q1
CAT3550(config-if-range)# wrr-queue cos-map 2 0 ! Assigns Best Effort to Q2
CAT3550(config-if-range)# wrr-queue cos-map 3 2 3 4 6 7
! Assigns CoS 2,3,4,6,7 to Q3
CAT3550(config-if-range)# wrr-queue cos-map 4 5 ! Assigns VoIP to Q4 (PQ)
CAT3550(config-if-range)# wrr-queue dscp-map 2 10 48 56
! Maps Bulk Data (10), Routing (48) and Spanning Tree (Internal DSCP 56)
! to WRED threshold 2 of their respective queues all other DSCP values
! are mapped (by default) to WRED threshold 1 of their respective queues
CAT3550(config-if-range)# priority-queue out ! Enables Q4 as PQ
CAT3550(config-if-range)#end
CAT3550#

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos in t e r fa ce qu e u e in g

sh ow m ls qos in t e r fa ce bu ffe r s
Catalyst MLS QoS Verification Command: show mls qos interface buffers

The sh ow m ls qos in t e r fa ce bu ffe r s verificat ion com m and displays t he queue sizes ( as per-
queue buffer allocat ion percent ages of t he t ot al buffer space) . Also, t he com m and displays
whet her WRED has been enabled on a queue and, if so, displays t he first and second t hresholds
( as percent ages of t he queue's dept h) .

I n Exam ple 12- 24 , t he queue lim it s are set t o 5 percent , 25 percent , 40 percent , and 30
percent of t he t ot al queuing buffer space for queues 1 t hrough 4 ( respect ively) . Addit ionally,
WRED is enabled on queues 1 t hrough 3 ( but not Q4 because it is t he priorit y queue) . The first
WRED t hreshold is set t o 5 percent on Q1 and is set t o 80 percent on queues 2 and 3.

Ex a m ple 1 2 - 2 4 . sh ow m ls qos in t e r fa ce bu ffe r s Verificat ion for a Cat alyst

3550 Swit ch

CAT3550#show mls qos interface GigabitEthernet0/1 buffers

GigabitEthernet0/1
Notify Q depth:
qid-size
1 5 ! Q1 queue-limit is set to 5% of total buffer space
2 25 ! Q2 queue-limit is set to 25% of total buffer space
3 40 ! Q3 queue-limit is set to 40% of total buffer space
4 30 ! Q4 queue-limit is set to 30% of total buffer space
qid WRED thresh1 thresh2
1 ena 40 100 ! WRED is enabled on Q1 first threshold is set to 40%
2 ena 80 100 ! WRED is enabled on Q2 first threshold is set to 80%
3 ena 80 100 ! WRED is enabled on Q3 first threshold is set to 80%
4 dis 100 100 ! WRED is disabled on Q4 (as it is the PQ)
CAT3550#

Catalyst MLS QoS Verification Command: show mls qos interface queueing

The sh ow m ls qos in t e r fa ce qu e u e in g verificat ion com m and displays t he CoS- t o- queuing

m appings t hat have been configured, in addit ion t o t he bandwidt h allocat ions per queue. On
Gigabit Et hernet int erfaces wit h WRED enabled, t he out put also includes t he DSCP- t o- WRED
t hreshold m appings. This inform at ion is displayed in a t able form , wit h t he first digit of t he
decim al DSCP value along t he y- axis ( in rows) and t he second digit of t he decim al DSCP value
along t he x- axis ( in colum ns) .

I n Exam ple 12- 25 , t he out put verifies t hat t he egress expedit e queue ( priorit y queue, Q4) is
enabled. Also, t he WRR bandwidt h weight s show t hat , of t he rem aining bandwidt h, Q1 is
allocat ed 5 percent , Q2 is allocat ed 25 percent , and Q3 is allocat ed 70 percent .

Addit ionally, t he DSCP- t o- WRED t able verifies t hat Bulk Dat a ( AF11/ 10) , I nt ernet work Cont rol
( DSCP CS6/ 48) , and Net work Cont rol ( DSCP CS7/ 56) each is m apped t o t he second WRED
t hreshold ( T2) of it s respect ive queue ( as det erm ined by t he CoS- t o- queue m appings) .

Finally, t he CoS- t o- queue m ap shows t hat CoS 0 ( Best - Effort ) is assigned t o Q2; CoS 1
( Scavenger) has been assigned t o Q1; CoS values 2, 3, 4, 6, and 7 have been assigned t o Q3;
and CoS 5 ( Voice) has been assigned t o t he priorit y queue, Q4.
Ex a m ple 1 2 - 2 5 . sh ow m ls qos in t e r fa ce qu e u e in g Verificat ion for a
Cat alyst 3550 Swit ch

CAT3550#show mls qos interface GigabitEthernet0/1 queueing

GigabitEthernet0/1
Egress expedite queue: ena ! Q4 is enabled as a PQ

wrr bandwidth weights:

qid-weights
1 5 ! Q1 is allocated 5%
2 25 ! Q2 is allocated 25%
3 70 ! Q3 is allocated 70&
4 - 1 when expedite queue is disabled

Dscp-threshold map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
----------------------------------------
0 : 01 01 01 01 01 01 01 01 01 01
1 : 02 01 01 01 01 01 01 01 01 01 ! DSCP 10 is mapped to WRED T2
2 : 01 01 01 01 01 01 01 01 01 01
3 : 01 01 01 01 01 01 01 01 01 01
4 : 01 01 01 01 01 01 01 01 02 01 ! DSCP 48 is mapped to WRED T2
5 : 01 01 01 01 01 01 02 01 01 01 ! DSCP 56 is mapped to WRED T2
6 : 01 01 01 01

Cos-queue map:
cos-qid
0 2 ! Best-Effort is assigned to Q2
1 1 ! Scavenger and Bulk are assigned to Q1
2 3 ! Transactional Data and Network Management are assigned to Q3
3 3 ! Mission-Critical Data and Call-Signaling are assigned to Q3
4 3 ! Interactive- and Streaming-Video are assigned to Q3
5 4 ! Voice is assigned to the priority queue: Q4
6 3 ! Internetwork Control (Routing) is assigned to Q3
7 3 ! Network Control (Spanning Tree) is assigned to Q3
CAT3550#
Catalyst 2970/3560/3750 QoS Considerations and
Design
The Cat alyst 2970 does not support Layer 3 rout ing and, as such, is rest rict ed t o t he role of an
access- layer swit ch. The 3560 does support Layer 3 rout ing as well as inline powera feat ure t hat
is rarely, if ever, required at t he dist ribut ion layerand so will only be considered in an access-
layer cont ext . The Cat alyst 3750 also support s Layer 3 rout ing and m ay be found in eit her t he
access layer or t he dist ribut ion layer.

Figure 12- 16 shows t he QoS design opt ions for access- layer Cat alyst 2970s, 3560s, or 3750s,
and Figure 12- 17 shows t he QoS design recom m endat ions for a dist ribut ion- layer Cat alyst 3750.

Figu r e 1 2 - 1 6 . Acce ss- La ye r Ca t a lyst 2 9 5 0 / 3 5 6 0 / 3 7 5 0 QoS D e sign

[View full size image]

Figu r e 1 2 - 1 7 . D ist r ibu t ion - La ye r Ca t a lyst 3 7 5 0 QoS D e sign

Because ( as point ed out in Chapt er 10 , " Cat alyst QoS Tools" ) t he QoS feat ures and
configurat ion synt ax are ident ical for t he Cat alyst 2970, 3560, and 3750, from a QoS design
recom m endat ion perspect ive t hey can be discussed as a single swit ch.

As wit h t he Cat alyst 3550, QoS is disabled globally by default on t he Cat alyst 2970/ 3560/ 3750.
While QoS is disabled, all fram es and packet s are passed t hrough t he swit ch unalt ered ( which is
equivalent t o a t rust CoS and t rust DSCP st at e on all port s) . When QoS is enabled globally,
however, all DSCP and CoS values ( by default ) are set t o 0 ( which is equivalent t o an unt rust ed
st at e on all port s) .

QoS m ust be enabled globally for configured policies t o becom e effect ive. Exam ple 12- 26 shows
how t o verify whet her QoS has been enabled and also how it can be enabled globally.

Ex a m ple 1 2 - 2 6 . En a blin g QoS Globa lly on t h e Ca t a lyst

2970/ 3560/ 3750

CAT2970#show mls qos

QoS is disabled
CAT2970#

CAT2970#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
CAT2970(config)#mls qos
CAT2970(config)#end
CAT2970#

CAT2970#show mls qos

QoS is enabled
CAT2970#

Catalyst 2970/3560/3750: Trusted Endpoint Model

The Trust ed Endpoint m odel configurat ion for t he Cat alyst 2970/ 3560/ 3750 is ident ical t o t he
configurat ion of t he swit ches previously discussed ( nam ely, t he Cat alyst 2950 and 3550) ; it is
shown in Exam ple 12- 27 .

Ex a m ple 1 2 - 2 7 . Ca t a lyst 2 9 7 0 / 3 5 6 0 / 3 7 5 0 : Tr u st e d En dpoin t Ex a m ple

CAT2970(config)#interface GigabitEthernet0/1
CAT2970(config-if)#mls qos trust dscp

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos

sh ow m ls qos in t e r fa ce
Catalyst 2970/3560/3750: Untrusted PC with SoftPhone Model
The Unt rust ed PC wit h Soft Phone m odel configurat ion for t he Cat alyst 2970/ 3560/ 3750 is
ident ical t o t he Cat alyst 3550's for t he sam e access edge m odel and is shown in Exam ple 12- 28 .

Ex a m ple 1 2 - 2 8 . Ca t a lyst 2 9 7 0 / 3 5 6 0 / 3 7 5 0 : Un t r u st e d PC w it h
Soft Ph on e Ex a m ple

CAT2970(config)#mls qos map policed-dscp 0 24 46 to 8

! Excess traffic marked 0 or CS3 or EF will be remarked to CS1
CAT2970(config)#
CAT2970(config)#class-map match-all SOFTPHONE-VOICE
CAT2970(config-cmap)# match access-group name SOFTPHONE-VOICE
CAT2970(config-cmap)#class-map match-all SOFTPHONE-SIGNALING
CAT2970(config-cmap)# match access-group name SOFTPHONE-SIGNALING
CAT2970(config-cmap)#exit
CAT2970(config)#
CAT2970(config)#policy-map SOFTPHONE-PC
CAT2970(config-pmap)#class SOFTPHONE-VOICE
CAT2970(config-pmap-c)# set ip dscp 46 ! Softphone VoIP is marked to DSCP EF
CAT2970(config-pmap-c)# police 128000 8000 exceed-action policed-dscp-transmit
! Out-of-profile SoftPhone voice traffic is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)#class SOFTPHONE-SIGNALING
CAT2970(config-pmap-c)# set ip dscp 24 ! Signaling is marked to DSCP CS3
CAT2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Signaling traffic is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)#class class-default
CAT2970(config-pmap-c)# set ip dscp 0
CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile data traffic is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)# exit
CAT2970(config-pmap)#exit
CAT2970(config)#
CAT2970(config)#interface GigabitEthernet0/1
CAT2970(config-if)# service-policy input SOFTPHONE-PC ! Applies policy to int
CAT2970(config-if)#exit
CAT2970(config)#
CAT2970(config)#ip access-list extended SOFTPHONE-VOICE
CAT2970(config-ext-nacl)# permit udp any any range 16384 32767 ! VoIP ports
CAT2970(config-ext-nacl)#
CAT2970(config-ext-nacl)#ip access-list extended SOFTPHONE-SIGNALING
CAT2970(config-ext-nacl)# permit tcp any any range 2000 2002 ! SCCP ports
CAT2970(config-ext-nacl)#end
CAT2970#

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos

sh ow m ls qos m a p
 sh ow m ls qos in t e r fa ce

sh ow m ls qos in t e r fa ce police r s

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce

Catalyst 2970/3560/3750: Untrusted Server Model

The Unt rust ed Mult iapplicat ion Server m odel configurat ion for t he Cat alyst 2970/ 3560/ 3750 is
ident ical t o t he configurat ion of t he Cat alyst 3550 and is shown in Exam ple 12- 29 .

Ex a m ple 1 2 - 2 9 . Ca t a lyst 2 9 7 0 / 3 5 6 0 / 3 7 5 0 : Un t r u st e d M u lt ia pplica t ion

Se r ve r Ex a m ple

CAT2970(config)#mls qos map policed-dscp 0 10 18 25 to 8

! Excess traffic marked 0 or AF11 or AF21 or DSCP 25 will be remarked to CS1
CAT2970(config)#
CAT2970(config)#class-map SAP
CAT2970(config-cmap)# match access-group name SAP
CAT2970(config-cmap)#class-map LOTUS
CAT2970(config-cmap)# match access-group name LOTUS
CAT2970(config-cmap)#class-map IMAP
CAT2970(config-cmap)# match access-group name IMAP
CAT2970(config-cmap)#exit
CAT2970(config)#
CAT2970(config)#policy-map UNTRUSTED-SERVER
CAT2970(config-pmap)#class SAP
CAT2970(config-pmap-c)# set ip dscp 25 ! SAP is marked as Mission-Critical
CAT2970(config-pmap-c)# police 15000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile SAP is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)#class LOTUS
CAT2970(config-pmap-c)# set ip dscp 18 ! Lotus is marked as Transactional
CAT2970(config-pmap-c)# police 35000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile LOTUS is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)#class IMAP
CAT2970(config-pmap-c)# set ip dscp 10 ! IMAP is marked as Bulk Data
CAT2970(config-pmap-c)# police 50000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile IMAP is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)#class class-default
CAT2970(config-pmap-c)# set ip dscp 0
CAT2970(config-pmap-c)# police 1000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile excess data traffic is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)# exit
CAT2970(config-pmap)#exit
CAT2970(config)#
CAT2970(config)#interface GigabitEthernet0/1
CAT2970(config-if)# service-policy input UNTRUSTED-SERVER
CAT2970(config-if)#exit
CAT2970(config)#
CAT2970(config)#ip access-list extended SAP
CAT2970(config-ext-nacl)# permit tcp any range 3200 3203 any
CAT2970(config-ext-nacl)# permit tcp any eq 3600 any
CAT2970(config-ext-nacl)#
CAT2970(config-ext-nacl)#ip access-list extended LOTUS
CAT2970(config-ext-nacl)# permit tcp any eq 1352 any
CAT2970(config-ext-nacl)#
CAT2970(config-ext-nacl)#ip access-list extended IMAP
CAT2970(config-ext-nacl)# permit tcp any eq 143 any
CAT2970(config-ext-nacl)# permit tcp any eq 220 any
CAT2970(config-ext-nacl)#end
CAT2970#

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos

sh ow m ls qos m a p

sh ow m ls qos in t e r fa ce

sh ow m ls qos in t e r fa ce police r s

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce

Catalyst 2970/3560/3750: Conditionally Trusted IP Phone + PC: Basic

Model
The Cat alyst 2970/ 3560/ 3750 does not support per- port and per- VLAN policing at t he t im e of
t his writ ing. Therefore, access list s are required t o m at ch Voice and Call- Signaling t raffic sourced
from t he VVLAN. These ACLs require t he adm inist rat or t o specify t he VVLAN subnet inform at ion.
Exam ple 12- 30 shows t he configurat ion for a Condit ionally Trust ed I P Phone + PC: Basic m odel
for a Cat alyst 2970/ 3560/ 3750.

Ex a m ple 1 2 - 3 0 . Ca t a lyst 2 9 7 0 / 3 5 6 0 / 3 7 5 0 : Con dit ion a lly Tr u st e d I P

Ph on e + PC: Ba sic M ode l Ex a m ple

CAT2970(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56

! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF
CAT2970(config)#mls qos map policed-dscp 0 24 to 8
! Excess VVLAN & DVLAN traffic will be remarked to Scavenger (CS1)
CAT2970(config)#
CAT2970(config)#
CAT2970(config)#class-map match-all VVLAN-VOICE
CAT2970(config-cmap)# match access-group name VVLAN-VOICE
CAT2970(config-cmap)#
CAT2970(config-cmap)#class-map match-all VVLAN-CALL-SIGNALING
CAT2970(config-cmap)# match access-group name VVLAN-CALL-SIGNALING
CAT2970(config-cmap)#
CAT2970(config-cmap)#class-map match-all VVLAN-ANY
CAT2970(config-cmap)# match access-group name VVLAN-ANY
CAT2970(config-cmap)#
CAT2970(config-cmap)#
CAT2970(config-cmap)#policy-map IPPHONE+PC-BASIC
CAT2970(config-pmap)#class VVLAN-VOICE
CAT2970(config-pmap-c)# set ip dscp 46 ! DSCP EF (Voice)
CAT2970(config-pmap-c)# police 128000 8000 exceed-action drop
! Only one voice call is permitted per switchport VVLAN
CAT2970(config-pmap-c)#class VVLAN-CALL-SIGNALING
CAT2970(config-pmap-c)# set ip dscp 24 ! DSCP CS3 (Call-Signaling)
CAT2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Call-Signaling is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)#class VVLAN-ANY
CAT2970(config-pmap-c)# set ip dscp 0
CAT2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
! Unauthorized VVLAN traffic is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)#class class-default
CAT2970(config-pmap-c)# set ip dscp 0
CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile data traffic is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)# exit
CAT2970(config-pmap)#exit
CAT2970(config)#
CAT2970(config)#
CAT2970(config)#interface GigabitEthernet0/1
CAT2970(config-if)# switchport access vlan 10 ! DVLAN
CAT2970(config-if)# switchport voice vlan 110 ! VVLAN
CAT2970(config-if)# mls qos trust device cisco-phone ! Conditional Trust
CAT2970(config-if)# service-policy input IPPHONE+PC-BASIC ! Attaches policy
CAT2970(config-if)#exit
CAT2970(config)#
CAT2970(config)#
CAT2970(config)#ip access-list extended VVLAN-VOICE
CAT2970(config-ext-nacl)#permit udp 10.1.110.0 0.0.0.255
any range 16384 32767 dscp ef
! Voice is matched by VVLAN subnet and DSCP EF
CAT2970(config-ext-nacl)#exit
CAT2970(config)#
CAT2970(config)#ip access-list extended VVLAN-CALL-SIGNALING
CAT2970(config-ext-nacl)#permit tcp 10.1.110.0 0.0.0.255
any range 2000 2002 dscp af31
! Call-Signaling is matched by VVLAN subnet and DSCP AF31
CAT2970(config-ext-nacl)#permit tcp 10.1.110.0 0.0.0.255
any range 2000 2002 dscp cs3
! Call-Signaling is matched by VVLAN subnet and DSCP CS3
CAT2970(config-ext-nacl)#exit
CAT2970(config)#
CAT2970(config)#ip access-list extended VVLAN-ANY
CAT2970(config-ext-nacl)# permit ip 10.1.110.0 0.0.0.255 any
! Matches all other traffic sourced from the VVLAN subnet
CAT2970(config-ext-nacl)#end
CAT2970#
Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos

sh ow m ls qos m a p

sh ow m ls qos in t e r fa ce

sh ow m ls qos in t e r fa ce police r s

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce

Catalyst 2970/3560/3750: Conditionally Trusted IP Phone + PC:

Advanced Model
Building on t he previous m odel, PC applicat ions, such as I nt eract ive- Video, Mission- Crit ical Dat a,
Transact ional Dat a, and Bulk Dat a, are ident ified by access list s. Exam ple 12- 31 shows t he
configurat ion for t he Condit ionally Trust ed I P Phone + PC Advanced m odel for t he Cat alyst
2970/ 3560/ 3750.

Ex a m ple 1 2 - 3 1 . Ca t a lyst 2 9 7 0 / 3 5 6 0 / 3 7 5 0 : Con dit ion a lly Tr u st e d I P

Ph on e + PC: Ba sic M ode l Ex a m ple

CAT2970(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56

! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF
CAT2970(config)#mls qos map policed-dscp 0 10 18 24 25 34 to 8
! Excess DVLAN traffic marked 0, AF11, AF21, CS3, DSCP 25
! and AF41 will be remarked to Scavenger (CS1)
CAT2970(config)#
CAT2970(config)#
CAT2970(config)#class-map match-all VVLAN-VOICE
CAT2970(config-cmap)# match access-group name VVLAN-VOICE
CAT2970(config-cmap)#
CAT2970(config-cmap)#class-map match-all VVLAN-CALL-SIGNALING
CAT2970(config-cmap)# match access-group name VVLAN-CALL-SIGNALING
CAT2970(config-cmap)#
CAT2970(config-cmap)#class-map match-all VVLAN-ANY
CAT2970(config-cmap)# match access-group name VVLAN-ANY
CAT2970(config-cmap)#
CAT2970(config-cmap)#class-map match-all DVLAN-PC-VIDEO
CAT2970(config-cmap)# match access-group name DVLAN-PC-VIDEO
CAT2970(config-cmap)#
CAT2970(config-cmap)#class-map match-all DVLAN-MISSION-CRITICAL-DATA
CAT2970(config-cmap)# match access-group name DVLAN-MISSION-CRITICAL-DATA
CAT2970(config-cmap)#
CAT2970(config-cmap)#class-map match-all DVLAN-TRANSACTIONAL-DATA
CAT2970(config-cmap)# match access-group name DVLAN-TRANSACTIONAL-DATA
CAT2970(config-cmap)#
CAT2970(config-cmap)#class-map match-all DVLAN-BULK-DATA
CAT2970(config-cmap)# match access-group name DVLAN-BULK-DATA
CAT2970(config-cmap)#exit
CAT2970(config)#
CAT2970(config)#policy-map IPPHONE+PC-ADVANCED
CAT2970(config-pmap)#class VVLAN-VOICE
CAT2970(config-pmap-c)# set ip dscp 46 ! DSCP EF (Voice)
CAT2970(config-pmap-c)# police 128000 8000 exceed-action drop
! Only one voice call is permitted per switchport VVLAN
CAT2970(config-pmap-c)#class VVLAN-CALL-SIGNALING
CAT2970(config-pmap-c)# set ip dscp 24 ! DSCP CS3 (Call-Signaling)
CAT2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Call-Signaling is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)#class VVLAN-ANY
CAT2970(config-pmap-c)# set ip dscp 0
CAT2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
! Unauthorized VVLAN traffic is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)#class DVLAN-PC-VIDEO
CAT2970(config-pmap-c)# set ip dscp 34 ! DSCP AF41 (Interactive-Video)
CAT2970(config-pmap-c)# police 496000 8000 exceed-action policed-dscp-transmit
! Only one IP/VC stream will be permitted per switchport
CAT2970(config-pmap-c)#class DVLAN-MISSION-CRITICAL-DATA
CAT2970(config-pmap-c)# set ip dscp 25 ! Interim Mission-Critical Data
CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Mission-Critical Data is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)#class DVLAN-TRANSACTIONAL-DATA
CAT2970(config-pmap-c)# set ip dscp 18 ! DSCP AF21 (Transactional Data)
CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Transactional Data is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)#class DVLAN-BULK-DATA
CAT2970(config-pmap-c)# set ip dscp 10 ! DSCP AF11 (Bulk Data)
CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Bulk Data is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)#class class-default
CAT2970(config-pmap-c)# set ip dscp 0
CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile data traffic is marked down to Scavenger (CS1)
CAT2970(config-pmap-c)# exit
CAT2970(config-pmap)#exit
CAT2970(config)#
CAT2970(config)#interface GigabitEthernet0/1
CAT2970(config-if)# switchport access vlan 10 ! DVLAN
CAT2970(config-if)# switchport voice vlan 110 ! VVLAN
CAT2970(config-if)# mls qos trust device cisco-phone ! Conditional Trust
CAT2970(config-if)# service-policy input IPPHONE+PC-ADVANCED! Attaches Policy
CAT2970(config-if)#exit
CAT2970(config)#
CAT2970(config)#
CAT2970(config)#ip access-list extended VVLAN-VOICE
CAT2970(config-ext-nacl)#permit udp 10.1.110.0 0.0.0.255
any range 16384 32767 dscp ef
! Voice is matched by VVLAN subnet and DSCP EF
CAT2970(config-ext-nacl)#exit
CAT2970(config)#
CAT2970(config)#ip access-list extended VVLAN-CALL-SIGNALING
CAT2970(config-ext-nacl)#permit tcp 10.1.110.0 0.0.0.255
 any range 2000 2002 dscp af31
CAT2970(config-ext-nacl)#permit tcp 10.1.110.0 0.0.0.255
any range 2000 2002 dscp cs3
! Call-Signaling is matched by VVLAN subnet and DSCP AF31 or CS3
CAT2970(config-ext-nacl)#exit
CAT2970(config)#
CAT2970(config)#ip access-list extended VVLAN-ANY
CAT2970(config-ext-nacl)# permit ip 10.1.110.0 0.0.0.255 any
! Matches all other traffic sourced from the VVLAN subnet
CAT2970(config-ext-nacl)#
CAT2970(config-ext-nacl)#ip access-list extended DVLAN-PC-VIDEO
CAT2970(config-ext-nacl)# permit udp any any range 16384 32767 ! IP/VC
CAT2970(config-ext-nacl)#
CAT2970(config-ext-nacl)#ip access-list extended DVLAN-MISSION-CRITICAL-DATA
CAT2970(config-ext-nacl)# permit tcp any any range 3200 3203 ! SAP
CAT2970(config-ext-nacl)# permit tcp any any eq 3600 ! SAP
CAT2970(config-ext-nacl)# permit tcp any any range 2000 2002 ! SCCP
CAT2970(config-ext-nacl)#
CAT2970(config-ext-nacl)#ip access-list extended DVLAN-TRANSACTIONAL-DATA
CAT2970(config-ext-nacl)# permit tcp any any eq 1352 ! Lotus
CAT2970(config-ext-nacl)#
CAT2970(config-ext-nacl)#ip access-list extended DVLAN-BULK-DATA
CAT2970(config-ext-nacl)# permit tcp any any eq 143 ! IMAP
CAT2970(config-ext-nacl)# permit tcp any any eq 220 ! IMAP
CAT2970(config-ext-nacl)#end
CAT2970#

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos

sh ow m ls qos m a p

sh ow m ls qos in t e r fa ce

sh ow m ls qos in t e r fa ce police r s

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce

Catalyst 2970/3560/3750: Queuing and Dropping

For t he m ost part , t he Cat alyst 2970/ 3560/ 3750 is relat ively com pat ible in QoS feat ures and
synt ax wit h t he Cat alyst 3550, except wit h respect t o per- port / per- VLAN policing and
queuing/ dropping.

The Cat alyst 2970/ 3560/ 3750 support s four egress queues, which can be configured on a per-
int erface basis t o operat e in eit her 4Q3T or 1P3Q3T m odes. Addit ionally, t he cat alyst
2970/ 3560/ 3750 support s t wo queue set s, allowing cert ain int erfaces t o be configured in one
m anner and ot hers t o be configured in a different m anner. For exam ple, som e int erfaces can be
assigned t o queue set ( qset ) 1 operat ing in 4Q3T m ode, while ot hers can be assigned t o queue
set 2 operat ing in 1P3Q3T m ode.

However, unlike t he cat alyst 2950 and 3550, t he cat alyst 2970/ 3560/ 3750 has queue 1 ( not
queue 4) as t he opt ional priorit y queue. I n a converged cam pus environm ent , it is recom m ended
t o enable t he priorit y queue using t he pr ior it y- qu e u e ou t int erface com m and.

N ot e
The cat alyst 2970/ 3560/ 3750 also support s t wo configurable ingress queues ( norm al
and expedit e) . I ngress scheduling, however, is rarely, if ever, required because it
becom es enabled only if t he com bined input rat es from any swit ch port exceeds t he
swit ch fabric's capacit y. Such cases are ext rem ely difficult t o achieve, even in
cont rolled lab environm ent s. I n t he ext rem e case t hat such a scenario should develop
in a product ion environm ent , t he default set t ings of t he ingress queues are accept able
for m aint aining VoI P qualit y and net work availabilit y.

The t hree rem aining egress queues on t he cat alyst 2970/ 3560/ 3750 are scheduled by a shaped
r ound- r obin ( SRR) algorit hm , which can be configured t o operat e in shaped m ode or in shared
m ode. I n shaped m ode, assigned bandwidt h is lim it ed t o t he defined am ount ; in shared m ode,
any unused bandwidt h is shared am ong ot her classes ( as needed) .

Shaped or shared bandwidt h weight s can be assigned t o a queue using t he sr r - qu e u e

ba n dw idt h sh a pe and sr r - qu e u e ba n dw idt h sh a r e int erface com m ands. Shaped- m ode
weight s override shared- m ode weight s. Also, if shaped weight s are set t o 0, t he queue is
operat ing in shared m ode.

To m ake t he queuing st ruct ure consist ent wit h exam ples provided for previously discussed
plat form s, queues 2 t hrough 4 should be set t o operat e in shared m ode ( which is t he default
m ode of operat ion on queues 2 t hrough 4) . The rat io of t he shared weight s det erm ines t he
relat ive bandwidt h allocat ions ( t he absolut e values are m eaningless) . Because t he PQ of t he
cat alyst 2970/ 3560/ 3750 is Q1 ( not Q4, as in t he cat alyst 3550) , t he ent ire queuing m odel can
be flipped upside down, wit h Q2 represent ing t he crit ical dat a queue, Q3 represent ing t he Best -
Effort queue, and Q1 represent ing t he Scavenger queue. Therefore, shared weight s of 70, 25,
and 5 percent can be assigned t o queues 2, 3, and 4, respect ively.

N ot e
Alt hough t he cat alyst 2970/ 3560/ 3750 support s t he t weaking of queue buffers, t est ing
has shown t hat t his can int erfere wit h ingress policing policies ( on cat alyst I OS
versions 12.2[ 19] EA1ad and 12.2[ 18] SE for t he cat alyst 2970) .

Furt herm ore, adj ust ing t he default t hresholds on t he cat alyst 3750 som et im es causes
sim ilar int erference wit h ingress policing policies ( on cat alyst I OS versions
12.2[ 19] EA1ad and 12.2[ 18] SE for t he cat alyst 3750) .

Addit ionally, t he cat alyst 2970/ 3560/ 3750 support s t hree weight ed t ail drop ( WTD) t hresholds
per queue. Two of t hese t hresholds are configurable ( explicit ) ; t he t hird is nonconfigurable
( im plicit ) because it is set t o t he queue- full st at e ( 100 percent ) . These t hresholds can be defined
wit h t he m ls qos qu e u e - se t ou t pu t qse t - id t h r e sh old global com m and. The only queues t hat
t hese t hresholds need t o define ( away from default s) are queues 2 and 4. I n queue 2, it is
recom m ended t o set t he first t hreshold t o 70 percent and t he second t o 80 percent , which leaves
t he t hird ( im plicit ) t hreshold set at 100 percent ( t he t ail of t he queue) . I n queue 4, it is
recom m ended t o set t he first t hreshold t o 40 percent , leaving t he default values for bot h t he
second and t hird t hresholds at 100 percent .

Aft er t he queues and t hresholds have been defined, t raffic can be assigned t o queues and
t hresholds by eit her CoS values or DSCP values, using t he m ls qos sr r - qu e u e ou t pu t cos- m a p
qu e u e and m ls qos sr r - qu e u e ou t pu t dscp- m a p qu e u e global com m ands, respect ively.
Alt hough DSCP- t o- queue/ t hreshold m aps override CoS- t o- queue/ t hreshold m aps, t hese
m appings should be as consist ent as possible, t o ensure predict able behavior and sim plify
t roubleshoot ing.

That being said, CoS 0/ DSCP 0 ( Best - Effort t raffic) should be m apped t o queue 3 t hreshold 3
( t he t ail of t he queue) because no ot her t raffic is t o be assigned t o queue 3.

CoS 1 ( Scavenger and Bulk Dat a) should be m apped t o queue 4 t hreshold 3. Scavenger t raffic
can t hen be cont ained furt her by a DSCP- t o- queue/ t hreshold m apping assigning DSCP CS1 t o
queue 4 t hreshold 1 ( previously set at 40 percent ) ; Bulk Dat a using DSCP values AF11, AF12, or
AF13 ( decim al values 10, 12, and 14, respect ively) can use t he rem ainder of t he queue. Bulk
Dat a can use eit her t hreshold 2 or t hreshold 3 as it s WTD lim it ( bot h of which are set t o 100
percent ) .

CoS 2 and DSCP CS2, AF21, AF22, and AF23 ( decim al values 16, 18, 20, and 22, respect ively)
can be assigned t o queue 2 t hreshold 1 ( previously set at 70 percent ) . This lim it s Net work-
Managem ent and Transact ional Dat a t o a subset of queue 2. The t em porary m arking value for
Mission- Crit ical Dat a t raffic, DSCP 25, also should be assigned t o queue 2 t hreshold 1.

CoS 3, along wit h DSCP CS3 and AF31 ( decim al values 24 and 26, respect ively) can be assigned
t o queue 2 t hreshold 2 ( previously set t o 80 percent ) . This allows for preferent ial t reat m ent of
Call- Signaling t raffic wit hin queue 2.

CoS 4 and DSCP CS4, AF41, AF42, and AF43 ( decim al values 32, 34, 36, and 38, respect ively)
can be assigned t o queue 2 t hreshold 1. I n t his m anner, video ( bot h int eract ive and st ream ing)
will not drown out Call- Signaling or Net work and I nt ernet work Cont rol t raffic wit hin queue 2.

CoS 5 and DSCP EF ( decim al value 46) should be assigned t o queue 1 t hreshold 3 because Voice
is t he only t raffic t o be assigned t o t he st rict - priorit y queue.

CoS 6 and DSCP CS6 ( decim al value 48) , and CoS 7 and DSCP CS7 ( decim al value 56) should be
assigned t o queue 2 t hreshold 3. I n t his m anner, t here will always be som e room available in
queue 2 t o service Net work and I nt ernet work Cont rol t raffic.

Figure 12- 18 illust rat es t hese recom m ended cat alyst 2970/ 3560/ 3750 assignm ent s from
CoS/ DSCP t o queues/ t hresholds.

Figu r e 1 2 - 1 8 . Ca t a lyst 2 9 7 0 / 3 5 5 0 1 P3 Q3 T Qu e u in g M ode l

[View full size image]

Exam ple 12- 32 shows t he cat alyst 2970/ 3560/ 3750 queuing and dropping configurat ion
recom m endat ions.

Ex a m ple 1 2 - 3 2 . Ca t a lyst 2 9 7 0 / 3 5 6 0 / 3 7 5 0 : Qu e u in g a n d D r oppin g

Ex a m ple

CAT2970(config)#mls qos srr-queue output cos-map queue 1 threshold 3 5

! Maps CoS 5 to Queue 1 Threshold 3 (Voice gets all of Queue 1)
CAT2970(config)#mls qos srr-queue output cos-map queue 2 threshold 1 2 4
! Maps CoS 2 and CoS 4 to Queue 2 Threshold 1
CAT2970(config)#mls qos srr-queue output cos-map queue 2 threshold 2 3
! Maps CoS 3 to Queue 2 Threshold 2
CAT2970(config)#mls qos srr-queue output cos-map queue 2 threshold 3 6 7
! Maps CoS 6 and CoS 7 to Queue 2 Threshold 3
CAT2970(config)#mls qos srr-queue output cos-map queue 3 threshold 3 0
! Maps CoS 0 to Queue 3 Threshold 3 (Best Efforts gets all of Q3)
CAT2970(config)#mls qos srr-queue output cos-map queue 4 threshold 3 1
! Maps CoS1 to Queue 4 Threshold 3 (Scavenger/Bulk gets all of Q4)
CAT2970(config)#
CAT2970(config)#
CAT2970(config)#mls qos srr-queue output dscp-map queue 1 threshold 3 46
! Maps DSCP EF (Voice) to Queue 1 Threshold 3
CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 1 16
! Maps DSCP CS2 (Network Management) to Queue 2 Threshold 1
CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 1 18 20 22
! Maps DSCP AF21, AF22, AF23 (Transactional Data) to Queue 2 Threshold 1
CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 1 25
! Maps DSCP 25 (Mission-Critical Data) to Queue 2 Threshold 1
CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 1 32
! Maps DSCP CS4 (Streaming Video) to Queue 2 Threshold 1
CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 1 34 36 38
! Maps DSCP AF41, AF42, AF43 (Interactive-Video) to Queue 2 Threshold 1
CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 2 24 26
 ! Maps DSCP CS3 and DSCP AF31 (Call-Signaling) to Queue 2 Threshold 2
CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 3 48 56
! Maps DSCP CS6 and CS7 (Network/Internetwork) to Queue 2 Threshold 3
CAT2970(config)#mls qos srr-queue output dscp-map queue 3 threshold 3 0
! Maps DSCP 0 (Best Effort) to Queue 3 Threshold 3
CAT2970(config)#mls qos srr-queue output dscp-map queue 4 threshold 1 8
! Maps DSCP CS1 (Scavenger) to Queue 4 Threshold 1
CAT2970(config)#mls qos srr-queue output dscp-map queue 4 threshold 3 10 12 14
! Maps DSCP AF11, AF12, AF13 (Bulk Data) to Queue 4 Threshold 3
CAT2970(config)#
CAT2970(config)#
CAT2970(config)#mls qos queue-set output 1 threshold 2 70 80 100 100
! Sets Q2 Threshold 1 to 70% and Q2 Threshold 2 to 80%
CAT2970(config)#mls qos queue-set output 1 threshold 4 40 100 100 100
! Sets Q4 Threshold 1 to 40% and Q4 Threshold 2 to 100%
CAT2970(config)#
CAT2970(config)#interface range GigabitEthernet0/1 - 28
CAT2970(config-if-range)# queue-set 1
! Assigns interface to Queue-Set 1 (default)
CAT2970(config-if-range)# srr-queue bandwidth share 1 70 25 5
! Q2 gets 70% of remaining BW; Q3 gets 25% and Q4 gets 5%
CAT2970(config-if-range)# srr-queue bandwidth shape 30 0 0 0
! Q1 is limited to 30% of the total available BW
CAT2970(config-if-range)# priority-queue out
! Q1 is enabled as a PQ
CAT2970(config-if-range)#end
CAT2970#

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos in t e r fa ce bu ffe r s

sh ow m ls qos in t e r fa ce qu e u e in g

sh ow m ls qos qu e u e - se t

sh ow m ls qos m a ps cos- ou t pu t - q

sh ow m ls qos m a ps dscp- ou t pu t - q

Catalyst MLS QoS Verification Command: show mls qos queue-set

The sh ow m ls qos qu e u e - se t verificat ion com m and ret urns t he configured buffer allocat ions
and defined t hresholds for each queue set .

I n Exam ple 12- 33 , each queue has a default buffer allocat ion of 25 percent . Addit ionally, all
WTD t hresholds are set t o 100 percent ( t he t ail of t he queue) , except for queue 2 t hreshold 1
( set t o 70 percent ) , queue 2 t hreshold 2 ( set t o 80 percent ) , and queue 4 t hreshold 1 ( set t o 40
percent ) .

Ex a m ple 1 2 - 3 3 . sh ow m ls qos qu e u e - se t Verificat ion for a cat alyst

2970/ 3560/ 3750 Swit ch
CAT2970#show mls qos queue-set 1
Queueset: 1
Queue : 1 2 3 4
----------------------------------------------
buffers : 25 25 25 25
threshold1: 100 70 100 40
threshold2: 100 80 100 100
reserved : 50 100 50 100
maximum : 400 100 400 100
CAT2970#

Catalyst MLS QoS Verification Command: show mls qos maps cos-output-q

The sh ow m ls qos m a ps cos- ou t pu t - q verificat ion com m and t runcat es t he sh ow m ls qos

m a ps out put t o report only t he CoS- t o- queue/ t hreshold m appings for egress queues.

I n Exam ple 12- 34 , CoS 0 is m apped t o Q3T3, CoS 1 is m apped t o Q4T3, CoS 2 is m apped t o
Q2T1, CoS 3 is m apped t o Q2T2, CoS 4 is m apped t o Q2T1, CoS 5 is m apped t o Q1T3 ( t he PQ) ,
and CoS 6 and CoS 7 are m apped t o Q2T3.

Ex a m ple 1 2 - 3 4 . sh ow m ls qos m a ps cos- ou t pu t - q Verificat ion for a

Cat alyst 2970/ 3560/ 3750 Swit ch

CAT2970#show mls qos maps cos-output-q

Cos-outputq-threshold map:
cos: 0 1 2 3 4 5 6 7
------------------------------------
queue-threshold: 3-3 4-3 2-1 2-2 2-1 1-3 2-3 2-3
CAT2970#

Catalyst MLS QoS Verification Command: show mls qos maps dscp-output-q

The sh ow m ls qos m a ps dscp- ou t pu t - q verificat ion com m and t runcat es t he sh ow m ls qos

m a ps out put t o report only t he DSCP- t o- queue/ t hreshold m appings for egress queues. The
out put is shown in t abular form , wit h t he first digit of t he decim al DSCP value in rows and t he
second digit in colum ns.

I n Exam ple 12- 35 , only st andard DSCP PHBs are being m apped away from t he default set t ings
( wit h t he except ion of t he t em porary m arking of DSCP 25 for Mission- Crit ical Dat a) . The ot her
nonst andard values can be m apped t o reflect t he CoS- t o- queue m appings, but , for exam ple
sim plicit y, t his has not been done in t his case.

Specifically, DSCP 0 is m apped t o Q3T3; DSCP CS1 ( 8) is m apped t o Q4T1; DSCP AF11, AF12,
and AF13 ( 10, 12, 14) are m apped t o Q4T3; DSCP CS2 ( 16) is m apped t o Q2T1, as are DSCP
AF21, AF22, and AF23 ( 18, 20, 22) ; DSCP CS3 ( 24) and AF31 ( 26) are m apped t o Q2T2; DSCP
CS4 ( 32) is m apped t o Q2T1, as are DSCP AF41, AF42, and AF43 ( 34, 36, 38) ; DSCP EF ( 46) is
m apped t o Q1T3 ( t he PQ) ; and DSCP CS6 ( 48) and CS7 ( 56) are m apped t o Q2T3. The
nonst andard DSCP 25 is m apped t o Q2T1.
Ex a m ple 1 2 - 3 5 . sh ow m ls qos m a ps dscp- ou t pu t - q Verificat ion for a
cat alyst 2970/ 3560/ 3750 Swit ch

CAT2970#show mls qos maps dscp-output-q

Dscp-outputq-threshold map:
d1 :d2 0 1 2 3 4 5 6 7 8 9
-------------------------------------------------------------
0 : 03-03 02-01 02-01 02-01 02-01 02-01 02-01 02-01 04-01 02-01
1 : 04-03 02-01 04-03 02-01 04-03 02-01 02-01 03-01 02-01 03-01
2 : 02-01 03-01 02-01 03-01 02-02 02-01 02-02 03-01 03-01 03-01
3 : 03-01 03-01 02-01 04-01 02-01 04-01 02-01 04-01 02-01 04-01
4 : 01-01 01-01 01-01 01-01 01-01 01-01 01-03 01-01 02-03 04-01
5 : 04-01 04-01 04-01 04-01 04-01 04-01 02-03 04-01 04-01 04-01
6 : 04-01 04-01 04-01 04-01
CAT2970#
Catalyst 4500-SupII+/III/IV/V QoS Considerations and
Design
The cat alyst 4500 wit h Supervisors I I + t hrough V can be found at eit her t he access layer or t he
dist ribut ion layer of t he cam pus. Furt herm ore, because of t heir high perform ance, t hey also can
be found at t he core layer of som e cam pus net works.

Figure 12- 19 shows t he QoS design opt ions for access- layer cat alyst 4500 design; Figure 12- 20
shows t he dist ribut ion- and core- layer recom m endat ions.

Figu r e 1 2 - 1 9 . Acce ss- La ye r ca t a lyst 4 5 0 0 QoS D e sign

[View full size image]

Figu r e 1 2 - 2 0 . D ist r ibu t ion - a n d Cor e - La ye r ca t a lyst 4 5 0 0 QoS D e sign

 N ot e
To narrow t he scope of t his discussion t o t he m ost current and relevant versions of t he
Cat alyst 4500 swit ch fam ily, only t he only t he cat alyst 4500 wit h Supervisors I I +
t hrough V is exam ined is exam ined in t his design chapt er. For discussions about older
versions of cat alyst 4000/ 4500s, refer t o t he Cisco Press book Cisco cat alyst QoS:
Qualit y of Service in Cam pus Net works , by Mike Flannagan, Richard Froom , and Kevin
Turek.

Much of t he cat alyst MLS QoS synt ax is support ed on t he cat alyst 4500; however, t he m ls prefix
keyword usually is om it t ed from t he configurat ion com m ands. For exam ple, as wit h t he cat alyst
3550 and 2970/ 3560/ 3750, QoS is disabled globally on t he cat alyst 4500, by default . However,
t he com m and t o enable QoS globally on a cat alyst 4500 is sim ply qos , not m ls qos .

The verificat ion com m ands are issued in t he sam e m anner: wit h t he m ls keyword om it t ed.
Generally, sh ow m ls qos [ ...] verificat ion com m ands from ot her cat alyst plat form s are
t ranslat ed t o sh ow qos [ ...] verificat ion com m ands on t he cat alyst 4500 plat form s.

Alt hough QoS is disabled globally on t he cat alyst 4500, all fram es and packet s are passed
t hrough t he swit ch unalt ered ( which is equivalent t o a t rust CoS and t rust DSCP st at e on all
port s) . When QoS is enabled globally, however, all DSCP and CoS values ( by default ) are set t o
0 ( which is equivalent t o an unt rust ed st at e on all port s) .

Exam ple 12- 36 shows t he verificat ion com m and t o check whet her QoS has been globally
enabled on t he cat alyst 4500, along wit h t he configurat ion com m and t o do so.

Ex a m ple 1 2 - 3 6 . En a blin g QoS Globa lly on t h e ca t a lyst 4 5 0 0

CAT4500#show qos
QoS is disabled globally
IP header DSCP rewrite is enabled
CAT4500#

CAT4500#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
CAT4500(config)#qos
CAT4500(config)#end
CAT4500#

CAT4500#show qos
QoS is enabled globally
IP header DSCP rewrite is enabled
CAT4500#

Catalyst 4500: Trusted Endpoint Model

To enable a given cat alyst 4500 int erface t o t rust t he DSCP m arkings of an endpoint , t he qos
t r u st dscp int erface com m and is used, as shown in Exam ple 12- 37 .

Ex a m ple 1 2 - 3 7 . Ca t a lyst 4 5 0 0 : Tr u st e d En dpoin t Ex a m ple

CAT4500(config)#interface FastEthernet2/1
CAT4500(config-if)# qos trust dscp
CAT4500(config-if)#end
CAT4500#

Cat alyst 4500 QoS verificat ion com m ands:

sh ow qos

sh ow qos in t e r fa ce

N ot e
Because m ost cat alyst 4500 verificat ion com m ands are reasonably sim ilar t o t he MLS
QoS verificat ion com m ands previously discussed ( albeit wit hout t he m ls keyword) , t o
m inim ize redundancy, t he MLS QoS verificat ion com m ands t hat already have been
det ailed are not repeat ed in t his sect ion.

Catalyst 4500: Untrusted PC with SoftPhone Model

The Unt rust ed PC wit h Soft Phone access edge m odel for cat alyst 4500s, shown in Exam ple 12-
38 , is sim ilar t o t he exam ples given for previously discussed plat form s. A few dist inct ions exist ,
such as t he absence of t he m ls keyword in defining t he policed- DSCP m ap ( along wit h som e
slight synt ax variat ion for t his com m and) and t he ( opt ional) use of k bps and m bps ( denot ing
kilobit s and m egabit s, respect ively) wit hin t he policing st at em ent s.

Ex a m ple 1 2 - 3 8 . Ca t a lyst 4 5 0 0 : Un t r u st e d PC w it h Soft Ph on e M ode l

Ex a m ple

CAT4500-SUP4(config)#qos map dscp policed 0 24 46 to dscp 8

! Excess traffic marked 0 or CS3 or EF will be remarked to CS1
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#class-map match-all SOFTPHONE-SIGNALING
CAT4500-SUP4(config-cmap)# match access-group name SOFTPHONE-SIGNALING
CAT4500-SUP4(config-cmap)#class-map match-all SOFTPHONE-VOICE
CAT4500-SUP4(config-cmap)# match access-group name SOFTPHONE-VOICE
CAT4500-SUP4(config-cmap)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#policy-map SOFTPHONE-PC
CAT4500-SUP4(config-pmap)# class SOFTPHONE-VOICE
CAT4500-SUP4(config-pmap-c)# set ip dscp ef
! Softphone VoIP is marked to DSCP EF
CAT4500-SUP4(config-pmap-c)# police 128 kbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile SoftPhone voice traffic is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#class SOFTPHONE-SIGNALING
CAT4500-SUP4(config-pmap-c)# set ip dscp cs3
! SoftPhone Call-Signaling is marked to DSCP CS3
CAT4500-SUP4(config-pmap-c)# police 32 kbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile Signaling traffic is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#class class-default
CAT4500-SUP4(config-pmap-c)# set ip dscp default
CAT4500-SUP4(config-pmap-c)# police 5 mbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile data traffic is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#interface FastEthernet2/1
CAT4500-SUP4(config-if)# service-policy input SOFTPHONE-PC ! Applies policy
CAT4500-SUP4(config-if)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#ip access-list extended SOFTPHONE-VOICE
CAT4500-SUP4(config-ext-nacl)# permit udp any any range 16384 32767 ! VoIP
CAT4500-SUP4(config-ext-nacl)#
CAT4500-SUP4(config-ext-nacl)#ip access-list extended SOFTPHONE-SIGNALING
CAT4500-SUP4(config-ext-nacl)# permit tcp any any range 2000 2002 ! SCCP
CAT4500-SUP4(config-ext-nacl)#end
CAT4500-SUP4#

Cat alyst 4500 QoS verificat ion com m ands:

sh ow qos

sh ow qos m a ps

sh ow qos in t e r fa ce

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce

Catalyst 4500: Untrusted Server Model

Exam ple 12- 39 shows t he cat alyst 4500 Unt rust ed Mult iapplicat ion Server m odel. The m ain
changes for t he cat alyst 4500 for t his m odel are t he synt ax defining t he policed- DSCP m ap and
t he policer definit ions ( using t he abbreviat ion m bps for m egabit s per second) .

Ex a m ple 1 2 - 3 9 . Ca t a lyst 4 5 0 0 : Un t r u st e d M u lt ia pplica t ion Se r ve r

M ode l Ex a m ple

CAT4500-SUP4(config)#qos map dscp policed 0 10 18 25 to dscp 8

! Excess traffic marked 0 or AF11 or AF21 or DSCP 25 will be remarked to CS1
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#class-map SAP
CAT4500-SUP4(config-cmap)# match access-group name SAP
CAT4500-SUP4(config-cmap)#
CAT4500-SUP4(config-cmap)#class-map LOTUS
CAT4500-SUP4(config-cmap)# match access-group name LOTUS
CAT4500-SUP4(config-cmap)#
CAT4500-SUP4(config-cmap)#class-map IMAP
CAT4500-SUP4(config-cmap)# match access-group name IMAP
CAT4500-SUP4(config-cmap)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#policy-map UNTRUSTED-SERVER
CAT4500-SUP4(config-pmap)#class SAP
CAT4500-SUP4(config-pmap-c)# set ip dscp 25
! SAP is marked as Mission-Critical (DSCP 25)
CAT4500-SUP4(config-pmap-c)# police 15 mbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile SAP is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#class LOTUS
CAT4500-SUP4(config-pmap-c)# set ip dscp 18
! Lotus is marked as Transactional Data (DSCP AF21)
CAT4500-SUP4(config-pmap-c)# police 35 mbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile LOTUS is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#class IMAP
CAT4500-SUP4(config-pmap-c)# set ip dscp 10
! IMAP is marked as Bulk Data (DSCP AF11)
CAT4500-SUP4(config-pmap-c)# police 50 mbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile IMAP is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#class class-default
CAT4500-SUP4(config-pmap-c)# set ip dscp 0
CAT4500-SUP4(config-pmap-c)# police 1 mbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile excess data traffic is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)# exit
CAT4500-SUP4(config-pmap)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#interface FastEthernet2/1
CAT4500-SUP4(config-if)# service-policy input UNTRUSTED-SERVER
CAT4500-SUP4(config-if)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#ip access-list extended SAP
CAT4500-SUP4(config-ext-nacl)# permit tcp any range 3200 3203 any
CAT4500-SUP4(config-ext-nacl)# permit tcp any eq 3600 any
CAT4500-SUP4(config-ext-nacl)#
CAT4500-SUP4(config-ext-nacl)#ip access-list extended LOTUS
CAT4500-SUP4(config-ext-nacl)# permit tcp any eq 1352 any
CAT4500-SUP4(config-ext-nacl)#
CAT4500-SUP4(config-ext-nacl)#ip access-list extended IMAP
CAT4500-SUP4(config-ext-nacl)# permit tcp any eq 143 any
CAT4500-SUP4(config-ext-nacl)# permit tcp any eq 220 any
CAT4500-SUP4(config-ext-nacl)#end
CAT4500-SUP4#
Cat alyst 4500 QoS verificat ion com m ands:

sh ow qos

sh ow qos m a ps

sh ow qos in t e r fa ce

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce

Catalyst 4500: Conditionally Trusted IP Phone + PC: Basic Model

At t he t im e of t his writ ing, t he cat alyst 4500 does not support per- port / per- VLAN policing.
Therefore, access list s t hat include t he VVLAN subnet are required t o achieve granular policing of
t he VVLAN and DVLAN subnet s, as shown in Exam ple 12- 40 .

Ex a m ple 1 2 - 4 0 . Ca t a lyst 4 5 0 0 : Con dit ion a lly Tr u st e d I P Ph on e + PC:

Ba sic M ode l Ex a m ple

CAT4500-SUP4(config)#qos map cos 5 to dscp 46

! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF
CAT4500-SUP4(config)#qos map dscp policed 0 24 to dscp 8
! Excess DVLAN & VVLAN traffic will be marked down to Scavenger (CS1)
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#class-map match-all VVLAN-VOICE
CAT4500-SUP4(config-cmap)# match access-group name VVLAN-VOICE
CAT4500-SUP4(config-cmap)#
CAT4500-SUP4(config-cmap)#class-map match-all VVLAN-CALL-SIGNALING
CAT4500-SUP4(config-cmap)# match access-group name VVLAN-CALL-SIGNALING
CAT4500-SUP4(config-cmap)#
CAT4500-SUP4(config-cmap)#class-map match-all VVLAN-ANY
CAT4500-SUP4(config-cmap)# match access-group name VVLAN-ANY
CAT4500-SUP4(config-cmap)#
CAT4500-SUP4(config-cmap)#
CAT4500-SUP4(config-cmap)#policy-map IPPHONE+PC-BASIC
CAT4500-SUP4(config-pmap)#class VVLAN-VOICE
CAT4500-SUP4(config-pmap-c)# set ip dscp 46 ! DSCP EF (Voice)
CAT4500-SUP4(config-pmap-c)# police 128 kbps 8000 byte exceed-action drop
! Only one voice call is permitted per switchport VVLAN
CAT4500-SUP4(config-pmap-c)#class VVLAN-CALL-SIGNALING
CAT4500-SUP4(config-pmap-c)# set ip dscp 24 ! DSCP CS3 (Call-Signaling)
CAT4500-SUP4(config-pmap-c)# police 32 kbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile Call-Signaling is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#class VVLAN-ANY
CAT4500-SUP4(config-pmap-c)# set ip dscp 0
CAT4500-SUP4(config-pmap-c)# police 32 kbps 8000 byte exceed-action
policed-dscp-transmit
! Unauthorized VVLAN traffic is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#class class-default
CAT4500-SUP4(config-pmap-c)# set ip dscp 0
CAT4500-SUP4(config-pmap-c)# police 5 mbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile data traffic is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)# exit
CAT4500-SUP4(config-pmap)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#interface FastEthernet2/1
CAT4500-SUP4(config-if)# switchport access vlan 10 ! DVLAN
CAT4500-SUP4(config-if)# switchport voice vlan 110 ! VVLAN
CAT4500-SUP4(config-if)# qos trust device cisco-phone ! Conditional Trust
CAT4500-SUP4(config-if)# service-policy input IPPHONE+PC-BASIC ! MQC Policy
CAT4500-SUP4(config-if)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#ip access-list extended VVLAN-VOICE
CAT4500-SUP4(config-ext-nacl)# permit udp 10.1.110.0 0.0.0.255 any
range 16384 32767
! Voice is matched by VVLAN subnet and UDP port-range
CAT4500-SUP4(config-ext-nacl)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#ip access-list extended VVLAN-CALL-SIGNALING
CAT4500-SUP4(config-ext-nacl)# permit tcp 10.1.110.0 0.0.0.255 any
range 2000 2002
! Call-Signaling is matched by VVLAN subnet and TCP port-range
CAT4500-SUP4(config-ext-nacl)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#ip access-list extended VVLAN-ANY
CAT4500-SUP4(config-ext-nacl)# permit ip 10.1.110.0 0.0.0.255 any
! Matches all other traffic sourced from the VVLAN subnet
CAT4500-SUP4(config-ext-nacl)#end
CAT4500-SUP4#

Cat alyst 4500 QoS verificat ion com m ands:

sh ow qos

sh ow qos m a ps

sh ow qos in t e r fa ce

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce

Catalyst 4500: Conditionally Trusted IP Phone + PC: Advanced Model

Building on t he previous m odel, PC applicat ions such as I nt eract ive- Video, Mission- Crit ical Dat a,
Transact ional Dat a, and Bulk Dat a are ident ified by access list s. Exam ple 12- 41 shows t he
configurat ion for t he Condit ionally Trust ed I P Phone + PC: Advanced m odel for t he cat alyst
4500.

Ex a m ple 1 2 - 4 1 . Ca t a lyst 4 5 0 0 : Con dit ion a lly Tr u st e d I P Ph on e + PC:

Adva n ce d M ode l Ex a m ple

CAT4500-SUP4(config)#qos map cos 5 to dscp 46

! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF
CAT4500-SUP4(config)#qos map dscp policed 0 10 18 24 25 34 to dscp 8
! Excess DVLAN traffic marked 0, AF11, AF21, CS3, DSCP 25
! and AF41 will be remarked to Scavenger (CS1)
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#class-map match-all VVLAN-VOICE
CAT4500-SUP4(config-cmap)# match access-group name VVLAN-VOICE
CAT4500-SUP4(config-cmap)#
CAT4500-SUP4(config-cmap)#class-map match-all VVLAN-CALL-SIGNALING
CAT4500-SUP4(config-cmap)# match access-group name VVLAN-CALL-SIGNALING
CAT4500-SUP4(config-cmap)#
CAT4500-SUP4(config-cmap)#class-map match-all VVLAN-ANY
CAT4500-SUP4(config-cmap)# match access-group name VVLAN-ANY
CAT4500-SUP4(config-cmap)#
CAT4500-SUP4(config-cmap)#class-map match-all DVLAN-PC-VIDEO
CAT4500-SUP4(config-cmap)# match access-group name DVLAN-PC-VIDEO
CAT4500-SUP4(config-cmap)#
CAT4500-SUP4(config-cmap)#class-map match-all DVLAN-MISSION-CRITICAL-DATA
CAT4500-SUP4(config-cmap)# match access-group name DVLAN-MISSION-CRITICAL-DATA
CAT4500-SUP4(config-cmap)#
CAT4500-SUP4(config-cmap)#class-map match-all DVLAN-TRANSACTIONAL-DATA
CAT4500-SUP4(config-cmap)# match access-group name DVLAN-TRANSACTIONAL-DATA
CAT4500-SUP4(config-cmap)#
CAT4500-SUP4(config-cmap)#class-map match-all DVLAN-BULK-DATA
CAT4500-SUP4(config-cmap)# match access-group name DVLAN-BULK-DATA
CAT4500-SUP4(config-cmap)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#policy-map IPPHONE+PC-ADVANCED
CAT4500-SUP4(config-pmap)#class VVLAN-VOICE
CAT4500-SUP4(config-pmap-c)# set ip dscp 46 ! DSCP EF (Voice)
CAT4500-SUP4(config-pmap-c)# police 128 kbps 8000 byte exceed-action drop
! Only one voice call is permitted per switchport VVLAN
CAT4500-SUP4(config-pmap-c)#class VVLAN-CALL-SIGNALING
CAT4500-SUP4(config-pmap-c)# set ip dscp 24 ! DSCP CS3 (Call-Signaling)
CAT4500-SUP4(config-pmap-c)# police 32 kbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile Call-Signaling is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#class VVLAN-ANY
CAT4500-SUP4(config-pmap-c)# set ip dscp 0
CAT4500-SUP4(config-pmap-c)# police 32 kbps 8000 byte exceed-action
policed-dscp-transmit
! Unauthorized VVLAN traffic is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#class DVLAN-PC-VIDEO
CAT4500-SUP4(config-pmap-c)# set ip dscp 34 ! DSCP AF41 (Int-Video)
CAT4500-SUP4(config-pmap-c)# police 500 kbps 8000 byte exceed-action
policed-dscp-transmit:
! Only one IP/VC stream will be permitted per switchport
CAT4500-SUP4(config-pmap-c)#class DVLAN-MISSION-CRITICAL-DATA
CAT4500-SUP4(config-pmap-c)# set ip dscp 25 ! Interim Mission-Critical
CAT4500-SUP4(config-pmap-c)# police 5 mbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile Mission-Critical Data is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#class DVLAN-TRANSACTIONAL-DATA
CAT4500-SUP4(config-pmap-c)# set ip dscp 18 ! DSCP AF21
CAT4500-SUP4(config-pmap-c)# police 5 mbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile Transactional Data is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#class DVLAN-BULK-DATA
CAT4500-SUP4(config-pmap-c)# set ip dscp 10 ! DSCP AF11
CAT4500-SUP4(config-pmap-c)# police 5 mbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile Bulk Data is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#class class-default
CAT4500-SUP4(config-pmap-c)# set ip dscp 0
CAT4500-SUP4(config-pmap-c)# police 5 mbps 8000 byte exceed-action
policed-dscp-transmit
! Out-of-profile data traffic is marked down to Scavenger (CS1)
CAT4500-SUP4(config-pmap-c)#exit
CAT4500-SUP4(config-pmap)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#interface FastEthernet2/1
CAT4500-SUP4(config-if)# switchport access vlan 10 ! DVLAN
CAT4500-SUP4(config-if)# switchport voice vlan 110 ! VVLAN
CAT4500-SUP4(config-if)# qos trust device cisco-phone ! Conditional Trust
CAT4500-SUP4(config-if)# service-policy input IPPHONE+PC-ADVANCED ! MQC Policy
CAT4500-SUP4(config-if)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#ip access-list extended VVLAN-VOICE
CAT4500-SUP4(config-ext-nacl)# permit udp 10.1.110.0 0.0.0.255 any
range 16384 32767
! Voice is matched by VVLAN subnet and UDP port-range
CAT4500-SUP4(config-ext-nacl)#
CAT4500-SUP4(config-ext-nacl)#ip access-list extended VVLAN-CALL-SIGNALING
CAT4500-SUP4(config-ext-nacl)# permit tcp 10.1.110.0 0.0.0.255 any
range 2000 2002
! Call-Signaling is matched by VVLAN subnet and TCP port-range
CAT4500-SUP4(config-ext-nacl)#
CAT4500-SUP4(config-ext-nacl)#ip access-list extended VVLAN-ANY
CAT4500-SUP4(config-ext-nacl)# permit ip 10.1.110.0 0.0.0.255 any ! VVLAN ANY
CAT4500-SUP4(config-ext-nacl)#
CAT4500-SUP4(config-ext-nacl)#ip access-list extended DVLAN-PC-VIDEO
CAT4500-SUP4(config-ext-nacl)# permit udp any any range 16384 32767 ! IP/VC
CAT4500-SUP4(config-ext-nacl)#
CAT4500-SUP4(config-ext-nacl)#ip access-list extended DVLAN-MISSION-CRITICAL-DATA
CAT4500-SUP4(config-ext-nacl)# permit tcp any any range 3200 3203 ! SAP
CAT4500-SUP4(config-ext-nacl)# permit tcp any any eq 3600 ! SAP
CAT4500-SUP4(config-ext-nacl)# permit tcp any any range 2000 2002 ! SCCP
CAT4500-SUP4(config-ext-nacl)#
CAT4500-SUP4(config-ext-nacl)#ip access-list extended DVLAN-TRANSACTIONAL-DATA
CAT4500-SUP4(config-ext-nacl)# permit tcp any any eq 1352 ! Lotus
CAT4500-SUP4(config-ext-nacl)#
CAT4500-SUP4(config-ext-nacl)#ip access-list extended DVLAN-BULK-DATA
CAT4500-SUP4(config-ext-nacl)# permit tcp any any eq 143 ! IMAP
CAT4500-SUP4(config-ext-nacl)# permit tcp any any eq 220 ! IMAP
CAT4500-SUP4(config-ext-nacl)#end
CAT4500-SUP4#

Cat alyst 4500 QoS verificat ion com m ands:

sh ow qos

sh ow qos m a ps

sh ow qos in t e r fa ce

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce

Catalyst 4500: Queuing

The cat alyst 4500 support s four egress queues for scheduling, which can be configured in eit her
4Q1T or 1P3Q1T m odes. The st rict - priorit y queue on t he cat alyst 4500 is t ransm it queue 3.

Alt hough t ail- drop or WRED t hresholds are not support ed on t he cat alyst 4500, it does support
one of t he m ost advanced congest ion- avoidance m echanism s in t he cat alyst fam ily. This
congest ion- avoidance feat ure is perform ed by dynam ic buffer lim it ing ( DBL) . DBL t racks t he
queue lengt h for each t raffic flow in t he swit ch and, when t he queue lengt h of a flow exceeds it s
lim it , drops packet s or set s t he ( RFC 3168) explicit congest ion not ificat ion ( ECN) bit s in t he I P
packet headers. Of course, set t ing ECN bit s is of value only if t he end- point applicat ions also
support ECN ( as discussed in Chapt er 6 , " Congest ion- Avoidance Tools" ) .

DBL can be enabled globally wit h t he qos dbl global com m and or on a per- class basis wit hin a
policy m ap wit h t he dbl policy com m and. A default DBL policy can be applied t o all t ransm it
queues, as shown in t he upcom ing Exam ple 12- 42 .

By default , all queues are scheduled in a round- robin m anner. The t hird t ransm it queue can be
designat ed as an opt ional st rict - priorit y queue. This can be enabled as a via t h e t x - qu e u e 3
int erface com m and, followed by t he pr ior it y h igh in t e r fa ce t r a n sm it - qu e u e subcom m and.
This queue can be defined t o be shaped t o a peak lim it , such as 30 percent , t o allow bandwidt h
t o be available t o nonvoice applicat ions. This would be valuable if a t rust boundary has been
com prom ised and a DoS or worm at t ack is sat urat ing voice queues.

Bandwidt h allocat ions also can be assigned t o queues ( for cert ain int erfaces) using t he t x -
qu e u e int erface com m and, followed by t he ba n dw idt h subcom m and. Bandwidt h allocat ions t o
queues can be assigned only on t he following int erface t ypes:

Uplink port s on supervisor engines

Port s on t he WS- X4306- GB line card

 The t wo 1000BASE- X port s on t he WS- X4232- GB- RJ line card

The first t wo port s on t he WS- X4418- GB line card

The t wo 1000BASE- X port s on t he WS- X4412- 2GB- TX line card

The cat alyst 4500 does not support CoS- t o- queue m appings; it support s only DSCP- t o- queue
m appings. These can be defined wit h t he qos m a p dscp t o t x - qu e u e global com m and.

Given t hese feat ures and t he obj ect ive t o m ake queuing as consist ent across plat form s as
possible, it is recom m ended t o enable DBL globally on t he cat alyst 4500 and t o enable Q3 as t he
st rict - priorit y queue on all int erfaces ( so t hat t he swit ch will operat e in 1P3Q1T m ode) . This
queue can be shaped t o 30 percent of t he link's capacit y. Furt herm ore, Q1 can be used as t he
Scavenger/ Bulk Dat a queue, Q2 can be used as t he Best - Effort queue, and Q4 can be used as
t he preferent ial queue.

On int erfaces t hat support bandwidt h allocat ion, 5 percent can be assigned t o Q1, 25 percent
can be assigned t o Q2, and 40 percent can be assigned t o Q3. Unlike bandwidt h weight s t hat are
used on ot her plat form s, t hese bandwidt h allocat ions are defined in absolut e bit s per second or
as relat ive percent ages of t he link's bandwidt h. I n eit her case, t hey should not t ot al in excess of
t he link's bandwidt h lim it ( 1 Gbps, or 100 percent ) , including t he priorit y- bandwidt h allocat ion
for Q3.

By default , t he DSCP- t o- queue assignm ent s are as follows:

DSCP 0 t o 15: queue 1

DSCP 16 t o 31: queue 2

DSCP 32 t o 47: queue 3

DSCP 48 t o 63: queue 4

The recom m ended DSCP- t o- queue assignm ent s for t he cat alyst 4500 are as follows:

DSCP 0 should be assigned t o Q2.

DSCP CS1 ( Scavenger) and DSCP AF11, AF12, and AF13 ( Bulk Dat a) should be assigned t o
Q1.

DSCP CS2 ( Net work- Managem ent ) and AF21, AF22, and AF23 ( Transact ional Dat a) should
be assigned t o Q4.

DSCP CS3 and AF31 ( Call- Signaling) should be assigned t o Q4.

DSCP 25 ( t em porary m arking for Mission- Crit ical Dat a) should be assigned t o Q4.

DSCP CS4 ( St ream ing- Video) and AF41, AF42, and AF43 ( I nt eract ive- Video) should be
assigned t o Q4.

DSCP EF ( Voice) should be assigned t o Q3 ( t he st rict - priorit y queue) .

DSCP CS6 ( I nt ernet work Cont rol) and CS7 ( Net work Cont rol/ STP) should be assigned t o
Q4.

Figure 12- 21 illust rat es t he queuing recom m endat ions for t he cat alyst 4500 ( Supervisors I I +
t hrough V) .

Figu r e 1 2 - 2 1 . Ca t a lyst 4 5 0 0 - Su pI I + / I I I / I V/ V 1 P3 Q1 T Qu e u in g M ode l

[View full size image]

Exam ple 12- 42 shows t he configurat ions for enabling queuing on t he cat alyst 4500 per t hese
recom m endat ions. Two separat e exam ples are given: one for a Fast Et hernet int erface t hat
doesn't support bandwidt h allocat ions, and anot her for a Gigabit Et hernet int erface t hat does.
Som e of t he DSCP- t o- queue m appings shown are not required ( because t hey overlap wit h t he
default set t ings) , but t hey are shown nonet heless t o com plet e t he logic of t he exam ple.

Ex a m ple 1 2 - 4 2 . Ca t a lyst 4 5 0 0 : Qu e u in g a n d D r oppin g Ex a m ple s

CAT4500-SUP4(config)#qos dbl
! Globally enables DBL
CAT4500-SUP4(config)#qos dbl exceed-action ecn
! Optional: Enables DBL to mark RFC 3168 ECN bits in the IP ToS Byte
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#qos map dscp 0 to tx-queue 2
! Maps DSCP 0 (Best Effort) to Q2
CAT4500-SUP4(config)#qos map dscp 8 10 12 14 to tx-queue 1
! Maps DSCP CS1 (Scavenger) and AF11/AF12/AF13 (Bulk) to Q1
CAT4500-SUP4(config)#qos map dscp 16 18 20 22 to tx-queue 4
! Maps DSCP CS2 (Net-Mgmt) and AF21/AF22/AF23 (Transactional) to Q4
CAT4500-SUP4(config)#qos map dscp 24 25 26 to tx-queue 4
! Maps DSCP CS3 and AF31 (Call-Signaling) and DSCP 25 (MC Data) to Q4
CAT4500-SUP4(config)#qos map dscp 32 34 36 38 to tx-queue 4
! Maps DSCP CS4 (Str-Video) and AF41/AF42/AF43 (Int-Video) to Q4
CAT4500-SUP4(config)#qos map dscp 46 to tx-queue 3
! Maps DSCP EF (VoIP) to Q3 (PQ)
CAT4500-SUP4(config)#qos map dscp 48 56 to tx-queue 4
 ! Maps DSCP CS6 (Internetwork) and CS7 (Network) Control to Q4
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#policy-map DBL
CAT4500-SUP4(config-pmap)#class class-default
CAT4500-SUP4(config-pmap-c)# dbl ! Enables DBL on all traffic flows
CAT4500-SUP4(config-pmap-c)# exit
CAT4500-SUP4(config-pmap)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#interface range FastEthernet2/1 - 48
CAT4500-SUP4(config-if-range)# service-policy output DBL ! Applies DBL policy
CAT4500-SUP4(config-if-range)# tx-queue 3
CAT4500-SUP4(config-if-tx-queue)# priority high ! Enables Q3 as PQ
CAT4500-SUP4(config-if-tx-queue)# shape percent 30 ! Shapes PQ to 30%
CAT4500-SUP4(config-if-tx-queue)# exit
CAT4500-SUP4(config-if-range)#exit
CAT4500-SUP4(config)#
CAT4500-SUP4(config)#interface range GigabitEthernet1/1 - 2
CAT4500-SUP4(config-if-range)# service-policy output DBL ! Applies DBL policy
CAT4500-SUP4(config-if-range)# tx-queue 1
CAT4500-SUP4(config-if-tx-queue)# bandwidth percent 5 ! Q1 gets 5%
CAT4500-SUP4(config-if-tx-queue)# tx-queue 2
CAT4500-SUP4(config-if-tx-queue)# bandwidth percent 25 ! Q2 gets 25%
CAT4500-SUP4(config-if-tx-queue)# tx-queue 3
CAT4500-SUP4(config-if-tx-queue)# priority high ! Enables Q3 as PQ
CAT4500-SUP4(config-if-tx-queue)# bandwidth percent 30 ! PQ gets 30%
CAT4500-SUP4(config-if-tx-queue)# shape percent 30 ! Shapes PQ to 30%
CAT4500-SUP4(config-if-tx-queue)# tx-queue 4
CAT4500-SUP4(config-if-tx-queue)# bandwidth percent 40 ! Q4 gets 40%
CAT4500-SUP4(config-if-tx-queue)#end
CAT4500-SUP4#

Cat alyst 4500 QoS verificat ion com m ands:

sh ow qos dbl

sh ow qos m a ps dscp t x - qu e u e

sh ow qos in t e r fa ce

Catalyst 4500 QoS Verification Command: show qos dbl

The cat alyst 4500 sh ow qos dbl verificat ion com m and ret urns whet her DBL has been enabled,
along wit h som e of t he operat ing param et ers t hat have been defined for it s operat ion. These
param et ers include allowing DBL t o set RFC 3168 ECN bit s in I P headers, as shown in Exam ple
12- 43 .

Ex a m ple 1 2 - 4 3 . sh ow qos dbl Verificat ion for a cat alyst 4500 Swit ch

CAT4500-SUP4#show qos dbl

QOS is enabled globally
DBL is enabled globally
DBL flow includes vlan
DBL flow includes layer4-ports
DBL uses ecn to indicate congestion
DBL exceed-action probability: 15%
DBL max credits: 15
DBL aggressive credit limit: 10
DBL aggressive buffer limit: 2 packets
CAT4500-SUP4#

Catalyst 4500 QoS Verification Command: show qos maps dscp tx-queue

The cat alyst 4500 sh ow qos m a ps dscp t x - qu e u e verificat ion com m and t runcat es t he sh ow
qos m a ps out put t o report only t he DSCP- t o- queue m appings for egress queues. The out put is
shown in t abular form , wit h t he first digit of t he decim al DSCP value in rows and t he second digit
in colum ns.

I n Exam ple 12- 44 , only DSCP 0 is m apped t o Q2; DSCP CS1 ( 8) and AF11, AF12, and AF13 ( 10,
12, and 14) are m apped t o Q1; DSCP CS2 ( 16) and AF22, AF22, and AF23 ( 18, 20, and 22) are
m apped t o Q4; DSCP CS3 ( 24) and AF31 ( 26) are m apped t o Q4, as is t he nonst andard DSCP
25; DSCP CS4 ( 32) and AF41, AF42, and AF43 ( 34, 36, and 38) are m apped t o Q4, as are DSCP
CS6 ( 48) and CS7 ( 56) ; and DSCP EF ( 46) is m apped t o Q3.

Ex a m ple 1 2 - 4 4 . sh ow qos m a ps dscp t x - qu e u e Verificat ion for a cat alyst

4500 Swit ch

CAT4500-SUP4#show qos maps dscp tx-queue

DSCP-TxQueue Mapping Table (dscp = d1d2)
d1 : d2 0 1 2 3 4 5 6 7 8 9
-------------------------------------
0 : 02 01 01 01 01 01 01 01 01 01 ! DSCP 0 => Q2; DSCP CS1 => Q1
1 : 01 01 01 01 01 01 04 02 04 02 ! DSCP AF11/AF12/AF13 => Q1
! DSCP CS2 and AF21 => Q4
2 : 04 02 04 02 04 04 04 02 02 02 ! DSCP AF22/AF23 => Q4
! DSCP CS3, 25 and AF31 => Q4
3 : 02 02 04 03 04 03 04 03 04 03 ! DSCP CS4 and AF41/AF42/AF43 => Q4
4 : 03 03 03 03 03 03 03 03 04 04 ! DSCP EF => Q3; DSCP CS6 => Q4
5 : 04 04 04 04 04 04 04 04 04 04 ! DSCP CS7 => Q4
6 : 04 04 04 04
CAT4500-SUP4#

Catalyst 4500 QoS Verification Command: show qos interface

The cat alyst 4500 sh ow qos in t e r fa ce verificat ion com m and displays t he global st at e of QoS
( enabled or not ) , t he t rust st at e of an int erface, and any queuing or shaping param et ers t hat
have been defined for t he int erface.

I n Exam ple 12- 45 , t he sh ow qos in t e r fa ce com m and is being applied on an access- edge Fast
Et hernet int erface t hat has been configured t o condit ionally t rust Cisco I P phones. Furt herm ore,
t he out put report s t hat Q3 has been enabled as t he priorit y queue on t his int erface and is
shaped t o 30 Mbps ( 30 percent ) . Bandwidt h cannot be assigned for nonpriorit y queues on t his
int erface, as is indicat ed by t he " N/ A" ent ries under t he bandwidt h colum n.

I n Exam ple 12- 45 , t he sh ow qos in t e r fa ce com m and is being applied t o a Gigabit Et hernet
uplink int erface t hat has been configured t o t rust - DSCP. As before, Q3 has been enabled as t he
priorit y queue and has been shaped t o 30 percent , which now t ranslat es t o 300 Mbps. Bandwidt h
is assignable on t his int erface; t herefore, Q1 is allocat ed 50 Mbps ( 5 percent ) , Q2 is allocat ed
250 Mbps ( 25 percent ) , Q3 is allocat ed 300 Mbps ( 30 percent ) , and Q4 is allocat ed 400 Mbps
( 40 percent ) .

Ex a m ple 1 2 - 4 5 . sh ow qos in t e r fa ce Verificat ion for a cat alyst 4500 Swit ch

CAT4500-SUP4#show qos interface FastEthernet2/1

QoS is enabled globally
Port QoS is enabled
Administrative Port Trust State: 'cos'
Operational Port Trust State: 'cos'
Trust device: cisco-phone
Default DSCP: 0 Default CoS: 0
Appliance trust: none
Tx-Queue Bandwidth ShapeRate Priority QueueSize
(bps) (bps) (packets)
1 N/A disabled N/A 240
2 N/A disabled N/A 240
3 N/A 30000000 high 240
4 N/A disabled N/A 240
CAT4500-SUP4#

CAT4500-SUP4#show qos interface GigabitEthernet1/1

QoS is enabled globally
Port QoS is enabled
Administrative Port Trust State: 'dscp'
Operational Port Trust State: 'dscp'
Trust device: none
Default DSCP: 0 Default CoS: 0
Appliance trust: none
Tx-Queue Bandwidth ShapeRate Priority QueueSize
(bps) (bps) (packets)
1 50000000 disabled N/A 1920
2 250000000 disabled N/A 1920
3 300000000 300000000 high 1920
4 700000000 disabled N/A 1920
CAT4500-SUP4#
Catalyst 6500 QoS Considerations and Design
The cat alyst 6500 is t he undisput ed flagship of t he Cisco fam ily of LAN swit ches: I t is t he m ost
powerful and flexible Cisco swit ching plat form . As such, it can be found in all t hree layers of a
cam pus net work ( access, dist ribut ion, and core) .

N ot e
The Cisco 7600 rout er is ident ical in hardware QoS feat ures and configurat ion t o
cat alyst 6500s running Cisco I OS. However, t he Cisco 7600 is bet t er suit ed t o a MAN
or MPLS VPN environm ent t han a cam pus cont ext , which is t he scope of t his chapt er.
Therefore, alt hough m uch of t his chapt er is applicable t o t he Cisco 7600, t his
discussion cent ers on cat alyst 6500 QoS.

When configured as an access- layer swit ch, t he preferred soft ware for t he Supervisor is Cat OS;
when configured as a dist ribut ion- or core- layer swit ch, t he preferred soft ware is Cisco I OS.
Figure 12- 22 sum m arizes t he QoS design recom m endat ions for a cat alyst 6500 swit ch at t he
access layer; Figure 12- 23 shows t he corresponding recom m endat ions for cat alyst 6500s
deployed in t he dist ribut ion or core layers.

Figu r e 1 2 - 2 2 . Acce ss- La ye r ( Ca t OS) ca t a lyst 6 5 0 0 QoS D e sign

Figu r e 1 2 - 2 3 . D ist r ibu t ion - or Cor e - La ye r ( Cisco I OS) ca t a lyst 6 5 0 0

 QoS D e sign

N ot e
To narrow t he scope of t he discussion t o t he m ost current and relevant versions of t he
Cat alyst 6500 swit ch fam ily, only t he cat alyst 6500 wit h Supervisor 2 ( PFC2) and
Supervisor 720 ( PFC3) is exam ined in t his design chapt er. For discussions on older
versions of cat alyst 6000/ 6500s ( such as Supervisor 1, 1a wit h or wit hout a PFC) , refer
t o t he Cisco Press book Cisco cat alyst QoS: Qualit y of Service in Cam pus Net works , by
Mike Flannagan, Richard Froom , and Kevin Turek.

QoS is disabled globally by default on cat alyst 6500s running eit her Cat OS or Cisco I OS. When
QoS is disabled globally, all fram es and packet s t hat are passed t hrough t he swit ch rem ain
unalt ered ( which is equivalent t o a t rust CoS and t rust DSCP st at e on all port s) . When QoS is
enabled globally, however, all DSCP and CoS values are ( by default ) set t o 0 ( which is equivalent
t o an unt rust ed st at e on all port s) .

The com m ands t o globally enable and verify QoS on a cat alyst 6500 are shown in Exam ple 12-
46 for Cat OS and Exam ple 12- 47 for Cisco I OS.

Ex a m ple 1 2 - 4 6 . En a blin g QoS Globa lly on a ca t a lyst 6 5 0 0 : Ca t OS

CAT6500-PFC2-CATOS> (enable) set qos enable

QoS is enabled.
CAT6500-PFC2-CATOS> (enable)

CAT6500-PFC2-CATOS> (enable) show qos status

QoS is enabled on this switch.
CAT6500-PFC2-CATOS> (enable)
Ex a m ple 1 2 - 4 7 . En a blin g QoS Globa lly on a ca t a lyst 6 5 0 0 : Cisco I OS

CAT6500-PFC2-IOS(config)#mls qos
CAT6500-PFC2-IOS(config)#end
CAT6500-PFC2-IOS#

CAT6500-PFC2-IOS#show mls qos

QoS is enabled globally
Microflow policing is enabled globally
Vlan or Portchannel(Multi-Earl) policies supported: Yes
----- Module [2] -----
QoS global counters:
Total packets: 65
IP shortcut packets: 0
Packets dropped by policing: 0
IP packets with TOS changed by policing: 0
IP packets with COS changed by policing: 0
Non-IP packets with COS changed by policing: 0
CAT6500-PFC2-IOS#

Catalyst 6500: CatOS Defaults and Recommendations

Cat OS specifies a num ber of default QoS set t ings per port t hat do not appear in t he norm al
configurat ion out put . However, it is beneficial t o be aware of what t hese default s are and what
t hey do, so as not t o override t hem by m ist ake.

For exam ple, Cat OS allows t he QoS policy source t o be defined by t he local configurat ion or by
t he Com m on Open Policy Source ( COPS) prot ocol, referring t o a COPS policy- decision point
( PDP) Server. COPS is a QoS adm inist rat ion prot ocol t hat is bot h dynam ic and scalable, but ,
unfort unat ely, it never gained m ainst ream accept ance. I t is recom m ended t o leave t he swit ch's
default policy source as local ( except , of course, in t he ext rem ely rare occurrence t hat COPS
act ually is deployed on t he net work) .

Addit ionally, QoS policies can be applied t o VLANs or t o port s. There was never any significant
advant age of using one base over t he ot her, but Aut oQoS t ools favor port - based QoS because it
is m arginally sim pler t o configure. Port - based QoS is t he default per- port set t ing, and all
exam ples in t his chapt er are configured using port - based QoS.

All port s ( aft er QoS has been enabled globally) are set t o an unt rust ed st at e, by default . The
port CoS set t ing t hat all packet s are t agged wit h is 0, by default . Also by default , t he t rust
ext ension st at e is set t o unt rust ed, and t he ext ended- CoS is correspondingly set t o 0; t his
indicat es t hat any connect ed I P phones should re- m ark PC t raffic t o 0 on t heir ASI Cs.

I t is recom m ended t o leave all t hese port QoS set t ings at t heir default s, wit h t he except ion of
t rust depending on t he access edge m odel t o be applied, as discussed in t he following sect ion.

Catalyst 6500: Trusted Endpoint Model

For m ost cat alyst 6500 swit ch port s, set t ing t he t rust st at e t o t rust DSCP is a relat ively
st raight forward com m and ( in eit her Cat OS or Cisco I OS) .

I n Exam ple 12- 48 , DSCP- t rust is configured on a port in Cat OS; in Exam ple 12- 51 , DSCP- t rust
is configured on a port / int erface in Cisco I OS.

Ex a m ple 1 2 - 4 8 . Ca t a lyst 6 5 0 0 Ca t OS: Tr u st e d En dpoin t Ex a m ple

CAT6500-PFC2-CATOS> (enable) set port qos 3/1 trust trust-dscp

Port 3/1 qos set to trust-dscp.
CAT6500-PFC2-CATOS> (enable)

Cat alyst 6500 Cat OS QoS verificat ion com m ands:

sh ow qos st a t u s

sh ow por t qos

Catalyst 6500 CatOS QoS Verification Command: show port qos

The cat alyst 6500 Cat OS sh ow por t qos verificat ion com m and ret urns t he configured and
runt im e QoS st at es of a port . These m ight differ because cert ain com m ands need t o be
com m it t ed ( program m ed int o hardware) before t hey becom e effect ive.

I n Exam ple 12- 49 , t he swit ch has QoS globally enabled, and t he source of QoS policy decisions
is t he local configurat ion inst ead of a Com m on Open Policy Source policy- decision point ( COPS
PDP) .

Furt herm ore, t he out put shows t hat t he port is configured for port - based QoS ( by default ) and
has been set t o t rust DSCP from connect ed endpoint s. No t rust ext ension has been configured
because t his is not a condit ionally t rust ed endpoint m odel.

The out put includes t he line card's queuing capabilit ies1P3Q1T ( Transm it ) and 1P1Q0T
( Receive) along wit h any ACLs t hat m ight be m apped t o t he port . However, no ACLs have been
m apped t o t his port in t his part icular exam ple.

Ex a m ple 1 2 - 4 9 . sh ow por t qos Verificat ion for a Cat alyst 6500- Cat OS
Swit ch

CAT6500-PFC2-CATOS> (enable) show port qos 3/1

QoS is enabled for the switch.
QoS policy source for the switch set to local.
Port Interface Type Interface Type Policy Source Policy Source
config runtime config runtime
----- -------------- -------------- ------------- -------------
3/1 port-based port-based COPS local
Port TxPort Type RxPort Type Trust Type Trust Type Def CoS Def CoS
config runtime config runtime
----- ------------ ------------ ------------ ------------- ------- --------
3/1 1p3q1t 1p1q0t trust-dscp trust-dscp 0 0
Port Ext-Trust Ext-Cos Trust-Device
----- --------- ------- ------------
3/1 untrusted 0 none
(*)Runtime trust type set to untrusted.
Config:
Port ACL name Type
----- -------------------------------- ----
No ACL is mapped to port 3/1.
Runtime:
Port ACL name Type
----- -------------------------------- ----
No ACL is mapped to port 3/1.
CAT6500-PFC2-CATOS> (enable)

On nonGigabit Et hernet line cards t hat use 2Q2T t ransm it queuing and 1Q4T receive queuing, a
hardware lim it at ion prevent s t he proper funct ioning of port - based t rust ( which affect s t rust - cos,
t rust - ipprec, and t rust - dscp) . The sh ow por t qos com m and can be used t o det erm ine whet her
t he line card is a 2Q2T- Tx/ 1Q4T- Rx line card. These cards also are list ed in Table 12- 2 .

WS- X6704- 10GE

Cat alyst 6500 4- port 10 Gigabit Et hernet m odule

1Q8T ( 8Q8T wit h DFC3a)

1P7Q8T

16 MB per port

WS- X6724- SFP

Cat alyst 6500 24- port Gigabit Et hernet SFP m odule

1Q8T ( 2Q8T wit h DFC3a)

1P3Q8T

1 MB per port

WS- X6748- GE- TX

Cat alyst 6500 48- port 10/ 100/ 1000 RJ- 45 m odule

1Q8T ( 2Q8T wit h DFC3a)

1P3Q8T

1 MB per port

WS- X6748- SFP

Cat alyst 6500 48- port Gigabit Et hernet SFP m odule

1Q8T ( 2Q8T wit h DFC3a)

1P3Q8T
1 MB per port

Cla ssic/ CEF2 5 6 Et h e r n e t M odu le s

D e scr ipt ion

Re ce ive Qu e u e St r u ct u r e

Tr a n sm it Qu e u e St r u ct u r e

Bu ffe r Size

WS- X6024- 10FL- MT

Cat alyst 6000 24- port 10BASE- FL MT- RJ m odule

1Q4T

2Q2T

64 KB per port

WS- X6148- RJ21

Cat alyst 6500 48- port 10/ 100 RJ- 21 m odule ( upgradeable t o Voice)

1Q4T

2Q2T

128 KB per port

WS- X6148- RJ21V

Cat alyst 6500 48- port 10/ 100 I nline Power RJ- 21 m odule

1Q4T

2Q2T

128 KB per port

WS- X6148- RJ45

Cat alyst 6500 48- port 10/ 100; RJ- 45 m odule ( upgradeable t o Voice)

1Q4T

2Q2T

128 KB per port

WS- X6148- RJ45V

Cat alyst 6500 48- port 10/ 100 I nline Power RJ- 45 m odule

1Q4T

2Q2T
128 KB per port

WS- X6148- GE- TX

Cat alyst 6500 48- port 10/ 100/ 1000 RJ- 45 m odule

1Q2T

1P2Q2T

1 MB per 8 port s

WS- X6148V- GE- TX

Cat alyst 6500 48- port 10/ 100/ 1000 I nline Power RJ- 45 m odule

1Q2T

1P2Q2T

1 MB per 8 port s

WS- X6316- GE- TX

Cat alyst 6000 16- port 1000TX Gigabit Et hernet RJ- 45 m odule

1P1Q4T

1P2Q2T

512 KB per port

WS- X6324- 100FX- MM

Cat alyst 6000 24- port 100FX MT- RJ MMF m odule ( wit h Enhanced QoS)

1Q4T

2Q2T

128 KB per port

WS- X6324- 100FX- SM

Cat alyst 6000 24- port 100FX MT- RJ SMF m odule ( wit h Enhanced QoS)

1Q4T

2Q2T

128 KB per port

WS- X6348- RJ- 21

Cat alyst 6000 48- port 10/ 100 RJ- 21 m odule

1Q4T

2Q2T
128 KB per port

WS- X6348- RJ21V

Cat alyst 6000 48- port 10/ 100 I nline Power RJ- 21 m odule

1Q4T

2Q2T

128 KB per port

WS- X6348- RJ- 45

Cat alyst 6500 48- port 10/ 100 RJ- 45 m odule ( upgradeable t o Voice)

1Q4T

2Q2T

128 KB per port

WS- X6348- RJ45V

Cat alyst 6500 48- port 10/ 100 I nline Power RJ- 45 m odule

1Q4T

2Q2T

128 KB per port

WS- X6408A- GBI C

Cat alyst 6000 8- port Gigabit Et hernet m odule ( wit h Enhanced QoS; requires GBI Cs)

1P1Q4T

1P2Q2T

512 KB per port

WS- X6416- GBI C

Cat alyst 6000 16- port Gigabit Et hernet m odule ( requires GBI Cs)

1P1Q4T

1P2Q2T

512 KB per port

WS- X6416- GE- MT

Cat alyst 6000 16- port Gigabit Et hernet MT- RJ m odule

1P1Q4T

1P2Q2T
512 KB per port

WS- X6501- 10GEX4

1- port 10 Gigabit Et hernet m odule

1P1Q8T

1P2Q1T

64 MB per port

WS- X6502- 10GE

Cat alyst 6500 10 Gigabit Et hernet Base m odule ( requires OI M)

1P1Q8T

1P2Q1T

64 MB per port

WS- X6516A- GBI C

Cat alyst 6500 16- port Gigabit Et hernet m odule ( fabric enabled; requires GBI Cs)

1P1Q4T

1P2Q2T

1 MB per port

WS- X6516- GBI C

Cat alyst 6500 16- port Gigabit Et hernet m odule ( fabric enabled; requires GBI Cs)

1P1Q4T

1P2Q2T

512 KB per port

WS- X6516- GE- TX

Cat alyst 6500 16- port Gigabit Et hernet Copper m odule; ( crossbar enabled)

1P1Q4T

1P2Q2T

512 KB per port

WS- X6524- 100FX- MM

Cat alyst 6500 24- port 100FX MT- RJ m odule ( fabric enabled)

1P1Q0T

1P3Q1T
1 MB per port

WS- X6548- RJ- 21

Cat alyst 6500 48- port 10/ 100 RJ- 21 m odule ( fabric enabled)

1P1Q0T

1P3Q1T

1 MB per port

WS- X6548- RJ- 45

Cat alyst 6500 48- port 10/ 100 RJ- 45 m odule ( crossbar enabled)

1P1Q0T

1P3Q1T

1 MB per port

WS- X6548V- GE- TX

Cat alyst 6500 48- port 10/ 100/ 1000 I nline Power RJ- 45 m odule ( fabric enabled)

1Q2T

1P2Q2T

1 MB per 8 port s

WS- X6548- GE- TX

Cat alyst 6500 48- port 10/ 100/ 1000 RJ- 45 m odule ( fabric enabled)

1Q2T

1P2Q2T

1 MB per 8 port s

WS- X6816- GBI C

Cat alyst 6500 16- port Gigabit Et hernet m odule ( fabric enabled; requires GBI Cs)

1P1Q4T

1P2Q2T

512 KB per port

Ta ble 1 2 - 2 . Ca t a lyst 6 5 0 0 Lin e Ca r d Qu e u in g St r u ct u r e s

Re ce ive Tr a n sm it
C2 ( x CEF7 2 0 ) Qu e u e Qu e u e
M od u le s D e scr ipt ion St r u ct u r e St r u ct u r e Bu ffe r Size
On such line cards, a workaround ACL can be used t o achieve t rust funct ionalit y for t rust - cos,
t rust - ipprec, and t rust - dscp. Exam ple 12- 50 shows t he workaround ACL for t rust - DSCP
funct ionalit y on such line cards.

Ex a m ple 1 2 - 5 0 . Tr u st - D SCP W or k a r ou n d ACL for Ca t a lyst 6 5 0 0 2 Q2 T-

TX/ 1 Q4 T- Rx N on - Giga bit Lin e Ca r ds

CAT6500-PFC2-CATOS> (enable) set qos acl ip TRUST-DSCP trust-dscp any

TRUST-DSCP editbuffer modified. Use 'commit' command to apply changes.
CAT6500-PFC2-CATOS> (enable) commit qos acl TRUST-DSCP
QoS ACL 'TRUST-DSCP' successfully committed.
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos acl map TRUST-DSCP 4/1

N ot e
To apply t he QoS ACL t hat you have defined ( previously) , t he ACL m ust be com m it t ed
t o hardware. The process of com m it t ing copies t he ACL from a t em porary edit ing
buffer t o t he PFC hardware. When it is resident in t he PFC m em ory, t he policy defined
in t he QoS ACL can be applied t o all t raffic t hat m at ches t he ACEs. For ease of
configurat ion, m ost adm inist rat ors issue a com m it a ll com m and. However, you can
com m it a specific ACL ( by nam e) t o be sent from t he edit ing buffer t o PFC m em ory, as
shown in Exam ple 12- 50 .

I n Exam ple 12- 51 , DSCP- t rust is configured on a port / int erface in Cisco I OS.

Ex a m ple 1 2 - 5 1 . Ca t a lyst 6 5 0 0 Cisco I OS: Tr u st e d En dpoin t Ex a m ple

CAT6500-PFC2-IOS(config)#interface FastEthernet3/1
CAT6500-PFC2-IOS(config-if)#mls qos trust dscp

Cat alyst MLS QoS verificat ion com m ands:

sh ow m ls qos

sh ow m ls qos in t e r fa ce

N ot e
The ACL t rust workaround t o t he 2Q2T line card ( nonGigabit Et hernet int erfaces)
 lim it at ion of not support ing t rust applies only in t he access layer or t he cam pus ( where
Cat OS is t he recom m ended soft ware for t he Cat alyst 6500) . I n t he dist ribut ion and
core layers, where Cisco I OS is t he preferred soft ware, all int erfaces are recom m ended
t o be Gigabit Et hernet or higher. Therefore, a Cisco I OS workaround solut ion for t his
lim it at ion of 10/ 100 2Q2T port s is not warrant ed.

Catalyst 6500: Untrusted PC with SoftPhone Model

The radical difference in synt ax bet ween Cat OS and Cisco I OS becom es increasingly apparent as
m ore com plex access edge m odels are present ed.

I n t he Unt rust ed PC wit h Soft Phone m odel, shown in Exam ple 12- 52 , per- applicat ion aggregat e
policers are definedone each for Soft Phone VoI P t raffic, Soft Phone Call- Signaling t raffic, and PC
dat a t raffic. Then an ACL ( t it led SOFTPHONE- PC) wit h m ult iple ACEs is defined, wit h each ACE
referencing it s associat ed aggregat e policer. When com plet e, t he ACL is com m it t ed t o PFC
m em ory and t hen m apped t o t he desired swit ch port ( s) . Swit ch responses t o t he com m ands
have been om it t ed t o sim plify t he exam ple.

Ex a m ple 1 2 - 5 2 . Ca t a lyst 6 5 0 0 Ca t OS: Un t r u st e d PC w it h Soft Ph on e

M ode l Ex a m ple

CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map 0,24,46:8

! Excess traffic marked DSCP 0 or CS3 or EF will be remarked to CS1
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate SOFTPHONE-VOICE
rate 128 burst 8 policed-dscp
! Defines the policer for SoftPhone VoIP traffic
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate SOFTPHONE-SIGNALING
rate 32 burst 8 policed-dscp
! Defines the policer for SoftPhone Call-Signaling traffic
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate PC-DATA
rate 5000 burst 8 policed-dscp
! Defines the policer for PC Data traffic
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos acl ip SOFTPHONE-PC dscp 46
aggregate SOFTPHONE-VOICE udp any any range 16384 32767
! Binds ACL to policer and marks in-profile SoftPhone VoIP to DSCP EF
CAT6500-PFC2-CATOS> (enable) set qos acl ip SOFTPHONE-PC dscp 24
aggregate SOFTPHONE-SIGNALING tcp any any range 2000 2002
! Binds ACL to policer marks in-profile Call-Signaling to DSCP CS3
CAT6500-PFC2-CATOS> (enable) set qos acl ip SOFTPHONE-PC dscp 0
aggregate PC-DATA any
! Binds ACL to policer and marks in-profile PC Data traffic to DSCP 0
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) commit qos acl SOFTPHONE-PC
! Commits ACL to PFC memory
CAT6500-PFC2-CATOS> (enable) set port qos 3/1 trust untrusted
! Sets the port trust state to untrusted
CAT6500-PFC2-CATOS> (enable) set qos acl map SOFTPHONE-PC 3/1
! Attaches ACL to switch port
CAT6500-PFC2-CATOS> (enable)
Cat alyst 6500 Cat OS QoS verificat ion com m ands:

sh ow qos st a t u s

sh ow qos m a ps

sh ow por t qos

sh ow qos a cl

sh ow qos police r

sh ow qos st a t ist ics

Catalyst 6500 CatOS QoS Verification Command: show qos maps

The Cat alyst 6500 Cat OS sh ow qos m a ps verificat ion com m and is fairly sim ilar t o t he sh ow
m ls qos m a ps MLS QoS verificat ion com m and. I t ret urns t he configured CoS- DSCP, I PPrec-
DSCP, DSCP- CoS, and Norm al- Rat e and Excess- Rat e Policed- DSCP m aps. The com m and can
ret urn configured m aps ( which m ight or m ight not be com m it t ed t o t he PFC) or runt im e m aps.

I n t he ( t runcat ed) runt im e exam ple shown in Exam ple 12- 53 , all m aps are at t heir default
st at es, wit h t he except ion of t he Norm al- Rat e Policed- DSCP m ap, which has DSCP 0, CS3 ( 24) ,
and EF ( 46) m apped for out - of- profile m arkdown t o DSCP CS1 ( 8) .

Ex a m ple 1 2 - 5 3 . sh ow qos m a ps Verificat ion for a Cat alyst 6500- Cat OS

Swit ch

CAT6500-PFC2-CATOS> (enable) show qos maps runtime

CoS - DSCP map:
CoS DSCP
--- ----
0 0
1 8
2 16
3 24
4 32
5 40
6 48
7 56

IP-Precedence - DSCP map:

IP-Prec DSCP
------- ----
0 0
1 8
2 16
3 24
4 32
5 40
6 48
7 56
DSCP - CoS map:
DSCP CoS
-------------------------------- ---
0-7 0
8-15 1
16-23 2
24-31 3
32-39 4
40-47 5
48-55 6
56-63 7
DSCP - Policed DSCP map normal-rate:
DSCP Policed DSCP
-------------------------------- ------------
1 1
2 2
3 3
4 4
5 5
6 6
7 7
0,8,24,46 8
9 9
10 10
<output truncated>
63 63
DSCP - Policed DSCP map excess-rate:
DSCP Policed DSCP
-------------------------------- ------------
0 0
1 1
2 2
3 3
4 4
5 5
<output truncated>
63 63

CAT6500-PFC2-CATOS> (enable)

Catalyst 6500 CatOS QoS Verification Command: show qos acl

The Cat alyst 6500 Cat OS sh ow qos a cl verificat ion com m and ret urns inform at ion about ACLs
and ACEs t hat have been configured for QoS purposes. ACL inform at ion can be displayed for
configurat ion ACLs or runt im e ACLs.

Exam ple 12- 54 displays t hree variat ions of t he sh ow qos a cl com m and.

The first one displays t he QoS ACLs t hat are st ill in t he edit buffer and indicat es whet her t he
ACLs have been com m it t ed t o PFC m em ory. I n t his exam ple, t he ACL SOFTPHONE- PC has been
com m it t ed t o t he PFC.

The second exam ple displays runt im e ACE- level inform at ion for a given ACL ( or all ACLs, if t he
keyword a ll is used inst ead of t he ACL nam e) . Each ACE's DSCP m arkings, associat ed aggregat e
policer, and filt ering crit eria are displayed.

The t hird exam ple displays t he VLANs and port s t hat t he ACL has been applied t o. I n t his specific
exam ple, port 3/ 1 has t he SOFTPHONE- PC ACL applied t o it .

Ex a m ple 1 2 - 5 4 . sh ow qos a cl Verificat ion for a Cat alyst 6500- Cat OS Swit ch

CAT6500-PFC2-CATOS> (enable) show qos acl editbuffer

ACL Type Status
-------------------------------- ---- ----------
SOFTPHONE-PC IP Committed
CAT6500-PFC2-CATOS> (enable)

CAT6500-PFC2-CATOS> (enable) show qos acl info runtime SOFTPHONE-PC

set qos acl IP SOFTPHONE-PC
-------------------------------------------------
1. dscp 46 aggregate SOFTPHONE-VOICE udp any any range 16384 32767
2. dscp 24 aggregate SOFTPHONE-SIGNALING tcp any any range 2000 2002
3. dscp 0 aggregate PC-DATA any
CAT6500-PFC2-CATOS> (enable)

CAT6500-PFC2-CATOS> (enable) show qos acl map runtime SOFTPHONE-PC

QoS ACL mappings on input side:
ACL name Type Vlans
-------------------------------- ---- ---------------------------------
SOFTPHONE-PC IP
ACL name Type Ports
-------------------------------- ---- ---------------------------------
SOFTPHONE-PC IP 3/1
CAT6500-PFC2-CATOS> (enable)

Catalyst 6500 CatOS QoS Verification Command: show qos policer

The Cat alyst 6500 Cat OS sh ow qos police r verificat ion com m and displays t he norm al and
excess rat es and burst for policers.

I n Exam ple 12- 55 , t hree aggregat e policers have been defined: SOFTPHONE- VOI CE,
SOFTPHONE- SI GNALI NG, and PC- DATA, wit h norm al rat es of 128 kbps, 32 kbps, and 5 Mbps,
respect ively. Each of t hese policers m arks down excess t raffic according t o t he policed- DSCP
norm al rat e and are at t ached t o t he ACL SOFTPHONE- PC.

Ex a m ple 1 2 - 5 5 . sh ow qos police r Verificat ion for a Cat alyst 6500- Cat OS
Swit ch

CAT6500-PFC2-CATOS> (enable) show qos policer runtime all

Warning: Runtime information may differ from user configured setting due to
hardware granularity.
QoS microflow policers:
QoS aggregate policers:
Aggregate name Avg. rate (kbps) Burst size (kb) Normal action
--------------------- ---------------- --------------- -------------
SOFTPHONE-VOICE 128 8 policed-dscp
Excess rate (kbps) Excess burst size (kb) Excess action
------------------ ---------------------- -------------
31457280 31744 policed-dscp
ACL attached
------------------------------------
SOFTPHONE-PC
Aggregate name Avg. rate (kbps) Burst size (kb) Normal action
--------------------- ---------------- --------------- -------------
SOFTPHONE-SIGNALING 32 8 policed-dscp
Excess rate (kbps) Excess burst size (kb) Excess action
------------------ ---------------------- -------------
31457280 31744 policed-dscp
ACL attached
------------------------------------
SOFTPHONE-PC
Aggregate name Avg. rate (kbps) Burst size (kb) Normal action
--------------------- ---------------- --------------- -------------
PC-DATA 4864 8 policed-dscp
Excess rate (kbps) Excess burst size (kb) Excess action
------------------ ---------------------- -------------
31457280 31744 policed-dscp
ACL attached
------------------------------------
SOFTPHONE-PC
CAT6500-PFC2-CATOS> (enable)

Catalyst 6500 CatOS QoS Verification Command: show qos statistics

The Cat alyst 6500 Cat OS sh ow qos st a t ist ics verificat ion com m and displays various dynam ic
st at ist ics regarding t he QoS policies.

I n t he t hree part s of Exam ple 12- 56 , t he first variat ion of t he com m and sh ow qos st a t ist ics
m od | port ret urns queuing st at ist ics for t he port . Specifically, it report s any drops because of
queue buffer overfill and breaks down t hese drops by queues or t hresholds, depending on t he
queuing st ruct ure of t he m odule. I n t his first part of t he exam ple, no drops have occurred
because of queuing buffer overfills.

I n t he second part of Exam ple 12- 56 , aggregat e policing st at ist ics are displayed t hrough t he
sh ow qos st a t ist ics a ggr e ga t e - police r variat ion of t he com m and. The num ber of packet s t hat
conform t o or exceed a given policer is report ed. I n t his part of t he exam ple, t he com m and
report s t hat no packet s have exceeded t he SOFTPHONE- VOI P or SOFTPHONE- SI GNALI NG
policers, but a few have exceeded t he PC- DATA policer.

Finally, in t he t hird part of Exam ple 12- 56 , t he num ber of packet s t hat have been dropped
because of policing or have been re- m arked at Layer 3 or Layer 2 is report ed wit h t he sh ow qos
st a t ist ics l3 st a t s com m and. I n t his final part of t he exam ple, t he com m and report s t hat no
packet s have been dropped because of policing, but t housands of packet s have had t heir L3 and
L2 m arkings m odified by t he configured policy.
Ex a m ple 1 2 - 5 6 . sh ow qos st a t ist ics Verificat ion for a Cat alyst 6500- Cat OS
Swit ch

CAT6500-PFC2-CATOS> (enable) show qos statistics 3/1

Tx port type of port 3/1 : 1p3q1t
WRED and tail drops are accumulated in one counter per queue.
Q # Packets dropped
--- -----------------------------------------------
1 0 pkts
2 0 pkts
3 0 pkts
4 0 pkts
Rx port type of port 3/1 : 1p1q0t
For untrusted ports all the packets are sent to the same queue,
Rx thresholds are disabled, tail drops are reported instead.
Q # Threshold #:Packets dropped
--- -----------------------------------------------
1 0:0 pkts
2 0:0 pkts
CAT6500-PFC2-CATOS> (enable)

CAT6500-PFC2-CATOS> (enable) show qos statistics aggregate-policer

QoS aggregate-policer statistics:
Aggregate policer Allowed packet Packets exceed
count excess rate
------------------------------- -------------- --------------
SOFTPHONE-VOICE 27536 0
SOFTPHONE-SIGNALING 224 0
PC-DATA 470069 645
CAT6500-PFC2-CATOS> (enable)

CAT6500-PFC2-CATOS> (enable) show qos statistics l3stats

Packets dropped due to policing: 0
IP packets with ToS changed: 169286
IP packets with CoS changed: 83507
Non-IP packets with CoS changed: 0
CAT6500-PFC2-CATOS> (enable)

Catalyst 6500: Untrusted Server Model

Addit ional flexibilit y is offered t o t he Unt rust ed Server m odel wit h t he Cat alyst 6500 PFC2/ PFC3's
support of dual- rat e policing ( as described in RFC 2698, " A Two Rat e Three Color Marker," and
as illust rat ed in Figure 4- 5 ) .

Using a dual- rat e policer, t hree colors are used t o indicat e t he following:

Conform ing t raffic ( wit hin t he norm al rat e)

Excess t raffic ( exceeding t he norm al rat e but less t han t he excess rat e)
 Violat ing t raffic ( exceeding bot h t he norm al and excess rat es)

The dual- rat e policer is int ended t o com plem ent t he RFC 2597 assured- forwarding groups
DiffServ m arking schem e. To illust rat e t his, consider Transact ional Dat a t raffic, which is m arked
t o AF Class 2. Conform ing Transact ional Dat a should be m arked t o AF21, excess Transact ional
Dat a t raffic should be m arked down t o AF22, and violat ing Transact ional Dat a t raffic should be
m arked down furt her t o AF23.

Such a m arkdown schem e is int ended t o be com plem ent ed furt her by DSCP- based WRED
congest ion avoidance. I n t his m anner, if congest ion occurs, AF23 is dropped m ore aggressively
t han AF22, which, in t urn, is dropped m ore aggressively t han AF21.

However, because Cat alyst 6500 queuing and congest ion avoidance are det erm ined prim arily by
CoS m arkings, t he st andards- based DSCP m odel cannot be followed com plet ely at t his t im e on
t his plat form . ( Because AF21, AF22, and AF23 all share CoS 3, t his does not allow for granular
subclass QoS.) Therefore, Scavenger class m arkings for violat ing t raffic could be used t o achieve
a sim ilar overall effect , while m aint aining consist ency wit h QoS designs previously present ed for
ot her Cat alyst plat form s.

Under such a m odified Unt rust ed Mult iapplicat ion Server m odel, excess Transact ional Dat a t raffic
can be m arked down t o AF22 and violat ing Transact ional Dat a t raffic can be m arked down t o
DSCP CS1 ( Scavenger) . Sim ilarly, excess Bulk Dat a t raffic can be m arked down t o AF12 and
violat ing Bulk Dat a t raffic can be m arked down t o DSCP CS1 ( Scavenger) . This m odified m odel is
shown in Figure 12- 24 .

Figu r e 1 2 - 2 4 . Ca t a lyst 6 5 0 0 PFC2 / PFC3 Un t r u st e d En dpoin t D u a l- Ra t e

Policin g: M u lt ia pplica t ion Se r ve r Ex a m ple

[View full size image]

Exam ple 12- 57 shows t he configurat ion for a Cat alyst 6500 Cat OS unt rust ed endpoint dual- rat e
policing of a m ult iapplicat ion server.
Ex a m ple 1 2 - 5 7 . Ca t a lyst 6 5 0 0 Ca t OS: Un t r u st e d M u lt ia pplica t ion
Se r ve r Ex a m ple ( D u a l- Ra t e Policin g)

CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map normal-rate 0,25:8

! Excess SAP and Data traffic is marked down to DSCP CS1 (Scavenger)
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map normal-rate 18:20
! Excess Transactional Data traffic is marked down from DSCP AF21 to AF22
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map excess-rate 18:8
! Violating Transactional Data traffic is marked down to CS1
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map normal-rate 10:12
! Excess Bulk Data traffic is marked down from DSCP AF11 to AF12
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map excess-rate 10:8
! Violating Bulk Data traffic is marked down to CS1
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate SAP
rate 15000 burst 8 policed-dscp
! Defines the policer for Mission-Critical Data (SAP) traffic
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate LOTUS
rate 25000 policed-dscp erate 35000 policed-dscp burst 8
! Defines the dual-rate policer for Transactional Data (Lotus) traffic
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate IMAP
rate 40000 policed-dscp erate 50000 policed-dscp burst 8
! Defines the dual-rate policer for Bulk Data (IMAP) traffic
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate DATA
rate 1000 burst 8 policed-dscp
! Defines the policer for other data traffic
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos acl ip UNTRUSTED-SERVER dscp 25
aggregate SAP tcp any range 3200 3203 any
! Binds ACL to policer and marks in-profile SAP to DSCP 25
CAT6500-PFC2-CATOS> (enable) set qos acl ip UNTRUSTED-SERVER dscp 25
aggregate SAP tcp any eq 3600 any
! Binds ACL to policer and marks in-profile SAP to DSCP 25
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos acl ip UNTRUSTED-SERVER dscp 18
aggregate LOTUS tcp any eq 1352 any
! Binds ACL to dual-rate policer and marks in-profile Lotus to DSCP AF21
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos acl ip UNTRUSTED-SERVER dscp 10
aggregate IMAP tcp any eq 143 any
! Binds ACL to dual-rate policer and marks in-profile IMAP to DSCP AF11
CAT6500-PFC2-CATOS> (enable) set qos acl ip UNTRUSTED-SERVER dscp 10
aggregate IMAP tcp any eq 220 any
! Binds ACL to dual-rate policer and marks in-profile IMAP to DSCP AF11
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos acl ip UNTRUSTED-SERVER dscp 0
aggregate DATA any
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) commit qos acl UNTRUSTED-SERVER
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set port qos 3/1 trust untrusted
! Sets the port trust state to untrusted
CAT6500-PFC2-CATOS> (enable) set qos acl map UNTRUSTED-SERVER 3/1
CAT6500-PFC2-CATOS> (enable)
Cat alyst 6500 Cat OS QoS verificat ion com m ands:

sh ow qos st a t u s

sh ow qos m a ps

sh ow por t qos

sh ow qos a cl

sh ow qos police r

sh ow qos st a t ist ics

Catalyst 6500: Conditionally Trusted IP Phone + PC: Basic Model

I n t he Condit ionally Trust ed I P Phone + PC m odel for t he Cat alyst 6500 ( Cat OS) , four aggregat e
policers are defined, one each for Voice from t he VVLAN, Call Signaling from t he VVLAN, all ot her
t raffic from t he VVLAN, and all PC dat a t raffic. Condit ional t rust is ext ended t o t he I P phones
using t he t r u st - de v ice com m and, as shown in Exam ple 12- 58 .

Ex a m ple 1 2 - 5 8 . Ca t a lyst 6 5 0 0 Ca t OS: Con dit ion a lly Tr u st e d I P Ph on e

+ PC: Ba sic M ode l Ex a m ple

CAT6500-PFC2-CATOS> (enable) set qos cos-dscp-map 0 8 16 24 32 46 48 56

! Modifies default CoS-DSCP mapping so that CoS 5 is mapped to DSCP EF
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map 0,24:8
! Excess traffic marked DSCP 0 or CS3 is remarked to CS1
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate VVLAN-VOICE
rate 128 burst 8 drop
! Defines the policer for IP Phone VoIP traffic
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate VVLAN-SIGNALING
rate 32 burst 8 policed-dscp
! Defines the policer for IP Phone Call-Signaling traffic
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate VVLAN-ANY
rate 32 burst 8 policed-dscp
! Defines the policer for any other traffic sourced from the VVLAN
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate PC-DATA
rate 5000 burst 8 policed-dscp
! Defines the policer for PC Data traffic
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-BASIC dscp 46
aggregate VVLAN-VOICE udp 10.1.110.0 0.0.0.255 any range 16384 32767
! Binds ACL to policer and marks in-profile VVLAN VoIP to DSCP EF
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-BASIC dscp 24
aggregate VVLAN-SIGNALING udp 10.1.110.0 0.0.0.255 any range 2000 2002
! Binds ACL to policer marks in-profile VVLAN Call-Signaling to DSCP CS3
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-BASIC dscp 0
aggregate VVLAN-ANY 10.1.110.0 0.0.0.255
 ! Binds ACL to policer and marks all other VVLAN traffic to DSCP 0
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-BASIC dscp 0
aggregate PC-DATA any
! Binds ACL to policer and marks in-profile PC Data traffic to DSCP 0
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) commit qos acl IPPHONE-PC-BASIC
! Commits ACL to PFC memory
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set port qos 3/1 trust-device ciscoipphone
! Conditional trust (for Cisco IP Phones only)
CAT6500-PFC2-CATOS> (enable) set qos acl map IPPHONE-PC-BASIC 3/1
! Attaches ACL to switch port
CAT6500-PFC2-CATOS> (enable)

Cat alyst 6500 Cat OS QoS verificat ion com m ands:

sh ow qos st a t u s

sh ow qos m a ps

sh ow por t qos

sh ow qos a cl

sh ow qos police r

sh ow qos st a t ist ics

N ot e
As previously m ent ioned, on nonGigabit Et hernet line cards t hat use 2Q2T t ransm it
queuing and 1Q4T receive queuing, a hardware lim it at ion prevent s t he proper
funct ioning of port - based t rust ( which affect s t rust - cos, t rust - ipprec, and t rust - dscp) .
On such line cards, a workaround ACL can be used t o achieve t rust funct ionalit y. For
such an exam ple, see t he sect ion " Cat alyst 6500 Cat OS QoS Verificat ion Com m and:
show port qos " ( see Exam ple 12- 50 ) , earlier in t his chapt er.

Catalyst 6500: Conditionally Trusted IP Phone + PC: Advanced Model

The Cat alyst 6500 Condit ionally Trust ed I P Phone: Advanced m odel leverages t he dual- rat e
policing capabilit ies of t he PFC2/ PFC3. I n Exam ple 12- 59 , t he dual- rat e policing feat ure is
applied t o client - t o- server flows t o com plem ent t he Unt rust ed Server m odel.

Dual- rat e policing, in t his cont ext , allows for graduat ed m arkdown of I nt eract ive- Video ( from
PCs) , Transact ional Dat a, and Bulk Dat a. Specifically, in t his exam ple, I nt eract ive- Video is
m arked down t o AF42 if it is in excess of 300 kbps but less t han 500 kbps; if it is great er t han
500 kbps, it is m arked down t o Scavenger ( CS1) . Sim ilarly, Transact ional Dat a and Bulk Dat a
are m arked down t o AF22 and AF12 ( respect ively) if t hey are in excess of 3 Mbps but less t han 5
Mbps; if t hey are in excess of 5 Mbps, t hey are bot h m arked down t o Scavenger ( CS1) . All ot her
policers are consist ent wit h t he single- rat e policer m odel.

The Cat alyst 6500 PFC2/ PFC3 Condit ionally Trust ed Endpoint Dual- Rat e Policing: I P Phone + PC
Advanced m odel is illust rat ed in Figure 12- 25 .

Figu r e 1 2 - 2 5 . Ca t a lyst 6 5 0 0 PFC2 / PFC3 Con dit ion a lly Tr u st e d En dpoin t

D u a l- Ra t e Policin g: I P Ph on e + PC ( Adva n ce d M ode l) Ex a m ple

[View full size image]

N ot e
The discret e t raffic wat erm arks at which graduat ed m arkdown should occur are at t he
net work adm inist rat or's discret ion and vary am ong ent erprises and applicat ions.
Exam ple 12- 59 shows a configurat ion for a Cat alyst 6500 Cat OS Condit ionally Trust ed I P Phone
+ PC: Advanced m odel.

Ex a m ple 1 2 - 5 9 . Ca t a lyst 6 5 0 0 Ca t OS: Con dit ion a lly Tr u st e d I P Ph on e

+ PC: Adva n ce d M ode l Ex a m ple

CAT6500-PFC2-CATOS> (enable) set qos cos-dscp-map 0 8 16 24 32 56 48 56

! Modifies default CoS-DSCP mapping so that CoS 5 is mapped to DSCP EF
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map normal-rate 0,24,25:8
! Excess Data, Call-Signaling and MC-Data traffic is marked down to CS1
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map normal-rate 10:12
! Excess Bulk traffic is marked down from DSCP AF11 to AF12
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map excess-rate 10:8
! Violating Bulk traffic is marked down to DSCP CS1
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map normal-rate 18:20
! Excess Transactional Data traffic is marked down from AF21 to AF22
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map excess-rate 18:8
! Violating Transactional Data traffic is marked down to DSCP CS1
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map normal-rate 34:36
! Excess Interactive-Video traffic is marked down from AF41 to AF42
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map excess-rate 34:8
! Violating Interactive-Video traffic is marked down to DSCP CS1
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate VVLAN-VOICE
rate 128 burst 8 drop
! Defines the policer for IP Phone VoIP traffic
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate VVLAN-SIGNALING
rate 32 burst 8 policed-dscp
! Defines the policer for IP Phone Call-Signaling traffic
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate VVLAN-ANY
rate 32 burst 8 policed-dscp
! Defines the policer for any other traffic sourced from the VVLAN
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate PC-VIDEO
rate 300 policed-dscp erate 500 policed-dscp burst 8
! Defines the Dual-Rate policer for Interactive-Video
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate MISSION-CRITICAL
rate 5000 burst 8 policed-dscp
! Defines the policer for Mission-Critical Data
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate TRANSACTIONAL
rate 3000 policed-dscp erate 5000 policed-dscp burst 8
! Defines the Dual-Rate policer for Transactional Data
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate BULK
rate 3000 policed-dscp erate 5000 policed-dscp burst 8
! Defines the Dual-Rate policer for Bulk Data
CAT6500-PFC2-CATOS> (enable) set qos policer aggregate PC-DATA
rate 5000 burst 8 policed-dscp
! Defines the policer for all other PC Data traffic
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-ADVANCED dscp 46
 aggregate VVLAN-VOICE udp 10.1.110.0 0.0.0.255 any range 16384 32767
! Binds ACL to policer and marks in-profile VVLAN VoIP to DSCP EF
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-ADVANCED dscp 24
aggregate VVLAN-SIGNALING tcp 10.1.110.0 0.0.0.255 any range 2000 2002
! Binds ACL to policer marks in-profile VVLAN Call-Signaling to DSCP CS3
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-ADVANCED dscp 0
aggregate VVLAN-ANY 10.1.110.0 0.0.0.255
! Binds ACL to policer and marks all other VVLAN traffic to DSCP 0
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-ADVANCED dscp 34
aggregate PC-VIDEO udp any any range 16384 32767
! Binds ACL to Dual-Rate policer and marks in-profile PC Video to AF41
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-ADVANCED dscp 25
aggregate MISSION-CRITICAL tcp any any range 3200 3203
! Binds ACL to policer and marks in-profile SAP to DSCP 25
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-ADVANCED dscp 25
aggregate MISSION-CRITICAL tcp any any eq 3600
! Binds ACL to policer and marks in-profile SAP to DSCP 25
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-ADVANCED dscp 18
aggregate TRANSACTIONAL tcp any any eq 1352
! Binds ACL to Dual-Rate policer and marks in-profile Lotus to AF21
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-ADVANCED dscp 10
aggregate BULK tcp any any eq 143
! Binds ACL to Dual-Rate policer and marks in-profile IMAP to AF11
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-ADVANCED dscp 10
aggregate BULK tcp any any eq 220
! Binds ACL to Dual-Rate policer and marks in-profile IMAP to AF11
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos acl ip IPPHONE-PC-ADVANCED dscp 0
aggregate PC-DATA any
! Binds ACL to policer and marks other in-profile PC data to DSCP 0
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) commit qos acl IPPHONE-PC-ADVANCED
! Commits ACL to PFC memory
CAT6500-PFC2-CATOS> (enable) set port qos 3/1 trust-device ciscoipphone
! Conditional trust (for Cisco IP Phones only)
CAT6500-PFC2-CATOS> (enable) set qos acl map IPPHONE-PC-ADVANCED 3/1
! Attaches ACL to switch port
CAT6500-PFC2-CATOS> (enable)

Cat alyst 6500 Cat OS QoS verificat ion com m ands:

sh ow qos st a t u s

sh ow qos m a ps

sh ow por t qos

sh ow qos a cl

sh ow qos police r
 sh ow qos st a t ist ics

N ot e
As previously m ent ioned, on nonGigabit Et hernet line cards t hat use 2Q2T t ransm it
queuing and 1Q4T receive queuing, a hardware lim it at ion prevent s t he proper
funct ioning of port - based t rust ( which affect s t rust - cos, t rust - ipprec, and t rust - dscp) .
On such line cards, a workaround ACL can be used t o achieve t rust funct ionalit y. For
such an exam ple, see t he sect ion " Cat alyst 6500 Cat OS QoS Verificat ion Com m and:
show port qos " ( see Exam ple 12- 50 ) , earlier in t his chapt er.

Catalyst 6500: Queuing and Dropping

Alt hough t he Cat alyst 6500 PFC perform s classificat ion, m arking, m apping, and policing
funct ions, all queuing and dropping policies are adm inist ered by t he Cat alyst 6500 line cards.
This inevit ably leads t o per- line card hardware- specific capabilit ies and synt ax when it com es t o
configuring queuing and dropping.

As previously discussed in relat ion t o ot her plat form s t hat support ingress queuing, receive
queues are ext rem ely difficult t o congest , even in cont rolled lab environm ent s. This is especially
so if access- edge policies, as det ailed in t his chapt er, are used on all access- layer swit ches.

I ngress congest ion im plies t hat t he com bined ingress rat es of t raffic exceed t he swit ch's
processing capabilit y and, t hus, packet s would need t o be queued sim ply t o gain access t o t he
swit ching fabric. On newer plat form s, such as t he Cat alyst 6500 Supervisor 720, t his m eans t hat
a com bined ingress rat e of m ore t han 720 Gbps would have t o be sent t o t he swit ch, which is
ext rem ely unlikely.

To obviat e such an ext rem e event , t he Cat alyst 6500 schedules ingress t raffic t hrough t he
receive queues based on CoS values. I n t he default configurat ion, t he scheduler assigns all
t raffic wit h CoS 5 t o t he st rict - priorit y queue ( if present ) ; in t he absence of a st rict - priorit y
queue, t he scheduler assigns all t raffic t o t he st andard queues. All ot her t raffic is assigned t o t he
st andard queue( s) ( wit h higher CoS values being assigned preference over lower CoS values,
wherever support ed) . Addit ionally, if a port is configured t o t rust CoS, t he ingress scheduler
im plem ent s CoS value- based receive- queue drop t hresholds, t o avoid congest ion in received
t raffic. Thus, even if t he ext rem ely unlikely event of ingress congest ion occurs, t he default
set t ings for t he Cat alyst 6500 line card receive queues are m ore t han adequat e t o prot ect VoI P
and Net work- Cont rol t raffic.

Therefore, t he focus of t his sect ion is on Cat alyst 6500 egress/ t ransm it queuing design
recom m endat ions. At t he t im e of writ ing, t here are six m ain t ransm it queuing/ dropping opt ions
for Cat alyst 6500 line cards:

2 Q2 T I ndicat es t wo st andard queues, each wit h t wo configurable t ail- drop t hresholds.

1 P2 Q1 T I ndicat es one st rict - priorit y queue and t wo st andard queues, each wit h one
configurable WRED drop t hreshold. ( However, each st andard queue also has one
nonconfigurable t ail- drop t hreshold.)

1 P2 Q2 T I ndicat es one st rict - priorit y queue and t wo st andard queues, each wit h t wo
configurable WRED drop t hresholds.
 1 P3 Q1 T I ndicat es one st rict - priorit y queue and t hree st andard queues, each wit h one
configurable WRED drop t hreshold. ( However, each st andard queue also has one
nonconfigurable t ail- drop t hreshold.)

1 P3 Q8 T I ndicat es one st rict - priorit y queue and t hree st andard queues, each wit h eight
configurable WRED drop t hresholds. ( However, each st andard queue also has one
nonconfigurable t ail- drop t hreshold.)

1 P7 Q8 T I ndicat es one st rict - priorit y queue and seven st andard queues, each wit h eight
configurable WRED drop t hresholds. ( On 1p7q8t port s, each st andard queue also has one
nonconfigurable t ail- drop t hreshold.)

Alm ost all Cat alyst 6500 line cards support a st rict - priorit y queue, and, when support ed, t he
swit ch services t raffic in t he st rict - priorit y t ransm it queue before servicing t he st andard queues.
When t he swit ch is servicing a st andard queue, aft er t ransm it t ing a packet , it checks for t raffic in
t he st rict - priorit y queue. I f t he swit ch det ect s t raffic in t he st rict - priorit y queue, it suspends it s
service of t he st andard queue and com plet es service of all t raffic in t he st rict - priorit y queue
before ret urning t o t he st andard queue.

Addit ionally, Cat alyst 6500 line cards im plem ent CoS value- based t ransm it - queue drop
t hresholds t o avoid congest ion in t ransm it t ed t raffic. WRED t hresholds also can be defined on
cert ain line cards, where t he CoS value of t he packet ( not t he I P Precedence value, alt hough
t hey likely will m at ch) det erm ines t he WRED weight . WRED param et ers include a lower and
upper t hreshold: The low WRED t hreshold is t he queue level where ( assigned) t raffic begins t o
be dropped select ively, and t he high WRED t hreshold is t he queue level above which all
( assigned) t raffic is dropped. Furt herm ore, packet s in t he queue bet ween t he low and high
WRED t hresholds have an increasing chance of being dropped as t he queue fills.

The t ransm it queuing and dropping capabilit ies can be ret urned wit h t he following com m ands.

Cat OS:

sh ow por t ca pa bilit ie s

sh ow por t qos

sh ow qos in fo

Cisco I OS:

sh ow qu e u e in g in t e r fa ce

Table 12- 2 includes t he Cat alyst 6500 line cards t hat were available at t he t im e of t his writ ing,
along wit h t heir respect ive queuing and dropping st ruct ures.

Design recom m endat ions for each of t hese six m ain Cat alyst 6500 queuing st ruct ures follow.

Catalyst 6500: 2Q2T Queuing and Dropping

Line cards t hat support only 2Q2T queuing m odels have no provision for priorit y queuing.
Nonet heless, t uning t he weight ed round- robin ( WRR) weight s and t he queue sizes can help
offset t his lim it at ion.

For exam ple, if Q1 is t o service Scavenger/ Bulk Dat a ( CoS 1) and Best - Effort ( CoS 0) t raffic,
assigning 30 percent of t he buffer space t o t he first queue is adequat e; t he rem aining 70 percent
can be assigned t o Q2.

The WRR weight s can be set t o t he sam e rat io of 30: 70 for servicing Q1: Q2.

Because t he 2Q2T m odel support s configurable t ail- drop t hresholds, t hese can be t uned t o
provide an addit ional layer of QoS granularit y. For exam ple, t he first queue's first t hreshold can
be set at 40 percent , t o prevent Scavenger/ Bulk Dat a t raffic from dom inat ing Q1. Sim ilarly, t he
second queue's first t hreshold can be set t o 80 percent , t o always allow som e room in t he queue
for VoI P. The second t hreshold of each queue always should be set t o t he t ail of t he queue ( 100
percent ) .

Aft er t he queues and t hresholds have been defined as such, CoS 1 ( Scavenger/ Bulk Dat a) can
be assigned t o Q1T1; CoS 0 ( Best Effort ) can be assigned t o Q1T2; CoS 2 ( Net work-
Managem ent and Transact ional Dat a) , CoS 3 ( Call- Signaling and Mission- Crit ical Dat a) , CoS 4
( I nt eract ive- and St ream ing- Video) , and CoS 6 and 7 ( I nt ernet work and Net work Cont rol) can be
assigned t o Q21T; and CoS 5 ( VoI P) can be assigned t o Q2T2.

Figure 12- 26 illust rat es t hese 2Q2T queuing recom m endat ions.

Figu r e 1 2 - 2 6 . Ca t a lyst 6 5 0 0 2 Q2 T Qu e u in g M ode l

[View full size image]

Exam ple 12- 60 shows t he Cat alyst 6500 Cat OS configurat ions t o configure 2Q2T queuing
recom m endat ions.

Ex a m ple 1 2 - 6 0 . Ca t a lyst 6 5 0 0 Ca t OS: 2 Q2 T Qu e u in g Ex a m ple

CAT6500-PFC2-CATOS> (enable) set qos txq-ratio 2q2t 30 70

! Sets the buffer allocations to 30% for Q1 and 70% for Q2
CAT6500-PFC2-CATOS> (enable) set qos wrr 2q2t 30 70
! Sets the WRR weights for 30:70 (Q1:Q2) bandwidth servicing
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CatOS> (enable) set qos drop-threshold 2q2t tx queue 1 40 100
! Sets Q1T1 to 40% to limit Scavenger/Bulk from dominating Q1
CAT6500-PFC2-CATOS> (enable) set qos drop-threshold 2q2t tx queue 2 80 100
! Sets Q2T1 to 80% to always have room in Q2 for VoIP
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos map 2q2t tx 1 1 cos 1
! Assigns Scavenger/Bulk to Q1T1
CAT6500-PFC2-CATOS> (enable) set qos map 2q2t tx 1 2 cos 0
! Assigns Best Effort to Q1T2
CAT6500-PFC2-CATOS> (enable) set qos map 2q2t tx 2 1 cos 2,3,4,6,7
! Assigns CoS 2,3,4,6 and 7 to Q2T1
CAT6500-PFC2-CATOS> (enable) set qos map 2q2t tx 2 2 cos 5
! Assigns VoIP to Q2T2
CAT6500-PFC2-CATOS> (enable)

Cat alyst 6500 Cat OS QoS verificat ion com m ands:

sh ow qos in fo con fig 2 q2 t t x

sh ow qos in fo r u n t im e

sh ow qos st a t ist ics

Catalyst 6500 CatOS QoS Verification Command: show qos info config 2q2t tx

The Cat alyst 6500 Cat OS sh ow qos in fo con fig 2 q2 t t x verificat ion com m and displays t he
queuing and dropping param et ers for 2Q2T line cards.

I n Exam ple 12- 61 , CoS 1 is assigned t o Q1T1; CoS 0 is assigned t o Q1T2; CoS values 2, 3, 4,
6, and 7 are assigned t o Q2T1; and CoS 5 is assigned t o Q2T2. The first t hresholds are set t o 40
percent and 80 percent of t heir respect ive queues, and t he second t hresholds are set t o t he t ail
of t he queue. The size rat io has been allocat ed 30 percent for Q1 and 70 percent for Q2, and t he
WRR weight s are set t o 30: 70 t o service Q1 and Q2, respect ively.

Ex a m ple 1 2 - 6 1 . sh ow qos in fo con fig 2 q2 t t x Verificat ion for a Cat alyst

6500- Cat OS Swit ch

CAT6500-PFC2-CATOS> (enable) show qos info config 2q2t tx

QoS setting in NVRAM for 2q2t transmit:
QoS is enabled
Queue and Threshold Mapping for 2q2t (tx):
Queue Threshold CoS
----- --------- ---------------
1 1 1
1 2 0
2 1 2 3 4 6 7
2 2 5
Tx drop thresholds:
Queue # Thresholds - percentage
------- -------------------------------------
1 40% 100%
2 80% 100%
Tx WRED thresholds:
WRED feature is not supported for this port type.
Tx queue size ratio:
Queue # Sizes - percentage
------- -------------------------------------
1 30%
2 70%
Tx WRR Configuration of ports with 2q2t:
Queue # Ratios
------- -------------------------------------
1 30
2 70
CAT6500-PFC2-CATOS> (enable)

Catalyst 6500 CatOS QoS Verification Command: show qos info runtime

The Cat alyst 6500 Cat OS sh ow qos in fo r u n t im e verificat ion com m and report s sim ilar
inform at ion as t he sh ow qos in fo config com m and, but it displays t he runt im e inform at ion
( com m it t ed t o t he PFC and line card) inst ead of only t he configured inform at ion.

I n Exam ple 12- 62 , CoS 1 is assigned t o Q1T1; CoS 0 is assigned t o Q1T2; CoS values 2, 3, 4,
6, and 7 are assigned t o Q2T1; and CoS 5 is assigned t o Q2T2. The first t hresholds are set t o 40
percent and 80 percent of t heir respect ive queues, and t he second t hresholds are set t o t he t ail
of t he queue. The size rat io has been allocat ed 30 percent for Q1 and 70 percent for Q2, and t he
WRR weight s are set t o 30: 70 t o service Q1 and Q2, respect ively.

Ex a m ple 1 2 - 6 2 . sh ow qos in fo r u n t im e Verificat ion for a Cat alyst 6500-

Cat OS Swit ch

CAT6500-PFC3-CATOS> (enable) show qos info runtime 3/1

Run time setting of QoS:
QoS is enabled
Policy Source of port 3/1: Local
Tx port type of port 3/1 : 2q2t
Rx port type of port 3/1 : 1q4t
Interface type: port-based
ACL attached:
The qos trust type is set to untrusted.
Default CoS = 0
Queue and Threshold Mapping for 2q2t (tx):
Queue Threshold CoS
----- --------- ---------------
1 1 1
1 2 0
2 1 2 3 4 6 7
2 2 5
Queue and Threshold Mapping for 1q4t (rx):
All packets are mapped to a single queue.
Rx drop thresholds:
Rx drop thresholds are disabled.
Tx drop thresholds:
Queue # Thresholds - percentage (* abs values)
------- -------------------------------------
1 40% (6144 bytes) 100% (15360 bytes)
2 80% (28672 bytes) 100% (35840 bytes)
Rx WRED thresholds:
Rx WRED feature is not supported for this port type.
Tx WRED thresholds:
WRED feature is not supported for this port type.
Tx queue size ratio:
Queue # Sizes - percentage (* abs values)
------- -------------------------------------
1 30% (17408 bytes)
2 70% (37888 bytes)
Rx queue size ratio:
Rx queue size-ratio feature is not supported for this port type.
Tx WRR Configuration of ports with speed 10Mbps:
Queue # Ratios (* abs values)
------- -------------------------------------
1 30 (7648 bytes)
2 70 (17840 bytes)
(*) Runtime information may differ from user configured setting due to hardware
granularity.
CAT6500-PFC3-CATOS> (enable)

Exam ple 12- 63 shows t he Cat alyst 6500 I OS configurat ions t o configure 2Q2T queuing
recom m endat ions.

Ex a m ple 1 2 - 6 3 . Ca t a lyst 6 5 0 0 I OS: 2 Q2 T Qu e u in g Ex a m ple

CAT6500-PFC3-IOS(config)# interface range FastEthernet6/1 - 48

CAT6500-PFC3-IOS(config-if)# wrr-queue queue-limit 30 70
! Sets the buffer allocations to 30% for Q1 and 70% for Q2
CAT6500-PFC3-IOS(config-if)# wrr-queue bandwidth 30 70
! Sets the WRR weights for 30:70 (Q1:Q2) bandwidth servicing
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)# wrr-queue threshold 1 40 100
! Sets Q1T1 to 40% to limit Scavenger/Bulk from dominating Q1
CAT6500-PFC3-IOS(config-if)# wrr-queue threshold 2 80 100
! Sets Q2T1 to 80% to always have room in Q2 for VoIP
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 1 1 1
! Assigns Scavenger/Bulk to Q1T1
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 1 2 0
! Assigns Best Effort to Q1T2
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 2 1 2 3 4 6 7
! Assigns CoS 2,3,4,6 and 7 to Q2T1
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 2 2 5
! Assigns VoIP to Q2T2
CAT6500-PFC3-IOS(config-if)#end
CAT6500-PFC3-IOS#
Cat alyst 6500 MLS QoS verificat ion com m and:

sh ow qu e u e in g in t e r fa ce

Catalyst 6500 IOS QoS Verification Command: show queueing interface

The Cat alyst 6500 I OS sh ow qu e u e in g in t e r fa ce verificat ion com m and displays t he queuing
param et ers for a given int erface ( according t o t he line card's capabilit ies) .

I n Exam ple 12- 64 , t he line card has 2Q2T t ransm it queuing. The WRR scheduling weight s are
set t o 30: 70 t o service Q1 and Q2, respect ively. The t ransm it queue size rat ios have been
allocat ed 30 percent for Q1 and 70 percent for Q2. The first queue's t ail- drop t hresholds are set
t o 40 percent and 100 percent , while t he second queue's t ail- drop t hresholds are set t o 80
percent and 100 percent . CoS 1 is assigned t o Q1T1; CoS 0 is assigned t o Q1T2; CoS values 2,
3, 4, 6, and 7 are assigned t o Q2T1; and CoS 5 is assigned t o Q2T2.

Ex a m ple 1 2 - 6 4 . sh ow qu e u e in g in t e r fa ce Verificat ion for a Cat alyst 6500

I OS Swit ch

CAT6500-PFC3-IOS#show queueing interface FastEthernet6/1

Interface FastEthernet6/1 queueing strategy: Weighted Round-Robin
Port QoS is enabled
Port is untrusted
Extend trust state: not trusted [COS = 0]
Default COS is 0
Queueing Mode In Tx direction: mode-cos
Transmit queues [type = 2q2t]:
Queue Id Scheduling Num of thresholds
-----------------------------------------
1 WRR low 2
2 WRR high 2
WRR bandwidth ratios: 30[queue 1] 70[queue 2]
queue-limit ratios: 30[queue 1] 70[queue 2]
queue tail-drop-thresholds
--------------------------
1 40[1] 100[2]
2 80[1] 100[2]
queue thresh cos-map
---------------------------------------
1 1 1
1 2 0
2 1 2 3 4 6 7
2 2 5
<output truncated>
CAT6500-PFC3-IOS#

Catalyst 6500: 1P2Q1T Queuing and Dropping

The 1P2Q1T queuing m odel builds on t he previous 2Q2T m odel, bringing wit h it t he advant ages
of st rict - priorit y queuing ( for VoI P) and a t unable WRED ( not t ail drop) t hreshold per queue.

The t erm 1P2Q1T is a bit of a m isnom er in t he Cat OS version of t his queuing st ruct ure because,
in Cat OS, t here are act ually t wo t hresholds per queue: t he t unable WRED t hreshold and t he
nonconfigurable t ail- of- t he- queue ( 100 percent ) t ail- drop t hreshold.

Under such a m odel, buffer space can be allocat ed as follows: 30 percent for Scavenger/ Bulk
Dat a plus Best - Effort queue ( Q1) , 40 percent for Q2, and 30 percent for t he PQ ( Q3) .

The WRR weight s for Q1 and Q2 ( for dividing t he rem aining bandwidt h, aft er t he priorit y queue
has been serviced fully) can be set t o 30: 70, respect ively, for Q1: Q2.

Under t he 1P2Q1T m odel, each queue's WRED t hreshold is defined wit h a lower and upper lim it .
For exam ple, t he WRED t hreshold 40: 80 indicat es t hat packet s assigned t o t his WRED t hreshold
will begin being random ly dropped when t he queue fills t o 40 percent and t hat t hese packet s will
be t ail- dropped if t he queue fills beyond 80 percent .

Furt herm ore, in Cat OS wit hin t he 1P2Q1T queuing st ruct ure, each CoS value can be assigned t o
a queue and a WRED t hreshold or j ust t o a queue. When assigned t o a queue ( only) , t he CoS
value will be lim it ed only by t he t ail of t he queue. ( I n ot her words, it is assigned t o t he queue
wit h a t ail drop t hreshold of 100 percent .)

Thus ( in Cat OS) , t he t unable WRED t hreshold for Q1 can be set t o 40: 80, m eaning t hat
Scavenger/ Bulk Dat a will be WRED- dropped if Q1 fills t o 40 percent and will be t ail- dropped if
Q1 fills past 80 percent of capacit y. This prevent s Scavenger/ Bulk Dat a from drowning out Best -
Effort t raffic in Q1. The WRED t hreshold for Q2 can be set t o 70: 80 t o provide congest ion
avoidance for all applicat ions assigned t o it and t o ensure t hat t here will always be room in t he
queue t o service Net work and I nt ernet work Cont rol t raffic.

Therefore, when t he queues and t hresholds have been defined as such, CoS 1 ( Scavenger/ Bulk
Dat a) can be assigned t o Q1T1; CoS 0 ( Best - Effort ) can be assigned t o Q1 only ( t ail) ; CoS 2
( Net work- Managem ent and Transact ional Dat a) , CoS 3 ( Call- Signaling and Mission- Crit ical Dat a)
and CoS 4 ( I nt eract ive- and St ream ing- Video) can be assigned t o Q2T1; CoS 6 and 7
( I nt ernet work and Net work Cont rol) can be assigned t o Q2 only ( t ail) ; and CoS 5 ( VoI P) can be
assigned t o Q3 ( t he PQ) .

Figure 12- 27 illust rat es t hese 1P2Q1T queuing recom m endat ions.

Figu r e 1 2 - 2 7 . Ca t a lyst 6 5 0 0 1 P2 Q1 T Qu e u in g M ode l ( Ca t OS Su ppor t s

1 P2 Q2 T)

[View full size image]

Exam ple 12- 65 shows t he Cat alyst 6500 Cat OS configurat ions t o configure 1P2Q1T queuing
recom m endat ions.

Ex a m ple 1 2 - 6 5 . Ca t a lyst 6 5 0 0 Ca t OS: 1 P2 Q1 T ( Te ch n ica lly, 1 P2 Q2 T)

Qu e u in g Ex a m ple

CAT6500-PFC2-CATOS> (enable) set qos txq-ratio 1p2q1t 30 40 30

! Sets the buffer allocations to 30% for Q1, 40% for Q2, 30% for Q3 (PQ)
CAT6500-PFC2-CATOS> (enable) set qos wrr 1p2q1t 30 70
! Sets the WRR weights for 30:70 (Q1:Q2) bandwidth servicing
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos wred 1p2q1t tx queue 1 40:80
! Sets Q1 WRED Threshold to 40:80 to limit Scavenger/Bulk from dominating Q1
CAT6500-PFC2-CATOS> (enable) set qos wred 1p2q1t tx queue 2 70:80
! Sets Q2 WRED Threshold to 70:80 to force room for Network Control traffic
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos map 1p2q1t tx 1 1 cos 1
! Assigns Scavenger/Bulk to Q1 WRED Threshold
CAT6500-PFC2-CATOS> (enable) set qos map 1p2q1t tx 1 cos 0
! Assigns Best Effort to Q1 tail (100%) threshold
CAT6500-PFC2-CATOS> (enable) set qos map 1p2q1t tx 2 1 cos 2,3,4
! Assigns CoS 2,3,4 to Q2 WRED Threshold
CAT6500-PFC2-CATOS> (enable) set qos map 1p2q1t tx 2 cos 6,7
! Assigns Network/Internetwork Control to Q2 tail (100%) threshold
CAT6500-PFC2-CATOS> (enable) set qos map 1p2q1t tx 3 cos 5
! Assigns VoIP to PQ (Q3)
CAT6500-PFC2-CATOS> (enable)

Cat alyst 6500 Cat OS QoS verificat ion com m ands:

 sh ow qos in fo con fig 1 p2 q1 t t x

sh ow qos in fo r u n t im e

sh ow qos st a t ist ics

N ot e
The Cat alyst 6500 Cat OS sh ow qos in fo verificat ion com m ands are reasonably sim ilar
for each queuing st ruct ure and, as such, are not det ailed for each queuing m odel
exam ple.

I n Cisco I OS, for any 1PxQyT queuing st ruct ure, set t ing t he size of t he priorit y queue is not
support ed. The only except ion t o t his rule is t he 1P2Q2T st ruct ure, in which t he priorit y queue
( Q3) indirect ly is set t o equal Q2's size. Therefore, in all exam ples of Cat alyst 6500 I OS queuing
st ruct ure configurat ions t hat follow t hat followexcept for t he 1P2Q2T exam pleonly t he sizes of
t he st andard queues are being set .

Furt herm ore, specific t o t he 1P2Q1T queuing st ruct ure, CoS values cannot be m apped t o t he t ail
of t he queue, as in Cat OS. CoS values can be m apped only t o t he single WRED t hreshold for
each queue. Therefore, t he 1P2Q1T queuing and dropping recom m endat ion requires som e slight
alt erat ions for Cisco I OS. These include changing Q1T1's WRED t hreshold t o 80: 100 and,
likewise, changing Q2T1's WRED t hreshold t o 80: 100.

The synt ax logic for set t ing WRED t hresholds in Cisco I OS is different t han in Cat OS. I n Cat OS,
m inim um and m axim um WRED t hresholds are set on t he sam e line; in Cisco I OS, m inim um and
m axim um WRED t hresholds are set on different lines.

Aft er t hese WRED t hresholds have been alt ered, CoS 1 ( Scavenger/ Bulk Dat a) and CoS 0 ( Best -
Effort ) can be assigned t o Q1T1; CoS 2 ( Net work- Managem ent and Transact ional Dat a) , CoS 3
( Call- Signaling and Mission- Crit ical Dat a) , CoS 4 ( I nt eract ive- and St ream ing- Video) , and CoS 6
and 7 ( I nt ernet work and Net work Cont rol) can be assigned t o Q2T1; and CoS 5 ( VoI P) can be
assigned t o Q3 ( t he PQ) .

Exam ple 12- 66 shows t he Cat alyst 6500 I OS configurat ions t o configure 1P2Q1T queuing
recom m endat ions.

Ex a m ple 1 2 - 6 6 . Ca t a lyst 6 5 0 0 I OS: 1 P2 Q1 T Qu e u in g Ex a m ple

CAT6500-PFC3-IOS(config)#interface TenGigabitEthernet1/1
CAT6500-PFC3-IOS(config-if)# wrr-queue queue-limit 30 40
! Sets the buffer allocations to 30% for Q1 and 40% for Q2
CAT6500-PFC3-IOS(config-if)# wrr-queue bandwidth 30 70
! Sets the WRR weights for 30:70 (Q1:Q2) bandwidth servicing
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect min-threshold 1 80
! Sets Min WRED Threshold for Q1T1 to 80%
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect max-threshold 1 100
! Sets Max WRED Threshold for Q1T1 to 100%
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect min-threshold 2 80
! Sets Min WRED Threshold for Q2T1 to 80%
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect max-threshold 2 100
! Sets Max WRED Threshold for Q2T1 to 100%
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 1 1 1 0
! Assigns Scavenger/Bulk and Best Effort to Q1 WRED Threshold 1
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 2 1 2 3 4 6 7
! Assigns CoS 2,3,4,6 and 7 to Q2 WRED Threshold 1
CAT6500-PFC3-IOS(config-if)# priority-queue cos-map 1 5
! Assigns VoIP to PQ (Q3)
CAT6500-PFC3-IOS(config-if)#end
CAT6500-PFC3-IOS(config-if)#

Cat alyst 6500 MLS QoS verificat ion com m and:

sh ow qu e u e in g in t e r fa ce

Catalyst 6500: 1P2Q2T Queuing and Dropping

The 1P2Q2T queuing m odel is essent ially ident ical t o t he 1P2Q1T m odel, except t hat it support s
t wo configurable WRED t hresholds per queue.

Under a 1P2Q2T m odel, buffer space can be allocat ed as follows: 40 percent for Q1 ( t he
Scavenger/ Bulk Dat a + Best - Effort queue) , 30 percent for Q2 ( t he preferent ial queue) , and 30
percent for t he Q3 ( t he priorit y queue) .

The WRR weight s for Q1 and Q2 ( for dividing t he rem aining bandwidt h, aft er t he priorit y queue
has been serviced fully) rem ain at 30: 70, respect ively, for Q1: Q2.

Under t he 1P2Q2T m odel, each WRED t hreshold is defined wit h a lower and upper lim it .
Therefore, t he first WRED t hreshold for Q1 can be set t o 40: 80, so t hat Scavenger/ Bulk Dat a
t raffic can be WRED- dropped if Q1 hit s 40 percent and can be t ail- dropped if Q1 exceeds 80
percent of it s capacit y ( t his prevent s Scavenger/ Bulk Dat a from drowning out Best - Effort t raffic
in Q1) . The second WRED t hreshold for Q1 can be set t o 80: 100 t o provide congest ion avoidance
for Best - Effort t raffic.

Sim ilarly, t he first WRED t hreshold of Q2 can be set t o 70: 80, and t he second can be set t o
80: 100. I n t his m anner, congest ion avoidance will be provided for all t raffic t ypes in Q2, and
t here will always be room in t he queue t o service Net work and I nt ernet work Cont rol t raffic.

Therefore, aft er t he queues have been defined as m ent ioned previously, CoS 1 ( Scavenger/ Bulk
Dat a) can be assigned t o Q1T1; CoS 0 ( Best - Effort ) can be assigned t o Q1T2; CoS 2 ( Net work-
Managem ent and Transact ional Dat a) , CoS 3 ( Call- Signaling and Mission- Crit ical Dat a) , and CoS
4 ( I nt eract ive- and St ream ing- Video) can be assigned t o Q2T1; CoS 6 and 7 ( I nt ernet work and
Net work Cont rol) can be assigned t o Q2T2; and CoS 5 ( VoI P) can be assigned t o Q3T1 ( t he PQ) .

Figure 12- 28 illust rat es t hese 1P2Q2T queuing recom m endat ions.

Figu r e 1 2 - 2 8 . Ca t a lyst 6 5 0 0 1 P2 Q2 T Qu e u in g M ode l

[View full size image]

Exam ple 12- 67 shows t he Cat alyst 6500 Cat OS configurat ions t o configure 1P2Q1T queuing
recom m endat ions.

Ex a m ple 1 2 - 6 7 . Ca t a lyst 6 5 0 0 Ca t OS: 1 P2 Q2 T Qu e u in g Ex a m ple

CAT6500-PFC2-CATOS> (enable) set qos txq-ratio 1p2q2t 40 30 30

! Sets the buffer allocations to 40% for Q1, 30% for Q2, 30% for Q3 (PQ)
CAT6500-PFC2-CATOS> (enable) set qos wrr 1p2q2t 30 70
! Sets the WRR weights for 30:70 (Q1:Q2) bandwidth servicing
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos wred 1p2q2t tx queue 1 40:80 80:100
! Sets Q1 WRED T1 to 40:80 to limit Scavenger/Bulk from dominating Q1
! Sets Q1 WRED T2 to 80:100 to provide congestion-avoidance for Best Effort
CAT6500-PFC2-CATOS> (enable) set qos wred 1p2q2t tx queue 2 70:80 80:100
! Sets Q2 WRED T1 to 70:80 to provide congestion-avoidance
! Sets Q2 WRED T2 to 80:100 to force room for Network Control traffic
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos map 1p2q2t tx 1 1 cos 1
! Assigns Scavenger/Bulk to Q1 WRED Threshold 1
CAT6500-PFC2-CATOS> (enable) set qos map 1p2q2t tx 1 2 cos 0
! Assigns Best Effort to Q1 WRED Threshold 2
CAT6500-PFC2-CATOS> (enable) set qos map 1p2q2t tx 2 1 cos 2,3,4
! Assigns CoS 2,3,4 to Q2 WRED Threshold 1
CAT6500-PFC2-CATOS> (enable) set qos map 1p2q2t tx 2 2 cos 6,7
! Assigns Network/Internetwork Control to Q2 WRED Threshold 2
CAT6500-PFC2-CATOS> (enable) set qos map 1p2q2t tx 3 1 cos 5
! Assigns VoIP to PQ
CAT6500-PFC2-CATOS> (enable)

Cat alyst 6500 Cat OS QoS verificat ion com m ands:

 sh ow qos in fo con fig 1 p2 q2 t t x

sh ow qos in fo r u n t im e

sh ow qos st a t ist ics

Exam ple 12- 68 shows t he com pat ible Cat alyst 6500 I OS configurat ions t o configure 1P2Q1T
queuing recom m endat ions. Not ice t hat t he buffer allocat ion for t he PQ ( Q3) is not configurable
but , by default ( for t he 1P2Q2T queuing st ruct ure only) , is set t o equal t he size defined for Q2.
Therefore, Q1 is set t o 40 percent and Q2 is set t o 30 percent , which indirect ly set s Q3 t o m at ch
at 30 percent .

Exam ple 12- 68 shows t he Cat alyst 6500 I OS configurat ions t o configure 1P2Q2T queuing
recom m endat ions.

Ex a m ple 1 2 - 6 8 . Ca t a lyst 6 5 0 0 I OS: 1 P2 Q2 T Qu e u in g Ex a m ple

CAT6500-PFC3-IOS(config)#interface range GigabitEthernet4/1 - 8

CAT6500-PFC3(config-if-range)# wrr-queue queue-limit 40 30
! Sets the buffer allocations to 40% for Q1 and 30% for Q2
! Indirectly sets PQ (Q3) size to equal Q2 (which is set to 30%)
CAT6500-PFC3(config-if-range)# wrr-queue bandwidth 30 70
! Sets the WRR weights for 30:70 (Q1:Q2) bandwidth servicing
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# wrr-queue random-detect min-threshold 1 40 80
! Sets Min WRED Thresholds for Q1T1 and Q1T2 to 40 and 80, respectively
CAT6500-PFC3(config-if-range)# wrr-queue random-detect max-threshold 1 80 100
! Sets Max WRED Thresholds for Q1T1 and Q1T2 to 80 and 100, respectively
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# wrr-queue random-detect min-threshold 2 70 80
! Sets Min WRED Thresholds for Q2T1 and Q2T2 to 70 and 80, respectively
CAT6500-PFC3(config-if-range)# wrr-queue random-detect max-threshold 2 80 100
! Sets Max WRED Thresholds for Q2T1 and Q2T2 to 80 and 100, respectively
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# wrr-queue cos-map 1 1 1
! Assigns Scavenger/Bulk to Q1 WRED Threshold 1
CAT6500-PFC3(config-if-range)# wrr-queue cos-map 1 2 0
! Assigns Best Effort to Q1 WRED Threshold 2
CAT6500-PFC3(config-if-range)# wrr-queue cos-map 2 1 2 3 4
! Assigns CoS 2,3,4 to Q2 WRED Threshold 1
CAT6500-PFC3(config-if-range)# wrr-queue cos-map 2 2 6 7
! Assigns Network/Internetwork Control to Q2 WRED Threshold 2
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# priority-queue cos-map 1 5
! Assigns VoIP to PQ
CAT6500-PFC3(config-if-range)#end
CAT6500-PFC3-IOS#

Cat alyst 6500 MLS QoS verificat ion com m and:

sh ow qu e u e in g in t e r fa ce
Catalyst 6500: 1P3Q1T Queuing and Dropping

The 1P3Q1T queuing st ruct ure is ident ical t o t he 1P2Q1T st ruct ure, except t hat an addit ional
st andard queue has been added t o it and t hat it does not support t uning t he t ransm it size rat ios.
Under t his m odel, Q4 is t he st rict - priorit y queue.

The WRR weight s for t he st andard queues ( Q1, Q2, Q3) , for dividing t he rem aining bandwidt h
aft er t he priorit y queue has been serviced serviced, can be set t o 5: 25: 70, respect ively, for
Q1: Q2: Q3.

I n Cat OS, wit hin t he 1P3T1T queuing st ruct ure, each CoS value can be assigned t o a queue and
a WRED t hreshold or j ust t o a queue. When assigned t o a queue ( only) , t he CoS value is lim it ed
only by t he t ail of t he queue ( in ot her words, it is assigned t o t he queue wit h a t ail drop
t hreshold of 100 percent ) . Therefore, Cat OS essent ially support s 1P3Q2T for t his t ype of line
card.

Thus, t he t unable WRED t hreshold for Q1 can be set t o 80: 100 t o provide congest ion avoidance
for Scavenger/ Bulk Dat a t raffic. The WRED t hreshold for Q2 sim ilarly can be set t o 80: 100 t o
provide congest ion avoidance on all Best - Effort flows. The WRED t hreshold for Q3 can be set t o
70: 80, t o provide congest ion avoidance for all applicat ions assigned t o it and t o ensure t hat
t here will always be room in t he Q3 t o service Net work and I nt ernet work Cont rol t raffic.

Therefore, when t he queues and t hresholds have been defined as such, CoS 1 ( Scavenger/ Bulk
Dat a) can be assigned t o Q1T1; CoS 0 ( Best - Effort ) can be assigned t o Q2T1; CoS 2 ( Net work-
Managem ent and Transact ional Dat a) , CoS 3 ( Call- Signaling and Mission- Crit ical Dat a) , and CoS
4 ( I nt eract ive- and St ream ing- Video) can be assigned t o Q3T1; CoS 6 and 7 ( I nt ernet work and
Net work Cont rol) can be assigned t o Q3 ( t ail) ; and CoS 5 ( VoI P) can be assigned t o Q4 ( t he PQ) .

Figure 12- 29 illust rat es t hese 1P3Q1T queuing recom m endat ions.

Figu r e 1 2 - 2 9 . Ca t a lyst 6 5 0 0 1 P3 Q1 T Qu e u in g M ode l ( Ca t OS Su ppor t s

1 P3 Q2 T)

[View full size image]

Exam ple 12- 69 shows t he Cat alyst 6500 Cat OS configurat ions t o configure 1P3Q1T queuing
recom m endat ions.

Ex a m ple 1 2 - 6 9 . Ca t a lyst 6 5 0 0 Ca t OS: 1 P3 Q1 T ( Te ch n ica lly, 1 P3 Q2 T)

Qu e u in g Ex a m ple

CAT6500-PFC2-CATOS> (enable) set qos wrr 1p3q1t 5 25 70

! Sets the WRR weights for 5:25:70 (Q1:Q2:Q3) bandwidth servicing
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos wred 1p3q1t tx queue 1 80:100
! Sets Q1 WRED T1 to 80:100 to provide congestion-avoidance for Scavenger
CAT6500-PFC2-CATOS> (enable) set qos wred 1p3q1t tx queue 2 80:100
! Sets Q2 WRED T1 to 80:100 to provide congestion-avoidance for Best Effort
CAT6500-PFC2-CATOS> (enable) set qos wred 1p3q1t tx queue 3 70:80
! Sets Q3 WRED T1 to 70:80 to provide congestion-avoidance for CoS 2,3,4
! and to force room (via tail-drop) for Network Control traffic
CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) set qos map 1p3q1t tx 1 1 cos 1
! Assigns Scavenger/Bulk to Q1 WRED Threshold 1 (80:100)
CAT6500-PFC2-CATOS> (enable) set qos map 1p3q1t tx 2 1 cos 0
! Assigns Best Effort to Q2 WRED Threshold 1 (80:100)
CAT6500-PFC2-CATOS> (enable) set qos map 1p3q1t tx 3 1 cos 2,3,4
! Assigns CoS 2,3,4 to Q3 WRED Threshold 1 (70:80)
CAT6500-PFC2-CATOS> (enable) set qos map 1p3q1t tx 3 cos 6,7
! Assigns Network/Internetwork Control to Q3 Tail (100%)
CAT6500-PFC2-CATOS> (enable) set qos map 1p3q1t tx 4 cos 5
! Assigns VoIP to PQ (Q4)
CAT6500-PFC2-CATOS> (enable)

Cat alyst 6500 Cat OS QoS verificat ion com m ands:

sh ow qos in fo con fig 1 p3 q1 t t x

sh ow qos in fo r u n t im e

sh ow qos st a t ist ics

I n Cisco I OS, t he 1P3Q1T, 1P3Q8T, and 1P7Q8T queuing st ruct ures can be configured t o use t ail
drop or WRED. By default , WRED is disabled. Therefore, it is good pract ice t o always explicit ly
enable WRED on a queue before set t ing WRED t hresholds for t hese queuing st ruct ures.

Addit ionally, in Cisco I OS, t he 1P3Q1T queuing st ruct ure does not support m apping CoS values
t o t he t ail of t he queue ( only t o t he single WRED t hreshold) . Therefore, t he queuing
recom m endat ion requires slight alt erat ions for Cisco I OS: changing all t hree WRED t hresholds t o
80: 100 and m apping CoS values 2, 3, 4, 6, and 7 t o Q3T1.

Exam ple 12- 70 shows t he Cat alyst 6500 I OS configurat ions t o configure 1P3Q1T queuing
recom m endat ions.

Ex a m ple 1 2 - 7 0 . Ca t a lyst 6 5 0 0 I OS: 1 P3 Q1 T Qu e u in g Ex a m ple

CAT6500-PFC3-IOS(config)# interface range FastEthernet3/1 - 48
CAT6500-PFC3-IOS(config-if)# wrr-queue bandwidth 5 25 70
! Sets the WRR weights for 5:25:70 (Q1:Q2:Q3) bandwidth servicing
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 1
! Enables WRED on Q1
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 2
! Enables WRED on Q2
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 3
! Enables WRED on Q3
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect min-threshold 1 80
! Sets Min WRED Threshold for Q1T1 to 80%
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect max-threshold 1 100
! Sets Max WRED Threshold for Q1T1 to 100%
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect min-threshold 2 80
! Sets Min WRED Threshold for Q2T1 to 80%
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect max-threshold 2 100
! Sets Max WRED Threshold for Q2T1 to 100%
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect min-threshold 3 80
! Sets Min WRED Threshold for Q3T1 to 80%
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect max-threshold 3 100
! Sets Max WRED Threshold for Q3T1 to 100%
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 1 1 1
! Assigns Scavenger/Bulk to Q1 WRED Threshold 1 (80:100)
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 2 1 0
! Assigns Best Effort to Q2 WRED Threshold 1 (80:100)
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 3 1 2 3 4 6 7
! Assigns CoS 2,3,4,6 and 7 to Q3 WRED Threshold 1 (80:100)
CAT6500-PFC3-IOS(config-if)# priority-queue cos-map 1 5
! Assigns VoIP to PQ (Q4)
CAT6500-PFC3-IOS(config-if)#end
CAT6500-PFC3-IOS#

Cat alyst 6500 MLS QoS verificat ion com m and:

sh ow qu e u e in g in t e r fa ce

Catalyst 6500: 1P3Q8T Queuing and Dropping

The 1P3Q8T queuing st ruct ure is ident ical t o t he 1P3Q1T st ruct ure, except it has eight t unable
WRED t hresholds per queue ( inst ead of one) and it also support s t uning t he t ransm it size rat ios.
Under t his m odel, Q4 is t he st rict - priorit y queue.

Under a 1P3Q8T m odel, buffer space can be allocat ed as follows: 5 percent for t he
Scavenger/ Bulk Dat a queue ( Q1) , 25 percent for t he Best - Effort queue ( Q2) , 40 percent for t he
preferent ial queue ( Q3) , and 30 percent for t he st rict - priorit y queue ( Q4) .
The WRR weight s for t he st andard queues ( Q1, Q2, Q3) , for dividing t he rem aining bandwidt h
aft er t he priorit y queue has been serviced fully, can be set t o 5: 25: 70, respect ively, for
Q1: Q2: Q3.

The t unable WRED t hreshold for Q1 can be set t o 80: 100 t o provide congest ion avoidance t o
Scavenger/ Bulk Dat a t raffic. The WRED t hreshold for Q2 sim ilarly can be set t o 80: 100 t o
provide congest ion avoidance on all Best - Effort flows.

The 1P3Q8T queuing st ruct ure's support for up t o eight WRED t hresholds per queue allows for
addit ional QoS granularit y for t he applicat ions sharing Q3. Because only five discret e CoS values
are sharing t his queue, only five of eight t hresholds need t o be defined for subqueue QoS. For
exam ple, Q3T1 could be set t o 50: 60, Q3T2 could be set t o 60: 70, Q3T3 could be set t o 70: 80,
Q3T4 could be set t o 80: 90, and Q3T5 could be set t o 90: 100.

Therefore, when t he queues and t hresholds have been defined as such, CoS 1 ( Scavenger/ Bulk
Dat a) can be assigned t o Q1T1; CoS 0 ( Best - Effort ) can be assigned t o Q2T1; CoS 4
( I nt eract ive- and St ream ing- Video) can be assigned t o Q3T1; CoS 2 ( Net work- Managem ent and
Transact ional Dat a) can be assigned t o Q3T2; CoS 3 ( Call- Signaling and Mission- Crit ical Dat a)
can be assigned t o Q3T3; CoS 6 ( I nt ernet work Cont rol) can be assigned t o Q3T4; CoS 7
( I nt ernet work and Net work Cont rol) can be assigned t o Q3T5; and CoS 5 ( VoI P) can be assigned
t o Q4 ( t he PQ) .

Figure 12- 30 illust rat es t hese 1P3Q8T queuing recom m endat ions.

Figu r e 1 2 - 3 0 . Ca t a lyst 6 5 0 0 1 P3 Q8 T Qu e u in g M ode l

[View full size image]

Exam ple 12- 71 shows t he Cat alyst 6500 ( PFC3) Cat OS configurat ions t o configure 1P3Q8T
queuing recom m endat ions.

Ex a m ple 1 2 - 7 1 . Ca t a lyst 6 5 0 0 ( PFC3 ) Ca t OS: 1 P3 Q8 T Qu e u in g

Ex a m ple
CAT6500-PFC3-CATOS> (enable) set qos txq-ratio 1p3q8t 5 25 40 30
! Allocates 5% for Q1, 25% for Q2, 40% for Q3 and 30% for Q4 (PQ)
CAT6500-PFC3-CATOS> (enable) set qos wrr 1p3q8t 5 25 70
! Sets the WRR weights for 5:25:70 (Q1:Q2:Q3) bandwidth servicing
CAT6500-PFC3-CATOS> (enable)
CAT6500-PFC3-CATOS> (enable) set qos wred 1p3q8t tx queue 1 80:100 100:100
100:100 100:100 100:100 100:100 100:100 100:100
! Sets Q1 WRED T1 to 80:100 and all other Q1 WRED Thresholds to 100:100
CAT6500-PFC3-CATOS> (enable) set qos wred 1p3q8t tx queue 2 80:100 100:100
100:100 100:100 100:100 100:100 100:100 100:100
! Sets Q2 WRED T1 to 80:100 and all other Q2 WRED Thresholds to 100:100
CAT6500-PFC3-CATOS> (enable) set qos wred 1p3q8t tx queue 3 50:60 60:70 70:80
80:90 90:100 100:100 100:100 100:100
! Sets Q3 WRED T1 to 50:60, Q3T2 to 60:70, Q3T3 to 70:80,
! Q3T4 to 80:90, Q3T5 to 90:100
! and the other two Q3 WRED Thresholds to 100:100
CAT6500-PFC3-CATOS> (enable)
CAT6500-PFC3-CATOS> (enable) set qos map 1p3q8t tx 1 1 cos 1
! Assigns Scavenger/Bulk to Q1 WRED Threshold 1
CAT6500-PFC3-CATOS> (enable) set qos map 1p3q8t tx 2 1 cos 0
! Assigns Best Effort to Q2 WRED Threshold 1
CAT6500-PFC3-CATOS> (enable) set qos map 1p3q8t tx 3 1 cos 4
! Assigns Video to Q3 WRED Threshold 1
CAT6500-PFC3-CATOS> (enable) set qos map 1p3q8t tx 3 2 cos 2
! Assigns Net-Mgmt and Transactional Data to Q3 WRED T2
CAT6500-PFC3-CATOS> (enable) set qos map 1p3q8t tx 3 3 cos 3
! Assigns Call-Signaling and Mission-Critical Data to Q3 WRED T3
CAT6500-PFC3-CATOS> (enable) set qos map 1p3q8t tx 3 4 cos 6
! Assigns Internetwork-Control (IP Routing) to Q3 WRED T4
CAT6500-PFC3-CATOS> (enable) set qos map 1p3q8t tx 3 5 cos 7
! Assigns Network-Control (Spanning Tree) to Q3 WRED T5
CAT6500-PFC3-CATOS> (enable) set qos map 1p3q8t tx 4 cos 5
! Assigns VoIP to the PQ (Q4)
CAT6500-PFC3-CATOS> (enable)

Cat alyst 6500 ( PFC3) Cat OS QoS verificat ion com m ands:

sh ow qos in fo con fig 1 p3 q8 t t x

sh ow qos in fo r u n t im e

sh ow qos st a t ist ics

Exam ple 12- 72 shows t he Cat alyst 6500 ( PFC3) I OS configurat ions t o configure 1P3Q8T queuing
recom m endat ions.

Ex a m ple 1 2 - 7 2 . Ca t a lyst 6 5 0 0 I OS: 1 P3 Q8 T Qu e u in g Ex a m ple

CAT6500-PFC3-IOS(config)# interface range GigabitEthernet1/1 - 48

CAT6500-PFC3-IOS(config-if)# wrr-queue queue-limit 5 25 40
 ! Allocates 5% for Q1, 25% for Q2 and 40% for Q3
CAT6500-PFC3-IOS(config-if)# wrr-queue bandwidth 5 25 70
! Sets the WRR weights for 5:25:70 (Q1:Q2:Q3) bandwidth servicing
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 1
! Enables WRED on Q1
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 2
! Enables WRED on Q2
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 3
! Enables WRED on Q3
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect min-threshold 1 80
100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q1T1 to 80% and all others to 100%
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect max-threshold 1 100
100 100 100 100 100 100 100
! Sets Max WRED Threshold for Q1T1 to 100% and all others to 100%
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect min-threshold 2 80
100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q2T1 to 80% and all others to 100%
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect max-threshold 2 100
100 100 100 100 100 100 100
! Sets Max WRED Threshold for Q2T1 to 100% and all others to 100%
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect min-threshold 3 50
60 70 80 90 100 100 100
! Sets Min WRED Threshold for Q3T1 to 50%, Q3T2 to 60%, Q3T3 to 70%
! Q3T4 to 80%, Q3T5 to 90% and all others to 100%
CAT6500-PFC3-IOS(config-if)# wrr-queue random-detect max-threshold 3 60
70 80 90 100 100 100 100
! Sets Max WRED Threshold for Q3T1 to 60%, Q3T2 to 70%, Q3T3 to 80%
! Q3T4 to 90%, Q3T5 to 100% and all others to 100%
CAT6500-PFC3-IOS(config-if)#
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 1 1 1
! Assigns Scavenger/Bulk to Q1 WRED Threshold 1
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 2 1 0
! Assigns Best Effort to Q2 WRED Threshold 1
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 3 1 4
! Assigns Video to Q3 WRED Threshold 1
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 3 2 2
! Assigns Net-Mgmt and Transactional Data to Q3 WRED T2
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 3 3 3
! Assigns Call-Signaling and Mission-Critical Data to Q3 WRED T3
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 3 4 6
! Assigns Internetwork-Control (IP Routing) to Q3 WRED T4
CAT6500-PFC3-IOS(config-if)# wrr-queue cos-map 3 5 7
! Assigns Network-Control (Spanning Tree) to Q3 WRED T5
CAT6500-PFC3-IOS(config-if)# priority-queue cos-map 1 5
! Assigns VoIP to the PQ (Q4)
CAT6500-PFC3-IOS(config-if)#end
CAT6500-PFC3-IOS#

Cat alyst 6500 MLS QoS verificat ion com m and:

 sh ow qu e u e in g in t e r fa ce

Catalyst 6500: 1P7Q8T Queuing and Dropping

The 1P7Q8T queuing st ruct ure adds four st andard queues t o t he 1P3Q8T st ruct ure and m oves
t he PQ from Q4 t o Q8. Ot herwise, it is ident ical.

Under a 1P7Q8T m odel, buffer space can be allocat ed as follows: 5 percent for t he
Scavenger/ Bulk Dat a queue ( Q1) , 25 percent for t he Best - Effort queue ( Q2) , 10 percent for t he
Video queue ( Q3) , 10 percent for t he Net work- Managem ent / Transact ional Dat a queue ( Q4) , 10
percent for t he Call- Signaling/ Mission- Crit ical Dat a queue ( Q5) , 5 percent for t he I nt ernet work
Cont rol queue ( Q6) , 5 percent for t he Net work Cont rol queue ( Q7) , and 30 percent for t he PQ
( Q8) .

The WRR weight s for t he st andard queues ( Q1 t hrough Q7) , for dividing t he rem aining
bandwidt h, aft er t he priorit y queue has been serviced fully, can be set t o 5: 25: 20: 20: 20: 5: 5,
respect ively, for Q1 t hrough Q7.

Because eight queues are available, each CoS value can be assigned t o it s own exclusive queue.
WRED can be enabled on each queue t o provide it wit h congest ion avoidance, by set t ing t he first
WRED t hreshold of each queue t o 80: 100. All ot her WRED t hresholds can rem ain at 100: 100.

Therefore, when t he queues and t hresholds have been defined as m ent ioned previously, CoS 1
( Scavenger/ Bulk Dat a) can be assigned t o Q1T1; CoS 0 ( Best - Effort ) can be assigned t o Q2T1;
CoS 4 ( I nt eract ive- and St ream ing- Video) can be assigned t o Q3T1; CoS 2 ( Net work-
Managem ent and Transact ional Dat a) can be assigned t o Q4T1; CoS 3 ( Call- Signaling and
Mission- Crit ical Dat a) can be assigned t o Q5T1; CoS 6 ( I nt ernet work Cont rol) can be assigned t o
Q6T1; CoS 7 ( I nt ernet work and Net work Cont rol) can be assigned t o Q7T1; and CoS 5 ( VoI P)
can be assigned t o Q8 ( t he PQ) .

Figure 12- 31 illust rat es t hese 1P7Q8T queuing recom m endat ions.

Figu r e 1 2 - 3 1 . Ca t a lyst 6 5 0 0 1 P7 Q8 T Qu e u in g M ode l

[View full size image]

Exam ple 12- 73 shows t he Cat alyst 6500 ( PFC3) Cat OS configurat ions t o configure 1P7Q8T
queuing recom m endat ions.

Ex a m ple 1 2 - 7 3 . Ca t a lyst 6 5 0 0 ( PFC3 ) Ca t OS: 1 P7 Q8 T Qu e u in g

Ex a m ple

CAT6500-PFC3-CATOS> (enable) set qos txq-ratio 1p7q8t 5 25 10 10 10 5 5 30

! Allocates 5% to Q1, 25% to Q2, 10% to Q3, 10% to Q4,
! Allocates 10% to Q5, 5% to Q6, 5% to Q7 and 30% to the PQ (Q8)
CAT6500-PFC3-CATOS> (enable) set qos wrr 1p7q8t 5 25 20 20 20 5 5
! Sets the WRR weights for 5:25:20:20:20:5:5 (Q1 through Q7)
CAT6500-PFC3-CATOS> (enable)
CAT6500-PFC3-CATOS> (enable)
CAT6500-PFC3-CATOS> (enable) set qos wred 1p7q8t tx queue 1 80:100 100:100
100:100 100:100 100:100 100:100 100:100 100:100
! Sets Q1 WRED T1 to 80:100 and all other Q1 WRED Thresholds to 100:100
CAT6500-PFC3-CATOS> (enable) set qos wred 1p7q8t tx queue 2 80:100 100:100
100:100 100:100 100:100 100:100 100:100 100:100
! Sets Q2 WRED T1 to 80:100 and all other Q2 WRED Thresholds to 100:100
CAT6500-PFC3-CATOS> (enable) set qos wred 1p7q8t tx queue 3 80:100 100:100
100:100 100:100 100:100 100:100 100:100 100:100
! Sets Q3 WRED T1 to 80:100 and all other Q3 WRED Thresholds to 100:100
CAT6500-PFC3-CATOS> (enable) set qos wred 1p7q8t tx queue 4 80:100 100:100
100:100 100:100 100:100 100:100 100:100 100:100
! Sets Q4 WRED T1 to 80:100 and all other Q4 WRED Thresholds to 100:100
CAT6500-PFC3-CATOS> (enable) set qos wred 1p7q8t tx queue 5 80:100 100:100
100:100 100:100 100:100 100:100 100:100 100:100
! Sets Q5 WRED T1 to 80:100 and all other Q5 WRED Thresholds to 100:100
CAT6500-PFC3-CATOS> (enable) set qos wred 1p7q8t tx queue 6 80:100 100:100
100:100 100:100 100:100 100:100 100:100 100:100
! Sets Q6 WRED T1 to 80:100 and all other Q6 WRED Thresholds to 100:100
CAT6500-PFC3-CATOS> (enable) set qos wred 1p7q8t tx queue 7 80:100 100:100
100:100 100:100 100:100 100:100 100:100 100:100
 ! Sets Q7 WRED T1 to 80:100 and all other Q7 WRED Thresholds to 100:100
CAT6500-PFC3-CATOS> (enable)
CAT6500-PFC3-CATOS> (enable)
CAT6500-PFC3-CATOS> (enable) set qos map 1p7q8t tx 1 1 cos 1
! Assigns Scavenger/Bulk to Q1 WRED Threshold 1
CAT6500-PFC3-CATOS> (enable) set qos map 1p7q8t tx 2 1 cos 0
! Assigns Best Effort to Q2 WRED Threshold 1
CAT6500-PFC3-CATOS> (enable) set qos map 1p7q8t tx 3 1 cos 4
! Assigns Video to Q3 WRED Threshold 1
CAT6500-PFC3-CATOS> (enable) set qos map 1p7q8t tx 4 1 cos 2
! Assigns Net-Mgmt and Transactional Data to Q4 WRED T1
CAT6500-PFC3-CATOS> (enable) set qos map 1p7q8t tx 5 1 cos 3
! Assigns Call-Signaling and Mission-Critical Data to Q5 WRED T1
CAT6500-PFC3-CATOS> (enable) set qos map 1p7q8t tx 6 1 cos 6
! Assigns Internetwork-Control (IP Routing) to Q6 WRED T1
CAT6500-PFC3-CATOS> (enable) set qos map 1p7q8t tx 7 1 cos 7
! Assigns Network-Control (Spanning Tree) to Q7 WRED T1
CAT6500-PFC3-CATOS> (enable) set qos map 1p7q8t tx 8 cos 5
! Assigns VoIP to the PQ (Q4)
CAT6500-PFC3-CATOS> (enable)

Cat alyst 6500 ( PFC3) Cat OS QoS verificat ion com m ands:

sh ow qos in fo con fig 1 p7 q8 t t x

sh ow qos in fo r u n t im e

sh ow qos st a t ist ics

Exam ple 12- 74 shows t he Cat alyst 6500 ( PFC3) I OS configurat ions t o configure 1P7Q8T queuing
recom m endat ions.

Ex a m ple 1 2 - 7 4 . Ca t a lyst 6 5 0 0 ( PFC3 ) I OS: 1 P7 Q8 T Qu e u in g Ex a m ple

CAT6500-PFC3-IOS(config)#interface range TenGigabitEthernet4/1 - 4

CAT6500-PFC3(config-if-range)# wrr-queue queue-limit 5 25 10 10 10 5 5
! Allocates 5% to Q1, 25% to Q2, 10% to Q3, 10% to Q4,
! Allocates 10% to Q5, 5% to Q6 and 5% to Q7
CAT6500-PFC3(config-if-range)# wrr-queue bandwidth 5 25 20 20 20 5 5
! Sets the WRR weights for 5:25:20:20:20:5:5 (Q1 through Q7)
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 1
! Enables WRED on Q1
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 2
! Enables WRED on Q2
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 3
! Enables WRED on Q3
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 4
! Enables WRED on Q4
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 5
! Enables WRED on Q5
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 6
! Enables WRED on Q6
CAT6500-PFC3(config-if-range)# wrr-queue random-detect 7
! Enables WRED on Q7
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# wrr-queue random-detect min-threshold 1 80
100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q1T1 to 80% and all others to 100%
CAT6500-PFC3(config-if-range)# wrr-queue random-detect max-threshold 1 100
100 100 100 100 100 100 100
! Sets Max WRED Threshold for Q1T1 to 100% and all others to 100%
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# wrr-queue random-detect min-threshold 2 80
100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q2T1 to 80% and all others to 100%
CAT6500-PFC3(config-if-range)# wrr-queue random-detect max-threshold 2 100
100 100 100 100 100 100 100
! Sets Max WRED Threshold for Q2T1 to 100% and all others to 100%
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# wrr-queue random-detect min-threshold 3 80
100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q3T1 to 80% and all others to 100%
CAT6500-PFC3(config-if-range)# wrr-queue random-detect max-threshold 3 100
100 100 100 100 100 100 100
! Sets Max WRED Threshold for Q3T1 to 100% and all others to 100%
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# wrr-queue random-detect min-threshold 4 80
100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q4T1 to 80% and all others to 100%
CAT6500-PFC3(config-if-range)# wrr-queue random-detect max-threshold 4 100
100 100 100 100 100 100 100
! Sets Max WRED Threshold for Q4T1 to 100% and all others to 100%
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# wrr-queue random-detect min-threshold 5 80
100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q5T1 to 80% and all others to 100%
CAT6500-PFC3(config-if-range)# wrr-queue random-detect max-threshold 5 100
100 100 100 100 100 100 100
! Sets Max WRED Threshold for Q5T1 to 100% and all others to 100%
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# wrr-queue random-detect min-threshold 6 80
100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q6T1 to 80% and all others to 100%
CAT6500-PFC3(config-if-range)# wrr-queue random-detect max-threshold 6 100
100 100 100 100 100 100 100
! Sets Max WRED Threshold for Q6T1 to 100% and all others to 100%
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# wrr-queue random-detect min-threshold 7 80
100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q7T1 to 80% and all others to 100%
CAT6500-PFC3(config-if-range)# wrr-queue random-detect max-threshold 7 100
100 100 100 100 100 100 100
! Sets Max WRED Threshold for Q7T1 to 100% and all others to 100%
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)#
CAT6500-PFC3(config-if-range)# wrr-queue cos-map 1 1 1
! Assigns Scavenger/Bulk to Q1 WRED Threshold 1
CAT6500-PFC3(config-if-range)# wrr-queue cos-map 2 1 0
! Assigns Best Effort to Q2 WRED Threshold 1
CAT6500-PFC3(config-if-range)# wrr-queue cos-map 3 1 4
! Assigns Video to Q3 WRED Threshold 1
CAT6500-PFC3(config-if-range)# wrr-queue cos-map 4 1 2
! Assigns Net-Mgmt and Transactional Data to Q4 WRED T1
CAT6500-PFC3(config-if-range)# wrr-queue cos-map 5 1 3
! Assigns Call-Signaling and Mission-Critical Data to Q5 WRED T1
CAT6500-PFC3(config-if-range)# wrr-queue cos-map 6 1 6
! Assigns Internetwork-Control (IP Routing) to Q6 WRED T1
CAT6500-PFC3(config-if-range)# wrr-queue cos-map 7 1 7
! Assigns Network-Control (Spanning Tree) to Q7 WRED T1
CAT6500-PFC3(config-if-range)# priority-queue cos-map 1 5
! Assigns VoIP to the PQ (Q4)
CAT6500-PFC3(config-if-range)#end
CAT6500-PFC3-IOS#

Cat alyst 6500 MLS QoS verificat ion com m and:

sh ow qu e u e in g in t e r fa ce

Catalyst 6500: PFC3 Distribution-Layer (Cisco IOS) Per-User Microflow

Policing
I n general, superior defense st rat egies have m ult iple lines of defense. I n t he cont ext of t he
cam pus designs discussed in t his chapt er, t here is a m ain line of defense against DoS/ worm
at t ack t raffic at t he access- layer edges. This line of defense can be bolst ered at t he dist ribut ion
layer whenever Cat alyst 6500 Sup720s ( PFC3s) are deployed t here. This can be done by
leveraging t he PFC3 feat ure of per- user m icroflow policing.

I n Exam ple 12- 75 , t raffic has been assum ed t o be correct ly classified. This m ight or m ight not
be a valid assum pt ion. I f it is suspect ed t o be invalid, ACLs should be used t o ident ify t he flows
( inst ead of using DSCP m arkings) . I n eit her case, various flow t ypes can be filt ered as t hey
arrive at t he dist ribut ion layer t o see if t hey conform t o t he norm al lim it s t hat have been set for
t he ent erprise. Each flow is exam ined by source I P address; if a source is t ransm it t ing out of
profile, t he excess t raffic can be dropped or m arked down. I n t his m anner, spurious flows can be
cont ained, even if access- layer swit ches ( such as t he Cat alyst 2950, discussed earlier in t his
chapt er) do not support granular policing or if policing has been m isconfigured on an access-
layer swit ch.

I n t his m anner, t he dist ribut ion- layer Cat alyst 6500 PFC3 can cat ch any DoS/ worm at t ack flows
t hat m ight have slipped t hrough t he access- layer net .

Ex a m ple 1 2 - 7 5 . Ca t a lyst 6 5 0 0 ( PFC3 ) I OSD ist r ibu t ion - La ye r Pe r - Use r

M icr oflow Policin g Ex a m ple

CAT6500-PFC3-IOS(config)#mls qos map policed-dscp normal 0 24 26 34 36 to 8

! Excess traffic marked 0,CS3,AF31,AF41 or AF42 will be remarked to CS1
CAT6500-PFC3-IOS(config)#
CAT6500-PFC3-IOS(config)#class-map match-all VOIP
CAT6500-PFC3-IOS(config-cmap)# match ip dscp ef
CAT6500-PFC3-IOS(config-cmap)#class-map match-all INTERACTIVE-VIDEO
CAT6500-PFC3-IOS(config-cmap)# match ip dscp af41 af42
CAT6500-PFC3-IOS(config-cmap)#class-map match-all CALL-SIGNALING
CAT6500-PFC3-IOS(config-cmap)# match ip dscp cs3 af31
CAT6500-PFC3-IOS(config-cmap)#class-map match-all BEST-EFFORT
CAT6500-PFC3-IOS(config-cmap)# match ip dscp 0
CAT6500-PFC3-IOS(config-cmap)#
CAT6500-PFC3-IOS(config-cmap)#
CAT6500-PFC3-IOS(config-cmap)#pconform-action transmit exceed-action
CAT6500-PFC3-IOS(config-pmap)# class VOIP
CAT6500-PFC3-I(config-pmap-c)# police flow mask src-only 128000 8000
conform-action transmit exceed-action drop
! No source can send more than 128k worth of DSCP EF traffic
CAT6500-PFC3-I(config-pmap-c)# class INTERACTIVE-VIDEO
CAT6500-PFC3-I(config-pmap-c)# police flow mask src-only 500000 8000
conform-action transmit exceed-action policed-dscp-transmit
! Excess IP/VC traffic from any source is marked down to CS1
CAT6500-PFC3-I(config-pmap-c)# class CALL-SIGNALING
CAT6500-PFC3-I(config-pmap-c)# police flow mask src-only 32000 8000
conform-action transmit exceed-action policed-dscp-transmit
! Excess Call-Signaling traffic from any source is marked down to CS1
CAT6500-PFC3-I(config-pmap-c)# class BEST-EFFORT
CAT6500-PFC3-I(config-pmap-c)# police flow mask src-only 5000000 8000
conform-action transmit exceed-action policed-dscp-transmit
! Excess PC Data traffic from any source is marked down to CS1
CAT6500-PFC3-I(config-pmap-c)# exit
CAT6500-PFC3-IOS(config-pmap)#exit
CAT6500-PFC3-IOS(config)#
CAT6500-PFC3-IOS(config)#
CAT6500-PFC3-IOS(config)#interface range GigabitEthernet4/1 - 4
CAT6500-PFC3(config-if-range)# mls qos trust dscp
CAT6500-PFC3(config-if-range)# service-policy input PER-USER-POLICING
! Attaches Per-User Microflow policing policy to Uplinks from Access
CAT6500-PFC3(config-if-range)#end
CAT6500-PFC3-IOS#

Cat alyst 6500 MLS QoS verificat ion com m ands:

sh ow m ls qos

sh ow cla ss- m a p

sh ow policy- m a p

sh ow policy in t e r fa ce
WAN Aggregator/Branch Router Handoff
Considerations
A final considerat ion in cam pus Qos design is t he cam pus- t o- WAN ( or VPN) handoff. I n t he case
of a branch, t his equat es t o a handoff from t he branch swit ch t o t he branch rout er.

I n eit her case, a m aj or speed m ism at ch is im pending because Gigabit Et hernet / Fast Et hernet
cam pus net works are connect ing t o WAN links t hat m ight be only a few m egabit s ( if t hat ) .

Grant ed, t he WAN aggregat ion rout ers and branch rout ers have advanced QoS m echanism s t o
priorit ize t raffic on t heir links, but it is crit ical t o keep in m ind t hat Cisco rout er QoS is perform ed
in Cisco I OS soft ware, while Cat alyst swit ch QoS is perform ed in ASI C hardware.

Therefore, t he opt im al dist ribut ion of QoS operat ions is t o have as m any QoS act ions perform ed
on t he Cat alyst swit ches as possible, saving t he WAN/ branch rout er valuable CPU cycles. This is
an especially crit ical considerat ion when deploying DoS/ worm - m it igat ion designs.

For exam ple, som e ent erprises have deployed advanced QoS policies on t heir branch swit ches
and rout ers, only t o have DoS/ worm at t acks originat e from wit hin t he branch. Rem em ber,
queuing will not engage on a swit ch unless it s links are congest edand even if it does, if t he
branch swit ch hands off 100 Mbps of ( correct ly queued) t raffic t o a branch rout er, it m ore t han
likely will bring it down.

Thus, t he following design principles for t he cam pus- t o- WAN handoff can help m it igat e t hese
t ypes of scenarios.

First , resist t he urge t o use a Gigabit Et hernet connect ion t o t he WAN aggregat ion rout er, even if
t he rout er support s GE.

I t is ext rem ely unlikely t hat t he WAN aggregat or will be serving anywhere close t o a ( com bined)
WAN circuit rat e of 1 Gbps. Therefore, use one ( or m ore) Fast Et hernet connect ion on t he
dist ribut ion- layer Cat alyst swit ch t o connect t o t he WAG so t hat not only is t he aggregat e t raffic
sent t o t he WAG lim it ed ( in 100 Mbps increm ent s) , but ( because congest ion point s now are
pulled back int o t he Cat alyst swit ch, t hus forcing queuing t o engage on t he FE swit ch port ) t he
t raffic also will be queued correct ly wit hin t hese lim it s ( of 100 Mbps increm ent s) .

For exam ple, a WAN aggregat ion rout er is support ing t wo DS3 WAN connect ions ( t ot aling 90
Mbps of WAN circuit capacit y) . I n t his case, t he dist ribut ion- layer swit ch port connect ing t o t he
WAG should be Fast Et hernet . Then, if m ore t han 100 Mbps of t raffic at t em pt s t o t raverse t he
WAN, t he Cat alyst swit ch will engage queuing on t he swit ch port and aggressively drop flows
according t o t he defined applicat ion hierarchies. Only 100 Mbps of correct ly queued t raffic will
ever be handed off t o t he WAG.

I n t he case of a WAN aggregat ion rout er support ing over 100 Mbps of WAN circuit s, as in t he
case of a WAG running one or m ore OC- 3 port s ( at 155 Mbps each) , m ult iple Fast Et hernet
connect ions can be used t o connect t o t he WAG from t he dist ribut ion- layer swit ch t o achieve t he
sam e net effect .

The point is t o bring back, as m uch as possible, t he choke point int o Cat alyst hardware and
engage hardware queuing t here inst ead of overwhelm ing t he soft ware- based policing and
queuing policies wit hin t he WAN aggregat ion rout er.
Second, if t he com bined WAN circuit rat e is significant ly below 100 Mbps, enable egress shaping
on t he Cat alyst swit ches ( when support ed) .

I f t here is no hope of engaging queuing on t he Cat alyst swit ch because t he com bined WAN
circuit rat es are far below t hose of Fast Et hernet ( t he m inim um port speed of Cat alyst swit ches) ,
enable shaping on plat form s t hat support t his feat ure. Such plat form s include t he Cat alyst 2970,
3560, 3750, and 4500.

I n t his m anner, t he Cat alyst swit ch can hold back t raffic and select ively drop ( according t o
defined policies) from flows t hat ot herwise would flood t he WAN/ branch rout er.

For exam ple, if a branch rout er is using t wo ATM- I MA T1 links ( 3 Mbps com bined t hroughput ) t o
connect t he branch t o t he WAN, t he branch swit ch could be configured t o shape all WAN-
dest ined t raffic t o 3 Mbps or could be configured t o shape on a per- applicat ion basis t o sm aller
increm ent s.

Refer t o t he queuing/ dropping sect ions of t hese plat form s in t his chapt er and Cisco I OS
docum ent at ion for addit ional guidance on enabling shaping.

Finally, if t he com bined WAN circuit rat e is significant ly below 100 Mbps and t he Cat alyst swit ch
does not support shaping, enable egress policing ( when support ed) .

I f t he Cat alyst swit ch does not support shaping, egress policing is t he next - best alt ernat ive for
t his scenario.

For exam ple, t he Cat alyst 3550 does not support shaping, but it does support up t o eight
policers on all egress port s. Thus, it could st ill prot ect it s branch rout er from being overwhelm ed
by policing on egress. Egress policing can be done on an aggregat e level or on a per- applicat ion
basis.

Again, t he obj ect ive is t o discard, as int elligent ly as possible, t raffic t hat will be dropped
inevit ably anyway ( by t he WAN/ branch rout er) , but , whenever possible, t o perform t he dropping
wit hin Cat alyst hardware ( inst ead of Cisco I OS Soft ware) .

Egress policers are configured in t he sam e m anner as ingress policers, but t he direct ion specified
in t he se r vice - policy int erface- configurat ion st at em ent will be ou t , not in .

N ot e
The only Cat alyst swit ch discussed in t his chapt er t hat did not support eit her shaping
or egress policing is t he Cat alyst 2950. Unfort unat ely, t here is no way t hat t he Cat alyst
2950 can offload QoS from t he branch rout er. I f such funct ionalit y is required, a
hardware upgrade is advisable.
Case Study: Campus QoS Design
ABC, I nc., is a young, innovat ive com pany seeking t o gain com pet it ive advant age in it s indust ry
vert ical by st rat egic use of inform at ion t echnologies. As such, expect at ions from it s net work
infrast ruct ure are considerable. These expect at ions include st rict - priorit y servicing of VoI P
applicat ions, and provisioning for high- qualit y videoconferencing and for discret e/ granular
service levels for m ult iple classes of dat a applicat ions. Furt herm ore, ABC, I nc., expect s t o
m inim ize net work downt im e from DoS and worm at t acks by building self- defending net works
t hat leverage int elligent net work services, such as qualit y of service, int rusion det ect ion,
encrypt ion, aut hent icat ion, and ot her securit y t echnologies.

ABC, I nc., follows t he Cisco recom m ended cam pus hierarchy of access, dist ribut ion, and core
layers and has deployed a m ix of Cat alyst swit ching plat form s at t hese layers. These swit ches
include Cat alyst 3550s and 3750s ( at t he access layer) , 6500- Sup2s ( wit hin t he dat a cent er) ,
4500- Sup4s ( wit hin t he dist ribut ion layer) , and 6500- Sup720s ( wit hin t he dist ribut ion and core
layers) . Also, ABC, I nc., is connect ing t o Cisco 7200- NPE- G1 WAN aggregat ion rout ers t hat are
providing WAN services at OC- 3 speeds. Figure 12- 32 shows t he cam pus net work t opology.

Figu r e 1 2 - 3 2 . Ca se St u dy: Ca m pu s N e t w or k w it h QoS Policie s t o

Pr ot e ct Voice , Vide o, a n d D a t a W h ile M it iga t in g D oS/ W or m At t a ck s

[View full size image]

At t his early phase in t he net work deploym ent , ABC, I nc., has basic net working configured and
want s t o overlay QoS funct ionalit y. Following t his phase, it will enable addit ional securit y
t echnologies.

ABC, I nc., has chosen t o im plem ent an Unt rust ed Server m odel wit hin t he dat a cent er because it
want s t o adm inist er QoS m arkings and policies on t he net work infrast ruct ure inst ead of on t he
applicat ion servers ( which, at t im es, have been infect ed wit h viruses) . The Mission- Crit ical Dat a
applicat ion is SAP, served off TCP port s 3200 t o 3203 and 3600; t he Transact ional Dat a
applicat ion is Lot us Not es, served off TCP port 1352; and t he Bulk Dat a applicat ion is I MAP for E-
m ail, served off TCP port s 143 and 220. The com pany has dedicat ed servers for t hese
applicat ions, but t hese servers som et im es are m oved. I nst ead of requiring t he net working t eam
t o be not ified for every server m ove, a blanket set of policies will be deployed for t hese m ain
applicat ions on every dat a cent er swit ch port t o correct ly m ark and police t hese flows.

ABC, I nc., has deployed Cisco I P phones and is encouraging em ployees t o m ake effect ive use of
videoconferencing applicat ions t o keep t ravel budget s low while m aint aining product ivit y.
Addit ionally, because t he com pany has been hit hard wit h nearly a dozen worm at t acks wit hin
t he past year, it has chosen t o im plem ent a Scavenger- class m arkdown/ queuing st rat egy
t hroughout t he net work t o m it igat e t he effect s of such flooding at t acks. Finally, because ABC,
I nc., prefers dat a applicat ions t o receive QoS in bot h server- t o- client and client - t o- server
direct ions, it has chosen t o deploy t he Condit ionally Trust ed Endpoint : I P Phone + PC Advanced
m odel on all end- user access- layer swit ches. On t he Cat alyst 3550, t his m odel is being deployed
t hrough per- port / per- VLAN policers; on t he Cat alyst 3750, it is being deployed by access list s
t hat include voice VLAN subnet inform at ion.

All dist ribut ion- layer and core- layer links have been configured t o t rust DSCP m arkings.
Addit ionally, all dist ribut ion- layer Cat alyst 6500- Sup720s ( wit h PFC3s) are configured t o perform
per- user m icroflow policing as a second line of defense against spurious flows from ( non- dat a
cent er access- layer swit ches) . Queuing st ruct ures are dependant on plat form and line card
capabilit ies, as det ailed in t he configurat ions.

Finally, ABC, I nc., has a series of Cisco 7200- NPE- G1 WAN aggregat ion rout ers t o provide WAN
services. These WAN rout ers have ATM OC- 3 ( 155- Mbps) links t o t heir carrier and hom e m ult iple
ATM PVCs t o t heir rem ot e sit es. Alt hough t hese NPE- G1 rout ers have Gigabit Et hernet int erfaces,
ABC, I nc., has chosen t o connect t o t hem using t wo Fast Et hernet int erfaces from t he cam pus
dist ribut ion- layer swit ches. I n t his m anner, t he am ount of t raffic sent t o WAN aggregat ors is
lim it ed t o 200 Mbps, while int elligent queuing is perform edaccording t o t he ent erprise- wide
applicat ion hierarchywit hin t hese physical 200- Mbps lim it s.

The QoS designs for t he ABC cam pus net work span six swit ches, but because one core swit ch is
a m irror im age of t he ot her, only five configurat ions are det ailed in t he following exam ple. These
include t he QoS configurat ions for t he Cat alyst 6500 PFC2 dat a cent er swit ch ( see Exam ple 12-
76 ) , t he Cat alyst 3550 access- layer swit ch ( see Exam ple 12- 77 ) , t he Cat alyst 3750 access-
layer swit ch ( see Exam ple 12- 78 ) , t he left Cat alyst 4500- Sup4 dist ribut ion- layer swit ch ( see
Exam ple 12- 79 ) , t he right Cat alyst 6500- PFC3 dist ribut ion- layer swit ch ( see Exam ple 12- 80 ) ,
and t he left Cat alyst 6500- PFC3 core- layer swit ch ( see Exam ple 12- 81 ) , of which t he right
Cat alyst 6500- PFC3 core- layer swit ch is a m irror im age.

Exam ple 12- 76 shows t he QoS configurat ion for t he Cat alyst 6500 PFC2 dat a cent er swit ch.

Ex a m ple 1 2 - 7 6 . Ca t a lyst 6 5 0 0 - PFC2 ( Ca t OS) : D a t a Ce n t e r Acce ss

Sw it ch for Un t r u st e d Se r ve r s ( Adva n ce d D u a l- Ra t e Policin g M ode l) :
Ca se St u dy Ex a m ple

!
#system
set system name C6500-PFC2-CatOS-DATACENTER
!
#!
#vtp
set vtp domain ABC-INC
set vtp mode transparent vlan
...
set vlan 1,200
...
!
#qos
set qos enable
! 1P2Q2T Global Definitions (for WS-X6K-S2U-MSFC2 GE Uplinks)
set qos map 1p2q2t tx 1 2 cos 0 ! Assigns Best Effort to Q1T2
set qos map 1p2q2t tx 2 1 cos 2 ! Assigns Net-Mgmt/Trans-Data to Q2T1
set qos map 1p2q2t tx 2 1 cos 3 ! Assigns Call-Sig/MC-Data to Q2T1
set qos map 1p2q2t tx 2 2 cos 6 ! Assigns Routing to Q2T2
! All other CoS-Queue mapping remain default
set qos wrr 1p2q2t 30 70 ! Sets WRR weights to 30:70 for Q1:Q2
set qos txq-ratio 1p2q2t 30 40 30 ! Sets sizes 30%,40%,30% for Q1,Q2,Q3/PQ
set qos wred 1p2q2t tx queue 1 40:80 80:100 ! Sets WRED Thresholds for Q1
set qos wred 1p2q2t tx queue 2 70:80 80:100 ! Sets WRED Thresholds for Q2
! 1P3Q1T Global Definitions (for WS-X6548-RJ-45 FE switch ports)
set qos map 1p3q1t tx 2 1 cos 0 ! Assigns Best Effort to Q2T1
set qos map 1p3q1t tx 3 1 cos 2 ! Assigns Net-Mgmt/Trans-Data to Q3T1
set qos map 1p3q1t tx 3 1 cos 3 ! Assigns Call-Sig/MC-Data to Q3T1
set qos map 1p3q1t tx 3 1 cos 4 ! Assigns Video to Q3T1
set qos map 1p3q1t tx 3 cos 6 ! Assigns IP Routing to Q3 (tail)
set qos map 1p3q1t tx 3 cos 7 ! Assigns STP to Q3 (tail)
! All other CoS-Queue mapping remain default
set qos wrr 1p3q1t 5 25 70 ! Sets WRR weights to 5:25:70 for Q1:Q2:Q3
set qos wred 1p3q1t tx queue 1 80:100 ! Sets WRED Thresholds for Q1 (80% to 100%)
set qos wred 1p3q1t tx queue 2 80:100 ! Sets WRED Thresholds for Q2 (80% to 100%)
set qos wred 1p3q1t tx queue 3 70:80 ! Sets WRED Thresholds for Q3 (70% to 80%)
set qos policed-dscp-map 1:1
set qos policed-dscp-map 2:2
set qos policed-dscp-map 3:3
set qos policed-dscp-map 4:4
set qos policed-dscp-map 5:5
set qos policed-dscp-map 6:6
set qos policed-dscp-map 7:7
set qos policed-dscp-map 0,8,25:8 ! Normal markdown of 0 and 25 set to CS1
set qos policed-dscp-map 9:9
set qos policed-dscp-map 11:11
set qos policed-dscp-map 10,12:12 ! Normal markdown of AF11 set to AF12
set qos policed-dscp-map 13:13
set qos policed-dscp-map 14:14
set qos policed-dscp-map 15:15
set qos policed-dscp-map 16:16
set qos policed-dscp-map 17:17
set qos policed-dscp-map 19:19
set qos policed-dscp-map 18,20:20 ! Normal markdown of AF21 set to AF22
set qos policed-dscp-map 21:21
...
<remaining policed-dscp-map (normal rate) DSCP values are mapped to themselves>
...
set qos
policed-dscp-map excess-rate 0:0
set qos
policed-dscp-map excess-rate 1:1
set qos
policed-dscp-map excess-rate 2:2
set qos
policed-dscp-map excess-rate 3:3
set qos
policed-dscp-map excess-rate 4:4
set qos
policed-dscp-map excess-rate 5:5
set qos
policed-dscp-map excess-rate 6:6
set qos
policed-dscp-map excess-rate 7:7
set qos
policed-dscp-map excess-rate 8,10,18:8
! Excess markdown of AF11 and AF12 set to CS1
set qos policed-dscp-map excess-rate 9:9
...
<remaining policed-dscp-map (excess rate) DSCP values are mapped to themselves>
...
set qos policer aggregate SAP rate 15000 policed-dscp erate 32000000
policed-dscp burst 8 eburst 32000
! SAP traffic is (single-rate) policed to 15 Mbps
set qos policer aggregate LOTUS rate 25000 policed-dscp erate 35000
policed-dscp burst 8 eburst 8000
! Lotus traffic is (dual-rate) policed to 25 Mbps and 35 Mbps
set qos policer aggregate IMAP rate 40000 policed-dscp erate 50000
policed-dscp burst 8 eburst 8000
! IMAP traffic is (dual-rate) policed to 40 Mbps and 50 Mbps
set qos policer aggregate DATA rate 1000 policed-dscp erate 32000000
policed-dscp burst 8 eburst 32000
! All other data is (single-rate) policed to 1 Mbps
clear qos acl all
#UNTRUSTED-SERVER
set qos acl ip UNTRUSTED-SERVER dscp 25 aggregate SAP tcp any range 3200 3203 any
set qos acl ip UNTRUSTED-SERVER dscp 25 aggregate SAP tcp any eq 3600 any
! Identifies SAP traffic by TCP source ports 3200-3203 and 3600
set qos acl ip UNTRUSTED-SERVER dscp 18 aggregate LOTUS tcp any eq 1352 any
! Identifies Lotus traffic by TCP source port 1352
set qos acl ip UNTRUSTED-SERVER dscp 10 aggregate IMAP tcp any any eq 143
set qos acl ip UNTRUSTED-SERVER dscp 10 aggregate IMAP tcp any any eq 220
! Identifies IMAP traffic by TCP source port 143 and 220
set qos acl ip UNTRUSTED-SERVER dscp 0 aggregate DATA ip any any
! ACL to Catch all other IP traffic
#
commit qos acl all ! Commits all ACLs to PFC
!
# default port status is enable
!
!
#module 1 : 2-port 1000BaseX Supervisor
clear trunk 1/1 1-199,201-1005,1025-4094
set trunk 1/1 on dot1q 200 ! Trunks Data Center VLAN
clear trunk 1/2 1-199,201-1005,1025-4094
set trunk 1/2 on dot1q 200 ! Trunks Data Center VLAN
commit qos set port qos 1/1-2 trust ! Uplink ports Trust DSCP
!
#module 3 : 48-port 10/100BaseTX Ethernet
set vlan 200 3/1-48 ! Data Center VLAN
set qos acl map UNTRUSTED-SERVER 3/1-48 ! ACL attached to all access-ports
!
Exam ple 12- 77 shows t he QoS configurat ion for t he ( left ) Cat alyst 3550 access- layer swit ch.

Ex a m ple 1 2 - 7 7 . Ca t a lyst 3 5 5 0 Acce ss Sw it ch for I P Ph on e s + PCs

( Adva n ce d M ode l) : Ca se St u dy Ex a m ple

!
hostname CAT3550-ACCESS-LEFT
!
vtp domain ABC-INC
vtp mode transparent
mls qos map policed-dscp 0 10 18 24 25 34 to 8
! Excess DVLAN traffic marked 0, AF11, AF21, CS3, DSCP 25 and AF41
! will be remarked to Scavenger (CS1)
mls qos map cos-dscp 0 8 16 24 32 46 48 56
! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF
mls qos ! Enables QoS Globally
!
class-map match-all VOICE
match ip dscp 46 ! DSCP EF (voice)
class-map match-all VVLAN-VOICE
match vlan 110 ! VLAN 110 is VVLAN
match class-map VOICE ! Matches VVLAN DSCP EF
!
class-map match-any CALL-SIGNALING ! Need 'match-any' here
match ip dscp 26 ! DSCP AF31 (old Call-Signaling)
match ip dscp 24 ! DSCP CS3 (new Call-Signaling)
class-map match-all VVLAN-CALL-SIGNALING
match vlan 110 ! VLAN 110 is VVLAN
match class-map CALL-SIGNALING ! Matches VVLAN AF31/CS3
!
class-map match-all ANY
match access-group name ANY ! Workaround ACL
class-map match-all VVLAN-ANY
match vlan 10 ! VLAN 110 is VVLAN
match class-map ANY ! Matches any other VVLAN traffic
!
class-map match-all PC-VIDEO
match access-group name PC-VIDEO
class-map match-all DVLAN-PC-VIDEO
match vlan 10 ! VLAN 10 is DVLAN
match class-map PC-VIDEO ! Matches PC IP/VC or SoftPhone
!
class-map match-all MISSION-CRITICAL-DATA
match access-group name MISSION-CRITICAL-DATA
class-map match-all DVLAN-MISSION-CRITICAL-DATA
match vlan 10 ! VLAN 10 is DVLAN
match class-map MISSION-CRITICAL-DATA ! Matches DVLAN MC-Data
!
class-map match-all TRANSACTIONAL-DATA
match access-group name TRANSACTIONAL-DATA
class-map match-all DVLAN-TRANSACTIONAL-DATA
match vlan 10 ! VLAN 10 is DVLAN
 match class-map TRANSACTIONAL-DATA ! Matches DVLAN Transactional
!
class-map match-all BULK-DATA
match access-group name BULK-DATA
class-map match-all DVLAN-BULK-DATA
match vlan 10 ! VLAN 10 is DVLAN
match class-map BULK-DATA ! Matches DVLAN Bulk Data
!
class-map match-all DVLAN-ANY
match vlan 10 ! VLAN 10 is DVLAN
match class-map ANY ! Matches all other DVLAN traffic
!
!
policy-map IPPHONE+PC-ADVANCED
class VVLAN-VOICE
set ip dscp 46 ! DSCP EF (Voice)
police 128000 8000 exceed-action drop
! Only one voice call is permitted per switchport VVLAN
class VVLAN-CALL-SIGNALING
set ip dscp 24 ! DSCP CS3 (Call-Signaling)
police 32000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Call-Signaling is marked down to Scavenger (CS1)
class VVLAN-ANY
set ip dscp 0
police 32000 8000 exceed-action policed-dscp-transmit
! Unauthorized VVLAN traffic is marked down to Scavenger (CS1)
class DVLAN-PC-VIDEO
set ip dscp 34 ! DSCP AF41 (Interactive-Video)
police 496000 8000 exceed-action policed-dscp-transmit
! Only one IP/VC stream will be permitted per switchport
class DVLAN-MISSION-CRITICAL-DATA
set ip dscp 25 ! Interim Mission-Critical Data
police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Mission-Critical Data is marked down to Scavenger (CS1)
class DVLAN-TRANSACTIONAL-DATA
set ip dscp 18 ! DSCP AF21 (Transactional Data)
police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Transactional Data is marked down to Scavenger (CS1)
class DVLAN-BULK-DATA
set ip dscp 10 ! DSCP AF11 (Bulk Data)
police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Bulk Data is marked down to Scavenger (CS1)
class DVLAN-ANY
set ip dscp 0
police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile data traffic is marked down to Scavenger (CS1)
!
...
!
interface FastEthernet0/1
description ACCESS-EDGE IP PHONE + PC ADVANCED MODEL
switchport access vlan 10 ! DVLAN
switchport mode dynamic desirable
switchport voice vlan 110 ! VVLAN
no ip address
mls qos trust device cisco-phone ! Conditional Trust
 service-policy input IPPHONE+PC-ADVANCED ! Attaches policy
wrr-queue bandwidth 5 25 70 1
! Q1 gets 5% BW, Q2 gets 25% BW, Q3 gets 70% BW, Q4 is the PQ
wrr-queue cos-map 1 1 ! Scavenger/Bulk is assigned to Q1
wrr-queue cos-map 2 0 ! Best Effort is assigned to Q2
wrr-queue cos-map 3 2 3 4 6 7 ! CoS 2,3,4,6,7 are assigned to Q3
wrr-queue cos-map 4 5 ! Voice is assigned to Q4 (PQ)
priority-queue out ! Enables Q4 as PQ
spanning-tree portfast
!
<repeated for all FE switchports>
!
!
interface GigabitEthernet0/1
description L2 UPLINK TO DISTRIBUTION CAT4500-SUP4-LEFT
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,110 ! Trunks DVLAN + VVLAN
switchport mode trunk
no ip address
mls qos trust dscp ! Trusts DSCP
wrr-queue bandwidth 5 25 70 1
! Q1 gets 5% BW, Q2 gets 25% BW, Q3 gets 70% BW, Q4 is the PQ
wrr-queue queue-limit 5 25 40 30
! Tunes buffers to 5% for Q1, 25% for Q2, 40% for Q3 and 30% for Q4
wrr-queue random-detect max-threshold 1 40 100
! Sets Q1 WRED threshold 1 to 40% and threshold 2 to 100%
wrr-queue random-detect max-threshold 2 80 100
! Sets Q2 WRED threshold 1 to 80% and threshold 2 to 100%
wrr-queue random-detect max-threshold 3 80 100
! Sets Q3 WRED threshold 1 to 80% and threshold 2 to 100%
wrr-queue cos-map 1 1 ! Scavenger/Bulk is assigned to Q1
wrr-queue cos-map 2 0 ! Best Effort is assigned to Q2
wrr-queue cos-map 3 2 3 4 6 7 ! CoS 2,3,4,6,7 are assigned to Q3
wrr-queue cos-map 4 5 ! Voice is assigned to Q4 (PQ)
wrr-queue dscp-map 2 10 48 56
! Maps Bulk Data (10), Routing (48) and Spanning Tree (Internal DSCP 56)
! to WRED threshold 2 of their respective queues all other DSCP values
! are mapped (by default) to WRED threshold 1 of their respective queues
priority-queue out ! Enables Q4 as PQ
!
<repeated for GigabitEthernet0/2 Uplink to Distribution Cat4500-Sup4-Left>
!
...
!
ip access-list standard ANY
permit any
!
ip access-list extended PC-VIDEO
permit udp any any range 16384 32767 ! IP/VC or SoftPhone
!
ip access-list extended MISSION-CRITICAL-DATA
permit tcp any any range 3200 3202 ! SAP
permit tcp any any eq 3600 ! SAP
permit tcp any any range 2000 2002 ! Softphone SCCP
!
ip access-list extended TRANSACTIONAL-DATA
 permit tcp any any eq 1352 ! Lotus
!
ip access-list extended BULK-DATA
permit tcp any any eq 143 ! IMAP
permit tcp any any eq 220 ! IMAP
!

Exam ple 12- 78 shows t he QoS configurat ion for t he ( right ) Cat alyst 3750 access- layer swit ch.

Ex a m ple 1 2 - 7 8 . Ca t a lyst 3 7 5 0 Acce ss Sw it ch for I P Ph on e s + PCs

( Adva n ce d M ode l) : Ca se St u dy Ex a m ple

!
hostname CAT3750-ACCESS-RIGHT
!
...
!
vtp domain ABC-INC
vtp mode transparent
mls qos map policed-dscp 0 10 18 24 25 34 to 8
! Excess DVLAN traffic marked 0, AF11, AF21, CS3, DSCP 25 and AF41
! will be remarked to Scavenger (CS1)
mls qos map cos-dscp 0 8 16 24 32 46 48 56
! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF
!
mls qos srr-queue output cos-map queue 1 threshold 3 0
! Maps CoS 5 to Queue 1 Threshold 3 (Voice gets all of Queue 1)
mls qos srr-queue output cos-map queue 2 threshold 1 2 4
! Maps CoS 2 and CoS 4 to Queue 2 Threshold 1
mls qos srr-queue output cos-map queue 2 threshold 2 3
! Maps CoS 3 to Queue 2 Threshold 2
mls qos srr-queue output cos-map queue 2 threshold 3 6 7
! Maps CoS 6 and CoS 7 to Queue 2 Threshold 3
mls qos srr-queue output cos-map queue 3 threshold 3 0
! Maps CoS 0 to Queue 3 Threshold 3 (Best Efforts gets all of Q3)
mls qos srr-queue output cos-map queue 4 threshold 3 1
! Maps CoS 1 to Queue 4 Threshold 3 (Scavenger/Bulk gets all of Q4)
!
mls qos srr-queue output dscp-map queue 1 threshold 3 46
! Maps DSCP EF (Voice) to Queue 1 Threshold 3
mls qos srr-queue output dscp-map queue 2 threshold 1 16 18 20 22 25 32 34 36
! Maps DSCP CS2 (Net-Mgmt/Transactional) to Queue 2 Threshold 1
! Maps DSCP AF21, AF22, AF23 (Transactional Data) to Queue 2 Threshold 1
! Maps DSCP 25 (Mission-Critical Data) to Queue 2 Threshold 1
! Maps DSCP CS4 (Streaming Video) to Queue 2 Threshold 1
! Maps DSCP AF41, AF42 (Interactive-Video) to Queue 2 Threshold 1
mls qos srr-queue output dscp-map queue 2 threshold 1 38
! Maps DSCP AF43 (Interactive-Video) to Queue 2 Threshold 1
mls qos srr-queue output dscp-map queue 2 threshold 2 24 26
! Maps DSCP CS3 and DSCP AF31 (Call-Signaling) to Queue 2 Threshold 2
mls qos srr-queue output dscp-map queue 2 threshold 3 48 56
! Maps DSCP CS6 and CS7 (Network/Internetwork) to Queue 2 Threshold 3
mls qos srr-queue output dscp-map queue 3 threshold 3 0
! Maps DSCP 0 (Best Effort) to Queue 3 Threshold 3
mls qos srr-queue output dscp-map queue 4 threshold 1 8
! Maps DSCP CS1 (Scavenger) to Queue 4 Threshold 1
mls qos srr-queue output dscp-map queue 4 threshold 3 10 12 14
! Maps DSCP AF11, AF12, AF13 (Bulk Data) to Queue 4 Threshold 3
!
mls qos queue-set output 1 threshold 2 70 80 100 100
! Sets Q2 Threshold 1 to 70% and Q2 Threshold 2 to 80%
mls qos queue-set output 1 threshold 4 40 100 100 100
! Sets Q4 Threshold 1 to 40% and Q4 Threshold 2 to 100%
mls qos ! Enables QoS Globally
!
class-map match-all VVLAN-VOICE
match access-group name VVLAN-VOICE
class-map match-all VVLAN-CALL-SIGNALING
match access-group name VVLAN-CALL-SIGNALING
class-map match-all VVLAN-ANY
match access-group name VVLAN-ANY
!
class-map match-all DVLAN-PC-VIDEO
match access-group name DVLAN-PC-VIDEO
class-map match-all DVLAN-MISSION-CRITICAL-DATA
match access-group name DVLAN-MISSION-CRITICAL-DATA
class-map match-all DVLAN-TRANSACTIONAL-DATA
match access-group name DVLAN-TRANSACTIONAL-DATA
class-map match-all DVLAN-BULK-DATA
match access-group name DVLAN-BULK-DATA
!
policy-map IPPHONE+PC-ADVANCED
class VVLAN-VOICE
set ip dscp 46 ! DSCP EF (Voice)
police 128000 8000 exceed-action drop
! Only one voice call is permitted per switchport VVLAN
class VVLAN-CALL-SIGNALING
set ip dscp 24 ! DSCP CS3 (Call-Signaling)
police 32000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Call-Signaling is marked down to Scavenger (CS1)
class VVLAN-ANY
set ip dscp 0
police 32000 8000 exceed-action policed-dscp-transmit
! Unauthorized VVLAN traffic is marked down to Scavenger (CS1)
class DVLAN-PC-VIDEO
set ip dscp 34 ! DSCP AF41 (Interactive-Video)
police 496000 8000 exceed-action policed-dscp-transmit
! Only one IP/VC stream will be permitted per switchport
class DVLAN-MISSION-CRITICAL-DATA
set ip dscp 25 ! Interim Mission-Critical Data
police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Mission-Critical Data is marked down to Scavenger (CS1)
class DVLAN-TRANSACTIONAL-DATA
set ip dscp 18 ! DSCP AF21 (Transactional Data)
police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Transactional Data is marked down to Scavenger (CS1)
class DVLAN-BULK-DATA
set ip dscp 10 ! DSCP AF11 (Bulk Data)
 police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile Bulk Data is marked down to Scavenger (CS1)
class class-default
set ip dscp 0
police 5000000 8000 exceed-action policed-dscp-transmit
! Out-of-profile data traffic is marked down to Scavenger (CS1)
!
...
!
interface FastEthernet1/0/1
description ACCESS-EDGE IP PHONE + PC ADVANCED MODEL
switchport access vlan 20 ! DVLAN
switchport voice vlan 120 ! VVLAN
no ip address
srr-queue bandwidth share 1 70 25 5
! Q1 is PQ; Q2 gets 70% of remaining BW; Q3 gets 25% and Q4 gets 5%
srr-queue bandwidth shape 30 0 0 0 ! Q1 is limited to 30%
priority-queue out ! Q1 is enabled as a PQ
mls qos trust device cisco-phone ! Conditional Trust
service-policy input IPPHONE+PC-ADVANCED ! Attaches policy to interface
no mdix auto
spanning-tree portfast
!
<repeated for all FE switchports>
!
interface GigabitEthernet1/0/1
description L2 UPLINK TO DISTRIBUTION CAT4500-SUP4-LEFT
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 20,120 ! Trunks DVLAN and VVLAN
switchport mode trunk
no ip address
srr-queue bandwidth share 1 70 25 5
! Q1 is PQ; Q2 gets 70% of remaining BW; Q3 gets 25% and Q4 gets 5%
srr-queue bandwidth shape 30 0 0 0 ! Q1 is shaped to 30%
priority-queue out ! Q1 is enabled as a PQ
mls qos trust dscp ! Trusts DSCP
!
<repeated for GigabitEthernet1/0/2 Uplink to Distribution CAT4500-Sup4>
!
...
!
ip access-list extended VVLAN-VOICE
permit udp 10.1.110.0 0.0.0.255 any range 16384 32767 dscp ef
! Voice is matched by VVLAN subnet and DSCP EF
!
ip access-list extended VVLAN-CALL-SIGNALING
permit tcp 10.1.120.0 0.0.0.255 any range 2000 2002 dscp af31
permit tcp 10.1.120.0 0.0.0.255 any range 2000 2002 dscp cs3
! Call-Signaling is matched by VVLAN subnet and DSCP AF31 or CS3
!
ip access-list extended VVLAN-ANY
permit ip 10.1.120.0 0.0.0.255 any
! Matches all other traffic sourced from the VVLAN subnet
!
ip access-list extended DVLAN-PC-VIDEO
permit udp any any range 16384 32767 ! DVLAN IP/VC
!
ip access-list extended DVLAN-MISSION-CRITICAL-DATA
permit tcp any any range 3200 3202 ! SAP
permit tcp any any eq 3600 ! SAP
permit tcp any any range 2000 2002 ! SoftPhone SCCP
!
ip access-list extended DVLAN-TRANSACTIONAL-DATA
permit tcp any any eq 1352 ! IMAP
!
ip access-list extended DVLAN-BULK-DATA
permit tcp any any eq 143 ! IMAP
permit tcp any any eq 220 ! IMAP
!

Exam ple 12- 79 shows t he QoS configurat ion for t he ( left ) Cat alyst 4500- Sup4 dist ribut ion- layer
swit ch.

Ex a m ple 1 2 - 7 9 . Ca t a lyst 4 5 0 0 - Su p4 D ist r ibu t ion Sw it ch Ca se St u dy

Ex a m ple

!
hostname C4500-SUP4-DIST-LEFT
!
qos dbl exceed-action ecn ! Optional: Enables DBL to mark IP ECN bits
qos dbl ! Globally enables DBL
qos map dscp 0 to tx-queue 2 ! Maps Best Effort to Queue 2
qos map dscp 16 18 20 22 24 25 26 32 to tx-queue 4
! Maps DSCP CS2 (Net-Mgmt) and AF21/AF22/AF23 (Transactional) to Q4
! Maps DSCP CS3 and AF31 (Call-Signaling) and DSCP 25 (MC Data) to Q4
! Maps DSCP CS4 (Str-Video) to Q4
qos map dscp 34 36 38 to tx-queue 4
! Maps DSCP AF41/AF42/AF43 (Int-Video) to Q4
! All other DSCP-to-Queue Mappings are remain at default
qos ! Enables QoS Globally
!
vtp domain ABC-INC
vtp mode transparent
!
...
!
policy-map DBL
class class-default
dbl ! Enables DBL on all traffic flows
!
!
interface GigabitEthernet1/1
description L3 UPLINK TO CORE 6500-PFC3-LEFT
no switchport
ip address 10.1.230.2 255.255.255.252
service-policy output DBL ! Applies DBL policy
qos trust dscp ! Trusts DSCP
tx-queue 1
 bandwidth percent 5 ! Q1 gets 5%
tx-queue 2
bandwidth percent 25 ! Q2 gets 25%
tx-queue 3
bandwidth percent 30 ! Enables Q3 as PQ
priority high ! PQ gets 30%
shape percent 30 ! Shapes PQ to 30%
tx-queue 4
bandwidth percent 40 ! Q4 gets 40%
!
<repeated for GigabitEthernet1/2 Uplink to Core 6500-PFC3-Right>
!
...
!
interface FastEthernet2/1
description L3 FASTETHERNET LINK TO WAG 7200-NPEG1
no switchport
ip address 10.1.220.1 255.255.255.252
service-policy output DBL ! Applies DBL policy
qos trust dscp ! Trusts DSCP
tx-queue 3
priority high ! PQ gets 30%
shape percent 30 ! Shapes PQ to 30%
!
<repeated for FastEthernet2/2 Link to WAN Aggregator>
!
...
!
interface GigabitEthernet3/1
description L2 DOWNLINK TO DATA CENTER 6500-PFC2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200 ! Trunks Data Center VLAN
switchport mode trunk
service-policy output DBL ! Applies DBL policy
qos trust dscp ! Trusts DSCP
tx-queue 1
bandwidth percent 5 ! Q1 gets 5%
tx-queue 2
bandwidth percent 25 ! Q2 gets 25%
tx-queue 3
bandwidth percent 30 ! Enables Q3 as PQ
priority high ! PQ gets 30%
shape percent 30 ! Shapes PQ to 30%
tx-queue 4
bandwidth percent 40 ! Q4 gets 40%
!
<repeated for GigabitEthernet3/2 Downlink to Access-Layer Cat3550>
<repeated for GigabitEthernet3/3 Downlink to Access-Layer Cat3750>
!

Exam ple 12- 80 shows t he QoS configurat ion for t he ( right ) Cat alyst 6500- PFC3 dist ribut ion- layer
swit ch.

Ex a m ple 1 2 - 8 0 . Ca t a lyst 6 5 0 0 - PFC3 I OS D ist r ibu t ion Sw it ch ( w it h Pe r -

Use r M icr oflow Policin g) : Ca se St u dy Ex a m ple

!
hostname CAT6500-PFC3-IOS-DIST-RIGHT
!
...
!
mls qos map policed-dscp normal-burst 0 24 26 34 36 to 8
! Excess traffic marked 0,CS3,AF31,AF41 or AF42 will be remarked to CS1
mls qos ! Enables QoS Globally
!
...
!
class-map match-all VOIP
match ip dscp ef
class-map match-all INTERACTIVE-VIDEO
match ip dscp af41 af42
class-map match-all CALL-SIGNALING
match ip dscp cs3 af31
class-map match-all BEST-EFFORT
match ip dscp default
!
!
policy-map PER-USER-POLICING
class VOIP
police flow mask src-only 128000 8000
conform-action transmit exceed-action drop
! No source can send more than 128k worth of Voice traffic
class INTERACTIVE-VIDEO
police flow mask src-only 496000 8000
conform-action transmit exceed-action policed-dscp-transmit
! Excess IP/VC traffic from any source is marked down to CS1
class CALL-SIGNALING
police flow mask src-only 32000 8000
conform-action transmit exceed-action policed-dscp-transmit
! Excess Call-Signaling from any source is marked down to CS1
class BEST-EFFORT
police flow mask src-only 5000000 8000
conform-action transmit exceed-action policed-dscp-transmit
! Excess PC Data traffic from any source is marked down to CS1
!
...
!
interface GigabitEthernet1/1 ! WS-X6408A-GBIC (1P2Q2T)
description L3 UPLINK TO CORE 6500-PFC3-LEFT
ip address 10.1.230.6 255.255.255.252
wrr-queue bandwidth 30 70
! Sets the WRR weights for 30:70 (Q1:Q2) bandwidth servicing
wrr-queue queue-limit 40 30
! Sets the buffer allocations to 40% for Q1 and 30% for Q2
! Indirectly sets PQ (Q3) size to equal Q2 (which is set to 30%)
wrr-queue random-detect min-threshold 1 40 40
! Sets Min WRED Thresholds for Q1T1 and Q1T2 to 40 and 80, respectively
wrr-queue random-detect min-threshold 2 70 80
! Sets Min WRED Thresholds for Q2T1 and Q2T2 to 70 and 80, respectively
 wrr-queue random-detect max-threshold 1 80 100
! Sets Max WRED Thresholds for Q1T1 and Q1T2 to 80 and 100, respectively
wrr-queue random-detect max-threshold 2 80 100
! Sets Max WRED Thresholds for Q2T1 and Q2T2 to 80 and 100, respectively
wrr-queue cos-map 1 1 1 ! Maps Scavenger/Bulk to Q1 WRED T1
wrr-queue cos-map 1 2 0 ! Maps Best Effort to Q1 WRED T2
wrr-queue cos-map 2 1 2 3 4 ! Maps CoS 2,3,4 to Q2 WRED T1
wrr-queue cos-map 2 2 6 7 ! Maps CoS 6 and 7 to Q2 WRED T2
mls qos trust dscp ! Trusts DSCP
!
<repeated for GigabitEthernet1/2 Uplink to Core 6500-PFC3-Right>
!
...
!
interface FastEthernet2/1 ! WS-X6548-RJ-45 (1P3Q1T)
description L3 FASTETHERNET LINK TO WAG 7200-NPEG1
ip address 10.1.220.10 255.255.255.252
wrr-queue bandwidth 5 25 70
! Sets the WRR weights for 5:25:70 (Q1:Q2:Q3) bandwidth servicing
wrr-queue random-detect min-threshold 1 80
! Sets the Min WRED Threshold for Q1T1 to 80%
wrr-queue random-detect min-threshold 2 80
! Sets Min WRED Threshold for Q2T1 to 80%
wrr-queue random-detect min-threshold 3 80
! Sets Min WRED Threshold for Q3T1 to 80%
! All other WRED Thresholds are left at default (100%)
wrr-queue cos-map 1 1 1 ! Maps Scavenger/Bulk to Q1 WRED T1
wrr-queue cos-map 2 1 0 ! Maps Best Effort to Q1 WRED T1
wrr-wrr-queue cos-map 3 1 2 3 4 ! Maps CoS 2,3,4,6 and 7 to Q3 WRED T1
mls qos trust dscp ! Trusts DSCP
!
<repeated for FastEthernet2/2 Link to WAN Aggregator>
!
...
!
interface GigabitEthernet3/2 ! WS-X6408A-GBIC (1P2Q2T)
description L2 DOWNLINK TO ACCESS-LAYER C3550 - LEFT
no ip address
wrr-queue bandwidth 30 70
! Sets the WRR weights for 30:70 (Q1:Q2) bandwidth servicing
wrr-queue queue-limit 40 30
! Sets the buffer allocations to 40% for Q1 and 30% for Q2
! Indirectly sets PQ (Q3) size to equal Q2 (which is set to 30%)
wrr-queue random-detect min-threshold 1 40 80
! Sets Min WRED Thresholds for Q1T1 and Q1T2 to 40 and 80, respectively
wrr-queue random-detect min-threshold 2 70 80
! Sets Min WRED Thresholds for Q2T1 and Q2T2 to 70 and 80, respectively
wrr-queue random-detect max-threshold 1 80 100
! Sets Max WRED Thresholds for Q1T1 and Q1T2 to 80 and 100, respectively
wrr-queue random-detect max-threshold 2 80 100
! Sets Max WRED Thresholds for Q2T1 and Q2T2 to 80 and 100, respectively
wrr-queue cos-map 1 1 1 , ! Maps Scavenger/Bulk to Q1 WRED T1
wrr-queue cos-map 1 2 0 ! Maps Best Effort to Q1 WRED T2
wrr-queue cos-map 2 1 2 3 4 ! Maps CoS 2,3,4 to Q2 WRED T1
wrr-queue cos-map 2 2 6 7 ! Maps CoS 6 and 7 to Q2 WRED T2
mls qos trust dscp ! Trusts DSCP
 switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,110 ! Trunks DVLAN and VVLAN
switchport mode trunk
service-policy input PER-USER-POLICING ! Attaches Per-User Policer
!
<repeated for GigabitEthernet3/3 Downlink to Access-Layer Cat3750>
<repeated for GigabitEthernet3/1 Downlink to Data Center C6500-PFC2>
<except no "service-policy input PER-USER-POLICING" for Data Center Downlink>
!

Exam ple 12- 81 shows t he QoS configurat ion for t he left Cat alyst 6500- PFC3 core- layer swit ch, of
which t he right Cat alyst 6500- PFC3 core- layer swit ch is a m irror im age.

Ex a m ple 1 2 - 8 1 . Ca t a lyst 6 5 0 0 - PFC3 I OS Cor e Sw it ch : Ca se St u dy

Ex a m ple

!
hostname CAT6500-PFC3-IOS-CORE-LEFT
!
mls qos ! Enables QoS Globally
!
...
!
interface Port-channel1
description 40GE CORE BACKBONE
ip address 10.1.240.1 255.255.255.252
mls qos trust dscp
!
...
!
interface TenGigabitEthernet1/1 ! WS-X6704-10GE (1P7Q8T)
no ip address
wrr-queue bandwidth 5 25 20 20 20 5 5
! Sets the WRR weights for 5:25:20:20:20:5:5 (Q1 through Q7)
wrr-queue queue-limit 5 25 10 10 10 5 5
! Allocates 5% to Q1, 25% to Q2, 10% to Q3, 10% to Q4,
! Allocates 10% to Q5, 5% to Q6 and 5% to Q7
wrr-queue random-detect min-threshold 1 80 100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q1T1 to 80% and all others to 100%
wrr-queue random-detect min-threshold 2 1 100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q2T1 to 80% and all others to 100%
wrr-queue random-detect min-threshold 3 80 100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q3T1 to 80% and all others to 100%
wrr-queue random-detect min-threshold 4 80 100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q4T1 to 80% and all others to 100%
wrr-queue random-detect min-threshold 5 80 100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q5T1 to 80% and all others to 100%
wrr-queue random-detect min-threshold 6 80 100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q6T1 to 80% and all others to 100%
wrr-queue random-detect min-threshold 7 80 100 100 100 100 100 100 100
! Sets Min WRED Threshold for Q7T1 to 80% and all others to 100%
 wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100
! Sets Max WRED Threshold for Q1T1 to 100% and all others to 100%
wrr-queue random-detect max-threshold 2 100 100 100 100 100 100 100 100
! Sets Max WRED Threshold for Q2T1 to 100% and all others to 100%
! All other WRED Thresholds remain at their default values (100%)
wrr-queue random-detect 4 ! Enables WRED on Q4
wrr-queue random-detect 5 ! Enables WRED on Q5
wrr-queue random-detect 6 ! Enables WRED on Q6
wrr-queue random-detect 7 ! Enables WRED on Q7
wrr-queue cos-map 1 1 1 ! Maps Scavenger/Bulk to Q1
wrr-queue cos-map 2 1 0 ! Maps Best Effort to Q2
wrr-queue cos-map 3 1 4 ! Maps Video to Q3
wrr-queue cos-map 4 1 2 ! Maps Net-Mgmt/Transactional to Q4
wrr-queue cos-map 5 1 3 ! Maps Call-Signaling/MC-Data to Q5
wrr-queue cos-map 6 1 6 ! Maps IP Routing to Q6
wrr-queue cos-map 7 1 7 ! Maps STP to Q7
mls qos trust dscp ! Trusts DSCP
channel-group 1 mode on
!
<repeated three more times on interfaces TenGigabitEthernet1/2-4>
!
...
!
interface GigabitEthernet2/1 ! WS-X6408A-GBIC (1P2Q2T)
description L3 DOWNLINK TO DISTRIBUTION 4500-SUP4-LEFT
ip address 10.1.230.1 255.255.255.252
wrr-queue bandwidth 30 70
! Sets the WRR weights for 30:70 (Q1:Q2) bandwidth servicing
wrr-queue queue-limit 40 30
! Sets the buffer allocations to 40% for Q1 and 30% for Q2
! Indirectly sets PQ (Q3) size to equal Q2 (which is set to 30%)
wrr-queue random-detect min-threshold 1 40 80
! Sets Min WRED Thresholds for Q1T1 and Q1T2 to 40 and 80, respectively
wrr-queue random-detect min-threshold 2 70 80
! Sets Min WRED Thresholds for Q2T1 and Q2T2 to 70 and 80, respectively
wrr-queue random-detect max-threshold 1 80 100
! Sets Max WRED Thresholds for Q1T1 and Q1T2 to 80 and 100, respectively
wrr-queue random-detect max-threshold 2 80 100
! Sets Max WRED Thresholds for Q2T1 and Q2T2 to 80 and 100, respectively
wrr-queue cos-map 1 1 1 ! Maps Scavenger/Bulk to Q1 WRED T1
wrr-queue cos-map 1 2 0 ! Maps Best Effort to Q1 WRED T2
wrr-queue cos-map 2 1 2 3 4 ! Maps CoS 2,3,4 to Q2 WRED T1
wrr-queue cos-map 2 2 6 7 ! Maps CoS 6 and 7 to Q2 WRED T2
mls qos trust dscp ! Trusts DSCP
!
<repeated for GigabitEthernet2/2 Downlink to Distribution 6500-PFC3-Right>
!
Summary
This chapt er began wit h est ablishing t he case for cam pus QoS by way of t hree m ain QoS design
principles: The first is t hat applicat ions should be classified and m arked as close t o t heir sources
as t echnically and adm inist rat ively feasible. The second is t hat unwant ed t raffic flows should be
policed as close t o t heir sources as possible. The t hird is t hat QoS always should be perform ed in
hardware, inst ead of soft ware, whenever a choice exist s. Furt herm ore, it was em phasized t hat
t he only way t o provide service guarant ees is t o enable queuing at any node t hat has t he
pot ent ial for congest ion, including cam pus uplinks and downlinks.

A proact ive approach t o m it igat ing DoS/ worm flooding at t acks wit hin cam pus environm ent s was
overviewed. This approach focuses on access- edge policers t hat m et er t raffic rat es received from
endpoint devices; when t hese exceed specified wat erm arks ( at which point t hey no longer are
considered norm al flows) , t hese policers m ark down excess t raffic t o Scavenger ( DSCP CS1) .
These policers are coupled wit h queuing policies t hroughout t he ent erprise t hat provision for a
less- t han best - effort Scavenger class on all links. I n t his m anner, legit im at e t raffic burst s are not
affect ed, but DoS/ worm - generat ed t raffic significant ly is m it igat ed.

Com m on endpoint s were overviewed and classified int o t hree m ain groups: t rust ed endpoint s,
unt rust ed endpoint s, and condit ionally t rust ed endpoint s. Unt rust ed endpoint s were subdivided
int o t wo sm aller m odels: unt rust ed PCs and unt rust ed servers. Sim ilarly, condit ionally t rust ed
endpoint s were subdivided int o t wo m odels: basic and advanced.

Following t hese access- edge m odel definit ions, plat form - specific recom m endat ions were given
on t o how t o im plem ent t hese access- edge m odels on Cisco Cat alyst 2950, 2970, 3550, 3560,
3750, 4500, and 6500 series swit ches. Plat form - specific lim it at ions, caveat s, and nerd knobs
were highlight ed t o t ailor each m odel t o each plat form 's unique feat ure set s. All configurat ions
were present ed in config m ode t o cont inually highlight what plat form was being discussed.
Furt herm ore, m any relevant verificat ion com m ands were discussed in det ail ( in cont ext ) t o
illust rat e how and when t hese can be used effect ively when deploying QoS wit hin t he cam pus.

Recom m endat ions also were given on how t o configure queuing on a per- plat form , per- line- card
basis. These recom m endat ions included configuring 1P3Q1T queuing on t he Cat alyst 2950,
configuring 1P3Q2T queuing on t he Cat alyst 3550, configuring 1P3Q3T queuing on t he Cat alyst
2970/ 3560/ 3750, and configuring 1P3Q1T queuing ( + DBL) on t he Cat alyst 4500. For t he
Cat alyst 6500, line cardspecific queuing st ruct ures were exam ined in det ail, including Cat OS and
Cisco I OS configurat ions for configuring 2Q2T, 1P2Q1T, 1P2Q2T, 1P3Q1T, 1P3Q8T, and 1P7Q8T
queuing.

Following t his, t he Cat alyst 6500 PFC3's per- user m icroflow policing feat ure was discussed in t he
cont ext of how it can be leveraged t o provide a second line of policing defense at t he dist ribut ion
layer.

Finally, cam pus- t o- WAN/ VPN handoff considerat ions were exam ined. I t was recom m ended t hat
you first resist t he urge t o use a Gigabit Et hernet connect ion t o t he WAN aggregat ion rout er,
even if t he rout er support s GE. Second, if t he com bined WAN circuit rat e is significant ly below
100 Mbps, enable egress shaping on t he Cat alyst swit ches ( when support ed) . Third, if t he
com bined WAN circuit rat e is significant ly below 100 Mbps and t he Cat alyst swit ch does not
support shaping, enable egress policing ( when support ed) .

The design chapt er concluded wit h a case st udy of a fict it ious ent erprise, t o illust rat e how t hese
various plat form - specific recom m endat ions can be brought t oget her in an end- t o- end cam pus
QoS design for prot ect ing voice, video, and crit ical dat a applicat ions while m it igat ing DoS/ worm
at t acks.
Further Reading
St andar ds:

RFC 2474, " Definit ion of t he Different iat ed Services Field ( DS Field) in t he I Pv4 and I Pv6
Headers" : ht t p: / / www.iet f.org/ rfc/ rfc2474 .

RFC 2597, " Assured Forwarding PHB Group" : ht t p: / / www.iet f.org/ rfc/ rfc2597 .

RFC 2697, " A Single Rat e Three Color Marker" : ht t p: / / www.iet f.org/ rfc/ rfc2697 .

RFC 2698, " A Two Rat e Three Color Marker" : ht t p: / / www.iet f.org/ rfc/ rfc2698 .

RFC 3168, " The Addit ion of Explicit Congest ion Not ificat ion ( ECN) t o I P" :
ht t p: / / www.iet f.org/ rfc/ rfc3168 .

RFC 3246, " An Expedit ed Forwarding PHB ( Per- Hop Behavior) " :
ht t p: / / www.iet f.org/ rfc/ rfc3246 .

Books:

Flannagan, Michael, Richard Froom , and Kevin Turek. Cisco Cat alyst QoS: Qualit y of
Service in Cam pus Net works . I ndianapolis: Cisco Press, 2003.

Cisco Cat alyst docum ent at ion:

Configuring QoS on t he Cat alyst 2950 ( Cisco I OS Release 12.1[ 19] EA1) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 2950/ 12119ea1/ 2950scg/ swqos.ht m
.

Configuring QoS on t he Cat alyst 3550 ( Cisco I OS Release 12.1[ 19] EA1) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ c3550/ 12119ea1/ 3550scg/ swqos.ht m .

Configuring QoS on t he Cat alyst 2970 ( Cisco I OS Release 12.2[ 18] SE) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 2970/ 12218se/ 2970scg/ swqos.ht m .

Configuring QoS on t he Cat alyst 2970 ( Cisco I OS Release 12.2[ 18] SE) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 3750/ 12218se/ 3750scg/ swqos.ht m .

Configuring QoS on t he Cat alyst 4500 ( Cisco I OS Release 12.2[ 18] EW) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 4000/ 12_2_18/ config/ qos.ht m .

Configuring QoS on t he Cat alyst 6500 ( Cisco Cat OS Release 8.2) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 6000/ sw_8_2/ confg_gd/ qos.ht m .

Configuring Aut om at ic QoS on t he Cat alyst 6500 ( Cisco Cat OS Release 8.2) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 6000/ sw_8_2/ confg_gd/ aut oqos.ht m
.
Configuring QoS on t he Cat alyst 6500 ( Cisco I OS Release 12.2[ 17] SX) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / lan/ cat 6000/ 122sx/ swcg/ qos.ht m .
Part IV: WAN QoS Design
Part I V of t his book provides an in- dept h discussion of privat e- WAN QoS design. QoS
considerat ions and det ailed designs are present ed for WAN aggregat ion rout ers connect ing
cam pus net works t o various WAN m edia, such as leased- lines, Fram e Relay, ATM and ATM-
t o- Fram e Relay Service- I nt erworking. Addit ionally, QoS considerat ions and designs unique
t o branch rout ers are exam ined, which include using Net work- Based Applicat ion
Recognit ion ( NBAR) for known- worm policing. While prim arily addressing privat e- WAN QoS
design, m any of t hese recom m endat ions are also applicable t o VPN QoS designs ( discussed
in Part V) where t radit ional privat e- WAN m edia is used for VPN access.

The chapt ers in t his part of t he book are as follows:

Chapt er 13 WAN Aggregat or QoS Design

Chapt er 14 Branch Rout er QoS Design

Chapter 13. WAN Aggregator QoS Design
This chapt er discusses WAN QoS considerat ions and designs, including t he following:

Slow- speed ( 768 kbps) WAN link design

Medium - speed ( 768 kbps t o T1/ E1 speed) WAN link design

High- speed ( > T1/ E1 speed) WAN link design

Addit ionally, t hese designs are applied t o specific Layer 2 WAN m edia, including t he following:

Leased lines

Fram e Relay

ATM

ATM- t o- Fram e Relay Service I nt erworking

I SDN

A fundam ent al principle of econom ics st at es t hat t he m ore scarce a resource is t he m ore
efficient ly it should be m anaged. I n an ent erprise net work infrast ruct ure, bandwidt h is t he prim e
resource and also is t he scarcest ( and, likewise, m ost expensive) over t he WAN. Therefore, t he
case for efficient bandwidt h opt im izat ion using QoS t echnologies is st rongest over t he WAN,
especially for ent erprises t hat are converging t heir voice, video, and dat a net works.

The design principles described in t his chapt er apply prim arily t o Layer 2 WANs, such as leased
lines, Fram e Relay, and ATM ( including ATM- t o- Fram e Relay Service I nt erworking) . However,
m any service providers use t hese Layer 2 WAN t echnologies t o access Layer 3 VPN services.
Therefore, m any of t he design principles and exam ples present ed in t his chapt er also apply t o
such VPN access scenarios.

This chapt er provides design guidance for enabling QoS over t he WAN. I t is im port ant t o not e
t hat t he recom m endat ions in t his chapt er are not aut onom ous. They are crit ically dependent on
t he recom m endat ions discussed in Chapt er 12, " Cam pus QoS Design."
Where Is QoS Needed over the WAN?
Wit hin t ypical WAN environm ent s, rout ers play one of t wo roles: a WAN aggregat or or a branch
rout er. I n som e very com plex WAN m odels, ent erprises m ight have dist ribut ed WAN aggregat ors
t o cover regional branches, but t he role of such m iddle- t ier rout ers is not significant ly different
from t hat of a WAN aggregat or locat ed at a cam pus edge. This chapt er focuses on WAN edge
recom m endat ionsprim arily for WAN aggregat or rout ers, but t hese correspondingly apply t o t he
WAN edge designs of branch rout ers. QoS policies required on WAN edges are shown in Figure
13- 1 .

Figu r e 1 3 - 1 . W h e r e I s QoS N e e de d ove r t h e W AN ?

Chapt er 14, " Branch Rout er QoS Design," discusses addit ional QoS considerat ions and designs
unique t o branch rout ers.
WAN Edge QoS Design Considerations
QoS policies required on WAN aggregat ors include queuing, shaping, select ive dropping, and
link- efficiency policies in t he out bound direct ion of t he WAN link. Traffic is assum ed t o be
correct ly classified and m arked ( at Layer 3) before WAN aggregat or ingress. Rem em ber, Layer 3
m arkings ( preferably DSCP) are m edia independent and t raverse t he WAN m edia, whereas Layer
2 CoS is lost when t he m edia swit ches from Et hernet t o WAN m edia.

Several fact ors m ust be kept in m ind when designing and deploying QoS polices on WAN edges.
Som e of t hese considerat ions were int roduced in earlier chapt ers. They are re- em phasized here
t o underscore t heir im port ance t o t he cont ext of t he WAN QoS designs t hat follow.

Software QoS
Unlike LAN ( Cat alyst ) queuing, which is done in hardware, WAN edge QoS is perform ed wit hin
Cisco I OS Soft ware. I f t he WAN aggregat or is hom ing several hundred rem ot e branches, t he
collect ive CPU required t o adm inist er com plex QoS policies m ight be m ore t han som e older
devices can provide.

The m ain point t o keep in m ind is t hat QoS ent ails a m arginal CPU load. WAN t opologies and
QoS policies should be designed t o lim it t he average CPU ut ilizat ion of t he WAN aggregat or t o 75
percent ( or lower) because t his leaves cycles available t o respond efficient ly t o rout ing updat es.

Bandwidth Provisioning for Best-Effort Traffic

As discussed previously, t he Best - Effort class is t he default class for all dat a t raffic. Only if an
applicat ion has been select ed for preferent ial or deferent ial t reat m ent is it rem oved from t he
default class. Because m any ent erprises have several hundreds, if not t housands, of dat a
applicat ions running over t heir net works, adequat e bandwidt h m ust be provisioned for t his class
as a whole t o handle t he sheer volum e of applicat ions t hat default t o it . I t is recom m ended t hat
at least 25 percent of a WAN link's bandwidt h be reserved for t he default Best - Effort class.

Bandwidth Provisioning for Real-Time Traffic

Not only does t he Best - Effort class of t raffic require special bandwidt h- provisioning
considerat ion, but t he Real- Tim e class does as well. The am ount of bandwidt h assigned t o t he
Real- Tim e class is variable; however, if t oo m uch t raffic is assigned t o Real- Tim e ( st rict -
priorit y/ low- lat ency) queuing, t he overall effect is a dam pening of QoS funct ionalit y for dat a
applicat ions.

The goal of convergence cannot be overem phasized: t o enable voice, video, and dat a t o coexist
t r anspar ent ly on a single net work. When real- t im e applicat ions ( such as voice or int eract ive-
video) dom inat e a WAN link, dat a applicat ions fluct uat e significant ly in t heir response t im es,
dest roying t he t ransparency of t he " converged" net work.

Cisco Technical Market ing t est ing has shown a significant decrease in dat a applicat ion response
t im es when Real- Tim e t raffic exceeds one- t hird of a link's bandwidt h capacit y. Cisco I OS
Soft ware allows t he abst ract ion ( and, t hus, configurat ion) of m ult iple LLQs. Ext ensive t est ing
and product ion- net work cust om er deploym ent s have shown t hat lim it ing t he sum of all LLQs t o
33 percent is a conservat ive and safe design rat io for m erging real- t im e applicat ions wit h dat a
applicat ions.

Furt herm ore, it should be kept in m ind t hat if VoI P t raffic is set t o dom inat e a link via low-
lat ency queuing ( which is essent ially st rict - priorit y FI FO queuing) , VoI P act ually could negat ively
im pact ot her VoI P t raffic because of ext ensive FI FO queuing. This easily could result in excessive
serializat ion delays ( 10 m s per hop) on even m edium - speed links ( T1/ E1 links) where
serializat ion delays ordinarily would not even be a considerat ion. ( Serializat ion delays are
discussed in m ore det ail in t he next sect ion.) Such excessive serializat ion delays from VoI P LLQ
overprovisioning would increase VoI P j it t er and, t hus, decrease overall call qualit y.

N ot e
The 33- percent lim it for t he sum of all LLQs is sim ply a best - pract ice design
recom m endat ion; it is not a m andat e. I n som e cases, specific business obj ect ives
cannot be m et while holding t o t his recom m endat ion. I n such cases, ent erprises m ust
provision according t o t heir det ailed requirem ent s and const raint s. However, it is
im port ant t o recognize t he t rade- offs involved wit h overprovisioning LLQ t raffic in
respect t o t he negat ive perform ance im pact on dat a applicat ion response t im es.

Serialization
Serializat ion delay refers t o t he finit e am ount of t im e it t akes t o clock a fram e ont o t he physical
m edia. Wit hin t he cam pus, t his t im e is so infinit esim al t hat it is com plet ely im m at erial. Over t he
WAN, however, lower link speeds can cause sufficient serializat ion delay t o adversely affect real-
t im e st ream s, such as Voice or I nt eract ive- Video.

Serializat ion delays are variable because t hey depend not only on t he line rat e of t he link speed,
but also on t he size of t he packet being serialized. Variable ( net work) delay also is known as
j it t er. Because t he end- t o- end one- way j it t er t arget has been set as 30 m s, t he t ypical per- hop
serializat ion delay t arget is 10 m s ( which allows for up t o t hree int erm ediat e hops per direct ion
of VoI P t raffic flow) . This 10 m s per- hop t arget leads t o t he recom m endat ion t hat a link
fragm ent at ion and int erleaving ( LFI ) t ool ( eit her MLP LFI or FRF.12) be enabled on links wit h
speeds at or below 768 kbps ( t his is because t he serializat ion delay of a m axim um - size Et hernet
packet 1500 byt est akes m ore t han 10 m s t o serialize at 768 kbps and below) . Nat urally, LFI t ools
need t o be enabled on bot h ends of t he link.

When deploying LFI t ools, it is recom m ended t hat t he LFI t ools be enabled during a scheduled
downt im e. Assum ing t hat t he net work adm inist rat or is wit hin t he ent erprise's cam pus, it is
recom m ended t hat LFI be enabled on t he branch rout er first ( which is on t he far end of t he WAN
link) because t his generally t akes t he WAN link down. Then t he adm inist rat or can enable LFI on
t he WAN aggregat or ( t he near end of t he WAN link) , and t he link will com e back up. Ot herwise,
if t he adm inist rat or enables LFI on t he WAN aggregat or first , t he link will go down, along wit h
any in- band m anagem ent access t o t he branch rout er. I n such a case, t he adm inist rat or would
need t o rem ove LFI from t he WAN aggregat or ( bringing t he link back up) , enable LFI on t he
branch rout er, and t hen re- enable LFI on t he WAN aggregat or.

Addit ionally, as point ed out in Chapt er 5, " Congest ion- Managem ent Tools," because t raffic
assigned t o t he LLQ escapes fragm ent at ion, it is recom m ended t hat I nt eract ive- Video not be
deployed on slow- speed links; t he large I nt eract ive- Video packet s ( such as 1500- byt e full-
m ot ion I - Fram es) could cause serializat ion delays for sm aller I nt eract ive- Video packet s.
I nt eract ive- Video t raffic pat t erns and net work requirem ent s are overviewed in Chapt er 2, " QoS
Design Overview."

IP RTP Header Compression

Com pressing I P, UDP, and RTP headers ( cRTP) for VoI P calls can result in significant bandwidt h
gains over WAN links. However, it is im port ant t o realize t hat cRTP is one of t he m ost CPU-
int ensive feat ures wit hin t he Cisco I OS Soft ware QoS t oolset . Therefore, it is recom m ended t hat
cRTP be used prim arily on slow- speed ( 768 kbps) links wit h a careful eye on CPU levels
( especially for WAN aggregat ors t hat hom e a large num ber of rem ot e branches) .

Tx-ring Tuning
Newer versions of Cisco I OS Soft ware aut om at ically size t he final int erface out put buffer ( Tx-
ring) t o opt im al lengt hs for Real- Tim e applicat ions, such as Voice or Video. On som e older
versions of Cisco I OS Soft ware, Tx- rings m ight need t o be reduced on slow- speed links t o avoid
excessive serializat ion delay.

To det erm ine t he value of t he Tx- ring on an int erface, use t he variat ion of t he sh ow con t r olle r s
com m and shown in Exam ple 13- 1.

Ex a m ple 1 3 - 1 . Displaying t he Tx- ring Value wit h t he sh ow con t r olle r s

Com m and

WAG-7206-Left#show controllers Serial 1/0 | include tx_limited

tx_underrun_err=0, tx_soft_underrun_err=0, tx_limited=1(64)
WAG-7206-Left#

The value wit hin t he parent heses following t he t x _ lim it e d keyword reflect s t he value of t he Tx-
ring. I n t his part icular exam ple, t he Tx- ring is set t o 64 packet s. This value can be t uned t o t he
recom m ended set t ing of 3 on T1/ E1 ( or slower) links using t he com m and shown in Exam ple 13-
2.

Ex a m ple 1 3 - 2 . Tu n in g t h e Tx - r in g

WAG-7206-Left(config)#interface Serial 1/0

WAG-7206-Left(config-if)#tx-ring-limit 3

The new set t ing quickly can be verified wit h t he sam e sh ow con t r olle r s com m and, as shown in
Exam ple 13- 3.
Ex a m ple 1 3 - 3 . Ve r ifyin g Tx - r in g Ch a n ge s

WAG-7206-Left#show controllers ser 1/0 | include tx_limited

Tx_underrun_err=0, tx-soft-underru_rr=0, tx-limited=1(3)
WAG-7206_Left#

N ot e
I n ATM, t he lengt h of t he Tx- ring is defined in ( 576- byt e) part icles, not packet s, and is
t uned on a per- PVC basis. On som e non- ATM int erfaces, t he Tx- ring even can be t uned
t o a m inim um of 1 ( packet ) . I n eit her case, t he Tx- ring can be t uned ( on 768 kbps
links) t o approxim at ely 1500 byt es, which is t he MTU of Et hernet .

PAK_priority
Chapt er 5 int roduced PAK_priorit y, t he int ernal Cisco I OS m echanism for prot ect ing rout ing and
cont rol t raffic. The design im plicat ions of PAK_priorit y are sum m arized in t he following list :

Layer 2 and Layer 3 cont rol t raffic on m oderat ely congest ed WAN links t ypically is
prot ect ed adequat ely wit h t he default PAK_priorit y t reat m ent wit hin t he rout er and t he I P
ToS byt e m arkings of I PP6/ CS6.

On heavily congest ed links, it m ight be necessary t o explicit ly provision a CBWFQ

bandwidt h class for rout ing/ cont rol t raffic, as ident ified by eit her I PP or CS6.

Alt hough I S- I S t raffic receives PAK_priorit y wit hin t he rout er, it cannot be m arked t o
I PP6/ CS6 because I S- I S uses a CLNS prot ocol. ( I t does not use I P, so t here are no I PP or
DSCP fields t o m ark.) This is im port ant t o keep in m ind if explicit bandwidt h provisioning is
required for I S- I S t raffic because it cannot be m at ched against I PP6/ CS6 like m ost ot her
I GPs. However, NBAR can be used wit hin a class m ap t o m at ch I S- I S t raffic ( for exam ple,
m a t ch pr ot ocol cln s_ is) .

Alt hough BGPs ( bot h eBGPs and iBGPs) are m arked t o I PP6/ CS6, t hey do not receive
PAK_priorit y t reat m ent wit hin t he rout ers. Therefore, it m ay be necessary t o provision a
separat e bandwidt h class t o prot ect BGP sessions, even on m oderat ely congest ed links
where t he underlying I GPs are st able.

On Cat alyst 6500 swit ches running Cisco I OS Soft ware on bot h t he supervisors and MSFC,
I GP packet s m arked int ernally wit h PAK_priorit y addit ionally are m arked wit h I PP6/ CS6 and
t he Layer 2 CoS value of 6. This is because scheduling and congest ion avoidance wit hin
Cisco Cat alyst swit ches is perform ed against Layer 2 CoS values.

Link Speeds
I n t he cont ext of WAN links, t here are t hree m ain groupings of link speeds. These link speeds
and t heir respect ive design im plicat ions are sum m arized in t he following list :

Slow ( link speed 768 kbps) :

- Deploym ent of I nt eract ive- Video generally is not recom m ended on t hese links
because of serializat ion im plicat ions.

- These links require LFI t o be enabled if VoI P is t o be deployed over t hem .

- cRTP is recom m ended ( wit h a wat chful eye on CPU levels) .

- Check Tx- ring sizes ( especially on slow- speed ATM PVCs) ; t une t o 3, if needed.

- Three- t o five- class t raffic m odels are recom m ended.

Medium ( 768 kbps link speed T1/ E1) :

- VoI P or I nt eract ive- Video can be assigned t o t he LLQ ( usually, t here is not enough
bandwidt h t o do bot h and st ill keep t he LLQ provisioned at less t han 33
percent alt ernat ively, I nt eract ive- Video can be placed in a CBWFQ queue) .

- LFI is not required.

- cRTP is opt ional.

- Three- t o five- class t raffic m odels are recom m ended.

High ( T1/ E1 link speeds) :

- LFI is not required.

- cRTP generally is not recom m ended ( because t he cost of increased CPU levels
t ypically offset s t he benefit s of t he am ount of bandwidt h saved) .

- Five- t o 11- class t raffic m odels are recom m ended.

Distributed Platform QoS and Consistent QoS Behavior

I t is im port ant t o keep in m ind t hat m inor differences m ight exist bet ween QoS configurat ions on
dist ribut ed plat form s ( such as t he Cisco 7500 series wit h VI Ps) and t hose on nondist ribut ed
plat form s ( such as t he Cisco 7200 or 1700) . The m ost com m on difference is t he inclusion of t he
dist r ibu t e d keyword aft er com m ands such as ip ce f on dist ribut ed plat form s. Where m ore
com plicat ed differences exist , t hey are highlight ed explicit ly in t his chapt er.

An im port ant init iat ive is under way wit hin Cisco t o port t he QoS code from t he Cisco 7500 series
rout ers t o t he nondist ribut ed rout er fam ilies. This init iat ive is called Consist ent QoS Behavior and
has as it s obj ect ives sim plifying QoS and increasing QoS consist ency bet ween plat form s.
Consist ent QoS Behavior code should rem ove m ost , if not all, configurat ion idiosyncrasies
bet ween dist ribut ed and nondist ribut ed plat form s.
WAN Edge Classification and Provisioning Models
One of t he m ost com m on quest ions raised when planning a QoS deploym ent over t he WAN is
" How m any classes of t raffic should be provisioned for?" The following considerat ions should be
kept in m ind when arriving at an appropriat e t raffic class m odel for a given ent erprise.

Slow/Medium Link-Speed QoS Class Models

Slow- speed ( 768 kbps) links have very lit t le bandwidt h t o carve up, t o begin wit h. When t he
serializat ion im plicat ions of sending I nt eract ive- Video int o t he LLQ are t aken int o considerat ion,
it becom es generally im pract ical t o deploy m ore t han five classes of t raffic over slow- speed links.

Medium - speed ( T1/ E1) links do not have serializat ion rest rict ions and can accom m odat e
eit her VoI P or I nt eract ive- Video in t heir LLQs. However, t ypically bot h t ypes of t raffic cannot be
provisioned at t he sam e t im e wit hout oversubscribing t he LLQ ( provisioning m ore t han 33
percent of t he t raffic for t he LLQ) . Alt hough t his m ight be possible t o configure ( t he parser will
accept t he policy and at t ach it t o t he int erface) , t he adm inist rat or should rem em ber t he t rade- off
of significant ly adverse dat a applicat ion response t im es when LLQs exceed one- t hird of t he link.
An alt ernat ive approach m ight be t o provision I nt eract ive- Video in a CBWFQ on m edium - speed
links.

Three-Class (Voice and Data) Model

I f t he business obj ect ive is sim ply t o deploy VoI P over t he exist ing dat a net work, t he Voice and
Dat a WAN Edge Model is appropriat e. Alt hough it m ight seem t hat t his is a t wo- class m odel, it is
act ually t hree: Voice, Call- Signaling, and ( generic) dat a.

Voice is ident ified by DSCP EF, which is set by default on Cisco I P phones. When ident ified, VoI P
is adm it t ed int o t he LLQ, which, in t his exam ple, is set t o t he m axim um recom m ended value of
33 percent of t he link. Call adm ission cont rol ( CAC) correspondingly should be assigned t o t his
link by dividing t he allocat ed bandwidt h by t he voice codec ( including Layer 2 overhead) t o
det erm ine how m any calls can be perm it t ed sim ult aneously over t his link. Because class- based
cRTP is used in t his exam ple t o com press voice t raffic, it also should be fact ored int o t he CAC
calculat ion.

Call- Signaling t raffic also is m arked on t he I P phones ( t o AF31 current ly, but it will be m igrat ed
t o CS3, per t he QoS Baseline) and requires a relat ively sm all but dedicat ed bandwidt h
guarant ee. All ot her dat a is fair- queued wit hin class- default . This Three- class WAN Edge Model is
illust rat ed in Figure 13- 2 and det ailed in Exam ple 13- 4 .

Figu r e 1 3 - 2 . Th r e e - Cla ss W AN Edge M ode l M igr a t ion St r a t e gy Ex a m ple

Ex a m ple 1 3 - 4 . Th r e e - Cla ss W AN Edge M ode l

!
class-map match-all Voice
match ip dscp ef ! IP Phones mark Voice to EF
class-map match-any Call Signaling
match ip dscp cs3 ! Future Call-Signaling marking
match ip dscp af31 ! IP Phones mark Call-Signaling to AF31
!
policy-map WAN-EDGE
class Voice
priority percent 33 ! Maximum recommended LLQ value
compress header ip rtp ! Optional: Enables Class-Based cRTP
class Call Signaling
bandwidth percent 5 ! BW guarantee for Call-Signaling
class class-default
fair-queue ! All other data gets fair-queuing
!

N ot e
Som et im es adm inist rat ors explicit ly creat e a class m ap t hat funct ions as t he MQC
class- default . For inst ance, an adm inist rat or m ight creat e a class along t he lines of t hat
shown in t he following code:

class-map match-all BEST-EFFORT

match any

or even:
 class-map match-all BEST-EFFORT
match access-group 101
...
access-list 101 permit ip any any

These addit ional configurat ions are superfluous and inefficient for t he rout er t o
process. The MQC im plicit cla ss- de fa u lt should be used inst ead.

Anot her advant age of using t he MQC im plicit cla ss- de fa u lt is t hat ( current ly, before
Consist ent QoS Behavior code) on nondist ribut ed plat form s, class- default is t he only
class t hat support s fair queuing wit hin it .

Verificat ion com m and:

sh ow policy

Verification Command: show policy

The preceding t hree- class policy, like any ot her MQC policy, can be verified using t he sh ow
policy com m and, as shown in Exam ple 13- 5 .

Ex a m ple 1 3 - 5 . Ve r ifica t ion of Th r e e - Cla ss W AN Edge Policy

RBR-2691-Right#show policy WAN-EDGE

Policy Map WAN-EDGE
Class VOICE
Strict Priority ! Voice will get LLQ
Bandwidth 33 (%) ! LLQ is provisioned to 33%
compress:
header ip rtp ! cRTP is enabled
Class CALL-SIGNALING
Bandwidth 5 (%) Max Threshold 64 (packets) ! Call-Signaling gets 5% BW
Class class-default
Flow based Fair Queueing ! Data will get FQ
Bandwidth 0 (kbps) Max Threshold 64 (packets)
RBR-2691-Right#

The Five- Class WAN Edge Model builds on t he previous Three- Class WAN Edge Model and
includes a provision for a Crit ical Dat a class and a Scavenger class.

The new Crit ical Dat a class requires Transact ional Dat a t raffic t o be m arked t o DSCP AF21 ( or
AF22, in t he case of dual- rat e policers deployed wit hin t he cam pus) . Addit ionally, I GP rout ing
( m arked by t he rout ers as CS6) and Net work- Managem ent t raffic ( recom m ended t o be m arked
t o CS2) are prot ect ed wit hin t his class. I n t his exam ple, t he Crit ical Dat a class is provisioned t o
36 percent of t he link and DSCP- based WRED is enabled on it .
The Scavenger class const rains any t raffic m arked t o DSCP CS1 t o 1 percent of t he link; t his
allows class- default t o use t he rem aining 25 percent . However, t o const rain Scavenger t o 1
percent , an explicit bandwidt h guarant ee ( of 25 percent ) m ust be given t o t he Best - Effort class.
Ot herwise, if class- default is not explicit ly assigned a m inim um bandwidt h guarant ee, t he
Scavenger class st ill can rob it of bandwidt h. This is because of t he way t he CBWFQ algorit hm
has been coded: I f classes prot ect ed wit h a ba n dw idt h st at em ent are offered m ore t raffic t han
t heir m inim um bandwidt h guarant ee, t he algorit hm t ries t o prot ect such excess t raffic at t he
direct expense of robbing bandwidt h from class- default ( if class- default is configured wit h fa ir -
qu e u e ) , unless class- default it self has a ba n dw idt h st at em ent ( providing it self wit h a
m inim um bandwidt h guarant ee) . However, assigning a ba n dw idt h st at em ent t o class- default
( on nondist ribut ed plat form s) current ly precludes t he enabling of fair queuing ( fa ir - qu e u e ) on
t his class and forces FI FO queuing on class- default ( t his lim it at ion is t o be rem oved wit h t he
release of Consist ent QoS Behavior code) .

N ot e
An addit ional im plicat ion of using a ba n dw idt h st at em ent on class- default is t hat even
t hough 25 percent of t he link is reserved explicit ly for class- default , t he parser will not
at t ach t he policy t o an int erface unless t he m a x - r e se r ve d- ba n dw idt h 1 0 0 com m and is
ent ered on t he int erface before t he se r vice - policy ou t pu t st at em ent . This is because t he
parser adds t he sum of t he ba n dw idt h st at em ent s ( regardless of whet her one of t hese is
applied t o t he class- default ) and, if t he t ot al is in excess of 75 percent of t he link's
bandwidt h, rej ect s t he applicat ion of t he policy t o t he int erface. This is shown in t he
following code:

!
interface Multilink1
description T1 to Branch#60
ip address 10.1.112.1 255.255.255.252
max-reserved-bandwidth 100 ! overrides the default 75% BW limit
service-policy output WAN-EDGE ! attaches the MQC policy
ppp multilink
ppp multilink group 1
!

Furt herm ore, WRED can be enabled on t he Best - Effort class t o provide congest ion m anagem ent .
Because all t raffic assigned t o t he default class is t o be m arked t o t he sam e DSCP value ( of 0) , it
would be superfluous t o enable DSCP- based WRED on such a class; WRED ( t echnically, RED, in
t his case because all t he [ I P Precedence] weight s are t he sam e) would suffice.

This Five- Class WAN Edge Model is illust rat ed in Figure 13- 3 and det ailed in Exam ple 13- 6 .

Figu r e 1 3 - 3 . Five - Cla ss W AN Edge M ode l Ba n dw idt h Alloca t ion

Ex a m ple
Ex a m ple 1 3 - 6 . Five - Cla ss W AN Edge M ode l

!
class-map match-all Voice
match ip dscp ef ! IP Phones mark Voice to EF
class-map match-any Call Signaling
match ip dscp cs3 ! Future Call-Signaling marking
bandwidth percent 1 ! Current Call-Signaling marking
class-map match-any Critical Data
match ip dscp cs6 ! Routers mark Routing traffic to CS6
match ip dscp af21 af22 ! Recommended markings for Transactional-Data
match ip dscp cs2 ! Recommended marking for Network Management
class-map match-all Scavenger
match ip dscp cs1 ! Scavenger marking
!
policy-map WAN-EDGE
class Voice
priority percent 33 ! Voice gets 33% of LLQ
class Call Signaling
bandwidth percent 5 ! BW guarantee for Call-Signaling
class Critical Data
bandwidth percent 36 ! Critical Data class gets 36% BW guarantee
random-detect dscp-based ! Enables DSCP-WRED for Critical-Data class
class Scavenger
bandwidth percent 1 ! Scavenger class is throttled
class class-default
bandwidth percent 25 ! Default class gets a 25% BW guarantee
random-detect ! Enables WRED for class-default
!

Verificat ion com m and:

 sh ow policy

High Link Speed QoS Class Models

High- speed links ( such as m ult iple T1/ E1 or above speeds) allow for t he provisioning of Voice,
I nt eract ive- Video, and m ult iple classes of dat a, according t o t he design rules present ed in t his
chapt er ( for exam ple, 25 percent for Best Effort class and 33 percent for all LLQs) .

Enabling QoS only opt im izes t he efficiency of bandwidt h ut ilizat ion; it does not creat e bandwidt h.
Therefore, it is im port ant t o have adequat e bandwidt h for all t he applicat ions being provisioned.
Furt herm ore, as WAN bandwidt h is becom ing less expensive, higher- speed links are becom ing
m ore popular.

Even if adequat e bandwidt h exist s for up t o 11 classes of t raffic, as out lined by t he QoS Baseline
Model, not all ent erprises are com fort able wit h deploying such com plex QoS policies at t his t im e.
Therefore, it is recom m ended t o st art sim ple, but wit h room t o grow int o m ore com plex m odels.
Figure 13- 4 illust rat es a sim ple m igrat ion st rat egy showing which classes are good candidat es
for subdivision int o m ore granular classes as fut ure needs arise.

Figu r e 1 3 - 4 . N u m be r of QoS Cla sse s M igr a t ion St r a t e gy Ex a m ple

I f t he ent erprises' QoS requirem ent s exceed t hat which t he Five- Class Model can provision for
( such as requiring service guarant ees for I nt eract ive- Video and requiring Bulk Dat a t o be
cont rolled during busy periods) , t hey m ight consider m igrat ing t o t he Eight - Class Model.

Eight-Class Model

The Eight - Class Model int roduces a dual- LLQ design: one for Voice and anot her for I nt eract ive-
Video.
As point ed out in Chapt er 5 , t he LLQ has an im plicit policer t hat allows for t im e- division
m ult iplexing of t he single priorit y queue. This im plicit policer abst ract s t he fact t hat t here is
essent ially a single LLQ wit hin t he algorit hm and, t hus, allows for t he " provisioning" of m ult iple
LLQs.

I nt eract ive- video ( or I P videoconferencing, known also as I P/ VC) is recom m ended t o be m arked
AF41 ( which can be m arked down t o AF42 in t he case of dual- rat e policing at t he cam pus access
edge) . I t is recom m ended t o overprovision t he LLQ by 20 percent of t he I P/ VC rat e. This t akes
int o account I P/ UDP/ RTP headers as well as Layer 2 overhead.

Addit ionally, Cisco I OS Soft ware aut om at ically includes a 200- m s burst param et er ( defined in
byt es) as part of t he pr ior it y com m and. On dual- T1 links, t his has proven sufficient for
prot ect ing a single 384- kbps I P/ VC st ream ; on higher- speed links ( such as t riple T1s) , t he
default burst param et er has shown t o be insufficient for prot ect ing m ult iple I P/ VC st ream s.
However, m ult iple- st ream I P/ VC qualit y t est ed well wit h t he burst set t o 30,000 byt es ( for
exam ple, pr ior it y 9 2 0 3 0 0 0 0 ) . Our t est ing did not arrive at a clean form ula for predict ing t he
required size of t he burst param et ers as I P/ VC st ream s cont inually were added; however, given
t he variable packet sizes and rat es of t hese I nt eract ive- Video st ream s, t his is not surprising. The
m ain point is t hat t he default LLQ burst param et er m ight require t uning as m ult iple I P/ VC
st ream s are added ( which likely will be a t rial- and- error process) .

Opt ionally, DSCP- based WRED can be enabled on t he I nt eract ive- Video class, but t est ing has
shown negligible perform ance difference in doing so ( because, as already has been not ed, WRED
is m ore effect ive on TCP- based flows t han UDP- based flows, such as I nt eract ive- Video) .

I n t hese designs, WRED is not enabled on classes such as Call- Signaling, I P Rout ing, or Net work-
Managem ent because WRED would t ake effect only if such classes were filling t heir queues
nearly t o t heir lim it s. Such condit ions would indicat e a provisioning problem t hat would bet t er be
addressed by increasing t he m inim um bandwidt h allocat ion for t he class t han by enabling WRED.

Addit ionally, t he Eight - Class Model subdivides t he preferent ial dat a class t o separat e cont rol
plane t raffic ( I P rout ing and Net work- Managem ent applicat ions) from business- crit ical dat a
t raffic. I nt erior Gat eway Prot ocol ( such as RI P, EI GRP, OSPF, and I S- I S) packet s are prot ect ed
t hrough t he PAK_priorit y m echanism wit hin t he rout er. However, EGP prot ocols, such as BGP, do
not get PAK_priorit y t reat m ent and m ight need explicit bandwidt h guarant ees t o ensure t hat
peering sessions do not reset during periods of congest ion. Addit ionally, adm inist rat ors m ight
want t o prot ect net work- m anagem ent access t o devices during periods of congest ion.

The ot her class added t o t his m odel is for bulk t raffic ( Bulk Dat a class) , which is also spun away
from t he Crit ical Dat a class. Because TCP cont inually increases it s window sizes, which is
especially not iceable in long sessions ( such as large file t ransfers) , const raining Bulk Dat a t o it s
own class alleviat es ot her dat a classes from being dom inat ed by such large file t ransfers. Bulk
Dat a is ident ified by DSCP AF11 ( or AF12, in t he case of dual- rat e policing at t he cam pus access
edges) . DSCP- based WRED can be enabled on t he Bulk Dat a class ( and also on t he Crit ical Dat a
class) .

Figure 13- 5 shows sam ple bandwidt h allocat ions of an Eight - Class Model ( for a dual- T1 link
exam ple) . Figure 13- 5 also shows how t his m odel can be derived from t he Five- Class Model in a
m anner t hat m aint ains respect ive bandwidt h allocat ions as consist ent ly as possible, which
increases t he overall end- user t ransparency of such a m igrat ion.

Figu r e 1 3 - 5 . Eigh t - Cla ss W AN Edge M ode l Ba n dw idt h Alloca t ion s

Ex a m ple
Exam ple 13- 7 shows t he corresponding configurat ion ( over a dual- T1 link) for t he Eight - Class
Model.

Ex a m ple 1 3 - 7 . Eigh t - Cla ss W AN Edge M ode l

!
class-map match-all Voice
match ip dscp ef ! IP Phones mark Voice to EF
class-map match-all Interactive Video
match ip dscp af41 af42 ! Recommended markings for IP/VC
class-map match-any Call Signaling
match ip dscp cs3 ! Future Call-Signaling marking
match ip dscp af31 ! Current Call-Signaling marking
class-map match-any Network Control
match ip dscp cs6 ! Routers mark Routing traffic to CS6
match ip dscp cs2 ! Recommended marking for Network Management
class-map match-all Critical Data
match ip dscp af21 af22 ! Recommended markings for Transactional-Data
class-map match-all Bulk Data
match ip dscp af11 af12 ! Recommended markings for Bulk-Data
class-map match-all Scavenger
match ip dscp cs1 ! Scavenger marking
!
policy-map WAN-EDGE
class Voice
priority percent 18 ! Voice gets 552 kbps of LLQ
class Interactive Video
priority percent 15 ! 384 kbps IP/VC needs 460 kbps of LLQ
class Call Signaling
 bandwidth percent 5 ! BW guarantee for Call-Signaling
class Network Control
bandwidth percent 5 ! Routing and Network Management get min 5% BW
class Critical Data
bandwidth percent 27 ! Critical Data gets min 27% BW
random-detect dscp-based ! Enables DSCP-WRED for Critical-Data class
class Bulk Data
bandwidth percent 4 ! Bulk Data gets min 4% BW guarantee
random-detect dscp-based ! Enables DSCP-WRED for Bulk-Data class
class Scavenger
bandwidth percent 1 ! Scavenger class is throttled
class class-default
bandwidth percent 25 ! Fair-queuing is sacrificed for BW guarantee
random-detect ! Enables WRED on class-default
!
!

N ot e
The Consist ent QoS Behavior init iat ive will enable t he configurat ion of a ba n dw idt h
st at em ent along wit h fa ir - qu e u e on any class, including class- default , on all
plat form s.

Verificat ion com m and:

sh ow policy

QoS Baseline (11-Class) Model

As m ent ioned in t he overview, t he QoS Baseline is a guiding m odel for addressing t he QoS needs
of t oday and t he foreseeable fut ure. The QoS Baseline is not a m andat e dict at ing what
ent erprises m ust deploy t oday; inst ead, t his st rat egic docum ent offers st andards- based
recom m endat ions for m arking and provisioning t raffic classes t hat will allow for great er
int eroperabilit y and sim plified fut ure expansion.

Building on t he previous m odel, t he Net work- Cont rol class is subdivided int o t he I P Rout ing and
Net work- Managem ent classes.

The Crit ical Dat a class also is subdivided furt her int o t he Mission- Crit ical Dat a and Transact ional
Dat a classes. Alt hough DSCP- based WRED is enabled on t he Transact ional Dat a class, because
packet s for t his class can be m arked AF21 ( or AF22, as in t he case of dual- rat e policers being
deployed in t he cam pus) , it would be superfluous t o enable DSCP- based WRED on t he Mission-
Crit ical Dat a class ( WRED will suffice because all Mission- Crit ical Dat a class packet s are m arked
t o t he sam e value: DSCP 25) .

Finally, a new class is provisioned for St ream ing- Video. Test ing has shown t hat t here is a
negligible difference in enabling WRED on t his UDP- based t raffic class, so, alt hough it rem ains an
opt ion, WRED is not enabled in t hese design exam ples.
Figure 13- 6 shows a sam ple WAN edge bandwidt h allocat ion for a QoS Baseline Model ( over a
dual- T1 link) and also shows how t his m odel can be derived from t he Five- and Seven- Class
Models in a m anner t hat m aint ains respect ive bandwidt h allocat ions as consist ent ly as possible.
This increases t he overall end- user t ransparency of such a m igrat ion.

Figu r e 1 3 - 6 . QoS Ba se lin e W AN Edge M ode l Ba n dw idt h Alloca t ion s

Ex a m ple

Exam ple 13- 8 shows t he corresponding configurat ion for an 11- Class QoS Baseline WAN Edge
Model ( over a dual- T1 link) .

Ex a m ple 1 3 - 8 . QoS Ba se lin e W AN Edge M ode l

!
class-map match-all Voice
match ip dscp ef ! IP Phones mark Voice to EF
class-map match-all Interactive Video
match ip dscp af41 af42 ! Recommended markings for IP/VC
class-map match-any Call Signaling
match ip dscp cs3 ! Future Call-Signaling marking
match ip dscp af31 ! Current Call-Signaling marking
class-map match-all Routing
match ip dscp cs6 ! Routers mark Routing traffic to CS6
class-map match-all Net Mgmt
match ip dscp cs2 ! Recommended marking for Network Management
class-map match-all Mission-Critical Data
 match ip dscp 25 ! Interim marking for Mission-Critical Data
class-map match-all Transactional Data
match ip dscp af21 af22 ! Recommended markings for Transactional-Data
class-map match-all Bulk Data
match ip dscp af11 af12 ! Recommended markings for Bulk-Data
class-map match-all Streaming Video
match ip dscp cs4 ! Recommended marking for Streaming-Video
class-map match-all Scavenger
match ip dscp cs1 ! Recommended marking for Scavenger traffic
!
policy-map WAN-EDGE
class Voice
priority percent 18 ! Voice gets 552 kbps of LLQ
class Interactive Video
priority percent 15 ! 384 kbps IP/VC needs 460 kbps of LLQ
class Call Signaling
bandwidth percent 5 ! BW guarantee for Call-Signaling
class Routing
bandwidth percent 3 ! Routing class gets explicit BW guarantee
class Net Mgmt
bandwidth percent 2 ! Net-Mgmt class gets explicit BW guarantee
class Mission-Critical Data
bandwidth percent 10 ! Mission-Critical class gets 10% BW guarantee
random-detect ! Enables WRED for Mission-Critical Data class
class Transactional Data
bandwidth percent 7 ! Transactional-Data class gets 7% BW guarantee
random-detect dscp-based ! Enables DSCP-WRED for Transactional-Data class
class Bulk Data
bandwidth percent 4 ! Bulk Data remains at 4% BW guarantee
random-detect dscp-based ! Enables DSCP-WRED for Bulk-Data class
class Streaming Video
bandwidth percent 10 ! Streaming-Video class gets 10% BW guarantee
class Scavenger
bandwidth percent 1 ! Scavenger class is throttled
class class-default
bandwidth percent 25 ! Class-Default gets 25% min BW guarantee
random-detect ! Enables WRED on class-default
!

Verificat ion com m and:

sh ow policy

Again, a ba n dw idt h st at em ent is used on class- default ( current ly) , precluding t he use of fa ir -
qu e u e on t he class for all nondist ribut ed plat form s. Also, a m a x - r e se r ve d- ba n dw idt h 1 0 0
st at em ent m ust be applied t o t he int erface before t he se r vice - policy ou t pu t st at em ent .

Distributed-Platform/Consistent QoS BehaviorQoS Baseline Model

One of t he current advant ages of t he Cisco 7500 ( dist ribut ed plat form ) QoS code is t hat it can
suppor t ba n dw idt h com m ands in conj unct ion wit h fa ir - qu e u e on any given class, including
class- default . This funct ionalit y will becom e available t o nondist ribut ed plat form s wit h t he
release of Consist ent QoS Behavior code. ( As of t his writ ing, t his init iat ive does not have a fixed
t arget delivery dat e.) When fa ir - qu e u e is enabled on t he m ain dat a classes, t he result ing
configurat ion becom es as shown in Exam ple 13- 9 .

Ex a m ple 1 3 - 9 . D ist r ibu t e d- Pla t for m / Con sist e n t QoS Be h a vior QoS
Ba se lin e W AN Edge M ode l

!
ip cef distributed ! 'distributed' keyword required on 7500 for ip cef
!
class-map match-all Voice
match ip dscp ef ! IP Phones mark Voice to EF
class-map match-all Interactive Video
match ip dscp af41 af42 ! Recommended markings for IP/VC
class-map match-any Call Signaling
match ip dscp cs3 ! Future Call-Signaling marking
match ip dscp af31 ! Current Call-Signaling marking
class-map match-all Routing
match ip dscp cs6 ! Routers mark Routing traffic to CS6
class-map match-all Net Mgmt
match ip dscp cs2 ! Recommended marking for Network Management
class-map match-all Mission-Critical Data
match ip dscp 25 ! Interim marking for Mission-Critical Data
class-map match-all Transactional Data
match ip dscp af21 af22 ! Recommended markings for Transactional-Data
class-map match-all Bulk Data
match ip dscp af11 af12 ! Recommended markings for Bulk-Data
class-map match-all Streaming Video
match ip dscp cs4 ! Recommended marking for Streaming-Video
class-map match-all Scavenger
match ip dscp cs1 ! Recommended marking for Scavenger traffic
!
policy-map WAN-EDGE
class Voice
priority percent 18 ! Voice gets 552 kbps of LLQ
class Interactive Video
priority percent 15 ! 384 kbps IP/VC needs 460 kbps of LLQ
class Call Signaling
bandwidth percent 5 ! Bandwidth guarantee for Call-Signaling
class Routing
bandwidth percent 3 ! Bandwidth guarantee for Routing
class Net Mgmt
bandwidth percent 2 ! Bandwidth guarantee for Network Management
class Mission-Critical Data
bandwidth percent 10 ! Mission-Critical data gets min 10% BW guarantee
fair-queue ! Applies FQ to Mission-Critical Data class
random-detect ! Enables WRED on Mission-Critical Data class
class Transactional Data
bandwidth percent 7 ! Transactional Data gets min 7% BW guarantee
fair-queue ! Applies FQ to Transactional Data class
random-detect dscp-based ! Enables DSCP-WRED on Transactional Data class
class Bulk Data
bandwidth percent 4 ! Bulk Data gets min 4% BW guarantee
fair-queue ! Applies FQ to Bulk Data class
random-detect dscp-based ! Enables DSCP-WRED on Bulk Data class
 class Streaming Video
bandwidth percent 10 ! Streaming-Video gets min 10% BW guarantee
class Scavenger
bandwidth percent 1 ! Scavenger class is throttled
class class-default
bandwidth percent 25 ! Class-Default gets min 25% BW guarantee
fair-queue ! Applies FQ to Class-Default
random-detect ! Enables WRED on Class-Default
!
WAN Edge Link-Specific QoS Design
The m ost popular WAN m edia in use t oday are leased lines, Fram e Relay, and ATM ( including
ATM- t o- Fram e Relay Service I nt erworking) . Each of t hese m edia can be deployed in t hree broad
cat egories of link speeds: slow speed ( 768 kbps) , m edium speed ( T1/ E1) , and high speed
( m ult iple T1/ E1 or great er) . The following sect ions det ail specific designs for each m edium at
each speed cat egory. Addit ionally, I SDN QoS design is discussed in t he cont ext of a backup WAN
link.

Leased Lines
Leased lines, or point - t o- point links, can be configured wit h HDLC, PPP, or MLP encapsulat ion.
MLP offers t he net work adm inist rat or t he m ost flexibilit y and deploym ent opt ions. For exam ple,
MLP is t he only leased- line prot ocol t hat support s LFI on slow- speed links ( t hrough MLP LFI ) .
Addit ionally, as bandwidt h requirem ent s grow over t im e, MLP requires t he fewest m odificat ions
t o accom m odat e t he addit ion of m ult iple T1/ E1 lines t o a WAN link bundle. Furt herm ore, MLP
support s all of t he securit y opt ions of PPP ( such as CHAP aut hent icat ion) .

Slow-Speed ( 768 kbps) Leased Lines

Re com m e n da t ion : Use MLP LFI and cRTP.

For slow- speed leased lines ( as illust rat ed in Figure 13- 7 ) , LFI is required t o m inim ize
serializat ion delay. MLP, t herefore, is t he only encapsulat ion opt ion on slow- speed leased lines
because MLP LFI is t he only m echanism available for fragm ent at ion and int erleaving on such
links. Opt ionally, cRTP can be enabled eit her as part of t he MQC policy m ap ( as shown in
Exam ple 13- 10 ) or under t he m ult ilink int erface ( using t he ip r t p h e a de r - com pr e ssion
com m and) . Ensure t hat MLP LFI and cRTP, if enabled, are configured on bot h ends of t he point -
t o- point link, as shown in Exam ple 13- 14 .

Figu r e 1 3 - 7 . Slow - Spe e d Le a se d Lin e s

Ex a m ple 1 3 - 1 0 . Slow - Spe e d ( 7 6 8 k bps) Le a se d- Lin e QoS D e sign

Ex a m ple
 !
policy-map WAN-EDGE
class Voice
priority percent 33 ! Maximum recommended LLQ value
compress header ip rtp ! Enables Class-Based cRTP
class Call Signaling
bandwidth percent 5 ! BW guarantee for Call-Signaling
... ! A 3 to 5 Class Model can be used
!
interface Multilink1
description 768 kbps Leased-Line to RBR-3745-Left
ip address 10.1.112.1 255.255.255.252
service-policy output WAN-EDGE ! Attaches the MQC policy to Mu1
ppp multilink
ppp multilink fragment delay 10 ! Limits serialization delay to 10 ms
ppp multilink interleave ! Enables interleaving of Voice with Data
ppp multilink group 1
!
...
!
interface Serial1/0
bandwidth 786
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1 ! Includes interface Ser1/0 into Mu1 group
!

Verificat ion com m ands:

sh ow policy

sh ow in t e r fa ce

sh ow policy in t e r fa ce

sh ow ppp m u lt ilin k

Verification Command: show interface

The sh ow in t e r fa ce com m and indicat es whet her drops are occurring on an int erface ( an
indicat ion of congest ion) . Addit ionally, on a m ult ilink int erface wit h LFI enabled, t he com m and
displays int erleaving st at ist ics, as shown in Exam ple 13- 11 .

Ex a m ple 1 3 - 1 1 . sh ow in t e r fa ce Verificat ion of MLP LFI on a Slow- Speed

Leased Line

WAG-7206-Left#show interface multilink 1

Multilink1 is up, line protocol is up
Hardware is multilink group interface
Description: 768 kbps Leased-Line to RBR-3745-Left
 Internet address is 10.1.112.1/30
MTU 1500 bytes, BW 768 Kbit, DLY 100000 usec,
reliability 255/255, txload 233/255, rxload 1/255
Encapsulation PPP, LCP Open, multilink Open
Open: CDPCP, IPCP, loopback not set
DTR is pulsed for 2 seconds on reset
Last input 00:00:01, output never, output hang never
Last clearing of "show interface" counters 00:16:15
Input queue: 0/75/0/0 (size/max/drops/flushes);
Total output drops: 49127
Queueing strategy: weighted fair
Output queue: 54/1000/64/49127/185507
(size/max total/threshold/drops/interleaves)

I n Exam ple 13- 11 , 49,127 drops have occurred on t he m ult ilink int erface ( because of
congest ion) , and LFI has engaged wit h 185,507 int erleaves of voice wit h dat a.

Verification Command: show policy interface (Three-Class Policy)

The sh ow policy in t e r fa ce com m and is probably t he m ost useful sh ow com m and for MQC-
based QoS policies. I t displays a wide array of dynam ic st at ist ics, including t he num ber of
m at ches on a class m ap as a whole, t he num ber of m at ches against each discret e m a t ch
st at em ent wit hin a class m ap, t he num ber of queued or dropped packet s ( eit her t ail dropped or
WRED dropped) , and m any ot her relevant QoS st at ist ics. Exam ple 13- 12 shows exam ple out put
of t he sh ow policy in t e r fa ce com m and.

Ex a m ple 1 3 - 1 2 . sh ow policy in t e r fa ce Verificat ion of a Three- Class Policy

on a Slow- Speed Leased Line

WAG-7206-Left#show policy interface multilink 1

Multilink1
Service-policy output: WAN-EDGE
Class-map: Voice (match-all)
68392 packets, 4377088 bytes
30 second offered rate 102000 bps, drop rate 0 bps
Match: ip dscp ef
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 33 (%)
Bandwidth 253 (kbps) Burst 6325 (Bytes)
(pkts matched/bytes matched) 68392/2043848
(total drops/bytes drops) 0/0
compress:
header ip rtp
UDP/RTP compression:
Sent: 68392 total, 68388 compressed,
2333240 bytes saved, 1770280 bytes sent
2.31 efficiency improvement factor
99% hit ratio, five minute miss rate 0 misses/sec,0 max
rate 41000 bps
Class-map: Call Signaling (match-any)
 251 packets, 142056 bytes
30 second offered rate 3000 bps, drop rate 0 bps
Match: ip dscp cs3
0 packets, 0 bytes
30 second rate 0 bps
Match: ip dscp af31
251 packets, 142056 bytes
30 second rate 3000 bps
Queueing
Output Queue: Conversation 265
Bandwidth 5 (%)
Bandwidth 38 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 255/144280
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
51674 packets, 28787480 bytes
30 second offered rate 669000 bps, drop rate 16000 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 36/458/0
WAG-7206-Left#

I n Exam ple 13- 12 , t he Voice class m ap and Call- Signaling class m ap are receiving m at ches on
t heir classificat ion crit eria ( DSCP EF and DSCP CS3/ AF31, respect ively) . However, because Cisco
I P Telephony product s current ly m ark Call- Signaling t raffic t o DSCP AF31, Call- Signaling t raffic is
m at ching only on DSCP AF31 in t his exam ple.

The last line of every class m ap out put is im port ant because t his line indicat es whet her any
drops are occurring on t his t raffic class. I n t his exam ple, t here are no drops in t he Voice or Call-
Signaling classes, which is t he desired behavior. A few drops are occurring in class- default , but
t his is expect ed when t he int erface is congest ed ( which is t he t rigger t o engage queuing) .

Also of not e, and specific t o t his part icular configurat ion, are t he cRTP st at ist ics included under
t he Voice class m ap. These cRTP st at ist ics are displayed because class- based cRTP was enabled
in t his exam ple ( inst ead of enabling cRTP on t he int erface) . Rem em ber, cRTP m ust be enabled
on bot h ends of t he links for com pression t o occur; ot herwise, t hese count ers will never
incr em ent .

Medium-Speed ( T1/E1) Leased Lines

Re com m e n da t ion : MLP LFI is not required; cRTP is opt ional.

Medium - speed leased lines ( as shown in Figure 13- 8 ) can use HDLC, PPP, or MLP encapsulat ion.
An advant age of using MLP encapsulat ion is t hat fut ure growt h ( t o m ult iple T1/ E1 links) will be
easier t o m anage. Also, MLP includes all t he securit y opt ions of PPP ( such as CHAP) .

Figu r e 1 3 - 8 . M e diu m - Spe e d Le a se d Lin e s

However, MLP LFI is not required at t hese speeds, and cRTP is opt ional. Exam ple 13- 13 shows
an exam ple configurat ion for m edium - speed leased lines.

Ex a m ple 1 3 - 1 3 . M e diu m - Spe e d Le a se d- Lin e QoS D e sign Ex a m ple

!
interface Multilink1
description T1 Leased-Line to RBR-3745-Left
ip address 10.1.112.1 255.255.255.252
service-policy output WAN-EDGE ! Attaches the MQC policy to Mu1
ppp multilink
ppp multilink group 1 ! Identifies Mu1 as logical Int for Mu1 group
!
...
!
interface Serial1/0
bandwidth 1536
no ip address
encapsulation ppp
load-interval 30
ppp multilink
ppp multilink group 1 ! Includes interface Ser1/0 into Mu1 group
!

Verificat ion com m ands:

sh ow policy

sh ow in t e r fa ce

sh ow policy in t e r fa ce

High-Speed (Multiple T1/E1 or Greater) Leased Lines

Re com m e n da t ion : Use MLP bundling, but keep an eye on CPU levels. When ent erprises have
m ult iple T1/ E1- speed leased lines t o individual branches, t hree opt ions exist for load sharing:

I P CEF per- dest inat ion load balancing

I P CEF per- packet load balancing

 Mult ilink PPP bundles

Cisco Technical Market ing t est ing has shown t hat I P CEF per- dest inat ion load balancing does not
m eet t he SLAs required for Voice and I nt eract ive- Video over m ult iple T1/ E1 links, as shown in
Figure 13- 9 .

Figu r e 1 3 - 9 . H igh - Spe e d Le a se d Lin e s

On t he ot her hand, I P- CEF per- packet load balancing did m eet t he required SLAs, but not quit e
as well as MLP bundling.

MLP bundling at t ained t he best overall SLA values for delay and j it t er, but it required m ore CPU
resources t han I P CEF per- packet load balancing. I f CPU levels are kept under t he recom m ended
75 percent , it is recom m ended t o use MLP bundling for m ult iple T1/ E1 links.

Also, if policy m aps t hat require bandwidt h st at em ent s on class- default are being at t ached t o t he
m ult ilink int erface, t he m a x - r e se r ve d- ba n dw idt h 1 0 0 com m and is required on t he int erface
before t he se r vice - policy ou t pu t st at em ent can be applied, as shown in Exam ple 13- 14 .

Ex a m ple 1 3 - 1 4 . H igh - Spe e d ( M u lt iple T1 / E1 ) Le a se d Lin e QoS

D e sign Ex a m ple

!
interface Multilink1
description Dual-T1 to RBR-3745-Left
ip address 10.1.112.1 255.255.255.252
max-reserved-bandwidth 100 ! Overrides the default 75% BW limit
service-policy output WAN-EDGE ! Attaches the MQC policy to Mu1
ppp multilink
ppp multilink group 1 ! Identifies Mu1 as logical int for Mu1 group
!
...
!
interface Serial1/0
bandwidth 1536 ! defined on physical interface only
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1 ! includes interface Ser1/0 into Mu1 group
!
interface Serial1/1
bandwidth 1536 ! defined on physical interface only
no ip address
 encapsulation ppp
ppp multilink
ppp multilink group 1 ! includes interface Ser1/1 into Mu1 group
!

N ot e
I nt erface ba n dw idt h com m ands ( not t o be confused wit h policy m ap CBWFQ
ba n dw idt h com m ands) should be defined only on t he physical int erfaces, not on
m ult ilink int erfaces. This way, if any physical int erfaces go down, t he Cisco I OS
Soft ware will reflect t he change in t he m ult ilink int erface's bandwidt h for rout ing and
QoS purposes. This change can be verified by t he sh ow in t e r fa ce com m and.
However, if a bandwidt h st at em ent is configured under t he m ult ilink int erface, t he
bandwidt h value for t he int erface will be st at ic even if an underlying physical int erface
is lost .

Verificat ion com m ands:

sh ow policy

sh ow in t e r fa ce

sh ow policy in t e r fa ce

sh ow ppp m u lt ilin k

Verification Command: show policy interface (QoS Baseline Policy)

A m ore com plex exam ple of t he sh ow policy in t e r fa ce com m and is given in Exam ple 13- 15 ,
where a QoS Baseline WAN edge policy is being applied t o a dual- T1 ( high- speed) leased line.

Ex a m ple 1 3 - 1 5 . sh ow policy in t e r fa ce Verificat ion of a QoS Baseline Policy

on a High- Speed Leased Line

WAG-7206-Left#show policy interface multilink 1

Multilink1
Service-policy output: WAN-EDGE
Class-map: Voice (match-all)
444842 packets, 28467338 bytes
30 second offered rate 434000 bps, drop rate 0 bps
Match: ip dscp ef
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 18 (%)
Bandwidth 552 (kbps) Burst 13800 (Bytes)
(pkts matched/bytes matched) 444842/28467338
 (total drops/bytes drops) 0/0
Class-map: Interactive Video (match-all)
32685 packets, 25977946 bytes
30 second offered rate 405000 bps, drop rate 0 bps
Match: ip dscp af41
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 15 (%)
Bandwidth 460 (kbps) Burst 11500 (Bytes)
(pkts matched/bytes matched) 32843/26097186
(total drops/bytes drops) 0/0
Class-map: Call Signaling (match-any)
1020 packets, 537876 bytes
30 second offered rate 7000 bps, drop rate 0 bps
Match: ip dscp cs3
0 packets, 0 bytes
30 second rate 0 bps
Match: ip dscp af31
1020 packets, 537876 bytes
30 second rate 7000 bps
Queueing
Output Queue: Conversation 265
Bandwidth 5 (%)
Bandwidth 153 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 1022/538988
(depth/total drops/no-buffer drops) 0/0/0
Class-map: Routing (match-all)
1682 packets, 112056 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs6
Queueing
Output Queue: Conversation 266
Bandwidth 3 (%)
Bandwidth 92 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 1430/95844
(depth/total drops/no-buffer drops) 0/0/0
Class-map: Net Mgmt (match-all)
32062 packets, 2495021 bytes
30 second offered rate 41000 bps, drop rate 0 bps
Match: ip dscp cs2
Queueing
Output Queue: Conversation 267
Bandwidth 2 (%)
Bandwidth 61 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 32256/2510284
(depth/total drops/no-buffer drops) 0/0/0
Class-map: Mission-Critical Data (match-all)
56600 packets, 40712013 bytes
30 second offered rate 590000 bps, drop rate 0 bps
Match: ip dscp 25
Queueing
Output Queue: Conversation 268
Bandwidth 12 (%)
Bandwidth 368 (kbps)
(pkts matched/bytes matched) 57178/41112815
 (depth/total drops/no-buffer drops) 10/0/0
exponential weight: 9
mean queue depth: 10
class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
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
3 57178/41112815 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-map: Transactional Data (match-all)
31352 packets, 31591979 bytes
30 second offered rate 435000 bps, drop rate 10000 bps
Match: ip dscp af21
Queueing
Output Queue: Conversation 269
Bandwidth 8 (%)
Bandwidth 245 (kbps)
(pkts matched/bytes matched) 31741/32008133
(depth/total drops/no-buffer drops) 29/954/0
exponential weight: 9
mean queue depth: 26
class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
0 0/0 0/0 0/0 20 40 1/10
1 0/0 0/0 0/0 22 40 1/10
2 30787/31019741 954/988392 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-map: Streaming Video (match-all)
23227 packets, 19293728 bytes
30 second offered rate 291000 bps, drop rate 0 bps
Match: ip dscp cs4
Queueing
Output Queue: Conversation 271
Bandwidth 10 (%)
Bandwidth 307 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 23683/19672892
(depth/total drops/no-buffer drops) 2/0/0

Class-map: Scavenger (match-all)

285075 packets, 129433625 bytes
30 second offered rate 2102000 bps, drop rate 2050000 bps
Match: ip dscp cs1
Queueing
Output Queue: Conversation 272
Bandwidth 1 (%)
Bandwidth 30 (kbps) Max Threshold 64 (packets)
 (pkts matched/bytes matched) 291885/132532775
(depth/total drops/no-buffer drops) 64/283050/0
Class-map: class-default (match-any)
40323 packets, 35024924 bytes
30 second offered rate 590000 bps, drop rate 0 bps
Match: any
Queueing
Output Queue: Conversation 273
Bandwidth 25 (%)
Bandwidth 768 (kbps)
(pkts matched/bytes matched) 41229/35918160
(depth/total drops/no-buffer drops) 12/268/0
exponential weight: 9
mean queue depth: 4
class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
0 40961/35700528 268/217632 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
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

I m port ant it em s t o not e for a given class are t he pk t s m a t ch e d st at ist ics ( which verify t hat
classificat ion has been configured correct ly and t hat t he packet s have been assigned t o t he
proper queue) and t he t ot a l dr ops st at ist ics ( which indicat e whet her adequat e bandwidt h has
been assigned t o t he class) .

Ext rem ely few drops, if any, are desired in t he Voice, I nt eract ive- Video, Call- Signaling, and
Rout ing classes.

N ot e
The Rout ing class is a special case because of t he st at ist ics t hat it displays.

On nondist ribut ed plat form s, t he classificat ion count er ( t he first line under t he class
m ap) shows any I GP t raffic m at ched by t he Rout ing class ( ident ified by DSCP CS6) .
But rem em ber t hat I GP prot ocols queue separat ely ( because t hese are handled by t he
PAK_priorit y m echanism ) and, t herefore, do not regist er queuing st at ist ics wit hin t he
MQC count ers for t he Rout ing class. EGP prot ocols ( such as BGP) , on t he ot her hand,
do regist er queuing/ dropping st at ist ics wit hin such an MQC class.

The sit uat ion is different on dist ribut ed plat form s, where all rout ing packet s ( I GP or
EGP) are m at ched and queued wit hin a provisioned Rout ing class ( com plet e wit h
queuing/ dropping st at ist ics t hrough t he sh ow policy in t e r fa ce verificat ion
com m and) .
Few drops are expect ed in t he Mission- Crit ical Dat a class. WRED ( essent ially RED because all
packet s are m arked t o t he sam e I PP/ DSCP value) is enabled t o avoid congest ion on t his class.
Som e drops are expect ed for t he Transact ional Dat a class, yet , in t his part icular exam ple, WRED
is m inim izing t ail drops for t his class.

I t is norm al for t he Bulk Dat a class t o show drops ( bot h WRED and t ail) . This is because t he Bulk
Dat a class is being const rained from dom inat ing bandwidt h by it s large and sust ained TCP
sessions. The Scavenger class should show very aggressive dropping during periods of
congest ion. Finally, it is norm al for drops t o appear in t he default class.

Verification Command: show ppp multilink

The sh ow ppp m u lt ilin k com m and is useful t o verify t hat m ult iple physical links are correct ly
associat ed and included in t he MLP bundle, as shown in Exam ple 13- 16 . Also, t he load ( which
m ight not quit e hit 255/ 255) indicat es congest ion on t he link.

Ex a m ple 1 3 - 1 6 . sh ow ppp m u lt ilin k Verificat ion of a High- Speed Leased

Line

WAG-7206-Left#show ppp multilink

Multilink1, bundle name is RBR-3745-Left
Bundle up for 00:28:33, 254/255 load
Receive buffer limit 24384 bytes, frag timeout 1000 ms
0/0 fragments/bytes in reassembly list
0 lost fragments, 2 reordered
0/0 discarded fragments/bytes, 0 lost received
0xE8F received sequence, 0x9A554 sent sequence
Member links: 2 active, 0 inactive (max not set, min not set)
Se1/0, since 00:28:35, 1920 weight, 1496 frag size
Se1/1, since 00:28:33, 1920 weight, 1496 frag size

Frame Relay
Re com m e n da t ion : For t he lat est feat ure com binat ions and m anagem ent opt ions, use class-
based Fram e Relay t raffic shaping whenever possible.

Fram e Relay net works are t he m ost popular WANs in use t oday because of t he low cost s
associat ed wit h t hem . Fram e Relay is a nonbroadcast m ult iaccess ( NBMA) t echnology t hat
frequent ly ut ilizes oversubscript ion t o achieve cost savings ( sim ilar t o airlines overselling seat s
on flight s t o achieve m axim um capacit y and profit abilit y) .

To m anage oversubscript ion and pot ent ial speed m ism at ches bet ween senders and receivers, a
t raffic- shaping m echanism m ust be used wit h Fram e Relay. Eit her Fram e Relay t raffic shaping
( FRTS) or class- based FRTS can be used. The prim ary advant age of using class- based FRTS is
m anagem ent because shaping st at ist ics and queuing st at ist ics are displayed j oint ly wit h t he
sh ow policy in t e r fa ce verificat ion com m and and are included in t he SNMPv2 Cisco class- based
QoS Managem ent I nform at ion Base ( MI B) .

FRTS and class- based FRTS require t he following param et ers t o be defined:
 Com m it t ed inform at ion rat e ( CI R)

Com m it t ed burst rat e ( Bc)

Excess burst rat e ( Be)

Minim um CI R

Fragm ent size ( required only on slow- speed links)

Committed Information Rate

Re com m e n da t ion : Set t he CI R t o 95 percent of t he PVC cont ract ed speed.

I n m ost Fram e Relay net works, a cent ral sit e's high- speed links connect t o lower- speed links
t o/ from m any rem ot e offices. For exam ple, consider a cent ral sit e t hat sends out dat a at 1.536
Mbps, while a rem ot e branch m ight have only a 56- kbps circuit int o it . This speed m ism at ch can
cause congest ion delays and drops. I n addit ion, t here is t ypically a m any- t o- one rat io of rem ot e
branches t o cent ral hubs, m aking it possible for m any rem ot e sit es t o send t raffic at a rat e t hat
can overwhelm t he T1 at t he hub. Bot h scenarios can cause fram e buffering in t he provider
net work, which int roduces j it t er, delay, and loss.

The only solut ion t o guarant ee service- level qualit y is t o use t raffic shaping at bot h t he cent ral
and rem ot e rout ers and t o define a consist ent CI R at bot h ends of t he Fram e Relay PVC. Because
t he FRTS m echanism does not t ake Fram e Relay overhead ( headers and cyclic redundancy
checks [ CRCs] ) int o account in it s calculat ions, it is recom m ended t hat t he CI R be set slight ly
below t he cont ract ed speed of t he PVC. Cisco Technical Market ing t est ing has shown t hat set t ing
t he CI R t o 95 percent of t he cont ract ed speed of t he PVC engages t he queuing m echanism
( LLQ/ CBWFQ) slight ly early and im proves service levels for Real- Tim e applicat ions, like Voice.

Committed Burst Rate

Re com m e n da t ion : Set t he Bc t o CI R/ 100 on nondist ribut ed plat form s and t o CI R/ 125 on
dist ribut ed plat form s.

Wit h Fram e Relay net works, you also need t o consider t he am ount of dat a t hat a node can
t ransm it at any given t im e. A 56- kbps PVC can t ransm it a m axim um of 56 kbps of t raffic in 1
second. Traffic is not sent during t he ent ire second, however, but only during a defined window
called t he int erval ( Tc) . The am ount of t raffic t hat a node can t ransm it during t his int erval is
called t he com m it t ed burst ( Bc) rat e. By default , Cisco I OS Soft ware set s t he Bc t o CI R/ 8. This
form ula is used for calculat ing t he Tc follows:

Tc = Bc / CI R

For exam ple, a CI R of 56 kbps is given a default Tc of 125 m s ( 7000 / 56,000) . I f t he 56- kbps
CI R is provisioned on a WAN aggregat or t hat has a T1 line- rat e clock speed, every t im e t he
rout er sends it s allocat ed 7000 bit s, it has t o wait 120.5 m s before sending t he next bat ch of
t raffic. Alt hough t his is a good default value for dat a, it is a bad choice for voice.

By set t ing t he Bc value t o a m uch lower num ber, you can force t he rout er t o send less t raffic per
int erval, but over m ore frequent int ervals per second. This result s in significant reduct ion in
shaping delays.

The opt im al configured value for Bc is CI R/ 100, which result s in a 10- m s int erval ( Tc = B / CI R) .

On dist ribut ed plat form s, t he Tc m ust be defined in 4- m s increm ent s. The nearest m ult iple of 4
m s wit hin t he 10- m s t arget is 8 m s. This int erval can be achieved by configuring t he Bc t o equal
CI R/ 125.

Excess Burst Rate

Re com m e n da t ion : Set t he Be t o 0.

I f t he rout er does not have enough t raffic t o send all of it s Bc ( 1000 bit s, for exam ple) , it can
" credit " it s account and send m ore t raffic during a lat er int erval. The m axim um am ount t hat can
be credit ed t o t he rout er's t raffic account is called t he excess burst ( Be) rat e. The problem wit h
Be in converged net works is t hat t his can creat e a pot ent ial for buffering delays wit hin a Fram e
Relay net work ( because t he receiving side can " pull" t he t raffic from a circuit only at t he rat e of
Bc, not Bc + Be) . To rem ove t his pot ent ial for buffering delays, it is recom m ended t o set t he Be
t o 0.

Minimum Committed Information Rate

Re com m e n da t ion : Set t he m inCI R t o CI R.

The m inim um CI R is t he t ransm it value t hat a Fram e Relay rout er will " rat e down" t o when
backward- explicit congest ion not ificat ions ( BECNs) are received. By default , Cisco I OS Soft ware
set s t he m inim um CI R t o CI R/ 2. However, t o m aint ain consist ent service levels, it is
recom m ended t hat adapt ive shaping be disabled and t hat t he m inim um CI R be set equal t o t he
CI R ( which m eans t here is no " rat ing down" ) . An except ion t o t his rule would occur if a t ool such
as Fram e Relay voice- adapt ive t raffic shaping was deployed ( for m ore inform at ion and
recom m endat ions on using FR- VATS, refer t o Chapt er 4 , " Policing and Shaping Tools" ) .

Slow-Speed ( 768 kbps) Frame Relay Links

Re com m e n da t ion : Enable FRF.12 and set t he fragm ent size for 10 m s m axim um serializat ion
delay. Enable cRTP.

As wit h all slow- speed links, slow Fram e Relay links ( as illust rat ed in Figure 13- 10 ) require a
m echanism for fragm ent at ion and int erleaving. I n t he Fram e Relay environm ent , t he t ool for
accom plishing t his is FRF.12.

Figu r e 1 3 - 1 0 . Slow - Spe e d Fr a m e Re la y Lin k s

Unlike MLP LFI , which t akes t he m axim um serializat ion delay as a param et er, FRF.12 requires
t he act ual fragm ent sizes t o be defined m anually. This requires som e addit ional calculat ions
because t he m axim um fragm ent sizes vary by link speed. These fragm ent sizes can be
calculat ed by m ult iplying t he provisioned line- clocking speed by t he recom m ended m axim um
serializat ion delay t arget ( 10 m s) , and convert ing t he result from bit s t o byt es ( which is done by
dividing t he result by 8) :

Fragm ent Size in Byt es = ( Link Speed in kbps * Maxim um Allowed Jit t er in m s) / 8

For exam ple, t he calculat ion for t he m axim um fragm ent size for a 56- kbps circuit is as follows:

Fragm ent Size = ( 56 kbps * 10 m s) / 8 = 70 Byt es

Table 13- 1 shows t he recom m ended values for FRF.12 fragm ent sizes, CI R, and Bc for slow-
speed Fram e Relay links.

56 kbps

70 byt es

53,200 bps

532 bit s per Tc

64 kbps

80 byt es

60,800 bps

608 bit s per Tc

128 kbps

160 byt es

121,600 bps

1216 bit s per Tc

256 kbps

320 byt es

243,200 bps

2432 bit s per Tc

512 kbps

640 byt es

486,400 bps

4864 bit s per Tc

768 kbps

960 byt es

729,600 bps

7296 bit s per Tc

 Ta ble 1 3 - 1 . Re com m e n de d Fr a gm e n t Size s, CI R, a n d Bc
Va lu e s for Slow - Spe e d Fr a m e Re la y Lin k s

M a x im u m Fr a gm e n t Re com m e n de d Re com m e n de d
Size ( for 1 0 - m s CI R Va lu e s Bc Va lu e s
PVC Spe e d D e la y)

Bot h FRTS and class- based FRTS require a Fram e Relay m ap class t o be applied t o t he DLCI .
Also in bot h cases, t he fr a m e - r e la y fr a gm e n t com m and is applied t o t he m ap class. However,
unlike FRTS, class- based FRTS does not require fr a m e - r e la y t r a ffic- sh a pin g t o be enabled on
t he m ain int erface. This is because MQC- based/ class- based FRTS requires a hierarchal ( or
nest ed) QoS policy t o accom plish bot h shaping and queuing. This hierarchical policy is at t ached
t o t he Fram e Relay m ap class, which is bound t o t he DLCI .

As wit h slow- speed leased- line policies, cRTP can be enabled wit hin t he MQC queuing policy
under t he Voice class. Exam ple 13- 17 shows an exam ple of slow- speed Fram e Relay link- specific
configurat ion.

Ex a m ple 1 3 - 1 7 . Slow - Spe e d ( 7 6 8 k bps) Fr a m e Re la y QoS D e sign

Ex a m ple

!
policy-map MQC-FRTS-768
class class-default
shape average 729600 7296 0 ! Enables MQC-Based FRTS
service-policy WAN-EDGE ! Queues packets headed to the shaper
!
...
!
interface Serial2/0
no ip address
encapsulation frame-relay
!
interface Serial2/0.12 point-to-point
ip address 10.1.121.1 255.255.255.252
description 768kbps FR Circuit to RBR-3745-Left
frame-relay interface-dlci 102
class FR-MAP-CLASS-768 ! Binds the map-class to the FR DLCI
!
...
!
map-class frame-relay FR-MAP-CLASS-768
service-policy output MQC-FRTS-768 ! Attaches nested MQC policies to map-class
frame-relay fragment 960 ! Enables FRF.12
!

Verificat ion com m ands:

 sh ow policy m a p

sh ow policy- m a p in t e r fa ce

sh ow fr a m e - r e la y fr a gm e n t

Verification Command: show frame-relay fragment

The sh ow fr a m e - r e la y fr a gm e n t com m and, shown in Exam ple 13- 18 , provides verificat ion of
t he fragm ent size, regardless of whet her regular FRF.12 fragm ent at ion or Fram e Relay voice-
adapt ive t raffic shaping ( and fragm ent at ion) is configured for a DLCI . Addit ionally, dynam ic
count ers m onit or how m any fram es required fragm ent at ion in eit her direct ion.

Ex a m ple 1 3 - 1 8 . sh ow fr a m e - r e la y fr a gm e n t Verificat ion of a Slow- Speed

Fram e Relay Link

WAG-7206-Left#show frame-relay fragment 102

interface dlci frag-type frag-size in-frag out-frag dropped-frag
Serial2/0.12 102 end-to-end 960 5476 2035 0
WAG-7206-Left#

Medium-Speed ( T1/E1) Frame Relay Links

Re com m e n da t ion : FRF.12 is not required. cRTP is opt ional.

The configurat ion for m edium - speed Fram e Relay links, illust rat ed in Figure 13- 11 and det ailed
in Exam ple 13- 19 , is ident ical t o t hat for slow- speed Fram e Relay links, wit h t he except ion t hat
enabling FRF.12 no longer is required.

Figu r e 1 3 - 1 1 . M e diu m - Spe e d Fr a m e Re la y Lin k s

N ot e
I n som e cases, however, adm inist rat ors have chosen t o enable FRF.12 on T1/ E1 speed
links, even t hough t he fragm ent size for a 10- m s m axim um serializat ion delay at such
speeds is great er t han t he MTU of Et hernet ( 1500 byt es) . The rat ionale behind doing
so is t o ret ain t he Fram e Relay dual- FI FO queuing m echanism at Layer 2 ( discussed in
 Chapt er 5 , " Congest ion- Managem ent Tools" ) , which can provide slight ly superior
service levels under cert ain condit ions. Generally, t his is not required, however.

Ex a m ple 1 3 - 1 9 . M e diu m - Spe e d ( T1 / E1 ) Fr a m e Re la y QoS D e sign

Ex a m ple

!
policy-map MQC-FRTS-1536
class class-default
shape average 1460000 14600 0 ! Enables MQC-Based FRTS
service-policy WAN-EDGE ! Queues packets headed to the shaper
!
...
!
interface Serial2/0
no ip address
encapsulation frame-relay
!
interface Serial2/0.12 point-to-point
ip address 10.1.121.1 255.255.255.252
description 1536kbps FR Circuit to RBR-3745-Left
frame-relay interface-dlci 102
class FR-MAP-CLASS-1536 ! Binds the map-class to the FR DLCI
!
...
!
map-class frame-relay FR-MAP-CLASS-1536
service-policy output MQC-FRTS-1536 ! Attaches nested MQC policies to map-class
!

Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

High-Speed (Multiple T1/E1 and Greater) Frame Relay Links

Re com m e n da t ion : Use I P CEF per- packet load balancing for load sharing across m ult iple
physical Fram e Relay links.

When m ult iple Fram e Relay circuit s exist bet ween a cent ral WAN aggregat ion rout er and a
rem ot e branch rout er, as illust rat ed in Figure 13- 12 , it is recom m ended t hat I P CEF per- packet
load balancing be used t o load- share bet ween t he links. Mult ilink PPP over Fram e Relay
( MLPoFR) bundles are com plex t o configure and difficult t o m anage, whereas I P CEF per- packet
load balancing is not and has t he lowest CPU im pact of t he load- sharing m echanism s. Therefore,
I P CEF per- packet load balancing is recom m ended across m ult iple Fram e Relay links t o t he sam e
br anch.
 Figu r e 1 3 - 1 2 . H igh - Spe e d Fr a m e Re la y Lin k s

N ot e
I t is im port ant t o keep in m ind t hat providers m ight have geographically dispersed
pat hs t o t he sam e sit es; t herefore, t he delay on one T1 FR link m ight be slight ly higher
or lower t han t he delay on anot her. This could cause TCP sequencing issues and
slight ly reduce effect ive dat a applicat ion t hroughput . Net work adm inist rat ors should
keep t hese fact ors in m ind when planning t heir WAN t opologies.

The m a x - r e se r ve d- ba n dw idt h 1 0 0 com m and is not required on t he int erfaces because t he

queuing policy is not applied direct ly t o t he int erface; inst ead, it is applied t o anot her policy ( t he
MQC- based Fram e Relay t raffic- shaping policy) . Exam ple 13- 20 shows t he configurat ion for a
high- speed Fram e Relay link.

Ex a m ple 1 3 - 2 0 . H igh - Spe e d ( M u lt iple T1 / E1 ) Fr a m e Re la y QoS

D e sign Ex a m ple

!
policy-map MQC-FRTS-1536
class class-default
shape average 1460000 14600 0 ! Enables MQC-Based FRTS
service-policy WAN-EDGE ! Queues packets headed to the shaper
!
...
!
interface Serial2/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
!
interface Serial2/0.12 point-to-point
description 1536kbps FR Circuit to RBR-3745-Left
ip address 10.1.121.1 255.255.255.252
ip load-sharing per-packet ! Enables IP CEF Per-Packet Load-Sharing
frame-relay interface-dlci 102
class FR-MAP-CLASS-1536 ! Binds the map-class to FR DLCI 102
 !
interface Serial2/1
no ip address
encapsulation frame-relay
serial restart_delay 0
!
interface Serial2/1.12 point-to-point
description 1536kbps FR Circuit to RBR-3745-Left
ip address 10.1.121.5 255.255.255.252
ip load-sharing per-packet ! Enables IP CEF Per-Packet Load-Sharing
frame-relay interface-dlci 112
class FR-MAP-CLASS-1536 ! Binds the map-class to FR DLCI 112
!
...
!
map-class frame-relay FR-MAP-CLASS-1536
service-policy output MQC-FRTS-1536 ! Attaches nested MQC policies to map-class
!

Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

Distributed Platform Frame Relay Links

Re com m e n da t ion : Set CI R values t o m ult iples of 8000. Set t he Bc t o CI R/ 125.

When port ed t o dist ribut ed- plat form WAN aggregat ors ( such as t he Cisco 7500 VI P) , m ost
policies require lit t le m ore t han ensuring t hat I P CEF is running in dist ribut ed m ode. However,
FRTS is not support ed in a dist ribut ed environm ent , so anot her shaping t ool is required.
Dist ribut ed t raffic shaping ( dTS) can be used in conj unct ion wit h hierarchical MQC policies t o
achieve a sim ilar effect on t raffic flows over dist ribut ed Fram e Relay WAN links. Figure 13- 13
shows a Fram e Relay link hom ed from a dist ribut ed- plat form WAN aggregat or.

Figu r e 1 3 - 1 3 . D ist r ibu t e d- Pla t for m Fr a m e Re la y Lin k s

Alt hough dTS on t he Cisco 7500 is very sim ilar t o MQC- based FRTS on nondist ribut ed plat form s,
t here are t wo m ain caveat s t o keep in m ind. The first is t hat t he CI R m ust be defined in
m ult iples of 8000. Therefore, it is recom m ended t hat t he CI R be defined as 95 percent of t he
PVC speed, rounded down t o t he nearest m ult iple of 8000. The second caveat is t hat t he Cisco
7500 VI P requires t he Tc t o be defined in an increm ent of 4 m s. Because t he t arget int erval for
all plat form s is 10 m s, which is not evenly divisible by 4 m s, t he recom m endat ion for t he Cisco
7500 VI P is t o use an int erval of 8 m s. The int erval can be set t o 8 m s by defining t he burst
using t he following form ula:

Bc = CI R/ 125

Table 13- 2 gives recom m ended values for fragm ent sizes, CI R, and Bc for dist ribut ed plat form s.
( Som e values have been slight ly rounded for configurat ion and m anagem ent sim plicit y.)

56 kbps

70 byt es

48,000 bps

384 bit s per Tc

64 kbps

80 byt es

56,000 bps

448 bit s per Tc

128 kbps

160 byt es

120,000 bps

960 bit s per Tc

256 kbps

320 byt es

240,000 bps

1920 bit s per Tc

512 kbps

640 byt es

480,000 bps

3840 bit s per Tc

768 kbps

960 byt es

720,000 bps
5760 bit s per Tc

1536 kbps

1,440,000 bps

11520 bit s per Tc

2048 kbps

1,920,000 bps

15360 bit s per Tc

Ta ble 1 3 - 2 . Re com m e n de d Fr a gm e n t Size s, CI R, a n d Bc

Va lu e s for D ist r ibu t e d Pla t for m Fr a m e Re la y Lin k s

M a x im u m Fr a gm e n t Re com m e n de d Re com m e n de d
Size ( for 1 0 - m s CI R Va lu e s Bc Va lu e s
PVC Spe e d D e la y)

Ex a m ple 1 3 - 2 1 . D ist r ibu t e d Pla t for m Fr a m e Re la y QoS D e sign ( Slow -

Spe e d Lin k ) Ex a m ple

!
!
ip cef distributed ! 'distributed' keyword required on 7500 for ip cef
!
...
!
policy-map MQC-DTS-768
class class-default
shape average 720000 5760 0 ! Enables Distributed Traffic Shaping
service-policy WAN-EDGE ! Queues packets headed to the shaper
!
...
!
interface Serial1/1/0
no ip address
encapsulation frame-relay
no fair-queue
!
interface Serial1/1/0.12 point-to-point
description 768kbps FR DLCI to RBR-3745-Left
ip address 10.1.121.1 255.255.255.252
frame-relay interface-dlci 102
class FR-MAP-CLASS-768 ! Binds the map-class to the FR-DLCI
!
...
!
 map-class frame-relay FR-MAP-CLASS-768
service-policy output MQC-DTS-768 ! Attaches nested MQC policies to map-class
frame-relay fragment 960 ! Enables FRF.12
!

Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

sh ow fr a m e - r e la y fr a gm e n t ( on slow- speed links only)

ATM
As wit h Fram e Relay, ATM is an NBMA m edium t hat perm it s oversubscript ion and speed
m ism at ches, and t hus requires shaping t o guarant ee service levels. I n ATM, however, shaping is
included as part of t he PVC definit ion.

Two opt ions exist for carrying voice t raffic over slow- speed ATM PVCs: eit her Mult ilink PPP over
ATM ( MLPoATM) , in conj unct ion wit h MLP LFI , or ATM PVC bundling. ATM PVC bundling is a
legacy t echnique t hat has drawbacks such as inefficient bandwidt h ut ilizat ion and classificat ion
lim it at ions ( I P precedence versus DSCP) . But som et im es service providers m ake ATM PVC
bundles econom ically at t ract ive t o ent erprise cust om ers, so bot h approaches are discussed.

Slow-Speed ( 768 kbps) ATM Links: MLPoATM

Re com m e n da t ion : Use MLP LFI . Tune t he ATM PVC Tx- ring t o 3. cRTP can be used only in
Cisco I OS Release 12.2( 2) T or lat er.

Serializat ion delays on slow- speed ATM links, as shown in Figure 13- 4 , necessit at e a
fragm ent at ion and int erleaving m echanism . The m ost com m on ATM adapt at ion layers ( such as
AAL5) do not have sequence num bers in t he cell headers and, t hus, require cells t o arrive in t he
correct order. This requirem ent m akes int erleaving a problem t hat cannot be solved at t hese
ATM adapt at ion layers and t hus m ust be solved at a higher layer.

Figu r e 1 3 - 1 4 . Slow - Spe e d M LPoATM Lin k s

A solut ion t o t his problem is t o run MLPoATM and let MLP LFI handle any necessary
fragm ent at ion and int erleaving so t hat such operat ions are com plet ely t ransparent t o t he lower
ATM layer. As far as t he ATM layer is concerned, all cells arrive in t he sam e order t hey were
sent .

MLPoATM funct ionalit y is enabled t hrough t he use of virt ual- access int erfaces. Virt ual- access
int erfaces are built on dem and from virt ual- t em plat e int erfaces and inherit t heir configurat ion
propert ies from t he virt ual t em plat es t hey are built from . Thus, t he I P address, se r vice - policy
st at em ent , and LFI param et ers all are configured on t he virt ual t em plat e, as shown in Exam ple
13- 22 .

cRTP is support ed only on ATM PVCs ( t hrough MLPoATM) , as of Cisco I OS Release 12.2( 2) T.

Addit ionally, as discussed previously in t his chapt er and in Chapt er 5 , it is recom m ended t hat
t he value of t he final out put buffer, t he Tx- ring, be t uned on slow- speed ATM PVCs t o a value of
t hree part icles t o m inim ize serializat ion delay.

Ex a m ple 1 3 - 2 2 . Slow - Spe e d ( 7 6 8 k bps) M LPoATM QoS D e sign

Ex a m ple

!
interface ATM4/0
bandwidth 768
no ip address
no atm ilmi-keepalive
!
interface ATM4/0.60 point-to-point
pvc BRANCH#60 0/60
vbr-nrt 768 768 ! ATM PVC definition
tx-ring-limit 3 ! Per-PVC Tx-ring is tuned to 3 particles
protocol ppp Virtual-Template60 ! PVC is bound to the Virtual-Template
!
interface Virtual-Template60
bandwidth 768
ip address 10.200.60.1 255.255.255.252
service-policy output WAN-EDGE ! Attaches MQC policy to Virtual-Template
ppp multilink
ppp multilink fragment-delay 10 ! Enables MLP Fragmentation
ppp multilink interleave ! Enables MLP Interleaving
!

N ot e
When using virt ual t em plat es for low- speed ATM links, keep t he following in m ind:

The dynam ic nat ure of virt ual- t em plat e int erfaces m ight m ake net work
m anagem ent unwieldy.

MLPoATM can be support ed only on hardware t hat support s per- VC t raffic

shaping.
Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

sh ow a t m pvc

Verification Command: show atm pvc

I n ATM, t he lengt h of t he Tx- ring is defined in part icles, not packet s. The size of a part icle varies
according t o hardware. For exam ple, on a Cisco 7200 PA- A3, part icles are 580 byt es ( including a
4- byt e ATM core header) . This m eans t hat a 1500- byt e packet would require t hree part icles of
buffering. Furt herm ore, ATM defines Tx- rings on a per- PVC basis, as shown in Exam ples 13- 23
and 13- 24 .

Ex a m ple 1 3 - 2 3 . Ba sic ATM PVC Con figu r a t ion Ex a m ple

!
interface ATM3/0.1 point-to-point
ip address 10.2.12.1 255.255.255.252
pvc 0/12
vbr-nrt 768 768 ! ATM PVC definition
!
!

The size of a default Tx- ring can be ascert ained using t he sh ow a t m pvc com m and ( an out put
m odifier is used t o focus on t he relevant port ion of t he out put ) , as shown in Exam ple 13- 28 .

Ex a m ple 1 3 - 2 4 . sh ow a t m pvc Verificat ion of Tx- ring Set t ing

WAG-7206-Left#show atm pvc 0/12 | include TxRingLimit

VC TxRingLimit: 40 particles

The out put shows t hat t he Tx- ring is set , in t his inst ance, t o a default value of 40 part icles. The
Tx- ring for t he PVC can be t uned t o t he recom m ended set t ing of 3 using t he t x - r in g- lim it
com m and under t he PVC's definit ion, as shown in Exam ple 13- 25 .

Ex a m ple 1 3 - 2 5 . Tu n in g a n ATM PVC Tx - r in g

WAG-7206-Left(config)#interface atm 3/0.1

WAG-7206-Left(config-subif)#pvc 0/12
WAG-7206-Le(config-if-atm-vc)#tx-ring-limit 3
The new set t ing can be verified quickly wit h t he sam e sh ow a t m pvc com m and variat ion, as
shown in Exam ple 13- 25 ( see Exam ple 13- 26 ) .

Ex a m ple 1 3 - 2 6 . sh ow a t m pvc Verificat ion of Tx- ring Set t ing Aft er Tuning

WAG-7206-Left#show atm pvc 0/12 | include TxRingLimit

VC TxRingLimit: 3 particles

Slow-Speed ( 768 kbps) ATM Links: ATM PVC Bundles

Re com m e n da t ion : Queuing policies for voice are not required ( because voice uses a dedicat ed
ATM PVC) . Tune t he ATM PVC Tx- ring t o 3.

An alt ernat ive opt ion t o provisioning QoS on slow- speed ATM PVCs is t o use PVC bundles, as
illust rat ed in Figure 13- 15 . PVC bundles consist of t wo ( or m ore) PVCs wit h different ATM t raffic
cont ract s, grouped t oget her in a logical associat ion in which I PP levels det erm ine t he PVC t o
which t he packet will be direct ed. The decision t o use PVC bundles inst ead of MLPoATM for slow-
speed ATM links is usually a m at t er of econom ics ( because service providers oft en offer
at t ract ive pricing for PVC bundles) and configurat ion/ m anagem ent com plexit y com fort levels.

Figu r e 1 3 - 1 5 . Slow - Spe e d ATM PVC Bu n dle s

I n Exam ple 13- 27 , one PVC ( for voice) has a variable bit rat e, non- real- t im e ( VBR- nrt ) ATM
t raffic cont ract and an adm ission crit erion of I PP 5, while anot her PVC ( for dat a) has an
unspecified bit rat e ( UBR) ATM t raffic cont ract and accept s all ot her precedence levels.

Again, it is also recom m ended t hat t he TX- ring be t uned t o 3 on such slow- speed ATM PVCs.

Ex a m ple 1 3 - 2 7 . Slow - Spe e d ( 7 6 8 k bps) ATM PVC Bu n dle s QoS

D e sign Ex a m ple

!
class-map match-any Call Signaling
match ip dscp cs3
match ip dscp af31
class-map match-any Critical Data
match ip dscp cs6
match ip dscp af21
 match ip dscp cs2
!
!
policy-map WAN-EDGE-DATA-PVC ! Only data queuing is required (no voice)
class Call Signaling
bandwidth percent 5
class Critical Data
bandwidth percent 40
class class-default
fair-queue
!
vc-class atm VOICE-PVC-256 ! Voice PVC-class definition
vbr-nrt 256 256 ! Voice ATM PVC definition
tx-ring-limit 3 ! Per-PVC Tx-ring is tuned to 3 particles
precedence 5 ! Only IPP5 traffic (voice) can use this PVC
no bump traffic ! Traffic will not be accepted from other PVCs
protect vc ! Optional: Protects VC status of Voice PVC
!
vc-class atm DATA-PVC-512 ! Data PVC-class definition
ubr 512 ! Data ATM PVC definition
tx-ring-limit 3 ! Per-PVC Tx-ring is tuned to 3 particles
precedence other ! All other IPP values (data) use this PVC
!
...
!
interface ATM3/0
no ip address
no atm ilmi-keepalive
!
interface ATM3/0.60 point-to-point
ip address 10.200.60.1 255.255.255.252
bundle BRANCH#60
pvc-bundle BRANCH60-DATA 0/60
class-vc DATA-PVC-512 ! Assigns PVC to data-class
service-policy output WAN-EDGE-DATA-PVC ! Attaches (data) MQC policy to PVC
pvc-bundle BRANCH60-VOICE 0/600
class-vc VOICE-PVC-256 ! Assigns PVC to voice-class
!

A m aj or drawback t o PVC bundling is t hat dat a never can get access t o t he voice PVC, even if
t here is available bandwidt h in it . This forces subopt im al consum pt ion of WAN bandwidt h.

Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

sh ow a t m pvc

sh ow a t m vc

sh ow a t m bu n dle
Verification Command: show atm vc

The sh ow a t m vc com m and det ails t he configured ATM PVCs and highlight s t heir encapsulat ion,
ATM t raffic cont ract s ( or service cont ract s) , st at us, and act ivit y, as shown in Exam ple 13- 28 .

Ex a m ple 1 3 - 2 8 . sh ow a t m vc Verificat ion of ATM PVC Definit ions and

Act ivit y

WAN-AGG-7200#show atm vc
VCD / Peak Avg/Min Burst
Interface Name VPI VCI Type Encaps SC Kbps Kbps Cells Sts
3/0.60 BRANCH60-DATA 0 60 PVC SNAP UBR 512 512 1145 UP
3/0.60 BRANCH60-VOICE 0 600 PVC SNAP VBR 256 256 94 UP
WAN-AGG-7200#

Verification Command: show atm bundle

The sh ow a t m bu n dle com m and provides det ails on t he configured and current adm ission
crit eria for individual ATM PVCs. I n Exam ple 13- 29 , PVC 0/ 600 ( t he voice PVC) accept s only
t raffic t hat has been m arked t o I PP 5 ( voice) . All ot her I PP values ( 0 t o 4 and 6 t o 7) are
assigned t o PVC 0/ 60 ( t he dat a PVC) . This com m and also shows t he act ivit y for each PVC.

Ex a m ple 1 3 - 2 9 . sh ow a t m bu n dle Verificat ion of ATM PVC Bundle

Definit ions and Act ivit y

WAN-AGG-7200#show atm bundle

BRANCH#60 on ATM3/0.60: UP
Config Current Bumping PG/ Peak Avg/Min Burst
VC Name VPI/ VCI Prec/Exp Prec/Exp PrecExp/ PV Kbps kbps Cells Sts
Accept
BRANCH60-DATA 0/60 7-6, 4-0 7-6, 4-0 - / Yes - 512 512 1145 UP
BRANCH60-VOICE 0/600 5 5 - / No PV 256 256 94 UP
WAN-AGG-7200#

Medium-Speed ( T1/E1) ATM Links

Re com m e n da t ion : Use ATM inverse m ult iplexing over ATM ( I MA) t o keep fut ure expansion
easy t o m anage. No LFI is required. cRTP is opt ional.

ATM I MA is a nat ural choice for m edium - speed ATM links, as shown in Figure 13- 16 . Alt hough
t he inverse- m ult iplexing capabilit ies are not used at t hese speeds, I MA int erfaces m ake fut ure
expansion t o high- speed links easy t o m anage ( as will be dem onst rat ed bet ween Exam ple 13- 30
and t he high- speed ATM link in Exam ple 13- 35 ) .

Figu r e 1 3 - 1 6 . M e diu m - Spe e d ATM Lin k s

Ex a m ple 1 3 - 3 0 . M e diu m - Spe e d ( T1 / E1 ) ATM I M A QoS D e sign Ex a m ple

!
interface ATM3/0
no ip address
no atm ilmi-keepalive
ima-group 0 ! ATM3/0 added to ATM IMA group 0
no scrambling-payload
!
...
!
interface ATM3/IMA0
no ip address
no atm ilmi-keepalive
!
interface ATM3/IMA0.12 point-to-point
ip address 10.200.60.1 255.255.255.252
description T1 ATM-IMA to Branch#60
pvc 0/100
vbr-nrt 1536 1536 ! ATM PVC defined under ATM IMA sub-int
max-reserved-bandwidth 100 ! Overrides the default 75% BW limit
service-policy output WAN-EDGE ! Attaches MQC policy to PVC
!
!

Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

sh ow a t m pvc

sh ow im a in t e r fa ce a t m

High-Speed (Multiple T1/E1) ATM Links

Re com m e n da t ion : Use ATM I MA and add m em bers t o t he I MA group, as needed.

Previous opt ions for accom m odat ing m ult iple T1/ E1 links were soft ware- based load- sharing
solut ions ( MLP bundling and I P CEF per- packet load sharing) . As such, t hese m et hods require
addit ional CPU cycles t o accom m odat e load- sharing m ult iple physical links. However, wit h ATM
I MA, inverse m ult iplexing over m ult iple T1/ E1 links, illust rat ed in Figure 13- 17 , is done in
hardware on t he port adapt or/ net work m odule. Therefore, ATM I MA scales m uch m ore
efficient ly.

Figu r e 1 3 - 1 7 . H igh - Spe e d ATM Lin k s

As m ent ioned, ATM I MA m akes bandwidt h expansion easy t o m anage. For exam ple, all t hat is
required t o add anot her T1 line t o t he previous exam ple is t o add an im a - gr ou p st at em ent t o
t he next ATM int erface and increase t he PVC speed, as shown in Exam ple 13- 31 .

Ex a m ple 1 3 - 3 1 . H igh - Spe e d ( M u lt iple T1 / E1 a n d Gr e a t e r ) ATM I M A

QoS D e sign Ex a m ple

!
interface ATM3/0
no ip address
no atm ilmi-keepalive
ima-group 0 ! ATM3/0 added to ATM IMA group 0
no scrambling-payload
!
interface ATM3/1
no ip address
no atm ilmi-keepalive
ima-group 0 ! ATM3/1 added to ATM IMA group 0
no scrambling-payload
!
...
!
interface ATM3/IMA0
no ip address
no atm ilmi-keepalive
!
interface ATM3/IMA0.12 point-to-point
ip address 10.6.12.1 255.255.255.252
pvc 0/100
vbr-nrt 3072 3072 ! ATM PVC speed expanded
max-reserved-bandwidth 100 ! Overrides the default 75% BW limit
service-policy output WAN-EDGE ! Attaches MQC policy to PVC
!
!
Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

sh ow a t m pvc

sh ow im a in t e r fa ce a t m

Verification Command: show ima interface atm

The sh ow im a in t e r fa ce a t m com m and is useful for verifying t hat all m em bers of an ATM I MA
group are act ive. See Exam ple 13- 32 .

Ex a m ple 1 3 - 3 2 . sh ow im a in t e r fa ce a t m Verificat ion of ATM I MA Group

WAG-7206-Left#show ima interface atm 3/ima0

Interface ATM3/IMA0 is up
Group index is 1
Ne state is operational, failure status is noFailure
Active links bitmap 0x3
IMA Group Current Configuration:
Tx/Rx configured links bitmap 0x3/0x3
Tx/Rx minimum required links 1/1
Maximum allowed diff delay is 25ms, Tx frame length 128
Ne Tx clock mode CTC, configured timing reference link ATM3/0
Test pattern procedure is disabled
IMA Group Current Counters (time elapsed 257 seconds):
0 Ne Failures, 0 Fe Failures, 0 Unavail Secs
IMA Group Total Counters (last 5 15 minute intervals):
0 Ne Failures, 0 Fe Failures, 0 Unavail Secs
IMA link Information:
Link Physical Status NearEnd Rx Status Test Status
---- --------------- ----------------- -----------
ATM3/0 up active disabled
ATM3/1 up active disabled
ATM3/2 administratively down unusableInhibited disabled
ATM3/3 administratively down unusableInhibited disabled

Very-High-Speed (DS3-OC3+) ATM Links

Re com m e n da t ion : Use newer hardware plat form s and keep an eye on CPU levels.

Maj or sit e- t o- sit e int erconnect ions drift slight ly away from t he t radit ional WAN
aggregat or/ rem ot e branch rout er m odels. I n sit e- t o- sit e scenarios, as illust rat ed in Figure 13- 18
, t he WAN edge rout ers usually support only one or t wo links, as opposed t o dozens or hundreds
of links t hat t ypical WAN aggregat ors support . However, in a sit e- t o- sit e scenario, t he
int erconnect ing links are running at far higher speeds t han m ost rem ot e branch links.

Figu r e 1 3 - 1 8 . Ve r y H igh - Spe e d ( D S3 - OC3 + ) ATM Lin k s

The policies and design principles do not change for sit e- t o- sit e scenarios. The m ain
considerat ion is t he perform ance of t he WAN edge rout er. Alt hough newer plat form s handle
com plex policies m ore efficient ly, it is st ill highly recom m ended t hat proof- of- concept t est ing of
t he plat form s involved be perform ed before im plem ent ing policies at such crit ical j unct ions in t he
net work. Exam ple 13- 33 illust rat es a sit e- t o- sit e QoS policy applied t o a very- high- speed ATM
( OC3) link.

Ex a m ple 1 3 - 3 3 . Ve r y H igh - Spe e d ( D S3 - OC3 + ) ATM Lin k QoS D e sign

Ex a m ple

!
interface ATM3/0
no ip address
load-interval 30
no atm ilmi-keepalive
!
interface ATM3/0.1 point-to-point
ip address 10.2.12.1 255.255.255.252
pvc 0/12
vbr-nrt 149760 149760 ! ATM OC3 PVC definition
max-reserved-bandwidth 100 ! Overrides the default 75% BW limit
service-policy output WAN-EDGE ! Attaches MQC policy to PVC
!
!

Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

sh ow a t m pvc

ATM-to-Frame Relay Service Interworking

Many ent erprises are deploying converged net works t hat use ATM at t he cent ral sit e and Fram e
Relay at t he rem ot e branches. The m edia conversion is accom plished t hrough ATM- t o- Fram e
Relay Service I nt erworking ( SI W or FRF.8) in t he carrier net work.

FRF.12 cannot be used because, current ly, no service provider support s FRF.12 t erm inat ion in
t he Fram e Relay cloud. I n fact , no Cisco WAN swit ching devices support FRF.12. Tunneling
FRF.12 t hrough t he service provider's net work does no good because t here is no FRF.12
st andard on t he ATM side. This is a problem because fragm ent at ion is a requirem ent if any of
t he rem ot e Fram e Relay sit es uses a circuit speed of 768 kbps or below. However, MLPoATM and
MLPoFR provide an end- t o- end, Layer 2 fragm ent at ion and int erleaving m et hod for low- speed
ATM t o Fram e Relay FRF.8 SI W links.

FRF.8 SI W is a Fram e Relay Forum st andard for connect ing Fram e Relay net works wit h ATM
net works. SI W provides a st andards- based solut ion for service providers, ent erprises, and end
users. I n service int erworking t ranslat ion m ode, Fram e Relay PVCs are m apped t o ATM PVCs
wit hout t he need for sym m et ric t opologies. FRF.8 support s t wo m odes of operat ion of t he
int erworking funct ion ( I WF) for upper- layer user prot ocol encapsulat ion:

Tr a n sla t ion m ode Maps bet ween ATM ( AAL) and Fram e Relay ( I ETF) encapsulat ion. I t
also support s int erworking of rout ed or bridged prot ocols.

Tr a n spa r e n t m ode Does not m ap encapsulat ions, but sends t hem unalt ered. This m ode is
used when t ranslat ion is im pract ical because encapsulat ion m et hods do not conform t o t he
support ed st andards for service int erworking.

MLP for LFI on ATM and Fram e Relay SI W net works is support ed for t ransparent - m ode VCs and
t ranslat ional- m ode VCs t hat support PPP t ranslat ion ( FRF 8.1) .

To m ake MLPoATM and MLPoFR SI W possible, t he service provider's int erworking swit ch m ust be
configured in t ransparent m ode, and t he end rout ers m ust be capable of recognizing bot h
MLPoATM and MLPoFR headers. This is accom plished wit h t he pr ot ocol ppp com m and for ATM
and t he fr a m e - r e la y in t e r fa ce - dlci dlci ppp com m and for Fram e Relay.

When an ATM cell is sent from t he ATM side of an ATM- t o- Fram e Relay SI W connect ion, t he
following m ust happen for int erworking t o be possible:

1 . The sending rout er encapsulat es a packet in t he MLPoATM header by t he sending rout er.

2 . I n t ransparent m ode, t he carrier swit ch prepends a 2- byt e Fram e Relay DLCI field t o t he
received packet and sends t he packet t o it s Fram e Relay int erface.

3 . The receiving rout er exam ines t he header of t he received packet . I f t he first 4 byt es aft er
t he 2- byt e DLCI field of t he received packet are 0xfefe03cf, it t reat s it as a legal MLPoFR
packet and sends it t o t he MLP layer for furt her processing.

When a fram e is sent from t he Fram e Relay side of an ATM- t o- Fram e Relay SI W connect ion, t he
following m ust happen for int erworking t o be possible:

1 . The sending rout er encapsulat es a packet in t he MLPoFR header.

2 . I n t ransparent m ode, t he carrier swit ch st rips off t he 2- byt e Fram e Relay DLCI field and
sends t he rest of t he packet t o it s ATM int erface.

3 . The receiving rout er exam ines t he header of t he received packet . I f t he first 2 byt es of t he
 3.
received packet are 0x03cf, it t reat s it as a legal MLPoATM packet and sends it t o MLP layer
for furt her processing.

A new ATM- t o- Fram e Relay SI W st andard, FRF.8.1, support s MLPoATM and Fram e Relay SI W,
but it could be years before all swit ches are updat ed t o t his new st andard.

When using MLPoATM and MLPoFR, keep t he following in m ind:

MLPoATM can be support ed only on plat form s t hat support per- VC t raffic shaping.

MLPoATM relies on per- VC queuing t o cont rol t he flow of packet s from t he MLP bundle t o
t he ATM PVC.

MLPoATM requires t he MLP bundle t o classify t he out going packet s before t hey are sent t o
t he ATM VC. I t also requires t he per- VC queuing st rat egy for t he ATM VC t o be FI FO
because t he MLP bundle handles queuing.

MLPoFR relies on t he FRTS engine t o cont rol t he flow of packet s from t he MLP bundle t o FR
VC.

cRTP is support ed only over ATM links ( t hrough MLPoATM) , as of Cisco I OS Release
12.2( 2) T.

Slow-Speed ( 768 kbps) ATM-FR SIW Links

Re com m e n da t ion : Use MLPoATM and MLPoFR. Use MLP LFI and opt im ize fragm ent sizes t o
m inim ize cell padding. cRTP can be used only in Cisco I OS Release 12.2( 2) T or lat er. Tune t he
ATM PVC Tx- ring t o 3.

As wit h any slow- speed WAN m edia, serializat ion delay m ust be addressed wit h a fragm ent at ion
and int erleaving m echanism . As previously m ent ioned, FRF.12 is not an opt ion for SI W links.
Therefore, MLP LFI m ust be used. Generally, MLP LFI requires no addit ional calculat ions t o
configure, but a special case exist s when int erworking ATM and FR ( as illust rat ed in Figure 13- 19
) because of t he nat ure of ATM's fixed cell lengt hs.

Figu r e 1 3 - 1 9 . Slow - Spe e d ATM - FR SI W Lin k s

When enabling MLPoATM, t he fragm ent size should be opt im ized so t hat it fit s int o an int egral
num ber of cells. Ot herwise, t he bandwidt h required could double because of cell padding. For
exam ple, if a fragm ent size of 49 byt es is configured, t his fragm ent would require 2 cells t o
t ransm it ( because ATM cells have 48- byt e payloads) . This would generat e 57 byt es of overhead
( 2 cell headers plus 47 byt es of cell padding) , which is m ore t han double t he fragm ent it self.
Table 13- 3 provides a sum m ary of t he opt im al fragm ent - delay param et ers for MLPoATM.

56 kbps

84 byt es

12 m s

64 kbps

80 byt es

10 m s

128 kbps

176 byt es

11 m s

256 kbps

320 byt es

10 m s

512 kbps

640 byt es

14

10 m s

768 kbps

960 byt es

21

10 m s

Ta ble 1 3 - 3 . Opt im a l Fr a gm e n t - D e la y Va lu e s for M LP LFI for

M LPoATM

ppp m u lt ilin k
Opt im a l Fr a gm e n t ATM Ce lls fr a gm e n t - de la y
PVC Spe e d Size ( Rou n de d Up) v a lu e
A slow- speed ATM- t o- Fram e Relay SI W configurat ion is shown next , in t wo part s:

The cent ral sit e WAN aggregat or MLPoATM configurat ion ( see Exam ple 13- 34 )

The rem ot e branch rout er MLPoFR configurat ion ( see Exam ple 13- 39)

Ex a m ple 1 3 - 3 4 . M LPoATM W AN Aggr e ga t or ATM - FR SI W QoS D e sign

Ex a m ple

!
interface ATM4/0
no ip address
no atm ilmi-keepalive
!
interface ATM4/0.60 point-to-point
pvc BRANCH#60 0/60
vbr-nrt 256 256 ! ATM PVC definition
tx-ring-limit 3 ! Per-PVC
Tx-ring is tuned to 3 particles
protocol ppp Virtual- Template60 ! Enables MLPoATM
!
interface Virtual-Template60
bandwidth 256
ip address 10.200.60.1 255.255.255.252
service-policy output WAN-EDGE ! Attaches MQC policy to Virtual-Template
ppp multilink
ppp multilink fragment-delay 10 ! Enables MLP fragmentation
ppp multilink interleave ! Enables MLP interleaving
!

Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

sh ow a t m pvc

sh ow ppp m u lt ilin k

Ex a m ple 1 3 - 3 5 . M LPoFR Re m ot e - Br a n ch Rou t e r ATM - FR SI W QoS

D e sign Ex a m ple

!
interface Serial6/0
description Parent FR Link for BRANCH#60
no ip address
encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial6/0.60 point-to-point
description FR Sub-Interface for BRANCH#60
bandwidth 256
frame-relay interface-dlci 60 ppp Virtual-Template60 ! Enables MLPoFR
class FRTS-256kbps ! Binds the map-class to the FR DLCI
!
interface Virtual-Template60
bandwidth 256
ip address 10.200.60.2 255.255.255.252
service-policy output WAN-EDGE ! Attaches MQC policy to map-class
ppp multilink
ppp multilink fragment-delay 10 ! Enables MLP fragmentation
ppp multilink interleave ! Enables MLP interleaving
!
...
!
map-class frame-relay FRTS-256kbps
frame-relay cir 243200 ! CIR is set to 95% of FR DLCI rate
frame-relay bc 2432 ! Bc is set to CIR/100
frame-relay be 0 ! Be is set to 0
frame-relay mincir 243200 ! MinCIR is set to CIR
!

Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

sh ow ppp m u lt ilin k

ISDN
When designing VoI P over I SDN net works, special considerat ion needs t o be given t o t he
following issues:

Link bandwidt h varies as B channels are added or dropped.

RTP packet s m ight arrive out of order when t ransm it t ed across m ult iple B channels.

CallManager has lim it at ions wit h locat ions- based CAC.

Variable Bandwidth

I SDN allows B channels t o be added or dropped in response t o t he dem and for bandwidt h. The
fact t hat t he bandwidt h of a link varies over t im e present s a special challenge t o t he LLQ/ CBWFQ
m echanism s of Cisco I OS Soft ware. Before Cisco I OS Release 12.2( 2) T, a policy m ap
im plem ent ing LLQ could be assigned only a fixed am ount of bandwidt h. On an I SDN int erface,
Cisco I OS Soft ware assum es t hat only 64 kbps is available, even t hough t he int erface has t he
pot ent ial t o provide 128 kbps, 1.544 Mbps, or 2.408 Mbps of bandwidt h. By default , t he
m axim um bandwidt h assigned m ust be less t han or equal t o 75 percent of t he available
bandwidt h. Hence, before Cisco I OS Release 12.2( 2) T, only 75 percent of 64 kbps, or 48 kbps,
could be allocat ed t o an LLQ on any I SDN int erface. I f m ore was allocat ed, an error m essage
was generat ed when t he policy m ap was applied t o t he I SDN int erface. This severely rest rict ed
t he num ber of VoI P calls t hat could be carried.

The solut ion t o t his problem was int roduced in Cisco I OS Release 12.2( 2) T wit h t he pr ior it y
pe r ce n t com m and. This com m and allows t he reservat ion of a variable bandwidt h percent age t o
be assigned t o t he LLQ.

MLP Packet Reordering Considerations

MLP LFI is used for fragm ent at ion and int erleaving voice and dat a over I SDN links. LFI segm ent s
large dat a packet s int o sm aller fragm ent s and t ransm it s t hem in parallel across all t he B
channels in t he bundle. At t he sam e t im e, voice packet s are int erleaved bet ween t he fragm ent s,
t hereby reducing t heir delay. The int erleaved packet s are not subj ect t o MLP encapsulat ion; t hey
are encapsulat ed as regular PPP packet s. Hence, t hey have no MLP sequence num bers and
cannot be reordered if t hey arrive out of sequence.

The packet s probably will need t o be reordered. The dept h of t he various link queues in t he
bundle m ight differ, causing RTP packet s t o overt ake each ot her as a result of t he difference in
queuing delay. The various B channels also m ight t ake different pat hs t hrough t he I SDN net work
and m ight end up wit h different t ransm ission delays.

This reordering of packet s is not generally a problem for RTP packet s. The buffers on t he
receiving VoI P devices reorder t he packet s based on t he RTP sequence num bers. However,
reordering becom es a problem if cRTP is used. The cRTP algorit hm assum es t hat RTP packet s are
com pressed and decom pressed in t he sam e order. I f t hey get out of sequence, decom pression
does not occur correct ly.

Mult iclass Mult ilink PPP ( MCMP) offers a solut ion t o t he reordering problem . Wit h MCMP, t he
int erleaved packet s are given a sm all header wit h a sequence num ber, which allows t hem t o be
reordered by t he far end of t he bundle before cRTP decom pression t akes place. MCMP is
support ed as of Cisco I OS Release 12.2( 13) T.

CallManager CAC Limitations

I P t elephony in branch net works t ypically is based on t he cent ralized call- processing m odel and
uses locat ions- based CAC t o lim it t he num ber of calls across t he WAN. Locat ions- based CAC
current ly does not have any m echanism for t racking t opology changes in t he net work. Therefore,
if t he prim ary link t o a branch goes down and I SDN backup engages, t he CallManager rem ains
ignorant of t he occurrence. For t his reason, it is crit ical t hat t he I SDN backup link be capable of
handling t he sam e num ber of VoI P calls as t he m ain link. Ot herwise, CAC ult im at ely could
oversubscribe t he backup link.

The act ual bandwidt h of t he prim ary link and t he backup link do not need t o be ident ical. They
j ust need t o be capable of carrying t he sam e num ber of VoI P calls. For exam ple, t he backup link
m ight use cRTP while t he prim ary link does not , in which case, less bandwidt h is required on t he
backup link t o carry t he sam e num ber of calls as t he prim ary link.

Because of t hese lim it at ions, it is recom m ended t hat t he 33 percent LLQ recom m endat ion be
relaxed in t his kind of dial- backup scenario. The LLQ could be provisioned as high as 70 percent
( leaving 5 percent for Voice cont rol t raffic over t he I SDN link and 25 percent for Best - Effort
t raffic) .
Voice and Data on Multiple ISDN B Channels

The Voice and Dat a design m odel over I SDN, illust rat ed in Figure 13- 20 , allows a service policy
t o be applied t o a bundle wit h m ult iple B channels. I t t akes advant age of t he fact t hat LLQ
bandwidt h can be expressed as a percent age inst ead of an absolut e num ber. I f cRTP is enabled,
MCMP is required on t he I SDN links.

Figu r e 1 3 - 2 0 . Voice a n d D a t a ove r I SD N

Cisco I OS provides t wo m echanism s for cont rolling how channels are added in response t o
dem and.

The first m echanism com m only is referred t o as dial- on- dem and rout ing ( DDR) . Wit h DDR, a
load t hreshold m ust be specified ( as a fract ion of available bandwidt h) . When t he t raffic load
exceeds t his num ber, an addit ional channel is added t o t he bundle. The t hreshold is calculat ed
as a running average. As a result , t here is a cert ain delay in bringing up addit ional B channels
when t he load increases. This delay does not present a problem wit h dat a, but it is unaccept able
wit h voice. This delay can be reduced t o around 30 seconds by adding t he loa d- in t e r va l
com m and t o t he physical I SDN int erface, but even 30 seconds is t oo long.

The second m echanism is a m ore robust solut ion, which is sim ply t o bring up all B channels
im m ediat ely and keep t hem up as long as t he I SDN service is required. This is achieved by using
t he ppp m u lt ilin k lin k s m in im u m com m and.

Wit h t wo B channels available, t he service policy can reserve ( approxim at ely) 90 kbps ( 70
percent of 128 kbps) for voice t raffic. The t ot al num ber of calls t hat can be t ransm it t ed depends
on t he codec and sam pling rat es used.

Exam ple 13- 36 illust rat es t he configurat ion for enabling voice and dat a over m ult iple I SDN B
channels.

Ex a m ple 1 3 - 3 6 . Voice a n d D a t a ove r M u lt iple I SD N B Ch a n n e ls QoS

D e sign Ex a m ple

!
class-map match-all Voice
match ip dscp ef
!
class-map match-any Call Signaling
match ip dscp cs3
match ip dscp af31
!
...
 !
policy-map WAN-EDGE-ISDN
class Voice
priority percent 70 ! LLQ 33% Rule is relaxed for DDR scenarios
compress header ip rtp ! Enables Class-Based cRTP
class Call Signaling
bandwidth percent 5 ! Bandwidth guarantee for Call-Signaling
class class-default
fair-queue
!
interface BRI0/0
encapsulation ppp
dialer pool-member 1
!
interface Dialer1
encapsulation ppp
dialer pool 1
dialer remote-name routerB-dialer1
dialer-group 1
dialer string 12345678
service-policy output WAN-EDGE-ISDN ! Attaches MQC policy to Dialer interface
ppp multilink
ppp multilink fragment-delay 10 ! Enables MLP fragmentation
ppp multilink interleave ! Enables MLP interleaving
ppp multilink links minimum 2 ! Activates both B Channels immediately
ppp multilink multiclass ! Enables MCMP
!

Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

sh ow ppp m u lt ilin k
Case Study: WAN Aggregation Router QoS Design
A fict it ious com pany, ABC, I nc., already correct ly is classifying and m arking ( at Layer 3 via
DSCP) all 11 classes of t raffic from t he QoS Baseline Model wit hin it s cam pus. I t want s t o
provision QoS policies for each of t hese applicat ion classes over it s WANs as well.

ABC, I nc., select ed ATM as it s prim ary Layer 2 m edium because of it s ease of expansion for
fut ure bandwidt h needs. Each rem ot e branch is connect ed t o t he m ain cam pus by dual- T1 links
( at a m inim um ) , wit h som e larger sit es using t hree or four T1s for connect ivit y. Most rem ot e
branches are connect ed using Fram e Relay links ( t hrough ATM- t o- FR SI W) ; however, som e
rem ot e sit es are using ATM I MA.

ABC, I nc., has select ed t he Cisco 7500- VI P6- 80 for t he WAN aggregat ion plat form and is
provisioning sit es so t hat t he CPU ut ilizat ion of any given WAN aggregat or is no m ore t han 75
percent ; it is running Cisco I OS Release 12.3 m ainline code.

WAN edge QoS designs for one of t he WAN aggregat ion rout ers are shown in Figure 13- 22 and
Exam ple 13- 37 .

Figu r e 1 3 - 2 1 . Ca se St u dy: QoS Ba se lin e Policie s on W AN Aggr e ga t ion

Rou t e r w it h H igh - Spe e d ATM Lin k s

Ex a m ple 1 3 - 3 7 . Ca se St u dy: QoS Ba se lin e Policie s on W AN

Aggr e ga t ion Rou t e r w it h D u a l- T1 ATM I M A Lin k s

!
ip cef distributed ! Required for C7500-VIP
!
class-map match-all Voice
 match ip dscp ef ! IP Phones mark Voice to EF
class-map match-all Interactive Video
match ip dscp af41 af42 ! Recommended markings for IP/VC
class-map match-any Call Signaling
match ip dscp cs3 ! Future Call-Signaling marking
match ip dscp af31 ! Current Call-Signaling marking
class-map match-all Routing
match ip dscp cs6 ! Routers mark Routing traffic to CS6
class-map match-all Net Mgmt
match ip dscp cs2 ! Recommended marking for Network Management
class-map match-all Mission-Critical Data
match ip dscp 25 ! Interim marking for Mission-Critical Data
class-map match-all Transactional Data
match ip dscp af21 af22 ! Recommended markings for Transactional-Data
class-map match-all Bulk Data
match ip dscp af11 af12 ! Recommended markings for Bulk-Data
class-map match-all Streaming Video
match ip dscp cs4 ! Recommended marking for Streaming-Video
class-map match-all Scavenger
match ip dscp cs1 ! Recommended marking for Scavenger traffic
!
policy-map WAN-EDGE
class Voice
priority percent 18 ! Voice gets 552 kbps of LLQ
class Interactive Video
priority percent 15 ! 384 kbps IP/VC needs 460 kbps of LLQ
class Call Signaling
bandwidth percent 5 ! Bandwidth guarantee for Call-Signaling
class Routing
bandwidth percent 3 ! Bandwidth guarantee for Routing
class Net Mgmt
bandwidth percent 2 ! Bandwidth guarantee for Network Management
class Mission-Critical Data
bandwidth percent 10 ! Mission-Critical data gets min 10% BW guarantee
fair-queue ! Applies FQ to MC-Data class (VIP Only)
random-detect ! Enables WRED on Mission-Critical Data class
class Transactional Data
bandwidth percent 7 ! Transactional Data gets min 7% BW guarantee
fair-queue ! Applies FQ to Trans-Data class (VIP Only)
random-detect dscp-based ! Enables DSCP-WRED on Transactional Data class
class Bulk Data
bandwidth percent 4 ! Bulk Data gets min 4% BW guarantee
fair-queue ! Applies FQ to Bulk Data class (VIP Only)
random-detect dscp-based ! Enables DSCP-WRED on Bulk Data class
class Streaming Video
bandwidth percent 10 ! Streaming-Video gets min 10% BW guarantee
class Scavenger
bandwidth percent 1 ! Scavenger class is throttled
class class-default
bandwidth percent 25 ! Class-Default gets min 25% BW guarantee
fair-queue ! Applies FQ to Class-Default (VIP Only)
random-detect ! Enables WRED on Class-Default
!
...
!
interface ATM3/0
 no ip address
no atm ilmi-keepalive
!
interface ATM3/0.60 point-to-point
ip address 10.2.60.1 255.255.255.252
description Dual-T1 ATM PVC to Branch#60
pvc 0/60
vbr-nrt 3072 3072 ! Dual-T1 ATM PVC definition
max-reserved-bandwidth 100 ! Overrides the default 75% BW limit
service-policy output WAN-EDGE ! Attaches MQC policy to PVC
!
!

Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

sh ow a t m pvc
Summary
This chapt er discussed t he QoS requirem ent s of rout ers perform ing t he role of a WAN
aggregat or. Specifically, it addressed t he need for queuing policies on t he WAN edges, com bined
wit h shaping policies when NBMA m edia ( such as Fram e Relay or ATM) are being used, and link-
specific policies, such as LFI / FRF.12 and cRTP, for slow- speed ( 768 kbps) links.

For t he WAN edges, bandwidt h- provisioning guidelines were considered, such as leaving 25
percent of t he bandwidt h for t he Best - Effort class and lim it ing t he sum of all LLQs t o 33 percent .

Three cat egories of WAN link speeds and t heir design im plicat ions were present ed:

Slow- speed ( 768 kbps) links, which can support only Three- t o Five- Class QoS m odels
and require LFI m echanism s and cRTP.

Medium - speed ( T1/ E1) links, which, likewise, can support only Three- t o Five- Class QoS
Models but no longer require LFI m echanism s. cRTP becom es opt ional.

High- speed ( m ult iple T1/ E1 or great er) links, which can support 5- t o 11- Class QoS Models.
No LFI is required on such links. cRTP likely would have a high CPU cost ( com pared t o
realized bandwidt h savings) and, as such, generally is not recom m ended for such links.
Addit ionally, som e m et hod of load sharing, bundling, or inverse m ult iplexing is required t o
dist ribut e t he t raffic across m ult iple physical links.

These principles t hen were applied t o cert ain WAN m edia designsspecifically, for leased lines,
Fram e Relay, ATM, and ATM- t o- Fram e Relay SI W. The corner case of I SDN as a backup WAN link
also was considered.

Finally, a case st udy was present ed, illust rat ing a com plex scenario t o show how t hese designs
can be put t oget her.
Further Reading
Layer 3 queuing:

Class- based weight ed fair queuing ( Cisco I OS Release 12.0.5T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 5/ cbwfq.ht m

Low- lat ency queuing ( Cisco I OS Release 12.0.7T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 7/ pqcbwfq.ht m
.

Dist ribut ed low- lat ency queuing ( Cisco I OS Release 12.1.5T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt llqvip.ht m
.

Low- lat ency queuing wit h priorit y percent age support ( Cisco I OS Release 12.2.2T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ ft llqpct .ht m

Congest ion avoidance:

MQC- based WRED ( Cisco I OS Release 12.0.5T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 5/ cbwfq.ht m

DiffServ- com pliant weight ed random early det ect ion ( Cisco I OS Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt dswred.ht m
.

Dist ribut ed class- based weight ed fair queuing and dist ribut ed weight ed random early det ect ion ( Cisco
I OS Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt cbwred.ht m
.

Fram e Relay t raffic shaping:

Class- based shaping ( Cisco I OS Release 12.1.2T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 2/ clsbsshp.ht m

MQC- based Fram e Relay t raffic shaping ( Cisco I OS Release 12.2.13T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ frqosm qc.ht
.

Dist ribut ed t raffic shaping ( Cisco I OS Release 12.1.5T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt dt s.ht m

ATM PVC t raffic param et ers:

Configuring ATM t raffic param et ers:

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fwan_c/ wcfat m .ht m # 1001
 .

Link fragm ent at ion and int erleaving:

MLP int erleaving and queuing for Real- Tim e t raffic ( Cisco I OS Release 12.0) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 12cgcr/ dial_c/ dcppp.ht m # 4550

FRF.12 ( Cisco I OS Release 12.0.4T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 4/ 120t vofr/ inde
.

Link fragm ent at ion and int erleaving for Fram e Relay and ATM virt ual circuit s ( Cisco I OS Release 12.1.5T
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ dt lfifra.ht m

Dist ribut ed link fragm ent at ion and int erleaving over leased lines ( Cisco I OS Release 12.2.8T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ ft dlfi2.ht m

Dist ribut ed link fragm ent at ion and int erleaving for Fram e Relay and ATM int erfaces ( Cisco I OS Release
12.2.4T) : ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 4/ ft d
.

Com pressed Real- Tim e Prot ocol:

RTP and TCP header com pression ( Cisco I OS Release 12.0.7T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios120/ 120newft / 120t / 120t 7/ rt pfast .ht m

Class- based RTP and TCP header com pression ( Cisco I OS Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft hdrcm p.ht
.

Tx- ring:

Tx- ring t uning:

ht t p: / / www.cisco.com / en/ US/ t ech/ t k39/ t k824/ t echnologies_t ech_not e09186a00800fbafc.sht m l
.

PAK_priorit y:

Underst anding how rout ing updat es and Layer 2 cont rol packet s are queued on an int erface
wit h a QoS service policy: ht t p: / / www.cisco.com / warp/ public/ 105/ rt gupdat es.ht m l .

I SDN:

Mult iclass Mult ilink PPP ( Cisco I OS Release 12.2.13T)

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft m m lppp.h
.

Marking:

Class- based m arking ( Cisco I OS Release 12.1.5T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ cbpm ark2.ht m
.
Enhanced packet m arking ( Cisco I OS Release 12.2.13T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft enpkm k.ht
.
Chapter 14. Branch Router QoS Design
This chapt er discusses Branch QoS considerat ions and designs, including t he following:

Unidirect ional applicat ions

Branch LAN edge ingress classificat ion

Branch NBAR policies for worm ident ificat ion and policing

Chapt er 13, " WAN Aggregat or QoS Design," discussed t he QoS design recom m endat ions for
WAN aggregat ors in det ail. For t he m ost part , t heses designs also apply t o branch rout ers
locat ed at t he far end of t he WAN links. However, at least t hree unique considerat ions m ust be
m ade for branch rout er QoS design. This chapt er exam ines in det ail t hese considerat ions and
t heir relat ed designs.

The first considerat ion is t hat of unidirect ional applicat ions. Som e applicat ions, such as
St ream ing- Video ( whet her unicast or m ult icast ) , require bandwidt h allocat ion only on t he WAN
aggregat or's WAN edge, not on t he branch rout er's WAN edge. Therefore, bandwidt h allocat ed t o
unidirect ional applicat ions on t he WAN aggregat or WAN edge can be redist ribut ed am ong ot her
preferent ial classes on t he branch rout er's WAN edge.

Anot her charact erist ic com m on t o branches is t hat t raffic dest ined t o t he cam pus m ight not be
correct ly m arked on t he branch access swit ches. These swit ches, which are usually lower- end
swit ches, m ight or m ight not have t he capabilit ies t o classify by Layer 3 or 4 param et ers and
m ark DSCP values for dat a applicat ions. Therefore, classificat ion and m arking m ight need t o be
perform ed on t he branch rout er's LAN edge in t he ingress direct ion. Furt herm ore, branch rout ers
provide t he capabilit y t o use NBAR t o classify and m ark flows t hat require st at eful packet
inspect ion.

Relat ed t o classificat ion and NBAR, anot her unique considerat ion t o branch QoS design is t hat
branch rout ers are a st rat egic place t o deploy NBAR policies for worm ident ificat ion and policing.
NBAR policies can be used t o ident ify and drop Code Red, NI MDA, SQL Slam m er, RPC
DCOM/ W32/ MS Blast er, Sasser, and ot her worm s.

Figure 14- 1 shows t he QoS policies required on a rem ot e branch rout er.

Figu r e 1 4 - 1 . Br a n ch Rou t e r QoS Policie s

[View full size image]

Branch WAN Edge QoS Design
WAN edge considerat ions discussed in Chapt er 13 apply also t o t he branch rout er's WAN edge.
This includes t he following:

Link- speed cat egories ( slow, m edium , and high) and t heir respect ive design im plicat ions

Bandwidt h- provisioning guidelines ( at least 25 percent for Best - Effort t raffic and no m ore
t han 33 percent for Real- Tim e applicat ions)

Link- specific caveat s ( such as t he fact t hat t ools such as LFI and cRTP, when enabled, m ust
be enabled on bot h ends of t he WAN link for t hem t o funct ion correct ly)

Dist ribut ed plat form idiosyncrasies are not as relevant for branch rout er designs because t hese
plat form s rarely are deployed at rem ot e sit es ( alt hough t hey can be used for sit e- t o- sit e links, as
discussed in Chapt er 13 ) .

Unidirectional Applications
Som e applicat ions are com plet ely sym m et rical and require ident ical bandwidt h provisioning on
bot h ends of t he WAN link. For exam ple, if 100 kbps of LLQ are assigned t o voice in one
direct ion, 100 kbps of LLQ also m ust be provisioned for voice in t he opposit e direct ion ( assum ing
t hat t he sam e VoI P codecs are being used in bot h direct ions, and put t ing aside for a m om ent
m ult icast Music- on- Hold [ MoH] provisioning) . Furt herm ore, having sym m et rical polices on bot h
sides of t he WAN links great ly sim plifies QoS policy deploym ent and m anagem ent , which is an
im port ant aspect of large- scale designs.

However, cert ain applicat ions, such as St ream ing- Video and m ult icast MoH, m ost oft en are
unidirect ional. Therefore, it m ight be unnecessary and even inefficient t o provision any
bandwidt h guarant ees for such t raffic on t he branch rout er for t he branch- t o- cam pus direct ion of
t raffic flow.

Most applicat ions lie som ewhere in t he m iddle of t he scale, bet ween t he ext rem es of being fully
bidirect ional and being com plet ely unidirect ional. Most client / server applicat ions lie closer t o t he
unidirect ional end of t he scale because t hese applicat ions usually consist of sm all am ount s of
client - t o- server t raffic coupled wit h larger am ount s of server- t o- client t raffic. Such behavior can
be reflect ed in t he asym m et rical bandwidt h provisioning for such t ypes of applicat ions.

For purely unidirect ional applicat ions, it is recom m ended t hat provisioning be rem oved from t he
WAN edge policies on branch rout ers and t he allocat ed bandwidt h be redist ribut ed am ong ot her
classes.

Branch Router WAN Edge (10-Class) QoS Baseline Model

The inclusion or exclusion of t he St ream ing- Video class affect s only t hose ent erprises deploying
com plex QoS class m odels, such as t he 11- Class QoS Baseline Model. When t he St ream ing- Video
class is rem oved from t his m odel ( for branch rout er WAN edges) , t he bandwidt h previously
allocat ed t o t his class can be reallocat ed am ong t he ot her preferent ial dat a classes, as illust rat ed
in Figure 14- 2 . Not ice t hat no class is provisioned for St ream ing- Video in t his m odel, and t he
bandwidt h assigned t o it from t he 11- Class WAN edge m odel ( from Figure 13- 6 in t he previous
chapt er) has been reassigned t o t he Mission- Crit ical Dat a class and t he Transact ional Dat a class.

Figu r e 1 4 - 2 . Br a n ch Rou t e r ( 1 0 - Cla ss) QoS Ba se lin e W AN Edge M ode l

Ba n dw idt h Alloca t ion s Ex a m ple ( D u a l- T1 Lin k Ex a m ple )

The configurat ion for such a branch rout er ( 10- class) QoS Baseline policy on a dual- T1 int erface
is shown in Exam ple 14- 1 . Not ice t hat t here is no St ream ing- Video class and t hat t he bandwidt h
for it has been dist ribut ed equally bet ween t he Mission- Crit ical Dat a class ( now at 15 percent
inst ead of 10 percent ) and t he Transact ional Dat a class ( now at 12 percent inst ead of 7
percent ) .

A ba n dw idt h st at em ent is used on class- default , precluding t he use of fa ir - qu e u e on t he class

for all nondist ribut ed plat form s. Also, a m a x - r e se r ve d- ba n dw idt h 1 0 0 com m and m ust be
issued on t he int erface before t he se r vice - policy ou t pu t com m and.

Ex a m ple 1 4 - 1 . Br a n ch Rou t e r ( 1 0 - Cla ss) QoS Ba se lin e W AN Edge

M ode l

!
class-map match-all VOICE
match ip dscp ef ! IP Phones mark Voice to EF
class-map match-all INTERACTIVE-VIDEO
match ip dscp af41 af42 ! Recommended markings for IP/VC
class-map match-any CALL-SIGNALING
match ip dscp cs3 ! Future Call-Signaling marking
match ip dscp af31 ! Current Call-Signaling marking
class-map match-all ROUTING
 match ip dscp cs6 ! Routers mark Routing traffic to CS6
class-map match-all NET-MGMT
match ip dscp cs2 ! Recommended marking for Network Management
class-map match-all MISSION-CRITICAL-DATA
match ip dscp 25 ! Interim marking for Mission-Critical Data
class-map match-all TRANSACTIONAL-DATA
match ip dscp af21 af22 ! Recommended markings for Transactional Data
class-map match-all BULK-DATA
match ip dscp af11 af12 ! Recommended markings for Bulk Data
class-map match-all SCAVENGER
match ip dscp cs1 ! Recommended marking for Scavenger traffic
!
policy-map BRANCH-WAN-EDGE
class VOICE
priority percent 18 ! Voice gets 552 kbps of LLQ
class INTERACTIVE-VIDEO
priority percent 15 ! 384 kbps IP/VC needs 460 kbps of LLQ
class CALL-SIGNALING
bandwidth percent 5 ! Minimal BW guarantee for Call-Signaling
class ROUTING
bandwidth percent 3 ! Routing class gets 3% explicit BW guarantee
class NET-MGMT
bandwidth percent 2 ! Net-Mgmt class gets 2% explicit BW guarantee
class MISSION-CRITICAL-DATA
bandwidth percent 15 ! Mission-Critical class gets min 15% BW guarantee
random-detect ! Enables WRED on Mission-Critical Data class
class TRANSACTIONAL-DATA
bandwidth percent 12 ! Transactional-Data class gets min 12% BW guarantee
random-detect dscp-based ! Enables DSCP-WRED on Transactional-Data class
class BULK-DATA
bandwidth percent 4 ! Bulk Data class gets 4% BW guarantee
random-detect dscp-based ! Enables DSCP-WRED on Bulk-Data class
class SCAVENGER
bandwidth percent 1 ! Scavenger class is throttled
class class-default
bandwidth percent 25 ! Default class gets min 30% BW guarantee
random-detect ! Enables WRED on the default class
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

Now t hat considerat ions and designs for t he WAN edge of t he branch rout er have been
addressed, t he next sect ion discusses t he LAN edge.
Branch Router LAN Edge QoS Design
The LAN edge of t he branch rout er can have egress and ingress policies. Because you have been
dealing wit h egress policies since t he WAN/ branch discussion began, and because t he egress
policies are not only opt ional, but also considerably sim pler, t hey are discussed first .

As previously m ent ioned, it is bet t er t o m ark at Layer 3 ( DSCP) inst ead of Layer 2 whenever
possible because Layer 2 m arkings are lost when t he t ransm ission m edium changes. This is t he
case wit h any Et hernet 802.1Q/ p CoS values t hat have been set wit hin t he cam pus and are
carried over a WAN ( or VPN) . I n som e cases, net work adm inist rat ors prefer t o have t hese
m arkings rest ored at t he branch; DSCP- t o- CoS m apping t hen can be perform ed on t he branch
rout er's LAN edge.

I n t he ingress direct ion, t he branch rout er m ight be required t o perform classificat ion and
m arking of branch- t o- cam pus t raffic. This m ight be because t he branch swit ch lacks t he
capabilit y t o classify and m ark t raffic, or because t he t raffic consist s of st at eful flows t hat require
NBAR for classificat ion. NBAR classificat ion also is required at branch LAN ingress edges t o
ident ify ( and im m ediat ely drop) known worm t raffic.

Each of t hese t ypes of polices is discussed in m ore det ail in t he following sect ions.

DSCP-to-CoS Remapping
DSCP- t o- CoS rem apping is opt ional. Newer Cat alyst swit ches perform QoS based on int ernal
DSCP values t hat are generat ed eit her by t rust ed DSCP m arkings or by t rust ed CoS m arkings
( coupled wit h CoS- t o- DSCP m appings) . I n t he case of legacy swit ches at t he branch t hat
perform QoS st rict ly by preset CoS values, CoS m ight need t o be rem apped on t he branch
rout er's LAN edge.

Enhanced packet m arking ( Cisco I OS Release 12.2[ 13] T or higher) is t he opt im al t ool for
reset t ing CoS values because it uses a t able. I n t his m anner, a default DSCP- t o- CoS m apping
can be used wit hout having t o configure explicit ly a class- based m arking policy t hat m at ches
every DiffServ class and perform s a corresponding se t cos funct ion.

I n bot h cases, keep in m ind t hat only Et hernet t runking prot ocols, such as 802.1Q, carry CoS
inform at ion. Therefore, t he policy works correct ly only when applied t o a t runked subint erface,
not t o a m ain Et hernet int erface.

Exam ple 14- 2 present s an enhanced packet m arking DSCP- t o- CoS configurat ion for a branch
LAN edge. Not e t hat t his DSCP- t o- CoS rem apping policy requires applicat ion t o bot h t he voice
VLAN ( VVLAN) subint erface and t he dat a VLAN ( DVLAN) subint erface on t he branch rout er's LAN
edge.

Ex a m ple 1 4 - 2 . Br a n ch LAN Edge En h a n ce d Pa ck e t M a r k in g for D SCP-

t o- CoS Re m a ppin g Ex a m ple

!
ip cef ! IP CEF is Required for Packet Marking
 !
policy-map BRANCH-LAN-EDGE-OUT
class class-default
set cos dscp ! Enables default DSCP-to-CoS Mapping
!
!
interface FastEthernet0/0
no ip address
speed auto
duplex auto
!
interface FastEthernet0/0.60
description DVLAN SUBNET 10.1.60.0
encapsulation dot1Q 60
ip address 10.1.60.1 255.255.255.0
service-policy output BRANCH-LAN-EDGE-OUT ! Restores CoS for Data VLAN
!
interface FastEthernet0/0.160
description VVLAN SUBNET 10.1.160.0
encapsulation dot1Q 160
ip address 10.1.160.1 255.255.255.0
service-policy output BRANCH-LAN-EDGE-OUT ! Restores CoS on Voice VLAN
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

Branch-to-Campus Classification and Marking

I n keeping wit h t he unofficial Different iat ed Services design principle of m arking t raffic as close
t o it s source as possible, I P phones m ark voice- bearer t raffic ( t o DSCP EF) and Call- Signaling
t raffic ( current ly, t o DSCP AF31, but t his will soon change t o DSCP CS3) on t he phones
t hem selves. Som e I P/ VC devices m ark I nt eract ive- Video t raffic t o AF41 on t heir net work
int erface cards ( NI Cs) .

However, as has already been discussed, it is not recom m ended t hat end- user PCs be t rust ed t o
set t heir CoS/ DSCP m arkings correct ly because users easily can abuse t his ( eit her
unint ent ionally or deliberat ely) . Therefore, applicat ion t raffic t hat originat es from unt rust ed host s
should be m arked on branch access swit ches. However, in som e circum st ances, t his m ight not
be possible:

The branch access swit ch does not have Layer 3 or Layer 4 awareness for t raffic
classificat ion or does not support m arking.

Classificat ion needs t o be perform ed at t he applicat ion layer ( t hrough NBAR) .

I n such cases, DSCP classificat ion m ust be perform ed at t he ingress int erface of t he branch
rout er.
Adm inist rat ors can ident ify and t hen m ark applicat ion t raffic based on t he following crit eria:

Sou r ce or de st in a t ion I P a ddr e ss ( or su bn e t ) Typically, dest inat ion subnet s are used
when set t ing branch QoS policies. For exam ple, t he dest inat ion subnet for a group of
applicat ion servers can be used t o ident ify a part icular t ype of client - t o- server applicat ion
t raffic.

W e ll- k n ow n TCP/ UD P por t s I t is im port ant t o know whet her t he well- known port is a
source port or a dest inat ion port from t he branch rout er's perspect ive.

N BAR pr ot ocol ( for e x a m ple , Cit r ix or Ka Za a ) or a pplica t ion su bpa r a m e t e r ( for

e x a m ple , H TTP URL) NBAR Packet Descript ion Language Modules ( PDLMs) also can be
configured t o ident ify st at eful or propriet ary applicat ions, as well as worm s.

Regardless of t he m et hod used t o ident ify t he applicat ion t raffic, t he inbound classificat ion and
m arking policy needs t o be applied only t o t he DVLAN subint erface. This is because only t rust ed
I P Telephony applicat ions, which m ark t heir voice t raffic correct ly, are adm it t ed ont o t he voice
VLAN.

N ot e
I f t he branch access swit ches support access- edge policers ( as described in Chapt er 12
, " Cam pus QoS Design" ) , t hese likewise should be enabled on t hem . This adds anot her
layer of defense t o t he net work, m it igat ing DoS/ worm t raffic t hat originat es from t he
branch t hrough Scavenger- class QoS.

I f t he branch access swit ches do not support such policing, com pat ible policers could
be placed at t he branch rout er access edge. This is in harm ony wit h t he principle of
policing as close t o t he source as possible.

Whenever possible, t hough, such policing should be done in Cat alyst hardware rat her
t han Cisco I OS Soft ware.

Alt hough it m ight be t em pt ing t o use t he sam e class- m ap nam es ( such as MI SSI ON- CRI TI CAL,
TRANSACTI ONAL- DATA, or BULK- DATA) for ingress LAN edge classificat ion and m arking policies
as are in use for egress WAN edge queuing policies, t his m ight cause confusion in policy
definit ion and t roubleshoot ing. Therefore, for m anagem ent and t roubleshoot ing sim plicit y, it is
beneficial t o have sim ilar yet descript ive nam es for t hese new classes ( for exam ple, branch-
originat ed t raffic m ight have class- m ap nam es prepended wit h " BRANCH- " ) . A descript ion can
also be added t o t he class m aps wit h t he de scr ipt ion com m and.

Source or Destination IP Address Classification

Exam ple 14- 3 shows how t raffic dest ined t o a specific subnet ( 10.200.200.0/ 24) which, in t his
case, represent s a server farm of propriet ary Mission- Crit ical Dat a applicat ion serverscan be
ident ified and m arked on ingress on t he branch rout er's LAN edge.

Ex a m ple 1 4 - 3 . Br a n ch LAN Edge D e st in a t ion I P Cla ssifica t ion a n d

M a r k in g Ex a m ple
 !
ip cef ! Required for Packet Marking
!
class-map match-all BRANCH-MISSION-CRITICAL
match access-group name MISSION-CRITICAL-SERVERS ! ACL to reference
!
policy-map BRANCH-LAN-EDGE-IN
class BRANCH-MISSION-CRITICAL
set ip dscp 25 ! (Interim) Recommended marking for Mission-Critical traffic
!
...
!
interface FastEthernet0/0
no ip address
speed auto
duplex auto
!
interface FastEthernet0/0.60
description DVLAN SUBNET 10.1.60.0
encapsulation dot1Q 60
ip address 10.1.60.1 255.255.255.0
service-policy output BRANCH-LAN-EDGE-OUT ! Restores CoS on Data VLAN
service-policy input BRANCH-LAN-EDGE-IN ! Marks MC Data on ingress
!
...
!
ip access-list extended MISSION-CRITICAL-SERVERS
permit ip any 10.200.200.0 0.0.0.255 ! MC Data Server-Farm Subnet
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

sh ow ip a cce ss- list

Verification Command: show ip access-list

When access list s are used as t he filt ering crit eria for a class m ap, t he sh ow ip a cce ss- list
com m and is helpful in ident ifying whet her t he access list is regist ering m at ches, especially for
ACLs t hat have m ult iple lines of m at ch crit eria. This com m and provides granular visibilit y int o
which lines of an access list are regist ering m at ches. I n Exam ple 14- 4 , 464 m at ches are
regist ered against t he access list .

Ex a m ple 1 4 - 4 . sh ow ip a cce ss- list Verificat ion of Rem ot e Branch LAN Edge
Dest inat ion I P Classificat ion Exam ple

BRANCH#60-C3745#show ip access-list MISSION-CRITICAL-SERVERS

Extended IP access list MISSION-CRITICAL-SERVERS
 10 permit ip any 10.200.200.0 0.0.0.255 (464 matches)
BRANCH#60-C3745#

Well-Known TCP/UDP Port Classification

Most applicat ions can be ident ified by t heir well- known TCP/ UDP port s. Som e of t hese port s have
keywords wit hin Cisco I OS Soft ware t o ident ify t hem when defining access list s.

N ot e
The I nt ernet Assigned Num bers Aut horit y ( I ANA) list s regist ered well- known and
regist ered applicat ion port s at ht t p: / / www.iana.org/ assignm ent s/ port - num bers .

Building on Exam ple 14- 4 , Exam ple 14- 5 classifies and m arks branch- originat ed FTP and e- m ail
t raffic, bot h POP3 and I MAP ( TCP port 143) , as Bulk Dat a ( DSCP AF11) .

Ex a m ple 1 4 - 5 . Br a n ch LAN Edge W e ll- Kn ow n Por t Cla ssifica t ion

Ex a m ple

!
ip cef ! Required for Packet Marking
!
class-map match-all BRANCH-MISSION-CRITICAL
match access-group name MISSION-CRITICAL-SERVERS
class-map match-all BRANCH-BULK-DATA
match access-group name BULK-DATA-APPS ! ACL to reference
!
policy-map BRANCH-LAN-EDGE-IN
class BRANCH-MISSION-CRITICAL
set ip dscp 25
class BRANCH-BULK-DATA
set ip dscp af11 ! Bulk data apps are marked to AF11
!
!
interface FastEthernet0/0
no ip address
speed auto
duplex auto
!
interface FastEthernet0/0.60
description DVLAN SUBNET 10.1.60.0
encapsulation dot1Q 60
ip address 10.1.60.1 255.255.255.0
service-policy output BRANCH-LAN-EDGE-OUT ! Restores CoS on Data VLAN
service-policy input BRANCH-LAN-EDGE-IN ! Marks Data on ingress
!
...
!
 ip access-list extended MISSION-CRITICAL-SERVERS
permit ip any 10.200.200.0 0.0.0.255
!
ip access-list extended BULK-DATA-APPS
permit tcp any any eq ftp ! Identifies FTP Control traffic
permit tcp any any eq ftp-data ! Identifies FTP Data traffic
permit tcp any any eq pop3 ! Identifies POP3 E-mail traffic
permit tcp any any eq 143 ! Identifies IMAP E-mail traffic
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

sh ow ip a cce ss- list

NBAR Application Classification

At t he t im e of t his writ ing, Cisco I OS Soft ware included NBAR PDLMs for 98 of t he m ost com m on
net work applicat ions, wit h t he capabilit y t o define an addit ional 10 applicat ions using cust om
PDLMs.

Of t hese prot ocols, 15 require st at eful packet inspect ion for posit ive ident ificat ion. Because NBAR
operat es in t he I P Cisco Express Forwarding ( CEF) swit ching pat h, only t he first packet wit hin a
flow requires st at eful packet inspect ion, and t he policy is applied t o all packet s belonging t o t he
flow. NBAR st at eful packet inspect ion requires m ore CPU processing power t han sim ple access
cont rol list s ( ACLs) . However, on newer branch rout er plat form s, such as t he Cisco 3745 or
2691, Cisco Technical Market ing t est ing has shown t he overhead of enabling NBAR classificat ion
at dual- T1 rat es t o be quit e m inim al ( t ypically 2 t o 5 percent , depending on t he t raffic m ix) .

Building again on t he previous exam ple, Exam ple 14- 6 uses NBAR t o ident ify several t ypes of
Transact ional Dat a applicat ions, Net work- Managem ent applicat ions, and Scavenger applicat ions.

I n Exam ple 14- 6 , Transact ional Dat a applicat ions include Cit rix, LDAP, Oracle SQL* NET, and
HTTP web t raffic wit h " SalesReport " in t he URL. I n addit ion, a cust om PDLM is defined t o ident ify
SAP t raffic ( by TCP port s 3200 t hrough 3203 and 3600) , and SAP also is included as a
Transact ional Dat a applicat ion.

Addit ionally, Net work- Managem ent applicat ions, such as SNMP, Syslog, Telnet , NFS, DNS, I CMP,
and TFTP, are ident ified t hrough NBAR and m arked t o DSCP CS2.

Furt herm ore, Scavenger applicat ions, such as Napst er, Gnut ella, KaZaa ( versions 1 and 2) ,
Morpheus, Grokst er, and m any ot her peer- t o- peer file- sharing applicat ions, are ident ified by
NBAR and m arked t o DSCP CS1.

Ex a m ple 1 4 - 6 . Br a n ch LAN Edge N BAR Cla ssifica t ion Ex a m ple

!
ip nbar port-map custom-01 tcp 3200 3201 3202 3203 3600 ! PDLM Mapping for SAP
!
ip cef ! IP CEF is required for both Class-Based Marking and for NBAR
!
class-map match-all BRANCH-MISSION-CRITICAL
match access-group name MISSION-CRITICAL-SERVERS
class-map match-any BRANCH-TRANSACTIONAL-DATA! Must use "match-any"
match protocol citrix ! Identifies Citrix traffic
match protocol ldap ! Identifies LDAP traffic
match protocol sqlnet ! Identifies Oracle SQL*NET traffic
match protocol http url "*SalesReport*" ! Identifies "SalesReport" URLs
match protocol custom-01 ! Identifies SAP traffic via Custom-01 PDLM Port-Map
class-map match-all BRANCH-BULK-DATA
match access-group name BULK-DATA-APPS
class-map match-any BRANCH-NET-MGMT
match protocol snmp ! Identifies SNMP traffic
match protocol syslog ! Identifies Syslog traffic
match protocol telnet ! Identifies Telnet traffic
match protocol nfs ! Identifies NFS traffic
match protocol dns ! Identifies DNS traffic
match protocol icmp ! Identifies ICMP traffic
match protocol tftp ! Identifies TFTP traffic
class-map match-any BRANCH-SCAVENGER
match protocol napster ! Identifies Napster traffic
match protocol gnutella ! Identifies Gnutella traffic
match protocol fasttrack ! Identifies KaZaa (v1) traffic
match protocol kazaa2 ! Identifies KaZaa (v2) traffic
!
policy-map BRANCH-LAN-EDGE-IN
class BRANCH-MISSION-CRITICAL
set ip dscp 25
class BRANCH-TRANSACTIONAL-DATA
set ip dscp af21 ! Transactional Data apps are marked to DSCP AF21
class BRANCH-NET-MGMT
set ip dscp cs2 ! Network Management apps are marked to DSCP CS2
class BRANCH-BULK-DATA
set ip dscp af11
class BRANCH-SCAVENGER
set ip dscp cs1 ! Scavenger apps are marked to DSCP CS1
!
...
!
interface FastEthernet0/0
no ip address
speed auto
duplex auto
!
interface FastEthernet0/0.60
description DVLAN SUBNET 10.1.60.0
encapsulation dot1Q 60
ip address 10.1.60.1 255.255.255.0
service-policy output BRANCH-LAN-EDGE-OUT ! Restores CoS on Data VLAN
service-policy input BRANCH-LAN-EDGE-IN ! Input Marking policy on DVLAN only
!
...
!
ip access-list extended MISSION-CRITICAL-SERVERS
permit ip any 10.200.200.0 0.0.0.255
 !
!
ip access-list extended BULK-DATA-APPS
permit tcp any any eq ftp
permit tcp any any eq ftp-data
permit tcp any any eq pop3
permit tcp any any eq 143
!

N ot e
The NBAR fa st t r a ck PDLM ident ifies KaZaa ( version 1) , Morpheus, Grokst er, and ot her
applicat ions. The NBAR gn u t e lla PDLM ident ifies Gnut ella, BearShare, Lim eWire, and
ot her peer- t o- peer applicat ions.

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

sh ow ip a cce ss- list

sh ow ip n ba r por t - m a p

Verification Command: show ip nbar port-map

When NBAR cust om PDLMs are used t o ident ify applicat ions, it is useful t o verify t hat t he port s
bound t o t he PDLM have been ent ered correct ly. This inform at ion is obt ained wit h t he sh ow ip
n ba r por t - m a p com m and. I n t his ( filt ered) exam ple, Exam ple 14- 7 , t he TCP port s given for
SAP ( 3200 t hrough 3203 and 3600) were bound correct ly t o t he Cust om - 01 NBAR PDLM.

Ex a m ple 1 4 - 7 . sh ow ip n ba r por t - m a p Verificat ion Cust om - PDLM TCP/ UDP

Port - Mapping Exam ple

BRANCH#60-C3745#show ip nbar port-map | include custom-01

port-map custom-01 tcp 3200 3201 3202 3203 3600
BRANCH#60-C3745#

NBAR Known-Worm Classification and Policing

Worm s are not hing new. They've been around alm ost as long as t he I nt ernet it self ( one of t he
first I nt ernet worm s was t he Morris worm , released in Novem ber 1988) . Typically, worm s are
self- cont ained program s t hat at t ack a syst em and t ry t o exploit a vulnerabilit y in t he t arget .
Upon successfully exploit ing t he vulnerabilit y, t he worm copies it s program from t he at t acking
host t o t he newly exploit ed syst em t o begin t he cycle again.

N ot e
A virus, which is slight ly different from a worm , requires a vect or t o carry t he virus
code from one syst em t o anot her. The vect or can be eit her a word- processing
docum ent , an e- m ail, or an execut able program .

The m ain elem ent t hat dist inguishes a worm from a virus is t hat a com put er virus
requires hum an int ervent ion t o facilit at e it s spreading, whereas worm s ( once released)
propagat e wit hout requiring addit ional hum an int ervent ion.

Worm s are com prised of t hree prim ary com ponent s ( as illust rat ed in Figure 14- 3 ) :

Th e e n a blin g e x ploit code The enabling exploit code is used t o exploit a vulnerabilit y on
a syst em . Exploit at ion of t his vulnerabilit y provides access t o t he syst em and t he capabilit y
t o execut e com m ands on t he t arget syst em .

A pr opa ga t ion m e ch a n ism When access has been obt ained t hrough t he enabling exploit ,
t he propagat ion m echanism is used t o replicat e t he worm t o t he new t arget . The m et hod
used t o replicat e t he worm can be achieved t hrough t he use of t he Trivial File Transfer
Prot ocol ( TFTP) , FTP, or anot her com m unicat ion m et hod. When t he worm code is brought
t o t he new host , t he cycle of infect ion can be st art ed again.

A pa yloa d Som e worm s also cont ain payloads, which m ight include addit ional code t o
furt her exploit t he host , m odify dat a on t he host , or change a web page. A payload is not a
required com ponent , and, in m any cases, t he worm 's enabling exploit code it self can be
considered t he payload.

Figu r e 1 4 - 3 . An a t om y of a n I n t e r n e t W or m

[View full size image]

Som e worm s use unique TCP/ UDP port s t o propagat e. These t ypes of worm s are fairly sim ple t o
block using access list s ( when t he port s are known) . Such ACLs can be configured on t he branch
swit ch ( whenever support ed) or on t he branch rout er's LAN edge.

Ot her worm s hij ack legit im at e TCP/ UDP port s t o carry t heir harm ful payloads. For t hese lat t er
t ypes of worm s, NBAR can be used at t he branch LAN edge t o perform deep- packet analysis and
drop any packet s t hat are carrying t he payloads of known worm s. Som e of t hese known worm s
include Code Red, NI MDA, SQL Slam m er, RPC DCOM/ W32/ MS Blast er, and Sasser. The following
sect ions discuss how NBAR can be used for each of t hese t ypes of worm s.

NBAR Versus Code Red

First released in July 2001, Code Red t arget ed Microsoft I nt ernet I nform at ion Server ( I I S) using
a vulnerabilit y in t he I I S I ndexing Service. Alt hough t he first variant of t his worm did lit t le
dam age because of a flaw in t he random num bergenerat or code used t o generat e addresses of
host s t o exploit , a second variant appeared wit h t he flaw fixed.

This worm , CodeRedv2, spread quickly and becam e t he m ost widespread and dam aging worm t o
hit t he I nt ernet since t he Morris worm . CodeRedv2's success as a worm relied on t he fact t hat
t he worm exploit ed t he vulnerabilit y in t he I I S I ndexing Service only as a m eans of gaining
access t o t he host . This, coupled wit h t he wide deploym ent of I I S as well as t he large num ber of
unpat ched I I S web servers, cont ribut ed t o t he quick and wide- ranging spread of t he worm . An
est im at ed 360,000 host s were infect ed wit hin a period of 14 hours.

CodeRedv2 t em porarily replaced t he hom e page of t he web servers t hat it st ruck wit h a new
page. Addit ionally, t he code of t he worm indicat ed t hat it was program m ed t o begin a packet -
flooding DoS at t ack against a hard- coded I P address. ( At t he t im e, t his was t he I P address of t he
Whit e House web server at ht t p: / / www.whit ehouse.gov .)

The original Code Red payload is shown in Exam ple 14- 8 . The init ial infect ion at t em pt sends a
large HTTP GET request t o t he t arget I I S server.

Ex a m ple 1 4 - 8 . Or igin a l Code Re d Pa yloa d

2001-08-04 16:32:23 24.101.17.216 - 10.1.1.75 80 GET /default.ida

NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd
3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u
531b%u53ff%u0078%u0000%u00=a 403

The CodeRedv2 payload is shown in Exam ple 14- 9 .

Ex a m ple 1 4 - 9 . Code Re dv2 Pa yloa d

2001-08-04 15:57:35 64.7.35.92 - 10.1.1.75 80 GET /default.ida

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u
9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u
8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a 403 -

Not ice t hat t he GET request in bot h cases is looking for a file nam ed default .ida. However, t his
filenam e changes in newer variant s of Code Red, such as CodeRedv3/ CodeRed.C, as shown in
Exam ple 14- 10 .

Ex a m ple 1 4 - 1 0 . Code Re dv3 Pa yloa d

2001-08-06 22:24:02 24.30.203.202 - 10.1.1.9 80 GET /x.ida

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAA=X 403 HTTP/1.1 -

Alt hough t he filenam e has changed, t he .ida suffix rem ains t he sam e.

Code Red variant s can include payloads t hat execut e cm d.exe or root .exe funct ions t o program
script s wit hin t he I I S script s direct ory, t hus providing a ready- m ade back door t o t he server for
any at t acker t o use.

Therefore, t o com bat Code Red, NBAR policies can be configured t o check t he payload of HTTP
packet s for t hese crit eria ( .ida, cm d.exe, and root .exe) , as shown in Exam ple 14- 11 .

Ex a m ple 1 4 - 1 1 . N BAR Policie s t o I de n t ify Code Re d

!
class-map match-any CODE-RED
match protocol http url "*.ida*" ! Identifies HTTP GET .ida requests
match protocol http url "*cmd.exe*" ! Identifies HTTP with cmd.exe
match protocol http url "*root.exe*" ! Identifies HTTP with root.exe
!

Verificat ion com m and:

sh ow policy

NBAR Versus NIMDA

Two m ont hs aft er Code Red st ruck t he I nt ernet , anot her large- scale worm , NI MDA, was
released. Unlike Code Red, NI MDA was a hybrid worm because it cont ained t he charact erist ics of
bot h a worm and a virus. NI MDA spread using several vect ors:

Through e- m ail as an at t achm ent ( virus vect or)

 Through net work shares ( worm vect or)

Through JavaScript by browsing com prom ised websit es ( virus vect or)

Through infect ed host s act ively scanning for addit ional exploit able host s ( worm vect or)

Through infect ed host s act ively scanning for back doors creat ed by Code Red ( worm
vect or)

NI MDA did not appear t o exhibit int ent ional dest ruct ive capabilit ies; t o dat e, NI MDA's act ivit ies
have been rest rict ed t o it s self- propagat ion, which has t he side effect of a DoS ( flooding) at t ack.

NI MDA propagat es it self by copying, downloading, or execut ing a file called readm e.em l.
Therefore, NBAR can be used t o check t he payload of HTTP packet s t o see if t hey are
propagat ing t his file, as shown in Exam ple 14- 12 .

Ex a m ple 1 4 - 1 2 . N BAR Policie s t o I de n t ify N I M D A

!
class-map match-any NIMDA
match protocol http url "*readme.eml*" ! Identifies HTTP with "readme.eml"
!

Verificat ion com m and:

sh ow policy

NBAR Versus SQL Slammer

Aft er t he NI MDA infect ion subsided, t he I nt ernet saw t he appearance of sm aller infect ious
worm s. I n January 2003, a new worm infect ed t he I nt ernet at such a high rat e t hat it was
cat egorized as a flash worm . This worm , t erm ed SQL Slam m er, once again t arget ed Microsoft
Windows servers; specifically, t his worm t arget ed servers running Microsoft St ruct ured Query
Language ( SQL) Server soft ware. The vulnerabilit y exploit ed by SQL Slam m er had been
published in July 2002, and a pat ch from Microsoft was available at t hat t im e as well. Even
t hough t his pat ch was available for alm ost six m ont hs, SQL Slam m er spread wit h incredibly high
efficiency.

SQL slam m er is a 376- byt e User Dat agram Prot ocol ( UDP) based worm t hat infect s Microsoft SQL
servers t hrough UDP port 1434. Exam ple 14- 13 shows a signat ure st ring from t he SQL Slam m er
w or m .

Ex a m ple 1 4 - 1 3 . SQL Sla m m e r W or m Sign a t u r e St r in g

\x04\x01\x01\x01\x01\x01.*[.][Dd][Ll][Ll]

Because of it s sm all size, t he SQL Slam m er worm is cont ained in a single packet . The fast
scanning rat e of SQL Slam m er is achieved not only because of t his sm all size, but also because
t he worm is UDP based. The worm does not have t o com plet e a handshake ( necessary wit h TCP-
based worm s) t o connect wit h a t arget syst em .

SQL Slam m er reached it s full scanning rat e of 55 m illion scans per second wit hin 3 m inut es of
t he st art of t he infect ion and infect ed t he m aj orit y of vulnerable host s on t he I nt ernet wit hin 10
m inut es of t he st art of t he infect ion, wit h an est im at ed 300,000 infect ed host s overall. A m aj or
consequence of such a fast scanning rat e was t hat edge net works were overwhelm ed by t he
am ount of t raffic generat ed by t he worm . SQL Slam m er's doubling rat e was approxim at ely 8.5
seconds. I n cont rast , CodeRedv2's doubling rat e was about 37 m inut es.

SQL Slam m er does not carry an addit ional harm ful payload ( beyond it s enabling exploit code) ,
and it s prim ary purpose is t o cause DoS t hrough exponent ial self propagat ion.

NBAR can be used t o det ect t he SQL Slam m er worm by m apping a cust om PDLM t o UDP port
1434 and m at ching on t he packet lengt h ( 376- byt e worm + 8 byt es of UDP header + 20 byt es of
I P header = 404 byt es) . This is shown in Exam ple 14- 14 .

Ex a m ple 1 4 - 1 4 . N BAR Policie s t o I de n t ify SQL Sla m m e r

!
ip nbar port-map custom-02 udp 1434 ! Maps a custom PDLM to UDP 1434
!
class-map match-all SQL-SLAMMER
match protocol custom-02 ! Matches the custom Slammer PDLM
match packet length min 404 max 404 ! Matches the packet length (376+28)
!

Verificat ion com m ands:

sh ow policy

sh ow ip n ba r por t - m a p

N ot e
Because NBAR cust om - 01 PDLM has been used in previous exam ples t o ident ify SAP
t raffic, anot her cust om PDLM ( cust om - 02) is used in t his exam ple. Subsequent
exam ples sim ilarly are defined wit h t he next - available cust om PDLM.

NBAR Versus RPC DCOM/W32/MS Blaster

First released in August 2003, t he Rem ot e Procedure Call ( RPC) Dist ribut ed Com ponent Obj ect
Model ( DCOM) worm exploit ed a flaw in a sect ion of Microsoft 's RPC code dealing wit h m essage
exchange over TCP/ I P, result ing in t he incorrect handling of m alform ed m essages. This flaw was
a st ack- based buffer overflow occurring in a low- level DCOM int erface wit hin t he RPC process
list ening on TCP port s 135, 139, and 445.

The DCOM prot ocol enables Microsoft soft ware com ponent s t o com m unicat e wit h one anot her.
This is a core funct ion of t he Windows kernel and cannot be disabled. The vulnerabilit y result s
because t he Windows RPC service does not properly check m essage input s under cert ain
circum st ances. By sending a m alform ed RPC m essage, an at t acker can cause t he RPC service on
a device t o fail in such a way t hat arbit rary code could be execut ed. The t ypical exploit for t his
vulnerabilit y launches a reverse- t elnet back t o t he at t acker's host t o gain com plet e access t o t he
t arget .

Successful exploit at ion of t his vulnerabilit y enables an at t acker t o run code wit h local syst em
privileges. This enables an at t acker t o inst all program s; view, change, or delet e dat a; and creat e
new account s wit h full privileges. Because RPC is act ive by default on all versions of t he Windows
operat ing syst em , any user who can deliver a m alform ed TCP request t o an RPC int erface of a
vulnerable com put er could at t em pt t o exploit t he vulnerabilit y. I t is even possible t o t rigger t his
vulnerabilit y t hrough ot her m eans, such as logging int o an affect ed syst em and exploit ing t he
vulnerable com ponent locally.

A variant of t he RPC DCOM worm is t erm ed W32 Blast er or MS Blast er. When MS Blast er
successfully exploit s a host , it at t em pt s t o upload a copy of t he worm program t o t he newly
exploit ed host . MS Blast er uses TFTP t o copy t he worm program from t he at t acking host t o t he
t arget syst em . MS Blast er also st art s up a cm d.exe process and binds it t o TCP port 4444 of t he
newly exploit ed syst em . This provides any at t acker wit h direct com m and- line access at t he local
syst em privilege level, as discussed previously.

To access t he syst em , t he at t acker needs only t o t elnet t o TCP port 4444 on t he exploit ed host .
I f t he worm is successful in copying t he MS Blast er program t o t he t arget , t he worm exploit code
m odifies t he syst em regist ry t o ensure t hat t he worm is rest art ed if t he syst em reboot s. I t t hen
launches t he worm program on t he newly exploit ed host t o begin t he cycle again, st art ing wit h
scanning for m ore exploit able host s. MS Blast er also cont ained code for a DoS at t ack. This
part icular at t ack was t arget ed at www.windowsupdat e.com .

NBAR can be used t o com bat t he RPC DCOM/ W32/ MS Blast er worm by ident ifying
com m unicat ions on TCP/ UDP port s 135, 139, and 445.

By default , t he NBAR e x ch a n ge PDLM is m apped t o TCP port 135; t herefore, t his PDLM can be
used as part of t he MS Blast er worm policy definit ion. Sim ilarly, t he NBAR n e t bios PDLM is
bound by default t o TCP/ UDP port 139 ( in addit ion t o TCP port 137 and UDP port s 137 and 138) ,
so t his PDLM also can be used wit hin t he policy definit ion; specifically, t he n e t bios PDLM can
have it s port m apping expanded t o include TCP port 445 and UDP port s 135, 139, and 445, as
shown in Exam ple 14- 15 .

N ot e
Alt ernat ively, a cust om PDLM can be defined for t hese port s ( TCP/ UDP 135, 139, and
445) , but before t his could be done, you would have t o m ap t he e x ch a n ge and
n e t bios PDLMs port s away from t heir default s, t o avoid conflict ing PDLM port
m appings.

Ex a m ple 1 4 - 1 5 . N BAR Policie s t o I de n t ify RPC D COM / W 3 2 / M S Bla st e r

!
ip nbar port-map netbios tcp 137 139 445 ! Matches TCP 137/139/445
ip nbar port-map netbios udp 135 137 138 139 445 ! Matches UDP 135/137-139/445
!
class-map match-any MS-BLASTER
match protocol exchange ! Matches TCP port 135
match protocol netbios ! Matches MS Blaster NetBIOS PDLM
!

Verificat ion com m ands:

sh ow policy

sh ow ip n ba r por t - m a p

NBAR Versus Sasser

The next m aj or worm aft er MS Blast er was t he Sasser worm ( and variant s Sasser.A/ B/ C/ D) ,
which was released in lat e April 2004. Sasser exploit s a flaw in t he Windows Local Securit y
Aut horit y Service Server ( LSASS) t hat can cause syst em s t o crash and cont inually reboot , or
allow a rem ot e at t acker t o execut e arbit rary code wit h local syst em privileges.

Sasser is very efficient in scanning: I t can scan 1024 separat e I P addresses sim ult aneously ( on
TCP port 445) . When scanning reveals a vulnerable syst em , t he worm exploit s t he LSASS
vulnerabilit y and creat es a rem ot e shell ( RSH) session on TCP port 9996 back t o t he infect ing
syst em . Then Sasser st art s an FTP server on TCP port 5554 t o ret rieve a copy of t he worm .

Sasser can be ident ified t hrough a cust om NBAR PDLM list ening for com m unicat ion on TCP port s
445, 5554, and 9996, as shown in Exam ple 14- 16 .

N ot e
I f TCP port 445 already has been bound t o t he n e t bios NBAR PDLM ( as recom m ended
previously in t he MS Blast er worm definit ion) , it is not necessary t o include t his port in
t he Sasser cust om PDLM port m apping ( because it will cause a conflict ) .

Ex a m ple 1 4 - 1 6 . N BAR Policie s t o I de n t ify Sa sse r

!
ip nbar port-map custom-03 tcp 445 5554 9996 ! Matches on TCP 445/5554/9996
!
class-map match-all SASSER
match protocol custom-03 ! Matches Sasser custom PDLM
!

Verificat ion com m ands:

sh ow policy
 sh ow ip n ba r por t - m a p

NBAR Versus Future Worms

There is every reason t o believe t hat new worm s will be released in t he fut ure. These worm s will
be not only m ore com plex, but also m ore efficient in t heir propagat ion, and t hus m ore dam aging
in t heir scope.

A new NBAR feat ure ( int roduced in Cisco I OS Release 12.3[ 4] T) enables net work adm inist rat ors
t o ext end t he capabilit y of NBAR t o classify ( and m onit or) addit ional st at ic port applicat ions or t o
allow NBAR t o classify unsupport ed st at ic port t raffic. Specifically, it enables adm inist rat ors t o
define t he st rings t hat t hey want t o search for in t he applicat ion payload ( for any applicat ion, not
j ust HTTP URLs) t o ident ify a given applicat ion.

This funct ionalit y can be used t o ident ify propriet ary applicat ions t hat ot herwise could not be
m at ched. However, it also can be very useful in plugging holes t hat fut ure worm s m ight open.

For exam ple, consider t he exam ple of a fict it ious worm called Moonbeam . Moonbeam scans and
propagat es it self on random ly generat ed TCP port s wit hin t he range of 21000 t hrough 21999.
Furt herm ore, t he worm carries t he word Moonbeam wit hin t he payload, beginning wit h t he nint h
ASCI I charact er of t he st ring. Moonbeam 's ( fict it ious) payload is shown in Exam ple 14- 17 .

Ex a m ple 1 4 - 1 7 . M oon be a m W or m Pa yloa d

\x04\x01Moonbeam\x01\x01\x01\x01.*[.][Dd][Ll][Ll]u9090%u6858%ucbd3%
u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%
u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a 403 ...

Moonbeam could be ident ified by a cust om NBAR PDLM t hat exam ines TCP packet s wit hin t he
range of 21000 t hrough 21999, ignores t he first eight ASCI I values, and checks for t he st ring
" Moonbeam " ( case sensit ive) , as shown in Exam ple 14- 18 .

Ex a m ple 1 4 - 1 8 . N BAR Policie s t o I de n t ify M oon be a m

!
ip nbar custom MOONBEAM 8 ascii Moonbeam tcp range 21000 21999 ! "Moonbeam" PDLM
!
class-map match-all MOONBEAM-WORM
match protocol MOONBEAM ! Matches the "Moonbeam" custom PDLM
!

Verificat ion com m ands:

sh ow policy

sh ow ip n ba r por t - m a p
Policing Known Worms

These are j ust a few exam ples of known worm s t hat can be ident ified using NBAR. Aft er t raffic
generat ed by known worm s has been posit ively ident ified, it should not be re- m arked or lim it ed;
rat her, it should be dropped im m ediat ely. This can be done on ingress on branch LAN edges, as
shown in Exam ple 14- 19 , which com bines t he policies for Code Red, NI MDA, SQL Slam m er, RPC
DCOM/ W32/ MS Blast er, and Sasser. Addit ionally, t he fict it ious worm Moonbeam has been
included in t he policy.

N ot e
A recursive classificat ion is required in t his policy for SQL Slam m er. This is because
SQL Slam m er requires a m a t ch - a ll crit eria for it s init ial classificat ion, but for policy-
m anagem ent purposes, it is desired t hat t his init ial classificat ion of SQL Slam m er be
lum ped under a single policy ( wit h a m a t ch - a n y crit eria) t o ident ify and drop all
known worm s.

Ex a m ple 1 4 - 1 9 . N BAR Br a n ch LAN Edge I n gr e ss Policy for Kn ow n

W or m s

!
ip nbar port-map custom-02 udp 1434 ! SQL Slammer custom PDLM
ip nbar port-map custom-03 tcp 5554 9996 ! Sasser custom PDLM
ip nbar port-map netbios tcp 137 139 445 ! MS Blaster TCP 137/139/445
ip nbar port-map netbios udp 135 137 138 139 445 ! MS Blaster UDP 135/137-139/445
ip nbar custom MOONBEAM 8 ascii Moonbeam tcp range 21000 21999 ! "Moonbeam" PDLM
!
class-map match-all SQL-SLAMMER
match protocol custom-02 ! Matches the SQL Slammer PDLM
match packet length min 404 max 404 ! Matches the packet length (376+28)
!
class-map match-any WORMS
match protocol http url "*.ida*" ! CodeRed
match protocol http url "*cmd.exe*" ! CodeRed
match protocol http url "*root.exe*" ! CodeRed
match protocol http url "*readme.eml*" ! NIMDA
match class-map SQL-SLAMMER ! SQL Slammer class-map
match protocol exchange ! MS Blaster (TCP 135)
match protocol netbios ! MS Blaster NetBIOS PDLM
match protocol custom-03 ! Sasser custom PDLM
match protocol MOONBEAM ! "Moonbeam" PDLM
!
policy-map WORM-DROP
class WORMS
drop ! Drops all known worms
!
...
!
interface FastEthernet0/0
no ip address
 speed auto
duplex auto
!
interface FastEthernet0/0.60
description DVLAN SUBNET 10.1.60.0
encapsulation dot1Q 60
ip address 10.1.60.1 255.255.255.0
service-policy input WORM-DROP ! Drops known worms (DVLAN only)
!
Case Study: Branch Router QoS Design
Cont inuing t he exam ple from t he previous chapt ers, t he fict it ious com pany ABC, I nc., already is
correct ly classifying and m arking all 11 classes of t raffic from t he QoS Baseline Model wit hin it s
cam pus. Such m arking is being perform ed at Layer 3 via DSCP. Furt herm ore, dual- rat e policing
is used wit hin t he cam pus so t hat cert ain AF classes of t raffic can be m arked down t o a second
level of drop preference ( for exam ple, AF21 can be m arked down t o AF22) . Addit ionally, t he
WAN aggregat or is provisioning LLQ and CBWFQ policies ( wit h WRED on m aj or dat a classes) for
all 11 classes of t raffic over t he preferred Layer 2 WAN m edium : ATM.

Every quart er, ABC, I nc., m ult icast s com pany m eet ings t o all it s branches and provides each
branch wit h on- dem and ( unicast ) e- learning cont ent . However, because all t he I P/ TV servers
belonging t o ABC, I nc., are locat ed at t he cent ral cam pus, t hey see no need t o provision a class
for St ream ing- Video in bot h direct ions on t he WAN links. Therefore, t he com pany has chosen t o
elim inat e t his class from t he branch rout er WAN edge configurat ions and redist ribut e t he
bandwidt h bet ween t he Mission- Crit ical Dat a class and t he Transact ional Dat a class.

Current ly, t he branch access swit ches do not have t he capabilit y t o classify and m ark t raffic,
alt hough t hey plan t o event ually deploy swit ches in t heir branches wit h such capabilit ies
( including dual- rat e policing and m arking) . I n t he m eant im e, ABC, I nc., will m ark all branch- t o-
cam pus t raffic on t he branch rout er's LAN edge on ingress. When t he budget enables t hem t o
upgrade t heir branch swit ches, m arking policies dependent on Layer 3 or Layer 4 crit eria will be
pushed out t o t he branch access swit ch ( based on designs covered in Chapt er 12 ) . However,
policies will rem ain on t he branch rout er's LAN edge t o classify and m ark applicat ions t hat
require st at eful packet inspect ion ( using NBAR) .

ABC, I nc., also has been hit wit h a num ber of worm s over t he past few years and want s t o do
everyt hing possible t o lim it and m it igat e such at t acks. The com pany has provisioned Scavenger-
class QoS wit hin t he cam pus and WAN edges. Furt herm ore, ABC, I nc., has chosen t o deploy
NBAR policies t o ident ify and drop known worm s t hat m ight originat e wit hin t heir branches.
These policies are included in t he branch rout er's ingress QoS policies.

QoS designs for t he WAN and LAN edges of one of ABC, I nc.'s, branch rout ers is illust rat ed in
Figure 14- 4 and det ailed in Exam ple 14- 20 .

Figu r e 1 4 - 4 . Ca se St u dy: Br a n ch Rou t e r w it h 1 0 - Cla ss QoS Ba se lin e

W AN Edge Policie s a n d D SCP- t o- CoS Re m a ppin g a n d N BAR
Cla ssifica t ion Plu s W or m - D r oppin g LAN Edge Policie s

[View full size image]

Ex a m ple 1 4 - 2 0 . Ca se St u dy: Br a n ch Rou t e r w it h 1 0 - Cla ss QoS Ba se lin e
W AN Edge Policie s, D SCP- t o- CoS Re m a ppin g, a n d N BAR Cla ssifica t ion
Plu s W or m - D r oppin g LAN Edge Policie s

!
ip nbar port-map custom-01 tcp 3200 3201 3202 3203 3600 ! SAP custom PDLM
ip nbar port-map custom-02 udp 1434 ! SQL Slammer PDLM
ip nbar port-map custom-03 tcp 5554 9996 ! Sasser PDLM
ip nbar port-map netbios tcp 137 139 445 ! MS Blaster NetBIOS
ip nbar port-map netbios udp 135 137 138 139 445 ! MS Blaster NetBIOS
ip nbar custom MOONBEAM 8 ascii Moonbeam tcp range 21000 21999 ! "Moonbeam" PDLM
!
!
class-map match-all BRANCH-MISSION-CRITICAL
match access-group name MISSION-CRITICAL-SERVERS ! MC Data ACL to reference
!
class-map match-any BRANCH-TRANSACTIONAL-DATA
match protocol citrix ! Identifies Citrix traffic
match protocol ldap ! Identifies LDAP traffic
match protocol sqlnet ! Identifies Oracle SQL*NET traffic
match protocol http url "*SalesReport*" ! Identifies "SalesReport" URLs
match protocol custom-01 ! Identifies SAP traffic via PDLM
!
class-map match-any BRANCH-NET-MGMT
match protocol snmp ! Identifies SNMP traffic
match protocol syslog ! Identifies Syslog traffic
match protocol telnet ! Identifies Telnet traffic
match protocol nfs ! Identifies NFS traffic
match protocol dns ! Identifies DNS traffic
match protocol icmp ! Identifies ICMP traffic
match protocol tftp ! Identifies TFTP traffic
!
class-map match-all BRANCH-BULK-DATA
match access-group name BULK-DATA-APPS ! Reference ACL for Bulk Data apps
!
class-map match-any BRANCH-SCAVENGER
match protocol napster ! Identifies Napster traffic
 match protocol gnutella ! Identifies Gnutella traffic
match protocol fasttrack ! Identifies KaZaa (v1) traffic
match protocol kazaa2 ! Identifies KaZaa (v2) traffic
!
class-map match-all SQL-SLAMMER
match protocol custom-02 ! Matches the custom Slammer PDLM
match packet length min 404 max 404 ! Matches the packet length (376+28)
!
class-map match-any WORMS
match protocol http url "*.ida*" ! CodeRed
match protocol http url "*cmd.exe*" ! CodeRed
match protocol http url "*root.exe*" ! CodeRed
match protocol http url "*readme.eml*" ! NIMDA
match class-map SQL-SLAMMER ! SQL Slammer class-map
match protocol exchange ! MS Blaster (TCP 135)
match protocol netbios ! MS Blaster NetBIOS PDLM
match protocol custom-03 ! Sasser custom PDLM
match protocol MOONBEAM ! "Moonbeam" PDLM
!
!
class-map match-all VOICE
match ip dscp ef ! IP Phones mark Voice to EF
class-map match-all INTERACTIVE-VIDEO
match ip dscp af41 af42 ! Recommended markings for IP/VC
class-map match-any CALL-SIGNALING
match ip dscp cs3 ! Future Call-Signaling marking
match ip dscp af31 ! Current Call-Signaling marking
class-map match-all ROUTING
match ip dscp cs6 ! Routers mark Routing traffic to CS6
class-map match-all NET-MGMT
match ip dscp cs2 ! Net-Mgmt apps are marked via NBAR ingress policy
class-map match-all MISSION-CRITICAL-DATA
match ip dscp 25 ! MC Data apps are marked via ACL ingress policy
class-map match-all TRANSACTIONAL-DATA
match ip dscp af21 af22 ! Transactional apps are marked via NBAR policy
class-map match-all BULK-DATA
match ip dscp af11 af12 ! Bulk Data apps are marked via ACL ingress policy
class-map match-all SCAVENGER
match ip dscp cs1 ! Scavenger apps are marked via NBAR ingress policy
!
!
policy-map BRANCH-LAN-EDGE-OUT ! Enhanced Packet Marking DSCP-to-CoS policy
class class-default
set cos dscp ! Default DSCP-to-CoS marking
!
!
policy-map BRANCH-LAN-EDGE-IN ! BRANCH LAN Edge Ingress Marking Policy
class BRANCH-MISSION-CRITICAL
set ip dscp 25 ! Marks Mission-Critical apps to DSCP 25
class BRANCH-TRANSACTIONAL-DATA
set ip dscp af21 ! Marks Transactional Data apps to DSCP AF21
class BRANCH-NET-MGMT
set ip dscp cs2 ! Marks Net Mgmt apps to DSCP CS2
class BRANCH-BULK-DATA
set ip dscp af11 ! Marks Bulk Data apps to DSCP AF11
class BRANCH-SCAVENGER
 set ip dscp cs1 ! Marks Scavenger apps to DSCP CS1
class WORMS
drop ! Drops all known worms
class class-default
set ip dscp default ! Marks everything else to DSCP 0
!
!
policy-map BRANCH-WAN-EDGE
class VOICE
priority percent 18 ! Voice gets 552 kbps of LLQ
class INTERACTIVE-VIDEO
priority percent 15 ! 384 kbps IP/VC needs 460 kbps of LLQ
class CALL-SIGNALING
bandwidth percent 5 ! Minimal BW guarantee for Call-Signaling
class ROUTING
bandwidth percent 3 ! Routing class gets 3% explicit BW guarantee
class NET-MGMT
bandwidth percent 2 ! Net-Mgmt class gets 2% explicit BW guarantee
class MISSION-CRITICAL-DATA
bandwidth percent 15 ! Mission-Critical class gets min 15% BW guarantee
random-detect ! Enables WRED on Mission-Critical Data class
class TRANSACTIONAL-DATA
bandwidth percent 12 ! Transactional-Data class gets min 12% BW guarantee
random-detect dscp-based ! Enables DSCP-WRED on Transactional-Data class
class BULK-DATA
bandwidth percent 4 ! Bulk Data class gets 4% BW guarantee
random-detect dscp-based ! Enables DSCP-WRED on Bulk-Data class
class SCAVENGER
bandwidth percent 1 ! Scavenger class is throttled
class class-default
bandwidth percent 25 ! Default class gets min 30% BW guarantee
random-detect ! Enables WRED on the default class
!
...
!
interface FastEthernet0/0
no ip address
speed auto
duplex auto
!
interface FastEthernet0/0.60
description DVLAN SUBNET 10.1.60.0
encapsulation dot1Q 60
ip address 10.1.60.1 255.255.255.0
service-policy output BRANCH-LAN-EDGE-OUT ! Restores CoS on Data VLAN
service-policy input BRANCH-LAN-EDGE-IN ! Marks data and drops worms
!
interface FastEthernet0/0.160
description VVLAN SUBNET 10.1.160.0
encapsulation dot1Q 160
ip address 10.1.160.1 255.255.255.0
service-policy output BRANCH-LAN-EDGE-OUT ! Restores CoS on Voice VLAN
!
...
!
interface ATM3/0
 no ip address
no atm ilmi-keepalive
ima-group 0 ! ATM3/0 added to ATM IMA group 0
no scrambling-payload
!
interface ATM3/1
no ip address
no atm ilmi-keepalive
ima-group 0 ! ATM3/1 added to ATM IMA group 0
no scrambling-payload
!
...
!
interface ATM3/IMA0
no ip address
no atm ilmi-keepalive
!
interface ATM3/IMA0.12 point-to-point
ip address 10.6.12.1 255.255.255.252
pvc 0/100
vbr-nrt 3072 3072 ! ATM PVC speed set for Dual-T1
max-reserved-bandwidth 100 ! Overrides the default 75% BW limit
service-policy output BRANCH-WAN-EDGE ! Attaches MQC policy to the ATM PVC
!
!
...
!
ip access-list extended MISSION-CRITICAL-SERVERS
permit ip any 10.200.200.0 0.0.0.255 ! MC Data Server-Farm Subnet
!
ip access-list extended BULK-DATA-APPS
permit tcp any any eq ftp ! Identifies FTP Control traffic
permit tcp any any eq ftp-data ! Identifies FTP Default traffic
permit tcp any any eq pop3 ! Identifies POP3 E-mail traffic
permit tcp any any eq 143 ! Identifies IMAP E-mail traffic
!

Verificat ion com m ands:

sh ow policy m a p

sh ow policy- m a p in t e r fa ce

sh ow ip n ba r por t - m a p

sh ow a t m pvc

sh ow im a in t e r fa ce a t m
Summary
Alt hough t he QoS design recom m endat ions for branch rout ers are very sim ilar t o and are relat ed
t o t he QoS recom m endat ions for WAN aggregat ors, t his chapt er exam ined t hree unique
considerat ions of branch rout ers.

The first considerat ion is whet her applicat ions provisioned over t he WAN are bidirect ional or
unidirect ional. Som e unidirect ional applicat ions, such as St ream ing- Video, provisioned on t he
WAN aggregat or WAN edge do not need t o be provisioned correspondingly on t he branch
rout er's WAN edge. Bandwidt h from unidirect ional applicat ion classes can be redist ribut ed
am ong ot her preferent ial applicat ion classes on t he branch rout er's WAN edge.

The second considerat ion unique t o branch rout ers is t hat ingress m arking m ight need t o be
perform ed on branch- t o- cam pus t raffic. This m ight be because t he rem ot e branch access swit ch
does not have t he capabilit y t o classify and m ark t raffic, or it m ight be because som e
applicat ions require st at eful packet inspect ion ( NBAR) t o ident ify t hem correct ly. I n eit her case,
ingress m arking policies would be required on t he branch rout er's LAN edge, on t he dat a VLAN's
subint erface ( t he voice VLAN t raffic m arkings are t rust ed) . Branch- t o- cam pus t raffic can be
ident ified by Layer 3 param et ers ( such as dest inat ion subnet ) , Layer 4 param et ers ( such as well-
known TCP/ UDP port s) , or NBAR PDLMs. An exam ple of each t ype of classificat ion is provided.
Addit ionally, opt ional DSCP- t o- CoS m apping policies ( for rest oring 802.1p CoS m arkings t hat
were lost when cam pus- originat ed t raffic t raversed t he WAN m edia) can be set on t he branch
rout er's LAN edge.

A t hird unique considerat ion in branch QoS design is t hat branch rout er ingress LAN edges are a
st rat egic place t o deploy NBAR policies for worm ident ificat ion and policing. NBAR policies can be
used t o ident ify and drop Code Red, NI MDA, SQL Slam m er, RPC DCOM/ W32/ MS Blast er, Sasser,
and ot her worm s. This chapt er discussed an ext ension of t he NBAR feat ure t hat enables
adm inist rat ors t o program t he st rings t hat t hey want NBAR t o search packet payloads for; t his
feat ure enables NBAR policies t o be used t o ident ify new worm s t hat undoubt edly will be
released in t he fut ure.

Finally, a case st udy was present ed illust rat ing how t hese t hree unique considerat ions could be
com bined in a com plex branch rout er design.
Further Reading
Cisco I OS docum ent at ion:

Class- based m arking ( Cisco I OS Release 12.1.5T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios121/ 121newft / 121t / 121t 5/ cbpm ark2.ht m

Enhanced packet m arking ( Cisco I OS Release 12.2.13T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft enpkm k.ht

NBAR overview ( Cisco I OS Release 12.3) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fqos_c/ fqcprt 1/ qcfclass.ht m
.

Net work- Based Applicat ion Recognit ion ( Cisco I OS Release 12.1.5T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fqos_c/ fqcprt 1/ qcfnbar.ht m

Net work- Based Applicat ion Recognit ion ( Cisco I OS Release 12.2.8T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ dt nbarad.ht m

Net work- Based Applicat ion Recognit ion ( Cisco I OS Release 12.3[ 4] T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 8/ dt nbarad.ht m

Cisco SAFE whit epapers:

SAFE worm m it igat ion:

ht t p: / / www.cisco.com / en/ US/ net sol/ ns340/ ns394/ ns171/ ns128/ net working_solut ions_whit e_paper091
.

Using Net work- Based Applicat ion Recognit ion and ACLs for blocking t he Code Red worm :
ht t p: / / www.cisco.com / en/ US/ product s/ hw/ rout ers/ ps359/ product s_t ech_not e09186a00800fc176.sht m l

How t o prot ect your net work against t he NI MDA virus:

ht t p: / / www.cisco.com / en/ US/ product s/ sw/ iosswrel/ ps1835/ product s_t ech_not e09186a0080110d17.sht

SAFE SQL Slam m er worm at t ack m it igat ion:

ht t p: / / www.cisco.com / en/ US/ net sol/ ns340/ ns394/ ns171/ ns128/ net working_solut ions_whit e_paper091
.

SAFE RPC DCOM/ W32/ Blast er at t ack m it igat ion:

ht t p: / / www.cisco.com / en/ US/ net sol/ ns340/ ns394/ ns171/ ns128/ net working_solut ions_whit e_paper091
.

Com bat ing t he I nt ernet worm Sasser:

ht t p: / / www.cisco.com / applicat ion/ pdf/ en/ us/ guest / net sol/ ns441/ c664/ cdccont _0900aecd800f613b.pdf
Part V: VPN QoS Design
Part V of t his book provides an in- dept h discussion of QoS considerat ions and designs for
bot h MPLS and I PSec VPNs. MPLS VPN QoS design is exam ined from bot h t he ent erprise
subscriber's perspect ive, covering im port ant considerat ions and designs for m apping int o
service- provider m odels, and also from t he service provider's perspect ive, including MPLS
DiffServ Tunneling m odes and MPLS Traffic Engineering ( in brief) . I PSec VPN designs are
considered for bot h sit e- t o- sit e scenarios and t elecom m ut er scenarios.

The chapt ers in t his part of t he book are as follows:

Chapt er 15 MPLS VPN QoS Design

Chapt er 16 I PSec VPN QoS Design

Chapter 15. MPLS VPN QoS Design
MPLS VPN QoS design t ypically is viewed from t wo dist inct perspect ives:

The ent erprise cust om er subscribing t o t he MPLS VPN service

The service provider provisioning edge and core QoS wit hin t he MPLS VPN service

To achieve end- t o- end service levels, ent erprise and service- provider QoS policies m ust be
consist ent and com plim ent ary. Therefore, QoS considerat ions and design recom m endat ions for
bot h t he ent erprise and service provider are present ed in t his chapt er. The following t opics are
discussed:

Ent erprise- t o- service provider m apping m odels

Service provider- t o- ent erprise m odels

MPLS DiffServ t unneling m odes

DiffServ in t he backbone

MPLS t raffic engineering

MPLS is a com binat ion of rout ing and swit ching t echnologies t hat can provide scalable VPNs wit h
end- t o- end qualit y of service.

Many cust om ers are t urning t o service providers t hat offer MPLS VPN services as privat e WAN
alt ernat ives. One of t he m ain reasons for t his is t he any- t o- any connect ivit y capabilit ies of MPLS
VPNs. However, t his full- m esh nat ure in it self poses significant QoS im plicat ions t o ent erprise
cust om ers and service providers alikenam ely, t hat t hey bot h need t o com anage QoS in a
cooperat ive and com plem ent ary fashion t o achieve end- t o- end service levels.

This chapt er exam ines in det ail QoS considerat ions t hat ent erprise cust om ers need t o bear in
m ind when subscribing t o MPLS VPNs, including how best t o m ap int o various service- provider
MPLS VPN QoS m odels.

Service provider- edge QoS considerat ions are reviewed in dept h, including egress queuing
m odels and MPLS DiffServ t unneling m odes ( Uniform , Short Pipe, and Pipe) . Furt herm ore,
service- provider core QoS considerat ions are reviewed, including aggregat e bandwidt h
provisioning and DiffServ in t he backbone. MPLS t raffic engineering as it relat es t o QoS is
covered, along wit h t wo det ailed exam ples: MPLS per- VPN t raffic engineering and MPLS DiffServ
t raffic engineering.

This chapt er concludes wit h a case st udy t hat shows how t hese designs can be com bined in a
com plex MPLS VPN end- t o- end scenario.

N ot e
This chapt er addresses QoS design for MPLS VPNs, not t he t heory and operat ion of
MPLS VPNs t hem selves. I t is assum ed t hat t he reader is fam iliar wit h basic MPLS VPN
archit ect ures and t echnologies. For a det ailed discussion of MPLS VPNs, refer t o t he
Cisco Press books MPLS and VPN Archit ect ures, Volum es I and I I , by I van Pepelnj ak
and Jim Guichard; Traffic Engineering wit h MPLS, by Eric Osborne and Aj ay Sim ha; and
Advanced MPLS Design and I m plem ent at ion, by Vivek Alwayn.
Where Is QoS Needed over an MPLS VPN?
MPLS VPN archit ect ures are com prised of cust om er edge ( CE) rout ers, provider- edge ( PE)
rout ers, and provider ( P) rout ers. MPLS VPNs provide fully m eshed Layer 3 virt ual WAN services
t o all int erconnect ed CE rout ers, as out lined by RFC 2547. This fully m eshed charact erist ic of
MPLS VPNs present s a significant design im plicat ion t o t radit ional Layer 2 WAN QoS design.

Because of cost , scalabilit y, and m anageabilit y const raint s, t radit ional privat e WAN designs
rarely use full- m esh m odels. I nst ead, m ost Layer 2 WAN designs revolve around a hub- and-
spoke m odel, im plem ent ing eit her a cent ralized hub design or t he m ore efficient regional hub
design. Under such hub- and- spoke designs, QoS prim arily is adm inist ered at t he hub rout er by
t he ent erprise. As long as t he service provider m eet s t he cont ract ed service levels, t he packet s
received at rem ot e branches will reflect t he scheduling policies of t he hub rout er ( som et im es
referred t o as a WAN aggregat or ) . The WAN aggregat or cont rols not only cam pus- t o- branch
t raffic, but also branch- t o- branch t raffic ( which is hom ed t hrough t he hub) . Under t radit ional
hub- and- spoke m odels, QoS principally is adm inist ered by t he ent erprise cust om er, as shown in
Figure 15- 1.

Figu r e 1 5 - 1 . QoS Adm in ist r a t ion in Tr a dit ion a l H u b- a n d- Spok e La ye r 2

W AN D e sign

[View full size image]

However, wit h t he advent of MPLS VPN service offerings t hat inherent ly offer full- m esh
connect ivit y, t he QoS adm inist rat ion paradigm shift s. Under a full- m esh design, t he hub rout er
st ill adm inist ers QoS for all cam pus- t o- branch t raffic, but it no longer fully cont rols t he QoS for
branch- t o- branch t raffic. Alt hough it m ight appear t hat t he only required workaround for t his
new scenario is t o ensure t hat QoS is provisioned on all branch rout ers, t his is insufficient
because it addresses only part of t he issue.

For exam ple, consider t he case of provisioning any- t o- any videoconferencing. As wit h a
t radit ional Layer 2 WAN design, a scheduling policy t o priorit ize I P/ VC on t he WAN aggregat or is
required. Then t he ent erprise m ust properly provision sim ilar priorit y scheduling for I P/ VC on t he
branch rout ers also. I n t his m anner, any videoconferencing calls from t he cam pus t o t he branch
( and also from branch t o branch) are prot ect ed against t raffic of lesser im port ance flowing
bet ween t he sam e sit es. The com plexit y of t he fully m eshed m odel arises when considering t hat
cont ending t raffic m ight not always com e for t he sam e sit es, but could com e from any sit e.
Furt herm ore, t he ent erprise no longer fully cont rols QoS for branch- t o- branch t raffic because
t his t raffic no longer is hom ed t hrough a hub. Cont inuing t he exam ple, if a videoconferencing call
is set up bet ween t wo branches and a user from one of t he branches also init iat es a large FTP
download from t he cent ral sit e, t he pot ent ial for oversubscript ion of t he PE- t o- CE link from t he
fully m eshed MPLS VPN cloud int o one of t he branches becom es very real, likely causing drops
from t he I P/ VC call.

The only way t o guarant ee service levels in such a scenario is for t he service provider t o
provision QoS scheduling t hat is com pat ible wit h t he ent erprise's policies on all PE links t o
rem ot e branches. This is what creat es t he paradigm shift in QoS adm inist rat ion for fully m eshed
t opologies. Nam ely, ent erprises and service providers m ust cooperat e t o j oint ly adm inist er QoS
over MPLS VPNs, as shown in Figure 15- 2.

Figu r e 1 5 - 2 . QoS Adm in ist r a t ion in Fu lly M e sh e d M PLS VPN D e sign

[View full size image]

Queuing policies are m andat ory on CE and PE rout ers because of t he full- m esh im plicat ions of
MPLS VPNs. PE rout ers also t ypically have policing ( and m arkdown) policies on ingress t o enforce
SLAs.

QoS policies on P rout ers are opt ional. Such policies are opt ional because som e service providers
overprovision t heir MPLS core net works and, as such, do not require any addit ional QoS policies
wit hin t heir backbones; on t he ot her hand, ot her providers m ight im plem ent sim plified DiffServ
policies wit hin t heir cores or m ight even deploy MPLS t raffic engineering ( MPLS TE) t o handle
congest ion scenarios wit hin t heir backbones. Figure 15- 3 sum m arizes t he point s where QoS
policies can be provisioned wit hin MPLS VPN archit ect ures.

Figu r e 1 5 - 3 . W h e r e QoS I s Re qu ir e d in M PLS VPN Ar ch it e ct u r e s

[View full size image]

This design chapt er first exam ines CE and PE QoS designs; t hen it overviews MPLS VPN core QoS
opt ions and designs.
Customer Edge QoS Design Considerations
I n addit ion t o t he full- m esh im plicat ion of MPLS VPNs, t hese considerat ions should be kept in
m ind when considering MPLS VPN CE QoS design:

Layer 2 access ( link- specific) QoS design

Service- provider service- level agreem ent s ( SLA)

Ent erprise- t o- service provider m apping m odels

The following sect ions exam ine t hese considerat ions in m ore det ail.

Layer 2 Access (Link-Specific) QoS Design

Alt hough MPLS VPNs are essent ially Layer 3 WANs, a Layer 2 access m edium t o connect t o t he
MPLS VPN service provider is an obvious requirem ent . Most providers support Fram e Relay and
ATM as access m edia because t his m akes m igrat ion from Layer 2 WANs t o Layer 3 MPLS VPNs
easier and cheaper t o m anage; cust om ers are not forced t o convert hardware on hundreds ( or,
in som e cases, t housands) of rem ot e branch rout ers t o connect t o MPLS VPN providers.

I t is im port ant t o recognize t hat Layer 2 QoS link- specific issues and designs rem ain t he sam e
wit h regular Layer 2 WAN edges or wit h Layer 3 MPLS VPN CE/ PE edges. For exam ple, shaping
and LFI recom m endat ions for slow- speed FR links are ident ical whet her t he link is used for a
Layer 2 WAN or for a Layer 3 MPLS VPN access link. Again, t his m akes m igrat ion easier t o
m anage because link- specific QoS designs do not need t o be changed ( alt hough t he service
policy it self m ight require m inor m odificat ion, which is discussed in m ore det ail short ly) .

I n addit ion t o FR and ATM for access, som e service providers support Et hernet / Fast Et hernet as
access m edia but usually guarant ee a CI R of only subline rat e. I n such cases, hierarchical
shaping and queuing policies on t he CE edges are recom m ended, as illust rat ed lat er in t his
chapt er.

Service-Provider Service-Level Agreements

End- t o- end QoS is like a chain t hat is only as st rong as t he weakest link. Therefore, it 's essent ial
for ent erprises ( wit h converged net works) subscribing t o MPLS VPN services t o choose service
providers t hat can provide t he required SLAs for t heir converged net works. For exam ple, t hese
are t he end- t o- end SLA requirem ent s of voice and int eract ive video:

No m ore t han 150 m s of one- way lat ency from m out h t o ear ( per I TU G.114 st andard)

No m ore t han 30 m s of j it t er

No m ore t han 1 percent loss

As a subset of t he t rip, t he service provider's com ponent of t he SLA m ust be considerably

t ight er. These SLAs are defined for Cisco- Powered Net works ( CPN) I P Mult iservice Service
Providers:

No m ore t han 60 m s of one- way lat ency from edge t o edge

No m ore t han 20 m s of j it t er

No m ore t han 0.5 percent loss

Figure 15- 4 illust rat es t he int errelat ionship of t hese SLAs.

Figu r e 1 5 - 4 . CPN - I P M u lt ise r vice Se r vice - Pr ovide r SLAs

CPN- I P Mult iservice Service Providers t hat m eet t hese SLAs can be found at
ht t p: / / www.cisco.com / pcgi- bin/ cpn/ cpn_pub_bassrch.pl; choose t he I P VPN Mult iservice opt ion.

To achieve such end- t o- end SLAs, ent erprise cust om ers ( m anaging CEs) and service providers
( m anaging PEs and core Ps) m ust cooperat e and be consist ent in classifying, provisioning, and
int egrat ing t heir respect ive QoS designs. To t his end, various m apping m odels have been
developed t o int egrat e ent erprise requirem ent s int o service- provider solut ions.

Enterprise-to-Service Provider Mapping Models

Alt hough Cisco is adopt ing it s new QoS Baseline init iat ive and designing t ools such as Cisco
Aut oQoS Ent erprise t o facilit at e and sim plify t he deploym ent of advanced QoS t raffic m odels
wit hin t he ent erprise, t o dat e, very few ent erprises have deployed m ore t han a handful of t raffic
classes. Therefore, m ost service providers offer only a lim it ed num ber of classes wit hin t heir
MPLS VPN clouds. At t im es, t his m ight require ent erprises t o collapse t he num ber of classes t hat
t hey have provisioned t o int egrat e int o t heir service provider's QoS m odels. The following
caveat s should be rem em bered when deciding how best t o collapse and int egrat e ent erprise
classes int o various service- provider QoS m odels.

Voice and Video

Service providers t ypically offer only one Real- Tim e class or Priorit y class of service. I f an
ent erprise want s t o deploy bot h Voice and I nt eract ive- Video ( each of which is recom m ended t o
be provisioned wit h st rict priorit y t reat m ent ) over t heir MPLS VPN, t hey m ight be faced wit h a
dilem m a. Which one should be assigned t o t he Real- Tim e class? Are t here any im plicat ions about
assigning bot h t o t he Real- Tim e class?

Keep in m ind t hat voice and video should never bot h be assigned low- lat ency queuing on link
speeds where serializat ion is a fact or ( 768 kbps) . Packet s offered t o t he LLQ t ypically are not
fragm ent ed; t hus, large I P/ VC packet s can cause excessive delays for VoI P packet s on slow-
speed links.

An alt ernat ive is t o assign I P/ VC t o a nonpriorit y class, which ent ails not only t he obvious caveat
of lower service levels, but also possible t raffic- m ixing concerns, as discussed short ly.

Call-Signaling

VoI P requires provisioning not only of RTP bearer t raffic, but also of Call- Signaling t raffic, which
is very light weight and requires only a m oderat e am ount of guarant eed bandwidt h. Because t he
service levels applied t o Call- Signaling t raffic direct ly affect delay t o t he dial t one, it is im port ant
from t he end user's expect at ions t hat Call- Signaling be prot ect ed. Service providers m ight not
always offer a suit able class j ust for call signaling t raffic it self, leading t o t he quest ion of which
ot her t raffic classes Call- Signaling should be m ixed wit h.

On links where serializat ion is not an issue ( > 768 kbps) , Call- Signaling could be provisioned int o
t he Real- Tim e class, along wit h voice.

However, t his is not recom m ended on slow- speed links where serializat ion is a fact or. On such
slow- speed links, Call- Signaling is best assigned t o one of t he preferent ial dat a classes for which
t he service provider provides a bandwidt h guarant ee.

I t is im port ant t o realize t hat a guarant ee applied t o a service- provider class as a whole does not
it self guarant ee adequat e bandwidt h for an individual ent erprise applicat ions wit hin t he class.

Mixing TCP with UDP

I t is a general best pract ice t o not m ix TCP- based t raffic wit h UDP- based t raffic ( especially
St ream ing- Video) wit hin a single service- provider class because of t he behaviors of t hese
prot ocols during periods of congest ion. Specifically, TCP t ransm it t ers t hrot t le back flows when
drops are det ect ed. Alt hough som e UDP applicat ions have applicat ion- level windowing, flow
cont rol, and ret ransm ission capabilit ies, m ost UDP t ransm it t ers are com plet ely oblivious t o drops
and, t hus, never lower t ransm ission rat es because of dropping.
When TCP flows are com bined wit h UDP flows wit hin a single service- provider class and t he class
experiences congest ion, TCP flows cont inually lower t heir t ransm ission rat es, pot ent ially giving
up t heir bandwidt h t o UDP flows t hat are oblivious t o drops. This effect is called TCP
st arvat ion/ UDP dom inance.

TCP st arvat ion/ UDP dom inance likely occurs if ( TCP- based) Mission- Crit ical Dat a is assigned t o
t he sam e service- provider class as ( UDP- based) St ream ing- Video and t he class experiences
sust ained congest ion. Even if WRED is enabled on t he service- provider class, t he sam e behavior
would be observed because WRED ( for t he m ost part ) m anages congest ion only on TCP- based
flows.

Grant ed, it is not always possible t o separat e TCP- based flows from UDP- based flows, but it is
beneficial t o be aware of t his behavior when m aking such applicat ion- m ixing decisions wit hin a
single service- provider class.

Marking and Re-Marking

Most service providers use Layer 3 m arking at t ribut es ( I PP or DSCP) of packet s offered t o t hem
t o det erm ine which service provider class of service t he packet should be assigned t o. Therefore,
ent erprises m ust m ark or re- m ark t heir t raffic consist ent wit h t heir service provider's adm ission
crit eria t o gain t he appropriat e level of service. Addit ionally, service providers m ight re- m ark at
Layer 3 out - of- cont ract t raffic wit hin t heir cloud, which m ight affect ent erprises t hat require
consist ent end- t o- end Layer 3 m arkings.

A general DiffServ principle is t o m ark or t rust t raffic as close t o t he source as adm inist rat ively
and t echnically possible. However, cert ain t raffic t ypes m ight need t o be re- m arked before
handoff t o t he service provider t o gain adm ission t o t he correct class. I f such re- m arking is
required, it is recom m ended t hat t he re- m arking be perform ed at t he CE's egress edge, not
wit hin t he cam pus. This is because service- provider service offerings likely will evolve or expand
over t im e, and adj ust ing t o such changes will be easier t o m anage if re- m arking is perform ed
only at t he CE egress edge.

Addit ionally, in som e cases, m ult iple t ypes of t raffic are required t o be m arked t o t he sam e
DiffServ code point value t o gain adm ission t o t he appropriat e queue. For exam ple, on high-
speed links, it m ight be desired t o send Voice, I nt eract ive- Video, and Call- Signaling t o t he
service provider's Real- Tim e class. I f t his service- provider class adm it s only DSCP EF and CS5,
t wo of t hese t hree applicat ions would be required t o share a com m on code point . The class-
based m arking configurat ion in Exam ple 15- 1 shows how t his can be done ( in t his exam ple, bot h
I nt eract ive- Video and Call- Signaling are re- m arked t o share DSCP CS5) .

Ex a m ple 1 5 - 1 . CE ( Egr e ss) En t e r pr ise - t o- Se r vice Pr ovide r Re - M a r k in g

Ex a m ple

!
class-map match-any VOICE
match ip dscp ef
class-map match-all INTERACTIVE-VIDEO
match ip dscp af41
class-map match-any CALL-SIGNALING
match ip dscp af31
match ip dscp cs3
!
 policy-map CE-EGRESS-EDGE
class VOICE
priority percent 18
class INTERACTIVE-VIDEO
priority percent 15
set ip dscp cs5 ! Interactive-Video is remarked to CS5
class CALL-SIGNALING
priority percent 2 ! Call-Signaling gets LLQ for this scenario
set ip dscp cs5 ! Call-Signaling is also remarked to CS5
!
!
interface Serial1/0
service-policy output CE-EGRESS-EDGE
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

Service providers m ight re- m ark t raffic at Layer 3 t o indicat e whet her cert ain flows are out of
cont ract . Alt hough t his is consist ent wit h DiffServ st andards, such as RFC 2597, it m ight present
m inor difficult ies t o ent erprises t hat require consist ent end- t o- end Layer 3 m arking ( t ypically, for
m anagem ent or account ing purposes) . I n such cases, t he ent erprise can choose t o apply re-
m arking policies as t raffic is received back from t he service provider's MPLS VPN ( on t he ingress
direct ion of t he ent erprise's CE) .

Class- based m arking can be used again because it support s not only access list s for
classificat ion, but also Net work- Based Applicat ion Recognit ion ( NBAR) .

Cont inuing and expanding on t he previous exam ple, t he ent erprise want s t o rest ore t he original
m arkings t hat it set for I nt eract ive- Video and Call- Signaling. Addit ionally, it want s t o rest ore
original m arkings for Oracle t raffic ( which it originally m arked DSCP 25 and is using TCP port
9000 wit h) and DLSw+ t raffic ( originally m arked AF21) . Bot h of t hese dat a applicat ions were
handed off t o t he service provider m arked as AF21, but t hey m ight have been m arked down t o
AF22 wit hin t he service- provider cloud. Exam ple 15- 2 shows a configurat ion t hat enables such
re- m arking from t he MPLS VPN. The " m at ch- all" crit eria of t he class m aps perform s a logical
AND operat ion against t he pot ent ial m arkings and re- m arkings, and t he access list ( or NBAR-
support ed prot ocol) t hat sift s t he applicat ions apart . The policy is applied on t he sam e CE link,
but in t he ingress direct ion.

Ex a m ple 1 5 - 2 . CE ( I n gr e ss) Se r vice Pr ovide r - t o- En t e r pr ise Re - M a r k in g

Ex a m ple

!
class-map match-all REMARKED-INTERACTIVE-VIDEO
match ip dscp cs5
match access-group 101 ! Interactive-Video must be CS5 AND UDP
!
class-map match-all REMARKED-CALL-SIGNALING
 match ip dscp cs5
match access-group 102 ! Call-Signaling must be CS5 AND TCP
!
class-map match-all REMARKED-ORACLE
match ip dscp af21 af22 ! Oracle may have been remarked to AF22
match access-group 103 ! Oracle uses TCP port 9000
!
class-map match-all REMARKED-DLSW+
match ip dscp af21 af22 ! DLSw+ may have been remarked to AF22
match protocol dlsw ! DLSw+ is identified by NBAR
!
policy-map CE-INGRESS-EDGE
class REMARKED-INTERACTIVE-VIDEO
set ip dscp af41 ! Restores Interactive-Video marking to AF41
class REMARKED-CALL-SIGNALING
set ip dscp af31 ! Restores Call-Signaling marking to AF31
class REMARKED-ORACLE
set ip dscp 25 ! Restores Oracle marking to DSCP 25
class REMARKED-DLSW+
set ip dscp af21 ! Restores DLSw+ marking to AF21
!
!
interface serial 1/0
service-policy output CE-EGRESS-EDGE
service-policy input CE-INGRESS-EDGE ! Marking restoration on ingress
!
!
access-list 101 permit udp any any ! Identifies UDP traffic
access-list 102 permit tcp any any ! Identifies TCP traffic
access-list 103 permit tcp any eq 9000 any ! Identifies Oracle on TCP 9000
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

Three-Class Provider-Edge Model: CE Design

I n t his m odel, t he service provider offers t hree classes of service: Real- Tim e ( st rict priorit y,
available in 5- percent increm ent s) , Crit ical Dat a ( guarant eed bandwidt h) , and Best - Effort . The
adm ission crit erion for t he Real- Tim e class is eit her DSCP EF or CS5; t he adm ission crit erion for
Crit ical Dat a is DSCP CS6, AF31, or CS3. All ot her code point s are re- m arked t o 0. Addit ionally,
out - of- cont ract AF31 t raffic can be m arked down wit hin t he service provider's MPLS VPN cloud t o
AF32.

Under such a m odel, t here is no recom m ended provision for prot ect ing St ream ing- Video
( following t he " Don't m ix TCP wit h UDP" guideline) , nor is t here a service- provider class suit able
for bulk dat a, which consist s of large, nonburst y TCP sessions t hat could drown out sm aller dat a
t ransact ions. Figure 15- 5 shows a re- m arking diagram for a t hree- class service- provider m odel.
 Figu r e 1 5 - 5 . Th r e e - Cla ss Pr ovide r - Edge M ode l Re - M a r k in g D ia gr a m

[View full size image]

Exam ple 15- 3 shows an exam ple CE configurat ion for an advanced ent erprise m odel m apping
( over a dual- T1 link) int o a t hree- class service- provider m odel.

Ex a m ple 1 5 - 3 . CE Con figu r a t ion for Th r e e - Cla ss Pr ovide r - Edge M ode l

!
class-map match-all ROUTING
match ip dscp cs6
class-map match-all VOICE
match ip dscp ef
class-map match-all INTERACTIVE-VIDEO
match ip dscp af41
class-map match-all MISSION-CRITICAL-DATA
match ip dscp 25
class-map match-any CALL-SIGNALING
match ip dscp af31
match ip dscp cs3
class-map match-all TRANSACTIONAL-DATA
match ip dscp af21
class-map match-all NETWORK-MANAGEMENT
match ip dscp cs2
class-map match-all SCAVENGER
match ip dscp cs1
!
!
policy-map CE-THREE-CLASS-SP-MODEL
 class ROUTING
bandwidth percent 3 ! Routing is assigned (by default) to Critical SP class
class VOICE
priority percent 18 ! Voice is admitted to Realtime SP class
class INTERACTIVE-VIDEO
priority percent 15
set ip dscp cs5 ! Interactive-Video is assigned to the Realtime SP class
class CALL-SIGNALING
priority percent 2 ! Call-Signaling gets LLQ for this scenario
set ip dscp cs5 ! Call-Signaling is assigned to the Realtime SP class
class MISSION-CRITICAL-DATA
bandwidth percent 20
random-detect
set ip dscp af31 ! MC Data is assigned to the Critical SP class
class TRANSACTIONAL-DATA
bandwidth percent 15
random-detect
set ip dscp cs3 ! Transactional Data is assigned to Critical SP class
class NETWORK-MANAGEMENT
bandwidth percent 2
set ip dscp cs3 ! Net Mgmt is assigned to Critical SP class
class SCAVENGER
bandwidth percent 1
class class-default
bandwidth percent 24
random-detect
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

The m a x - r e se r ve d- ba n dw idt h com m and m ight be required on t he int erface t o which t he

previously discussed policy is applied.

Four-Class Provider-Edge Model: CE Design

Building on t he previous m odel, a fourt h class is added t hat can be used for eit her Bulk Dat a or
St ream ing- Video. The adm ission crit erion for t his new class is eit her DSCP AF21 or CS2. The re-
m arking diagram shown in Figure 15- 6 illust rat es how t his new class can be used for St ream ing-
Video and ( prim arily UDP- based) Net work- Managem ent t raffic.

Figu r e 1 5 - 6 . Fou r - Cla ss Pr ovide r - Edge M ode l Re - M a r k in g D ia gr a m

[View full size image]

Exam ple 15- 4 shows an exam ple CE configurat ion for an advanced ent erprise m odel m apping
( over a dual- T1 link) int o a four- class service- provider m odel.

Ex a m ple 1 5 - 4 . CE Con figu r a t ion for Fou r - Cla ss Pr ovide r - Edge M ode l

!
class-map match-all ROUTING
match ip dscp cs6
class-map match-all VOICE
match ip dscp ef
class-map match-all INTERACTIVE-VIDEO
match ip dscp af41
class-map match-all STREAMING-VIDEO
match ip dscp cs4
class-map match-all MISSION-CRITICAL-DATA
match ip dscp 25
class-map match-any CALL-SIGNALING
match ip dscp af31
match ip dscp cs3
class-map match-all TRANSACTIONAL-DATA
match ip dscp af21
class-map match-all NETWORK-MANAGEMENT
match ip dscp cs2
class-map match-all SCAVENGER
match ip dscp cs1
!
!
policy-map CE-FOUR-CLASS-SP-MODEL
class ROUTING
bandwidth percent 3 ! Routing is assigned (by default) to Critical SP class
class VOICE
priority percent 18 ! Voice is admitted to Realtime SP class
class INTERACTIVE-VIDEO
 priority percent 15
set ip dscp cs5 ! Interactive-Video is assigned to the Realtime SP class
class STREAMING-VIDEO
bandwidth percent 13
set ip dscp af21 ! Streaming-Video is assigned to the Video SP class
class CALL-SIGNALING
priority percent 2 ! Call-Signaling gets LLQ for this scenario
set ip dscp cs5 ! Call-Signaling is assigned to the Realtime SP class
class MISSION-CRITICAL-DATA
bandwidth percent 12
random-detect
set ip dscp af31 ! MC Data is assigned to the Critical SP class
class TRANSACTIONAL-DATA
bandwidth percent 10
random-detect
set ip dscp cs3 ! Transactional Data is assigned to Critical SP class
class NETWORK-MANAGEMENT
bandwidth percent 2 ! Net Mgmt (mainly UDP) is admitted to Video SP class
class SCAVENGER
bandwidth percent 1
class class-default
bandwidth percent 24
random-detect
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

The m a x - r e se r ve d- ba n dw idt h com m and m ight be required on t he int erface t o which t he

previously discussed policy is applied.

Five-Class Provider-Edge Model: CE Design

Building again on t he previous m odel, a fift h class is added t hat also can be used for eit her Bulk
Dat a or St ream ing- Video ( whichever wasn't used under t he four- class m odel) . The adm ission
crit erion for t his new class is eit her DSCP AF11 or CS1, which necessit at es t he previously
unrequired re- m arking of t he Scavenger class t o DSCP 0 ( so t hat it will not be adm it t ed int o t he
Bulk Dat a class, but will fall int o t he Best - Effort class) . Figure 15- 7 illust rat es t he re- m arking
required when using t his new class for Bulk Dat a.

Figu r e 1 5 - 7 . Five - Cla ss Pr ovide r - Edge M ode l Re - M a r k in g D ia gr a m

[View full size image]

Exam ple 15- 5 shows an exam ple CE configurat ion for a QoS Baseline ent erprise m odel m apping
( over a dual- T1 link) int o a five- class service- provider m odel.

Ex a m ple 1 5 - 5 . CE Con figu r a t ion for Five - Cla ss Pr ovide r - Edge M ode l

!
class-map match-all ROUTING
match ip dscp cs6
class-map match-all VOICE
match ip dscp ef
class-map match-all INTERACTIVE-VIDEO
match ip dscp af41
class-map match-all STREAMING-VIDEO
match ip dscp cs4
class-map match-all MISSION-CRITICAL-DATA
match ip dscp 25
class-map match-any CALL-SIGNALING
match ip dscp af31
match ip dscp cs3
class-map match-all TRANSACTIONAL-DATA
match ip dscp af21
class-map match-all BULK-DATA
match ip dscp af11
class-map match-all NETWORK-MANAGEMENT
match ip dscp cs2
class-map match-all SCAVENGER
match ip dscp cs1
!
!
policy-map CE-FIVE-CLASS-SP-MODEL
class ROUTING
bandwidth percent 3 ! Routing is assigned (by default) to Critical SP class
 class VOICE
priority percent 18 ! Voice is admitted to Realtime SP class
class INTERACTIVE-VIDEO
priority percent 15
set ip dscp cs5 ! Interactive-Video is assigned to the Realtime SP class
class STREAMING-VIDEO
bandwidth percent 13
set ip dscp af21 ! Streaming-Video is assigned to the Video SP class
class CALL-SIGNALING
priority percent 2 ! Call-Signaling gets LLQ for this scenario
set ip dscp cs5 ! Call-Signaling is assigned to the Realtime SP class
class MISSION-CRITICAL-DATA
bandwidth percent 12
random-detect
set ip dscp af31 ! MC Data is assigned to the Critical SP class
class TRANSACTIONAL-DATA
bandwidth percent 5
random-detect
set ip dscp cs3 ! Transactional Data is assigned to Critical SP class
class NETWORK-MANAGEMENT
bandwidth percent 2 ! Net Mgmt (mainly UDP) is admitted to Video SP class
class BULK-DATA
bandwidth percent 5 ! Bulk Data is assigned to Bulk SP class
random-detect
class SCAVENGER
bandwidth percent 1
set ip dscp 0 ! Scavenger is re-marked to 0
class class-default
bandwidth percent 24
random-detect
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

The m a x - r e se r ve d- ba n dw idt h com m and m ight be required on t he int erface t o which t he

preceding policy is applied.
Provider-Edge QoS Considerations
PE designs are relevant for service providers ( and for ent erprises t hat are self- m anaging t heir
own MPLS VPNs) . Two unique considerat ions for PE QoS design are discussed next :

Service provider- t o- ent erprise m odels

MPLS DiffServ t unneling m odes

These considerat ions are exam ined in m ore det ail in t he following sect ions.

Service Provider-to-Enterprise Models

The PE edges facing cust om er CEs are com plem ent ary t o t he ent erprise- t o- service provider
m apping m odels discussed previously. The PE designs for each class m odel ( t hree, four, and
five) are det ailed in t he following sect ions.

Three-Class Provider-Edge Model: PE Design

As out lined previously ( and illust rat ed in Figure 15- 5 ) , in t his m odel, t he service provider offers
t hree classes of service: Real- Tim e ( st rict priorit y, available in 5- percent increm ent s) , Crit ical
Dat a ( guarant eed bandwidt h) , and Best - Effort . The adm ission crit erion for t he Real- Tim e class is
eit her DSCP EF or CS5; t he adm ission crit erion for Crit ical Dat a is DSCP CS6 ( for cust om er
rout ing t raffic) , AF31, or CS3. All ot her code point s are rem arked t o 0 by an ingress policer ( not
shown in t his configurat ion exam ple, but det ailed lat er under t he MPLS DiffServ t unneling
exam ples) . Addit ionally, service- provider policers can re- m ark out - of- cont ract AF31 t raffic down
t o AF32, which result s in a higher drop preference because DSCP- based WRED is enabled on t his
class. As in previous exam ples, Exam ple 15- 6 is based on an access link of m ore t han 3 Mbps.

Ex a m ple 1 5 - 6 . PE Con figu r a t ion for Th r e e - Cla ss Pr ovide r - Edge M ode l

!
class-map match-any REALTIME
match ip dscp ef
match ip dscp cs5
class-map match-any CRITICAL-DATA
match ip dscp cs6
match ip dscp af31
match ip dscp cs3
!
policy-map PE-THREE-CLASS-SP-MODEL
class REALTIME
priority percent 35 ! Realtime class gets 35% LLQ
class CRITICAL-DATA
bandwidth percent 40 ! Critical-Data SP class gets 40% CBWFQ
random-detect dscp-based ! DSCP-based WRED enabled on class
 class class-default
fair-queue ! Best Effort SP class gets FQ
random-detect ! WRED enabled on Best Effort SP class
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

Four-Class Provider-Edge Model: PE Design

Building on t he previous m odel ( and as illust rat ed in Figure 15- 6 ) , a fourt h class is added t o t his
SP m odel, which can be used for eit her Bulk Dat a or St ream ing- Video. The adm ission crit erion
for t his new class is eit her DSCP AF21 or CS2. Out - of- cont ract AF21 t raffic offered t o t his class
can be m arked down t o AF22. I n t his part icular exam ple, t he class is being called Video, but it is
im port ant t o keep in m ind t hat t he cust om er can offer any t raffic desired t o t his class, provided
t hat it is m arked appropriat ely. For t his reason ( alt hough it norm ally is not required on UDP-
based flows such as St ream ing- Video) , DSCP- based WRED is enabled on t his class t o
aggressively drop out - of- cont ract t raffic as needed. As in previous exam ples, Exam ple 15- 7 is
based on an access link of m ore t han 3 Mbps.

Ex a m ple 1 5 - 7 . PE Con figu r a t ion for Fou r - Cla ss Pr ovide r - Edge M ode l

!
class-map match-any REALTIME
match ip dscp ef
match ip dscp cs5
class-map match-any CRITICAL-DATA
match ip dscp cs6
match ip dscp af31
match ip dscp cs3
class-map match-any VIDEO
match ip dscp af21
match ip dscp cs2
!
policy-map PE-FOUR-CLASS-SP-MODEL
class REALTIME
priority percent 35 ! Realtime SP class gets 35% LLQ
class CRITICAL-DATA
bandwidth percent 25 ! Critical-Data SP class gets 40% CBWFQ
random-detect dscp-based ! DSCP-based WRED enabled on class
class VIDEO
bandwidth percent 15 ! Video SP class gets 15% CBWFQ
random-detect dscp-based ! DSCP-based WRED enabled on "Video" SP class
class class-default
fair-queue ! Best Effort SP class gets FQ
random-detect ! WRED enabled on Best Effort SP class
!
Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

Five-Class Provider-Edge Model: PE Design

Building again on t he previous m odel ( and as illust rat ed in Figure 15- 7 ) , a fift h class is added
t hat can be used for eit her Bulk Dat a or Video ( whichever wasn't used under t he four- class
m odel) . I n t his exam ple, t he new class is used for Bulk Dat a. The adm ission crit erion for t his
new class is eit her DSCP AF11 or CS1. Out - of- cont ract AF11 t raffic offered t o t his class can be
re- m arked t o AF12 and can be discarded earlier by t he DSCP- based WRED algorit hm operat ing
on t he out put queue for t his class.

To prevent long TCP sessions of t he Bulk Dat a SP class from dom inat ing bandwidt h int ended for
t he Best - Effort class, a bandwidt h guarant ee is offered t o t he Best - Effort class. This guarant ee
m ight require t he use of t he m a x - r e se r ve d- ba n dw idt h override under t he applied int erface
configurat ion. As in t he previous exam ples, an access link of m ore t han 3 Mbps is assum ed in
Exam ple 15- 8 .

Ex a m ple 1 5 - 8 . PE Con figu r a t ion for Five - Cla ss Pr ovide r - Edge M ode l

!
class-map match-any REALTIME
match ip dscp ef
match ip dscp cs5
class-map match-any CRITICAL-DATA
match ip dscp cs6
match ip dscp af31
match ip dscp cs3
class-map match-any VIDEO
match ip dscp af21
match ip dscp cs2
class-map match-any BULK-DATA
match ip dscp af11
match ip dscp cs1
!
policy-map PE-FIVE-CLASS-SP-MODEL
class REALTIME
priority percent 35 ! Realtime SP class gets 35% LLQ
class CRITICAL-DATA
bandwidth percent 20 ! Critical-Data SP class gets 40% CBWFQ
random-detect dscp-based ! DSCP-based WRED enabled on class
class VIDEO
bandwidth percent 15 ! Video SP class gets 15% CBWFQ
random-detect dscp-based ! DSCP-based WRED enabled on "Video" SP class
class BULK-DATA
bandwidth percent 5 ! Bulk Data SP class gets 15% CBWFQ
random-detect dscp-based ! DSCP-based WRED enabled on Bulk Data SP class
class class-default
 bandwidth percent 25 ! Best Effort SP class gets 25% CBWFQ
random-detect ! WRED enabled on Best Effort SP class
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

MPLS DiffServ Tunneling Modes

As described in previous exam ples, som e service providers re- m ark packet s at Layer 3 t o
indicat e whet her t raffic is in cont ract or out - of- cont ract . Alt hough t his conform s t o DiffServ
st andards, such as RFC 2597, t his is not always desirable from an ent erprise cust om er's
st andpoint .

Because MPLS labels include 3 bit s t hat com m only are used for QoS m arking, it is possible t o
" t unnel DiffServ" t hat is, preserve Layer 3 DiffServ m arkings t hrough a service provider's MPLS
VPN cloud while st ill perform ing re- m arking ( via MPLS EXP bit s) wit hin t he cloud t o indicat e in-
or out - of- cont ract t raffic.

RFC 3270 defines t hree dist inct m odes of MPLS DiffServ t unneling; each is discussed in det ail in
t he following sect ions:

Uniform Mode

Short Pipe Mode

Pipe Mode

Uniform Mode

Uniform Mode generally is ut ilized when t he cust om er and service provider share t he sam e
DiffServ dom ain, as in t he case of an ent erprise deploying it s own MPLS VPN core.

I n Uniform Mode, which is t he default m ode, t he first 3 bit s of t he I P ToS field ( I P Precedence
bit s) aut om at ically are m apped t o t he MPLS EXP bit s on t he ingress PE as labels are pushed ont o
t he packet s.

I f policers or any ot her m echanism s re- m ark t he MPLS EXP values wit hin t he MPLS core, t hese
m arking changes are propagat ed t o lower- level labels and event ually are propagat ed t o t he I P
ToS field ( MPLS EXP bit s are m apped t o I P Precedence values on t he egress PE) .

Figure 15- 8 shows t he behavior of Uniform Mode MPLS DiffServ t unneling.

Figu r e 1 5 - 8 . M PLS D iffSe r v Un ifor m Tu n n e lin g M ode Ope r a t ion

[View full size image]

The m apping of I P Precedence t o MPLS EXP is perform ed by default on PEs for cust om er- t o-
provider t raffic.

However, for provider- t o- cust om er egress t raffic ( from t he MPLS VPN cloud) , addit ional
configurat ion is required on t he PE t o achieve m apping of MPLS EXP t o I P Precedence. This is
because t he final label is popped ( and discarded) when it is received from t he MPLS VPN cloud
and, t herefore, cannot be used as a m at ch crit erion for policies applied t o t he egress int erface of
t he final PE rout er ( facing t he dest inat ion CE) . The solut ion is t o copy t he final MPLS EXP bit
values t o a t em porary placeholder on PE ingress from t he MPLS core ( before t he label is
discarded) and t hen use t hese t em porary placeholder values for set t ing t he I P Precedence bit s
on egress t o t he cust om er CE.

Cisco I OS provides t wo such t em porary placeholders, t he QoS Group and t he Discard Class. For
Uniform Mode scenarios, it is recom m ended t o copy t he MPLS EXP values t o QoS Group values
on ingress from t he MPLS VPN cloud. ( The Discard Class is recom m ended for use in Pipe Mode
scenarios only.) Then QoS Group values can be copied t o I P Precedence values ( on egress t o t he
cust om er CE) . Figure 15- 9 illust rat es t he policies required for a single direct ion for Uniform Mode
MPLS DiffServ t unneling. ( This policy also would be required on t he com plem ent ary int erfaces for
t he reverse t raffic direct ion.)

Figu r e 1 5 - 9 . M PLS D iffSe r v Un ifor m Tu n n e lin g M ode Policie s

[View full size image]

Exam ple 15- 9 shows t he configurat ion for Uniform Mode operat ion on a PE.

Ex a m ple 1 5 - 9 . PE Con figu r a t ion for M PLS D iffSe r v Un ifor m M ode

Tu n n e lin g

!
policy-map MPLSEXP-TO-QOSGROUP
class class-default
set qos-group mpls experimental topmost ! Copies MPLS EXP to QoS Group
!
policy-map QOSGROUP-TO-IPP
class class-default
set precedence qos-group ! Copies QoS Group to IPP
!
...
!
interface ATM2/0
no ip address
no atm ilmi-keepalive
!
interface ATM2/0.1 point-to-point
description ATM-OC3 TO MPLS VPN CORE ! Link to/from MPLS VPN Core
ip address 20.2.34.4 255.255.255.0
pvc 0/304
vbr-nrt 149760 149760
service-policy input MPLSEXP-TO-QOSGROUP ! MPLS EXP to QoS Group on ingress
!
tag-switching ip
!
...
!
interface FastEthernet1/0
description FE TO CUSTOMER RED CE ! Link to/from CE
ip vrf forwarding RED
ip address 10.1.45.4 255.255.255.0
 service-policy output QOSGROUP-TO-IPP ! QoS Group to IPP on egress to CE
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

Of course, addit ional QoS policies ( t o t hese Uniform Mode t unneling policies) , such as queuing or
WRED, can be applied on t he PE- t o- CE egress link ( as det ailed earlier in t he previous sect ion) .

Short Pipe Mode

Short Pipe Mode is ut ilized when t he cust om er and service provider are in different DiffServ
dom ains. ( The service provider's DiffServ dom ain begins at t he ingress PE's ingress int erface and
t erm inat es on t he egress PE's ingress int erface.)

This m ode is useful when t he service provider want s t o enforce it s own DiffServ policy and t he
cust om er request s t hat it s DiffServ inform at ion be preserved t hrough t he MPLS VPN cloud. Short
Pipe Tunneling Mode provides DiffServ t ransparency t hrough t he service provider net work ( as
does Pipe Mode) .

The out m ost label is ut ilized as t he single m ost m eaningful inform at ion source as it relat es t o t he
service provider's QoS PHB. On MPLS label im posit ion, t he I P classificat ion is not copied int o t he
out erm ost label's EXP. I nst ead, t he value for t he MPLS EXP is set explicit ly on t he ingress PE's
ingress int erface, according t o t he service provider's adm inist rat ive policies.

I n t he case of any re- m arking occurrence wit hin t he service provider's MPLS VPN cloud, changes
are lim it ed t o MPLS EXP re- m arking only and are not propagat ed down t o t he underlying I P
packet 's ToS byt e. Figure 15- 10 shows t he operat ion of Short Pipe Mode MPLS DiffServ
t unneling.

Figu r e 1 5 - 1 0 . M PLS D iffSe r v Sh or t Pipe M ode Tu n n e lin g Ope r a t ion

[View full size image]

MPLS EXP values can be m arked in any way t hat t he provider want s t o provide local significance.
Figure 15- 11 shows an exam ple use of MPLS EXP m arkings t o indicat e in- or out - of- cont ract
t raffic for a five- class service- provider m odel.

Figu r e 1 5 - 1 1 . Five - Cla ss Se r vice Pr ovide r M ode l Sh or t Pipe M ode Re -

M a r k in g D ia gr a m

[View full size image]

Figure 15- 12 shows t he ingress PE ingress int erface re- m arking policies for Short Pipe Mode,
based on t he re- m arking diagram provided in Figure 15- 11 . No m apping from MPLS EXP t o QoS
Group is needed on t he egress PE's ingress int erface ( as was required for Uniform Mode)
because t he MPLS EXP value loses relevance beyond t his int erface.

Figu r e 1 5 - 1 2 . M PLS D iffSe r v Sh or t Pipe M ode Tu n n e lin g Policie s

[View full size image]

Any egress policies on t he egress PE's egress int erface ( facing t he cust om er's dest inat ion CE) ,
are based on I P Precedence or DSCP values ( which have rem ained unt ouched) . This is t he m ain
difference bet ween Short Pipe Mode and Pipe Mode.

Figure 15- 12 shows t he int erfaces in which explicit policy configurat ion is required for Short Pipe
Mode MPLS DiffServ t unneling.

Exam ple 15- 10 shows t he configurat ion for Short Pipe Mode operat ion on a PE. Traffic received
from CEs is m arked explicit ly ( t hrough MPLS EXP values) t o reflect t he service provider's
policies. I n t his exam ple, t he cust om er is given a 3- Mbps CI R t hrough an FE access link. The
provider is using a five- class m odel wit h 35 percent for Real- Tim e t raffic, 20 percent for Crit ical
Dat a t raffic, 15 percent for Video t raffic, 5 percent for Bulk Dat a t raffic, and 25 percent for Best -
Effort t raffic. On PE- t o- CE links ( in t he egress direct ion) , queuing and dropping policies based on
cust om er I P DiffServ m arkings also are recom m ended ( as was discussed previously) .

Ex a m ple 1 5 - 1 0 . PE Con figu r a t ion for M PLS D iffSe r v Sh or t Pipe M ode

Tu n n e lin g

!
class-map match-any REALTIME
match ip dscp ef
match ip dscp cs5
class-map match-any CRITICAL-DATA
match ip dscp cs6
match ip dscp af31
match ip dscp cs3
class-map match-any VIDEO
match ip dscp af21
 match ip dscp cs2
class-map match-any BULK-DATA
match ip dscp af11
match ip dscp cs1
!
!
policy-map PE-FIVE-CLASS-SHORT-PIPE-MARKING
class REALTIME
police cir 1050000
conform-action set-mpls-exp-topmost-transmit 5 ! Conforming RT set to 5
exceed-action drop ! Excess Realtime is dropped
class CRITICAL-DATA
police cir 600000
conform-action set-mpls-exp-topmost-transmit 3 ! Critical Data set to 3
exceed-action set-mpls-exp-topmost-transmit 7 ! Excess Critical set 7
class VIDEO
police cir 450000
conform-action set-mpls-exp-topmost-transmit 2 ! Conforming Video set to 2
exceed-action drop ! Excess Video dropped
class BULK-DATA
police cir 150000
conform-action set-mpls-exp-topmost-transmit 1 ! Conforming Bulk set to 1
exceed-action set-mpls-exp-topmost-transmit 6 ! Excess Bulk set to 6
class class-default
police cir 750000
conform-action set-mpls-exp-topmost-transmit 0 ! Conforming BE set to 0
exceed-action set-mpls-exp-topmost-transmit 4 ! Excess BE set to 4
!
...
!
interface FastEthernet1/0
description FE TO CUSTOMER RED CE ! Link to/from CE
ip vrf forwarding RED
ip address 10.1.12.2 255.255.255.0
service-policy input PE-FIVE-CLASS-SHORT-PIPE-MARKING
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

Pipe Mode

The m ain difference bet ween Short Pipe Mode and Pipe Mode MPLS DiffServ t unneling is t hat t he
PE egress policies ( t oward t he cust om er CEs) are provisioned according t o t he service provider's
explicit m arkings and re- m arkings, not t he ent erprise cust om er's I P DiffServ m arkings ( alt hough
t hese are preserved) . As wit h Short Pipe Mode, any changes t o label m arkings t hat occur wit hin
t he service provider's cloud do not get propagat ed t o t he I P ToS byt e when t he packet leaves t he
MPLS net work.

Because egress PE- t o- CE QoS policies in Pipe Mode are dependent on t he last MPLS EXP value,
t his value m ust be preserved before t he final label is popped. A t em porary placeholder ( as used
in Uniform Mode operat ion) is again required. On t he final PE rout er in a given pat h, t he MPLS
EXP value is copied t o t he QoS Group value. Opt ionally, a Discard Class value also m ight set
drop preference at t he sam e t im e. Thereaft er, egress queuing or dropping policies are perform ed
based on t hese QoS Group/ Discard Class values. Figure 15- 13 illust rat es t he Pipe Mode MPLS
DiffServ t unneling operat ion.

Figu r e 1 5 - 1 3 . M PLS D iffSe r v Pipe M ode Tu n n e lin g Ope r a t ion

[View full size image]

QoS Groups and Discard Classes can be com bined t o provide virt ual DiffServ PHB classificat ion.
For exam ple, RFC 2597 assured- forwarding PHBs can be m im icked using QoS Group values 1
t hrough 4 ( t o represent t he AF class) coupled wit h Discard Class values 1 t hrough 3 ( t o
represent t he drop preference) . I n general, QoS Group and Discard Class values are arbit rary
and have only local significance. However, an except ion is found when WRED is configured t o
select ively drop based on Discard Class values, in which case t he lower Discard Class values are
dropped first ( by default ) . I f no Discard Class value is assigned explicit ly, t he value default s t o 0.

Figure 15- 14 shows t he point s where policies are required for Pipe Mode MPLS DiffServ
t unneling.

Figu r e 1 5 - 1 4 . M PLS D iffSe r v Pipe M ode Tu n n e lin g Policie s

[View full size image]

Figure 15- 15 illust rat es adapt ing t he five- class service provider m odel t o Pipe Mode. The first set
of re- m arkings shows ingress PE re- m arking from DSCP t o MPLS EXP values, depending on
whet her t he t raffic is in cont ract or out - of- cont ract . The second set of m arkings shows how t hese
MPLS EXP values can be m apped t o QoS Groups ( QG) and Discard Classes ( DC) t o provide PHB
classificat ion and provisioning on PE- t o- CE links ( wit hout alt ering t he I P DSCP values of t he
t unneled packet s) .

Figu r e 1 5 - 1 5 . Five - Cla ss Se r vice Pr ovide r M ode l Pipe M ode I n gr e ss

a n d Egr e ss Re - M a r k in g D ia gr a m

[View full size image]

Exam ple 15- 11 shows t he configurat ion for bidirect ional re- m arking on a PE rout er t o support
Pipe Mode operat ion. Traffic received from CEs is m arked explicit ly ( t hrough MPLS EXP values) t o
reflect t he service provider's policies. Then t raffic ( t raversing in t he opposit e direct ion) received
from t he MPLS VPN core is m apped t o QoS Groups and Discard Classes so t hat PE- t o- CE PHB
egress policies can be perform ed against provider re- m arkings. I n t his exam ple, t he cust om er
has cont ract ed for 3- Mbps service over an FE link. Hierarchical policies are used t o achieve
queuing wit hin ( 3 Mbps) shaping over t his ( 100- Mbps) link. Addit ionally, Discard- class WRED is
enabled on t he out put queues so t hat dropping decisions are based on Discard- class values ( not
I P ToS or DSCP values) . Furt herm ore, Discard- class dropping t hresholds are t uned so t hat
Discard- Class 1 ( indicat ing out - of- cont ract t raffic) is dropped m ore aggressively t han Discard-
Class 0 ( m im icking DSCP- based WRED behavior) , which is m ore consist ent wit h RFC 2597
Assured- Forwarding PHBs.

Ex a m ple 1 5 - 1 1 . PE Con figu r a t ion for M PLS D iffSe r v Pipe M ode

Tu n n e lin g

!
class-map match-any REALTIME
match ip dscp ef
match ip dscp cs5
class-map match-any CRITICAL-DATA
match ip dscp cs6
match ip dscp af31
match ip dscp cs3
class-map match-any VIDEO
match ip dscp af21
match ip dscp cs2
class-map match-any BULK-DATA
match ip dscp af11
match ip dscp cs1
!
!
class-map match-all MPLS-EXP-7
match mpls experimental topmost 7 ! Matches MPLS EXP 7
class-map match-all MPLS-EXP-6
match mpls experimental topmost 6 ! Matches MPLS EXP 6
class-map match-all MPLS-EXP-5
match mpls experimental topmost 5 ! Matches MPLS EXP 5
class-map match-all MPLS-EXP-4
match mpls experimental topmost 4 ! Matches MPLS EXP 4
class-map match-all MPLS-EXP-3
match mpls experimental topmost 3 ! Matches MPLS EXP 3
class-map match-all MPLS-EXP-2
match mpls experimental topmost 2 ! Matches MPLS EXP 2
class-map match-all MPLS-EXP-1
match mpls experimental topmost 1 ! Matches MPLS EXP 1
class-map match-all MPLS-EXP-0
match mpls experimental topmost 0 ! Matches MPLS EXP 0
!
!
class-map match-all QOSGROUP5
match qos-group 5 ! Matches QoS Group 5
class-map match-all QOSGROUP3
match qos-group 3 ! Matches QoS Group 3
class-map match-all QOSGROUP2
 match qos-group 2 ! Matches QoS Group 2
class-map match-all QOSGROUP1
match qos-group 1 ! Matches QoS Group 1
class-map match-all QOSGROUP0
match qos-group 0 ! Matches QoS Group 0
!
!
policy-map PIPE-MARKING ! Sets MPLS EXP Values
class REALTIME
police cir 1050000
conform-action set-mpls-exp-topmost-transmit 5 ! Conforming RT set to 5
exceed-action drop ! Excess Realtime is dropped
class CRITICAL-DATA
police cir 600000
conform-action set-mpls-exp-topmost-transmit 3 ! Critical Data set to 3
exceed-action set-mpls-exp-topmost-transmit 7 ! Excess Critical set 7
class VIDEO
police cir 450000
conform-action set-mpls-exp-topmost-transmit 2 ! Conforming Video set to 2
exceed-action drop ! Excess Video dropped
class BULK-DATA
police cir 150000
conform-action set-mpls-exp-topmost-transmit 1 ! Conforming Bulk set to 1
exceed-action set-mpls-exp-topmost-transmit 6 ! Excess Bulk set to 6
class class-default
police cir 750000
conform-action set-mpls-exp-topmost-transmit 0 ! Conforming BE set to 0
exceed-action set-mpls-exp-topmost-transmit 4 ! Excess BE set to 4
!
!
policy-map MPLSEXP-QOSGROUP-DISCARDCLASS ! Maps MPLS EXP to QG/DC values
class MPLS-EXP-5
set qos-group 5 ! Conforming Realtime is set to QG 5
class MPLS-EXP-3
set qos-group 3 ! Conforming Critical Data is set to QG 3
class MPLS-EXP-7
set qos-group 3 ! Excess Critical Data is set to QG3
set discard-class 1 ! Excess Critical Data has DC set to 1
class MPLS-EXP-2
set qos-group 2 ! Conforming Video is set to QG 2
class MPLS-EXP-1
set qos-group 1 ! Conforming Bulk is set to QG 1
class MPLS-EXP-6
set qos-group 1 ! Excess Bulk is set to QG 1
set discard-class 1 ! Excess Bulk has DC set to 1
class MPLS-EXP-0
set qos-group 0 ! Conforming Best Effort is set to QG 0
class MPLS-EXP-4
set qos-group 0 ! Excess Best Effort is set to QG 0
set discard-class 1 ! Excess Best Effort has DC set to 1
!
!
policy-map PE-CE-QUEUING ! Queuing policy for PE to CE link
class QOSGROUP5
priority percent 35 ! Voice class gets 35% LLQ
class QOSGROUP3
 bandwidth percent 20 ! Critical Data class gets 20% CBWFQ
random-detect discard-class-based ! DC-Based WRED is enabled
random-detect discard-class 0 30 40 10 ! DC 0 is tuned for WRED
random-detect discard-class 1 20 40 10 ! DC 1 is tuned for WRED
class QOSGROUP2
bandwidth percent 15 ! Video class gets 15% CBWFQ
class QOSGROUP1
bandwidth percent 5 ! Bulk class gets 5% CBWFQ
random-detect discard-class-based ! DC-Based WRED is enabled
random-detect discard-class 0 30 40 10 ! DC 0 is tuned for WRED
random-detect discard-class 1 20 40 10 ! DC 1 is tuned for WRED
class QOSGROUP0
bandwidth percent 25 ! Best Effort class gets 25% CBWFQ
random-detect discard-class-based ! DC-Based WRED is enabled
random-detect discard-class 0 30 40 10 ! DC 0 is tuned for WRED
random-detect discard-class 1 20 40 10 ! DC 1 is tuned for WRED
!
!
policy-map PE-CE-SHAPING-QUEUING ! Customer has 3 Mbps CIR over FE
class class-default
shape average 3000000 ! Shaping policy for 3 Mbps CIR
service-policy PE-CE-QUEUING ! Nested queuing policy
!
interface ATM2/0
no ip address
no atm ilmi-keepalive
!
interface ATM2/0.1 point-to-point
description ATM-OC3 TO MPLS VPN CORE ! Link to/from MPLS VPN Core
ip address 20.2.34.4 255.255.255.0
pvc 0/304
vbr-nrt 149760 149760
service-policy input MPLSEXP-QOSGROUP-DISCARDCLASS ! MPLS EXP to QG/DC
!
tag-switching ip
!
!
interface FastEthernet1/0
description FE TO CUSTOMER RED CE ! Link to/from CE
ip vrf forwarding RED
ip address 10.1.12.2 255.255.255.0
service-policy input PIPE-MARKING ! Pipe marking policy
service-policy output PE-CE-SHAPING-QUEUING ! Shaping/Queuing policy
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

Pipe Mode with an Explicit Null LSP

When CEs are provider m anaged, som e providers prefer t o offload t he ingress MPLS EXP
m arking of cust om er t raffic from t he PE and push t hese policies out t o t he ingress int erface of
t he CE. However, because t he CE- t o- PE link is regular I P ( not MPLS) , a difficult y arises as t o how
t o set t he provider's m arking wit hout affect ing t he I P DiffServ m arkings t hat t he cust om er has
set ( because, again, t hese are t o be preserved and unt ouched t hrough t he MPLS VPN cloud in
Pipe Mode operat ion) . Therefore, a solut ion t o t his scenario was int roduced in Cisco I OS Release
12.2( 13) T, wit h t he Pipe Mode MPLS DiffServ t unneling wit h an Explicit Null LSP feat ure.

This feat ure prepends an Explicit Null LSP label for cust om er t raffic headed from t he CE t o t he
PE. This label is not used for MPLS swit ching; it is used only t o preserve t he provider's MPLS EXP
m arkings over t he CE- t o- PE link. On t he PE, t he MPLS EXP values are copied t o regular MPLS
labels t hat are pushed ont o t he packet ( which are used for MPLS swit ching) , and t he explicit null
label is discarded.

Thus, t he ingress m arking policies from t he PE are pushed t o t he m anaged CE. This expands t he
provider's DiffServ dom ain t o include t he ( m anaged) CEs. All ot her aspect s of Pipe Mode
operat ion and configurat ion, however, rem ain t he sam e.

Figu r e 1 5 - 1 6 . M PLS D iffSe r v Pipe M ode w it h a n Ex plicit N u ll LSP

Tu n n e lin g Ope r a t ion

[View full size image]

Figure 15- 17 shows t he point s where policies are required for Pipe Mode wit h Explicit Null LSP
MPLS DiffServ t unneling.

Figu r e 1 5 - 1 7 . M PLS D iffSe r v Pipe M ode w it h a n Ex plicit N u ll LSP

Tu n n e lin g Policie s

[View full size image]

As not ed, PE configurat ions rem ain t he sam e as wit h norm al Pipe Mode, wit h t he except ion t hat
ingress MPLS EXP m arking policies have been rem oved. These policies now are set on t he
m anaged CE, as shown in Exam ple 15- 12 . As wit h Exam ple 15- 13 , t he provider has cont ract ed
for a CI R of 3 Mbps in a five- class m odel. All ingress t raffic is policed on t he cust om er edge of
t he CE and is m arked ( t hrough MPLS EXP values) t o indicat e whet her it is in cont ract or out - of-
cont ract . Then an Explicit Null LSP is pushed ont o t he packet t o carry t hese MPLS EXP m arkings
from t he CE t o t he PE. Opt ionally, queuing policies can be added on t he CE- t o- PE link, but for
sim plicit y, t hese have been om it t ed from t his exam ple because t hey already have been covered.

Ex a m ple 1 5 - 1 2 . M a n a ge d CE Con figu r a t ion for M PLS D iffSe r v Pipe

M ode w it h a n Ex plicit N u ll LSP Tu n n e lin g

!
class-map match-any REALTIME
match ip dscp ef
match ip dscp cs5
class-map match-any CRITICAL-DATA
match ip dscp cs6
match ip dscp af31
match ip dscp cs3
class-map match-any VIDEO
match ip dscp af21
match ip dscp cs2
class-map match-any BULK-DATA
match ip dscp af11
match ip dscp cs1
!
!
policy-map PIPE-EXPLICIT-NULL-MARKING
class REALTIME
police cir 1050000
conform-action set-mpls-exp-topmost-transmit 5 ! Conforming RT set to 5
exceed-action drop ! Excess Realtime is dropped
class CRITICAL-DATA
 police cir 600000
conform-action set-mpls-exp-topmost-transmit 3 ! Critical Data set to 3
exceed-action set-mpls-exp-topmost-transmit 7 ! Excess Critical set 7
class VIDEO
police cir 450000
conform-action set-mpls-exp-topmost-transmit 2 ! Conforming Video set to 2
exceed-action drop ! Excess Video dropped
class BULK-DATA
police cir 150000
conform-action set-mpls-exp-topmost-transmit 1 ! Conforming Bulk set to 1
exceed-action set-mpls-exp-topmost-transmit 6 ! Excess Bulk set to 6
class class-default
police cir 750000
conform-action set-mpls-exp-topmost-transmit 0 ! Conforming BE set to 0
exceed-action set-mpls-exp-topmost-transmit 4 ! Excess BE set to 4
!
...
!
interface FastEthernet0/0
description FE to Customer Network ! Link to/from customer
ip address 10.1.1.1 255.255.255.0
service-policy input PIPE-EXPLICIT-NULL-MARKING ! MPLS EXP set on ingress
!
!
interface FastEthernet0/1
description FE TO PE ! Link to/from PE
ip address 10.1.12.1 255.255.255.0
duplex auto
speed auto
mpls ip encapsulate explicit-null ! Explicit Null LSP is added
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce
Core QoS Considerations
Several opt ions exist t o m eet st rict SLA considerat ions for loss, delay, and j it t er in t he service-
provider MPLS VPN core:

Aggregat e bandwidt h overprovisioning

DiffServ in t he backbone

MPLS t raffic engineering ( which m ight or m ight not be used in conj unct ion wit h DiffServ in
t he backbone)

Aggregate Bandwidth Overprovisioning

Aggregat e bandwidt h overprovisioning is a com m on t rend in t he service- provider backbone
because of it s sim plicit y and ease of design, deploym ent , and operat ion. Alt hough DiffServ
dom ain charact erist ics are assum ed at t he provider edges for t raffic aggregat ion, st udies have
shown t hat designing t he service provider backbone for low delay, j it t er, or loss can be a m at t er
of sim ply overprovisioning t he net work by approxim at ely t wo t im es t he m axim um of t he
aggregat e t raffic load.

Caveat s t o overprovisioning include capacit y planning failures, net work failure sit uat ions, and
unexpect ed t raffic dem ands or pat t erns. For inst ance, because t his st rat egy does not
different iat e bet ween Real- Tim e t raffic and Best - Effort t raffic, real- t im e service levels can be
degraded if net work failure or congest ion occurs. Furt herm ore, t his approach is relat ively
expensive and inefficient , com pared t o alt ernat ive opt ions such as Core DiffServ and MPLS TE.

DiffServ in the Backbone

Deploying a sim plified DiffServ policy in t he backbone allows t he service provider t o support
m ult iple classes of t raffic wit h different overprovisioning and underprovisioning rat ios on a per-
class basis.

DiffServ in t he backbone allows for m ore aggregat e t raffic t o be support ed for t he sam e
provisioned net work bandwidt h, as com pared t o t he non- DiffServ backbone. Also, Real- Tim e
t raffic can be serviced preferent ially, even if failure or congest ion occurs.

The m ain caveat t o t his solut ion is t hat it adds com plexit y t o t he core net work design and
oper at ions.

I n a DiffServ backbone, it m ight not be necessary t o assum e t he sam e num ber of classes t hat
exist at t he edge in t he PE- t o- CE link, as long as provision is m ade for a Real- Tim e t raffic class
( which is associat ed t o a PQ) and Crit ical Dat a is prot ect ed over Best - Effort t raffic.

Three-Class Provider-Core Model: PE-to-P or P-to-P Design

I t is not necessary t o ensure t hat t he backbone support s t he sam e num ber of DiffServ classes as
t he edge, assum ing t hat proper design principles are in place t o support t he given SLAs.

Figure 15- 18 gives an exam ple of how a five- class provider- edge m odel can be collapsed int o a
t hree- class provider- core m odel.

Figu r e 1 5 - 1 8 . Five - Cla ss Pr ovide r - Edge M ode l Sh or t Pipe / Pipe M ode

M a ppin g t o Th r e e - Cla ss Pr ovide r - Cor e M ode l Ex a m ple

[View full size image]

Det ailed definit ions of t he core classes used in t his figure follow:

Cor e Re a l- Tim e This class t arget s applicat ions such as Voice and I nt eract ive- Video, which
require low loss ( less t han 0.25 percent ) , low delay, and low j it t er ( t ypically 5 m s wit hin t he
backbone) , and have a defined availabilit y. This class also support s per- flow sequence
preservat ion. This class always should be engineered for t he worst - case delay, t o support
Real- Tim e t raffic. Excess t raffic in t his class t ypically is dropped. This class should be
associat ed wit h MPLS EXP 5 wit h a PQ, t o ensure t hat t he delay and j it t er cont ract s are
m et . Bet ween 25 and 35 percent of link capacit y should be allocat ed t o t he PQ. WRED
t ypically is not required on t his queue.

Cor e Cr it ica l D a t a This class represent s business- crit ical int eract ive applicat ions. Round-
t rip t im e ( RTT) should be less t han 250 m s ( t he t hreshold for hum an delay percept ion) ,
and loss should be less t han 0.5 percent . Throughput is derived from loss and RTT. Jit t er is
not im port ant for t his service class and is not defined. Excess t raffic wit hin t his class
t ypically is re- m arked wit h an out - of- cont ract ident ifier ( re- m arking of eit her DSCP or MPLS
EXP values) and t ransm it t ed. This class also support s per- flow sequence preservat ion. This
class should be associat ed wit h an AF class- based queue or MPLS EXP- based queue
( depending on t he MPLS DiffServ t unneling m ode in use) . WRED could be configured here
t o opt im ize TCP t hroughput and t o accom m odat e a drop policy for out - of- profile t raffic.

Cor e Be st - Effor t This class represent s all ot her cust om er t raffic t hat has not been
classified as Real- Tim e or Crit ical Dat a. I t is defined in t erm s of a loss rat e wit h availabilit y;
 t hroughput is derived from loss. Delay and j it t er are not im port ant for t his service and are
not defined.

Exam ple 15- 13 shows t he configurat ion of a t hree- class provider- core m odel. I f DiffServ is
im plem ent ed wit hin t he core, t he policies should be kept as sim ple as possible, t o reduce t he
CPU ut ilizat ion for QoS t o an absolut e m inim um .

Ex a m ple 1 5 - 1 3 . Th r e e - Cla ss Pr ovide r Cor e M ode l Ex a m ple

!
class-map match-all CORE-REALTIME
match mpls experimental topmost 5 ! Identifies in-contract Realtime
class-map match-all CORE-CRITICAL-DATA
match mpls experimental topmost 3 ! Identifies in-contract Critical-Data
match mpls experimental topmost 7 ! Identifies out-of-contract Critical Data
match mpls experimental topmost 2 ! Identifies in-contract Video
match mpls experimental topmost 1 ! Identifies in-contract Bulk
match mpls experimental topmost 6 ! Identifies out-of-contract Bulk
!
!
policy-map CORE-THREE-CLASS-SP-MODEL
class CORE-REALTIME
priority percent 35 ! CORE-REALTIME gets 35% LLQ
class CORE-CRITICAL-DATA
bandwidth percent 55 ! CORE-CRITICAL gets 55% CBWFQ
class class-default
fair-queue ! CORE-BEST-EFFORT gets FQ
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

The m a x - r e se r ve d- ba n dw idt h com m and m ight be required on t he int erface t o which t he

policy is applied.

Platform-Specific ConsiderationsCisco 12000 GSR MDRR Example

Because of t he highly specialized role of core rout ers, not all previously discussed QoS feat ures
are support ed by each plat form / line card com binat ion. I t is beyond t he scope of t his chapt er t o
enum erat e all plat form / line card caveat s; however, an exam ple of t he Cisco 12000 GSR can
illust rat e t he point .

The Cisco 12000 series rout er plat form s support queuing t hrough a m odified- deficit round- robin
( MDRR) algorit hm . MDRR works in m uch t he sam e m anner as CBWFQ and allows for up t o eight
queues t o be provisioned; non- em pt y queues are serviced in a round- robin fashion, depending
on t he bandwidt h assigned t o t hem .

Wit hin t hese eight queues, MDRR m aint ains a priorit y queue, which can be serviced in st rict
priorit y or alt ernat e priorit y.
Wit h MDRR st rict priorit y, t he priorit y queue always is serviced exhaust ively, as long as t here are
packet s in t his queue. An im port ant dist inct ion bet ween MDRR priorit y queuing and LLQ is t hat
MDRR priorit y queuing does not have an im plicit policer. However, t he MQC synt ax does support
configuring MDRR st rict priorit y in conj unct ion wit h class- based policing t o enforce a lim it on t he
am ount of t raffic t hat can be given st rict priorit y.

To prevent st arvat ion scenarios t hat could exist wit h t he lack of a policer, an alt ernat ive t o MDRR
st rict - priorit y servicing exist s in t he opt ion of MDRR alt ernat e- priorit y queuing. When alt ernat e-
priorit y queuing is configured, t he priorit y queue is serviced alt ernat ely wit h all ot her queues.
For exam ple, one priorit y packet is serviced, followed by a packet from any one of t he ot her
queues ( depending on how t hey are configured) . Then anot her priorit y packet is serviced and
again is followed by a nonpriorit y packet . I n t his m anner, priorit y servicing does not st arve ot her
t raffic as st rict - priorit y queuing could.

MDRR can be applied t o an inbound int erface or an out bound int erface.

Exam ple 15- 14 shows how t o adapt t he previous t hree- class provider- core policy t o a Cisco
12000 GSR rout er. I n t his exam ple, t he LLQ is policed t o approxim at ely 35 percent of t he
Packet - over- SONET ( POS) line rat e of OC3 ( 155 Mbps) . Because t he Cisco 12000 GSR does not
support WFQ, no explicit configurat ion is required for t he Best - Effort class.

Ex a m ple 1 5 - 1 4 . Th r e e - Cla ss Pr ovide r Cor e M ode l Ada pt e d for a Cisco

1 2 0 0 0 GSR w it h Lin e Ca r d 3 Ex a m ple

!
class-map match-all CORE-REALTIME
match mpls experimental 5
class-map match-all CORE-CRITICAL-DATA
match mpls experimental 3
match mpls experimental 7
match mpls experimental 2
match mpls experimental 1
match mpls experimental 6
!
!
policy-map CORE-THREE-CLASS-SP-MODEL-GSR
class CORE-REALTIME
police cir 54248000 bc 4470 be 4470 ! Voice is explicitly policed to 33%
conform-action transmit
exceed-action drop
priority ! Voice is assigned strict-priority MDRR
class CORE-CRITICAL-DATA
bandwidth percent 40
!
! WFQ is not supported so no default-class polices are required
!
interface POS0/0
ip address 10.131.160.233 255.255.255.252
no ip directed-broadcast
tag-switching ip
crc 16
service-policy output CORE-THREE-CLASS-SP-MODEL-GSR
!
 N ot e
The im plem ent at ion of t he priorit y com m and on t he Cisco 12000 series differs from t he
im plem ent at ion on ot her rout ers running Cisco I OS Soft ware. On t his plat form , t he
priorit y t raffic is not lim it ed t o t he configured kbps value during periods of congest ion.
Thus, you also m ust configure t he police com m and t o lim it how m uch bandwidt h a
priorit y class can use and t o ensure adequat e bandwidt h for ot her classes. At t his t im e,
t he police com m and is support ed on only Engine 3 line cards. On t he ot her engine line
cards, only class- default is allowed when you configure a priorit y class.

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

MPLS Traffic Engineering

Traffic engineering enables service providers t o rout e net work t raffic efficient ly t o offer t he
opt im al service levels, in t erm s of t hroughput and delay. Such effect ive use of net work resources
allows providers t o offer m ore granular services and, at t he sam e t im e, reduce t he cost of t heir
net work.

Current ly, m any service providers base t heir services on an overlay m odel. I n t he overlay m odel,
t ransm ission facilit ies are m anaged by Layer 2 swit ching. The rout ers see only a fully m eshed
virt ual t opology, m aking m ost dest inat ions appear one hop away. MPLS t raffic engineering
( MPLS TE) provides a way t o achieve t he sam e t raffic- engineering benefit s of t he overlay m odel
wit hout needing t o run a separat e net work and wit hout needing a nonscalable, full m esh of
rout er int erconnect s. Furt herm ore, MPLS TE enables adm inist rat ors t o use com plex m et rics in
det erm ining t he opt im al pat h of a given flow.

MPLS t raffic engineering does t he following:

Replaces t he need t o m anually configure t he net work devices t o set up explicit rout es.
I nst ead, you can rely on t he MPLS t raffic engineering funct ionalit y t o underst and t he
backbone t opology and t he aut om at ed signaling process.

Account s for link bandwidt h and for t he size of t he t raffic flow when det erm ining explicit
rout es across t he backbone.

Has a dynam ic adapt at ion m echanism t hat enables t he backbone t o be resilient t o failures,
even if several prim ary pat hs are precalculat ed offline.

MPLS TE aut om at ically est ablishes and m aint ains a t unnel across t he backbone, using RSVP. The
pat h used by a given t unnel at any point in t im e is det erm ined based on t he t unnel resource
requirem ent s and net work resources, such as bandwidt h.

Available resources are flooded t hrough ext ensions t o a link st at ebased I nt erior Gat eway
Prot ocol ( I GP) , such as OSPF or I S- I S.
Tunnel pat hs are calculat ed at t he t unnel head based on a fit bet ween required and available
resources ( const raint - based rout ing) . The I GP aut om at ically rout es t he t raffic int o t hese t unnels.
Typically, a packet crossing t he MPLS TE backbone t ravels on a single t unnel t hat connect s t he
ingress point t o t he egress point .

MPLS TE is built on t he following Cisco I OS m echanism s:

Label- swit ched pat h ( LSP) t unnels, which are signaled t hrough RSVP, wit h t raffic
engineering ext ensions. LSP t unnels are represent ed as t unnel int erfaces, have a
configured dest inat ion, and are unidirect ional.

A link- st at e I GP ( such as OSPF or I S- I S) wit h ext ensions for t he global flooding of resource
inform at ion, and ext ensions for t he aut om at ic rout ing of t raffic ont o LSP t unnels, as
appropriat e.

An MPLS TE pat h- calculat ion m odule t hat det erm ines pat hs t o use for LSP t unnels.

An MPLS TE link- m anagem ent m odule t hat does link adm ission and bookkeeping of t he
resource inform at ion t o be flooded.

One approach t o engineer a backbone is t o define a m esh of t unnels from every ingress device
t o every egress device. The I GP, operat ing at an ingress device, det erm ines which t raffic should
go t o which egress device, and st eers t hat t raffic int o t he t unnel from ingress t o egress. The
MPLS t raffic- engineering pat h- calculat ion and signaling m odules det erm ine t he pat h t aken by t he
LSP t unnel, subj ect t o resource availabilit y and t he dynam ic st at e of t he net work. For each
t unnel, count s of packet s and byt es sent are kept .

Som et im es a flow is so large t hat it cannot fit over a single link, so it cannot be carried by a
single t unnel. I n t his case, m ult iple t unnels bet ween a given ingress and egress can be
configured, and t he flow is load- shared am ong t hem .

Basic MPLS TE

Basic MPLS TE configurat ion requires you t o do t he following:

Enable I P CEF globally:

Router(config)#ip cef

Enable MPLS TE globally:

Router(config)#mpls traffic-eng tunnels

Enable MPLS TE on every int erface t hat m ight be part of a t unnel, and configure t he am ount of
bandwidt h t hat can be reserved ( t hrough RSVP) for all t unnels t raversing t he link:

Router(config)#interface POS5/0
Router(config-if)#mpls traffic-eng tunnels
Router(config-if)#ip rsvp bandwidth 77500 77500
Define a loopback int erface t o be used as an MPLS TE Rout er I D ( RI D) :

Router(config)#interface loopback 0
Router(config-if)#ip address 20.1.1.1 255.255.255.255

Configure a link- st at e I nt erior Gat eway Prot ocol ( I GP) for MPLS TE, eit her OSPF or I S- I S:

OSPF

Router(config)#router ospf 100

Router(config-router)# mpls traffic-eng router-id loopback 0
Router(config-router)# mpls traffic-eng area 0

I S- I S

Router(config)#router isis
Router(config-router)#net 49.0000.0000.0000.0010.00
Router(config-router)#metric-style wide
Router(config-router)#mpls traffic-eng level-1
Router(config-router)#mpls traffic-eng router-id loopback 0

Define a t unnel int erface configured wit h MPLS TE, wit h an am ount of bandwidt h t hat can be
reserved ( t hrough RSVP) for t he t unnel:

Router(config)#interface Tunnel0
Router(config-if)# description BLUE-TUNNEL (PE1=>PE2)
Router(config-if)# ip unnumbered loopback 0
Router(config-if)# tunnel destination 20.2.2.2
Router(config-if)# tunnel mode mpls traffic-eng
Router(config-if)# tunnel mpls traffic-eng bandwidth 77500

Set a priorit y for t he t unnel int erface ( lower is preferred) :

Router(config-if)# tunnel mpls traffic-eng priority 7 7

Select a pat h opt ion for t he t unneldynam ic, explicit , or a com binat ion:

D yn a m ic pa t h opt ion The soft ware calculat es t he best pat h t o t he dest inat ion, based on t unnel
const raint s.

Router(config-if)#tunnel mpls traffic-eng path-option 10 dynamic

Ex plicit pa t h opt ion Each hop is defined st at ically.

Router(config-if)# tunnel mpls traffic-eng path-option 1 explicit name BLUE-TUNNEL

Router(config-if)#exit
Router(config)#ip explicit-path name BLUE-TUNNEL enable
Router(cfg-ip-expl-path)# next-address 20.1.12.2
Explicit Path name BLUE-TUNNEL:
1: next-address 20.1.12.2
Router(cfg-ip-expl-path)#

Com bin a t ion pa t h opt ion s When t he first opt ion cannot be m et , t he algorit hm at t em pt s t he
second, and so on.

Router(config-if)# tunnel mpls traffic-eng path-option 1 explicit name BLUE-

TUNNEL
Router(config-if)# tunnel mpls traffic-eng path-option 2 dynamic
Router(config-if)#exit
Router(config)#ip explicit-path name BLUE-TUNNEL enable
Router(cfg-ip-expl-path)# next-address 20.1.12.2
Explicit Path name BLUE-TUNNEL:
1: next-address 20.1.12.2
Router(cfg-ip-expl-path)#

Select a forwarding opt ion t o direct t raffic down t he t unnelst at ic rout es, policy rout ing, or
Aut oRout e:

St at ic rout es

Router(config)#ip route 16.16.16.16 255.255.255.255 Tunnel0

Policy- based rout ing

Router(config)#interface FastEthernet 1/0

Router(config-if)#ip policy route-map TUNNEL-ASSIGNMENT
Router(config-if)#exit
Router(config)#route-map TUNNEL-ASSIGNMENT
Router(config-route-map)#match ip address 100
Router(config-route-map)#set interface Tunnel 0
Router(config-route-map)#exit
Router(config)#access-list 100 permit ip any 10.2.2.0 0.0.0.255

Aut oRout e ( enabled on t he t unnel headend)

Router(config)#interface Tunnel0
 Router(config-if)#tunnel mpls traffic-eng autoroute announce

N ot e
As st at ed at t he opening of t he chapt er, it is sim ply beyond t he scope of t his book t o
go int o det ail on MPLS t raffic engineering. Many MPLS TE feat ures, such as at t ribut e
flags, affinit y, adm inist rat ive weight s, flooding t hresholds, and Fast Rerout e, have been
om it t ed from t his overview. For a com prehensive t echnical discussion on t hese and
ot her MPLS TE feat ures and operat ion, refer t o t he Cisco Press book Traffic Engineering
wit h MPLS , by Eric Osborne and Aj ay Sim ha.

Two exam ples of QoS- relat ed MPLS TE scenarios are present ed in t his chapt er. The first is t he
use of MPLS per- VPN t raffic engineering; t he second is t he use of MPLS DiffServ t raffic
engineering ( MPLS DS- TE) .

MPLS Per-VPN TE

MPLS VPNs provide t he rout e isolat ion necessary for dat a privacy and support of privat e I P
address allocat ion overlapping, while RSVP- signaled MPLS- TE provides opt im al pat h select ion,
per- VPN SLAs, and pat h resiliency.

The not ion of int egrat ing t hese t wo MPLS applicat ions is pret t y st raight forward. Where it get s
int erest ing is in t he act ual binding process of an MPLS VPN t o t he TE t unnel. Today t his can be
achieved by t aking advant age of next - hop rout e recursion at t he PE; however, t his is a less t han
elegant int erim solut ion. Cisco I OS innovat ions in policy- based rout ing ( PBR) and QoS- based
rout ing ( QBR) will allow for a m ore scalable way t o int egrat e MPLS VPN and TE in t he near
fut ure.

I n t his sim plified exam ple scenario, t he service provider has Packet over SONET ( POS) links from
each PE t o t he core, and also direct PE- t o- PE POS links for geographically adj acent PEs.
Furt herm ore, t he service provider has t wo cust om ers, Blue and Red. Cust om er Blue has
cont ract ed wit h t he provider for a prem ium service so t hat Blue t raffic t hat is dest ined for
geographically adj acent CEs is t unneled over t he direct PE- t o- PE links. However, Red t raffic
always is swit ched t hrough t he MPLS core, even when t here is a short er pat h t o t he dest inat ion
CEs t hrough t he direct PE- t o- PE links. Figure 15- 19 illust rat es t he desired operat ion of t his
scenario. Because MPLS TE is unidirect ional, separat e t unnels would be required for t he sam e
behavior in t he ret urn direct ion.

Figu r e 1 5 - 1 9 . M PLS Pe r - VPN TE Ope r a t ion Ex a m ple

[View full size image]

Figure 15- 20 zoom s in on t he relevant subsect ion of t he previous diagram and provides specific
addressing det ail for t his exam ple.

Figu r e 1 5 - 2 0 . M PLS Pe r - VPN TE Ex a m ple D e t a ils

[View full size image]

The configurat ion for t his exam ple of MPLS per- VPN TE spans t hree rout ers: PE1 configurat ion
( see Exam ple 15- 15 ) , PE2 configurat ion ( see Exam ple 15- 16 ) , and t he P- rout er configurat ion
( see Exam ple 15- 17 ) .

To achieve t he desired behavior of forcing Cust om er Blue's t raffic down t he short er MPLS t unnel
and forcing Cust om er Red's t raffic down t he longer t unnel, a com binat ion of st at ic and BGP
policy- based rout ing is used ( relying on recursive rout ing on each PE) .

When Cust om er Blue's geographically adj acent CE net works are received at t he PE, BGP direct s
t hese prefixes t o be processed by t he TUNNEL- ASSI GNMENT rout e m ap. This rout e m ap m at ches
Blue's prefixes against access- list 1 and set s t he BGP next - hop at t ribut e t o t he fict it ious rout e of
16.16.16.16. Sim ilarly, Cust om er Red's prefixes are m at ched against access- list 2 and have t heir
BGP next - hop at t ribut e set t o t he fict it ious rout e of 17.17.17.17. Then each of t hese fict it ious
rout es is resolved t hrough st at ic- rout ing st at em ent s t hat direct t he flow t o t he desired MPLS
t unnel int erface. This is det ailed in Exam ple 15- 15 .

Ex a m ple 1 5 - 1 5 . PE1 M PLS Pe r - VPN TE Ex a m ple Con figu r a t ion

!
hostname PE1
!
!
ip vrf BLUE ! BLUE MPLS VPN definition
rd 100:1
route-target export 100:1
route-target import 100:1
!
ip vrf RED ! RED MPLS VPN definition
rd 150:1
route-target export 150:1
route-target import 150:1
!
ip cef ! IP CEF is required for MPLS and MPLS TE
mpls ldp logging neighbor-changes
mpls traffic-eng tunnels ! MPLS TE is enabled globally
!
!
interface Loopback0 ! Loopback interface for MPLS TE RID
ip address 20.1.1.1 255.255.255.255
!
interface Tunnel0
description BLUE-TUNNEL (PE1=>PE2)
ip unnumbered Loopback0
tunnel destination 20.2.2.2
tunnel mode mpls traffic-eng ! MPLS TE is enabled on Tunnel int
tunnel mpls traffic-eng priority 7 7 ! Lower value is preferred
tunnel mpls traffic-eng bandwidth 77500 ! 77.5 Mbps can be reserved
tunnel mpls traffic-eng path-option 1 explicit name BLUE-TUNNEL ! BLUE Path
!
interface Tunnel1
description RED-TUNNEL (PE1=>P=>PE2)
ip unnumbered Loopback0
tunnel destination 20.2.2.2
tunnel mode mpls traffic-eng ! MPLS TE is enabled on Tunnel int
tunnel mpls traffic-eng priority 7 7 ! Lower value is preferred
tunnel mpls traffic-eng bandwidth 77500 ! 77.5 Mbps can be reserved via RSVP
tunnel mpls traffic-eng path-option 1 explicit name RED-TUNNEL ! RED Path
!
!
interface FastEthernet1/0
description FE to Customer Blue CE1
ip vrf forwarding BLUE ! Interface to Blue CE1
ip address 10.20.1.2 255.255.255.252
!
interface FastEthernet1/1
description FE to Customer Red CE1
ip vrf forwarding RED ! Interface to Blue CE1
ip address 15.20.1.2 255.255.255.252
!
interface POS5/0
ip address 20.1.12.1 255.255.255.252
description PE1=>PE2 POS Link
mpls traffic-eng tunnels ! MPLS TE enabled on int
tag-switching ip ! MPLS enabled on int
ip rsvp bandwidth 77500 77500 ! RSVP enabled on int for 77.5 Mbps
!
interface POS6/0
description PE1=>P-Router (Core) POS Link
ip address 20.1.13.1 255.255.255.252
mpls traffic-eng tunnels ! MPLS TE enabled on int
tag-switching ip ! MPLS enabled on int
ip rsvp bandwidth 77500 77500 ! RSVP enabled on int for 77.5 Mbps
!
router ospf 100
mpls traffic-eng router-id Loopback0 ! MPLS TE RID
mpls traffic-eng area 0 ! Enables OSPF area 0 for MPLS TE
log-adjacency-changes
redistribute connected subnets
network 20.1.12.0 0.0.0.3 area 0
network 20.1.13.0 0.0.0.3 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
redistribute connected
neighbor 20.2.2.2 remote-as 100
neighbor 20.2.2.2 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 20.2.2.2 activate ! MPLS VPN neighbor (PE2)
neighbor 20.2.2.2 send-community extended
neighbor 20.2.2.2 route-map TUNNEL-ASSIGNMENT in ! Applies BGP PBR
exit-address-family
!
address-family ipv4 vrf BLUE
redistribute connected
neighbor 10.20.1.1 remote-as 10 ! EBGP peer with Customer Blue CE1
neighbor 10.20.1.1 activate
neighbor 10.20.1.1 default-originate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
neighbor 15.20.1.1 remote-as 15 ! EBGP peer with Customer Red CE1
neighbor 15.20.1.1 activate
neighbor 15.20.1.1 default-originate
no auto-summary
 no synchronization
exit-address-family
!
ip classless
ip route 16.16.16.16 255.255.255.255 Tunnel0 ! Static Route for BLUE Tunnel
ip route 17.17.17.17 255.255.255.255 Tunnel1 ! Static Route for RED Tunnel
!
ip bgp-community new-format
!
ip explicit-path name BLUE-TUNNEL enable ! Explicit Path for BLUE Tunnel
next-address 20.1.12.2 ! Direct to PE2
!
ip explicit-path name RED-TUNNEL enable ! Explicit Path for RED Tunnel
next-address 20.1.13.2 ! First to P-Router (Core)
next-address 20.1.23.1 ! Then to PE2
!
access-list 1 permit 10.2.2.0 0.0.0.255 ! Adjacent Customer Blue subnets
access-list 1 permit 10.20.2.0 0.0.0.3 ! Adjacent Customer Blue subnets
access-list 2 permit 15.2.2.0 0.0.0.255 ! Adjacent Customer Red subnets
access-list 2 permit 15.20.2.0 0.0.0.3 ! Adjacent Customer Red subnets
!
route-map TUNNEL-ASSIGNMENT permit 10 ! BGP Inbound Route-Map
match ip address 1 ! Identifies Customer Blue subnets
set ip next-hop 16.16.16.16 ! Sets BGP Next-Hop to 16.16.16.16
!
route-map TUNNEL-ASSIGNMENT permit 20
match ip address 2 ! Identifies Customer Red subnets
set ip next-hop 17.17.17.17 ! Sets BGP Next-Hop to 17.17.17.17
!
!

Because all t unnels are unidirect ional, t he sam e logic is applied in t he reverse direct ion, where
t he fict it ious addresses are 18.18.18.18 ( for Blue) and 19.19.19.19 ( for Red) , as det ailed in
Exam ple 15- 16 .

Ex a m ple 1 5 - 1 6 . PE2 M PLS Pe r - VPN TE Ex a m ple Con figu r a t ion

!
hostname PE2
!
!
ip vrf BLUE ! BLUE MPLS VPN definition
rd 100:1
route-target export 100:1
route-target import 100:1
!
ip vrf RED ! RED MPLS VPN definition
rd 150:1
route-target export 150:1
route-target import 150:1
!
ip cef ! IP CEF is required for MPLS and MPLS TE
mpls ldp logging neighbor-changes
mpls traffic-eng tunnels ! MPLS TE is enabled globally
!
!
interface Loopback0 ! Loopback interface for MPLS TE RID
ip address 20.2.2.2 255.255.255.255
!
interface Tunnel0
description BLUE-TUNNEL (PE2=>PE1)
ip unnumbered Loopback0
tunnel destination 20.1.1.1
tunnel mode mpls traffic-eng ! MPLS TE is enabled on Tunnel int
tunnel mpls traffic-eng priority 7 7 ! Lower value is preferred
tunnel mpls traffic-eng bandwidth 77500 ! 77.5 Mbps can be reserved
tunnel mpls traffic-eng path-option 1 explicit name BLUE-TUNNEL ! BLUE Path
!
interface Tunnel1
description RED-TUNNEL (PE2=>P=>PE1)
ip unnumbered Loopback0
tunnel destination 20.1.1.1
tunnel mode mpls traffic-eng ! MPLS TE is enabled on Tunnel int
tunnel mpls traffic-eng priority 7 7 ! Lower value is preferred
tunnel mpls traffic-eng bandwidth 77500 ! 77.5 Mbps can be reserved via RSVP
tunnel mpls traffic-eng path-option 1 explicit name RED-TUNNEL ! RED Path
!
!
interface FastEthernet1/0
description FE to Customer Blue CE2
ip vrf forwarding BLUE ! Interface to Blue CE2
ip address 10.20.2.2 255.255.255.252
!
interface FastEthernet1/1
description FE to Customer Red CE2
ip vrf forwarding RED ! Interface to Red CE2
ip address 15.20.2.2 255.255.255.252
!
interface POS5/0
description PE2=>PE1 POS Link
ip address 20.1.12.2 255.255.255.252
mpls traffic-eng tunnels ! MPLS TE enabled on int
tag-switching ip ! MPLS enabled on int
ip rsvp bandwidth 77500 77500 ! RSVP enabled on int for 77.5 Mbps
!
interface POS6/0
description PE2=>P-Router (Core) POS Link
ip address 20.1.23.1 255.255.255.252
mpls traffic-eng tunnels ! MPLS TE enabled on int
tag-switching ip ! MPLS enabled on int
ip rsvp bandwidth 77500 77500 ! RSVP enabled on int for 77.5 Mbps
!
router ospf 100
mpls traffic-eng router-id Loopback0 ! MPLS TE RID
mpls traffic-eng area 0 ! Enables OSPF area 0 for MPLS TE
log-adjacency-changes
redistribute connected subnets
network 20.1.12.0 0.0.0.3 area 0
 network 20.1.23.0 0.0.0.3 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
redistribute connected
neighbor 20.1.1.1 remote-as 100
neighbor 20.1.1.1 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 20.1.1.1 activate ! MPLS VPN neighbor (PE1)
neighbor 20.1.1.1 send-community extended
neighbor 20.1.1.1 route-map TUNNEL-ASSIGNMENT in ! Applies BGP PBR
exit-address-family
!
address-family ipv4 vrf BLUE
redistribute connected
neighbor 10.20.2.1 remote-as 10 ! EBGP peer with Customer Blue CE2
neighbor 10.20.2.1 activate
neighbor 10.20.2.1 default-originate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
neighbor 15.20.2.1 remote-as 15 ! EBGP peer with Customer Red CE2
neighbor 15.20.2.1 activate
neighbor 15.20.2.1 default-originate
no auto-summary
no synchronization
exit-address-family
!
ip classless
ip route 18.18.18.18 255.255.255.255 Tunnel0 ! Static Route for BLUE Tunnel
ip route 19.19.19.19 255.255.255.255 Tunnel1 ! Static Route for RED Tunnel
!
ip bgp-community new-format
!
ip explicit-path name BLUE-TUNNEL enable ! Explicit Path for BLUE Tunnel
next-address 20.1.12.1 ! Direct to PE1
!
ip explicit-path name RED-TUNNEL enable ! Explicit Path for RED Tunnel
next-address 20.1.23.2 ! First to P-Router (Core)
next-address 20.1.13.1 ! Then to PE1
!
access-list 1 permit 10.1.1.0 0.0.0.255 ! Adjacent Customer Blue subnets
access-list 1 permit 10.20.1.0 0.0.0.3 ! Adjacent Customer Blue subnets
access-list 2 permit 15.1.1.0 0.0.0.255 ! Adjacent Customer Red subnets
access-list 2 permit 15.20.1.0 0.0.0.3 ! Adjacent Customer Red subnets
!
route-map TUNNEL-ASSIGNMENT permit 10 ! BGP Inbound Route-Map
match ip address 1 ! Identifies Customer Blue subnets
set ip next-hop 18.18.18.18 ! Sets BGP Next-Hop to 18.18.18.18
!
 route-map TUNNEL-ASSIGNMENT permit 20
match ip address 2 ! Identifies Customer Red subnets
set ip next-hop 19.19.19.19 ! Sets BGP Next-Hop to 19.19.19.19
!

A sam ple P- rout er configurat ion is shown in Figure 15- 17 t o illust rat e t he MPLS TE com m ands
required in t he core.

Ex a m ple 1 5 - 1 7 . P- Rou t e r M PLS Pe r - VPN TE Ex a m ple Con figu r a t ion

!
hostname P-Router
!
!
ip cef ! IP CEF is required for MPLS and MPLS TE
mpls ldp logging neighbor-changes
mpls traffic-eng tunnels ! MPLS TE is enabled globally
!
!
!
interface Loopback0 ! Loopback interface for MPLS TE RID
ip address 20.3.3.3 255.255.255.255
!
!
interface POS5/0
description P-Router (Core) => PE1 POS Link
ip address 20.1.13.2 255.255.255.252
mpls traffic-eng tunnels ! MPLS TE enabled on int
tag-switching ip ! MPLS enabled on int
ip rsvp bandwidth 77500 77500 ! RSVP enabled on int for 77.5 Mbps
!
interface POS6/0
description P-Router (Core) => PE2 POS Link
ip address 20.1.23.2 255.255.255.252
mpls traffic-eng tunnels ! MPLS TE enabled on int
tag-switching ip ! MPLS enabled on int
ip rsvp bandwidth 77500 77500 ! RSVP enabled on int for 77.5 Mbps
!
router ospf 100
mpls traffic-eng router-id Loopback0 ! MPLS TE RID
mpls traffic-eng area 0 ! Enables OSPF area 0 for MPLS TE
log-adjacency-changes
redistribute connected subnets
network 20.1.13.0 0.0.0.3 area 0
network 20.1.23.0 0.0.0.3 area 0
!

Verificat ion com m ands:

sh ow ip r svp in t e r fa ce
 sh ow ip r svp n e igh bor

sh ow m pls in t e r fa ce

sh ow m pls t r a ffic- e n g t u n n e ls su m m a r y

sh ow m pls t r a ffic- e n g t u n n e ls sh ow m pls t r a ffic- e n g t opology

sh ow ip bgp vpn v4 a ll

pin g vr f wit h sh ow in t e r fa ce t u n n e l

Verification Command: show ip rsvp interface

The sh ow ip r svp in t e r fa ce com m and is useful t o verify whet her all physical int erfaces t hat can
part icipat e in t unnels have been configured wit h an am ount of reservable bandwidt h. I f t he
com m and ip r svp ba n dw idt h is om it t ed from t he int erface configurat ion, t he am ount of
reservable bandwidt h for t hat int erface default s t o 0. A com m on cause of t unnels not com ing up
is t he oversight of configuring RSVP reservat ions on t he physical int erface. See Exam ple 15- 18 .

Ex a m ple 1 5 - 1 8 . Ve r ifica t ion of RSVP Con figu r a t ion on Loca l Rou t e r

PE1#show ip rsvp interface

interface allocated i/f max flow max sub max
PO5/0 77500K 77500K 77500K 0
PO6/0 77500K 77500K 77500K 0
PE1#

Verification Command: show ip rsvp neighbor

A sim ilar com m and for checking whet her RSVP has been enabled properly on physical int erfaces
is t he sh ow ip r svp n e igh bor com m and, which report s whet her RSVP has been enabled on
neighboring rout er int erfaces. See Exam ple 15- 19 .

Ex a m ple 1 5 - 1 9 . Ve r ifica t ion of RSVP Con figu r a t ion on N e igh bor in g

Rou t e r s

PE1#show ip rsvp neighbor

20.1.12.2 RSVP
20.1.13.2 RSVP
PE1#

Verification Command: show mpls interface

The sh ow m pls in t e r fa ce com m and is a useful com m and t o verify whet her t ag swit ching has
been configured properly on local int erfaces. This com m and also list s which int erfaces m ay
part icipat e in t unnels. Not ice t hat t ag swit ching is not configured explicit ly on t unnel int erfaces,
alt hough t hey are advert ised t hrough t he link- st at e I GP. See Exam ple 15- 20 .

Ex a m ple 1 5 - 2 0 . Ve r ifica t ion of Ta g- Sw it ch in g Con figu r a t ion

PE1#show mpls interfaces

Interface IP Tunnel Operational
POS5/0 Yes (tdp) Yes Yes
POS6/0 Yes (tdp) Yes Yes
Tunnel0 No No Yes
Tunnel1 No No Yes
PE1#

Verification Command: show mpls traffic-eng tunnels summary

A quick way t o check whet her MPLS TE has been enabled globally and has been configured
properly is t o use t he sh ow m pls t r a ffic- e n g t u n n e ls su m m a r y com m and. Exam ple 15- 21
shows an exam ple of t his com m and: Two t unnel heads and t wo t unnel t ails have been
configured correct ly and are act ive.

Ex a m ple 1 5 - 2 1 . Ve r ifica t ion of M PLS TE Globa l Con figu r a t ion

PE1#show mpls traffic-eng tunnels summary

Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Head: 2 interfaces, 2 active signalling attempts, 2 established
3 activations, 1 deactivations
Midpoints: 0, Tails: 2
Periodic reoptimization: every 3600 seconds, next in 1712 seconds
Periodic auto-bw collection: disabled
PE1#

Verification Command: show mpls traffic-eng tunnels

Addit ional per- t unnel det ail is shown by t he sh ow m pls t r a ffic- e n g t u n n e ls com m and. See
Exam ple 15- 22 .

Ex a m ple 1 5 - 2 2 . Ve r ifica t ion of M PLS Tu n n e l D e t a ils

PE1#show mpls traffic-eng tunnels tunnel 0

Name: BLUE-TUNNEL (PE1=>PE2) (Tunnel0) Destination: 20.2.2.2
Status
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type explicit BLUE-TUNNEL (Basis for Setup, path weight 1)
 Config Parameters:
Bandwidth: 77500 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 77500 bw-based
auto-bw: disabled
InLabel : -
OutLabel : POS5/0, implicit-null
RSVP Signalling Info:
Src 20.1.1.1, Dst 20.2.2.2, Tun_Id 0, Tun_Instance 7
RSVP Path Info:
My Address: 20.1.1.1
Explicit Route: 20.1.12.2 20.2.2.2
Record Route: NONE
Tspec: ave rate=77500 kbits, burst=1000 bytes, peak rate=77500 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=77500 kbits, burst=1000 bytes, peak rate=77500 kbits
Shortest Unconstrained Path Info:
Path Weight: 1 (TE)
Explicit Route: 20.1.12.2 20.2.2.2
History:
Tunnel:
Time since created: 2 hours, 34 minutes
Time since path change: 2 hours, 34 minutes
Current LSP:
Uptime: 2 hours, 34 minutes
PE1#

Verification Command: ping vrf with show interface tunnel

Verificat ion of t he MPLS TE solut ion can be perform ed wit h a pin g vr f com m and coupled wit h a
sh ow in t e r fa ce t u n n e l com m and t o dem onst rat e t hat t raffic for each VPN is being sent over
t he proper t unnel. The int erface count ers can be cleared wit h t he cle a r cou n t e r s com m and
before t hese t est s. See Exam ple 15- 23 .

Ex a m ple 1 5 - 2 3 . Solut ion Verificat ion wit h pin g vr f and sh ow in t e r fa ce

t u n n e l Com m ands

PE1#ping vrf BLUE 10.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
PE1#ping vrf RED 15.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 15.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
PE1#ping vrf RED 15.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 15.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
PE1#ping vrf RED 15.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 15.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
PE1#
PE1#show interface tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Description: BLUE-TUNNEL (PE1=>PE2)
Interface is unnumbered. Using address of Loopback0 (20.1.1.1)
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source UNKNOWN, destination 20.2.2.2
Tunnel protocol/transport Label Switching, key disabled, sequencing disabled
Checksumming of packets disabled, fast tunneling enabled
Last input never, output never, output hang never
Last clearing of "show interface" counters 00:00:28
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 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
5 packets output, 500 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
PE1#
PE1#show interface tunnel 1
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Description: RED-TUNNEL (PE1=>P=>PE2)
Interface is unnumbered. Using address of Loopback0 (20.1.1.1)
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source UNKNOWN, destination 20.2.2.2
Tunnel protocol/transport Label Switching, key disabled, sequencing disabled
Checksumming of packets disabled, fast tunneling enabled
Last input never, output never, output hang never
Last clearing of "show interface" counters 00:00:37
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 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
15 packets output, 1500 bytes, 0 underruns
 0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
PE1#

MPLS DS-TE

MPLS t raffic engineering allows const raint - based rout ing ( CBR) of I P t raffic. One of t he
const raint s sat isfied by CBR is t he availabilit y of required bandwidt h over a select ed pat h.
DiffServ- aware t raffic engineering ext ends MPLS t raffic engineering t o enable you t o perform
const raint - based rout ing of " guarant eed" t raffic, which sat isfies a m ore rest rict ive bandwidt h
const raint t han t hat required for regular t raffic. The m ore rest rict ive bandwidt h is t erm ed a
subpool, and t he regular TE t unnel bandwidt h is called t he global pool ( t he subpool is a port ion
of t he global pool) . This capabilit y t o sat isfy a m ore rest rict ive bandwidt h const raint t ranslat es
int o a capabilit y t o achieve higher qualit y of service perform ance ( in t erm s of delay, j it t er, or
loss) for t he guarant eed t raffic.

For exam ple, DS- TE can be used t o ensure t hat t raffic is rout ed over t he net work so t hat , on
every link, t here is never m ore t han 35 percent ( or any assigned percent age) of t he link capacit y
of guarant eed t raffic ( for exam ple, voice) , while t here can be up t o 100 percent of t he link
capacit y of regular t raffic. Assum ing t hat QoS m echanism s also are used on every link t o queue
guarant eed t raffic separat ely from regular t raffic, it t hen becom es possible t o enforce separat e
" overbooking" rat ios for guarant eed and regular t raffic.

Also, t hrough t he capabilit y t o enforce a m axim um percent age of guarant eed t raffic on any link,
t he net work adm inist rat or direct ly can cont rol t he end- t o- end QoS perform ance param et ers
wit hout having t o rely on overengineering or on expect ed short est - pat h rout ing behavior. This is
essent ial for t ransport of applicat ions t hat have very high QoS requirem ent s ( such as real- t im e
voice, virt ual I P leased line, and bandwidt h t rading) , where overengineering cannot be assum ed
everywhere in t he net work.

DS- TE involves ext ending t he I GP link- st at e prot ocols so t hat t he available subpool bandwidt h at
each preem pt ion level is advert ised in addit ion t o t he available global pool bandwidt h at each
preem pt ion level. DS- TE m odifies const raint - based rout ing t o t ake t his m ore com plex advert ised
inform at ion int o account during pat h com put at ion.

DiffServ- aware t raffic engineering enables service providers t o perform separat e adm ission
cont rol and separat e rout e com put at ion for discret e subset s of t raffic ( for exam ple, voice and
dat a t raffic) . Rem em ber, as wit h expedit ed forwarding, PHBs can prot ect voice from dat a, but
only adm ission- cont rol m echanism s can prot ect voice from voice.

For exam ple, a service provider m ight sell voice services t o t wo cust om ers, bot h wit h a st rict -
priorit y servicing requirem ent . However, if congest ion is occurring on a node t o t he point t hat
not enough bandwidt h is available for bot h cust om ers' voice t raffic, MPLS DS- TE can signal t his
condit ion back t o t he headend so t hat addit ional voice t raffic can be rerout ed along a different
pat h where adequat e priorit y bandwidt h st ill exist s.

I n short , MPLS DS- TE offers addit ional granularit y and guarant ees t o t raffic engineering
scenarios, which are suit ed especially t o Real- Tim e applicat ions such as Voice and I nt eract ive-
Video.

These increm ent al st eps are required for enabling MPLS DS- TE:

Provision per- link DiffServ policies:

 PE1(config)#class-map match-all CORE-REALTIME
PE1(config-cmap)#match mpls experimental topmost 5
PE1(config-cmap)#class-map match-all CORE-CRITICAL-DATA
PE1(config-cmap)#match mpls experimental topmost 6
PE1(config-cmap)#match mpls experimental topmost 3
PE1(config-cmap)#policy-map CORE-THREE-CLASS-SP-MODEL
PE1(config-pmap)#class CORE-REALTIME
PE1(config-pmap-c)#priority percent 35
PE1(config-pmap-c)#class CORE-CRITICAL-DATA
PE1(config-pmap-c)#bandwidth percent 55
PE1(config-pmap-c)#class class-default
PE1(config-pmap-c)#interface pos 5/0
PE1(config-if)# max-reserved-bandwidth 100
PE1(config-if)# service-policy output CORE-THREE-CLASS-SP-MODEL
PE1(config)#interface pos 6/0
PE1(config-if)# max-reserved-bandwidth 100
PE1(config-if)# service-policy output CORE-THREE-CLASS-SP-MODEL
PE1(config-if)#exit

Assign per- link reservable subpool bandwidt h allot m ent s on all physical int erfaces t hat are
part icipat ing in DS- TE t unnels ( including links on m idpoint rout ers) :

PE1(config)#interface pos 5/0

PE1(config-if)# ip rsvp bandwidth 77500 sub-pool 54250

Assign a reservable subpool bandwidt h t o each MPLS DS- TE t unnel headend:

PE1(config)#interface tunnel 0
PE1(config-if)#tunnel mpls traffic-eng bandwidth sub-pool 54250

Lower t he priorit y ( rem em ber lower is bet t er) of t he MPLS DS- TE t unnel so t hat it can
preem pt reservat ions, as needed:

PE1(config)#interface tunnel 0
PE1(config-if)# tunnel mpls traffic-eng priority 0 0

Tight en down on t he MPLS DS- TE headend t unnel adm ission cont rol crit eria ( via st at ic
rout es and/ or policy- based rout ing) .

A sim plifying assum pt ion was m ade in t he previous scenario ( MPLS per- VPN TE) t hat each
cust om er's subnet s would not overlap. I n t he real world, however, t his is an unlikely
assum pt ion. Therefore, in t his second MPLS TE exam ple, addit ional rat chet ing has been done on
t he t unnel headends t o allow only Voice t raffic from Cust om er Blue t o t raverse t he short er
t unnel, despit e t he fact t hat , in t his exam ple, bot h Cust om er Blue and Cust om er Red are using
t he sam e privat e address space. Voice t raffic is ident ified as dest ined for t he voice VLAN subnet s
of t he CE rout ers ( 10.1.10 x .0/ 24) , as shown in Figure 15- 21 .
 Figu r e 1 5 - 2 1 . M PLS D S- TE Ex a m ple D e t a ils

[View full size image]

I n addit ion t o ident ifying Voice t raffic by dest inat ion subnet address, t he BGP VPNv4 rout e
t arget s m ust m at ch Cust om er Blue's assigned rout e t arget ( 100: 1) . I n t his m anner, only
Cust om er Blue, which has purchased a prem ium service, gains access t o t he direct DS- TE t unnel
t o geographically adj acent CEs ( despit e t he fact t hat Cust om er Red is using ident ical privat e I P
addresses) .

N ot e
Only st andard I P Ext ended Com m unit y list s ( num bered 1 t o 99) support t he rout e
t arget ( RT) keyword and funct ionalit y.

Addit ionally, very basic core DiffServ policies are applied t o t he POS links connect ing PE and P
rout ers. A sim plifying assum pt ion is m ade t hat t raffic has been m arked correct ly on t he CEs and
is being m apped t o MPLS EXP values using t he st andard ( default ) DSCP- t o- EXP m apping ( for
exam ple, DSCP EF is m apped t o MPLS EXP 5) . For sim plicit y, no policers are shown in Exam ple
15- 24 ; t hese are reint roduced, however, in t he final case st udy exam ple at t he end of t his
chapt er.

As wit h t he previous exam ple, t he configurat ion for t his MPLS DS- TE exam ple spans t hree
rout ers: PE1 configurat ion ( see Exam ple 15- 24 ) , PE2 configurat ion ( see Exam ple 15- 25 ) , and
t he P rout er ( see Exam ple 15- 26 ) configurat ion.

Ex a m ple 1 5 - 2 4 . PE1 M PLS D S- TE Ex a m ple Con figu r a t ion

!
hostname PE1
!
!
ip vrf BLUE ! BLUE MPLS VPN definition
 rd 100:1
route-target export 100:1
route-target import 100:1
!
ip vrf RED ! RED MPLS VPN definition
rd 150:1
route-target export 150:1
route-target import 150:1
!
ip cef ! IP CEF is required for MPLS and MPLS TE
mpls ldp logging neighbor-changes
mpls traffic-eng tunnels ! MPLS TE is enabled globally
!
!
class-map match-all CORE-REALTIME
match mpls experimental topmost 5
class-map match-all CORE-CRITICAL-DATA
match mpls experimental topmost 6
match mpls experimental topmost 3
!
!
policy-map CORE-THREE-CLASS-SP-MODEL ! Per-link scheduling policy
class CORE-REALTIME
priority percent 35
class CORE-CRITICAL-DATA
bandwidth percent 55
class class-default
fair-queue
!
!
interface Loopback0 ! Loopback interface for MPLS TE RID
ip address 20.1.1.1 255.255.255.255
!
interface Tunnel0
description TUNNEL0 (PE1=>PE2)
ip unnumbered Loopback0
tunnel destination 20.2.2.2
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng priority 0 0 ! Lower value is preferred
tunnel mpls traffic-eng bandwidth sub-pool 54250 ! MPLS DS-TE sub-pool
tunnel mpls traffic-eng path-option 1 explicit name TUNNEL0
!
interface Tunnel1
description TUNNEL0 (PE1=>P=>PE2)
ip unnumbered Loopback0
tunnel destination 20.2.2.2
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 77500
tunnel mpls traffic-eng path-option 1 explicit name TUNNEL1
!
!
interface FastEthernet1/0
description FE to Customer Blue CE1
ip vrf forwarding BLUE ! Interface to Blue CE1
ip address 10.20.1.2 255.255.255.252 ! Same IP address as Red
!
interface FastEthernet1/1
description FE to Customer Red CE1
ip vrf forwarding RED ! Interface to Red CE1
ip address 10.20.1.2 255.255.255.252 ! Same IP address as Blue
!
interface POS5/0
description PE1=>PE2 POS Link
ip address 20.1.12.1 255.255.255.252
max-reserved-bandwidth 100
service-policy output CORE-THREE-CLASS-SP-MODEL ! Scheduling applied
mpls traffic-eng tunnels
tag-switching ip
ip rsvp bandwidth 77500 sub-pool 54250 ! Sub-pool defined on int
!
interface POS6/0
description PE1=>P-Router (Core) POS Link
ip address 20.1.13.1 255.255.255.252
max-reserved-bandwidth 100
service-policy output CORE-THREE-CLASS-SP-MODEL ! Scheduling applied
mpls traffic-eng tunnels
tag-switching ip
ip rsvp bandwidth 77500 77500 ! No change to PE-P RSVP
!
router ospf 100
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
log-adjacency-changes
redistribute connected subnets
network 20.1.12.0 0.0.0.3 area 0
network 20.1.13.0 0.0.0.3 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
redistribute connected
neighbor 20.2.2.2 remote-as 100
neighbor 20.2.2.2 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 20.2.2.2 activate
neighbor 20.2.2.2 send-community extended
neighbor 20.2.2.2 route-map TUNNEL-ASSIGNMENT in ! Applies BGP PBR
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
neighbor 10.20.1.1 remote-as 15
neighbor 10.20.1.1 activate
neighbor 10.20.1.1 default-originate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf BLUE
 redistribute connected
neighbor 10.20.1.1 remote-as 10
neighbor 10.20.1.1 activate
neighbor 10.20.1.1 default-originate
no auto-summary
no synchronization
exit-address-family
!
ip classless
ip route 16.16.16.16 255.255.255.255 Tunnel0 ! Static route for Tunnel 0
ip route 17.17.17.17 255.255.255.255 Tunnel1 ! Static route for Tunnel 1
!
ip extcommunity-list 1 permit rt 100:1 ! Identifies Blue VPN by RT
ip extcommunity-list 2 permit rt 150:1 ! Identifies Red VPN by RT
ip bgp-community new-format
!
ip explicit-path name TUNNEL0 enable
next-address 20.1.12.2
!
ip explicit-path name TUNNEL1 enable
next-address 20.1.13.2
next-address 20.1.23.1
!
access-list 1 permit 10.2.102.0 0.0.0.255 ! Identifies (Blue) Voice-VLAN
access-list 2 permit 10.2.2.0 0.0.0.255 ! Identifies (Blue) Data-VLAN
access-list 2 permit 10.20.2.0 0.0.0.3 ! Identifies (Blue) PE-CE link
access-list 3 permit 10.2.102.0 0.0.0.255 ! Identifies (Red) Voice-VLAN
access-list 3 permit 10.2.2.0 0.0.0.255 ! Identifies (Red) Data-VLAN
access-list 3 permit 10.20.2.0 0.0.0.3 ! Identifies (Red) PE-CE Link
!
route-map TUNNEL-ASSIGNMENT permit 10
match ip address 1 ! Matches Voice-VLAN subnet
match extcommunity 1 ! Matches Blue VPN RT
set ip next-hop 16.16.16.16 ! Sets BGP Next-Hop to 16.16.16.16
!
route-map TUNNEL-ASSIGNMENT permit 20
match ip address 2 ! Matches other (Blue) subnets
match extcommunity 1 ! Matches Blue VPN RT
set ip next-hop 17.17.17.17 ! Sets BGP Next-Hop to 17.17.17.17
!
route-map TUNNEL-ASSIGNMENT permit 30
match ip address 3 ! Matches all (Red) subnets
match extcommunity 2 ! Matches Red VPN RT
set ip next-hop 17.17.17.17 ! Sets BGP Next-Hop to 17.17.17.17
!

The second/ com plem ent ary PE rout er's configurat ion for t his MPLS DS- TE exam ple is shown in
Exam ple 15- 25 .

Ex a m ple 1 5 - 2 5 . PE2 M PLS D S- TE Ex a m ple Con figu r a t ion

!
hostname PE2
!
!
ip vrf BLUE ! BLUE MPLS VPN definition
rd 100:1
route-target export 100:1
route-target import 100:1
!
ip vrf RED ! RED MPLS VPN definition
rd 150:1
route-target export 150:1
route-target import 150:1
!
ip cef ! IP CEF is required for MPLS and MPLS TE
mpls ldp logging neighbor-changes
mpls traffic-eng tunnels ! MPLS TE is enabled globally
!
!
class-map match-all CORE-REALTIME
match mpls experimental topmost 5
class-map match-all CORE-CRITICAL-DATA
match mpls experimental topmost 6
match mpls experimental topmost 3
!
!
policy-map CORE-THREE-CLASS-SP-MODEL ! Per-link scheduling policy
class CORE-REALTIME
priority percent 35
class CORE-CRITICAL-DATA
bandwidth percent 55
class class-default
fair-queue
!
!
interface Loopback0 ! Loopback interface for MPLS TE RID
ip address 20.2.2.2 255.255.255.255
!
interface Tunnel0
description TUNNEL0 (PE2=>PE1)
ip unnumbered Loopback0
tunnel destination 20.1.1.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng priority 0 0 ! Lower value is preferred
tunnel mpls traffic-eng bandwidth sub-pool 54250 ! MPLS DS-TE sub-pool
!
interface Tunnel1
description TUNNEL1 (PE2=>P=>PE1)
ip unnumbered Loopback0
tunnel destination 20.1.1.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 77500
tunnel mpls traffic-eng path-option 1 explicit name TUNNEL1
!
!
interface FastEthernet1/0
 description FE to Customer Blue CE2
ip vrf forwarding BLUE ! Interface to Blue CE2
ip address 10.20.2.2 255.255.255.252 ! Same IP address as Red
!
interface FastEthernet1/1
description FE to Customer Red CE2
ip vrf forwarding RED ! Interface to Red CE2
ip address 10.20.2.2 255.255.255.252 ! Same IP address as Blue
!
interface POS5/0
description PE2=>PE1 POS Link
ip address 20.1.12.2 255.255.255.252
max-reserved-bandwidth 100
service-policy output CORE-THREE-CLASS-SP-MODEL ! Scheduling applied
mpls traffic-eng tunnels
tag-switching ip
ip rsvp bandwidth 77500 sub-pool 54250 ! Sub-pool defined on int
!
interface POS6/0
description PE2=>P-Router (Core) POS Link
ip address 20.1.23.1 255.255.255.252
max-reserved-bandwidth 100
service-policy output CORE-THREE-CLASS-SP-MODEL ! Scheduling applied
mpls traffic-eng tunnels
tag-switching ip
ip rsvp bandwidth 77500 77500 ! No change to PE-P RSVP
!
router ospf 100
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
log-adjacency-changes
redistribute connected subnets
network 20.1.12.0 0.0.0.3 area 0
network 20.1.23.0 0.0.0.3 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
redistribute connected
neighbor 20.1.1.1 remote-as 100
neighbor 20.1.1.1 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 20.1.1.1 activate
neighbor 20.1.1.1 send-community extended
neighbor 20.2.2.2 route-map TUNNEL-ASSIGNMENT in ! Applies BGP PBR
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
neighbor 10.20.2.1 remote-as 15
neighbor 10.20.2.1 activate
neighbor 10.20.2.1 default-originate
no auto-summary
no synchronization
 exit-address-family
!
address-family ipv4 vrf BLUE
redistribute connected
neighbor 10.20.2.1 remote-as 10
neighbor 10.20.2.1 activate
neighbor 10.20.2.1 default-originate
no auto-summary
no synchronization
exit-address-family
!
ip classless
ip route 18.18.18.18 255.255.255.255 Tunnel0 ! Static route for Tunnel 0
ip route 19.19.19.19 255.255.255.255 Tunnel1 ! Static route for Tunnel 1
!
ip extcommunity-list 1 permit rt 100:1 ! Identifies Blue VPN by RT
ip extcommunity-list 2 permit rt 150:1 ! Identifies Red VPN by RT
ip bgp-community new-format
!
ip explicit-path name TUNNEL0 enable
next-address 20.1.12.1
!
ip explicit-path name TUNNEL1 enable
next-address 20.1.23.2
next-address 20.1.13.1
!
access-list 1 permit 10.1.101.0 0.0.0.255 ! Identifies (Blue) Voice-VLAN
access-list 1 access-list 2 permit 10.1 ! Identifies (Blue) Data-VLAN
access-list 2 permit 10.20.1.0 0.0.0.3 ! Identifies (Blue) PE-CE link
access-list 3 permit 10.1.101.0 0.0.0.255 ! Identifies (Red) Voice-VLAN
access-list 3 permit 10.1.1.0 0.0.0.255 ! Identifies (Red) Data-VLAN
access-list 3 permit 10.20.1.0 0.0.0.3 ! Identifies (Red) PE-CE Link
!
route-map TUNNEL-ASSIGNMENT permit 10
match ip address 1 ! Matches Voice-VLAN subnet
match extcommunity 1 ! Matches Blue VPN RT
set ip next-hop 18.18.18.18 ! Sets BGP Next-Hop to 18.18.18.18
!
route-map TUNNEL-ASSIGNMENT permit 20
match ip address 2 ! Matches other (Blue) subnets
match extcommunity 1 ! Matches Blue VPN RT
set ip next-hop 19.19.19.19 ! Sets BGP Next-Hop to 19.19.19.19
!
route-map TUNNEL-ASSIGNMENT permit 30
match ip address 3 ! Matches all (Red) subnets
match extcommunity 2 ! Matches Red VPN RT
set ip next-hop 19.19.19.19 ! Sets BGP Next-Hop to 19.19.19.19
!

A P rout er's configurat ion for t his MPLS DS- TE exam ple is shown in Exam ple 15- 26 t o highlight
t he MPLS DS- TE configurat ions required in t he core.

Ex a m ple 1 5 - 2 6 . P- Rou t e r M PLS D S- TE Ex a m ple Con figu r a t ion

!
hostname P-Router
!
!
ip cef ! IP CEF is required for MPLS and MPLS TE
mpls ldp logging neighbor-changes
mpls traffic-eng tunnels ! MPLS TE is enabled globally
!
!
class-map match-all CORE-REALTIME
match mpls experimental topmost 5
class-map match-all CORE-CRITICAL-DATA
match mpls experimental topmost 6
match mpls experimental topmost 3
!
!
policy-map CORE-THREE-CLASS-SP-MODEL ! Per-link scheduling policy
class CORE-REALTIME
priority percent 35
class CORE-CRITICAL-DATA
bandwidth percent 55
class class-default
fair-queue
!
!
interface Loopback0 ! Loopback interface for MPLS TE RID
ip address 20.3.3.3 255.255.255.255
!
interface POS5/0
description P-Router (Core) => PE1 POS Link
ip address 20.1.13.2 255.255.255.252
max-reserved-bandwidth 100
service-policy output CORE-THREE-CLASS-SP-MODEL ! Scheduling applied
mpls traffic-eng tunnels
tag-switching ip
ip rsvp bandwidth 77500 77500 ! RSVP enabled on int for 77.5 Mbps
!
interface POS6/0
description P-Router (Core) => PE2 POS Link
ip address 20.1.23.2 255.255.255.252
max-reserved-bandwidth 100
service-policy output CORE-THREE-CLASS-SP-MODEL ! Scheduling applied
mpls traffic-eng tunnels
tag-switching ip
ip rsvp bandwidth 77500 77500 ! RSVP enabled on int for 77.5 Mbps
!
router ospf 100
mpls traffic-eng router-id Loopback0 ! MPLS TE RID
mpls traffic-eng area 0 ! Enables OSPF area 0 for MPLS TE
log-adjacency-changes
redistribute connected subnets
network 20.1.13.0 0.0.0.3 area 0
network 20.1.23.0 0.0.0.3 area 0
!
Verificat ion com m ands:

sh ow ip r svp in t e r fa ce

sh ow ip r svp n e igh bor

sh ow m pls in t e r fa ce

sh ow m pls t r a ffic- e n g t u n n e ls su m m a r y

sh ow m pls t r a ffic- e n g t u n n e ls

sh ow m pls t r a ffic- e n g t opology

sh ow ip bgp vpn v4 a ll

pin g vr f wit h sh ow in t e r fa ce t u n n e l

Verification Command: show mpls traffic-eng topology

The sh ow m pls t r a ffic- e n g t opology com m and det ails ( am ong ot her t hings) t he am ount of
allocat ed bandwidt h for reservat ions on a per- priorit y basis. Exam ple 15- 27 shows t he det ails of
t he 54.25 Mbps ( or 35 percent of t he link) t o be reserved in a subpool of priorit y 0 ( best priorit y)
on t he PE- t o- PE t unnel ( Tunnel0) . Furt herm ore, because t he t ot al reservable bandwidt h on t he
PE- t o- PE links is 77.5 Mbps, t here rem ains 23.35 Mbps ( 77.5 54.25 Mbps) available t o be
reserved over t he sam e link by global- pool t raffic.

The com m and also shows t hat 77.5 Mbps of global- pool t raffic has been allocat ed over t he PE-
t o- P t unnel ( Tunnel1) .

Ex a m ple 1 5 - 2 7 . Ve r ifica t ion of Su bpool a n d Globa l- Pool RSVP

Re se r va t ion s for D S- TE

PE1#show mpls traffic-eng topology 20.1.1.1

IGP Id: 20.1.1.1, MPLS TE Id:20.1.1.1 Router Node id 1
link[0 ]:Nbr IGP Id: 20.2.2.2, nbr_node_id:2, gen:30
frag_id 0, Intf Address:20.1.12.1, Nbr Intf Address:20.1.12.2
TE metric:1, IGP metric:1, attribute_flags:0x0
physical_bw: 155000 (kbps), max_reservable_bw_global: 77500 (kbps)
max_reservable_bw_sub: 54250 (kbps)
Global Pool Sub Pool
Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 54250 23250 0
bw[1]: 0 23250 0
bw[2]: 0 23250 0
bw[3]: 0 23250 0
bw[4]: 0 23250 0
bw[5]: 0 23250 0
bw[6]: 0 23250 0
bw[7]: 0 23250 0
 link[1 ]:Nbr IGP Id: 20.3.3.3, nbr_node_id:3, gen:32
frag_id 1, Intf Address:20.1.13.1, Nbr Intf Address:20.1.13.2
TE metric:1, IGP metric:1, attribute_flags:0x0
physical_bw: 155000 (kbps), max_reservable_bw_global: 77500 (kbps)
max_reservable_bw_sub: 0 (kbps)
Global Pool Sub Pool
Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 0 77500 0
bw[1]: 0 77500 0
bw[2]: 0 77500 0
bw[3]: 0 77500 0
bw[4]: 0 77500 0
bw[5]: 0 77500 0
bw[6]: 0 77500 0
bw[7]: 77500 0 0
PE1#

Verification Command: show ip bgp vpnv4 all

The sh ow ip bgp vpn v4 a ll com m and displays t he BGP next - hop ( and ot her) at t ribut es of all
prefixes from all VRFs. I n Exam ple 15- 28 , t he next - hop at t ribut e of t he prefix represent ing
Cust om er Blue's adj acent CE's voice VLAN ( 10.1.102.0/ 24) is shown t o be set t o t he fict it ious
address of 16.16.16.16, which is resolved recursively t o point t o Tunnel0 ( t he prem ium DS- TE
t unnel for voice) . Alt hough Cust om er Red has t he sam e I P address prefix, it s next hop is set t o
t he fict it ious address of 17.17.17.17, which is resolved recursively t o point t o Tunnel1 ( t he
default t unnel) .

Ex a m ple 1 5 - 2 8 . Ve r ifica t ion of BGP N e x t - H op Policie s

PE1#show ip bgp vpnv4 all

BGP table version is 78, local router ID is 20.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf BLUE)
*> 10.1.1.0/24 10.20.1.1 0 0 10 ?
*> 10.1.101.0/24 10.20.1.1 0 0 10 ?
*>i10.2.2.0/24 17.17.17.17 0 100 0 10 ?
*>i10.2.102.0/24 16.16.16.16 0 100 0 10 ?
* 10.20.1.0/30 10.20.1.1 0 0 10 ?
*> 0.0.0.0 0 32768 ?
*>i10.20.2.0/30 17.17.17.17 0 100 0 ?
Route Distinguisher: 150:1 (default for vrf RED)
*> 10.1.1.0/24 10.20.1.1 0 0 15 ?
*> 10.1.101.0/24 10.20.1.1 0 0 15 ?
*>i10.2.2.0/24 17.17.17.17 0 100 0 15 ?
*>i10.2.102.0/24 17.17.17.17 0 100 0 15 ?
* 10.20.1.0/30 10.20.1.1 0 0 15 ?
*> 0.0.0.0 0 32768 ?
*>i10.20.2.0/30 17.17.17.17 0 100 0 ?
PE1#
Case Study: MPLS VPN QoS Design (CE/PE/P Routers)
Cont inuing t he exam ple from t he previous design chapt ers, t he fict it ious com pany ABC, I nc., has
been growing and expanding, bot h geographically and t echnologically. I t has m ult iple dat a
cent ers in geographically diverse regions t o which it s field needs t o connect efficient ly.
Addit ionally, t o increase collaborat ion and sim ult aneously reduce t ravel expenses, ABC, I nc.,
plans t o roll out any- t o- any videoconferencing. For t hese business reasons, ABC, I nc., has
decided t o m igrat e from it s privat e WAN t o an MPLS VPN, m anaged by service provider XYZ ( SP
XYZ) .

To m inim ize t he cost s of m igrat ion, SP XYZ support s bot h Fram e Relay and ATM Layer 2 access
( including ATM I MA, which has been ABC, I nc.'s, prim ary choice for branch WAN m edia) .

Furt herm ore, SP XYZ is a leader in MPLS VPN services and support s a five- class provider- edge
m odel. Real- t im e service can be purchased in 5 percent increm ent s, as can t he am ount s of t he
t hree ot her levels of preferred service ( Crit ical Dat a, Video, and Bulk Dat a) . ABC I nc. want s it s
WAN m igrat ion t o MPLS VPN t o be as t ransparent t o end users as possible, so it agrees t o
purchase t hese services in am ount s t hat closely m at ch t he current QoS Baseline WAN edge
m odel, wit hout causing t raffic class- m ixing issues.

Addit ionally, ABC, I nc., m onit ors net work ut ilizat ion ( part icularly videoconferencing t raffic) and
perform s t raffic account ing and depart m ent bill- back based on t he DSCP m arkings of t raffic
flows. ABC, I nc., views it as essent ial t hat t he SP not re- m ark any t raffic at Layer 3 as it
t raverses t he MPLS VPN, but rat her preserve t he DSCP m arkings int act . Again, SP XYZ can
accom m odat e ABC, I nc., because it deploys t he popular Short Pipe Mode of MPLS DiffServ
t unneling.

SP XYZ also offers t he opt ion of prem ium service for voice t raffic t o geographically adj acent sit es
( t hrough MPLS DS- TE) . Because ABC, I nc., is a heavy I P t elephony user, it elect s t o purchase
t his prem ium service for voice t raffic ( t hus, from SP XYZ's perspect ive, ABC, I nc., is considered a
" BLUE" class cust om er) .

Figure 15- 22 illust rat es t he com bined ent erprise and service- provider nodes where QoS policies
are required for t his com plex MPLS VPN scenario.

Figu r e 1 5 - 2 2 . Ca se St u dy: M PLS VPN QoS D e sign Ex a m ple D e t a ils

[View full size image]

I n Exam ple 15- 29 , it is assum ed t hat t raffic has been m arked correct ly on cam pus/ branch
swit ches before it arrives at t he CE LAN edges. Where such an assum pt ion is invalid, ingress LAN
edge m arking policies, discussed in Chapt er 14 , " Branch Rout er QoS Design," can be applied t o
t he CE LAN edges. Addit ionally, it has been assum ed t hat t here are no unidirect ional applicat ions
in t his exam ple.

Queuing and m arking policies for a five- class provider- edge m odel have been applied on CE
edges.

On ingress, SP XYZ applies a five- class short pipe MPLS DiffServ t unneling m ode policer t o
ident ify ( t hrough MPLS EXP values) t raffic t hat is in cont ract or out - of- cont ract . DiffServ policies
are applied t hroughout t he MPLS VPN core, and MPLS DS- TE also is provisioned for voice t raffic
t o geographically adj acent CEs. On egress, SP XYZ applies a five- class provider- edge m odel,
which is based on t he cust om er's DiffServ m arkings. I n t his exam ple, com pany ABC, I nc., fit s
service provider XYZ's cust om er Blue profile.

The configurat ion for t his exam ple spans six rout ers: Blue- CE1, Blue- CE2, Red- CE1, Red- CE2,
PE1, PE2, and P rout er. However, because CE configurat ions are virt ually ident ical, only one is
present ed here ( Blue- CE1see Exam ple 15- 29 ) , along wit h t he configurat ions for PE1 ( see
Exam ple 15- 30 ) , PE2 ( see Exam ple 15- 31 ) , and t he P rout er ( see Exam ple 15- 32 ) .

Ex a m ple 1 5 - 2 9 . Blu e - CE1 Ca se St u dy M PLS VPN QoS D e sign Ex a m ple

!
hostname CE1-BLUE
!
ip cef ! IP CEF is required for Packet Marking
!
class-map match-all ROUTING
match ip dscp cs6
class-map match-all VOICE
match ip dscp ef
class-map match-all INTERACTIVE-VIDEO
match ip dscp af41
class-map match-all STREAMING-VIDEO
 match ip dscp cs4
class-map match-all MISSION-CRITICAL-DATA
match ip dscp 25
class-map match-any CALL-SIGNALING
match ip dscp af31
match ip dscp cs3
class-map match-all TRANSACTIONAL-DATA
match ip dscp af21
class-map match-all BULK-DATA
match ip dscp af11
class-map match-all NETWORK-MANAGEMENT
match ip dscp cs2
class-map match-all SCAVENGER
match ip dscp cs1
!
!
policy-map CE-FIVE-CLASS-SP-MODEL
class ROUTING
bandwidth percent 3 ! Routing is assigned (by default) to Critical SP class
class VOICE
priority percent 18 ! Voice is admitted to Realtime SP class
class INTERACTIVE-VIDEO
priority percent 15
set ip dscp cs5 ! Interactive-Video is assigned to the Realtime SP class
class STREAMING-VIDEO
bandwidth percent 13
set ip dscp af21 ! Streaming-Video is assigned to the Video SP class
class CALL-SIGNALING
priority percent 2 ! Call-Signaling gets LLQ for this scenario
set ip dscp cs5 ! Call-Signaling is assigned to the Realtime SP class
class MISSION-CRITICAL-DATA
bandwidth percent 12
random-detect
set ip dscp af31 ! MC Data is assigned to the Critical SP class
class TRANSACTIONAL-DATA
bandwidth percent 5
random-detect
set ip dscp cs3 ! Transactional Data is assigned to Critical SP class
class NETWORK-MANAGEMENT
bandwidth percent 2 ! Net Mgmt (mainly UDP) is admitted to Video SP class
class BULK-DATA
bandwidth percent 5 ! Bulk Data is assigned to Bulk SP class
random-detect
class SCAVENGER
bandwidth percent 1
set ip dscp 0
class class-default
bandwidth percent 24
random-detect
!
!
policy-map CE-LAN-EDGE-OUT
class class-default
set cos dscp ! Enables default DSCP-to-CoS Mapping
!
!
 interface FastEthernet0/0
description TO CAT3500 BRANCH ACCESS-SWITCH
no ip address
!
interface FastEthernet0/0.11
description DLVAN SUBNET 10.1.1.0
encapsulation dot1Q 11
ip address 10.1.1.1 255.255.255.0
service-policy output CE-LAN-EDGE-OUT ! Restores CoS for Data VLAN
!
!
interface FastEthernet0/0.101
description VVLAN SUBNET 10.1.101.0
encapsulation dot1Q 101
ip address 10.1.101.1 255.255.255.0
service-policy output CE-LAN-EDGE-OUT ! Restores CoS on Voice VLAN
!
!
interface ATM1/0
no ip address
no atm ilmi-keepalive
ima-group 1
no scrambling-payload
!
interface ATM1/1
no ip address
no atm ilmi-keepalive
ima-group 1
no scrambling-payload
!
!
interface ATM1/IMA1
no ip address
no atm ilmi-keepalive
!
interface ATM1/IMA1.20 point-to-point
description Dual-T1 ATM IMA Link to PE1
ip address 10.20.1.1 255.255.255.252
pvc 0/120
vbr-nrt 3072 3072
max-reserved-bandwidth 100 ! Overrides 75% BW limit
service-policy output CE-FIVE-CLASS-SP-MODEL ! Applies 5-Class CE-PE Model
!
!
router bgp 10
no synchronization
bgp log-neighbor-changes
redistribute connected
neighbor 10.20.1.2 remote-as 100
no auto-summary
!
!

The configurat ion for t he first PE rout er for t his MPLS VPN QoS design case st udy exam ple is
shown in Exam ple 15- 30 .

Ex a m ple 1 5 - 3 0 . PE1 Ca se St u dy M PLS VPN QoS D e sign Ex a m ple

!
hostname PE1
!
!
ip vrf BLUE ! BLUE MPLS VPN Definition
rd 100:1
route-target export 100:1
route-target import 100:1
!
ip vrf RED ! RED MPLS VPN Definition
rd 150:1
route-target export 150:1
route-target import 150:1
!
ip cef
mpls ldp logging neighbor-changes
mpls traffic-eng tunnels ! Enables MPLS TE globally
!
!
!
class-map match-any REALTIME
match ip dscp ef
match ip dscp cs5
class-map match-any CRITICAL-DATA
match ip dscp cs6
match ip dscp af31
match ip dscp cs3
class-map match-any VIDEO
match ip dscp af21
match ip dscp cs2
class-map match-any BULK-DATA
match ip dscp af11
match ip dscp cs1
class-map match-all CORE-REALTIME
match mpls experimental topmost 5 ! Identifies in-contract Realtime
class-map match-all CORE-CRITICAL-DATA
match mpls experimental topmost 3 ! Identifies in-contract Critical-Data
match mpls experimental topmost 7 ! Identifies out-of-contract Critical Data
match mpls experimental topmost 2 ! Identifies in-contract Video
match mpls experimental topmost 1 ! Identifies in-contract Bulk
match mpls experimental topmost 6 ! Identifies out-of-contract Bulk
!
!
policy-map PE-FIVE-CLASS-SHORT-PIPE-MARKING
claexceed-action set-mpls-exp-topmost-transmit 7
police cir 1050000
conform-action set-mpls-exp-topmost-transmit 5 ! Conforming RT set to 5
exceed-action drop ! Excess Realtime is dropped
class CRITICAL-DATA
police cir 600000
 conform-action set-mpls-exp-topmost-transmit 3 ! Critical Data set to 3
exceed-action set-mpls-exp-topmost-transmit 7 ! Excess Critical set 7
class VIDEO
police cir 450000
conform-action set-mpls-exp-topmost-transmit 2 ! Conforming Video set to 2
exceed-action drop ! Excess Video dropped
class BULK-DATA
police cir 150000
conform-action set-mpls-exp-topmost-transmit 1 ! Conforming Bulk set to 1
exceed-action set-mpls-exp-topmost-transmit 6 ! Excess Bulk set to 6
class class-default
police cir 750000
conform-action set-mpls-exp-topmost-transmit 0 ! Conforming BE set to 0
exceed-action set-mpls-exp-topmost-transmit 4 ! Excess BE set to 4
!
!
policy-map PE-FIVE-CLASS-SP-MODEL
class REALTIME
priority percent 35 ! Realtime SP class gets 35% LLQ
class CRITICAL-DATA
bandwidth percent 20 ! Critical-Data SP class gets 40% CBWFQ
random-detect dscp-based ! DSCP-based WRED enabled on class
class VIDEO
bandwidth percent 15 ! Video SP class gets 15% CBWFQ
random-detect dscp-based ! DSCP-based WRED enabled on "Video" SP class
class BULK-DATA
bandwidth percent 5 ! Bulk Data SP class gets 15% CBWFQ
random-detect dscp-based ! DSCP-based WRED enabled on Bulk Data SP class
class class-default
bandwidth percent 25 ! Best Effort SP class gets 25% CBWFQ
random-detect ! WRED enabled on Best Effort SP class
!
!
policy-map CORE-THREE-CLASS-SP-MODEL
class CORE-REALTIME
priority percent 35 ! CORE-REALTIME gets 35% LLQ
class CORE-CRITICAL-DATA
bandwidth percent 55 ! CORE-CRITICAL gets 55% CBWFQ
class class-default
fair-queue ! CORE-BEST-EFFORT gets FQ
!
!
interface Loopback0 ! Loopback interface for MPLS TE RID
ip address 20.1.1.1 255.255.255.255
!
interface Tunnel0
description TUNNEL0 (PE1=>PE2)
ip unnumbered Loopback0
tunnel destination 20.2.2.2
tunnel mode mpls traffic-eng ! Enables MPLS TE on tunnel
tunnel mpls traffic-eng priority 0 0 ! Best priority
tunnel mpls traffic-eng bandwidth sub-pool 54250 ! Assigns sub-pool
tunnel mpls traffic-eng path-option 1 explicit name TUNNEL0
!
interface Tunnel1
description TUNNEL1 (PE1=>P=>PE2)
 ip unnumbered Loopback0
tunnel destination 20.2.2.2
tunnel mode mpls traffic-eng ! Enables MPLS TE
tunnel mpls traffic-eng priority 7 7 ! Worst priority
tunnel mpls traffic-eng bandwidth 77500 ! Assigns global pool
tunnel mpls traffic-eng path-option 1 explicit name TUNNEL1
!
!
interface ATM2/0
no ip address
ima-group 1
!
interface ATM2/1
no ip address
ima-group 1
!
interface ATM2/ima1
no ip address
no atm ilmi-keepalive
!
interface ATM2/ima1.20 point-to-point
description Dual-T1 ATM IMA Link to Blue CE1
ip vrf forwarding BLUE
ip address 10.20.1.2 255.255.255.252
pvc 0/120
vbr-nrt 3072 3072
max-reserved-bandwidth 100 ! Overrides 75% BW
service-policy input PE-FIVE-CLASS-SHORT-PIPE-MARKING ! Short Pipe Marking
service-policy output PE-FIVE-CLASS-SP-MODEL ! Egress policy to CE
!
!
interface ATM2/2
no ip address
ima-group 2
!
interface ATM2/ima2
no ip address
no atm ilmi-keepalive
!
interface ATM2/ima2.20 point-to-point
description Dual-T1 ATM IMA Link to Red CE1
ip vrf forwarding RED
ip address 10.20.1.2 255.255.255.252
pvc 0/220
vbr-nrt 3072 3072
max-reserved-bandwidth 100 ! Overrides 75% BW
service-policy input PE-FIVE-CLASS-SHORT-PIPE-MARKING ! Short Pipe Marking
service-policy output PE-FIVE-CLASS-SP-MODEL ! Egress policy to CE
!
!
interface ATM2/3
no ip address
ima-group 2
!
!
interface POS5/0
 description PE1=>PE2 POS Link
ip address 20.1.12.1 255.255.255.252
max-reserved-bandwidth 100 ! Overrides 75% BW limit
service-policy output CORE-THREE-CLASS-SP-MODEL ! Applies Core DS policies
mpls traffic-eng tunnels ! Enables MPLS TE on int
tag-switching ip
ip rsvp bandwidth 77500 sub-pool 54250 ! Assigns sub-pool BW
!
interface POS6/0
description PE1=>P-Router (Core) POS Link
ip address 20.1.13.1 255.255.255.252
max-reserved-bandwidth 100 ! Overrides 75% BW limit
service-policy output CORE-THREE-CLASS-SP-MODEL ! Applies Core DS policies
mpls traffic-eng tunnels ! Enables MPLS TE on int
tag-switching ip
ip rsvp bandwidth 77500 77500 ! Assigns global-pool BW
!
router ospf 100
mpls traffic-eng router-id Loopback0 ! MPLS TE RID
mpls traffic-eng area 0 ! Enables OSPF area 0 for MPLS TE
log-adjacency-changes
redistribute connected subnets
network 20.1.12.0 0.0.0.3 area 0
network 20.1.13.0 0.0.0.3 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
redistribute connected
neighbor 20.2.2.2 remote-as 100
neighbor 20.2.2.2 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 20.2.2.2 activate
neighbor 20.2.2.2 send-community extended
neighbor 20.2.2.2 route-map TUNNEL-ASSIGNMENT in ! Applies BGP PBR
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
neighbor 10.20.1.1 remote-as 15
neighbor 10.20.1.1 activate
neighbor 10.20.1.1 default-originate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf BLUE
redistribute connected
neighbor 10.20.1.1 remote-as 10
neighbor 10.20.1.1 activate
neighbor 10.20.1.1 default-originate
no auto-summary
no synchronization
exit-address-family
 ip extcommunity-list 2 permit rt 150:1
ip classless
ip route 16.16.16.16 255.255.255.255 Tunnel0 ! Static route for Tunnel 0
ip route 17.17.17.17 255.255.255.255 Tunnel1 ! Static route for Tunnel 1
!
ip extcommunity-list 1 permit rt 100:1 ! Identifies Blue VPN by RT
ip extcommunity-list 2 permit rt 150:1 ! Identifies Red VPN by RT
ip bgp-community new-format
!
ip explicit-path name TUNNEL0 enable ! Defines explicit path for Tu0
next-address 20.1.12.2
!
ip explicit-path name TUNNEL1 enable ! Defines explicit path for Tu1
next-address 20.1.13.2
next-address 20.1.23.1
!
access-list 1 permit 10.2.102.0 0.0.0.255 ! Identifies (Blue) Voice-VLAN
access-list 2 permit 10.2.2.0 0.0.0.255 ! Identifies (Blue) Data-VLAN
access-list 2 permit 10.20.2.0 0.0.0.3 ! Identifies (Blue) PE-CE link
access-list 3 permit 10.2.102.0 0.0.0.255 ! Identifies (Red) Voice-VLAN
access-list 3 permit 10.2.2.0 0.0.0.255 ! Identifies (Red) Data-VLAN
access-list 3 permit 10.20.2.0 0.0.0.3 ! Identifies (Red) PE-CE Link
!
route-map TUNNEL-ASSIGNMENT permit 10
match ip address 1 ! Matches Voice-VLAN subnet
match extcommunity 1 ! Matches Blue VPN RT
set ip next-hop 16.16.16.16 ! Sets BGP Next-Hop to 16.16.16.16
!
route-map TUNNEL-ASSIGNMENT permit 20
match ip address 2 ! Matches other (Blue) subnets
match extcommunity 1 ! Matches Blue VPN RT
set ip next-hop 17.17.17.17 ! Sets BGP Next-Hop to 17.17.17.17
!
route-map TUNNEL-ASSIGNMENT permit 30
match ip address 3 ! Matches all (Red) subnets
match extcommunity 2 ! Matches Red VPN RT
set ip next-hop 17.17.17.17 ! Sets BGP Next-Hop to 17.17.17.17
!
!

Exam ple 15- 31 shows t he configurat ion for t he second PE rout er for t his MPLS VPN QoS design
case st udy exam ple.

Ex a m ple 1 5 - 3 1 . PE2 Ca se St u dy M PLS VPN QoS D e sign Ex a m ple

!
hostname PE2
!
!
ip vrf BLUE ! BLUE MPLS VPN Definition
rd 100:1
route-target export 100:1
 route-target import 100:1
!
ip vrf RED ! RED MPLS VPN Definition
rd 150:1
route-target export 150:1
route-target import 150:1
!
ip cef
mpls ldp logging neighbor-changes
mpls traffic-eng tunnels ! Enables MPLS TE globally
!
!
!
class-map match-any REALTIME
match ip dscp ef
match ip dscp cs5
class-map match-any CRITICAL-DATA
match ip dscp cs6
match ip dscp af31
match ip dscp cs3
class-map match-any VIDEO
match ip dscp af21
match ip dscp cs2
class-map match-any BULK-DATA
match ip dscp af11
match ip dscp cs1
class-map match-all CORE-REALTIME
match mpls experimental topmost 5 ! Identifies in-contract Realtime
class-map match-all CORE-CRITICAL-DATA
match mpls experimental topmost 3 ! Identifies in-contract Critical-Data
match mpls experimental topmost 7 ! Identifies out-of-contract Critical Data
match mpls experimental topmost 2 ! Identifies in-contract Video
match mpls experimental topmost 1 ! Identifies in-contract Bulk
match mpls experimental topmost 6 ! Identifies out-of-contract Bulk
!
!
policy-map PE-FIVE-CLASS-SHORT-PIPE-MARKING
class REALTIME
police cir 1050000
conform-action set-mpls-exp-topmost-transmit 5 ! Conforming RT set to 5
exceed-action drop ! Excess Realtime is dropped
class CRITICAL-DATA
police cir 600000
conform-action set-mpls-exp-topmost-transmit 3 ! Critical Data set to 3
exceed-action set-mpls-exp-topmost-transmit 7 ! Excess Critical set 7
class VIDEO
police cir 450000
conform-action set-mpls-exp-topmost-transmit 2 ! Conforming Video set to 2
exceed-action drop ! Excess Video dropped
class BULK-DATA
police cir 150000
conform-action set-mpls-exp-topmost-transmit 1 ! Conforming Bulk set to 1
exceed-action set-mpls-exp-topmost-transmit 6 ! Excess Bulk set to 6
class class-default
police cir 750000
conform-action set-mpls-exp-topmost-transmit 0 ! Conforming BE set to 0
 exceed-action set-mpls-exp-topmost-transmit 4 ! Excess BE set to 4
!
!
policy-map PE-FIVE-CLASS-SP-MODEL
class REALTIME
priority percent 35 ! Realtime SP class gets 35% LLQ
class CRITICAL-DATA
bandwidth percent 20 ! Critical-Data SP class gets 40% CBWFQ
random-detect dscp-based ! DSCP-based WRED enabled on class
class VIDEO
bandwidth percent 15 ! Video SP class gets 15% CBWFQ
random-detect dscp-based ! DSCP-based WRED enabled on "Video" SP class
class BULK-DATA
bandwidth percent 5 ! Bulk Data SP class gets 15% CBWFQ
random-detect dscp-based ! DSCP-based WRED enabled on Bulk Data SP class
class class-default
bandwidth percent 25 ! Best Effort SP class gets 25% CBWFQ
random-detect ! WRED enabled on Best Effort SP class
!
!
policy-map CORE-THREE-CLASS-SP-MODEL
class CORE-REALTIME
priority percent 35 ! CORE-REALTIME gets 35% LLQ
class CORE-CRITICAL-DATA
bandwidth percent 55 ! CORE-CRITICAL gets 55% CBWFQ
class class-default
fair-queue ! CORE-BEST-EFFORT gets WFQ
!
!
interface Loopback0 ! Loopback interface for MPLS TE RID
ip address 20.2.2.2 255.255.255.255
!
interface Tunnel0
description TUNNEL0 (PE2=>PE1)
ip unnumbered Loopback0
tunnel destination 20.1.1.1
tunnel mode mpls traffic-eng ! Enables MPLS TE on tunnel
tunnel mpls traffic-eng priority 0 0 ! Best priority
tunnel mpls traffic-eng bandwidth sub-pool 54250 ! Assigns sub-pool
tunnel mpls traffic-eng path-option 1 explicit name TUNNEL0
!
interface Tunnel1
description TUNNEL1 (PE2=>P=>PE1)
ip unnumbered Loopback0
tunnel destination 20.1.1.1
tunnel mode mpls traffic-eng ! Enables MPLS TE
tunnel mpls traffic-eng priority 7 7 ! Worst priority
tunnel mpls traffic-eng bandwidth 77500 ! Assigns global pool
tunnel mpls traffic-eng path-option 1 explicit name TUNNEL1
!
!
interface ATM2/0
no ip address
ima-group 1
!
interface ATM2/1
 no ip address
ima-group 1
!
interface ATM2/ima1
no ip address
no atm ilmi-keepalive
!
interface ATM2/ima1.20 point-to-point
description Dual-T1 ATM IMA Link to Blue CE2
ip vrf forwarding BLUE
ip address 10.20.2.2 255.255.255.252
pvc 0/120
vbr-nrt 3072 3072
max-reserved-bandwidth 100 ! Overrides 75% BW
service-policy input PE-FIVE-CLASS-SHORT-PIPE-MARKING ! Short Pipe Marking
service-policy output PE-FIVE-CLASS-SP-MODEL ! Egress policy to CE
!
!
interface ATM2/2
no ip address
ima-group 2
!
interface ATM2/ima2
no ip address
no atm ilmi-keepalive
!
interface ATM2/ima2.20 point-to-point
description Dual-T1 ATM IMA Link to Red CE2
ip vrf forwarding RED
ip address 10.20.2.2 255.255.255.252
pvc 0/220
vbr-nrt 3072 3072
max-reserved-bandwidth 100 ! Overrides 75% BW
service-policy input PE-FIVE-CLASS-SHORT-PIPE-MARKING ! Short Pipe Marking
service-policy output PE-FIVE-CLASS-SP-MODEL ! Egress policy to CE
!
!
interface POS5/0
description PE2=>PE1 POS Link
ip address 20.1.12.2 255.255.255.252
max-reserved-bandwidth 100 ! Overrides 75% BW limit
service-policy output CORE-THREE-CLASS-SP-MODEL ! Applies Core DS policies
mpls traffic-eng tunnels ! Enables MPLS TE on int
tag-switching ip
ip rsvp bandwidth 77500 sub-pool 54250 ! Assigns sub-pool BW
!
interface POS6/0
description PE2=>P-Router (Core) POS Link
ip address 20.1.23.1 255.255.255.252
max-reserved-bandwidth 100 ! Overrides 75% BW limit
service-policy output CORE-THREE-CLASS-SP-MODEL ! Applies Core DS policies
mpls traffic-eng tunnels ! Enables MPLS TE on int
tag-switching ip
ip rsvp bandwidth 77500 77500 ! Assigns global-pool BW
!
router ospf 100
 mpls traffic-eng router-id Loopback0 ! MPLS TE RID
mpls traffic-eng area 0 ! Enables OSPF area 0 for MPLS TE
log-adjacency-changes
redistribute connected subnets
network 20.1.12.0 0.0.0.3 area 0
network 20.1.23.0 0.0.0.3 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
redistribute connected
neighbor 20.1.1.1 remote-as 100
neighbor 20.1.1.1 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 20.1.1.1 activate
neighbor 20.1.1.1 send-community extended
neighbor 20.1.1.1 route-map TUNNEL-ASSIGNMENT in ! Applies BGP PBR
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
neighbor 10.20.2.1 remote-as 15
neighbor 10.20.2.1 activate
neighbor 10.20.2.1 default-originate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf BLUE
redistribute connected
neighbor 10.20.2.1 remote-as 10
neighbor 10.20.2.1 activate
neighbor 10.20.2.1 default-originate
no auto-summary
no synchronization
exit-address-family
!
ip classless
ip route 18.18.18.18 255.255.255.255 Tunnel0 ! Static route for Tunnel 0
ip route 19.19.19.19 255.255.255.255 Tunnel1 ! Static route for Tunnel 1
!
ip extcommunity-list 1 permit rt 100:1 ! Identifies Blue VPN by RT
ip extcommunity-list 2 permit rt 150:1 ! Identifies Red VPN by RT
ip bgp-community new-format
!
ip explicit-path name TUNNEL0 enable ! Defines explicit path for Tu0
next-address 20.1.12.1
!
ip explicit-path name TUNNEL1 enable ! Defines explicit path for Tu1
next-address 20.1.23.2
next-address 20.1.13.1
!
access-list 1 permit 10.1.101.0 0.0.0.255 ! Identifies (Blue) Voice-VLAN
access-list 2 permit 10.1.1.0 0.0.0.255 ! Identifies (Blue) Data-VLAN
 access-list 2 permit 10.20.1.0 0.0.0.3 ! Identifies (Blue) PE-CE link
access-list 3 permit 10.1.101.0 0.0.0.255 ! Identifies (Red) Voice-VLAN
access-list 3 permit 10.1.1.0 0.0.0.255 ! Identifies (Red) Data-VLAN
access-list 3 permit 10.20.1.0 0.0.0.3 ! Identifies (Red) PE-CE Link
!
route-map TUNNEL-ASSIGNMENT permit 10
match ip address 1 ! Matches Voice-VLAN subnet
match extcommunity 1 ! Matches Blue VPN RT
set ip next-hop 18.18.18.18 ! Sets BGP Next-Hop to 18.18.18.18
!
route-map TUNNEL-ASSIGNMENT permit 20
match ip address 2 ! Matches other (Blue) subnets
match extcommunity 1 ! Matches Blue VPN RT
set ip next-hop 19.19.19.19 ! Sets BGP Next-Hop to 19.19.19.19
!
route-map TUNNEL-ASSIGNMENT permit 30
match ip address 3 ! Matches all (Red) subnets
match extcommunity 2 ! Matches Red VPN RT
set ip next-hop 19.19.19.19 ! Sets BGP Next-Hop to 19.19.19.19
!
!

The configurat ion for t he P rout er for t his MPLS VPN QoS design case- st udy exam ple is shown in
Exam ple 15- 32 .

Ex a m ple 1 5 - 3 2 . P- Rou t e r Ca se St u dy M PLS VPN QoS D e sign Ex a m ple

!
hostname P-Router
!
!
ip cef
mpls ldp logging neighbor-changes
mpls traffic-eng tunnels ! MPLS TE is enabled globally
!
!
class-map match-all CORE-REALTIME
match mpls experimental topmost 5 ! Identifies in-contract Realtime
class-map match-all CORE-CRITICAL-DATA
match mpls experimental topmost 3 ! Identifies in-contract Critical-Data
match mpls experimental topmost 7 ! Identifies out-of-contract Critical Data
match mpls experimental topmost 2 ! Identifies in-contract Video
match mpls experimental topmost 1 ! Identifies in-contract Bulk
match mpls experimental topmost 6 ! Identifies out-of-contract Bulk
!
!
policy-map CORE-THREE-CLASS-SP-MODEL
class CORE-REALTIME
priority percent 35 ! CORE-REALTIME gets 35% LLQ
class CORE-CRITICAL-DATA
bandwidth percent 55 ! CORE-CRITICAL gets 55% CBWFQ
class class-default
 fair-queue ! CORE-BEST-EFFORT gets WFQ
!
!
interface Loopback0 ! Loopback interface for MPLS TE RID
ip address 20.3.3.3 255.255.255.255
!
!
interface POS5/0
description P-Router (Core) => PE1 POS Link
ip address 20.1.13.2 255.255.255.252
max-reserved-bandwidth 100 ! Overrides 75% BW limit
service-policy output CORE-THREE-CLASS-SP-MODEL ! Applies Core DS policies
mpls traffic-eng tunnels ! Enables MPLS TE on int
tag-switching ip
ip rsvp bandwidth 77500 77500 ! Assigns global-pool BW
!
interface POS6/0
description P-Router (Core) => PE2 POS Link
ip address 20.1.23.2 255.255.255.252
max-reserved-bandwidth 100 ! Overrides 75% BW limit
service-policy output CORE-THREE-CLASS-SP-MODEL ! Applies Core DS policies
mpls traffic-eng tunnels ! Enables MPLS TE on int
tag-switching ip
ip rsvp bandwidth 77500 77500 ! Assigns global-pool BW
!
router ospf 100
mpls traffic-eng router-id Loopback0 ! MPLS TE RID
mpls traffic-eng area 0 ! Enables OSPF area 0 for MPLS TE
log-adjacency-changes
redistribute connected subnets
network 20.1.13.0 0.0.0.3 area 0
network 20.1.23.0 0.0.0.3 area 0
!
!

Verificat ion com m ands:

sh ow ip r svp in t e r fa ce

sh ow ip r svp n e igh bor

sh ow m pls in t e r fa ce

sh ow m pls t r a ffic- e n g t u n n e ls su m m a r y

sh ow m pls t r a ffic- e n g t u n n e ls

sh ow m pls t r a ffic- e n g t opology

sh ow ip bgp vpn v4 a ll

pin g vr f wit h sh ow in t e r fa ce t u n n e l
Summary
MPLS VPNs are rapidly gaining popularit y as privat e WAN alt ernat ives. This chapt er present ed
QoS design principles and designs t o achieve end- t o- end service levels over MPLS VPNs.. The
forem ost design principle is t hat ent erprise subscribers and service providers have t o
cooperat ively deploy QoS over MPLS VPNs in a consist ent and com plem ent ary m anner.

Ent erprise ( cust om er) considerat ions, such as class- collapsing guidelines and t raffic- m ixing
principles, were overviewed along wit h re- m arking exam ples.

Service- provider edge QoS policies were present ed for t hree- , four- , and five- class edge m odels.
Addit ionally, det ails on how RFC 3270 t unneling m odes ( Uniform , Short Pipe, and Pipe) can be
im plem ent ed wit hin Cisco I OS Soft ware were provided.

Service provider core QoS opt ions, such as aggregat e bandwidt h overprovisioning or deploying
DiffServ in t he backbone, were considered along wit h plat form - specific considerat ions, such as
MDRR on t he 12000 GSR.

MPLS t raffic engineering was int roduced in brief, and t wo exam ples of MPLS TE for QoS were
present ed ( MPLS per- VPN TE and MPLS DS- TE) .

The chapt er concluded wit h a case- st udy cont inuat ion from previous chapt ers, showing how an
ent erprise t hat is com pliant wit h t he QoS Baseline can m igrat e it s privat e WAN t o an MPLS VPN.
The service provider's QoS designs also were det ailed wit hin t he case st udy.
Further Reading
St andar ds:

RFC 2547, " BGP/ MPLS VPNs" : ht t p: / / www.iet f.org/ rfc/ rfc2547.t xt .

RFC 2597, " Assured Forwarding PHB Group" : ht t p: / / www.iet f.org/ rfc/ rfc2597.t xt .

RFC 2702, " Requirem ent s for Traffic Engineering over MPLS" :
ht t p: / / www.iet f.org/ rfc/ rfc2702.t xt .

RFC 2917, " A Core MPLS I P VPN Archit ect ure" : ht t p: / / www.iet f.org/ rfc/ rfc2917.t xt .

RFC 3270, " Mult iprot ocol Label Swit ching ( MPLS) Support of Different iat ed Services" :
ht t p: / / www.iet f.org/ rfc/ rfc3270.t xt .

RFC 3564, " Requirem ent s for Support of Different iat ed Services- Aware MPLS Traffic
Engineering" : ht t p: / / www.iet f.org/ rfc/ rfc3564.t xt .

Books:

Alwayn, Vivek. Advanced MPLS Design and I m plem ent at ion . I ndianapolis: Cisco Press,
2001.

Pepelnj ak, I van, and Jim Guichard. MPLS and VPN Archit ect ures . Cisco Press, 2002.

Pepelnj ak, I van, Jim Guichard, and Jeff Apcar. MPLS and VPN Archit ect ures. Cisco Press,
2003.

Osborne, Eric, and Aj ay Sim ha. Traffic Engineering wit h MPLS . Cisco Press, 2003.

Cisco MPLS feat ures:

Configuring MPLS and MPLS t raffic engineering ( Cisco I OS Release 12.2) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fswt ch_c/ swprt 3/ xcft agc.h
.

MPLS VPNS ( Cisco I OS Release 12.2.13T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft vpn13.ht m

MPLS DiffServ t unneling m odes ( Cisco I OS Release 12.2.13T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft dt m ode.ht
.

MPLS DiffServ- Aware Traffic Engineering ( DS- TE) ( Cisco I OS Release 12.2.4T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 4/ ft _ds_t e.ht m

MPLS Cisco I OS docum ent at ion m ain link ( Cisco I OS Release 12.3) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios123/ 123cgcr/ swit _vcg.ht m # 999526
Chapter 16. IPSec VPN QoS Design
I PSec VPNs are t he m ost widely deployed VPNs and are found in t hree m ain cont ext s:

Sit e- t o- sit e I PSec VPNs

Teleworker I PSec VPNs

Rem ot e- access client ( m obilit y) I PSec VPNs

QoS considerat ions for sit e- t o- sit e and t eleworker I PSec VPNs are exam ined in t his design
chapt er ( as QoS is rarelyif everdeployed in rem ot e- access client I PSec VPN scenarios) . These
considerat ions include t he following:

I PSec m odes of operat ion

Bandwidt h and delay increases because of encrypt ion

I PSec and cRTP incom pat ibilit y

I P ToS byt e preservat ion t hrough I PSec encrypt ion

QoS and Ant i- Replay int eract ion im plicat ions

Following a discussion of t hese considerat ions, design recom m endat ions for sit e- t o- sit e and
t eleworker ( DSL and cable) solut ions are present ed in det ail.

Whereas MPLS t echnologies provide VPN services, such as net work segregat ion and privacy, by
m aint aining independent virt ual rout er forwarding t ables, I PSec achieves such VPN services
t hrough encrypt ion.

As defined in RFCs 2401 t hrough 2412, I PSec prot ocols provide m echanism s t o enable rem ot e
sit es t o cost effect ively connect t o ent erprise int ranet s or ext ranet s using t he I nt ernet ( or a
service provider's shared I P net works) . Because of I PSec prot ocol encrypt ion, such VPNs can
provide t he sam e m anagem ent and securit y policies as privat e net works.

I PSec VPN services are built by overlaying a point - t o- point m esh over t he I nt ernet using Layer
3encrypt ed t unnels. This archit ect ure requires securit y appliances, such as ( hardware or
soft ware) firewalls or rout ers t hat support I PSec t unnels, t o be inst alled at bot h ends of each
t unnel. Encrypt ion/ decrypt ion is perform ed at t hese t unnel endpoint s, and t he prot ect ed t raffic is
carried across t he shared net work.

Three m ain design cont ext s for I PSec VPNs exist , as shown in Figure 16- 1:

Sit e - t o- sit e VPN s Tunnels are m aint ained by hardware devices t o connect m ult iple users
at rem ot e branches t o ( one or m ore) cent ral sit es.

Te le w or k e r VPN s Tunnels are m aint ained by hardware devices t o connect ( t ypically) a

single user at his or her residence t o a cent ral sit e.
 Re m ot e - a cce ss clie n t s Tunnels are est ablished by soft ware t o connect m obile users at
airport s, hot els, or sim ilar places t o a cent ral sit e using WLAN hot spot s, LAN port s, or
m odem s.

Figu r e 1 6 - 1 . I PSe c VPN D e sign Con t e x t s

Enabling converged services, such as voice and video, on an I PSec VPN has been dubbed V3PN.
V3PN is essent ially t he overlaying of QoS t echnologies over I PSec VPNs t o provide t he required
service levels t o voice and video applicat ions. As such, V3PN solut ions relat e t o only t wo of t he
t hree I PSec VPN design cont ext s: sit e- t o- sit e VPNs and t elecom m ut er VPNs. ( Lit t le, if any, QoS
is available in rem ot e- access client net works.)

This chapt er discusses QoS design considerat ions and recom m endat ions for bot h sit e- t o- sit e and
t elecom m ut er V3PN solut ions.

N ot e
I t is beyond t he scope of t his chapt er t o det ail I PSec encrypt ion operat ion and
configurat ion; a working knowledge of I PSec is assum ed.
Site-to-Site V3PN QoS Considerations
At t ract ive pricing is usually t he driver behind deploying sit e- t o- sit e I PSec VPNs as an alt ernat ive
t o privat e WAN t echnologies. Many of t he sam e considerat ions required by privat e WANs need t o
be t aken int o account for I PSec VPN scenarios because t hey usually are deployed over t he sam e
Layer 2 WAN access m edia.

I PSec VPNs also share som e sim ilar concerns wit h MPLS VPNs. For inst ance, t he ent erprise's
end- t o- end delay and j it t er budget s depend significant ly on t he service provider's SLAs.
Therefore, ent erprises deploying V3PN solut ions are recom m ended t o ut ilize Cisco Powered
Net work I P Mult iservice service providers, as discussed in Chapt er 15, " MPLS VPN QoS Design."

However, I PSec VPNs present m any unique considerat ions for QoS design, including t he
following ( each is discussed in det ail t hroughout t he rest of t he chapt er) :

I PSec VPN m odes of operat ion

Packet overhead increases because of encrypt ion

cRTP and I PSec incom pat ibilit y

Prefragm ent at ion

Bandwidt h provisioning

Logical t opologies

Delay budget increases because of encrypt ion

ToS byt e preservat ion

QoS Pre- Classify feat ure

Pre- encrypt ion queuing

Ant i- Replay im plicat ions

Cont rol plane provisioning

IPSec VPN Modes of Operation

Three principal m odes of I PSec VPN operat ion exist :

I PSe c t u n n e l m ode No I P GRE t unnel

I PSe c t r a n spor t m ode Encrypt ing an I P GRE t unnel

I PSe c t u n n e l m ode Encrypt ing an I P GRE t unnel

The advant ages, disadvant ages, feat ures, and lim it at ions of t hese opt ions are discussed next .
IPSec Tunnel Mode (No IP GRE Tunnel)

This opt ion does not ut ilize an I P GRE t unnel. Wit h t his opt ion, only I PSec unicast t raffic can be
t ransport ed. ( I P m ult icast t raffic cannot be t ransport ed bet ween I PSec peers wit hout configuring
an I P GRE t unnel.)

This configurat ion m ight be sufficient t o support applicat ion requirem ent s; it s advant age lies in
lower CPU overhead ( prim arily at t he headend I PSec VPN rout er) com pared wit h alt ernat ive
I PSec design opt ions.

I PSec securit y associat ions ( SAs) are creat ed for each access list line m at ched. An access list
m ust be specified in t he crypt o m ap t o designat e packet s t hat are t o be encrypt ed. Such an
access list t ypically ent ails several lines t o define t he applicat ion( s) t o be encrypt ed by t he five
ACL t uples: source/ dest inat ion I P address, prot ocol, and source/ dest inat ion port num bers. When
not encrypt ing a GRE t unnel, it is possible t o creat e a separat e SA for each applicat ion or access-
list line m at ch or t o creat e an SA t hat carries all t raffic t hat m at ches an ACL range ( which is
recom m ended) . Each SA has it s own Encrypt ion Securit y Prot ocol ( ESP) or Aut hent icat ion
Header ( AH) sequence num ber.

Ant i- Replay drops can be elim inat ed or m inim ized by const ruct ing access list s t hat creat e a
separat e securit y associat ion for each class of t raffic being influenced by per- hop QoS policies.
( Ant i- Replay is an I PSec st andard feat ure t hat discards packet s t hat fall out side a receiver's 64-
byt e sliding window because such packet s are considered suspect or pot ent ially com prom isedit is
discussed in great er det ail lat er in t his chapt er.)

The Cisco I OS feat ure of prefragm ent at ion for I PSec VPNs ( also discussed lat er in t his chapt er) is
support ed in I PSec t unnel m ode ( no I P GRE t unnel) as of Cisco I OS Release 12.2( 12) T.

IPSec Transport Mode (Encrypting an IP GRE Tunnel)

I PSec t ransport m ode ( encrypt ing an I P GRE t unnel) is a com m only deployed opt ion because it
provides all t he advant ages of using I P GRE, such as I P Mult icast prot ocol support ( and, t hus,
also t he support of rout ing prot ocols t hat ut ilize I P Mult icast ) and m ult iprot ocol support .
Furt herm ore, t his opt ion saves 20 byt es per packet over I PSec t unnel m ode ( encrypt ing an I P
GRE t unnel) because an addit ional I P header is not required. Figure 16- 2 illust rat es I PSec
t ransport m ode versus t unnel m ode when encrypt ion is perform ed in an I P GRE t unnel.

Figu r e 1 6 - 2 . I PSe c Tr a n spor t M ode Ve r su s Tu n n e l M ode for a G.7 2 9

VoI P Pa ck e t

[View full size image]

The I PSec peer I P addresses and t he I P GRE peer address m ust m at ch for t ransport m ode t o be
negot iat ed; if t hey do not m at ch, t unnel m ode is negot iat ed.

The Cisco I OS prefragm ent at ion feat ure for I PSec VPNs ( discussed lat er in t he chapt er) is not
support ed for t ransport m ode because t he decrypt ing rout er cannot det erm ine whet her t he
fragm ent at ion was done before or aft er encrypt ion ( for exam ple, by a downst ream rout er
bet ween t he encrypt ing and decrypt ing rout ers) .

Alt hough I PSec t ransport m ode saves a sm all t o m oderat e am ount of link bandwidt h, it does not
provide any reduct ion in packet s per second swit ched by t he rout er. Therefore, because t he
num ber of packet s per second prim arily affect s CPU perform ance, no significant CPU
perform ance gain is realized by using I PSec t ransport m ode.

I PSec t unnel m ode is t he default configurat ion opt ion. To configure t ransport m ode, it m ust be
specified under t he I PSec t ransform set , as shown in Exam ple 16- 1.

Ex a m ple 1 6 - 1 . En a blin g I PSe c Tr a n spor t M ode

!
crypto ipsec transform-set ENTERPRISE esp-3des esp-sha-hmac
mode transport ! Enables IPSec Transport mode
!

IPSec Tunnel Mode (Encrypting an IP GRE Tunnel)

I PSec t unnel m ode ( encrypt ing an I P GRE t unnel) is t he prim arily recom m ended I PSec VPN
design opt ion. Alt hough it incurs t he great est header overhead of t he t hree opt ions, it is capable
of support ing I P Mult icast ( wit h t he capabilit y t o run a dynam ic rout ing prot ocol wit hin t he I P
GRE t unnel for failover t o an alt ernat ive pat h) , and it support s prefragm ent at ion for I PSec VPNs.

When configured wit h a rout ing prot ocol running wit hin an I P GRE t unnel, t he rout ing prot ocol's
Hello packet s m aint ain t he securit y associat ions bet ween t he branch and bot h ( assum ing a
redundant configurat ion) headend rout ers. There is no need t o creat e a securit y associat ion wit h
a backup headend peer if t he prim ary peer fails.

N ot e
The design principles in t his chapt er were proven by scalabilit y t est ing in t he Cisco
Ent erprise Solut ions Engineering labs. These large- scale t est ing m et hods were
designed t o t est worst - case scenarios. From a design st andpoint , t hese ent ailed
enabling t he following:

St rong Triple- Digit al Encrypt ion St andard ( 3DES) encrypt ion for bot h I nt ernet Key
Exchange ( I KE) and I PSec

I P GRE wit h I PSec t unnel m ode

Diffie- Hellm an Group 2 ( 1024 bit ) for I KE

 Secure Hash Algorit hm ( SHA) 160- bit RFC 2104 Keyed- Hashing for Message
Aut hent icat ion ( HMAC) wit h RFC 1321 Message Digest 5 ( MD5)

( MD5) - HMAC ( bot h hash algorit hm s t runcat ed t o 12 byt es in t he ESP packet

t railer)

Preshared keys

I f an ent erprise chooses t o im plem ent less st ringent securit y param et ers, t o use I PSec
t ransport m ode inst ead of t unnel m ode, or t o not im plem ent I P GRE t unnels, t he
designs cont inue t o be applicable from funct ional and scalabilit y st andpoint s.

Packet Overhead Increases

The addit ion of t unnel headers and encrypt ion overhead increases t he packet sizes of all
encrypt ed applicat ions: voice, video, and dat a. This needs t o be t aken int o account when
provisioning LLQ or CBWFQ bandwidt h t o a given class.

For exam ple, consider voice. The t wo m ost widely deployed codecs for voice are G.711 and
G.729. Each codec t ypically is deployed at 50 pps ( generat ing 20- m s packet izat ion int ervals) .

The Layer 3 dat a rat e for a G.711 call ( at 50 pps) is 80 kbps. I P Generic Rout ing Encapsulat ion
( GRE) t unnel overhead adds 24 byt es per packet . The I PSec Encapsulat ing Securit y Payload
( ESP) adds anot her 56 byt es. The com bined addit ional overhead increases t he rat e from 80 kbps
( clear voice) t o 112 kbps ( I PSec ESP t unnel- m ode encrypt ed voice) .

The calculat ion is as follows:

200 byt es per packet ( G.711 voice)

24 byt es per packet ( I P GRE overhead)

+ 56 byt es per packet ( I PSec ESP overhead)

________
280 byt es per packet

x 8 bit s per byt e

________
2240 bit s per packet

x 50 packet s per second

________
112,000 bit s per second

The addit ional overhead represent s a 40 percent increase in t he bandwidt h required for an
encrypt ed G.711 call.

The 280- byt e packet 's header, dat a, and t railer fields for an I PSec t unnel- m ode ESP encrypt ed
G.711 call are shown in Figure 16- 3.
 Figu r e 1 6 - 3 . An a t om y of a n I PSe c- En cr ypt e d G.7 1 1 Pa ck e t

[View full size image]

The Layer 3 dat a rat e for a G.729 call ( at 50 pps) is 24 kbps. I P GRE t unnel overhead adds 24
byt es per packet . I PSec ESP adds anot her 52 byt es. The com bined addit ional overhead increases
t he rat e from 24 kbps ( clear voice) t o j ust less t han 56 kbps ( I PSec ESP t unnel- m ode encrypt ed
voice) .

The calculat ion is as follows:

60 byt es per packet ( G.729 voice)

24 byt es per packet ( I P GRE overhead)

+ 52 byt es per packet ( I PSec ESP overhead)

________

136 byt es per packet

x 8 bit s per byt e

________

1088 bit s per packet

x 50 packet s per second

________

54,400 bit s per second

The addit ional overhead represent s a 227 percent increase in t he bandwidt h required for an
encrypt ed G.729 call.

The 136- byt e packet 's header, dat a, and t railer fields for an I PSec t unnel- m ode ESP encrypt ed
G.729 call are shown in Figure 16- 4.
 Figu r e 1 6 - 4 . An a t om y of a n I PSe c- En cr ypt e d G.7 2 9 Pa ck e t

[View full size image]

I t is im port ant t o not e t hat t hese bandwidt h allocat ions are Layer 3 bandwidt h requirem ent s and
do not include Layer 2 overhead ( which is m edia dependent ) . Therefore, Layer 2 overhead needs
t o be added on t op of t he Layer 3 requirem ent s in provisioning LLQ and CBWFQ bandwidt h. This
is illust rat ed in Figure 16- 5, where Et hernet overhead ( Et hernet plus 802.1Q t runking) and
Fram e Relay overhead are added and rem oved from t he packet in t ransit .

Figu r e 1 6 - 5 . Pa ck e t Size Ch a n ge s of a G.7 2 9 I PSe c- En cr ypt e d Pa ck e t

[View full size image]

Key Layer 2 overhead values are reit erat ed in Table 16- 1 .

 Ta ble 1 6 - 1 . La ye r 2 En ca psu la t ion Ove r h e a d

L2 En ca psu la t ion Ove r h e a d

Et hernet 14 byt es ( + 4 for 802.1Q)

Fram e Relay 4 byt es ( + 4 for FRF.12)

MLP 10 byt es ( + 3 for MLP LFI )

ATM 5 byt es per 53- byt e cell + cell padding
( variable)

Therefore, t he calculat ion, inclusive of Layer 2 overhead, is as follows. This exam ple assum es
t hat a G.729 call will be encrypt ed over a slow speed ( 768- kbps Fram e Relay link) , which
requires FRF.12 fragm ent at ion and int erleaving.

60 byt es per packet ( G.729 voice)

24 byt es per packet ( I P GRE overhead)

52 byt es per packet ( I PSec ESP overhead)

4 byt es per packet ( FR overhead)

+ 4 byt es per packet ( FRF.12 overhead)

________
44 byt es per packet

x 8 bit s per byt e

________
1152 bit s per packet

x 50 packet s per second

________
57,600 bit s per second ( rounded up t o 58 kbps)

I n sum m ary, it is im port ant always t o include Layer 2 overhead in accurat e bandwidt h
provisioning for I PSec- encrypt ed applicat ions.

cRTP and IPSec Incompatibility

The significant increases in bandwidt h required by I PSec encrypt ion lead m any adm inist rat ors t o
consider t he use of I P RTP header com pression ( cRTP) t o offset t hese increases.

However, one of t he caveat s of encrypt ion is t hat key port ions of t he original I P packet t hat
could be referenced for QoS ( and ot her) purposes are no longer readable. Such is t he case wit h
cRTP.

cRTP and I PSec are inherent ly incom pat ible st andards. The original I P/ UDP/ RTP header already
is encrypt ed by I PSec by t he t im e t he RTP com pressor is called upon t o perform t he
com pression. Therefore, because cRTP cannot associat e t he encrypt ed I P/ UDP/ RTP packet wit h a
known m edia st ream , com pression cannot occur and cRTP bandwidt h savings cannot be realized.
The encrypt ed I P/ UDP/ RTP packet sim ply bypasses t he com pression process and cont inues
( uncom pressed) t o t he t ransm it queue.

This is illust rat ed in Figure 16- 6.

Figu r e 1 6 - 6 . I PSe c a n d cRTP I n com pa t ibilit y

[View full size image]

I t is im port ant t o recognize t hat cRTP funct ions on a hop- by- hop basis, whereas I PSec can span
m ult iple int erm ediat e ( Layer 3) hops bet ween I PSec endpoint s. This dist inct ion furt her
exacerbat es incom pat ibilit y bet ween t he feat ures.

Alt hough developm ent s are under way t o address t hese incom pat ibilit ies, at t he t im e of t his
writ ing, cRTP cannot be ut ilized t o achieve bandwidt h savings in an I PSec VPN environm ent .

Prefragmentation
A problem arises when a packet is nearly t he size of t he m axim um t ransm ission unit ( MTU) of
t he out bound link of t he encrypt ing rout er and t hen is encapsulat ed wit h I PSec headers.

The result ing packet is likely t o exceed t he MTU of t he out bound link. This causes packet
fragm ent at ion aft er encrypt ion, which m akes t he decrypt ing rout er reassem ble in t he process
pat h.

Cisco I OS Release 12.2( 13) T int roduced a new feat ure: prefragm ent at ion for I PSec VPNs.
Prefragm ent at ion increases t he decrypt ing rout er's perform ance by enabling it t o operat e in t he
high- perform ance CEF pat h inst ead of t he process pat h.

This feat ure enables an encrypt ing rout er t o predet erm ine t he encapsulat ed packet size from
inform at ion available in t ransform set s, which are configured as part of t he I PSec securit y
associat ion. I f it is predet erm ined t hat t he packet will exceed t he MTU of t he out put int erface,
t he packet is fragm ent ed before encrypt ion. This funct ion avoids process- level reassem bly
before decrypt ion and helps im prove decrypt ion perform ance and overall I PSec t raffic
t hroughput .
Prefragm ent at ion for I PSec VPNs is enabled globally by default for Cisco VPN rout ers running
Cisco I OS Release 12.2( 13) T or higher.

Bandwidth Provisioning
Chapt er 2, " QoS Design Overview," present ed t he 33 Percent LLQ Rule, along wit h t he design
rat ionale behind t he recom m endat ion. Furt herm ore, t he rule was expressed as a conservat ive
design recom m endat ion t hat m ight not be valid under all const raint s. Provisioning for VoI P over
I PSec on slow links som et im es poses const raint s t hat m ight preclude applying t he 33 Percent
LLQ Rule.

As shown in Table 16- 2 , t he percent age of LLQ required on 64- , 128- , and 256- kbps links for a
single encrypt ed G.729 call exceeds t he recom m ended 33 percent LLQ lim it . Ent erprises
considering such deploym ent s m ust recognize t he im pact on dat a t raffic t raversing such links
when encrypt ed voice calls were m adespecifically, dat a applicat ions would slow down
significant ly. I f t hat is considered an accept able t rade- off, not m uch can be said or done.
Ot herwise, it is recom m ended t o increase bandwidt h t o t he point t hat encrypt ed VoI P calls can
be m ade and st ill fall wit hin t he 33 percent bandwidt h recom m endat ion for priorit y queuing.

Ta ble 1 6 - 2 . G.7 2 9 Ca lls by Lin k Spe e ds ( FRF.1 2 I s

En a ble d on Lin k Spe e ds 7 6 8 k bps On ly)

M a x im u m
Lin e Ra t e N u m be r LLQ Ba n dw idt h LLQ Ba n dw idt h
( k bps) of G.7 2 9 Ca lls ( k bps) ( Pe r ce n t a ge )

64 ( FRF.12) 1 ( 58 kbps) 58 91%

128 ( FRF.12) 1 ( 58 kbps) 58 46%

256 ( FRF.12) 2 ( 58 kbps) 116 46%

512 ( FRF.12) 3 ( 58 kbps) 174 34%

768 ( FRF.12) 4 ( 58 kbps) 232 31%

1024 6 ( 56 kbps) 336 33%

1536 9 ( 56 kbps) 504 33%

2048 12 ( 56 kbps) 672 33%

When planning t he bandwidt h required for a branch office, consider t he num ber of concurrent
calls t raversing t he I PSec VPN t hat t he branch is expect ed t o m ake during peak call periods. This
varies based on t he j ob funct ion of t he em ployees locat ed at a branch. For exam ple, an office of
soft ware engineers would be expect ed t o m ake fewer calls t han an office of t elem arket ers. A
t ypical act ive call rat io m ay be one act ive call for every six people ( 1: 6) , but t his could range
from 1: 4 or 1: 10, depending on t he j ob funct ion of t he em ployees. Given t he 512- kbps link from
Table 16- 2 as an exam ple, wit h a t arget of 3 G.729 calls, t his link t heoret ically could support a
branch office of bet ween 12 and 30 people. As wit h all ot her t opologies, call adm ission cont rol
m ust be adm inist ered properly t o correspond t o t he QoS policies deployed wit hin t he net work
infrast ruct ure.
 N ot e
Alt hough VoI P has been discussed as a prim ary exam ple of bandwidt h provisioning
considerat ions when deploying QoS over I PSec VPNs, it is im port ant t o recognize t hat
VoI P is not t he only applicat ion t hat m ight require such considerat ions; t his exercise
needs t o be perform ed for any applicat ion t hat is being encrypt ed.

Unlike VoI P, however, ot her applicat ionssuch as video and dat ahave varying packet
rat es and sizes. Therefore, crisp provisioning form ulas m ight not apply. Moderat e
t raffic analysis and best guesses, along wit h t rial- and- error t uning, are usually t he only
opt ions for fact oring bandwidt h provisioning increases for non- VoI P applicat ions.

Logical Topologies
Sim ilar t o privat e WANs, but unlike fully m eshed MPLS VPNs, I PSec VPNs t ypically are deployed
in a ( logical) hub- and- spoke t opology.

The QoS im plicat ions of hub- and- spoke t opologies include t hat access rat es t o rem ot e sit es need
t o be const rained and shaped at t he hub, t o avoid delays and drops wit hin t he provider's cloud.
Shaping at t he I PSec VPN hub is done in a m anner sim ilar t o t hat of privat e WAN NBMA m edia,
such as Fram e Relay or ATM. Refer t o t he " Headend VPN Edge QoS Opt ions for Sit e- t o- Sit e
V3PNs" sect ion, lat er in t his chapt er, and also t o Chapt er 13, " WAN Aggregat or QoS Design," for
addit ional det ails.

I PSec VPNs are not lim it ed t o hub- and- spoke designs. They also can be deployed in part ial- m esh
or even fully m eshed t opologies. I n such cases, shaping is recom m ended on any links where
speed m ism at ches occur ( sim ilar t o privat e WAN scenarios) .

Anot her alt ernat ive is t o deploy I PSec VPNs via Dynam ic Mult ipoint Virt ual Privat e Net works
( DMVPN) , which est ablish sit e- t o- sit e I PSec t unnels as needed and t ear t hem down when t hey
no longer are required. As wit h t he previously discussed logical t opologies, shaping is required
on DMVPN NBMA links wit h speed m ism at ches. Specifically, shapers are required t o be creat ed
dynam ically and applied t o logical DMVPN t unnels t o offset any speed m ism at ches at t ribut ed t o
phy sical NMBA links. However, as of t he t im e of t his writ ing, no shaping or queuing solut ion
exist s t o guarant ee QoS SLAs over DMVPN t opologies ( alt hough Cisco I OS solut ions current ly are
being evaluat ed and are in developm ent ) .

Delay Budget Increases

As previously discussed, t he delay budget for a t ypical I P Telephony im plem ent at ion includes
fixed and variable com ponent s. The I TU G.114 specificat ion's t arget value for one- way delay is
150 m s. I n an I PSec VPN deploym ent , however, t wo addit ional delay com ponent s m ust be
fact ored int o t he overall delay budget :

Encrypt ion delay at t he originat ion point of t he I PSec VPN t unnel

Decrypt ion delay at t he t erm inat ion point of t he I PSec VPN t unnel

Perform ance and scalabilit y t est ing result s suggest t hat , in m ost cases, t he addit ional delay
caused by encrypt ion and decrypt ion is approxim at ely 4 t o 10 m s ( com bined) . These increm ent al
delays are shown in Figure 16- 7.

Figu r e 1 6 - 7 . I PSe c En cr ypt ion / D e cr ypt ion I n cr e m e n t a l D e la ys

[View full size image]

A conservat ive planning est im at e would be 10 m s for encrypt ion delay and 10 m s for decrypt ion
delay.

This delay m ight not seem significant for a cam pus- t o- branch call ( hub- t o- spoke) , but t he delay
m ight be m ore relevant in branch- t o- branch ( spoke- t o- spoke) scenarios because encrypt ion and
decrypt ion m ight occur t wice ( depending on t he logical t opology of t he VPN) . This is illust rat ed in
Figure 16- 8.

Figu r e 1 6 - 8 . I PSe c VPN Spok e - t o- Spok e En cr ypt ion / D e cr ypt ion D e la ys

 N ot e
Not only do encrypt ion delays need t o be fact ored int o spoke- t o- spoke I PSec VPN
scenarios, but queuing and serializat ion delays for bot h legs of t he t unnel do as well
( as t hey also would in privat e WAN spoke- t o- spoke scenarios) .

ToS Byte Preservation

For t he m aj orit y of QoS designs discussed t hus far, classificat ion is perform ed based on DSCP
m arkings in t he ToS byt e of t he I P packet . However, when an I P packet is encrypt ed t hr ough
I PSec, t he original ToS byt e values also are encrypt ed and, t hus, unusable by QoS m echanism s
t hat process t he packet ( post encrypt ion) .

To overcom e t his predicam ent , t he I PSec prot ocol st andards inherent ly have provisioned t he
capabilit y t o preserve t he ToS byt e inform at ion of t he original I P header by copying it t o t he I P
headers added by t he t unneling and encrypt ion process.

As shown in Figure 16- 9, t he original I P ToS byt e values are copied init ially t o t he I P header
added by t he GRE encapsulat ion. Then t hese values are copied again t o t he I P header added by
I PSec encrypt ion.

Figu r e 1 6 - 9 . I P ToS Byt e Pr e se r va t ion

[View full size image]

This process com pensat es for t he fact t hat t he original I P header ( including t he ToS byt e) is
act ually unreadable ( because of encrypt ion) and allows t he packet t o be processed by ( post
encrypt ion) QoS m echanism s in t he sam e m anner as any ot her packet .

Addit ionally, t his process underscores t he im port ance of ensuring t hat t he encrypt ed t raffic is
m arked properly ( at Layer 3) before encrypt ion.

QoS Pre-Classify
The QoS Pre- Classify feat ure oft en is confused wit h ToS byt e preservat ion. QoS Pre- Classify is a
Cisco I OS feat ure t hat allows for packet s t o be classified on header param et ers ot her t han ToS
byt e values aft er encrypt ion.

Because all original packet header fields are encrypt ed, including source or dest inat ion I P
addresses, Layer 4 prot ocol, and source or dest inat ion port addresses, post - encrypt ion QoS
m echanism s cannot perform classificat ion against crit eria specified wit hin any of t hese fields.

A solut ion t o t his const raint is t o creat e a clone of t he original packet 's headers before
encrypt ion. The crypt o engine encrypt s t he original packet , and t hen t he clone is associat ed wit h
t he newly encrypt ed packet and sent t o t he out put int erface. At t he out put int erface, any QoS
decisions based on header crit eria, except for ToS byt e valueswhich have been preservedcan be
perform ed by m at ching on any or all of t he five access- list t uple values of t he clone. I n t his
m anner, advanced classificat ion can be adm inist ered even on encrypt ed packet s. The process is
illust rat ed in Figure 16- 10.

Figu r e 1 6 - 1 0 . QoS Pr e - Cla ssify Fe a t u r e Ope r a t ion

[View full size image]

A key point t o rem em ber regarding QoS Pre- Classify is t hat it is applicable only at t he encrypt ing
rout er's out put int erface. The fields preserved by QoS Pre- Classify are not available t o any
rout ers downst ream ; t he clone never leaves t he rout er perform ing t he encrypt ion, t hus ensuring
t he int egrit y and securit y of t he I PSec VPN t unnel.

QoS Pre- Classify is support ed in all Cisco I OS swit ching pat hs and is recom m ended t o be
enabled on som e plat form s even when only t he ToS byt e values are being used for classificat ion.
Test ing has shown t hat when hardware- based encrypt ion cards are com bined wit h QoS, t he
Cisco I OS Soft ware im plem ent at ion of t he QoS Pre- Classify feat ure slight ly enhances
perform ance, even when m at ching only on ToS byt e values. Furt herm ore, enabling QoS Pre-
Classify by default elim inat es t he possibilit y t hat it s configurat ion will be overlooked if t he QoS
policy lat er is changed t o include m at ching on I P addresses, port s, or prot ocols.

Design recom m endat ions for t he QoS Pre- Classify feat ure can be sum m arized as follows:

Enable QoS Pre- Classify on all branch I PSec VPN rout ers t hat support t he feat ure.

Enable QoS Pre- Classify on headend I PSec VPN rout ers only when bot h t he VPN t erm inat ion
and QoS policies reside on t he sam e device.

Pre-Encryption Queuing
The hardware crypt o engine wit hin a Cisco VPN rout er's chassis can be viewed as an int ernal
int erface t hat processes packet s for encrypt ion or decrypt ion.

Before Cisco I OS Release 12.2( 13) T, packet s t o be encrypt ed were handed off t o t he crypt o
engine in a first - in- first - out ( FI FO) basis. No dist inct ion was m ade bet ween voice packet s and
dat a packet s. The FI FO queuing for crypt o engines is illust rat ed in Figure 16- 11.

Figu r e 1 6 - 1 1 . FI FO Cr ypt o En gin e QoS

Consider a Cisco 2651XM rout er deployed at a branch sit e configured wit h a full- duplex Fast
Et hernet int erface, a Serial E1 int erface ( also full duplex) , and an AI M- BP encrypt ion accelerat or.
The Fast Et hernet int erface connect s t o t he branch's LAN, and t he serial int erface connect s t o t he
I nt ernet . These fact ors could lim it t hroughput ( causing a bot t leneck) in t his scenario:

The clock rat e of t he slowest int erface ( in bit s per secondin t his case, 2 Mbps t ransm it t ed
or 2 Mbps received over t he E1 int erface)

The packet - forwarding rat e of t he rout er's m ain CPU ( in packet s per second)

The crypt o engine encrypt ion/ decrypt ion rat e ( in packet s per second)

The perform ance charact erist ics of t hese it em s furt her are influenced by t he t raffic m ix, including
t he rat es and sizes of t he I P packet s being swit ched t hrough t he rout er and t he configured Cisco
I OS swit ching pat h ( process- swit ched, fast - swit ched, or CEF- swit ched) .

N ot e
I n m ost hardware plat form s, t he packet s- per- second capabilit ies of t he rout er are
m ore im port ant for planning purposes t han bit s per second swit ched t hrough t he
rout er. For exam ple, if t he average packet size of packet s swit ched t hrough t he rout er
increases from 128 byt es t o 256 byt es, t he packet - per- second capabilit ies of t he m ain
CPU are not necessarily cut in half.

The cont rol plane requirem ent s also fact or int o t he CPU's ut ilizat ion. These requirem ent s are
det erm ined by t he rout ing prot ocol( s) in use, t he num ber of rout es in t he rout ing t able, t he
overall net work st abilit y, and any redist ribut ion requirem ent s. Managem ent requirem ent s such
as NTP and SNMP also add t o t he CPU t ax. Addit ionally, Cisco I OS HA, QoS, m ult icast , and
securit y feat ures all consum e CPU resources and m ust be t aken int o account .

Anot her fact or in t he equat ion is t he rat io of packet s swit ched t hrough ( and originat ed by) t he
rout er in relat ion t o t he num ber of packet s select ed by t he crypt o m ap's access list for
encrypt ion or decrypt ion. I f an I P GRE t unnel is being encrypt ed, t his t ends t o be a large
percent age of encrypt ed packet s t o t ot al packet s; if an I P GRE t unnel is not being encrypt ed, t he
rat io could be quit e sm all.

Hardware crypt o engines can becom e congest ed when t heir packet - processing capabilit ies are
less t han t hose of t he rout er's m ain CPU and int erface clock speeds. I n such a case, t he crypt o
engine becom es a bot t leneck, or a congest ion point . The crypt o engine m ight be oversubscribed
on eit her a m om ent ary or ( worse case) sust ained basis. Such int ernal precrypt o congest ion
could affect t he qualit y of real- t im e applicat ions, such as VoI P.

Cisco int ernal t est ing and evaluat ion has shown it t o be ext rem ely difficult for condit ions t o arise
t hat cause hardware crypt o engine congest ion. I n nearly all cases, t he Cisco VPN rout er
plat form 's m ain CPU is exhaust ed before reaching t he lim it of t he crypt o engine's packet -
processing capabilit ies.

Nevert heless, Cisco provides a solut ion t o t his pot ent ial case of congest ion in t he rare event t hat
a hardware crypt o engine is overwhelm ed so t hat VoI P qualit y will be preserved. This feat ure,
low- lat ency queuing ( LLQ) for I PSec encrypt ion engines, was int roduced in Cisco I OS Release
12.2( 13) T.

The LLQ for Crypt o Engine feat ure provides a dual- input queuing st rat egy for packet s being sent
t o t he crypt o engine:

A priorit y or low- lat ency queue

A best - effort queue

This feat ure is t arget ed at alleviat ing any effect s of m om ent ary or sust ained oversubscript ion of
t he hardware crypt o engines t hat could result in priorit y t raffic ( such as voice and video)
experiencing qualit y issues. This feat ure is illust rat ed in Figure 16- 12.

Figu r e 1 6 - 1 2 . LLQ ( D u a l- FI FO) Cr ypt o En gin e QoS

N ot e
Because soft ware- based crypt o adds unaccept able lat ency and j it t er, t here are no
plans t o incorporat e t his feat ure for soft ware crypt o. Hardware accelerat ors for I PSec
encrypt ion are highly recom m ended.

The classificat ion com ponent t o segregat e t raffic bet ween t he priorit y ( LLQ) queue and t he best -
effort queue is based on t he MQC service policy on t he out put int erface( s) .

No addit ional configurat ion is required t o enable LLQ for crypt o engines; it is enabled int ernally
by t he presence of a service policy wit h an LLQ pr ior it y com m and t hat is applied t o an out put
int erface of an I PSec VPN rout er.

Traffic specified in t he service policy t o be assigned t o t he int erface's priorit y queue ( LLQ)
aut om at ically is sent t o t he crypt o engine's LLQ. Traffic included in any CBWFQ bandwidt h
classes ( including t he default class) aut om at ically is assigned t o t he crypt o engine's best - effort
queue.

I t is possible t o configure different service policies, each wit h different t raffic assigned t o an LLQ,
on different int erfaces. For exam ple, perhaps voice is assigned t o t he LLQ of Serial1/ 0 and video
is assigned t o t he LLQ of an ATM PVC. Assum ing t hat bot h voice and video are t o be encrypt ed,
t he quest ion arises, which t ype of t raffic ( voice or video) will be assigned t o t he crypt o engine's
LLQ?

Because t he crypt o engine act s like a single int erface inside t he VPN rout er, encrypt ing and
decrypt ing all out bound and inbound t raffic st ream s for each int erface on which crypt o is
applied, in t he case of m ult iple service policies ( on different int erfaces) t he crypt o engine m aps
all int erface priorit y queues ( LLQ) t o it s LLQ and all ot her queues t o it s best - effort queue.
Therefore, bot h voice and video would be assigned t o t he crypt o engine's LLQ.

I n short , t he LLQ for Crypt o Engine feat ure ensures t hat if packet s are dropped by m om ent ary or
sust ained congest ion of t he crypt o engine, t he dropped packet s will be of appropriat ely lower
priorit y ( not VoI P packet s) .

Alt hough t he feat ure is enabled by t he presence of a service policy wit h an LLQ pr ior it y
st at em ent , as wit h int erface queuing it self, crypt o- engine queuing does not act ually engage
priorit izat ion t hrough t he dual- FI FO queuing st rat egy unt il t he crypt o engine it self experiences
congest ion.

The LLQ for Crypt o Engine feat ure in Cisco I OS Soft ware is not a prerequisit e for deploying QoS
for I PSec VPN im plem ent at ions in a high- qualit y m anner. As indicat ed previously, int ernal Cisco
evaluat ions have found it ext rem ely difficult t o produce net work t raffic condit ions t hat result ed in
VoI P qualit y suffering because of congest ion of t he hardware crypt o engine.

I n general, t he LLQ for Crypt o Engine feat ure offers t he m ost benefit under one of t he following
condit ions:

When im plem ent ing Cisco I OS VPN rout er plat form s t hat have a relat ively high am ount of
m ain CPU resources relat ive t o crypt o engine resources ( t hese vary depending on t he
fact ors out lined earlier in t his discussion) .

When t he net work experiences a periodic or sust ained burst of large packet s ( for exam ple,
for video applicat ions) .

To sum m arize, high- qualit y I PSec VPN deploym ent s are possible t oday wit hout t he LLQ for
Crypt o Engine feat ure in Cisco I OS soft ware. The addit ion of t his feat ure in Cisco I OS soft ware
furt her ensures t hat high- priorit y applicat ions, such as voice and video, can operat e in a high-
qualit y m anner even under harsh net work condit ions.

Anti-Replay Implications
I PSec offers inherent m essage- int egrit y m echanism s t o provide a m eans t o ident ify whet her an
individual packet is being replayed by an int ercept or or hacker. This concept is called
connect ionless int egrit y. I PSec also provides for a part ial sequence int egrit y, prevent ing t he
arrival of duplicat e packet s. These concept s are out lined in RFC 2401, " Securit y Archit ect ure for
t he I nt ernet Prot ocol."

When ESP aut hent icat ion ( e sp- sh a - h m a c) is configured in an I PSec t ransform set , for each
securit y associat ion, t he receiving I PSec peer verifies t hat packet s are received only once.
Because t wo I PSec peers can send m illions of packet s, a 64- packet sliding window is
im plem ent ed t o bound t he am ount of m em ory required t o t ally t he receipt of a peer's packet s.
Packet s can arrive out of order, but t hey m ust be received wit hin t he scope of t he window t o be
accept ed. I f t hey arrive t oo lat e ( out side t he window) , t hey are dropped.

The operat ion of t he Ant i- Replay window prot ocol is as follows:

 1 . The sender assigns a unique sequence num ber ( per securit y associat ion) t o encrypt ed
packet s.

2 . The receiver m aint ains a 64- packet sliding window, t he right edge of which includes t he
highest sequence num ber received. I n addit ion, a Boolean variable is m aint ained t o
indicat e whet her each packet in t he current window was received.

3 . The receiver evaluat es t he received packet 's sequence num ber:

- I f a received packet 's sequence num ber falls wit hin t he window and was not
received previously, t he packet is accept ed and m arked as received.

- I f t he received packet 's sequence num ber falls wit hin t he window and previously
was received, t he packet is dropped and t he replay error count er is increm ent ed.

- I f t he received packet 's sequence num ber is great er t han t he highest sequence in
t he window, t he packet is accept ed and m arked as received, and t he sliding window
is m oved " t o t he right ."

- I f t he received packet 's sequence num ber is less t han t he lowest sequence in t he
window, t he packet is dropped and t he replay error count er is increm ent ed.

I n a converged I PSec VPN im plem ent at ion wit h QoS enabled, lower- priorit y packet s are delayed
so t hat higher- priorit y packet s receive preferent ial t reat m ent . This has t he unfort unat e side
effect of reordering t he packet s t o be out of sequence from an I PSec Ant i- Replay sequence
num ber perspect ive. Therefore, t here is a concern t hat t hrough t he norm al QoS priorit izat ion
process, t he receiver m ight drop packet s as Ant i- Replay errors, when, in fact , t hey are
legit im at ely sent or received packet s.

Figure 16- 13 provides a visualizat ion of t he process. I n t his exam ple, voice packet s 4 t hrough 67
have been received, and dat a packet 3 was delayed and t ransm it t ed following voice packet 68.
When t he Ant i- Replay logic is called t o process packet 3, it is dropped because it is out side t he
left edge of t he sliding window. Packet s can be received out of order, but t hey m ust fall wit hin
t he window t o be accept ed.

Figu r e 1 6 - 1 3 . An t i- Re pla y Ope r a t ion

Ant i- Replay drops can be elim inat ed in a pure I PSec t unnel design ( no encrypt ed I P GRE t unnel)
by creat ing separat e securit y associat ions for voice and dat a; voice and dat a packet s m ust
m at ch a separat e line in t he access list referenced by t he crypt o m ap. This is im plem ent ed easily
if t he I P phones are addressed by net work addresses ( such as privat e RFC 1918 addresses)
separat e from t he workst at ions.

However, if I PSec t unnel m ode ( wit h an encrypt ed I P GRE t unnel) is used for a converged
net work of voice and dat a, Ant i- Replay drops im pact dat a packet s inst ead of voice packet s
because t he QoS policies priorit ize voice over dat a.

Consider t he effect of packet loss on a TCP- based applicat ion: TCP is connect ion orient ed and
incorporat es a flow- cont rol m echanism wit hin t he prot ocol. The TCP applicat ion cannot see why a
packet was dropped. A packet dropped by a service policy on a congest ed out put int erface is no
different t o t he applicat ion t han a packet lost by an Ant i- Replay drop. From a net work
perspect ive, however, it would be m ore efficient t o drop t he packet before sending it over t he
WAN link ( where bandwidt h is t he m ost expensive, only t o have it dropped by t he Ant i- Replay
m echanism on t he receiving I PSec VPN rout er) , but t he locat ion or nat ure of t he packet loss is
im m at erial t o t he TCP driver.

Ant i- Replay drops of dat a t raffic flows are usually in t he order of 1 percent t o 1.5 percent on
I PSec VPN links t hat experience sust ained congest ion and have queuing engaged ( wit hout any
addit ional policy t uning) .

Out put drops on t he out put WAN int erface, however, t end t o be few, if any, and cert ainly are far
fewer t han t hose dropped by Ant i- Replay. This is because Ant i- Replay t riggers packet drops
m ore aggressively t han t he out put service policy, which is a funct ion of t he size of t he out put
queues and t he num ber of defined classes.

By default , each CBWFQ class receives a queue wit h a lengt h of 64 packet s. This can be verified
wit h t he sh ow policy in t e r fa ce verificat ion com m and. Meanwhile, t he receiving I PSec peer has
a single 64- packet Ant i- Replay window ( per I PSec Securit y Associat ion) wit h which t o process all
packet s from all LLQ and CBWFQ bandwidt h classes.

So, it st ands t o reason t hat t he Ant i- Replay m echanism on t he receiving VPN rout er will be m ore
aggressive at dropping packet s delayed by QoS m echanism s preferent ial t o VoI P t han t he
service policy at t he sending rout er. This is because of t he size m ism at ch of t he queue dept h on
t he sender's out put int erface ( m ult iple queues of 64 packet s each) com pared t o t he widt h of t he
receiver's Ant i- Replay window ( a single sliding window of 64 packet s per SA) . As m ore
bandwidt h classes are defined in t he policy m ap, t his m ism at ch increases. As m ent ioned, t his is
an inefficient use of expensive WAN/ VPN bandwidt h because packet s are t ransm it t ed only t o be
dropped before decrypt ion.

The default value of 64 packet s per CBWFQ queue is designed t o absorb burst s of dat a t raffic
and delay rat her t han drop t hose packet s. This is opt im al behavior in a non- I PSecenabled
net work.

When I PSec aut hent icat ion is configured ( e sp- sh a - h m a c) in t he net work, t he scenario can be
im proved by reducing t he queue lim it ( m ax t hreshold) of t he bandwidt h classes of t he sender's
out put service policy so t hat it becom es m ore aggressive at dropping packet s t han buffering or
delaying t hem . Ext ensive lab t est ing has shown t hat such queue- lim it t uning can reduce t he
num ber of Ant i- Replay drops from 1 percent t o less t han a t ent h of percent ( < 0.1 percent ) . This
is because decreasing t he service policy queue lim it s causes t he sender's out put service policy t o
becom e m ore aggressive in dropping inst ead of significant ly delaying packet s ( which occurs wit h
large queue dept hs) . This, in t urn, decreases t he num ber of Ant i- Replay drops.

As a rule of t hum b, t he queue lim it s should be reduced in descending order of applicat ion
priorit y. For exam ple, t he queue lim it for Scavenger should be set lower t han t he queue lim it for
a Transact ional Dat a class, as is shown lat er in Exam ples 16- 3 t hrough 16- 6 .

N ot e
I n m any net works, t he default queue lim it s and I PSec Ant i- Replay perform ance are
considered accept able. A m odificat ion of queue- lim it values ent ails side effect s on t he
QoS service policy and relat ed CPU perform ance. When queue lim it s are t uned, a
careful eye should be kept on CPU levels.

Control Plane Provisioning

As discussed in Chapt er 13, Cisco I OS Soft ware has an int ernal m echanism for prot ect ing cont rol
t raffic, such as rout ing updat es, called PAK_priorit y.

PAK_priorit y m arks rout ing prot ocols t o DSCP CS6, but it current ly does not prot ect I PSec
cont rol prot ocols, such as I SAKMP ( UDP port 500) . Therefore, it is recom m ended t o provision an
explicit CBWFQ bandwidt h class for cont rol plane t raffic, including I SAKMP, as shown in Exam ple
16- 2 .

Ex a m ple 1 6 - 2 . Pr ot e ct in g I PSe c Con t r ol Pla n e Tr a ffic

!
class-map match-any INTERNETWORK-CONTROL
match ip dscp cs6
match access-group name IKE ! References ISAKMP ACL
!
!
policy-map V3PN
...
class INTERNETWORK-CONTROL
bandwidth percent 5 ! Control Plane provisioning
...
!
ip access-list extended IKE
permit udp any eq isakmp any eq isakmp ! ISAKMP ACL
!
Site-to-Site V3PN QoS Designs
As wit h WAN and MPLS VPN QoS m odels, sit e- t o- sit e V3PN QoS m odels can range from a basic
num ber of classes ( in t his case, t he m inim um num ber of recom m ended classes is 6) t o a
com plex QoS Baseline m odel ( 11 classes) . Each ent erprise m ust det erm ine present needs and
com fort level of QoS com plexit y, along wit h fut ure needs, t o m ore easily m igrat e t o
progressively m ore com plex QoS m odels, as required.

Six-Class Site-to-Site V3PN Model

The six- class V3PN m odel t echnically should be referred t o as V2PN because it includes
provisioning for only voice ( not for video) over an I PSec VPN. Voice is prot ect ed explicit ly wit h
LLQ; call signaling and cont rol plane t raffic also explicit ly are prot ect ed t hrough CBWFQ classes.
This m odel includes a preferent ial dat a class ( Transact ional Dat a) and a deferent ial class
( Scavenger, which is squelched t o t he m inim um configurable am ount : 1 percent ) . I f t he queue
lim it s are t uned t o m inim ize Ant i- Replay drops, t he queue lim it for Transact ional Dat a should be
set higher t han t he queue lim it for class default .

An exam ple six- class V3PN m odel, which is suit able for link speeds up t o and including T1/ E1
speeds, is illust rat ed in Figure 16- 14 and det ailed in Exam ple 16- 3 .

Figu r e 1 6 - 1 4 . Six - Cla ss Sit e - t o- Sit e V3 PN M ode l

Ex a m ple 1 6 - 3 . Six - Cla ss Sit e - t o- Sit e V3 PN M ode l Con figu r a t ion

Ex a m ple

!
 class-map match-all VOICE
match ip dscp ef ! VoIP
class-map match-any CALL-SIGNALING
match ip dscp cs3 ! New Call-Signaling
match ip dscp af31 ! Old Call-Signaling
class-map match-any INTERNETWORK-CONTROL
match ip dscp cs6 ! IP Routing
match access-group name IKE ! References ISAKMP ACL
class-map match-all TRANSACTIONAL-DATA
match ip dscp af21 af22 ! Transactional-Data
class-map match-all SCAVENGER
match ip dscp cs1 ! Scavenger
!
!
policy-map SIX-CLASS-V3PN-EDGE
class VOICE
priority percent 33 ! VoIP gets 33% LLQ
class CALL-SIGNALING
bandwidth percent 5 ! Call-Signaling provisioning
class INTERNETWORK-CONTROL
bandwidth percent 5 ! Control Plane provisioning
class TRANSACTIONAL-DATA
bandwidth percent 31 ! Transactional-Data provisioning
queue-limit 20 ! Optional: Anti-Replay tuning
class SCAVENGER
bandwidth percent 1 ! Scavenger class is throttled
queue-limit 1 ! Optional: Anti-Replay tuning
class class-default
bandwidth percent 25 ! Best Effort needs BW guarantee
queue-limit 16 ! Optional: Anti-Replay Tuning
!
!
ip access-list extended IKE
permit udp any eq isakmp any eq isakmp ! ISAKMP ACL
!

N ot e
Current ly, only dist ribut ed plat form s support t he qu e u e - lim it com m and in conj unct ion
wit h WRED com m ands. However, t his com m and com binat ion will be available on
nondist ribut ed plat form s wit h t he release of Consist ent QoS Behavior, as discussed in
Chapt er 13 .

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce
Eight-Class Site-to-Site V3PN Model
Wit h t he addit ion of a class for I nt eract ive- Video, t his m odel m ore accurat ely lives up t o it s V3PN
nam e. I nt eract ive- Video ( as wit h VoI P) m ust be provisioned adequat ely t o include I PSec
encrypt ion overhead, but ( unlike VoI P) t here are no clean form ulas for calculat ing t he required
increm ent al bandwidt h. This is because video packet sizes and packet rat es vary significant ly
and are largely a funct ion of t he degree of m ot ion wit hin t he video im ages being t ransm it t ed.

On an unencrypt ed t opology, t he guideline for provisioning for I nt eract ive- Video is t o

overprovision t he LLQ by 20 percent . Alt hough t his conservat ive guideline holds t rue in m ost
videoconferencing scenarios, which usually consist of relat ively m inor m ot ion ( m eet ings,
conferences, t alking heads, and so on) , in som e cases t his rule proves inadequat e over an I PSec
VPN. I n such cases, t he LLQ m ight need t o be provisioned t o t he st ream 's rat e plus 25 percent
or m ore. The need t o increase t he bandwidt h for I nt eract ive- Video's LLQ will be apparent if
drops ( in excess of 1 percent ) appear under t his class when using t he verificat ion com m and
sh ow policy in t e r fa ce .

The ot her class added t o t his m odel is a separat e class for Bulk Dat a applicat ions ( which will be
const rained if congest ion occurs, t o prevent long sessions of TCP- based flows from dom inat ing
t he link) . Not ice t hat t he queue lim it of t he Bulk Dat a class has been reduced t o below t he queue
lim it of t he Best - Effort class. This is because of t he relat ive ranking of applicat ion priorit y:
During periods of congest ion, t he Bulk Dat a class ( large TCP- based file operat ions t hat operat e
m ainly in t he background) is prevent ed from dom inat ing bandwidt h away from t he Best - Effort
class ( as a whole) .

This policy is suit able for link speeds of 3 Mbps or higher. However, in an I PSec environm ent , it
is good t o rem em ber t hat load- sharing GRE t unnels over m ult iple physical int erfaces exacerbat e
Ant i- Replay drops. Whenever possible, a single physical int erface should be used t o achieve
t hese higher speeds. Anot her considerat ion t o bear in m ind is t hat higher- end plat form s, such as
t he 2691 and 3700- or 7200- series rout ers, are required t o perform crypt o at higher speeds. The
Eight - Class Sit e- t o- Sit e V3PN m odel is illust rat ed in Figure 16- 15 and det ailed in Exam ple 16- 4 .

Figu r e 1 6 - 1 5 . Eigh t - Cla ss Sit e - t o- Sit e V3 PN M ode l

Ex a m ple 1 6 - 4 . Eigh t - Cla ss Sit e - t o- Sit e V3 PN M ode l Con figu r a t ion

Ex a m ple

!
class-map match-all VOICE
match ip dscp ef ! VoIP
class-map match-all INTERACTIVE-VIDEO
match ip dscp af41 af42 ! Interactive-Video
class-map match-any CALL-SIGNALING
match ip dscp cs3 ! Old Call-Signaling
match ip dscp af31 ! New Call-Signaling
class-map match-any INTERNETWORK-CONTROL
match ip dscp cs6 ! IP Routing
match access-group name IKE ! References ISAKMP ACL
class-map match-all TRANSACTIONAL-DATA
match ip dscp af21 af22 ! Transactional-Data
class-map match-all BULK-DATA
match ip dscp af11 af12 ! Bulk Data
class-map match-all SCAVENGER
match ip dscp cs1 ! Scavenger
!
policy-map EIGHT-CLASS-V3PN-EDGE
class VOICE
priority percent 18 ! VoIP gets 18% LLQ
class INTERACTIVE-VIDEO
priority percent 15 ! IP/VC gets 15% LLQ
class CALL-SIGNALING
bandwidth percent 5 ! Call-Signaling provisioning
class INTERNETWORK-CONTROL
bandwidth percent 5 ! Control Plane provisioning
class TRANSACTIONAL-DATA
bandwidth percent 27 ! Transactional-Data provisioning
queue-limit 18 ! Optional: Anti-Replay tuning
class BULK-DATA
bandwidth percent 4 ! Bulk-Data provisioning
queue-limit 3 ! Optional: Anti-Replay tuning
class SCAVENGER
bandwidth percent 1 ! Scavenger class is throttled
queue-limit 1 ! Optional: Anti-Replay tuning
class class-default
bandwidth percent 25 ! Best Effort needs BW guarantee
queue-limit 16 ! Optional: Anti-Replay Tuning
!
ip access-list extended IKE
permit udp any eq isakmp any eq isakmp ! ISAKMP ACL
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce
QoS Baseline (11-Class) Site-to-Site V3PN Model
Building on t he previous m odel, t hree new classes are added: Net work- Managem ent , Mission-
Crit ical Dat a, and St ream ing- Video.

This m odel also is suit able only for high- speed ( 3 Mbps and above) links, wit h t he sam e caveat s
regarding m ult iple physical links aggravat ing Ant i- Replay drops and t he requirem ent of using
newer plat form s t o perform crypt o at t hese speeds. The queue lim it s have been t uned t o reflect
relat ive applicat ion priorit y.

The QoS Baseline V3PN m odel, suit able for 3- Mbps link speeds and higher, is illust rat ed in Figure
16- 16 and det ailed in Exam ple 16- 5 .

Figu r e 1 6 - 1 6 . QoS Ba se lin e ( Ele ve n - Cla ss) Sit e - t o- Sit e V3 PN M ode l

Ex a m ple 1 6 - 5 . QoS Ba se lin e ( Ele ve n - Cla ss) Sit e - t o- Sit e V3 PN M ode l

Con figu r a t ion Ex a m ple

!
class-map match-all VOICE
match ip dscp ef ! VoIP
class-map match-all INTERACTIVE-VIDEO
match ip dscp af41 af42 ! Interactive-Video
class-map match-any CALL-SIGNALING
match ip dscp cs3 ! Old Call-Signaling
match ip dscp af31 ! New Call-Signaling
class-map match-any INTERNETWORK-CONTROL
match ip dscp cs6 ! IP Routing
match access-group name IKE ! References ISAKMP ACL
class-map match-all NET-MGMT
match ip dscp cs2 ! Network Management
 class-map match-all MISSION-CRITICAL-DATA
match ip dscp 25 ! Interim MC Data
class-map match-all TRANSACTIONAL-DATA
match ip dscp af21 af22 ! Transactional Data
class-map match-all STREAMING-VIDEO
match ip dscp cs4 ! Streaming Video
class-map match-all BULK-DATA
match ip dscp af11 af12 ! Bulk Data
class-map match-all SCAVENGER
match ip dscp cs1 ! Scavenger
!
!
policy-map QOSBASELINE-V3PN-EDGE
class VOICE
priority percent 18 ! VoIP gets 18% LLQ
class INTERACTIVE-VIDEO
priority percent 15 ! IP/VC gets 15% LLQ
class CALL-SIGNALING
bandwidth percent 5 ! Call-Signaling provisioning
class INTERNETWORK-CONTROL
bandwidth percent 5 ! Control Plane provisioning
class NET-MGMT
bandwidth percent 2 ! Network Management provisioning
class MISSION-CRITICAL-DATA
bandwidth percent 10 ! Mission-Critical Data provisioning
queue-limit 6 ! Optional: Anti-Replay tuning
class TRANSACTIONAL-DATA
bandwidth percent 5 ! Transactional-Data provisioning
queue-limit 3 ! Optional: Anti-Replay tuning
class STREAMING-VIDEO
bandwidth percent 10 ! Streaming-Video provisioning
queue-limit 6 ! Optional: Anti-Replay tuning
class BULK-DATA
bandwidth percent 4 ! Bulk-Data provisioning
queue-limit 3 ! Optional: Anti-Replay tuning
class SCAVENGER
bandwidth percent 1 ! Scavenger throttling
queue-limit 1 ! Optional: Anti-Replay tuning
class class-default
bandwidth percent 25 ! Best Effort needs BW guarantee
queue-limit 16 ! Optional: Anti-Replay tuning
!
!
ip access-list extended IKE
permit udp any eq isakmp any eq isakmp ! ISAKMP ACL
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce
At rem ot e sit es, t hese policies can be applied t o t he physical int erfaces connect ing t hem t o t he
service provider ( provided t hat t he SLAs are for line rat esot herwise, shapers m ust be used) . For
exam ple, if t he service provider guarant ees a full T1 rat e t o a rem ot e sit e and t he access
m edium is Fram e Relay, t he service policy can be applied direct ly t o t he m ain Fram e Relay
int erface. I f t he service provider guarant ees only 768 kbps across t he sam e link, Fram e Relay
t raffic shaping ( eit her legacy or class- based FRTS) com bined wit h FRF.12 m ust be used at t he
rem ot e sit e.

For t he cent ral sit e( s) WAN aggregat ors, however, unique considerat ions exist . These are
discussed in t he next sect ion.
Headend VPN Edge QoS Options for Site-to-Site V3PNs
I PSec V3PNs can be configured in various ways at t he cent ral sit es. Som e ent erprises sim ply
overlay V3PNs on t op of t heir exist ing privat e WANs; ot hers subscribe t o service providers t hat
offer classes of service wit hin t heir clouds. Many ent erprises deploy VPN headends behind WAN
aggregat ion rout ers t o dist ribut e CPU loads, while som e perform encrypt ion and QoS on t he
sam e box. Each of t hese opt ions present s considerat ions on how V3PN policies opt im ally are
applied on WAN aggregat ion rout ers.

For ent erprises t hat have overlaid I PSec VPNs on t op of t heir privat e WAN t opologies, t he V3PN
policies should be applied t o t he leased lines or Fram e Relay/ ATM PVCs, as described in Chapt er
13 .

For ent erprises t hat are subscribing t o service providers t hat offer PE- t o- CE QoS classes
( including ent erprises t hat are deploying I PSec VPNs over MPLS VPNs) , V3PN policies need t o be
applied on t he CE- t o- PE links ( com plet e wit h any re- m arking t hat t he service provider requires
t o m ap int o t hese service provider classes) , as described in Chapt er 15, " MPLS VPN QoS
Design."

For ent erprises t hat are subscribing t o service providers t hat do not offer explicit QoS ( beyond
an SLA) wit hin t heir cloud and are using VPN headends behind WAN aggregat ion rout ers, t he
V3PN service policies would be applied t o t he WAN aggregat or's ( CE- t o- PE) physical links. This
priorit izes packet s ( by applicat ions) and relies on t he service provider's SLA t o ensure t hat t he
delivery largely reflect s t he priorit y of t he packet s as t hey are handed off t o t he service provider.
Such a configurat ion would require only a single QoS policy for a WAN aggregat or ( albeit , on a
high- speed int erface) , but at t he sam e t im e, it would involve an increased dependence on t he
service provider's SLA t o deliver t he desired QoS service levels.

When t he VPN headend rout ers have adequat e CPU cycles t o perform QoS, anot her opt ion
exist s: hierarchical MQC policies t hat shape and queue ( wit hin t he shaped rat e) and are applied
on a per- t unnel basis. A sam ple of per- t unnel hierarchal QoS policies is shown in Exam ple 16- 6.
As wit h previous shaping design recom m endat ions, t he shaper is configured t o shape t o 95
percent of t he rem ot e sit e's line rat e.

N ot e
I t is crit ical t o keep an eye on CPU levels when I PSec VPN encrypt ion and per- t unnel
QoS policies are applied on t he sam e rout er. CPU levels, in general, should not exceed
75 percent during norm al operat ing condit ions. Configuring hierarchical shaping and
queuing policies on a per- t unnel ( per- SA) basis t o a large num ber of sit es could be
very CPU int ensive, especially when such sit es experience periods of sust ained
congest ion.

Ex a m ple 1 6 - 6 . Pe r - Tu n n e l H ie r a r ch ica l Sh a pin g a n d Qu e u in g M QC

Policy for VPN H e a de n ds/ W AN Aggr e ga t or s
!
policy-map SHAPING-T1-TUNNEL
class class-default
shape average 1460000 14600 0 ! Shaped to 95% of T1 line-rate
service-policy V3PN-EDGE ! Nested queuing policy
!
!
interface Tunnel120
description VPN Pipe to V3PN Site#120 (T1 Link)
bandwidth 1536
ip address 10.10.120.1 255.255.255.252
ip mtu 1420
service-policy output SHAPING-T1-TUNNEL ! Policy applied to tunnel int
qos pre-classify ! Performance recommandation
tunnel source 192.168.1.1
tunnel destination 192.168.2.2
crypto map VPN
!
Teleworker V3PN QoS Considerations
Organizat ions const ant ly are st riving t o reduce cost s and im prove product ivit y and em ployee
ret ent ion. Teleworker solut ions address t hese organizat ional obj ect ives by giving em ployees t he
abilit y t o work from hom e wit h com pat ible qualit y, funct ionalit y, perform ance, convenience, and
securit y, as com pared t o working in an office locat ion. Teleworker solut ions t hat provide such
funct ionalit y have been branded " ent erprise class" or " business ready" by Cisco Market ing and
are illust rat ed in Figure 16- 17.

Figu r e 1 6 - 1 7 . Bu sin e ss- Re a dy Te le w or k e r D e sign

[View full size image]

Telecom m ut er solut ions include t hese m ain benefit s:

I n cr e a se d pr odu ct ivit y On average, em ployees spend 60 percent of t heir t im e or less at

t heir desks, yet t his is where t he bulk of invest m ent is m ade in providing access t o
corporat e applicat ions. Providing sim ilar services at an em ployee's residence, for a
relat ively m inor invest m ent , significant ly can increase product ivit y gains.

Bu sin e ss r e silie n ce Em ployees can be displaced from t heir norm al workplace by nat ural
event s ( such as wint er st orm s, hurricanes, or eart hquakes) , healt h alert s ( such as SARS) ,
m an- m ade event s ( such as t ravel rest rict ions or t raffic condit ions) , or sim ply fam ily- relat ed
event s, such as sick children or hom e repairs. These disrupt ions significant ly can im pact an
organizat ion's processes. Providing em ployees wit h cent ral sit eequivalent access t o
applicat ions and services in geographically dispersed locat ions ( such as hom e offices)
creat es a built - in back- up plan t o keep business processes funct ioning in unforeseen
circum st ances.

Cost sa vin gs A t radit ional rem ot e worker set up involves t oll charges for dial- up and
addit ional phone lines. I nt egrat ing services int o a single, broadband- based connect ion can
elim inat e t hese charges while delivering superior overall connect ivit y perform ance.

Se cu r it y Dem ands for access t o ent erprise applicat ions out side t he cam pus are st ret ching
t he lim it s of securit y policies. Teleworking over I PSec VPNs offers inherent securit y
provided by encrypt ion of all t raffic, including dat a, voice, and video. Also crit ical is
int egrat ing firewall and int rusion- det ect ion capabilit ies, along wit h finding ways t o easily
 accom m odat e bot h corporat e and personal users who share a single broadband connect ion
( t he " spouse- and- children" concern, which will be discussed short ly) .

Em ploye e r e cr u it m e n t a n d r e t e n t ion I n t he past , ent erprises recruit ed em ployees in t he

locat ions where corporat e offices were locat ed. Today ent erprises need t he flexibilit y of
hiring skilled em ployees wherever t he skills exist and need t o int egrat e rem ot e workers int o
geographically dispersed t eam s wit h access t o equivalent corporat e applicat ions.

Alt hough QoS designs for I PSec V3PN t eleworker scenarios share m any of t he sam e concerns of
sit e- t o- sit e V3PN scenarios, addit ional specific considerat ions relat ing t o t eleworker deploym ent
m odels and broadband access t echnologies need t o be t aken int o account .

Teleworker Deployment Models

Business- ready t eleworker deploym ent m odels m ust provide t he following services:

Ba sic se r vice s These include NAT, DHCP, I P rout ing, and m ult iple Et hernet connect ions for
hom e office devices and broadband connect ion ( at t achm ent t o t he WAN circuit cable, DSL,
I SDN, or wireless net work) .

QoS se r vice s These include classificat ion, priorit izat ion, and, in som e cases, shaping of
t raffic.

VPN / se cu r it y se r vice s These include encrypt ion of t raffic t o t he m ain sit e and firewall
funct ionalit y for t he hom e office.

Given t hese requirem ent s, t here are t hree m ain deploym ent m odels for business- ready
t eleworker V3PN solut ions, as illust rat ed in Figure 16- 18. These include t he I nt egrat ed Unit
Model, t he Dual- Unit Model, and t he I nt egrat ed Unit + Access Model.

Figu r e 1 6 - 1 8 . Bu sin e ss- Re a dy Te le w or k e r D e ploym e n t M ode ls

[View full size image]

Integrated Unit Model

I n t he I nt egrat ed Unit Model, a single device ( such as a Cisco 837 or 1700- series rout er)
provides basic services, QoS services, and VPN/ securit y services. Furt herm ore, t he device
connect s direct ly t o t he broadband m edia.

N ot e
The Cisco rout ers used in t hese scenarios require an I P/ FW/ PLUS 3DES Cisco I OS
Soft ware feat ure set . This feat ure set would include support for LLQ/ CBWFQ wit h class-
based hierarchical t raffic shaping, and also support for Easy VPN ( EZVPN) , PKI , I DS,
AES, URL filt ering, and EI GRP.

Advant ages include t he following:

Single- device deploym ent and m anagem ent

Adapt abilit y for service provider fully m anaged services ( t ransport , QoS, I P Telephony
applicat ion)

Pot ent ial cost savings

Disadvant ages include t he following:

Availabilit y of a single device at an appropriat e cost wit h t he feat ures and perform ance
required

No single unit for som e broadband access circuit t ypes

The I nt egrat ed Model is a preferred m odel for service providers offering a fully m anaged V3PN
t eleworker service.

From a QoS design perspect ive, t his m odel is highly sim ilar t o a sit e- t o- sit e V3PN, except t hat it
int erfaces wit h a broadband m edia inst ead of a t radit ional WAN access m edia.

Dual-Unit Model

I n t his m odel, one device ( such as a Cisco 831, 837, or 1700- series rout er) provides basic
services and QoS, and a second device ( a Cisco rout er or a PI X 501 or even a VPN 3002)
perform s securit y/ VPN services.

Advant ages include t he following:

Gr a n u la r it y of m a n a ge d se r vice s Service providers can m anage broadband access while

ent erprises m anage VPN/ securit y and privat e net work addressing because t hese are t wo
different unit s.

M e dia in de pe n de n ce Because t he VPN/ securit y device is separat e from t he rout er

connect ing t o t he broadband circuit , t he sam e VPN device can be used for cable, DSL,
wireless, and I SDN by changing t he rout er m odel or m odule in t he rout er. This is especially
valuable if one ent erprise m ust support t eleworkers wit h different broadband circuit t ypes
( such as DSL, cable, and I SDN) .
Disadvant ages include t he following:

Two unit s packaged for deploym ent

Ongoing m anagem ent of t wo devices

The cost for t wo devices

From a QoS design perspect ive, t his m odel is no different from t he previous ( I nt egrat ed Unit )
m odel.

Integrated Unit + Access Model

I n t his t hird m odel, a single rout er ( such as a Cisco 831 or 1700- series rout er) provides basic
services, QoS services, and VPN/ securit y services. However, t he rout er does not connect direct ly
t o t he broadband access m edia; it connect s ( t hrough Et hernet ) t o a broadband access device
( such as a DSL or cable m odem ) .

Advant ages include t he following:

Cost savings realized by using exist ing broadband- access devices

Sim plified provisioning because one size fit s all, regardless of broadband access m edia

Solut ion support even when no rout er int erface for a specific broadband circuit t ype is
available

Disadvant ages include t he following:

I ncreased t roubleshoot ing com plexit y because m ost broadband- access devices ( m odem )
are not int elligent and, t herefore, cannot be queried, m anaged, or cont rolled.

Addit ional QoS com plexit y because, in t his m odel, t he rout er does not cont rol t he
broadband circuit and, t hus, m ust perform hierarchical shaping, as shown in Figure 16- 19.

Figu r e 1 6 - 1 9 . H ie r a r ch ica l QoS Re qu ir e m e n t s for I n t e gr a t e d Un it +

Acce ss Te le w or k e r D e ploym e n t M ode l

[View full size image]

Because of t he m edia- specific encapsulat ion overhead requirem ent s ( discussed in t he following
sect ions) , it is recom m ended t o shape t o 95 percent of broadband link for cable and 70 percent
of t he uplink rat e for DSL.

A hierarchical shaping policy t hat forces queuing t o engage for a 384- kbps cable broadband
connect ion is shown in Exam ple 16- 7.

Ex a m ple 1 6 - 7 . H ie r a r ch ica l Sh a pin g a n d Qu e u in g M QC Policy for a 3 8 4 -

k bps Ca ble Con n e ct ion

!
policy-map SHAPE-384-CABLE
class class-default
shape average 364800 3640 ! Shapes to 95% of 384 kbps cable link
service-policy V3PN-TELEWORKER ! Nested V3PN Teleworker queuing policy
!
...
!
interface Ethernet0
service-policy output SHAPE-384-CABLE ! Shaper applied to LAN interface
!

The I nt egrat ed Unit + Access Model is a preferred m odel for ent erprise V3PN t eleworker
deploym ent s because it com plet ely abst ract s any service provideror access m ediaspecific
requirem ent s ( a one- size- fit s- all solut ion) .

Broadband-Access Technologies
I n Nort h Am erica, t here are four m ain broadband- access t echnology opt ions for t elecom m ut er
scenarios: DSL, cable, I SDN, and wireless. DSL and cable are by far t he dom inant broadband
t echnologies.
Because of per- m inut e cost s, I SDN is used considerably less; however, I SDN flat rat e is
becom ing available and will m ake I SDN a good opt ion for areas where DSL or cable is not
available. Last - m ile wireless is a new opt ion t hat is being pilot ed in cert ain areas t o det erm ine
v iabilit y .

The m inim um recom m ended broadband dat a rat e for m ost deploym ent s is 160 kbps
( uplink) / 860 kbps ( downlink) . Dat a rat es below t his speed require m ore t roubleshoot ing by
support st aff and are less likely t o provide accept able voice qualit y. The recom m ended dat a rat e
for V3PN t eleworker deploym ent s is 256 kbps ( uplink) / 1.4 Mbps ( downlink) or higher rat es.
Alt hough V3PN can be deployed at rat es less t han 160 kbps/ 860 kbps, generally t he voice
qualit y at t hat service level is in t he cell phone qualit y range, and support cost s are higher.

Because QoS design for I SDN was discussed in Chapt er 13, and because wireless as a last - m ile
broadband t echnology has yet t o gain wide deploym ent , t his sect ion focuses only on DSL and
cable broadband t echnologies.

DSL and cable t opologies are illust rat ed in Figure 16- 20. Cable is a shared m edium bet ween t he
t eleworker's cable m odem and t he broadband provider's cable headend rout er. DSL is a
dedicat ed circuit bet ween t he t eleworker's DSL m odem ( bridge) and t he DSL Access Mult iplexer
( DSLAM) . Bot h cable and DSL offerings ut ilize shared uplinks bet ween t hese aggregat ion devices
and t he service provider's core net work. QoS t ypically is not provisioned wit hin t he broadband
service provider's cloud in eit her m edium . This lack of QoS wit hin t he broadband cloud
underscores t he requirem ent of adequat e QoS provisioning at t he endpoint s of t he VPN t unnels.

Figu r e 1 6 - 2 0 . D SL a n d Ca ble Topologie s

Digital Subscriber Line

DSL service feat ures a dedicat ed access circuit and offers a service sim ilar t o Fram e Relay or
Asynchronous Transfer Mode ( ATM) , in which a single perm anent virt ual circuit ( PVC) is
provisioned from t he hom e office t o t he service provider aggregat ion point . DSL has a variet y of
speeds and encoding schem es.

Most service providers t oday offer resident ial Asynchronous Digit al Subscriber Line ( ADSL) . ADSL
provides for asym m et ric speeds ( wit h t he downst ream rat e great er t han t he upst ream rat e) .
Asym m et rical links are a bet t er choice and benefit for t he t elecom m ut er because t he great er t he
downlink bandwidt h is, t he less t he need is for QoS. ( Slower- speed uplinks slow TCP sender
t ransm ission rat es t o m ore m anageable levels.) Because QoS is not generally available by
broadband service providers, such uplink/ downlink speed m ism at ches are desirable.

Resident ial access speeds are generally 128 t o 384 kbps upst ream and 608 kbps t o 1.5 Mbps
downst ream . For ADSL circuit s wit h upst ream speeds less t han 256 kbps, G.729 VoI P codecs are
recom m ended.

ADSL also ut ilizes a single best - effort PVC using RFC 2516based PPP over Et hernet ( PPPoE)
encapsulat ion. I n DSL net works, delay and j it t er are very low but are not guarant eed. Because
PPPoE is used, no LFI is available in service provider DSL net works. I n t he fut ure, QoS at Layer 2
m ight be available across service provider net works using fam iliar ATM variable bit - rat e ( VBR)
definit ions.

Single- pair high bit - rat e DSL ( G.SHDSL) is t he new high- speed st andard for business DSL. Most
residences will cont inue t o be served by ADSL, while sm all business and branch offices likely will
use G.SHDSL. G.SHDSL offers varying rat es cont rolled by t he service provider; t he upst ream
and downst ream rat es are t he sam e speed ( sym m et ric) . G.SHDSL is seen as an event ual
replacem ent for T1s in t he Unit ed St at es and will becom e increasingly available from m ore
service providers.

The t elecom m ut er deploym ent opt ions for DSL circuit s include all t hree t eleworker deploym ent
m odels: I nt egrat ed Unit , Dual- Unit , and I nt egrat ed Unit + Access, as shown in Figure 16- 21.

Figu r e 1 6 - 2 1 . Te le w or k e r D e ploym e n t M ode ls for D SL

Cable

Cable offers a shared service wit h sym m et ric speeds varying from 100 kbps t o 4 Mbps. I n t he
past , delay and j it t er varied t oo great ly over cable, m aking it unsuit able for VoI P.

The com m on inst alled base of cable services t oday is m ade up of Dat a- over- Cable Service
I nt erface Specificat ions ( DOCSI S) 1.0. No LFI is available wit h DOCSI S 1.0, alt hough DOCSI S
1.1 defines fragm ent at ion and int erleaving m echanism s.

DOCSI S 1.1 also provides t he capabilit ies t o shape t raffic at Layer 2 before t ransm ission over
t he cable net work. Alt hough t he circuit and frequencies physically are shared, access t o t he
m edium can be cont rolled by t he headend so t hat a device can be guarant eed specified
bandwidt h.

At t he t im e of t his writ ing, t he only recom m ended deploym ent m odel for cable is t he I nt egrat ed
Unit + Access Model, as shown in Figure 16- 22.

Figu r e 1 6 - 2 2 . Te le w or k e r D e ploym e n t M ode l for Ca ble

Bandwidth Provisioning
A few key differences wit h respect t o bandwidt h provisioning need t o be t aken int o account for
broadband t eleworker scenarios, as com pared t o sit e- t o- sit e VPNs.

The first is t hat usually only a single call needs t o be provisioned for ( unless t wo t eleworkers
share a single resident ial broadband connect ion, which is rarely t he case) . I f bandwidt h is low,
G.729 codecs are recom m ended. The second key bandwidt h- provisioning considerat ion is t he
inclusion of t he overhead required by t he broadband access t echnologies, whet her DSL or cable.

N ot e
Som et im es m ult icast support is not required in a t eleworker environm ent . For
exam ple, rout ing prot ocols ( which depend on m ult icast support ) m ight not be required
by t eleworkers ( because default gat eways are usually sufficient in t his cont ext ) . I n
such cases, I PSec t unnel m ode ( no encrypt ed I P GRE t unnel) can be used t o achieve
addit ional bandwidt h savings of 24 byt es per packet .

For t he rem ainder of t his chapt er, I PSec t unnel m ode ( no encrypt ed I P GRE t unnel) is
t he assum ed m ode of operat ion.

NAT Transparency Feature Overhead

Beginning in Cisco I OS Release 12.2( 13) T, NAT t ransparency was int roduced and is enabled by
default , provided t hat bot h peers support t he feat ure. I t is negot iat ed in t he I KE exchange
bet ween t he peers. This feat ure addresses t he environm ent in which I PSec packet s m ust pass
t hrough a NAT/ pNAT device, and it adds 16 byt es t o each voice and dat a packet . The overhead
t hat t his feat ure adds is shown in Figure 16- 23.

Figu r e 1 6 - 2 3 . N AT Tr a n spa r e n cy Fe a t u r e ( La ye r 3 ) Ove r h e a d

[View full size image]

No addit ional overhead is caused by NAT t ransparency on a G.729 call over DSL ( PPPoE/ AAL5)
because t here is enough AAL5 cell padding t o absorb t he 16 addit ional byt es per packet
( discussed in m ore det ail in t he following sect ion) . I n cable im plem ent at ions, t hese addit ional 16
byt es increase t he num ber of bit s on t he wire and, t hus, t he overall bandwidt h consum pt ion. At
t he headend, NAT t ransparency increases t he bandwidt h consum pt ion of VoI P t raffic by 1 Mbps
for approxim at ely every 82 concurrent G.729 calls; on t he t eleworker rout er, NAT t ransparency
increases t he bandwidt h required by 6.4 kbps per G.729 call.

Unless t here is a need t o im plem ent t his feat ure, t he recom m endat ion is t o disable it when
bandwidt h conservat ion is a requirem ent . This feat ure can be disabled wit h t he n o cr ypt o ipse c
n a t - t r a n spa r e n cy u dp- e n ca psu la t ion global configurat ion com m and.

DSL (AAL5 + PPPoE) Overhead

For DSL broadband connect ions, PPPoE is t he m ost com m only im plem ent ed deploym ent . Given
t he 112- byt e, Layer 3 size of an I PSec ( only) encrypt ed G.729 VoI P call, 40 byt es of PPP, PPPoE,
Et hernet , and ATM AAL5 headers and t railers are added. Addit ionally, t he pre- ATM Soft ware
Segm ent at ion and Reassem bly ( SAR) engine is required t o pad t he result ing 152- byt e packet t o
t he nearest m ult iple of 48 ( each fixed- lengt h ATM cell can t ransport only a 48- byt e payload) .
Figure 16- 24 shows t he result ing 192- byt e pre- ATM packet .

Figu r e 1 6 - 2 4 . I PSe c- En cr ypt e d G.7 2 9 Pa ck e t Size Th r ou gh AAL5 +

PPPoE En ca psu la t ion

[View full size image]

The 192 byt es of cell payload are incorporat ed t hrough ATM SAR int o t he ( 48- byt e) payloads of
four 53- byt e ATM cells ( 192 / 48 = 4 cells) .

Therefore, t he bandwidt h required for an I PSec ( only) encrypt ed G.729 VoI P call over DSL is
calculat ed as follows:

53 byt es per cell

x 4 cells per I PSec- encrypt ed VoI P packet

________
212 byt es per ( 192- byt e) AAL5/ PPPoE I PSec VoI P packet

x 50 packet s per second

________
10,600 byt es per second

x 8 bit s per byt e

________
84,800 bit s per second

Thus, an encrypt ed G.729 call requires 85 kbps of bandwidt h, while an encrypt ed G.711 requires
seven ATM cells or 148,400 bps on t he wire.

This result s in t he LLQ configurat ion values of 85 kbps ( pr ior it y 8 5 ) for a G.729 VoI P call and
150 kbps for a G.711 ( pr ior it y 1 5 0 ) VoI P call, respect ively, for DSL.

Cable Overhead

For cable deploym ent s, t he Layer 2 overhead is less t han t hat for DSL. The I PSec packet is
encapsulat ed in an Et hernet header ( and t railer) t hat includes a 6- byt e DOCSI S header, as
shown in Figure 16- 25.

Figu r e 1 6 - 2 5 . I PSe c- En cr ypt e d G.7 2 9 Pa ck e t Size Th r ou gh Et h e r n e t

a n d D OCSI S En ca psu la t ion

[View full size image]

I f baseline privacy is enabled ( baseline privacy encrypt s t he payload bet ween a cable m odem
and t he headend) , t he ext ended header is used, adding anot her 5 byt es.

The packet size of a G.729 call ( wit h a zero- lengt h ext ended header) is 136 byt es or 54,400 bps
( at 50 pps) ; a G.711 call is 280 byt es or 112,000 bps ( at 50 pps) .

To sim plify configurat ion and deploym ent , t he values of 64 kbps ( for G.729) and 128 kbps ( for
eit her G.729 or G.711) can be used for priorit y queue definit ion for cable.

Asymmetric Links and Unidirectional QoS

Wit h bot h DSL and cable, t he uplink connect ion can be enabled wit h QoS, eit her in t he form of a
service policy on t he DSL ( ATM PVC) int erface or t hrough a hierarchical MQC service policy t hat
shapes t he uplink and priorit izes packet s wit hin t he shaped rat e on t he Et hernet int erface. This
half of t he link is under t he ent erprise's cont rol and easily can be configured.

The downlink connect ion is under t he cont rol of t he broadband service provider, and any QoS
policy m ust be configured by t he service provider; however, m ost service providers do not offer
QoS- enabled broadband services. This is usually because DSL providers oft en have im plem ent ed
non- Cisco equipm ent ( DSLAM or ot her ATM concent rat ion devices) t hat t ypically have few or no
QoS feat ures available. Cable providers, on t he ot her hand, m ight have an opt ion t o enable QoS
as DOCSI S 1.1 becom es m ore widely deployed.

Fort unat ely, m ost service offerings are asym m et rical. For exam ple, consider a circuit wit h a 256-
kbps uplink and 1.5- Mbps downlink. The downlink rarely is congest ed t o t he point of degrading
voice qualit y.

Test ing in t he Cisco Ent erprise Solut ions Engineering labs has shown t hat when congest ion is
experienced on t he uplink, t he result ing delay of ( TCP) dat a packet acknowledgm ent s
aut om at ically decreases t he arrival rat e of downlink dat a t raffic so t hat downlink congest ion does
not occur. To sum m arize t he result s of t hese t est s: Asym m et rical links are preferred ( over
sym m et rical links) as long as QoS is enabled on t he uplink, provided t hat t he lower of t he t wo
speeds ( t he uplink) is adequat e for t ransport ing bot h voice and dat a.

Som e service providers for business- class services offer sym m et rical links in an effort t o
com pet e wit h Fram e Relay providers; 384 kbps/ 384 kbps and 768 kbps/ 768 kbps are exam ples.
Wit h no QoS enabled on t he service provider edge, t his offering is not opt im al for t he ent erprise.
An asym m et rical link such as 384 kbps/ 1.5 kbps is a bet t er choice for t he V3PN net works.

Broadband Serialization Mitigation Through TCP Maximum Segment

Size Tuning
The m aj orit y of broadband deploym ent s are DSL wit h PPPoE and cable wit h DOCSI S 1.0. As
previously not ed, neit her of t hese t echnologies includes any m echanism s t o fragm ent dat a
packet s and int erleave voice packet s at Layer 2 t o m inim ize t he im pact of serializat ion and
blocking delay on voice packet s ( which is a recom m ended requirem ent on link speeds 768
kbps) .

The DOCSI S 1.1 specificat ion for cable includes fragm ent at ion and int erleaving support , and DSL
providers can im plem ent MLP over ATM ( which includes MLP LFI support ) . However, t hese do not
represent t he m aj orit y of t he current ly deployed base of broadband net works.

An alt ernat ive way t o m it igat e serializat ion delay on broadband circuit s is provided by adj ust ing
t he TCP Maxim um Segm ent Size ( MSS) . The TCP MSS value influences t he result ing size of TCP
packet s and can be adj ust ed wit h t he ip t cp a dj u st - m ss int erface com m and. Because t he
m aj orit y of large dat a packet s on a net work are TCP ( norm al UDP applicat ion packet s, such as
DNS and NTP, average less t han 300 byt es and do not creat e a significant serializat ion delay
issue) , t his com m and effect ively can reduce serializat ion delay in m ost t eleworker scenarios
when no Layer 2 fragm ent at ion and int erleaving m echanism is available.

N ot e

I t is not recom m ended t o run UDP- based video applicat ions on broadband links 768
kbps t hat do not support Layer 2 LFI in a V3PN t eleworker scenario. This is because
such applicat ions regularly generat e large UDP packet s t hat , obviously, are not subj ect
t o TCP MSS and t hus can cause significant and unm it igat able serializat ion delays t o
VoI P packet s.

The recom m ended TCP MSS value of 542 was calculat ed t o elim inat e t he I PSec crypt o algorit hm
( 3DES) padding and t he ATM AAL5 padding in DSL im plem ent at ions ( cable im plem ent at ions
have 3DES padding but no AAL5) . Therefore, a TCP MSS value of 542 byt es is valid for cable but
is opt im ized for DSL. Figure 16- 26 illust rat es a TCP packet wit h an MSS size of 542.

Figu r e 1 6 - 2 6 . Opt im ize d TCP M SS Va lu e for D SL ( 5 4 2 Byt e s)

[View full size image]

N ot e
Bot h t he ESP and AAL5 pad lengt hs are 0. A TCP packet wit h a TCP MSS value of 542
fit s exact ly int o 14 ATM cells, wit h no wast ed byt es because of cell padding.

The evident negat ive aspect of using t his t echnique t o m inim ize t he im pact of serializat ion delay
is t he decreased efficiency of large dat a t ransfers, coupled wit h an increase in t he num ber of
packet s per second t hat t he rout er m ust swit ch. The higher packet s- per- second rat e is not as
m uch of an issue at t he rem ot e rout er as at t he headend, where hundreds or t housands of
rem ot e connect ions are concent rat ed. However, adj ust ing t he TCP MSS value provides a m eans
for t he net work m anager t o deploy voice over broadband connect ions, which do not support any
LFI m echanism at rat es less t han 768 kbps.

Split Tunneling
The t eleworker is usually not t he only user of t he resident ial broadband connect ion. The worker's
spouse and children also m ight ut ilize t his link from ot her devices, such as addit ional PCs or
lapt ops or even gam ing unit s. I n such cases, only " work- relat ed" t raffic would require encrypt ion
and could be given a preferent ial t reat m ent , t hrough QoS, over general I nt ernet t raffic.

I n t his sit uat ion, priorit izat ion could be m ade based on t he dest inat ion address of t he t raffic. One
m et hod t o accom plish t his would be t o creat e a separat e bandwidt h class ( for exam ple, nam ed
CORPORATE) and provision t his class wit h a dedicat ed CBWFQ queue.

Given t he sam ple t opology illust rat ed in Figure 16- 27, a suit able QoS configurat ion is broken
down as follows:

VOI CE A single call's VoI P packet s assigned t o an LLQ, wit h t he bandwidt h allocat ion based
on codec and broadband m edia ( DSL or cable) .

CALL- SI GN ALI N G Call- Signaling t raffic in a CBWFQ queue, allocat ed 5 percent .

I N TERN ETW ORK I nt ernet work- Cont rol t raffic, such as rout ing prot ocol updat es and I KE
keepalives, in a CBWFQ queue, allocat ed 5 percent .

CORPORATE All ot her t raffic t hat is dest ined t o t he ent erprise t hrough t he I PSec t unnel, in
a CBWFQ queue, allocat ed 25 percent .

I N TERN ET/ Cla ss- D e fa u lt Traffic t o t he I nt ernet ( out side t he I PSec t unnel) default s t o
t his fair- queued class.

Figu r e 1 6 - 2 7 . Split Tu n n e l Ex a m ple Topology

The following configurat ion fragm ent provides a m eans t o im plem ent t his policy. I t assum es t hat
t he headend I PSec crypt o peers reside on net work 150.102.223.0/ 29. I n t his exam ple
environm ent , t wo peers are configured at 150.102.223.3 and 150.102.223.4. Packet s wit hin t he
I PSec t unnelt hose m at ching t he CORP- I NTRANET access cont rol list ( ident ifying RFC 1918
privat e addresses t hat are assum ed in t his exam ple t o represent t he int ranet s behind t he
headends) will be encapsulat ed in an ESP ( I PSec- I P prot ocol 50) I P header. A class- m ap
CORPORATE is configured t hat references t he CORPORATE ext ended access list , point ing t o t he
VPN headend subnet .

A policy m ap nam ed V3PN- SPLI T- TUNNEL is creat ed t hat includes classes for VOI CE,
I NTERNETWORK- CONTROL, and CALL- SI GNALI NG, along wit h a bandwidt h class for
CORPORATE.

I n t his exam ple, t he VOI CE class is provisioned for a G.711 codec over a ( 384- kbps) DSL uplink,
allocat ing 150 kbps ( or 40 percent , whichever synt ax is preferred) for VoI P. Exam ple 16- 8 shows
t he relevant configurat ion fragm ent .

Ex a m ple 1 6 - 8 . V3 PN - SPLI T- TUN N EL Policy Ex a m ple

!
crypto map SPLIT-TUNNEL-CRYPTO-MAP 1 ipsec-isakmp
set peer 150.102.223.3
set peer 150.102.223.4
set transform-set TS
match address CORP-INTRANET ! References CORP-INTRANET ACL
qos pre-classify ! Enables QoS Pre-Classify
!
!
class-map match-all VOICE
match ip dscp ef ! VoIP
class-map match-any INTERNETWORK-CONTROL
match ip dscp cs6 ! IP Routing
match access-group name IKE ! References ISAKMP ACL
class-map match-any CALL-SIGNALING
match ip dscp cs3 ! New Call-Signaling
match ip dscp af31 ! Old Call-Signaling
class-map match-all CORPORATE
match access-group name CORPORATE ! References CORPORATE ACL
!
policy-map V3PN-SPLIT-TUNNEL
class VOICE
priority 150 ! Encrypted G.711 over DSL (PPPoE/AAL5)
class INTERNETWORK-CONTROL
bandwidth percent 5 ! Control Plane provisioning
class CALL-SIGNALING
bandwidth percent 5 ! Call-Signaling provisioning
class CORPORATE
bandwidth percent 25 ! "Work-related" traffic provisioning
queue-limit 15 ! Optional: Anti-Replay Tuning
class class-default
fair-queue
queue-limit 15 ! Optional: Anti-Replay Tuning
!
...
!
ip access-list extended CORP-INTRANET ! CORP-INTRANET ACL (RFC 1918)
permit ip any 10.0.0.0 0.255.255.255
permit ip any 172.16.0.0 0.15.255.255
permit ip any 192.168.0.0 0.0.255.255
!
ip access-list extended IKE
permit udp any eq isakmp any eq isakmp ! ISAKMP ACL
!
ip access-list extended CORPORATE ! CORPORATE ACL (VPN Head-ends)
permit esp any 150.102.223.0 0.0.0.7
!
Teleworker V3PN QoS Designs
To review, t hree deploym ent m odels exist for t eleworker V3PN scenarios:

I nt egrat ed Unit Model

Dual- Unit Model

I nt egrat ed Unit + Access Model

Furt herm ore, t here are t wo m ain broadband deploym ent m edia: DSL and cable. DSL support s all
t hree t eleworker deploym ent m odels, but cable support s ( at t he t im e of writ ing) only t he
I nt egrat ed Unit + Access Model.

Integrated Unit/Dual-Unit ModelsDSL Design

The key point t o rem em ber when provisioning QoS for V3PN over DSL ( PPPoE/ ATM AAL5) is t he
significant bandwidt h overhead required by t hese prot ocols ( 85 kbps is needed per G.729 call,
and 150 kbps is needed per G.711 call) .

Som e addit ional point s t o keep in m ind are t hat since t he service policy is being applied t o a low-
speed ATM PVC, t he Tx- ring should be t uned t o 3 ( as discussed in Chapt er 13 ) and also t hat
because no LFI m echanism exist s for DSL, TCP- MSS t uning can be done on t he dialer int erface
t o m it igat e serializat ion delay. An I nt egrat ed Unit / Dual- Unit V3PN t eleworker exam ple for a 384-
kbps DSL circuit is illust rat ed in Figure 16- 28 and det ailed in Exam ple 16- 9 .

Figu r e 1 6 - 2 8 . I n t e gr a t e d Un it / D u a l- Un it V3 PN Te le w or k e r M ode l for

3 8 4 - k bps D SL Uplin k
Ex a m ple 1 6 - 9 . I n t e gr a t e d Un it / D u a l- Un it V3 PN Te le w or k e r QoS D e sign
Ex a m ple for a 3 8 4 - k bps ( PPPoE/ ATM ) D SL Uplin k

!
class-map match-all VOICE
match ip dscp ef ! VoIP
class-map match-any INTERNETWORK-CONTROL
match ip dscp cs6 ! IP Routing
match access-group name IKE ! References ISAKMP ACL
class-map match-any CALL-SIGNALING
match ip dscp cs3 ! New Call-Signaling
match ip dscp af31 ! Old Call-Signaling
!
!
policy-map V3PN-TELEWORKER
class VOICE
priority 150 ! Encrypted G.711 over DSL (PPPoE/AAL5)
class INTERNETWORK-CONTROL
bandwidth percent 5 ! Control Plane provisioning
class CALL-SIGNALING
bandwidth percent 5 ! Call-Signaling provisioning
class class-default
fair-queue
queue-limit 30 ! Optional: Anti-Replay Tuning
!
...
!
interface ATM0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
 dsl power-cutback 0
!
interface ATM0.35 point-to-point
description Outside PPPoE/ATM DSL Link
bandwidth 384
pvc dsl 0/35
vbr-nrt 384 384
tx-ring-limit 3 ! Tx-Ring tuned to 3
pppoe max-sessions 5
service-policy output V3PN-TELEWORKER ! MQC policy applied to PVC
pppoe-client dial-pool-number 1
!
...
!
interface Dialer1
description Dialer for PPPoE
ip address negotiated
ip mtu 1492
encapsulation ppp
ip tcp adjust-mss 542 ! TCP MSS value tuned for slow-link
!
...
!
ip access-list extended IKE
permit udp any eq isakmp any eq isakmp ! ISAKMP ACL
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

sh ow a t m pvc

Integrated Unit + Access ModelDSL/Cable Designs

Hierarchical MQC policies are required for I nt egrat ed Unit + Access Models t o shape and queue
( wit hin t he shaped rat e) on t he out bound Et hernet int erface. For cable, t he shaped rat e should
be 95 percent of t he broadband link's speed ( as det ailed in Chapt er 13 in t he " Fram e Relay "
sect ion [ " Com m it t ed I nform at ion Rat e " subsect ion] ) . For DSL, t he shaped rat e should be 70
percent of t he uplink's speed ( t o account for t he increased bandwidt h overhead required by
DSL) . Furt herm ore, on slow- speed ( 768 kbps) links, TCP- MSS should be t uned on bot h t he
inbound and out bound Et hernet int erfaces. An I nt egrat ed Unit + Access Model for a 384- kbps
cable t eleworker uplink is shown in Figure 16- 29 and det ailed in Exam ple 16- 10 .

Figu r e 1 6 - 2 9 . I n t e gr a t e d Un it + Acce ss V3 PN Te le w or k e r M ode l for

3 8 4 - k bps Ca ble Uplin k
Ex a m ple 1 6 - 1 0 . I n t e gr a t e d Un it + Acce ss M ode lCa ble D e sign Ex a m ple

!
class-map match-all VOICE
match ip dscp ef ! VoIP
class-map match-any INTERNETWORK-CONTROL
match ip dscp cs6 ! IP Routing
match access-group name IKE ! References ISAKMP ACL
class-map match-any CALL-SIGNALING
match ip dscp cs3 ! Old Call-Signaling
match ip dscp af31 ! New Call-Signaling
!
!
policy-map V3PN-TELEWORKER
class VOICE
priority 128 ! Encrypted G.711 over Cable
class INTERNETWORK-CONTROL
bandwidth percent 5 ! Control Plane provisioning
class CALL-SIGNALING
bandwidth percent 5 ! Call-Signaling provisioning
class class-default
fair-queue
queue-limit 30 ! Optional: Anti-Replay Tuning
!
!
policy-map SHAPE-384-CABLE
class class-default
shape average 364800 3640 ! Shapes to 95% of 384 kbps cable link
service-policy V3PN-TELEWORKER ! Nested V3PN Teleworker queuing policy
!
...
!
interface Ethernet0
description Inside Ethernet Interface
ip tcp adjust-mss 542 ! TCP MSS value tuned for slow-link
 !
interface Ethernet1
description Outside Ethernet Interface
ip address dhcp
ip tcp adjust-mss 542 ! TCP MSS value tuned for slow-link
service-policy output SHAPE-384-CABLE ! Shaper applied to LAN interface
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce
Case Study: IPSec VPN QoS Design
ABC, I nc., is cont inuing t o expand in it s operat ions. Recent ly, it acquired a new subsidiary, DEF
Group, and want s t o incorporat e t his new group wit hin it s exist ing net work infrast ruct ure.

DEF already has provisioned it s wide- area net working needs t o it s m ore t han 100 branches
t hrough I PSec VPNs. However, it has provisioned only for dat a net working needs. ABC, I nc.,
want s t o deploy I P Telephony t o all of DEF's rem ot e sit es im m ediat ely. At t his point in t im e,
DEF's branches are running full T1s, wit h Fram e Relay as t he access m edium . ABC also plans t o
deploy I P videoconferencing t o t hese sit es in t he fut ure, aft er t he access links have been
upgraded t o higher- speed ATM PVCs.

At t he sam e t im e, ABC, I nc.'s, m anagem ent has received num erous request s from em ployees
who want t o relocat e away from t he com pany's cent ral cam pus because t he cost of living in
ot her areas is m ore at t ract ive. ABC is concerned t hat it will lose m uch of it s t op t alent and has
decided t o deploy a business- ready t eleworker solut ion for any approved em ployees.

This t eleworker solut ion is t o be t ailored t o work wit h eit her DSL or cable resident ial broadband
opt ions t hrough t he I nt egrat ed Unit + Access Teleworker deploym ent m odel.

The com bined set of V3PN solut ions is illust rat ed in Figure 16- 30 .

Figu r e 1 6 - 3 0 . Ca se St u dy I PSe c VPN QoS D e sign Ex a m ple

[View full size image]

I n t his exam ple, ABC, I nc., is cont inuing t o part ner wit h a Cisco I P Mult iservice Service Provider
( Service Provider XYZ) who offers t hem t ight service- level agreem ent s, such as 60- m s edge- t o-
edge delay, 10- m s edge- t o- edge j it t er, and 0.5 percent packet loss. However, for t his part icular
service ( nam ely, t he int erconnect of DEF's rem ot e sit es) , XYZ is not offering explicit classes of
service or QoS ( beyond t he edge- t o- edge SLA) .

For scalabilit y and availabilit y reasons, ABC, I nc., has decided t o decouple I PSec VPN encrypt ion
and QoS at it s cent ral sit e: one pair of rout ers ( Cisco 7200 VXR NPE- G1s wit h dual VPN
Accelerat ion Modules, or VAMs) will provide I PSec VPN encrypt ion, and anot her pair of rout ers
( Cisco 7500 wit h VI P6- 80s) will perform WAN aggregat ion QoS. As ABC cont inues t o expand it s
operat ions, it plans t o m igrat e it s VPN headends t o t he Cat alyst 6500 wit h t he VPN Services
Module ( VPNSM) t o achieve even higher scalabilit y.

Because ABC, I nc., plans t o support I P videoconferencing in t he fut ureand, t herefore, will be
expanding t he link speeds t o it s branchesit has decided t o upgrade it s branch rout ers t o Cisco
3725s and Cisco 3745s ( bot h wit h AI M- I I hardware crypt o engines) , wit h t he 3745s being
deployed at t he busiest sit es.

For t he t elecom m ut er solut ion, ABC, I nc., has chosen a Cisco 831 rout er t o perform t he basic,
VPN/ securit y, and QoS services required by t eleworkers. I t has decided t o support split -
t unneling so t hat I nt ernet t raffic belonging t o a spouse or child will not t ax net work resources.

The configurat ion solut ion for t his exam ple spans m ult iple rout ers: VPN headend rout ers ( see
Exam ple 16- 11 ) , WAN aggregat ors ( see Exam ple 16- 12 ) , branch rout ers ( see Exam ple 16- 13 ) ,
and t elecom m ut er rout ers ( see Exam ple 16- 14 ) . To m inim ize redundancy, only a single
exam ple of each rout er t ype is present ed.

A key point t o not ice in t he VPN headend designs, as det ailed in Exam ple 16- 11 , is t hat QoS
Pre- Classify is not required because encrypt ion and QoS are being perform ed on separat e
rout ers at t he cent ral sit e.

Ex a m ple 1 6 - 1 1 . Ca se St u dy Ex a m ple : Pa r t 1 , VPN H e a de n d D e sign

!
hostname VPN-HEADEND-1
!
ip cef
!
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key SECRETKEY address 25.25.25.1
!
!
crypto ipsec transform-set V3PN-TS esp-3des esp-sha-hmac
!
crypto map V3PN-CM 10 ipsec-isakmp
set peer 25.25.25.1
set transform-set V3PN-TS
match address V3PN-SITE1
[REPEAT CRYPTO MAP ENTRIES FOR EVERY REMOTE SITE, INCLUDING TELEWORKER SITES]
 !
crypto map static-map local-address GigabitEthernet0/1
!
...
!
interface Tunnel101
ip address 10.100.101.1 255.255.255.252
tunnel source 100.100.100.1
tunnel destination 25.25.25.1
crypto map V3PN-CM ! Applies crypto-map to tunnel interface
!
[REPEAT TUNNEL INTERFACES FOR EVERY REMOTE SITE, INCLUDING TELEWORKER SITES]
!
interface GigabitEthernet0/1
description CENTRAL SITE DATA SUBNET
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto
media-type rj45
no negotiation auto
!
!
interface GigabitEthernet0/2
description VPN HEADEND SUBNET
ip address 100.100.100.1 255.255.255.0
duplex auto
speed auto
media-type rj45
no negotiation auto
crypto map V3PN-CM ! Applies crypto map to GE 0/2
!
...
!
ip access-list extended V3PN-SITE1
permit gre host 100.100.100.1 host 25.25.25.1
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

Som e key point s t o not ice in t he WAN aggregat or designs, as det ailed in Exam ple 16- 12 ,
include t hese:

I P CEF is required t o be run in dist ribut ed m ode on t his plat form ( Cisco 7500) .

A six- class V3PN policy has been deployed on t he WAN aggregat ors edge.

WRED in conj unct ion wit h queue- lim it t uning is support ed on dist ribut ed plat form s ( such as
t he Cisco 7500) , alt hough it current ly is not support ed on nondist ribut ed plat form s ( unt il
t he release of Consist ent QoS Behavior, as described in Chapt er 13 ) .
 Because t he cent ral sit e's link t o t he I SP is a ( very) high- speed ATM PVC ( OC3) , no t uning
of t he Tx- ring is required.

I SAKMP t raffic is not encrypt ed and t hus can be classified by a sim ple ACL ( UDP port 500) .

Ex a m ple 1 6 - 1 2 . Ca se St u dy Ex a m ple : Pa r t 2 , W AN Aggr e ga t or QoS

D e sign

!
hostname WAG-1
!
ip cef distributed ! Distributed platform
!
class-map match-all VOICE
match ip dscp ef ! VoIP
class-map match-any CALL-SIGNALING
match ip dscp cs3 ! New Call-Signaling
match ip dscp af31 ! Old Call-Signaling
class-map match-any INTERNETWORK-CONTROL
match ip dscp cs6 ! IP Routing
match access-group name IKE ! References ISAKMP ACL
class-map match-all TRANSACTIONAL-DATA
match ip dscp af21 af22 ! Transactional-Data
class-map match-all SCAVENGER
match ip dscp cs1 ! Scavenger
!
!
policy-map SIX-CLASS-V3PN-EDGE
class VOICE
priority percent 33 ! VoIP gets 33% LLQ
class CALL-SIGNALING
bandwidth percent 5 ! Call-Signaling provisioning
class INTERNETWORK-CONTROL
bandwidth percent 5 ! Control Plane provisioning
class TRANSACTIONAL-DATA
bandwidth percent 31 ! Transactional-Data provisioning
random-detect dscp-based ! WRED + QL tuning supported on 7500
queue-limit 20 ! Optional: Anti-Replay tuning
class SCAVENGER
bandwidth percent 1 ! Scavenger class is throttled
queue-limit 1 ! Optional: Anti-Replay tuning
class class-default
bandwidth percent 25 ! Best Effort needs BW guarantee
random-detect dscp-based ! WRED + QL tuning supported on 7500
queue-limit 16 ! Optional: Anti-Replay Tuning
!
...
!
interface GigabitEthernet1/0/0
description VPN HEADEND SUBNET
ip address 100.100.100.3 255.255.255.0
duplex auto
speed auto
media-type rj45
 no negotiation auto
!
...
!
interface ATM1/1/0
no ip address
no atm ilmi-keepalive
!
interface ATM1/1/0.100 point-to-point
description ATM OC3 TO ISP
ip address 20.20.20.1 255.255.255.252
pvc 0/100
vbr-nrt 149760 149760
service-policy out SIX-CLASS-V3PN-EDGE ! MQC policy applied to PVC
!
!
...
!
ip access-list extended IKE ! ISAKMP ACL
permit udp any eq isakmp any eq isakmp
!

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce

Som e key point s t o not ice in t he V3PN branch rout er designs, as det ailed in Exam ple 16- 13 ,
include t hese:

A six- class V3PN policy has been deployed on t he branch VPN access edge.

WRED is not support ed in conj unct ion wit h queue- lim it t uning ( for Ant i- Replay) on t hese
nondist ribut ed plat form s.

Even t hough Fram e Relay is being used as t he access m edium , no shaping is required
because all sit es are running at full ( T1) port speeds.

QoS Pre- Classify is enabled on bot h crypt o m ap ent ries and t unnel int erfaces, t o enhance
per for m ance.

The delay param et er has been t uned on t he t unnel int erfaces t o influence t he rout ing
prot ocol's ( EI GRP, in t his inst ance) choice for prim ary and secondary t unnels.

Ex a m ple 1 6 - 1 3 . Ca se St u dy Ex a m ple : Pa r t 3 , V3 PN Br a n ch Rou t e r

D e sign

!
hostname V3PN-BRANCH-1
!
ip cef
!
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key SECRETKEY address 100.100.100.1
crypto isakmp key SECRETKEY address 100.100.100.2
!
!
crypto ipsec transform-set V3PN-TS esp-3des esp-sha-hmac
!
crypto map V3PN-CM 10 ipsec-isakmp
set peer 100.100.100.1
set transform-set V3PN-TS
match address V3PN-HE1
qos pre-classify ! Enables QoS Pre-Classify
crypto map V3PN-CM 20 ipsec-isakmp
set peer 100.100.100.2
set transform-set V3PN-TS
match address V3PN-HE2
qos pre-classify ! Enables QoS Pre-Classify
!
crypto map static-map local-address Serial0/0
!
!
class-map match-all VOICE
match ip dscp ef ! VoIP
class-map match-any CALL-SIGNALING
match ip dscp cs3 ! New Call-Signaling
match ip dscp af31 ! Old Call-Signaling
class-map match-any INTERNETWORK-CONTROL
match ip dscp cs6 ! IP Routing
match access-group name IKE ! References ISAKMP ACL
class-map match-all TRANSACTIONAL-DATA
match ip dscp af21 af22 ! Transactional-Data
class-map match-all SCAVENGER
match ip dscp cs1 ! Scavenger
!
!
policy-map SIX-CLASS-V3PN-EDGE
class VOICE
priority percent 33 ! VoIP gets 33% LLQ
class CALL-SIGNALING
bandwidth percent 5 ! Call-Signaling provisioning
class INTERNETWORK-CONTROL
bandwidth percent 5 ! Control Plane provisioning
class TRANSACTIONAL-DATA
bandwidth percent 31 ! Transactional-Data provisioning
queue-limit 20 ! Optional: Anti-Replay tuning
class SCAVENGER
bandwidth percent 1 ! Scavenger class is throttled
queue-limit 1 ! Optional: Anti-Replay tuning
class class-default
bandwidth percent 25 ! Best Effort needs BW guarantee
queue-limit 16 ! Optional: Anti-Replay Tuning
 !
!
...
!
interface Tunnel101
ip address 10.100.101.2 255.255.255.252
delay 50000
qos pre-classify ! Enables QoS Pre-Classify
tunnel source 25.25.25.1
tunnel destination 100.100.100.1
crypto map V3PN-CM
!
interface Tunnel102
ip address 10.100.102.2 255.255.255.252
delay 60000
qos pre-classify ! Enables QoS Pre-Classify
tunnel source 25.25.25.1
tunnel destination 100.100.100.2
crypto map V3PN-CM
!
!
interface FastEthernet0/0
description V3PN-BRANCH-1 INTRANETS
ip address 172.16.1.1 255.255.255.0
duplex auto
speed auto
!
...
!
interface Serial0/0
description FRAME RELAY T1 TO ISP
bandwidth 1536
ip address 25.25.25.1 255.255.255.252
service-policy output SIX-CLASS-V3PN-EDGE ! MQC policy applied to T1 int
encapsulation frame-relay
frame-relay interface-dlci 100
crypto map V3PN-CM
!
...
!
ip access-list extended IKE ! ISAKMP ACL
permit udp any eq isakmp any eq isakmp
!
ip access-list extended V3PN-HE1
permit gre host 25.25.25.1 host 100.100.100.1
!
ip access-list extended V3PN-HE2
permit gre host 25.25.25.1 host 100.100.100.2
!

Verificat ion com m ands:

sh ow policy
 sh ow policy in t e r fa ce

Som e key point s t o not ice in t he V3PN t eleworker rout er designs, as det ailed in Exam ple 16- 14 ,
include t hese:

I n t his exam ple, an ADSL link ( of 1536 kbps downlink and 384 kbps uplink) is provisioned
for V3PN. Because of t he overhead of DSL, VoI P bandwidt h is provisioned for 150 kbps
( which can support eit her G.711 or G.729) .

A hierarchical QoS policy is set t o shape ( and queue wit hin t he shaped rat e) t o 70 percent
of t he uplink's rat e and is applied t o t he Et hernet int erface facing t he DSL m odem .

WRED is not support ed in conj unct ion wit h queue- lim it t uning ( for Ant i- Replay) on t hese
nondist ribut ed plat form s.

NAT t ransparency is disabled globally t o reduce bandwidt h overhead.

QoS Pre- Classify is enabled on t he crypt o m ap t o enhance perform ance.

A split - t unneling policy is provisioned on t eleworker rout ers, det erm ining " work- relat ed"
t raffic as being dest ined t o privat e int ranet addresses.

TCP MSS is adj ust ed on bot h Et hernet int erfaces t o m it igat e serializat ion delay.

Ex a m ple 1 6 - 1 4 . Ca se St u dy Ex a m ple : Pa r t 4 , Te le com m u t e r Rou t e r

!
hostname TELEWORKER-V3PN-1
!
ip cef
ip inspect name CBAC tcp
ip inspect name CBAC udp
ip inspect name CBAC ftp
!
crypto isakmp policy 1
encr 3des
group 2
!
!
crypto ipsec transform-set V3PN-TELEWORKER-TS esp-3des esp-sha-hmac
no crypto ipsec nat-transparency udp-encaps ! Disables NAT Transparency
!
crypto map V3PN-TELEWORKER-CM 1 ipsec-isakmp
set peer 100.100.100.1
set peer 100.100.100.2
set transform-set V3PN-TELEWORKER-TS
match address CORP-INTRANET
qos pre-classify ! Enables QoS Pre-Classify
!
!
class-map match-all VOICE
match ip dscp ef ! VoIP
class-map match-any INTERNETWORK-CONTROL
match ip dscp cs6 ! IP Routing
 match access-group name IKE ! References ISAKMP ACL
class-map match-any CALL-SIGNALING
match ip dscp cs3 ! New Call-Signaling
match ip dscp af31 ! Old Call-Signaling
class-map match-all CORPORATE
match access-group name CORPORATE ! References CORPORATE ACL
!
!
policy-map V3PN-SPLIT-TUNNEL
class VOICE
priority 150 ! Encrypted G.711 over DSL (PPPoE/AAL5)
class INTERNETWORK-CONTROL
bandwidth percent 5 ! Control Plane provisioning
class CALL-SIGNALING
bandwidth percent 5 ! Call-Signaling provisioning
class CORPORATE
bandwidth percent 25 ! "Work-related" traffic provisioning
queue-limit 15 ! Optional: Anti-Replay Tuning
class class-default
fair-queue
queue-limit 15 ! Optional: Anti-Replay Tuning
!
!
policy-map SHAPE-384-ADSL-UPLINK
class class-default
shape average 268800 2688 ! Shapes to 70% of 384 kbps ADSL uplink
service-policy V3PN-SPLIT-TUNNEL ! Nested V3PN split-tunnel policy
!
...
!
interface Ethernet0
description TELEWORKER 1 INTRANET
ip address 10.200.1.1 255.255.255.248
ip inspect CBAC in
ip tcp adjust-mss 542 ! TCP MSS value tuned for slow-link
!
interface Ethernet1
description ETHERNET LINK TO DSL MODEM
ip address dhcp
service-policy output SHAPE-384-ADSL-UPLINK ! Shaping + Queuing
ip tcp adjust-mss 542 ! TCP MSS value tuned for slow-link
duplex auto
no cdp enable
crypto map V3PN-TELEWORKER-CM
!
!
ip access-list extended CORP-INTRANET ! CORP-INTRANET ACL (RFC 1918)
permit ip 10.200.1.0 0.0.0.7 10.0.0.0 0.255.255.255
permit ip 10.200.1.0 0.0.0.7 172.16.0.0 0.15.255.255
permit ip 10.200.1.0 0.0.0.7 192.168.0.0 0.0.255.255
!
ip access-list extended IKE
permit udp any eq isakmp any eq isakmp ! ISAKMP ACL
!
ip access-list extended CORPORATE ! CORPORATE ACL (VPN Head-ends)
permit esp any 100.100.100.0 0.0.0.3
 !

Verificat ion com m ands:

sh ow policy

sh ow policy in t e r fa ce
Summary
I PSec VPNs, t he m ost com m only deployed VPN solut ions t oday, are found in t hree m ain
cont ext s: sit e- t o- sit e VPNs, t eleworker VPNs, and rem ot e- access VPNs. The overlaying of QoS
t echnologies on t op of I PSec VPNs is dubbed V3PN, for voice- and video- enabled Virt ual Privat e
Net works. This chapt er present ed considerat ions and design recom m endat ions for V3PN
deploym ent s in sit e- t o- sit e and t eleworker cont ext s. A sum m ary of t he design recom m endat ions
for encrypt ion and QoS for sit e- t o- sit e and t eleworker I PSec V3PNs is illust rat ed in Figure 16- 31.

Figu r e 1 6 - 3 1 . I PSe c V3 PN Sit e - t o- Sit e a n d Te le w or k e r D e sign

Su m m a r y Com pa r ison

Som e sit e- t o- sit e considerat ions t hat were discussed include t he bandwidt h im plicat ions of
various I PSec m odes of operat ions and t he incom pat ibilit y of cRTP and I PSec. The int errelat ion
of I PSec VPN logical hub- and- spoke t opologies and t he effect t hese have on spoke- t o- spoke
delay budget s also were exam ined. Subsequent ly, t he ToS byt e preservat ion m echanism was
overviewed along wit h t he QoS Pre- Classify Cisco I OS Soft ware feat ure, which allows for t he
classificat ion of packet s already encrypt ed ( on t he sam e rout er) t hrough ACLs. QoS and Ant i-
Replay im plicat ions t hen were discussed, illust rat ing how QoS policies t hat reorder packet s
pot ent ially can exacerbat e Ant i- Replay drops ( an I PSec m essage- int egrit y m echanism ) .
Techniques for m inim izing such undesired QoS/ Ant i- Reply int eract ion effect s, such as reducing
t he queue lengt h of dat a queues, were present ed. Next , t he need for cont rol plane provisioning
was highlight ed, along wit h basic designs for doing so.

Several sit e- t o- sit e QoS m odels were det ailed, ranging from a six- class V3PN QoS m odel t o a
com plex 11- class V3PN QoS Baseline m odel. WAN aggregat or considerat ions specific t o I PSec
VPN deploym ent s were exam ined next , including QoS provisioning for I PSec over privat e WANs,
per- t unnel hierarchical shaping and queuing, and recom m endat ions for decoupled VPN
headend/ WAN aggregat ion deploym ent m odels, where encrypt ion and QoS are perform ed on
different rout ers.

At t ent ion t hen shift ed t o t eleworker scenarios and t he t hree m ain t eleworker deploym ent
m odels: t he I nt egrat ed Unit Model, t he Dual- Unit Model, and t he I nt egrat ed Unit + Access
Model. The t wo m ain broadband m edia t ypes, DSL and cable, were broken down t o ascert ain t he
bandwidt h- provisioning im plicat ions of each m edia. Neit her DSL nor ( DOCSI S 1.0) cable includes
any m echanism for serializat ion delay m it igat ion, so TCP m axim um segm ent - size t uning was
considered as an alt ernat ive m echanism t o achieve t his. Split - t unneling designs, t o address
spouse- and- child requirem ent s, were int roduced.

Teleworker V3PN designs t hen were det ailed for I nt egrat ed Unit and Dual- Unit m odels over DSL,
in addit ion t o an I nt egrat ed Unit + Access Model solut ion for cable.

The chapt er concluded wit h a case st udy ( which, likewise, concluded t he case st udies present ed
in each previous design chapt er) highlight ing how an ent erprise could overlay QoS on t op of an
exist ing sit e- t o- sit e I PSec VPN t o enable a V3PN. Addit ionally, a solut ion was present ed for a
business- ready t eleworker.
Further Reading
St andar ds:

RFC 1321, " The MD5 Message- Digest Algorit hm " : ht t p: / / www.iet f.org/ rfc/ rfc1321.t xt .

RFC 1918, " Address Allocat ion for Privat e I nt ernet s" : ht t p: / / www.iet f.org/ rfc/ rfc1918.t xt .

RFC 2104, " HMAC: Keyed- Hashing for Message Aut hent icat ion" :
ht t p: / / www.iet f.org/ rfc/ rfc2104.t xt .

RFC 2401, " Securit y Archit ect ure for t he I nt ernet Prot ocol" :
ht t p: / / www.iet f.org/ rfc/ rfc2401.t xt .

RFC 2402, " I P Aut hent icat ion Header" : ht t p: / / www.iet f.org/ rfc/ rfc2402.t xt .

RFC 2403, " The Use of HMAC- MD5- 96 Wit hin ESP and AH" :
ht t p: / / www.iet f.org/ rfc/ rfc2403.t xt .

RFC 2404, " The Use of HMAC- SHA- 1- 96 wit hin ESP and AH" :
ht t p: / / www.iet f.org/ rfc/ rfc2404.t xt .

RFC 2405, " The ESP DES- CBC Cipher Algorit hm wit h Explicit I V" :
ht t p: / / www.iet f.org/ rfc/ rfc2405.t xt .

RFC 2406, " I P Encapsulat ing Securit y Payload ( ESP) " : ht t p: / / www.iet f.org/ rfc/ rfc2406.t xt .

RFC 2407, " The I nt ernet I P Securit y Dom ain of I nt erpret at ion for I SAKMP" :
ht t p: / / www.iet f.org/ rfc/ rfc2407.t xt .

RFC 2408, " I nt ernet Securit y Associat ion and Key Managem ent Prot ocol ( I SAKMP) " :
ht t p: / / www.iet f.org/ rfc/ rfc2408.t xt .

RFC 2409, " The I nt ernet Key Exchange ( I KE) " : ht t p: / / www.iet f.org/ rfc/ rfc2409.t xt .

RFC 2410, " The NULL Encrypt ion Algorit hm and I t s Use wit h I PSec" :
ht t p: / / www.iet f.org/ rfc/ rfc2410.t xt .

RFC 2411, " I P Securit y Docum ent Roadm ap" : ht t p: / / www.iet f.org/ rfc/ rfc2411.t xt .

RFC 2412, " The OAKLEY Key Det erm inat ion Prot ocol" : ht t p: / / www.iet f.org/ rfc/ rfc2412.t xt .

Books:

Kaeo, Merike. Designing Net work Securit y . I ndianapolis: Cisco Press, 2003.

Malik, Saadat . Net work Securit y Principles and Pract ices . I ndianapolis: Cisco Press, 2002.

Mason, Andrew. Cisco Secure Virt ual Privat e Net works . I ndianapolis: Cisco Press, 2001.
Cisco I OS docum ent at ion:

I P Securit y and Encrypt ion overview ( Cisco I OS Release 12.2) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fsecur_c/ fipsenc/ scfencov.h
.

Configuring I PSec net work securit y ( Cisco I OS Release 12.2) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fsecur_c/ fipsenc/ scfipsec.h
.

Configuring I nt ernet Key Exchange Securit y Prot ocol ( Cisco I OS Release 12.2) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fsecur_c/ fipsenc/ scfike.ht m

Prefragm ent at ion for I PSec VPNs ( Cisco I OS Release 12.2[ 13] T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft prefrg.ht m

Qualit y of service for Virt ual Privat e Net works ( Cisco I OS Release 12.2[ 2] T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ ft qosvpn.ht m

Low- lat ency queuing ( LLQ) for I PSec encrypt ion engines ( Cisco I OS Release 12.2[ 13] T) :
ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ llqfm .ht m

I PSec NAT t ransparency ( Cisco I OS Release 12.2[ 13] T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 13/ ft ipsnat .ht m

I PSec and qualit y of service feat ure ( Cisco I OS Release 12.3[ 8] T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios123/ 123newft / 123t / 123t _8/ gt qosips.ht m

Configuring broadband access ( Cisco I OS Release 12.2) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122cgcr/ fwan_c/ wcfppp.ht m

PPP over Et hernet Client ( Cisco I OS Release 12.2[ 2] T) :

ht t p: / / www.cisco.com / univercd/ cc/ t d/ doc/ product / soft ware/ ios122/ 122newft / 122t / 122t 2/ ft pppoec.ht m
QoS "At-A-Glance" Summaries
[View full size image]

[View full size image]

[View full size image]

[View full size image]

[View full size image]

[View full size image]

[View full size image]

[View full size image]

[View full size image]

[View full size image]

Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

10-Class WAN Edge Model

1P2Q1T queuing and dropping
1P2Q2T queuing and dropping
1P3Q1T mode
1P3Q1T queuing and dropping
1P3Q8T queuing and dropping
1P7Q8T queuing and dropping
1PxQyT queuing
2Q2T queuing and dropping
show qos info config 2q2 tx verification command
show qos info runtime verification command
show queuing interface verification command
33 percent limit (sum of LLQs)
4Q1T mode
802.11e
802.1D, classes of service
802.1Q/p, translating to and from DSCP
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

access control entries (ACEs)

access layer
Catalyst 3550 QoS design
policers
access point (AP)
access switches
configuring to conditionally trust CoS
access switches (campus networks)
access-edge QoS design
access-edge trust boundaries
Conditionally Trusted Endpoint Models 2nd
Trusted Endpoint Models
Untrusted Endpoint Models
access-edge utilization
ACEs (access control entries)
ACLs, MQC-based class maps
adaptive jitter buffers
admission control
admission criterion (Real-Time class)
ADSL (Asynchronous Digital Subscriber Lines)
aggregate policers (Catalyst 6500)
aggregation routers
algorithms
MDRR
queuing
CBWFQ
comparison
PQ-WFQ
priority queuing
WFQ
shaping
token bucket algorithms
analog gateways
Anti-Replay drops 2nd
Anti-Replay functionality (IPSec QoS design)
any-to-any videoconferencing
AP (access point)
applications
data applications by class
Mission-Critical Data
Streaming-Video
unidirectional
architectures (MPLS VPNs). [See MPLS VPN-QoS design]
Assured Forwarding
asymmetric links
Asynchronous Digital Subscriber Lines (ADSL)
ATM
 PVC bundles
Tx-rings
WAN edge link-specific QoS design
ATM-FR SIW
high-speed links
medium-speed links
slow-speed links
very-high-speed links
ATM CLP (ATM Cell-Loss Priority bit)
ATM inverse multiplexing over ATM
ATM networks
ATM PVC bundles, slow-speed
ATM-FR SIW (ATM-to-Frame Relay Service Interworking)
slow-speed links
attacks (worms)
authentication
ESP
IPSec
AutoQoS (Automatic QoS)
Enterprise feature
evolution of
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

backbone
bandwidth
Catalyst 4500
Eight-Class Model
guarantees 2nd
ISDN
provisioning 2nd
Best-Effort class
Real-Time class
teleworker V3PN QoS
VoIP
WAN aggregators
reservations
RSVP
statements, on class default
VoIP streams
Bc (committed burst) 2nd
Be (excess burst) 2nd
bearer traffic
jitter
latency
loss
Best-Effort class
bandwidth provisioning
enabling WRED
Best-Effort data
best-effort networks
best-effort service
binary eponential backoff
branch router QoS design
case study
LAN edge
branch-to-campus classification and marking
DSCP-to-CoS remapping
NBAR known worm classification and policing
WAN edge
branch-to-branch traffic
branch-to-campus classification and marking
NBAR application classification
source or destination IP address marking
TCP/UDP classification
broadband
serialization mitigation through TCP maximum segment size tuning
split tunneling
UDP-based video applications
broadband-access technologies
cable
 DSL
buffer space
buffers
Bulk Data class
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

cable
DOCSIS 1.1 specification
Integrated Unit + Access Models
overhead
uplink connections
CAC (call admision control)
CallManager locations CAC
defined
GK CAC
local CAC tools
measurement-based CAC tools
prering CAC
resource-based CAC tools
RSVP
tool categories
VoIP CAC through RSVP
Call-Signaling
campus QoS design
MPLS VPN CE QoS design considerations
Call-Signaling traffic, jitter
CallManager environments
CallManager locations CAC
CallManager services
campus Catalyst switches
campus networks
oversubscription ratios
QoS design. [See campus QoS design]
traffic
underutilization
campus QoS design
access switches
Call-Signaling
case study
Catalyst 2950
Conditionally Trusted IP Phone + PC Advanced Model
Conditionally Trusted IP Phone + PC Basic Model
queuing
Trusted Endpoint Model
Untrusted Multiapplication Server Model
Untrusted PC with SoftPhone Model
Catalyst 2970/3750
Conditionally Trusted IP Phone + PC Basic Model
enabling/disabling QoS
queuing/dropping
Trusted Endpoint Model
Unconditionally Trusted IP Phone + PC Basic Model
Untrusted PC with SoftPhone Model
 Untrusted Server Model
Catalyst 3550
Conditionally Trusted IP Phone + PC Advanced Model
Conditionally Trusted IP Phone + PC Basic Model
queuing and dropping
Trusted Endpoint Model
Untrusted PC with SoftPhone Model
Untrusted Server Model
Catalyst 4500
Conditionally Trusted IP Phone + PC Advanced Model
Conditionally Trusted IP Phone + PC Basic Model
queuing
show qos dbl command
show qos interface command
show qos maps dscp tx-queue command
Trusted Endpoint Model
Untrusted PC with SoftPhone Model
Untrusted Server Model
Catalyst 6500 2nd
1P2Q1T queuing and dropping
1P2Q2T queuing and dropping
1P3Q1T queuing and dropping
1P3Q8T queuing and dropping
1P7Q8T queuing and dropping
2Q2T queuing and dropping
CatOS defaults/recommendations
Conditionally Trusted IP Phone + PC Advanced Model
Conditionally Trusted IP Phone + PC Basic Model
congestion avoidance
PFC3 distribution-layer Per-User Microflow Policing
queuing/dropping
show port qos command
Trusted Endpoint Model
Untrusted PC with SoftPhone Model
defining designs
DoS/worm mitigation
Untrusted Server Model
WAN aggregator/branch router handoff
campus-to-branch traffic
CAR (committed access rate) 2nd
case studies
branch router QoS design
campus QoS design
IPSec VPN QoS design
telecommuter router
V3PN branch router design
VPN headend design
WAN aggregator QoS design
MPLS VPN QoS design
CE routers
P routers
PE routers
WAN aggregation router QoS design
Catalyst 2950
classification, marking, and mapping
Conditionally Trusted IP Phone + PC Advanced Model
 Conditionally Trusted IP Phone + PC Basic Model
CoS-to-DSCP map
DSCP-to-CoS map
policing and markdown
queuing 2nd
show wrr-queue bandwidth command
show wrr-queue cos-map command
range keyword
Trusted Endpoint Model
Untrusted Multiapplication Server Model
show class-map and show policy-map verification commands
show mls masks qos verification command
show mls qos interface policers verification command
Untrusted PC with SoftPhone Model
vs. Catalyst 3550
Catalyst 2970 2nd
classification, marking, and mapping
Conditionally Trusted IP Phone + PC Basic Model
enabling/disabling QoS
policing and markdown
queuing/dropping 2nd
Trusted Endpoint Model
Unconditionally Trusted IP Phone + PC Basic Model
Untrusted PC with SoftPhone Model
Untrusted Server Model
Catalyst 3550 2nd
classification, marking, and mapping
Conditionally Trusted IP Phone + PC Advanced Model
Conditionally Trusted IP Phone + PC Basic Model
DSCP mutation maps
policing and markdown
queuing and dropping 2nd
show mls qos interface buffers verification command
show mls qos interface queuing verification command
Trusted Endpoint Model
Untrusted PC with SoftPhone Model
Untrusted Server Model
Catalyst 3750 2nd
classification, marking, and mapping
Conditionally Trusted IP Phone + PC Advanced Model
Conditionally Trusted IP Phone + PC Basic Model
enabling/disabling QoS
policing and markdown
queuing/dropping 2nd
Trusted Endpoint Model
Untrusted PC with SoftPhone Model
Untrusted Server Model
Catalyst 4500 2nd
classification, marking, and mapping
Conditionally Trusted IP Phone + PC Advanced Model
Conditionally Trusted IP Phone + PC Basic Model
DSCP-to-queue maps
enabling QoS
policing and markdown
queuing
queuing and dropping
 show qos dbl command
show qos interface command
show qos maps dscp tx-queue command
Trusted Endpoint Model
Untrusted PC with SoftPhone Model
Untrusted Server Model
Catalyst 6500 2nd 3rd
CatOS
1P2Q1T queuing and dropping
1P2Q2T queuing and dropping
1P3Q1T queuing and dropping
1P3Q8T queuing and dropping
1P7Q8T queuing and dropping
2Q2T queuing and dropping
Conditionally Trusted IP Phone + PC Advanced Model
Conditionally Trusted IP Phone + PC Basic Model
congestion avoidance
defaults/recommendations
queuing/dropping
Trusted Endpoint Model
Untrusted PC with SoftPhone Model 2nd
Untrusted PC with SoftPhone Model Model
Untrusted Server Model
classification, marking and mapping
enabling QoS
PFC QoS
PFC3 distribution-layer Per-User Microflow Policing
policing and markdown
queuing and dropping
Supervisor 720
Trusted Endpoint Model
show port qos command
VLAN-based QoS
WRED-drop thresholds
Catalyst 6500 configuring microflow policers
Catalyst QoS Models
classification
policing
queuing
CatOS defaults/recommendations
CBR (constraint-based routing)
CBWFQ (Class-Based Weighted Fair Queuing) 2nd
CDP (Cisco Discover Protocol)
CE bit
CE design
CE routers, MPLS VPN QoS design case study
CEF (Cisco Express Forwarding)
Channel Utilization field
CIR (committed information rate)
Frame Relay networks
policing behavior based on percentages
Cisco 12000 routers
priority command
queuing
Cisco Discover Protocol (CDP)
Cisco Express Forwarding (CEF)
class default policing
class selectors
class-based Frame Relay traffic shaping
class-based marking
class-based policing 2nd
benefits
single-rate three-color marker/policer
two-rate three-color marker/policer
class-based shaping
Class-Based Weighted Fair Queuing (CBWFQ)
classes of service (802.1D)
classification 2nd
branch-to-campus
Catalyst 2950
Catalyst 2970
Catalyst 3550
Catalyst 3750
Catalyst 4500
Catalyst 6500
Catalyst QoS models
NBAR application
source or destination IP addresses
TCP/UDP
tools
MQC-based class maps
NBAR
Code Red
codecs (frame-based)
CodeRedv2
color-aware policing
color-blind policing
commands
commit all command
dbl policy command
frame-relay fragment command
match protocol dlsw command
max-reserved-bandwidth
mls qos cos override interface command
ping vrf command
ppp multilink links minimum command
priority-queue out command
qos dbl command
qos map dscp to tx-queue command
show atm bundle command
show atm pvc command
show atm vc command
show class-map verification command
show controllers command
show frame-relay fragment command
show ima interface atm command
show ip access-list command
show ip bgp vpnv4 all command
show ip nbar map command
show ip rsvp interface command
show ip rsvp neighbor command
show mls masks qos verification command
 show mls qos command
show mls qos interface buffers verification command
show mls qos interface policers verification command
show mls qos interface queuing verification command
show mls qos interface statistics verification command
show mls qos maps command
show mls qos maps dscp-output-q command
show mpls interface command
show mpls traffic-eng topology command
show mpls traffic-eng tunnels command
show mpls traffic-eng tunnels summary command
show policy command
show policy interface command
show policy interface verification command
show policy-map verification command
show port qos commands
show ppp multilink command
show qos acl verification command
show qos command
show qos dbl command
show qos info config 2q2 tx verification command
show qos info runtime verification command
show qos interface command
show qos maps dscp tx-queue command
show qos maps verification command
show qos policer verification command
show qos statistics verification command
show queuing interface verification command
show wrr-queue bandwidth command
show wrr-queue cos-map command
trust-device command
tx-queue command
tx-ring-limit command
wrr-queue bandwidth command
wrr-queue cos-map command
wrr-queue dscp-map interface configuration command
wrr-queue queue-limit command
wrr-queue queue-limit interface command
commit all command
committed access rate (CAR) 2nd
committed burst rate (Bc 2nd
committed information rate. [See CIR]
compatibility (802.1D classes of service)
compression
G.729 voice compression
hardware compression
Conditionally Trusted Endpoint Models (Trust Boundaries) 2nd
Conditionally Trusted IP Phone + PC Advanced Model
Catalyst 2970/3750
Catalyst 3550
Catalyst 4500
Catalyst 6500
Conditionally Trusted IP Phone + PC Basic Model 2nd
Catalyst 2970/3750
Catalyst 3550
Catalyst 4500
 Catalyst 6500
configuring
1P2Q2T queuing
1P3Q1T queuing
1P3Q1T queuing model
1P3Q8T queuing
1P7Q8T queuing
Catalyst 2950 switches
Conditionally Trusted IP Phone + PC Advanced Model
Conditionally Trusted IP Phone + PC Basic Model
queuing
Trusted Endpoint Model
Untrusted Multiapplication Server Model 2nd
Untrusted PC with SoftPhone Model
CoS-to-queue mapping (Catalyst 3550)
cRTP for ATM links
DSCP mutation
FR-VATS
individual policer on Catalyst 4500
IPSec authentication
MCMP for an ISDN interface
microflow policing on Catalyst 6500
MLP LFI
MPLS DS-TE
MPLS per-VPN TE
PFC
policing
QoS on Cisco APs
queuing (Catalyst 2950)
RSVP
SRR shaping and sharing weights on Catalyst 2970/3750
trust on Catalyst 6500
VLAN-based QoS on Catalyst 6500
WRED
configuring WRED-drop thresholds
confirming traffic
congestion avoidance
Catalyst 6500
tools
DSCP-based WRED
explicit congestion notification
RED
WRED
congestion-management tools
converged networks
connecting trusted endpoints
consistent QoS behavior
constraint-based routing (CBR)
constricted channels
control plane provisioning
control plane QoS
IP routing
network management
controlled load 2nd
controlling traffic
branch-to-branch
 campus-to-branch
converged networks
congestion-management tools
QoS
convergence
Core Best-Effort class
Core Critical Data class
core QoS considerations
aggregate bandwidth overprovisioning
DiffServ in the backbone
platform specific considerations
Three-Class Provider-Core Model
MPLS traffic engineering
basic
MPLS DS-TE
MPLS per-VPN TE
Core Real-Time class
CoS values, assigning queues
CoS-to-DSCP maps
Catalyst 2950
Catalyst 6500
CQ (custom queuing)
cRTP (RTP header compression)
class-based header compression
configuring for ATM links
formats
Cisco propriety format
IETF format
IPHC
formats and encapsulation summary
incompatibility with IPSec
Layer 2 encapsulation protocol support
ATM
Frame Relay
HDLC
PPP
LLQ
policing and shaping
tunnels
crypto engine
cTCP (TCP header compression)
custom queuing (CQ)
CWmax 2nd
CWmin 2nd 3rd
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

data
applications by class
QoS
Best-Effort data
DLSw+
locally defined Mission-Critical Data
Transactional Data/Interactive Data
data frames (802.11)
data VLANs (DVLANs)
data-link connection identifiers (DLCIs)
data-link switching plus (DLSw+)
datagrams
DBL (dynamic buffer limiting)
DCF (Distributed Coordination Function)
Interframe Spaces
random backoffs
DDR (dial-on-demand routing)
DDT (delay to dial tone)
delay budgets (IPSec VPNs)
delay to dial tone (DDT)
delay variation [See also jitter]
deploying
IPSec VPNs via DMVPN
LFI tools
policers
QoS designs
Untrusted Server Model on Catalyst 2950
designing QoS
classification and marking principles
deployment
DoS and worm mitigation principles
policing and markdown principles
queuing and dropping principles
destination IP address classification
DHCP, translating to Frame Relay DE bit
dial-on-demand routing (DDR)
Differentiated Services code points (DSCPs)
DiffServ
advantages of DiffServ model
deploying in backbone
platform specific considerations
Three-Class Provider-Core Model
DIFS
Digital Subscriber Line. [See DSL]
disabling
flow control
native DLSw+ ToS markings
 QoS on Catalyst 2970/3750
Discard class placeholder
Distributed Coordination Function (DCF)
distributed platform frame relay links
distributed platform QoS
distributed traffic shaping (DTS) 2nd
Distributed-Platform/Consistent QoS Behavior QoS Baseline Model
distribution layer, Catalyst 3550 QoS design
DLCIs (data-link connection identifiers)
dlsw tos disable command
dlsw tos map command
DLSw+ (data-link switching plus)
DMVPNS (Dynamic Multipoint Virtual Private Networks)
DOCSIS 1.1 specification 2nd
dominating links (VoIP)
DoS attacks
campus network mitigation strategies
mitigation principles
downstream QoS
drop thresholds (Catalyst 2970 and 3750)
dropping
Anti-Replay
Catalyst 2970
Catalyst 3550 2nd
Catalyst 3750
Catalyst 4500
Catalyst 6500 2nd
1P2Q1T queuing and dropping
1P2Q2T queuing and dropping
1P3Q1T queuing and dropping
1P3Q8T queuing and dropping
1P7Q8T queuing and dropping
2Q2T queuing and dropping
DSCP-to-CoS maps
Catalyst 2950
Catalyst 3550
DSCP-to-CoS remapping
DSCP-to-queue maps
Catalyst 4500
DSCPs (Differentiated Services code points)
DSCP-based WRED
mutation maps (Catalyst 3550)
DSL (AAL5 + PPPoE) overhead
DSL (Digital Subscriber Line)
Integrated Unit + Access Models
Integrated Unit/Dual-Unit models
uplink connections
DSLAM (DSL Access Multiplexer)
DTS (distributed traffic shaping) 2nd
Dual-Unit Model 2nd
DVLANs (data VLANs)
dynamic buffer limiting (DBL)
Dynamic Multipoint Virtual Private Networks (DMVPNs)
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

EAP (Extensible Authentication Protocols)

ECN bit
ecn keyword
ECT bit
EDCF (Enhanced Distributed Coordination Function)
EI (Enhanced Image)
Eight-Class Model
Eight-Class Site-to-Site V3PN Model
EMI (Enhanced Multilayer Software Image)
enabling
MLPoATM
QoS
Catalyst 2970/3750
Catalyst 4500
Catalyst 6500
encryption, delay budgets
end users' network expectations
end-to-end QoS
endpoints 2nd
Enhanced Distributed Coordination Function (EDCF) 2nd
Enhanced Image (EI)
Enhanced Multilayer Software Image (EMI)
enterprise resource planning (ERP)
ERP (enterprise resource planning)
errors (Anti-Replay)
ESP authentication
Ethernet 802.1Q tunnels
Ethernet 802.1Q/p
Ethernet downstream
evolution of QoS
exceeding traffic
excess burst rate (Be) 2nd
expedited forwarding
explicit congestion notification
Extensible Authentication Protocols (EAP)
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

FIFO Tx-ring
Five-Class Model
Five-Class Provider-Edge Model
MPLS VPN CE QoS design considerations
Fixed Slot Time Default values
flow control, disabling
Four-Class Provider-Edge Model
MPLS VPN CE QoS design considerations
FR-VATS (Frame Relay voice-adaptive traffic shaping)
fragment sizes
distributed platform Frame Relay links
WAN link fragmentation
Frame Relay
cRTP
Frame-Relay fragmentation
FRF.11.1 and FRF.12.1
LFI for Frame Relay/ATM service interworking
PVCs
PIPQ
WAN edge link-specific QoS design
Bc
Be
CIR
distributed platform links
high-speed links
medium-speed links
slow-speed links
Frame Relay bundles
Frame Relay DE bit, translating to from DSCHP
Frame Relay Dual-FIFO
Frame Relay traffic shaping (FRTS)
Frame Relay voice-adaptive traffic shaping (FR-VATS)
frame-based codecs
Frame-Relay DE bit
frame-relay fragment command
FRF.11.1 and FRF.12.1 fragmenting
FRF.8
FRTS (Frame Relay traffic shaping)
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

G.729 voice compression

G.SHDSL
gatekeepers (GK)
generic traffic shaping
GK (gatekeepers)
GK CAC
global synchronization
goals of convergence
guaranteed load service
guaranteed services
guarantees (bandwidth) 2nd 3rd
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

handoffs (WAN aggregator/branch router)

hardware compression
hardware crypto engines
HDLC (High-Level Data Link Control) 2nd
header-compression techniques
class-based header compression
formats,
Cisco propriety format
IETF format
IPHC
Layer 2 encapsulation protocol support
ATM
Frame Relay
HDLC
PPP
RTP header compression (cRTP)
standards
TCP header compression (cTCP)
hierarchical class-based shaping
hierarchical policing
High Link-Speed QoS Class Models
Distributed-Platform/Consistent QoS Behavior QoS Baseline Model
Eight-Class model
QoS Baseline Model
High-Level Data Link Control (HDLC)
high-speed ATM links
high-speed frame relay links
high-speed leased lines
pkts matched statistics
show policy interface command
show ppp multilink command
horizontal separation of traffic
how qos dbl command
hub routers
WAN aggregators
hub-and-spoke topology 2nd
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

IANA (Internet Assigned Numbers Authority)

IETF (Internet Engineering Task Force)
IETF format
IMA (ATM inverse multiplexing over ATM)
Integrated Services
Integrated Unit + Access Model 2nd
Integrated Unit Model 2nd
Interactive Data
Interactive-Video
Interframe Spaces
Internal DSCP value
Internet Assigned Numbers Authority (IANA)
interoperability (RSVP)
IntServ 2nd
IP configuring stations
IP header compression format (IPHC)
IP Precedence
IP routing
ip rsvp bandwidth command
IP RTP header compression
IP RTP priority
IP telephony
IP ToS (IP type of service)
IP VPN Multiservice
IPHC (IP header compression format)
IPSec
authentication
incompatibility with cRTP
LLQ
prefragmentation
IPSec Encryption Engines
IPSec QoS design
anti-replay functionality
Anti-Replay functionality
bandwidth provisioning
control plane provisioning
cRTP and IPSec incompatibility
delay budget increases
headend VPN edge QoS options for site-to-site V3PNs
packet overhead increases
pre-encryption queuing
prefragmentation
QoS Pre-Classify
site-to-site V3PN
IPSec transport mode (encrypting an IP GRE tunnel)
IPSec tunnel mode (encrypting an IP GRE tunnel)
IPSec tunnel mode (No IP GRE tunnel)
 site-to-site V3PN QoS models
Eight-Class Site-to-Site V3PN Model
Six-Class Site-to-Site V3PN Model
teleworker V3PN QoS
asymmetric links and unidirectional QoS
bandwidth provisioning
broadband-access technologies
deployment models
topologies
ToS byte preservation
VPNs
IPSec transport mode (encrypting an IP GRE tunnel)
IPSec tunnel mode (encrypting an IP GRE tunnel)
IPSec tunnel mode (No IP GRE tunnel)
IPSec VPN QoS design (case study)
VPNs
telecommuter router
V3PN branch router design
VPN headend design
WAN aggregator QoS design
IPSec-encrypted G.729 packets
ISDN
WAN edge link-specific QoS design
CallManager CAC limitations
MLP packet reordering
variable bandwidth
voice and data on multiple ISDN B channels
ITDP/UDP ports (CallManager environments)
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

jitter 2nd 3rd

jitter buffers
adaptive
underruns
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

keywords
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

LAN edge QoS design

branch-to-campus classification and marking
DSCP-to-CoS remapping
NBAR known worm classification and policing
LANs
QoS for wired vs. wireless
switching environments
latency
converged networks
VoIP
Layer 2
access (MPLS VPN CE QoS design)
marking fields
ATM CLP
Frame-Relay DE bit
MPLS EXP bits
queuing mechanisms
queuing subsystems
Layer 3 marking fields
Layer 3 queuing mechanisms
CBWFQ
legacy
LLQ 2nd 3rd 4th 5th
ATM PVC bundles
bandwidth provisioning
cRTP
IPSec
LFI
MLP and Frame Relay bundles
operation
policing
VoFR
Layer 3 queuing subsystems
leased lines
high-speed
medium-speed
slow-speed
legacy Layer 3 queuing mechanisms
LFI (Link Fragmentation and Interleaving)
for Frame Relay/ATM service interworking
LLQ
tools 2nd
line card queuing structures (catalyst 6500)
link-specific tools 2nd
links
asymmetric
ATM
 high-speed
medium-speed
slow-speed
very-high-speed
capacity
Eight-Class Site-to-Site V3PN Model
Frame Relay networks
distributed platform
high-speed
medium-speed
slow-speed
speed
VoIP, dominating
LLQ (low-latency queuing) 2nd 3rd 4th 5th
ATM PVC bundles
LLQ
bandwidth provisioning
cRTP
IPSec
LFI
MLP and Frame Relay bundles
operation
policing
VoFR
VoIP and multiple levels of data
local CAC tools
locally defined Mission-Critical Data
loss (voice)
low link speeds (WANs)
low-latency queuing. [See LLQ]
LS VPN QoS design
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

mapping
Catalyst 2950
Catalyst 2970
Catalyst 3550
Catalyst 3750
Catalyst 4500
Catalyst 6500
IP Precedence
Mapping Models (enterprise-to-service provider)
Five-Class Provider-Edge Model
Four-Class Provider-Edge Model
Three-Class Provider-Edge Model
markdown
Catalyst 2950
Catalyst 2970
Catalyst 3550
Catalyst 3750
Catalyst 4500
Catalyst 6500
Catalyst QoS Models
markers (policers as)
marking 2nd
branch-to-campus
Catalyst 2970
Catalyst 3550
Catalyst 3750
Catalyst 4500
Catalyst 6500
DLSw+ traffic
MPLS VPN CE QoS design considerations
tools
class-based marking
class-based policing
Layer 2 marking fields
Layer 3 marking fields
Layer 3 tunnel marking tools
translating Layer 2 and Layer 3 packet markings
voice gateway packet marking
traffic
match protocol commands
match protocol dlsw command
max-reserved-bandwidth command
max-reserved-bandwidth interface command
MCMP (Multiclass Multilink PPP)
MDRR (modified-deficit round-robin) algorithm
mean opinion scores (MOS)
measurement-based CAC tools
Media Gateway Control Protocol (MGCP)
Medium Link-Speed QoS Class Models
medium-speed ATM links
medium-speed frame relay links
medium-speed leased lines
MGCP (Media Gateway Control Protocol)
Microflow policers
Mission-Critical Data applications
mitigating serialization delay
MLP (Multi Point-to-Point Protocol)
MLP bundles
MLP LFI (Multilink PPP Link Fragmentation and Interleaving)
MLP packets, reordering
MLPoATM 2nd
MLPoFR (MLP over Frame Relay)
mls prefix keyword
mls qos cos override command
modified-deficit round-robin (MDRR) algorithm
modular QoS CLI based class maps 2nd
Modular QoS Command-Line Interface (MQC)
MOS (mean opinion scores)
MPLS DiffServ Tunneling modes
Pipe Mode
Short Pipe Mode
Uniform Mode
MPLS EXP bits
MPLS Traffic Engineering 2nd
basic
MPLS DS-TE
configuring
P-router configuration
show ip bgp vpnv4 all command
show mpls traffic-eng topology command
MPLS per-VPN TE
ping vrf tunnels command
show ip rsvp interface command
show ip rsvp neighbor command
show mpls interface command
show mpls traffic-eng tunnels command
show mpls traffic-eng tunnels summary command
MPLS VPN CE QoS design
special considerations
Five-Class Provider-Edge Model
Four-Class Provider-Edge Model
Layer 2 access
marking/re-marking
service-provider service-level agreements
TCP and UDP
Three-Class Provider-Edge Model
voice and call signaling
voice and video
MPLS VPN QoS design
case studies
CE routers
P routers
PE routers
 core considerations
aggregate bandwidth overprovisioning
DiffServ in the backbone
MPLS traffic engineering
need for QoS
MQC (Modular QoS Command-Line Interface)
MQC-based class maps
ACLs
MQC/ACL classification
Multi Point-to-Point Protocol (MLP)
multiaction policing
Multiclass Multilink PPP (MCMP)
multilink fragment-delay 10 command
Multilink PPP Link Fragmentation and Interleaving (MLP LFI)
multiple priority classes
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

NAT transparency feature overhead

NBAR (Network-Based Application Recognition) 2nd
application classification
known-worm classification and policing
Code Red
CodeRedv2
future worms
NIMDA
policing worms
RPC DCOM/W32MS Blaster
Sasser worm
SQL Slammer
Packet Description Language Modules (PDLMs)
protocol classification
RTP payload classification
NBAR exchange PDLM
NBAR netbios PDLM
NBMA (nonbroadcast multiaccess)
nested hierarchical policing
Network-Based Application Recognition. [See NBAR]
networks
Best-Effort
end user expectations
management (QoS)
VoIP design considerations
NIMDA
nonbroadcast multiaccess (NBMA)
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

out-of-profile traffic
overprovisioning LLQ traffic
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

P routers 2nd
P-to-P design
packets
MLP, reordering
overhead increases (IPSec QoS design)
packetization delay
prefragmentation
PAK_priority 2nd 3rd
PAK_priority flag
PBR (policy-based routing)
PBS (peak burst size)
PDLMs (NBAR Packet Description Language Modules) 2nd
PE QoS considerations
Enterprise-to-Service Provider Mapping Models
Five-Class Provider-Edge Model
Four-Class Provider-Edge Model
Mapping Models
Three-Class Provider-Edge Model
MPLS DiffServ Tunneling modes
Pipe Mode
Short Pipe Mode
Uniform Mode
PE routers
PE-to-P design
peak burst size (PBS)
peak information rate (PIR) 2nd
peak rate
peak-rate shaping
per-Port/per-VLAN policing
percent keyword
percentage-based policing
percentage-based shaping
performance (cRTP)
PFC, configuring
PFC3
PFC3 distribution-layer Per-User Microflow Policing (Catalyst 6500)
PIFS
ping vrf command
Pipe Mode
PIPQ (PVC Interface Priority queuing)
PIR (peak information rate) 2nd
pkts matched statistics
placeholders.
PoC (proof-of-concept) tests
police statements
policers 2nd
as markers
 CAR
class-based
benefits
single-rate three-color marker/policer
two-rate three-color marker/policer
color-aware policing
color-blind policing
compared to shapers
default
deploying
DoS/worm mitigation (campus networks)
hierarchical policing
microflow
multiaction policing
percentage-based policing
policies
access switches
LAN switching environments
on P routers
on routers
policing
Catalyst 2950
Catalyst 2970
Catalyst 3550
Catalyst 3750
Catalyst 4500
Catalyst 6500
Catalyst QoS Models
class-based
cRTP
LLQ
worms
policy-based routing (PBR)
policy-map
porting software QoS to hardware
ports
presetting those used by SoftPhone
trust states
PPP
ppp multilink links minimum command
PPPoFR (PPP over Frame Relay)
PQ (priority queuing)
PQ-WFQ
pre-encryption queuing
prefragmentation
IPSec transport mode
IPSec tunnel mode
prering CAC
prioritization
priority classes, police statements
priority queuing
priority-queue out command
propagation delay
protecting video
Protocol Description Language Module (PDLM) 2nd
provisioning (bandwidth)
proxies
PVC Interface Priority queuing (PIPQ)
PVCs
bundling
fragmenting
VoFR
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

QBSS IE (QoS basic service set information element)

QoS
access-edge design
branch routers
campus networks. [See campus QoS design]
Catalyst Models. [See Catalyst QoS models]
Cisco APs
classification and marking principles
control plane
IP routing
network-management
converged networks
data
Best-Effort data
DLSw+
locally defined Mission-Critical Data
Transactional Data/Interactive Data
deploying
design principles
DiffServ
disabling on Catalyst 2970/3750
DoS and worm mitigation principles
enabling on Catalyst 2970/3750
end-to-end
evolution of 2nd 3rd
guidance
historical perspective
IntServ
link-specific tools 2nd
models
need for on MPLS VPNs
network expectations of end users
policies required on WAN aggregators
policing and markdown principles
porting software QoS to hardware
queuing and dropping principles
Scavenger class
simplifying
AutoQoS
cross-platform feature consistency
default behavior
MQC
QoS Baseline
tool set 2nd
upstream vs. downstream
video
interactive
 streaming
VoIP
bearer traffic
Call-Signaling traffic
WAN edge link-specific
ATM
ATM-FR SIW
Frame Relay
ISDN
leased lines
wireless LANs vs. wired LANs
QoS Baseline Model 2nd
class deployment
QoS design principles
recommendations
QoS basic service set (QBSS)
qos dbl command
QoS Design Guide
QoS group placeholder
qos map dscp to tx-queue command
QoS Pre-Classify
QoS preclassify feature
queuing 2nd
algorithms
CBWFQ
comparison
PQ-WFQ
priority queuing
WFQ
buffer space
Catalyst 2950
Catalyst 2950 switches
show wrr-queue bandwidth command
show wrr-queue cos-map command
Catalyst 2970 2nd
Catalyst 3550 2nd
show mls qos interface buffers verification command
show mls qos interface queuing verification command
Catalyst 3750
Catalyst 4500 2nd
show qos dbl command
show qos interface command
show qos maps dscp tx-queue command
Catalyst 6500 2nd
1P2Q1T queuing and dropping
1P2Q2T queuing and dropping
1P3Q1T queuing and dropping
1P3Q8T queuing and dropping
1P7Q8T queuing and dropping
l2Q2T queuing and dropping
line card queuing structures
Catalyst QoS models 2nd
Cisco 12000 routers
default queue limits
Layer 2 queuing mechanisms
Layer 3 queuing mechanisms
 CBWFQ
legacy
LLQ
LLQ
policies on routers
reducing queue limits
software (WAN aggregators)
transmit ring (Tx-ring)
Tx-ring
queuing tools
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

radio downstream QoS

radio upstream QoS
RAI (resource activity indicator)
random backoffs
random-detect command
ecn keyword
re-marking
MPLS VPN CE QoS design considerations
traffic
Real-Time class
admission criterion
bandwidth provisioning
RED (Random Early Detection)
reservations
resource activity indicator (RAI)
resource-based CAC tools
RFC 2205
RFC 2597
RFC 3168
RFC 3246
ROHC (robust header compression)
routers
branch routers
hub routers
P routers
policies
roles in WANs
WAN aggregators
bandwidth provisioning
distributed platform QoS
IP RTP header compression
link speeds
PAK_priority
required QoS policies
serialization
software queuing
Tx-ring tuning
routing
DDR
packets-per-second capability
RPC DCOM/W32/MS Blaster
RSVP
admission control
CAC
configuring
cRTP
interoperability
 LLQ
overview
scalability
security
service types
VoIP CAC through RSVP
RSVP PATH message
RSVP RESV message
RSVP-DiffServ integration
RTP header compression (cRTP)
class-based header compression
formats
Cisco propriety format
IETF format
IPHC
formats and encapsulation summary
Layer 2 encapsulation protocol support
Frame Relay
HDLC
PPP
policing and shaping
tunnels
RTP payload classification
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

SAR (Segmentation and Reassembly) engine

SAs (security associations)
Sasser worm
scalability
IPSec VPN QoS design case study
RSVP
Scavenger class
DoS and worm mitigation
QoS
Scavenger-class QoS strategy
SCCP (Skinny Call Control Protocol)
scheduling tools
SCSP mutation maps (Catalyst 6500)
security
RSVP
worms
security associations (SAs)
Serial Line IP (SLIP) protocol
serialization
delay
WAN aggregators
servers
service provider service-level agreements
service types (RSVP)
service-policy
services for CallManagers
shapers 2nd
ATM networks
class-based Frame Relay traffic shaping
class-based shaping
compared to policers
cRTP
distributed traffic shaping (DTS)
Frame Relay traffic shaping (FRTS)
Frame Relay voice-adaptive traffic shaping
generic traffic shaping
peak-rate shaping
shaping algorithms
Short Pipe Mode
show atm bundle command
show atm pvc command
show atm vc command
show class-map verification command
show controllers command
show frame-relay fragment command
show ima interface atm command
show ip access-list command
show ip bgp vpnv4 all command
show ip nbar port-map command
show ip rsvp interface command
show ip rsvp neighbor command
show mls masks qos verification command
show mls qos command
show mls qos interface buffers verification command
show mls qos interface policers verification command
show mls qos interface queuing verification command
show mls qos interface statistics verification command
show mls qos interface verification command
show mls qos map
show mls qos maps command
show mls qos maps dscp-output-q command
show mpls interface command
show mpls traffic-eng topology command
show mpls traffic-eng tunnels command
show mpls traffic-eng tunnels summary command
show policy command
show policy interface command
high-speed leased lines
slow-speed leased lines
show policy interface verification command
show policy-map interface command
show policy-map verification command
show port qos commands
show ppp multilink command
show qos acl verification command (Catalyst 6500)
show qos command
show qos info config 2q2 tx verification command
show qos info runtime verification command
show qos interface command
show qos maps dscp tx-queue command
show qos maps verification command (Catalyst 6500)
show qos policer verification command (Catalyst 6500)
show qos statistics verification command (Catalyst 6500)
show queuing interface verification command
show wrr-queue bandwidth command
show wrr-queue cos-map command
SI (Standard Image)
SIFS
site-to-site V3PN
headend VPN edge QoS options
IPSec transport mode (encrypting an IP GRE tunnel)
IPSec tunnel mode (encrypting an IP GRE tunnel)
IPSec tunnel mode (No IP GRE tunnel)
QoS models
Eight-Class Site-to-Site V3PN Model
Six-Class Site-to-Site V3PN Model
Six-Class Site-to-Site V3PN Model
Skinny Call Control Protocol (SCCP)
SLIP (Serial Line IP) protocol
Slow Link-Speed QoS Class Models
slow-speed ATM links
ATM PVC bundles
show atm bundle command
 show atm vc command
show atm pvc command
Tx-rings
slow-speed Frame Relay links
slow-speed leased lines
show interface command
show policy interface command
slow-speed links (ATM-FR SIW)
SMI (Standard Multilayer Software Image)
SoftPhone
software queuing (WAN aggregators)
source IP address classification
speed (links)
split tunneling
SQL Slammer
Standard Image (SI)
Standard Multilayer Software Image (SMI)
state-machine synchronization
streaming video 2nd
strict-priority queuing rule
sum of LLQs
Supervisor 720
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

table map feature

tail drops
TAM (time-division multiplexing)
TCP
and UDP
global synchronization behavior
packet loss
TCP/UDP classification
teleworker V3PN QoS
asymmetric links and unidirectional QoS
bandwidth provisioning
cable overhead
DSL (AAL5 + PPPoE) overhead
NAT transparency feature overhead
broadband serialization mitigation through TCP maximum segment size tuning
broadband-access technologies
cable
DSL
business-ready teleworker design
Deployment Models 2nd
Dual-Unit Model
Integrated Unit + Access Model 2nd
Integrated Unit Model
Integrated Unit/Dual Unit Models
split tunneling
Three-Class (Voice and Data) Model
Three-Class Provider-Core Model
Three-Class Provider-Edge Model 2nd
time-division multiplexing (TDM)
token bucker algorithms
topologies
IPSec QoS design
split tunnel
ToS (type of service)
byte preservation
reflection
total drops statistics
traffic
branch-to-branch
campus networks
campus-to-branch
classification
conforming
data
defined by QoS Baseline
DLSw+, marking
exceeding
 handoffs
horizontal separation of
IP
LLQ
marking/remarking 2nd
out-of-profile
PAK_priority
prioritization
Scavenger
Scavenger-class QoS strategy
unpoliced classes
vertical separation of
violating
worm mitigation in Scavenger class
Transactional Data
translating Layer 2 and Layer 3 packet markings
802.1Q/p to and from DSCP
DHCP to Frame Relay DE bit
IP precedence to ATM/Frame Relay PVCs
table map feature
transmit queuing (Catalyst 6500)
transmit ring (Tx-ring)
troubleshooting
class naming
DoS attacks (campus networks)
worms (campus networks)
trust boundaries
access-edge
Conditionally Trusted Endpoint Models 2nd
Trusted Endpoint Models 2nd
Untrusted Endpoint Models
defined
trust states
configuring trust on Catalyst 6500
trust-device command
trusted endpoint models 2nd
Catalyst 2970/3750
Catalyst 3550
Catalyst 4500
Catalyst 6500
show port qos command
trusted endpoints, connecting
tunnel DiffServ
tunneling
cRTP
modes (MPLS DiffServ)
Pipe Mode
Short Pipe Mode
Uniform Mode
split tunneling
tx-queue command
tx-ring-limit command
Tx-rings (transmit rings) 2nd
ATM
tuning
type of service (ToS)
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

UBR (unspecified bit rate)

UDP and TCP
underruns (jitter buffers)
unidirectional applications
unidirectional QoS
Uniform Mode
unspecified bit rate (UBR)
Untrusted Endpoint Models (trust boundaries)
Untrusted Multiapplication Server Model
show class-map and show policy-map verification commands
show mls masks qos verification command
show mls qos interface policers verification command
Untrusted PC with SoftPhone Model
Catalyst 2950
Catalyst 2970/3750
Catalyst 3550
Catalyst 4500
Catalyst 6500
show qos acl verification command
show qos maps verification command
show qos policer verification command
show qos statistics verification command
Untrusted Server Model
Catalyst 2970/3750
Catalyst 3550
Catalyst 4500
Catalyst 6500
uplink connections (DSL and cable)
upstream QoS
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

variable network delay. [See jitter]

VBR (variable bit-rate)
verification command
verifying
ATM IMA group
tag-switching configuration (MPLS per-VPN TE)
vertical separation of traffic
very-high-speed ATM links
video
MPLS VPN CE QoS design considerations
QoS
Interactive-Video
Streaming-Video
Streaming-Video, protecting
surveillance systems
videoconferencing
any-to-any
gateways and systems
videoconferencing rate
violating traffic
viruses
VoFR (Voice over Frame Relay)
voice
gateway packet marking
MPLS VPN CE QoS design considerations
VVLANs
Voice and Data WAN Edge Model
Voice over Frame Relay (VoFR)
voice VLANs (VVLANs)
VoIP (Voice over IP)
bandwidth
bandwidth provisioning
Call-Signaling traffic
campus networks
header-compression techniques
class-based header compression
formats
Layer 2 encapsulation protocol support
RTP header compression (cRTP)
standards
TCP header compression (cTCP)
LLQ
over ATM
over Ethernet to VoIP over a WAN
over MPLS
QoS
bearer traffic
 Call-Signaling traffic
traffic, dominating links
VPNs (virtual private networks)
IPSec QoS design
MPLS VPN QoS design 2nd [See also MPLS VPN QoS design]
VVLANs (voice VLANs)
Index
[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

WAN aggregation router QoS design

case study
WAN aggregator/branch router handoff
WAN aggregators 2nd
bandwidth provisioning
distributed platform QoS
IP RTP header compression
link speeds
PAK_priority
required QoS policies
serialization
software queuing
Tx-ring tuning
WAN Edge Classification and Provisioning Models
High Link-Speed QoS Class Models
Distributed-Platform/Consistent QoS Behavior QoS Baseline Model
Eight-Class Model
QoS Baseline Model
Slow/Medium Link-Speed QoS Class Models
Five-Class Model
Three-Class (Voice and Data) Model
WAN edge link-specific QoS design
ATM
high-speed links
medium-speed links
slow-speed links
very-high-speed links
ATM-FR SIW
Frame Relay
Bc
Be
CIR
distributed platform links
high-speed links
medium-speed links
slow-speed links
ISDN
CallManager CAC limitations
MLP packet reordering
variable bandwidth
voice and data on multiple ISDN B channels
leased lines
high-speed
medium-speed
slow-speed
WAN edge QoS design
WANs 2nd
 link fragmentation and interleaving
fragment sizes
Frame Relay fragmentation 2nd
IPSec prefragmentation
Multilink PPP Link Fragmentation and Interleaving (MLP LFI)
low link speeds
routers roles in
Weighted Random Early Detection. [See WRED]
WFQ
wireless access points
wireless IP phones
WLANs (wireless LANs)
basic service set information element
QoS
worms
campus network mitigation strategies
CodeRedv2
compared to viruses
mitigation in Scavenger class
mitigation principles
NIMDA
policing
preparing for future worms
RPC DCOM/W32/MS Blaster
Sasser
SQL Slammer
WRED (Weighted Random Early Detection)
Catalyst 3550
DSCP-based WRED
ECN
enabling on the Best-Effort class
thresholds
WRED-drop thresholds (Catalyst 6500)
wrr-queue bandwidth command
wrr-queue cos map command
wrr-queue dscp-map interface configuration command
wrr-queue queue-limit command
wrr-queue queue-limit interface command