Вы находитесь на странице: 1из 768

Junos Enterprise Routing

D
o
SECOND EDITION
Junos Enterprise Routing
Pctcr Southuick, Doug Marschkc, and Harry Rcynolds
Beijing Cambridge Farnham Kln Sebastopol Tokyo
Junos Enterprise Routing, Second Edition
Ly Petei Southwick, Doug Maischke, anu Haiiy Reynolus
Copyiight 2011 Petei Southwick, Doug Maischke, anu Haiiy Reynolus. All iights ieseiveu.
Piinteu in the Uniteu States ol Ameiica.
PuLlisheu Ly O`Reilly Meuia, Inc., 1005 Giavenstein Highway Noith, SeLastopol, CA 95+72.
O`Reilly Looks may Le puichaseu loi euucational, Lusiness, oi sales piomotional use. Online euitions
aie also availaLle loi most titles (http://ny.sajariboo|son|inc.con). Foi moie inloimation, contact oui
coipoiate/institutional sales uepaitment: (S00) 99S-993S oi corporatcorci||y.con.
Editor: Mike Loukiues
Development Editor: Patiick Ames
Production Editor: Teiesa Elsey
Copyeditor: Genevieve u`Entiemont
Proofreader: Teiesa Elsey
Indexer: Lucie Haskins
Cover Designer: Kaien Montgomeiy
Interior Designer: Daviu Futato
Illustrators: RoLeit Romano anu ReLecca Demaiest
Printing History:
Maich 200S: Fiist Euition.
]une 2011: Seconu Euition.
Nutshell HanuLook, the Nutshell HanuLook logo, anu the O`Reilly logo aie iegisteieu tiauemaiks ol
O`Reilly Meuia, Inc. junos Entcrprisc Routing, the image ol Tengmalm`s owl, anu ielateu tiaue uiess aie
tiauemaiks ol O`Reilly Meuia, Inc.
Many ol the uesignations useu Ly manulactuieis anu selleis to uistinguish theii piouucts aie claimeu as
tiauemaiks. Vheie those uesignations appeai in this Look, anu O`Reilly Meuia, Inc., was awaie ol a
tiauemaik claim, the uesignations have Leen piinteu in caps oi initial caps.
Vhile eveiy piecaution has Leen taken in the piepaiation ol this Look, the puLlishei anu authois assume
no iesponsiLility loi eiiois oi omissions, oi loi uamages iesulting liom the use ol the inloimation con-
taineu heiein.
ISBN: 97S-1-++9-39S63-7
LSI
13079S5113
Table of Contents
About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
1. Junos in the Enterprise Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Intiouuction to ]unos Enteipiise Routing 1
]unos Oveiview 2
]unos Releases +
CLI Review 6
Routing Featuies 9
Switching Featuies 12
Secuiity Featuies 1+
Routing Platloims 17
Speeus anu Feeus 1S
MX Seiies 3D Univeisal Euge Routeis 19
Switching Platloims 21
SRX Seiies Seivices Gateways 23
Conclusion 2+
Exam Topics 25
Chaptei Review Questions 25
Chaptei Review Answeis 26
2. Enterprise Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Design Guiuelines 29
Technological Goals ol Netwoik Design 30
Legacy Netwoik Design 33
The New Netwoik 37
Dual Stai Inteinet Access 39
Existing Inteinet Access Design 39
Design Goals anu Constiaints +0
Solution: Dual Inteinet Access Design +1
v
Data Centei anu Disastei Recoveiy (DR) Aichitectuie +3
Multitiei Data Centei Design +3
Goals anu Constiaints +5
Solution: Data Centei Design +6
Campus Aichitectuie +9
Legacy Campus BackLone +9
Goals anu Constiaints +9
Solution: Campus Netwoik 50
Conclusion: Design Best Piactices 52
3. Juniper Switching and Routing Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Enteipiise Netwoik Roles 53
Scieening Routei 5+
Secuiity Gateway 55
Inteinet Boiuei Routei 59
Coie Routeis 6+
Access Routei 66
Multiseivices Gateway 69
Device Limitations 69
L2 anu L3 Deployments 71
Link Aggiegation Gioups 71
VPLS Implementation 72
Miscellaneous Piotocols 7+
All-in-One Veisus Components 75
Chaptei Review Questions 77
Chaptei Review Answeis 77
4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Peimanent Inteilaces 79
Tiansient Inteilaces S1
Inteilace Naming S1
Inteilace Piopeities S9
Physical Piopeities 90
Logical Piopeities 90
Inteilace Conliguiation Examples 92
GigaLit Etheinet Inteilace 92
GigaLit Etheinet with VLAN Tagging 9+
T1 Inteilace with Cisco HDLC Encapsulation 96
Seiial Inteilace with PPP 96
Seiial Inteilace with Fiame Relay 9S
ADSL Using PPPoE ovei ATM 99
MLPPP 100
Aggiegateu Etheinet 101
vi | Table of Contents
GRE 103
VRRP 10+
Inteilace TiouLleshooting 10S
Auuiess Conliguiation Issues 10S
Encapsulation Mismatches 111
Path MTU Issues 11+
Loopeu Inteilaces 115
Conclusion 117
Exam Topics 117
Chaptei Review Questions 117
Chaptei Review Answeis 119
5. Protocol Independent Properties and Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 121
Piotocol Inuepenuent Piopeities 122
Static, Aggiegate, anu Geneiateu Routes 122
GloLal Route Pieleience 129
Maitian Routes 132
Routing TaLles anu RIB Gioups 133
Routei ID anu Antonymous System NumLei 13S
Summaiy ol Piotocol-Inuepenuent Piopeities 1+0
Routing Policy 1+0
Vhat Is a Routing Policy, anu Vhen Do I Neeu One? 1+1
Vheie anu How Is Policy Applieu? 1+1
Policy Components 1++
Policy Match Ciiteiia anu Actions 1+6
Route Filteis 1+S
Delault Policies 153
Auvanceu Policy Concepts 15+
Summaiy ol Routing Policy 160
Conclusion 161
Exam Topics 161
Chaptei Review Questions 162
Chaptei Review Answeis 165
6. Interior Gateway Protocols and Migration Strategies . . . . . . . . . . . . . . . . . . . . . . . 167
IGP Oveiview 16S
Routing Inloimation Piotocol 169
Open Shoitest Path Fiist 171
Enhanceu Inteiioi Gateway Routing Piotocol 1S0
IGP Summaiy 1S+
RIP Deployment Scenaiio 1S+
Existing RIP Conliguiation 1S6
Baseline Opeiation 1SS
Table of Contents | vii
Summaiy ol RIP Reguiiements 1S9
Entei ]unipei Netwoiks 190
Conliim RIP Opeiation: Ale anu Lagei 195
Conliim RIP: ]unipei Netwoiks to Cisco Systems Integiation 196
The PioLlem 202
RIP Deployment Summaiy 205
IGP Migiation 205
IGP Migiation: Common Technigues anu Conceins 206
IGP Migiation Mouels 207
The Oveilay Mouel 207
The ReuistiiLution Mouel 209
The Integiation Mouel 211
IGP Migiation Summaiy 212
Oveilay Migiation Scenaiio: RIP to OSPF 213
RIP-to-OSPF Migiation: Cutovei to OSPF 221
Beloie You Go, Can You Set Up Aiea 1 Real Quick? 22+
RIP Migiation with the Oveilay Mouel Summaiy 229
EIGRP-to-OSPF Migiation 229
Mutual Route ReuistiiLution 230
Conliim EIGRP/OSPF Mutual Route ReuistiiLution 236
EIGRP-to-OSPF Migiation Summaiy 2+3
Conclusion 2+3
Exam Topics 2++
Chaptei Review Questions 2++
Chaptei Review Answeis 2+7
7. Border Gateway Protocol and Enterprise Routing Policy . . . . . . . . . . . . . . . . . . . . . 249
Vhat Is BGP? 2+9
Intei-AS Routing 250
BGP Route AttiiLutes 251
BGP Path Selection 253
Inteinal anu Exteinal BGP 256
Scaling IBGP with Route Rellection 25S
BGP anu the Enteipiise 261
Vhen Shoulu an Enteipiise Run BGP? 261
ASN PoitaLility 262
Asymmetiic Link Speeu Suppoit 263
Vhich Routeis Shoulu Run IBGP? 26+
No Tiansit Seivices 265
The Impact ol Accepting Specilics Veisus a Delault liom Youi Pioviuei 266
Summaiy ol Enteipiise BGP Reguiiements 267
BGP Deployment: Asymmetiic Loau Balancing 26S
Valiuate Baseline Opeiation 270
viii | Table of Contents
Conliguie Geneiateu Route 271
Conliguie Initial BGP Peeiing 275
Conliguie Initial BGP Policy 2S2
Use BGP loi Asymmetiic Loau Balancing 2S+
Initial BGP Peeiing Summaiy 291
Enteipiise Routing Policy 292
InLounu anu OutLounu Routing Policies 292
Common Policy Design Ciiteiia 292
Enteipiise Policy Summaiy 29+
Multihome Beei-Co 295
Implement Beei-Co`s OutLounu Policy 297
EBGP Peeiing to AS +20 29S
Expoit Beei-Co Aggiegate to Boignet 302
IBGP Peeiing Vithin AS 12S2 30+
Conliim OutLounu Policy Opeiation 313
Dual-Homing anu OutLounu Policy Summaiy 317
InLounu Policy 31S
AS Path Piepenu to Inlluence Nonaujacent AS Path Selection 322
Use Communities to Inlluence Peei AS 327
BGP InLounu Policy Summaiy 33+
Conclusion 33+
Exam Topics 335
Chaptei Review Questions 335
Chaptei Review Answeis 33S
8. Access Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Secuiity Concepts 3+1
Summaiy ol Secuiity Concepts 3+3
Secuiing Access to the Routei 3+3
Usei Authentication 3+3
Remote Access 351
Summaiy ol Access Secuiity 355
Fiiewall Filteis 355
Filtei Piocessing 356
Filtei Match Conuitions 357
Filtei Actions 360
Applying a Filtei 361
Case Stuuy: Tiansit Filteis 361
Case Stuuy: LoopLack Filteis 36+
Policeis 36S
Summaiy ol Fiiewall Filteis anu Policeis 373
Spool Pievention (uRPF) 37+
Summaiy ol Spool Pievention 3S0
Table of Contents | ix
Monitoiing the Routei 3S0
Syslog 3S0
SNMP 3S5
NTP 3S7
Is NTP Really Voiking? 3S9
Summaiy ol Routei Monitoiing 390
Conclusion 390
Exam Topics 391
Chaptei Review Questions 391
Chaptei Review Answeis 393
9. Junos Layer 2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
]unos Seivices 395
Layei 2 Seivices 39S
Multilink PPP 39S
CRTP +02
Multilink Fiame Relay +0+
GRE +07
Etheinet Aggiegation +09
Switching Seivices +10
Auuitional Seivice Options +12
Layei 2 Tunneling Piotocol (L2TP) +12
Real-Time Peiloimance Monitoiing (RPM) +12
Data Link Switching (DLSw) +1+
Flow Monitoiing +16
Tunnel Seivices +17
Conclusion +17
Exam Topics +1S
Chaptei Review Questions +1S
Chaptei Review Answeis +19
10. Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Vhat Is IP CoS, anu Vhy Do I Neeu It? +21
Vhy IP Netwoiks Neeu CoS +22
CoS Teims anu Concepts +25
IP CoS Summaiy +3S
IP Dilleientiateu Seivices +3S
IP ToS +3S
Entei IP Integiateu Seivices ++0
IP Dilleientiateu Seivices ++2
DillSeiv Teiminology ++3
DillSeiv Summaiy ++6
CoS CapaLilities ++6
x | Table of Contents
Input Piocessing ++7
Output Piocessing +53
Delay Bullei Size +5S
Scheuulei Maps +59
Dilleiences Between ]unos CoS +63
]unos Soltwaie CoS Delaults +70
CoS Summaiy +71
DillSeiv CoS Deployment anu Veiilication +71
Vhy Not Test CoS with Contiol-Plane-Geneiateu Tiallic? +72
Conliguie DillSeiv-Baseu CoS +75
An Alteinative Piioiity-Baseu Scheuulei Appioach +S+
Deline RED Pioliles +S6
Veiily DillSeiv-Baseu CoS +91
DillSeiv Deployment Summaiy 503
Auaptive Shapeis anu Viitual Channels 50+
Conliguie Auaptive Shaping 50+
Viitual Channels 505
Auaptive Shaping anu Viitual Channel Summaiy 511
Conclusion 511
Exam Topics 512
Chaptei Review Questions 512
Chaptei Review Answeis 51+
11. IP Multicast in the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Vhat Is Multicast? 517
Multicast Applications 51S
Multicast Teiminology anu Concepts 520
Mapping IP Multicast to Link Layei Multicast 52+
Multicast Teiminology Summaiy 53+
Multicast Piotocols 53+
Gioup Management Piotocols 53+
PIM 53S
Multicast Piotocol Summaiy 5++
PIM Spaise Moue: Static RP 5++
Valiuate the Baseline IGP Foiwaiuing Path 5+5
Conliguie PIM Spaise Moue with Static RP 5+7
A Voiu on Multicast Client Options 556
PIM Spaise Moue with Static RP Summaiy 56S
Conliguie PIM Spaise Moue with Bootstiap RP 56S
TiouLleshoot a Bootstiap PioLlem 57+
PIM Spaise Moue with Bootstiap RP Summaiy 5S0
PIM-Baseu Anycast-RP 5S0
Conliguie Anycast-RP 5S2
Table of Contents | xi
PIM Spaise Moue with Anycast-RP Summaiy 590
Conclusion 590
Exam Topics 590
Chaptei Review Questions 591
Chaptei Review Answeis 593
12. Junos Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
]unos Soltwaie anu Secuiity 595
Do I Neeu a Routei oi a Secuiity Device? 596
Secuiity-Baseu Enteipiise Scenaiio 596
Packet- Veisus Flow-Baseu Piocessing 597
Aichitectuie Changes 59S
]unos Secuiity Summaiy 601
Unueistanuing ]unos Opeiational Moues 601
Secuiity Featuies 606
Netwoik Auuiess Tianslation 619
Viitual Piivate Netwoiks 62+
Attack Detection anu Pievention 632
Clusteiing 635
Conclusion 6+1
Exam Topics 6+1
Chaptei Review Questions 6+1
Chaptei Review Answeis 6+2
A. Junos Layer 3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
B. Upgrading Junos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
xii | Table of Contents
About the Authors
Peter V. Southwick has spent the last 30 yeais in telecommunicationsuesigning,
implementing, anu tiaining on voice, uata, anu secuiity systems. He is a Pioteus Net-
woiks piolessional seivices senioi engineei specializing in the ueployment ol high-enu
]unipei iouteis anu seivice gateways. He has leu ueployments ol SRXs, MXs, anu
]-seiies iouteis loi majoi enteipiise anu caiiiei customeis. He is also a veteian ]unipei
Netwoiks Ceitilieu Instiuctoi anu has uevelopeu multiple couises loi the vaiious ]u-
nipei piouuct lines. Petei is an authoi ol Tc|cconnunications: A Bcginncr`s Guidc anu
coauthoi ol |SDN: Conccpts, Iaci|itics, and Scrviccs (Loth puLlisheu Ly McGiaw-Hill)
anu contiiLuting authoi to Thc Handboo| oj Loca| Arca Nctwor|s (CRC Piess). Petei
holus a B.S.E.E. liom Claikson Univeisity. He is a memLei ol IEEE anu has ]unipei
Ceitilications incluuing ]NCIS-FVV, ]NCIA-SSL, ]NCIE-M/T =+73, ]NCIS-ER, anu
]NCIP-SEC.
Doug Marschke is an engineeiing giauuate liom the Univeisity ol Michigan anu cui-
iently a piincipal paitnei at Pioteus Netwoiks. He is ]NCIE-ER =3, ]NCIE-M =+1,
]NCIS-FV, anu ]NCIA ceitilieu. He has wiitten vaiious ]unipei ceitilication exams,
is a cowiitei ol the ]NCIE Enteipiise Exam, anu coauthoieu junos Entcrprisc Switch-
ing (O`Reilly). Doug cuiiently spenus his time woiking with Loth seivice pioviueis anu
enteipiises to optimize theii IP netwoiks loi Lettei peiloimance, cost, anu ieliaLility,
anu he has spent the last six months woiking on a next-geneiation goveinment satellite
netwoik. He also llies aiounu the woilu anu Lack to shaie his knowleuge in a vaiiety
ol tiaining classes anu seminais on topics such as tiouLleshooting, uesign, anu ceitil-
ication piepaiation. Il Doug is not on the ioau, you can linu him at his Lai in San
Fiancisco, Taco Shop at Unueiuogs, uiscussing a wiue vaiiety ol topics. He iecently
staiteu a new company calleu Funny How Films, piouucing inuepenuent lilms such as
Anstcrdan Hcavy anu Mad Cow.
Harry ReynoIds has moie than 25 yeais ol expeiience in the netwoiking inuustiy, with
the last 15 yeais locuseu on LANs anu LAN inteiconnection. He is CCIE =+977 anu
]NCIE =3 ceitilieu, anu he also holus vaiious othei inuustiy anu teaching ceitilications.
Haiiy was a contiiLuting authoi on the junipcr Nctwor| Conp|ctc Rcjcrcncc (McGiaw-
Hill), anu wiote the ]NCIE anu ]NCIP stuuy guiues loi SyLex Books. Piioi to joining
]unipei, Haiiy seiveu time in the US Navy as an avionics technician, woikeu loi
xiii
eguipment manulactuiei Micom Systems, anu spent much time ueveloping anu pie-
senting hanus-on technical tiaining cuiiiculums taigeteu to Loth enteipiise anu seivice
pioviuei neeus. Haiiy has piesenteu classes loi oiganizations such as Ameiican Insti-
tute, Ameiican Reseaich Gioup, Hill Associates, anu Data Tiaining Resouices. Haiiy
is cuiiently employeu Ly ]unipei Netwoiks, wheie he is a senioi test engineei pei-
loiming customei-specilic testing. Haiiy`s othei ioles at ]unipei have incluueu test
engineei in the coie piotocols gioup, consulting engineei on an aeiospace iouting con-
tiact, anu senioi euucation seivices engineei, wheie he woikeu on couisewaie anu
ceitilication olleiings.
About the Technical Reviewers, Second Edition
The seconu euition was ievieweu Ly seveial ]unos engineeis, incluuing the authois ol
the liist euition, Doug Maischke anu Haiiy Reynolus. RoL Cameion ol ]unipei Net-
woiks was kinu enough to give the new chapteis auueu to this seconu euition a caielul
ieauing, anu Chiis ]ones ol Accuvent also ievieweu the new chapteis.
About the Lead Technical Reviewers, First Edition
Maiio Puias is a ]unipei Netwoiks Systems Engineei Managei suppoiting majoi en-
teipiise anu state goveinment accounts in the Atlantic iegion. He has moie than 13
yeais expeiience in the netwoiking inuustiy anu locuses on uatacenteis, enteipiise
moLility, anu secuiity solutions. He is ]NCIP =119 anu holus vaiious othei inuustiy
ceitilications. Piioi to joining ]unipei Netwoiks, he seiveu in the US Aimy anu woikeu
at Metiolink, Duio Communications, anu Solunet Inc. He is giatelul to his wile anu
Lest liienu ol 15 yeais, Stacy.
]ack V. Paiks has moie than 15 yeais expeiience in inloimation technology, anu he
has woikeu in almost eveiy position known in the iealm ol IT. Most iecently he has
locuseu on enteipiise iouting anu switching, seivice pioviuei iouting, anu MPLS anu
VPNs. He holus a B.S. in Business Inloimation Systems liom ]ohn Biown Univeisity
anu has ieceiveu seveial inuustiy ceitilications, incluuing ]NCIE-M =666 anu
CCIE=116S5. Altei seiving eight yeais in the US Aii Foice, ]ack tiansitioneu into the
coipoiate woilu, woiking loi seivice pioviueis in the enteipiise anu ISP maiket spaces.
]ack is cuiiently a ]unipei Systems Engineei Laseu in Atlanta.
xiv | About the Authors
Preface
The woilu ol enteipiise iouting with ]unipei Netwoiks uevices is getting veiy
excitingnew technologies, piouucts, anu netwoik uevelopments aie making the en-
teipiise netwoik enviionment one ol the most uynamic places to Le. Howevei, we, the
authois, hope to locus that eneigy Ly pioviuing you with a uetaileu anu piactical loun-
uation that ensuies ellective use ol the ]unos opeiating system in youi uay-to-uay joL.
]unipei has iounueu out its line ol enteipiise piouucts to incluue not only iouteis Lut
also switches anu secuiity uevices, so uiawing liom oui piolessional seivices expeii-
ences, this new euition pioviues you with uesign guiuelines anu compaiisons ol uevice
capaLilities. Oui hope heie is not to give you a single way to uesign a netwoik Lut plenty
ol iueas that allow you to get the most liom youi netwoik uesign, whatevei it is.
Because we aie also involveu in the uevelopment anu testing ol ceitilication exams,
incluuing those loi enteipiise iouting, this Look uoes uouLle uuty. It is Loth a lielu
guiue anu a ceitilication stuuy guiue. Reaueis who aie inteiesteu in attaining a ]unipei
Netwoiks ceitilication level woulu Le wise to note that we uiscuss anu covei topics that
aie ielevant to the ollicial exams (hint, hint) anu that the enu ol each chaptei pioviues
a listing ol examination topics coveieu as well as a seiies ol ieview guestions that allow
you to test youi compiehension.
Regaiuless ol one`s ceitilication plans, this one-ol-a-kinu Look will not Le oLsolete just
Lecause you pass an exam. In lact, we wiote this mateiial to seive as a uselul lielu guiue
almost any time you log on to a ]unipei Netwoiks ioutei. The extensive use ol tutoiials,
samples ol actual commanu output, anu uetaileu theoietical coveiage go well Leyonu
any ceitilication exam, to pioviue you with something that can`t Le testeugetting
things to woik the iight way, anu the liist time. Vhen plan A lails, the mateiial also
pioviues the steps neeueu to monitoi netwoik opeiation anu guickly iuentily anu ie-
solve the ioot cause ol mallunctions.
As tiaineis who ueal with laige numLeis ol Loth expeiienceu anu inexpeiienceu useis
on a iegulai Lasis, we have seen it all. Vithin this guiue, you will linu the many peails
ol oui accumulateu wisuom, any one ol which can easily pay loi this Look many times
ovei in incieaseu netwoik uptime anu peiloimance.
xv
Some ol oui chapteis tenu to Le on the longei siue, simply Lecause they aie packeu
with uetaileu inloimation iegaiuing theoiy, conliguiation, anu tiouLleshooting loi
each topic. Rathei than cieate moie chapteis, we`ve incluueu solt Lieaks anu sum-
maiies within the chapteis to iuentily Lounuaiies in the mateiial that alloiu a conven-
ient place to take a Lieathei, oi as we olten pioviue in oui tiaining classes, a Liology
Lieak anu stietch. Dog-eai the pages, wiite notes in the maigins, augment the topology
illustiations with something moie akin to youi netwoikjust iememLei that this is a
Leastly ]unos Look: pait uesign guiue, pait exam, pait tiaining class, pait knowleuge
Lase. It`s meant to Le useu, aLuseu, anu put to woik. Theie`s a ieason you`ie holuing
the Lest-selling ]unos Look ol all time. Let`s get going.
What Is Enterprise Routing?
Altei you`ve spent some time in the netwoiking lielu, you tenu to notice that theie is
iaiely a single way to uo things, anu in many cases, iaiely a single, piecise uelinition
loi teims. Altei all, olten a netwoik engineei`s Lest answei is it uepenus. Such is the
case with enteipiise iouting, so let`s stait oll with a uelinition guestion: what is an
enteipiise netwoik? Is it a laige multinational netwoik useu Ly a manulactuiing com-
pany; is it a goveinment netwoik suppoiting a state oi a county; is it a iegional netwoik
useu Ly a paits uistiiLutoi; oi is it a netwoik that suppoits youi local uentist`s ollice?
Ol couise, it`s pioLaLly all ol these, anu many moie. At a veiy high level, you can state
that an enteipiise netwoik is one that is useu to suppoit activities as opposeu to gen-
eiating ievenue, as in a seivice pioviuei`s netwoik. Some might say that il someone
pays you to access youi netwoik, you aie pioviuing a seivice to him anu you`ie no
longei an enteipiise netwoik. But that sweeping statement uoesn`t ieally apply il that
someone is paying you to covei youi costs to pioviue that seivice. So, as you can see,
it uepenus.
Delining an enteipiise netwoik also manilests itsell in how ]unipei Netwoiks uelines
its piouucts within the enteipiise woilu. On the one hanu, ]unipei uesignates ceitain
haiuwaie platloims as enteipiise, Lut then many enteipiise netwoiks ieguiie uensity
anu thioughput options liom a platloim listeu as a seivice pioviuei piouuct. Fiom the
soltwaie siue ol things, the same issue aiiives. Vheieas a technology such as IPSec is
useu Ly all types ol netwoiks aiounu the gloLe, is it useu moie Ly enteipiise netwoiks
than Ly seivice pioviuei netwoiks? Some engineeis woulu answei yes to that guestion,
Lut then, you can`t say that a seivice pioviuei will nevei use IPSec.
Fiom the peispective ol haiuwaie platloims, ]unipei Netwoiks has uesignateu the lol-
lowing as enteipiise piouucts:
]-seiies iouteis to incluue the ]2320, ]2350, ]+350, anu ]6350
M-seiies to incluue the 7i, M10i, anu M120 iouteis
MX Univeisal Euge iouteis to incluue the MX-S0 anu MX-2+0
xvi | Preface
SRX Seivices Gateway to incluue the Bianch Ollice anu the Data Centei mouels
EX Etheinet switches to incluue the EX2200, EX2500, EX3200, EX+200, EX+500,
anu EXS200
Howevei, laigei enteipiise netwoiks might linu platloims such as the M320 anu
MX960/+S0 veiy uselul loi theii enviionments. In lact, the ieveise is also tiue, in that
a tiauitional seivice pioviuei netwoik might veiy well linu an appiopiiate neeu anu use
loi platloims uesignateu as enteipiise iouteis.
The goou news in all this is that you have a well-thought-out opeiating system, Lecause
]unos has a single tiain ol leatuies that opeiates acioss all ol the vaiious iouting plat-
loims. So, whethei you iun an enteipiise netwoik oi a seivice pioviuei netwoik, anu
iegaiuless ol youi actual haiuwaie platloim, theie is a single veision ol soltwaie coue
to loau. Although this single coue tiain has lots ol hiuuen Lenelits, such as staLility,
ease ol expanuaLility, lowei total opeiational costs, anu moie, what it ieally means is
the aLility to have the same Lase leatuies availaLle on all uevices. So, liom a leaining
peispective, we can talk aLout the soltwaie anu its leatuies without having to constantly
caveat oui uiscussion with except loi on this platloim oi only on these paiticulai
platloims. Although such exceptions uo occui, anu they iesult liom haiuwaie en-
hancements that aie unigue to a paiticulai platloim, these cases tenu to Le exceptions
anu aie inlieguent enough to iememLei.
Thioughout this Look, we will attempt to simplily the uiscussion Ly limiting ouiselves
to those seivices anu leatuies that aie lounu on all uevices in the ]unipei enteipiise
lineup. Ve also locus on those topics that the vast majoiity ol enteipiise netwoiks caie
aLout anu actually use. Ve will also ueline an enteipiise netwoik as one that uses an
Inteinet connection as opposeu to a netwoik that pioviues connectivity to the Inteinet
as its sole lunction.
Juniper Networks Technical Certification Program (JNTCP)
This Look is a stuuy guiue loi the ]NTCP Enteipiise tiacks. Use it to piepaie anu stuuy
loi the ]NCIA-]unos, ]NCIS-ENT, ]NCIP-ENT, anu ]NCIE-ENT ceitilication exams.
Foi the most cuiient inloimation on ]unipei Netwoiks` Enteipiise ceitilication tiacks,
visit the ]NTCP weLsite at http://www.junipcr.nct/ccrtijication.
How to Use This Book
Let`s look at some specilics on how this Look can help you. Ve`ll talk aLout what we
covei in the vaiious chapteis, how the Look is laiu out, anu some iesouices to help you
along the way. To stait, let`s uiscuss what you shoulu know Leloie you Legin to ieau
this Look.
Preface | xvii
Ve aie assuming a ceitain level ol knowleuge on the ieauei`s pait. This is impoitant
Lecause we assume you aie conveisant in the lollowing topic aieas:
OS| nodc|
The Open Systems Inteiconnection (OSI) mouel uelines seven uilleient layeis ol
technology: Physical, Data Link, Netwoik, Tianspoit, Session, Piesentation, anu
Application. This mouel allows netwoik engineeis anu netwoik venuois to easily
uiscuss anu apply technology to a specilic OSI level. This segmentation lets engi-
neeis uiviue the oveiall pioLlem ol getting one application to talk to anothei into
uisciete paits anu moie manageaLle sections. Each level has ceitain attiiLutes that
uesciiLe it anu each level inteiacts with its neighLoiing levels in a veiy well uelineu
mannei.
Switchcs
These uevices opeiate at Layei 2 ol the OSI mouel anu use logical local auuiessing
to move liames acioss a netwoik. Devices in this categoiy incluue Etheinet, Asyn-
chionous Tianslei Moue (ATM), anu Fiame Relay switches.
Routcrs
These uevices opeiate at Layei 3 ol the OSI mouel anu connect IP suLnets to each
othei. Routeis move packets acioss a netwoik in a hop-Ly-hop lashion.
Ethcrnct
These Lioaucast uomains connect multiple hosts togethei on a common inlia-
stiuctuie. Hosts communicate with each othei using Layei 2 meuia access contiol
(MAC) auuiesses.
Point-to-point |in|s
These netwoik segments aie olten thought ol as VAN links in that they uo not
contain any enu useis. Olten, these links aie useu to connect iouteis togethei in
uispaiate geogiaphical aieas. PossiLle encapsulations useu on these links incluue
ATM, Fiame Relay, Point-to-Point Piotocol (PPP), anu High-Level Data Link
Contiol (HDLC).
|P addrcssing and subnctting
Hosts using IP to communicate with each othei use 32-Lit auuiesses. Humans olten
use a uotteu uecimal loimat to iepiesent this auuiess. This auuiess notation in-
cluues a netwoik poition anu a host poition, which is noimally uisplayeu as
192.16S.1.1/2+.
TCP and UDP
These Layei + piotocols ueline methous loi communicating Letween hosts. The
Tiansmission Contiol Piotocol (TCP) pioviues loi connection-oiienteu commu-
nications, wheieas the Usei Datagiam Piotocol (UDP) uses a connectionless paia-
uigm. Othei Lenelits ol using TCP incluue llow contiol, winuowing/Lulleiing, anu
explicit acknowleugments.
xviii | Preface
|CMP
Netwoik engineeis use this piotocol to tiouLleshoot anu opeiate a netwoik, as it
is the coie piotocol useu (on some platloims) Ly the ping anu tiaceioute piogiams.
In auuition, the Inteinet Contiol Message Piotocol (ICMP) is useu to signal eiioi
anu othei messages Letween hosts in an IP-Laseu netwoik.
junos CL|
The commanu-line inteilace (CLI) useu Ly ]unipei Netwoiks iouteis, which is the
piimaiy methou loi conliguiing, managing, anu tiouLleshooting the ioutei. ]unos
uocumentation coveis the CLI in uetail, anu it is lieely availaLle on the ]unipei
Netwoiks weLsite.
Whats in This Book?
The ultimate puipose ol this Look is to Le the single most complete souice loi woiking
knowleuge ielateu to ]unipei Netwoiks enteipiise iouting. Although you won`t linu
much locus on actual packet loimats anu lielus, topics loi which theie is alieauy plen-
tilul coveiage on the Inteinet anu in Lookstoies, you will linu how to ueploy ]unos
technology ellectively in youi netwoik.
Heie`s a shoit summaiy ol the chapteis anu what you`ll linu insiue:
Chaptei 1, junos in thc Entcrprisc Nctwor|
This chaptei pioviues an oveiview ol the haiuwaie anu soltwaie aichitectuie on
]unipei enteipiise iouteis, as well as an oveiview ol the ]unos CLI loi Loth new
anu expeiienceu useis. It then pioviues a uesciiption ol the ]unipei enteipiise ue-
vices, walking thiough the vaiious mouel lamilies anu pioviuing a Liiel uelinition
ol the seivices, capaLilities, anu usages ol each uevice.
Chaptei 2, Entcrprisc Dcsign
This chaptei pioviues a set ol uesign guiuelines loi the enteipiise netwoik. It
piesents the methouology loi enteipiise uesign anu a seiies ol netwoik scenaiios
that illustiate the changes you can make to netwoiks to impiove theii elliciency,
secuiity, anu connectivity.
Chaptei 3, junipcr Switching and Routing P|atjorns
This chaptei pioviues the usage iecommenuations loi ]unipei enteipiise uevices.
Many uevices ollei oveilapping leatuies anu capaLilities, anu this chaptei looks at
these capaLilities anu positions the uevices within the enteipiise netwoik.
Chaptei +, |ntcrjaccs
This chaptei pioviues an oveiview ol ]unos inteilace oiganization. Then, it uives
into some ol the most common inteilace types anu conliguiations seen in netwoiks
touay. Finally, it concluues with a tiouLleshooting section with ieal-lile scenaiios
seen eveiy uay.
Preface | xix
Chaptei 5, Protoco| |ndcpcndcnt Propcrtics and Routing Po|icy
This chaptei pioviues a conuenseu Lut compiehensive oveiview ol ]unos Piotocol
Inuepenuent Piopeities (PIPs), such as static anu aggiegate ioute, anu ol the ]unos
iouting policy, which is useu to contiol ioute auveitisement, ieuistiiLution, anu
attiiLute manipulation.
Chaptei 6, |ntcrior Gatcway Protoco|s and Migration Stratcgics
This chaptei pioviues a uetaileu ieview ol Inteiioi Gateway Piotocol (IGP) opei-
ation, anu then locuses on multivenuoi ueployments ol the Routing Inloimation
Piotocol (RIP) anu Open Shoitest Path Fiist (OSPF). The mateiial also locuses on
IGP migiation stiategies anu incluues an EIGRP-to-OSPF migiation case stuuy.
Chaptei 7, Bordcr Gatcway Protoco| and Entcrprisc Routing Po|icy
Altei pioviuing a uetaileu ieview ol what the Boiuei Gateway Piotocol (BGP) is
anu how it can Lenelit an enteipiise, this chaptei pioviues a seiies ol case stuuies
that Luilu in complexity, staiting with a single homeu netwoik with no Inteinal
BGP (IBGP) speakei anu enuing with a multihomeu-to-multiple-pioviueis sce-
naiio, to incluue a ieuunuant IBGP ioute iellection uesign that avoius iunning
IBGP on all inteinal iouteis. The policy tieatment is locuseu on piactical enteipiise
iouting goals, anu it uetails Loth inLounu anu outLounu policy, incluuing
autonomous system (AS) path iegex matching anu BGP attiiLute manipulation.
Chaptei S, Acccss Sccurity
This chaptei pioviues an oveiview ol a laige vaiiety ol secuiity concepts anu the
tools availaLle to ueploy them. These tools incluue usei authentication anu au-
thoiization, iemote access, liiewall lilteis, policeis, Unicast Reveise Path Foiwaiu-
ing, the Simple Netwoik Management Piotocol (SNMP), anu syslog.
Chaptei 9, junos Laycr 2 Scrviccs
This chaptei pioviues an oveiview ol the Layei 2 seivices that can Le ueployeu on
a ]unipei Netwoiks ioutei. Layei 2 seivices incluue leatuies such as link Lunuling,
Geneiic Routing Encapsulation (GRE), anu link aggiegation.
Chaptei 10, C|ass oj Scrvicc
This chaptei pioviues an oveiview ol IP class ol seivice (CoS) anu incluues a ue-
taileu piimei on IP DillSeiv. The mateiial then uetails the similaiities anu uillei-
ences in CoS hanuling Letween the uilleient platloims, which is a common souice
ol conlusion. A piactical CoS case stuuy seives as the lounuation loi CoS ueploy-
ment anu opeiational veiilication. The chaptei also uemonstiates the Viitual
Channel CoS leatuie.
Chaptei 11, |P Mu|ticast in thc Entcrprisc
Multicast tenus to see little ueployment anu is a common aiea ol conlusion. This
chaptei uetails IP multicast concepts, pioviues an oveiview ol multicast piotocols,
anu then uemonstiates seveial Physical Inteilace Mouule (PIM) spaise moue sce-
naiios, to incluue PIM spaise moue with static, Lootstiap, anu Anycast-RP.
Thiough all the examples, piactical veiilication anu lault isolation steps aie
pioviueu.
xx | Preface
Chaptei 12, junos Sccurity Scrviccs
This chaptei incluues uesciiptions ol the secuiity seivices lounu in the ]-seiies
Seivices Routeis anu SRX Seivices Gateways. NAT, VPNs, UTM, anu secuiity
policies aie explaineu with conliguiation examples ol each.
Appenuix A, junos Laycr 3 Scrviccs
This appenuix coveis the legacy Layei 3 seivice set as lounu on oluei ]unos veisions
anu the M-seiies uevices, hence its appenuix status. NAT, IPSec VPNs, anu statelul
lilteis aie coveieu, as well as conliguiation examples loi each. This appenuix also
coveis inteilace anu next-hop seivice sets, with a compaiison ol wheie each shoulu
Le useu.
Appenuix B, Upgrading junos
This appenuix coveis the methous that aie availaLle loi upgiauing a ]unos uevice
to a newei veision ol the opeiating system. Stoiage cleanup methous anu memoiy
extension capaLilities aie coveieu, anu examples aie pioviueu loi maximizing a
uevice`s llash memoiy.
In auuition, you can also use this Look to attain one ol the ]unipei Netwoiks ceitili-
cation levels ielateu to enteipiise iouting. To that enu, each chaptei incluues a set ol
ieview guestions anu exam topics that have Leen coveieu, all uesigneu to get you
thinking aLout what you`ve just ieau anu uigesteu. Il you`ie not in the ceitilication
moue, the guestions will pioviue a mechanism loi ciitical thinking, potentially piompt-
ing you to locate othei iesouices to luithei youi knowleuge.
Topology of This Book
Figuie P-1 uisplays this Look`s iouting topology, which appeais Leginning in Chap-
tei +. It consists ol 11 ]-seiies iouteis iunning veision 10.+R1.9 anu 2 Cisco iouteis
iunning IOS Release 12.3(15L). The Cisco iouteis aie piimaiily employeu in Chap-
tei 6, wheie they aie useu loi Loth RIP inteiopeiaLility anu as pait ol an EIGRP-to-
OSPF migiation exeicise. The topology uses only GigaLit Etheinet anu T1 inteilaces;
howevei, othei inteilace types aie examineu in Chaptei +. You might iecognize the
hostnames ol the iouteis, which all ielate to a Leveiage that was cieateu moie than
7,000 yeais ago (with eviuence to consumption) in Mesopotamia. The names aie
chosen uue to the inteinational appeal ol the iesultant piouuct anu loi its loou value
only, as Leei is an excellent way to pieseive the nutiitional value ol giain.
Preface | xxi
I
i
g
u
r
c

P
-
1
.

T
h
i
s

b
o
o
|
`
s

t
o
p
o
|
o
g
y
x
x
i
i
|
P
r
e
f
a
c
e
Do
Conventions Used in This Book
The lollowing typogiaphical conventions aie useu in this Look:
|ta|ic
Inuicates new teims, URLs, email auuiesses, lilenames, lile extensions, pathnames,
uiiectoiies, anu Unix utilities
Constant width
Inuicates commanus, options, switches, vaiiaLles, attiiLutes, keys, lunctions,
types, classes, namespaces, methous, mouules, piopeities, paiameteis, values,
oLjects, events, event hanuleis, XML tags, HTML tags, macios, the contents ol
liles, anu the output liom commanus
Constant width bold
Shows commanus anu othei text that shoulu Le typeu liteially Ly the usei, as well
as impoitant lines ol coue
Constant width italic
Shows text that shoulu Le ieplaceu with usei-supplieu values
This icon signilies a tip, suggestion, oi geneial note.
This icon inuicates a waining oi caution.
Using Code Examples
This Look is heie to help you get youi joL uone. In geneial, you may use the coue in
this Look in youi own conliguiation anu uocumentation. You uo not neeu to contact
us loi peimission unless you`ie iepiouucing a signilicant poition ol the mateiial. Foi
example, ueploying a netwoik Laseu on actual conliguiations liom this Look uoes not
ieguiie peimission. Selling oi uistiiLuting a CD-ROM ol examples liom this Look uoes
ieguiie peimission. Answeiing a guestion Ly citing this Look anu guoting example
coue uoes not ieguiie peimission. Incoipoiating a signilicant amount ol opeiational
output oi sample conliguiations liom this Look into youi piouuct`s uocumentation
uoes ieguiie peimission.
Ve appieciate, Lut uo not ieguiie, attiiLution. An attiiLution usually incluues the title,
authoi, puLlishei, anu ISBN, loi example: junos Entcrprisc Routing, seconu euition,
Ly Petei Southwick, Doug Maischke, anu Haiiy Reynolus (O`Reilly). Copyiight 2011
Petei Southwick, Doug Maischke, anu Haiiy Reynolus, 97S-1-++9-39S63-7.
Preface | xxiii
Il you leel youi use ol coue examples lalls outsiue laii use oi the peimission given heie,
leel liee to contact us at pcrnissionsorci||y.con.
Safari Books Online
Salaii Books Online is an on-uemanu uigital liLiaiy that lets you easily
seaich ovei 7,500 technology anu cieative ieleience Looks anu viueos to
linu the answeis you neeu guickly.
Vith a suLsciiption, you can ieau any page anu watch any viueo liom oui liLiaiy online.
Reau Looks on youi cell phone anu moLile uevices. Access new titles Leloie they aie
availaLle loi piint, anu get exclusive access to manusciipts in uevelopment anu post
leeuLack loi the authois. Copy anu paste coue samples, oiganize youi lavoiites, uown-
loau chapteis, Lookmaik key sections, cieate notes, piint out pages, anu Lenelit liom
tons ol othei time-saving leatuies.
O`Reilly Meuia has uploaueu this Look to the Salaii Books Online seivice. To have lull
uigital access to this Look anu otheis on similai topics liom O`Reilly anu othei puL-
lisheis, sign up loi liee at http://ny.sajariboo|son|inc.con.
How to Contact Us
Please auuiess comments anu guestions conceining this Look to the puLlishei:
O`Reilly Meuia, Inc.
1005 Giavenstein Highway Noith
SeLastopol, CA 95+72
S00-99S-993S (in the Uniteu States oi Canaua)
707-S29-0515 (inteinational oi local)
707-S29-010+ (lax)
Ve have a weL page loi this Look, wheie we list eiiata, examples, anu any auuitional
inloimation. You can access this page at:
http://orci||y.con/cata|og/978111939837
oi:
http://cubcdnctwor|s.con
To comment oi ask technical guestions aLout this Look, senu email to:
boo|qucstionsorci||y.con
Foi moie inloimation aLout oui Looks, couises, conleiences, anu news, see oui weLsite
at http://www.orci||y.con.
Finu us on FaceLook: http://jaccboo|.con/orci||y
Follow us on Twittei: http://twittcr.con/orci||yncdia
xxiv | Preface
Vatch us on YouTuLe: http://www.youtubc.con/orci||yncdia
Acknowledgments
From the First Edition
The authois woulu like to giatelully anu enthusiastically acknowleuge the woik ol
many piolessionals who assisteu us in the uevelopment ol the mateiial loi this Look.
Although oui names aie piinteu on the Look as authois, in ieality no authoi woiks
alone. The contiiLutions ol many people have maue this Look possiLle, anu otheis
have assisteu us with theii technical accuiacy, typogiaphical excellence, anu euitoiial
inspiiation.
Many thanks aie oweu to the ollicial technical euitois ol this mateiial. Maiio anu ]ack
weie extiemely iesponsive to the uemanuing neeus ol oui scheuule. Youi attention to
uetail anu wealth ol knowleuge no uouLt saveu us many an emLaiiassing Lit ol eiiata.
To this enu, we also thank Colleen Goiman loi hei line uevelopmental euiting, anu
Auuiey Doyle loi hei thoiough copyeuiting, which iesulteu in a much-impioveu ex-
peiience loi you, the ieauei.
Ve woulu also like to acknowleuge ]unipei Netwoiks in geneial, loi the assistance
pioviueu on vaiious lionts, anu specilically Moneai ]alal, Daviu Ranch, anu ]eiish
Paiapuiath, loi theii elloits in making the coveiage ol secuiity seivices possiLle. Ve
also extenu thanks to ]onathon Looney, who volunteeieu to pioviue a technical ieview
loi the seivices chapteis, loi his uetaileu knowleuge ol ]unos soltwaie with enhanceu
seivices, anu loi the inspiiation he pioviueu with iegaiu to the BGP policy tieatment.
Ve woulu also like to thank Chiis Hellnei, who pioviueu the iouteis useu loi this Look
via http://www.ccrtijicd-|abs.con, with a piice that coulu not Le matcheuliee ol
chaige.
Thanks also to Matt Kolon, loi taking time liom his Lusy scheuule to evaluate the
mateiial, anu loi his inspiiational loiewoiu.
Anu last Lut not least, special thanks to ]ason Rogan anu Patiick Ames loi theii assis-
tance anu Lehinu-the-scenes activations that maue this elloit possiLle. They weie the
ones who ieally pusheu the iueas ol two wacky authois into a ieality.
From Doug Marschke
I woulu like to acknowleuge all my liienus who helpeu me thiough this veiy time-
consuming anu, at times, stiesslul elloit with many woius ol encouiagement anu well-
timeu stiess ielieveis. I woulu like to thank Becca Moiiis in paiticulai loi hei liee time
spent coiiecting my hoiiiLle giammai to avoiu emLaiiassment Leloie euitoiial suL-
mission. I woulu also like to thank my ioommate, Catheiine la O`, loi putting up with
the man wiiting in the cave. Ol couise, I woulu Le iemiss il I uiu not thank my luiiy
Preface | xxv
guauiupeu liienu, ]osh, who was Ly my siue the entiie time, olleiing a wool to any
potential uistiacteis.
From Harry Reynolds
I woulu like to acknowleuge my wile, Anita, anu two lovely uaughteis, Chiistina anu
Maiissa, loi once again unueistanuing anu accommouating my uesiie to engage in this
pioject. Also, special thanks to my manageis at ]unipei Netwoiks, Coiinne Rattay anu
Sieeuhevi Sankai, loi theii unueistanuing anu suppoit. I ieally appieciate theii will-
ingness to accommouate the occasional glitch in my uay joL scheuule that was neeueu
to make this happen. Lastly, I`u like to thank Doug Maischke (whose name I can nevei
spell, Lut shall nevei loiget), loi olleiing me the chance to paiticipate in this pioject. I
take gieat piiue in seeing how lai Doug has come in his piolessional caieei anu lully
expect to linu mysell woiking loi him one uay. You go, Doug!
For the Second Edition
From Doug Marschke and Harry Reynolds
Velcome to the upuateu veision ol junos Entcrprisc Routing! Much has changeu in
]unos since we wiote the liist euition ol this Look, mostly ielateu to the ]-seiies anu
SRX uevices moving liom packet-Laseu to llow-Laseu uevices. This auus many changes
in the secuiity leatuies ol the uevices, Lut Lecause oui Look is still titleu iouting, we
lelt the new secuiity aspects to the junos Sccurity Look iecently puLlisheu Ly O`Reilly.
Ve uiu keep in legacy seivices as an appenuix since these aie still ielevant to MX anu
M uevices.
Ve ieally woulu like to thank Petei Southwick loi taking the time to ievise anu upuate
this Look. He uiu the majoiity ol the upuate, with us just keeping a watchlul eye anu
auuing to each chaptei when we coulu. Ve have to say that he uiu guite an amazing joL!
Enjoy the new euition, anu keep on Lecoming ]unolieu.
From Peter Southwick
The authois acknowleuge with gieat piaise the woik ol the piolessionals who assisteu
us in ueveloping the mateiial loi this Look. Ve aie engineeis anu actually uo lall into
the steieotype ol that gioup, anu so the euitoiial cleanup, loimatting, anu giaphical
conloimity aie all peiloimeu Ly people not listeu as authois. It is they who ueseive the
acknowleugments.
Ve aie giatelul to Mike Loukiues, senioi O`Reilly euitoi, who was iesponsive to oui
availaLility anu unueistanuing ol oui spoiauic scheuules. His technical expeitise anu
attention to uetail maue this expeiience Lettei than the inuiviuual contiiLutions ol us
authois. Ve also thank Genevieve u`Entiemont loi hei copyeuiting anu RoLeit
xxvi | Preface
Romano loi his aitwoik; theii contiiLutions have maue this a Lettei expeiience loi you,
the ieauei.
Again we acknowleuge the contiiLutions ol ]unipei Netwoiks in geneial, loi the as-
sistance pioviueu on vaiious lionts, anu specilically Chiis ]ones anu RoL Cameion loi
theii technical ieviews ol the new mateiial in this euition.
A gigantic thanks to Patiick Ames loi his iueas, euitoiial help, patience, anu eagle eye
loi uetail. Youi peisistence anu enthusiasm have maue this pioject enjoyaLle anu
possiLle.
Finally, I ollei heaitlelt thanks to my lamilyMichele, my patient anu loving wile, anu
GaLiiella anu Victoiia, the two Lest uaughteis in the woiluloi theii unueistanuing
uuiing this pioject. My piolessional seivices iole takes me away liom my lamily loi a
goou pait ol the yeai, anu this pioject uemanueu that I Le away even when I was
home. Giils, thank you loi unueistanuing anu suppoiting me. Vithout you, I woulu
nevei Le aLle to uo this.
Preface | xxvii
CHAPTER 1
Junos in the Enterprise Network
The ]unos opeiating system is the common element in ]unipei enteipiise platloims. It
enaLles the leatuies anu capaLilities that uistinguish the ]unipei Netwoiks line ol
eguipment liom otheis in the enteipiise space. The llexiLility ol this stanuaius-Laseu
opeiating system pioviues a ioLust lounuation onto which multiple platloims have
Leen Luilt. The mouulai natuie ol the opeiating system allows it to suppoit any numLei
ol specializeu capaLilities such as switching, secuiity, anu, ol couise, iouting platloims.
The uevices can Le useu at the enteipiise euge, the coie, as liiewalls, oi as access uevices.
A cential theme loi all ol these uevices is theii iouting capaLility, which is not suipiising
given the oiigins ol ]unipei Netwoiks.
This chaptei takes a Liiel look at the uevices that aie lounu in the enteipiise netwoik
anu that iun the ]unos opeiating system. So much has changeu since the liist euition
ol this Look that ]unos in the enteipiise neeus its own intiouuctoiy chaptei.
Introduction to Junos Enterprise Routing
Vhen the lounuing engineeis ol ]unipei ueciueu to cieate iouteis, they took the view
ol loiwaiuing packets as guickly as possiLle (line iate) with seivices enaLleu, which
spawneu the maiketing ueciee Seivice without Compiomise.
All ]unipei Netwoiks uevices that iun on the ]unos opeiating system shaie the same
common uesign philosophy, which is to have a clean sepaiation ol the contiol anu
loiwaiuing planes. In the high-enu uevices (loi example, M-seiies iouteis, MX euge
uevices, anu Data Centei SRXs), this sepaiation is cieateu in haiuwaie, wheieas the
othei uevices (]-seiies iouteis anu Bianch Ollice SRXs) maintain this uivision in solt-
waie. The loiwaiuing plane is ieleiieu to as the Packet Foiwaiuing Engine (PFE), anu
the contiol plane is calleu the Routing Engine (RE).
The RE`s piimaiy lunctions aie to manage the PFE, contiol the uevice`s soltwaie (]unos
opeiating system), manage the commanu-line inteilace (CLI), pioviue tiouLleshooting
tools, anu maintain the ioute taLles (Loth the ioute taLle anu the ioute loiwaiuing
taLle). The loiwaiuing taLle, a suLset ol the ioute taLle, is passeu uown to the PFE anu
1
is useu to loiwaiu tiallic. In this way, the RE nevei has to Le uiiectly involveu in packet
loiwaiuing, which allows moie iesouices loi the actual contiol lunctions (see Fig-
uie 1-1). One example ol the Lenelits ol sepaiating the contiol anu loiwaiuing lunctions
is the aLility to issue tiaceoptions commanus (similai to ueLug) without uegiauing
the thioughput peiloimance ol the ioutei.
Iigurc 1-1. junipcr`s architccturc dcsign phi|osophy
Junos Overview
]unos is pietty cool once you unueistanu it. It cieeps up on you, especially il you`ie
coming liom anothei venuoi oi liom Cisco IOS. That`s Lecause the uesigneis ol ]unos
put tiemenuous thought into making a staLle, ioLust, anu scalaLle opeiating system
loi netwoiking uevices. They weie aLle to leain liom pievious venuois` mistakes anu
cieateu an opeiating system that othei companies will loievei use as theii mouel.
The coie philosophy ol ]unos was to cieate a mouulai anu staLle opeiating system.
The mouulaiization was cieateu Ly the use ol soltwaie uaemons, anu the staLility was
achieveu Ly choosing a well-known, open souice, anu staLle keinel ol FieeBSD. This
keinel is usually hiuuen liom the usei, Lut many leatuies ol FieeBSD have Leen poiteu
to the commanu line ol ]unos.
The keinel also maintains the loiwaiuing taLle synchionization Le-
tween the RE anu the PFE.
2 | Chapter 1:Junos in the Enterprise Network
Riuing on top ol the keinel aie all the lully inuepenuent soltwaie piocesses loi iouting,
CLI, inteilaces, anu so loith. Figuie 1-2 shows a small suLset ol these piocesses; you
can show a complete list in the uevice Ly issuing the show system processes commanu.
Iigurc 1-2. junos sojtwarc architccturc
These piocesses aie lully inuepenuent, so a lailuie ol one piocess uoes not allect the
othei. Foi example, Figuie 1-2 shows the Simple Netwoik Management Piotocol
(SNMP) piocess pulling inloimation liom the inteilace, chassis, anu iouting piocesses.
Il this SNMP piocess lails oi contains a soltwaie Lug, it allects only this piocess anu
not the otheis. This is a majoi shilt liom othei iouting venuois that opeiateu monolithic
coue wheie one change in the inteilace coue coulu allect just aLout anything without
ieason.
Eveiy ]unipei Netwoiks uevice iunning ]unos is cieateu liom the same coue Lase. Since
all uevices uo not shaie common haiuwaie, a new image has to Le cieateu loi each
uevice type. This is still ]unos, howevei, with the same Lase leatuie set acioss all uevices
(iouting, CLI, seivices, etc.). This means that theie is a single image pei veision loi all
M/T-seiies uevices anu all MX euge uevices, iegaiuless ol mouel numLei, anu a single
image pei veision loi all ]-seiies iouteis. The exception loi image ielease is loi the EX
anu SRX uevices. Theie is an image loi each ol the EX mouels, anu the SRXs have thiee
inuiviuual images. The uays ol cieating anu maintaining laige spieausheets oi lists loi
each ioutei aie now gone.
The uilleiences in aichitectuie Letween the M-seiies iouteis anu the ]-seiies iouteis
show one ol the ieasons loi the sepaiation liom a single image. The majoi uilleience
in the ]-seiies image is the inclusion ol a soltwaie piocess calleu jwdd (loiwaiuing
uevices uaemon), which acts as the viitualizeu PFE. It is essentially a seiies ol ieal-time
Introduction to Junos Enterprise Routing | 3
thieaus opeiating ovei the keinel, as shown in Figuie 1-3. Insteau ol an application-
specilic integiateu ciicuit (ASIC) pioviuing the lunctionality ol the PFE, sockets anu
APIs inteilace with the keinel, pioviuing a ueteiministic peiloimance.
Iigurc 1-3. j-scrics sojtwarc architccturc
Junos Releases
One ol the key auvantages ol ]unos is the single ielease tiain. This ielease tiain olleis
auministiatois ol ]unipei Netwoik uevices a pieuictaLle scheuule loi netwoik up-
giaues. The ielease tiain lollows a stiict calenuai loi initial ielease, enu ol engineeiing
suppoit, anu enu ol lile. TaLle 1-1 is an exceipt liom the ]unipei Netwoiks weLsite.
Tab|c 1-1. junos rc|casc support
Product FRS date EOE End of Life (EOL)
Junos 10.4 12/08/2010 12/08/2013 06/08/2014
Junos 10.3 08/15/2010 05/15/2011 11/15/2011
Junos 10.2 05/15/2010 02/15/2011 08/15/2011
Junos 10.1 02/15/2010 11/15/2010 05/15/2011
Junos 10.0 11/15/2009 11/15/2012 05/15/2013
Junos 9.6 08/06/2009 05/06/2010 11/06/2010
Junos 9.5 04/14/2009 02/15/2010 08/15/2010
Junos 9.4 02/11/2009 11/11/2009 05/11/2010
Junos 9.3 11/14/2008 11/14/2011 05/14/2012
Junos 9.2 08/12/2008 05/12/2009 11/12/2009
Junos 9.1 04/28/2008 01/28/2009 07/28/2009
Junos 9.0 02/15/2008 11/15/2008 05/15/2009
The liist ieleaseu shipments (FRS) aie olleieu on a guaiteily Lasis thioughout the yeai.
Vith each veision ol an image, theie aie ieleases anu Luilus. The lull naming conven-
tion loi ]unos ieleases is given in Figuie 1-+.
4 | Chapter 1:Junos in the Enterprise Network
Iigurc 1-1. junos inagc naning convcntion
Once a new veision ol ]unos is issueu, it unueigoes multiple maintenance ieleases (loi
example, 10.0R1.S, 10.0R2.5, anu 10.0R3.1). Foi any veision, ]unipei Netwoiks iec-
ommenus the latest maintenance ielease loi a uevice, anu the weLsite pioviues a list ol
iecommenueu ieleases loi vaiious eguipment.
]unipei iecognizes thiee levels ol suppoit loi a ]unos veision:
End oj Enginccring (EOE)
Active engineeiing suppoit is pioviueu uuiing the peiiou coveiing the cuiient vei-
sion anu the next two veisions, oi 1S months liom the liist ieleaseu shipment.
Because the veisions aie ieleaseu on a guaiteily Lasis, active suppoit is typically
availaLle loi 9 months altei liist ielease shipment, which essentially means that no
luithei maintenance ieleases aie cieateu loi the veision altei this uate.
junipcr Tcchnica| Assistancc Ccntcr (jTAC)
]TAC pioviues tiouLleshooting anu woikaiounu suppoit loi iuentilieu pioLlems
in a veision liom the time that EOE Legins until two luithei veisions aie ieleaseu
oi up to an auuitional yeai.
End oj Lijc (EOL)
Once EOL is ieacheu loi a veision, ]TAC typically ieguests that the customei
upuate his oi hei image. Il suppoit is still ieguesteu, it is pioviueu on a commei-
cially ieasonaLle elloit Lasis.
To assist customeis who see no neeu to upgiaue ]unos on a iegulai Lasis,
]unipei Netwoiks has cieateu what is calleu a ]unos Extenueu Enu ol
Lile (EEOL) ielease. These veisions, which pioviue auuitional time loi
engineeiing anu ]TAC suppoit, aie ieleaseu in the louith guaitei.
EEOLs pioviue thiee yeais ol engineeiing suppoit anu an auuitional six
months ol ]TAC suppoit.
In auuition to the liist shipment ieleases anu the maintenance ieleases, ]unipei also
pioviues seivice anu inciuent ieleases. These ieleases aie not loi geneial uistiiLution,
Lut might Le iecommenueu Ly an engineei oi ]TAC to solve specilic pioLlems. Seivice
ieleases (loi example, jinsta||-cx-1200-10.0S.1-doncstic) aie cieateu to auuiess spe-
cilic pioLlems lounu in an image anu span the time Letween Luilus. Inteinal ieleases
Introduction to Junos Enterprise Routing | 5
(loi example, junos-srx5000-10.1|20100513_0739_schung-doncstic) aie olten tiou-
Lleshooting tools cieateu Ly ]unipei Netwoik engineeiing when investigating a pioL-
lem anu tiying uilleient lixes. The pioLlems solveu Ly seivice anu inteinal ieleases aie
incoipoiateu into the next geneial ielease Luilus.
Accoiuing to some ]unipei loiums, seivice (S) ieleases aie the iecom-
menueu ieleases loi specilic uevices ueployeu in ceitain scenaiios. Until
the newei veisions ol ]unos aie testeu anu veiilieu, these netwoik en-
gineeis aie moie comloitaLle with the S ielease.
CLI Review
The tool that will most olten Le useu to conliguie anu tiouLleshoot ]unipei uevices is
the commanu-line inteilace (CLI). The ]unos soltwaie CLI is one ol the most usei-
liienuly anu leatuie-iich in the inuustiy. Most auministiatois spenu yeais attempting
to mastei othei ioutei venuois` CLIs, wheieas ]unos soltwaie can Le masteieu in just
a lew houis.
Othei conliguiation methous uo exist, such as a weL GUI calleu ]-VeL (see Fig-
uie 1-5), which is availaLle on all ]unipei uevices. The ]-VeL is enaLleu Ly uelault on
most enteipiise uevices anu can Le activateu loi all uevices. It`s a ioLust way ol mon-
itoiing anu conliguiing youi uevices, anu it even has a point-anu-click CLI component.
Note that the opeiation ol ]-VeL is Leyonu the scope ol this Look, so all conliguiation
examples aie shown via CLI commanus insteau. Leain the CLI liist, anu the ]-VeL is
a snap to implement.
Iigurc 1-5. j-Wcb
6 | Chapter 1:Junos in the Enterprise Network
General CLI features
The CLI has two moues: opeiational anu conliguiation. Opeiational moue is wheie
you can tiouLleshoot anu monitoi the soltwaie, ioutei, anu netwoik. Conliguiation
moue is wheie the actual statements loi inteilaces, iouting piotocols, anu otheis aie
placeu.
Eveiy commanu that can Le iun in opeiational moue can also Le useu
in conliguiation moue with the auuitional keywoiu run. Foi example,
il the show route commanu is issueu in opeiational moue, it can Le
issueu as run show route in conliguiation moue.
Vhen a usei liist enteis the ioutei via Telnet, Secuie Shell (SSH), oi uiiect console
access, the usei sees a login piompt. Altei enteiing the coiiect useiname anu passwoiu,
the usei is placeu uiiectly into the opeiational moue. Opeiational moue is uesignateu
Ly the > (chevion) chaiactei at the uevice piompt ol username@hostname. As shown heie,
usei doug logs into a ioutei calleu Hops:
Hops (ttyd0)
login: doug
Password:
--- Junos 10.4R1.9 built 2010-12-08 16:25:40 UTC
doug@Hops>
An exception to this automatic placement into opeiational moue occuis when you log
in as usei root. In this case, you aie placeu into the shell (uesignateu Ly the peicent
sign) anu will have to stait the CLI piocess manually:
Hops (ttyd0) login: root
Password:
--- Junos 10.4R1.9 built 2010-12-08 09:22:36 UTC
root@Hops% cli
root@Hops>
Most ol the commanus that you iun in opeiational moue aie show commanus, which
allow you to gathei inloimation aLout the iouting piotocols, inteilaces, anu the uevice`s
soltwaie anu haiuwaie. Ping, tiaceioute, telnet, anu ssh can also Le peiloimeu liom
this moue. Finally, some veiy ]unos-specilic commanus, such as request, restart, anu
test, can Le issueu. Reguest commanus peiloim system-wiue lunctions such as ie-
Looting, upgiauing, anu shutting uown the uevice. Restait commanus aie similai to
the Unix-style kill commanus, which allow you to iestait ceitain soltwaie piocesses.
Test commanus allow veiilications loi saveu conliguiation liles, pioactive testing ol
policies, anu inteilace testing methous such as BERT (Lit eiioi iate testing) anu FEAC
(lai-enu alaim anu contiol) loopLacks.
Introduction to Junos Enterprise Routing | 7
You shoulu use the restart commanu with gieat caution! Depenuing
on the soltwaie piocess Leing iestaiteu, the conseguences coulu Le se-
veie. Restaiting the SNMP piocess woulu pioLaLly get you a slap on
the wiist, Lut iestaiting the iouting piocess coulu Le a ieason to go into
hiuing on a iemote islanu!
To actually conliguie the ]unos uevice, entei conliguiation moue Ly typing the woiu
configure in opeiational moue. The uevice piompt changes to the octothoipe (#)
symLol:
doug@Hops> configure
Entering configuration mode
[edit]
doug@Hops#
By uelault, multiple useis can entei the conliguiation moue on a uevice anu make
changes at the same time. To avoiu any issues that may aiise, you can use the configure
exclusive oi configure private commanu. The loimei commanu allows only a single
usei to conliguie the ioutei, wheieas the lattei commanu allows multiple useis to
change uilleient pieces ol the conliguiation. Il you use configure exclusive, no othei
useis can make changes to the conliguiation Lesiues the single usei who enteieu ex-
clusively. Using piivate moue, each usei will get a copy ol the cuiient conliguiation
anu only the changes that they make will Le applieu. Il two useis attempt to make the
same change, such as auuing an IP auuiess to the same inteilace, the change is iejecteu
anu Loth useis will exit conliguiation moue to iesolve theii conllict Ly some othei
means.
In conliguiation moue, you can auu conliguiation Ly using a set commanu. Foi ex-
ample, to enaLle the Telnet seivei application on the uevice, issue this commanu:
doug@Hops# set system services telnet
Othei uselul commanus in the conliguiation moue aie:
delete
Opposite ol the set commanu, this suLtiacts conliguiation items:
doug@Hops# delete system services telnet
replace pattern
Peiloims an exact match anu ieplace loi a stiing in the conliguiation:
doug@Hops# replace pattern 10.1.1.1/32 with 10.1.1.1/24
insert
In a conliguieu list (iules oi policies), allows an item to Le moveu liom the Lottom
ol the list to a uilleient position:
doug@Hops# insert policy permit_all before policy deny_all
save
Viites the conliguiation to a lile nameu in the commanu:
8 | Chapter 1:Junos in the Enterprise Network
doug@Hops# save test_configuration
edit
Moves the usei to a uilleient level ol the conliguiation:
[edit]
doug@Hops# edit system services
[edit system services]
doug@Hops#
exit
Moves the usei to the next level up in the conliguiation (a usei can also use the
up commanu), oi il the usei is at the top ol the conliguiation, it will put the usei
into opeiational moue:
[edit system services]
doug@Hops# exit
[edit system]
doug@Hops# up
[edit]
doug@Hops# exit
doug@Hops>
rename
Assigns a new name to a conliguieu oLject:
doug@Hops# rename interface ge-0/0/1 to interface ge-10/0/1
copy
Copies the attiiLutes ol a conliguieu oLject to anothei oLject:
doug@Hops# copy interface ge-0/0/1 to ge-0/0/2
commit
Peiloims a semantic anu completeness check ol the changes maue to the conligu-
iation, anu il the changes pass these checks, the changes aie wiitten to the uevice`s
iunning conliguiation:
doug@Hops# commit
A lull tieatment ol the capaLilities anu opeiation ol the CLI is Leyonu the scope ol this
Look, as mentioneu in the Pielace, Lut the opeiational capaLilities ol the CLI aie ex-
ploieu thioughout this Look Ly Luiluing anu showing hunuieus ol examples.
Routing Features
Let`s continue oui toui ol ]unos in the enteipiise with the iouting leatuies lounu in
most ]unos-Laseu uevices, keeping in minu that many ol the uetails ol these leatuies
anu example conliguiations aie lounu in latei chapteis.
The liist piouuct piouuceu Ly ]unipei Netwoiks was an IP ioutei, anu since that initial
launch, all ]unipei Netwoiks piouucts Laseu on ]unos have hau iouting capaLilities at
theii coie.
Introduction to Junos Enterprise Routing | 9
The piinciples loi iouting tiansit tiallic aie hanuleu in the same way in all uevices:
1. The iouting lunctions aie uiviueu Letween the RE anu the PFE.
2. The RE is iesponsiLle loi ueteimining the Lest ioute to a pielix.
3. This inloimation is passeu to the PFE.
+. All tiansit tiallic is hanuleu Ly the PFE.
5. Vhen the RE ueteimines that the conuitions in the netwoik have changeu enough
to waiiant a change in packet iouting, a new set ol instiuctions is loiwaiueu to the
PFE.
The netwoik pielixes anu the ioutes to them aie kept in a set ol taLles stoieu in the RE
anu the PFE. Chaptei 5 exploies the lull set ol iouting taLles anu the use loi each, so
heie the locus is only on the taLle that is useu loi IPv+ tiallic. This taLle is calleu the
inct.0 tab|c, anu it contains a list ol all known netwoik pielixes anu the attiiLutes loi
each pielix. The attiiLutes maintaineu loi a pielix aie ueteimineu Ly the way that pielix
was leaineu Ly the uevice. So il a pielix was enteieu as a static ioute, only the inloi-
mation that was manually enteieu woulu Le stoieu with the pielix, oi il the ioute was
leaineu via a iouting piotocol (e.g., OSPF), the auuitional inloimation associateu with
the pielix woulu Le stoieu with the ioute. The inet.0 taLle is also ieleiieu to as the
nastcr routing tab|c when this taLle is iuentilieu liom anothei taLle loi static ioutes.
The lollowing shows example output ol an inet.0 taLle:
doug@Hops> show route
inet.0: 23 destinations, 23 routes (22 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
1.12.1.0/24 *[Direct/0] 00:33:41
> via ge-1/0/0.0
1.12.1.1/32 *[Local/0] 00:33:41
Local via ge-1/0/0.0
10.255.66.0/24 *[OSPF/10] 00:32:53, metric 1
> to 1.12.1.2 via ge-1/0/0.0
192.168.102.0/23 *[Static/5] 5d 02:42:28
> to 192.168.71.254 via ge-1/0/0.0
This taLle has Leen ieuuceu in size, Lut it shows that the uevice knows loui pielixes.
The pielix 1.12.1.0/2+ is a uiiectly connecteu netwoik on inteilace ge-1/0/0.0, the
inteilace ge-1/0/0.0 has an auuiess ol 1.12.1.1/32, pielix 10.255.66.0/2+ was leaineu
via OSPF liom anothei uevice connecteu via inteilace ge-1/0/0.0, anu the pielix
192.16S.102.0/23 was statically auueu to the conliguiation.
The entiies in the inet.0 taLle aie analyzeu, anu the active ioutes (all the ioutes in the
pieceuing example aie active, as inuicateu Ly the *) aie sent to the loiwaiuing taLle.
The loiwaiuing taLle is then sent to the PFE (ielei to Figuie 1-1). The loiwaiuing taLle
uoes not contain the pielix attiiLutes that aie containeu in the inet.0 taLle, just the key
elements loi how to hanule tiallic uestineu loi a netwoik pielix. The lollowing shows
an example loiwaiuing taLle entiy:
10 | Chapter 1:Junos in the Enterprise Network
doug@Hops> show route forwarding-table destination 10.255.66.1
Routing table: inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
10.255.66.0/24 user 0 1.12.1.2 ucst 286 2 ge-1/0/.0
The ueteimination ol which ioutes aie sent to the loiwaiuing taLle liom the iouting
taLle lollows a simple iule: thc routc nust bc thc activc routc with thc |owcst cost and
routc prcjcrcncc. Il a single pielix has multiple ioutes that have egual costs anu piel-
eiences, one ol the next hop inteilaces is chosen in a pseuuoianuom mannei (the ex-
ception to this is egual cost iouting, explaineu in the next section).
Once this piocess is complete anu all pielixes aie loaueu in the PFE, tiansit tiallic can
Le hanuleu. The uestination auuiess liom an incoming packet is compaieu to the loi-
waiuing taLle, looking loi the longest match. Once a match is lounu, the next hop anu
inteilace inloimation aie useu to hanule the egiess piocessing loi the packet. Il no
match is lounu loi the uestination auuiess anu no uelault ioute is estaLlisheu loi the
uevice, the packet is uioppeu.
Routing modifiers
The ueteimination ol which ioute gets sent to the loiwaiuing taLle can Le manipulateu
Ly othei paits ol the conliguiation. Most attiiLutes ol a pielix entiy can Le mouilieu
Ly policies anu iules. These conliguiaLle leatuies allow an auministiatoi to customize
how tiallic is hanuleu within the uevice.
Route policies can Le applieu as ioutes entei the iouting taLle (impoit) oi as ioutes aie
sent to neighLois (expoit). The policies can accept oi ieject ioutes, anu loi accepteu
ioutes, the attiiLutes ol the ioutes can Le mouilieu. Vhen pielixes aie leaineu Ly one
iouting piotocol (loi example, BGP) anu wish to Le auveitiseu in anothei (say, OSPF)
a piocess known as ioute ieuistiiLutiona iouting policy is useu. Il ioutes leaineu
liom one souice aie to Le pieleiieu to ioutes leaineu liom anothei souice, again, pol-
icies can Le useu to accomplish this. Full tieatment ol iouting policies is lounu in
Chaptei 5.
Filtei-Laseu loiwaiuing, which is similai to what othei venuois call policy-Laseu iout-
ing, allows incoming (ingiess) oi outgoing (egiess) tiallic to Le compaieu to a set ol
match ciiteiia uelineu in a liltei. Vhen the tiallic matches the liltei, the action uelineu
in that liltei aiea is applieu to that packet. One such action woulu Le iouting the packet
Laseu on the iules ol a nonuelault iouting taLle, allowing scenaiios to Le cieateu wheie
matching tiallic is iouteu ovei a uilleient set ol next hops/links Laseu on local policy
iathei than conventional longest match. In a simplistic example, piivately auuiesseu
tiallic can Le sent to a piivate.inet.0 taLle wheie a uelault ioute shunts them to a specilic
next hop oi seivei, while puLlic auuiesses can Le sent to the uelault inet.0 iouting taLle.
Loau Lalancing, oi egual cost multipath (ECMP) iouting, is tuineu oll Ly uelault on
]unipei uevices. The uelault iouting mechanism chooses a single next hop uestination
loi eveiy pielix, Lut loau Lalancing can Le conliguieu on the uevices anu can Le set
Introduction to Junos Enterprise Routing | 11
eithei as a gloLal leatuie loi all tiallic on the uevice oi loi specilic tiallic. The loau-
Lalancing algoiithm uses a hash lunction to ueteimine the link to use loi tiallic. The
loau Lalancing is on a pei-llow Lasis anu is calculateu Laseu on a conliguiaLle Layei 3
anu/oi Layei + hash. A conliguiation example loi ECMP anu a lull explanation can Le
lounu in Chaptei 5.
Multitopology iouting enaLles the ioutei to paiticipate in an enviionment that has
uilleient iouting iules loi uilleient tiallic types. It uses the concepts ol liltei-Laseu
loiwaiuing with conliguieu topologies. The topologies cieate uilleient loiwaiuing in-
loimation Lases (FIBs) loi each tiallic type. Each FIB can use a uilleient instance ol a
iouting piotocol as well as uilleient attiiLutes (costs anu pieleiences) loi pielixes.
Vhen tiallic enteis the uevice, the liltei-Laseu loiwaiuing allocates the tiallic to a
specilic FIB. The inloimation in that FIB is useu to ioute the tiallic. This capaLility,
when ueployeu acioss an enteipiise netwoik, allows a single netwoik inliastiuctuie to
suppoit multiple tiallic types on logically sepaiate netwoiks. Conliguiation examples
loi multitopology iouting anu a lull explanation ol its capaLilities aie uiscusseu in
Chaptei 6.
Switching Features
Let`s guickly ueline some ol the moie common switching leatuies lounu in ]unos ue-
vices. Vhile the lull uetails ol these leatuies anu conliguiation examples aie Leyonu
the scope ol this Look, its companion volume, junos Entcrprisc Switching, Ly Haiiy
Reynolus anu Doug Maischke (O`Reilly), is an excellent iesouice loi Loth the aumin-
istiatoi anu the netwoik uesignei.
The uesign ol an enteipiise netwoik ieguiies the use ol iouting, switching, anu secuiity
uevices. Vhen ]unipei ueciueu to entei the enteipiise maiket, it uiu so with the uetei-
mination that these othei netwoiking ieguiiements woulu Le auueu to ]unos. Touay,
Etheinet switching is a leatuie loi the EX piouuct line, the MX piouuct, anu the SRX
piouuct line. All ol these piouucts ollei Loth Etheinet switching capaLilities anu IP
iouting capaLilities in a single uevice.
The choice Letween switching anu iouting is uepenuent on the natuie ol the tiallic anu
the uevice`s conliguiation. Foi the most pait, when Loth switching anu iouting aie
piesent, the uevice ioutes tiallic that is auuiesseu (at the MAC layei) to it anu switches
all othei tiallic. Switching leatuies aie conliguieu in uilleient uevices in uilleient man-
neis. Foi instance, in the high-enu Data Centei SRXs, switching is enaLleu in what is
calleu transparcnt nodc, wheieas in the Bianch Ollice SRX anu EX switches, specilying
the Ethernet-switching lamily on an inteilace enaLles switching.
Let`s look at some ol the switching leatuies you`ll likely encountei in enteipiise
netwoiks.
Tianspaient moue is enaLleu loi the high-enu Data Centei SRX Seiies Seivices Gate-
ways (SRX 3xxx anu 5xxx) via conliguiation moue anu allows inteilaces to opeiate in
12 | Chapter 1:Junos in the Enterprise Network
an Etheinet switch moue. The uevice can Le conliguieu to suppoit Loth iouteu intei-
laces anu switcheu inteilaces. Tianspaient moue uevices suppoit options loi lloouing
unknown MAC auuiesses, Liiuge uomains (Lioaucast uomains), anu viitual LANs.
The lull capaLilities ol tianspaient moue can Lest Le uiscoveieu in the Look junos
Sccurity, Ly RoL Cameion et al. (O`Reilly).
Leaining MAC auuiesses is the means Ly which all Etheinet switching uevices uetei-
mine wheie to switch liames in a netwoik. The size ol the switching taLle is a measuie
ol the powei ol the switching uevices, anu the ]unipei switches suppoit taLle sizes liom
S,000 entiies loi the low-enu EX2200 to 160,000 entiies loi the enteipiise-level EXS200
(the MX euge iouteis aie capaLle ol having a million MAC auuiesses). Vhen a liame
is ieceiveu that contains a uestination MAC that is not in the loiwaiuing taLle, that
liame is llooueu to all the inteilaces ol the specilic Liiuge uomain on the switch. ]unipei
switches suppoit two lloouing options loi unknown tiallic: conventional lloouing anu
the moie secuie auuiess iesolution piotocol (ARP) lloouing capaLility.
Viitual switch constiucts allow single Etheinet switches to suppoit multiple logical
uivisions in an enteipiise. These constiucts incluue:
Bridgc donain
A Liiuge uomain is uelineu Ly a viitual LAN (VLAN) anu a gioup ol inteilaces that
loim a Lioaucast uomain loi Etheinet tiallic. Multiple Liiuge uomains can Le cie-
ateu on a single platloim, pioviuing loi a sepaiation ol tiallic.
\LAN
A VLAN allows tiallic liom a common community ol inteiest to communicate in
an Etheinet-switcheu enviionment. VLANs segment the tiallic anu pioviue secui-
ity liom othei VLANs.
\irtua| chassis
A viitual chassis allows the inteiconnection ol multiple physical switches to loim
a single auministeieu unit. The inuiviuual switches act as a iouting engine, a
Lackup iouting engine, oi a line caiu in the giouping ol switches.
Etheinet piotocols govein the inteiaction ol Etheinet switches in an enteipiise netwoik.
They allow ieuunuancy while avoiuing Lioaucast stoims, theieLy Liinging suivivaLility
to an Etheinet enviionment. The piotocols suppoiteu Ly ]unipei Netwoiks switches
iunning ]unos aie:
Spanning Trcc
Spanning Tiee Piotocol (STP) anu its vaiiations, RSTP anu MSTP, opeiate Letween
Etheinet switches to ensuie a loop-liee netwoik. Multiple Spanning Tiee Piotocol
(MSTP) incoipoiates the concepts ol VLANs into the piotocol, wheieas Rapiu
Spanning Tiee Piotocol (RSTP) opeiates on a single VLAN Lut impioves the time
to iecovei liom a netwoik lailuie.
Introduction to Junos Enterprise Routing | 13
Lin| Aggrcgation
Link Aggiegation Contiol Piotocol (LACP) anu S02.3au pioviue link aggiegation
capaLilities loi uevices. Up to 16 links can Le Lounu into a single Lunule. This
pioviues a high-Lanuwiuth, suivivaLle link Letween uevices. Link aggiegation also
suppoits a MAC hashing lunction to suppoit loau Lalancing, which assuies that
tiallic in a single llow lollows the same link in the S02.3au Lunule.
Etheinet switching also suppoits a numLei ol othei capaLilities on the ]unos platloims,
such as multicast suppoit anu S02.1X poit-Laseu authentication.
Security Features
Let`s Liielly covei the secuiity leatuies lounu in ]unos-Laseu uevices, keeping in minu
that the lull uetails ol these leatuies anu conliguiation examples aie Leyonu the scope
ol this Look. Foi in-uepth coveiage, seek out junos Sccurity.
Staiting in the miu-9 ielease ol ]unos, SRX uevices anu ]-seiies iouteis incoipoiateu
session-Laseu piocessing, which is the single unigue leatuie in the SRX Seiies uevices.
Foi the ]-seiies iouteis, ]unos 9.3 incoipoiateu the liist ol these secuiity
leatuies, anu 9.+ olleieu no packet-Laseu option loi the ]-seiies. Foi the
Data Centei SRXs, ]unos 9.2 was the liist llow-Laseu olleiing, wheieas
]unos 9.+ was the liist llow-Laseu olleiing loi the Bianch Ollice SRXs.
Rathei than piocessing each packet as an inuepenuent entity, packets aie gioupeu to-
gethei in uniuiiectional llows, anu llows aie paiieu into a session. Conseguently, a
majoiity ol the piocessing is peiloimeu at the session level iathei than the packet level.
Once a session is cieateu anu auuitional packets aie ieceiveu that match the session
paiameteis, the session attiiLutes aie useu to hanule the packet.
Session-Laseu piocessing enaLles these secuiity leatuies lounu in ]unos:
Sccurity zoncs
A secuiity zone is a set ol inteilaces anu the auuiesses lounu on those inteilaces
that aie gioupeu togethei as a single secuiity element. All secuiity policies aie
wiitten jron a secuiity zone to a secuiity zone.
Statcju| sccurity po|icics
]unos-Laseu secuiity uevices aie piuuent secuiity uevices, staiting with the lact
that all tiallic thiough the uevice is Llockeu unless explicitly peimitteu. Secuiity
policies aie cieateu to ueteimine what tiallic is alloweu anu what shoulu Le
Llockeu. The match ciiteiia loi tiallic aie the souice anu uestination auuiesses anu
the application-level iuentilication lounu in the tiallic. Policies aie uniuiiectional
at the session level. They aie uelineu loi sessions that aie initiateu liom a single
zone uestineu loi a zone. Reveise tiallic that is associateu with the session uoes not
14 | Chapter 1:Junos in the Enterprise Network
neeu a ieveise policy, Lut sessions that lollow the ieveise path uo neeu a policy
matching the session`s uiiection.
App|ication |aycr gatcways (ALGs)
ALGs pioviue pioxy suppoit loi ceitain applications, allowing the piopei opeia-
tion ol applications that woulu not opeiate successlully thiough a liiewall. One
example ol such an application layei piotocol is the session initiation piotocol
(SIP) useu in voice ovei IP (VoIP) implementations. Vhen useu in a secuieu sce-
naiio, SIP ieguiies a liiewall to paise its messages anu peiloim actions on Lehall
ol the SIP seivei anu client. These actions coulu incluue netwoik auuiess tiansla-
tion, opening auuitional poits thiough the liiewall, anu pioviuing pioxy seivices.
The seivices aie all peiloimeu Ly the ALG uelineu loi SIP. ALG suppoit is enaLleu
Ly uelault on ]unos-ielateu secuiity piouucts, except loi the Data Centei SRXs.
Nctwor| Addrcss Trans|ation (NAT)
One ol the most common secuiity leatuies, NAT allows an auministiatoi to hiue
the insiue ol the enteipiise netwoik liom piying eyes. The ]unos-Laseu secuiity
systems suppoit uynamic anu static NAT, as well as souice-Laseu anu uestination-
Laseu NAT.
|ntrusion Dctcction and Protcction (|DP)
IDP is a sophisticateu secuiity leatuie that ielies on attack signatuies anu oLsei-
vation ol enteipiise tiallic. ]unos secuiity uevices can peiloim eithei a passive
alaim-only iole oi an active alaim anu uetei iole. The IDP leatuies ieguiie an
auministiatoi to monitoi the state ol the signatuie uataLase anu tune the IDP iules
to the tiallic that is seen on the enteipiise. IDP leatuies aie integiateu into the SRX
piouuct line oi can Le ueployeu in puipose-Luilt IDP uevices.
Uscr authcntication
Usei authentication anu usei access contiol enaLle a ]unos secuiity uevice to ac-
tivate iules Laseu on the useis that aie cieating tiallic. Teaming ]unipei netwoik
access contiol uevices with the ]unos secuiity uevices cieates a uynamic paii loi
iecognizing useis anu mouilying the secuiity policies to accommouate these useis.
\irtua| privatc nctwor|s (\PN)
IPsec VPNs aie a mainstay loi site-to-site anu iemote access secuiity. They pioviue
enciyption anu authentication seivices as well as uata integiity capaLilities loi the
tiansmitteu tiallic. The ]unos secuiity uevices ollei a lull iange ol IPsec VPN
capaLilities.
Scrccn junctions
Vhen the lull capaLilities ol IDP aie not waiianteu, the scieen lunctions can Le
consiueieu an IDP-lite capaLility. These attack-ueteiient lunctions piotect the
uevice liom common hacks anu uenial ol seivice attacks. They aie implementeu
at the zone level anu pioviue a liist line ol uelense.
Introduction to Junos Enterprise Routing | 15
Unijicd Thrcat Managcncnt (UTM)
UTM is a set ol secuiity leatuies that incluues anti-viius piotection, anti-spam
lilteiing, URL lilteiing, content lilteiing, anu usei authentication. These seivices
aie availaLle on the ]-seiies iouteis anu the lowei-enu Bianch Ollice SRX Seiies.
Vhen session-Laseu piocessing was intiouuceu into ]unos, a new tiallic-piocessing
algoiithm was neeueu Lecause the existing packet-Laseu piocessing peiloimeu in haiu-
waie woulu not sullice loi this new paiauigm. Figuie 1-6 shows the oiuei loi piocessing
tiallic in a session-Laseu enviionment. Class ol Seivice (CoS) anu liltei lunctions aie
peiloimeu liist anu last at the line caiu level. Foi incoming tiallic, session matching
is peiloimeu next. Il an existing session is lounu loi the tiallic, last path piocessing
is peiloimeu Laseu on the attiiLutes ol the session. In the last path, scieen lunctions
aie peiloimeu, NAT anu ALGs complete theii actions, anu the tiallic is sent loi egiess
piocessing.
Iigurc 1-. Scssion-bascd proccssing
Il the packet is not pait ol an existing session, new session piocessing is peiloimeu.
This entails the initial iouting, policy lookup, any NAT that neeus to Le peiloimeu,
ALGs, anu linally enteiing the inloimation into the session taLle. Once this is complete,
the packet is piocesseu as it is in the last path loi egiess.
16 | Chapter 1:Junos in the Enterprise Network
Routing Platforms
Ovei 15 yeais ago ]unipei Netwoiks uesigneu theii liist Inteinet ioutei. This uevice
was unigue in its packet piocessing powei, low electiical powei consumption, anu
small physical size. The ieliaLility ol the ]unos opeiating system also Lecame a selling
point in the eia ol ieLoot tiouLleshooting. That initial ioutei is the paient ol the
cuiient M-seiies iouteis, anu even though the M-seiies has gone thiough many ievi-
sions since the initial olleiing, they aie still the highest thioughput loi the least powei
in the smallest package on the maiket touay.
The M-seiies iouteis anu theii laigei cousins, the T-seiies iouteis, ollei seivice pio-
viueis anu enteipiises a staLle platloim loi iouting IP tiallic. They ollei suppoit loi
most stanuaius-Laseu iouting piotocols anu suppoit Layei 3 anu Layei 2 pioviuei-
Laseu VPN seivices.
The cuiient lineup ol the ]unipei Netwoiks M-seiies is:
M7i Mu|tiscrvicc Edgc Routcr
10 GLps ol thioughput makes this ioutei a peilect euge uevice loi SMB applications
oi Inteinet gateway oi aggiegation ioutei loi Lianch locations.
M10i Mu|tiscrvicc Edgc Routcr
At 16 GLps ol thioughput, this compact anu ieuunuant ioutei pioviues a staLle
platloim loi giowing enteipiise netwoiks.
M10c Mu|tiscrvicc Edgc Routcr
This +0 GLps platloim olleis llexiLility anu suivivaLility loi meuium-sizeu
enteipiises.
M120 Mu|tiscrvicc Edgc Routcr
Vith a thioughput ol 120 GLps, this platloim will suppoit multimeuia anu seivice
aggiegation loi an enteipiise oi seivice ol any size.
M320 Mu|tiscrvicc Edgc Routcr
The 320 GLps thioughput allows this platloim to hanule the laigest LackLone coie
iouting anu the most uemanuing multiplay applications.
The ]-seiies iouteis weie auueu to meet the uemanus ol the smallei enteipiise. The
aichitectuie ol the ]-seiies is slightly uilleient than that ol the M-seiies, in that the
sepaiation Letween the contiol plane anu the loiwaiuing plane is viitual iathei than
physical. In an M-seiies ioutei, the packet-loiwaiuing plane consists ol specializeu
haiuwaie uesigneu loi packet hanuling; in the ]-seiies, the loiwaiuing plane is a vii-
tualizeu ieal-time thieau with vaiious application piogiam inteilaces anu sockets mou-
eling the specializeu lunctionality. This uilleience allows ]unipei to lielu a ioutei with
the same OS as the estaLlisheu M-seiies, Lut at a Lettei piice point loi the enteipiise.
Fiiewall anu secuiity leatuies have Leen auueu to the iouting capaLilities ol the ]-seiies
iouteis.
The cuiient ]unipei ]-seiies iouteis aie:
Routing Platforms | 17
j2320
Thiee PIM slots anu 90 MLps ol thioughput loi iouting anu liiewall leatuies
j2350
Five PIM slots anu 105 MLps ol thioughput loi iouting anu liiewall leatuies
j1350
Six PIM slots anu 115 MLps ol thioughput loi iouting anu liiewall leatuies
j350
Six PIM slots anu 205 MLps ol thioughput loi iouting anu liiewall leatuies
The ]-seiies iouteis aie uesigneu loi enteipiises that aie connecting uesktops to seiveis
loi ollice automation anu Lack ollice applications. The Physical Inteilace Mouule
(PIM) slots can Le useu loi LAN connectivity, vaiious VAN connectivity options (Se-
iial, T1/E1, FE, DS3/E3, ISDN, ADSL2/2-, G.SHDS), anu Avaya VoIP gateway anu/
oi VAN acceleiation.
Vith the auvent ol the SRX Seiies Seivices Gateways, the ]-seiies iouteis
aie now pieleiieu loi theii inteilace selection iathei than peiloimance
oi leatuies.
Speeds and Feeds
Most ol the iouteis lielueu Ly ]unipei aie mouulai in uesign, allowing them to Le
conliguieu loi any iole in the enteipiise. The mouulai components auu inteilace
choices, seivice acceleiatois, anu tunneling options to theii Lase capaLilities as iouteis.
The availaLle mouules can Le uiviueu into vaiious categoiies, each with suppoiting
multiple poit uensities anu inteilace speeus. The mouule categoiies aie:
SONET/SDN physica| intcrjacc cards (P|Cs)
Rates liom OC-3 (155 MLps) to OC-76S (+0 GLps)
Ethcrnct P|Cs
Rates liom 100 MLps to 10 GLps, 1 poit to +S poits
ATM P|Cs
E3, DS3, OC-3 to OC-+S ATM inteilaces
Channc|izcd P|Cs
E1, T1, DS3, OC-3, OC-12, anu OC-+S
Nonchannc|izcd P|Cs
E1, T1, DS3, E3
Scria| P|Cs
EIA-530, 2-poit
18 | Chapter 1:Junos in the Enterprise Network
Scrviccs P|Cs
Enciyption Seivices (ES), Monitoiing Seivices, Multiseivices, Link Seivices,
Tunnel
WAN P|Ms
E1, T1, Seiial, DS3, ISDN BRI, SHDSL, G.SHDSL
Ethcrnct P|Ms
100 MLps anu 1 GpLs coppei anu liLei
Scrviccs P|Ms
Avaya Meuia Gateway, ]unipei VXC VAN Acceleiatoi
A lull uelinition ol each ol these mouules can Le lounu at http://www
.junipcr.nct/us/cn/products-scrviccs/routing/n-scrics/n7i/=nodu|cs.
Fiom an aichitectuial peispective, these uevices` inteilace llexiLility, piotocol options,
anu scalaLle thioughput allow the iouteis to Le ueployeu in a collapseu LackLone oi
a uistiiLuteu coie. The viitualization capaLilities allow the iouteis to Le placeu in
multitopology anu multiclient enviionments, maintaining secuiity via sepaiation ol
tiallic anu seivices. Finally, the wiue iange ol Lackplane speeus anu thioughputs (90
MLps to 320 GLps) allows a scalaLle anu cost-ellective ]unipei ioutei to Le ueployeu
loi just aLout eveiy netwoik uesign.
MX Series 3D Universal Edge Routers
]unipei MX euge iouteis have the thiee uimensions ieguiieu in touay`s enteipiises anu
seivice pioviueis: scaling, availaLility, anu agility. The liist ol these scaling lactois is
the maximum peiloimance ol the uevices. The MX platloims suppoit Etheinet tiallic
iates liom 50 Mpps to 1.9S Bpps, allowing an MX platloim to meet most iouting anu
switching uemanus. Auu to this the capaLility ol aiiaying the MX in a viitual chassis,
which ieuuces the management Luiuen while incieasing the connectivity capaLility
compaieu to stanualone switches. The miu-iange MX line olleis a pay-as-you-go scal-
aLility. The MX5 can Le upgiaueu to the MX20, MX+0, oi the MXS0 with the auuition
ol a soltwaie license. This allows an enteipiise to puichase the uevice that lits its neeus
touay anu migiate as those ieguiiements giow.
The next uimension is the availaLility ol the MX platloim, which exceeus the Metio
Etheinet Foium`s caiiiei giaue switch specilications. The high-enu MX platloims sup-
poit ieuunuant iouting engines, ieuunuant switching planes, viitual chassis opeiation,
ieuunuant powei, anu ieuunuant cooling. Uptime is also maintaineu Ly the use ol
giacelul iestait, nonstop iouting, last ieioute (FRR), unilieu in-seivice soltwaie up-
giaue (ISSU), anu viitual piivate LAN switching (VPLS) multihoming.
Routing Platforms | 19
The linal uimension is the agility ol the MX piouuct line. The MX can peiloim iouting
anu switching lunctions, anu these platloims also suppoit secuiity leatuies anu viitu-
alization leatuies. This suite ol capaLilities allows the MX to opeiate as a coie Etheinet
switch, an MPLS euge ioutei, an Etheinet aggiegation point, oi a uistiiLution ioutei.
In many uesign scenaiios, the agility ol the MX allows multiple layeis ol a legacy uesign
to Le collapseu into a single layei. The auuition ol VAN optical inteilaces to the MX
expanus its agility in the enteipiise. No longei is the MX uestineu loi the inteiioi ol the
enteipiise; it can opeiate as an enteipiise euge uevice as well as an all-Etheinet coie
uevice.
The MX piouuct line is composeu ol the lollowing uevices:
Mid-rangc MX
The miu-iange chassis coveis the MX5, MX20, MX+0, anu MXS0 mouels. The
chassis is a compact unit (3.5 inches high) with loui Luilt-in 10 GLps Etheinet
poits anu up to two Mouulai Inteilace Caius (MICs). (The MX5 has a single MIC
poit.) The size anu poit uensity ol the miu-iange MX makes it iueal loi small sites
that neeu a leatuie-iich enviionment, such as moLile Lackhaul, metio Etheinet
access, anu lielu multimeuia aggiegation. Futuie suppoit loi viitual chassis will
allow the miu-iange MX to opeiate like the laigei uevices with ieuunuant iouting
engines. The miu-iange MXs aie soltwaie upgiauaLle, with the upgiaue suppoiting
highei thioughput iates on the chassis. The MXS0 also is availaLle in a +S-poit
gigaLit Etheinet conliguiation. The Lase thioughput ol the miu-iange MXs staits
at 20 GLps loi the MX5, +0 GLps loi the MX20, 60 GLps loi the MX+0, anu S0
GLps loi the MXS0. All mouels hanule 50 Mpps ol mixeu tiallic.
MX210
The MX2+0 suppoits the MX leatuie set anu auus suivivaLility to the mix with
ieuunuant REs, switch laLiic, powei, anu lans. This uevice can hanule up to +S0
GLps ol thioughput anu suppoits up to 120 gigaLit Etheinet poits.
MX180
The +S0 lills the neeu loi high-uensity Etheinet aggiegation in a suivivaLle chassis.
The platloim can suppoit 1.+ TLps anu a total ol 2+0 GE poits. Each ol the six
caiu slots can hanule 120 GLps. The MX+S0 is uesigneu to suppoit laige points ol
piesence in enteipiise netwoiks.
MX90
At 2.6 TLps, the MX960 can lill any iole in a campus netwoik that ieguiies massive
thioughput. The thioughput anu leatuie set allows the MX960 to lunction at the
coie ol the netwoik as the Inteinet gateway loi a campus oi as an aggiegation euge
uevice loi a laige Lusiness paik. The viitualization capaLilities allow the MX960
to hanule the tiallic liom multiple customeis in a sale anu uepenuaLle mannei.
The MX euge iouteis suppoit technologies anu leatuies that allow a sepaiation Letween
the physical ueployment ol uevices anu theii logical capaLilities. No longei is it neces-
saiy to ueploy oveilay netwoiks loi uilleient seivices, uilleient customeis, oi uilleient
20 | Chapter 1:Junos in the Enterprise Network
meuia. By using netwoik seivice viitualization (Layei 2 VPNs L2VPN, Layei 3 VPNs
L3VPN, anu viitual piivate LAN seivice VPLS), viitual uevices (viitual chassis, vii-
tual iouteis, anu switching uomains), anu viitual link technologies (VLAN, link ag-
giegation, pseuuowiie, anu tunnels), the MX piouuct line can act as any numLei ol
netwoiks oi uevices, each pioviuing a consistent guality ol seivice (QoS) anu secuiity
while incieasing uevice utilization anu loweiing oveiall cost.
TRIO DPC
The intiouuction ol the MXS0 also Liought along a new lamily ol uense poit concen-
tiatois (DPCs) suppoiting the TRIO chip set. The TRIO DPCs suppoit gieatei on-
Loaiu leatuies than the oluei DPCs anu ollei a highei level ol piogiammaLility loi
lutuie capaLilities. The upgiaueu leatuies on the DPC incluue: enhanceu loau Lalanc-
ing, llexiLle multicast suppoit, integiateu Etheinet lunctions, inline packet seivices
(tunnel encapsulation anu ue-encapsulation), Cllowu, NAT, ueep packet inspection
(DPI), anu a Leeleu-up QOS. The TRIO DPCs aie initially suppoiteu in the miu-iange
MX line, anu they will Le suppoiteu in othei MX platloims in the lutuie.
Howevei, until the TRIO DPC is lully integiateu into the MX piouuct line, theie aie
seveie limitations ielateu to the ueployment ol TRIO anu non-TRIO DPCs in the same
chassis. Consult the ]unipei knowleuge Lase loi possiLle scenaiios: http://www.junipcr
.nct/|b.
Switching Platforms
Etheinet switches anu Liiuges have Leen piesent in the enteipiise space loi 30 yeais,
Lut ]unipei Netwoiks EX Seiies switches lollow the classical uesign with the auuition
ol a lew iouting layei leatuies anu a numLei ol viitualization options. ]unipei Netwoiks
olleis the EX Seiies switches in options liom the stanualone EX2200, with its lixeu 2+
poits, to the EX S216, which can Le comLineu into a viitual chassis that can suppoit
ovei 2,000 gigaLit inteilaces. As an example ol the llexiLility ol the piouuct line, the
EX+200s can Le ueployeu in stanualone, physically stackeu, anu top ol uata caLinet
viitual chassis conliguiations. This olleis llexiLle ueployment options loi all ]unipei
switches.
The ]unipei EX Seiies switch line incluues:
EX2200 Ethcrnct Switchcs
An economy-minueu Lianch oi campus switch with leatuies usually lounu in
highei-cost switches.
EX2500 Ethcrnct Switchcs
High-uensity 1/10 GLps inteilaces in a compact solution.
EX3200 Ethcrnct Switchcs
A choice ol 2+- oi +S-poit mouels allows this switch to Le sizeu loi iemote ollices
oi small anu meuium Lusinesses (SMBs).
Switching Platforms | 21
EX1200 Ethcrnct Switchcs
ScalaLility via the viitual chassis opeiation allows this uevice to seive most access
scenaiios liom 2+ to +S0 poits.
EX1500 Ethcrnct Switchcs
Up to +S 10 GLps inteilaces anu 715 Mpps thioughput positions this uevice as a
high-speeu seivei access uevice.
EX8200 Ethcrnct Switchcs
Up to 76S 1 GLps poits anu 1.92 Gpps thioughput allow this mouulai chassis
switch to lunction as a coie switch in the laigest uata centeis anu campuses.
The viitual chassis opeiation suppoiteu on the EX +000 Seiies anu the EXS000 Seiies
ol switches allows multiple switches to Le comLineu to loim an extenueu switch op-
eiating unuei the contiol ol a single iouting engine. This capaLility cieates ueployment
options that have not Leen possiLle until now. One example is the iack top ueployment
mouel (shown in Figuie 1-7) wheie the uevices in a iack gain access to netwoik ie-
souices via the EX+200 in that iack. Placing the EX+200s in a viitual chassis aiiange-
ment with othei EX+200s in othei iacks olleis suivivaLle single-switch connectivity loi
useis in any ol the iacks. By auuing viitual LANs, secuiity anu tiallic sepaiation is
assuieu loi all useis in the iacks. This ueployment saves poits, incieases elliciency, anu
simplilies management ol access.
Iigurc 1-7. Rac| top inp|cncntation
Up to live ol the EX+200s can Le connecteu while maintaining lull speeu
connectivity acioss the Lackplane (physical anu viitual).
The EXS000 seiies ol switches olleis the highest uensity ol Etheinet poits anu also the
lowest pei-poit cost ol any ]unipei uevice. Auu to this a lull set ol ioutei leatuies, anu
the EXS000 can Le ueployeu as the uata centei coie switching system anu uistiiLution
22 | Chapter 1:Junos in the Enterprise Network
system in a single chassis. (Chaptei 2 contains a couple ol ueployment examples ol the
]unipei EX switches.)
SRX Series Services Gateways
The SRX Seiies Seivices Gateways aie the most iecent entiies into the enteipiise staLle
ol uevices. The SRX has a haiuwaie lineage Laseu on the ]-seiies iouteis anu the MX
euge iouteis, while theii soltwaie leatuies aie Laseu on the secuiity leatuies ol
ScieenOS anu the iouting leatuies native to ]unos. ]unipei calls the SRX a scrviccs
gatcway iathei than a liiewall Lecause it is a statelul liiewall with auuitional secuiity
seivices. It also has an Etheinet switching capaLility, ViFi suppoit, 3G suppoit, VoIP
suppoit, anu, linally, a lull set ol iouting leatuies. These auueu leatuies anu lunctions
eain the nomenclatuie.
The SRX is olleieu in two aichitectuies, commonly ieleiieu to as the Bianch Ollice
gateways anu the Data Centei gateways, oi as low-enu SRXs anu high-enu SRXs.
The SRX Bianch Ollice gateways ollei the iouting capaLilities anu the inteilace llexi-
Lilities that aie lounu in ]-seiies iouteis. The Bianch Ollice SRXs aie Leing ueployeu
to ieplace euge anu local iouteis. Vhy have two uevices when a single uevice can hanule
Loth lunctions while ieuucing complexity anu auministiation?
The Bianch Ollice SRX mouels aie:
SRX100
This small, low-cost liiewall olleis 650 MLps ol liiewall thioughput. Its eight lixeu
10/100 Etheinet poits aie iueally suiteu loi ueployment scenaiios in home ollices
anu iemote enteipiise locations with a limiteu numLei ol useis.
SRX210
This awaiu-winning SMB liiewall can ollei 750 MLps ol thioughput. 3G VAN
suppoit allows loi cieative connectivity anu/oi suivivaLility options. The SRX210
has eight lixeu Etheinet poits anu a single VAN caiu slot.
SRX220
The SRX220 suppoits 950 MLps in a 3.5-pounu loim lactoi. It suppoits eight
10/100/1000 Etheinet poits anu a paii ol expansion slots. It is iueal loi secuiing
SMB locations that neeu ieuunuant connectivity to the enteipiise.
SRX210
The SRX2+0 is the woikhoise ol the SRX Bianch Ollice line. Suppoiting 1.5 GLps
ol secuie thioughput, this uevice can hanule most Lianch ollice applications. The
16 lixeu 10/100/1000 Etheinet poits anu loui expansion caius will pioviue suppoit
loi most installations.
SRX50
Anothei awaiu-winnei, the SRX650 can haiuly Le calleu a Lianch ollice uevice. It
can hanule 7 GLps ol secuie tiallic in a two-RU size. The SRX650 suppoits loui
SRX Series Services Gateways | 23
lixeu 10/100/1000 Etheinet poits anu a comLination ol expansion caius that can
pioviue auuitional Etheinet poits oi VAN connectivity. The SRX650 can suppoit
iemote ollices, aggiegation locations, anu piimaiy gateway seivices loi meuium to
laige enteipiises.
The Data Centei SRX mouels aie Laseu on the MX chassis, anu they locus on thiough-
put anu inteilaces iathei than UTM secuiity leatuies. That`s Lecause it is sale to assume
that auuitional uevices to peiloim UTM leatuies woulu Le cost-piohiLitive in a Lianch
ollice. This same assumption is not valiu in the uata centei.
The high-enu Data Centei SRX mouels incluue:
SRX1100
The newest SRX mouel is uesigneu on the Data Centei aichitectuie Lut at a Lianch
ollice scale. This uevice is peilect wheie seiious liiewall piocessing is neeueu with-
out the high poit concentiations. The SRX1+00 is ellectively one hall ol a SRX3+00
anu olleis peiloimance up to 10 GLps.
SRX3100 and SRX300
These meuium-sizeu liiewalls ollei 10 anu 30 GLps ol secuie thioughput iespec-
tively. Both ollei suivivaLle clusteiing loi loss-liee seivice. They suppoit eight lixeu
100/1000 Etheinet poits, loui lixeu SFP poits, anu loui oi six input/output caiu
(IOC) expansion slots. The 3000 seiies uses a comLination ol seivice piocessoi
caius (SPC) anu netwoik piocessoi caius (NPC) to allow customization ol the
seivice ieguiiements. Install moie SPCs loi seivice-heavy scenaiios anu moie NPCs
loi inteilace-heavy scenaiios.
SRX500 and SRX5800
These aie two ol the highest-poweieu liiewalls in the inuustiy. The SRX5S00 sup-
poits 120 GLps ol secuie thioughput anu 30 GLps ol eithei IDP oi IPSec seivice.
The 5000 seiies can Le clusteieu with ieuunuant contiol anu laLiic links, anu the
uevices can Le inteiconnecteu Ly liLei to allow physical sepaiation to the nonstop
piocessing. This capaLility olleis suivivaLility loi laige uata centei installations,
campus-level liiewalls, oi laige enteipiise viitual gateways Letween uata centeis.
A lot ol uevices weie calleu out in this chaptei. Depenuing on when you
aie ieauing this Look uuiing its natuial shell lile, new anu novel uevices
will have Leen auueu to this chaptei`s lists. Be suie to check out the
]unipei Netwoiks weLsite loi the most cuiient list anu lineup.
Conclusion
]unipei Netwoiks has enteieu the enteipiise netwoik maiket with a stiong lineup ol
uevices that can meet those netwoiks` iouting, switching, anu secuiity ieguiiements.
This chaptei lookeu at the oveiall stiuctuie ol the ]unos uevices, the leatuie sets sup-
poiteu Ly each uevice type, anu soltwaie image ieleases. Many ol the leatuies that weie
24 | Chapter 1:Junos in the Enterprise Network
uesciiLeu in this chaptei can Le peiloimeu Ly the vaiious uevices. In the next two
chapteis we look at enteipiise scenaiios anu iuentily which uevices match the uilleient
ioles in the enteipiise.
Exam Topics
Ve examineu the lollowing Enteipiise Exam Topics in this chaptei:
List the enteipiise piouuct line.
DesciiLe tiansit anu host piocessing.
Iuentily key uilleiences Letween the M-seiies, ]-seiies, MX, EX, anu SRX uevices.
DesciiLe conliguiation management.
Iuentily the leatuies ol the ]unos CLI (CLI moues, piompts, anu auto-complete).
Iuentily the commanus useu in conliguiation moue (edit, set, delete, anu commit).
Iuentily options loi manipulating saveu conliguiation liles. Incluue iollLack op-
tions, loau options, anu iollLack lile locations.
DesciiLe the leatuies ol ]unipei uevices.
Chapter Review Questions
1. Vhich ol the lollowing two ]unipei Netwoiks iouteis aie classilieu as enteipiise
iouteis? (Choose two.)
A. T6+0
B. M7i
C. ]+350
D. M320
2. Vhich haiuwaie component contiols ueLugging on the ioutei?
A. Packet Foiwaiuing Engine
B. Route Piocessoi
C. System Contiol Boaiu
D. Routing Engine
3. Tiue oi False: Because the ]-seiies has only a single piocessoi, theie is no Packet
Foiwaiuing Engine.
+. Vhich commanu woulu Le issueu to ieLoot the ioutei?
A. request system reboot
B. reload
C. reboot
D. restart router
Chapter Review Questions | 25
5. Vhat is the uelault passwoiu to entei the conliguiation moue on the ioutei?
A. juniper
B. enable
C. Theie is no passwoiu
D. root
6. Vhich CLI commanu shoulu Le issueu to navigate to the jcdit protoco|s ospjj
uiiectoiy?
A. cd protocols ospf
B. edit protocols ospf
C. cd /edit/protocols/ospf
D. dir protocols ospf
7. Vhich CLI commanu must Le issueu to activate conliguiation changes in the
ioutei?
A. apply
B. copy
C. save
D. commit
S. Vhat is the top level ol the conliguiation tiee calleu?
A. C:/
B. /var
C. cdit
D. root
Chapter Review Answers
1. Answei: B, C. The T6+0 anu M320 aie valiu ]unipei Netwoiks ioutei mouels Lut
aie usually ueployeu in seivice pioviuei netwoiks.
2. Answei: D. The Routing Engine is the component in the ioutei that contiols all
management lunctions, incluuing commanus that woulu Le useu to ueLug the
ioutei.
3. Answei: False. The ]-seiies iouteis uo contain a viitualizeu PFE, with API anu
sockets ieplacing the ASICs that aie lounu in the M-seiies iouteis.
+. Answei: A. request commanus aie useu to issue system-wiue lunctions such as
ieLooting the ioutei. The iest ol the options aie invaliu CLI commanus.
5. Answei: C. Theie is no passwoiu to entei conliguiation moue. Useis aie alloweu
into conliguiation moue Laseu on access piivileges.
6. Answei: B. To change the uiiectoiy in conliguiation moue, use the edit commanu.
26 | Chapter 1:Junos in the Enterprise Network
7. Answei: D. To activate the changes in the ioutei, issue a commit commanu. Ol the
iemaining options, copy anu save aie valiu CLI commanus Lut aie useu loi con-
liguiation management.
S. Answei: C. Vhen at the top level ol the conliguiation tiee, the CLI Lannei will
uisplay the [edit] piompt.
Chapter Review Answers | 27
D
o
CHAPTER 2
Enterprise Design
Changes maue to netwoik tiallic patteins, seivei aichitectuies, anu tiallic types in the
past couple ol yeais have causeu existing netwoik uesign philosophies to Lecome out-
uateu. Pieexisting multitieieu netwoik uesigns aie no longei aLle to meet the scaling,
management, oi suivivaLility uemanus ol the cuiient enteipiise; in the lollowing pages
we piesent new netwoik uesigns that utilize the capaLilities ol the ]unipei Netwoiks
]unos-Laseu eguipment that expiessly meet these new uemanus.
This chaptei examines the new netwoik uesign guiuelines that aie Leing implementeu
in the enteipiise touay, as well as the goals anu Lenelits ol these uesigns when compaieu
to the legacy aichitectuies. The chaptei concluues with a seiies ol uesign scenaiios
anu solutions at laige enteipiises that use ]unipei eguipment.
To locus on the uesign aspects ol the netwoik without getting Loggeu uown in the
technical uetails ol the seivices anu piotocols, this chaptei is tightly connecteu to
Chapteis 1 anu 3. The pievious chaptei lookeu at the ]unipei Netwoiks uevices that
aie olleieu at the enteipiise level, anu the next chaptei uelves into the uetails ol this
eguipment`s technical capaLilities. But in this chaptei we locus on the outcome ol the
uesign, not the uetails ol the implementation. Foi those uetails, ielei to the othei chap-
teis in this Look.
Design Guidelines
The uesign guiuelines loi an enteipiise netwoik lollow a similai set ol piinciples as
uesigning a home. Theie is not a single home uesign that will meet the neeus ol all
people, Lecause theii ieguiiements will uillei in too many aieas. Howevei, uiawing
liom the histoiy ol house uesign anu constiuction, theie is a common set ol uesign
guiuelines that can Le applieu to any home uesign.
Foi any home uesign, theie aie seveial lactois to consiuei: what aie the availaLle ma-
teiials anu technologies, anu what aie the components ol the home itsell that must
meet the lilestyle ieguiiements ol the occupants? Only when these elements aie com-
Lineu into the total home uesign will it Le a home loi a liletime.
29
Designing an enteipiise netwoik shoulu Le uone along the same lines. An enteipiise
netwoik shoulu consiuei the lollowing lactois:
Sct goa|s jor thc nctwor|
The netwoik uesign goals have to mesh with the coipoiate goals ol the enteipiise.
Vhat aie the giowth expectations, what aie the secuiity ieguiiements, anu what
aie the access ieguiiements? These goals have moie to uo with the expectations ol
the enteipiise than with the technologies ol the netwoik.
What tcchno|ogics havc historica||y bccn uscd to ncct thc nctwor| rcquircncnts?
A histoiical peispective allows a uesignei to leain the whys ol a netwoik element
anu pioviues an unueistanuing ol the how. Any uesign has to look at the univeise
ol uesign elements anu cull the possiLilities, sepaiating what is neeueu to meet the
oveiall uesign goals liom what can Le uiscaiueu as not ieguiieu. As an example, a
loui-tieieu netwoik uesign has Leen the stanuaiu uata centei uesign loi the last
uecaue, Lut il the majoiity ol tiallic is east to west, not noith to south, this uesign
element is not necessaiy.
What ncw tcchno|ogics arc avai|ab|c, and what cjjicicncics and capabi|itics do thcy
cnab|c?
Do ielatively new technologies such as viitualization anu clouu computing have a
place in the enteipiise? Can the haiuwaie anu soltwaie that cuiiently exist in the
enteipiise suppoit these new technologies?
Dcsign jor nanagcabi|ity oj thc nctwor|
This might Le as simple as staying with a known venuoi oi a known opeiating
system, oi as complex as having a management suite that can communicate to all
elements anu is extensiLle to new technologies anu capaLilities.
Technological Goals of Network Design
As stateu, the economic goals ol the enteipiise have to Le iellecteu in the goals ol the
enteipiise netwoik. The goals also have to meet ceitain technical stanuaius, which
incluue:
Managcabi|ity
A uesign must meet the uemanus ol minimizing Loth capital expenses (CAPEX)
anu opeiating expenses (OPEX). A netwoik that ieguiies constant upgiaues (Loth
haiuwaie anu soltwaie), iegaiuless ol how last it is, is not leasiLle in these eco-
nomically conseivative times. Any netwoik must have sulliciently tiaineu techni-
cians to maintain the netwoik at peak peiloimance. A common set ol languages
acioss the eguipment scope ieuuces the tiaining costs anu ultimately the opeiating
expenses ol a netwoik. The same is tiue loi any management system that ieguiies
the ueployment ol venuoi-specilic management platloims; again, this is not leasi-
Lle in any economy. The management systems shoulu Le Laseu on an open system
that uses stanuaiu piotocols anu allows integiation Letween multiple venuois.
30 | Chapter 2:Enterprise Design
Sca|abi|ity
The goal ol any enteipiise is to make money. Most enteipiises uo this Ly giowth
in theii piouuct, seivices, anu olleiings. Any netwoik uesign must Le aLle to hanule
the same giowth expectations as the enteipiise. The populaiity ol giowth clouu
computing is an example ol this tienu. Vhy invest in application seivei haiuwaie
when the seiveis aie unueisizeu immeuiately upon ueployment? Vhy not ient
seivei space anu iun youi applications on someone else`s haiuwaie? Any netwoik
uesign has to Le aLle to scale up anu uown easily (avoiuing loiklilts il possiLle).
Because ol the lieguency ol meigeis anu acguisitions, any uesign shoulu have an
ease ol integiation with othei eguipment, ueploying open stanuaius loi piotocols
at application piogiam inteilaces (APIs). Because not all netwoik giowth comes
with a guaiantee ol capital expenses giowth, inciemental Lounuaiies in the net-
woik shoulu have a minimum impact on the Luuget (again avoiuing the loiklilt).
Vhen uevices that weie ueployeu in the past cannot Le useu in the
cuiient uesign, they must Le ieplaceu wholesale loi the new uesign
to lunction. So a loiklilt is necessaiy to iemove the olu eguipment
anu Liing in the new eguipment. Vhen examples ol technologies
anu venuois cannot scale, they aie ieleiieu to as jor||ijts.
Ejjicicncy
Theie is an inheient tiaue-oll Letween suivivaLility anu elliciency in a netwoik
uesign. Il enough haiuwaie anu connectivity is auueu to suivive lailuies, each el-
ement is unueiutilizeu. Maximize the elliciency liom each element, anu when a
lailuie occuis, theie is not enough capacity to hanule all the tiallic without a loss.
Vithin an enteipiise netwoik, tiansmission links aie not the only aieas wheie
elliciency must Le measuieu. Netwoik noues, seiveis, application silos, anu entiie
uata centeis aie Leing analyzeu to ueteimine theii elliciency anu suivivaLility. The
alteinative to ieuunuant passive elements is to incoipoiate loau-shaiing anu/oi
loau-Lalancing technologies to egually spieau the enteipiise loau ovei all elements
ol the netwoik. This allows the netwoik to aLsoiL tiallic spikes anu outages moie
easily. A Lenelit ol spieauing the loau ovei all elements is that all elements aie in
constant use. (Netwoiking is iile with stoiies ol how stanuLy lacilities laileu to
opeiate as expecteu just at the time when they weie neeueu.) A ciisis is not the
time to linu out that the Lackup system is not opeiational!
Conncctivity
The piincipal goal ol any netwoik is to pioviue any-to-any connectivity, Lut the
uesign consiueiations tenu to Le moie iestiictive than just optimal connectivity. It
woulu Le cost-piohiLitive to pioviue lull Lanuwiuth Letween all uevices in an en-
teipiise. The goal ol connectivity is a tiaue-oll Letween cost anu connectivity. The
connectivity goal shoulu Le that all communities ol inteiest will have Lanuwiuth
to peiloim theii lunctions. Auuitional goals, oi possiLly challenges loi connectiv-
ity, incluue a ieuuction in latency loi tiallic anu the aLility to maintain connectivity
Design Guidelines | 31
in the event ol a lailuie. The goals loi connectivity span many othei goals as well
(e.g., elliciency, secuiity, multiseivices).
Sccurity
Secuiity anu connectivity woik togethei in the enteipiise netwoik. The goals as-
sociateu with secuiity loim two uistinct camps. The liist type ol secuiity is asso-
ciateu with the suivivaLility ol the netwoik. Vill the netwoik continue to opeiate
in the lace ol haiuwaie, soltwaie, link, oi noue lailuies? Il possiLle, will the netwoik
conveige in a timely mannei as a iesult ol a lailuie, eithei automatically oi man-
ually, anu at what cost in lailovei lacilities?
Inloimational secuiity is the othei camp. Does the netwoik pioviue the integiity,
conliuentiality, anu availaLility ol inloimation as ieguiieu Ly coipoiate secuiity
plans? Vhat aLout leueial anu inuustiy guiuelines? Can the tiallic Le segmenteu
into secuiity silos, allowing intia-silo connectivity Lut iestiicting intei-silo tiallic?
Vhat aie the ieguiiement loi usei access contiol anu uynamic allocation ol con-
nectivity Laseu on usei ioles anu pioliles? All these elements lall unuei the goals
ol secuiity.
Trajjic typcs
Compaieu to the goals ol secuiity anu connectivity, the challenge ol hanuling uil-
leiing tiallic types seems tiivial. Most enteipiise netwoiks aie Laseu on the tians-
poit ol IPv+ tiallic (although othei piotocols can still Le lounu). Most enteipiises
have some ieguiiements Laseu on the IPv6 stanuaiu, Lut most have not yet ue-
ployeu this set ol piotocols. Although the majoiity ol tiallic touay is unicast, mul-
ticast is Lecoming a common uesign ciiteiia loi enteipiise netwoiks.
The uepletion ol IPv+ auuiesses will Le a ciitical issue. At the time
ol this wiiting, the last ol the unassigneu auuiesses have Leen
ueployeu!
Mu|tiscrvicc
Although an aigument coulu Le maue loi oi against the neeu loi IPv6, theie is no
such ueLate when it comes to the uilleientiation ol tiallic within the enteipiise
netwoik. In the tiaue-oll Letween connectivity anu elliciency, loau Lalancing is a
means to meet the goals ol Loth. Dilleientiation ol tiallic is anothei way to ap-
pioach that tiaue-oll. Il tiallic can Le classilieu anu uilleientiateu in the netwoik,
only high-piioiity tiallic passes uuiing a lailuie. The uelinitions ol which tiallic is
high piioiity anu which tiallic is alloiueu special hanuling aie iooteu in the coi-
poiate goals loi the netwoik as much as the connectivity goals.
The othei aspect ol multiseivice netwoiks is the uilleientiation ol seivices that
shaie a common enteipiise netwoik. Voice, viueo, anu uata have all conveigeu to
Lecome Lits on the enteipiise netwoik. As long as unlimiteu Lanuwiuth is not liee,
enteipiise netwoiks have to tieat tiallic types uilleiently within the enteipiise.
32 | Chapter 2:Enterprise Design
Legacy Network Design
A look at the histoiy ol uata communications netwoik uesign, like the stuuy ol any
othei histoiy, lollows a ciiculai pattein in which histoiy iepeats itsell. In initial com-
munication patteins, 100 ol the tiallic was Letween uesktops anu mainliame com-
puteis in uata centeis. The intiouuction ol the woikgioup seivei changeu that pattein
to iellect an S0/20 iule: only 20 ol the tiallic was slateu to the uata centeis, with S0
iemaining in the woikgioup (see Figuie 2-1). As enteipiises iealizeu the value ol the
uata stoieu on these seiveis, they weie secuie in the uata centei. This change once
again alteieu the communications iatio to a 20/S0 split (S0 to/liom the uata centei,
20 within the woikgioup). Touay the tiallic patteins in the enteipiise cannot Le
explaineu Ly a simple iatio ol tiallic to anu liom the woikgioup; insteau, they contain
seivei-to-seivei tiallic, peei-to-peei tiallic, Inteinet tiallic, anu the legacy client-seivei
tiallic.
Iigurc 2-1. 80/20 trajjic pattcrn
In the 1990s, uuiing the migiation liom the S0/20 to the 20/S0 tiallic pattein, the thiee-
tiei uata centei uesign was uevelopeu, iepiesenting the coie, uistiiLution, anu access
tieis (see Figuie 2-2). The uesign was Laseu on the cuiient tiallic patteins, limitations
in that peiiou`s state-ol-the-ait eguipment uesign, anu the neeu loi secuiity. The uesign
Design Guidelines | 33
was championeu Ly Cisco Netwoiks anu has loimeu the Lasis ol most enteipiise in-
stallations Ly that company.
The lunctions ol the tieis aie:
Corc |aycr
The coie layei is a high-speeu switcheu LackLone. Since iouteis at the time coulu
impact peiloimance, high-speeu switching is employeu. The coie is typically com-
piiseu ol a ielatively small numLei ol high-enu switches connecteu in a lull mesh
topology. Scaling in the coie is peiloimeu Ly ieplacing the switches with highei-
speeu uevices (anu loiklilts). The coie is iesponsiLle loi connecting tiallic Letween
the vaiious uistiiLution layei iouteis.
Distribution |aycr
The uistiiLution layei, sometimes calleu the aggiegation layei, pioviues the con-
nectivity Letween the coie anu access layeis. This layei is compiiseu ol iouteis anu
liiewalls that inteiconnect the vaiious technologies ol the access layeis to the high-
speeu coie switches. The uistiiLution layei is iesponsiLle loi secuiing the vaiious
enteipiise gioups anu summaiizing anu aggiegating ioutes Letween enteipiise
suLnets lounu in the access layeis.
Acccss |aycr
The access layei pioviues the connections to the enu stations anu seiveis. The
access layei, like the coie, is a switcheu layei that olleis ieliaLle connectivity to the
uistiiLution layei. Reuunuancy in the access layei is accomplisheu with the use ol
multiple uplinks to the uistiiLution seiveis.
Iigurc 2-2. Thrcc-ticr dcsign
34 | Chapter 2:Enterprise Design
The VAN layei, which is not commonly associateu with the thiee-tiei
uesign, pioviues intei-site communications anu Inteinet access. The
VAN layei uses ieuunuant links to the coie layei loi ieliaLility anu can
pioviue secuiity as well as connectivity. The VAN layei is consiueieu
a iouteu layei.
The iationale loi the thiee-tiei uesign is Laseu on a numLei ol technological lacts ol
the peiiou. The pieuominant lactoi was the cost ol piocessing powei; alloiuaLle iouteis
weie not capaLle ol hanuling the lull thioughput ieguiiements ol laige enteipiises.
Anothei lactoi was the ielative simplicity ol Etheinet switches, which olleieu high
speeu at the cost ol lunctionality. DumL switches loiwaiueu tiallic in a nonuetei-
ministic lashion limiteu only Ly taLle sizes anu the speeu ol a shaieu Etheinet link.
SuivivaLility in the thiee-tiei uesign is suppoiteu Ly ieuunuancy. Back-up iouteu links
anu multiple switcheu links ollei lailuie piotection liom Loth link anu noue lailuie.
Reuunuant switcheu links cieate the possiLility ol Lioaucast stoims with theii associ-
ateu outages. To avoiu this uevastating situation, the spanning tiee piotocol (STP) is
employeu. STP ensuies a stoim-liee netwoik at a cost ol elliciency on the links.
In a lull mesh loui-switch netwoik with STP iunning, one thiiu ol the links aie Llockeu
liom caiiying tiallic (Figuie 2-3).
Iigurc 2-3. Loop-jrcc switchcd nctwor|
STP iecoveis liom link lailuie Ly means ol a seiies ol timeis that monitoi the health ol
links anu noues. Once these timeis expiie, the netwoik conveiges to anothei loop-liee
Design Guidelines | 35
topology. The conveigence time can cause uisiuption to communications loi 10 sec-
onus oi moie. Although RSTP can shoiten this uisiuption time, the amount ol time
that it takes to iecognize a lailuie anu iecovei is not acceptaLle in the enteipiise touay.
Scaling in the thiee-tiei netwoik is limiteu. The coie layei is limiteu Ly the ieguiiement
loi lull mesh connectivity, the uistiiLution layei is limiteu Ly conveigence inteivals anu
inteilaces, anu the access layei is limiteu Ly the numLei ol uplinks anu access inteilaces
pei uevice. These limitations uictate a scaling Ly multiplication. As the enteipiise net-
woik giows, auuitional veitical silos aie auueu to the uesign to accommouate the auueu
tiallic (see Figuie 2-+).
Iigurc 2-1. Thrcc-ticr sca|cd
This scaling philosophy incieases the numLei ol inteilaces anu links at the coie layei,
the amount ol tiallic Letween silos, anu the numLei ol iouteu hops Letween access
uevices. Il the aujacent silo is geogiaphically sepaiateu, all the tiallic has to Le sent
thiough the VAN layei.
The technical issues inheient in the thiee-tiei uesign that make it unsuitaLle loi the
enteipiise touay also incluue:
A change in the tiallic patteins in the enteipiise makes the thiee-tiei uesign
inellicient.
The conveigence times associateu with STP aie inconsistent with nonstop
computing.
36 | Chapter 2:Enterprise Design
The iepeateu iouting latency associateu with the thiee-tiei uesign is not acceptaLle
to low-latency seivei-to-seivei communications.
Secuiity must Le integiateu at all layeis ol the uesign, not only at the euges.
The low-link utilization associateu with STP anu ieuunuant alteinate ioute paths
is uneconomical.
The thiee-tiei uesign uoes not ollei a common classilication ol seivices loi tiallic.
The scalaLility costs ol the uesign aie veiy high.
The New Network
The uesign philosophy piesenteu in this Look pioviues a means to migiate the legacy
enteipiise uesign anu emLiace the new technologies olleieu Ly ]unipei Netwoik uevi-
ces. The changes to the uesigns meet the new linancial anu technological iealities ol
the enteipiise netwoik. The uesign philosophy is to ieuuce the thiee-tiei (plus VAN)
uesign liom thiee tieis to two tieis, to possiLly a single tiei (see Figuie 2-5).
Iigurc 2-5. Dcsign nigration
These new iealities incluue Lut aie Ly no means limiteu to:
Thc 70/30 trajjic nodc|
In the new netwoik uesign, 70 ol the tiallic is peei-to-peei tiallic liom uevices
(useis oi seiveis) at the access layei, anu the iemaining 30 ol tiallic is to anu liom
the access layei. Peei-to-peei netwoiking anu seivei-to-seivei tiallic loim a gieatei
pait ol the enteipiise tiallic mouel than legacy client-seivei tiallic. One example
is the use ol HTTP loi most enteipiise lunctions. A client kicks oll a tiansaction
Ly connecting to a seivei (possiLly lilling out a loim oi ieguesting a seivice). The
HTTP seivei takes this ieguest loi seivice, communicates to othei Lack-ollice
seiveis to veiily the usei, communicates to possiLly anothei seivei to place the
ieguest, ieceives the iesponse to the seivice ieguest, stoies the iesponse on anothei
Design Guidelines | 37
seivei loi secuiity, anu linally iesponus to the ieguesting client. The minoi input
liom the client causes a toiient ol inloimation llowing Letween the seiveis.
Sccurity
Because ol secuiity iestiictions imposeu Ly coipoiate anu goveinmental policies,
most enteipiise netwoiks must segment theii seiveis into piocessing silos. Access
to anu communications Letween silos must Le secuieu. Enteipiise uata centeis aie
moie vulneiaLle touay than evei Leloie. Data centei stoiage typically is measuieu
in pctabytcs ol uata. Backing up these systems can cause congestion anu netwoik
tiallic spikes that must Le hanuleu.
Mininizc dc|ay
In touay`s coipoiate enviionment, milliseconus count. Vhethei the enteipiise
netwoik is useu loi electionic tiauing, inventoiy contiol, linancial uealings, oi
seivei Lackups, each lunction ielies on suLseconu iesponse times. Delays in the
netwoik aie auuitive, anu so as tiallic passes Letween clients anu seiveis anu Le-
tween seiveis, each stop causes an auueu uelay. Vhat`s moie, iouteis in the path
also cause uelays. The loimei is a iesult ol the piocessing scenaiio, anu the lattei
the iesult ol the netwoik uesign. In the past, the piocessing uelay associateu with
a ioutei was small compaieu to the seiialization uelay associateu with putting a
liame on the wiie. As the Lanuwiuth ol links giows, the seiialization uelay shiinks.
As Lanuwiuth continues to giow, the uelay associateu with iouting tiallic Lecomes
the gating lactoi ol the eguation. In any enteipiise uesign the numLei ol iouteu
hops must Le minimizeu to ieuuce the inheient uelay.
Ejjort|css sca|ing
Coipoiate meigeis, acguisitions, lailuies, anu Lankiuptcies aie all a lact ol lile,
which means no netwoik is in a steauy state loi any length ol time. Any enteipiise
uesign must Le aLle to giow oi shiink as the ieguiiements ol the enteipiise change
while Leing minulul ol the Lottom line, since all assets aie paieu to the minimum.
Link utilization, poit uensities, powei usage, anu occupieu space aie all conceins
ol the enteipiise netwoik, Lut any uesign must also have a smooth migiation stiat-
egy that allows high utilization at a minimal inciemental cost.
\irtua|ization
A one-to-one alignment ol a uevice to a lunction is no longei valiu. Because ol
viitualization, a single uevice can pioviue multiple lunctions, oi a single lunction
can Le spieau ovei multiple uevices. Viitualization is appeaiing in the uata centei
anu the netwoik, anu the viitualization ol applications in the uata centei allows a
new level ol scalaLility anu ieliaLility in an aiea that has histoiically lackeu Loth.
Viitual seivices can Le installeu, moveu, expanueu, anu accesseu acioss any num-
Lei ol physical seiveis. In the netwoiking enviionment, viitualization allows single
uevices to act as physically sepaiate uevices oi physically sepaiate uevices to act as
a single uevice. Enteipiise netwoik viitualization capaLilities ieuuce the costs as-
sociateu with the uevices (Loth OPEX anu CAPEX) anu allow the llexiLility neeueu
to meet the uemanus ol the seivice viitualization.
38 | Chapter 2:Enterprise Design
Vith these new-netwoik lacts ol lile stuck in youi minu, let`s look at what happens
when existing netwoik uesigns aie piesenteu alongsiue these new goals ol the entei-
piise. Foi each example, a new uesign is piesenteu that meets the existing goals anu
acknowleuges the new iealities ol technology.
Dual Star Internet Access
As enteipiises giow, the neeu loi Inteinet access giows accoiuingly. As the enteipiise
takes on moie ol a puLlic-lacing Inteinet piesence, access Lecomes an impoitant coi-
poiate asset iathei than an employee peik. In this scenaiio, oui sample enteipiise olleis
a host ol weL-Laseu seivices to the geneial puLlic. It also ielies on secuieu weL-Laseu
poitals loi iemote ollices anu employees who aie in the lielu. Foi this enteipiise, the
Inteinet has Lecome the access mechanism loi most uay-to-uay Lusiness tiallic, anu
without it, the enteipiise woulu sullei gieatly.
Recognizing the impoitance ol the Inteinet anu the thieats that exist in this enviion-
ment, all access to anu liom the Inteinet is secuieu. Fiiewalls aie placeu to pievent
unwanteu tiallic, intiusion uetection anu pievention systems (IDP) aie in place to
monitoi loi secuiity thieats in the peimitteu tiallic, anu content lilteis aie in place to
ensuie that enteipiise use policies aie auheieu to. The two Inteinet leeus aie liom
uilleient ISPs anu aie teiminateu in lacilities that aie in the same metiopolitan aiea.
Existing Internet Access Design
The existing Inteinet access, as shown in Figuie 2-6, is an evolveu uesign that has
expanueu as auuitional ieguiiements have Leen auueu to the enteipiise. Each lunc-
tional auuition was implementeu in a sepaiate uevice. VLANs pioviue tiallic segmen-
tation in the Etheinet switches thiough the use ol inuepenuent inteilaces on the iouteis
anu liiewalls.
The uesign incoipoiates multiple layeis ol switches anu iouteis, the iesult ol incie-
mental giowth anu its ieliance on the Inteinet iathei than a single uesign philosophy.
The enteipiise coie switches connect to a seiies ol egiess switches. The insiue-egiess
switches suppoit tiusteu tiallic, while the outsiue-egiess switches hanule a mixtuie ol
tiusteu anu untiusteu tiallic. Both sets ol switches aie inteiconnecteu with Etheinet
tiunks that aie piovisioneu ovei ueuicateu liLei Letween the uata centeis.
Each enteipiise lunction that ielies on Inteinet connectivity has a sepaiate liiewall. All
liiewalls aie piovisioneu in a piimaiy/seconuaiy ielationship, with all tiallic passing
thiough the piimaiy uevice. A ueuicateu connection Letween the piimaiy anu secon-
uaiy pioviues a keepalive loi lailuie uetection. In the event ol a lailuie ol one uevice,
the othei is activateu anu staits iesponuing to ARP ieguests (Loth liiewalls have the
same IP auuiesses).
Dual Star Internet Access | 39
HTTP tiallic is iouteu thiough a content liltei seivei that allows oi Llocks access to
Inteinet pages. The content liltei seiveis also aie ueployeu in a piimaiy/seconuaiy
ielationship Laseu on which Inteinet access point is active.
Design Goals and Constraints
This enteipiise, like most touay, is constiaineu Ly its Luuget. Funus loi capital
impiovements aie allocateu once a yeai, anu opeiating Luugets aie lixeu. Any
Iigurc 2-. Existing dua| |ntcrnct acccss dcsign
40 | Chapter 2:Enterprise Design
impiovements involving Inteinet access have to show a ietuin on investment in eithei
impioveu seivices oi a ieuuction in opeiating expenses.
The enteipiise is having a management ciisis Lecause auuitois ieguiie that all changes
to the liiewall policies have a papei tiail anu that all tiallic Le loggeu. Each liiewall is
manageu Ly a uilleient gioup, anu a change in Inteinet policy coulu allect as many as
thiee active liiewalls anu theii Lackups.
One woulu also assume that the enteipiise neeus to inciease the speeu ol Inteinet access
(liom 100 MLps to 1 GLps) anu wishes to use Loth ISPs as active links. They want to
inciease the speeu ol the links to the coie Ly the same amountan inteimeuiate step
in the long-iange plan ol having multiple 10 GLps links to the Inteinet.
Solution: Dual Internet Access Design
The solution to this uesign, as shown in Figuie 2-7, auuiesses thiee ciitical goals ol the
enteipiise: secuiity, management, anu scalaLility.
Iigurc 2-7. Dua| |ntcrnct acccss so|ution
As Figuie 2-7 illustiates, the secuiity loi the enteipiise has Leen consoliuateu into two
liiewalls, each hanuling the policy, IDP, anu content lilteiing lunctions.
The vaiious liiewalls anu theii sepaiate logging, access, anu policies aie now incoipo-
iateu into a clusteieu paii ol SRX5S00s. Sepaiate secuiity zones aie cieateu loi inteinal
Dual Star Internet Access | 41
anu exteinal inteilaces. The inteiconnecting links caiiy Loth the intei-SRX tiallic anu
the contiol inloimation, allowing Loth liiewalls to maintain the tiallic session inloi-
mation. The liiewalls opeiate in an active/active conliguiation, Loth passing tiallic to
anu liom the ISPs. All outgoing tiallic to the Inteinet is netwoik auuiess tianslateu to
an auuiess pool that is pieleiieu Ly the local ISP. All tiallic to incoming seiveis is also
tianslateu liom gloLal auuiesses that aie pieleiieu on one ISP. This use ol NAT anu
ioute pieleience limits the amount ol asymmetiical tiallic to anu liom the Inteinet.
The HTTP content lilteiing is implementeu Ly the use ol liltei-Laseu loiwaiuing. All
outgoing ieguests loi HTTP content aie loiwaiueu Ly the SRX to one ol the two content
liltei seiveis. This aiiangement allows Loth lilteis to opeiate inuepenuently ol each
othei anu caiiy gieatei amounts ol tiallic.
The IPS capaLilities ol the SRX aie now employeu to ieplace the stanualone IDS uevices
anu the SNORT uevice. IDP is employeu as necessaiy loi tiallic that passes thiough
secuiity policies in the liiewall. Tiallic that uoes not waiiant IDP Lypasses this lunction.
VPN useis aie accommouateu as well within the SRX, Lecause the SRX5S00 can hanule
30 GLps ol enciypteu tiallic loi Loth point-to-point (P2P) anu iemote useis.
The suivivaLility aspect ol the secuiity is pioviueu Ly a comLination ol Layei 3 lailovei
anu clusteiing. Because ol the ieguiiement ol using Loth ISPs, an active/active conlig-
uiation is ueployeu. In this conliguiation, Loth liiewalls aie actively passing tiallic anu
also monitoiing the tiallic passeu on the othei uevice. In the event ol an SRX lailuie,
the othei SRX will tiansmit an ARP anu hanule all existing sessions. The Layei 3 lailovei
peiloimance is impioveu Ly the use ol Liuiiectional loiwaiuing uetection (BFD). This
RFC-Laseu piotocol assuies lailuie uetection in suLseconus, theieLy ieuucing convei-
gence on OSPF anu BGP links.
The scalaLility ieguiiements aie met with a comLination ol inteilaces anu piotocols.
The SRX suppoits Loth 1 anu 10 gigaLit Etheinet inteilaces, anu the SRX5S00 will
hanule a minimum ol 30 GLps thioughput (all tiallic going thiough IDP). Foi those
connecting uevices that uo not have 10 GLps inteilace capaLility, the SRX olleis Ethei-
net link aggiegation.
The management nightmaie ol the enteipiise is solveu Ly a single souice loi auuit anu
tiallic logs. All ]unos uevices maintain a cache ol pievious conliguiations, anu each
pievious conliguiation lists the time, uate, anu peison who peiloimeu the change. The
onLoaiu stoieu conliguiation plus the aichive-on-commit leatuie ensuie that no
changes can Le maue without a piopei papei tiail. Access to the liiewall is contiolleu
Ly a RADIUS seivei that contiols useis anu peimissions within the liiewall. Finally,
tiallic logs anu IDP logs aie stoieu oll-Loaiu on secuieu syslog seiveis (a ]unipei Net-
woiks STRM uevice).
The migiation Letween the olu uesign anu the new is peiloimeu in a phaseu mannei.
The initial cut-ovei ol the Inteinet liiewall anu Inteinet Loiuei ioutei allows a clean
uivision ol lunctions anu a secuie iollLack position il necessaiy. Once the Inteinet
42 | Chapter 2:Enterprise Design
tiallic is passing thiough the SRX, all othei tiallic is migiateu one lunction at a time.
This scenaiio allows each lunction to Le lully testeu anu veiilieu piioi to moving onto
the next change.
Data Center and Disaster Recovery (DR) Architecture
Data centeis that weie uesigneu aiounu the S0/20 tiallic concept cannot easily hanule
tiallic patteins seen in touay`s uata centei. Tiallic Letween seivei silos must pass up
liom the access layei, thiough the uistiiLution layei, thiough the coie, anu Lack uown
again. This incieaseu piocessing allects scalaLility anu latency.
In oui next uesign scenaiio, the uistiiLution layei auus anothei set ol iouteis anu a
liiewall into the mix. All in all, the inciease in piocessing contiiLutes to a six-hop path
loi tiallic Letween the seiveis in uilleient silos.
The seiveis anu the stoiage aiea netwoiks (SANs) in this netwoik aie the piouuct loi
this example enteipiise. Vithout secuie, ieliaLle access to these seiveis anu theii con-
tent, the enteipiise can neithei lunction noi make a piolit. The cuiient uesign is Laseu
on the concept ol nonstop secuie computing in oiuei to pioviue Lack-ollice seivices
loi aiea coipoiations. All seivices aie ieacheu via IPSec VPNs oi SSL VPNs. All tiallic
passes thiough liiewalls as an auueu piotection against unintenueu useis. The entei-
piise maintains two uata centeis that aie geogiaphically sepaiateu anu miiioi each
othei, anu thiough the use ol viitual seivices, eithei site can seive a customei egually
well.
Multitier Data Center Design
The uata centei netwoik uesign shown in Figuie 2-S is typical loi seivei peiloimance
anu suivivaLility. All tiallic to oi liom the seiveis anu the SAN is lilteieu Ly liiewalls
anu segmenteu Ly viitual segmentation (VLANs). Tiallic liom a customei`s location
enteis the uata centei thiough the egiess liiewall paii. Once past initial scieening, the
tiallic is iouteu to one ol the outsiue uistiiLution iouteis loi piocessing. The outsiue
uistiiLution ioutei ueteimines which silo to access anu ioutes the tiallic thiough the
liiewalls anu the insiue uistiiLution iouteis to the access switches (loau-Lalancing al-
goiithms associateu with the outsiue uistiiLution iouteis ensuie an egual loau loi all
seiveis). Each lunctional seivice anu each customei`s seivice is secuieu Ly the use ol
VLANs within a stack. Tiallic Letween stacks uses a Q-in-Q metio-Etheinet seivice loi
connectivity.
Because ol the high uemanus ol uata shaiing anu Lackups Letween the uata centeis, a
seconu means ol connectivity is estaLlisheu to inteiconnect the SANs. This inteicon-
nection is a piivate IP seivice that tianspoits liLei channel ovei IP tiallic Letween the
SAN switches.
Data Center and Disaster Recovery (DR) Architecture | 43
The suivivaLility ol the system is achieveu thiough iouting piotocols. Exteiioi BGP
(EBGP) is useu extensively thioughout the uata centei uesign, so it is possiLle to tailoi
the ioutes Letween the uistiiLution iouteis (insiue anu outsiue), the liiewalls (egiess
Iigurc 2-8. Lcgacy data ccntcr dcsign
44 | Chapter 2:Enterprise Design
anu inteinal), anu the access switches. In the event ol a lailuie ol any link oi uevice,
BGP will use a seconuaiy ioute to the uestination.
East-to-west tiallic is ueteimineu Ly the egiess liiewall oi Ly the outsiue uistiiLution
iouteis. Il the outsiue uistiiLution iouteis ueteimine that the tiallic is to tiaveise the
netwoik, a VLAN on the metio-Etheinet link is useu.
All links Letween the uevices caiiy all the viitual instances, except loi the inteinal
liiewalls. In this case, each liiewall is ueuicateu to a customei oi lunction. The liiewalls
opeiate inuepenuently ol each othei, Loth in one stack anu Letween east anu west. The
BGP iouting ensuies that asymmetiical iouting uoes not occui.
The management ol the uesign is veiy laLoi intensive. The BGP policies anu the liiewall
policies keep the management team Lusy. Tiallic monitoiing, uesign mouilications,
anu moves, auus, anu changes loi customeis anu lunctions is anothei lull-time joL.
Goals and Constraints
The goals anu constiaints lounu in the uata centei can Le gioupeu into the lollowing
paiameteis:
Physica| p|ant |initations
Vhen the costs associateu with leasing space in a uata centei aie compounueu
with the cost ol powei anu cooling, you have an incentive to go gieen. Eveiy time
a uevice can Le eliminateu liom a uesign, the cost savings in ieal estate, powei, anu
cooling can Le auueu to the Lottom line ol pioject. Unless an enteipiise has the
luxuiy ol owning the uata centei anu its own powei plant, the size anu elliciency
ol the uevices aie ciitical consiueiations.
Scrvcr virtua|ization and |oad ba|ancing
To light the haiuwaie limitations ol seiveis, loau Lalancing anu seivei viitualiza-
tion aie useu to smooth applications ovei many seiveis anu to put useis wheie the
CPU cycles aie availaLle. The use ol viitualization anu loau Lalancing changes the
tiallic patteins.
Sinp|icity
Management ol a uata centei is getting moie anu moie complex. As moie appli-
cations anu moie useis access the centei, moie viitualization anu hoiizontal tiallic
appeais. Tiacing piocesses might span multiple seiveis anu multiple silos. Any
simplilication in the inliastiuctuie will ieuuce tiouLleshooting Luiuens.
Data ccntcrs conso|idation
As this enteipiise will attest, moie anu moie seivices anu applications aie moving
to the uata centei anu away liom woikgioups anu local seiveis. Clouu computing
is nothing moie than the consoliuation ol moie usei inloimation in lewei uata
centeis.
Data Center and Disaster Recovery (DR) Architecture | 45
Pcrjornancc and sca|c
The oiiginal uesign ol the uata centei was limiteu in scale Ly its aichitectuie. As
moie seiveis aie auueu, moie switches aie auueu, anu as moie switches aie auueu,
moie uistiiLution poits, liiewalls, anu coie poits aie neeueu. At some point a new
stack will Le ieguiieu Lecause ol the limitation ol the haiuwaie. This Look`s liguies
woulu neeu to Le vieweu in thiee uimensions to cleaily see all the inteiconnectivity.
Avai|abi|ity and agi|ity
The oiiginal uesign piesenteu a high-availaLility uesign with little agility. The use
ol EBGP anu iouting policies to contiol ioutes anu iecovei liom lailuies pioviueu
high availaLility Lut sulleieu liom the unknown. It is not agile enough to cope with
the unexpecteu lailuie oi the unplanneu expansion.
Solution: Data Center Design
The alteinative to the multitiei uata centei uesign is to consoliuate anu ieuuce. The
new uesign, as shown in Figuie 2-9, auuiesses most ol the goals anu conceins ol the
enteipiise without saciilicing availaLility oi secuiity. The uesign is a two-tiei appioach
composeu ol a coie uistiiLution tiei implementeu in an MX960 anu an access tiei
implementeu in a viitual chassis aiiangement ol EX+200s.
Secuiity is now pioviueu Ly an SRX3600 opeiating as a liiewall-on-a-stick loi tiallic.
The SRX is piovisioneu with a viitual ioutei pei customei oi lunction anu can pioviue
IPSec VPN teimination suppoit as neeueu.
The uesign uses the same loau Lalancei as the pievious uesign, Lut attacheu to the MX
chassis to ensuie even uistiiLution ol tiallic acioss the seiveis. Routing in the uesign is
pei-instance OSPF, with BFD loi ieuuceu conveigence times. The MX is viitualizeu on
a pei-VLAN (silo) Lasis. All intei-VLAN tiallic llows thiough the SRX, while all intia-
VLAN passes thiough the MX without the SRX.
East-to-west tiallic llows ovei an MPLS connection that mimics the MX viitualization
with L2VPNs pei customei. These connections will hanule Loth usei tiallic anu SAN
tiallic.
The access switches ieuuce the total numLei ol links to the uistiiLution netwoik while
maintaining a Lettei utilization than the oiiginal uesign. The links aie Etheinet aggie-
gation links Letween the MX anu the EX viitual chassis. The uesign ol the chassis allows
the inuiviuual links to Le on sepaiate uevices anu still paiticipate in a link aggiegation
gioup (LAG). STP is not iun heie, so lull utilization is possiLle on all links.
Access to the SAN is also pioviueu via the EX+200. The switch suppoits liLei channel
ovei Etheinet inteilaces, allowing uiiect connections to the stoiage aiea netwoik.
46 | Chapter 2:Enterprise Design
Iigurc 2-9. Conso|idatcd data ccntcr dcsign
This new netwoik uesign llattens the uata centei anu pioviues these Lenelits:
Reuuceu eguipment count, saving llooi space, powei, anu cooling
Reuuceu hop count, so usei-to-seivei anu seivei-to-seivei communications have
minimal piocessing
Reuuction in links anu ioutes simplilies the aichitectuie while maintaining avail-
aLility anu ieliaLility
ScalaLility Ly using MPLS anu a two-tiei uesign, so scaling Lecomes a mattei ol
meiely auuing gieatei access switches
Fiom a suivivaLility peispective, the new uesign coulu Lecome even moie ioLust Ly
clusteiing the SRX3600s, anu the MXs coulu Le set in a viitual clustei. These capaLil-
ities, while costly in eguipment, space, powei, anu cooling, woulu pioviue anothei level
ol suivivaLility that might Le ueemeu necessaiy Ly the enteipiise.
Data Center and Disaster Recovery (DR) Architecture | 47
Vhat is not necessaiy is the associateu inciease in the numLei ol links Letween these
suivivaLle elements anu the othei uevices, as shown in Figuie 2-10. Vhen the links aie
piovisioneu as eithei LAG links oi ieuunuant Etheinet links, they can iesiue on eithei
memLei ol the paii ol uevices, pioviuing the same availaLility anu elliciency as the
pievious uesign with an inciease in suivivaLility.
The MX960 is availaLle with ieuunuant iouting engines, switch laLiic,
powei supplies, anu cooling systems. The viitual chassis aiiangement
guaius against a chassis lailuie.
Iigurc 2-10. U|tra-survivab|c data ccntcr
48 | Chapter 2:Enterprise Design
Campus Architecture
Univeisity campuses have not Leen immune to the changes in Inteinet use. Social net-
woiking, lile shaiing, anu peei-to-peei netwoiking aie all aspects ol a univeisity cam-
pus`s inteinal netwoik, anu the uays ol using the Inteinet solely loi ieseaich anu
uevelopment aie long gone. One campus secuiity auministiatoi stateu that he hau two
untiusteu netwoiks to ueal with: the campus anu the Inteinet. Secuiity anu Lanuwiuth
conceins aie such that univeisities anu coipoiations have ueployeu stanualone ReD
netwoiks, such as the Inteinet2.
The challenges lacing campuses touay aie similai to those laceu Ly enteipiises, Lut
with the auuition ol tens ol thousanus ol useis who olten have liee time on theii hanus
anu an allinity loi social netwoiking. The challenges can Le uiviueu into secuiity,
classes ol seivice, anu availaLility. The case that is piesenteu heie is loi a laige
univeisity.
Legacy Campus Backbone
Oui campus netwoik is uiviueu into thiee aieas: the common LackLone netwoik, the
uepaitmental netwoiks, anu the intei-univeisity LackLone. Each uepaitment maintains
its own uata centei anu ollice connectivity. Some uepaitments maintain Inteinet anu
extianet access anu liiewalls loi piotection (an enteipiise within the campus). Othei
uepaitments use the seivices ol the LackLone netwoik loi outsiue access (Inteinet anu
intei-univeisity).
Theie aie S0 uepaitments on the campus anu some 20,000 stuuents in uoimitoiies.
The legacy netwoik, as shown in Figuie 2-11, was uesigneu to act as a common Lack-
Lone Letween all Luiluings, anu as you can guickly guess, as uepaitmental uemanus
loi Lanuwiuth anu secuiity giew, moie oveilays weie auueu to the netwoik. Vhat is
uepicteu in Figuie 2-11 is just one ol the oveilay netwoiks; live such oveilays exist.
Most Luiluings aie connecteu to one oi moie ol the oveilay netwoiks, anu all ol the
netwoiks aie iouteu, with puLlic auuiessing Leing useu thioughout the campus.
A single ISP pioviues Inteinet access, with each liiewall ueuicateu on a pei-uepaitment
Lasis. In an attempt to avoiu viiuses anu othei nasties, a stack ol IDS uevices aie in-
stalleu to monitoi tiallic.
By the way, theie is no centializeu management loi the netwoik; each uepaitment has
its own management system, as uoes the LackLone.
Goals and Constraints
Univeisities, like enteipiises, aie Luuget-constiaineu, anu Loth CAPEX anu OPEX
Luugets aie unuei close oLseivation Ly each uepaitment anu the cential auministiation.
The LackLone netwoik must Lill Lack to the uepaitments anu colleges loi its seivices,
auuing anothei Luuget-ielateu complication.
Campus Architecture | 49
The management ol the netwoik is complicateu Ly piessuie liom gioups such as the
Recoiuing Inuustiy Association ol Ameiica (RIAA). The RIAA has Leen piessuiing the
univeisity to monitoi music tiallicking anu show uue uiligence in stopping copyiight
inliingements.
It seems that stuuents always linu ways to utilize all the availaLle Lanuwiuth on the
LackLone netwoiks anu the Inteinet, anu the univeisity must install a seivice classili-
cation system that will limit the amount ol tiallic accepteu onto the LackLone liom the
uoimitoiies. This allows uepaitments to have aueguate Lanuwiuth to peiloim theii
assigneu lunctions anu euucation ieguiiements.
One ol the seivices olleieu Ly the LackLone to the uepaitments is a manageu liiewall
seivice, anu the univeisity neeus an easy way to hanule auus, moves, anu changes loi
liiewall policies anu usei communities.
Solution: Campus Network
The solution to the campus LackLone is ieplacing technology anu ielying on viituali-
zation. The iouteu netwoiks aie Leing ieplaceu Ly a single Etheinet switch LackLone,
as shown in Figuie 2-12. Six EXS20Ss aie useu as the LackLone loi the campus. Each
EXS20S is uual-connecteu to othei LackLone switches, anu each is iunning VSTP. Each
Luiluing is seiveu Ly an EX+200. Geogiaphically aujacent Luiluings aie inteiconnecteu
Iigurc 2-11. Lcgacy canpus nctwor|s
50 | Chapter 2:Enterprise Design
with liLei to loim an intei-Luiluing viitual chassis. Each viitual chassis is connecteu to
multiple LackLone switches with a LAG Lunule, anu the EX+200s loim the access tiei
loi uepaitmental anu uoimitoiy tiallic.
The LackLone is connecteu in a uual-stai conliguiation to a paii ol MX960s. The MXs
aie the next hop ioutei loi all uepaitmental tiallic anu connect via BGP to the Inteinet
anu the intei-univeisity netwoik.
Associateu with each MX is an SRX5S00 iunning IDP seivices. The MX/SRX paiis aie
opeiating in a piimaiy/seconuaiy moue, with eithei capaLle ol hanuing the entiie loau
ol the univeisity.
Viitualization pioviues the secuiity anu contiols uepaitmental tiallic, as each uepait-
ment is assigneu a VLAN that appeais in the EX+200s only when memLeis ol the
uepaitments aie attacheu to that switch. The VLANs aie mappeu to a sepaiate viitual
ioutei in the MX960 anu the SRX5S00. Intia-VLAN tiallic is switcheu locally in the
LackLone, wheieas intei-VLAN tiallic must tiaveise the MX/SRX paii. The Inteinet is
on its own viitual ioutei, as is the intei-univeisity netwoik. A common iouting instance
on the MX allows the inteiconnection ol all the othei viitual iouteis.
Tiallic to anu liom the Inteinet anu the intia-univeisity netwoik is monitoieu Ly the
IDP policies. All policies aie loggeu (IDP anu secuiity) to a secuieu syslog system, anu
any ol the tiallic in the LackLone can Le miiioieu to tiallic-captuie seiveis.
Iigurc 2-12. Canpus nctwor| so|ution
Campus Architecture | 51
The EX+200s suppoit a loui-level class ol seivice capaLility that allows tiallic to Le
policeu at the ingiess point. Tiallic liom the uoimitoiies is classilieu anu policeu. The
ingiess inteilaces on the MXs also have thiesholus set loi stuuent tiallic anu peiloim
a tail-uiop lunction on excess tiallic.
Vithin the SRX, each uepaitment has a slice ol the liiewall. Each uepaitment can
contiact with the LackLone ollice loi liiewall seivice oi peiloim its liiewall lunctions
in the uepaitment netwoik. In the lattei case, the liiewall policies in the SRX aie pei-
missive. Il the uepaitment elects to use the LackLone seivices, then a lull set ol intei-
uepaitmental policies aie cieateu. Each uepaitment has two secuiity zones: the tiusteu
zone contains the inteilaces (anu VLANs) to the uepaitment, anu the untiusteu zone
has an inteilace to the common iouting instance on the MX. Tiallic always passes
thiough two liiewall policies when it leaves the uepaitment (the oiiginal uepaitment`s
policy anu the uestination uepaitment`s policy). The same is tiue loi Inteinet anu intei-
univeisity tiallic. This aiiangement allows lull llexiLility anu contiol ol all tiallic.
Conclusion: Design Best Practices
The solutions in these new netwoik uesigns all auheie to a common set ol uesign
piinciples:
Fiist, eveiy uesign is secuieu, Loth liom an inloimational secuiity peispective anu
liom a ieliaLility peispective.
Seconu, they comLine the lunctions ol the uistiiLution anu coie tieis into a single
tiei wheie possiLle.
Anu linally, they simplily the netwoik aichitectuie to the Lase elements, thus
ieuucing management, CAPEX, anu OPEX.
Foi any enteipiise uesign, nothing Leats homewoik. Touay, netwoiks aie complex
aiiangements that cannot Le lelt to chance. Each uesign must Le ieseaicheu, assemLleu,
pioven, anu then implementeu. This cycle nevei enus; as one uesign is implementeu,
anothei is in the ieseaich stage. That`s Lecause technology is moving at such a last pace;
il a netwoik is lelt to its own uevices, it will Le oLsolete in a veiy shoit time.
All ol oui netwoik ieuesigns useu ]unipei Netwoiks EX switches, MX euge iouteis,
anu SRX Seivices Gateways. ]unipei has cieateu uesign guiues loi most enteipiise
installations; see http://www.junipcr.nct/tcchpubs.
52 | Chapter 2:Enterprise Design
CHAPTER 3
Juniper Switching and
Routing Platforms
In the pievious chapteis ol this Look, we examineu ]unipei Netwoiks enteipiise uevices
anu uesigns to Liing you up to uate on what is happening in enteipiise netwoiking.
Howevei, we uiu not covei which uevices shoulu Le useu, wheie in the uesigns they
can Le useu, anu why those uevices aie Lest situateu loi such positions. Investigating
anu answeiing those guestions is the iole ol this chaptei.
Enterprise Network Roles
Rathei than ievisit each uesign liom the last chaptei, let`s use a simplei ieleience uesign.
Oui new ieleience uesign contains live types ol uevices, each useu to uesciiLe the uevice
ioles in the enteipiise netwoik. Listing them liom the outsiue ol the enteipiise netwoik
to the insiue, the live uevices aie: the scieening ioutei, the secuiity gateway, the Inteinet
Loiuei ioutei, coie iouteis, anu the access iouteis (see Figuie 3-1). The teim ioutei
is useu heie veiy loosely; in some cases an Etheinet switch is implementeu in the iel-
eience position in enteipiise netwoiks.
Iigurc 3-1. Entcrprisc rcjcrcncc diagran
53
Ol couise, enteipiise netwoiks vaiy wiuely in theii implementations. Some netwoiks
uo not have all these ieleience uevices, anu some have othei uevices not uelineu heie.
The choice ol uevice type is olten ueciueu in the topmost layeis ol the piotocol stack
(sometimes calleu layeis S anu 9, oi politics anu cost). Oui uevice iecommenuations
aie piimaiily Laseu on leatuies anu size, anu take into account those wiue-swinging
vaiiaLles, politics anu cost.
Screening Router
The classical scieening ioutei pioviues a Lullei Letween the piivate netwoiks anu
the Inteinet, with its piincipal lunction to piotect the othei uevices liom attacks oiig-
inating on the Inteinet. These lunctions incluue Lut aie not limiteu to:
Iircwa|| ji|tcrs
The scieening ioutei implements a seiies ol piotective liiewall lilteis that stop
unwanteu tiallic liom enteiing the enteipiise netwoik.
Nctwor| addrcss trans|ation
Il the enteipiise uses piivate auuiessing loi inteinal opeiations, the scieening ioutei
is a piime choice loi implementing that lunction.
Routing
The scieening ioutei typically will not implement BGP anu lull-size iouting taLles,
Lecause it has iouting piioiities to allow uilleientiating Letween inteinal tiallic anu
possiLly tiallic loi a uemilitaiizeu zone (DMZ). Such iouting is olten implementeu
in static ioutes.
Scrccn options
Denial ol seivice attacks can Le thwaiteu Ly the use ol the scieen options lounu in
select ]unipei uevices. These enhanceu liiewall options iecognize common attacks
anu stop them liom allecting inteinal uevices. (A lull listing ol the availaLle scieen
options anu the uevices that suppoit them can Le lounu in the ]unipei Netwoiks
knowleuge Lase at http://|b.junipcr.nct. Look loi KB1661S.)
Although the neeu loi a scieening ioutei might Le ueLateu, the lunctions peiloimeu
Ly this uevice cannot Le eliminateu liom the enteipiise netwoik. Foi netwoik engineeis
who ueploy a scieening ioutei, the choices aie ueteimineu Ly the uevice`s ieguiieu
inteilaces, the Inteinet access speeus, anu the secuiity leatuie set that is ieguiieu.
The ]-seiies iouteis anu the Bianch Ollice SRXs aie pieleiieu loi this iole. Both can
hanule Etheinet anu VAN inteilaces. The VAN inteilaces iange liom T-1 speeus to
DS-3s.
The choice Letween eithei the ]-seiies oi the SRX is one ol cost anu thioughput. Both
have the same leatuie set anu almost iuentical VAN inteilaces. The ]-seiies aie moie
tiauitional iouteis, wheieas the Bianch Ollice SRX mouels ollei cost savings Lut have
a lowei thioughput.
54 | Chapter 3:Juniper Switching and Routing Platforms
A ]2320 with high memoiy (1 GB DRAM anu 512 MB Flash) has a iateu
thioughput ol 600 MLps with laige packets anu +00 MLps with mixeu
packet sizes. The SRX220 with high memoiy (1 GB DRAM anu 1 GB
Flash) has a iateu thioughput ol 950 MLps with laige packets anu 300
MLps with mixeu packet sizes. The SRX220 lists loi ioughly hall the
cost ol the ]2320.
The political uecision ol whethei this is a liiewall to Le manageu Ly the secuiity gioup
oi a ioutei to Le manageu Ly the netwoik gioup might Le the ueciuing lactoi in which
uevice type you choose.
Security Gateway
The next uevice type in oui ieleience netwoik is the secuiity gateway. Although the
uselulness ol the scieening ioutei might Le ueLateu, the ieguiiement ol a secuiity gate-
way cannot. Due to the uniuly natuie ol the Inteinet touay, no enteipiise, SMB, oi
iesiuence can Le connecteu without the piotection olleieu Ly a secuiity gateway.
One ol the majoi uistinctions Letween secuiity gateways (aka liiewalls) is theii unuei-
lying tieatment ol tiallic. The two majoi uivisions in tiallic hanuling aie packet-Laseu
piocessing anu llow-Laseu piocessing. In a packet-Laseu system, each packet is tieateu
as an inuiviuual entity. Each is alloweu oi uenieu Laseu on the attiiLutes ol the packet
(anu possiLly the histoiy ol packets ol similai stiuctuie). These types ol uevices aie
ieleiieu to as statc|css jircwa||s.
The llow-Laseu uevices look at tiallic as pait ol a seguence ol packets woiking togethei
in a session. These uevices aie ieleiieu to as statcju| jircwa||s. The uistinction is easiei
to unueistanu with an example, as in Figuie 3-2, illustiating the state uiagiam loi a
noimal TCP session. Heie, a session is initially openeu when a SYN message is ieceiveu.
Vhen acknowleugment is ieceiveu, the session moves liom the opening to the open
state. In the open state, uata is passeu Letween the uevices engageu in the session. Once
the uata has Leen exchangeu, the session closing is initiateu with the senuing ol a FIN
message. The closeu state is the linal (iule) state loi TCP, anu is inuicateu Ly the ieceipt
ol the FIN acknowleugment message.
A stateless uevice woulu look at each TCP message inuiviuually anu act on it Laseu on
the inloimation containeu in the message. These attiiLutes aie compaieu to a secuiity
policy ol some kinu anu eithei alloweu oi uenieu Laseu on the action specilieu in the
policy. The auvantage ol the stateless uevices is theii simplicity. No histoiy is neeueu,
anu only the piesent packet is known. The uisauvantage with these uevices is that many
attacks aie peiloimeu with well-gioomeu packets that can pass any attiiLute test Le-
cause they aie legal packets; they aie simply out ol seguence oi aie causing state tian-
sitions that aie not goou. Foi example, a uevice senuing thousanus ol SYN messages
without acknowleuging them coulu give the ieceiving seivei heaitLuin. Each SYN
message is line, Lut when tens oi hunuieus ol thousanus ol these aie ieceiveu at the
Enterprise Network Roles | 55
same time, theie is a pioLlem, anu stateless uevices uo not liltei against this type ol
attack.
A communications session is uelineu Ly the souice anu uestination IP
auuiesses anu the souice anu uestination UDP oi TCP poit numLeis.
This guau ol auuiesses associates a single computei to a single seivei
application.
Statelul secuiity gateways look at each packet anu compaie it to the othei packets
ieceiveu in that session. Il messages aie out ol seguence (ieceipt ol a FIN ACK piioi to
a FIN, oi multiple SYNs without ACKs), the statelul uevice will Llock these packets,
even il eveiything is line with the attiiLutes ol the packet. The auvantages ol statelul
secuiity gateways aie that they can iecognize a gieatei vaiiety ol attacks anu can pioviue
a highei thioughput than stateless gateways. The inciease in thioughput is uue to the
ieuuceu piocessing peiloimeu on a pei-packet Lasis. In a statelul scenaiio, the oiigi-
nating packet ol the session is suLjecteu to the lull-lookup piocesses ol the gateway.
Once the packet passes policies anu iouting, it is enteieu into a session taLle. All suL-
seguent packets aie liist compaieu to the session taLle. Il a match is lounu, the same
tieatment as the list packet can Le applieu to these latei packets, ieuucing the oveiall
piocessoi loau loi the gateway.
As noteu, the piimaiy lunction ol the secuiity gateway is to pioviue piotection to the
enteipiise netwoik. This piotection is olleieu in many loims, all ol which oveilap in
lunctionality, incieasing the chances ol catching attacks piioi to them causing haim:
Netwoik auuiess tianslation masks the inteinal netwoik stiuctuie.
Stateless lilteis Llock oLvious attacks.
Iigurc 3-2. TCP scssion statcs
56 | Chapter 3:Juniper Switching and Routing Platforms
Scieen lunctions Llock uenial-ol-seivice (DOS) attacks.
Statelul lilteis Llock attacks that aie uesigneu to uisiupt uevices.
Intiusion uetection anu piotection policies ioot out anu stop known thieats.
Unilieu thieat management soltwaie looks at the content ol the alloweu tiallic anu
seaiches loi malicious content.
Management uevices monitoi the netwoik as a whole, looking loi tienus anu
aLnoimalities.
The uevice choices loi secuiity gateways aie the SRX Seivices Gateway piouuct lines
(the ]-seiies iouteis might Le consiueieu as an option, Lut they aie a stietch). The SRX
line ol secuiity gateways is typically uiviueu Letween the Bianch Ollice SRXs anu the
Data Centei SRXs, the uistinctions Leing leatuies anu thioughput.
The high-enu Data Centei SRXs suppoit thioughput iates that woulu satisly the laigest
enteipiise Inteinet appetite. Theii leatuie list incluues the lull suite ol seivices, except
the UTM capaLilities (anti-spam, anti-viius, content lilteiing, anu URL lilteiing). The
high-enu SRXs suppoit only Etheinet inteilaces, limiting the positioning ol these ue-
vices in the netwoik (they cannot uiiectly connect to a VAN ciicuit).
The Bianch Ollice SRXs have the same leatuie set as the Data Centei SRXs Lut with
the auueu capaLilities ol UTM. The Bianch Ollice SRXs also can incoipoiate VAN
inteilaces uiiectly into the uevice. Anothei aiea ol llexiLility is theii suppoit loi othei
technologies. The uevices incluue powei ovei Etheinet (POE) anu voice ovei IP (VoIP)
piotocol suppoit (the SRX can act as a VoIP switch in an emeigency). The Bianch Ollice
SRXs can also contiol a ViFi access point.
The choice Letween these two uevice lamilies in youi netwoik Loils uown to the leatuies
anu thioughput you neeu. Foi enteipiises that neeu massive thioughput, the Data
Centei SRXs aie the Lettei choice, anu any omitteu leatuies neeueu can Le pioviueu
Ly othei uevices in the enteipiise. These uevices accept a lull BGP ioute taLle anu
pioviue a 10-gigaLit inteilace to the Inteinet.
Foi those enteipiises that uo not have massive Inteinet ieguiiements Lut woulu like to
have a single point loi all secuiity conceins, the Bianch Ollice SRX is a logical choice.
These uevices can Le the netwoik`s local point loi secuiity in the enteipiise. Auuition-
ally, they can Le the contiolleis loi voice, ViFi, anu wiieu tiallic in the enteipiise.
Although not consiueieu heie, the ]-seiies iouteis ollei a lull set ol se-
cuiity leatuies, as uo the legacy Netscieen liiewalls. These piouucts aie
still availaLle liom ]unipei anu will lill the ioles uesciiLeu pieviously.
Foi lull uetails on the capaLilities ol these piouucts, check out the Piou-
ucts anu Seivices taLs at http://www.junipcr.nct.
Enterprise Network Roles | 57
Once the leatuie veisus thioughput Lattle is ueciueu, the mouel within the lamily has
to Le chosen. This uecision is Laseu on thiee lactois: the numLei ol inteilaces, the type
ol inteilaces, anu the expecteu thioughput loi the secuiity gateway. TaLle 3-1 pioviues
a look at the SRX Bianch Ollice choices. The thioughput numLeis aie given in Lits pei
seconu anu connections pei seconu, anu the poit options show the numLei ol onLoaiu
lixeu Etheinet poits anu the numLei ol optional caiu slots that can Le useu. The I/O
caius loi the Bianch Ollice SRXs suppoit one VAN inteilace pei mini-PIM, except loi
the slots in the SRX650, which can accommouate Etheinet caius (up to 2+ poits pei
caiu) oi a VAN caiu.
Tab|c 3-1. Branch Ojjicc SRX options
SRX100 SX210 SRX220 SRX240 SRX650
Firewall performance (max) 650 Mbps 750 Mbps 95 Mbps 1.5 Gbps 7 Gbps
Connections per second 2,000 2,000 2,500 9,000 30,000
Fixed Ethernet ports 8 8 8 16 4
WAN/LAN I/O slots N/A 1 2 4 8
POE ports N/A 4 8 16 48
The Data Centei SRXs lack the VAN inteilaces anu the POE suppoit Lut spoit highei
peiloimance numLeis anu can hanule laige numLeis ol connections pei seconu.
TaLle 3-2 lists the specilications loi the Data Centei SRXs.
Tab|c 3-2. Data Ccntcr SRX options
SRX1400 SRX3400 SRX3600 SRX5600 SRX5800
Firewall performance (max) 10 Gbps 10Gbps 20Gbps 30Gbps 60Gbps
Connections per second 45,000 175,000 175,000 350,000 350,000
LAN I/O slots 1
a
4
a
6
a
5
b
11
b
Fixed Ethernet ports 12 12 12 N/A N/A
a
Up to 16 port Ethernet IOCs
b
Up to 40 port Ethernet IOCs
The choice Letween these uevices is maue Laseu on the expecteu loau to anu liom the
Inteinet. Theie aie no iecognizeu guiuelines loi the numLei ol connections pei seconu
pei usei, anu expeiience uictates that when a Lettei Inteinet connection is installeu,
moie useis will take auvantage ol it (which makes histoiical uata almost useless). Best
piactice guiuelines aie typically to size the gateway loi the enteipiise neeus anu then
iestiict iecieational use to an acceptaLle limit.
58 | Chapter 3:Juniper Switching and Routing Platforms
Internet Border Router
Like the secuiity gateway, the Inteinet Loiuei ioutei is an integial pait ol any enteipiise
netwoik Lecause the Inteinet is a iouteu netwoik that ieguiies a iouteu inteilace. The
ISP must have a iouteu next hop to ieach the enteipiise, anu the enteipiise must have
a uelault gateway to ieach the Inteinet. The Inteinet Loiuei ioutei olleis this lunction.
It is the exteinal/inteinal uemaication loi iouting piotocols anu possiLly the puLlic/
piivate uemaication loi IP auuiessing (il the enteipiise is using RFC-191S auuiessing
loi inteinal auuiesses).
Piivate IP auuiessing, also ieleiieu to as RFC-191S auuiessing, uses the
auuiesses in the iange ol 10.0.0.0/S, 172.16.0.0/12, oi 192.16S.0.0/16.
These auuiesses aie not assigneu in the Inteinet. As such, they can Le
useu in an enteipiise as neeueu. Vhen tiallic leaves the enteipiise, the
RFC-191S auuiesses aie tianslateu to a puLlic auuiess at the Inteinet
euge. Typically the secuiity gateway uevice peiloims the tianslation, Lut
it can Le peiloimeu in the Inteinet Loiuei ioutei.
The piincipal lunctions ol the Inteinet Loiuei ioutei ueal with iouting tiallic liom the
Inteinet to the enteipiise, anu vice veisa. This lunction can vaiy wiluly in complexity,
as illustiateu in the vaiious scenaiios uiscusseu heie, Lut auuitional lunctions ol the
Inteinet Loiuei ioutei ueal with access secuiity, which incluues Loth inloimation se-
cuiity anu suivivaLility.
The inloimation secuiity lunctions ol the Inteinet Loiuei ioutei locus on limiting the
exposuie ol the enteipiise netwoik to pioLes anu scans geneiateu on the Inteinet. The
Inteinet Loiuei ioutei shoulu:
Not iesponu to ieguests liom ICMP, HTTP, Telnet, oi SSH
Have authentication loi all iouting piotocols, to limit the exposuie to spooling
attacks
Employ ieveise-path lookup loi all ieceiveu tiallic
Have an up-to-uate maitian/Logon auuiess list anu Llock all tiallic liom oi to these
auuiesses
Employ piuuent ioute policies that stiictly ueline the acceptaLle ioutes to Le ie-
ceiveu oi auveitiseu
Enterprise Network Roles | 59
The suivivaLility lunctions ol the Inteinet Loiuei ioutei shoulu piotect against single
points ol lailuie Letween the ISP anu the enteipiise. The moie suivivaLle the Inteinet
access, the moie complex the iouting Lecomes. Figuie 3-3 pioviues a guick look at loui
options. The simplest option (shown on the lai lelt) pioviues no suivivaLility, wheieas
the most complex option (lai iight) can suivive the loss ol any Inteinet access
component.
Iigurc 3-3. |ntcrnct bordcr routcr survivabi|ity options
The iouting lunctions ol an Inteinet Loiuei ioutei uepenu on the iouting mechanisms
in use loi the Inteinet connection anu the suivivaLility.
The conliguiation examples loi the iouting anu suivivaLility aie lounu
in Chaptei 6.
60 | Chapter 3:Juniper Switching and Routing Platforms
Single link
Il a single ISP link anu static iouting aie employeu (the liist example in Figuie 3-3), the
iouting opeiation is oLviously stiaightloiwaiu. All inteinal uevices use a uelault ioute
to the Inteinet, anu the ISP auveitises the enteipiise`s auuiess Llocks to the Inteinet.
The Inteinet Loiuei ioutei uses a static uelault ioute loi all tiallic anu ieauveitises that
uelault ioute to the inteinal iouteis. In the event ol an Inteinet link oi Inteinet ioutei
lailuie, the static ioute woulu Le withuiawn, anu the tiallic uestineu loi the Inteinet
woulu Le uiscaiueu at the oiiginating ioutei.
Il a single ISP link anu the BGP piotocol aie employeu, the conliguiation is a little moie
complex, with the enteipiise anu the Inteinet Loiuei ioutei auveitising the enteipiise
auuiess Llocks to the ISP (note that the suivivaLility is the same as with static iouting).
Dual links, single router
Vhen multiple links to the Inteinet aie useu, the suivivaLility options anu the iouting
complexity inciease. On the suivivaLility liont, a lailuie ol an inteilace oi a link will
not cause a loss ol Inteinet access. On the iouting liont, the use ol static ioutes oi the
BGP piotocol can Le implementeu to pioviue a piimaiy/seconuaiy ielationship Le-
tween the ISP links. Although loau shaiing Letween the ISP links is possiLle, it piesents
a numLei ol issues that have to Le iesolveu, the most complicateu ol which is the
iesolution ol asymmetiical iouting (tiallic leaving on one Inteinet link anu ietuining
on the othei). Typically asymmetiical iouteu tiallic is Llockeu il statelul secuiity uevices
aie useu.
Vhen multiple links aie employeu in a piimaiy/seconuaiy ielationship, a single uelault
ioute is auveitiseu to the inteinal iouteis. Il one ol the Inteinet links Lecomes unavail-
aLle, the othei woulu Le useu in its place anu the inteinal iouting woulu not Le alteieu.
Dual links, dual routers
This option olleis the Lest piotection liom lailuies anu involves the most complex
iouting conliguiations. The possiLle scenaiios loi multiple links aie the same as those
in the uual links, single ioutei option, Lut in this case multiple uelault ioutes aie pio-
viueu to the Inteinet. Each ioutei auveitises its own ioute to the Inteinet to the inteinal
iouteis, anu when one link lails, that ioute is withuiawn anu the seconuaiy ioute
is useu.
Vhen multiple ISPs aie useu, the use ol BGP is ieguiieu. That`s Lecause the enteipiise
auveitises its Llock ol auuiesses to one ISP as the piimaiy ioute liom the Inteinet to
the enteipiise, anu the auveitisement to the seconuaiy ISP contains attiiLutes that spoil
those piimaiy ioutes. All tiallic to the Inteinet is hanuleu as with uual links, single
ioutei: all tiallic liom the Inteinet lollows the path to the piimaiy ISP, anu in the event
ol a lailuie ol the piimaiy ISP, Inteinet tiallic lollows the path thiough the seconuaiy
ISP.
Enterprise Network Roles | 61
Internet border router device options
Choosing an Inteinet Loiuei ioutei uevice is Lest ueteimineu Ly consiueiing the lol-
lowing lactois:
Bandwidth oj thc |ntcrnct |in|
The amount ol Lanuwiuth ieguiieu Ly the enteipiise is an economic uecision.
Enteipiises will use all the availaLle Lanuwiuth to the Inteinet, iegaiuless ol the
speeu ol the inteilace. The ioutei must Le aLle the hanule the peak loaus ol the
Inteinet link.
BGP routcs
Il the enteipiise ieceives the lull iouting taLle liom the Inteinet, the ioutei must
Le poweilul enough to guickly stoie anu hanule the moie than 330,000 pielixes
that aie Leing passeu touay in the Inteinet.
Sccurity junctions
Sometimes the Inteinet Loiuei ioutei anu the Inteinet secuiity gateway aie the
same uevice. In this case, the ioutei neeus to Le aLle to hanule secuiity ioles as well
as the ioutei ioles.
|ntcrjacc options
The ioutei will olten neeu to inteilace to the Inteinet ovei a wiue aiea link, which
ieguiies the use ol VAN inteilaces anu piotocols.
Given all the possiLle choices ol ]unipei uevices that can Le useu as an Inteinet Loiuei
ioutei, a lew stanuouts appeai, as you can see in TaLle 3-3.
Foi enteipiises with Inteinet leeus less than 1 GLps that want a consoliuateu uevice to
peiloim Loth Inteinet ioutei anu secuiity lunctions, the SRX650 is the pieleiieu uevice.
Il secuiity lunctions aie not ieguiieu (i.e., an Inteinet secuiity gateway is Leing ue-
ployeu), the Lest selection is the M7i.
Foi enteipiises with Inteinet leeus gieatei than 1 GLps that aie consoliuating iouting
anu secuiity, the high-enu Data Centei SRXs aie the iight choice. Il secuiity lunctions
aie not ieguiieu at this junctuie, the M10i is the choice. Il the Inteinet Loiuei ioutei
anu the coie ioutei aie going to Le collapseu into a single uevice, the Lest selection is
an MX mouel.
62 | Chapter 3:Juniper Switching and Routing Platforms
T
a
b
|
c

3
-
3
.

|
n
t
c
r
n
c
t

b
o
r
d
c
r

r
o
u
t
c
r

c
h
o
i
c
c
s

S
R
X
2
4
0
S
R
X
6
5
0
S
R
X

(
d
c
)
J
2
3
2
0
J
2
3
5
0
J
4
3
5
0
J
6
3
5
0
M
7
i
M
1
0
i
M
X
I
n
t
e
r
n
e
t

l
i
n
k










1
0

M
b
p
s
X
X
X
X
X
X
X
X
X
X
1
0
0

M
b
p
s
X
X
X

X
X
X
X
X
X
5
0
0

M
b
p
s

X
X




X
X
X
1

G
b
p
s

X
X




X
X
X
O
v
e
r

1

G
b
p
s


X






X
S
e
c
u
r
i
t
y










S
t
a
t
e
l
e
s
s
X
X
X
X
X
X
X
X
X
X
S
t
a
t
e
f
u
l
X
X
X
X
X
X
X



N
A
T
X
X
X
X
X
X
X



R
o
u
t
i
n
g










E
B
G
P

(
f
u
l
l

f
e
e
d
)

X
X


X
X
X
X
X
I
B
G
P
X
X
X
X
X
X
X
X
X
X
P
o
l
i
c
i
e
s
X
X
X
X
X
X
X
X
X
X
O
S
P
F
X
X
X
X
X
X
X
X
X
X
I
n
t
e
r
f
a
c
e
s










W
A
N

s
u
p
p
o
r
t
X
X

X
X
X
X
X
X
X
E
t
h
e
r
n
e
t

1

G
b
p
s
X
X
X
X
X
X
X
X
X
X
E
t
h
e
r
n
e
t

1
0

G
b
p
s


X






X
Enterprise Network Roles | 63
Core Routers
The coie iouteis ol an enteipiise netwoik aie the piincipal uevices that pioviue con-
nectivity (some aichitects consiuei them the only iouteis) anu holu the centei ol the
netwoik togethei. They aie iesponsiLle loi the speeu anu ieach ol the enteipiise
netwoik anu aie the piincipal locus ol the high-speeu ]unipei piouuct line. As the
numLei ol layeis in the enteipiise netwoik is compiesseu, the coie layei iemains anu
aLsoiLs the iesponsiLilities ol the othei layeis.
Those iesponsiLilities incluue:
|BGP
Foi enteipiise netwoiks that have multiple Inteinet points ol piesence, oi loi veiy
laige enteipiises, BGP is useu to hanule pielixes.
|GP
OSPF (oi possiLly ISIS) is the piincipal stanuaius-Laseu inteiioi gateway piotocol
(IGP) useu Ly enteipiises. The coie iouteis neeu to Le aLle to suppoit all aspects
ol these piotocols anu the suppoiting lunctions (lilteis, policies, etc.) that allow
them to pioviue contiolleu connectivity.
CoS
The Lanuwiuth ol the enteipiise is unuei attack liom applications anu seivices that
simply weien`t aiounu just a lew yeais ago. Instant messaging suppoits viueo,
music uownloaus aie 30ML pei song, anu YouTuLe viueos aie useu loi political
campaigns. Any ol these can usuip the Lanuwiuth ol the coie. CoS assuies that
enteipiise-ciitical tiallic is not Llockeu.
WAN
The coie ol the enteipiise connects all othei netwoik components, incluuing the
wiue aiea netwoik. The coie ioutei must Le aLle to inteilace to legacy VAN pio-
tocols (ATM, liame ielay, PPP) as well as the newei VPN piotocols (L3VPN, VPLS,
L2VPNs).
Survivabi|ity
Because ol the coie`s ciitical iole in an enteipiise, it must suppoit leatuies that
ensuie the suivivaLility ol the netwoik. Haiuwaie anu soltwaie ieuunuancy, link
aggiegation, anu shoit conveigence aie all leatuies that will piotect the netwoik.
Core router device options
Similai to the othei uevices in oui ieleience netwoik, the selection ol a coie ioutei
uepenus on a numLei ol lactois, although they can Le ieuuceu to just a lew key tiaits:
loiwaiuing technology, total thioughput, anu inteilace types.
Depenuing on the oveiall aichitectuie ol the enteipiise netwoik, the coie uevices aie
iouteis oi switches. Il the enteipiise netwoik lollows the legacy uesign philosophies,
the coie will consist ol Etheinet switches. In this case, the choice ol uevices is Letween
the EXS000s anu the MXs, Loth ol which ollei switching capaLilities that can hanule
64 | Chapter 3:Juniper Switching and Routing Platforms
the uemanus ol the coie. Il the enteipiise implements a moie collapseu uesign, such as
one ol the examples in the pievious chaptei, the coie uevice woulu Le a ioutei, in which
case the selection woulu Le Laseu on the thioughput anu inteilace olleiings shown in
TaLle 3-+.
Because ol the collapseu natuie ol the enteipiise netwoik anu its lunuamental neeu loi
suivivaLility, all coie iouteis shoulu Le aLle to hanule the lull loau ol the enteipiise.
Vith touay`s applications, that thioughput ieguiiement coulu easily ieach 10 GLps,
so touay`s selection ol a coie ioutei shoulu Le maue with that liguie in minu.
The M7i anu the M10i aie lully capaLle ol hanuling any ieguiiements ol the coie ioutei
loi total thioughputs less than 10 GLps, Lut they guickly iun out ol hoisepowei loi
thioughputs appioaching that numLei. The miu-iange MXs aie a new option that can
ieplace the M7i anu the M10i. The thioughput loi these new uevices Legins at 20 GLps,
allowing them to hanule even gieatei amounts ol tiallic than the enteipiise M-seiies
iouteis.
The MX seiies anu the EX S000s aie Luilt to suppoit thioughputs aLove 10 GLps, as
shown in TaLle 3-+.
Tab|c 3-1. 10 Gbps corc routcr options
MX240 MX480 MX960 EX8000
Backplane 480 Gbps 1.4 Tbps 2.6 Tbps 6.2 Tbps
Throughput 440 Mpps 1.3 Bpps 2.4 Bpps 1.92 Bpps
WAN interfaces? Yes Yes Yes No
The specilications in TaLle 3-+ neeu luithei explanation. The Lackplane liguies aie the
system capacities ol the vaiious uevices anu iepiesent the total thioughput that the
uevice can hanule lully loaueu, with caius. Howevei, this numLei typically uouLle-
counts the tiallic (so that a 100 MLps inteilace can hanule 200 MLps ol tiallic). The
actual system thioughputs ol these uevices aie consiueiaLly lowei than these numLeis
Lecause ol the constiaints ol the piotocols anu the tiallic patteins seen in a netwoik,
Lut all ol these uevices will hanule tiallic loau well aLove 10 GLps. The thioughputs
aie calculateu with a lixeu liame size anu iepiesent, again, a peilect enviionment. Foi
the MX uevices, the liame size calculates out to 136 octets pei liame; loi the EXS000,
that numLei is +00 octets pei liame.
The inteilace type suppoiteu Ly the uevice is the othei lactoi when choosing a coie
ioutei. Il the coie is totally Etheinet, which is a laii assumption loi many enteipiises,
any ol the uevices shown in TaLle 3-+ will lill the iole. Il legacy VAN suppoit is ieguiieu
loi the coie uevice, the MX platloims aie the Lettei choice.
Out ol all the coie ioutei oi switch choices, the EXS200 suppoits the gieatest thiough-
put pei uollai spent.
Enterprise Network Roles | 65
Access Router
As uesciiLeu loi othei uevices in oui ieleience uiagiam, the exact ieguiiement loi a
uistinct access layei in the aichitectuie is ueLataLle. Regaiuless ol whethei the layei is
implementeu in sepaiate uevices, the lunctions associateu with the layei must Le pio-
viueu in the enteipiise netwoik. Assuming that an access layei ioutei is pait ol the
uesign, its lunctions incluue class ol seivice (CoS) uelinitions, seivei anu client uevice
hanuling, secuiity, anu iouting lunctions.
Class ol seivice lunctions ueal with the classilication, maiking, anu gueuing ol tiallic
to anu liom the enu uevices. Il piopei class ol seivice maiking is peiloimeu at this point
in the enteipiise, all othei uevices can pioviue a consistent guality ol seivice to uesig-
nateu tiallic. The classilication anu gueuing aspect ol CoS is neeueu only loi teimi-
nating tiallic to seiveis attacheu to the access layei. The piimaiy puipose ol the access
ioutei is to connect usei computeis anu teiminals to the iesouices ol the netwoik anu
to connect the netwoik to the seiveis ol the enteipiise. To lullill this puipose, the ioutei
has to have a mechanism to:
Pioviue suivivaLle access loi all useis (client oi seivei). This is accomplisheu Ly
means ol a viitual ioutei ieuunuancy piotocol (VRRP). This allows multiple ue-
vices to pioviue gateway seivices to access uevices with lailovei capaLility.
Pioviue an automateu management lunction that piovisions IP auuiesses, uelault
gateways, DNS anu NTP seiveis, etc., on the enu uevices. This lunction is accom-
plisheu Ly use ol a uynamic host conliguiation piotocol (DHCP).
Pioviue a means to ensuie that tiallic liom one inloimation silo cannot gain access
to the inloimation in anothei silo. Viitual LANs is a means loi segmenting tiallic.
Pioviue a piimaiy anu alteinate path liom the access uevices to the enteipiise`s
iesouices. This is accomplisheu Ly the use ol uynamic iouting piotocols anu link
aggiegation.
A seconuaiy lunction ol the access ioutei is to pioviue a connection Letween the stoiage
systems ol the uata centei anu the iesouices ol the enteipiise netwoik. Stoiage aiea
netwoiks anu netwoik attacheu stoiage systems have theii own uistinct piotocols (i.e.,
liLei channel anu SCSI) that neeu to Le incoipoiateu into the enteipiise netwoik. The
lull tieatment ol these impoitant piotocols is Leyonu the scope ol this Look, Lut a goou
ieleience is Data Ccntcr Nctwor| Conncctivity with |BM Scrvcrs, which is lieely avail-
aLle at http://www.junipcr.nct/boo|s.
The uilleience Letween the legacy uesign appioach (Figuie 3-+) anu those auvocateu
Ly ]unipei Netwoiks is the consoliuation ol the enteipiise uesign`s access anu uistii-
Lution layeis.
66 | Chapter 3:Juniper Switching and Routing Platforms
Iigurc 3-1. Lcgacy acccss/distribution dcsign
In the legacy uesign, the access layei is an Etheinet-switcheu layei pioviuing last access
to uistiiLution iouteis. Vhen these layeis aie consoliuateu, as shown in Figuie 3-5, the
lunctions ol the uistiiLution layei (loi example, VRRP, DHCP, OSPF) aie also con-
soliuateu into the comLineu uevices.
Iigurc 3-5. Conso|idatcd acccss |aycr
Enterprise Network Roles | 67
The natuie ol the access layei is to allow laige numLeis ol useis to ieach the seivices
ol the enteipiise netwoik. This ieguiies eithei a laige single uevice accompanieu Ly a
massive wiiing plan oi a gioup ol uevices. The uevices olleieu Ly ]unipei netwoiks will
satisly Loth ol these implementation scenaiios. The use ol viitual chassis technology
allows these access uevices to pioviue:
Reuunuancy loi the iouting engine wheie each memLei ol the viitual chassis has
a iouting engine, Lut only one is active anu one is in stanuLy moue. In the event
ol a lailuie ol the active RE, the stanuLy can take ovei contiol ol the viitual chassis.
SuivivaLle aggiegate Etheinet links aie teiminateu on uilleient switches ol the vii-
tual chassis. This olleis gieatei Lanuwiuth than ieuunuant links with the same
ieliaLility.
A single uelault gateway loi the usei uevices is piovisioneu liom the viitual chassis.
All switches look like a single ioutei to the usei (seivei oi client) uevices.
Options loi the uplinks to the netwoik coie incluue ieuunuant Etheinet links,
egual cost iouteu links, piimaiy/seconuaiy iouteu links, anu simple switcheu links.
These options allow the viitual chassis access uevices to opeiate in any scenaiio.
Access router options
The ]unipei Netwoiks options loi the access ioutei lie Letween its EX platloim anu its
MX platloim. Both uevice platloims aie eguippeu with the ieguiieu lunctions anu have
mouels that will lit the Lanuwiuth ieguiiements ol small to laige enteipiises:
EX1200 virtua| chassis
Best choice loi a top-ol-iack installation, as up to ten +S-poit EX+200s can Le
inteiconnecteu loi a single access uevice. The EX+200 can Le conliguieu with
switching anu iouting lunctions. The thioughput limit on the EX+200 viitual
chassis is testeu at 12S GLps, which shoulu allow it to hanule most enteipiise
applications. Auuitionally, the EX+500 can Le auueu to the EX+200s viitual chas-
sis, auuing high-uensity 10 GLps connectivity.
EX8200 (EX8208 and EX821)
Best choice loi a collapseu access scenaiio, Lecause the EXS216 can hanule a max-
imum ol 76S 1 GLps inteilaces oi 12S 10 GLps inteilaces. The 16 slots can Le
piovisioneu with a comLination ol 10/100/1000 MLps caius oi 10 GLps caius. The
EXS200 seiies has lull ieuunuancy ol ciitical mouules Lut can Le placeu into a two-
unit viitual chassis to luithei expanu the poit count anu ieliaLility capaLilities.
MX90
Best choice loi a lully integiateu uevice, as the MX960 suppoits up to +S0 1 GLps
Etheinet poits anu a total Lackplane thioughput ol 2.6 TLps. All ciitical mouules
aie ieuunuant, anu like the EXS200s, two MX960s can Le inteiconnecteu in a
viitual chassis.
68 | Chapter 3:Juniper Switching and Routing Platforms
The uilleience Letween the EXS200s anu the MX960 coulu Le uesciiLeu as lollows:
the EX is a massive switch with a iouting letish, wheieas the MX is a massive ioutei
with a switching letish. Although they Loth opeiate the ]unos opeiating system anu
Loth platloims have a similai switching anu iouting conliguiation, the uevices
uiscusseu aie eithei scalaLle to the maximum (EX+200) oi have smallei uevices (miu-
iange MX, MX2+0, anu MX+S0) that can Le ueployeu.
Multiservices Gateway
As moie anu moie applications aie mappeu to the IP inliastiuctuie ol the enteipiise
netwoiksuch as voice, multimeuia conleiencing, suiveillance, viueo Lioaucasts, anu
moieoui netwoik uevices have to suppoit these seivices as well. The multiseivice
gateway is a new class ol uevice uesigneu to opeiate in this multiseivice netwoik, anu
a piime example ol this tienu is the ]unipei Netwoiks SRX2+0 Seivices Gateway. This
mouulai uevice pioviues iouting, switching, liiewall lunctions, UTM, VoIP, ViFi con-
tiol, anu CoS. It coulu lunction as the only netwoiking uevice loi a iemote ollice oi
can seive as any one ol these lunctions loi a laigei uepaitment.
As the integiation ol seivices matuies in the enteipiise in the veiy neai lutuie, net-
woiking uevices must Le aLle to suppoit the lollowing lunctions:
Multicast suppoit loi viueo anu multimeuia stieams
Class ol seivice gueuing, tiallic shaping, anu maiking
VoIP suivivaLility suppoit
Device Limitations
Any uevice analysis locuses on the auvantages anu Lenelits ol the uevices iathei than
the limitations ol the uevices, Lut Lest piactice neeus to consiuei the limitations, il only
to ensuie suivivaLility, not to mention unueistanuing how to uesign loi netwoik scal-
aLility. In the lollowing sections, we auuiess the notaLle limitations loi each ]unipei
Netwoiks seiies ol uevices.
M-series
The M-seiies enteipiise iouteis aie Laseu on the aichitectuie ol the seivice pioviuei
platloims. Although this aichitectuie olleis signilicant auvantages loi iouting packets,
it cieates limitations loi suppoiting auuitional seivices anu loi tiouLleshooting.
One auvantage anu limitation ol the M-seiies is the numLei ol physical inteilace caiu
(PIC) choices loi the platloim. The uatasheets list the options loi each mouel, Lut not
the seivices that aie suppoiteu on each mouule. Theie aie seivices PICs, IQ PICs, IQE
PICs loi ATM, Etheinet, anu seiial piotocols. The auvantage is the llexiLility inheient
in the platloim, anu the limitation is having the iight PIC loi the implementeu seivice.
Enterprise Network Roles | 69
One example is the note loi the conliguiation ol a VPLS inteilace: On
M Seiies iouteis (except the M320 ioutei), the +-poit Fast Etheinet TX
PIC anu the 1-poit, 2-poit, anu +-poit, +-slot GigaLit Etheinet PICs can
use the Etheinet VPLS encapsulation type. The othei Etheinet PICs
will not (oi might not) suppoit the ieguiieu etheinet-vpls, extenueu-
vlan-vpls, oi the vlan-vpls encapsulation types. So loi each auvanceu
leatuie, the coiiect PICs must Le in place loi theii piopei opeiation.
Anothei limitation ol the M-seiies (anu othei uistiiLuteu-aichitectuie ]unipei uevices)
is the lack ol visiLility at the poit level loi tiallic tiouLleshooting. Theie aie lew mech-
anisms loi actually seeing what tiallic is tiansiting the M-seiies inteilaces. This limi-
tation causes auministiatois to install exteinal test anu monitoiing eguipment loi
tiouLleshooting puiposes. An alteinative to exteinal test eguipment is installing a pas-
sive monitoi PIC. Il you have passive monitoiing PICs anu SONET/SDH PICs installeu
in an M160 oi M+0e ioutei, you can monitoi IPv+ tiallic liom anothei ioutei.
J-series
The most signilicant limitation ol the ]-seiies is its age in the ]unipei Netwoiks piouuct
line. Vhen the SRX was intiouuceu anu its secuiity leatuies integiateu into ]unos, the
]-seiies took a Lack seat in the enteipiise. Touay an SRX iunning in packet moue is
lastei anu olten cheapei than ]-seiies iouteis ol eguivalent poit uensities. In auuition,
these secuiity leatuies ieguiie moie opeiating memoiy, thus ieuucing the capaLilities
ol the ]-seiies (loi example, the iouting taLle sizes aie ieuuceu).
MX edge routers
The MX seiies ol euge iouteis have evolveu liom the gigantic MX960 uown to the
alloiuaLle MX5. Initially the I/O caius weie limiteu to eithei Etheinet switching oi IP
iouting, Lut latei caius suppoiteu eithei iouting oi switching. The newest ol the caius,
the Tiio, is capaLle ol multiple lunctions Lut is not compatiLle with oluei caius. Like
the M-seiies, the selection ol MX I/O caius must Le maue with caie. Foi the miu-iange
MXs, the upgiaue paths anu costs shoulu Le stuuieu caielully to make suie that you
aie getting the uevice that lits youi application.
EX switches
The EX switch seiies olleis Etheinet switching capaLilities anu limiteu iouting capa-
Lilities. The limiting lactoi loi iouting anu othei auvanceu leatuies is Laseu on the EX
mouel iathei than the OS. The EX2200 anu EX2500 have veiy limiteu iouting capa-
Lilities, wheieas the EXS000s have lull ioutei capaLilities. An auuitional caution is that
only the EX3200 anu EX+200 seiies suppoit MPLS in ]unos 9.5R1, limiting the use ol
these uevices in L3VPN anu L2VPN implementations.
70 | Chapter 3:Juniper Switching and Routing Platforms
SRX Services Gateway
The SRX is piimaiily a secuiity uevice opeiating as a session-Laseu ioutei. In llow moue,
the Bianch Ollice SRXs cannot opeiate as an MPLS noue. Vhen in packet moue, the
SRX continues to allocate memoiy to the llow-Laseu piocesses.
Anothei limitation is the opeiation ol Etheinet switching in the Bianch Ollice SRX
uevices. Vhen poits aie enaLleu as Etheinet switching poits, they uo not paiticipate
in the session piocessing. Tiallic Letween Etheinet switch poits cannot Le passeu
thiough secuiity policies.
L2 and L3 Deployments
The eaily chapteis ol the seconu euition ol this Look locus on some ol the newei ]unipei
Netwoiks uevice leatuies anu capaLilities lounu in the new enteipiise netwoik that
Llui the uistinction Letween iouting anu switching. Anu this section continues that
locus Ly uelining the leatuies that aie not coveieu in the iemainuei ol this Look, which
concentiates on enteipiise iouting anu the iouting capaLilities you will linu in youi
MX, EX, anu SRX uevices.
Heie, Leloie we launch into an in-uepth look at enteipiise iouting, we take a guick
look at the Lluiieu leatuies. Vheie the lollowing leatuies aie Lettei uelineu in anothei
woik, we ieleience that woik iathei than iepeat the content heie.
Link Aggregation Groups
Link aggiegation gioups (LAGs) aie a means to inciease Lanuwiuth anu ieuunuancy
Letween uevices in the enteipiise. These uevices can Le switches, iouteis, oi seiveis.
The LAG implementation in ]unos lollows the S02.3au stanuaiu anu can suppoit up
to eight inteilaces. Vhen LAGs aie auueu to a viitual chassis opeiation, the links can
Le suppoiteu liom uilleient uevices in the viitual chassis, incieasing ieuunuancy.
Figuie 3-6 uepicts a LAG conliguiation example wheie two inteilaces, ge-0/0/0 anu
ge-0/0/1, aie pait ol a LAG calleu ae0. A LAG ieguiies thiee sepaiate settings: the
chassis has to have the uevice count uelineu, the aggiegate Etheinet (ae) inteilace must
Le uelineu, anu the Etheinet inteilaces must Le associateu with the ae0 inteilace. Il the
link activation contiol piotocol (LACP) weie useu, it woulu Le applieu to the ae0 in-
teilace as an ethei-option.
Iigurc 3-. LAG cxanp|c
L2 and L3 Deployments | 71
To conliguie such a LAG:
[edit]
peter@switch1# show chassis
aggregated-devices {
ethernet {
device-count 1;
}
}
[edit]
peter@switch1# show interface ae0
unit 0
family ethernet-switching {
port-mode trunk;
vlan {
members [all];
}
}
}
[edit]
user@switch1# show interface ge-0/0/0
ge-0/0/0
ether-options {
802.3ad ae0
}
}
[edit]
user@switch1# show interface ge-0/0/1
ether-options {
802.3ad ae0
}
}
Viitual chassis loim a majoi component in the enteipiise netwoik aichitectuie. Chaptei
+ ol junos Entcrprisc Switching, Ly Reynolus anu Maischke (O`Reilly), contains a lull
uesciiption ol this capaLility. Viitual chassis capaLilities have Leen auueu to the
EXS200 anu MX platloims, in auuition to the EX+200 anu EX+500 uevices, as uescii-
Leu in the switching ieleience Look.
VPLS Implementation
Routing instances allow the ]unipei iouting platloims to suppoit multiple iouting anu
loiwaiuing taLles. They aie commonly useu to pioviue sepaiation ol iouting piotocol
instances anu customei instances loi VPN ueployments. In the campus enviionment
anu the uata centei, viitual piivate LAN seivice (VPLS) olleis lull connectivity Letween
the uevices iunning this VPN technology. The implementation ol VPLS olleis a goou
example ol a viitual iouting instance in a uevice.
Although a lull tieatment ol VPLS is Leyonu the scope ol this Look, the Laie essentials
aie pioviueu heie loi one site ol a two-site VPLS implementation, as shown in Fig-
uie 3-7. In this example, RSTP is useu loi signaling (LDP can Le useu as well). The
inteiioi-lacing (VPLS) inteilace is ge-0/0/0, anu the exteiioi-lacing (LAN) inteilace is
72 | Chapter 3:Juniper Switching and Routing Platforms
ge-0/0/1. All tiallic enteiing into the ge-0/0/1 inteilace will Le Liiugeu to the coiie-
sponuing inteilace on the othei uevice (192.16S.1.2).
Iigurc 3-7. \PLS cxanp|c
To conliguie such a VPLS implementation:
[edit]
peter@M7i#show
.
.
.
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.10.10.1/24;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family vpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
}
routing-options {
autonomous-system 65001;
}
protocols {
rsvp {
interface ge-0/0/0.0; {
}
interface ge-0/0/1.0;
}
mpls {
no-cspf;
label-switched-path vpls {
to 192.168.1.2;
}
L2 and L3 Deployments | 73
interface ge-0/0/0.0;
interface ge-0/0/0.0; {
}
}
bgp {
group ibgp {
type internal;
local-address 192.168.1.1;
family inet {
unicast;
}
family l2vpn {
signaling;
}
neighbor 192.168.1.2;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
}
}
}
routing-instances {
vpls {
instance-type vpls;
interface ge-0/0/1.0;
route-distinguisher 192.168.1:1;
vrf-target target:65001:100;
protocols {
vpls {
site-range 8;
site ce1 {
site-identifier 1;
}
}
}
}
}
Miscellaneous Protocols
A lew miscellaneous piotocols aie uiscusseu heie.
Spanning tree protocol
Spanning tiee piotocol anu its vaiiations, iapiu spanning tiee piotocol anu multi-
instance spanning tiee piotocol, aie coveieu in lull uetail in junos Entcrprisc Switching.
74 | Chapter 3:Juniper Switching and Routing Platforms
Fibre channel
FiLie channel is a stoiage aiea netwoik stanuaiu piotocol that can opeiate ovei Etheinet
(FCoE). The EX+500 suppoits FCoE to allow inteiconnection Letween uata centeis
ovei Etheinet while pieseiving the FiLie Channel piotocol anu leatuies.
Bidirectional forwarding detection
Biuiiectional loiwaiuing uetection (BFD) allows a guickei lailovei Letween a piimaiy
anu a seconuaiy iouteu path. The piotocol iuns along with the iouting piotocol anu
tests the opeiational status ol the inteilace multiple times pei seconu. BFD pioviues
loi conliguiation timeis anu thiesholus loi lailuie uetection. Foi example, il the min-
imum inteival is set loi 50 ms anu the thiesholu uses the uelault value ol thiee misseu
messages, a lailuie will Le uetecteu on an inteilace within 200 ms ol the lailuie. This
gieatly ieuuces the times loi OSPF anu BGP lailuie uetection.
BFD is conliguieu on a pei-inteilace Lasis:
[edit]
peter@M7i#show protocol ospf area 0 interface ge-0/0/0.0
bfd-liveness-detection {
minimum-interval 50;
multiplier 3;
}
All-in-One Versus Components
The capaLilities ol the iouteis olleieu Ly ]unipei Netwoiks allow the same uevices to
Le placeu in many positions on the enteipiise ieleience uesign. The MX can opeiate as
an access, coie, IBR, oi scieening ioutei. The SRXs can lill the ioles ol eveiy uevice
Letween the useis anu the Inteinet. Theie is an unueilying guestion as to which lunction
shoulu Le comLineu anu which shoulu Le sepaiateu, as illustiateu in Figuie 3-S.
Fiom a secuiity-in-uepth point ol view, the moie inuiviuual uevices theie aie, the highei
the potential to thwait a hackei. A uesign that oiiginates liom the uesk ol a CISSP will
have multiple layeis ol secuiity, each implementeu in a uilleient uevice, opeiating sys-
tem, iepoiting system, anu contiol means. The CFO, on the othei hanu, woulu pioL-
aLly choose a uesign that pioviues the most leatuies loi the uollais spent.
So lai in this chaptei, the sepaiate-is-Lettei appioach has Leen piesenteu. Each lunction
ol the ieleience uiagiam is allocateu to a unigue uevice, anu the options loi each uevice
have Leen examineu.
But theie is anothei option loi the enteipiise: the Data Centei SRX, which pioviues the
capaLilities anu leatuies to opeiate as an all-in-one uevice loi an enteipiise. The
SRX5S00 suppoits secuiity, iouting, anu switching lunctions in the same chassis. Al-
though it has limiteu suppoit loi MPLS oi non-Etheinet inteilaces, it can inteiopeiate
with the uevices that suppoit these VAN capaLilities. The SRX allows the conliguia-
All-in-One Versus Components | 75
tion ol multiple syslog anu tiallic logs, suppoits viitual systems loi iouting sepaiation,
anu even suppoits IDP policies.
In a clustei, the SRX olleis lailuie iecoveiy without the loss ol tiallic anu pioviues tiue
suivivaLility loi all majoi components. The SRX can Le manageu liom the commanu
line, the ]-weL inteilace, the Netwoik anu Secuiity Managei (NSM), oi ]unipei Space.
Anu Lest ol all, the iouting lunctionality uetaileu in the iest ol this Look is as applicaLle
on the SRX as it is on the MX oi M-seiies iouteis.
The choice Letween all-in-one veisus a component uesign loi youi enteipiise comes
uown to a guestion ol secuiity-in-uepth veisus unilieu lunctionality anu manageaLility.
Foi some secuiity manageis, the SRX has not yet eaineu its place in the netwoik, Le-
cause it is too new anu not yet pioven. Yet loi many iouting auministiatois who have
woikeu with ]unos loi the last uecaue, the SRX is a oppoitunity to ieplace many uevices
liom multiple venuois with a single ]unos-ieauy uevice.
But the ieally goou news is that eveiything in Figuie 3-S can iun on ]unos, a single
netwoik opeiating system that has the secuiity, switching, anu iouting lunctionalities
Luilt in. The choice is youis.
The liist thiee chapteis ol this Look have locuseu on the new enteipiise netwoik anu
the new uevices capaLle ol meeting the challenges ol enteipiise netwoiking in the next
uecaue. Going loiwaiu, this Look locuses on ]unos enteipiise iouting, no mattei which
]unipei uevice oi platloim you have chosen.
Iigurc 3-8. A||-in-onc
76 | Chapter 3:Juniper Switching and Routing Platforms
Chapter Review Questions
1. Vhat is the piopei oiuei loi an Inteinet-lacing enteipiise netwoik?
A. Scieening iouteiliiewallIBR
B. IBRliiewallscieening ioutei
C. Scieening iouteicoie ioutei
D. Fiiewallcoie iouteis
2. Vhat type ol liiewall is moie secuie: stateless oi statelul?
A. Stateless
B. Statelul
C. Neithei; an Inteinet Loiuei ioutei is ieguiieu
D. Neithei; Loth ollei the same secuiity
3. Vhich ]unipei uevices ollei only stateless liiewall suppoit?
A. M-seiies
B. ]-seiies
C. SRX
D. MX
+. Foi the access layei ol a uata centei, the ]unipei appioach incluues:
A. Multilayei switches iunning STP
B. A thiee-tiei appioach using OSFP anu BGP
C. A single-tiei appioach using viitual chassis switching
D. Replacing all iouting with switching anu VPLS
5. A Lenelit ol the all-in-one appioach to Inteinet access is:
A. Secuiity in uepth
B. DistiiLuteu piocessing
C. Management ease
D. All ol the aLove
Chapter Review Answers
1. Answei: A. Although D woulu woik, sepaiating the uevices impioves secuiity.
2. Answei: B. In auuition to tiacking which packets aie alloweu, a statelul liiewall
can also look loi attacks in alloweu packets.
3. Answei: None. Soiiy loi the tiick guestion; all ]unos uevices listeu can ollei Loth
statelul oi stateless seivices.
Chapter Review Answers | 77
+. Answei: C. The use ol viitual chassis connectivity Letween EX switches allows a
scalaLle solution with suivivaLility.
5. Answei: C. The single uevice solution ieuuces the tiaining anu management ie-
guiieu to secuie youi netwoik.
78 | Chapter 3:Juniper Switching and Routing Platforms
CHAPTER 4
Interfaces
This chaptei uesciiLes the inteilace conliguiations loi a ]unipei Netwoiks ioutei. It
staits with a uesciiption ol the types ol inteilaces, the naming conventions, anu the
inteilace piopeities. It then iuentilies how to conliguie a laige vaiiety ol inteilace meuia,
such as T1 inteilaces, Etheinet, anu Seiial inteilaces. Lastly, it examines common in-
teilace pioLlems, concentiating on the tools availaLle to uetect these issues.
Beloie you Legin to uesign a netwoik`s iouting topology, you shoulu ensuie that all the
piopei physical connections aie in place anu aie opeiational. Vith such a laige vaiiance
in inteilace types, this can olten Le a challenging task, so it is impoitant to unueistanu
how an inteilace is oiganizeu within the ]unos netwoik opeiating system.
]unipei Netwoiks iouteis contain two majoi categoiies ol inteilaces: pcrnancnt anu
transicnt. Useis cannot iemove peimanent inteilaces, wheieas they can move, change,
anu iemove tiansient inteilaces. Othei technical uilleiences exist that aie eviuent when
you examine the applications loi each inteilace type.
The inteilace topics coveieu in this chaptei incluue:
Peimanent inteilaces
Tiansient inteilaces
Inteilace piopeities
Inteilace conliguiation examples
Inteilace tiouLleshooting
Permanent Interfaces
A peimanent inteilace is any inteilace that is always piesent on the ioutei (it cannot
Le alteieu). These inteilaces can Le management inteilaces such as Etheinet, soltwaie
pseuuointeilaces such as tunnel inteilaces, oi lixeu-poit LAN/VAN inteilaces.
79
On ]unos iouteis, two management inteilaces exist:
fxp0
This is an Out ol Banu (OOB) management Etheinet inteilace. It is connecteu to
the ioutei`s Routing Engine (RE) anu can Le useu loi Out ol Banu management
access to the ioutei. It can also Le useu to senu management messages such as
syslog oi Simple Netwoik Management Piotocol (SNMP) tiaps. This inteilace is a
nontransit intcrjacc, which means that tiallic cannot entei this inteilace anu exit
via a LAN/VAN inteilace, noi can it entei a LAN/VAN inteilace anu exit thiough
the management inteilace. On EX switches, the management inteilace is calleu the
me0 inteilace; on all othei iouteis, it is the fxp0 inteilace.
Vhen iunning iouting piotocols, Le veiy caielul when using the
fxp0 inteilace. Il you uon`t conliguie the iouting piotocol coiiectly,
you coulu have a ioute in youi ioute taLle that points to the fxp0
inteilace anu Llack hole tiallic, since this is a nontiansit inteilace.
To piotect youisell liom these types ol situations, you shoulu not
iun any iouting piotocols ovei this inteilace.
fxp1
This is an inteinal Fast Etheinet oi GigaLit Etheinet (uepenuing on the mouel ol
ioutei) inteilace Letween the RE anu the Packet Foiwaiuing Engine (PFE). This
inteilace is nevei conliguieu Lut can Le helplul when tiouLleshooting ioutei issues.
It is only in application-specilic integiateu ciicuit (ASIC) platloims (M/T-seiies)
anu not in the viitualizeu PFE ]-seiies platloims. In clusteieu oi viitual chassis
uevices, the lxp1 poit is extenueu Letween uevices on the VC caLles oi the laL links.
Many soltwaie pseuuointeilaces that the ioutei will cieate at staitup also exist. A shoit
list ol these inteilaces is as lollows:
lo0
This is a loopLack inteilace that ties to the ioutei itsell anu not to any one physical
inteilace. This is olten assigneu an auuiess to pioviue a staLle auuiess loi man-
agement tiallic anu iouting piotocols, which allows youi ioutei to auapt to net-
woik anu physical inteilace lailuies. Also, when conliguieu with liiewall lilteis,
this inteilace seives to piotect the RE liom attacks uestineu to the ioutei.
pd
This Physical Inteilace Mouule (PIM) ue-encapsulation inteilace allows a multicast
ienuezvous point (RP) to piocess PIM iegistei messages.
pe
This PIM encapsulation inteilace is useu in multicast to cieate a unicast PIM ieg-
istei message to senu to the RP.
ip
This is an IP-ovei-IP encapsulation inteilace to cieate IP-in-IP tunnels.
80 | Chapter 4:Interfaces
dsc
This is a uiscaiu inteilace, which can Le useu to silently uiscaiu packets. This is
olten useu to cieate a choke point loi uenial ol seivice (DoS) attacks.
tap
This is a viitual Etheinet inteilace histoiically useu loi monitoiing on FieeBSD
systems. This inteilace coulu Le useu to monitoi uiscaiueu packets on a ioutei Lut
is no longei ollicially suppoiteu.
The last type ol peimanent inteilace is the lixeu LAN/VAN poits lounu on ]unipei
iouteis. Ve will examine these in uepth in the next section.
Transient Interfaces
Tiansient inteilaces aie any inteilaces that the usei can iemove, move, oi ieplace. These
incluue poits on the iemovaLle caius (PICs, PIMs, IOCs, etc.). Examples ol tiansient
inteilaces aie Fast Etheinet, gigaLit Etheinet, Asynchionous Tianslei Moue (ATM),
SONET, anu T1/E1, as well as seivice PICs such as tunnels, multilinks, link seivices,
Auaptive Seivices PICs (ASPs), anu passive monitoiing.
Interface Naming
All ]unos inteilaces lollow the same naming conventionthe inteilace name lolloweu
Ly thiee numLeis that inuicate the location ol the actual inteilace. The geneial con-
vention is illustiateu Ly the inteilace seguence MM-F/P/T, wheie:
MM
Meuia type
I
Chassis slot numLei
P
PIC slot numLei
T
Poit numLei
Media type
The liist pait ol the inteilace name is the inteilace meuia name (MM), inuicating the
type ol inteilace. Common inteilace meuia names incluue:
ae
Aggiegateu Etheinet, a logical linkage ol multiple Etheinet inteilaces uelineu in
the IEEE S02.3au stanuaiu.
Transient Interfaces | 81
at
ATM, which senus lixeu 53-Lyte cells ovei the tianspoit meuia. This inteilace
coulu also Le useu loi ATM ovei uigital suLsciiLei line (DSL) connections.
br
Physical Integiateu Seivices Digital Netwoik (ISDN) inteilace.
e1
Stanuaiu uigital communication stanuaiu ovei coppei at a iate ol 2.0+S MLps,
useu mostly in Euiope.
e3
Stanuaiu uigital communication stanuaiu ovei coppei at a iate ol 3+.36S MLps,
useu mostly in Euiope.
t1
Basic physical layei stanuaiu useu Ly the uigital signal level 1 at a iate ol 1.5++
MLps, useu extensively in Noith Ameiica.
t3
Basic physical layei stanuaiu useu Ly the uigital signal level 3 at a iate ol ++.736
MLps, useu extensively in Noith Ameiica.
fe
100 MLps stanuaiu initially cieateu Ly Xeiox in the 1970s loi connecting multiple
computeis togethei; ieleiieu to as a LAN touay.
ge
Highei-speeu Etheinet stanuaiu at 1 GLps.
xe
Highei-speeu Etheinet stanuaiu at 10 GLps.
se
Inteilace useu loi seiial communications (one Lit at a time). Seiial inteilaces in-
cluue stanuaius such as EIA 530, V.35, anu X.21.
ct1
T1 inteilace that is channelizeu Ly splitting the inteilace into 2+ DSO channels.
Chassis slot number
The next pait ol the inteilace name is F, a chassis slot numLei iepiesenteu Ly a FlexiLle
PIC Concentiatoi (FPC) slot numLei on an M-seiies ioutei, a PIM slot numLei on a
]-seiies ioutei, the IOC slot numLei on an SRX, oi the DPC slot numLei on an MX.
The M-seiies iouteis have two possiLle FPC alignments: hoiizontal slots oi veitical
slots. The laigei M-seiies iouteis (M+0e, M320) have veitically mounteu FPCs with
slot numLeis staiting at slot 0 anu counting liom lelt to iight (see Figuie +-1). The
smallei M-seiies iouteis (M7i, M10i) have hoiizontal slots staiting at slot 0 anu count-
ing liom top to Lottom (see Figuie +-2).
82 | Chapter 4:Interfaces
Iigurc 1-1. \crtica| IPC s|ots (M10c and M320)
Iigurc 1-2. Horizonta| IPC s|ots (M7i and M10i)
The M7i slot 1 is ieseiveu loi the Fixeu Inteilace Caiu slots.
A ]-seiies ioutei uoes not contain any FPCs Lut uoes have PIM slots that aie iepiesenteu
Ly the vaiiaLle F. All lixeu-poit slots aie always assigneu slot 0, anu PIM slots aie
assigneu 16 numLeiing liom top to Lottom anu lelt to iight (see Figuie +-3).
Iigurc 1-3. j350 and j1350 P|M s|ot nunbcrs
Transient Interfaces | 83
D
o
The SRXs suppoit IOCs, not FPCs, anu the slot numLeis aie uepenuent on the mouel
types. Foi the SRX5S00 seiies, the IOCs aie mounteu veitically anu aie numLeieu lelt
to iight, staiting at slot 0, wheieas the SRX5600s aie numLeieu liom top to Lottom
(see Figuie +-+).
Iigurc 1-1. SRX5000 scrics s|ot nunbcrs
The SRX 3000 seiies aie numLeieu in two iows, liont anu ieai (Figuie +-5). Theie aie
limitations on wheie IOCs can Le placeu in the chassis; ielei to the haiuwaie guiues
loi these locations.
Iigurc 1-5. SRX3000 scrics s|ot nunbcrs
The Lianch ollice SRX seiies aie numLeieu like the ]-seiies iouteis, with the lixeu
inteilaces on slot 0 anu the iemaining inteilaces numLeieu in a lelt to iight, top to
Lottom mannei.
84 | Chapter 4:Interfaces
The MXs suppoit inteilaces on the uense poit concentiatois (DPCs) anu mouulai poit
concentiatois (MPCs). These aie inseiteu into slots ol the MX chassis. Similai to the
SRX line, the MX slot-numLeiing system is mouel uepenuent. The MX960 is numLeieu
iuentically to the SRX5S00, wheieas the MX+S0, MX2+0, anu miu-iange MXs aie
numLeieu liom Lottom to top (see Figuie +-6).
Iigurc 1-. MX s|ot nunbcring
PIC slot number
The next pait ol the inteilace name is the PIC slot numLei, iepiesenteu Ly the vaiiaLle
P. In M-seiies iouteis, loui PICs can lit into a single FPC slot. The slot numLeis Legin
at 0 anu continue to the linal slot, 3. In M-seiies iouteis, the uiiection ol PIC slot
numLeiing uepenus on whethei the chassis slots aie veitically oi hoiizontally aligneu.
In a veitically aligneu M-seiies ioutei, the PIC slot numLei is counteu liom top to
Lottom, as shown in Figuie +-7.
Iigurc 1-7. P|C s|ot nunbcrs jor M10c and M320
Transient Interfaces | 85
PIC slot numLeiing in hoiizontally aligneu systems such as the M7i anu M10i is a little
less stanuaiu. In these systems, the PIC slot numLeiing goes liom iight to lelt, staiting
at 0 anu enuing at slot 3, as shown in Figuie +-S. The M7i`s seconu FPC slot contains
only two possiLle PIC slot numLeis, anu as shown in Figuie +-9, slot 2 is useu loi the
Luilt-in tunnel inteilace, oi Auaptive Seivices Mouule (ASM), anu slot 3 is useu loi the
lixeu Etheinet inteilaces.
Iigurc 1-8. P|C s|ot nunbcrs jor M7i, M10i, and M20
Iigurc 1-9. M7i P|C s|ot nunbcring
In the SRX anu MX uevices, the PIC iuentilieis aie Laseu on the type ol caius useu. Foi
the lull-size slot caius (IOCs anu DPCs), theie aie loui PICs assigneu to the slot (0, 1,
2, 3) in a top to Lottom, lelt to iight lashion when the caius aie helu veitically. Foi the
smallei caius (MICs, PIMs, etc.), theie aie no PIC slots; thus, the inteilace naming (F)
convention is always set to a value ol 0.
It seems counteiintuitive that PIC slot numLeiing is counteu liom iight
to lelt. The ieason haikens Lack to the liist iouteis (M+0), which weie
veitically aligneu FPC slots with PIC slot numLeiing liom top to Lottom.
Next came the hoiizontally aligneu FPC slot (M20), which was essen-
tially a veitically aligneu ioutei tuineu on its siue, which causeu the PIC
slot to shilt to iight to lelt.
86 | Chapter 4:Interfaces
Port number
The last pait ol the inteilace name is iepiesenteu Ly the vaiiaLle T, oi the actual physical
poit numLei. M-seiies iouteis have poit numLeis with a vaiiety ol schemes, uepenuing
on the PIC anu the ioutei mouel (hoiizontal veisus veitical slots). Foi veitical FPC
iouteis (m+0e, M320), poit numLeis stait liom the top iight anu continue liom the
Lottom to the top anu then move iight to lelt. Foi hoiizontal FPC iouteis (m20, m7i,
m10i), poit numLeis stait liom the Lottom iight anu then move iight to lelt anu liom
the Lottom to the top. It`s easiei to see Ly examining Figuies +-10 thiough +-13, which
show this seguence in the uilleient chassis types.
To avoiu any conlusion oi spontaneous Liain comLustions, iememLei
that the poit numLei is always wiitten on the PIC itsell.
Iigurc 1-10. Port nunbcrs on a vcrtica| IPC chassis starting at thc top right
Iigurc 1-11. Port nunbcrs on a vcrtica| IPC chassis starting at thc top
Transient Interfaces | 87
Iigurc 1-12. Port nunbcrs on a horizonta| IPC chassis starting at thc botton right
Iigurc 1-13. Port nunbcrs on a horizonta| IPC chassis starting on thc right
The lixeu Etheinet poits on the M7i lollow the convention ol
Figuie +-13 anu count liom iight to lelt, staiting at poit 0.
Poit numLeis aie gieatly simplilieu in ]-seiies iouteis anu Bianch Ollice SRXs, as all
poits aie always numLeieu liom lelt to iight. This incluues poits on a PIM (see Fig-
uie +-1+) as well any lixeu poits on the chassis (see Figuie +-15).
Iigurc 1-11. Iour-port Iast Ethcrnct E-P|M
88 | Chapter 4:Interfaces
Iigurc 1-15. j2320 IE ports with right-to-|cjt nunbcring
Heie aie a lew M-seiies example inteilaces:
se-1/0/0
Seiial inteilace in FPC slot 1, PIC slot 0, anu poit 0
fe-0/2/1
Fast Etheinet inteilace in FPC slot 0, PIC slot 2, anu poit 2
t1-1/0/1
T1 inteilace in FPC slot 1, PIC slot 0, anu poit 1
Logical unit and channel numbers
Inteilaces also have a logical poition ol the name iepiesenteu Ly eithei a unit numLei
oi a channel numLei. A |ogica| unit is a numLei that iepiesents the suLinteilace piop-
eities ol the ioutei anu can Le conliguieu in the iange ol 016,3S5. This is uesignateu
Ly a peiiou (.) in the inteilace name. Foi example:
ge-0/0/0.0
Unit 0 conliguieu on the GigaLit Etheinet inteilace
e3-1/0/2.12
Unit 12 conliguieu on the e3 inteilace
The othei logical uivision coulu Le a channel numLeiloi example, when Lieaking
up a T1 inteilace into multiple DS0 channels (up to 2+). Channel values aie iepiesenteu
using a colon (:). Foi example:
ct-1/1/2:14
Channel 1+ on a channelizeu T1 inteilace
Ve will covei logical units in uepth in Logical Piopeities on page 90.
Interface Properties
Each inteilace has two types ol piopeities assigneu to it: physical piopeities anu logical
piopeities. Physica| propcrtics aie tieu to the entiie physical poit, wheieas |ogica| prop-
crtics allect only that logical poition ol the inteilace iepiesenteu Ly unit numLeis oi
channel numLeis.
Interface Properties | 89
Physical Properties
A physical piopeity on an inteilace is any piopeity that shoulu Le assigneu to the entiie
physical poit. Depenuing on the inteilace meuia, a laige iange ol piopeities can Le
conliguieu, Lut they can Le uiviueu into a lew majoi categoiies:
C|oc|ing
This aligns the Lits as they aie tiansmitteu out ol the inteilace. The clocking can
Le leaineu eithei liom an exteinal souice oi liom the ioutei itsell.
Encapsu|ation
This is the Layei 2 encapsulation that is going to Le useu on the inteilace. Examples
incluue Fiame Relay, Point-to-Point Piotocol (PPP), anu Cisco High-Level Data
Link Contiol (HDLC).
MTU
This is the maximum tiansmission unit, which is the maximum size ol the liame
tiansmitteu liom the inteilace.
Kccpa|ivcs
These aie mechanisms useu to veiily the opeiation ol the inteilace. Most encap-
sulations have keepalives enaLleu Ly uelault, Lut you can uisaLle them to aiu in
tiouLleshooting.
Laycr 1/2 options
These aie vaiious Lit anu Lyte settings loi the inteilace meuia. Foi a T1 inteilace,
this incluues Lyte encouings, liaming, liame check seguences (FCSs), anu line
Luiluouts. In compaiison, a Fast Etheinet inteilace might have options such as
llow contiol, loopLacks, anu souice auuiess lilteis.
A physical piopeity shoulu always Le conliguieu Leloie any logical iuentiliei, such as
a unit numLei. Foi example, the lollowing is a seiial inteilace with no logical piopeities
conliguieu Lut with physical piopeities ol encapsulation cisco-HDLC anu no-
keepalives, anu with clocking set to internal:
se-0/0/2 {
no-keepalives;
encapsulation cisco-hdlc;
serial-options {
clocking-mode internal;
}
unit 0;
}
Logical Properties
All ioutei inteilaces that will senu anu ieceive tiansit tiallic ieguiie a logical unit to Le
conliguieu. This logical unit cieates a uivision ol the physical inteilace into multiple
paits. Foi instance, an Etheinet inteilace can Le suLuiviueu into multiple viitual LANs
(VLANs), each ieguiiing its own logical unit.
90 | Chapter 4:Interfaces
Many ioutei venuois ielei to a logical unit as a subintcrjacc; they uo not
ieguiie a suLinteilace on eveiy physical inteilace, wheieas a ]unipei
Netwoiks ioutei uoes.
Some inteilace types, such as point-to-point inteilaces anu non-VLAN-taggeu Etheinet
inteilaces, still ieguiie a logical unit to Le conliguieu. This is a unigue leatuie ol ]unos
anu may take a little getting useu to il you`ie coming liom othei ioutei venuois` haiu-
waie. These inteilaces ieguiie a unit numLei Lecause any logical piopeity that neeus
to Le conliguieu nust Le uelineu altei the unit numLei uelinition. The most common
types ol logical piopeities incluue:
Protoco| jani|y
Inuicates which Layei 3 piotocols can Le sent anu ieceiveu on the inteilace. The
ioutei can have one piotocol lamily pei logical unit oi multiple lamilies pei logical
unit conliguieu. The most common lamily conliguieu is family inet, which ena-
Lles the senuing anu ieceiving ol all packets in the Tiansmission Contiol Piotocol/
Inteinet Piotocol (TCP/IP) suite (e.g., TCP, Usei Datagiam Piotocol UDP, In-
teinet Contiol Message Piotocol ICMP, anu IP). Othei common lamilies aie inet6
(IPv6), Multipiotocol LaLel Switching (MPLS), anu ISO (ISIS packets). The lami-
lies multilink-frame-relay-end-to-end anu Multilink PPP aie useu to cieate mul-
tilink inteilaces.
Protoco| addrcss
The Layei 3 lamily auuiess, such as a family inet IP auuiess.
\irtua| circuit addrcss
Ciicuit iuentiliei useu when uiviuing the physical inteilace into multiple logical
inteilaces. These coulu Le the VLAN ID, Fiame Relay uata-link connection iuen-
tilieis (DLCIs), oi ATM Viitual Channel Iuentiliei VCIs).
The logical unit numLei when conliguiing VLAN, Fiame Relay, oi ATM can Le any
value liom 016,3S5. The cuiient Lest piactice, howevei, is to keep the ciicuit auuiess
the same as the unit numLei loi easiei tiouLleshooting. So, il you have a VLAN ID ol
+0 conliguieu on youi inteilace, the logical inteilace shoulu also Le a unit ol +0,
although it`s not ieguiieu. Il you aie conliguiing a point-to-point ciicuit oi non-VLAN-
taggeu Etheinet, the logical unit numLei nust Le zeio. Think ol this unit as a place-
holuei loi all the logical piopeities that will neeu to Le conliguieu on that inteilace.
Heie is an example ol a T1 inteilace conliguiation with the uelault paiameteis (PPP
encapsulation), family inet suppoit, anu an IP auuiess ol 66.32.3.2/30. Note that since
this is a point-to-point ciicuit, the unit numLei must Le conliguieu as unit 0:
t1-2/0/2 {
unit 0 {
family inet {
Interface Properties | 91
address 66.32.3.2/30;
}
}
Interface Configuration Examples
A walkthiough ol conliguiation examples, staiting with Lasic examples anu then get-
ting into a lew moie complex conliguiations, will help to put this into peispective. The
oiuei ol the walkthiough uses the lollowing conliguiation examples:
GigaLit Etheinet inteilaces
GigaLit Etheinet with VLAN tagging
T1 inteilace with Cisco HDLC
Seiial inteilace with PPP
Seiial inteilace with Fiame Relay
DSL
MLPPP
Aggiegateu Etheinet inteilaces
GRE Tunnel Inteilaces
Initially, we will use a step-Ly-step appioach to estaLlish the conliguiation lunuamen-
tals. Then the walkthiough will move towaiu conliguiation iesults that Luilu on the
lunuamentals anu Lecome auvanceu. Once you giasp the lunuamentals, you shoulu
Le aLle to lollow the auvanceu conliguiations. At the enu ol this section, we will uiscuss
the use ol the Viitual Routei Reuunuancy Piotocol (VRRP).
Gigabit Ethernet Interface
Fiist, let`s Luilu an inteilace on ioutei Lager that connects uiiectly to ioutei Ale ovei
the ge-0/0/0 inteilace.
Check the status ol the ge-0/0/0 inteilace Ly issuing a show interfaces ge-0/0/0
terse commanu. ]unos inteilaces aie automatically enaLleu when the physical con-
nection is wiieu:
root@Lager> show interfaces terse ge-0/0/0
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
Il an inteilace neeus to Le auministiatively uisaLleu, issue the set
interfaces <interface name> disable commanu.
92 | Chapter 4:Interfaces
The inteilace appeais to Le physically up, so next, conliguie the inteilace to allow IP
tiallic to llow as well as auu an IP auuiess. Begin Ly enteiing conliguiation moue,
uiopping uown to the hieiaichy ol the inteilace, anu conliguiing the coiiect lamily anu
local IP auuiess:
root@Lager> configure
Entering configuration mode
[edit]
root@Lager# edit interfaces ge-0/0/0
[edit interfaces ge-0/0/0]
root@Lager# set unit 0 family inet address 10.10.20.122/24
Since this is a non-VLAN-taggeu Etheinet inteilace, unit 0 nust Le useu when conlig-
uiing the logical piopeities ol lamily inet.
Also, note that ]unos ieguiies a mask loi eveiy IP auuiess in the classless inteiuomain
iouting (CIDR) slash notation. An aLsence ol the mask can leau to the less uesiiaLle
iesult ol conliguiing a /32 suLnet on youi inteilace. (Look loi othei ]unos auuiess issues
in Inteilace TiouLleshooting on page 10S.)
Veiily the conliguiation anu activate the changes Ly issuing a commit and-quit
commanu:
[edit interfaces ge-0/0/0]
root@Lager# show
unit 0 {
family inet {
address 10.10.20.122/24;
}
}
[edit interfaces ge-0/0/0]
root@Lager# commit and-quit
commit complete
Exiting configuration mode
Veiily the status ol the inteilace. Note that the status now incluues the logical poition
as well as the physical poition ol the inteilace:
root@Lager> show interfaces terse ge-0/0/0
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.10.20.122/24
Lastly, test connectivity Ly issuing a ping commanu towaiu the othei enu ol the link
ol Ale:
root@Lager> ping 10.10.20.121
PING 10.10.20.121 (10.10.20.121): 56 data bytes
64 bytes from 10.10.20.121: icmp_seq=0 ttl=64 time=7.758 ms
64 bytes from 10.10.20.121: icmp_seq=1 ttl=64 time=10.394 ms
^C
Interface Configuration Examples | 93
--- 10.10.20.121 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 7.758/9.076/10.394/1.318 ms
Notice the Ctil-C seguence useu to Lieak out ol the ping commanu.
]unos will senu an enuless numLei ol pings unless a Lieak is issueu oi
a specilic numLei ol ping packets aie specilieu with the count commanu.
root@Lager> ping 10.10.20.121 count 3
PING 10.10.20.121 (10.10.20.121): 56 data bytes
64 bytes from 10.10.20.121: icmp_seq=0 ttl=64 time=16.822 ms
64 bytes from 10.10.20.121: icmp_seq=1 ttl=64 time=20.382 ms
64 bytes from 10.10.20.121: icmp_seq=2 ttl=64 time=10.370 ms
--- 10.10.20.121 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 10.370/15.858/20.382/4.144 ms
Gigabit Ethernet with VLAN Tagging
Continuing with oui example, let`s auu VLAN tagging Letween Lager anu Ale, which
is alieauy conliguieu with a VLAN ID ol 100. The liist step is to enaLle VLAN tagging
on the physical inteilace ol Lager:
root@Lager> configure
Entering configuration mode
[edit]
root@Lager# edit interfaces ge-0/0/0
[edit interfaces ge-0/0/0]
root@Lager# set vlan-tagging
Next, auu a VLAN ID ol 100 on logical unit 0:
[edit interfaces ge-0/0/0]
root@Lager# set unit 0 vlan-id 100
[edit interfaces ge-0/0/0]
root@Lager# show
vlan-tagging;
unit 0 {
vlan-id 100;
family inet {
94 | Chapter 4:Interfaces
address 10.10.20.122/24;
}
}
]unipei iouteis uo not have a uelault VLAN, as eveiy VLAN must Le
explicitly conliguieu. Many switches use a uelault VLAN ol 1, so make
suie you explicitly conliguie a vlan-id ol 1 on the ioutei loi
connectivity.
Although this is a valiu conliguiation on unit 0, the Lest piactice is to always keep the
same unit numLei as the VLAN tag, so let`s change the unit numLei with the rename
commanu:
[edit interfaces ge-0/0/0]
root@Lager# rename unit 0 to unit 100
[edit interfaces ge-0/0/0]
root@Lager# show
vlan-tagging;
unit 100 {
vlan-id 100;
family inet {
address 10.10.20.122/24;
}
}
Lastly, activate the changes, veiily the inteilace status, anu test connectivity:
[edit interfaces ge-0/0/0]
root@Lager# top
[edit]
root@Lager# commit
commit complete
[edit]
root@Lager# run show interfaces terse ge-0/0/0
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
ge-0/0/0.100 up up inet 10.10.20.122/24
[edit]
root@Lager# run ping 10.10.20.121 count 1
PING 10.10.20.121 (10.10.20.121): 56 data bytes
64 bytes from 10.10.20.121: icmp_seq=0 ttl=64 time=46.668 ms
--- 10.10.20.121 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 46.668/46.668/46.668/0.000 ms
[edit]
root@Lager# run show interfaces terse ge-0/0/0
Interface Configuration Examples | 95
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
Notice the use ol the commanu run to issue the opeiational moue com-
manu ping in conliguiation moue.
Also notice the use ol the top commanu piioi to the commit commanu.
In some cases a commit can Le issueu only liom the top. Using top will
save time otheiwise spent issuing multiple commit commanus.
T1 Interface with Cisco HDLC Encapsulation
The T1 inteilace is the most populai Lasic physical layei piotocol useu Ly the Digital
Signal level 1 (DS1) multiplexing methou in Noith Ameiica. Foi point-to-point intei-
laces on ]unipei Netwoiks iouteis, the uelault Layei 2 encapsulation is PPP, which
uilleis liom many othei venuois` uelault Lehavioi. To guickly inteiopeiate with those
venuois, change the encapsulation to the uelault setting, which is usually Cisco HDLC.
Since we alieauy showeu the step-Ly-step conliguiation in the pievious conliguiation,
we show heie only the iesult ol auuing the coiiect encapsulation:
t1-2/0/2 {
encapsulation cisco-hdlc;
unit 0 {
family inet {
address 10.200.8.9/30;
}
}
}
An inguiiing minu may wonuei why the encapsulation has the woiu
cisco in it. Is theie a non-Cisco HDLC? As a mattei ol lact, theie is! Theie
is a stanuaiu HDLC piotocol (ISO 13239), useu in piotocols such as
X.25 anu SDLC. The oiiginal specilication uiu not have multipiotocol
suppoit, so Cisco ueciueu to cieate its own veision with this suppoit
with uilleient heauei lielus anu uelinitions. Although this piotocol is
ollicially piopiietaiy, the woikings aie open anu have Leen implemen-
teu Ly many uilleient ioutei venuois.
Serial Interface with PPP
A seiial inteilace can come in a vaiiety ol uilleient physical loims, such as V.35, X.21,
anu EIA-530. The choice ol physical meuia olten uepenus on geogiaphical location;
V.35 is the most common choice in the Uniteu States anu Euiope, anu X.21 is moie
common in ]apan. Regaiuless ol physical meuia, all seiial inteilaces have the same iuea
ol uelining a uata ciicuit-teiminating eguipment (DCE) uevice anu a uata teiminal
eguipment (DTE) uevice. The DTE uevice is the enu unit that ieceives uata encouing,
clocking, anu signal conveision liom the DCE uevice. In mouein communications, the
96 | Chapter 4:Interfaces
DCE uevice olten takes the loim ol a channel seivice unit/uata seivice unit (CSU/DSU)
oi a mouem; howevei, when connecting two iouteis in a Lack-to-Lack lashion, one ol
the iouteis takes the iole ol a DCE.
Routei Ale anu ioutei Bock have a Lack-to-Lack seiial connection using V.35 with the
uelault encapsulation ol PPP. Noimally, a ioutei will uelault to DTE moue, Lut in this
case, Ale is automatically chosen as the DCE Laseu on the uetection ol a DCE caLle.
You can oLseive this uetection in the Local mode lielu ol the show interfaces commanu:
root@ale# run show interfaces se-1/0/0 extensive | find "serial media"
Serial media information:
Line protocol: v.35
Resync history:
Sync loss count: 0
Data signal:
Rx Clock: Not Detected
Control signals:
Local mode: DCE
To DTE: CTS: up, DCD: up, DSR: up
From DTE: DTR: up, RTS: up
DCE loopback override: Off
Clocking mode: loop-timed
Loopback: none
Tx clock: non-invert
Line encoding: nrz
Since one ol the ioles ol the DCE is to pioviue clocking to the DTE, an inteinal clocking
moue neeus to Le conliguieu on Ale. This allows Ale to geneiate a clocking signal
towaiu Bock using the inteinal clock with a uelault clock iate ol S MHz:
[edit interfaces]
root@ale# show se-1/0/0
serial-options {
clocking-mode internal;
}
unit 0 {
family inet {
address 172.16.1.1/30;
}
}
Bock has no clocking moue conliguieu anu takes the uelault clock moue ol loop-timeu,
which takes the tiansmitteu clock liom Ale. Bock coulu also have Leen conliguieu loi
DCE moue, which woulu have the same iesult in this case. Heie is the Bock
conliguiation:
[edit interfaces se-1/0/1]
root@Bock# show
unit 0 {
family inet {
address 172.16.1.2/30;
}
}
Interface Configuration Examples | 97
You can veiily the local moue, clocking moue, anu clock iate on Bock Ly using the show
interfaces commanu:
[edit interfaces se-1/0/1]
root@Bock# run show interfaces se-1/0/1 extensive | find "serial media"
Serial media information:
Line protocol: v.35
Resync history:
Sync loss count: 0
Data signal:
Rx Clock: OK
Control signals:
Local mode: DTE
To DCE: DTR: up, RTS: up
From DCE: CTS: up, DCD: up, DSR: up
Clocking mode: loop-timed Clock rate: 8.0 MHz
Loopback: none
Tx clock: non-invert
Line encoding: nrz
Clocking can olten Le a conlusing topic loi many useis. Foi Lack-to-
Lack ioutei connections, ]unipei maue it simple Ly allowing multiple
uilleient clocking moues to Le conliguieu anu still uo the iight thing.
The only comLinations that will not woik loi Lack-to-Lack connections
aie the DCE in loop moue anu the DTE in loop oi DCE moue. Howevei,
when connecting to a CSU/DSU oi a mouem, piopei caie must Le taken
to conliguie the coiiect clock moue.
Serial Interface with Frame Relay
Fiame Relay is a Layei 2 encapsulation that enaLles the connection ol youi LAN via a
VAN connection to a Fiame Relay noue. Fiame Relay cieates a tunnel calleu a pei-
manent viitual ciicuit (PVC) ovei a piivate oi leaseu line to pioviue connectivity to
othei sites ovei the Inteinet seivice pioviuei`s (ISP`s) inliastiuctuie. Vith the emei-
gence ol DSL anu IP-Laseu netwoiks, Fiame Relay is not olten seen anymoie, except
in iuial aieas as a cheapei, always on connection.
To estaLlish a Fiame Relay connection with the Fiame Relay noue, the piopei encap-
sulation ol frame-relay (RFC 1+90) must Le conliguieu as well as the local ciicuit
iuentiliei loi the PVC iepiesenteu Ly the logical piopeity ol a dlci numLei:
se-1/0/0 {
encapsulation frame-relay;
unit 645 {
description "to R3";
dlci 645;
family inet {
address 172.17.24.130/30;
}
}
}
98 | Chapter 4:Interfaces
The ioutei can also suppoit Lack-to-Lack ioutei connections Ly conliguiing one ioutei
to opeiate in DCE moue oi Ly tuining oll keepalives on each ioutei. Il keepalives aie
uisaLleu, the ioutei will not wait loi any local management messages to enaLle that
inteilace. Also, tuining keepalives oll can help in tiouLleshooting Ly allowing loi loop-
Lack testing, which we`ll uiscuss latei in this chaptei.
ADSL Using PPPoE over ATM
DSL is one ol the moie populai connection meuia loi Loth companies anu consumeis
Lecause the local seivice is pioviueu via a noimal phone line with a DSL mouem. This
connection teiminates at the telco uigital suLsciiLei line access multiplexei (DSLAM),
a uevice that concentiates multiple DSL connections togethei. Some ]-seiies iouteis
have suppoit loi ATM ovei asymmetiical uigital suLsciiLei line (ADSL)Annex A loi
DSL ovei POTS oi Annex B loi DSL ovei ISDNanu symmetiic high-speeu uigital
suLsciiLei line (SHDSL) conliguiations that allow them to act as the DSL mouem at
the customei site. The inteilaces appeai to Le ATM connections Lut uo not suppoit
native ATM, only the use ol ATM ovei a DSL connection.
Routei PBR has an ADSL Annex A PIM installeu in slot 6 anu will act as a client to the
DSLAM. This connection is using Point-to-Point Piotocol ovei Etheinet (PPPoE) ovei
ATM loi the DSL connection, which ieguiies that two uilleient inteilaces Le conlig-
uieu. The liist inteilace that is conliguieu is the physical ATM inteilace ol at-6/0/0.
To conliguie the inteilace, the ATM viitual path anu viitual channel iuentities must Le
the same values that aie piovisioneu at the DSLAM. The iest ol the paiameteis can Le
leaineu liom the DSLAM Ly setting an opeiating moue ol auto. Since PBR will Le using
PPPoE, the encapsulation nust Le conliguieu at both the physical anu the logical layeis:
[edit]
doug@PBR# show interfaces
at-6/0/0 {
encapsulation ethernet-over-atm;
atm-options {
vpi 0;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation ppp-over-ether-over-atm-llc;
vci 0.39;
}
}
The next inteilace that must Le conliguieu is the PPPoE inteinal ioutei inteilace. This
inteilace maps the physical inteilace wheie PPPoE will Le iunning, sets the access
seivei`s name anu unueilying seivice to Le ieguesteu, anu sets an IP auuiess. The
IP auuiess can Le leaineu automatically liom the access seivei Ly specilying the
Interface Configuration Examples | 99
negotiate-address commanu, as seen in the conliguiation ol PBR that lollows, oi Ly
setting the IP auuiess to Le static:
pp0 {
unit 0 {
pppoe-options {
underlying-interface at-6/0/0.0;
access-concentrator mgmgrand;
service-name "pppserv@mgmgrand";
auto-reconnect 5;
}
family inet {
negotiate-address
}
}
}
}
You can veiily the coiiect opeiation ol the PPPoE negotiation Ly issuing the show
pppoe interfaces commanu:
[edit]
doug@PBR# run show pppoe interfaces
pp0.0 Index 68
State: Session up, Session ID: 4,
Service name: pppserv@mgmgrand, Configured AC name: mgmgrand,
Session AC name: mgmgrand, AC MAC address: 00:05:85:ca:7a:a8,
Session uptime: 00:22:43 ago,
Auto-reconnect timeout: 5 seconds, Idle timeout: Never,
Underlying interface: at-6/0/0.0 Index 66
MLPPP
To inciementally inciease the speeu ol inuiviuual PPP links without auuing speeu to
the physical inteilaces, the Multilink Point-to-Point Piotocol (MLPPP) was cieateu un-
uei RFC 1990. This is essentially a soltwaie Lonu ol multiple physical PPP inteilaces
to loim one laigei logical link, calleu a bund|c. ]unos allows loi up to eight physical
inteilaces to Le assigneu to a Lunule.
To suppoit MLPPP on any ]unipei Netwoiks ioutei, the ioutei must suppoit this spe-
cial seivice. This suppoit coulu Le in the loim ol an auuitional haiuwaie PIC on an
M-seiies ioutei, oi it coulu inheiit soltwaie suppoit on othei ]unipei iouteis.
The liist step is to conliguie the pseuuolink seivice inteilace, which takes the loim ol
lsq-0/0/0 on ]-seiies, MX, anu SRX iouteis, oi an ml, lsq, oi ls inteilace on an
M-seiies ioutei, uepenuing on the PIC type. This inteilace will take all the same chai-
acteiistics ol a noimal PPP inteilace, such as an IP auuiess, Lut will have a logical
encapsulation ol multilink-ppp. This is conliguieu at the logical layei ol the inteilace
to allow multiple Lunules anu types ol Lunules on the same ioutei Ly conliguiing
multiple unit numLeis. As shown heie, the Lunule is assigneu to logical unit 0:
100 | Chapter 4:Interfaces
lsq-0/0/0 {
unit 0 {
encapsulation multilink-ppp;
family inet {
address 172.8.17.30/30;
}
}
}
Next, conliguie the physical inteilaces to link the newly cieateu link seivice inteilace.
In the lollowing example, inteilaces se-1/0/0 anu se-1/0/1 aie linkeu to the logical
Lunule unit 0 on the ls-0/0/0 inteilace:
se-1/0/0 {
unit 0 {
family mlppp {
bundle lsq-0/0/0.0;
}
}
}
se-1/0/1 {
unit 0 {
family mlppp {
bundle lsq-0/0/0.0;
}
}
}
To veiily the status, issue the show interfaces terse commanu. Notice that Loth the
seiial inteilaces anu the link seivice inteilaces aie tiackeu. The link seivice will Le in
the up state as long as one ol the physical inteilaces is also in the up state. You can
mouily this Ly conliguiing the minimum-links number commanu unuei the link seivice
inteilace. This commanu sets the numLei ol physical links that must Le in the up state
loi the Lunule to Le laLeleu up:
root@Bock# run show interfaces terse | match "se|lsq-"
lsq-0/0/0 up up
lsq-0/0/0.0 up up inet 172.17.8.30/30
se-1/0/0 up up
se-1/0/0.0 up up mlppp lsq-0/0/0.0
se-1/0/1 up up
se-1/0/1.0 up up mlppp lsq-0/0/0.0
Notice the use ol an oi statement in the match ciiteiia. The use ol
guotes anu the pipe symLol uenotes an oi statement loi the match,
looking loi lines that contain eithei se oi lsq-.
Aggregated Ethernet
The IEEE S02.3au stanuaiu uelines a means to Lunule multiple Etheinet inteilaces into
an aggiegate gioup. Tiallic is passeu ovei all memLeis ol the gioup in a loau-Lalancing
Interface Configuration Examples | 101
aiiangement. The link aggiegation contiol piotocol (LACP) can Le auueu to monitoi
the Lunule, allowing inteilaces to Le auueu oi suLtiacteu liom the Lunule without loss
ol tiallic.
The use ol S02.3au allows multiple connections Letween a ioutei anu a switch without
the possiLility ol a Lioaucast stoim. This impioves peiloimance anu has a guickei
iecoveiy time than using a spanning tiee piotocol.
The conliguiation ol S02.3au has thiee paits: setting the chassis paiameteis, the ag-
giegate inteilace, anu the paiticipating inteilaces. The chassis paiameteis ueline the
total numLei ol aggiegate inteilaces that will Le set on the ioutei. In this example, we
aie installing only a single aggiegate inteilace:
root@Lager> show configuration chassis
aggregated-devices {
ethernet {
device-count 1;
}
}
The aggiegate inteilace uses an inteinal inteilace type ol ae0. This inteilace caiiies the
logical inteilace piopeities loi the inteilacein this case, the IP auuiess loi the Lunule:
root@Lager> show configuration interfaces ae0
unit 0 {
family inet {
address 4.4.4.1/24;
}
}
Finally the paiticipating inteilaces aie auueu to the conliguiation. Up to 10 Etheinet
inteilaces can Le auueu to an aggiegate Lunule. These inteilaces can Le in any location
on the ioutei:
root@Lager> show configuration interfaces ge-0/0/2
gigether-options {
802.3ad ae0;
}
root@Lager> show configuration interfaces ge-0/0/3
gigether-options {
802.3ad ae0;
}
Once the conliguiation is enteieu anu committeu, the ae0 inteilace is monitoieu as any
othei inteilace on the ioutei. The show interfaces ae0 commanu shows the inteilace`s
Lanuwiuth anu status. The show interface terse commanu shows the auuiesses ol the
aggiegate inteilace anu the Lunule ol the aggiegateu Etheinet inteilaces:
root@Lager> show interfaces ae0
Physical interface: ae0, Enabled, Physical link is Up
Interface index: 146, SNMP ifIndex: 142
Link-level type: Ethernet, MTU: 1514, Speed: 2000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
102 | Chapter 4:Interfaces
Flow control: Disabled, Minimum links needed: 1, Minimum bandwidth needed: 0
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
root@Lager> show interfaces terse | match "ge-|ae0"
....
ge-0/0/2 up up
ge-0/0/2.0 up up aenet --> ae0.0
ge-0/0/3 up up
ge-0/0/3.0 up up aenet --> ae0.0
ae0 up up
ae0.0 up up inet 4.4.4.1/24
GRE
Geneiic Routing Encapsulation (GRE) is a tunneling piotocol that enaLles the tianspoit
ol a vaiiety ol Layei 3 piotocols. The tunnel cieateu Ly GRE was uesigneu to Le state-
less with no monitoiing ol the tunnel enupoint. GRE tunnels aie useu loi a vaiiety ol
applications, incluuing pioviuing Lackup links, tianspoiting non-IP piotocols ovei an
IP netwoik, anu connecting islanus ol IP netwoiks.
To cieate a GRE tunnel on a ]unipei Netwoiks ioutei, the ioutei must Le eguippeu
with Layei 2 seivice capaLilities, which aie native in the ]-seiies, MX, anu SRX iouteis
anu aie availaLle via a haiuwaie PIC in an M-seiies ioutei. Vhen these seivices aie
enaLleu on a ioutei, a pseuuointeilace calleu gr is cieateu. The inteilace must Le con-
liguieu with the souice IP auuiess loi the GRE packets, the uestination ol the tunnel,
anu the lamilies ol piotocols that will Le caiiieu in the piotocol. The GRE tunnel con-
liguieu in the lollowing case is caiiying IP tiallic anu is using a souice IP auuiess ol
10.20.1.3S anu a uestination ol 172.66.13.1. An IP auuiess loi the gr-0/0/0 inteilace
is not ieguiieu Lut coulu Le uselul loi management puiposes:
gr-0/0/0 {
unit 0 {
tunnel {
source 10.20.1.38;
destination 172.66.13.1;
}
family inet
}
}
It is impoitant not to mistake the inteinal gre inteilace with the gr in-
teilace on the ioutei. The gre inteilace is useu Ly the ioutei inteinally
anu shoulu not Le conliguieu to cieate GRE tunnels.
The linal piece is mapping actual tiallic loi use Ly the GRE tunnel. This is accomplisheu
in a vaiiety ol methous uepenuing on the type ol tiallic enteiing the GRE tunnel. Com-
mon mapping examples loi IP incluue cieating a static ioute with a next-up ol the gr
Interface Configuration Examples | 103
inteilace oi even iunning a iouting piotocol such as Open Shoitest Path Fiist (OSPF)
ovei the inteilace!
VRRP
AnyLouy using a PC loi Inteinet suiling, music uownloaus, oi gaming uses IP as the
netwoik piotocol. The PC will have an IP auuiess assigneu as well as a uelault gateway
auuiess to ieach any uestinations that aie not on the local suLnet. In the lollowing coue
snippet, a PC is using an IP auuiess ol 10.70.129.36 with a mask ol 255.255.255.0 anu
a uelault gateway ol 10.70.129.1:
Microsoft Windows [Version 6.0.6002]
Copyright <c> 2006 Microsoft Corporation
C:\Documents and Settings\Douglas Marschke>ipconfig
Ethernet adapter Local Area Connection 3:
Connection-specific DNS Suffix . : eu-af.regus.local
IP Address. . . . . . . . . . . . : 10.70.129.36
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.70.129.1
This uelault gateway auuiess is eithei statically uelineu Ly the usei oi leaineu via the
Dynamic Host Conliguiation Piotocol (DHCP) piocess. Regaiuless ol the methou, the
uelault gateway will Le useu as the next hop auuiess loi the uelault ioute that will
Le cieateu to ieach iemote uestinations:
Microsoft Windows [Version 6.0.6002]
Copyright <c> 2006 Microsoft Corporation
C:\Documents and Settings\Douglas Marschke>netstat -r
Route Table
================================================================
Interface List
0x1 ......................... MS TCP Loopback interface
0x2 ...00 12 f0 ac 46 d5 ..... Intel(R) PRO/Wireless 2200BG Network
Connection - Packet Scheduler Miniport
0x3 ...00 12 3f 12 d7 59 ...... Broadcom NetXtreme 57xx Gigabit
Controller - Packet Scheduler Miniport
0x20005 ...00 ff e8 25 91 85 ..... Juniper Network Connect Virtual
Adapter
================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.70.129.1 10.70.129.36 20
10.70.129.0 255.255.255.0 10.70.129.36 10.70.129.36 20
10.70.129.36 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.70.129.36 10.70.129.36 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 10.70.129.36 10.70.129.36 20
104 | Chapter 4:Interfaces
255.255.255.255 255.255.255.255 10.70.129.36 10.70.129.36 1
255.255.255.255 255.255.255.255 10.70.129.36 2 1
255.255.255.255 255.255.255.255 10.70.129.36 20005 1
Default Gateway: 10.70.129.1
==============================================================
Persistent Routes:
None
Il the uelault gateway was a single uevice anu that uevice laileu, a PC woulu not Le aLle
to ieach uestinations outsiue the local suLnet. In a lault-toleiant netwoik, it woulu Le
iueal to have a Lackup gateway uevice, without having to mouily the conliguiation on
the PC, as well as Leing aLle to loau-shaie with multiple PCs on the LAN.
VRRP was cieateu to eliminate single points ol Lehavioi that aie inheient to static
uelault iouteu netwoiks. VRRP cieates a logical giouping ol multiple physical iouteis
to a viitual ioutei that will Le useu as the uelault gateway loi enu hosts. This allows
the PC to always maintain the same gateway auuiess even il the physical gateway has
changeu (see Figuie +-16). The iouteis that aie pait ol the same VRRP logical gioup
will shaie this viitual IP auuiess as well as a viitual meuia access contiol (MAC)
auuiess. Essentially VRRP uesciiLes an election piotocol to maintain owneiship ol this
viitual IP (VIP) auuiess anu MAC auuiess. One ioutei in the VRRP gioup will Le the
mastei ioutei, which contiols this VIP auuiess unless a lailuie occuis that iesults in a
ielease ol that owneiship. This lailuie causes anothei ioutei to claim owneiship ol the
VIP Ly issuing a VRRP message anu a giatuitous Auuiess Resolution Piotocol (ARP)
to claim the viitual MAC auuiess. Once a ioutei Lecomes the mastei, it will peiiouically
auveitise VRRP messages to inuicate its oveiall health anu ieachaLility.
Vhen conliguiing VRRP loi the liist time on a ]unipei Netwoiks ioutei, it can seem
like locating the conliguiation is similai to tiying to linu a neeule in a haystack. The
conliguiation will Le within the logical piopeity anu will Le conliguieu altei the lamily
inet auuiess. A VRRP gioup value (1255) is assigneu on eveiy ioutei that neeus to Le
pait ol the viitual ioutei. Also, a VIP auuiess is assigneu that the hosts will use as theii
gateway auuiess. This coulu Le an auuiess owneu Ly one ol the iouteis in the gioup
oi an auuiess taken out ol the auuiess Llock owneu Ly the LAN. Lastly, a piioiity value
can Le conliguieu to change the uelault value ol 100, which is useu to elect the mastei
ioutei ol the VRRP gioup. The ioutei with the highest piioiity value Lecomes the
mastei loi that gioup; il the piioiities aie egual, the tieLieakei goes to the highest local
LAN IP auuiess:
lab@LAGER# show interfaces
ge-0/0/1 {
vlan-tagging;
speed 100m;
link-mode full-duplex;
unit 1115 {
description LAGER-to-ALE;
vlan-id 1115;
family inet {
address 10.40.1.2/24 {
Interface Configuration Examples | 105
vrrp-group 1 {
virtual-address 10.40.1.200;
priority 200;
}
}
}
}
Iigurc 1-1. \RRP cxanp|c
Veiily the opeiation ol VRRP with the show vrrp summary commanu. Routei Lager is
the mastei loi gioup 1 Lecause it has a highei piioiity:
[edit interfaces ge-0/0/1]
lab@LAGER# run show vrrp summary
Interface State Group VR state VR Mode Type Address
ge-0/0/1.0 up 1 master Active lcl 4.4.4.1
vip 4.4.4.100
Piioiity values iange liom 0255; howevei, only values 125+ aie con-
liguiaLle. Piioiity 0 is ieseiveu loi the mastei ioutei to issue an imme-
uiate ielease ol masteiship. A piioiity ol 255 is useu il the VIP is an actual
inteilace IP that is owneu Ly that ioutei.
Anothei option that can Le conliguieu is the aLility to tiack the inteilace piioiity set-
tings. Il an inteilace goes uown, the auveitiseu piioiity will Le suLtiacteu Ly a conlig-
uieu value. This coulu iesult in a new mastei ioutei loi the viitual ioutei. This is veiy
106 | Chapter 4:Interfaces
uselul to ensuie upstieam ieachaLility. In the example on Lager, a T1 inteilace is Leing
tiackeu. Il this inteilace goes uown, 150 will Le suLtiacteu liom the conliguieu piioiity
ol 200:
lab@LAGER# show interfaces
ge-0/0/1 {
vlan-tagging;
unit 1115 {
description LAGER-to-ALE;
vlan-id 1115;
family inet {
address 10.40.1.2/24 {
vrrp-group 1 {
virtual-address 10.40.1.200;
priority 200;
track {
interface t1-2/0/2.0 priority-cost 150;
}
}
}
}
}
You can loice an inteilace lailuie Ly auministiatively uisaLling the T1 inteilace:
lab@LAGER# top set interfaces t1-2/0/2 disable
[edit]
lab@LAGER# commit
commit complete
The iesult ol this lailuie is a masteiship change, as Lager is now the Lackup ioutei:
[edit]
lab@LAGER# run show vrrp summary
Interface State Group VR state VR Mode Type Address
ge-0/0/1.0 up 1 backup Active lcl 4.4.4.1
vip 4.4.4.100
Notice in the show vrrp track commanu that Lager has a conliguieu (cfg) piioiity value
ol 200, Lut a piioiity ol 50 is cuiiently Leing useu Lecause we`ve suLtiacteu the cost ol
150 liom the uowneu T1 inteilace:
lab@LAGER# run show vrrp track
Track Int State Speed VRRP Int Group VR State Current prio
t1-2/0/2.0 down 0 ge-0/0/1.0 1 backup 50
The uelault Lehavioi ol VRRP is to use prccnption, which causes a ioutei with a highei
piioiity to Lecome the mastei at any time. Vhen Lager`s T1 inteilace is ieenaLleu, it
will again Lecome the mastei loi the viitual ioutei:
[edit]
lab@LAGER# rollback 1
load complete
Interface Configuration Examples | 107
[edit]
lab@LAGER# commit
commit complete
[edit]
lab@LAGER# run show vrrp track
Track Int State Speed VRRP Int Group VR State Current prio
se-1/0/0.0 up 16384k ge-0/0/3.0 1 master 200
Since pieemption coulu cause a tempoiaiy uisiuption in the netwoik, a no-preempt
commanu can also Le conliguieu.
Lastly, accoiuing to RFC 376S, A VRRP ioutei SHOULD not loiwaiu packets au-
uiesseu to the VIP Auuiess(es) it Lecomes Mastei loi il it is not the ownei. That means
il we have an IP auuiess that is not owneu Ly any ioutei anu is simply an auuiess liom
the suLnet that was useu as the VIP, opeiational issues may appeai. The most common
issue is not Leing aLle to ping the viitual auuiess. In the case just examineu, 10.+0.1.200
was the VIP auuiess chosen out ol the 10.+0.1/2+ suLnet, Lut it was not actually con-
liguieu on eithei Lager oi Ale. ]unipei iouteis allow you to Lieak this iule Ly conliguiing
the accept-data commanu to allow the mastei ioutei to iesponu to the VIP auuiess.
This will allow testing to occui towaiu the VIP; howevei, caie must Le taken to avoiu
unnecessaiy tiallic on the LAN.
Interface Troubleshooting
Inteilaces can have a vaiiety ol issues uepenuing on the actual inteilace type, anu listing
all the possiLilities woulu ieguiie a sepaiate Look! Insteau, in this section, we will
uiscuss a lew common issues that illustiate the types ol tiouLleshooting commanus
availaLle on the ioutei.
Address Configuration Issues
Since ]unipei Netwoiks iouteis allow multiple IP auuiesses to Le conliguieu on a single
logical unit, conliguiation eiiois can occui il caie is not taken. Lager has an IP auuiess
ol 10.10.20.122 conliguieu on its gigaLit Etheinet inteilace with a suLnet mask ol /2+.
This was noticeu to Le a conliguiation eiioi, as the mask shoulu have Leen conliguieu
loi /27:
[edit interfaces ge-2/0/1]
root@Lager# show
vlan-tagging;
unit 100 {
vlan-id 100;
family inet {
address 10.10.20.122/24;
}
}
108 | Chapter 4:Interfaces
Heie, the auuiess ol 10.10.20.122 is auueu with the coiiect suLnet ol /27:
[edit interfaces ge-2/0/1]
root@Lager# set unit 100 family inet address 10.10.20.122/27
Vhen you view the iesultant inteilace conliguiation, the ioutei appeais to contain the
uuplicate IP auuiesses with vaiying suLnet masks. This illustiates the lact that IP au-
uiesses aie not oveiiiuuen pei logical unit, Lut simply aie auueu to the logical unit:
[edit interfaces ge-2/0/1]
root@Lager# show
vlan-tagging;
unit 100 {
vlan-id 100;
family inet {
address 10.10.20.122/24;
address 10.10.20.122/27;
}
}
To coiiect this, the olu auuiess with the /2+ mask is iemoveu Ly use ol the delete
commanu:
[edit interfaces ge-2/0/1]
root@Lager# delete unit 100 family inet address 10.10.20.122/24
Anothei solution with the same iesult is to use the rename commanu to change the
suLnet mask liom /2+ to /27:
[edit interfaces ge-2/0/1 unit 100]
root@Lager# rename address 10.10.20.122/24 to address 10.10.20.122/27
Since ]unipei Netwoiks iouteis allow placement ol multiple auuiesses on a single log-
ical inteilace, caie must also Le taken to allow loi the ioutei to choose the coiiect souice
IP auuiess loi outgoing packets on that inteilace. By uelault, the souice IP auuiess is
chosen Ly using the piimaiy anu pieleiieu auuiesses assigneu to the inteilace. Each
unit can have only one piimaiy auuiess, Lut each inteilace can have multiple pieleiieu
auuiesses. Simply put, a piimaiy auuiess is the auuiess chosen to souice local packets
out ol the inteilace uestineu loi a iemote netwoik. As shown in the lollowing output,
10.20.20.122 is the only auuiess on the inteilace, anu as such, it contains Loth a piimaiy
anu a pieleiieu llag:
root@Lager# run show interfaces ge-2/0/1.100
Logical interface ge-2/0/1.100 (Index 67) (SNMP ifIndex 45)
Flags: SNMP-Traps 0x4000 VLAN-Tag [0x8100.100] Encapsulation: ENET2
Input packets : 2215
Output packets: 23
Protocol inet, MTU: 1500
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.10.20.96/27, Local: 10.10.20.122,
Broadcast: 10.10.20.127
Interface Troubleshooting | 109
Now conliguie two auuitional IP auuiesses, 6.6.6.6 anu 6.6.6.+, on the inteilace anu
oLseive the iesults:
root@Lager# set address 6.6.6.4/24
root@Lager# set address 6.6.6.6/24
[edit interfaces ge-2/0/1 unit 100 family inet]
root@Lager# commit
commit complete
[edit interfaces ge-2/0/1 unit 100 family inet]
root@Lager# run show interfaces ge-2/0/1.100 | find protocol
Protocol inet, MTU: 1500
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 6.6.6/24, Local: 6.6.6.4, Broadcast: 6.6.6.255
Addresses
Destination: 6.6.6/24, Local: 6.6.6.6, Broadcast: 6.6.6.255
Addresses, Flags: Is-Preferred
Destination: 10.10.20.96/27, Local: 10.10.20.122,
Broadcast: 10.10.20.127
The piimaiy auuiess has changeu to 6.6.6.+, anu now two auuiesses contain the pie-
leiieu llag: auuiesses 6.6.6.6 anu 10.10.20.122. The pieleiieu auuiess is useu as the
souice IP auuiess il you`ie tiying to ieach a netwoik that is locally attacheu. In this
case, il tiallic is uestineu loi 172.16.1.2, the souice IP auuiess ol 6.6.6.+ is useu, Lut il
the uestination auuiess is 10.10.20.121, the souice IP auuiess ol 10.10.20.122 will Le
useu. ]unos Ly uelault will choose the piimaiy anu pieleiieu auuiesses Laseu on the
lowest IP auuiess that is conliguieu. The piimaiy auuiess will Le the lowei IP auuiess
conliguieu on the inteilace, anu the pieleiieu auuiess will Le the lowest IP auuiess
conliguieu loi each local suLnet. In the eailiei example, tiallic uestineu to a host on
the 6.6.6/2+ suLnet is souiceu liom 6.6.6.+. You can mouily these uelaults Ly conlig-
uiing the appiopiiate llag (piimaiy oi pieleiieu) to the auuiess ol choice:
[edit interfaces ge-2/0/1 unit 100 family inet]
root@Lager# set address 10.10.20.122/27 primary
[edit interfaces ge-2/0/1 unit 100 family inet]
root@Lager# commit
commit complete
The 10.10.20.122 auuiess has now Leen conliguieu loi the piimaiy auuiess ol the
inteilace, as inuicateu Ly the show interfaces commanu:
[edit interfaces ge-2/0/1 unit 100 family inet]
root@Lager# run show interfaces ge-2/0/1.100 | find protocol
Protocol inet, MTU: 1500
Flags: None
Addresses, Flags: Is-Preferred
Destination: 6.6.6/24, Local: 6.6.6.4, Broadcast: 6.6.6.255
Addresses
Destination: 6.6.6/24, Local: 6.6.6.6, Broadcast: 6.6.6.255
Addresses, Flags: Primary Is-Preferred Is-Primary
Destination: 10.10.20.96/27, Local: 10.10.20.122,
110 | Chapter 4:Interfaces
Broadcast: 10.10.20.127
[edit interfaces ge-2/0/1 unit 100 family inet]
root@Lager# set address 6.6.6.6/24 preferred
Encapsulation Mismatches
Foi two iouteis` inteilaces to communicate piopeily, the same Layei 2 encapsulation
must Le conliguieu on each uevice; uepenuing on the type ol encapsulation, this coulu
Le a uillicult eiioi to ueteimine. A common inteilace meuium wheie this coulu occui
is Etheinet. The inteilace on ioutei Lager is conliguieu to senu VLAN taggeu liames
on the 10.10.20/2+ suLnet; howevei, a ping to ioutei Hangover in that segment lails:
[edit interfaces ge-2/0/1 unit 100]
root@Lager# run ping 10.10.20.121
PING 10.10.20.121 (10.10.20.121): 56 data bytes
^C
--- 10.10.20.121 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
Looking at the statistics on Lager`s Etheinet inteilace, a numLei ol Layei 2 channel
eiiois aie iecoiueu:
root@Lager# run show interfaces ge-2/0/1 extensive
Physical interface: ge-2/0/1, Enabled, Physical link is Up
Interface index: 142, SNMP ifIndex: 37, Generation: 143
Link-level type: Ethernet, MTU: 1514, Link-mode: Full-duplex Speed: 1000mbps,
BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
Remote fault: Online
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
Link flags : None
CoS queues : 8 supported, 8 maximum usable queues
Hold-times : Up 0 ms, Down 0 ms
Current address: 00:12:1e:76:1e:29, Hardware address:
00:12:1e:76:1e:29
Last flapped : 2010-04-05 22:01:18 UTC (1w0d 10:11 ago)
Statistics last cleared: 2010-04-13 08:10:48 UTC (00:02:18 ago)
Traffic statistics:
Input bytes : 0 0 bps
Output bytes : 230 0 bps
Input packets: 0 0 pps
Output packets: 5 0 pps
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards:
0, L3 incompletes: 0, L2 channel errors: 42, L2 mismatch timeouts:
,0 FIFO errors: 0, Resource errors: 0
Output errors:
Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged
packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0,
Resource errors: 0
Egress queues: 8 supported, 8 in use
.....
Interface Troubleshooting | 111
To see whethei the Layei 2 channel eiiois aie cuiiently incieasing oi whethei they aie
oluei counteis that have not Leen cleaieu, the monitor interface ge-2/0/1 commanu
is issueu. The seconu column in the lollowing coue snippet shows the inteilace countei
statistics, anu the cuiient uelta column inuicates ieal-time statistics iecoiueu since is-
suing the monitor commanu. Layei 2 channel eiiois aie cuiiently incieasing, as the
cuiient uelta countei inuicates:
Lager Seconds: 14 Time: 08:13:54
Delay: 0/0/50
Interface: ge-2/0/1, Enabled, Link is Up
Encapsulation: Ethernet, Speed: 1000mbps
Traffic statistics: Current delta
Input bytes: 0 (0 bps) [0]
Output bytes: 230 (0 bps) [0]
Input packets: 0 (0 pps) [0]
Output packets: 5 (0 pps) [0]
Error statistics:
Input errors: 0 [0]
Input drops: 0 [0]
Input framing errors: 0 [0]
Policed discards: 0 [0]
L3 incompletes: 0 [0]
L2 channel errors: 105 [18]
L2 mismatch timeouts: 0 Carrier transit [0]
An auuitional monitor commanu is now useu to veiily that the ioutei is senuing out the
coiiect packets. The monitor traffic commanu is the ioutei`s tcpuump
'
utility that
allows local ioutei tiallic to Le oLseiveu on a paiticulai inteilace. Since Etheinet ie-
guiies the IP auuiess to MAC auuiess mapping Leloie senuing the FRAME, a seiies ol
ARP ieguests with an S02.1Q (VLAN) heauei aie sent out to the inteilace with no
iesponse ieceiveu. The layer2-header switch is useu to oLtain some Etheinet heauei
inloimation as the monitor commanu is usually Layei 3 anu Layei + only:
[edit interfaces ge-2/0/1 unit 100]
root@Lager# run monitor traffic interface ge-2/0/1 layer2-headers
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ge-2/0/1, capture size 96 bytes.
....
08:18:09.764757 Out 0:12:1e:76:1e:29 > Broadcast, ethertype 802.1Q (0x8100), length
46: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.121 tell 10.10.20.122
08:18:10.564781 Out 0:12:1e:76:1e:29 > Broadcast, ethertype 802.1Q (0x8100), length
46: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.121 tell 10.10.20.122
08:18:12.214889 Out 0:12:1e:76:1e:29 > Broadcast, ethertype 802.1Q (0x8100), length
46: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.121 tell 10.10.20.122
08:18:12.814634 Out 0:12:1e:76:1e:29 > Broadcast, ethertype 802.1Q (0x8100), length
46: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.121 tell 10.10.20.122
' tcpuump is a common ueLugging tool that allows the usei to inteicept anu uisplay IP packets Leing
tiansmitteu oi ieceiveu ovei a netwoik inteilace.
112 | Chapter 4:Interfaces
08:18:13.414648 Out 0:12:1e:76:1e:29 > Broadcast, ethertype 802.1Q (0x8100), length
46: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.121 tell 10.10.20.122
08:18:14.314858 Out 0:12:1e:76:1e:29 > Broadcast, ethertype 802.1Q (0x8100), length
46: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.121 tell 10.10.20.122
^C
7 packets received by filter
0 packets dropped by kernel
[edit interfaces ge-2/0/1 unit 100]
root@Lager#
Routei Hangover is then accesseu anu a ping commanu towaiu Lager is issueu. The
monitor traffic commanu is issueu at Hangover with similai output, except loi a single
impoitant uilleience. Vhile ioutei Lager is senuing out the ARP packets with an
S02.1Q heauei (0 S100), ioutei Hangover appeais to Le senuing a non-VLAN-taggeu
Etheinet liame (0 0S06), which is the cause ol the Layei 2 channel eiiois that weie
pieviously uiscoveieu:
doug@hangover> monitor traffic interface ge-2/0/0 layer2-headers
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Listening on ge-2/0/0, capture size 96 bytes
....
08:20:32.901733 Out 0:12:1e:75:fa:28 > Broadcast, ethertype ARP (0x0806), length 42:
arp who-has 10.10.20.122 tell 10.10.20.121
08:20:33.801530 Out 0:12:1e:75:fa:28 > Broadcast, ethertype ARP (0x0806), length 42:
arp who-has 10.10.20.122 tell 10.10.20.121
08:20:34.601659 Out 0:12:1e:75:fa:28 > Broadcast, ethertype ARP (0x0806), length 42:
arp who-has 10.10.20.122 tell 10.10.20.121
08:20:35.301622 Out 0:12:1e:75:fa:28 > Broadcast, ethertype ARP (0x0806), length 42:
arp who-has 10.10.20.122 tell 10.10.20.121
08:20:36.001475 Out 0:12:1e:75:fa:28 > Broadcast, ethertype ARP (0x0806), length 42:
arp who-has 10.10.20.122 tell 10.10.20.121
08:20:36.941611 Out 0:12:1e:75:fa:28 > Broadcast, ethertype ARP (0x0806), length 42:
arp who-has 10.10.20.122 tell 10.10.20.121
^C
7 packets received by filter
0 packets dropped by kernel
Altei coiiecting the conliguiation eiioi on Hangover to allow loi VLAN encapsulation
with the coiiect VLAN ID, the ping succeeus anu is veiilieu:
root@Lager# run monitor traffic interface ge-2/0/1 layer2-headers
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Listening on ge-2/0/1, capture size 96 bytes
...
08:20:55.076174 In 0:12:1e:75:fa:28 > Broadcast, ethertype 802.1Q (0x8100), length
60: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.122 tell 10.10.20.121
08:20:55.076308 Out 0:12:1e:76:1e:29 > 0:12:1e:75:fa:28, ethertype 802.1Q (0x8100),
length 46: vlan 100, p 0, ethertype ARP, arp reply 10.10.20.122 is-at 0:12:1e:76:1e:
29
Interface Troubleshooting | 113
08:20:55.096237 In PFE proto 2 (ipv4): 10.10.20.121 > 10.10.20.122: ICMP echo
request seq 0, length 64
08:20:55.096272 Out 0:12:1e:76:1e:29 > 0:12:1e:75:fa:28, ethertype 802.1Q (0x8100),
length 102: vlan 100, p 0, ethertype IPv4, 10.10.20.122 > 10.10.20.121: ICMP echo
reply seq 0, length 64
Path MTU Issues
Vhen an IP packet is tiansiting a netwoik, it is olten liagmenteu so that it can tiansveise
inteilaces with vaiying sizes ol MTUs. Howevei, some applications uo not allow this
liagmentation, so you must ensuie that the ingiess MTU is not laigei than a tiansit
MTU loi those applications. One simple tool you can use to test whethei the piopei
MTU is assigneu is the pac|ct intcrnct gropcr (ping) commanu. Connectivity to a iemote
system is conliimeu on ioutei Lager Ly issuing a ping commanu to an auuiess ol
172.17.20.2:
root@Lager> ping 172.17.20.2
PING 172.17.20.2 (172.17.20.2): 56 data bytes
64 bytes from 172.17.20.2: icmp_seq=0 ttl=62 time=7.133 ms
64 bytes from 172.17.20.2: icmp_seq=1 ttl=62 time=10.375 ms
^C
--- 172.17.20.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 7.133/8.754/10.375/1.621 ms
Issue the traceroute commanu to check the path these packets take to ieach the ues-
tination. Routei Lager appeais to Le locateu two IP systems away liom the uestination
ol 172.17.20.2:
root@Lager> traceroute 172.17.20.2
traceroute to 172.17.20.2 (172.17.20.2), 30 hops max, 40 byte packets
1 10.10.20.121 (10.10.20.121) 18.572 ms 12.953 ms 35.782 ms
2 172.17.20.2 (172.17.20.2) 9.804 ms 9.497 ms 10.003 ms
The application that is Leing testeu ieguiies an MTU ol 1,50S Lytes, so a ping ol size
1,500 is sent with S Lytes ol oveiheau to the iemote station:
root@Lager> ping 172.17.20.2 size 1500 count 3
PING 172.17.20.2 (172.17.20.2): 1500 data bytes
1508 bytes from 172.17.20.2: icmp_seq=0 ttl=63 time=11.591 ms
1508 bytes from 172.17.20.2: icmp_seq=1 ttl=63 time=10.580 ms
1508 bytes from 172.17.20.2: icmp_seq=2 ttl=63 time=20.939 ms
--- 172.17.20.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 10.580/14.370/20.939/4.663 ms
The ping succeeus, anu at liist glance, all appeais well, Lut let`s not count oui chickens
Leloie they hatch! Some examination into the opeiation ol the ping commanu is neeueu
Leloie giving the gieen light ol appioval. By uelault, the ping packet will Le sent out
with the do-not-fragment Lit cleaieu in the IP heauei. This means that although the
ping packet will exit the ioutei with a size ol 1,50S Lytes, it coulu Le liagmenteu along
114 | Chapter 4:Interfaces
the way. So, now issue the ping commanu with the do-not-fragment llag set anu oLseive
the iesults:
root@Lager> ping 172.17.20.2 size 1500 count 3 do-not-fragment
PING 172.17.20.2 (172.17.20.2): 1200 data bytes
36 bytes from 10.10.20.121: frag needed and DF set (MTU 1119)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 04cc af90 2 0000 40 01 a809 10.10.20.122 172.17.20.2
36 bytes from 10.10.20.121: frag needed and DF set (MTU 1119)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 04cc af91 2 0000 40 01 a808 10.10.20.122 172.17.20.2
^C
--- 172.17.20.2 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
It appeais that the inteimeuiate station cannot hanule a packet laigei than 1,119 Lytes
on its outgoing inteilace towaiu the uestination, as oLseiveu Ly the ICMP message that
is ietuineu. Luckily, we lounu this out Leloie the application was ueployeu, so we weie
aLle to coiiect this pioLlem!
Il the outgoing inteilace on an inteimeuiate system uiu not contain the
piopei MTU size, an ICMP eiioi message will Le geneiateu. Il the in-
coning inteilace was conliguieu with a smallei-than-neeueu MTU, the
oLseivation will Le uilleient. Since the packet is uioppeu at input, no
ICMP MTU message will Le ieceiveu. Insteau, oveisize liame eiiois
woulu inciease on the inteimeuiate system`s input inteilace.
Looped Interfaces
Cieating a physical loop on an inteilace has Leen a tiouLleshooting tool loi many yeais.
Since the physical path ol a leaseu line lieguently consists ol multiple segments, olten
a pioLlem can Le localizeu Ly testing the ciicuit segment Ly segment. The iuea is to
cieate a loop at the enupoint ol the ciicuit anu senu a seiies ol tests towaiu that enupoint
that can ueteimine whethei packets aie lost oi coiiupteu uuiing tiansmission. Two
types ol loops aie suppoiteu on most types ol inteilaces: a iemote loop anu a local loop.
A |oca| |oop cieates a loop towaiu the ioutei, wheieas a rcnotc |oop is a line loop that
is cieateu towaiu the uownstieam netwoik uevice (see Figuie +-17).
Interface Troubleshooting | 115
Iigurc 1-17. Loopbac| typcs
Olten, the local LEC will go thiough a seiies ol tests uuiing the piovisioning piocess
to ensuie that the ciicuit integiity incluues loopLack testing. The ciicuit may also Le
lelt in the loopeu state to avoiu any local alaim geneiation. To see whethei a loop is
still in place, issue a ping towaiu the iemote enu ol the ciicuit. Il the iemote enu is
loopeu (iemote), the ping packets will continue until the Time to Live (TTL) expiies,
iesulting in ICMP TTL expiiation messages:
[edit]
doug@PBR# run ping 10.200.8.10
PING 10.200.8.10 (10.200.8.10): 56 data bytes
36 bytes from 10.200.8.9: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 30e2 0 0000 01 01 6325 10.200.8.9 10.200.8.10
36 bytes from 10.200.8.9: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 30e3 0 0000 01 01 6324 10.200.8.9 10.200.8.10
36 bytes from 10.200.8.9: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 30e6 0 0000 01 01 6321 10.200.8.9 10.200.8.10
^C
--- 10.200.8.10 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
On the iemote uevice, a loop will Le inuicateu (iemote oi local) Ly examining the
loopback llag in the show interfaces commanu:
dougl@closing_time# run show interfaces t1-2/0/2
Physical interface: t1-2/0/2, Enabled, Physical link is Up
Interface index: 139, SNMP ifIndex: 37
Link-level type: Cisco-HDLC, MTU: 1504, Clocking: Internal, Speed: T1,
Loopback: Remote, FCS: 16, Framing: ESF
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps 16384
Link flags : No-Keepalives
CoS queues : 8 supported
Last flapped : 2007-04-17 16:55:37 UTC (00:02:01 ago)
Input rate : 200 bps (0 pps)
Output rate : 224 bps (0 pps)
116 | Chapter 4:Interfaces
DS1 alarms : None
DS1 defects : None
Conclusion
An inteilace is the lunuamental Luiluing Llock ol any ioutei with a laige vaiiety ol
possiLle inteilace types. Although the ]unos OS allows loi many uilleient inteilace
types, the geneial conliguiation piocess is consistent acioss each type. This also helps
when it is time to tiouLleshoot the pioLlem inteilace. The specilics ol the meuia signals
will vaiy, Lut the opeiational commanus useu aie the same. Once a ioutei has all its
inteilaces, opeiational ioutes to iemote netwoiks can Le conliguieu via iouting pio-
tocols. Ve will examine these piotocols in suLseguent chapteis.
Exam Topics
Ve examineu the lollowing Enteipiise Exam Topics in this chaptei:
Iuentily valiu options loi inteilace names, logical units, anu piotocol lamilies
within the ]unos OS.
DesciiLe how to monitoi inteilaces in ieal time.
DesciiLe the inloimation containeu within the show interfaces extensive
commanu.
DesciiLe the uses ol netwoik utilities such as ping anu tiaceioute.
Conliguie MLPPP.
Conliguie IPv+ auuiessing.
Implement Fiame Relay.
Cieate VLAN-taggeu inteilaces.
Pioviue ieuunuancy anu high availaLility with VRRP.
Conliguie link Lunuling anu aggiegateu inteilaces.
EstaLlish point-to-point oi point-to-multipoint links with a vaiiety ol Layei 2
encapsulations.
Chapter Review Questions
1. On a ]-seiies ioutei inteilace, what aie the possiLle values loi the PIC slot numLei?
A. 1
B. 0
C. VaiiaLle, uepenuing on the physical location ol the inteilace
D. A iange ol 0+
Chapter Review Questions | 117
2. Vhich two inteilaces aie consiueieu peimanent inteilaces on a ]unipei Netwoiks
ioutei? (Choose two.)
A. lo0
B. ge-0/1/0
C. fxp3
D. fxp0
E. loopback0
3. On a point-to-point inteilace, which logical unit(s) can Le assigneu to an inteilace?
A. None
B. +095
C. 100
D. 0
+. Vhich inteilace name inuicates that it is a seiial inteilace in a ]-seiies ioutei that
is locateu in PIM slot 1 anu poit numLei 1?
A. se-1/1
B. se-1/0/1
C. serial1/1
D. se-0/1/1
5. Vhich ]unos commanu allows loi ieal-time uisplay ol inteilace statistics?
A. monitor interface
B. show interface statistics
C. monitor traffic
D. monitor statistics
6. Tiue oi False: An inteilace must Le auministiatively enaLleu Leloie it is opeia-
tionally in the up status.
7. Vhat is the uelault Layei 2 encapsulation loi a seiial inteilace?
A. SDLC
B. HDLC
C. X.121
D. PPP
S. Vhat is the maximum numLei ol inteilaces that can Le auueu to an MLPPP Lunule?
A. S
B. 6
C. 16
D. +
118 | Chapter 4:Interfaces
9. Vhat is the uelault clocking moue on a seiial inteilace?
A. DCE
B. Inteinal
C. Loop
D. DTE
10. Vhich CLI commanu woulu auministiatively uisaLle the ge-0/0/0 inteilace?
A. no shutdown
B. set interface ge-0/0/0 disable
C. deactivate interface ge-0/0/0
D. disable interface ge-0/0/0
11. Tiue oi False: All ]unipei Netwoiks iouteis contain an fxp0 OoB management
inteilace.
12. Vhich type ol inteilace woulu Le useu to cieate a GRE tunnel?
A. gre
B. tunnel.0
C. gr
D. ip.0
Chapter Review Answers
1. Answei: B. ]-seiies iouteis uo not contain PICs, so this value in the inteilace name
is always set to zeio anu is sometimes ieleiieu to as the viitual PIC value.
2. Answei: A, D. ge-0/1/0 is a tiansient inteilace, wheieas fxp3 anu loopback0 aie
invaliu meuia types.
3. Answei: D. A point-to-point inteilace has only one valiu logical unit numLei, which
is unit 0.
+. Answei B. Eveiy tiansient inteilace always takes the loim ol MM-F/P/T, with F
inuicating the PIM slot anu T iepiesenting the poit numLei.
5. Answei: A. The monitor statistics commanu is an invaliu commanu, wheieas
monitor traffic uisplays local TCP/IP tiallic anu show interfaces uoes not uisplay
inloimation uynamically.
6. Answei: False. ]unipei inteilaces aie always auministiatively enaLleu when
installeu.
7. Answei: D. The uelault encapsulation is PPP on all point-to-point inteilaces.
S. Answei: A. As ol ]unos veision S.3, eight inteilaces aie alloweu in a single Lunule.
Chapter Review Answers | 119
9. Answei: C. A seiial inteilace always attempts to oLtain its tiansmit timing liom
the line itsell, using what is calleu |oop tining. Othei valiu options that can Le
conliguieu incluue internal anu dce. DTE is not a conliguiaLle option.
10. Answei: B. The only othei valiu ]unos commanu listeu in the answei choices is the
deactivate commanu. This commanu comments out the conliguiation that the
iunning system will ignoie.
11. Answei: False. Only M/T-seiies iouteis contain an fxp0 OoB management intei-
lace. ]-seiies iouteis must Le manageu via console, auxiliaiy poits, oi iegulai PFE
inteilaces.
12. Answei: C. The soltwaie pseuuointeilace that is useu to cieate GRE tunnels is the
gr inteilace. The gre inteilace is useu inteinally Ly the ioutei anu shoulu not Le
conliguieu. The ip.0 anu tunnel.0 inteilaces aie not valiu inteilace types.
120 | Chapter 4:Interfaces
CHAPTER 5
Protocol Independent Properties
and Routing Policy
This chaptei is uiviueu into two main sections. The liist section uetails iouting capa-
Lilities anu leatuies that aie not specilic to any paiticulai iouting piotocol, hence the
phiase protoco| indcpcndcnt. Although teimeu indcpcndcnt, these leatuies olten inteiact
with one oi moie iouting piotocols, anu in some cases may Le ieguiieu loi piopei
piotocol opeiation! The seconu hall ol the chaptei investigates ]unos soltwaie iouting
policy. Routing policy pioviues a toolLox that lacilitates the contiol ol ioute uistiiLu-
tion, incluuing ioute lilteiing anu ioute attiiLute manipulation.
In many cases, you comLine the lunctions ol Piotocol Inuepenuent Piopeities (PIPs)
anu iouting policy to achieve some goal. Foi example, a static ioute is uelineu using
PIP, Lut this same static ioute can then Le ieuistiiLuteu, peihaps with a mouilieu at-
tiiLute such as a ioute tag oi Boiuei Gateway Piotocol (BGP) community, as a iesult
ol iouting policy.
This chaptei exposes the ieauei to PIP anu iouting policy in a mannei that is analogous
to a mechanic Leing intiouuceu to each tool compiising a complete toolLox. To con-
tinue the analogy, the ways in which tools can Le useu, eithei alone oi in comLinations,
aie viitually limitless. Foi example, youi hammei can Le useu as pait ol the iepaii ol a
hole in a Loat`s hull, oi it can Le useu to make the hole, peihaps in an elloit to scuttle
the cialt. Although the Loat may have some opinion, it`s sale to say that the toolthe
hammei, in this caseis just happy to Le useu, with no ieal concein as to the natuie
ol the task.
The iouting anu seivice examples coveieu in suLseguent chapteis ol this Look all make
use ol the PIP anu policy tools to solve some ieguiiement specilic to the example Leing
uiscusseu in that chaptei. Since piactical PIP anu policy-ielateu applications aie pio-
viueu thioughout the iemainuei ol this Look, the goal ol this chaptei is to expose the
ieauei to the geneial capaLilities anu conliguiation ol PIP anu policy so that suLseguent
case stuuy examples aie lully unueistoou.
121
The PIP topics incluue:
Static, aggiegateu, anu geneiateu ioutes
GloLal pieleience
Maitian ioutes
Route taLles anu iouting inloimation Lase (RIB) gioups
Autonomous system (AS) numLei anu ioutei ID
Routing policy topics incluue:
Policy oveiview, impoit anu expoit policy
Policy components (teims, match conuitions, actions, policy chains)
Route lilteis
Auvanceu policy concepts
Protocol Independent Properties
PIPs aie useu loi a vaiiety ol lunctions, such as static anu aggiegate ioutes, piotocol
pieleiences, ioute taLles, ioutei ID, anu so loith. The iange ol PIPs is conliguieu at the
[edit routing-options] hieiaichy.
Static, Aggregate, and Generated Routes
Although the use ol static iouting is sometimes consiueieu Lau loim, especially uuiing
a iouting-piotocol-Laseu piactical examination, theie aie many piactical applications
loi static ioutes, along with theii aggiegate/geneiateu counteipaits.
Static iouting sulleis liom a geneial lack ol uynamism (though Biuiiectional Foiwaiu-
ing Detection BFD can mitigate this issue), which olten leaus to loss ol connectivity
uuiing netwoik outages uue to the inaLility to ieioute. Static ioutes can guickly Lecome
maintenance anu auministiation Luiuens loi netwoiks that have lieguent auus, moves,
oi changes. Vith that saiu, static iouting is olten useu at the netwoik euge to suppoit
attachment to stuL netwoiks, which, given theii single point ol entiy/egiess, aie well
suiteu to the simplicity ol a static ioute.
Static ioutes aie olten useu to piomote staLility thiough auveitisement into a iouting
piotocol, such as BGP, wheie a single ioute that is always up is useu to iepiesent the
connectivity ol numeious, moie specilic ioutes, which inuiviuually may come anu go
(llap) Lecause ol instaLility in the attacheu netwoik`s inliastiuctuie. By suppiessing
the specilics in lavoi ol a single static ioute, the woilu is shielueu liom the uay-to-uay
llapping while oveiall connectivity is pieseiveu.
Static, aggiegate, anu geneiateu ioutes aie similai in that all aie uelineu statically, anu
all can have mask lengths that iepiesent supcr-ncts (aggiegateu netwoik pielixes) oi
subncts (extenuing the netwoik ID into the host lielu ol a classlul auuiess to gain moie
122 | Chapter 5:Protocol Independent Properties and Routing Policy
netwoiks, each with lewei hosts). As such, theie is olten conlusion aLout the uillei-
ences, anu why all thiee types ol static iouting aie neeueu. TaLle 5-1 summaiizes how
these ioute types uillei.
Tab|c 5-1. Static, aggrcgatc, and gcncratcd routc conparison
Route type Next hop type Comment
Static Discard, reject, IP/interface next hop,
label-switched path (LSP) next hop
Global preference of 5; can be used for forwarding. Supports qualified
and indirect next hops. Activated by valid next hop.
Aggregate Reject (default), discard Global preference of 130; not used for forwarding, activated by contri-
buting route. Default reject for matching traffic.
Generated Preferred contributor (default) or
discard
Global preference of 130; default forwarding next hop based on preferred
contributor. Activated by a contributing route.
Next hop types
Static anu aggiegate ioutes suppoit vaiious next hop types, some ol which pioviue
loiwaiuing anu otheis which uo not. Unueistanuing the uilleiences Letween one next
hop type anu anothei is ciitical to achieving uesiieu goals. Heie aie the specilics loi
each type ol next hop:
Discard
A uiscaiu next hop iesults in the silent uiscaiu ol matching tiallic. Si|cnt heie ieleis
to the lact that no Inteinet Contiol Message Piotocol (ICMP) eiioi message is
geneiateu Lack to the souice ol the packet. You noimally choose a uiscaiu next
hop when the goal is to auveitise a single aggiegate that iepiesents a gioup ol
pielixes, with the expectation that any tiallic attiacteu Ly the aggiegate ioute will
longest-match against one ol the moie specilic ioutes, anu theieloie Le loiwaiueu
accoiuing to the ielateu next hop iathei than the ieject oi uiscaiu next hop ol the
aggiegate ioute itsell.
The use ol uiscaiu is Lest cuiient piactice when auveitising an aggiegate Lecause
the geneiation ol ICMP eiioi messages can consume system iesouices anu may
enu up LomLaiuing an innocent thiiu paity, as in the case ol spooleu souice au-
uiessing as pait ol a uistiiLuteu uenial ol seivice (DDoS) attack.
Rcjcct
A ieject next hop iesults in the geneiation ol an ICMP eiioi message iepoiting an
unieachaLle uestination loi matching tiallic. This is the uelault next hop type ol
an active aggiegateu ioute. Vhen a geneiateu ioute is kept active in the ioute taLle
Ly means ol the passive commanu iathei than a contiiLuting ioute, the entiy is
maikeu Ly uelault with a ieject next hop.
Iorwarding
A loiwaiuing next hop is useu to move tiallic to a uownstieam noue, anu it is
typically specilieu as the IP auuiess ol a uiiectly connecteu uevice. Matching tiallic
is then loiwaiueu to the specilieu next hop. On a multiaccess netwoik such as a
Protocol Independent Properties | 123
LAN, this involves the iesolution ol the IP auuiess to a link layei auuiess thiough
the Auuiess Resolution Piotocol (ARP) oi some loim ol static mapping. Vhen
uiiecting tiallic ovei a point-to-point inteilace, the next hop can Le specilieu as an
inteilace name; howevei, LAN inteilace types ieguiie an IP auuiess next hop Le-
cause ol theii multipoint natuie.
Vhen uelining a static ioute with a loiwaiuing next hop,
you can use gualilieis that inlluence how the next hop is iesolveu anu hanuleu.
Specilically:
resolve
The resolve keywoiu allows you to ueline an inuiiect next hop loi a static ioute,
which is to say an IP loiwaiuing auuiess that uoes not iesolve to a uiiectly con-
necteu inteilace ioute. Foi example, you coulu specily a static ioute that points to
a uownstieam neighLoi`s loopLack auuiess. In this case, matching tiallic will iesult
in a iecuisive lookup against the specilieu (lo0) next hop to select a uiiectly con-
necteu loiwaiuing next hop. Il a paiallel connection exists, the lailuie ol the cui-
iently useu link iesults in a new iecuisive lookup anu selection ol the iemaining
link loi packet loiwaiuing.
qualified-next-hop
The qualified-next-hop keywoiu allows you to ueline a single static ioute with a
list ol next hops that aie inuiviuually gualilieu with a pieleience. In opeiation, the
most pieleiieu gualilieu next hop that is opeiational is useu. An opeiational next
hop is one that can Le iesolveu anu is associateu with an up inteilace. Vhen that
next hop is no longei usaLle, the next-Lest-gualilieu next hop is selecteu. That is
to say, when the piimaiy link is uown, the ioutei selects the next pieleiieu next
hop, which may point to a low-speeu Lackup lacility.
retain
The retain keywoiu allows you to ueline a static ioute that iemains in the loi-
waiuing taLle, iegaiuless ol the state ol the ioute. The retain llag shoulu Le useu
with caution Lecause tiallic uestineu loi this next hop is lost il the next hop is not
ieachaLle. This lunction is similai to the passive keywoiu useu with geneiateu
ioutes.
Static versus aggregate routes
Simply iealizing that an aggiegate/geneiateu ioute suppoits a suLset ol the next hop
options suppoiteu Ly a simple static ioute uoes not ieally explain the ieal opeiational
moue uilleiences Letween these ioute types. A static ioute is active whenevei it has a
viaLle next hop. This next hop can take the loim ol uiscaiu/ieject, which ellectively
nails the ioute up.
In contiast, Loth aggiegate anu geneiateu ioutes ie-
guiie at least one contributing ioute to Lecome active. A contiiLuting ioute is simply a
moie specilic ioute that is leaineu thiough some othei mechanism, such as static
Forwarding next hop qualifiers.
Aggregates need contributing routes.
124 | Chapter 5:Protocol Independent Properties and Routing Policy
uelinition oi uynamic leaining thiough a piotocol such as Open Shoitest Path Fiist
(OSPF). A ioute is moie specilic anu is theieloie aLle to contiiLute to an aggiegate
ioute (when it has a mask length longei than the associateu aggiegate) while shaiing
the same pielix as the aggiegate (as inuicateu Ly the aggiegate ioute`s mask length).
Foi example, the aggiegate ioute 10.1/16 can Le activateu Ly ioute 10.1.1/2+ Lecause
it has a longei (moie specilic) mask anu shaies the same 16 high-oiuei pielix Lits as
the aggiegate ioute. In contiast, the ioute 10.2.2/2+ uoes not contiiLute to a 10.1/16
aggiegate, as it uoes not shaie the same aggiegate pielix.
You can use iouting policy to liltei the set ol ioutes that aie alloweu to contiiLute to
an aggiegate, which helps you contiol when the coiiesponuing aggiegate Lecomes ac-
tive. Because only active ioutes aie suLject to iouting policy, this in tuin can inlluence
when a given aggiegate is auveitiseu in a iouting piotocol. Foi example, you can liltei
all othei contiiLutois so as to auveitise an aggiegate loi 10.1/16 into BGP Laseu stiictly
on the aLsence oi piesence ol a 10.1.1.0/30 ioute. By uelault, the pieleiieu oi piimaiy
contiiLuting ioute is selecteu liom the pool ol viaLle canuiuates Laseu on gloLal piel-
eience. To Lieak pieleience ties, the numeiically smallest contiiLuting ioute is
pieleiieu.
A given ioute can contiiLute only to a single aggiegate ioute. Howevei, an active ag-
giegate ioute can iecuisively contiiLute to a less specilic matching aggiegate ioute. Foi
example, an aggiegate ioute to the uestination 10.1.0.0/16 can contiiLute to an aggie-
gate ioute to 10.0.0.0/S.
Aggregate versus generated routes
People olten get conluseu aLout aggiegate anu geneiateu ioutesLecause Loth ieguiie
contiiLutois to Lecome active anu Loth aie assigneu the same iouting pieleience ol
130. The key uilleience Letween the two types ol ioutes is that an aggiegate ioute is
ncvcr useu loi loiwaiuing. Although it may attiact plenty ol tiallic, the next hop ol an
aggiegate ioute is eithei a uiscaiu oi a iejectno ils, anus, oi Luts. In contiast, a gen-
eiateu ioute installs the next hop associateu with the pieleiieu contiiLutoi, anu theie-
loie can Le useu to loiwaiu matching tiallic. Foi this ieason, a geneiateu ioute is
sometimes calleu a ioute ol last iesoit. This is Lecause in the geneial case, tiallic typi-
cally matches a moie specilic ioute anu is iouteu appiopiiately, just as in the case ol
an aggiegate ioutewhen the most specilic (longest) match is against the geneiateu
ioute itsell, it is loiwaiueu to a gateway ol last iesoit, as iuentilieu Ly the next hop
associateu with the cuiiently pieleiieu contiiLutoi ioute.
These opeiational uilleiences aie shown via the commanu-line inteilace (CLI) at
Cider using a 10.10/16 aggiegate veisus a 10.10/16 geneiateu ioute:
[edit routing-options]
lab@Cider# show aggregate
route 10.10.0.0/16;
[edit routing-options]
lab@Cider# run show route protocol aggregate detail
Protocol Independent Properties | 125
inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
10.10.0.0/16 (1 entry, 1 announced)
*Aggregate Preference: 130
Next hop type: Reject
Next-hop reference count: 2
State: <Active Int Ext>
Age: 1:50
Task: Aggregate
Announcement bits (1): 0-KRT
AS path: I (LocalAgg)
Flags: Depth: 0 Active
AS path list:
AS path: I Refcount: 2
Contributing Routes (2):
10.10.11.0/24 proto Direct
10.10.12.1/32 proto Direct
A 10.10/16 aggiegate is activateu Ly the piesence ol uiiectly connecteu ioutes that
contiiLute to the aggiegate. Diiect ioutes loi multiaccess netwoiks cannot contiiLute
to a geneiateu ioute Lecause a loiwaiuing next hop cannot Le ueiiveu liom the meie
piesence ol the local inteilace, as is possiLle in the case ol a point-to-point link, wheie
the inteilace itsell can Le specilieu as a next hop.
Both the aggiegateu ioutes anu the geneiateu ioutes aie uisplayeu in the
ioute taLle with the show route protocol aggregate commanu.
To ieiteiate, a geneiateu ioute iemains hiuuen when only uiiect multiaccess ioutes aie
piesent to contiiLute:
[edit routing-options]
lab@Cider# show generate
route 10.10.0.0/16;
[edit routing-options]
lab@Cider# run show route protocol aggregate detail hidden
inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden)
10.10.0.0/16 (1 entry, 0 announced)
Aggregate
Next hop type: Reject
Next-hop reference count: 1
State: <Hidden Int Ext>
Age: 3:10
Task: Aggregate
AS path: I
Flags: Generate Depth: 0 Inactive
This is Lecause the next hop loi a geneiateu ioute is Laseu on the loiwaiuing next hop
ol the pieleiieu contiiLutoi, anu loi a multiaccess type ol netwoik, this ieguiies a static
126 | Chapter 5:Protocol Independent Properties and Routing Policy
oi leaineu ioute that iuentilies a next hop on one ol the uiiect inteilace ioutes. In this
example, a static ioute with a loiwaiuing next hop pointing out Cider`s ge-0/0/1.100
inteilace towaiu Bock is useu to activate the geneiateu ioute:
[edit routing-options]
lab@Cider# set static route 10.10.1/24 next-hop 10.10.11.1
[edit routing-options]
lab@Cider# commit
commit complete
[edit routing-options]
lab@Cider# run show route 10.10.1/24 detail
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
10.10.1.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next-hop type: Router, Next-hop index 500
Next-hop reference count: 5
Next hop: 10.10.11.1 via ge-0/0/1.100, selected
State: <Active Int Ext>
Age: 17
Task: RT
Announcement bits (2): 0-KRT 1-Aggregate
AS path: I
[edit routing-options]
lab@Cider# run show route protocol aggregate detail
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
10.10.0.0/16 (1 entry, 1 announced)
*Aggregate Preference: 130
Next-hop type: Router, Next-hop index 501
Next-hop reference count: 5
Next hop: 10.10.11.1 via ge-0/0/1.100, selected
State: <Active Int Ext>
Age: 11:34
Task: Aggregate
Announcement bits (1): 0-KRT
AS path: I
Flags: Generate Depth: 0 Active
Contributing Routes (1):
10.10.1.0/24 proto Static
Note that Loth the 10.10.1.0/2+ static ioute anu the iesultant geneiateu ioute shaie
the same loiwaiuing next hop. As the only viaLle contiiLuting ioute, the 10.10.1.0/2+
ioute is the pieleiieu contiiLutoi in this example.
Route attributes and flags
Vhen you ueline a static ioute, you can incluue vaiious ioute attiiLutes such as AS
path, BGP community, ioute tag, metiic, anu so loith. These attiiLutes may oi may
not come into play latei when the ioute is ieuistiiLuteu into a specilic iouting piotocol.
Protocol Independent Properties | 127
Foi example, OSPF has no notion ol a BGP community oi AS path, anu theieloie these
attiiLutes aie not injecteu into OSPF uespite Leing attacheu to the ioute. The ioute
attiiLutes can Le uelineu inuiviuually loi each ioute oi as pait ol a uelault template that
is inheiiteu Ly all ielateu ioutes, unless specilically oveiwiitten Ly a competing
attiiLute.
You can also attach llags to a static ioute that contiols vaiious aspects ol how the ioute
is hanuleu oi opeiates. Foi example, the no-advertise llag pievents the associateu ioute
liom Leing expoiteu into iouting piotocols, even when the policy conliguiation oth-
eiwise selects that ioute loi ieuistiiLution. You can uisplay the list ol availaLle ioute
attiiLutes anu llags with the CLI`s ? leatuie:
[edit routing-options]
lab@Cider# set static route 10/8 ?
Possible completions:
active Remove inactive route from forwarding table
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> as-path Autonomous system path
> bfd-liveness-detection Bidirectional Forwarding Detection (BFD) options
> color Color (preference) value
> color2 Color (preference) value 2
+ community BGP community identifier
discard Drop packets to destination; send no ICMP unreachables
install Install route into forwarding table
> lsp-next-hop LSP next hop
> metric Metric value
> metric2 Metric value 2
> metric3 Metric value 3
> metric4 Metric value 4
+ next-hop Next hop to destination
next-table Next hop to another table
no-install Don't install route into forwarding table
no-readvertise Don't mark route as eligible to be readvertised
no-resolve Don't allow resolution of indirectly connected next hops
no-retain Don't always keep route in forwarding table
> p2mp-lsp-next-hop Point-to-multipoint LSP next hop
passive Retain inactive route in forwarding table
> preference Preference value
> preference2 Preference value 2
> qualified-next-hop Next hop with qualifiers
readvertise Mark route as eligible to be readvertised
receive Install a receive route for the destination
reject Drop packets to destination; send ICMP unreachables
resolve Allow resolution of indirectly connected next hops
retain Always keep route in forwarding table
> tag Tag string
> tag2 Tag string 2
128 | Chapter 5:Protocol Independent Properties and Routing Policy
The ieauei is encouiageu to consult ]unos soltwaie uocumentation loi uetails on the
vaiious attiiLutes anu llags that can Le attacheu to static oi aggiegateu ioutes. The
commonly useu attiiLutes aie uemonstiateu eithei in this chaptei oi within the vaiious
scenaiios uemonstiateu thioughout this Look. Figuie 5-1 illustiates a typical applica-
tion ol a static ioute via a sample iouting topology.
Iigurc 5-1. Static routing conjiguration
Global Route Preference
Routing inloimation can Le leaineu liom multiple souices. In oiuei to Lieak ties among
egually specilic ioutes leaineu thiough multiple souices, each souice is assigneu a
gloLal pieleience. It can Le saiu that the gloLal pieleience ueteimines the oveiall Le-
lievaLility oi goouness ol a iouting souice. As such, ioutes that aie leaineu thiough
local auministiative actionloi example, static ioutesaie moie LelievaLle than the
same ioutes leaineu thiough a iouting piotocol such as OSPF. In Cisco IOS, this con-
cept is calleu adninistrativc distancc. TaLle 5-2 shows the uelault piotocol pieleiences
loi ]unos soltwaie.
Protocol Independent Properties | 129
Tab|c 5-2. G|oba| protoco| prcjcrcncc va|ucs
Source Purpose
Default
preference
Local Local IP address of the interface 0
Directly connected
network
Subnet corresponding to the directly connected interface 0
System
Static
Routes installed by Junos
Static routes
4
5
RSVP Routes learned from the Resource Reservation Protocol used in Multiprotocol Label
Switching (MPLS)
7
LDP Routes learned from the Label Distribution Protocol used in MPLS 9
OSPF internal route OSPF internal routes such as interfaces that are running OSPF 10
IS-IS Level 1 internal
route
Intermediate SystemtoIntermediate System Level 1 internal routes such as
interfaces that are running ISIS
15
IS-IS Level 2 internal
route
Intermediate SystemtoIntermediate System Level 2 internal routes such as
interfaces that are running ISIS
18
Redirects Routes from ICMP redirect 30
Kernel Routes learned via route socket from kernel 40
SNMP Routes installed by Network Management System through the Simple Network
Management Protocol
50
Router discovery Routes installed by ICMP Router Discovery 55
RIP Routes from Routing Information Protocol (IPv4) 100
RIPng Routes from Routing Information Protocol (IPv6) 100
PIM Routes from Protocol Independent Multicast 105
DVMRP Routes from Distance Vector Multicast 110
Aggregate Aggregate and generated routes 130
OSPF AS external routes Routes from Open Shortest Path First that have been redistributed into OSPF 150
IS-IS Level 1 external
route
Routes from Intermediate SystemtoIntermediate System Level 1 that have been
redistributed into ISIS
160
IS-IS Level 2 external
route
Routes from Intermediate SystemtoIntermediate System Level 2 that have been
redistributed into ISIS
165
BGP
MSDP
Routes from Border Gateway Protocol
Routes from Multicast Source Discovery Protocol
170
175
As with a ioute metiic, numeiically lowei pieleience values aie pieleiieu. You can altei
the uelault pieleience values when neeueu to accommouate some specilic goal, such
as ioute ieuistiiLution uuiing an Inteiioi Gateway Piotocol (IGP) migiation, which is
uemonstiateu in Chaptei 6.
130 | Chapter 5:Protocol Independent Properties and Routing Policy
Reaueis lamiliai with Cisco Systems may note a lew uilleiences Letween how the two
venuois assign uistance/pieleience. Foi example, Cisco has a sepaiate uistance loi In-
teinal BGP (IBGP) veisus Exteinal BGP (EBGP) (200 veisus 20), wheieas ]unipei uses
the same value. In this case, theie is no opeiational impact Lecause in the ioute selection
piocess ]unos soltwaie pieleis EBGP ovei IBGP, iesulting in the same Lehavioi loi Loth
venuois. One aiea wheie the venuois uillei is in iegaiu to IGP veisus EBGP uistance.
Heie, Cisco assigns an OSPF IGP uistance ol 110; since this is highei than the EBGP
uistance ol 20, it iesults in the selection ol an EBGP ioute ovei an eguivalent OSPF
ioute. In the same setup, a ]unipei ioutei chooses the OSPF ioute, owing to the piel-
eience values shown in TaLle 5-2.
Although you coulu altei ]unos soltwaie pieleience to mimic IOS Lehavioi, ]unipei
cieateu a compatiLility knoL loi this situation, calleu advertise-inactive. Vhen ap-
plieu to an EBGP peeiing session, this knoL iesults in the auveitisement ol the Lest
BGP ioute that happens to Le inactive Lecause ol IGP pieleience. Vhen using the
advertise-inactive option, the ]unos uevice continues to use the OSPF copy loi loi-
waiuing, anu the IOS uevice uses the EBGP copy to loiwaiu. Howevei, liom the pei-
spective ol an EBGP peei in a neighLoiing AS, Loth venuois appeai to Lehave the same.
Floating static routes
A lloating static ioute is nothing moie than a static ioute that has a mouilieu pieleience,
causing it to Le less pieleiieu than a uynamically leaineu copy. The uelaults cause a
static ioute to always Le pieleiieu ovei a uynamic ioute. A lloating static ioute is olten
useu to pioviue Lackup in the event ol a netwoik oi piotocol mallunction. Vhen all is
opeiating noimally, the static ioute iemains iule Lecause the uynamically leaineu iout-
ing is pieleiieu. Vhen iouting piotocol uisiuption iesults in the loss ol a leaineu ioute,
the pieviously inactive static ioute Lecomes active.
The lollowing coue sample cieates a lloating static ioute Ly assigning a mouilieu piel-
eience that makes the ioute |css pieleiieu than an OSPF inteinal ioute, which has a
uelault pieleience ol 10:
[edit routing-options static route 0.0.0.0/0]
lab@PBR# show
next-hop 172.16.1.1;
preference 11;
[edit routing-options static route 0.0.0.0/0]
lab@PBR# run show route 200.0.0.0
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/11] 00:00:06
> to 172.16.1.1 via ge-0/0/0.412
Protocol Independent Properties | 131
Martian Routes
]unos soltwaie suppoits the concept ol maitian ioutes, which is a euphemistic way to
uesciiLe a ioute that shoulu not Le piesent. Most netwoik opeiatois consiuei local use
auuiessing, as uelineu in RFC 191S, Auuiess Allocation loi Piivate Inteinets, as an
example ol maitian ioutes, at least when ieceiveu outsiue ol the context ol a viitual
piivate netwoik (VPN).
Routes containeu in the maitian taLle aie excluueu liom ioute upuate piocessing,
which pievents them liom evei Leing installeu into the ioute taLle. The maitian mech-
anism pioviues a consoliuateu way to liltei Logus iouting inloimation liom all piotocol
souices without the use ol explicit policy.
You can uisplay maitian entiies with a show route martians commanu. In this example,
only entiies loi the main inet.0 ioute taLle aie uisplayeu thiough the table keywoiu:
[edit routing-options]
lab@Bock# run show route martians table inet.0
inet.0:
0.0.0.0/0 exact -- allowed
0.0.0.0/8 orlonger -- disallowed
127.0.0.0/8 orlonger -- disallowed
128.0.0.0/16 orlonger -- disallowed
191.255.0.0/16 orlonger -- disallowed
192.0.0.0/24 orlonger -- disallowed
223.255.255.0/24 orlonger -- disallowed
240.0.0.0/4 orlonger -- disallowed
The uelault entiies peimit piivate use ol RFC 191S piivate auuiessing space while
lilteiing pielixes that shoulu nevei appeai in a ioute upuateloi example, the
127.0.0.1 loopLack auuiess oi the IANA ieseiveu 192.0.0.0/2+ netwoik Llock. You
can auu entiies to the taLle, which can latei Le iemoveu using set anu delete, iespec-
tively. You cannot explicitly iemove pieuelineu maitian entiies, Lut you can auu new
entiies that negate theii ellect. Foi example, iathei than tiying to uelete the 0/0 exact
allow entiy, you negate its ellect Ly adding a new entiy with a competing action. Foi
instance, the uelault maitian taLle allows the uelault ioute, which in this example is
Leing auveitiseu via OSPF liom Bock to Cider:
[edit]
lab@Cider# run show route protocol ospf
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 00:00:07, metric 0, tag 0
> to 10.10.11.1 via ge-0/0/1.100
. . .
224.0.0.5/32 *[OSPF/10] 00:00:27, metric 1
MultiRecv
132 | Chapter 5:Protocol Independent Properties and Routing Policy
The maitian taLle loi the inet.0 ioute taLle is mouilieu with a set 0/0 exact deny
statement, which oveiiiues the pievious entiy loi the 0/0 exact ioute. Note that a
deny action is the uelault loi any entiy in the maitian taLle:
[edit routing-options martians]
lab@Cider# set 0/0 exact
[edit routing-options martians]
lab@Cider# show
0.0.0.0/0 exact;
Altei the change is committeu, the iesults aie conliimeu:
[edit routing-options martians]
lab@Cider# run show route martians table inet.0
inet.0:
0.0.0.0/0 exact -- disallowed
0.0.0.0/8 orlonger -- disallowed
127.0.0.0/8 orlonger -- disallowed
128.0.0.0/16 orlonger -- disallowed
191.255.0.0/16 orlonger -- disallowed
192.0.0.0/24 orlonger -- disallowed
223.255.255.0/24 orlonger -- disallowed
240.0.0.0/4 orlonger -- disallowed
[edit routing-options martians]
lab@Cider# run show route protocol ospf | match 0.0.0.0
The lack ol an OSPF-leaineu uelault ioute at Cider conliims the mouilieu maitian taLle
iesults in ignoiing iouting inloimation loi the 0/0 ioute.
Routing Tables and RIB Groups
All ]unos-Laseu iouteis maintain a numLei ol ioute taLles that aie useu loi specilic
puiposes. In auuition to the automatically cieateu taLles, you can cieate youi own ioute
taLles, eithei inuiiectly thiough the use ol viitual iouteis oi Layei 2/Layei 3 VPNs anu
the ielateu Viitual Route anu Foiwaiuing (VRF) taLles, oi uiiectly thiough the use ol
RIB gioups.
Geneially speaking, each ioute taLle/RIB populates a uesignateu poition ol the loi-
waiuing taLle. This cieates a single loiwaiuing taLle that is paititioneu Laseu on a
specilic ioute taLle context. Packets aie loiwaiueu Laseu on this ioute taLle context,
which allows loi uistinct loiwaiuing Lehavioi on a pei-ioute-taLle Lasis. It`s a key
component ol any VPN type ol seivice, wheie pei-VRF (pei VPN site) ioute taLles aie
maintaineu along with a coiiesponuing VPN-specilic loiwaiuing taLle context.
You can view the contents ol a paiticulai ioute taLle using the commanu show route
table <table name>. The geneial naming convention loi ioute taLles takes the loim ol
the piotocol lamily such as inet (Inteinet) oi inet6, iso (ISO), oi mpls, lolloweu Ly a
peiiou anu a nonnegative integei. Routing instance taLle names aie somewhat the
Protocol Independent Properties | 133
D
o
exception heie, taking the loim ol instance-name.inet.0, wheie the liist pait consists
ol a usei-assigneu symLolic name, lolloweu Ly the piotocol lamily anu taLle ID, which
is inet.0 in this example.
Default route tables
The uelault ioute taLles cieateu Ly ]unos soltwaie incluue:
inet.0
The inet.0 taLle is the uelault unicast ioute taLle loi the IPv+ piotocol. This is the
main ioute taLle useu to stoie unicast ioutes such as inteilace local/uiiect, static,
oi uynamically leaineu ioutes.
inet.1
The inet.1 taLle seives as a multicast loiwaiuing cache. This taLle constiains the
vaiious IPv+ (S,G) gioup entiies that aie uynamically cieateu as a iesult ol join state.
inet.2
The inet.2 taLle houses unicast ioutes that aie useu loi multicast ieveise path
loiwaiuing (RPF) lookup, typically as leaineu thiough MP-BGP using SAFI 2. The
IPv+ unicast ioutes stoieu in this taLle can Le useu Ly multicast piotocols such as
the Distance Vectoi Multicast Routing Piotocol (DVMRP), which ieguiies a spe-
cilic RPF taLle. In contiast, PIM uoes not neeu an inet.2 Lecause it can peiloim
RPF checks against the inet.0 taLle. You can impoit ioutes liom inet.0 into
inet.2 using RIB gioups, oi install ioutes uiiectly into inet.2 liom a multicast
iouting piotocol.
inet.3
The inet.3 taLle contains MPLS LSP inloimation. This taLle contains the egiess
auuiess ol the MPLS LSP, along with the LSP name anu outgoing inteilace, anu is
populateu Ly Loth RSVP anu LSP. The inet.3 taLle is useu when the local ioutei
lunctions as the ingiess to an LSP.
instance_name.inet.0
Vhen you conliguie a VRF oi VR iouting instance, the iesultant instance cieates
a ioute taLle Laseu on the iouting instance`s name. Foi example, uelining a Layei 3
VPN instance calleu ce1 iesults in the cieation ol a ioute taLle nameu
ce1.inet.0. A iouting instance uilleis liom a logical ioutei in that vaiious iouting
instances shaie a single instance ol the iouting piotocol uaemon (ipu), wheieas
each LR gets its own instance ol ipu, which in tuin pioviues gieatei isolation. Note
that LRs aie not suppoiteu on ]-seiies platloims with the 10.3 ielease useu to wiite
this Look.
inet6.0
The inet6.0 taLle is useu to house IPv6 unicast ioute taLles.
134 | Chapter 5:Protocol Independent Properties and Routing Policy
bgp.l3vpn.0
The bgp.l3vpn.0 taLle contains ioutes leaineu liom othei Pioviuei Euge (PE) iout-
eis in a Layei 3 VPN enviionment via BGP. Routes in this taLle aie copieu into a
paiticulai Layei 3 VRF when theie is a matching ioute taLle.
bgp.l2vpn.0
The bgp.l2vpn.0 taLle contains ioutes leaineu liom othei PE iouteis in a Layei 2
VPN enviionment via BGP. The ielateu Layei 2 iouting inloimation is copieu into
Layei 2 VRFs Laseu on matching taiget communities.
mpls.0
The mpls.0 taLle houses the MPLS laLel-switching opeiations useu when the local
ioutei is acting as a tiansit laLel-switching ioutei (LSR) in suppoit ol LSPs.
iso.0
The iso.0 taLle houses IS-IS ioutes, which consist ol a netwoik entity title (NET)
anu a host ID. Vhen using IS-IS in suppoit ol IP iouting, you can expect to see
only the iouteis` NETs, which aie typically assigneu to the loopLack inteilace,
Lecause in this context the IS-IS piotocol is useu to convey IP, not IS-IS ioutes.
juniper_private
]unos soltwaie neeus to communicate inteinally with seivice Physical Inteilace
Caius (PICs). The juniper_private taLles aie cieateu as neeueu to lacilitate these
inteinal communications Letween the RE anu seivice PIC haiuwaie. These taLles
aie not seen Ly uelault in the show route commanu Lut can Le seen in the show
route forwarding table commanu.
Vhen you issue a show route commanu, all taLles aie listeu chionologically staiting
with inet.0. Vithin each taLle, you will also see the total numLei ol ioutes in the taLle
anu a listing luithei Lieaking uown active ioutes anu hiuuen ioutes. The lollowing
sample output liom a show route commanu uisplays many ol the taLles uesciiLeu eai-
liei, anu it is taken liom a ioutei conliguieu to suppoit a BGP-signaleu Layei 3 VPN
using RSVP-Laseu LSP tianspoit. The ioutei also has the inet6 anu iso lamilies enaLleu
on its loopLack inteilace.
The puipose ol the lollowing output uisplay is simply to show a ieal-woilu example in
which many ol the uelault ioute taLles aie populateu anu useu. The specilic uetails ol
which ioutes aie piesent oi how a given entiy in some paiticulai taLle is actually useu,
aie not the locus heie, hence a ielateu topology uiagiam is not neeueu loi the puipose
ol simply oLseiving the piesence ol multiple ioute taLles. SuLseguent chapteis in this
Look expanu on these specilics as neeueu in the context ol enteipiise iouting:
user@L3_VPN_router> show route
inet.0: 23 destinations, 23 routes (22 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
1.12.1.0/24 *[Direct/0] 00:33:41
> via ge-1/0/0.0
1.12.1.1/32 *[Local/0] 00:33:41
Local via ge-1/0/0.0
Protocol Independent Properties | 135
. . .
10.255.66.50/32 *[OSPF/10] 00:32:53, metric 1
> to 1.12.1.2 via ge-1/0/0.0
. . .
192.168.64.0/21 *[Direct/0] 5d 02:42:28
> via fxp0.0
192.168.66.47/32 *[Local/0] 5d 02:42:28
Local via fxp0.0
192.168.102.0/23 *[Static/5] 5d 02:42:28
> to 192.168.71.254 via fxp0.0
. . .
224.0.0.5/32 *[OSPF/10] 00:33:41, metric 1
MultiRecv
ce1.inet.0: 3 destinations, 3 routes (3 active, 0 holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.0/24 *[Direct/0] 00:33:41
> via ge-1/2/0.0
1.1.1.2/32 *[Local/0] 00:33:41
Local via ge-1/2/0.0
10.255.66.52/32 *[BGP/170] 00:33:24, localpref 100
AS path: I
> to 1.1.1.1 via ge-1/2/0.0
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
47.0005.80ff.f800.0000.0108.0001.0102.5506.6047/152
*[Direct/0] 5d 02:42:28
> via lo0.0
mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 00:33:41, metric 1
Receive
1 *[MPLS/0] 00:33:41, metric 1
Receive
2 *[MPLS/0] 00:33:41, metric 1
Receive
inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
abcd::10:255:66:47/128
*[Direct/0] 5d 02:42:28
> via lo0.0
fe80::2a0:a5ff:fe12:47ed/128
*[Direct/0] 5d 02:42:28
> via lo0.0
136 | Chapter 5:Protocol Independent Properties and Routing Policy
User-defined RIBs and RIB groups
You can ueline auuitional ioute taLles with the rib keywoiu. This capaLility is iaiely
useu, Lut it is uemonstiateu heie loi completeness. In the lollowing example, the usei
has conliguieu a custom IPv+ RIB calleu inet.69, in which a single static ioute hau Leen
uelineu:
[edit routing-options]
lab@PBR# show
rib inet.69 {
static {
route 10.1.0.0/16 discard;
}
}
The contents ol the usei-uelineu RIB aie uisplayeu with a show route table <table
name> commanu:
[edit routing-options]
lab@PBR# run show route table inet.69
inet.69: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.0.0/16 *[Static/5] 00:15:53
Discard
You can gioup togethei multiple ioute taLles (RIBs) to loim a routc tab|c group. Vithin
a gioup, a iouting piotocol can impoit ioutes into all the ioute taLles in the gioup, anu
it can expoit ioutes liom a single ioute taLle. Simply put, RIB gioups pioviue a way to
copy iouting inloimation liom one ioute taLle to anothei. In opeiation, a RIB gioup
consists ol one piimaiy anu one oi moie seconuaiy ioute taLlesthe liist ioute taLle
specilieu is the prinary ioute taLle, anu any auuitional ioute taLles lunction as sccon-
dary ioute taLles. The piimaiy ioute taLle ueteimines the auuiess lamily ol the ioute
taLle gioup. To conliguie an IPv+ ioute taLle gioup, specily inet.0 as the piimaiy ioute
taLle. To conliguie an IPv6 ioute taLle gioup, specily inet6.0 as the piimaiy ioute taLle.
Each RIB gioup must contain one oi moie ioute taLles that ]unos soltwaie uses as the
souice ol any impoiteu ioutes, as specilieu with the import-rib statement.
In the lollowing example, a rib-group calleu my_interface_routes is conliguieu to im-
poit inteilace ioute entiies liom inet.0 into inet.2. The my_interface_routes RIB
gioup is uelineu unuei the interface-routes hieiaichy, which specilies the piotocol
(uiiect) that is useu to match against when copying the ioutes into inet.2:
[edit routing-options]
lab@PBR# show
interface-routes {
rib-group inet my_interface_routes;
}
rib-groups {
my_interface_routes {
Protocol Independent Properties | 137
import-rib [ inet.0 inet.2 ];
}
}
The iesult ol the inteilace ioutes RIB gioup uelinition is conliimeu with a uisplay ol
the inet.2 taLle Loth Leloie anu altei the changes aie committeu:
[edit routing-options rib-groups]
lab@PBR# run show route table inet.2
[edit routing-options rib-groups]
lab@PBR# commit
commit complete
Altei the commit, the inet.2 taLle is coiiectly populateu with inteilace ioutes, as copieu
liom the inet.0 taLle:
[edit routing-options rib-groups]
lab@PBR# run show route table inet.2
inet.2: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.130.0/24 *[Direct/0] 00:00:04
> via ge-0/0/0.1141
10.10.130.2/32 *[Local/0] 00:00:04
Local via ge-0/0/0.1141
10.20.128.3/32 *[Direct/0] 00:00:04
> via lo0.0
10.20.129.0/24 *[Direct/0] 00:00:04
> via ge-0/0/0.3141
10.20.129.2/32 *[Local/0] 00:00:04
Local via ge-0/0/0.3141
10.20.130.0/24 *[Direct/0] 00:00:04
> via ge-0/0/0.1241
. . .
Il uesiieu, you can use impoit policy to auu auuitional contiol ovei which ioutes aie
copieu Letween RIBs.
Router ID and Antonymous System Number
The last PIP-ielateu conliguiation to Le uiscusseu is ielateu to the ioutei ID (RID) anu
BGP AS numLei.
Router ID
Many iouting piotocols ieguiie that the souice ol iouting inloimation Le uniguely
iuentilieu using the concept ol a RID. A RID noimally takes the loim ol an IPv+ auuiess,
anu in most cases uoes not have to Le ieachaLle to coiiectly lunction as a RID. Stateu
uilleiently, a ioutei can ieceive a BGP oi OSPF ioute upuate liom a ioutei iuentilieu
as 1.1.1.1, anu coiiectly piocess the ielateu iouting inloimation, even though it may
138 | Chapter 5:Protocol Independent Properties and Routing Policy
not have a ioute to 1.1.1.1. Vith that saiu, it is common to use a ioutaLle IP auuiess
as the RID Lecause this can simplily opeiations Ly enaLling pings oi telnet to the RID.
You can specily only one RID, anu the same value is useu Ly all piotocols that ieguiie
a RID (OSPF, OSPFv3, anu BGP). The cuiient Lest piactice is to Lase the RID on the
ioutei`s gloLally ioutaLle lo0 auuiess. You explicitly conliguie a RID as lollows:
[edit routing-options]
lab@PBR# set router-id 1.1.1.1
[edit routing-options]
lab@PBR# show
router-id 1.1.1.1;
Vhen you explicitly conliguie a RID that is Laseu on an auuiess assigneu to the ioutei`s
lo0 inteilace, you will have to iun an explicit IGP instance (typically passive) on that
inteilace to auveitise ieachaLility to the RID, when uesiieu. Vhen a RID is not explicitly
conliguieu, the ioutei oLtains its RID liom the piimaiy auuiess ol the liist inteilace
that comes online. This is typically the loopLack inteilace, when it has Leen assigneu
a nonmaitian (non-127.0.0.1) auuiess. Because changes in RID aie uisiuptive to pio-
tocol opeiation, it`s a goou piactice to manually conliguie a RID to ensuie that changes
to lo0 auuiessing uo not cause unanticipateu chuin.
Histoiically, ]unos soltwaie automatically auveitiseu a stuL ioute to the inteilace liom
which the RID is oLtaineu. This meant that you uiu not neeu to iun an IGP instance
on the loopLack inteilace to auveitise ieachaLility to the RID. Staiting with ]unos
Release S.5, this Lehavioi has changeu. Now, whethei you use an explicit oi an auto-
matically geneiateu RID that is lo0Laseu, you neeu to enaLle OSPF on the loopLack
inteilace to auveitise ieachaLility to the ielateu loopLack auuiess, even when it is the
souice ol an automatically selecteu RID.
Autonomous system number
An autonomous system (AS) numLei is ieguiieu loi BGP opeiation; you cannot commit
a BGP-ielateu conliguiation without also uelining the local ioutei`s AS numLei. In this
iegaiu, it can Le saiu that the AS numLei is not ieally piotocol-inuepenuent, Lut loi
whatevei ieason it can Le conliguieu unuei [routing-options], iathei than unuei BGP
itsell.
Chaptei 7 pioviues a uetaileu uesciiption ol what an AS numLei is anu how BGP uses
it. The lollowing is a sample AS numLei conliguiation:
[edit routing-options]
lab@PBR# set autonomous-system ?
Possible completions:
<as_number> Autonomous system number (1..65535)
loops Maximum number of times this AS can be in an AS path
[edit routing-options]
lab@PBR# set autonomous-system 100
Protocol Independent Properties | 139
[edit routing-options]
lab@PBR# show
autonomous-system 100;
The loops option allows you to conliguie toleiance loi occuiiences ol the local ASN in
ieceiveu ioute upuates; noimally such an occuiience inuicates a BGP iouting loop anu
iesults in the ielateu ioute Leing uiscaiueu. Theie aie ceitain coinei-case scenaiios,
mostly ielateu to VPNs anu the suppoit ol EBGP on the PE-CE customei links, wheie
you might neeu to altei the uelault value. Note that the uelault value ol 1 inuicates that
a ioute with a single instance ol the local ASN shoulu Le uiscaiueu. Theieloie, to sup-
poit ieception ol ioutes with a single instance ol the local ASN, specily a loop value
ol 2.
Summary of Protocol-Independent Properties
This section uiscusseu common PIPs that aie typically useu in enteipiise netwoiks.
Topics incluueu the cieation ol static, aggiegate, anu geneiateu ioutes, along with theii
uilleiences anu associateu vaiious next hop options. GloLal pieleience, which is useu
to Lieak ties Letween competing souices ol iouting inloimation, was uiscusseu, as was
the conliguiation ol a lloating static ioutewhich is simply a static ioute with an
alteieu gloLal pieleience that makes it less pieleiieu than a ioute leaineu via a uynamic
iouting piotocol. This section also uesciiLeu the use anu puipose ol the uelault ]unos
soltwaie ioute taLles, anu how RIBs anu RIB gioups aie useu to cieate anu link ioute
taLles. Ve enueu with a uesciiption ol how the RID can Le explicitly conliguieu oi
automatically computeu, in auuition to how the local AS numLei is conliguieu to sup-
poit BGP opeiation.
The next section uelves into ]unos soltwaie iouting policy, which pioviues you with
complete contiol ovei ioute exchanges anu attiiLute mouilication.
Routing Policy
This section uetails ]unos soltwaie iouting policy opeiation anu conliguiation. The
actual application ol policy to solve some specilic netwoiking ieguiiement is geneially
lelt to the piotocol-specilic coveiage lounu in suLseguent chapteis. You conliguie
policy-ielateu options anu statements at the [edit policy-options] hieiaichy. Routing
policy anu liiewall lilteis have a similai syntax in ]unos soltwaie. The loimei ueals with
ioutes in the contiol plane, wheieas the lattei ueals with packets in the uata plane.
Fiiewalls aie coveieu in uetail in a latei chaptei.
140 | Chapter 5:Protocol Independent Properties and Routing Policy
What Is a Routing Policy, and When Do I Need One?
Simply put, iouting policy is useu to:
Contiol what ioutes aie installeu into the ioute taLle loi possiLle selection as an
active ioute
Contiol what ioutes aie expoiteu liom the ioute taLle, anu into which piotocols
Altei attiiLutes ol ioutes, eithei at ieception oi at the time ol auveitisement to othei
peeis
Given that iouting policy is useu to contiol the ieception anu tiansmission ol iouting
inloimation anu to altei ioute attiiLutes, it`s sale to say that you neeu iouting policy
when the uelault policy uoes not meet youi ieguiiements.
The specilics ol the vaiious uelault policies aie coveieu latei, Lut to pioviue an example,
consiuei that, Ly uelault, uiiectly connecteu ioutes aie not auveitiseu into any iouting
piotocol; in the case ol RIP, not even when RIP is conliguieu to iun on those uiiectly
connecteu inteilaces. Il youi goal is to get uiiect ioutes auveitiseu into RIP, the uelault
policy oLviously uoes not meet youi neeus, anu a custom policy must Le wiitten, anu
applieu, to achieve youi goal ol ieuistiiLuting uiiect ioutes into RIP.
Where and How Is Policy Applied?
You can apply policy in one ol two places: eithei at impoit oi at expoit. Geneially
speaking, use a commanu ol the loim set protocols <protocol-name> import to apply
an impoit policy, oi use set protocols <protocol-name> export to apply an expoit pol-
icy. Figuie 5-2 illustiates this concept.
Iigurc 5-2. Po|icy app|ication and nonitoring points
Figuie 5-2 shows ioutes Leing ieceiveu thiough some piotocol, anu how impoit policy
seives to liltei anu aujust ioute attiiLutes Leloie they aie copieu into the ioute taLle.
Routing Policy | 141
In contiast, expoit policy comes into play when ioutes aie Leing selecteu liom the ioute
taLle loi inclusion in tiansmitteu ioute upuates. Once again, the expoit policy seives
to liltei anu aujust ioute attiiLutes to meet the specilic neeus ol the netwoiking
enviionment.
It is woith noting that uistance vectoi piotocols such as RIP anu path vectoi piotocols
such as BGP actually suppoit the notion ol ieceiveu anu tiansmitteu ioutes. These
piotocols suppoit the show route receiving-protocol <protocol-name> <neighbor-
address> anu show route advertising-protocol <protocol> <neighbor-address> com-
manus, which aie veiy uselul when tiouLleshooting oi analyzing policy opeiation.
Figuie 5-2 shows how the ieceiving-piotocol loim ol the commanu is useu to uisplay
ioutes ajtcr ioute lilteiing, Lut bcjorc attiiLute manipulation. In contiast, the
auveitising-piotocol loim ol the commanu is executeu altei all expoit policy opeia-
tions, incluuing ioute lilteiing anu attiiLute mouilication. Simply issue a show route
<prefix> commanu to uisplay a ioute as it exists in the ioute taLle, which will incluue
any mouilieu attiiLutes iesulting liom impoit policy opeiations.
Applying policy to link state routing protocols
Link state (LS) piotocols such as OSPF anu IS-IS uo not senu anu ieceive ioutes uiiectly.
Insteau, they lloou link-state auveitisement (LSA) packets, which aie useu to Luilu a
topological uataLase liom which each ioutei computes a ioute taLle. As such, LS pio-
tocols uo not suppoit much in the way ol impoit policy. OSPF impoit policies can liltei
exteinal ioutes liom the ioute taLle oi assign a ielative piioiity loi ioute iestoiation
(loi moie on applying policies to OSPF, see http://www.junipcr.nct/tcchpubs/cn_US/
junos10.3/topics/usagc-guidc|incs/routing-app|ying-po|icics-to-ospj-routcs.htn|).
Il you wish to liltei LSAs, piotocol-specilic mechanisms aie ieguiieu to ensuie that LS
uataLase consistency is maintaineu. Chaptei 6 coveis the concepts ol OSPF stuL aieas
anu LSA lilteiing.
You can apply expoit policy to an LS piotocol to ellect ioute ieuistiiLution, Lut the
exteinal ioute is still llooueu in an LSA iathei than Leing sent outiight; the iesult is
that the show route receiving protocol anu show route-advertising protocol com-
manus aie not ellective when uealing with LS piotocols.
Vhen you apply policy to an LS piotocol, you uo so gloLally, which is to say the policy
is not applieu to paiticulai inteilaces oi aieas. In the case ol OSPF, you apply expoit
policy at the [edit protocol ospf] hieiaichy:
[edit protocols ospf]
lab@PBR# show
export test_export; ## 'test_export' is not defined
The CLI waining pioviues a nice ieminuei that the ielateu test_export policy uoes not
yet exist. Because the piesence (oi aLsence) oi a policy can have a uiamatic ellect on
oveiall netwoik opeiation, you will not Le aLle to commit a conliguiation with this
142 | Chapter 5:Protocol Independent Properties and Routing Policy
type ol omission. You can ueline a policy that is nevei applieuLut once applieu, the
policy must exist Leloie you can commit the changes.
Applying policy to BGP and RIP
Both BGP anu RIP suppoit the application ol impoit anu expoit policy, anu Loth sup-
poit policy application at uilleient hieiaichies. Focusing on BGP loi the moment, you
can apply a policy at one ol thiee uilleient hieiaichiesgloLal, gioup, oi neighLoi.
The lollowing coue snippet pioviues an example ol this concept:
[edit protocols bgp]
lab@PBR# show
export global_export;
group internal {
export internal_export;
neighbor 1.1.1.1 {
export neighbor_1.1.1.1_export;
}
neighbor 2.2.2.2;
}
group other {
neighbor 3.3.3.3;
}
In this example, a policy nameu global_export is applieu at the gloLal level, anothei
policy nameu internal_export is applieu at the gioup level, anu yet a thiiu policy nameu
neighbor_1.1.1.1_export is applieu at the neighLoi level.
A key point, anu one that is olten misunueistoou anu that can leau to pioLlems, is that
in such a conliguiation, on|y the most explicit policy is applieu. A neighLoi-level policy
is moie explicit than a gioup-level policy, which in tuin is moie explicit than a gloLal
policy. Hence, neighLoi 1.1.1.1 is suLjecteu only to the neighbor_1.1.1.1_export pol-
icy, wheieas neighLoi 2.2.2.2, lacking anything moie specilic, is suLjecteu only to the
internal_export policy. Meanwhile, neighLoi 3.3.3.3 in gioup other has no gioup- oi
neighLoi-level policy, so it uses the global_export policy.
So, what il you neeu to have neighLoi 1.1.1.1 peiloim the lunction ol all thiee policies?
Simpleyou coulu wiite anu apply a new neighLoi-level policy that encompasses the
lunctions ol the othei thiee, oi simply apply all thiee cxisting policies, as a chain, to
neighLoi 1.1.1.1. Note the use ol Liackets in the lollowing commanu to open a set ol
values; il uesiieu, each policy can Le specilieu inuiviuually:
[edit protocols bgp group internal]
lab@PBR# set neighbor 1.1.1.1 export [global-export internal_export]
[edit protocols bgp]
lab@PBR# show group internal neighbor 1.1.1.1
export [ neighbor_1.1.1.1_export global_export internal_export];
As with access contiol lists (ACLs) oi liiewall lilteis, chaineu policy statements aie
evaluateu in a specilic lelt-to-iight oiuei anu only up to the point when a ioute is eithei
Routing Policy | 143
accepteu oi iejecteu. As a iesult, you must consiuei lactois such as whethei a policy
makes use ol a match-all ueny teim at its enu, which is common loi a stanualone policy.
Howevei, when applieu at the liont ol a policy chain, the match-all aspect ol such a
policy pievents ioute piocessing Ly any iemaining policies. To help illustiate this point,
consiuei two policies, one nameu dcny, which uenies all, anu anothei nameu acccpt,
which accepts all. Given the natuie ol the two policies, you will see a uiamatic uilleience
Letween these two policy chains, even though they aie composeu ol the same paits:
export [accept deny];
export [deny accept];
Heie, the liist policy chain iesults in a|| ioutes Leing acccptcd, wheieas the ieveise
application iesults in a|| ioutes Leing dcnicd. You can use the CLI`s inseit leatuie to
ieaiiange the oiuei ol applieu policies, oi simply uelete anu ieapply the policies to get
the oiuei neeueu. Note that a newly applieu policy always takes the leltmost place in
a policy chain, wheie it Lecomes the liist in line loi ioute evaluation.
Ve coveieu a lew ciitical points heie, so much so that they Leai iepeat-
ing in anothei loim. The liist point is that when multiple policies aie
applieu at uilleient CLI hieiaichies loi the same piotocol, only the most
specilic application is evaluateu, to the exclusion ol othei, less specilic
policy applications. Seconu, a given ioute is evaluateu against a chain
ol policies staiting with the leltmost policy, up until the ioute meets a
teiminating action ol eithei accept oi ieject. This leaus to oiueiing sen-
sitivity ol Loth teims within a policy, anu loi policies when they aie
chaineu togethei.
Although these points always seem to make sense when you aie leaining
them, they aie somehow easily loigotten uuiing ioutei conliguiation,
when two policies that inuiviuually woikeu as expecteu suuuenly Lieak
when they aie comLineu, oi when you mistakenly Lelieve that a
neighLoi-level policy is comLineu with a gloLal oi gioup-level policy,
only to linu that youi policy Lehavioi is not as anticipateu.
Policy Components
Geneially speaking, a policy statement consists ol one oi moie nameu teims, each
consisting ol two paits: a from statement that uelines a set ol match ciiteiia, anu a
coiiesponuing then statement that specilies the set ol actions to Le peiloimeu loi
matching tiallic. It is possiLle to cieate a policy with a single teim, in which case the
teim can Le unnameu, such as in these two examples:
[edit policy-options]
lab@PBR# show
policy-statement explicit_term {
term 1 {
from protocol direct;
then accept;
}
144 | Chapter 5:Protocol Independent Properties and Routing Policy
}
policy-statement implict_term {
from protocol direct;
then accept;
}
The two policy statements peiloim iuentical lunctions; Loth have a match ciiteiion ol
direct, anu Loth have an associateu action ol accept. The explicit teim loimat is gen-
eially pieleiieu, Lecause new teims can Le auueu without the neeu to ieueline the
existing teim. Note that any new teims aie auueu to the enu ol the policy statement,
as shown heie, wheie, ouuly enough, a new teim nameu new is auueu to the
explict_term policy statement:
[edit policy-options]
lab@PBR# set policy-statement explicit_term term new from protocol direct
[edit policy-options]
lab@PBR# set policy-statement explicit_term term new then reject
[edit policy-options]
lab@PBR# show policy-statement explicit_term
term 1 {
from protocol direct;
then accept;
}
term new {
from protocol direct;
then reject;}
As with policy chains, teim oiueiing within a policy is signilicant. In the example,
explict_term policy, teim 1, anu teim new aie uiametiically opposeu, with one accepting
anu the othei uenying the same set ol uiiect ioutes. Although making little piactical
sense, it uoes alloiu the oppoitunity to uemonstiate teim ieseguencing with the
insert lunction:
[edit policy-options]
lab@PBR# edit policy-statement explicit_term
[edit policy-options policy-statement explicit_term]
lab@PBR# insert term new before term 1
[edit policy-options policy-statement explicit_term]
lab@PBR# show
term new {
from protocol direct;
then reject;}
term 1 {
from protocol direct;
then accept;
}
Theie is no piactical limit to the numLei ol teims that can Le specilieu in a single policy,
oi to how many policies can Le chaineu togethei.
Routing Policy | 145
Logical OR and AND functions within terms
It`s possiLle to ueline a teim with multiple match ciiteiia uelineu unuei a single from
statement. Foi a match to occui, all ol the from conuitions must Le met, which is a
logical AND. Howevei, loi a specilic match type, such as protocol, you can specily
multiple values, in which case each piotocol match conuition lunctions as a logical OR.
Consiuei this example:
[edit policy-options]
lab@PBR# show
policy-statement test {
term 1 {
from {
protocol [ bgp rip ]; ##logical OR within brackets
interface ge-0/0/0.0; ## logical AND with other match criteria
}
then next term;
}
}
In this case, a match will occui when a ioute is leaineu ovei the ge-0/0/0 inteilace
and is leaineu liom BGP or RIP.
Policy Match Criteria and Actions
]unos soltwaie policy pioviues a iich set ol ciiteiia you can match against, anu an
egually iich set ol actions that can Le peiloimeu as a iesult ol a match. The vaiious
match anu action lunctions aie well uocumenteu, so the goal heie is not to ie-cieate
the wheel Ly iehashing each optionas noteu at the Leginning ol this chaptei, the
oLject is to acguaint you with a Lox ol tools; latei chapteis will pioviue specilic exam-
ples ol those tools Leing useu.
Policy match criteria
The list ol availaLle match ciiteiia is long in the ]unos soltwaie 10.3 ielease:
lab@PBR# set policy-statement test term 1 from ?
Possible completions:
aggregate-contributor Match more specifics of an aggregate
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
area OSPF area identifier
+ as-path Name of AS path regular expression (BGP only)
+ as-path-group Name of AS path group (BGP only)
color Color (preference) value
color2 Color (preference) value 2
+ community BGP community
+ condition Condition to match on
> external External route
family
instance Routing protocol instance
+ interface Interface name or address
146 | Chapter 5:Protocol Independent Properties and Routing Policy
level IS-IS level
local-preference Local preference associated with a route
metric Metric value
metric2 Metric value 2
metric3 Metric value 3
metric4 Metric value 4
> multicast-scope Multicast scope to match
+ neighbor Neighboring router
+ next-hop Next-hop router
next-hop-type Next-hop type
origin BGP origin attribute
+ policy Name of policy to evaluate
preference Preference value
preference2 Preference value 2
> prefix-list List of prefix-lists of routes to match
> prefix-list-filter List of prefix-list-filters to match
+ protocol Protocol from which route was learned
rib Routing table
> route-filter List of routes to match
route-type Route type
> source-address-filter List of source addresses to match
state Route state
+ tag Tag string
tag2 Tag string 2
The key takeaway heie is that you can match on things such as inteilace, piotocol,
ioute tag, AS path, communities, souice auuiess, metiic, anu so on. Route lilteiing
Laseu on pielix anu mask length is peiloimeu with the route-filter keywoiu. Theie
is signilicant powei (anu complexity) in ioutei lilteiing, anu it is coveieu in the section
Route Filteis on page 1+S.
Policy actions
Vhen a match occuis, a wiue iange ol actions aie availaLle:
[edit policy-options]
lab@PBR# set policy-statement test term 1 then ?
Possible completions:
accept Accept a route
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
>as-path-expand Prepend AS numbers prior to adding local-as (BGP only)
as-path-prepend Prepend AS numbers to an AS path (BGP only)
class Set class-of-service parameters
> color Color (preference) value
> color2 Color (preference) value 2
> community BGP community properties associated with a route
cos-next-hop-map Set CoS-based next-hop map in forwarding table
damping Define BGP route flap damping parameters
default-action Set default policy action
destination-class Set destination class in forwarding table
> external External route
forwarding-class Set source or destination class in forwarding table
> install-nexthop Choose the next hop to be used for forwarding
Routing Policy | 147
label-allocation Set label allocation mode
> load-balance Type of load balancing in forwarding table
> local-preference Local preference associated with a route
> map-to-interface Set output logical interface
> metric Metric value
> metric2 Metric value 2
> metric3 Metric value 3
> metric4 Metric value 4
next Skip to next policy or term
> next-hop Set the address of the next-hop router
origin BGP path origin
> preference Preference value
> preference2 Preference value 2
priority Set priority for route installation
reject Reject a route
source-class Set source class in forwarding table
> tag Tag string
> tag2 Tag string 2
trace Log matches to a trace file
Actions incluue AS path piepenuing, changing ioute coloi (inteinal tieLieakei), evok-
ing uamping, alteiing local pieleience, specilying metiic anu community, alteiing a
packet`s loiwaiuing class, auuing a ioute tag, anu so loith. Key actions incluue
accept anu reject, which aie teimination actions. The next keywoiu allows you to skip
to the next teim, oi policy in the chain, anu it is uselul loi shunting ioutes liom one
teim oi policy into anothei.
Route Filters
The aLility to match on specilic ioutes to accept oi ieject them oi to mouily some
attiiLute is a ciitical aspect ol viitually any netwoiking scenaiio. The majoiity ol ]unos
soltwaie iouting policy stiikes most useis as intuitive anu logical, given the easy-to-
lollow ij, thcn constiuct ol policy syntax.
The exception always seems to Le ioute lilteiing, Lecause to tiuly unueistanu how this
is peiloimeu in ]unos soltwaie, you must liist unueistanu the Linaiy iauix tiee natuie
ol the ioute lookup taLle anu how the Linaiy tiee is useu in conjunction with ioute
lilteis.
Binary trees
Binaiy tiees have Leen useu in computei science loi seveial uecaues as a way to guickly
locate a uesiieu Lit ol inloimation. In the case ol ioute lookup, the goal is to guickly
linu the longest match loi some pielix, with the coiiesponuing next hop Leing the
inloimation that is sought. The ]unipei Netwoiks implementation ol a Linaiy tiee is
calleu the ]-Tiee, anu it loims the Lasis ol Loth ioute lookup anu policy-Laseu ioute
lilteiing. Figuie 5-3 shows the ioot ol a Linaiy tiee, along with a lew ol its Lianches.
Figuie 5-3 shows a Linaiy to poweis ol a uecimal chait, to help with unueistanuing the
stiuctuie ol the ]-Tiee. Foi example, the Linaiy seguence 0100 0000 eguates to a
148 | Chapter 5:Protocol Independent Properties and Routing Policy
uecimal 6+, wheieas 0110 0000 coues a uecimal 96. In this example, Lit S, which has
the uecimal powei ol 12S, iepiesents the seconu set ol noues liom the top ol the tiee.
The top ol the tiee iepiesents no Lit, anu the liist paii ol noues uown iepiesents a test
ol the MSB, which is Lit S in this example, as eithei 0 (0), oi 1 (12S).
The Linaiy tiee is Laseu on noues that test the state ol a paiticulai Lit that makes up
the 32-Lit IP auuiess oi ioute pielix. The Lit Leing testeu is inuicateu Ly the ielateu
pielix (mask) length. Foi example, the top ol the tiee is testing no Lits, as inuicateu Ly
the /0 pielix length. All pielixes match when you uo not Lothei to test any Lits, so the
top ol the tiee ellectively iepiesents a uelault ioute, which is to say when no othei
patteins match you aie guaianteeu to match the liist noue. Vhethei such a match
actually iesults in loiwaiuing uepenus on whethei a uelault ioute has Leen installeu,
Lut that is anothei stoiy.
The tiee Lianches to the lelt when a given Lit is a 0, anu it Lianches to the iight loi a
1. As a iesult, the liist two noues Lelow the ioot iepiesent the state ol the most signil-
icant Lit in the most signilicant Lyte, which is eithei a 0 oi a 1. Il it is a 0, you have a
0/1 match, which coues a uecimal 0. Il that Lit is a 1, you have a 1/1 match, which
coues a uecimal 12S. Each noue then Lianches out, Laseu on the test ol the next Lit,
until you ieach the Lottom ol the tiee, which iepiesents a test ol all 32 Lits (which is
sonctincs necessaiy when uoing a ioute lookup oi ioute liltei that is Laseu on a /32
pielix length).
In actual opeiation, the ]-Tiee is optimizeu anu can guickly jump to a longest match
when othei poitions ol the tiee aie eliminateu. It coulu Le saiu that the act ol linuing
a longest match against a Linaiy tiee is not so much linuing what you seek as it is guickly
eliminating all that cannot Le what you want, anu then simply looking at what is lelt.
Iigurc 5-3. A binary trcc
Routing Policy | 149
By way ol example, a 32-Lit IP auuiess can take moie than + Lillion comLinations.
Howevei, hall ol these (2 Lillion) will have a 0 in the high-oiuei Lit position, wheieas
the othei hall will have a 1. By simply testing the status ol one Lit, you have ellectively
eliminateu one-hall ol the tiee as not Leing possiLle to match. Vith each suLseguent
Lit test eliminating one-hall ol the iemaining possiLilities, you guickly aiiive at a noue
that eithei matches all 32 Lits ol the pielix, oi uoes not match the pielix Leing evaluateu,
in which case you Lack up one noue. That is the longest match loi this pielix.
Route filters and match types
Vhen you conliguie a ioute liltei, you specily a staiting pielix anu initial pielix length,
anu then incluue a match type to inuicate whethei ioutes with pielixes longei than the
initial value shoulu Le consiueieu as matching. Put anothei way, a ioute liltei is Laseu
on a match against the specilieu pielix Lits, as Laseu on the pioviueu mask, in auuition
to the oveiall mask length ol the pielix Leing evaluateu. As such, it can Le saiu that a
]unipei ioute liltei caies as much aLout the pielix |cngth as it uoes the prcjix itsc|j.
Figuie 5-+ illustiates the suppoiteu route-filter match types in the context ol a
]-Tiee; it was saiu Leloie, anu is stateu heie again, that you cannot ellectively use ioute
lilteis il you uo not liist unueistanu the opeiation ol the ]-Tiee. This is especially tiue
loi the through match type, which 99.9 ol the time is applieu incoiiectly, anu theieloie
uoes not uo what the opeiatoi wanteu.
Iigurc 5-1. Routc ji|tcr natch typcs and thc j-Trcc
150 | Chapter 5:Protocol Independent Properties and Routing Policy
Figuie 5-+ is Laseu on a poition ol the ]-Tiee that iepiesents ioute 192.16S/16. Entiies
Lelow the staiting noue all shaie the same high-oiuei 16 Lits ol 192.16S, Lut uillei liom
the ioot pielix in that they have longei mask lengths, as shown Ly the two noues Lelow
the liist, each ol which is testing Lit 17, theieloie inuicating a /17 mask length.
Each ioute liltei match type is uesciiLeu against the coiiesponuing poition ol the liguie:
exact
The exact match type is just what it sounus like. To match with exact, Loth the
initial pielix Lits must match, anu the pielix length must Le egual to the value
specilieu. Il the pielix Lits uo not match, oi il the pielix length is eithei shoitei oi
longei, the exact match type uoes not match. Figuie 5-+ shows that ioute liltei
192.16S.0.0/16 exact matches only on that noue ol the ]-Tiee, to the exclusion ol
all otheis.
or-longer
The or-longer match type matches the specilieu pielix anu initial mask length anu
matches on pielixes with longei mask lengths when they shaie the same high-oiuei
Lits, as inuicateu Ly the specilieu pielix. In this example, the iesult is a match
against 192.16S.0.0/16 itsell, as well as 192.16S.0/17 anu 192.16S.12S/1S anu all
longei mask lengths, up to /32.
longer
The longer match type excluues the exact match anu catches all ioutes with the
same pielix Lits, Lut only when theii masks aie longei than the pielix length speci-
lieu. The uilleience Letween or-longer anu longer is shown in Figuie 5-+, wheie
the lattei excluues the exact match, which is pielix 192.16S.0.0/16 in this case.
upto
The upto match type matches against the initial pielix anu mask length, as well as
matching pielixes with masks that aie longei than the initial value, upto the enuing
mask length value. In the example, the initial pielix ol 192.16S.0.0/16 matches, as
well as all othei 192.16S pielixes that have mask lengths upto the specilieu value,
which is 1S in this example. Theieloie, 192.16S.192/1S will match, wheieas
192.16S.1/2+ will not.
prefix-length-range
The prefix-length-range match type matches against ioutes with the same pielix
as specilieu in the initial mask length, Lut only when the associateu mask lalls
Letween the staiting anu enuing values. The iesult is that the exact match is ex-
cluueu, wheieas ioutes with the same high-oiuei pielix Lits, Lut masks that lall
within the specilieu iange, aie accepteu. This match type is especially uselul when
the goal is to liltei the ioute Laseu on mask length alone, which is a common policy
within seivice pioviuei netwoiks, as many ieluse to caiiy ioutes with masks longei
than 2S in an elloit to keep ioute taLle size manageaLle. To pievent installation ol
any ioute with a mask length longei than /2S, you can use a route-filter 0/0
prefix-length-range /28-/32 reject statement. Because the initial pielix length
Routing Policy | 151
is 0, all pielix values match, making the uecision to ieject one that is Laseu stiictly
on mask length.
It`s woith noting that ioute-liltei syntax suppoits a shoit loim ol
action linking, in which the ielateu then action can Le specilieu
uiiectly on the route-filter line. Functionally theie is no uillei-
ence Letween the shoit loim anu auuing an explicit then action.
through
The through match type is geneially misunueistoou, anu it iaiely woiks the way
lolks think it shoulu. This is not to say that it is Lioken, Lut it has leu to this
somewhat humoious iule ol thumL: Vhen you aie thinking ol using through,
think again. In most cases, when people use through, what they wanteu is moie
ol the upto oi prefix-length-range type ol match. The statement is intenueu to
wain the usei that in most cases, through is not what you ieally want, anu that the
uecision to use it shoulu Le caielully thought, paiuon the pun, thiough.
A through match type matches the initial pielix anu mask length exactly, as well
as the enuing pielix anu mask length, anu matches on the contiguous set ol noues
Letween the two points. The through match type was oiiginally olleieu to meet a
coinei case, in which a customei was lounu to Le using 32 exact matches, all Laseu
on some loim ol a uelault ioute. Although a tiue uelault is 0/0, the customei wan-
teu to ensuie that no 0.0.0.0 pielixes weie installeu, iegaiuless ol mask length. So,
iathei than a 0.0 exact, 0/1 exact, 0/2 exact ... 0/32 exact, the through match
type was cieateu to allow the same ellect with a single 0/0 through 0/32 statement.
This matches the top ol the tiee, all the way uown the lelt siue to the veiy Lottom,
anu all contiguous points in Letween.
In Figuie 5-+, the through match type is specilieu as 192.16S.0.0/16 thiough
192.16S.32.0/19. The line shows the seguence ol contiguous matches Letween the
two points, which in this case incluues 192.16S.0.0/16, 192.16S.0.0/17,
192.16S.0.0/1S, anu 192.16S.32.0/19. Now ask youisell (anu Le honest): is this
what you expecteu a 192.16S/16 thiough 192.16S.32/19 to match?
As with iouting in geneial, ioute liltei piocessing is
Laseu on linuing a longest match, anu then peiloiming the action associateu with that
match. Theie aie cases wheie this may leau to unexpecteu Lehavioi Lecause useis uo
not always take into account the conseguences ol uilleient match types. Recall that the
longest-match lunction is Laseu on the high-oiuei pielix Lits, wheieas the match type
locuses moie on mask length. Consiuei this ioute-liltei example, anu what will happen
when ioute 200.0.67.0/2+ is evaluateu against it:
[edit policy-options policy-statement test_me]
user@host# show
from {
route-filter 200.0.0.0/16 longer reject;
route-filter 200.0.67.0/24 longer;
Longest match wins, but may not.
152 | Chapter 5:Protocol Independent Properties and Routing Policy
route-filter 200.0.0.0/8 orlonger accept;
}
then {
metric 10;
accept;
}
The guestion is, will ioute 200.0.67.0/2+ match this teim, anu il so, is it accepteu, is it
iejecteu, oi uoes it have its metiic set to 10 Leloie Leing accepteu? Think caielully, anu
consiuei how longest matching is peiloimeu, along with how the match type comes
into play.
Il you answeieu The ioute uoes not match, anu is neithei accepteu, noi iejecteu, anu
no metiic mouilication is maue, give youisell a well-ueseiveu pat on the Lack. It`s
guite OK il you answeieu uilleientlythis little tiuLit alone may well justily the ex-
penuituie loi this Look (you uiu pay loi this Look, iight?). The key heie is that the
longest match, as Laseu on specilieu pielix, is against the seconu ioute-liltei
statementheie the liist 2+ Lits ol the pielix uo in lact match 200.0.67/2+, which is
moie exact than eithei 200/S oi 200.0/16. Howevei, the longest match in this example
has a match type ol longer, meaning that only a ioute with a mask length ol /25/32
with the 2+ high-oiuei Lits set to 200.0.67 is consiueieu to match.
Because this ioute has a mask length that is egual to the value specilieu, it uoes not
match. A given ioute is only evaluateu against the longest match in a given teim. This
is to say that il the longest match enus up not ieally matching, as shown in this example,
othei ioute-liltei statements within that same teim aie not evaluateu. Insteau, the ioute
lalls thiough to the next teim oi policyoi lacking any ol those, to the uelault policy
loi the iouting piotocol in guestion.
Default Policies
The last huiule in unueistanuing ]unos soltwaie policy is to Le lamiliai with the uelault
policy associateu with each piotocol useu in youi netwoik. Unueistanuing the uelault
policy is impoitant Lecause it ultimately ueciues the late ol any ioute that is not matcheu
against in youi usei-uelineu policy. Some opeiatois iely on the uelault policy to uo
something, anu otheis pielei to ensuie that theii policy is wiitten to match on a|| pos-
siLle ioutes, which means the uelault policy is negateu Lecause it nevei gets a chance
to come into play.
OSPF (and IS-IS) default policy
The uelault impoit policy loi LS piotocols is to accept all ioutes leaineu thiough that
piotocol. OSPF suppoits input policies to liltei exteinal ioutes liom Leing installeu
into the ioute taLle anu to assign piioiity loi ioute iestoiation. The liltei impoit policies
uo not liltei exteinal ioute LSAs liom the uataLase; they only iestiict the ioutes liom
Leing installeu in the ioute taLle.
Routing Policy | 153
The uelault LS expoit policy is to ieject eveiything. LSA lloouing is not allecteu Ly
expoit policy, anu it is useu to convey iouting in an inuiiect mannei in an LS piotocol.
The iesult ol this lloouing is the auveitisement ol local inteilaces that aie enaLleu to
iun OSPF, as well as the ieauveitisement (lloouing) ol LSAs ieceiveu liom othei iouteis.
Expoit policies aie useu to inseit othei (non-OSPF) ioutes into the OSPF uataLase.
These ioutes aie then hanuleu as exteinal ioutes within OSPF.
RIP default policy
The uelault RIP impoit policy is to accept all ieceiveu RIP ioutes that pass a sanity
check. In contiast, the uelault expoit policy is to auveitise no ioutes. None, zip, naua,
zilch. Not even RIP leaineu ioutes aie auveitiseu with the uelault RIP expoit policy.
Although it may Le an ouu choice ol uelault Lehavioi, the net ellect is that loi any
piactical RIP ueployment, you will neeu to cieate anu apply a custom expoit policy to
ieauveitise RIP leaineu anu uiiect ioutes loi inteilaces iunning RIP to othei RIP
speakeis.
BGP default policy
The uelault BGP impoit policy is to accept all ieceiveu BGP ioutes that pass a sanity
checkloi example, those ioutes that uo not have an AS loop, as inuicateu Ly the AS
path attiiLute.
The uelault BGP expoit policy is to ieauveitise all active leaineu BGP ioutes to all BGP
speakeis, while oLeying piotocol-specilic iules that piohiLit one IBGP speakei liom
ieauveitising ioutes leaineu liom anothei IBGP speakei, unless it is lunctioning as a
ioute iellectoi.
Advanced Policy Concepts
Congiatulations. You have maue it to this point, anu theieloie you now possess an in-
uepth anu piactical unueistanuing ol iouting policy. This section exploies some au-
vanceu policy concepts, some ol which aie guite inteiesting Lut iaiely useu. The use
ol iegulai expiessions (iegexes) is tieateu as an auvanceu topic, Lut uilleis liom the
iemaining topics Lecause the use ol AS path oi community iegex matching is somewhat
common, especially in laige netwoiks such as those opeiateu Ly seivice pioviueis.
Testing policy results
Making a mistake in a ioute-liltei statement can have a uiamatic impact on netwoik
staLility, secuiity, anu oveiall opeiation. Foi example, consiuei the opeiatoi that uoes
not notice that, in the lollowing policy example (appiopiiately calleu whoops), iathei
than auuing the then accept to teim 1, as intenueu, the accept action is mistakenly
auueu as pait ol a linal, unnancd teim. Because this teim has no from statement, it
matches on a|| possiLle ioutes anu iouting souices!
154 | Chapter 5:Protocol Independent Properties and Routing Policy
[edit policy-options]
lab@Wheat# show policy-statement whoops
term 1 {
from {
route-filter 0.0.0.0/0 prefix-length-range /8-/24;
}
}
then accept; ###this action is part of an unnamed match all term!
Applying a Lioken policy such as this in a piouuction netwoik that ueals with multiple
live BGP leeus coulu iesult in netwoik meltuown when all ioutes, iathei than the ex-
pecteu suLset, aie suuuenly auveitiseu within youi netwoik.
]unos soltwaie olleis a test policy leatuie that is uesigneu to avoiu this type ol pioLlem.
You use the test commanu to liltei ioutes thiough the iuentilieu policy to ueteimine
which ioutes aie accepteu (those uisplayeu) veisus iejecteu.
The test policy commanu is piimaiily uselul loi route-filter testing. You cannot test
ioute ieuistiiLution policies, Lecause the uelault policy loi a policy test is to acccpt
a|| piotocol souices. This means that a given ioute liltei policy might match against
static ioutes, Lut the same policy when applieu to BGP may not iesult in the auveitise-
ment ol the same static ioutes. This is Lecause the uelault policy loi BGP uoes not
accept static ioutes, wheieas the uelault loi the test policy uoes. As an example, con-
siuei this policy:
[edit policy-options]
lab@Wheat# show policy-statement test_route_filter
term 1 {
from {
route-filter 0.0.0.0/2 orlonger;
}
then next policy;
}
term 2 {
then reject;
}
Vith the test_route_filter policy shown, the test policy commanu will match on anu
accept static, uiiect, OSPF, BGP, anu ioutes that match the ioute liltei (ioutes in the
iange ol 063), while the same policy applieu to BGP iesults in the auveitisement ol
only BGP ioutes that match the liltei. Again, this is Lecause the matching ioutes aie
not explicitly accepteu Ly the test_route_filter policy in this example, anu woulu
theieloie Le suLjecteu to the uelault policy loi BGP.
A numLei ol static ioutes that iange liom 0192 have Leen auueu to ioutei Wheat. The
test_route_filter policy is iun against these ioutes:
lab@Wheat> test policy test_route_filter 82.137.128.0/18
Policy test_route_filter: 0 prefix accepted, 1 prefix rejected
Routing Policy | 155
The iesult conliims that a pielix outsiue the iange ol 063 is iejecteu:
lab@Wheat> test policy test_route_filter 6.1.0.0/16
inet.0: 815 destinations, 1500 routes (815 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
6.1.0.0/16 *[Static/5] 00:44:51
Discard
Policy test_route_filter: 1 prefix accepted, 0 prefix rejected
This iesult conliims that a pielix insiue the iange ol 063 is accepteu. To test against
all possiLle ioutes, use 0/0:
lab@Wheat> test policy test_route_filter 0/0
inet.0: 815 destinations, 1500 routes (815 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
6.1.0.0/16 *[Static/5] 00:45:05
Discard
6.2.0.0/22 *[Static/5] 00:45:05
Discard
. . .
10.0.0.0/8 *[BGP/170] 20:42:56, localpref 100
AS path: 1282 I
> to 172.16.1.2 via ge-0/0/0.412
[BGP/170] 20:42:44, localpref 80
AS path: 666 1282 I
> to 172.16.2.2 via ge-0/0/0.423
12.0.48.0/20 *[Static/5] 00:45:05
Discard
. . .
Discard
63.207.252.0/22 *[Static/5] 00:45:05
Discard
Policy test_route_filter: 58 prefix accepted, 759 prefix rejected
The output conliims that Loth static anu BGP ioutes aie matching the route-filter in
the test_route_filter policy. Note again that the policy Leing testeu uoes not have an
explicit accept action, anu insteau uses the next policy loi matching ioutes; the ac-
ceptance in this case is the iesult ol the uelault accept-all policy loi the test policy. It`s
woith stating again that the same policy applieu to BGP will auveitise only BGP ioutes
that match the liltei, unless you auu an explicit accept action to the liist teim.
Community and AS path regex matching
Complete coveiage ol iegex matching is outsiue the scope ol this Look. The ieauei
shoulu consult technical uocumentation loi a lull uesciiption ol suppoiteu matching
opeiatois (e.g., http://www.junipcr.nct/tcchpubs/cn_US/junos10.3/topics/usagc-guidc
156 | Chapter 5:Protocol Independent Properties and Routing Policy
|incs/po|icy-conjiguring-as-path-rcgu|ar-cxprcssions-to-usc-as-routing-po|icy-natch
-conditions.htn|, which uesciiLes AS path iegex matching).
Heie aie some geneial things to Le awaie ol when uealing with iegex matching:
Regex matching pioviues a poweilul tool to liltei ioutes Laseu on viitually any
conceivaLle pattein ol AS path oi community attiiLutes.
In ]unos soltwaie, community iegex matching is POSIX 1003.2-compliant. In
contiast, AS path iegex matching is not, Lecause in an AS path iegex, a uot, . (the
wilucaiu chaiactei), iepiesents an entiie AS numLei, iathei than an atom oi spe-
cilic uigit in the AS numLei.
You can test youi iegulai expiession syntax against ioutes a|rcady piesent in the
ioute taLle using a show route community <community-regex> oi show route aspath-
regex <as-path-regex> commanu. Once you leel the expiession syntax iesults in
the matches you expect, you can wiite a policy that uses the same iegex.
To use a community ol AS path iegexes in a policy, you must liist ueline the iegex
using a symLolic name, which is then ieleienceu in the policy.
The lollowing example uemonstiates a Lasic AS path iegex:
[edit policy-options]
lab@PBR# show
policy-statement as_path_filter {
term 1 {
from {
protocol bgp;
as-path sample_as_regex;
}
then reject;
}
}
as-path sample_as_regex "^. 1234 . 1111$";
Note that the symLolic name sample_as_regex is uelineu outsiue ol any paiticulai policy
statement. In this example, the specilieu iegex will match when the associateu ioute
has an AS path consisting ol exactly loui entiies. The AS path can Legin with any AS
numLei, as inuicateu Ly the . wilucaiu (a wilucaiu matches a complete AS numLei in
]unos soltwaie). The seconu AS numLei has to Le 123+ anu can Le lolloweu Ly any
othei AS numLei, Lut the linal AS numLei entiy must Le 1111 to match. The ^ anu $
chaiacteis aie anchois, which loice the initial anu linal matches to Le against the Le-
ginning anu enu ol the line, iespectively.
The as_path_filter policy statement makes use ol the uelineu AS path iegex Ly match-
ing against it in teim 1. Heie the iesult ol an AS path iegex match is iejection.
Heie is a community iegex matching example:
[edit policy-options]
lab@PBR# show
policy-statement community_regex_test {
Routing Policy | 157
term 1 {
from community comm_regex;
then accept;
}
}
community comm_regex members "^(.*):(.*)1:(11.1)(.*):(.*)$";
In this example, the comm_regex expiession is wiitten to match on a seguence ol thiee
community stiings, Lut only when the liist is liom any AS numLei anu any community
value, anu the seconu is liom AS 1 with a community value ol 11x1, wheie the x iep-
iesents any uecimal value Letween 0 anu 9. This example shows that loi community
iegex matching, the . wilucaiu iepiesents a single uigit, iathei than a complete AS
numLei, as was the case with AS path iegex matching. Lastly, a match occuis in this
example only when the liist two matches aie lolloweu Ly a thiiu community value, anu
like the liist, iespectively. Note that Lecause communities aie acteu upon as a single
value, iathei than as a seguence oi set (as is the case with AS matching), you cannot
easily match against a community list Laseu on some specilic count, as you can with
an AS iegex. As a iesult, in this example, the Leginning anu enu ol line maikeis ( anu
$, iespectively), uo not iesult in a match occuiiing when exactly thiee matching com-
munities aie piesent. In lact, in this case, a stiing ol 10 communities will match as long
as any thiee consecutive values match the iegex.
Auuitional uetails anu examples ol community iegex matching aie availaLle at http://
www.junipcr.nct/tcchpubs/cn_US/junos10.3/topics/usagc-guidc|incs/po|icy-dcjining-bgp
-connunitics-and-cxtcndcd-connunitics-jor-usc-in-routing-po|icy-natch-conditions
.htn|=id-1022330.
Policy subroutines (nesting)
Routes that match a given teim in a policy can ieleience anothei policy as the associateu
action. The policy is calleu a policy subroutinc, oi a ncstcd po|icy. This is a poweilul
capaLility that allows you to Luilu mouulai policies that, iathei than Leing applieu as
a policy chain, aie calleu liom within a mastei policy.
A common usage ol a policy suLioutine takes the loim ol a maitian oi Logon liltei.
Rathei than applying the same maitian liltei as pait ol each policy chain, oi iathei than
auuing the complete maitian liltei logic to eveiy policy you wiite, you coulu simply
have a teim in all youi policies that calls the maitian policy as a suLioutine.
The key to ellectively using policy suLioutines lies in unueistanuing the iesult coue
that is hanueu Lack liom the calling policy Ly the calleu policy. Figuie 5-5 illustiates
policy suLioutine Lehavioi.
In Figuie 5-5, things Legin in the uppei lelt, wheie a ioute is hanueu to the nastcr oi
ca||ing po|icy loi evaluation. In this example, the liist teim in the calling policy has a
match ciiteiion specilying from policy <sub-routine-name>. This uiiective evokes the
calleu policy loi ioute evaluation; meanwhile, the main policy suspenus its piocessing
158 | Chapter 5:Protocol Independent Properties and Routing Policy
penuing a iesult coue that is hanueu Lack to the calling policy once the calleu policy
completes its evaluation.
Vhen the calleu policy/suLioutine completes its evaluation, the iesult is eithei a 1 oi
a 0. Heie, the loimei inuicates an accept action Ly the calleu policy, anu the lattei
iepiesents a reject action. Vhen the iesult coue is hanueu Lack to the calling policy,
a 1 is inteipieteu as a positive match, which iesults in the execution ol the calling teim`s
then action. A ietuin ol 0 inuicates no match, anu policy piocessing continues with the
next teim.
Foi ieliaLle opeiation, you must make suie that all policy suLioutines
match a|| ioutes with eithei an accept oi a reject action.
You will encountei inconsistent Lehavioi with policy suLioutines il the
suLioutine is not wiitten to match against a|| possiLle ioutes. This is
Lecause when a ioute is not matcheu, the suLioutine cannot peiloim
an accept oi a reject action, anu theieloie ietuins an empty value to
the calling policy. The lack ol a uelinitive iesult liom the calleu policy
olten leaus to unpieuictaLle opeiation in the calling policy.
Boolean grouping
Ve coveieu the use ol policy chains pieviouslya policy chain is a giouping ol policies
evaluateu in seguence until an accept oi reject action is encounteieu. ]unos soltwaie
also suppoits policy expiessions, which pioviue Boolean giouping lunctionality. This
Iigurc 5-5. Po|icy subroutincs
Routing Policy | 159
is a lancy way to say you can logically AND, OR, oi NOT a given policy. You can linu
uetails on policy expiessions at http://www.junipcr.nct/tcchpubs/cn_US/junos10.3/top
ics/usagc-guidc|incs/po|icy-app|ying-po|icy-cxprcssions-to-routcs-cxportcd-jron-rout
ing-tab|cs.htn|.
By way ol an example, consiuei the lollowing policy:
[edit policy-options]
lab@PBR# show
policy-statement community_regex_test {
term 1 {
from community comm_regex;
then accept;
}
}
community comm_regex members "^(.*):(.*)1:(11.1)(.*):(.*)$";
As pieviously uesciiLeu, this policy matches on, anu as a iesult, accepts ioutes with a
paiticulai community seguence. Vhat uo you expect will Le the iesult il a
community_regex_test policy is applieu as an impoit with a Boolean NOT?
[edit protocols bgp]
lab@PBR# set import (!community_regex_test)
[edit protocols bgp]
lab@PBR# show
import ( ! community_regex_test );
Il you guesseu that all ioutes that weie loimeily accepteu will now Le iejecteu, you aie
coiiect. The Boolean NOT inveits the iesults ol policy evaluation, changing an accept
(1) to a reject (0), anu vice veisa.
As a linal example, consiuei this policy expiession:
[edit protocols ospf]
lab@PBR# show
export ( policy1 && policy2 );
The use ol the logical AND inuicates that loi a ioute to Le expoiteu into OSPF, it must
Le evaluateu as tiue Ly both policy1 anu policy2. Any ioute that is evaluateu as lalse
oi iejecteu Ly eithei policy is not consiueieu viaLle loi expoit into OSPF.
Summary of Routing Policy
Ve just uetaileu ]unos soltwaie iouting policy. The policy liamewoik pioviues a con-
sistent anu easy-to-lathom enviionment loi all ol youi ioute-exchange anu attiiLute-
manipulation neeus. Although ioute lilteis anu the whole ]-Tiee thing can Le a Lit
uaunting when liist encounteieu, the oveiall logic ol a ]unos policy is easy to lollow,
anu the consistent way in which they aie applieu to iouting piotocols makes netwoik
auministiation that much easiei. Vith ]unipei policy iathei than a collection ol net-
woik statements, uelault-inloimation-oiiginate statements, uistiiLute lists, ioute
160 | Chapter 5:Protocol Independent Properties and Routing Policy
maps, anu so on, you cieate anu auveitise a static ioute into OSPF, oi BGP, oi RIP,
using the same appioach anu syntax.
Auvanceu leatuies such as iegex-Laseu AS path anu community matching, policy suL-
ioutines, anu policy expiessions ensuie that you can nevei iun out ol cieative anu
elegant ways to meet youi netwoik`s policy goals.
This section also coveieu the commanus anu pioceuuies useu to monitoi anu ueLug
the opeiation ol youi impoit anu expoit policies.
Conclusion
]unos soltwaie PIPs anu iouting policy may not Le veiy sexy Ly themselves, Lut togethei
they loim the lounuation ol viitually all sophisticateu netwoik conliguiations.
The PIP toolLox pioviues many uselul tools that allow you to cieate static anu aggiegate
ioutes, cieate anu gioup ioute taLles, anu altei piotocol pieleiences. Routing policy
pioviues a poweilul anu consistent set ol iules anu syntax that supplies line-giaineu
contiol ovei the exchange ol ioutes, along with mouilication ol ioute attiiLutes. Once
you unueistanu the Lasic concepts ol impoit anu expoit policy, you guickly come to
appieciate the elegance ol Leing aLle to peiloim similai tasks on uilleient piotocols,
using the same policy liamewoik, iathei than a collection ol mechanisms such as ioute
maps, uistiiLute lists, netwoik statements, anu so on, which may oi may not woik in
a given piotocol context.
Vhen comLineu, PIP anu policy yielu a poweilul mechanism that enaLles you to Lenu
a netwoik`s opeiation to suit youi will. The skills anu concepts coveieu in this chaptei
aie uemonstiateu thioughout the iemainuei ol this Look, in vaiious ieal-woilu anu
piactical scenaiios.
Exam Topics
Ve examineu the lollowing Enteipiise Exam Topics in this chaptei:
PIPs:
Iuentily static, aggiegate, anu geneiateu ioutes.
DesciiLe the conliguiation ol static ioutes.
DesciiLe the puipose ol the uelault ]unos soltwaie ioute taLles.
DesciiLe gloLal ioute pieleience anu the concept ol a lloating static ioute.
Routing policy:
Iuentily the two types ol policy application.
Iuentily policy components (teims, match conuitions, actions, anu policy
chains).
Iuentily points wheie iouting policy may Le applieu.
Exam Topics | 161
DesciiLe the piocessing ol iouting policies.
Evaluate the iesult ol a given iouting policy.
Chapter Review Questions
1. Altei uelining an aggiegate ioute loi 0/0, you note that the M7i`s system Loaiu
CPU utilization incieases. Vhat might account loi this?
A. The uelault ioute is attiacting tiallic that is not specilically matcheu, leauing
to a reject action anu coiiesponuing ICMP eiioi packet geneiation
B. The uelault ioute is attiacting tiallic that is not specilically matcheu, leauing
to uiscaiu anu ICMP eiioi packet geneiation
C. The uelault ioute is attiacting tiallic that matches moie specilic pielixes anu
is Leing loiwaiueu, hence the incieaseu CPU usage
D. The uelault ioute is attiacting tiallic that matches moie specilic pielixes anu
is Leing uioppeu, hence the incieaseu CPU usage
2. Vhich ol the lollowing uelines a lloating static ioute that Lacks up an OSPF ex-
teinally leaineu ioute?
A. Set static ioute 1.1.10/2+, next hop t1-2/0/2
B. Set static ioute 1.1.10/2+, next hop t1-2/0/2, pieleience 11
C. Set static ioute 1.1.10/2+, next hop t1-2/0/2, pieleience 151
D. Set static ioute 1.1.10/2+, next hop t1-2/0/2, gualilieu next hop
E. None ol the aLove
3. You issue the commanu set routing-options autonomous-system loops 3. Vhat
uoes it uo?
A. Toleiates as many as thiee instances ol the local AS numLei in tiansmitteu
ioute upuates
B. Toleiates as many as thiee instances ol the local AS numLei in ieceiveu ioute
upuates
C. Toleiates as many as two instances ol the local AS numLei in tiansmitteu ioute
upuates
D. Toleiates as many as two instances ol the local AS numLei in ieceiveu ioute
upuates
+. Altei uelining a geneiateu ioute loi 10/S, you linu that the ioute is inactive, uespite
having inteilaces that aie locally numLeieu liom the 10.x. x.0/2+ space. Vhat
coulu account loi this?
A. Youi inteilaces aie all multipoint, anu you have not leaineu any ioutes ovei
any ol them, so theie is no loiwaiuing next hop loi the geneiateu ioute
162 | Chapter 5:Protocol Independent Properties and Routing Policy
B. Youi inteilaces aie all point-to-point, anu you have not leaineu any ioutes ovei
any ol them, so theie is no loiwaiuing next hop loi the geneiateu ioute
C. You must ueline an explicit policy to list which ioutes aie alloweu to contiiLute
D. Youi inteilaces aie all multipoint, anu you have leaineu ioutes ovei them,
which makes the geneiateu ioute unneeueu
5. Vhat commanu uisplays the ioute taLle loi a Layei 3 VPN iouting instance nameu
l3_vpn?
A. show route
B. show route table l3_vpn
C. show route table l3_vpn.inet.0
D. All ol the aLove
6. You have conliguieu RIP Letween thiee iouteis connecteu in a seiial chain, Lut no
RIP ioutes aie Leing leaineu. Vhich policy iesults in lull RIP connectivity loi all
uiiect ioutes?
A. A RIP impoit policy ol the loim:
term 1 {
from protocol [ rip direct ];
then accept;
}
B. A RIP expoit policy ol the loim:
term 1 {
from protocol [ rip direct ];
then accept;
}
C. A RIP impoit policy ol the loim:
term 1 {
from protocol direct;
then accept;
}
D. A RIP expoit policy ol the loim:
term 1 {
from protocol direct;
then accept;
}
7. Vhat happens when the static ioute 192.16S.10/2+ is evaluateu Ly this policy?
[edit policy-options policy-statement test]
lab@PBR# show
term 1 {
from {
protocol bgp;
Chapter Review Questions | 163
route-filter 192.168.0.0/16 orlonger reject;
route-filter 192.168.10.0/24 exact {
metric 10;
accept;
}
}
}
A. Nothing, Lecause no match occuis
B. The ioute is longest-matcheu against the liist ioute liltei anu iejecteu
C. The ioute is longest-matcheu against the seconu ioute liltei anu has its metiic
set to 10
D. Both B anu C
S. Vhat happens il the not policy matches a ioute with a ieject action in the lollowing
policy expiession?
[edit protocols ospf]
lab@PBR# show
export (( ! not ) && and );
A. The iesult is inveiteu to an accept, anu the seconu policy is evaluateu
B. The ieject action in the not policy ensuies that the AND conuition cannot Le
met, so the seconu policy is nevei evaluateu
C. Both policies aie evaluateu, anu the logical iesult, which is lalse Lecause ol the
ieject in the not policy, is inveiteu, so the ioute is accepteu
D. None ol the aLove
9. Vhat type ol impoit policy can you apply to OSPF?
A. None; LS piotocols uo not suppoit the notion ol impoit policies Lecause it
Lieaks uataLase consistency
B. You can apply policy to liltei ceitain LSA types, such as AS exteinals to cieate
a stuL aiea
C. Impoit policy loi OSPF can only Le useu to liltei AS exteinal LSAs liom Leing
llooueu
D. Impoit policy loi OSPF can Le useu to pievent installation ol AS exteinal ioutes
into the ioute taLle, Lut has no ellect on lloouing
10. In the lollowing conliguiation, which expoit policy is peei 1.1.1.1 suLjecteu to?
[edit protocols bgp]
lab@PBR# show
import ( ! community_regex_test );
export globalize;
group internal {
export keep_it_on_down_low;
neighbor 1.1.1.1;
neighbor 1.1.1.2 {
164 | Chapter 5:Protocol Independent Properties and Routing Policy
export bad_peer_filter;
}
}
A. The globalize policy
B. The keep_it_on_down_low policy
C. The bad_peer_filter policy
D. The globalize anu keep_it_on_down_low policies
E. Fiist the keep_it_on_down_low, anu then the globalize policy
11. Fiom wheie uoes a ]unipei ioutei oLtain its RID?
A. Fiom explicit conliguiation at the [edit routing-options] hieiaichy
B. Fiom the liist nonmaitian auuiess lounu on the liist inteilace that is lounu
C. Both A anu B
D. Eithei A oi B
12. You weie pioviueu a netwoik uiagiam that tolu you to numLei youi netwoik liom
the 191.255.0.0/16 space. OSPF is enaLleu anu aujacencies aie up, Lut no iouteis
aie leaining any ioutes. Vhat can explain this?
A. The uelault OSPF expoit policies auveitise nothing, so you neeu to apply ex-
poit policy
B. The uelault OSPF impoit policy iejects all OSPF ioutes, so you neeu to apply
impoit policy
C. You neeu to mouily the maitian taLle with a 191.255.0.0/16 accept statement
D. You neeu to enaLle OSPF on the lo0 inteilace to pioviue a ioute to the RID ol
each ioutei in the netwoik
Chapter Review Answers
1. Answei: A. The uelault next hop type loi an aggiegate ioute is reject, which when
matcheu uoes iesult in the M7i`s system Loaiu having to cieate an ICMP eiioi.
Even with iate-limiting saleguaius, these messages consume system piocessing,
Lut not loiwaiuing iesouices.
2. Answei: C. A lloating static neeus to have a pieleience that is less pieleiieu than
the ioute it Lacks up. OSPF exteinals have a pieleience ol 150, so you neeu a value
that is highei; otheiwise, the static ioute will take pieceuence ovei the OSPF ioute.
3. Answei: D. The loops aigument to the autonomous-system statement allects ie-
ceiveu ioute upuates only. Fuithei, whatevei value is specilieu, suLtiact one loi
the numLei ol local AS instances that aie peimitteu. The uelault setting ol 1 will
ieject any ioute with 1 instance ol the local AS numLei.
Chapter Review Answers | 165
+. Answei: A. Point-to-point inteilaces can contiiLute to a geneiateu ioute Lecause
an explicit next hop is not ieguiieu. LAN inteilaces ieguiie some iouteeithei
static oi leaineuto activate an aggiegate oi geneiateu ioute. Policy is useu to
excluue ioutes liom contiiLuting, not to incluue.
5. Answei: D. All ol the commanus listeu will uisplay the Layei 3 VPN instance ioute
taLle. Some aie simply moie veiLose oi moie uiiect Ly uisplaying only the taLle
uesiieu.
6. Answei: B. The uelault RIP impoit policy accepts RIP ioutes. To senu uiiect ioutes,
you neeu the uiiect piotocol, anu to ieauveitise RIP leaineu ioutes, you neeu the
RIP piotocol. The uelault RIP expoit policy is to ieject all.
7. Answei: A. A static ioute can nevei match a liom piotocol BGP conuition, so it
uoes not match the teim. Theie is a logical AND loi uistinct conuitions such as
route-filter anu protocol when listeu unuei the same statement.
S. Answei: A. The negative/ieject iesult ol the not policy is inveiteu, which Lecomes
tiue, anu this enaLles the evaluation ol the seconu policy. Vhen the liist policy is
lalse, a logical AND can nevei Le satislieu, so without the ! lunction, the seconu
policy woulu not Le evaluateu in this case.
9. Answei: D. You cannot use policy to contiol LSA lloouing. Impoit policies can
eithei liltei exteinal ioutes liom the ioute taLle oi assign piioiity to ioutes loi
iecoveiy.
10. Answei: B. Only the most explicit policy is executeu, which in this case is the gioup-
level policy Lecause neighLoi 1.1.1 has no neighLoi-level expoit policy.
11. Answei: D. Theie can Le only one RID in ellect at any time, anu it is uisiuptive to
change it. The ioutei uses an explicit value when piesent; otheiwise, it automati-
cally ueiives one. Theie is no neeu to Le aLle to ioute to the RID, at least not loi
piopei piotocol opeiation.
12. Answei: C. You ieally have to watch those pesky maitians.
166 | Chapter 5:Protocol Independent Properties and Routing Policy
CHAPTER 6
Interior Gateway Protocols and
Migration Strategies
This chaptei ieviews key concepts anu chaiacteiistics ol Inteiioi Gateway Piotocols
(IGPs) commonly ueployeu in enteipiise netwoiks. It staits with a Liiel uesciiption ol
the thiee most common enteipiise IGPs anu pioviues examples ol IGP conliguiation
anu opeiational analysis in a ]unos enviionment. The chaptei also uiscusses cuiient
Lest piactices to minimize netwoik uisiuption when migiating liom one IGP to an-
othei, with conliguiation examples loi Routing Inloimation Piotocol to Open Shoitest
Path Fiist (RIP to OSPF) anu Enhanceu Inteiioi Gateway Routing Piotocol to OSPF
(EIGRP to OSPF) migiation. The topics uiscusseu in this chaptei incluue:
IGP oveiview
RIP ueployment case stuuy
IGP migiation
RIP to OSPF migiation case stuuy
EIGRP migiation case stuuy
Fiom an IGP peispective, a ]unipei Netwoiks ioutei suppoits RIP, the OSPF piotocol,
anu the Inteimeuiate SystemtoInteimeuiate System (IS-IS) iouting piotocols. This
chaptei uoes not auuiess IS-IS, as it is noimally seen in seivice pioviuei netwoiks anu
iaiely is lounu in the enteipiise.
It shoulu Le noteu that ]unipei Netwoiks iouteis uo not suppoit the Cisco Systems
piopiietaiy Inteiioi Gateway Routing Piotocol (IGRP), oi the upuateu veision known
as EIGRP. Technical meiits asiue, licensing iestiictions comLineu with the closeu na-
tuie ol these piotocols pievent ]unipei Netwoiks liom implementing eithei ol these
IGPs. Given that IGRP/EIGRP was commonly ueployeu in many small to meuium-size
enteipiises, a laige poition ol this chaptei locuses on migiation stiategies uesigneu to
ease such a tiansition Letween the two venuois.
167
IGP Overview
As its name woulu imply, the iole ol an IGP is to pioviue iouting connectivity within
oi intcrior to a given iouting uomain (RD). An RD is uelineu as a set ol iouteis unuei
common auministiative contiol that shaie a common iouting piotocol. An enteipiise
netwoik, which can also Le consiueieu an autonomous system (AS), may consist ol
multiple RDs, which may iesult liom the (histoiic) neeu loi multiple iouteu piotocols,
scaling limitations, acguisitions anu meigeis, oi even a simple lack ol cooiuination
among oiganizations making up the enteipiise. Routc rcdistribution, the act ol ex-
changing iouting inloimation among uistinct iouting piotocols, is olten peiloimeu to
tie these RDs togethei when connectivity is uesiieu.
IGP lunctions to auveitise anu leain netwoik pielixes (ioutes) liom neighLoiing iouteis
to Luilu a ioute taLle that ultimately contains entiies loi all souices auveitising ieach-
aLility loi a given pielix. A ioute selection algoiithm is executeu to select the Lest (i.e.,
the shoitest) path Letween the local ioutei anu each uestination, anu the next hop
associateu with that path is pusheu into the loiwaiuing taLle to allect the loiwaiuing
ol packets that longest-match against that ioute pielix. The IGP wants to pioviue lull
connectivity among the iouteis making up an RD. Geneially speaking, IGPs lunction
to piomote, not limit, connectivity, which is why we uo not see IGPs useu Letween
ASsthey lack the auministiative contiols neeueu to limit connectivity Laseu on iout-
ing policy. This is also why intei-AS iouting is noimally accomplisheu using an Exteiioi
Gateway Piotocol (EGP), which touay takes the loim ol Boiuei Gateway Piotocol
(BGP) veision +. Ve uiscuss enteipiise application ol BGP in Chaptei 7.
Vhen netwoik conuitions change, peihaps uue to eguipment lailuie oi management
activity, the IGP Loth geneiates anu ieceives upuates anu iecalculates a new Lest ioute
to the allecteu uestinations. Heie, the concept ol a Lest ioute is noimally tieu to a
ioute metiic, which is the ciiteiion useu to ueteimine the ielative path ol a given ioute.
Geneially speaking, a ioute metiic is signilicant only to the iouting piotocol it`s asso-
ciateu with, anu it is meaninglul only within a given RD. In some cases, a ioutei may
leain multiple paths to an iuentical uestination liom moie than one iouting piotocol.
Given that metiic compaiison Letween two uilleient IGPs is meaningless, the selection
ol the Lest ioute Letween multiple iouting souices is contiolleu Ly a ioute pieleience.
The concept ol ioute pieleience is exploieu in uetail in IGP Migiation: Common
Technigues anu Conceins on page 206 anu is also known as adninistrativc distancc
(AD) on Cisco Systems iouteis.
In auuition to auveitising inteinal netwoik ieachaLility, IGPs aie olten useu to auveitise
iouting inloimation that is exteinal to that IGP`s RD thiough a piocess known as routc
rcdistribution. Route ieuistiiLution is olten useu to exchange iouting inloimation Le-
tween RDs to pioviue intia-AS connectivity. Route ieuistiiLution can Le tiicky Lecause
mistakes can easily leau to lack ol connectivity (Llack holes) oi, woise yet, iouting
loops. To ensuie iuentical loiwaiuing paths, you may also neeu to map the metiics
useu Ly each iouting piotocol to ensuie that they aie meaninglul to the IGP into which
168 | Chapter 6:Interior Gateway Protocols and Migration Strategies
they aie ieuistiiLuteu. Route ieuistiiLution is peiloimeu via iouting policy in ]unos.
Ve use iouting policies latei in this chaptei anu covei them in uetail in Chaptei 5. On
Cisco Systems platloims, ieuistiiLution is olten peiloimeu thiough some comLination
ol the redistribute commanu, thiough uistiiLute lists, oi thiough ioute maps anu theii
associateu IP access lists. Although theie is a leaining cuive, it`s olten a uelight loi those
lamiliai with the IOS way ol peiloiming ieuistiiLution when they iealize that ]unos
iouting policy pioviues the same lunctionality with a consistent set ol semantics/
syntax, loi all piotocols, anu all in one place!
The ieauei ol this Look is assumeu to have an inteimeuiate level unueistanuing ol the
IP piotocol anu the geneial opeiation anu chaiacteiistics ol IGPs that suppoit IP iout-
ing. This section pioviues a ieview ol majoi chaiacteiistics, Lenelits, anu uiawLacks ol
the IGPs uiscusseu in this chaptei to piepaie the ieauei loi the conliguiation anu mi-
giation examples that lollow.
Routing Information Protocol
RIP is one ol the oluest IP iouting piotocols still in piouuction netwoik use anu is a
tiue case ol il something woiks, why lix it? The oiiginal specilication loi RIP
(veision 1) is uelineu in RFC 105S, oiiginally puLlisheu in ]une 19SS! RIP veision 2
(RIPv2) was oiiginally uelineu in RFC 13SS (1993) anu is cuiiently specilieu in RFC
2+53 (199S).
RIP is classilieu as a Distance Vectoi (DV) iouting piotocol Lecause it auveitises ieach-
aLility inloimation in the loim ol uistance/vectoi paiiswhich is to say that each ioute
is iepiesenteu as a cost (uistance) to ieach a given pielix (vectoi) tuple. DV iouting
piotocols typically exchange entiie ioute taLles among theii set ol uiiectly connecteu
peeis, on a peiiouic Lasis. This Lehavioi, although uiiect anu easy to unueistanu, leaus
to many ol the uisauvantages associateu with DV iouting piotocols. Specilically:
Incieaseu netwoik Lanuwiuth consumption stemming liom the peiiouic exchange
ol potentially laige ioute taLles, even uuiing peiious ol netwoik staLility. This can
Le a signilicant issue when iouteis connect ovei low-speeu oi usage-Laseu netwoik
seivices.
Slow netwoik conveigence, anu as a iesult, a piopensity to piouuce iouting loops
when ieconveiging aiounu netwoik lailuies. To alleviate (Lut not eliminate) the
potential loi iouting loops, mechanisms such as split hoiizon, poisoneu ieveise,
ioute holu uowns, anu tiiggeieu upuates aie geneially implementeu. These staLil-
ity leatuies come at the cost ol piolonging conveigence.
DV piotocols aie noimally associateu with ciuue ioute metiics that olten will not
yielu optimal loiwaiuing Letween uestinations. The typical metiic (cost) loi DV
piotocols is a simple hop count, which is a ciuue measuie ol actual path cost, to
say the least. Foi example, most useis iealize lai Lettei peiloimance when ciossing
seveial iouteis inteiconnecteu Ly GigaLit Etheinet links, as opposeu to hall as
many iouteis connecteu ovei low-speeu seiial inteilaces.
IGP Overview | 169
On the upsiue, DV piotocols aie ielatively simple to implement, unueistanu, conliguie,
anu tiouLleshoot, anu they have Leen aiounu jorcvcr, allowing many netwoik engi-
neeis a chance to Lecome piolicient in theii ueployment. The memoiy anu piocessing
ieguiiements loi DV piotocols aie geneially less than those ol a link state (LS) iouting
piotocol (moie on that latei).
To help illustiate what is meant Ly s|ow to convcrgc, consiuei that the piotocol`s ai-
chitects ultimately uelineu a hop count (the numLei ol iouteis that neeu to Le ciosseu
to ieach a uestination) ol 16 to Le inlinity! Given the oiiginal peiloimance ol initial
implementations, the uesigneis Lelieveu that netwoiks ovei 16 hops in uimension
woulu not Le aLle to conveige in a mannei consiueieu piactical loi use in piouuction
netwoiksanu those weie 19S0s netwoiks, loi which uemanuing applications such
as Voice ovei IP weie Lut a uistant gleam in an as yet giaue-school-attenuing C-couei`s
eye. Setting inlinity to a iathei low value was neeueu Lecause in some conuitions, RIP
can conveige only Ly cycling thiough a seiies ol ioute exchanges Letween neighLois,
with each such iteiation incieasing the ioute`s cost Ly one, until the conuition is cleaieu
Ly the metiic ieaching inlinity anu Loth enus linally agiee that the ioute is not ieachaLle.
Vith the uelault 30-seconu upuate lieguency, this conuition is aptly nameu a s|ow
count to injinity.
Stability and performance tweaks
Holu uowns seive to inciease staLility, at the expense ol iapiu conveigence, Ly pie-
venting installation ol a ioute with a ieachaLle metiic, altei that same ioute was iecently
maikeu as unieachaLle (cost = 16) Ly the local ioutei. This Lehavioi helps to pievent
loops Ly keeping the local ioutei liom installing ioute inloimation loi a ioute that was
origina||y auveitiseu Ly the local ioutei, anu which is now Leing rcadvcrtiscd Ly anothei
neighLoi. It`s assumeu that the slow count to inlinity will complete Leloie the holu
uown expiies, altei which the ioutei will Le aLle to install the ioute using the lowest
auveitiseu cost.
Split hoiizon pievents the auveitisement ol iouting inloimation Lack ovei the inteilace
liom which it was leaineu, anu poisoneu ieveise alteis this iule to allow ieauveitisement
Lack out the leaining inteilace, as long as the cost is explicitly set to inlinity: a case ol
I can ieach this uestination, NOT! This helps to avoiu loops Ly making it cleai to
any ieceiving iouteis that they shoulu not use the auveitising ioutei as a next hop loi
the pielix in guestion. This Lehavioi is uesigneu to avoiu the neeu loi a slow count to
inlinity that might otheiwise occui Lecause the explicit inuication that I cannot ieach
uestination X is less likely to leau to misunueistanuings when compaieu to the aLsence
ol inloimation associateu with split hoiizon. To pievent unnecessaiy Lanuwiuth waste
that stems liom Lotheiing to auveitise a pielix that you cannot ieach, most RIP im-
plementations use split hoiizon, except when a ioute is maikeu as unieachaLle, at
which point it is auveitiseu with a poisoneu metiic loi some numLei ol upuate inteivals
(typically thiee).
170 | Chapter 6:Interior Gateway Protocols and Migration Strategies
Tiiggeieu upuates allow a ioutei to geneiate event-uiiven as well as ongoing peiiouic
upuates, seiving to expeuite the iate ol conveigence as changes piopagate guickly.
Vhen comLineu with holu uowns anu split hoiizon, a RIP netwoik can Le saiu to
ieceive Lau news last while goou news tiavels slow.
RIP and RIPv2
Although the oiiginal RIP veision still woiks anu is cuiiently suppoiteu on ]unipei
Netwoiks iouteis, it`s assumeu that ieaueis ol this Look will consiuei ueploying only
RIP veision 2. Although the Lasic opeiation anu conliguiation aie the same, seveial
impoitant Lenelits aie associateu with RIPv2 anu theie aie no ieal uiawLacks (consiu-
eiing that viitually all mouein iouteis suppoit Loth veisions anu that RIPv2 messages
can Le maue Lackwaiu-compatiLle with v1 iouteis, alLeit while losing the Lenelits ol
RIPv2 loi those V1 noues).
RIPv2`s suppoit ol VaiiaLle Length SuLnet Masking/classless inteiuomain iouting
(VLSM/CIDR), comLineu with its aLility to authenticate iouting exchanges, has iesul-
teu in a Lieath ol new lile loi oui olu liienu RIP (pun intenueu). TaLle 6-1 pioviues a
summaiy compaiison ol the two RIP veisions.
Tab|c -1. Conparing charactcristics and capabi|itics oj R|P and R|Pv2
Characteristic RIP RIPv2
Metric Hop count (16 max) Hop count (16 max)
Updates/hold down/route
timeout
30/120/180 seconds 30/120/180 seconds
Max prefixes per message 25 25 (24 when authentication is used)
Authentication None Plain text or Message Digest 5 (MD5)
Broadcast/multicast Broadcast to all nodes using all 1s,
RIP-capable or not
Multicast only to RIPv2-capable routers using
224.0.0.9 (broadcast mode is configurable)
Support for VLSM/CIDR No, only classful routing is supported
(no netmask in updates)
Yes
Route tagging No Yes (useful for tracking a routes source, i.e., internal
versus external)
Open Shortest Path First
The OSPF iouting piotocol cuiiently enjoys wiuespieau use in Loth enteipiise anu
seivice pioviuei netwoiks. Il OSPF can meet the neeus ol the woilu`s laigest netwoik
opeiatois, it`s sale to say that it shoulu Le moie than sullicient loi even the laigest
enteipiise netwoik. OSPF veision 2 is uelineu in RFC 232S, Lut numeious othei RFCs
ueline enhanceu capaLilities loi OSPF, such as suppoit ol not-so-stuLLy aieas
(NSSAs) in RFC 3101, Multipiotocol LaLel Switching (MPLS) Tiallic Engineeiing Ex-
tensions (MPLS TE) in RFC 3630, anu giacelul iestait extensions that minimize uata
IGP Overview | 171
plane uisiuption when a neighLoiing OSPF ioutei iestaits in RFC 3623. OSPF suppoits
viitually all the leatuies any enteipiise coulu uesiie, incluuing VLSM, authentication,
switcheu ciicuit suppoit (suppiesseu hellos), anu MPLS TE extensions, among many
moie.
OSPF is classilieu as an LS iouting piotocol. This is Lecause, unlike a DV piotocol that
exchanges its entiie ioute taLle among uiiectly connecteu neighLois, OSPF exchanges
on|y inloimation aLout the local ioutei`s links, anu these upuates aie llooueu to a||
routcrs in the same aiea. Floouing ensuies that all the iouteis in the aiea ieceive the
new upuate at viitually the same time. The iesult ol this lloouing is a link-state uataLase
(LSDB) that is ieplicateu among all iouteis that Lelong to a given aiea. DataLase con-
sistency is ciitical loi piopei opeiation anu the assuiance ol loop-liee loiwaiuing top-
ologies. OSPF meets this ieguiiement thiough ieliaLle link-state auveitisement (LSA)
exchanges that incoipoiate acknowleugment anu ietiansmission pioceuuies. Each
ioutei peiloims a Shoitest Path Fiist (SPF) calculation Laseu on the Dijkstia algo-
iithm, using itsell as the ioot ol the tiee to compute a shoitest-path giaph containing
noues iepiesenting each ioutei in the aiea, along with its associateu links. The metii-
cally shoitest path to each uestination is then computeu, anu that ioute is placeu into
the ioute taLle loi consiueiation to Lecome an active ioute Ly the path selection
algoiithm.
OSPF auveitises anu upuates pielix inloimation using LSA messages, which aie sent
only upon uetection ol a change in netwoik ieachaLility. LSAs aie also iellooueu pe-
iiouically to pievent theii Leing ageu out Ly othei iouteis. Typically, this occuis some-
wheie Letween 30 anu +5 minutes, given the uelault 3,600-seconu LSA liletime. In
auuition, iathei than senuing an entiie ioute taLle oi uataLase, these LSAs caiiy only
the essential set ol inloimation neeueu to uesciiLe the ioutei`s new LS. Upon sensing
a change in theii local LSDBs, othei iouteis ieiun the SPF anu act accoiuingly.
OSPF uynamically uiscoveis anu maintains neighLois thiough geneiation ol peiiouic
hello packets. An aujacency is loimeu when two neighLois ueciue to synchionize theii
LSDBs to Lecome iouting peeis. A ioutei may choose to loim an aujacency with only
a suLset ol the neighLois that it uiscoveis to help impiove elliciency, as uesciiLeu in
NeighLois anu aujacencies on page 173.
It shoulu Le no wonuei that OSPF has uiamatically impioveu conveigence chaiactei-
istics when one consiueis its event-uiiven lloouing ol small upuates to all iouteis in an
aiea. This is especially tiue when contiasteu to RIP`s peiiou exchange ol the entiie ioute
taLle among uiiectly connecteu neighLois, who then convey that inloimation to theii
neighLois at the next scheuuleu peiiouic upuate.
The uownsiue to all this incieaseu peiloimance is that CPU anu memoiy loau in iouteis
aie incieaseu as compaieu to the same ioutei iunning a DV piotocol. This is Lecause
an LS ioutei has to house both the LSDB anu the iesulting ioute taLle, anu the ioutei
must compute these ioutes Ly executing an SPF algoiithm each time the LSDB changes.
Consiueiing that ioutei piocessing capaLility anu memoiy tenu to inciease, while
172 | Chapter 6:Interior Gateway Protocols and Migration Strategies
actual costs tenu to ueciease loi the same unit ol piocessing powei, these uiawLacks
aie a moie-than-acceptaLle tiaue-oll loi the Lenelit ol ongoing ieuuceu netwoik loau-
ing anu iapiu conveigence. Anothei uiawLack to LS iouting piotocols is theii ielative
complexity when compaieu to DV piotocols, which can make theii opeiation uillicult
to unueistanu, which in tuin can make lault isolation moie uillicult.
OSPF was uesigneu to suppoit Type ol Seivice (ToS)-Laseu iouting, Lut this capaLility
has not Leen ueployeu commeicially. This means that a single ioute taLle is maintaineu,
anu that loi each uestination, a single path metiic is computeu. This metiic is saiu to
Le dincnsion|css in that it seives only to inuicate the ielative goouness oi Launess ol a
path, with smallei numLeis consiueieu to Le Lettei. Exactly what is Lettei cannot Le
ueteimineu liom the OSPF metiic, LSDB, oi iesulting ioute taLle. Vhethei the OSPF
metiic is set to iellect link speeu (uelault), hop count, uelay, ieliaLility, oi some com-
Lination theieol is a mattei ol auministiative policy.
The uelault metiic in ]unos loi OSPF is calculateu Ly taking
100,000,000 anu uiviuing it Ly the Lanuwiuth ol the inteilace. Il the
iesult is less than one, the metiic is one. This numLei can Le aujusteu
Ly auuing the reference bandwidth statement to the conliguiation. A
ieleience Lanuwiuth ol 10G is iecommenueu loi enteipiises that con-
tain high-Lanuwiuth links (gieatei than 100 MLps).
Neighbors and adjacencies
Pieviously, it was noteu that OSPF uynamically uiscoveis neighLois using a peiiouic
exchange ol hello packets. It shoulu also Le noteu that OSPF contains sanity checks
that pievent neighLoi uiscoveiy (anu theieloie, aujacency loimation) when paiameteis
such as the hello time, aiea type, maximum tiansmission unit (MTU), oi suLnet mask
aie mismatcheu. The uesigneis ol the piotocol lelt it was much easiei to tiouLleshoot
a missing aujacency than the potential iesult ol tiying to opeiate with mismatcheu
paiameteis, anu having uealt with moie than a lew misconliguieu OSPF netwoiks, the
piotocol aichitects weie aLsolutely iight.
To maximize elliciency, OSPF uoes not loim an aujacency with
eveiy neighLoi that is uetecteu, Lecause the maintenance ol an aujacency ieguiies
compute cycles anu Lecause on multiaccess netwoiks such as LANs, a lull mesh ol
aujacencies is laigely ieuunuant. On multiaccess netwoiks, an election algoiithm is
peiloimeu to liist elect a uesignateu ioutei (DR), anu then a Lackup uesignateu ioutei
(BDR). The DR lunctions to iepiesent the LAN itsell anu loims an aujacency with the
BDR anu all othei compatiLle neighLois (DRothei) on the LAN segment. The DRothei
iouteis loim two aujacencies acioss the LANone to the DR anu one to the BDR. The
neighLoi state loi DRothei neighLois on a DRothei ioutei itsell is expecteu to iemain
in the two-way state. This simply means that the vaiious DRotheis have uetecteu
each othei as neighLois, Lut an aujacency has not Leen loimeu.
The designated router.
IGP Overview | 173
The DR is iesponsiLle loi lloouing LSAs that iellect the connectivity ol the LAN. This
means that loss ol one neighLoi on a 12-noue LAN iesults in a single LSA that is llooueu
Ly the DR, as opposeu to each iemaining ioutei lloouing its own LSA. The ieuuceu
lloouing iesults in ieuuceu netwoik Lanuwiuth consumption anu ieuuceu OSPF pio-
cessing oveiheau. Il the DR lails, the BDR will take ovei anu a new BDR is electeu.
OSPF elects a DR anu BDR Laseu on a piioiity setting, with a lowei value inuicating a
lessei chance at winning the election; a setting ol 0 pievents the ioutei liom evei Le-
coming the DR. In the event ol a tie, the ioutei with the highest ioutei ID (RID) takes
the piize. The OSPF DR Election algoiithm is nonueteiministic anu nonieveitive,
which means that auuing a new ioutei with a highei, moie pieleiieu piioiity uoes not
iesult in the oveithiow ol the existing DR. In othei woius, ioutei piioiity matteis only
uuiing active DR/BDR election. This Lehavioi minimizes the potential loi netwoik
uisiuption/LSA lloouing when new iouteis aie auueu to the netwoik. Thus, the only
way to guaiantee that a given ioutei is the DR is to eithei uisaLle DR capaLility in all
othei iouteis (set theii piioiity to 0), oi ensuie that the uesiieu ioutei is poweieu on
liist anu nevei ieLoots. Vheie possiLle, the most staLle anu poweilul ioutei shoulu Le
maue the DR/BDR, anu a ioutei shoulu iueally Le the DR loi only one netwoik segment.
OSPF router types
OSPF uesciiLes vaiious ioutei ioles that govein theii opeiation anu impact the types
ol aieas in which they aie peimitteu. To Lecome piolicient with OSPF opeiation anu
netwoik uesign, you must have a cleai unueistanuing ol the uilleiences Letween OSPF
aiea types anu Letween the LSAs peimitteu within each aiea:
|ntcrna| routcr
Any ioutei that has all its inteilaces containeu within a single aiea is an inteinal
ioutei. Il attacheu to the LackLone aiea, the ioutei is also known as a LackLone
ioutei.
Bac|bonc routcr
Any ioutei with an attachment to aiea 0 (the LackLone aiea) is consiueieu a Lack-
Lone ioutei. This ioutei may also Le an inteinal oi aiea Loiuei ioutei, uepenuing
on whethei it has links to othei, nonLackLone aieas.
Arca bordcr routcr (ABR)
A ioutei with links in two oi moie aieas is an ABR. The ABR is iesponsiLle loi
connecting OSPF aieas to the LackLone Ly conveying netwoik summaiy inloima-
tion Letween the LackLone anu nonLackLone aieas.
Antonynous systcn boundary routcr (ASBR)
A ioutei that injects exteinal iouting inloimation into an OSPF uomain is an ASBR.
Areas and LSAs
As pieviously noteu, LS piotocols lloou LSAs to all iouteis in the same aiea in oiuei to
cieate a ieplicateu LSDB liom which a ioute taLle is ueiiveu thiough execution ol an
174 | Chapter 6:Interior Gateway Protocols and Migration Strategies
SPF algoiithm. The inteiplay ol these piocesses can leau to a uownwaiu-scaling spiial
in laige netwoiks, especially when theie aie laige numLeis ol unstaLle links.
As the numLei ol iouteis anu ioutei links within an aiea giows, so too uoes the size ol
the iesulting LSDB. In auuition, moie links means a gieatei likelihoou ol an inteilace
oi ioute llap, which leaus to gieatei neeu loi lloouing ol LSAs. The incieaseu pioLaLility
ol LSDB chuin leaus to an incieaseu lieguency ol the SPF calculations that must Le
peiloimeu each time the LSDB changes (Laiiing any SPF holu uowns loi Lack-to-Lack
LSA change events). These conuitions comLine to loim the uownwaiu spiial ol in-
cieaseu lloouing, laigei uataLases, moie lieguent SPF iuns, anu a laigei piocessing
Luiuen pei SPF iun, uue to the laige size ol the LSDB.
But uon`t leai: OSPF tackles this pioLlem thiough the suppoit ol aieas, which pioviues
a hieiaichy ol LSDBs. As a iesult, LSA lloouing is now constiaineu to each aiea, anu
no one ioutei has to caiiy LS loi the entiie RD. Because each aiea is associateu with its
own LSDB, a multiaiea OSPF netwoik will, loi the aveiage ioutei, iesult in a smallei
LSDB. Each ioutei must maintain an LSDB only loi its attacheu aieas, anu no one
ioutei neeu attach to eveiy aiea. This is a key point, Lecause in theoiy it means OSPF
has almost unlimiteu scaling potential, especially when compaieu to nonhieiaichical
piotocols such as Cisco`s EIGRP oi RIP. In auuition, with lewei iouteis anu links, theie
is a ieuuceu likelihoou ol having to lloou upuateu LSAs, which in tuin means a ieuuceu
numLei ol SPF iuns aie neeueuwhen an SPF iun is neeueu, it is now executeu against
a smallei LSDB, which yielus a win-win loi all involveu.
Routeis that connect to multiple aieas aie calleu ABRs anu maintain an LSDB loi each
aiea to which they attach. An ABR has a gieatei piocessing Luiuen than an inteinal
ioutei, Ly viitue ol maintaining multiple LSDBs, Lut the piocessing Luiuen associateu
with two small LSDBs can still Le consiueiaLly less than that associateu with a single,
laige uataLase, loi ieasons citeu eailiei. It is common to ueploy youi most poweilul
iouteis to seive the iole ol ABRs, Lecause these machines will geneially have to woik
haiuei than a puiely inteinal ioutei, given that they must maintain an LSDB pei at-
tacheu aiea, anu have the gieatei chance ol a iesulting SPF calculation. Howevei, the
tiaue-oll is Leing aLle to use smallei, less poweilul iouteis within each aiea (inteinal
iouteis), Lecause ol the ieuuceu LSDB size that iesults liom a hieiaichical OSPF uesign.
Inteiestingly, OSPF is tiuly link-state on|y within a single aiea uue to the scope ol LSA
lloouing Leing conlineu to a single aiea. An ABR iuns SPF loi each attacheu aiea`s
LSDB anu then summaiizes its intiaaiea LS costs into othei aieas in DV-like lashion.
This Lehavioi is the ieason OSPF ieguiies a LackLone aiea that is uesignateu as aiea 0
geneially speaking, each ABR geneiates anu ieceives summaiies on|y liom the Lack-
Lone, which exists to pioviue a loop-liee enviionment ovei which these summaiies can
Le exchangeu. Put anothei way, the LackLone seives to pievent loop loimation that
coulu iesult liom the inloimation that is hiuuen Ly ABRs when they summaiize the
contents ol theii nonLackLone aiea LSDBs into simple uistance/vectoi paiis. A ioutei
ieceiving a summaiy auveitisement uses SPF against that aiea`s LSDB to compute the
shoitest path to the ioutei that geneiateu the summaiy auveitisement, anu then it
IGP Overview | 175
simply auus the summaiy cost, as oiiginally calculateu Ly the auveitising ioutei, to
oLtain the total path cost.
Having saiu all this, it is not unheaiu ol to see laige, gloLally spanning OSPF netwoiks
consisting ol hunuieus ol iouteis successlully ueployeu within a single OSPF aiea.
Theie simply aie no haiu iules iegaiuing the age-olu guestion ol how many iouteis
can I put into a single aiea, Lecause too many vaiiaLles exist. In auuition to a simple
ioutei count, one must also consiuei lactois such as link count, link staLility, ioutei
piocessing powei, the peicentage ol exteinal veisus inteinal LSAs, anu the geneial
ioLustness ol the piotocol`s implementation. The signilicance ol the lattei shoulu not
Le unueiestimateu. A pooily implementeu OSPF instance iunning on the woilu`s last-
est haiuwaie will likely not peiloim veiy well, unless, ol couise, you consiuei the num-
Lei ol coie liles uumpeu anu/oi ieLoots pei unit ol time, which is a signilicant IGP
Lenchmaik. Seiiously, it`s Lau enough when one netwoik noue keeps iolling ovei to
play ueau, Lut it`s woise when instaLility in a single noue iapiuly iipples out to allect
the opeiation ol othei iouteis, even those with well-Lehaveu coue.
OSPF uelines seveial uilleient aiea types. To tiuly unueistanu OSPF
opeiation, you must have a cleai unueistanuing ol the uilleiences Letween OSPF aiea
types, anu Letween the LSAs peimitteu within each aiea:
Bac|bonc
To ensuie loop-liee connectivity, OSPF maintains a special aiea calleu the Lack-
Lone aiea, which shoulu always Le uesignateu as aiea 0. All othei OSPF aieas
shoulu connect themselves to the LackLone loi inteiaiea connectivity; noimally,
inteiaiea tiallic tiansits the LackLone.
Stub
StuL aieas uo not caiiy AS exteinal auveitisements, with the goal Leing a ieuuction
ol LSDB size loi inteinal iouteis within that stuL aiea. Because iouteis in a stuL
aiea see only LSAs that auveitise iouting inloimation liom within the OSPF RD, a
uelault ioute is noimally injecteu to pioviue ieachaLility to exteinal uestinations.
StuL aiea iouteis use the metiically closest ABR when loiwaiuing to AS exteinal
pielixes.
Tota||y stubby arca
A totally stuLLy aiea is a stuL aiea that on|y ieceives the uelault ioute liom the
LackLone. Routeis in the totally stuLLy aiea uo not see OSPF inteinal ioutes liom
othei OSPF aieas. Theii LSDBs iepiesent theii own aiea anu the injecteu uelault
ioute, which is now useu to ieach Loth AS exteinal anu inteiaiea uestinations.
NSSAs
As noteu pieviously, an OSPF stuL aiea uoes not caiiy exteinal ioutes, which
means you cannot ieuistiiLute ioutes into a stuL aiea Lecause ieuistiiLuteu ioutes
aie always tieateu as AS exteinals in OSPF. An NSSA Lenus this iule anu allows a
special loim ol exteinal ioute within the NSSA. Although an NSSA can oiiginate
AS exteinals into OSPF, exteinal ioutes liom othei aieas aie still not peimitteu
OSPF area types.
176 | Chapter 6:Interior Gateway Protocols and Migration Strategies
within the NSSA. This is a case ol having one`s cake (small LSDB uue to not Leing
Luiueneu Ly exteinals liom othei aieas) while eating it, too (Leing alloweu to Lui-
uen othei iouteis with the exteinal ioutes you choose to geneiate). The NSSA`s
ABRs can tianslate the special loim ol exteinal ioute useu in an NSSA loi lloouing
ovei the iest ol the OSPF uomain. NSSAs can Le conliguieu to ieceive only a uelault
ioute liom the ABR, Lecoming a Totally Not So StuLLy Aiea. Vho saiu the stanu-
aius Louies uo not have a sense ol humoi?
Transit arcas
Tiansit aieas pass tiallic liom one aujacent aiea to the LackLone oi to anothei aiea
il the LackLone is moie than two hops away liom an aiea.
LSAs aie the woikhoise ol OSPF in that they aie useu to lloou inloi-
mation iegaiuing netwoik ieachaLility anu loim the Lasis ol the iesulting LSDB. Ta-
Lle 6-2 uesciiLes the LSA types useu Ly mouein OSPF netwoiks. It Leais iestating that
a tiue unueistanuing ol OSPF ieguiies knowleuge ol what type ol iouting inloimation
is caiiieu in a given LSA, in auuition to unueistanuing each LSA`s lloouing scope. Foi
example, an LSA with aiea scope is nevei seen outsiue the aiea liom which it was
geneiateu, wheieas an LSA with gloLal scope is llooueu thioughout the entiie OSPF
RD, Laiiing any aiea type iestiictions; that is, AS exteinals aie nevei peimitteu within
a stuL aiea. Figuie 6-1 pioviues a giaphical summaiy ol the puipose anu scope ol the
most common LSA types.
Tab|c -2. Connon OSPI LSA typcs
LSA type Generated by/contents/purpose
Flooding
scope
Type 1, router Generated by all OSPF routers, the Type 1 LSA describes the status and cost of the routers
links.
Area
Type 2,
network
Generated by the DR on a LAN, the Type 2 LSA lists each router connected to the broadcast
link, including the DR itself.
Area
Type 3, network
summary
Generated by ABRs, Type 3 LSAs carry summary route information between OSPF areas.
Typically, this information is exchanged between a nonbackbone area and the backbone
area, or vice versa. Type 3 LSAs are not reflooded across area boundaries; instead, a receiving
ABR generates its own Type 3 LSA summarizing its interarea routing information into any
adjacent areas.
Area
Type 4, ASBR
summary
Each ABR that forwards external route LSAs must also provide reachability information for
the associated ASBR so that other routers know how to reach that ASBR when routing to
the associated external destinations. The Type 4 LSA provides reachability information for
the OSPF domains ASBRs. As with Type 3 LSAs, each ABR generates its own Type 4 when
flooding external LSAs into another area.
Area
Type 5, AS
external LSA
Generated by ASBRs, the Type 5 LSA carries information for prefixes that are external to
the OSPF RD.
Global,
except for
stub areas
Primary LSA types.
IGP Overview | 177
LSA type Generated by/contents/purpose
Flooding
scope
Type 7, NSSA Generated by ASBRs in an NSSA, the Type 7 LSA advertises prefixes that are external to
the OSPF RD. Unlike the Type 5 LSA, Type 7 LSAs are not globally flooded. Instead, the
NSSAs ABR translates Type 7 LSAs into Type 5 for flooding throughout the RD.
Area
Type 9, 10, and
11, opaque LSAs
Generated by enabled OSPF routers to carry arbitrary information without having to define
new LSA types, the Type 9 LSA has link scope and is currently used to support graceful
restart extensions, whereas the Type 10 LSA has area scope and is used for MPLS TE support.
Type 9, link;
Type 10, area;
Type 11,
global scope
Iigurc -1. OSPI LSA typcs and scopc
OSPF stability and performance tweaks
Bieaking a laige OSPF uomain into multiple aieas can have a signilicant impact on
oveiall peiloimance anu conveigence. In auuition, most OSPF implementations sup-
poit vaiious timeis to luithei tune anu tweak the piotocol`s opeiation.
The ]unipei Netwoiks OSPF implementation is guite optimizeu anu lacks many ol the
timeis anu holu uowns that ieaueis may Le lamiliai with in IOS. It is not uncommon
178 | Chapter 6:Interior Gateway Protocols and Migration Strategies
D
o
to see useis new to ]unipei asking loi ]unos analogs anu ieceiving the stanuaiu answei
that they uo not exist Lecause they aie not neeueu. The uevelopment engineeis at
]unipei leel that aitilicially uelaying tiansmission ol an LSAostensiLly to alleviate
the piocessing Luiuen associateu with its ieceiptuoes nothing except piolong net-
woik conveigence.
TaLle 6-3 maps OSPF-ielateu knoLs liom IOS to theii ]unos eguivalent, when availaLle.
Tab|c -3. |OS vcrsus junos OSPI tincrs
IOS name Junos OS name Comment
carrier-delay (0) hold-time (0) Delay notification of interface up/down events to
damp interface transitions. Default is 0, but notifica-
tion times can vary based on interrupt versus polled.
timers throttle spf (spf-start,
spf-hold, spf-max-wait)
spf-delay
(200)
Control the rate of SPF calculation. In Junos, the value
is used for as many as three back-to-back SPF runs,
and then a 5-second hold down is imposed to ensure
stability in the network.
timers throttle lsa all (lsa-
start, lsa-hold, lsa-max((0, 5000,
5000)))
N/A By default, Junos sends 3 back-to-back updates with
a 50 msec delay, and then a five-second hold down.
timers lsa arrival N/A Controls the minimum interval for accepting a copy
of the same LSA.
timers pacing flood (33 msec) transmit-
interval
(30 msec)
Delay back-to-back LSA transmissions out the same
interface.
ispf N/A Enable incremental SPF calculations; Junos does not
support ISPF but does perform partial route calcula-
tions when the ospf topology is stable and only routing
information changes.
The ]unos OS has auueu an auuitional optimization in the loim ol a peiiouic packet
management piocess uaemon (ppmu) that hanules the geneiation anu piocessing ol
OSPF (anu othei piotocol) hello packets. The goal ol ppmu is to peimit scaling to laige
numLeis ol piotocol peeis Ly ollloauing the munuane piocessing tasks associateu with
peiiouic packet geneiation. The ppmu piocess can iun uiiectly in the PFE to ollloau
RE cycles on application-specilic integiateu ciicuit (ASIC)-Laseu systems such as
the M7i.
In auuition to the aloiementioneu timeis, Loth venuois also suppoit Biuiiectional Foi-
waiuing Detection (BFD), which is a iouting-piotocol-agnostic mechanism to pioviue
iapiu uetection ol link lailuies, as opposeu to waiting loi an OSPF aujacency timeout.
Note that inteilace holu time comes into play only when a physical layei lault is ue-
tecteu, as opposeu to a link-level issue such as can occui when two iouteis aie
connecteu via a LAN switch, wheie the local inteilace status iemains up even when a
physical lault occuis on the iemote link. As ol this wiiting, IOS suppoit loi BFD is
IGP Overview | 179
limiteu anu vaiies Ly platloim anu soltwaie ielease; Cisco Systems iecommenus that
you see the Cisco IOS soltwaie ielease notes loi youi soltwaie veision to ueteimine
suppoit anu applicaLle iestiictions.
Enhanced Interior Gateway Routing Protocol
The EIGRP is an upuateu veision ol Cisco Systems` piopiietaiy IGRP. The oiiginal
veision ol EIGRP hau staLility issues, piompting the ielease ol EIGRP veision 1, staiting
in IOS veisions 10.3(11), 11.0(S), anu 11.1(3). This chaptei locuses stiictly on EIGRP
Lecause it has laigely uisplaceu IGRP in mouein enteipiise netwoiks.
EIGRP is sometimes saiu to Le a DV piotocol that thinks it`s an LS. EIGRP uoes in
lact shaie some ol the chaiacteiistics noimally associateu with LS iouting, incluuing
iapiu conveigence anu loop avoiuance, Lut the lack ol LSA lloouing anu the aLsence
ol the iesulting LSDB expose EIGRP`s tiue DV natuie. This section highlights the majoi
opeiational chaiacteiistics anu capaLilities ol EIGRP. The goal is not an exhaustive
tieatment ol EIGRP`s opeiation oi conliguiationthis suLject has Leen coveieu in
numeious othei wiitings. Insteau, the puipose heie is to unueistanu EIGRP to the
uegiee necessaiy to ellectively ieplace this piopiietaiy legacy piotocol with anothei
IGP, while maintaining maximum netwoik availaLility thioughout the piocess.
The opeiational chaiacteiistics ol EIGRP aie as lollows:
It uses nonpeiiouic upuates that aie paitial anu Lounueu. This means that unlike
typical DV piotocol opeiation, EIGRP geneiates on|y tiiggeieu upuates, that these
upuates iepoit on|y allecteu pielixes, anu that the upuates aie sent to a Lounueu
set ol neighLois.
It uses a Dillusing Upuate Algoiithm (DUAL) to guaiantee a loop-liee topology
while pioviuing iapiu conveigence. The specilics ol DUAL opeiation aie outsiue
the scope ol this Look; sullice it to say that DUAL is the muscle Lehinu EIGRP`s
iapiu conveige anu loop guaiantees.
It uses a composite metiic that, Ly uelault, lactois uelay anu thioughput. Also, it
suppoits the lactoiing ol uynamically vaiying ieliaLility anu loauing, Lut useis aie
cautioneu not to use this capaLility. EIGRP uses the same metiic loimula as IGRP,
Lut it multiplies the iesult Ly 256 loi gieatei gianulaiity.
It suppoits VLSM/CIDR anu automatic summaiization at classlul Lounuaiies Ly
uelault.
It suppoits unegual cost loau Lalancing using a variancc knoL.
It suppoits neighLoi uiscoveiy anu maintenance using multicast.
It automatically ieuistiiLutes to IGRP when piocess numLeis aie the same.
It leatuies piotocol-inuepenuent mouules loi common lunctionality (ieliaLle
tianspoit ol piotocol messages).
180 | Chapter 6:Interior Gateway Protocols and Migration Strategies
It leatuies piotocol-uepenuent mouules loi IP, IPX, anu AppleTalk that pioviue
multipiotocol iouting via the constiuction ol sepaiate ioute taLles using piotocol-
specilic iouting upuates.
At liist glance, the multipiotocol capaLilities ol EIGRP may seem enticing. Altei all,
this lunctionality cannot Le matcheu Ly touay`s standardizcd iouting piotocols. Theie
was a time when many enteipiise LackLones weie in lact iunning multiple netwoik
piotocols, anu the luie ol a single, high-peiloimance IGP instance that coulu hanule
the thiee most common netwoik suites was haiu to iesist. Howevei, theie has Leen an
unmistakaLle tienu towaiu IP tianspoit loi viitually all inteinetwoiking suites, incluu-
ing IBM`s SNA/SAA. (Ve have a haiu time iecalling the last time we knew ol an
enteipiise still ueploying the native Netwaie oi AppleTalk tianspoit piotocols.) In
contiast, these piopiietaiy-iouteu piotocols aie Leing phaseu out in lavoi ol native IP
tianspoit, which seives to ienuei EIGRP`s multipiotocol leatuies moot in this mouein
age ol |P inteinetwoiking.
EIGRP can loau-Lalance acioss paths that aie not egual in cost, Laseu on a vaiiance
setting, which ueteimines how much laigei a path metiic can Le as compaieu to the
minimum path metiic, while still Leing useu loi loau Lalancing. This chaiacteiistic
iemains unigue to IGRP/EIGRP, as neithei RIP noi OSPF suppoits unegual cost loau
Lalancing.
EIGRP metrics
EIGRP uses a composite metiic that lacks a uiiect coiollaiy in stanuaiuizeu IGPs.
EIGRP metiics tenu to Le laige numLeis. Although pioviuing gieat gianulaiity, these
huge numLeis iepiesent a ieal issue loi a piotocol such as RIP, which sees any metiic
gieatei than 16 as inlinity. It`s guite unlikely that any enteipiise woulu migiate liom
EIGRP to RIP anyway, given the ielatively pooi peiloimance ol RIP anu the wiuespieau
availaLility ol OSPF on mouein netwoiking uevices, so such a tiansition scenaiio is not
auuiesseu in this chaptei.
Foi ieleience, the loimula useu Ly EIGRP to calculate the metiic is:
Metiic = K1 Bw - K2 Bw/(256 Loau) - K3 Delay K5/(ReliaLility - K+)
Although the MTU is not useu in the calculation ol the metiic, it is tiackeu acioss the
path to iuentily the minimum path MTU. The K paiameteis aie useu to weigh each ol
the loui components that lactoi into the composite metiicnamely, Lanuwiuth, loau,
uelay, anu ieliaLility. The uelault values loi the weighing iesult in only K1 anu K3 Leing
nonzeio, which gives the uelault loimula ol Bw - Delay loi the metiic.
Note that Cisco Systems uoes not iecommenu usei aujustment ol the
metiic weighting. So, in piactical teims, EIGRP`s metiic is a 32-Lit
guantity that iepiesents the path`s cumulative uelay (in tens ol micio-
seconus) anu the path`s minimum thioughout in KL/s, uiviueu Ly 10
7
(scaleu anu inveiteu).
IGP Overview | 181
Foi EIGRP, the iesult is then multiplieu Ly 256 to conveit liom IGRP`s 2+-Lit metiic
to EIGRP`s 32-Lit metiic. It shoulu Le oLvious that one cannot peiloim a simple one-
to-one mapping ol legacy EIGRP metiics to OSPF, given that EIGRP suppoits a 32-Lit
metiic anu OSPF`s is only 16-Lit. This is not a signilicant shoitcoming in piactice, given
that lew enteipiise netwoiks aie composeu ol enough paths to waiiant + Lillion levels
ol metiic gianulaiity anyway!
Figuie 6-2 shows an example netwoik to help illustiate how EIGRP calculates a path
metiic.
Iigurc -2. E|GRP nctric cxanp|c
Using the uelault composite metiic weighting loi the topology shown in Figuie 6-2,
ioutei r1`s metiic to ieach 10.0.3.0/2+ is computeu Laseu on the minimum Lanuwiuth
anu the sum ol the path uelay, using the loimula:
Metiic = 256 (10
7
/minBV KLs) - (uelay sum usec/10)
Plugging in the specilics loi this example yielus a path metiic ol 3,S70,976 loi the path
to 10.0.3.0/2+, liom the peispective ol r1:
Metiic = 256 (10
7
/76S) - (20,000 - 1,000 /10)
Metiic = 256 (13021) - (2100)
Metiic = 256 15121
Metiic = 3,S70,976
By way ol compaiison, the same netwoik iunning OSPF with ]unos uelaults loi OSPF
ieleience Lanuwiuth yielus a path metiic ol only 137! A key point heie is that although
137 is ceitainly much smallei than the 3,S70,976 value computeu Ly EIGRP, the iange
ol OSPF metiics, liom 1 to 65,53+, shoulu Le moie than sullicient to uilleientiate
among the numLei ol links/paths availaLle in even the laigest enteipiise netwoik.
Also, iecall that the OSPF metiic is saiu to Le uimensionless, which is to say that a
smallei value is always pieleiieu ovei laigei values, Lut the exact natuie ol what is
smallei is not conveyeu in the metiic itsell. By uelault, OSPF ueiives its metiic liom
inteilace Lanuwiuth using a scaling lactoi, Lut the scaling lactoi can Le alteieu, anu
the metiic can Le auministiatively assigneu to iellect any paiametei chosen Ly the
auministiatoi. Vhen all is saiu anu uone, as long as a consistent appioach is auopteu
when assigning OSPF metiics, the iight thing shoulu just happen. By way ol example,
182 | Chapter 6:Interior Gateway Protocols and Migration Strategies
consiuei a case wheie OSPF metiics aie assigneu Laseu on the economic costs ol a
usage-Laseu netwoik seivice. The iesultant shortcst path measuies uistance as a lunc-
tion ol economic impact anu will iesult in optimization Laseu on the least expensive
paths Letween any two points. Thus, OSPF has uone its joL Ly locating the shortcst
path, which in this example means the |cast cxpcnsivc path, given that the auministia-
tion consiueis uistance to eguate to money. Ve ievisit the suLject ol EIGRP to OSPF
metiic conveisions in EIGRP-to-OSPF Migiation Summaiy on page 2+3.
EIGRP: A grand past and a dubious future
It`s woith iestating that, unlike open stanuaius piotocols such as RIP anu OSPF, EIGRP
is piopiietaiy to Cisco Systems. As a iesult, only Cisco Systems piouucts can speak
EIGRP, Loth Lecause ol the closeu natuie ol the specilication anu Lecause ol the li-
censing anu patent issues that pievent otheis liom implementing the piotocol. Most
enteipiise customeis (anu seivice pioviueis, loi that mattei) pielei not to Le lockeu
into any solution that is souiceu liom a single venuoi, even one as laige anu uominant
as Cisco Systems.
EIGRP`s lack ol hieiaichical suppoit signilicantly limits its use in laige-scale netwoiks
Lecause ol scaling issues. EIGRP lacks the piotocol extensions neeueu to Luilu a tiallic
engineeiing uataLase (TED), as useu to suppoit MPLS applications. Although MPLS
is still somewhat iaie in the enteipiise, it cuiiently enjoys signilicant momentum anu
is in wiuespieau use within seivice pioviuei netwoiks acioss the gloLe. Consiueiing
that many ol the ieguiiements ol seivice pioviueis thiee oi loui yeais ago aie the same
ieguiiements that we aie seeing in the enteipiise touay, an enteipiise woulu Le wise to
heuge its Lets Ly auopting piotocols that can suppoit this impoitant technology, shoulu
the neeu latei aiise.
Suppoit is an impoitant lactoi that must Le consiueieu when ueploying any piotocol.
At one point, it was uillicult to linu oll-the-shell oi open souice piotocol analysis loi
IGRP/EIGRP. Cisco coulu change the specilication at any time, making oLsolete any
such tools that exist. At the time ol this wiiting, the Viieshaik analysis piogiam lists
EIGRP suppoit; howevei, it`s uillicult to conliim the uecoue accuiacy without an open
stanuaiu to ieleience against.
Given the uiawLacks to a single-venuoi closeu solution, an enteipiise shoulu consiuei
the use ol open stanuaiu piotocols. In the case ol IGPs, you gain highei peiloimance,
venuoi inuepenuence, anu oll-the-shell suppoit capaLilities. EIGRP`s multipiotocol
capaLility asiue, the laigest IP netwoiks on the planet (those ol Inteinet seivice
pioviueis ISPs) geneially iun OSPF. Seivice pioviuei netwoiks aie all aLout ieliaLility,
staLility, iapiu conveigence at a laige scale, anu the aLility to ollei seivices that iesult
in ievenue geneiationgiven these IGP ieguiiements, the ieauei is lelt to ponuei why
seivice pioviuei netwoiks aie nevei lounu to Le iunning EIGRP within theii netwoiks.
IGP Overview | 183
IGP Summary
IGPs pioviue the inuispensaLle seivice ol maintaining inteinal connectivity thioughout
the myiiau link anu eguipment lailuies possiLle in mouein IP inteinetwoiks. IGP pei-
loimance anu staLility in the lace ol laige volumes ol netwoik change can pioviue a
stiategic euge Ly guickly iouting aiounu pioLlems to maintain the highest uegiee ol
connectivity possiLle.
This section oveivieweu the RIP, OSPF, anu EIGRP piotocols to piepaie the ieauei loi
the lollowing ueployment anu IGP migiation scenaiios. Now is a goou time to take a
Lieak Leloie you heau into the RIP ueployment case stuuy that lollows.
RIP Deployment Scenario
OK, that`s enough ol an IGP oveiview. Theie`s little uouLt that the ioutei-jockey ieau-
eis ol this Look aie champing at the Lit to stait iouting some packets! Let`s uemonstiate
Lasic RIP conliguiation anu opeiational moue commanus that assist in tiouLleshooting
a RIP opeiation in a ]unos enviionment.
Figuie 6-3 uepicts the topology loi the Cisco Systems/IOS to ]unipei Netwoiks/]unos
RIP integiation scenaiio. It shows the existing Beei-Co RIP netwoik, which cuiiently
consists ol two Cisco Systems 2600 seiies iouteis iunning IOS veision 12.3(15L) anu
inteiconnecteu Ly a seiial link. Beei-Co is expanuing its wiuget opeiation anu plans to
auu two auuitional locations. Despite the existing inliastiuctuie, the CIO has opteu to
Lecome a multivenuoi shop, anu a uecision has Leen maue to ueploy two ]unipei Net-
woiks ]-seiies iouteis. The existing (anu planneu) IP auuiessing is shown anu contains
a mix ol suLnetteu class A anu class C auuiesses (just to keep things inteiesting). Each
ioutei`s loopLack auuiess is also shown, along with a simulateu customei netwoik that
is instantiateu via a static ioute (laLs commonly use a static ioute to iepiesent a cus-
tomei netwoik loi puiposes ol ieuucing eguipment ieguiiements). Note that the last
uigit ol each ioutei`s loopLack auuiess is tieu numeiically to that ioutei`s simulateu
customei netwoik to help ease ieguiiements on the ieauei`s memoiy.
As a ieminuei, iecall that in this laL, each ioutei`s Fast Etheinet inteilace is tieu to a
viitual LAN (VLAN) switch, anu VLAN tags aie useu to estaLlish links Letween com-
municating iouteis. The suLinteilace/logical unit ol each inteilace match the associateu
VLAN tag value, which is also shown in the liguie. You may assume that all ioutei
inteilace piopeities aie coiiectly conliguieu to peimit communication with uiiectly
attacheu neighLois. The lollowing coue snippets show the Fast Etheinet inteilace con-
liguiation at Cisco ioutei Malt anu ]unipei ioutei Ale.
184 | Chapter 6:Interior Gateway Protocols and Migration Strategies
Iigurc -3. R|P topo|ogy
Malt`s FastEthernet0/1 inteilace anu suLinteilace conliguiation:
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
interface FastEthernet0/1.69
encapsulation dot1Q 69
ip address 192.168.1.1 255.255.255.252
ip rip authentication mode md5
ip rip authentication key-chain test
no snmp trap link-status
Ale`s ge-0/0/0 inteilace anu logical unit conliguiation:
[ge-0/0/0 {
vlan-tagging;
unit 69 {
description Ale-to_Malt;
vlan-id 69;
family inet {
address 192.168.1.2/30;
}
}
unit 1121 {
description Ale-to_Lager;
vlan-id 1121;
family inet {
RIP Deployment Scenario | 185
address 10.10.129.1/24;
}
}
}
Existing RIP Configuration
Beloie auuing the new RIP iouteis, it makes sense to liist inspect the ielateu RIP con-
liguiation in the Cisco platloim to get a leel loi what RIP conliguiation tasks will Le
neeueu on the ]unipei Netwoiks Loxes. The RIP-ielateu conliguiation paits liom
ioutei Malt aie shown, along with some inline comment as to what each pait is uoing:
Malt# show run
Building configuration...
. . .
!
key chain test
key 1
key-string jncie
. . .
The key chain conliguiation is useu to pioviue authentication to vaiious iouting pio-
tocols, ostensiLly RIP, in this example. The nameu key chain has a single key that is
numLeieu as 1 using a key value ol jncie. Key chains pioviue the aLility to iotate the
cuiient key, Laseu on stait anu enu times (which aie not specilieu in this example). As
ol this wiiting, ]unos suppoits authentication key chains only loi the LaLel DistiiLution
Piotocol (LDP), OSPF, anu BGP. RIP suppoits a single passwoiu-MD5 key, which is
goou loi us Lecause that is just what`s neeueu heie:
interface FastEthernet0/1.69
encapsulation dot1Q 69
ip address 192.168.1.1 255.255.255.252
ip rip authentication mode md5
ip rip authentication key-chain test
no snmp trap link-status
!
. . .
The two suLinteilace-level IP rip authentication statements conliguie RIP authenti-
cation loi messages sent out to oi ieceiveu liom the ielateu inteilace. The commanus
specily the associateu key chain anu authentication appioach, which again is MD5 in
this example:
router rip
version 2
redistribute connected
redistribute static route-map TAGGING
network 10.0.0.0
network 192.168.1.0
distribute-list 3 out static
no auto-summary
. . .
186 | Chapter 6:Interior Gateway Protocols and Migration Strategies
This poition ol the conliguiation actually enaLles the RIP piocess. Things Legin with
the specilication that RIP veision 2 is to Le iun. Consiueiing the VLSM in ellect, this
is a veiy goou choice. The network statements, which aie assumeu to lall on classlul
Lounuaiies, ueline the set ol inteilaces on which RIP shoulu opeiate. Rathei than listing
inteilaces uiiectly Ly name, they aie inuiiectly iuentilieu thiough the inteilace`s IP
auuiess. Notice the two loims ol ioute ieuistiiLution in ellect. The redistribute
connected anu redistribute static statements, the lattei with an associateu ioute map,
seive to ieuistiiLute connecteu anu static ioutes, iespectively. A uistiiLution list coulu
also have Leen useu to contiol the ioutes auveitiseu into RIP. The connecteu ioutes
will catch the ioutei`s seiial, Fast Etheinet, anu loopLack inteilace suLnets. You will
have to wait anu see what static ioute ieuistiiLution is uoing when you inspect the
ielateu ioute map.
The no-auto-summary statement uisaLles the uelault (Cisco) Lehavioi ol automatically
summaiizing at classlul netwoik Lounuaiies. Vhen comLineu with RIP veision 2,
which conveys a netwoik mask, VLSM/CIDR is suppoiteu:
ip route 0.0.0.0 0.0.0.0 Null0
ip route 200.0.100.0 255.255.255.0 Null0
!
access-list 3 permit 200.0.100.0
access-list 4 permit 0.0.0.0
!
The whole classlul auuiessing concept is totally alien to a ]unipei Netwoiks ioutei, as
the Loxes weie uesigneu in an eia well altei the concept ol class-Laseu auuiessing hau
come anu gone. To help illustiate this point, ]unos has no neeu loi an ip classless
statement, as always seen in IOS, anu consistently uses CIDR / notation loi pielix
lengths.
This poition ol the conliguiation uelines two static ioutes: the loimei is a uelault ioute
anu the lattei is the simulateu customei netwoik associateu with Malt. Both aie pointeu
to null0 as a next hop, which means that any tiallic that longest-matches eithei ol these
two ioutes will Le uiscaiueu.
This may stiike the ieauei as ouu, so some auuitional explanation is waiianteu. The
assumption is that the ieal customei netwoik will Le assigneu a mask longei than
the /2+ useu Ly the static ioute that cuiiently iepiesents itloi example, a /2S. Theie-
loie, packets actually sent to hosts within the customei netwoik will longest-match
against the customei netwoik inteilace ioute (longest-match iules), anu aie theieLy
spaieu the ignominious tieatment ol a one-way tiip to null0 lanu. Il, on the othei hanu,
the customei netwoik inteilace is uown, these packets aie uiscaiueu as they now lon-
gest-match against the static ioutemeanwhile, the piesence ol the static ioute is pie-
venting ioute chuin in the iest ol the netwoik Lecause it`s always Leing auveitiseu in
RIP. This staLility comes with the uownsiue that, uuiing a customei netwoik inteilace
outage, othei iouteis in the RIP uomain have a lalse Leliel that hosts on the customei
netwoik aie still ieachaLle, anu the iesultant tiallic is loiwaiueu ovei the enteipiise
RIP Deployment Scenario | 187
netwoik only to Le uiscaiueu Ly the last hop. This technigue is somewhat common in
seivice pioviuei netwoiks, Lecause contiol plane staLility is geneially moie impoitant
than the netwoik Lanuwiuth that is wasteu Ly loiwaiuing packets acioss a netwoik
only to shunt them to null0.
In the RIP scenaiio, the two Cisco iouteis aie attacheu to some othei netwoik clouu.
Rathei than iun a iouting piotocol oi ueline numeious static ioutes, the auministiatoi
ielies on a uelault ioute to uiiect matching tiallic into this clouu. The uotteu lines on
the uiawing symLolize that this clouu is not pait ol the actual test Leu.
Also, note the two ielateu IP access contiol lists (ACLs), each matching on one ol the
two static ioutes. These ACLs aie in tuin ieleienceu Ly the ioute map:
route-map TAGGING permit 10
match ip address 3
set metric 3
!
route-map TAGGING permit 20
match ip address 4
set tag 100
. . .
End
The TAGGING ioute map liist matches against ACL 3 anu sets the outgoing metiic to 3
loi matching pielixes (the simulateu customei netwoik ioute in this case). The uelault
metiic woulu Le 1, so this action simulates a netwoik that is two ioutei hops laithei
away than it actually is. This might Le uone to cause anothei souice ol this ioute to Le
pieleiieu (the lowei hop count wins), oi, peihaps, to limit the scope ol stations that
can ieach this netwoik (iecall that in RIP, 16 means you cannot get theie). Like it oi
not, this is an example ol how ioute maps aie useu in IOS to altei ioute attiiLutes,
peihaps just to keep the scenaiio inteiesting.
The permit 20 statement evokes ACL +, which matches the uelault ioute loi puiposes
ol setting a ioute tag. In this example, the tag happens to Le Laseu on the ioutei`s
loopLack auuiess. It`s common to tag ioutes that aie ieuistiiLuteu loi puiposes ol
tiacking uown the souice ol the ioute when tiouLleshooting, oi loi use in policy
matching Laseu on tag values. This is especially impoitant when peiloiming mutual
ioute ieuistiiLution, which is a piocess pione to iouting loops when ioute lilteiing
piecautions aie not exeiciseu.
Baseline Operation
A guick look at the state ol the IP ioute taLle at ioutei Malt is peiloimeu Leloie any
mouilications aie maue. This will seive as the netwoik Laseline loi lutuie compaiison:
Malt# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
188 | Chapter 6:Interior Gateway Protocols and Migration Strategies
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
R 200.0.200.0/24 [120/3] via 10.1.254.2, 00:00:03, Serial0/0
S 200.0.100.0/24 is directly connected, Null0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.10.128.100/32 is directly connected, Loopback0
R 10.10.128.200/32 [120/1] via 10.1.254.2, 00:00:03, Serial0/0
C 10.1.254.0/24 is directly connected, Serial0/0
C 10.1.254.2/32 is directly connected, Serial0/0
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, FastEthernet0/1.69
192.168.2.0/30 is subnetted, 1 subnets
R 192.168.2.0 [120/1] via 10.1.254.2, 00:00:04, Serial0/0
S* 0.0.0.0/0 is directly connected, Null0
No ieal suipiises heie. Malt has seveial uiiectly connecteu ioutes, in the loim ol its FA
0/1.69, loopLack 0, anu seiial 0/0 inteilaces. Anu the two locally uelineu static ioutes,
0.0.0.0 anu 200.0.0.100, aie Loth pointing to null0. Lo anu Leholu, Malt has leaineu
thiee ioutes via RIP: Barley`s FA 0/1.70 ioute (192.16S.2.0), its loopLack inteilace ioute
(10.10.12S.200), anu the simulateu customei ioute (200.0.200.0). Note that the cus-
tomei ioute ieceiveu liom Barley uemonstiates the ellects ol the ioute map. This
ioute`s ieceiveu hop count is 3 wheieas the othei two ioutes auveitiseu Ly Barley weie
ieceiveu with the uelault value ol 1. The hop count/metiic is uisplayeu just altei the
auministiative uistance, which loi RIP is 120. Heie is a summaiy view ol the RIP ioutes
at Barley:
Barley# show ip route rip
R 200.0.100.0/24 [120/3] via 10.1.254.1, 00:00:14, Serial0/0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
R 10.10.128.100/32 [120/1] via 10.1.254.1, 00:00:14, Serial0/0
192.168.1.0/30 is subnetted, 1 subnets
R 192.168.1.0 [120/1] via 10.1.254.1, 00:00:14, Serial0/0
Vith Barley uisplaying the same type anu numLei ol ioutes, Laseline opeiation is
conliimeu.
Summary of RIP Requirements
The opeiational aspects ol the RIP netwoik uesign, as ueteimineu thiough analysis ol
the legacy RIP conliguiation, aie as lollows:
RIPv2 (without auto-summaiization).
Delaults aie in place loi upuate, holu uown, anu ioute timeout timeis.
MD5 authentication is in ellect using key ID 1 with stiing jncie.
RIP Deployment Scenario | 189
Diiect netwoiks aie Leing ieuistiiLuteu.
The static ioute iepiesenting an attacheu customei netwoik is ieuistiiLuteu with
an aitilicially escalateu hop count ol 3.
Enter Juniper Networks
Baseu on the analysis ol the IOS RIP conliguiation, we know what neeus to Le uone at
Ale anu Lager. To help mitigate any opeiational impacts, it is ueciueu to liist Liing up
the RIP peeiings Letween Ale anu Lager Leloie attaching them to the existing RIP
LackLone.
Configure static routes
The conliguiation Legins with the uelinition ol the static ioute that simulates an at-
tacheu customei netwoik. The conliguiation steps loi Ale aie:
lab@Ale> configure
Entering configuration mode
[edit]
lab@Ale# edit routing-options
[edit routing-options]
lab@Ale# set static route 200.0.1/24 discard
[edit routing-options]
lab@Ale# show
static {
route 200.0.1.0/24 discard;
}
Vith the static ioute uelineu, the change is committeu anu the iesult conliimeu (while
still in conliguiation moue). In this example, tiallic matching the static ioute is uiiecteu
to a uiscaiu next hop, which means that no iesponses will Le geneiateu loi matching
tiallica tiue Llack hole liom which nothing will escape. Anothei option woulu Le
reject, which geneiates an Inteinet Contiol Message Piotocol (ICMP) eiioi iepoiting
that the uestination is unieachaLle. This cieates lunctionality similai to IOS`s null0, in
that matching tiallic will geneiate host unieachaLle eiioi messages. The reject option
can assist in tiouLleshooting, Lut it consumes ioutei iesouices in the loim ol message
geneiation, which can Le an issue uuiing a laige-scale uenial ol seivice (DoS) attack,
making discard the pieleiieu taiget loi such a ioute:
[edit routing-options]
lab@Ale# commit
commit complete
[edit routing-options]
lab@Ale# run show route protocol static
190 | Chapter 6:Interior Gateway Protocols and Migration Strategies
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.0.1.0/24 *[Static/5] 00:00:37
Discard
Configure RIP
The RIP conliguiation is now auueu to Ale. Stait Ly moving to the RIP conliguiation
hieiaichy, wheie the geneial options aie shown:
[edit routing-options]
lab@Ale# top edit protocols rip
[edit protocols rip]
lab@Ale# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
authentication-key Authentication key (password)
authentication-type Authentication type
check-zero Check reserved fields on incoming RIPv2 packets
> graceful-restart RIP graceful restart options
> group Instance configuration
holddown Hold-down time (10..180 seconds)
+ import Import policy
message-size Number of route entries per update message (25..255)
metric-in Metric value to add to incoming routes (1..15)
no-check-zero Don't check reserved fields on incoming RIPv2 packets
> receive Configure RIP receive options
> rib-group Routing table group for importing RIP routes
route-timeout Delay before routes time out (30..360 seconds)
> send Configure RIP send options
> traceoptions Trace options for RIP
update-interval Interval between regular route updates (10..60 seconds)
[edit protocols rip]
lab@Ale# set
It shoulu Le appaient that many aspects ol RIP aie conliguiaLle within ]unos. Some
options aie gloLal, such as the authentication key/type oi impoit/expoit policy, which
means they apply to all gioups (unless negateu Ly a moie specilic gioup setting, il
availaLle). Othei paiameteis can Le specilieu only at a suLseguent hieiaichy. Foi ex-
ample, a neighLoi can Le uelineu only within a gioup. You can guickly exploie the
options availaLle unuei send anu receive using the commanu-line inteilace`s
(CLI`s) ? help utility:
[edit protocols rip]
lab@Ale# set send ?
Possible completions:
broadcast Broadcast RIPv2 packets (RIPv1 compatible)
multicast Multicast RIPv2 packets
RIP Deployment Scenario | 191
none Do not send RIP updates
version-1 Broadcast RIPv1 packets
[edit protocols rip]
lab@Ale# set receive ?
Possible completions:
both Accept both RIPv1 and RIPv2 packets
none Do not receive RIP packets
version-1 Accept RIPv1 packets only
version-2 Accept only RIPv2 packets
It`s appaient liom the uisplay that the senu anu ieceive settings gloLally contiol the
RIP veision anu whethei multicast (uelault loi v2) oi Lioaucast packets aie sent. It just
so happens that these same settings can also Le specilieu on a pei-neighLoi (inteilace)
Lasisiecall that in ]unos, the moie-specilic gioup-level conliguiation hieiaichy set-
tings oveiiiue the less-specilic gloLal values. Let`s take a guick look at the options
availaLle unuei a gioup, which is wheie you can ueline neighLois (inteilaces) that
iun RIP:
[edit protocols rip]
lab@Ale# set group rip ?
Possible completions:
<[Enter]> Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> bfd-liveness-detection Bidirectional Forwarding Detection options
+ export Export policy
+ import Import policy
metric-out Default metric of exported routes (1..15)
> neighbor Neighbor configuration
preference Preference of routes learned by this group
route-timeout Delay before routes time out (30..360 seconds)
update-interval Interval between regular route updates (10..60 seconds)
| Pipe through a command
Conliguiation options lounu at the neighLoi level incluue the import oi export key-
woiu, which is useu to apply iouting policy to ieceive oi tiansmit ioute upuates, ie-
spectively. Note that when applieu at the neighLoi level, any gloLally uelineu impoit
oi expoit policies aie negateu. The ioutei iuns cithcr the gloLal oi the gioup policy,
nevei Loth, anu the ioutei always chooses the most specilic applicationa neighLoi
level is moie specilic than a gloLal level, ol couise. You may iecall that policy is useu
to contiol ioute exchange anu altei ioute attiiLutes. The gloLal pieleience loi ioutes
leaineu liom a paiticulai neighLoi can also Le conliguieu heie. Note that in ]unos, the
concept ol gloLal pieleience is eguivalent to that ol IOS`s auministiative uistance
this value is alteieu to make a souice ol iouting inloimation moie (lowei value) oi less
(highei value) pieleiieu.
192 | Chapter 6:Interior Gateway Protocols and Migration Strategies
The teiminology ol gioups anu neighLois may seem a Lit conlusing at
liist, given the way RIP is conliguieu in IOS. ]unos is optimizeu when
iouting peeis with similai expoit policy aie placeu into the same gioup.
As a iesult, even il you have only one peei, that neighLoi neeus to Lelong
to a RIP gioup. Also, the teim ncighbor heie actually means intcrjacc,
given that RIP messages aie not unicast to specilic machines, Lut insteau
aie Lioaucast oi multicast to all RIP speakeis on a given link. This means
that specilying a single neighLoi in the loim ol a multiaccess inteilace
iesults in RIP communications with all RIP-capaLle iouteis on that LAN
segment.
Ale`s RIP stanza is now conliguieu in accoiuance with the RIP ue-
sign guiueline uiscoveieu when analyzing the legacy RIP conliguiation. Recall that the
plan is to liist estaLlish RIP peeiings Letween Ale anu Lager Leloie tiying ioute ex-
changes to the Cisco iouteis (see Figuie 6-3). Heie is the iesulting RIP stanza, along
with the set commanus useu to cieate it couitesy ol the display set lunction in the CLI:
[edit protocols rip]
lab@Ale# show
send multicast;
receive version-2;
authentication-type md5;
authentication-key "$9$cf3rK84oGiHm-VgJ"; ## SECRET-DATA
group rip {
inactive: neighbor ge-0/0/0.69;
neighbor ge-0/0/0.1121;
}
[edit protocols rip]
lab@Ale# show | display set
set protocols rip send multicast
set protocols rip receive version-2
set protocols rip authentication-type md5
set protocols rip authentication-key "$9$cf3rK84oGiHm-VgJ"
deactivate protocols rip group rip neighbor ge-0/0/0.69
set protocols rip group rip neighbor ge-0/0/0.1121
The gloLal send multicast statement ensuies that we will only speak to RIPv2 noues,
as RIPv1 iouteis will not see multicast upuates. The receive version-2 ensuies that we
piocess only multicast upuates, theieLy conliguiing the ioutei loi RIPv2-only opeia-
tion. The authentication settings specily a (now cipheieu) text stiing ol jncie anu in-
uicates that MD5-Laseu authentication shoulu Le useu.
]unos always enciypts passwoius; IOS ieguiies that the passwoiu
enciyption seivice Le enaLleu loi the same lunctionality.
Lastly, notice the two neighbor statements that iuentily what inteilaces RIP shoulu iun
on. Note that the link to Malt is cuiiently ueactivateu (inactive), which means that
Ales RIP configuration.
RIP Deployment Scenario | 193
poition ol the conliguiation will Le ignoieu. This will iesult in Ale iunning RIP only
on the ge-0/0/0.1121 inteilace to Lager. Once RIP has Leen conliimeu Letween Ale anu
Lager, this link will Le activateu to enaLle RIP exchanges with the Cisco iouteis.
The one pait ol Ale`s conliguiation yet to Le auuiesseu is the ieuistiiLution into RIP ol
its connecteu anu simulateu customei static ioutes. Recall that in ]unos, contiol ovei
what ioutes entei anu leave the ioute taLle anu the mouilication ol attiiLutes associateu
with these ioutes is contiolleu Ly iouting policy. Heie is an example ol the ]unos ioute
policy neeueu to match the Cisco ioutei`s ieuistiiLution ol connecteu (uiiect) ioutes
anu the ioute map lunction that sets the metiic on a ieuistiiLuteu static ioute:
[edit policy-options policy-statement rip_export]
lab@Ale# show
term 1 {
from protocol direct;
then accept;
}
term 2 {
from {
protocol static;
route-filter 200.0.1.0/24 exact;
}
then {
metric 3;
accept;
}
}
[edit policy-options policy-statement rip_export]
lab@Ale# show | display set
set policy-options policy-statement rip_export term 1 from protocol direct
set policy-options policy-statement rip_export term 1 then accept
set policy-options policy-statement rip_export term 2 from protocol static
set policy-options policy-statement rip_export term 2 from route-filter 200.0.1.0/24
exact
set policy-options policy-statement rip_export term 2 then metric 3
set policy-options policy-statement rip_export term 2 then accept
The newly cieateu RIP policy is applieu to the RIP gioup (alteinatively, it coulu Le
applieu gloLally in this example) as export, wheie it will contiol the exchange ol ioutes
that aie auveitiseu into RIP. The uelault RIP impoit policy, which is to accept RIP
ioutes, is lelt unalteieu:
[edit]
lab@Ale# set protocols rip group rip export rip_export
[edit]
lab@Ale# show protocols rip
send multicast;
receive version-2;
authentication-type md5;
authentication-key "$9$cf3rK84oGiHm-VgJ"; ## SECRET-DATA
group rip {
export rip_export;
inactive: neighbor ge-0/0/0.69;
194 | Chapter 6:Interior Gateway Protocols and Migration Strategies
neighbor ge-0/0/0.1121;
}
You may assume that a compatiLle RIP policy conliguiation has Leen auueu to Lager
anu that the changes aie committeu.
Confirm RIP Operation: Ale and Lager
Vith the RIP anu ielateu static ioute/policy conliguiation in place at Ale anu Lager,
the opeiation ol RIP can Le conliimeu. Stait with the conliimation that RIPv2 is iun-
ning, anu that it is uoing so on the expecteu inteilaces:
lab@Ale> show rip neighbor
Source Destination Send Receive In
Neighbor State Address Address Mode Mode Met
-------- ----- ------- ----------- ---- ------- ---
ge-0/0/0.1121 Up 10.10.129.1 224.0.0.9 mcast v2 only 1
The output ol the show rip neighbor commanu conliims that Ale is set loi v2 opeiation,
anu that RIP is iunning on its link to Lager. The Up status inuicates that the inteilace
is opeiational, Lut not that any paiticulai neighLoi has Leen uetecteu. The In Met
column uisplays the metiic value that will Le auueu to any ioute upuates ieceiveu ovei
the associateu inteilaces; Ly uelault, each ieceiveu upuate has its metiic inciementeu
Ly one Leloie Leing placeu into the ioute taLle.
The geneial RIP statistics conliim that upuates aie Leing sent anu ieceiveu, that no
eiiois aie occuiiing, anu that in the case ol Ale, thiee ioutes have Leen leaineu via RIP,
inuicating that RIP is opeiating coiiectly Letween Ale anu Lager:
lab@Ale> show rip statistics
RIPv2 info: port 520; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
3 0 0 0
ge-0/0/0.1121: 3 routes learned; 3 routes advertised; timeout 180s;
update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 25 11 2
Triggered Updates Sent 1 0 0
Responses Sent 0 0 0
Bad Messages 0 0 0
RIPv1 Updates Received 0 0 0
RIPv1 Bad Route Entries 0 0 0
RIPv1 Updates Ignored 0 0 0
RIPv2 Updates Received 17 11 2
RIPv2 Bad Route Entries 0 0 0
RIPv2 Updates Ignored 0 0 0
Authentication Failures 1 0 0
RIP Requests Received 1 0 0
RIP Requests Ignored 0 0 0
RIP Deployment Scenario | 195
Anu now we conliim the piesence ol RIP ioutes in Ale`s ioute taLle:
lab@Ale> show route protocol rip
inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.128.2/32 *[RIP/100] 00:09:54, metric 2, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
192.168.2.0/30 *[RIP/100] 00:09:54, metric 2, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
200.0.2.0/24 *[RIP/100] 00:09:54, metric 4, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
224.0.0.9/32 *[RIP/100] 00:10:57, metric 1
MultiRecv
Ale`s ioute taLle contains the expecteu RIP ioutes, consiueiing that RIP is not yet en-
aLleu to Malt anu Barley. Notice that Lager has auveitiseu its uiiectly connecteu loop-
Lack inteilace (10.10.12S.2) ioute to Ale. Also ol note is that the ]unos ioute taLle
uisplays the local RIP cost, as opposeu to the metiic ieceiveu in the ioute upuate. This
uilleis a Lit liom IOS, which uisplays the ieceiveu RIP metiic iathei than local cost
(ieceiveu - 1 Ly uelault). The 200.0.0.2/2+ static ioute uelineu at Lager has Leen in-
jecteu into RIP with a metiic ol 3 uue to the action ol its expoit policythis ioute is
installeu in Ale`s ioute taLle with a local cost ol 3 - 1, oi +. You`ll also see that the RIP
gloLal pieleience in ]unos is 100.
A latei section uetails auuitional opeiational moue commanus that assist in ueLugging
RIP opeiation. But iight now, all seems to Le woiking as expecteu, so theie is not much
to ueLug. Ol couise, things might change when tying into the Cisco poition ol the
netwoik.
Confirm RIP: Juniper Networks to Cisco Systems Integration
Vith RIP opeiation in the ]unipei anu Cisco uomains conliimeu, it`s time to liie up
RIP Letween the two venuois` Loxes to see what happens. RIP is a simple piotocol, so
what coulu go wiong? Things stait with the activation ol the RIP neighLoi (inteilace)
linking Ale to Malt. Similai steps aie peiloimeu at Lager loi its RIP inteilace to Barley:
lab@Ale> configure
Entering configuration mode
[edit]
lab@Ale# activate protocols rip group rip neighbor ge-0/0/0.69
[edit]
lab@Ale# commit
commit complete
196 | Chapter 6:Interior Gateway Protocols and Migration Strategies
Confirm route exchange
Altei a lew minutes, RIP upuates shoulu have piopagateu. Let`s stait with a guick look
at RIP statistics at ioutei Lager, as any pioLlems will likely manilest in the loim ol an
inciementing eiioi countei:
[edit]
lab@Lager# run show rip statistics
RIPv2 info: port 520; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
10 0 0 0
ge-0/0/0.1121: 3 routes learned; 3 routes advertised; timeout 180s;
update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 29 11 2
Triggered Updates Sent 1 0 0
Responses Sent 0 0 0
Bad Messages 0 0 0
RIPv1 Updates Received 0 0 0
RIPv1 Bad Route Entries 0 0 0
RIPv1 Updates Ignored 0 0 0
RIPv2 Updates Received 29 10 2
RIPv2 Bad Route Entries 0 0 0
RIPv2 Updates Ignored 0 0 0
Authentication Failures 0 0 0
RIP Requests Received 0 0 0
RIP Requests Ignored 0 0 0
ge-0/0/0.70: 7 routes learned; 3 routes advertised; timeout 180s;
update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 29 11 2
Triggered Updates Sent 1 0 0
Responses Sent 0 0 0
Bad Messages 0 0 0
RIPv1 Updates Received 0 0 0
RIPv1 Bad Route Entries 0 0 0
RIPv1 Updates Ignored 0 0 0
RIPv2 Updates Received 31 11 2
RIPv2 Bad Route Entries 0 0 0
RIPv2 Updates Ignored 0 0 0
Authentication Failures 0 0 0
RIP Requests Received 0 0 0
RIP Requests Ignored 0 0 0
The RIP statistics inuicate that all is noimal. Lager is conliiming that 10 ioutes have
Leen leaineu via RIP, with thiee coming liom its link to Ale anu the Lalance leaineu
liom its link to Barley. Authentication is cleaily woiking, given the leaineu ioutes anu
no inuication ol message uiscaius oi eiiois.
RIP Deployment Scenario | 197
Next, conliim whethei any RIP ioutes aie piesent in the ioute taLle ol Lager:
[edit]
lab@Lager# run show route protocol rip
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[RIP/100] 00:16:35, metric 2, tag 200
> to 192.168.2.1 via ge-0/0/0.70
10.1.254.0/24 *[RIP/100] 00:16:35, metric 2, tag 0
> to 192.168.2.1 via ge-0/0/0.70
10.1.254.1/32 *[RIP/100] 00:16:35, metric 2, tag 0
> to 192.168.2.1 via ge-0/0/0.70
10.10.128.100/32 *[RIP/100] 00:16:35, metric 3, tag 0
> to 192.168.2.1 via ge-0/0/0.70
10.10.128.200/32 *[RIP/100] 00:16:35, metric 2, tag 0
> to 192.168.2.1 via ge-0/0/0.70
10.10.128.1/32 *[RIP/100] 00:16:29, metric 2, tag 0
> to 10.10.129.1 via ge-0/0/0.1121
192.168.1.0/30 *[RIP/100] 00:16:29, metric 2, tag 0
> to 10.10.129.1 via ge-0/0/0.1121
200.0.1.0/24 *[RIP/100] 00:16:29, metric 4, tag 0
> to 10.10.129.1 via ge-0/0/0.1121
200.0.100.0/24 *[RIP/100] 00:16:35, metric 5, tag 0
> to 192.168.2.1 via ge-0/0/0.70
200.0.200.0/24 *[RIP/100] 00:11:44, metric 4, tag 0
> to 192.168.2.1 via ge-0/0/0.70
224.0.0.9/32 *[RIP/100] 00:16:50, metric 1
MultiRecv
RIP ioutes aie piesent. The ioutes leaineu thiough RIP incluue the seiial link Letween
Malt anu Barley (10.1.25+.0/2+ anu associateu host ioutes), the two simulateu cus-
tomei netwoiks (200.0.100/2+ anu 200.0.200/2+), anu the RIP peeiing netwoik loi the
link Letween Malt anu Ale (192.16S.2.0/30). Also piesent aie the /32 ioutes loi Malt`s
anu Barley`s loopLack 0 inteilaces (10.10.12S.100 anu 10.10.12S.200). The uelault
ioute is piesent, anu it`s coiiectly pointing to neighLoi Barley, given the metiic shoulu
Le less via this path than loiwaiuing thiough Ale to ieach the uelault auveitiseu Ly
Barley.
The RIP ioutes at Barley aie examineu next:
Barley# show ip route rip
R 200.0.1.0/24 [120/4] via 10.1.254.1, 00:00:27, Serial0/0
R 200.0.2.0/24 [120/3] via 192.168.2.2, 00:00:25, FastEthernet0/1.70
R 200.0.100.0/24 [120/3] via 10.1.254.1, 00:00:27, Serial0/0
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
R 10.10.128.100/32 [120/1] via 10.1.254.1, 00:00:27, Serial0/0
R 10.10.129.0/24 [120/1] via 192.168.2.2, 00:00:25, FastEthernet0/1.70
R 10.10.128.1/32 [120/2] via 10.1.254.1, 00:00:27, Serial0/0
R 10.10.128.2/32 [120/1] via 192.168.2.2, 00:00:25, FastEthernet0/1.70
192.168.1.0/30 is subnetted, 1 subnets
R 192.168.1.0 [120/1] via 10.1.254.1, 00:00:27, Serial0/0
198 | Chapter 6:Interior Gateway Protocols and Migration Strategies
The uisplay conliims that RIP exchanges aie woiking Letween the ]unipei Netwoiks
iouteis anu the Cisco Loxes; Barley has a RIP ioute loi Loth ol Ale`s anu Lager`s si-
mulateu customei netwoiks (200.0.1/2+ anu 200.0.2/2+) as well as the link Letween
Ale anu Lager (10.10.129.0/2+), in auuition to the /32 loopLack auuiesses assigneu to
Ale anu Lager (10.10.12S.1 anu 10.10.12S.2).
Confirm forwarding path
A tiaceioute is peiloimeu liom Lager to the simulateu netwoik on Barley to valiuate
the uata plane anu iesulting loiwaiuing paths (the no-resolve switch ensuies that the
local ioutei uoes not waste time tiying to peiloim ieveise Domain Name System DNS
lookups on the iesulting IP auuiesses in the event that DNS is not conliguieu in the laL):
[edit]
lab@Ale# run traceroute no-resolve 200.0.200.1
traceroute to 200.0.200.1 (200.0.200.1), 30 hops max, 40 byte packets
1 192.168.1.1 9.498 ms 9.705 ms 10.127 ms
2 10.1.254.2 19.700 ms 20.004 ms 20.073 ms
3 10.1.254.2 19.772 ms !H * 20.392 ms !H
The tiaceioute iesults aie as expecteu; ioutei Ale ciosseu two iouteis to ieach the
simulateu customei netwoik, anu as pieviously noteu, the null0 action ol the longest
match iesulteu in ICMP host unieachaLle messages, as inuicateu Ly the !H in the ietuin.
The iesults seem to inuicate that RIPv2 is woiking Letween ]unos anu IOS.
Congiatulations!
Actually, nothing in the iealm ol inteinetwoiking woiks the
liist time. In lact, the iesults ol that tiaceioute shoulu have gotten you thinking a Lit.
Given the RIP topology, Ale shou|d have two egual cost paths to the simulateu customei
netwoik attacheu to Barley. Altei all, it`s two hops to ieach Barley via Malt, Lut also
two hops to ieach Barley via Lager. Knowing that ]unos automatically peiloims loau
Lalancing ovei as many as 16 egual cost paths, you`u expect to see Ale with two egual
cost ioutes loi the 200.0.200/2+ ioute. Unloitunately, pievious uisplays conliim this
is not the case. A similai conuition exists at Lager with iegaiu to the simulateu customei
ioute at Malt.
Theie aie a lew tools loi tiouLleshooting this type ol issue in ]unos. One appioach is
piotocol tiacing, useu to show the RIP messages Leing sent anu ieceiveu, anu the oveiall
iesults ol RIP message piocessing. Tiacing is similai to the IOS dcbug leatuie. Given
that RIP is a DV piotocol, you can also avail youisell ol the show route advertising-
protocol anu the show route receiving-protocol commanus. As theii names imply,
these commanus uisplay what ioutes the local ioutei is auveitising out a given inteilace
oi what ioutes aie Leing ieceiveu (leaineu) liom a paiticulai neighLoi. The piocess
Legins at ioutei Lager:
[edit]
lab@Lager# run show route advertising-protocol rip ?
Possible completions:
<neighbor> IP address of neighbor (local for RIP and RIPng)
RIP troubleshooting scenario.
RIP Deployment Scenario | 199
The commanu syntax help stiing ol ? is uselul heie Lecause it ieminus us that loi the
RIP loim ol this commanu, you must specily the |oca| intcrjacc addrcss; iecall that RIP
geneiates Lioaucast oi multicast upuates to all neighLois on the link, so unlike BGP,
wheie a specilic neighLoi auuiess is specilieu, it`s the local IP auuiess loi RIP:
[edit]
lab@Lager# run show route advertising-protocol rip 10.10.129.2
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.128.2/32 *[Direct/0] 02:31:29
> via lo0.0
192.168.2.0/30 *[Direct/0] 02:31:29
> via ge-0/0/0.70
200.0.2.0/24 *[Static/5] 02:32:10
Discard
The iesult leaves something to Le uesiieusomething such as a ioute auveitisement
loi the 200.0.200/2+ ioute, that is! The receiving-protocol loim ol the commanu is
useu to conliim that whatevei is wiong is at least symmetiical:
lab@Lager# run show route receive-protocol rip ?
Possible completions:
<peer> IP address of neighbor
Note that loi the receiving-protocol commanu, RIP ieguiies the specilication ol a
spccijic ncighbor |P auuiess, which in tuin is ieachaLle via a RIP-enaLleu inteilace (a
goou way to look at this is to consiuei that tiansmitteu upuates aie sent to all neighLois,
Lut ieceiveu upuates come liom a specilic neighLoia souice IP auuiess is nevei ol
the multicast/Lioaucast loim):
[edit]
lab@Lager# run show route receive-protocol rip 10.10.129.1
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.128.1/32 *[RIP/100] 01:01:13, metric 2, tag 0
> to 10.10.129.1 via ge-0/0/0.1121
192.168.1.0/30 *[RIP/100] 01:01:13, metric 2, tag 0
> to 10.10.129.1 via ge-0/0/0.1121
200.0.1.0/24 *[RIP/100] 01:01:13, metric 4, tag 0
> to 10.10.129.1 via ge-0/0/0.1121
The pieceuing output pioves that, like Lager, Ale is not ieauveitising the 200.0.100/2+
ioute leaineu liom Malt. Foi auueu veiilication, we conliguie RIP tiacing at Ale:
[edit protocols rip]
lab@Ale# set traceoptions file rip_trace
[edit protocols rip]
lab@Ale# set traceoptions flag ?
Possible completions:
all Trace everything
200 | Chapter 6:Interior Gateway Protocols and Migration Strategies
auth Trace RIP authentication
error Trace RIP errors
expiration Trace RIP route expiration processing
general Trace general events
holddown Trace RIP hold-down processing
normal Trace normal events
nsr-synchronization Trace NSR synchronization events
packets Trace all RIP packets
policy Trace policy processing
request Trace RIP information packets
route Trace routing information
state Trace state transitions
task Trace routing protocol task processing
timer Trace routing protocol timer processing
trigger Trace RIP triggered updates
update Trace RIP update packets
[edit protocols rip]
lab@Ale# set traceoptions flag update detail
[edit protocols rip]
lab@Ale# commit
No one wants a tool he can`t use when he neeus it. ]unos piotocol tiac-
ing is much like Cisco Systems` ueLug in that it`s a gieat way to gain
insight into the opeiation ol a given piotocol, especially when things aie
not woiking. The upsiue is that you can ueploy tiacing on a ]unipei
Netwoiks ioutei, in a piouuction netwoik, with little to no opeiational
impactthat is, the manual uoes not wain against using tiacing, which
is the case loi ueLug in IOS. Vith that saiu, it is a Lest piactice to enaLle
tiacing only when neeueu anu only at the level ol uetail neeueu, anu
then to iemove the tiacing conliguiation when the joL is uone.
Also note that the ]unipei Netwoiks aichitectuie cleanly sepaiates the
contiol anu loiwaiuing planes, which means that you can monitoi in-
teilace tiallic (tcpuump) oi tiace piotocol opeiation only when it is
souiceu liom oi uestineu to the local ioutei`s Routing Engine (RE). You
cannot monitoi oi tiace tiansit tiallic unless a sampling conliguiation
is useu to sample/miiioi such tiallic out ol a specilic inteilace.
This example shows the RIP tiacing options along with a sample RIP tiacing conligu-
iation. Heie, tiallic matching the update llag is wiitten to a lile calleu rip_tracc. Vaiious
othei tiace llags exist anu aie uselul when uealing with specilic issues, such as using
the auth llag when you suspect an authentication pioLlem. The rip_tracc lile is moni-
toieu in ieal time with the monitor start commanu:
[edit protocols rip]
lab@Ale# run monitor start rip_trace
. . .
Aug 15 02:00:30.039884 Update job: sending 20 msgs; nbr: ge-0/0/0.1121;
group: rip; msgp: 0x876a000.
Aug 15 02:00:30.039916 nbr ge-0/0/0.1121; msgp 0x876a000.
RIP Deployment Scenario | 201
Aug 15 02:00:30.039985 0.84.1.20/0x46c25e20: tag 3, nh
0.0.0.0, met 0.
Aug 15 02:00:30.040011 10.10.128.1/0xffffffff: tag 0, nh
0.0.0.0, met 1.
Aug 15 02:00:30.040027 192.168.1.0/0xfffffffc: tag 0, nh
0.0.0.0, met 1.
Aug 15 02:00:30.040041 200.0.1.0/0xffffff00: tag 0, nh
0.0.0.0, met 3.
Aug 15 02:00:30.040053 sending msg 0x876a004, 4 rtes
(needs MD5)
Aug 15 02:00:30.040691 Update job done for nbr ge-0/0/0.1121
group: rip
Aug 15 02:00:32.560426 received response: sender 10.10.129.2,
command 2, version 2, mbz: 0; 5 routes.
Aug 15 02:00:32.560579 10.10.128.2/0xffffffff: tag 0, nh
0.0.0.0, met 1.
Aug 15 02:00:32.560645 192.168.2.0/0xfffffffc: tag 0, nh
0.0.0.0, met 1.
Aug 15 02:00:32.560694 200.0.2.0/0xffffff00: tag 0, nh
0.0.0.0, met 3.
*** monitor and syslog output disabled, press ESC-Q to enable ***
You can entei the Esc-g (oi Ctil-s) seguence to suspenu tiace output to the scieen while
inloimation is still Leing wiitten to the tiace lielu. Piessing Esc-g again (oi Ctil-i) ie-
sumes output to the scieen. It`s nice to Le aLle to enaLle tiacing anu suspenu it on
uemanu so that you can ieau what has Leen painteu to the scieen, without having to
type something such as unueLug IP iip, all while youi scieen is oveillowing with
ueLug uata. Use the monitor stop commanu to stop tailing the loglile. The monitor
list commanu shows any logliles that aie Leing monitoieu.
The RIP tiacing inloimation ielating to neighLoi ge-0/0/0.1121 conliims the iesults ol
the show route-advertising protocol commanu; namely that Lager is not ieauveitising
ioutes that it leains via RIP to othei RIP neighLois. Having seen what theie is to Le
seen, RIP tiacing is uiligently iemoveu:
[edit protocols rip]
lab@Ale# delete traceoptions
[edit protocols rip]
lab@Ale# commit
commit complete
The Problem
Think Lack to youi knowleuge ol ]unos iouting policy; you`ll iecall that an expoit
policy is the entity iesponsiLle loi taking activc ioutes liom the ioute taLle anu placing
them into outgoing piotocol upuates. Because the pioLlem ioute is in the ioute taLle,
is active, anu is conliimeu as not Leing auveitiseu to anothei RIP neighLoi, it woulu
seem to Le a classic case ol Lioken expoit policy. But why is oui expoit Lioken?
202 | Chapter 6:Interior Gateway Protocols and Migration Strategies
In ]unos, all piotocols have a uelault impoit anu expoit policy. The uelault impoit
policy loi RIP is to accept all (sane) RIP ioutes, as you might expect. Howevei, the
uelault RIP expoit policy is to advcrtisc nothing; not even ioutes leaineu thiough RIP!
Put anothei way, anu loi whatevei ieason, the conliguiation ol RIP in ]unos is not a
simple mattei ol router rip comLineu with a lew network statements. You will almost
always want the RIP ioutei to piopagate ioutes leaineu via RIP; to uo this you will neeu
to auu explicit expoit policy.
You alieauy have a RIP expoit policy in ellect to auveitise the uiiect (connecteu) anu
the simulateu customei static ioutes. Theieloie, a guick mouilication will put things
iight again in RIP lanu:
[edit policy-options policy-statement rip_export]
lab@Ale# show
term 1 {
from protocol direct;
then accept;
}
term 2 {
from {
protocol static;
route-filter 200.0.1.0/24 exact;
}
then {
metric 3;
accept;
}
}
[edit policy-options policy-statement rip_export]
lab@Ale# set term 3 from protocol rip
[edit policy-options policy-statement rip_export]
lab@Ale# set term 3 then accept
[edit policy-options policy-statement rip_export]
lab@Ale# show
term 1 {
from protocol direct;
then accept;
}
term 2 {
from {
protocol static;
route-filter 200.0.1.0/24 exact;
}
then {
metric 3;
accept;
}
}
RIP Deployment Scenario | 203
term 3 {
from protocol rip;
then accept;
}
A similai change is also maue (anu committeu) to the expoit policy at Lager. Altei a
lew minutes, the iesults aie conliimeu:
[edit]
lab@Lager# run show route receive-protocol rip 10.10.129.1
inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.254.2/32 *[RIP/100] 00:01:22, metric 3, tag 0
> to 10.10.129.1 via ge-0/0/0.1121
10.10.128.100/32 *[RIP/100] 01:31:13, metric 3, tag 0
to 192.168.2.1 via ge-0/0/0.70
> to 10.10.129.1 via ge-0/0/0.1121
10.10.128.1/32 *[RIP/100] 01:31:07, metric 2, tag 0
> to 10.10.129.1 via ge-0/0/0.1121
192.168.1.0/30 *[RIP/100] 01:31:07, metric 2, tag 0
> to 10.10.129.1 via ge-0/0/0.1121
200.0.1.0/24 *[RIP/100] 01:31:07, metric 4, tag 0
> to 10.10.129.1 via ge-0/0/0.1121
200.0.100.0/24 *[RIP/100] 01:31:13, metric 5, tag 0
> to 192.168.2.1 via ge-0/0/0.70
to 10.10.129.1 via ge-0/0/0.1121
_ _juniper_private1_ _.inet.0: 2 destinations, 2 routes (2 active,
0 holddown, 0 hidden)
The show route-receiving protocol rip commanu at Lager conliims that Ale is now
coiiectly ieauveitising RIP ioutes leaineu liom Malt. You can also see the ellects ol the
mouilieu expoit policy in the show route-advertising protocol rip commanu issueu
at Lager:
[edit]
lab@Lager# run show route advertising-protocol rip 10.10.129.2
inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[RIP/100] 01:31:24, metric 2, tag 200
> to 192.168.2.1 via ge-0/0/0.70
10.1.254.0/24 *[RIP/100] 01:31:24, metric 2, tag 0
> to 192.168.2.1 via ge-0/0/0.70
10.1.254.1/32 *[RIP/100] 01:31:24, metric 2, tag 0
> to 192.168.2.1 via ge-0/0/0.70
10.10.128.200/32 *[RIP/100] 01:31:24, metric 2, tag 0
> to 192.168.2.1 via ge-0/0/0.70
10.10.128.2/32 *[Direct/0] 03:05:21
> via lo0.0
192.168.2.0/30 *[Direct/0] 03:05:21
> via ge-0/0/0.70
204 | Chapter 6:Interior Gateway Protocols and Migration Strategies
200.0.2.0/24 *[Static/5] 03:06:02
Discard
200.0.200.0/24 *[RIP/100] 01:26:33, metric 4, tag 0
> to 192.168.2.1 via ge-0/0/0.70
Lager`s output conliims that it too is now ieauveitising RIP leaineu ioutes. As a linal
veiilication, the ioute taLle at Lager is inspecteu loi the customei netwoik associateu
with Malt:
[edit]
lab@Lager# run show route 200.0.100.0
inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.0.100.0/24 *[RIP/100] 01:33:57, metric 5, tag 0
> to 192.168.2.1 via ge-0/0/0.70
to 10.10.129.1 via ge-0/0/0.1121
The ioute`s piesence with two loiwaiuing next hops conliims the eailiei suspicion that
theie shoulu Le multiple egual cost paths loi some RIP uestinations in this laL topology.
Fiom Lager`s theie aie now two egual cost paths to 200.0.100/2+one via Barley anu
the othei thiough Ale.
RIP Deployment Summary
RIP ieally is a simple piotocol, anu conliguiing ]unos to inteiopeiate with IOS loi RIP
was, loi the most pait, pietty stiaightloiwaiu. The most common pioLlem you`ll en-
countei with this scenaiio is unlamiliaiity with the uelault RIP expoit policy, which is
not intuitive, to say the least. This section uemonstiateu Lasic RIP conliguiation anu
opeiational moue commanus that assist in tiouLleshooting RIP opeiation in a ]unos
enviionment.
The next section auuiesses ways to migiate a netwoik liom one IGP to anothei, a
concept calleu |GP nigration. Once again, now is an oppoitune time to take a Lieak
Leloie moving on.
IGP Migration
This section examines cuiient Lest piactices loi IGP migiation, ieleiiing to the ex-
change ol a netwoik`s existing, oi legacy, IGP with a uilleient veision ol IGP. Geneially,
the oveiall goals aie to minimize netwoik uisiuption while also taking the oppoitunity
to impiove on the netwoik`s uesign anu opeiation. The IGP plays a ciitical iole in the
opeiation ol any IP netwoik. Upgiauing a legacy netwoik`s IGP can iesult in uiamatic
peiloimance impiovements anu new seivice capaLilities, anu can align a company with
an open stanuaius-Laseu solution, which in tuin lacilitates a Lest-ol-Lieeu uecision
among netwoiking Loxes.
IGP Migration | 205
IGP migiation is an excellent time to clean house, so to speak, Ly ieevaluating all aspects
ol the cuiient netwoik`s uesign. Some lactois to consiuei incluue:
The potential loi ieauuiessing to Lettei accommouate hieiaichical uesign anu
ioute summaiization
The numLei anu types ol iouteis neeueu
How those iouteis inteiconnect (VAN/LAN technologies may have evolveu since
the oiiginal netwoik ueployment)
Vays to impiove ieliaLility
The neeu to maintain high netwoik availaLility may piecluue signilicant ieuesign.
Usually a compiomise must Le ieacheu Letween the neeu loi availaLility veisus po-
tential optimizations, Laseu on the specilics unigue to each enteipiise. In some cases,
a new LackLone is ueployeu in paiallel (the integiation mouel), which alloius the luxuiy
ol complete ieuesign at the cost ol auuitional geai.
IGP Migration: Common Techniques and Concerns
Beloie uiscussing specilic migiation appioaches, it makes sense to examine some ol the
issues anu consiueiations common to all appioaches. Geneial lactois anu concepts
applying to IGP migiations incluue the lollowing:
G|oba| routc prcjcrcncc
IGP tiansitions olten touch on the concept ol g|oba| routc prcjcrcncc, which is
known as adninistrativc distancc in IOS. A ioute`s gloLal pieleience inuicates the
oveiall goodncss ol a souice ol iouting inloimation anu is useu to Lieak ties when
two oi moie piotocols announce ieachaLility to the same pielix. Recall that longest
match always iules; theieloie, a longest-matching RIP ioute will always Le pielei-
ieu ovei a less specilic veision (a shoitei netmask) that is leaineu liom a moie
pieleiieu piotocol. Foi example, a /2+ OSPF inteinal ioute will lose to a /32 RIP
ioute eveiy uay ol the week uespite its much lowei, anu theieloie pieleiieu, piel-
eience. GloLal pieleience Lieaks ties on|y when ioutes with the sanc |cvc| oj spc-
cijicity aie leaineu Ly multiple iouting piotocols.
Routc rcdistribution
Route ieuistiiLution is the act ol exchanging ioute inloimation among uilleient
iouting piotocols anu is a common aspect ol most IGP migiation stiategies. In
many cases, you will not conliguie all iouteis loi the new IGP at the same time anu
will maintain connectivity Letween IGP uomains Ly ieuistiiLuting ioutes Letween
the new anu legacy IGPs at select iouteis. Because this will typically Le mutual,
also known as Liuiiectional ioute ieuistiiLution, you must iemain evei-vigilant oi
else lall victim to the ellects ol iouting loops. Accuiate policy is neeueu to ensuie
that ioutes oiiginating within IGP A that aie sent into IGP B aie nevei ieuistiiLuteu
Lack into IGP A, anu vice veisa.
206 | Chapter 6:Interior Gateway Protocols and Migration Strategies
Concurrcnt |GP opcration
Many migiation scenaiios will ieguiie that a uevice Le conliguieu to iun instances
ol Loth the olu anu the new IGPs at the same time. The liist issue heie is whethei
the uevice olleis suppoit loi Loth piotocols. Foi example, iunning EIGRP on a
]unipei Netwoiks ioutei is simply not an option. Then theie aie matteis ol
peiloimancecan the uevice Le expecteu to iun two instances ol an IGP anu still
opeiate ieliaLly? Theie aie numeious cases ol IGP migiation (ones that weie plan-
neu to occui with little oi no uisiuption, we might auu) that insteau melteu uown
when a Lox staiteu ieLooting oi peeis stait llapping, all Lecause ol insullicient
memoiy oi CPU powei when taskeu with iunning Loth IGPs concuiiently. This is
something that is olten not consiueieu when testing a migiation scenaiio in a laL,
wheie Loxes may Le iunning at lai lowei memoiy anu CPU levels than they woulu
in the piouuction enviionment.
As a geneial iule, you can salely iun Loth IGPs concuiiently il an existing uevice`s
CPU loau is less than 50 while its memoiy loau is less than 60. Il the uevice`s
CPU oi memoiy loau is highei, you shoulu consiuei a uevice upgiaue oi a migiation
appioach that uoes not place Loth IGPs in seivice at the same time.
Nctwor| c|canup and dcsign
IGP migiation is an oppoitune time to iiu youi netwoik ol excess Laggage anu
pooi uesign chaiacteiistics that may have evolveu in an au hoc lashion ovei the
yeais. Beloie migiation, you shoulu make suie youi netwoik uocumentation is
accuiate anu that you have ieuuceu as much cluttei as possiLle Ly iemoving any
unauthoiizeu oi unneeueu auuiesses, netwoiks, peeis, piotocols, anu so loith.
Caielul thought shoulu Le leveleu at the uesign ol the new IGP. Vill it Le llat oi
hieiaichical? Does the existing auuiessing mouel accommouate? How will metiics
Le mappeu Letween the olu anu new IGPs? Vheie will you place ABRs anu ASBRs,
anu which iouteis shoulu lunction as the DRs on LAN segments?
IGP Migration Models
Seveial pioven appioaches to IGP tiansitions have Leen uevelopeu ovei the yeais, anu
most ol these appioaches shaie common elements to one uegiee oi anothei. Each en-
teipiise netwoik is unigue, anu the specilics ol youi netwoik uesign, youi stanuaius
loi acceptaLle levels ol uisiuption, anu youi Luuget will come into play when ueciuing
on a specilic appioach. The migiation stiategies aie piesenteu in an oiuei iepiesenting
easiest to most uillicult. The moie uillicult stiategies aie olten comLineu with a moie
extensive netwoik ieuesign given the woik alieauy Leing peiloimeu.
The Overlay Model
The oveilay mouel is geneially consiueieu the most stiaightloiwaiu IGP migiation ap-
pioach. The oveilay is Lest suiteu to netwoiks that have a similai bcjorc and ajtcr logical
topology. Foi example, il the legacy netwoik is a llat RIP netwoik anu the pioposeu
IGP Migration | 207
uesign is a single aiea OSPF netwoik, logically Loth netwoiks aie llat anu IGP migiation
will Le stiaightloiwaiu. Using an oveilay appioach to move liom a llat to a hieiaichical
netwoik can Le iile with uilliculties. Foi example, a llat netwoik`s auuiessing scheme
may not accommouate a sounu hieiaichical uesign, anu the placement ol noues may
not accommouate the uesiieu location oi level ol ieuunuancy loi things such as ABRs.
Figuie 6-+ illustiates a netwoik iunning Loth the legacy (RIP) anu the new (OSPF) IGPs.
Because Layei 2 switching is olten useu in the access anu aggiegation layeis, the locus
ol most IGP migiations is centeieu on the coie layeithe technigues uemonstiateu
heie aie applicaLle loi access anu aggiegation layei migiations as well. Note how Loth
IGPs aie conliguieu at the same time, that the new IGP is initially set to Le less pieleiieu
(Loth OSPF pieleience values aie laigei than RIP`s uelault 100), anu that each ioutei
senus upuates loi Loth IGPs in a ships-in-the-night lashion, meaning that neithei IGP
is awaie ol the othei`s opeiation.
Iigurc -1. Thc ovcr|ay nodc|
The oveilay mouel hinges on all uevices having the aLility to iun Loth the olu anu the
new IGPs concuiiently, anu it makes heavy use ol ioute pieleience to keep the new
IGP`s ioutes liom Lecoming active, anu theieloie installeu in the loiwaiuing taLle, until
all aspects ol the new IGP`s opeiation aie ueteimineu to Le satislactoiy. Vhen ieauy
to make the cutovei, the ioute pieleience is alteieu to have the iouteis pielei the new
IGP`s ioutes. Iueally, this is all uone in paiallel, Lecause having some uevices use one
IGP`s ioutes while othei iouteis use a uilleient IGP`s ioutes can leau to loops stemming
liom vaiiances Letween each piotocol`s take on the Lest ioute. In many cases, the ouus
ol which can Le impioveu Ly the caielul mapping ol olu to new metiics, the loiwaiuing
208 | Chapter 6:Interior Gateway Protocols and Migration Strategies
paths ol Loth piotocols will Le iuentical anu you can get away with an inciemental,
Lox-at-a-time shilt in piotocol pieleience. Vhen the new IGP`s opeiation is ueemeu
staLle, the olu IGP is uecommissioneu Ly iemoving its conliguiation liom each ioutei
(theie is no neeu to peiloim this in paiallel, as you aie now using the new IGP). It`s a
goou iuea to keep a copy ol the olu conliguiation aiounu, anu you shoulu consiuei
using the deactivate lunction ol the ]unos CLI to comment out the olu IGP`s stanza,
all the while knowing that you can salely Liing it Lack at any time Ly activating that
poition ol the conliguiation.
The Redistribution Model
The ieuistiiLution mouel is olten useu when an oveilay appioach is not woikaLle Le-
cause ol a migiation liom a llat to a hieiaichical uesign oi Lecause some ol the uevices
cannot iun Loth IGPs concuiiently. The lattei conuition may Le uue to lack ol uevice
suppoit oi Lecause ol peiloimance limitations. Figuie 6-5 illustiates a Leloie-anu-altei
view ol a netwoik that, given the shilt to a hieiaichical uesign, iepiesents a goou can-
uiuate loi the ioute ieuistiiLution mouel.
The liist phase ol the migiation liom RIP to OSPF is shown in Figuie 6-6. Heie, Lack-
Lone iouteis Ale anu Lager aie conliguieu to iun Loth RIP anu OSPF concuiiently,
with the OSPF LackLone Leing loimeu as a iesult. The aiiow shows a RIP upuate sent
Ly Malt anu ieceiveu Ly Ale, wheie it will Le injecteu into the nascent LackLone as a
Type 5 AS exteinal LSA. Though not shown, ioutes oiiginating in the OSPF LackLone
unueigo a similai piocess wheieLy they aie injecteu into the RIP uomain to maintain
lull connectivity. It is ciitical to stiess that contiols must Le in place to ensuie that
ioutes aie nevei ieuistiiLuteu Lack into the RD liom wheie they oiiginateu, unless youi
goal is a netwoik-wiue test ol the IP Time to Live (TTL) mechanism. A well-planneu
auuiessing appioach always makes the lilteiing ol ioute upuates easiei, as uoes a con-
sistent appioach to ioute tagging (wheie suppoiteu Ly the piotocol). The use ol ioute
tags makes contiol ovei ioute ieuistiiLution much easiei to conliguie anu conseguently
lai less pione to human eiioi.
Once again, the OSPF pieleience is alteieu to Le |css prcjcrrcd than that ol the oiiginal
IGP, as was the case in the oveilay mouel. The uelault gloLal pieleience loi ]unos is
100 loi RIP anu 10/150 loi OSPF inteinal anu AS exteinal, iespectively. Setting these
pieleiences to 101/110 achieves the goal ol ensuiing that RIP is pieleiieu. This step
ensuies that the LackLone will always pielei ioutes in theii native RIP loim, thus
avoiuing iouting loops anu suLoptimal iouting. By way ol example, consiuei that
without this step, ioutei Barley`s 200.0.200/2+ ioute might Le initially leaineu Ly
Lager as an OSPF ioute, via a RIP upuate that was geneiateu Ly Malt anu then ieuis-
tiiLuteu into OSPF Ly Ale. By this time, Lagei shoulu have also ieceiveu a RIP upuate
loi the same pielix uiiect liom Barley. Il the pieleiences aie such that Lager pieleis
OSPF exteinals ovei RIP, we woulu have an extia hop as Lager loiwaius packets loi
200.0.200/2+ ioute ovei the OSPF LackLone thiough Ale, iathei than the uiiect shot
via Barley.
IGP Migration | 209
Iigurc -. Routc tagging in thc rcdistribution nodc| to contro| routc cxchangc
In this example, the uelault ]unos ioute pieleiences woulu have iesulteu
in the uesiieu Lehavioi. Vhen ieuistiiLuteu into OSPF, the RIP ioutes
take the loim ol AS exteinals, which Ly uelault have a pieleience ol 150,
which makes them less pieleiieu than RIP anyway. Nonetheless, it`s
iecommenueu that you always explicitly set pieleiences. It`s iaiely a
goou iuea to leave such things to chance in youi netwoik!
Iigurc -5. Thc rcdistribution nodc|
210 | Chapter 6:Interior Gateway Protocols and Migration Strategies
The next phase ol the migiation is uepicteu in Figuie 6-7, wheie iouteis PBR anu
Stout have Leen conveiteu to OSPF anu placeu into Aiea 2. The specilic appioach taken
to make this change coulu have Leen that ol an oveilay, wheie the iouteis iun RIP anu
OSPF concuiiently, oi as a hot cutovei that iemoveu the olu anu auueu the new IGP
in one lell swoop. Such cutoveis aie maue a little less stiesslul with the nothing hap-
pens until you commit natuie ol ]unos OS. IOS useis woulu likely paste such changes
in liom a conliguiation lile to tiy to minimize uisiuption. It enus with iouteis Barley
anu Malt iemaining in the RIP uomain along with the associateu inteilaces on Ale anu
Lager. The next phase ol the migiation is an iteiative piocess that iepeats the same
pioceuuie on Barley anu Malt to cieate Aiea 1. The IGP migiation is completeu with
iemoval ol any RIP iemnants liom the conliguiations ol Aiea 0 iouteis Ale anu Lager.
Iigurc -7. Routc rcdistribution |GP nigration: Phasc 2
The Integration Model
The integiation mouel is also well suiteu to IGP migiations that tiansition liom a llat
to a hieiaichical uesign, especially when a signilicant IP ieauuiessing anu/oi netwoik
inliastiuctuie upgiaue is planneu as pait ol the migiation. In the integiation mouel, a
new LackLone netwoik is ueployeu anu tieu to the legacy LackLone, wheie mutual
ioute ieuistiiLution is peiloimeu. Poitions ol the legacy netwoik aie tiansitioneu to
the new LackLone in a phaseu mannei. This type ol migiation is not hitless, Lut it uoes
alloiu a neai gieen-lielu chance to ieuesign youi IGP while conlining uown time to
those segments that aie actively Leing tiansitioneu. Once all segments have Leen mi-
giateu to the new LackLone, the legacy LackLone is uecommissioneu. This piocess is
shown in Figuie 6-S, which Legins with the legacy LackLone anu moves on to the
Luiluout ol a new LackLone anu the migiation ol one netwoik segment. The piocess
IGP Migration | 211
enus with the iightmost uiagiam showing all netwoik segments tiansitioneu to the new
LackLone anu iemoval ol the legacy LackLone inliastiuctuie.
You`ll again linu mutual ioute ieuistiiLution at play, anu also this ieguiies stiict contiol
to pievent ioutes liom Leing sent Lack to theii oiiginating IGP. As each netwoik seg-
ment is tiansitioneu, you may Le aLle to ueploy an oveilay appioach oi you might Le
loiceu into a hot cutovei Laseu on eguipment capaLility anu the level ol netwoik ie-
uesign (e.g., any ienumLeiing that is also planneu).
It goes without saying, Lut we will state it heie anyway, that the integiation mouel
iepiesents the laigest uegiee ol elloit anu capital expenuituie. Theie is the cost ol new
eguipment anu new LackLone Luiluout, anu then the sustaining costs ol Loth the legacy
anu new LackLones as segments aie tiansitioneu. Duiing these tiansitions, theie may
Le signilicant ienumLeiing anu a neeu to ueploy the new LackLone piotocol on iouteis
as they Lecome pait ol the new IGP.
IGP Migration Summary
Netwoiks, like people, evolve anu change ovei time. Many netwoiks aie still iunning
yesteiuay`s IGP anu coulu Lenelit liom a lacelilt in the inteiioi iouting uepaitment. Oi
mayLe youi netwoik is iunning some piopiietaiy iouting piotocol anu you have ueci-
ueu that it is time to auu anothei venuoi to the netwoik, loi whatevei ieason. Eithei
way, the technigues anu concepts uiscusseu heie can help to minimize uisiuption anu
make the shilt to a new IGP as pain-liee as possiLle.
In the next section, you will put this theoiy into piactice as you migiate a netwoik liom
RIP to the OSPF piotocol.
Iigurc -8. Thc intcgration nodc|
212 | Chapter 6:Interior Gateway Protocols and Migration Strategies
Overlay Migration Scenario: RIP to OSPF
]ust when you aie consiueiing some well-ueseiveu time oll, given the success ol the
iecently ueployeu RIPv2 inteinetwoik, you ieceive notilication liom the new CIO that
the Beei-Co netwoik must migiate to OSPF as pait ol a moueinization initiative. Beei-
Co has conuucteu a uesign ieview anu ueteimineu that a single OSPF aiea with the
aLility to expanu to a hieiaichical uesign in the neai lutuie is ieguiieu.
Consiueiing the migiation methous uesciiLeu in the pievious section anu the cuiient
uesign ciiteiia, you piopose an oveilay-Laseu migiation. The ieasons loi this iecom-
menuation incluue the lollowing:
Both the legacy anu planneu netwoiks aie llat.
Both the legacy Cisco anu new ]unipei Netwoiks geai suppoit the legacy anu new
IGPs.
It`s the most uiiect migiation stiategy, anu you aie still smaiting liom tilting at RIP.
Figuie 6-9 shows the Leloie, uuiing, anu altei netwoiks. In the miuule, Loth IGPs aie
iunning, Lut alteieu pieleiences ensuie that RIP ioutes iemain active, which pioviues
you the chance to veiily all aspects ol OSPF bcjorc its ioutes Lecome active. The key
to the oveilay mouel is alteieu piotocol pieleiences, anu the liguie also shows the
Leginning, initial mouilication, anu linal pieleience values loi RIP anu OSPF inteinal/
exteinal ioutes.
The ciitical point occuis Leloie OSPF is activateu (especially in IOS, wheie changes
take ellect immeuiately as they aie enteieu). Both the inteinal anu exteinal pieleiences
aie set so that RIP iemains unpeituiLeu until you aie ieauy to ietiie it. Failing to ensuie
that OSPF exteinal pieleience is set lowei (is moie pieleiieu) than RIP leaus to a
Fiankenstein-like loiwaiuing mouel that has the simulateu customei netwoiks anu
ieuistiiLuteu loopLack ioutes loiwaiuing ovei OSPF paths while the inteinal ioutes
continue to loiwaiu via RIP.
The ]unipei Loxes aie conliguieu liist (iecall that, until you commit, no change takes
ellect, so you have a salety net ol iollLack oi commit conliimeu in case you uo not like
the iesults). The OSPF stanza is uisplayeu at Ale along with the associateu set com-
manus using the CLI`s show | display set commanu. The authentication key value
jncie is ieuseu heie. Also ol note aie the alteieu pieleience values loi OSPF inteinal
anu exteinal ioutesthat authentication is conliguieu at the aiea level while the spe-
cilics aie set on a pei-inteilace Lasis:
[edit protocols ospf]
lab@Ale# show
preference 105;
external-preference 106;
export ospf_export; ## 'ospf_export' is not defined
area 0.0.0.0 {
authentication-type md5;
interface ge-0/0/0.69 {
Overlay Migration Scenario: RIP to OSPF | 213
authentication {
md5 1 key "$9$Yb4JD3nCu0I.PF/"; ## SECRET-DATA
}
}
interface ge-0/0/0.1121 {
authentication {
md5 1 key "$9$WitXNbiHmTQn4ajq"; ## SECRET-DATA
}
}
}
[edit protocols ospf]
lab@Ale# show | display set
set protocols ospf preference 105
set protocols ospf external-preference 106
set protocols ospf export ospf_export
set protocols ospf area 0.0.0.0 authentication-type md5
set protocols ospf area 0.0.0.0 interface ge-0/0/0.69 authentication
md5 1 key "$9$Yb4JD3nCu0I.PF/"
set protocols ospf area 0.0.0.0 interface ge-0/0/0.1121 authentication
md5 1 key "$9$WitXNbiHmTQn4ajq"
Iigurc -9. R|P-to-OSPI ovcr|ay topo|ogy
Like RIP, OSPF ieguiies an expoit policy loi ioute ieuistiiLution, anu the CLI`s copy
leatuie is evokeu to save some elloit:
214 | Chapter 6:Interior Gateway Protocols and Migration Strategies
[edit protocols ospf]
lab@Ale# top edit policy-options
[edit policy-options]
lab@Ale# copy policy-statement rip_export to policy-statementospf_export
[edit policy-options]
lab@Ale# edit policy-statement ospf_export
[edit policy-options policy-statement ospf_export]
lab@Ale# show
term 1 {
from protocol direct;
then accept;
}
term 2 {
from {
protocol static;
route-filter 200.0.1.0/24 exact;
}
then {
metric 3;
accept;
}
}
term 3 {
from protocol rip;
then accept;
}
Looking ovei the copy ol the RIP policy, now in its ienameu ospf_export loim, it seems
that the only teim that is out ol place is term 3 anu the Lit aLout matching RIP. You
ceitainly uo not want any RIP-to-OSPF ieuistiiLution in this example! Ve iemove
term 3 (committing the changes) anu make similai changes to Lager:
[edit policy-options policy-statement ospf_export]
lab@Ale# delete term 3
Altei a lew moments, the OSPF aujacency status is conliimeu Letween Ale anu Lager.
Recall that Malt anu Barley have not Leen conliguieu with OSPF at this time:
[edit]
lab@Ale# run show ospf interface
Interface State Area DR ID BDR ID Nbrs
ge-0/0/0.1121 DR 0.0.0.0 10.10.128.1 10.10.128.2 1
ge-0/0/0.69 DR 0.0.0.0 10.10.128.1 0.0.0.0 0
The output liom the show ospf interface commanu conliims that OSPF is iunning on
the uesiieu inteilaces anu that local ioutei Ale has won the DR election on Loth ol its
inteilaces. Consiueiing that Ale is alone (zeio neighLois have Leen uetecteu) on its
ge-0/0/0.69 inteilace, its DR status on that segment shoulu Le no suipiise. You can
also veiily the aiea 0 setting anu that the only othei ioutei on the fe0-0/0/0.1121 link
has uelegateu itsell to Le the Lackup DR. RememLei that piioiity anu RID lactoi only
uuiing an active election. Given the matcheu piioiity anu Ale`s lowei RID (its lo0
Overlay Migration Scenario: RIP to OSPF | 215
auuiess is lowei than Lager`s), this must Le a case ol Ale having Leen conliguieu loi
OSPF liist. The liist non-0 piioiity ioutei up always Lecomes the DR:
[edit]
lab@Ale# run show ospf neighbor
Address Interface State ID Pri Dead
10.10.129.2 ge-0/0/0.1121 Full 10.10.128.2 128 38
The show ospf neighbor commanu veiilies that a lull aujacency has Leen loimeu Le-
tween Ale anu Lager, which is a veiy goou sign inueeu:
[edit]
lab@Ale# run show route protocol ospf
inet.0: 19 destinations, 22 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.128.2/32 [OSPF/105] 00:01:03, metric 1
> to 10.10.129.2 via ge-0/0/0.1121
192.168.2.0/30 [OSPF/105] 00:01:03, metric 2
> to 10.10.129.2 via ge-0/0/0.1121
200.0.2.0/24 [OSPF/106] 00:01:03, metric 3, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
224.0.0.5/32 *[OSPF/10] 00:07:52, metric 1
MultiRecv
Showing the ioutes leaineu via OSPF conliims seveial impoitant points. One is simply
that ioutes aie Leing leaineu via OSPF (Lager`s 10.10.126.2 loopLack anu the
192.16S.2.0 link to Barley), anu egually signilicant is that none ol these leaineu OSPF
ioute aie cuiiently active.
Unlike IOS, which ieguiies that you iun OSPF on the loopLack inteilace
to auveitise its associateu ioute, ]unos automatically auveitises a stuL
ioute to the dcjau|t auuiess useu as the souice ol the RID, assuming that
a RID has not Leen explicitly set unuei [routing-options]. Because the
lo0 inteilace is the liist to Le activateu, the lo0 inteilace`s prinary au-
uiess is useu as the RID. In contiast, loi IOS it is common to eithei iun
a passive OSPF instance on the loopLack inteilace oi to ieuistiiLute the
connecteu ioutei into OSPF, as shown in the lollowing example.
A linal conliimation that oui ioute pieleience changes aie woiking comes when we
uisplay the ioute to Lager`s customei netwoik at Ale:
[edit]
lab@Ale# run show route 200.0.2.0
inet.0: 19 destinations, 22 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.0.2.0/24 *[RIP/100] 02:47:22, metric 4, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
216 | Chapter 6:Interior Gateway Protocols and Migration Strategies
[OSPF/106] 00:09:29, metric 3, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
Peilect! Ale has Loth OSPF anu RIP copies ol the customei ioute. The key thing heie
is that the oiiginal RIP veision is, anu has always Leen, active. Unlike RIP, the uisplayeu
OSPF ioute metiic uoes not iellect Ale`s inteilace costs to ieach Lager. Vith the uelault
scaling lactoi ol 100,000,000, the cost loi Ale`s Fast Etheinet inteilace is 1 (you can
conliim this with a show ospf interface detail commanu), so you might expect to see
Ale uisplay a cost ol + loi the 200.0.0.2/2+ pielix. The ieason loi this situation is that
the OSPF_export policy at Lager uiu not Lothei to specily a Type 1 exteinal metiic, so
the uelault Type 2 metiic is geneiateu, anu Ly OSPF stanuaius this metiic is nevei
inciementeu Ly othei iouteis. A sample ol a policy mouilication that alteis the metiic
type is pioviueu, along with the iesults oLseiveu Lack at Ale. These changes aie then
iolleu Lack to iestoie the initial Lehavioi:
[edit policy-options policy-statement ospf_export]
lab@Lager# show
term 1 {
from protocol direct;
then accept;
}
term 2 {
from {
protocol static;
route-filter 200.0.2.0/24 exact;
}
then {
metric 3;
external {
type 1;
}
accept;
}
}
[edit]
lab@Ale# run show route 200.0.2.0
inet.0: 19 destinations, 22 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.0.2.0/24 *[RIP/100] 03:03:06, metric 4, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
[OSPF/106] 00:02:35, metric 4, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
Vith the OSPF oveilay woiking on the ]unipei Netwoiks poition ol the netwoik, we
place the eguivalent conliguiation into ellect at the Cisco Loxes. It is ciitical that the
mouilieu OSPF pieleience (setting Loth the inteinal anu exteinal to a uistance highei
than RIP`s) Le the liist thing conliguieu to help ensuie that RIP is not impacteuin
IOS lanu, changes go into ellect as soon as they aie enteieu. By uelault, IOS assigns the
same auministiative uistance to OSPF inteinals anu exteinals (anu inteiaiea, loi that
mattei), so we shoulu auopt the same appioachas long as the uistance loi all OSPF
Overlay Migration Scenario: RIP to OSPF | 217
ioutes is less pieleiieu than RIP, it will Le OK. The commanus enteieu on Malt aie
shown. Similai commanus aie also enteieu on Barley:
Malt# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Malt(config)# router ospf 10
Malt(config-router)# distance 125
Malt(config-router)# area 0 authentication message-digest
Malt(config-router)# redistribute static route-map TAGGING
% Only classful networks will be redistributed
Malt(config-router)# network 10.0.0.0 0.255.255.255 area 0
Malt(config-router)# network 192.168.2.0 0.0.0.3 area 0
Malt(config-router)# default-information originate route-map FOO
Malt(config-router)# exit
Malt(config)# interface fastEthernet 0/1.69
Malt(config-subif)# ip ospf message-digest-key 1 md5 jncie
Malt(config-router)# exit
Malt(config)# interface serial 0/0
Malt(config-subif)# ip ospf message-digest-key 1 md5 jncie
Malt(config)# route-map FOO permit 20
Malt(config-route-map)# match ip address 4
Malt(config-route-map)# set tag 100
Malt(config-subif)# ^Z
Malt#
*Mar 1 04:01:28.603: %SYS-5-CONFIG_I: Configured from console by
console
*Mar 1 04:01:30.495: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.128.1 on FastEthernet0/
1.69 from LOADING to FULL, Loading Done
The iesultant OSPF poition ol the conliguiation is shown next, along with the new
ioute map. Note the log message in the pievious captuie iepoiting an up aujacency on
Malt`s fa 0/1.69 inteilace. This is a goou inuication that we have compatiLle OSPF
settings Letween the Cisco anu ]unipei iouteis:
router ospf 10
log-adjacency-changes
area 0 authentication message-digest
redistribute static route-map TAGGING
network 10.0.0.0 0.255.255.255 area 0
network 192.168.2.0 0.0.0.3 area 0
default-information originate route-map FOO
distance 125
!
. . .
route-map FOO permit 20
match ip address 4
set tag 100
!
The conliguiation cieates an OSPF instance iuentilieu as 10, enaLles MD5 authenti-
cation in aiea 0, ieuistiiLutes anu ioute-maps the same ioutes useu in the RIP example,
anu enaLles OSPF aiea 0 in the seiial 0/0 anu fa 0/1.60 inteilaces. Note that in the IOS
implementation, OSPF will not ieuistiiLute a uelault static ioute. You must use the
default-information originate commanu insteau. Using the pieexisting TAGGING ioute
218 | Chapter 6:Interior Gateway Protocols and Migration Strategies
map uiu not woik, so a new ioute map nameu FOO was cieateu. It`s things such as this
that make you appieciate the consistent natuie ol ]unos iouting policy.
In an appioach that is similai to ]unos OSPF conliguiation, the specilic MD5 key ID
anu key value aie set unuei each inteilace. The uilleience is that loi ]unos, this was
uone within the OSPF conliguiation piopei, wheieas loi IOS, it is unuei the inteilace
conliguiation. The OSPF authentication settings aie also shown loi one ol Malt`s
inteilaces:
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
interface FastEthernet0/1.69
encapsulation dot1Q 69
ip address 192.168.1.1 255.255.255.252
ip rip authentication mode md5
ip rip authentication key-chain test
ip ospf message-digest-key 1 md5 jncie
no snmp trap link-status
!
Altei a lew moments, the OSPF status is analyzeu on Malt:
Malt# show ip ospf interface fastEthernet 0/1.69
FastEthernet0/1.69 is up, line protocol is up
Internet Address 192.168.1.1/30, Area 0
Process ID 10, Router ID 10.10.128.100, Network Type BROADCAST,
Cost: 1
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 10.10.128.1, Interface address 192.168.1.2
Backup Designated router (ID) 10.10.128.100, Interface address
192.168.1.1
Timer intervals configured, Hello 10, Dead 40, Wait 40,
Retransmit 5
oob-resync timeout 40
Hello due in 00:00:05
Index 3/3, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.10.128.1 (Designated Router)
Suppress hello for 0 neighbor(s)
Message digest authentication enabled
Youngest key id is 1
The show ip ospf interface commanu loi Malt`s fa 0/1.69 veiilies the piesence ol a
neighLoi with RID 10.10.12S.1 (Ale`s loopLack auuiess/RID) anu conliims the au-
thentication anu timei settings that aie in ellect. As expecteu, Ale iemains the DR
Lecause in OSPF, this DR election is not ieveitive:
Malt# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
Overlay Migration Scenario: RIP to OSPF | 219
10.10.128.1 128 FULL/DR 00:00:38 192.168.1.2 FastEthernet0/1.69
10.10.128.200 0 FULL/ - 00:00:36 10.1.254.2 Serial0/0
The show ip ospf neighbor commanu conliims the expecteu aujacencies to Loth
Barley anu Ale. Ve next uisplay a simulateu customei ioute to conliim that the RIP
copy is still Leing useu at the Cisco Loxes:
Malt# show ip route 200.0.2.0
Routing entry for 200.0.2.0/24
Known via "rip", distance 120, metric 4
Redistributing via rip
Last update from 10.1.254.2 on Serial0/0, 00:00:03 ago
Routing Descriptor Blocks:
* 10.1.254.2, from 10.1.254.2, 00:00:03 ago, via Serial0/0
Route metric is 4, traffic share count is 1
192.168.1.2, from 192.168.1.2, 00:00:14 ago, via FastEthernet0/1.69
Route metric is 4, traffic share count is 1
The output conliims that the RIP veision ol the ioute is still active.
Unloitunately, IOS uisplays on|y the active ioute, making it haiu to
conliim that OSPF shauow veisions also exist. The LSDB is inspecteu
to make this ueteimination:
Malt# show ip ospf database external adv-router 10.10.128.2
OSPF Router with ID (192.168.1.1) (Process ID 120)
OSPF Router with ID (10.10.128.100) (Process ID 10)
Type-5 AS External Link States
LS age: 97
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.10.128.2 (External Network Number )
Advertising Router: 10.10.128.2
LS Seq Number: 80000006
Checksum: 0x2858
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 0
Forward Address: 0.0.0.0
External Route Tag: 0
Routing Bit Set on this LSA
LS age: 397
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 200.0.2.0 (External Network Number )
Advertising Router: 10.10.128.2
LS Seq Number: 80000006
Checksum: 0x92B6
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 3
220 | Chapter 6:Interior Gateway Protocols and Migration Strategies
Forward Address: 0.0.0.0
External Route Tag: 0
The exteinal (in lixeu coue) aigument to the show ip ospf database commanu lilteis
the output such that only AS LSAs sent Ly Lager aie shown. The adv-router aigument
specilieu Lager`s OSPF RID to iuentily it liom all othei souices ol AS exteinal LSAs in
the OSPF RD. The output conliims that Lager`s customei ioute (200.0.2/2+) is Leing
auveitiseu into OSPF.
RIP-to-OSPF Migration: Cutover to OSPF
Vith vaiious aspects ol OSPF opeiation conliimeu, it`s time to make the cut liom RIP
to OSPF. This shoulu Le a nonuisiuptive piocess, Lut as with all IGP migiation pio-
ceuuies, it`s Lest to peiloim the cutovei in a maintenance winuow as auueu insuiance
the inteiplay ol complex inteinetwoiking piotocols is sometimes haiu to pieuict. The
actual tiansition noimally occuis in two phases. Fiist, make the OSPF ioutes active,
anu then, altei you conliim piopei opeiation, iemove all tiaces ol the legacy piotocol
anu ieset the new piotocol to its uelault pieleience values.
To achieve the liist goal you coulu ieconliguie the OSPF inteinal anu exteinal pielei-
ences to Le moie pieleiieu than RIP, oi you coulu altei RIP`s pieleience to Le less
pieleiieu than OSPF. Eithei way, il something Llows up, you can ioll Lack oi simply
iemove the OSPF conliguiation, anu ietuin to RIP opeiation while ueteimining what
went wiong. Given that IOS is now set with a single pieleience loi Loth OSPF anu RIP,
the amount ol change is a wash. On the ]unos uevices, it will Le easiei to change the
one RIP pieleience iathei than Loth OSPF values. Theieloie, the plan is to set the RIP
auministiative uistance to 126 on the IOS uevices, while setting the RIP pieleience to
107 on the ]unos uevices. In Loth cases, the change will make RIP a less-pieleiieu
piotocol.
The changes aie shown loi the ]unipei ioutei Ale. Similai commanus aie also executeu
at Lager:
[edit protocols]
lab@Ale# set rip group rip preference 107
The RIP auministiative uistance is alteieu on Loth IOS Loxes:
Malt# conf terminal
Enter configuration commands, one per line. End with CNTL/Z.
Malt(config)# router rip
Malt(config-router)# distance 126
Altei a lew moments, it`s conliimeu that the OSPF veision ol Lager`s 200.0.2.0 ioute
is now pieleiieu at Barley:
Barley# show ip route 200.0.2.0
Routing entry for 200.0.2.0/24
Known via "ospf 10", distance 125, metric 3, type extern 2, forward
metric 1
Overlay Migration Scenario: RIP to OSPF | 221
Last update from 192.168.2.2 on FastEthernet0/1.70, 00:03:42 ago
Routing Descriptor Blocks:
* 192.168.2.2, from 10.10.128.2, 00:03:42 ago, via FastEthernet0/1.70
Route metric is 3, traffic share count is 1
Back at the ]unipei siue ol things, you shoulu make a similai ueteimination as to which
set ol ioutes is pieleiieu. Note how ioutes leaineu thiough multiple souices aie cleaily
shown in ]unos, anu that the active veisions ol these ioutes aie now OSPF-Laseu:
lab@Ale# run show route
inet.0: 19 destinations, 26 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/106] 00:00:25, metric 1, tag 200
> to 10.10.129.2 via ge-0/0/0.1121
[RIP/107] 06:14:07, metric 2, tag 100
> to 192.168.1.1 via ge-0/0/0.69
10.1.254.0/24 *[OSPF/105] 00:08:03, metric 66
> to 10.10.129.2 via ge-0/0/0.1121
[RIP/107] 06:14:07, metric 2, tag 0
> to 192.168.1.1 via ge-0/0/0.69
10.1.254.1/32 *[RIP/107] 04:14:22, metric 3, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
10.1.254.2/32 *[RIP/107] 06:14:07, metric 2, tag 0
> to 192.168.1.1 via ge-0/0/0.69
10.10.128.100/32 *[OSPF/105] 00:08:03, metric 67
> to 10.10.129.2 via ge-0/0/0.1121
[RIP/107] 06:14:07, metric 2, tag 0
> to 192.168.1.1 via ge-0/0/0.69
10.10.128.200/32 *[OSPF/105] 00:08:03, metric 3
> to 10.10.129.2 via ge-0/0/0.1121
10.10.128.1/32 *[Direct/0] 3d 21:34:05
> via lo0.0
10.10.128.2/32 *[OSPF/105] 00:08:03, metric 1
> to 10.10.129.2 via ge-0/0/0.1121
[RIP/107] 05:45:43, metric 2, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
10.10.129.0/24 *[Direct/0] 2d 22:32:39
> via ge-0/0/0.1121
10.10.129.1/32 *[Local/0] 3d 21:34:05
Local via ge-0/0/0.1121
192.168.1.0/30 *[Direct/0] 2d 22:32:39
> via ge-0/0/0.69
192.168.1.2/32 *[Local/0] 3d 06:03:32
Local via ge-0/0/0.69
192.168.2.0/30 *[OSPF/105] 00:08:03, metric 2
> to 10.10.129.2 via ge-0/0/0.1121
[RIP/107] 05:45:43, metric 2, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
200.0.1.0/24 *[Static/5] 2d 07:10:57
Discard
200.0.2.0/24 *[OSPF/106] 00:08:03, metric 3, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
[RIP/107] 05:45:43, metric 4, tag 0
222 | Chapter 6:Interior Gateway Protocols and Migration Strategies
D
o
> to 10.10.129.2 via ge-0/0/0.1121
200.0.100.0/24 *[OSPF/106] 00:08:03, metric 3, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
[RIP/107] 06:14:07, metric 4, tag 0
> to 192.168.1.1 via ge-0/0/0.69
200.0.200.0/24 *[OSPF/106] 00:08:03, metric 3, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
224.0.0.5/32 *[OSPF/10] 03:14:39, metric 1
MultiRecv
224.0.0.9/32 *[RIP/100] 00:08:03, metric 1
MultiRecv
The uisplay shows the uelault ioute in its OSPF anu RIP loims, Loth ol which aie taggeu
uue to ioute-map actions. Heie, Ale has installeu the uelault geneiateu Ly Barley (tag
200), with the RIP veision leaineu uiiectly liom Malt also listeu (tag 100). The ]unos
CLI`s matching lunction is useu to iuentily any iemaining active RIP ioutes. The \ is
useu heie to escape the * chaiactei, so it is not incoiiectly expanueu as a shell wilucaiu,
iathei than a specilic match conuition:
[edit protocols]
lab@Ale# run show route protocol rip | match \*
+ = Active Route, - = Last Active, * = Both
10.1.254.1/32 *[RIP/107] 04:16:48, metric 3, tag 0
10.1.254.2/32 *[RIP/107] 06:16:33, metric 2, tag 0
224.0.0.9/32 *[RIP/100] 00:10:29, metric 1
Besiues the multicast ioute associateu with RIPv2, only the /32 host ioutes liom the
MaltBarley seiial link aie still active as a RIP ioute. This is not an issue, as the ielateu
suLnet 10.1.25+.0/2+ is coiiectly auveitiseu into OSPF (see the pievious ioute uisplay).
These iesults conliim that it`s sale to iemove RIP liom the inteinetwoik. Things Legin
liist at the ]unipei Netwoiks Loxes:
[edit]
lab@Ale# delete protocols rip
Anu then the change occuis at the Cisco Loxes:
Malt# conf terminal
Enter configuration commands, one per line. End with CNTL/Z.
Malt(config)# no router rip
Malt(config)# ^Z
Malt#
Though not shown, the ielateu RIP policy anu ioute maps can now Le salely iemoveu.
Altei a lew moments ol waiting, no angiy useis suilace, anu OSPF iouting is veiilieu
at Ale. Peihaps it`s now time loi that vacation.
[edit]
lab@Ale# run show route protocol rip
inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
_ _juniper_private1_ _.inet.0: 2 destinations, 2 routes (2 active,
0 holddown, 0 hidden)
Overlay Migration Scenario: RIP to OSPF | 223
No moie RIP ioutes, as planneu:
[edit]
lab@Ale# run show route 200.0.200.0
inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.0.200.0/24 *[OSPF/106] 00:16:20, metric 3, tag 0
> to 10.10.129.2 via ge-0/0/0.1121
The active ioute is still OSPF, anu a tiaceioute conliims iuentical connectivity:
[edit]
lab@Ale# run traceroute 200.0.200.1 no-resolve
traceroute to 200.0.200.1 (200.0.200.1), 30 hops max, 40 byte
packets
1 10.10.129.2 17.647 ms 14.877 ms 14.854 ms
2 192.168.2.1 8.879 ms 10.982 ms 9.878 ms
3 192.168.2.1 10.287 ms !H * 10.282 ms !H
Before You Go, Can You Set Up Area 1 Real Quick?
So, the CIO ol Beei-Co is so impiesseu with the success ol the RIP-to-OSPF migiation
that you have Leen askeu to Liing up an Aiea 1 attachment to ioutei PBR. This is to Le
a stuL aiea, with a uelault ioute injecteu Ly the aiea`s ABR so that PBR can ieach the
vaiious OSPF exteinal uestinations now piesent in the new netwoik. Figuie 6-10 shows
the new topology. You may assume that inteilace paiameteis aie coiiectly set.
Iigurc -10. A hicrarchica| OSPI nctwor|
224 | Chapter 6:Interior Gateway Protocols and Migration Strategies
In Figuie 6-10`s example, PBR`s ge-0/0/1 inteilace has Leen loopeu Lack (to ensuie that
it`s ueclaieu up, even il not connecteu), anu live VLANs have Leen cieateu, each with
an IP auuiess in the loim ol 200.10.x.1/2+. All live ol these logical inteilaces have Leen
placeu into OSPF aiea 1, which has Leen set as a stuL aiea. PBR`s OSPF anu ge-0/0/1
conliguiation is as lollows:
[edit]
lab@PBR# show interfaces ge-0/0/1
vlan-tagging;
fastether-options {
loopback;
}
unit 1 {
vlan-id 1;
family inet {
address 200.10.1.1/24;
}
}
unit 2 {
vlan-id 2;
family inet {
address 200.10.2.1/24;
}
}
unit 3 {
vlan-id 3;
family inet {
address 200.10.3.1/24;
}
}
unit 4 {
vlan-id 4;
family inet {
address 200.10.4.1/24;
}
}
unit 5 {
vlan-id 5;
family inet {
address 200.10.5.1/24;
}
}
[edit]
lab@PBR# show protocols ospf
area 0.0.0.1 {
stub;
interface ge-0/0/1.1;
interface ge-0/0/1.2;
interface ge-0/0/1.3;
interface ge-0/0/1.4;
interface ge-0/0/1.5;
interface ge-0/0/0.1141;
}
Overlay Migration Scenario: RIP to OSPF | 225
Meanwhile, a compatiLle OSPF aiea 1 conliguiation has Leen auueu at Ale:
[edit protocols ospf area 0.0.0.1]
lab@Ale# show
stub default-metric 10;
interface ge-0/0/0.1141;
Note that to inject a uelault ioute into the stuL, you must specily a uelault metiic. Altei
a lew moments, OSPF opeiation is conliimeu at PBR. The show ospf neighbor commanu
conliims that the aujacency to Ale is estaLlisheu:
[edit protocols ospf]
lab@PBR# run show ospf neighbor
Address Interface State ID Pri Dead
10.10.130.1 ge-0/0/0.1141 Full 10.10.128.1 128 39
The uisplay ol OSPF ioutes veiilies the piesence ol the uelault ioute, injecteu Ly ABR
ioutei Ale, anu ieveals an aLsence ol AS exteinals, which aie not peimitteu in a stuL
netwoik. On|y LSA types 1, 2, anu 3 aie peimitteu in a stuL aieathe OSPF ioute taLle
at PBR contains only intiaaiea anu inteiaiea ioutes, thus conliiming this aspect ol OSPF
stuL aiea opeiation:
[edit]
lab@PBR# run show ospf route
Prefix Path Route NH Metric NextHop Nexthop
Type Type Type Interface addr/label
10.10.128.1 Intra Area BR IP 1 ge-0/0/0.1141 10.10.130.1
0.0.0.0/0 Inter Network IP 11 ge-0/0/0.1141 10.10.130.1
10.10.128.1/32 Intra Network IP 1 ge-0/0/0.1141 10.10.130.1
10.10.128.2/32 Inter Network IP 2 ge-0/0/0.1141 10.10.130.1
10.10.129.0/24 Inter Network IP 2 ge-0/0/0.1141 10.10.130.1
10.10.130.0/24 Intra Network IP 1 ge-0/0/0.1141
10.10.131.0/24 Inter Network IP 3 ge-0/0/0.1141 10.10.130.1
192.168.1.0/30 Inter Network IP 2 ge-0/0/0.1141 10.10.130.1
192.168.2.0/30 Inter Network IP 3 ge-0/0/0.1141 10.10.130.1
200.10.1.0/24 Intra Network IP 1 ge-0/0/1.1
200.10.2.0/24 Intra Network IP 1 ge-0/0/1.2
200.10.3.0/24 Intra Network IP 1 ge-0/0/1.3
200.10.4.0/24 Intra Network IP 1 ge-0/0/1.4
200.10.5.0/24 Intra Network IP 1 ge-0/0/1.5
PBR ielies on the ABR-geneiateu uelault ioute to ieach exteinal uestinations Lecause
AS exteinal LSAs aie not auveitiseu into stuL aieas:
[edit protocols ospf]
lab@PBR# run show route 200.0.200.1
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/10] 00:04:31, metric 11
> to 10.10.130.1 via ge-0/0/0.1141
226 | Chapter 6:Interior Gateway Protocols and Migration Strategies
You can auu the no-summaries keywoiu to the aiea 1 conliguiation at the stuL aiea`s
ABR (Ale) to also liltei Type 3 netwoik summaiy LSAs, which also iesult in the use ol
a uelault ioute loi inteiaiea uestinations. Vith this change, a totally stuLLy aiea is Loin:
[edit protocols ospf area 0.0.0.1]
lab@Ale# set stub no-summaries
[edit protocols ospf area 0.0.0.1]
lab@Ale# commit
The iesults aie conliimeu at PBR, whose LSDB just got much smallei:
[edit]
lab@PBR# run show ospf route
Prefix Path Route NH Metric NextHop Nexthop
Type Type Type Interface addr/label
10.10.128.1 Intra Area BR IP 1 ge-0/0/0.1141 10.10.130.1
0.0.0.0/0 Inter Network IP 11 ge-0/0/0.1141 10.10.130.1
10.10.128.1/32 Intra Network IP 1 ge-0/0/0.1141 10.10.130.1
10.10.130.0/24 Intra Network IP 1 ge-0/0/0.1141
200.10.1.0/24 Intra Network IP 1 ge-0/0/1.1
200.10.2.0/24 Intra Network IP 1 ge-0/0/1.2
200.10.3.0/24 Intra Network IP 1 ge-0/0/1.3
200.10.4.0/24 Intra Network IP 1 ge-0/0/1.4
200.10.5.0/24 Intra Network IP 1 ge-0/0/1.5
[edit protocols ospf]
lab@PBR# run show route 192.168.1.1
inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/10] 00:01:41, metric 11
> to 10.10.130.1 via ge-0/0/0.1141
A final task: Aggregate network summaries into the backbone
Aiea 1 is now guite optimizeu, Lut it has Leen calleu to youi attention that the live
200.10.x.1/2+ netwoiks owneu Ly PBR aie Leing llooueu into the LackLone as inuiviuual
Type 3 netwoik summaiy LSAs. This is noimal loi OSPF, Lut youi CIO wants to iun
a tight ship anu has askeu that you geneiate a single summaiy LSA into aiea 0 in place
ol the cuiient live. Beloie making changes, you conliim that the CIO has coiiectly
uesciiLeu the netwoik summaiy situation Ly uisplaying Type 3 LSAs geneiateu Ly ABR
Ale. Note that these summaiies aie in LackLone aiea 0:
[edit]
lab@Lager#run show ospf database netsummary advertising-router
10.10.128.1
OSPF link state database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Summary 10.10.130.0 10.10.128.1 0x80000003 421 0x22 0xc449 28
Summary 10.20.128.3 10.10.128.1 0x80000002 421 0x22 0x46bd 28
Summary 200.10.1.0 10.10.128.1 0x80000002 421 0x22 0xb11f 28
Overlay Migration Scenario: RIP to OSPF | 227
Summary 200.10.2.0 10.10.128.1 0x80000002 421 0x22 0xa629 28
Summary 200.10.3.0 10.10.128.1 0x80000002 421 0x22 0x9b33 28
Summary 200.10.4.0 10.10.128.1 0x80000002 421 0x22 0x903d 28
Summary 200.10.5.0 10.10.128.1 0x80000002 421 0x22 0x8547 28
Taking note ol Lager`s cuiient aiea 0 LSDB state, you make a change to the aiea 1
poition ol Ale, which iesults in the summaiization ol matching netwoik summaiy
LSAs:
[edit protocols ospf area 0.0.0.1]
lab@Ale# set area-range 200.10/16
[edit protocols ospf area 0.0.0.1]
lab@Ale# show
stub default-metric 10 no-summaries;
area-range 200.10.0.0/16;
interface ge-0/0/0.1141;
The area-range statement ieplaces inuiviuual netwoik summaiies that lall within the
conliguieu iange with a single netwoik summaiy iepiesenting the entiie iange. Auuing
the restrict keywoiu as pait ol the area-range statement seives to Llock any netwoik
summaiies that aie egual in length to the area-range`s mask. In othei woius, the area-
range is noimally a |ongcr lunction with iegaiu to pielix length, Lut auuing the
restrict keywoiu alteis this match type to that ol orlonger. The lattei iesults in lilteiing
ol any summaiies cqua| in length to the specilieu area-range pielix length.
Youi woik is conliimeu with a look at the netwoik summaiies now auveitiseu into aiea
0 Ly Ale:
[edit]
lab@Lager# show ospf database netsummary advertising-router
10.10.128.1
OSPF link state database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Summary 10.10.130.0 10.10.128.1 0x8000000a 9 0x22 0xb650 28
Summary 10.20.128.3 10.10.128.1 0x80000009 9 0x22 0x38c4 28
Summary 200.10.0.0 10.10.128.1 0x80000001 9 0x22 0xbe14 28
As a linal check, the connectivity liom Cisco ioutei Barley to one ol the 200.10.x.1/2+
netwoiks on PBR is conliimeu:
Barley# traceroute 200.10.1.1
Type escape sequence to abort.
Tracing the route to 200.10.1.1
1 192.168.2.2 4 msec 4 msec 12 msec
2 10.10.129.1 8 msec 4 msec 12 msec
3 200.10.1.1 4 msec 8 msec 8 msec
Awesome! This iesult completes the RIP-to-OSPF migiation. This example also
toucheu on stuL aiea anu aiea-iange summaiization conliguiation.
228 | Chapter 6:Interior Gateway Protocols and Migration Strategies
RIP Migration with the Overlay Model Summary
This section uemonstiateu a typical RIP-to-OSPF IGP migiation using the oveilay
mouel. This was uemonstiateu in a multivenuoi enviionment to help show that the
piinciples anu pioceuuies aie somewhat univeisal, alLeit with slightly vaiieu commanu
syntax that seives only to conluse the innocent. The mouilication ol gloLal ioute piel-
eiences alloweu a smooth, hitless tiansition. Once the new IGP was lounu to Le opei-
ating as expecteu, a guick change ol pieleience iesulteu in use ol the new IGP`s
loiwaiuing paths while ietaining the legacy IGP`s conliguiation (anu legacy piotocol
neighLois/aujacency state), in the event that the change neeus to Le Lackeu out guickly.
The migiation enus with the iemoval ol all legacy IGP tiaces liom the ioutei
conliguiations.
This section also showeu the conveision ol a llat OSPF netwoik into a hieiaichical
uesign that incluueu the lunction ol stuL netwoiks, totally stuLLy netwoiks, anu aiea-
iange syntax to consoliuate netwoik summaiies as they entei the LackLone.
Now is a goou time to take anothei Lieak. The next section continues oui uiscussion
ol IGP migiation, Lut this time in the context ol an EIGRP-to-OSPF scenaiio.
EIGRP-to-OSPF Migration
This section uemonstiates a smooth migiation liom a legacy EIGRP netwoik to a hi-
eiaichical OSPF IGP. You coulu take many appioaches to lacilitate such a migiation.
The Lest appioach will uepenu on numeious lactois, such as uevice suppoit ol olu anu
new IGPs anu whethei new eguipment is Leing auueu, anu il so, whethei it`s auueu to
ieplace oi augment an existing netwoik`s inliastiuctuie. Also ol consiueiation is the
legacy netwoik`s uesign with iegaiu to auuiessing anu hieiaichy, in comLination with
the uesign goals loi the new netwoik`s elliciency anu scalaLility.
The tactic uemonstiateu heie is ol the ioute ieuistiiLution vaiiety. But consiueiing that
]unipei Netwoiks iouteis have nevei spoken EIGRP, a Lit ol the integiation mouel has
to Le at woik as wellaltei all, a new LackLone is Leing Luilt out. It is acknowleugeu
that leveiaging existing netwoik inliastiuctuie will Le ol piime concein loi most en-
teipiises, anu theieloie that a typical EIGRP-to-OSPF migiation will centei on the
phaseu ieconliguiation ol existing IOS uevices to Legin iunning the new anu stop iun-
ning the olu IGP. This chaptei uemonstiates a migiation appioach in which ]unipei
Netwoiks iouteis aie auueu to loim a new OSPF LackLone while ninina| changes aie
maue to the legacy inliastiuctuie to accommouate communications Letween the
EIGRP anu OSPF uomains.
EIGRP-to-OSPF Migration | 229
The solution uemonstiateu accommouates giacelul giowth ol the OSPF LackLone
while the legacy EIGRP LackLone is phaseu out. The migiation goals loi this scenaiio
aie as lollows:
Theie shoulu Le a minimal impact to the existing IOS conliguiations anu existing
EIGRP LackLone opeiation.
The solution shoulu accommouate a phasing out ol the legacy LackLone IGP
(though not necessaiily the cuiient uevices) towaiu an all-OSPF LackLone.
The solution shoulu Le as simple as possiLle anu Le woikaLle loi small-to-laige-
scale enteipiise migiations.
The uesign must minimize the impact ol laige numLeis ol AS exteinal LSAs loi
low-enu iouteis.
Mutual Route Redistribution
To make this scenaiio woik, mutual ioute ieuistiiLution is neeueu Letween EIGRP anu
OSPF. As always, you must ensuie that ioutes aie ieuistiiLuteu only once, Lecause
loops will violate the minimal impact to existing LackLone ciiteiion. In auuition,
ioute pieleience aujustments may Le neeueu to ensuie optimal iouting, uepenuing on
the uelault pieleiences loi inteinal veisus exteinal EIGRP anu OSPF Letween the two
venuois.
As much as you might pielei to have all this happen on the ]unos uevi-
ces, the simple lact is that they cannot iun EIGRP, while the Cisco Loxes
suppoit Loth EIGRP anu OSPF. This means the ieuistiiLution woik will
have to occui in IOS lanu. Fiom the viewpoint ol the ]unipei iouteis,
howevei, this is just anothei OSPF netwoik, alLeit one with a lot ol
taggeu AS exteinals.
Figuie 6-11 pioviues the topology anu auuiessing specilics to assist the ieauei in tiack-
ing uown which uevices anu IGPs own which ioutes.
Figuie 6-12 pioviues the summaiy plan ol action, as ueiiveu liom the uesign ciiteiia
pioviueu.
The oveiall plan is to add an OSPF piocess on the Cisco iouteis that ieuistiiLutes
connecteu, static, anu EIGRP leaineu ioutes ajtcr auuing a tag value to these ioutes. In
this case, the tag chosen is Laseu on the EIGRP uomain`s AS (piocess) numLei (it coulu
Le any unigue value, howevei). In auuition, the existing EIGRP conliguiation is moui-
lieu to ieuistiiLute OSPF into EIGRP ajtcr tagging these ioutes in a similai lashion. In
Loth cases, the jirst step in the iespective ioute maps is to dcny any ioutes that alieauy
have the EIGRP piocess tag value. It`s ciitical that the ueny action occui liist, as the
whole point ol the ioute tags is to simplily the Llocking ol ioutes that oiiginateu in
EIGRP liom Leing ieuistiiLuteu Lack onto EIGRP liom OSPF. Likewise, we neeu to
230 | Chapter 6:Interior Gateway Protocols and Migration Strategies
Llock ioutes that oiiginateu in OSPF liom Leing sent Lack into OSPF Ly EIGRP; the
same tag value is also useu loi this lilteiing ieguiiement.
Recall that ieuistiiLution ol connecteu, static, oi EIGRP ioutes into OSPF iesults in
Type 5 AS exteinal LSAs, which aie in tuin llooueu ovei the entiie OSPF uomain (except
stuL aieas). This is a signilicant point, Lecause one ol the uesign goals is to minimize
the impact ol laige numLeis ol exteinal LSAs on low-enu iouteis. This is why the new,
nonLackLone OSPF aieas aie conliguieu as NSSA aieas in this example. As with the
stuL aiea example, the uelault ioute injecteu Ly the ABRs pioviues connectivity to the
exteinal uestinationsloi example, EIGRPanu the NSSA capaLility accommouates
lutuie placement ol an ASBR to oiiginate AS exteinal ioutes liom these aieas as neeueu.
Iigurc -11. E|GRP-to-OSPI nigration topo|ogy
EIGRP-to-OSPF Migration | 231
The Junos OSPF configuration
On the ]unos siue, things aie pietty stiaightloiwaiu, anu the OSPF anu ielateu policy
Lits aie shown loi Ale:
[edit]
lab@Ale# show protocols ospf
export static;
area 0.0.0.0 {
interface ge-0/0/0.69;
interface ge-0/0/0.1121;
}
area 0.0.0.1 {
nssa {
default-lsa default-metric 10;
}
interface ge-0/0/0.1141;
}
[edit]
lab@Ale# show policy-options policy-statement static
term 1 {
from {
protocol static;
Iigurc -12. E|GRP-to-OSPI nigration p|an ovcrvicw
232 | Chapter 6:Interior Gateway Protocols and Migration Strategies
route-filter 200.0.1.0/24 exact;
}
then accept;
}
The OSPF expoit policy ieuistiiLutes the simulateu customei static ioute into OSPF.
No ioute tagging is Leing peiloimeu heie, Lecause il tag 100 weie auueu, these ioutes
woulu Le lilteieu liom ieuistiiLution into the EIGRP uomain. Aiea 1 is conliguieu as
an NSSA, anu a uelault ioute is conliguieu (via the default-metric statement) loi use
Ly iouteis within the NSSA when iouting AS exteinal uestinations. Recall that all the
EIGRP ioutes will Le Lecome AS exteinals once they aie injecteu into the OSPF uomain,
making the piesence ol the uelault ioute in stuL aieas ciitical loi maintaining connec-
tivity. The conliguiation ol ]unos ioutei Stout is shown loi completeness, Lut theie is
not much to say, except that its aiea 2 is compatiLly conliguieu as an NSSA:
[edit]
lab@stout# show protocols ospf
area 0.0.0.2 {
nssa;
interface ge-0/0/0.2131;
}
The IOS configuration
The ieal woik is Leing uone on the IOS siue Lecause these uevices aie aLle to iun Loth
the olu anu the new IGPs.
Beloie auuing the new OSPF piocess to any ol the legacy Cisco iouteis, you must liist
veiily that they have the capacity to iun Loth IGPs without encounteiing peiloimance
issues. The cuiient Lest piactice is to conliim that CPU anu memoiy use aie less than
50 to 60, iespectively. Il the ioutei is alieauy iunning shoit ol iesouices, auuing a
new IGP anu ielateu ieuistiiLution may well push it ovei the limit. Oluei iouteis that
aie alieauy having tiouLle keeping up shoulu Le ieplaceu oi upgiaueu Leloie
pioceeuing.
The show memory anu show processes commanu output inuicates that Beei-Co`s IOS
Loxes aie not heavily taxeu, so we aie liee to pioceeu:
Malt# show mem stat
Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
Processor 82B00CC0 18493864 6288376 12205488 12000052 11685420
I/O 3C00000 4194304 2013112 2181192 2174960 2181148
Malt# show processes cpu sorted
CPU utilization for five seconds: 0%/0%; one minute: 0%;
five minutes: 0%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
3 15492 3513 4409 0.31% 0.80% 0.26% 0 Exec
1 0 2 0 0.00% 0.00% 0.00% 0 Chunk Manager
2 4 2527 1 0.00% 0.00% 0.00% 0 Load Meter
4 320 2958 108 0.00% 0.00% 0.00% 0 OSPF Hello
. . . .
EIGRP-to-OSPF Migration | 233
Having ueteimineu sullicient iesouice capacity, the migiation pioceeus; the mouilieu
poitions ol Cisco ioutei Malt aie shown heie:
router eigrp 100
redistribute connected
redistribute static
redistribute ospf 10 metric 10 100 255 1 1500 route-map OSPF_EIGRP
network 10.0.0.0
no auto-summary
!
router ospf 10
network 192.168.1.0 0.0.0.3 area 0
redistribute eigrp 100 metric 4 route-map EIGRP_OSPF subnets
redistribute static metric 3 route-map EIGRP_OSPF subnets
redistribute connected tag 100 subnets metric 2
!
access-list 3 permit any
!
route-map OSPF_EIGRP deny 10
match tag 100
!
route-map OSPF_EIGRP permit 20
match ip address 3
set tag 100
!
route-map EIGRP_OSPF deny 10
match tag 100
!
route-map EIGRP_OSPF permit 20
match ip address 3
set tag 100
The mouilieu poitions ol the IOS conliguiation aie highlighteu to help to call out the
uelta. The EIGRP piocess was instiucteu to ieuistiiLute ioutes liom the OSPF piocess
iuentilieu as 10, setting the EIGRP Lanuwiuth, uelay, ieliaLility, loauing, anu MTU
values to 10, 100, 255, 1, anu 1500, iespectively. The ieuistiiLution is contiolleu Ly
the logic in the ioute map nameu OSPF_EIGRP.
The entiie OSPF piocess is new anu was auueu to integiate with the new ]unipei ioutei-
Laseu LackLone. Because connecteu ioutes coulu not Le lilteieu thiough the existing
EIGRP_OSPF ioute map, tagging loi the connecteu ioutes is conliguieu uiiectly on the
uistiiLute line.
In contiast, Loth static anu EIGRP ioutes aie Leing ieuistiiLuteu thiough the contiol
ol the common EIGRP_OSPF ioute map. The subnet keywoiu inveits the uelault Lehavioi
ol ieuistiiLuting only classlul netwoiks. Lastly, you`ll see that OSPF aiea 0 is conliguieu
to iun on the link connecting Malt to Ale.
Both ioute maps make use ol an initial ueny teim loi any ioute with a tag value ol 100.
Remaining ioutes aie then matcheu against the match-all IP access list 3, with the iesult
Leing the auuition ol tag value 100. Vhen comLineu, the opeiation ol the two ioute
234 | Chapter 6:Interior Gateway Protocols and Migration Strategies
maps seives to ensuie that a ioute is nevei ieuistiiLuteu Lack into the IGP liom wheie
it oiiginateu, which shoulu pievent loop loimation.
You use ]unos iouting policy to comLine the vaiious ellects ol IOS`s
distribute, distribute-list, ACL, anu route-map lunctions. Foi exam-
ple, heie is a policy example that lunctions to ieject anu tag ioutes, much
as the EIGRP_OSPF ioute map uoes, alLeit loi RIP anu OSPF given the
lack ol EIGRP suppoit. The RIP_to_OSPF policy is applieu to the OSPF
piotocol as an expoit policy to ieuistiiLute only untaggeu RIP ioutes
into OSPF, at which time a tag value ol 100 is auueu:
[edit policy-options]
regress@plato# show policy-statement RIP_to_OSPF
term 1 {
from tag 100;
then reject;
}
term 2 {
from protocol rip;
then {
tag 100;
accept;
}
}
[edit policy-options]
regress@plato# show policy-statement RIP_to_OSPF | display set
set policy-options policy-statement RIP_to_OSPF term 1 from tag 100
set policy-options policy-statement RIP_to_OSPF term 1 then reject
set policy-options policy-statement RIP_to_OSPF term 2 from protocol rip
set policy-options policy-statement RIP_to_OSPF term 2 then tag 100
set policy-options policy-statement RIP_to_OSPF term 2 then accept
To Lettei unueistanu how the tagging woiks, ielei Lack to Figuie 6-12 anu then con-
siuei an EIGRP (oi connecteu, oi static) ioute x that oiiginates in the EIGRP uomain
anu is evaluateu loi ieuistiiLution into OSPF. Accoiuing to the EIGRP_OSPF ioute map,
the liist action is to ueny any ioute with the tag value 100. Because ioute x oiiginates
within EIGRP, it has no tag anu theieloie the ioute lalls to the next teim. Action 20
auus tag 100 to the ioute anu senus it into OSPF. Route x, which is now an OSPF
Type 5 LSA, is then llooueu into the OSPF RD, wheie it aiiives at Cisco ioutei Bar
ley. In most cases, Barley will alieauy have a moie pieleiieu EIGRP ioute to this ues-
tination (iecall that it oiiginateu in EIGRP to Legin with), Lut il not, it will install the
OSPF ioute to x, as leaineu liom Malt`s OSPF auveitisement.
Now Barley`s OSPF piocess consiueis OSPF ioute x loi ieuistiiLution into EIGRP.
Foitunately, the liist teim in its OSPF_EIGRP ioute map uenies any ioutes with tag 100.
This action seives to pievent ioute x liom Leing sent Lack into its oiiginating EIGRP
IGP. Any ioutes that oiiginate in the OSPF uomain, iegaiuless ol whethei they aie
inteinal oi AS exteinal, aiiive at Barley with no tag. This peimits the ieuistiiLution ol
these ioutes into the EIGRP piocess, altei they have Leen taggeu. This tag will in tuin
keep ioutei Malt liom senuing the ioute Lack into the OSPF uomain.
EIGRP-to-OSPF Migration | 235
Releiiing Lack to Figuie 6-11, you can see the uelault piel-
eiences loi the ioute souices useu in this example. At liist glance, it seems that we want
Loth Malt anu Barley to pielei all OSPF ioutes iegaiuless ol whethei they aie inteinal
oi exteinal. This is to ensuie that Loth Cisco iouteis loiwaiu uiiectly into the OSPF
clouu when iouting to OSPF oiiginateu ioutes, iathei than Lackhauling ovei the EIGRP
LackLone Lecause they pielei a ieuistiiLuteu EIGRP veision ol the same ioute. This is
loitunate heie Lecause the OSPF ioutes ieuistiiLuteu into EIGRP aie consiueieu EIGRP
exteinals, anu the uelault uistance loi these ioutes is 170, making them less pieleiieu
than the native OSPF copy with a uelault uistance ol 110.
The uelault settings mean that the EIGRP uomain will always pielei a leaineu OSPF
ioute ovei the same copy in the (ieuistiiLuteu) exteinal EIGRP loim. The ]unos Loxes
have only one IGP, so theie is no neeu to altei any pieleience theie, ol couise. Time
will tell whethei we neeu to ievisit this thinking.
Confirm EIGRP/OSPF Mutual Route Redistribution
Vith all iouteis conliguieu, conliim piopei ieuistiiLution anu loiwaiuing. Begin at
Cisco ioutei Malt, wheie the IP ioute taLle is uisplayeu:
Malt# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
O E2 200.0.200.0/24 [110/3] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
O IA 200.10.4.0/24 [110/3] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
O IA 200.10.5.0/24 [110/3] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
O E2 200.0.1.0/24 [110/0] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
O IA 200.10.1.0/24 [110/3] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
O E2 200.0.2.0/24 [110/0] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
O IA 200.10.2.0/24 [110/3] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
S 200.0.100.0/24 is directly connected, Null0
O IA 200.10.3.0/24 [110/3] via 192.168.1.2, 00:05:10, FastEthernet0/1.69
10.0.0.0/8 is variably subnetted, 11 subnets, 2 masks
D 10.10.128.200/32 [90/2297856] via 10.1.254.2, 03:10:02, Serial0/0
O 10.10.129.0/24 [110/2] via 192.168.1.2, 00:05:10, FastEthernet0/1.69
O 10.10.128.1/32 [110/1] via 192.168.1.2, 00:05:10, FastEthernet0/1.69
O IA 10.10.130.0/24 [110/2] via 192.168.1.2, 00:05:14, FastEthernet0/1.69
O 10.10.128.2/32 [110/2] via 192.168.1.2, 00:05:14, FastEthernet0/1.69
O IA 10.10.131.0/24 [110/3] via 192.168.1.2, 00:05:14, FastEthernet0/1.69
O IA 10.20.128.4/32 [110/3] via 192.168.1.2, 00:05:14, FastEthernet0/1.69
O IA 10.20.128.3/32 [110/2] via 192.168.1.2, 00:05:14, FastEthernet0/1.69
C 10.10.128.100/32 is directly connected, Loopback0
C 10.1.254.0/24 is directly connected, Serial0/0
What about route preferences?
236 | Chapter 6:Interior Gateway Protocols and Migration Strategies
C 10.1.254.2/32 is directly connected, Serial0/0
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, FastEthernet0/1.69
192.168.2.0/30 is subnetted, 1 subnets
O 192.168.2.0 [110/3] via 192.168.1.2, 00:05:14, FastEthernet0/1.69
Fiom a guick look, it seems that all the ioutes aie theie: PBR`s live 200.10.x/2+ ioutes
as netwoik summaiies (inteiaiea), the simulateu customei ioutes liom Ale anu Lager
as AS exteinals, anu theii loopLack/OSPF inteilace ioutes appeaiing as OSPF inteinals
(intiaaiea). It ceitainly appeais that these ioutes aie pieleiieu in theii OSPF loim,
uespite theii Leing ieuistiiLuteu into EIGRP at Barley, which is uesiieu Lehavioi loi
optimal iouting Letween the EIGRP anu OSPF uomains. Note how Barley`s loopLack
0 auuiess (10.10.12S.200) is uisplayeu as an EIGRP leaineu inteinal ioute with a uis-
tance ol 90.
To conliim that the OSPF ioutes aie ieally Leing ieuistiiLuteu into EIGRP (IOS uisplays
only the active ioute), the EIGRP topology taLle loi one ol PBR`s 200.0.1.0/2+ ioutes is
shown heie:
Malt# show ip eigrp topology 200.0.1.0
IP-EIGRP (AS 100): Topology entry for 200.0.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is
256025600
Routing Descriptor Blocks:
192.168.1.2, from Redistributed, Send flag is 0x0
Composite metric is (256025600/0), Route is External
Vector metric:
Minimum bandwidth is 10 Kbit
Total delay is 1000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
External data:
Originating router is 10.10.28.100 (this system)
AS number of route is 10
External protocol is OSPF, external metric is 0
Administrator tag is 100 (0x00000064)
The ioute`s piesence is conliimeu in the EIGRP topology taLle, anu the tag value ol
100 pioves that the OSPF_EIGRP ioute map is woiking.
Troubleshoot a preference issue
Oveiall, the output liom the show ip route commanu at Malt is what you want to see.
Theie is one pioLlem, howevei, with iespect to the simulateu customei ioute owneu
Ly Barley: the uisplay shows that Malt pieleis the OSPF exteinal veision ol the
200.0.200/2+ ioute Lecause the EIGRP exteinal uistance is highei (less pieleiieu) than
OSPF`s (as noteu pieviously, this is pait ol the migiation plan). This occuis on|y loi
the simulateu customei ioutes Lecause EIGRP is set to iun on the seiial anu loopLack
inteilaces as a iesult ol the network 10.0.0.0 statement. These ioutes aie theieloie
EIGRP-to-OSPF Migration | 237
consiueieu intcrna| to the EIGRP piocess anu they have a uistance ol 90. In contiast,
the simulateu customei static ioute is rcdistributcd into EIGRP, making it an EIGRP
exteinal. This situation iesults in an extia hop when Malt tiies to ieach Barley`s cus-
tomei netwoik, anu vice veisa:
Malt# trace 200.0.200.1
Type escape sequence to abort.
Tracing the route to 200.0.200.1
1 192.168.1.2 4 msec 8 msec 8 msec
2 10.10.129.2 8 msec 8 msec 8 msec
3 192.168.2.1 12 msec 8 msec 12 msec
4 192.168.2.1 !H !H *
Rethinking the uelault pieleiences, it was coiiect to asseit that a|| OSPF ioutes woulu
Le pieleiieu ovei EIGRP exteinals, which loi the majoiity ol oui ioutes is exactly what
is uesiieu. The ieuistiiLuteu statics aie causing issues with this plan, howevei. Chang-
ing OSPF exteinal pieleiences may lix the issue with the pioLlematic static ioutes, Lut
will then cieate pioLlems loi the othei OSPF ioutes that aie now uoing what they
shoulu Le uoing.
Some possiLle solutions incluue iunning EIGRP passively on the ielateu customei in-
teilace so that the ioute is auveitiseu as an EIGRP inteinal. This solution ieguiies an
actual inteilace (oi loopLack instance), anu these statics weie useu to ieuuce geai ie-
guiiements in the liist place. Still, no new geai is neeueu loi an IOS loopLack 1 inteilace.
Oi, you coulu ueline a static ioute, Lut this iepiesents auministiative woik anu may
leau to a Llack hole il the legacy EIGRP LackLone lails. Using a gualilieu/iecuisive static
shoulu iesult in tiallic lalling Lack to the leaineu OSPF veision shoulu the static ioute`s
next hop Lecome unieachaLle, Lut this woulu neeu to Le testeu to make suie ol lailovei
Lehavioi. Yet anothei solution woulu Le to simply toleiate the inellicient iouting, given
that connectivity is still pioviueu anu the conuition shoulu Le tiansient as the EIGRP
netwoik is phaseu out. Being a puiist, you opt to altei the IOS conliguiations to auu a
new loopLack instance that will iun EIGRP on Lehall ol the simulateu customei net-
woik. Such changes aie shown heie:
!
interface Loopback1
ip address 200.0.100.1 255.255.255.0
!
. . .
router eigrp 100
redistribute connected
redistribute static
redistribute ospf 10 metric 10 100 255 1 1500 route-map OSPF_EIGRP
network 10.0.0.0
network 200.0.100.0
passive-interface Loopback1
no auto-summary
A new loopLack instance has Leen uelineu to iepiesent the simulateu customei netwoik
that pieviously was iepiesenteu Ly a static ioute. The static ioute has also Leen iemoveu
238 | Chapter 6:Interior Gateway Protocols and Migration Strategies
(not shown), anu the EIGRP piocess is conliguieu to iun passively on the loopLack 1
inteilace. The passive ueclaiation ensuies that CPU cycles aie not wasteu on the EIGRP
neighLoi uiscoveiy that is uoomeu to lail, given the lonely neighLoihoou that is loop-
Lack 1. Anu yes, loopLack 0 shoulu Le set to Le passive loi the same ieasons, Lut that
is saveu loi anothei uay. Altei similai changes aie maue at Barley, the active EIGRP
ioutes aie uisplayeu anu the pievious tiaceioute is iepeateu:
Malt# showip route eigrp
D 200.0.200.0/24 [90/2297856] via 10.1.254.2, 00:11:42, Serial0/0
10.0.0.0/8 is variably subnetted, 11 subnets, 2 masks
D 10.10.128.200/32 [90/2297856] via 10.1.254.2, 04:24:16,
Serial0/0
Malt# traceroute 200.0.200.1
Type escape sequence to abort.
Tracing the route to 200.0.200.1
1 10.1.254.2 16 msec 12 msec *
Excellent, just what you wanteu to see. Beloie moving on, tiaceioutes to a lew othei
uestinations in the OSPF uomain aie executeu loi auueu conliimation. Note that the
simulateu customei netwoik ioutes at Ale anu Lager aie set to uiscaiu, so you shoulu
expect no ieply liom them:
Malt# trace 10.20.128.3
Type escape sequence to abort.
Tracing the route to 10.20.128.3
1 192.168.1.2 4 msec 4 msec 12 msec
2 10.20.128.3 4 msec 8 msec 8 msec
Malt# trace 200.10.5.1
Type escape sequence to abort.
Tracing the route to 200.10.5.1
1 192.168.1.2 8 msec 8 msec 8 msec
2 200.10.5.1 4 msec 20 msec 100 msec
The tiaceioutes to the loopLack auuiess anu OSPF aiea 1 ioutes on PBR aie successlul
anu aie oLseiveu to take a ieasonaLle loiwaiuing path. Similai iesults aie oLseiveu at
Barley:
Barley# trace 200.10.2.1
Type escape sequence to abort.
Tracing the route to 200.10.2.1
1 192.168.2.2 20 msec 4 msec 12 msec
2 10.10.129.1 4 msec 28 msec 12 msec
3 200.10.2.1 8 msec 8 msec 8 msec
Let`s tempoiaiily uown the OSPF aujacency at Malt (tiallic will Le ieiouteu thiough
Barley) to conliim that Malt lalls Lack to the EIGRP veisions ol the OSPF uomain`s
ioutes anu actually Legins to loiwaiu thiough Barley:
EIGRP-to-OSPF Migration | 239
Malt(config)# interface fastEthernet 0/1
Malt(config-if)# sh
Malt(config-if)# ^Z
. . .
Altei a lew moments, the ioute taLle is again uisplayeu at Malt:
Malt# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
D 200.0.200.0/24 [90/2297856] via 10.1.254.2, 00:31:34, Serial0/0
D EX 200.10.4.0/24 [170/256537600] via 10.1.254.2, 00:00:36, Serial0/0
D EX 200.10.5.0/24 [170/256537600] via 10.1.254.2, 00:00:36, Serial0/0
D EX 200.0.1.0/24 [170/256537600] via 10.1.254.2, 00:00:36, Serial0/0
D EX 200.10.1.0/24 [170/256537600] via 10.1.254.2, 00:00:36, Serial0/0
D EX 200.0.2.0/24 [170/256537600] via 10.1.254.2, 00:00:36, Serial0/0
D EX 200.10.2.0/24 [170/256537600] via 10.1.254.2, 00:00:36, Serial0/0
C 200.0.100.0/24 is directly connected, Loopback1
D EX 200.10.3.0/24 [170/256537600] via 10.1.254.2, 00:00:37, Serial0/0
10.0.0.0/8 is variably subnetted, 11 subnets, 2 masks
D 10.10.128.200/32 [90/2297856] via 10.1.254.2, 04:44:10, Serial0/0
D EX 10.10.129.0/24 [170/256537600] via 10.1.254.2, 00:00:37, Serial0/0
D EX 10.10.128.1/32 [170/256537600] via 10.1.254.2, 00:00:37, Serial0/0
D EX 10.10.130.0/24 [170/256537600] via 10.1.254.2, 00:00:39, Serial0/0
D EX 10.10.128.2/32 [170/256537600] via 10.1.254.2, 00:00:39, Serial0/0
D EX 10.10.131.0/24 [170/256537600] via 10.1.254.2, 00:00:39, Serial0/0
D EX 10.20.128.4/32 [170/256537600] via 10.1.254.2, 00:00:39, Serial0/0
D EX 10.20.128.3/32 [170/256537600] via 10.1.254.2, 00:00:39, Serial0/0
C 10.10.128.100/32 is directly connected, Loopback0
C 10.1.254.0/24 is directly connected, Serial0/0
C 10.1.254.2/32 is directly connected, Serial0/0
192.168.1.0/30 is subnetted, 1 subnets
D EX 192.168.1.0 [170/256537600] via 10.1.254.2, 00:00:34, Serial0/0
192.168.2.0/30 is subnetted, 1 subnets
D EX 192.168.2.0 [170/2172416] via 10.1.254.2, 00:00:40, Serial0/0
The uisplay conliims that the EIGRP veisions ol the ieuistiiLuteu OSPF ioutes aie now
active. A tiaceioute conliims the expecteu loiwaiuing path, given the uown fa 0/0
inteilace at Malt:
Malt# traceroute 200.10.5.1
Type escape sequence to abort.
Tracing the route to 200.10.5.1
1 10.1.254.2 12 msec 12 msec 12 msec
2 192.168.2.2 20 msec 16 msec 20 msec
3 10.10.129.1 116 msec 24 msec 20 msec
240 | Chapter 6:Interior Gateway Protocols and Migration Strategies
4 200.10.5.1 48 msec 28 msec 36 msec
Malt#
Malt`s fa 0/1 inteilace is ietuineu to opeiation anu the OSPF aujacency is alloweu to
ieloim. You shoulu then inspect the ioute taLle to ensuie that the netwoik state has
ietuineu to the initial state. Issues with ioute ieuistiiLution/pieleience aie olten timing-
uepenuent, anu you may linu that altei a lailuie the netwoik uoes not ietuin to the
uesiieu state. Heie, expect to linu that the OSPF veisions ol the ioutes aie again pie-
leiieu ovei the EIGRP veision:
Malt#
*Mar 1 06:02:24.202: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.128.1 on FastEthernet0/1.
69 from LOADING to FULL, Loading Done
Malt#
Malt# show ip route eigrp
D 200.0.200.0/24 [90/2297856] via 10.1.254.2, 00:36:14, Serial0/0
10.0.0.0/8 is variably subnetted, 11 subnets, 2 masks
D 10.10.128.200/32 [90/2297856] via 10.1.254.2, 04:48:48, Serial0/0
Malt#
The uisplay conliims that the native OSPF ioutes aie again active, as they aie pieleiieu
ovei ieuistiiLuteu EIGRP copies. This valiuates that the netwoik is aLle to lail ovei,
anu then switch Lack to a steauy state. Connectivity Letween the two RDs has alieauy
Leen uemonstiateu, so let`s concluue oui IGP migiation veiilication with some selective
captuies in the OSPF uomain, staiting Ly examining the laige exteinal LSA uataLase
now on LackLone iouteis:
[edit]
lab@Ale# run show ospf database extern
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 10.1.254.0 10.10.28.100 0x8000000b 850 0x20 0xe0c4 36
Extern 10.1.254.0 10.10.28.200 0x8000000b 783 0x20 0x86ba 36
Extern 10.1.254.1 10.10.28.200 0x8000000b 783 0x20 0x7cc3 36
Extern 10.1.254.2 10.10.28.100 0x8000000b 850 0x20 0xccd6 36
Extern 10.10.128.100 10.10.28.100 0x80000009 1607 0x20 0xfbbc 36
Extern 10.10.128.100 10.10.28.200 0x80000009 1531 0x20 0xb59c 36
Extern 10.10.128.200 10.10.28.100 0x80000009 1607 0x20 0x242e 36
Extern 10.10.128.200 10.10.28.200 0x80000009 1531 0x20 0xb53a 36
Extern *200.0.1.0 10.10.128.1 0x80000005 2101 0x22 0x87c7 36
Extern 200.0.2.0 10.10.128.2 0x80000005 2427 0x22 0x76d6 36
Extern 200.0.100.0 10.10.28.100 0x8000000d 592 0x20 0xdda2 36
Extern 200.0.100.0 10.10.28.200 0x80000002 526 0x20 0xad77 36
Extern 200.0.200.0 10.10.28.100 0x80000002 351 0x20 0xb76d 36
Extern 200.0.200.0 10.10.28.200 0x80000002 526 0x20 0x4979 36
Vell, it seems that |argc tiuly is a suLjective teim. Howevei, moie than 10 Type 5 LSAs
aie in the LackLone aiea`s uataLase, anu consiueiing the small scope ol the EIGRP
netwoik in this laL example, it`s sale to say that a laige enteipiise coulu easily geneiate
hunuieus il not thousanus ol these AS exteinal LSAs:
[edit]
lab@Ale# run show ospf database extern detail | match tag
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
EIGRP-to-OSPF Migration | 241
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 4, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 4, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 0, fwd addr 0.0.0.0, tag 0.0.0.0
Type 2, TOS 0x0, metric 0, fwd addr 0.0.0.0, tag 0.0.0.0
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 4, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 4, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Next, the CLI`s matching lunction, comLineu with the detail switch, allows conlii-
mation that most ol these exteinals oiiginateu in the EIGRP uomain, given that the
majoiity aie spoiting a tag with an EIGRP piocess numLei.
The new OSPF netwoik was uesigneu to Le hieiaichical to piomote scaling. To take
this a step luithei, let`s also ueploy NSSAs to ieuuce the piocessing uemanus on non-
LackLone iouteis. Inteinal iouteis within a stuL aiea uo not see any AS exteinal LSAs,
which in this type ol a migiation can suLstantially ieuuce theii loau. Conliim this lact
at ioutei PBR:
[edit]
lab@PBR# run show ospf database
OSPF link state database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.10.128.1 10.10.128.1 0x8000000c 273 0x20 0xac79 48
Router *10.20.128.3 10.20.128.3 0x80000008 928 0x20 0x6124 108
Network *10.10.130.2 10.20.128.3 0x80000007 928 0x20 0x7b49 32
Summary 10.10.128.2 10.10.128.1 0x80000008 2223 0x20 0xda30 28
Summary 10.10.129.0 10.10.128.1 0x80000008 2073 0x20 0xe328 28
Summary 10.10.131.0 10.10.128.1 0x80000008 1773 0x20 0xd731 28
Summary 10.20.128.4 10.10.128.1 0x80000007 1473 0x20 0x5aa4 28
Summary 192.168.1.0 10.10.128.1 0x8000000b 625 0x20 0x9a9c 28
Summary 192.168.2.0 10.10.128.1 0x80000006 573 0x20 0xa396 28
NSSA 0.0.0.0 10.10.128.1 0x80000008 423 0x20 0xa1ea 36
NSSA 200.0.1.0 10.10.128.1 0x80000005 2373 0x20 0x89c5 36
Note the aLsence ol Type + anu Type 5 LSAs, anu the piesence ol the uelault ioute,
which pioviues the inteinal stuL aiea iouteis with a ioute to exteinal uestinations:
[edit]
lab@PBR# run show route 200.0.200.4
inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 04:26:43, metric 11, tag 0
> to 10.10.130.1 via ge-0/0/0.1141
This last uisplay conliims the use ol the uelault ioute loi AS exteinal uestinations Ly
the inteinal NSSA ioutei PBR.
242 | Chapter 6:Interior Gateway Protocols and Migration Strategies
Vith initial connectivity conliimeu, the EIGRP-to-OSPF migiation can pioceeu
thiough a phaseu movement ol legacy EIGRP segments to the new OSPF LackLone.
Alteinatively, the EIGRP uomain can Le shiunk Lack Ly incieasing the scope ol the
OSPF uomain anu moving the EIGRP ieuistiiLution points until theie is no EIGRP lelt.
EIGRP-to-OSPF Migration Summary
This section uemonstiateu how you can integiate a new OSPF LackLone into an ex-
isting EIGRP inliastiuctuie, while maintaining loop-liee connectivity thiough caielul
use ol ioute lilteiing. Filteiing is neeueu to ensuie that those ioutes aie ieuistiiLuteu
only once. The example useu ioute tags to simplily lilteiing. Auuiess-Laseu lilteis can
also woik, especially il the two IGP uomains have uistinct numLeiing that can easily
Le summaiizeu.
Mutual ioute ieuistiiLution is always a Lit tiicky, anu caielul thought shoulu Le leveleu
against any migiation plan to tiy to heau oll potential issues stemming liom piotocol
pieleiences oi incomplete ioute lilteiing. In this example, the inteiaction ol OSPF anu
EIGRP exteinal pieleiences cieateu a pioLlem loi static ioutes ieuistiiLuteu into
EIGRP. Although connectivity was maintaineu anu no loops weie loimeu, the conui-
tion iesulteu in suLoptimal loiwaiuing loi some uestinations. The specilics ol this
example alloweu the cieation ol a new loopLack inteilace, which then ian a passive
instance ol EIGRP to stanu in loi the static ioute, yieluing optimal connectivity loi all
uestinations in the test Leu.
Conclusion
The IGP is a ciitical component in any enteipiise netwoik. The IGP lunctions to pioviue
optimal connectivity to inteiioi uestinations in the lace ol changing netwoik conui-
tions. To peiloim this lunction, the IGP must Lalance the opposing loices ol iapiu
conveigence against instaLility anu iouting loops. A well-uesigneu anu implementeu
IGP can easily spell the uilleience Letween a high-peiloiming netwoik anu an ongoing
litany ol tiouLle tickets anu suppoit calls.
Histoiically, enteipiise netwoiks neeueu to suppoit multiple iouteu piotocols, anu the
uominance ol Cisco Systems in these eaily yeais iesulteu in wiuespieau ueployment ol
its piopiietaiy IGRP anu EIGRP IGP solutions. Since that time, most enteipiise net-
woiks have completeu a migiation to an all-IP iouting inliastiuctuie. Simply stateu,
the woilu seems to have settleu on the mantia IP ovei eveiything, anu eveiything ovei
IP. Although EIGRP uoes a goou joL at iouting IP, its closeu natuie, coupleu with its
lack ol iouting hieiaichy anu MPLS TE suppoit, cast seiious conceins ovei its lutuie
high-peiloimance enteipiise netwoiks.
Ovei the yeais, seveial tiieu anu pioven stiategies have Leen uevelopeu to ease the pain
anu uisiuption that olten accompany IGP migiation. Vhethei an enteipiise chooses
Conclusion | 243
to ueploy ]unos oi not, these migiation technigues can get youi legacy netwoik weaneu
oll ol EIGRP anu onto an open stanuaiu such as OSPF.
]unipei Netwoiks iouteis suppoit all stanuaiuizeu IGPs, anu theii implementation has
Leen successlully Lattle testeu in the planet`s laigest seivice pioviuei netwoiks. The
same OSPF coue iunning in the multiteiaLit iion ol the ]unipei Netwoiks llagship
T+000 coie ioutei can also Le lounu puiiing away in the smallest enteipiise-taigeteu
]unipei uevices. Although histoiically uesigneu loi seivice pioviuei netwoiks, ]unipei
Netwoiks continues to evolve its IGP implementation to meet the neeus ol Loth its
seivice pioviuei anu enteipiise customeis.
Exam Topics
Ve coveieu the lollowing Enteipiise Exam Topics in this chaptei:
The iole anu lunction ol an IGP
Opeiational chaiacteiistics ol RIP, RIPv2, OSPF, anu IGRP/EIGRP
RIP anu OSPF conliguiation on ]unipei Netwoiks iouteis
Opeiational analyses ol RIP anu OSPF on ]unipei Netwoiks iouteis
The oveilay, ieuistiiLution, anu integiateu IGP migiation mouels
Chapter Review Questions
1. Vhich ol the lollowing uelines sp|it horizon?
A. Senuing ioutes out the inteilace they weie leaineu liom
B. Senuing ioutes out the inteilace they weie leaineu liom with inlinite metiic
C. Holuing a iecently unieachaLle ioute in the taLle loi a lixeu time to allow othei
iouteis to Le notilieu
D. Not senuing ioutes out the inteilace they weie leaineu liom
2. Vhen you conliguie RIP on a ]unipei Netwoiks ioutei, how uo you specily what
inteilaces the piotocol shoulu opeiate on?
A. You use a netwoik statement with a netwoik mask
B. You use a netwoik statement with a wilucaiu mask
C. You specily inteilace names anu logical units explicitly as pait ol RIP neighLoi
conliguiation
D. You use iouting policy
E. None ol the aLove
244 | Chapter 6:Interior Gateway Protocols and Migration Strategies
3. Vhat commanu uisplays the RIP ioutes a ]unipei Netwoiks ioutei is senuing out
to a given inteilace?
A. This is not possiLle given the LS natuie ol RIP
B. show route protocol rip
C. show route advertising-protocol rip <neighbor>
D. show route receiving-protocol rip <neighbor>
+. Vhich type ol ioutei geneiates a Type 2 LSA?
A. Inteinal
B. ABR
C. ASBR
D. DR
5. Vhich is tiue iegaiuing a stuL aiea with no-summaries?
A. The aiea uses a uelault to ieach inteiaiea uestinations
B. The aiea impoits exteinal ioutes as Type 7 LSAs
C. The aiea uoes not ieceive Type 3 summaiy LSAs liom the LackLone
D. The aiea has no OSPF iouteis in it
6. Vhen you auu a new OSPF ioutei to a LAN, what lactoi(s) ueteimine whethei it
will Lecome the DR?
A. Its piioiity setting
B. The RID
C. Vhethei any othei iouteis aie alieauy opeiating on that LAN
D. All ol the aLove
7. Vhat ueteimines which ioute will Le active when a given pielix is leaineu Ly mul-
tiple iouting piotocols?
A. The lowest metiic
B. The path with the lewest hops
C. The piotocol with the highest numeiical pieleience is chosen
D. The piotocol with the lowest numeiical pieleience is chosen
S. Vhich syntax at an ABR woulu suppiess inuiviuual summaiies loi ioutes in the
10.0/16 Llock in aiea 1 while ieplacing them with a single summaiy?
A.
[edit protocols ospf area 0.0.0.1]
set area-range 10.0/16 restrict
B.
[edit protocols ospf area 0.0.0.0]
set area-range 10.0/16
Chapter Review Questions | 245
C.
[edit protocols ospf area 0.0.0.1]
set area-range 10.0/16
D. This is not possiLle; LSAs cannot Le lilteieu without Lieaking LS piotocol
opeiation
9. Vhich is tiue iegaiuing the oveilay migiation mouel?
A. You liist set the legacy IGP to Le less pieleiieu than the new IGP
B. You liist set the new IGP to Le less pieleiieu than the legacy IGP
C. Route ieuistiiLution is neeueu to maintain connectivity thiough the migiation
D. A new LackLone is neeueu
10. Vhat is the piimaiy mechanism loi loop pievention in the ieuistiiLution mouel?
A. A common LSDB ensuies a loop-liee topology
B. Stiict contiols that ensuie ioutes aie not ieuistiiLuteu Lack to theii oiiginating
IGP
C. Setting the new IGP to Le moie pieleiieu than the legacy IGP
D. A caielul mapping ol metiics Letween oiiginating anu ieceiving IGPs
11. Vhat types ol authentication aie suppoiteu in ]unos loi OSPF?
A. Simple passwoiu
B. MD5 checksum
C. Hitless key chain ol MD5 keys/checksums
D. All ol the aLove
12. Vhich conliguiation will inject a uelault ioute into stuL aiea 1?
A.
area 0.0.0.1 {
stub default-metric 10 no-summaries;
area-range 10.0.0.0/16 restrict;
}
B.
area 0.0.0.0 {
stub default-metric 10;
}
C.
area 0.0.0.1 {
stub no-summaries;
area-range 10.0.0.0/16 restrict;
}
D.
area 0.0.0.1 {
stub default-metric;
area-range 10.0.0.0/16 restrict;
}
246 | Chapter 6:Interior Gateway Protocols and Migration Strategies
Chapter Review Answers
1. Answei: D. Split hoiizon iules pievent a ioutei liom ieauveitising iouting inloi-
mation Lack out the same inteilace it was leaineu liom; poisoneu ieveise alteis
this Lehavioi to peimit such upuates as long as they have an inlinite metiic.
2. Answei: C. You specily RIP-enaLleu inteilaces Ly name anu unit numLei, unuei
the [edit protocols rip group <name> neighbor] hieiaichy.
3. Answei: C. The show route advertising protocol <protocol> <neighbor> com-
manu is useu to uisplay the ioute the local ioutei is senuing out an inteilace to a
neighLoi loi RIP/BGP, iespectively. The receiving-protocol loim ol this com-
manu shows the ioutes Leing leaineu ovei an inteilace.
+. Answei: D. Only uesignateu iouteis, which aie electeu only on multiaccess net-
woiks, geneiate Type 2 netwoik summaiy LSAs. This LSA type is useu to iepoit
the list ol OSPF neighLois (incluuing the DR itsell) attacheu to the multiaccess
segment.
5. Answei: C. A stuL aiea with no-summaries uoes not ieceive summaiy LSAs liom
the LackLone. It ielies on an injecteu uelault ioute to ieach inteiaiea anu AS ex-
teinal uestinations.
6. Answei: D. All ol the lactois listeu inlluence whethei a given ioutei can Lecome
the DR. Recall that DR election is not ieveitive. A ioutei`s ID anu piioiity come
into play only uuiing an active DR election.
7. Answei: D. The piotocol with the numeiically lowest pieleience (oi auministiative
uistance) is consiueieu moie ieliaLle anu is chosen as the souice ol the active
ioute.
S. Answei: C. Youi goal is to liltei liom aiea 1 into aiea 0, so the area-range statement
neeus to Le applieu to aiea 1. The iestiict keywoiu shoulu not Le useu heie as it
will also liltei on the summaiy, in ellect conveiting liom a match type ol longer to
one ol orlonger. The goal is to peimit the summaiy, which makes answei A lalse.
9. Answei: B. To avoiu uisiuption, the legacy piotocol must opeiate until all aspects
ol the new IGP have Leen put in place anu conliimeu. The new IGP has to Le less
pieleiieu than the oiiginal until you aie ieauy to actually make the switchovei.
10. Answei: B. You must uiligently use lilteiing mechanisms to ensuie that ioutes aie
nevei ieuistiiLuteu Lack into the IGP liom wheie they oiiginateu, oi else loops will
likely loim.
11. Answei: D. Foi OSPF, ]unos suppoits simple passwoius, MD5, anu a key chain
ol MD5 seciets. RIP uoes not suppoit key chain authentication as ol the ]unos S.3
ielease.
12. Answei: A. ]unos will geneiate a uelault ioute only when a metiic value is specilieu
using the default-metric commanu.
Chapter Review Answers | 247
CHAPTER 7
Border Gateway Protocol and
Enterprise Routing Policy
This chaptei ieviews the Boiuei Gateway Piotocol (BGP) veision + opeiation anu key
attiiLutes to accommouate a uetaileu uiscussion ol BGP enteipiise applications. BGP
is all aLout the contro| ol iouting inloimation bctwccn autonomous systems (ASs).
Emphasis is placeu on the use ol iouting policy to lacilitate loau Lalancing anu common
enteipiise applications ol inLounu anu outLounu iouting ieguiiements when custom-
eis aie uual-homeu to uilleient seivice pioviueis. The topics coveieu incluue:
BGP oveiview anu enteipiise applications
Exteinal BGP (EBGP) peeiing with asymmetiic loau Lalancing
BGP policy loi the enteipiise
BGP uual-homing scenaiio with ioute iellection anu outLounu policy
Implementation ol a uual-homeu inLounu policy Ly manipulating BGP attiiLutes
]unipei Netwoiks iouteis ollei extensive leatuie suppoit loi BGP. In lact, the list ol
suppoiteu stanuaius is too long to Le valuaLle heie. Consult the BGP oveiview in the
]unos uocumentation to conliim the list ol suppoiteu RFCs anu uialts loi youi pai-
ticulai ]unos soltwaie ielease.
What Is BGP?
BGP is an inteiuomain iouting piotocol, which means it opeiates Letween netwoiks
that aie unuei uilleient auministiative contiolmaking BGP an Exteiioi Gateway
Piotocol (EGP) that opeiates Letween ASs. An AS is uelineu as a gioup ol IP netwoiks
opeiateu Ly one oi moie netwoik opeiatois that has a single, cleaily uelineu iouting
policy.
BGP is a path-vectoi iouting piotocol that ielies on the unigueness ol AS path numLeis
loi loop pievention. Rathei than auveitising a simple vectoi (pielix), as in the case ol
249
the Routing Inloimation Piotocol (RIP), BGP`s ieachaLility inloimation is a pielix with
associateu attiiLutes that uesciiLe the path to that pielix. The iich set ol suppoiteu
attiiLutes in tuin allows loi an egually iich set ol policy actions.
BGP is somewhat unigue in that it uses a ieliaLle Tiansmission Contiol Piotocol (TCP)-
Laseu tianspoit loi its contiol anu upuate messages. ReliaLle tianspoit means theie is
no neeu loi peiiouic ioute upuates, which is ieally, ieally goou, consiueiing that a lull
BGP taLle typically compiises moie than 350,000 ioutes! BGP uoes geneiate peiiouic
keepalive tiallic in the aLsence ol ioute upuate activity to ensuie that the unueilying
TCP tianspoit is still lunctional.
BGP veision + has Leen in use loi moie than two uecaues, with the cuiient veision
(BGP +) oiiginally uelineu in RFC 165+ Lack in 199+. This RFC was oLsoleteu Ly RFC
1771, which in tuin was oLsoleteu Ly the cuiient specilication, RFC +271. The lact
that BGP still enjoys a giowing ueployment Lase, with no ieplacement looming on the
hoiizon, is a testament to the aichitects` loiwaiu-thinking uesign. BGP is Laseu on the
use ol paiametei type, paiametei length, anu paiametei value tuples (sometimes
calleu tag |cngth va|ucs, oi TLVs). It is these TLVs that pioviue the inheient extensiLility
without the neeu loi signilicant piotocol changes. You want IPv6 auuiess lamily sup-
poit? Simple; just ueline a new netwoik layei ieachaLility inloimation (NLRI) attiiLute.
You neeu ioute iellection? No pioLlem; auu some new attiiLutes to communicate
clustei anu oiiginatoi ID inloimation. Meanwhile, the Lasic opeiation anu piotocol
mechanisms iemain unalteieu anu, in many cases, Lackwaiu-compatiLle.
Inter-AS Routing
In seveial iegaius, you can think ol BGP as the antithesis ol an Inteiioi Gateway Pio-
tocol (IGP). Foi example, an IGP lunctions within an AS anu stiives to pronotc con-
nectivity, wheieas a BGP opeiates bctwccn ASs anu tenus to |init connectivity. That
last point may ieguiie a Lit moie claiilication. An IGP noimally actively seeks to uis-
covei iouting peeis (neighLoi uiscoveiy). Once the neighLois aie lounu, ioutes aie
exchangeu anu connectivity is piomoteu Ly viitue ol always seeking the Lest path Le-
tween enupoints. BGP, on the othei hanu, has to Le explicitly tolu which neighLois to
peei with, anu then the use ol auministiative policy is useu to liltei anu mouily iouting
inloimation to select the Lest ioute that meets the netwoik opeiatoi`s uelineu policy.
The woiu bcst is guoteu heie Lecause when iouting Letween ASs, the concept ol what
constitutes a Lest path is clouuy at Lest. Foi example, a company may choose to liltei
laige poitions ol BGP connectivity liom Lest path consiueiation, Laseu solely on a local
policy that uoes not allow the use ol a specilic competitoi`s LackLone. Exactly why
such a policy is in place is not the guestion, although many goou answeis spiing to
minu, incluuing potential conceins ol coipoiate espionage. The point heie is that with
BGP, you aie noimally as conceineu aLout iestiiction/ignoiing iouting inloimation as
you aie aLout ieceiving it in the liist place. The IGP is locuseu on getting you theie,
wheieas BGP is moie conceineu with how you get theie.
250 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
Figuie 7-1 illustiates a simple inteiuomain iouting scenaiio, wheie each AS is iepie-
senteu Ly a clouu. The clouu is, ol couise, the univeisal symLol loi uon`t ask, uon`t
tell. This is to say that specilics ol each AS aie lelt to the auministiatois ol that netwoik
anu aie geneially not known outsiue ol that scope. It might Le possiLle loi a tiansit
netwoik to ueploy an avian-Laseu tianspoit technology, as pei RFC 11+9
'
; as long as
they meet theii seivice level agieements (SLAs), the uetails ol how they manage to pull
it oll aie typically not a mattei ol concein.
Iigurc 7-1. |ntcrdonain routing with BGP
BGP opeiates on the links that tie these netwoiks togethei, in ellect seiving as the pub|ic
jacc ol each netwoik. The BGP speakeis in each AS auveitise netwoik ieachaLility to
the ASs they aie conliguieu to peei with, unuei the conlines ol theii specilic expoit
policy. In like lashion, each BGP speakei lilteis ieceiveu inloimation thiough its ie-
spective impoit policy Leloie placing what iemains into its ioute taLle loi consiueiation
loi the active ioute selection piocess. Figuie 7-1 shows that Pioviuei D`s policy pievents
the auveitisement ol the 10.0.20/2+ pielix liom Site 2 to Pioviuei A. Pioviuei A will
have to ieceive the Site 2 pielix liom Pioviuei B. As a iesult, the two customei sites will
Le loiwaiuing ovei auuitional AS hops to ieach each othei. This point helps to uem-
onstiate that loi BGP, connectivity is as much a mattei ol politics as it is peiloimance.
BGP Route Attributes
BGP auveitises ioute inloimation calleu next layei ieachaLility inloimation (NLRI),
along with vaiious attiiLutes that uesciiLe the path to that pielix. The teims NLR|,
' RFC 11+9 is one ol the moie notoiious less than seiious RFCs, as inuicateu Ly its Apiil 1 puLlication uate.
What Is BGP? | 251
routc, anu prcjix aie synonymous anu aie useu inteichangeaLly in this chaptei. This
section uesciiLes key BGP path attiiLutes. Policy uiscussions latei in this chaptei ie-
guiie that you unueistanu what these attiiLutes uo anu how you woik with them to
achieve youi iouting goals.
All BGP ioute attiiLutes lall into one ol the lollowing categoiies Laseu on whethei all
BGP speakeis aie expecteu to unueistanu the attiiLute anu whethei the attiiLute has
local-AS oi enu-to-enu scope:
Wc||-|nown nandatory
A well-known manuatoiy attiiLute must Le suppoiteu Ly all BGP speakeis anu
must Le piesent in all BGP upuates that contain an NLRI.
Wc||-|nown discrctionary
A well-known uiscietionaiy attiiLute must Le suppoiteu Ly all BGP speakeis anu
may oi may not Le piesent in a given NLRI upuate.
Optiona| transitivc
An optional tiansitive attiiLute is an optional attiiLute that may not Le unueistoou
Ly all speakeis anu is expecteu to tiansit the local AS, even il it is not unueistoou
Ly the local speakei.
Optiona| nontransitivc
An optional nontiansitive attiiLute is an optional attiiLute that may not Le un-
ueistoou Ly all speakeis anu uoes not tiansit the local ASthat is, it is not ieau-
veitiseu to anothei, iemote AS.
Common BGP path attiiLutes incluue:
Ncxt hop
The next hop is a manuatoiy attiiLute that caiiies the IP auuiess ol a BGP speakei
(oi a thiiu paity when peimitteu) to iuentily wheie packets shoulu Le loiwaiueu
when using the associateu ioute. The next hop is changeu Ly uelault loi EBGP anu
is unchangeu loi Inteinal BGP (IBGP); howevei, this uelault Lehavioi can Le alteieu
with policy.
Loca| prcjcrcncc
Local pieleience is a well-known uiscietionaiy attiiLute useu to inlluence BGP path
selection with iegaiu to the uesiieu egiess point loi tiallic liom within an AS.
Tiallic llows towaiu the peei auveitising the highest (most pieleiieu) local piel-
eience. Local pieleience is piesent only in IBGP upuates (nontiansitive); this at-
tiiLute is not auveitiseu to EBGP peeis.
AS path
The manuatoiy attiiLute AS path lists the AS numLeis that will Le ciosseu when
loiwaiuing to the associateu NLRI. The AS path attiiLute is useu loi loop pieven-
tion anu inlluences path selection in accoiuance with the motto the lewei ASs in
a path, the Lettei. Each AS auus its AS numLei to the liont ol the cuiient AS
seguence when geneiating EBGP upuates; the lack ol upuateu AS path inloimation
252 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
in IBGP upuates is why IBGP speakeis aie not peimitteu to ieauveitise ioutes
leaineu liom IBGP Lack to othei IBGP speakeis. By uelault, BGP uiscaius any ioute
auveitisement that contains its local AS numLei in the AS path, Lecause this inui-
cates that the ioute has alieauy passeu thiough the local AS once; that is, a loop
has loimeu.
Origin
The oiigin coue is a well-known, manuatoiy attiiLute that iuentilies the oiiginal
souice ol a ioute as Leing leaineu liom an IGP, EGP, oi unknown souice. In ioute
selection, a BGP speakei will pielei IGP to EGP, anu EGP to unknown. Oiigin is
piesent in all ioute upuates anu is suLject to mouilication with policy (tiansitive).
Mu|tip|c cxit discrininator
The multiple exit uisciiminatoi (MED) attiiLute is an optional, nontiansitive at-
tiiLute, which means that some BGP speakeis may not unueistanu oi use MED.
MED is auueu on upuates sent ovei EBGP links, anu is then auveitiseu Ly IBGP
within the ieceiving AS to inlluence its outLounu iouting. Howevei, the MED
attiiLute uoes not tiansit Leyonu the AS into which it was oiiginally auveitiseu
BGP speakeis in upstieam ASs eithei ieceive no MED oi ieceive a new MED value
cieateu Ly that peeiing AS.
MED lunctions like a conventional iouting metiic in that speakeis pielei the ioute
with the lowest MED when all pieceuing uecision points aie egual. The MED
auveitiseu Ly the oiiginating AS to an aujacent AS pioviues a clue to the aujacent
AS iegaiuing what links shoulu Le useu loi cgrcss liom the neighLoi AS Lack to-
waiu the oiiginating AS, anu theieloie what links aie useu as ingrcss to the local
AS. Stateu uilleiently, the MED is useu Ly the local AS to inlluence the iouting
uecisions in an aujacent AS loi tiallic that is inLounu to the local AS. Vhen aLsent,
]unos soltwaie assumes an MED value ol 0, which is the most pieleiieu setting.
In contiast, the aLsence ol a local pieleience is assumeu to Le a value ol 100.
Connunity
The community attiiLute allows loi the aiLitiaiy giouping ol ioutes that shaie one
oi moie chaiacteiistics via the auuition ol a common community tag value. The
community tags can Le useu loi a vaiiety ol puiposes, such as ioute lilteiing anu
attiiLute mouilication. Foi example, all ioutes leaineu liom customeis may Le
assigneu the community value ol 65000:100. Vhen this community is seen on a
ioute, the local policy will set a moie pieleiieu local pieleience. As anothei exam-
ple, consiuei the well-known community no-cxport. Vhen attacheu to a ioute, this
community tells the aujacent AS that the associateu ioute shoulu not Le ieauvei-
tiseu to any iemote ASs.
BGP Path Selection
A BGP speakei that is piesenteu with two oi moie upuates, specilying the same pielix,
peiloims a ioute selection piocess to select the Lest BGP path loi that pielix. Once the
What Is BGP? | 253
Lest path is selecteu, the ioute is installeu in the ioute taLle, wheie it may Lecome active
il the same pielix is not Leing leaineu Ly a piotocol with a Lettei gloLal pieleience. The
]unos soltwaie BGP path selection piocess consists ol the lollowing uecision steps:
1. Can the BGP next hop Le iesolveu?
2. Pielei the path with the highest local pieleience value.
3. Pielei the path with the shoitest AS-path length.
+. Pielei the path with the lowest oiigin value.
5. Pielei the path with the lowest MED value.
6. Pielei the path leaineu using EBGP ovei paths leaineu using IBGP.
7. Pielei paths with the lowest IGP metiic:
a. Examine ioute taLles inet.0 anu inet.3 loi the BGP next hop, anu then install
the physical next hop(s) loi the ioute with the Lettei pieleience.
L. Foi pieleience ties, install the physical next hop(s) lounu in inet.3.
c. Foi pieleience ties within the same ioute taLle, install the physical next hop(s)
wheie the gieatei numLei ol egual-cost paths exists.
S. Pielei paths with the shoitest clustei length.
9. Pielei ioutes liom the peei with the lowest ioutei ID (RID), unless multipath is
enaLleu:
a. Foi exteinal ioutes liom uilleient ASs, uo not altei the active ioute Laseu on
the lowest RID to pievent MED oscillation.
10. Pielei ioutes liom the peei with the lowest peei ID (BGP peeiing auuiess), unless
multipath is enaLleu.
Conliguiing the multipath option ueactivates the last two uecision points, which aie
noimally useu as tieLieakeis. Vhen multipath is enaLleu, all paths that aie egual up
to step 9 aie installeu in the ioute taLle. Multipath suppoits EBGP anu IBGP, Lut it is
noimally associateu with EBGP sessions Lecause IBGP will olten achieve its loau-
Lalancing lunctionality thiough the unueilying IGP when egual cost paths to the IBGP
speakei exist. Use multipath loi IBGP when two oi moie IBGP speakeis auveitise the
same pielix anu you wish to install Loth speakeis as viaLle next hops.
Figuie 7-2 uemonstiates the BGP path selection piocess at woik.
Heie, NLRI 10.0.20/2+ is oiiginateu into BGP Ly AS 65000. Note that when auveitiseu
to ASs 65010 anu 65069, this NLRI is associateu with an AS path attiiLute that consists
ol a single AS anu has an oiigin value ol I inuicating IGP leaineu. This coulu Le a
uelault value loi ieuistiiLution ol static ioutes into BGP oi the iesult ol policy setting.
The NLRI is then ieauveitiseu into AS 65069 Ly AS 65010. Initially, iouteis R1 anu R2
pielei theii local copy ol this path, so Loth R1 anu R2 select it as active anu auveitise
the NLRI to all IBGP peeis, which means that R3 ieceives two upuates loi the same
path. In this example policy, R2 causes the ioute to Le sent into IBGP with a mouilieu
254 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
local pieleience value ol S0. Note that the ioute ieceiveu liom AS 65010 has an AS
seguence one AS longei than the ioute sent to R2 uiiectly liom AS 65000.
Running thiough the path selection piocess steps listeu pieviously, it`s sale to assume
that R3 will make a uecision eaily in the piocess, pieleiiing the copy ol the ioute with
a uelault local pieleience ol 100. Hau Loth local pieleience values Leen the same, the
selection ciiteiion woulu now Lecome the shoitest AS path length, iesulting in R3
loiwaiuing thiough R2. Note that R1 anu R2 will also senu theii 10.0.20/2+ upuates
to each othei. This means that R2 pieleis the path thiough R1, anu theieloie now senus
anothei upuate to R1 anu R3, withuiawing its eailiei IBGP upuate loi 10.0.20/2+. The
example also helps to uemonstiate how local pieleience is useu to inlluence the egiess
point in the local AS.
]unos soltwaie is uesigneu to uisplay all valiu BGP paths, anu even incluues the ieason
why a given path was not selecteu. This gieatly simplilies the netwoik auministiatoi`s
joL when the goal is to make a cuiiently inactive path the active path; policy can Le
applieu to altei the ciiteiion that leaus to the oiiginal path Leing pieleiieu. Heie`s the
output liom a show route detail commanu, to illustiate this point:
user@host> show route 10.0.20/24 detail
inet.0: 52 destinations, 94 routes (52 active, 0 holddown, 0 hidden)
10.0.20.0/24 (3 entries, 1 announced)
Iigurc 7-2. BGP path sc|cction
What Is BGP? | 255
*BGP Preference: 170/-201
Source: 192.168.32.1
Next hop: 10.222.28.2 via ge-0/0/0.0, selected
Protocol next hop: 192.168.32.1 Indirect next hop:
858b4e0 73
State: <Active Int Ext>
Local AS: 65069 Peer AS: 65069
Age: 18:57 Metric2: 3
Task: BGP_65432.192.168.32.1+1042
AS path: 65000 65010 I
Localpref: 100
Router ID: 192.168.32.1
BGP Preference: 170/-101
Source: 10.222.29.2
Next hop: 10.222.29.2 via ge-0/1/0.0, selected
State: <Ext>
Inactive reason: Local Preference
Local AS: 65069 Peer AS: 65069
. . .
Localpref: 80
Fiom the sample output, it is guite cleai that Lecause ol the local pieleience compai-
ison, the path thiough 192.16S.32.1 is pieleiieu. Knowing that this BGP ioute was not
chosen Lecause ol the local pieleience value makes it a ielatively simple task to change
the selection ol the path thiough 192.16S.32.1 Ly setting its pieleience to Le highei
than 100.
Internal and External BGP
Ve have alieauy useu the teims |ntcrna| BGP anu Extcrna| BGP (IBGP/EBGP) a lew
times leauing up to this point. It`s time to exploie what this teiminology signilies. Foi
the most pait, BGP opeiation is the same when opeiating inteinally to an AS veisus
exteinally to a iemote AS, Lut TaLle 7-1 summaiizes the key uilleiences.
Tab|c 7-1. |BGP and EBGP
Characteristic/attribute IBGP EBGP
Local AS added to AS path No Yes
Next hop overwritten No Yes
New MED added No; the MED received on an EBGP link can
be advertised via IBGP within the local AS
Yes
Local preference Yes No
Peering address Normally loopback, recursive lookup pro-
vided by IGP, Time to Live (TTL) = 64
Normally peers directly to interface ad-
dress, no recursion or IGP needed, TTL = 1
Update received from EBGP, is
sent to
All IBGP peers Other EBGP peers
Update received from IBGP, is
sent to
No IBGP peers All EBGP peers
256 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
Although the uilleiences may seem tiivial, they can have a signilicant impact. Foi ex-
ample, Lecause IBGP upuates uo not altei the AS path attiiLute, loops Lecome a con-
cein, anu this leaus to the iestiiction that IBGP speakeis cannot ieauveitise an IBGP
upuate to othei IBGP speakeis, which leaus to the ieguiiement that IBGP speakeis
shoulu Le lully mesheu (see the next section loi alteinatives).
The next hop-hanuling uilleiences olten leau to IBGP ioutes that aie hiuuen Lecause
the ieceivei cannot iesolve the associateu BGP next hop. By uelault, the next hop iuen-
tilies the EBGP speakei in the aujoining AS, anu olten the IGP will not caiiy this ioute,
theieLy leauing to an unieachaLle next hop. An IBGP expoit policy that oveiwiites the
BGP next hop, typically to the IBGP peeiing auuiess (next-hop sell), is noimally useu
to iesolve this issue (no pun intenueu).
The MED attiiLute is noimally auueu only when a ioute is auveitiseu ovei an EBGP
peeiing, anu its aLsence may Le inteipieteu as the lowest oi highest possiLle value,
uepenuing upon implementation]unipei assumes the lowest value, which is 0. In
contiast, local pieleience is piesent only in IBGP upuates, anu Ly stanuaiu is assumeu
to Le 100 when aLsent. Vhen ieceiveu liom an EBGP peei, the MED value can Le
auveitiseu to othei speakeis within that AS using IBGP.
The peeiing uilleiences aie signilicant loi seveial ieasons. EBGP noimally peeis to a
neighLoi using an auuiess on the uiiectly connecteu link Letween the iouteis. As a
iesult, no ioute iecuision is neeueu to iesolve the BGP peeiing auuiess to a next hop
loiwaiuing auuiess, given that they aie one anu the same. This means that an IGP, to
incluue static iouting, is noimally not ieguiieu to suppoit EBGP peeiing. It also means
that loss ol the uiiectly connecteu netwoik/peeiing inteilace iesults in loss ol the EBGP
session. Foi secuiity ieasons, the TTL loi EBGP sessions is set to 1 Ly uelault, which
pievents attempts to peei liom a iemote link. This Lehavioi is alteieu Ly conliguiing
multihop on the EBGP session. Lastly, a local-address (ieleiieu to as updatc-sourcc in
IOS) is noimally not useu loi an EBGP session, Lecause Ly uelault, it is souiceu liom
the same uiiectly connecteu netwoik inteilace that the two BGP iouteis aie peeiing
ovei; theieloie, the souice anu uestination auuiesses loi the BGP session will Le liom
the same, uiiectly connecteu suLnet.
IBGP, in contiast, is noimally conliguieu to peei Letween the loopLack auuiesses ol
the iouteis. This pioviues iesiliency liom the lailuie ol inuiviuual netwoiks oi inteila-
ces. IBGP inheiently suppoits multihop, which is goou Lecause IBGP neighLois can Le
locateu anywheie with the AS anu olten uo not shaie a link. A iecuisive ioute lookup
is neeueu to iesolve the loopLack peeiing auuiess to an IP loiwaiuing next hop, anu
thus this seivice is noimally pioviueu Ly the netwoik`s unueilying IGP. Vhen uelining
a BGP loopLack peeiing session, you neeu to coiiectly match the souice auuiess useu
Ly the local peei to ensuie that it matches the session uelinition at the iemote peei.
Recall that Ly uelault, the ioutei will souice tiallic liom its egiess inteilace, which will
not Le the loopLack inteilace, anu this can make the incoming connection ieguest
appeai to come liom an unuelineu peei.
Internal and External BGP | 257
Scaling IBGP with Route Reflection
The pievious sections toucheu on the lact that IBGP speakeis shoulu Le lully mesheu
Lecause ol the iestiictions that IBGP has on ieauveitising upuates to othei IBGP speak-
eis. Vhen BGP was liist envisioneu moie than 20 yeais ago, conventional wisuom was
that the gloLal Inteinet woulu consist ol only a lew ASs, anu that each AS woulu have
a lew BGP speakeis, anu that these speakeis woulu Le uealing with a lew hunuieu
ioutes. Recall also that the VP ol IBM once announceu the woiluwiue maiket loi
mainliames to Le aiounu 10 units! Maintaining a lull IBGP mesh among a lew iouteis
is tiivial, Lut uoing so among hunuieus ol iouteis is neaily impossiLle.
Given the mouein ieality ol tiansit pioviuei netwoiks neeuing to iun IBGP on viitually
eveiy ioutei in theii AS, anu that theie may Le hunuieus ol these iouteis, you can
guickly concluue that maintaining a lull mesh ol IBGP sessions guickly Lecomes un-
manageaLle. The loimula to compute the numLei ol sessions ieguiieu loi a lull mesh
is v (v - 1)/2, wheie v is the numLei ol BGP speakeis. Using the loimula, we see that
loi 10 IBGP speakeis, a total ol +5 IBGP sessions aie neeueu (10 (9)/2 = +5). Inciease
the numLei ol speakeis Ly a meie 50to 15anu the numLei ol sessions ieguiieu
incieases geometiically to 105! It`s cleai that the lull-mesh mouel simply uoes not scale;
soon iouteis woulu exhaust all theii contiol plane iesouices just maintaining all theii
BGP sessions. A solution was neeueu, anu ioute iellection, as cuiiently uelineu in RFC
++56, pioviues a iemaikaLly elegant solution to what coulu have Leen a signilicant
piotocol shoitcoming. Figuie 7-3 shows a small IBGP clouu Leloie anu altei ioute
iellection is auueu.
Iigurc 7-3. BGP routc rcj|cction
Note that in the liist example, an IBGP session is missing, iesulting in a less than lull
mesh, which in tuin leaus to holes in the BGP topology. In the seconu example,
258 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
howevei, R2 has Leen conliguieu to peiloim iellection, using Lut a single commanu
to assign a clustei ID. The only change maue to clients R1, R3, anu R+ is the iemoval
ol theii now unneeueu IBGP sessions.
Route iellection auus two new attiiLutes to IBGP upuates to auuiess conceins aLout
BGP loops that woulu otheiwise occui, given that IBGP upuates uo not mouily the AS
path. These attiiLutes aie auueu Ly the ioute iellectoi when it liist touches a client`s
ioute. Conliguiation ol iellection is peiloimeu only on the ioute iellectoi itsell; no
conliguiation changes aie neeueu loi a ioute iellectoi client, othei than peihaps to
uecommission unneeueu IBGP peeiing uelinitions to othei clients in the same clustei.
The clustei list attiiLute iuentilies the ioute iellection clusteis that the ioute has visiteu,
wheieas the oiiginatoi ID attiiLute iuentilies the ioute`s oiiginal souice. These attiiL-
utes aie piocesseu Ly ioute iellectois to pievent loops Ly ensuiing that IBGP upuates
aie echoeu only once to each iellectoi client anu noniellectoi client. Simply put, a
clustei`s iellectoi will not ieauveitise an IBGP upuate into clustei ID n, when clustei
ID n is alieauy piesent in the clustei list attiiLute. The iellectoi also uses the oiiginatoi
ID attiiLute to ensuie that upuates aie nevei sent Lack to the client that oiiginateu the
ioute. Note that the ioute iellectoi liist peiloims the Lest path selection piocess on all
upuates anu iellects only the paths it chooses as Lest.
You typically want the loiwaiuing topology to uillei liom the iellection topology,
which is to say that packets can Le loiwaiueu uiiectly Letween two BGP speakeis,
uespite theii leaining each othei`s ioutes thiough a iellectoi. Il the IGP`s shoitest path
uoes not leau thiough the iellectoi, the packets shoulu not llow thiough the iellectoi.
Caie must Le taken with any next hop sell-policy applieu to a iellectoi to ensuie that
it uoes not iewiite the next hop on IBGP ioutes that it is iellectinguoing so will loice
extia hops on packets that now neeu to cioss the iellectoi. A next hop sell-policy is
olten applieu to IBGP upuates to iewiite the BGP next hop ol EBGP leaineu ioutes
with the peeiing auuiess ol the local speakei. This pievents pioLlems with inteinal
speakeis not Leing aLle to iesolve the next hop oiiginally ieceiveu in the EBGP upuate,
which is set to the iemote EBGP speakei`s peeiing auuiess anu noimally not alteieu in
IBGP upuates.
Route reflection and redundancy
Rellection can iepiesent a single point ol lailuie, making it common to auu ieuunuancy
Ly ueploying multiple iellectois. Noimally, each iellectoi IBGP peeis with each client
in the clustei, anu the two ioute iellectois aie then joineu via a nonclient IBGP session.
Theie always seems to Le enuless ueLate in such uesigns as to whethei each iellectoi
shoulu Le assigneu the same oi a unigue clustei ID. Figuie 7-+ illustiates the two uesign
alteinatives.
In most cases, a uesign using unigue clustei IDswhich technically iesults in two ioute
iellectoi clusteis, each having one iellectoiis consiueieu the Lest appioach loi main-
taining connectivity in the event ol lailuies. This is Lecause the iellectois uo not see
Internal and External BGP | 259
theii own clustei ID in the upuates they senu each othei via the ioute iellectoiioute
iellectoi IBGP session, anu theieloie the iellectois will leain ol Loth theii intiaclustei
anu inteiclustei paths, iesulting in a moie complete BGP taLle at the iellectois. Foi
example, il the R3-R1 IBGP session shoulu lail, R1 is still aLle to ieach R3 via the path
leaineu liom R2 in clustei 2.2.2.2. The uual-clustei appioach uoes have the uiawLack
ol incieaseu BGP ioute state at the iellectois, piompting some to pielei the shaieu
clustei ID mouel.
Ve uiscusseu the main uiawLack to the shaieu clustei ID appioach eailieinamely,
the potential loi client-to-iellectoi session loss anu the iesultant lack ol connectivity.
Howevei, il we assume loopLack-Laseu peeiing, theie is actually little iisk to the shaieu
clustei mouel. This is Lecause it`s extiemely unlikely that a client-to-iellectoi IBGP
session will Le lost while the client is still aLle to maintain connectivity to the iest ol
the netwoik. You shoulu use unigue clustei IDs il you`ie using inteilace-Laseu peeiing
so as to pioviue toleiance loi lailuie ol inuiviuual inteilaces.
Scaling IBGP: Confederations
A BGP conleueiation ellectively uiviues a laige AS into smallei, mini ASs known as
ncnbcr ASs. Vithin each memLei AS, you noimally linu a lull IBGP mesh, Lut ioute
iellectois can also Le ueployeu as pait ol a conleueiation solution. It`s noimal to see
memLei ASs assigneu AS numLeis liom the piivate numLeiing space Lecause memLei
AS numLeis aie not seen exteinal to the AS conleueiation anyway. Because the numLei
ol iouteis within each suL-AS is ielatively small, maintaining a lull IBGP mesh is man-
ageaLle. To the outsiue woilu, all these conleueiation shenanigans aie hiuuen, anu the
entiie AS conleueiation is iepiesenteu Ly a single AS numLei.
Iigurc 7-1. Routc rcj|cction rcdundancy
260 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
Conleueiation use is iaie in enteipiise netwoiks, anu we will not exploie the suLject
heie othei than to mention that ]unipei iouteis ollei lull suppoit loi BGP conleueia-
tions. Foi moie inloimation on BGP conleueiations, consult ]unos soltwaie uocu-
mentation oi RFC 5065, Autonomous System Conleueiations loi BGP.
BGP and the Enterprise
The pieceuing section pioviueu a taigeteu ieview ol BGP`s opeiational chaiacteiistics
anu scaling appioaches. BGP is noimally associateu with Inteinet seivice pioviuei (ISP)
netwoiks that ollei tiansit seivices loi Inteinet tiallic. This section locuses on how BGP
can Le applieu to meet the iouting neeus ol enteipiise netwoiks.
When Should an Enterprise Run BGP?
BGP is a sophisticateu iouting piotocol that can help to optimize an enteipiise`s iout-
ing, Lut that uoesn`t mean all enteipiise netwoiks will see a Lenelit liom its ueployment.
An enteipiise uecision to iun BGP noimally hinges on the Lenelits that can Le gaineu
Ly making intelligent outgoing iouting uecisions anu Ly using BGP attiiLutes in an
attempt to inlluence how upstieam netwoiks ioute towaiu youi netwoik to help con-
tiol which links aie useu loi ingiess tiallic. The common lactoi to Loth ol these
scenaiios is a netwoik with at least two exteinal connectionssuch a netwoik is con-
siueieu to Le dua|-honcd. Enteipiise netwoiks with a single attachment to a seivice
pioviuei will noimally not Lenelit Ly iunning BGP anu shoulu simply use a static uelault
ioute. Vhen uual-attacheu to the same pioviuei, two static uelaults can Le useu to
achieve some measuie ol outLounu loau Lalancing.
A word about AS numbers
Although likely oLvious Ly now, we must state that to iun BGP you must liist have an
AS numLei. Like IP auuiesses, theie aie Loth puLlic anu piivate AS numLei pools.
PuLlic AS numLeis aie assigneu Ly a Regional Inteinet Registiyloi example, ARIN
loi the Ameiicas, CaiiLLean, anu suL-Sahaian Aliica, APNIC loi Asia Pacilic, oi RIPE
loi Euiope, the Miuule East, anu Noithein Aliica.
Histoiically, the ASN space was limiteu Ly the use ol a 2-Lyte value, which peimitteu
a maximum ol 65,535 ASs. Suppoit ol +-Lyte couing loi ASNs, which can pioviue moie
than + Lillion unigue ASNs, is uelineu in RFC +S93 anu is suppoiteu in ]unos soltwaie.
An enteipiise shoulu expect to justily its neeu to the Regional Inteinet Registiy when
applying loi a puLlic ASN. Reguiiements vaiy, Lut noimally you gualily loi a puLlic
ASN only when youi netwoik is multihomeu anu has a single, cleaily uelineu iouting
policy that is uilleient liom its pioviueis` iouting policies. This Liings up a key point
aLout BGP, policy, anu uual homing. Vhen you aie attacheu to a single upstieam
pioviuei, liom the peispective ol the iest ol the woilu youi policy must, Ly uelinition,
match that ol youi pioviuei. This is Lecause only one exteinal view ol that enteipiise`s
BGP and the Enterprise | 261
ioutes is Leing maue availaLle, anu this view is Laseu on youi pioviuei`s policy. BGP
can still Le useu when connecteu to a single upstieam pioviuei, Lut in these cases, you
will olten conliguie the iouteis with an ASN liom the piivate AS space. The pioviuei
will then stiip the piivate ASN anu ieplace it with its ASN when announcing these
ioutes to othei netwoiks. The piivate ASN space, which is technically allocateu to the
IANA itsell, ianges liom 6+,512 to 65,53+, inclusive. These numLeis aie olten useu to
numLei suLconleueiations within a conleueiateu AS.
ASN Portability
An oiganization may oLtain its ASN uiiectly liom a iegional numLeiing authoiity oi
as pait ol its seivice agieement with a local pioviuei, which in this case lunctions as a
Local Inteinet Registiy (LIR) Ly uelegating ASNs (anu auuiess Llocks) liom its assigneu
pool. In most cases, ASNs oLtaineu liom an LIR will not Le poitaLle il you latei ueciue
to move to a new pioviuei. This situation is similai to nonpoitaLle IP auuiess Llocks,
which stay with the pioviuei shoulu you choose to oLtain seivice elsewheie. Although
AS ienumLeiing is ceitainly less woik than IP ienumLeiing, Loth can Le uisiuptive anu
time-consumingcaielul thought shoulu Le given to the potential neeu loi ASN poit-
aLility when planning youi BGP ueployment.
Dual-homed: Single versus multiple providers
Being uual-homeu is a gieat way to impiove peiloimance anu ieliaLility. But uo all
uual-homeu enviionments waiiant use ol BGP? In most cases, this is a lunction ol
whethei the enteipiise is uual-homeu to the same oi to uilleient upstieam pioviueis.
Figuie 7-5 shows the two types ol uual-homing aiiangements. Note that Loth mouels
suppoit multiple attachments to the same ISP, whethei loi ieasons ol ieuunuancy oi
auueu capacity. In lact, the simplest loim ol the uual-homeu single-pioviuei/uual-
pioviuei mouel is to use a single ioutei with uual links. Relying on a single uevice loi
all exteinal connectivity sulleis oLvious ieliaLility conceins, anu it is assumeu iaie loi
all Lut the smallest ol enteipiise netwoiks. Eveiy iule has exceptions, anu heie the
exception is when a clusteieu aiiangement ol SRXs is useu to inteilace to the pioviuei.
In this case, the simplicity ol the single uevice is coupleu with the ieliaLility ol a
multiioutei uesign.
Running BGP is noimally oveikill when you aie uual-homeu to the same pioviuei,
especially when the paiallel connections aie in close geogiaphic pioximity. This is Le-
cause you aie pietty much at the meicy ol youi pioviuei`s policy, anu BGP cannot uo
much to altei the way tiallic enteis oi exits youi netwoikyoui gloLal view ol the
Inteinet must match that ol youi pioviuei Lecause it is the only view you ieceive. An
enteipiise with this type ol connectivity is olten well seiveu with a simple static uelault
ioute. Loau Lalancing can occui in one ol two ways. Foi a single ioutei with uual
attachments, the loau Lalancing occuis at that ioutei, using the unueilying IGP (static)
to map pielixes oi llows to one ol the two links. This ioutei is in tuin conliguieu to
262 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
auveitise a uelault ioute into the IGP to attiact nonlocal tiallic. Vhen uual iouteis aie
useu, each with a single pioviuei uplink, it`s common to see each ioutei geneiate anu
auveitise a uelault ioute into the IGP, while they in tuin each have a static uelault
pointing towaiu that ioutei`s pioviuei uplink.
Asymmetric Link Speed Support
The use ol asymmetiic link speeus loi ieuunuant attachment to the same pioviuei is
common in Loth mouels. Vhen iunning BGP, the Lanuwiuth community can Le useu
to pioviue unegual cost loau Lalancing piopoitionate to the link speeu. In contiast,
static iouting ovei asymmetiic links is typically uone Ly uiiecting all tiallic ovei the
high-speeu link until it Lecomes unavailaLle, at which point the tiallic is switcheu to
the lowei-speeu seconuaiy. In ]unos soltwaie, this is accomplisheu with a static ioute
along with a qua|ijicd ncxt hop. A gualilieu next hop is a list ol next hops with vaiying
pieleiences/metiics that aie useu in oiuei ol theii pieleience, Laseu on the aLility to
iesolve the associateu next hop. The lollowing coue snippet shows how a uual-homeu
customei coulu conliguie all tiallic to egiess on a high-speeu T3 link, unless the T3
inteilace/next hop Lecomes unavailaLle, at which point the tiallic will switch to the
gualilieu next hop with the next most pieleiieu (next lowest) pieleience:
[edit routing-options static]
ruser@router# show
route 0.0.0.0/0 {
qualified-next-hop 10.0.1.1 {
preference 20;
interface t3-1/0/0.0;
}
qualified-next-hop 10.0.1.5 {
Iigurc 7-5. BGP dua| honing
Asymmetric Link Speed Support | 263
preference 30;
interface t1-2/0/0.0;
}
}
Which Routers Should Run IBGP?
Gieat! You`ve maue it this lai, which shows that you still leel youi netwoik eithei
justilies use ol BGP, oi simply neeus a puppy. Fiom this point loiwaiu, this chaptei
assumes a netwoik that is uual-homeu to multiple pioviueis, as is youi uesiie loi line-
giaineu contiol ovei how tiallic enteis anu exits youi netwoik. Having ieacheu this
ueteimination, the next logical guestion is, Vheie shoulu I conliguie BGP? Knowing
wheie to iun EBGP is pietty stiaightloiwaiu; you must conliguie EBGP on the iouteis
that peei to othei ASs. The ieal guestion is wheie uo you have to iun IBGP, anu this is
a veiy, veiy goou guestion inueeu.
Fiist, consiuei that most seivice pioviuei netwoiks iun both an IGP anu an IBGP on
a|| ol theii coie iouteis.

Seivice pioviueis neeu to iun BGP on all theii iouteis to ensuie that the Inteinet coie
iemains a uelault liee iouting zone, anu Lecause no seivice pioviuei in its iight minu
woulu (intentionally) tiy to ieuistiiLute a lull BGP taLle into its IGP. Foi the liist point,
any tiansit netwoik that uoes not caiiy lull Inteinet iouting, anu theieloie ielies on
some type ol uelault ioute, will Le pione to loops. Il the netwoik is not iunning BGP
on all tiansit iouteis, anu theie is no uelault ioute, the implication is that the IGP is in
lact caiiying a lull Inteinet ioute taLle. Even the Lest implementeu IGPs aie not inten-
ueu to caiiy hunuieus ol thousanus ol exteinal ioutes, making such a uesign implau-
siLle given the sheei size ol Inteinet ioute taLles.
It`s inteiesting to note that ]unos soltwaie uoes not have the concept ol
IGP-BGP synchionization, making a no synchronization conliguiation
statement unnecessaiy. In IOS, the BGP piocess expects the IGP to have
a copy ol each ioute Leloie that ioute can Le auveitiseu Ly BGP, unless,
ol couise, you have tuineu oll synchionization. This is why uisaLling
synchionization is the liist step in almost any IOS conliguiation. Con-
siuei this one less commanu to get BGP up anu iunning on a ]unipei!
By iunning BGP on all its iouteis, a seivice pioviuei uoes not iely on a uelault ioute,
anu it can meicilully spaie its IGP an ignoLle meltuown. By iunning Loth piotocols,
the IGP is lelt to uo what it uoes Lest: pioviuing connectivity Letween the loopLack
inteilaces useu loi IBGP peeiing, while BGP ioutes keep the tiansit tiallic liom looping
aLout anu also pioviue neeueu auministiative policy contiols.
The notaLle exception heie is the BGP liee coie, typically Laseu on Multipiotocol LaLel Switching (MPLS)
to avoiu the neeu loi lull iouting state in the coie.
264 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
No Transit Services
Seivice pioviuei netwoiks aie iichly inteiconnecteu to the outsiue woilu, anu they aie
optimizeu loi making money Ly tianspoiting tiallic that neithei oiiginates on noi tei-
minates in theii netwoiks. This is, altei all, what makes them transit seivice pioviueis.
In contiast, an enteipiise netwoik is conceineu with the tianspoit ol its own tiallic,
alLeit sometimes neeuing to ventuie ollsite to oLtain ieguiieu inloimation. By not pio-
viuing tiansit seivices, an enteipiise can avoiu iunning IBGP on eveiy ioutei. Vhen
possiLle, the netwoik shoulu Le uesigneu so that the BGP speakeis aie geogiaphically
localizeu, thus minimizing the poitions ol the netwoik that neeu to iun BGP. Fig-
uie 7-6 pioviues a sample topology to illustiate this concept.
Iigurc 7-. Which routcrs nccd to run |BGP?
The liguie shows a netwoik topology that iuns BGP loi its own connectivity, not loi
pioviuing tiansit/connectivity seivices to othei netwoiks. The BGP speakeis have Leen
positioneu neai the netwoik`s euge anu in geogiaphic pioximity, in an elloit to
constiain the scope ol iouteis that neeu to iun BGP. Routeis R1 thiough R3 aie
BGP-enaLleu anu speak EBGP to theii attacheu seivice pioviueis anu IBGP among
themselves. BGP is neeueu Letween these iouteis Lecause Inteinet-uestineu tiallic
oiiginating within the enteipiise can aiiive at any ol these, anu the consistent BGP
taLles ensuie that tiallic egiesses the netwoik accoiuing to local policy, even il some
auuitional hops acioss the LackLone aie neeueu to ieach the uesiieu egiess point.
A uelault ioute is geneiateu Ly two ol the IBGP speakeis anu is injecteu into the IGP
to pioviue the non-BGP-speaking iouteis with exteinal connectivity. The use ol a gen-
eiateu ioute, as opposeu to a simple static ioute, allows the withuiawal ol an auveitiseu
Asymmetric Link Speed Support | 265
uelault when the BGP speakei has pioLlems with its EBGP sessionthe geneiateu
ioute is maue active Ly the piesence ol leaineu EBGP ioutes. Inteinal iouteis simply
select the iemaining uelault ioute that is metiically closest to maintain theii exteinal
connectivity.
The Impact of Accepting Specifics Versus a Default from Your Provider
The neeu to iun IBGP on iouteis that uo not speak EBGP is noimally a lunction ol
whethei the enteipiise`s impoit policy accepts only a uelault ioute oi is conliguieu to
accept specilic ioutes. In the lattei case, you will neeu to iun BGP on any iouteis that
aie useu to inteiconnect youi EBGP/IBGP-speaking noues to pievent iouting loops.
Figuie 7-7 pioviues an example ol how inconstant iouting knowleuge can leau to a
iouting loop. The inconsistency aiises liom loiwaiuing state that is known to the BGP
speakeis only while othei iouteis iely on a uelault ioute. Il all iouteis accepteu only a
uelault oi the same set ol specilics, this conuition woulu not aiise.
Iigurc 7-7. Routing |oop jron |ac| oj BGP routing |now|cdgc
In this example, iouteis R1 anu R2 aie iunning EBGP with impoit policies that accept
specilic ioutes. Both iouteis IBGP-peei to each othei. All othei iouteis aie iunning an
IGP only. Things Legin at step 1 in Figuie 7-7, wheie Loth R1 anu R2 geneiate a uelault
ioute that is injecteu into Open Shoitest Path Fiist (OSPF). Step 2 shows Pioviuei B
auveitising the 10.0.1/2+ pielix, which is accepteu Ly R2, given its impoit policy that
266 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
accepts specilics anu iejects the uelault ioute. R2 auveitises this ioute to R1 ovei the
IBGP session at step 3. R1 installs this ioute as active in this example Lecause the same
ioute leaineu liom ISP A will have a longei AS path length.
Things Legin to go wiong at step + in Figuie 7-7, when R+ ueciues to avail itsell ol the
uelault ioute to loiwaiu a packet to uestination 10.0.1.1. In this example, R+ senus the
packet to R3, Lut senuing it uiiectly to R1 woulu not change things in the long iun.
Recall that R3 is not iunning BGP anu is theieloie ielying on the uelault ioute to ieach
this uestination, as uiu R+. Il R3 ueciues to loiwaiu to the uelault it leaineu liom R2,
eveiything is all iight. But theie is a 50 chance that it will ueciue to loiwaiu to the
uelault ioute it leains liom R1. As a BGP speakei, R1 has specilic iouting inloimation
loi this pielix, which it leaineu ovei its IBGP session to R2. R1`s iouting uecision ue-
teimines that the packet shoulu Le loiwaiueu towaiu the piotocol next hop auveitiseu
Ly R2, that is, R2`s loopLack auuiess. The iesult ol R1`s iecuisive ioute lookup on R2`s
loopLack auuiess may Le the uecision to loiwaiu the packet ovei the R1-R2 link oi
ovei the set ol R1-R2-R3 links, as ueteimineu Ly IGP metiics. Il R1 loiwaius the packet
Lack to R3, a loop is loimeu, given that R3 has alieauy hanuleu this packet anu ueciueu
to senu it to R1.
Two solutions piesent themselves:
Enab|c |BGP on R3
Il you enaLle IBGP on R3, anu then lully mesh the IBGP speakeis, R3 woulu have
nevei useu the uelault ioute to loiwaiu this packet anu woulu have sent it uiiectly
to R2 loi uispatch into AS B.
Rcjcct spccijics
Il the impoit policy at R1 anu R2 is alteieu to accept only a uelault, this ioute coulu
Le ieuistiiLuteu into the IGP. The EBGP leaineu veision ol the uelault ioute will
iemain active at Loth R1 anu R2, even il the BGP speakeis ieauveitise the uelault
ioute to each othei, owing to the ioute selection step that pieleis EBGP leaineu
ovei IBGP leaineu ioutes. Now, when a packet auuiesseu to 10.0.1.1 aiiives at R1,
it longest-matches against the uelault ioute leaineu liom Pioviuei A anu is not sent
Lack to eithei R2 oi R3, so no loops loim.
Although the seconu solution pievents a iouting loop, senuing to ISP A is pioLaLly not
the optimal way loi this enteipiise to ieach pielix 10.0.1.0/2+. This helps to illustiate
why accepting specilic ioutes, anu then iunning IBGP among the iouteis that can Le
useu to tiansit Letween EBGP speakeis, is geneially the optimal way loi an enteipiise
to ueploy BGP.
Summary of Enterprise BGP Requirements
To summaiize, an enteipiise shoulu consiuei iunning EBGP when it is multihomeu,
to take auvantage ol the optimal iouting anu iouting contiols pioviueu Ly BGP. The
enteipiise shoulu iun IBGP on any ioutei that iuns EBGP, anu it must caielully consiuei
Asymmetric Link Speed Support | 267
what othei iouteis shoulu Le IBGP-enaLleu. Recall that IBGP ieguiies a lull mesh oi
the use ol ioute iellection/conleueiations loi piopei opeiation. Because BGP is not
ieuistiiLuteu into youi IGP, lailing to iun IBGP on all iouteis will iesult in those iouteis
not having a complete view ol BGP ieachaLility. Noimally, a geneiateu uelault ioute
is injecteu into the IGP to accommouate exteinal iouting loi the non-BGP speakeis.
RememLei that BGP will neeu to Le enaLleu on iouteis that aie expecteu to pioviue
tiansit seivice bctwccn youi EBGP speakeis when the enteipiise policy is to accept
specilic ioutes liom youi seivice pioviueis to pievent against iouting loops. Rejecting
specilics anu accepting only a uelault ioute lessens this ieguiiement, as uesciiLeu
eailiei.
This section gave a compiehensive ieview ol BGP anu its key capaLilities anu opeia-
tional chaiacteiistics. Ve also uiscusseu how BGP can Lenelit an enteipiise Ly helping
to make optimizeu outLounu iouting uecisions, anu when all goes to plan, to also help
inlluence youi peei`s outLounu uecisions to ellect Lettei contiol ol how tiallic aiiives
at youi netwoik`s Lounuaiies.
You may consiuei taking a Liiel Lieak Leloie uiving into the next section. Some ol the
hanus-on scenaiios aie a Lit lengthy Lecause ol the numeious inclusions ol actual ioutei
output, which aie auueu to ensuie that the ieauei is aLle to lollow the uetails ol the
case stuuy.
BGP Deployment: Asymmetric Load Balancing
Having maue it thiough the piotocol oveiview anu enteipiise application section, it is
now time to apply youi knowleuge ol BGP anu ]unos soltwaie to the liist ol thiee
piactical BGP ueployment scenaiios.
The liist scenaiio Legins when the CIO at Beei-Co seizes upon the oiganization`s new-
lounu appieciation loi all things BGP Ly applying loi a puLlic ASN anu uetailing a BGP
ueployment plan that ultimately involves uual-homing to multiple pioviueis. BGP ue-
ployment will occui in a phaseu appioach, anu you have Leen selecteu to heau up
phase 1: estaLlishment ol the initial BGP peeiing anu ielateu policy to Botnet in AS 3+.
The ueployment goals loi initial BGP peeiing with Botnet aie as lollows:
EstaLlish EBGP inteilace-Laseu peeiing to Botnet/AS 3+.
Use impoit policy to ieject all Lut the uelault ioute that oiiginates within Botnet/
AS 3+.
Use expoit policy to auveitise a single aggiegate ioute that iepiesents Beei-Co`s
inteinal pielixes.
Use a static ioute to uiiect tiallic to the Lackup link on|y in the event ol BGP session
uisiuption, anu to ensuie that tiallic switches Lack to the piimaiy upon seivice
iestoiation.
268 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
D
o
ReuistiiLute a uelault ioute to pioviue exteinal ieachaLility loi inteinal Beei-Co
iouteis.
Figuie 7-S uetails the cuiient Beei-Co inteinal topology anu the newly activateu access
links to Botnet.
Iigurc 7-8. Bccr-Co to Botnct pccring
Figuie 7-S shows that Botnet is attacheu to othei seivice pioviueis, anu to a paiticulai
customei, Biewei Inc., which has Leen assigneu a 192.16S.3+.0/2+ auuiess Llock. The
numLeis encloseu within paientheses iepiesent the iange ol ioute pielixes that Botnet
is expecteu to auveitise. In this example, these ioutes aie instantiateu as locally uelineu
static ioutes, complete with associateu AS numLeis anu oiigin coue. This technigue
helps to simulate the leaining, anu suLseguent ieauveitisement, ol BGP ioutes Letween
Botnet anu its BGP peeis. The customei ioute shown loi pioviuei Biewei, which is
192.16S.3+.0/2+ in this case, is set to a ieject next hop so that ieachaLility can Le
conliimeu, even when the customei site uoes not exist. Note that you expect to ieceive
an Inteinet Contiol Message Piotocol (ICMP) uestination unieachaLle message uue to
the ieject-style next hop, Lut this eiioi message seives to valiuate ieachaLility loi oui
puiposes.
BGP Deployment: Asymmetric Load Balancing | 269
Note also that Beei-Co has ieuunuant links to Botnet. The huge uispaiity in link speeu
(1 GLps veisus 1.5 MLps) uiives the uecision to use the lastei link as a piimaiy with
the seconu link useu only in the event ol pioLlems on the piimaiy inteilace oi a ielateu
BGP peeiing session. Caie must Le taken to ensuie that the static ioute useu to uiiect
tiallic ovei the seconuaiy link is |css prcjcrrcd than any BGP ioutes leaineu liom
AS 3+, which is not the uelault Lehavioi, as a static ioute is moie pieleiieu than any
uynamically leaineu one. A mistake heie coulu easily mean paying loi a 1 GLps pipe
while thioughput is limiteu to a paltiy 1.5++ MLps!
Validate Baseline Operation
Conliguiation gets unueiway at ioutei Yeast with the uelinition ol a geneiateu static
ioute. Recall that a geneiateu ioute uilleis liom an aggiegateu ioute in that the loimei
has a loiwaiuing next hop ueteimineu Ly the most pieleiieu contiiLuting ioute. In
contiast, an aggiegate ioute can only point to a uiscaiu oi ieject next hop. The geneiateu
ioute is ieuistiiLuteu into OSPF to pioviue connectivity to Inteinet uestinations loi
Beei-Co`s inteinal iouteis.
The OSPF conliguiation loi aiea 0 is pieexisting, anu all iouteis have a similai
conliguiationthe OSPF stanza at Porter is uisplayeu, along with its aujacency status:
lab@Porter> show configuration protocols ospf
area 0.0.0.0 {
interface ge-0/0/1.1331;
interface ge-0/0/1.2332;
interface t1-2/0/2.0;
}
lab@Porter> show ospf neighbor
Address Interface State ID Pri Dead
10.20.131.2 ge-0/0/1.1331 Full 10.20.128.4 128 33
10.10.8.2 ge-0/0/1.2332 Full 10.30.1.1 128 36
10.10.10.1 t1-2/0/2.0 Full 10.10.12.3 128 32
The single-aiea OSPF conliguiation at Porter matches the topology in Figuie 7-S, anu
the ioutei has all thiee expecteu OSPF aujacencies: one each to iouteis Stout, Yeast,
anu Bock. The ioutes Leing leaineu Ly OSPF aie uisplayeu anu pipeu thiough the
commanu-line inteilace`s (CLI`s) match lunction to show only those ioutes with a /32
netwoik mask. These ioutes iepiesent the loopLack auuiesses assigneu to each ioutei
(they aie the only /32 IP auuiesses assigneu), anu theieloie pioviue a guick sanity check
ol inteinal ieachaLility:
lab@Porter> show route protocol ospf | match /32
10.10.12.3/32 *[OSPF/10] 00:05:54, metric 3
10.20.128.3/32 *[OSPF/10] 00:05:54, metric 2
10.20.128.4/32 *[OSPF/10] 00:23:46, metric 1
10.30.1.1/32 *[OSPF/10] 00:22:18, metric 1
224.0.0.5/32 *[OSPF/10] 01:03:03, metric 1
The output conliims a ioute to the loopLack auuiesses ol Stout, Yeast, PBR, anu Bock.
The metiic values associateu with each ioute seem ieasonaLle in this topology. The
270 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
uelault scaling lactoi ol 100 MLps assigns a GigaLit Etheinet inteilace a cost ol 1, which
iesults in avoiuance ol the T1 link Letween Bock anu Porter. Porter theieloie sees an
OSPF cost ol 3 to ieach the loopLack inteilace ol Bock via Stout anu PBR. Next, the ioute
to Biewei Inc. is uisplayeu:
lab@Porter> show route 192.168.34.0
lab@Porter>
The output conliims that Porter cannot ioute to the 192.16S.3+/2+ ioute associateu
with Biewei Inc., which also conliims the lack ol a uelault ioute in aiea 0. As a linal
veiilication step, ieachaLility is conliimeu to the EBGP peeiing auuiesses on Loth the
piimaiy anu seconuaiy links Letween Botnet anu Yeast:
lab@Yeast> ping 84.10.113.1 count 1
PING 84.10.113.1 (84.10.113.1): 56 data bytes
64 bytes from 84.10.113.1: icmp_seq=0 ttl=64 time=26.887 ms
--- 84.10.113.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 26.887/26.887/26.887/0.000 ms
lab@Yeast> ping 84.10.109.7 count 1
PING 84.10.109.7 (84.10.109.7): 56 data bytes
64 bytes from 84.10.109.7: icmp_seq=0 ttl=64 time=12.255 ms
--- 84.10.109.7 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 12.255/12.255/12.255/0.000 ms
Configure Generated Route
Conliguie a geneiateu uelault ioute that uses policy to constiain the set ol contiiLuting
ioutes to the uiiect ioute associateu with the Lackup peeiing link to Botnet. The piemise
heie is that in noimal opeiation, Yeast will have two uelault ioutes: one leaineu thiough
BGP that points to the piimaiy Botnet peeiing, anu a seconu, geneiateu uelault ioute
pointing to the seconuaiy peeiing. Route pieleience aujustments aie maue to ensuie
that the BGP ioute will Le pieleiieu when availaLle. Loss ol the BGP session iesults in
the geneiateu static ioute Lecoming active. Eithei way, an OSPF expoit policy ieuis-
tiiLutes the uelault ioute, Le it leaineu oi geneiateu, into OSPF. The uelault ioute is
withuiawn only in the event that Yeast loses its BGP session at the same time as its
t1-2/0/2 inteilace goes uown, in which case the uecision to loiego guaianteeu uiveise
iouting loi the piimaiy anu seconuaiy ciicuits may come into guestion.
The conliguiation staits with the static ioute anu, at this stage, is guite stiaightloiwaiu.
By Leginning with the geneiateu uelault, you have a chance to test lailovei to seconuaiy
link Lehavioi Leloie the piimaiy link is Liought up. It`s always a goou iuea to peiiou-
ically conliim opeiation ol Lackup links uuiing a maintenance winuow, iathei than
waiting until youi piimaiy lails. The geneiateu ioute poition ol Yeast`s conliguiation
is uisplayeu:
BGP Deployment: Asymmetric Load Balancing | 271
[edit]
lab@Yeast# show routing-options generate
route 0.0.0.0/0 policy gen_default;
[edit]
lab@Yeast# show policy-options policy-statement gen_default
term 1 {
from {
protocol direct;
route-filter 84.10.113.0/31 exact;
}
then accept;
}
term 2 {
then reject;
}
The conliguiation iesults in the geneiation ol a 0/0 ioute that, when matcheu, will
loiwaiu ovei the next hop assigneu to the pieleiieu contiiLuting ioute. Heie, the set
ol possiLle contiiLutois is constiaineu Ly the policy nameu gen_default, which matches
only on the S+.10.113.0/31 ioute assigneu to the t1-2/0/2 inteilace. The policy`s sec-
onu teim guaiantees that no othei ioute can contiiLute Ly iejecting all iemaining ioutes
anu souices. Opeiation ol the geneiateu ioute is veiilieu:
[edit]
lab@Yeast# run show route protocol aggregate detail
inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
0.0.0.0/0 (1 entry, 1 announced)
*Aggregate Preference: 130
Next-hop reference count: 2
Next hop: via t1-2/0/2.0, selected
State: <Active Int Ext>
Age: 10:07
Task: Aggregate
Announcement bits (1): 0-KRT
AS path: I
Flags: Generate Depth: 0 Active
Contributing Routes (1):
84.10.113.0/31 proto Direct
The highlighteu poitions ol the output conliim that all is woiking to plan with the
geneiateu ioute. A uelault ioute is piesent, it is cuiiently active (theie is no BGP leaineu
veision yet), anu tiallic matching this ioute will Le uiiecteu out the t1-2/0/2 inteilace.
Fuithei, the expecteu numLei ol contiiLuting ioutes, 1, is shown, anu that ioute
matches the uiiect ioute loi the seconuaiy peeiing. Note that the ioute is consiueieu
to Le ol the type aggregate, anu that the pieleience loi this ioute is 130. Thinking aheau,
you`ll iecall that this ioute ultimately neeus to Le less pieleiieu than any BGP leaineu
veision, anu that the uelault pieleience loi BGP is 170. The geneiateu ioute`s pieleience
is set to Le just highei than BGP`s, so it will Le less pieleiieu when a BGP leaineu veision
Lecomes availaLle:
[edit]
lab@Yeast# set routing-options generate route 0.0.0.0/0 preference 175
272 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
The T1 inteilace is Liielly Liought uown, anu the show route commanu is iepeateu to
valiuate that the geneiateu ioute`s late tiacks that ol the t1-2/0/2 inteilace:
[edit]
lab@Yeast# set interfaces t1-2/0/2 disable
[edit]
lab@Yeast# commit
commit complete
[edit]
lab@Yeast# run show route protocol aggregate detail
inet.0: 16 destinations, 16 routes (15 active, 0 holddown, 1 hidden)
The commanu output uoes not uisplay any active aggiegate ioutes. The highlight calls
out that one ioute, ol an as-yet-unknown type, is hiuuen, howevei. To uisplay a hiuuen
ioute, auu the hidden switch. Heie, the uisplay conliims that the hiuuen ioute is, in
lact, the geneiateu uelaultthe ioute is now hiuuen Lecause ol a lack ol contiiLutois:
[edit]
lab@Yeast# run show route protocol aggregate detail hidden
inet.0: 16 destinations, 16 routes (15 active, 0 holddown, 1 hidden)
0.0.0.0/0 (1 entry, 0 announced)
Aggregate
Next hop type: Reject
Next-hop reference count: 3
State: <Hidden Int Ext>
Age: 1:19:04
Task: Aggregate
AS path: I
Flags: Generate Depth: 0 Inactive
The change is iolleu Lack anu committeu (not shown) at Yeast to ensuie that the
t1-2/0/2 inteilace is no longei uisaLleu. Next, a policy is wiitten to ieuistiiLute a uelault
ioute liom any piotocol souice. The ospf_default policy is applieu to the OSPF pio-
tocol as export:
[edit]
lab@Yeast# show policy-options policy-statement ospf_default
term 1 {
from {
route-filter 0.0.0.0/0 exact;
}
then accept;
}
[edit]
lab@Yeast# show protocols ospf export
export ospf_default;
The ospf_default policy is wiitten to Le piotocol-agnostic, Lecause the goal is to have
an active uelault ioute stemming liom cithcr BGP oi the aggiegate piotocol souices. Il
you pielei a tight ship, you coulu always auu a logical OR match conuition loi the two
BGP Deployment: Asymmetric Load Balancing | 273
piotocols, aggregate anu bgp. Altei committing the changes, an OSPF leaineu uelault
ioute is conliimeu in aiea 0 at ioutei PBR:
lab@PBR> show route 192.168.34.0
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 00:03:04, metric 0, tag 0
> to 10.20.129.1 via ge-0/0/0.3141
Gieat! As planneu, the longest match loi the 192.16S.3+/2+ ioute to Biewei Inc. at
PBR is now the OSPF leaineu uelault ioute. A tiaceioute veiilies connectivity to Botnet
customeis liom within Beei-Co. The tiaceioute has an auspicious Leginning, Lut it
soon uegiaues to timeouts:
lab@PBR> traceroute 192.168.34.1 no-resolve
traceroute to 192.168.34.1 (192.168.34.1), 30 hops max, 40 byte
packets
1 10.20.129.1 14.345 ms 9.916 ms 8.099 ms
2 10.20.131.1 11.864 ms 30.002 ms 20.016 ms
3 10.10.8.2 9.901 ms 29.991 ms 9.984 ms
4 * * *
5 *^C
lab@PBR>
The tiaceioute iesult shows the expecteu iouting path thiough Beei-Co`s intianet
liom PBR to Stout, anu then to Porteranu it makes it as lai as the 10.10.S.2 auuiess
assigneu to Yeast`s ge-0/0/1.2332 inteilace. This makes it seem like theie`s a pioLlem
on the PorterYeast link, except that pievious oLseivations showeu that the OSPF
aujacency was staLle. To naiiow uown the issue, a ping is geneiateu liom Yeast, Lut
this time it is souiceu liom the ioutei`s loopLack inteilace. This is an impoitant point
Lecause it will ieveal any potential iouting issues that may impact Botnet`s aLility to
ioute Lack into Beei-Co`s 10/S auuiess Llock:
lab@Yeast> ping 84.10.113.1 count 1
PING 84.10.113.1 (84.10.113.1): 56 data bytes
64 bytes from 84.10.113.1: icmp_seq=0 ttl=64 time=16.750 ms
--- 84.10.113.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 16.750/16.750/16.750/0.000 ms
lab@Yeast> ping 84.10.113.1 count 1 source 10.30.1.1
PING 84.10.113.1 (84.10.113.1): 56 data bytes
--- 84.10.113.1 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
Euieka! The uelault ping, as souiceu liom the shaieu uiiect connection, succeeus,
wheieas the loopLack souiceu ping lails. This uemonstiates a iouting pioLlem within
Botnet. It is not uncommon to encountei uilliculties such as this. Altei a lew phone
calls, you aie assuieu that eveiything is (now) in oiuei with the newly installeu static
274 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
ioute Lack to youi netwoik; it seems that conlusion stemmeu liom Botnet`s misun-
ueistanuing that BGP woulu Le useu to auveitise an aggiegate loi youi netwoik, anu
it shallonce it`s up anu iunning, that is. The tiaceioute is iepeateu, anu its successlul
completion inuicates that you aie ieauy to move on to BGP conliguiation:
lab@PBR> traceroute 192.168.34.1 no-resolve
traceroute to 192.168.34.1 (192.168.34.1), 30 hops max, 40 byte
packets
1 10.20.129.1 14.807 ms 9.827 ms 9.949 ms
2 10.20.131.1 19.967 ms 40.010 ms 13.579 ms
3 10.10.8.2 16.439 ms 10.131 ms 9.777 ms
4 84.10.113.1 39.727 ms !N 40.154 ms !N 17.789 ms !N
Recall that in this laL, you expect an ICMP unieachaLle eiioi message loi the linal hop
Lecause a static ioute pointing to a ieject next hop is useu within Botnet to simulate
the Biewei Inc. netwoik.
Configure Initial BGP Peering
Vith the Lackup link anu its associateu static iouting/geneiateu ioute conliimeu, you`ll
move on to the task ol conliguiing BGP. In auuition to the BGP session, you also neeu
to cieate an aggiegate ioute iepiesenting Beei-Co`s inteinal ieachaLility, along with
the expoit policy neeueu to auveitise it into EBGP. The aggiegate ioute is ciitical Le-
cause it enaLles iemote ASs to ioute towaiu Beei-Co. An impoit policy that iejects all
Lut a Botnet-oiiginateu uelault ioute is also neeueu. In most cases, you will want to
wiite anu apply policy Leloie the BGP session is actually activateu to guaiu against
unwanteu siue ellects that stem liom ieceiving oi auveitising unuesiieu ioutes, oi woise
yet, Leloie hitting a platloim scaling limit that leaus to an unpieuictaLle opeiation.
Ve must emphasize that enteipiise iouting platloims aie not always
capaLle ol hanuling a lull BGP taLle, especially when the same platloim
is also taxeu with value-auueu seivices such as statelul liiewalls, Net-
woik Auuiess Tianslation (NAT), viitual piivate netwoik (VPN) tun-
nels, anu so on. Exceeuing platloim scaling limits can iesult in contiol
plane instaLility anu possiLle loiwaiuing plane impact. Caie shoulu Le
exeiciseu to lactoi the ellects ol ioute taLle size, the numLei ol iouting
peeis, the impact ol enaLleu seivices, anu inteinal iesouice consump-
tion loi managing inteilaces (IFDs/IFLs) anu Auuiess Resolution Pio-
tocol (ARP) taLles Leloie auuing a new piotocol oi seivice to any
piouuction ioutei. Vhen in uouLt, simulation testing shoulu Le pei-
loimeu. Vhen simulation is not possiLle, you shoulu closely monitoi
uevice opeiation anu iesouice usage as new peeis anu seivices aie acti-
vateu to pievent opeiational pioLlems causeu Ly iesouice exhaustion.
As ol this wiiting, ]unipei Netwoiks iecommenus that ]-seiies iouteis expecteu to
hanule a lull BGP ioute taLle, in conjunction with seivices Leing enaLleu, have 1 GB
ol memoiy. The ]2320 platloim seiving the iole ol Yeast in this netwoik is eguippeu
BGP Deployment: Asymmetric Load Balancing | 275
with the lull complement ol DRAM. This setup anu the limiteu numLei ol ioutes in
oui netwoik alloiu the liLeity ol auuing the impoit policy ajtcr the EBGP session is
estaLlisheu. This methou is auopteu heie to help uemonstiate the ellects ol impoit
policy using a Leloie-anu-altei appioach.
Ve`ve alieauy stateu this, Lut we will say it one moie time. It is highly iecommenueu
that you wiite anu apply both youi expoit anu impoit policies bcjorc you attempt to
estaLlish any EBGP peeiings. Failing to uo this coulu iesult in ioutei meltuown uue to
excessive BGP taLle size oi the potential loi unwanteu iouting exchange/loiwaiuing
Lehavioi. The ]unos soltwaie canuiuate conliguiation anu commit lunctionality makes
it easy to Luilu anu apply a policy Leloie any ol the changes take ellect at commit time.
The BGP conliguiation Legins at Yeast with conliguiation ol the local ioutei`s ASN.
The ASN is conliguieu unuei the [edit routing-options] hieiaichy, iathei than within
the BGP stanza, wheie you may expect to linu it when you aie lamiliai with the IOS
way ol conliguiing BGP:
[edit]
lab@Yeast# edit routing-options
[edit routing-options]
lab@Yeast# set autonomous-system 1282
You next ueline a BGP gioup to house the S+.10.109.7 neighLoi associateu with the
Botnet peeiing. At a minimum, you must cieate the gioup, ueclaie the gioup type as
inteinal oi exteinal, specily the peei, anu in the case ol an exteinal gioup, specily the
ASN associateu with the peei. The iesulting BGP stanza is uisplayeu along with the
set commanus that cieateu it:
[edit protocols bgp]
lab@Yeast# show
group as_34 {
type external;
peer-as 34;
neighbor 84.10.109.7;
}
[edit protocols bgp]
lab@Yeast# show | display set
set protocols bgp group as_34 type external
set protocols bgp group as_34 peer-as 34
set protocols bgp group as_34 neighbor 84.10.109.7
To Lettei evaluate the impact ol auuing EBGP to Yeast, the cuiient memoiy anu CPU
usage is examineu Leloie the changes aie committeu:
[edit protocols bgp]
lab@Yeast# run show task memory summary
Memory InUse: 6439 kB [1%] Max: 6762 kB [1%]
[edit protocols bgp]
lab@Yeast# run show chassis routing-engine
Routing Engine status:
276 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
Temperature 22 degrees C / 71 degrees F
CPU temperature 24 degrees C / 75 degrees F
Total memory 1024 MB Max 584 MB used ( 57 percent)
Control plane memory 594 MB Max 279 MB used ( 47 percent)
Data plane memory 430 MB Max 310 MB used ( 72 percent)
CPU utilization:
User 0 percent
Real-time threads 17 percent
Kernel 0 percent
Idle 83 percent
Model RE-J2320-2000
Serial ID AABY9625
Start time 2010-12-20 21:31:28 UTC
Uptime 21 days, 5 hours, 1 minute, 56 seconds
Last reboot reason 0x1:power cycle/failure
Load averages: 1 minute 5 minute 15 minute
1.30 0.46 0.17
The output liom the show task memory commanu uisplays memoiy usage liom the
peispective ol rpd, the iouting uaemon. In this case, it`s iathei low, inuicating that
rpd is having an easy time. The show chassis routing-engine commanu output shows
that the Routing Engine`s (RE`s) CPU is laigely iule.
Vith the pie-BGP iesouice snapshot in place, the new BGP conliguiation is committeu
at Yeast. Altei a lew moments, BGP session status is ueteimineu with a show bgp
summary commanu:
[edit protocols bgp]
lab@Yeast# commit and-quit
commit complete
Exiting configuration mode
lab@Yeast> show bgp summary
Groups: 1 Peers: 1 Down peers: 1
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Damped...
84.10.109.7 34 0 0 0 0 11 Active
The commanu output shows that Yeast is actively tiying to estaLlish its BGP session
to peei S+.10.109.7. This is a goou sign, Lut it`s not as goou as an estaLlisheu session.
A status ol id|c, loi example, inuicates that the ioutei cannot even Legin to initiate a
session, likely Lecause ol no ioute to the peeiing auuiess. BGP will ietiy its connection
eveiy 30 seconus oi so, making patience a viitue heie. ALout a minute latei, the status
is again uisplayeu:
lab@Yeast> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 434 434 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|# Active/
Received/Damped...
BGP Deployment: Asymmetric Load Balancing | 277
84.10.109.7 34 285 7 0 0 2:25
801/801/0 0/0/0
The output conliims BGP session estaLlishmentthe highlighteu uisplay inuicates
that a total ol S01 ioutes have Leen leaineu liom the S+.10.109.7 peeiing, anu that all
ol the ieceiveu ioutes have Leen selecteu as active. It also notes the total numLei ol
ioutes leaineu liom this peei anu the numLei ol ioutes cuiiently uampeu, iespectively.
In this example, Botnet has auveitiseu a total ol S01 ioutes, all ol which aie cuiiently
active at Yeast.
As ol this wiiting, a lull BGP leeu is appioximately 350,000 ioutes. OL-
viously, the BGP taLle useu in this laL is a Lit smallei. The goal heie is
to have enough ioutes to simulate a ieal BGP expeiience, without the
hassle ol oLtaining a live leeu.
You can view uetails loi the peeiing session with a show bgp neighbor commanu. The
uisplay incluues any negotiateu options, session holu time, suppoiteu NLRI gueueu
messages, anu so on:
lab@Yeast> show bgp neighbor
Peer: 84.10.109.7+179 AS 34 Local: 84.10.109.8+2333 AS 1282
Type: External State: Established Flags: <ImportEval Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference PeerAS Refresh>
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 84.10.109.1 Local ID: 10.30.1.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
Local Interface: ge-0/0/0.3233
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 801
Received prefixes: 801
Suppressed due to damping: 0
Advertised prefixes: 0
Last traffic (seconds): Received 8 Sent 8 Checked 8
Input messages: Total 296 Updates 280 Refreshes 0 Octets 15175
Output messages: Total 18 Updates 0 Refreshes 0 Octets 368
Output Queue[0]: 0
Heie the output shows that the EBGP session to Botnet is in the estaLlisheu state, that
it suppoits IPv+ unicast NLRI, that the session has negotiateu the BGP ieliesh option,
anu that the holu time is 90 seconus, which leaus to a 30-seconu keepalive timei. The
ieliesh option allows a BGP speakei to ieguest that its peei iesenu pieviously auveitiseu
iouting inloimation. This is uselul when a change in impoit policy may iesult in
278 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
acceptance ol a ioute that was pieviously uenieu. Vithout ieliesh, the BGP session
woulu have to Le Lounceu to loice the peei to iesenu ioutes. Recall that BGP uses TCP
tianspoit, so theie is, in theoiy, no ieason loi a BGP speakei to evei ieauveitise iouting
inloimation that it has alieauy sent.
The ieceipt ol valiu BGP iouting is conliimeu Ly uisplaying BGP ioutes in the ioute
taLle:
lab@Yeast> show route protocol bgp detail
inet.0: 818 destinations, 819 routes (818 active, 0 holddown, 0 hidden)
0.0.0.0/0 (2 entries, 1 announced)
*BGP Preference: 170/-101
Next-hop reference count: 1602
Source: 84.10.109.7
Next hop: 84.10.109.7 via ge-0/0/0.3233, selected
State: <Active Ext>
Local AS: 1282 Peer AS: 34
Age: 2:26:23
Task: BGP_34.84.10.109.7+179
Announcement bits (2): 0-KRT 3-OSPFv2
AS path: 34 I
Localpref: 100
Router ID: 84.10.109.1
129.1.0.0/16 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next-hop reference count: 1602
Source: 84.10.109.7
Next hop: 84.10.109.7 via ge-0/0/0.3233, selected
State: <Active Ext>
Local AS: 1282 Peer AS: 34
Age: 9:04
Task: BGP_34.84.10.109.7+179
Announcement bits (1): 0-KRT
AS path: 34 11537 3112 3112 I
Localpref: 100
Router ID: 84.10.109.1
. . .
The uisplay conliims many active BGP ioutes at Yeast. The highlights call out key ioute
attiiLutes such as the AS path, the oiigin ol the ioute, the loiwaiuing next hop, anu
local/iemote ASNs. This example shows that a uelault ioute is auveitiseu, anu the AS
path, Ly viitue ol the single entiy loi 3+, conliims that this ioute oiiginates within
AS 3+. In contiast, the ioute to 129.1/16 inuicates an oiigin in AS 3112, anu suLseguent
tiansveisal ol ASs 11537 anu 3+ (Botnet), Leloie aiiiving at Beei-Co. Note that these
ioutes have an assuncd local pieleience ol 100 as pei BGP stanuaius. A local pieleience
value attiiLute is not attacheu to any ol these ioutes Lecause this attiiLute is not sup-
poiteu on EBGP links.
The announcement Lits loi the 0/0 BGP ioute inuicate that it is Leing ieuistiiLuteu into
OSPF. Because only active ioutes aie suLject to expoit policy, this implies that the BGP
BGP Deployment: Asymmetric Load Balancing | 279
veision ol the uelault ioute must Le pieleiieu ovei the geneiateu one. This is easily
conliimeu:
lab@Yeast> show route 0.0.0.0/0
inet.0: 818 destinations, 801 routes (818 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 00:26:28, localpref 100
AS path: 34 I
> to 84.10.109.7 via ge-0/0/0.3233
[Aggregate/175] 16:56:59
> via t1-2/0/2.0
The uisplay shows that the BGP uelault is active with a pieleience ol 170, anu the
highlights show that tiallic matching this uelault ioute will Le loiwaiueu ovei the high-
speeu BGP peeiing link. Shoulu the BGP session mallunction, Yeast will lose the BGP
veision ol the uelault anu lall Lack to the geneiateu copy, which in tuin loiwaius tiallic
ovei the seconuaiy T1 link.
To conliim what ioutes aie Leing ieceiveu, oi sent, to a specilic BGP peei, use the show
route-advertising protocol oi show route receive-protocol commanu:
lab@Yeast> show route receive-protocol bgp 84.10.109.7
inet.0: 818 destinations, 801 routes (818 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 84.10.109.7 34 I
* 129.1.0.0/16 84.10.109.7 34 11537 3112 3112 I
* 129.2.0.0/16 84.10.109.7 34 11537 10886 27 I
* 129.7.0.0/16 84.10.109.7 34 11537 4557 7276 I
* 129.7.0.0/17 84.10.109.7 34 11537 4557 7276 I
* 129.7.128.0/19 84.10.109.7 34 11537 4557 7276 I
* 129.7.160.0/19 84.10.109.7 34 11537 4557 7276 I
* 129.7.192.0/19 84.10.109.7 34 11537 4557 7276 I
* 129.7.224.0/19 84.10.109.7 34 11537 4557 7276 I
* 129.8.0.0/16 84.10.109.7 34 11537 2153 2152
11422 2150 I
---(more)---[abort]
lab@Yeast> show route advertising-protocol bgp 84.10.109.7
lab@Yeast>
The show route receive-protocol bgp 84.10.109.7 commanu conliims the ieceipt ol
pielixes liom neighLoi S+.10.109.7. You can auu the detail oi extensive switch to see
auuitional inloimation. In contiast, the show route advertising-protocol bgp
84.10.109.7 commanu conliims that no iouting inloimation is Leing sent Lack to Bot-
net. This is expecteu, given that iecent ]unos soltwaie ieleases no longei echo ieceiveu
BGP ioutes Lack to theii souice, anu Lecause the uelault BGP expoit policy is to au-
veitise active BGP ioutes. Heie, all the active BGP ioutes weie leaineu liom neighLoi
S+.10.109.7; hence, theie is nothing loi Yeast to auveitise Lack.
280 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
Reaueis lamiliai with the IOS uisplay loimat loi BGP ioutes may appieciate the
terse switch:
lab@Yeast> show route protocol bgp terse
inet.0: 818 destinations, 801 routes (818 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 0.0.0.0/0 B 170 100 >84.10.109.7 34 I
* 129.1.0.0/16 B 170 100 >84.10.109.7 34 11537 3112 3112 I
* 129.2.0.0/16 B 170 100 >84.10.109.7 34 11537 10886 27 I
* 129.7.0.0/16 B 170 100 >84.10.109.7 34 11537 4557 7276 I
* 129.7.0.0/17 B 170 100 >84.10.109.7 34 11537 4557 7276 I
* 129.7.128.0/19 B 170 100 >84.10.109.7 34 11537 4557 7276 I
* 129.7.160.0/19 B 170 100 >84.10.109.7 34 11537 4557 7276 I
* 129.7.192.0/19 B 170 100 >84.10.109.7 34 11537 4557 7276 I
* 129.7.224.0/19 B 170 100 >84.10.109.7 34 11537 4557 7276 I
* 129.8.0.0/16 B 170 100 >84.10.109.7 34 11537 2153 2152 11422
2150 I
* 129.10.0.0/16 B 170 100 >84.10.109.7 34 11537 10578 156 I
* 129.11.0.0/16 B 170 100 >84.10.109.7 34 11537 20965 786 I
. . .
In the pieceuing uisplay, the local pieleience is shown unuei the Metiic 1 column.
Beloie moving on, you gauge the ellects ol iunning BGP Ly again analyzing iesouice
utilization at Yeast:
lab@Yeast> show task memory summary
Memory InUse: 6517 kB [1%] Max: 6762 kB [1%]
lab@Yeast> show chassis routing-engine
Routing Engine status:
Temperature 31 degrees C / 87 degrees F
CPU temperature 32 degrees C / 89 degrees F
Total memory 1024 MB Max 584 MB used ( 57 percent)
Control plane memory 594 MB Max 279 MB used ( 47 percent)
Data plane memory 430 MB Max 310 MB used ( 72 percent)
CPU utilization:
User 0 percent
Real-time threads 18 percent
Kernel 0 percent
Idle 82 percent
Model RE-J2320-2000
Serial ID AABY9625
Start time 2010-12-20 21:31:28 UTC
Uptime 21 days, 5 hours, 21 minutes, 16 seconds
Last reboot reason 0x1:power cycle/failure
Load averages: 1 minute 5 minute 15 minute
0.10 0.15 0.02
The output conliims veiy little change to iesouice consumption. Howevei, we must
stiess that you aie uealing with a veiy small numLei ol peeis (1) anu a veiy limiteu set
ol ioutes (S00 oi so), anu that these ioutes aie staLle, iesulting in veiy little ongoing
BGP piocess chuin.
BGP Deployment: Asymmetric Load Balancing | 281
Configure Initial BGP Policy
The initial BGP peeiing session is conliimeu opeiational. To complete this task, you
now cieate anu apply Loth BGP impoit anu expoit policy. The loimei is to ieject all
ieceiveu BGP ioutes except a uelault ioute that oiiginates in AS 3+. The lattei neeus to
auveitise a single 10/S aggiegate to iepiesent the inteinal connectivity ol Beei-Co. An
impoit policy is cieateu anu uisplayeu at Yeast:
[edit]
lab@Yeast# show policy-options policy-statement as_34_import
term 1 {
from {
protocol bgp;
as-path 34_originate;
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term 2 {
from protocol bgp;
then reject;
}
[edit]
lab@Yeast# show policy-options as-path 34_originate
"^34$";
[edit]
lab@Yeast# show protocols bgp group as_34 import
import as_34_import;
The as_34_import policy matches on a specilic ioute (0/0) anu ioute souice (BGP), anu
loices the associateu AS path to match the AS iegulai expiessions uelineu in
34_originate. The AS path iegulai expiession lunctions to guaiantee that only a uelault
ioute that oiiginates in AS 3+ will Le accepteuall ioutes oiiginating within AS 3+ will
have an AS path list that staits anu enus with 3+; the associateu iegex uses the ^ anu
$, iespectively, to loice AS 3+ to Le the liist anu last AS numLei in the list. The
as_34_import policy is applieu to the as_34 BGP gioup at impoit, anu the iesults aie
conliimeu:
[edit]
lab@Yeast: run show route protocol bgp
inet.0: 818 destinations, 819 routes (18 active, 0 holddown, 800 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 02:34:36, localpref 100
AS path: 34 I
> to 84.10.109.7 via ge-0/0/0.3233
The output conliims that only the uelault ioute is accepteu anu installeu into the ioute
taLle, iesulting in some S00 ioutes Leing hiuuen.
282 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
Geneially speaking, the output ol the show route receive-protocol
commanu uisplays iouting inloimation as ieceiveu, Leloie impoit pol-
icy is applieu. The exception to this iule is ioute lilteiing, which occuis
bcjorc the show route receive-protocol commanu output is compileu.
This means that il youi impoit policy is set to iemove a given commun-
ity, you can expect to see the community (that is to Le iemoveu) in the
show route receive-protocol output, Lut not when the ioute is installeu
into the ioute taLle, Lecause youi impoit policy will have taken ellect
anu will have iemoveu the specilieu community. In contiast, il youi
impoit policy uses route-filter syntax to ieject ioutes, these ioutes will
not Le oLseiveu in eithei the ioute taLle oi the output ol a show route
receive-protocol commanu. This conuition is uemonstiateu heie,
wheie only the 0/0 uelault that is accepteu Ly impoit policy ioute lil-
teiing is uisplayeu:
lab@Yeast> show route receive-protocol bgp 84.10.109.7
inet.0: 818 destinations, 819 routes (18 active, 0 holddown, 800 hidden)
Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 84.10.109.7 34 I
Auu the hidden keywoiu to uisplay ieceiveu ioutes that aie hiuuen, pei-
haps uue to ioute lilteiing actions.
Youi expoit policy ieguiies that you ueline a 10/S aggiegate, anu then auveitise this
aggiegate into BGP. At this time, it`s assumeu that Botnet is iouting Lack into youi AS
using its static ioute that points to the slow-speeu T1 inteilace, making this a ciitical
step loi piopei opeiation. In theoiy, it has conliguieu its netwoik to pielei a BGP
leaineu veision ol the 10/S ioute, which iesults in use ol the high-speeu link loi inLounu
tiallic once you auveitise the ioute thiough BGP. Heie aie the aggiegate ioute uelinition
anu BGP expoit policy:
[edit]
lab@Yeast# show routing-options aggregate
route 10.0.0.0/8;
[edit]
lab@Yeast# show policy-options policy-statement as_34_export
term 1 {
from {
protocol aggregate;
route-filter 10.0.0.0/8 exact;
}
then accept;
}
[edit]
lab@Yeast# show protocols bgp group as_34 export
export as_34_export;
Altei committing the change, the aggiegate ioute is conliimeu active anu auveitiseu to
Botnet via EBGP:
BGP Deployment: Asymmetric Load Balancing | 283
lab@Yeast> show route protocol aggregate
inet.0: 801 destinations, 451 routes (18 active, 0 holddown, 432 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 [Aggregate/175] 17:57:54
> via t1-2/0/2.0
10.0.0.0/8 *[Aggregate/130] 00:00:13
Reject
lab@Yeast> show route advertising-protocol bgp 84.10.109.7
inet.0: 801 destinations, 451 routes (18 active, 0 holddown, 432 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/8 Self I
The 10/S aggiegate ioute is active, which is goou given that only active ioutes can Le
ieuistiiLuteu thiough policy. Note that unlike the geneiateu ioute, the aggiegate ioute
has a nonloiwaiuing next hop, which happens to Le the uelault ieject-style next hop
in this case. Tiallic iouteu into Beei-Co shoulu noimally match a moie specilic ioute
(OSPF oi uiiect) anu Le loiwaiueu towaiu that uestination. Il not, the tiallic is shunteu
to ieject, anu an ICMP eiioi message is geneiateu iepoiting an unieachaLle uestination.
The show route advertising-protocol commanu conliims that a single ioute, the 10/S
aggiegate, is auveitiseu to Botnet.
Foi linal veiilication, the pievious tiaceioute is iepeateu at PBR:
lab@PBR> traceroute 192.168.34.1 no-resolve
traceroute to 192.168.34.1 (192.168.34.1), 30 hops max, 40 byte packets
1 10.20.129.1 53.267 ms 13.506 ms 10.634 ms
2 10.20.131.1 9.955 ms 9.985 ms 9.996 ms
3 10.10.8.2 9.977 ms 10.042 ms 10.034 ms
4 84.10.109.7 15.349 ms !N 24.503 ms !N 19.968 ms !N
The tiaceioute again succeeus, Lut this time the linal hop is S+.10.109.7; this conliims
that the high-speeu piimaiy inteilace is now useu to loiwaiu tiallic into AS 3+. This
completes the initial BGP peeiing scenaiio.
Use BGP for Asymmetric Load Balancing
Vhile congiatulating you on the line woik, the CIO ol Beei-Co iespectlully suggests
that you linu a way to use the seconuaiy link also. Altei all, 1.5++ MLps is nothing to
sneeze at, anu paying loi a Lackup ciicuit that will nevei see any use except uuiing a
piimaiy outage can Le painlul.
The most uiiect solution to this pioLlem is to Liing up a seconu EBGP session to Botnet
anu simply enaLle BGP multipath. The multipath option iemoves the tieLieakeis liom
the active ioute uecision piocess, theieLy allowing otheiwise egual-cost BGP ioutes
leaineu liom multiple souices to Le installeu into the loiwaiuing taLle. Once multiple
next hops aie installeu in the loiwaiuing taLle, a specilic loiwaiuing next hop is selecteu
Ly the uelault ]unos soltwaie pei-pielix loau-Lalancing algoiithm. This piocess hashes
284 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
against a packet`s souice anu uestination auuiesses to ueteiministically map the pielix
paiing onto one ol the availaLle next hops. Pei-pielix mapping woiks Lest when the
hash lunction is piesenteu with a laige numLei ol pielixes, such as might occui on an
Inteinet peeiing exchange, anu it seives to pievent packet ieoiueiing among paiis ol
communicating noues.
An enteipiise netwoik will noimally want to altei the uelault Lehavioi to evoke a pei-
packet loau-Lalancing algoiithm. Pcr-pac|ct is guoteu heie Lecause its use is a mis-
nomei that stems liom the histoiic Lehavioi ol the oiiginal Inteinet Piocessoi ASIC. In
ieality, cuiient ]unipei Netwoiks iouteis suppoit pei-pielix (uelault) anu pcr-j|ow loau
Lalancing. The lattei involves hashing against vaiious L3 anu L+ heaueis, incluuing
poitions ol the souice auuiess, uestination auuiess, tianspoit piotocol, incoming in-
teilace, anu application poits. The ellect is that now inuiviuual j|ows aie hasheu to a
specilic next hop, iesulting in a moie even uistiiLution acioss availaLle next hops,
especially when iouting Letween lewei souice anu uestination paiis. Vith pei-packet
loau Lalancing, packets compiising a communication stieam Letween two enupoints
may Le ieseguenceu, Lut packets within inuiviuual llows maintain coiiect seguencing.
Vhethei you opt loi pei-pielix oi pei-packet loau Lalancing, the extieme asymmetiy
ol the Botnet access links piesents a technical challenge. Eithei way, the pielixes/llows
that aie mappeu to the T1 link will exhiLit uegiaueu peiloimance when compaieu to
those llows that map to the GE access link, anu woise yet, with heavy tiallic loaus, any
attempt at 50/50 loau Lalancing is likely to iesult in total satuiation ol the T1 link anu
session uisiuption stemming liom packet loss.
Foitunately, the ]unipei BGP implementation suppoits the notion ol a Lanuwiuth
community. This extenueu community encoues the Lanuwiuth ol a given next hop,
anu when comLineu with multipath, the loau-Lalancing algoiithm will uistiiLute llows
acioss the set ol next hops piopoitional to theii ielative Lanuwiuths. Put anothei way,
il you have a 10 MLps anu a 1 MLps next hop, on aveiage nine llows will map to the
high-speeu next hop loi eveiy one that uses the low speeu.
As ol this wiiting, use ol BGP Lanuwiuth community is suppoiteu only
with pei-packet loau Lalancing.
The cuiient conliguiation task is uiviueu into two paits:
Conliguie a seconu EBGP peeiing session, enaLle multipath, anu ueline an impoit
policy to tag ioutes with a Lanuwiuth community that iellects link speeu.
EnaLle pei-packet (ieally pei-llow) loau Lalancing loi optimal uistiiLution ol
tiallic.
You stait with the uelinition ol the seconu EBGP peeiing session at Yeast. Though not
shown heie, the geneiateu uelault ioute is iemoveu liom the conliguiation Lecause it
BGP Deployment: Asymmetric Load Balancing | 285
is no longei neeueu. Recall that you now expect two uelault ioutes, Loth leaineu liom
BGP, with piopoitionate loau Lalancing when Loth ioutes aie active:
[edit]
lab@Yeast# show protocols bgp
group as_34 {
type external;
import as_34_import;
export as_34_export;
peer-as 34;
neighbor 84.10.109.7;
neighbor 84.10.113.1;
}
The new session shaies the same gioup-level impoit anu expoit policy, which iesults
in accepting only a uelault ioute anu the auveitisement ol only the 10/S aggiegate. Altei
a minute oi so, you conliim successlul estaLlishment ol the seconu Botnet peeiing
session:
[edit]
lab@Yeast# run show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 1602 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Damped...
84.10.109.7 34 824 329 0 0 2:42:55 1/801/0
0/0/0
84.10.113.1 34 462 3 0 0 6 0/801/ 0
0/0/0
The uisplay conliims estaLlishment ol the seconu peeiing session. Ol special inteiest
is the lact that S01 ioutes have Leen leaineu ovei each session, anu only one ol these
ioutes is active, loi only one ol the sessions. Recall that the goal heie is to ieceive an
active uelault ioute liom each peeiing. Foi auuitional uetails, we uisplay the uelault
ioute:
[edit]
lab@Yeast# run show route protocol bgp detail
inet.0: 818 destinations, 1619 routes (18 active, 0 holddown, 1600
hidden)
0.0.0.0/0 (2 entries, 1 announced)
*BGP Preference: 170/-101
Next-hop reference count: 802
Source: 84.10.109.7
Next hop: 84.10.109.7 via ge-0/0/0.3233, selected
State: <Active Ext>
Local AS: 1282 Peer AS: 34
Age: 2:46:39
Task: BGP_34.84.10.109.7+179
Announcement bits (2): 0-KRT 3-OSPFv2
AS path: 34 I
Localpref: 100
Router ID: 84.10.109.1
286 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
BGP Preference: 170/-101
Next-hop reference count: 801
Source: 84.10.113.1
Next hop: 84.10.113.1 via t1-2/0/2.0, selected
State: <NotBest Ext>
Inactive reason: Update source
Local AS: 1282 Peer AS: 34
Age: 3:50
Task: BGP_34.84.10.113.1+179
AS path: 34 I
Localpref: 100
Router ID: 84.10.109.1
The uisplay shows that each BGP peei is auveitising the 0/0 ioute, anu it conliims that
only one veision ol the ioute is active. This active ioute is leaineu thiough peei
S+.10.109.7, anu as such, the ioute shows a single loiwaiuing next hop ol
ge-0/0/0.3233. Theie is no hope ol any loau Lalancing until Loth ol the next hops loi
Loth BGP ioutes aie installeu into the loiwaiuing taLle. The pioLlem heie is calleu out
Ly the update source inactive ieason. Accoiuing to uocumentation, this inuicates that
a ioute was not selecteu Lecause ol chaiacteiistics associateu with the souice, which
means eithei the RID oi the BGP peeiing auuiess. These last two steps in the active
ioute selection piocess exist to Lieak ties, which is exactly what has happeneu heie.
Because Loth peeiing sessions teiminate on the same ioutei (Hops), the RID is the same,
anu theieloie the ioute leaineu liom the numeiically lowest peeiing auuiess is selecteu.
To uisaLle the tieLieaking iules anu allow use ol multiple otheiwise egual-cost BGP
ioutes, you must enaLle multipath:
[edit]
lab@Yeast# set protocols bgp group as_34 multipath
[edit]
lab@Yeast# commit
commit complete
The change is conliimeu Ly the piesence ol Loth the S+.10.109.7 and S+.10.113.1 BGP
next hops in the show route uisplay:
[edit]
lab@Yeast# run show route protocol bgp detail
inet.0: 818 destinations, 1619 routes (18 active, 0 holddown, 1600
hidden) 0.0.0.0/0 (2 entries, 1 announced)
*BGP Preference: 170/-101
Next-hop reference count: 1
Source: 84.10.109.7
Next hop: 84.10.109.7 via ge-0/0/0.3233, selected
Next hop: 84.10.113.1 via t1-2/0/2.0
State: <Active Ext>
Local AS: 1282 Peer AS: 34
Age: 2:54:43
Task: BGP_34.84.10.109.7+179
Announcement bits (2): 0-KRT 3-OSPFv2
AS path: 34 I
Localpref: 100
BGP Deployment: Asymmetric Load Balancing | 287
Router ID: 84.10.109.1
BGP Preference: 170/-101
Next-hop reference count: 801
Source: 84.10.113.1
Next hop: 84.10.113.1 via t1-2/0/2.0, selected
State: <NotBest Ext>
Inactive reason: Update source
Local AS: 1282 Peer AS: 34
Age: 11:54
Task: BGP_34.84.10.113.1+179
AS path: 34 I
Localpref: 100
Router ID: 84.10.109.1
The uisplay still shows that only one ioute is active, Lut without the tieLieakeis in
ellect, the next hops associateu with Loth ioutes have Leen installeu loi use, theieLy
enaLling loau Lalancing. Youi next goal is to aujust the as_34_import policy to tag ioutes
with a Lanuwiuth community, Laseu on the peeiing liom wheie they aie leaineu. You
stait Ly uelining the two extenueu Lanuwiuth communities. The loimat ol this com-
munity is bandwidth:asn:bandwidth_value, wheie the Lanuwiuth is enteieu in Lytes pei
seconu. The actual values enteieu aie not as impoitant as having the coiiect iatio Le-
cause it is the iatio that actually ueteimines the peicentage ol llows/pielixes mappeu
to each next hop:
[edit policy-options]
lab@Yeast# show community bw_slow
members bandwidth:1282:193000;
[edit policy-options]
lab@Yeast# show community bw_fast
members bandwidth:1282:12500000000;
The bw_slow anu bw_fast communities aie set to iellect the Lyte-pei-seconu iates ol a
T1 anu GigaLit Etheinet inteilace, iespectively. The iatio ol the two is appioxi-
mately .00015++, meaning that loi eveiy 100000 pielixes/llows, you expect to see
1.5 ol them mappeu to the T1. In the ]unipei implementation, the llow count is iounueu
up, giving us an expecteu spieau ol 2 llows mappeu to the T1 loi eveiy 9S000 mappeu
to the GigaLit Etheinet. The existing as_34_import policy is iewiitten, anu the mouilieu
policy is uisplayeu:
[edit]
lab@Yeast# show policy-options policy-statement as_34_import
term slow_peer {
from {
protocol bgp;
neighbor 84.10.113.1;
as-path 34_originate;
route-filter 0.0.0.0/0 exact;
}
then {
community add bw_slow;
accept;
}
288 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
}
term fast_peer {
from {
protocol bgp;
neighbor 84.10.109.7;
as-path 34_originate;
route-filter 0.0.0.0/0 exact;
}
then {
community add bw_fast;
accept;
}
}
term reject-all {
then reject;
}
The new as_34_import policy makes use ol a from neighbor match conuition to tag the
matching ioute with the iuentilieu Lanuwiuth community. In theoiy, this can also Le
uone as pait ol an expoit policy within Botnet, Lut this puts ieliance on the auminis-
tiation ol the iemote AS, which may involve uelays anu the potential loi Lilling anu
mistakes. Expecteu opeiation is veiilieu Ly once again uisplaying uetails aLout the
active BGP ioute:
[edit policy-options]
lab@Yeast# run show route protocol bgp detail
inet.0: 818 destinations, 1619 routes (18 active, 0 holddown, 1600
hidden) 0.0.0.0/0 (2 entries, 1 announced)
*BGP Preference: 170/-101
Next-hop reference count: 1
Source: 84.10.109.7
Next hop: 84.10.109.7 via ge-0/0/0.3233 balance 99%
Next hop: 84.10.113.1 via t1-2/0/2.0 balance 1%, selected
State: <Active Ext>
Local AS: 1282 Peer AS: 34
Age: 3:48:08
Task: BGP_34.84.10.109.7+179
Announcement bits (2): 0-KRT 3-OSPFv2
AS path: 34 I
Communities: bandwidth:1287:12500000
Localpref: 100
Router ID: 84.10.109.1
BGP Preference: 170/-101
Next-hop reference count: 801
Source: 84.10.113.1
Next hop: 84.10.113.1 via t1-2/0/2.0, selected
State: <NotBest Ext>
Inactive reason: Update source
Local AS: 1282 Peer AS: 34
Age: 1:05:19
Task: BGP_34.84.10.113.1+179
AS path: 34 I
Communities: bandwidth:1287:193000
BGP Deployment: Asymmetric Load Balancing | 289
Localpref: 100
Router ID: 84.10.109.1
The highlights in the show route output conliim that Lalancing now occuis in piopoi-
tion to link speeu, as ieguiieu. To complete this task, a pei-packet loau-Lalancing policy
must Le placeu into ellect at Yeast. A policy nameu lb_per_packet is cieateu, anu it is
applieu to the main iouting instance`s loiwaiuing taLle:
[edit]
lab@Yeast# show policy-options policy-statement lb_per_packet
then {
load-balance per-packet;
accept;
}
[edit]
lab@Yeast# show routing-options forwarding-table
export lb_per_packet;
The lb_per_packet policy matches on all possiLle ioutes anu ellectively conveits the
system liom pei-pielix to pei-llow loau Lalancing. The ellect ol youi woik is conliimeu
Lack on ioutei PBR, wheie tiaceioutes aie peiloimeu. The test tiallic is souiceu liom
vaiious IP auuiesses owneu Ly PBR in an attempt to tiiggei the pei-llow hashing lunction
to use Loth next hops. Note that Ly enaLling pei-llow loau Lalancing, lewei Lits aie
maue availaLle loi hashing against the souice auuiess/uestination auuiess paii. The
iesult is that without a wiue uegiee ol souice auuiess/uestination auuiess vaiiance,
theie is a goou chance that all test tiallic will hash to the same next hop. To accuiately
test ]unipei pei-pielix oi pei-llow loau Lalancing, a laige numLei ol llows shoulu Le
geneiateu, pieleiaLly liom multiple tiallic souices. Put anothei way, as the numLei ol
llows/pielixes incieases, so too uoes the likelihoou ol oLseiving iueal Lalancing among
the set ol availaLle next hops. Beaiing this in minu, the bw_slow community is tempo-
iaiily set to egual bw_fast so that we can expect a 50/50 loau-Lalancing split. This will
inciease the chances ol oLseiving loau Lalancing at play with the limiteu numLei ol
llows availaLle in the laL setup:
lab@PBR> traceroute 192.168.34.1 no-resolve source 10.20.129.2
traceroute to 192.168.34.1 (192.168.34.1) from 10.20.129.2, 30 hops
max, 40 byte packets
1 10.20.129.1 14.553 ms 9.782 ms 8.084 ms
2 10.20.131.1 21.914 ms 9.935 ms 9.988 ms
3 10.10.8.2 10.081 ms 19.865 ms 10.002 ms
4 84.10.113.1 15.697 ms !N 14.286 ms !N 18.954 ms !N
The linal hop ol the tiaceioute to Biewei Inc.`s 192.16S.3+.1 ioute is the S+.10.113.1
auuiess associateu with the low-speeu Botnet peeiing link. In this example, test tiallic
is explicitly souiceu liom the 10.20.129.2 auuiess on the PBRStout link, which happens
to Le the same IP auuiess that the packet woulu noimally take. Next, a uilleient llow
is cieateu Ly geneiating an ICMP echo packet liom the same souice auuiess, Lut to a
uilleient host auuiess (.100), on the 192.16S.3+.0/2+ suLnet. The goal heie is to tiy
anu tiiggei a uilleient llow hashing iesult Ly alteiing some ol the Lits useu in the llow
290 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
hashing algoiithm. Heie, we change Loth the piotocol (ICMP veisus UDP) anu some
ol the Lits in the auuiesses` host ID:
lab@PBR> ping 192.168.34.100 rapid count 1 source 10.20.129.2
PING 192.168.34.100 (192.168.34.100): 56 data bytes
36 bytes from 84.10.109.7: Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 5e00 0 0000 3d 01 b186 10.20.129.2 192.168.34.100
.
--- 192.168.34.100 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
The uestination unieachaLle eiioi message geneiateu Ly S+.10.109.7 pioves that the
ICMP test packet was loiwaiueu ovei the high-speeu Botnet peeiing link. Satislieu that
pei-llow loau Lalancing is woiking, you iestoie the bw_slow community to its pievious
value anu take a well-ueseiveu Lieak:
[edit]
lab@Yeast# rollback 1
load complete
[edit]
lab@Yeast# show | compare
[edit policy-options community bw_slow]
- members bandwidth:1287:12500000000;
+ members bandwidth:1287:193000;
[edit]
lab@Yeast# commit
commit complete
Initial BGP Peering Summary
This section showeu you an example ol how to conliguie anu veiily Lasic EBGP peeiing
using ]unos soltwaie. Ve also showeu the use ol iouting policy to liltei ieceiveu ioutes
anu to contiol the ioutes that you auveitise, along with the ieuistiiLution ol a BGP-
leaineu uelault ioute into youi IGP to pioviue exteinal ieachaLility loi non-BGP
speakeis within youi AS. You also saw how to use a static ioute with an alteieu gloLal
pieleience (a concept known as a j|oating static routc in IOS speak) to Lack up a BGP
peeiing, anu how the BGP Lanuwiuth community is useu to pioviue asymmetiic loau
Lalancing Laseu on link speeu.
The next section exploies typical enteipiise applications ol BGP iouting policy, which
in tuin piepaies you loi the incieasingly complicateu BGP ueployment scenaiios that
lollow latei in this chaptei. Now is a goou time to take a Lieak, peihaps to think Lack
ovei the points coveieu in this section oi just to cleai youi minu loi the outLounu anu
inLounu policy uiscussions in the next section.
BGP Deployment: Asymmetric Load Balancing | 291
Enterprise Routing Policy
You have now Leen exposeu to vaiious applications ol ]unos soltwaie iouting policy,
heie anu in eailiei chapteis. Ve uiscusseu the opeiational theoiy ol iouting policy in
uetail in Chaptei 5. In summaiy, impoit iouting policy is iesponsiLle loi placing ioutes
into the ioute taLle, possiLly with mouilieu attiiLutes, anu expoit policy is iesponsiLle
loi placing copies ol ioutes into outgoing iouting piotocol upuates, again possiLly with
mouilieu attiiLutes. The complexity ol an oiganization`s policy is typically tieu uiiectly
to the uegiee ol its inteiconnectivity ieguiiements. An enteipiise that is single-homeu
neeus veiy little policy; in most cases, such an attachment uoes not even waiiant use
ol BGP!
This section locuses on applying ]unos soltwaie iouting policy to meet the neeus ol an
enteipiise that is uual-homeu to uilleient pioviueis.
Inbound and Outbound Routing Policies
In a majoiity ol cases, a uual-homeu enteipiise netwoik will have uistinctly uilleient
inLounu anu outLounu policies. Youi inLounu policy is intenueu to contiol how tiallic
enteis youi AS liom othei netwoiks, wheieas youi outLounu policy uictates how tiallic
leaves youi AS to entei othei netwoiks. You use specilic instances ol expoit anu impoit
policy to lacilitate youi oiganization`s inLounu anu outLounu policy goals.
Achieving youi inLounu policy goals can Le uillicult, oi even impossiLle, given that
you uo not have uiiect contiol ovei the outLounu policies ol the netwoiks that you
peei with. In the enu, each netwoik opeiatoi has complete contiol ol its local outLounu
policy, so at Lest youi inLounu policy can inlluence its policy uecisions only within the
limits that aie peimitteu Ly that netwoik`s outLounu policy. In some cases, achieving
youi inLounu policy goals may ieguiie selecting ISPs that aie willing to woik with youi
neeusthis is a political, not a technical, issue. In contiast, you have complete contiol
ovei youi outLounu policy. Simply put, it`s youi netwoik, anu you can conliguie it to
uo whatevei you want in this iegaiu.
As with most netwoik uesign consiueiations, each netwoik must caielully weigh its
policy uesiies against the potential costs, measuieu in incieaseu auministiative/suppoit
Luiuens, potential economic impacts, peiloimance consiueiations, eguipment capa-
Lilities, anu so on. The netwoik then must ueciue on a set ol policies that Lest Lalance
all ol the lactois involveu.
Common Policy Design Criteria
Although the specilics always vaiy, many common elements uiive most policy
uecisions:
292 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
Topo|ogy-drivcn
A topology-uiiven policy is Laseu on the physical connectivity ol youi netwoik anu
is typically conceineu with locating the lowest-cost (lowest-metiic) path loi tiallic.
In many cases, a topology-uiiven policy will use IGP metiics to locate the Lest
egiess point, anu in tuin will senu the IGP metiic as the MED in EBGP upuates.
Recall that MED is like a tiue metiic, in that lowei values aie pieleiieu. Il youi peei
honois MEDs in its uecision piocess, this shoulu iesult in tiallic enteiing youi AS
at the point that is metiically closest to the actual uestination. You can set the MED
in BGP policy using the metric keywoiu. Suppoit loi automatically tiacking the
IGP metiic is also pioviueu.
The topology-uiiven mouel is the easiest to implement Lecause in most cases, you
leave all attiiLutes unmouilieu anu simply iely on the ioute selection algoiithm to
select the Lest ioute, which will noimally Le the shoitest path (the lewest numLei
ol ASs, Lest oiigin, lowest MED, anu lowest IGP metiic).
Prinary/sccondary
A piimaiy/seconuaiy policy is Laseu on the pieleiential use ol a piimaiy access
link. Motivations loi a piimaiy/seconuaiy mouel tenu to Le peiloimance-uiiven,
Lut can also lactoi in economic, ieliaLility, oi secuiity conceins. The last lactoi,
secuiity, is olten oveilookeu. Knowing that all youi tiallic leaves anu enteis on the
same set ol links gieatly simplilies ueployment ol statelul liiewalls anu NAT uevi-
ces. This is Lecause state instantiateu Ly the tiansmission ol tiallic is ieauily avail-
aLle to match against the ietuin tiallic. Senuing tiallic out ol one uevice, anu having
the iesponse hanuleu at a uilleient access point Ly a uilleient uevice, makes statelul
seivices guite complex.
In a strict piimaiy/seconuaiy mouel, no tiallic shoulu use the seconuaiy links un-
less the piimaiy link Lecomes unavailaLle. In contiast, in a |oosc mouel, some
tiallic, peihaps Laseu on topology consiueiations, is alloweu to use the seconuaiy,
even when the piimaiy is opeiating. Youi uesign shoulu also lactoi the uesiie to
ieveit Lack to a piimaiy altei seivice is iestoieu. A ieveitive uesign switches Lack
to the piimaiy, Lut this Lehavioi can cause issues when chionic pioLlems plague
the piimaiy link. This is Lecause ongoing uisiuption occuis each time tiallic is
ieuiiecteu to anu liom the Louncing piimaiy ciicuit. Heie, a nonieveitive policy
that piomotes staLility ovei othei lactois such as cost, oi iaw Lanuwiuth, woulu
Le pieleiieu.
Using egual capacity links in conjunction with a stiict piimaiy/seconuaiy mouel
pioviues the highest uegiee ol ieuunuancy Lecause eithei link can hanule the ol-
leieu loau with egual peiloimance. Vith the loose vaiiation, usaLle Lanuwiuth
can Le the sum ol Loth link capacities; theieloie, the lailuie ol eithei link ieuuces
oveiall capacity anu may impact peiloimance. This is also tiue ol a stiict mouel
that uses asymmetiic link speeus to save on Lanuwiuth costs.
Enterprise Routing Policy | 293
Load-sharing
A loau-shaiing policy attempts to maximize use ol all availaLle iesouices Ly
spieauing tiallic ovei the set ol availaLle access points. This is typically peiloimeu
on a pei-pielix Lasis, wheie some set ol ioutes is mappeu to one link while anothei
set is mappeu to a uilleient link. In a lailuie scenaiio, tiallic liom allecteu links is
switcheu to the next most pieleiieu opeiational link.
A word on outbound/inbound versus export/import policy
Beloie moving on, it`s woith noting that theie is somewhat ol a ieveise ielationship
Letween youi inLounu/outLounu policy anu the type ol ]unos soltwaie iouting policy
that is applieu to youi EBGP session. Foi example, you will noimally use cxport policy
when you wish to instantiate an inbound policy to contiol how othei netwoiks ioute
tiallic into youi AS. Likewise, you noimally use inport policy to aujust attiiLutes in
ieceiveu ioutes that in tuin allect youi outbound policyloi example, setting local
pieleience on ioutes as they aie ieceiveu liom an EBGP peei.
Il that weie not conlusing enough, you will likely linu that in many cases, you can
achieve the same ellect using eithei an impoit oi an expoit policy. Foi example, local
pieleience can Le set at ieception liom an EBGP peei using an impoit policy oi when
senuing the ioute to othei IBGP speakeis using an expoit policy. In lact, you may use
an impoit to set an attiiLute to some local value, anu then use an expoit to senu a
mouilieu value to othei peeis. Vheievei possiLle, you shoulu take a consistent ap-
pioach to help minimize suppoit Luiuens anu oveiall netwoik complexity.
Know your ISPs policy
Because youi BGP speakeis aie expecteu to inteiact with those unuei the contiol ol
youi ISP, it pays to Le lamiliai with youi ISP`s geneial policies. Foi example, many ISPs
set ioute attiiLutes within theii netwoik, Laseu on the ieceipt ol ceitain communities
attacheu Ly theii customeis. As anothei example, consiuei that theie is no point in
auveitising a pielix with a /32 netwoik mask il youi ISP`s policy is not to accept any
ioutes with a pielix length longei than /2S.
Most pioviueis use local pieleience to pielei ioutes liom theii customeis ovei those
leaineu liom theii peeis, liltei ioute upuates Laseu on pielix lengths, anu liltei upuates
ieceiveu liom theii customeis to ensuie that they aie not acting as tiansit peeis. Pio-
viueis olten post theii policies on puLlic weLsites wheie the inloimation can Le useu
to compaiison shop when seeking seivice.
Enterprise Policy Summary
This section Lioke uown the seemingly uaunting task ol BGP anu policy into the cat-
egoiies ol inLounu anu outLounu policies, which helps to make things moie manage-
aLle. In most cases, an enteipiise will neeu to Le uual-homeu to take lull auvantage ol
the powei ol BGP anu ]unos soltwaie iouting policy. RememLeiing that you use
294 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
cxport policy to allect youi inbound iouting goals, anu use inport policy loi youi
outbound goals, helps to eliminate a lot ol potential conlusion.
By uelault, BGP settles on a topology-Laseu mouel, Lut in many cases you will want to
altei this Lehavioi Laseu on youi oiganization`s neeus anu uesiies. You have uiiect
contiol ovei youi own netwoik`s output iouting, making that pait ol the eguation
stiaightloiwaiu. Ellectively estaLlishing a uesiieu inLounu policy means you have
manageu to inlluence the outLounu action ol iouteis in a iemote netwoik, which aie
not unuei youi uiiect contiol. That is the maik ol a tiue BGP policy guiu.
In the next section, you will Legin to apply complex enteipiise iouting policies, iight
altei you multihome the netwoik Ly auuing a new EBGP peeiing anu ueploy a ioute-
iellecteu IBGP topology within Beei-Co.
Multihome Beer-Co
Beei-Co`s initial BGP peeiing with Botnet in AS 3+ is opeiating successlully, anu it`s
time to Liing up a seconu EBGP session to Boignet in AS +20. Vhen multihomeu to
uual pioviueis, the tiue Lenelit ol BGP anu its policy contiols can Le lully iealizeu.
Figuie 7-9 pioviues the new BGP peeiing topology anu illustiates how Boignet connects
to seivice pioviuei Daiknet in AS 666, which is also peeieu with Botnet. It seems that
things coulu get guite inteiesting heie.
The liguie shows key uetails ol each AS. These incluue the EBGP peeiing ioutei`s name,
its loopLack auuiess, anu the set ol ioutes that oiiginate within that AS anu the cus-
tomei ioutes associateu with that netwoik. The liguie calls out thiee paiticulai cus-
tomei pielixes within Boignet, Daiknet, anu Botnet, which aie assigneu to customeis
Cap-co Inc., Bottles Inc., anu Biewei Inc., iespectively. The 192.16S.xx/2+ pielixes
associateu with these extianet paitneis uemonstiate the ellects ol inLounu anu out-
Lounu policy actions in the lollowing sections.
In this scenaiio, Beei-Co`s IGP consists ol an aiea 0 LackLone with two stuL aieas. Aiea
Loiuei iouteis (ABRs) PBR anu Stout oiiginate an OSPF uelault ioute into theii iespec-
tive stuL aieas.
The uesign goals loi the new BGP peeiing aiiangement aie as lollows:
Deploy new impoit policy at iouteis Yeast anu PBR to accept only ioutes that oiig-
inate in the peeiing AS, incluuing a uelault ioute geneiateu Ly Loth pioviueis.
EstaLlish the new EBGP peeiing session Letween PBR anu Wheat anu auveitise a
10/S aggiegate.
Conliguie loopLack-Laseu IBGP peeiing on a minimal set ol iouteis as neeueu loi
loop-liee tianspoit within Beei-Co.
Use ioute iellection to ieuuce the total numLei ol IBGP sessions anu ensuie no
single point ol lailuie.
Multihome Beer-Co | 295
EstaLlish an outLounu policy that pieleis each peei`s customei ioutes, with all
othei uestinations using the Boignet link as a ieveitive piimaiy.
The iesult ol the initial BGP multihoming task is a (uelault) topology-uiiven inLounu
policy anu a hyLiiu outLounu policy that comLines elements ol the topology-uiiven
anu piimaiy mouels. Route lilteiing anu ioute iellection aie useu to minimize BGP
piocessing uemanu on iouteis with limiteu memoiy.
To help put these ieguiiements into a lunctional peispective, the expecteu Lehavioi is
summaiizeu as lollows:
EBGP speakeis accept only peei customei ioutes (customei ioutes).
Vhen senuing to customei ioutes, loiwaiu uiiectly to the AS that owns that ioute
when the ielateu peeiing session is opeiational.
Vhen senuing to othei BGP uestinations, all BGP speakeis use the uelault ioute
associateu with the piimaiy peeiing to Boignet.
Iigurc 7-9. Bccr-Co gocs nu|tihoncd with a conncction to Borgnct
296 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
Routeis in stuL aieas use a uelault to ieach the closest ABR, at which point BGP
loiwaiuing takes ellect.
The lailuie ol any access link shoulu not sevei communications; upon iestoiation,
tiallic shoulu again auheie to the loose piimaiy outLounu policy.
Implement Beer-Cos Outbound Policy
Conliguiation Legins Ly cieating the impoit policy at PBR that accepts only those ioutes
that oiiginate within Boignet. The intention is to piotect the ielatively small access
ioutei liom the potentially haimlul ellects associateu with the ieceipt ol a lull BGP
ioute taLle liom Wheat. Similai policy actions will also Le peiloimeu at Yeast. The ellect
is a topology-uiiven outLounu iouting mouel loi the ioutes owneu Ly each peeiing AS,
anu the use ol the metiically closest uelault ioute loi uestinations that oiiginate outsiue
ol these ASs; loi example, the 12S/S anu 192.16S.66/2+ ioutes that aie oiiginateu Ly
the nonaujacent AS Daiknet.
This type ol BGP impoit policy noimally uses an AS path iegulai expiession Lecause
it gieatly simplilies the matching ciiteiia against the numeious ioute pielixes that coulu
oiiginate within a given AS. In this example, the ioutes owneu Ly Boignet aie shown
as Leing in the iange ol 6S2, making a ioute liltei leasiLle. Howevei, you also neeu to
consiuei its inteinal/uiiect ioutes, in this case the 172.16.1.3 loopLack auuiess ol
Wheat. Vhen ieally tight contiol is neeueu, you can always comLine the ellects ol ioute
lilteis anu AS path iegulai expiessions. The impoit policy cieateu loi PBR uses an AS
path iegulai expiession to only accept ioutes with one oi moie instances ol ASN +20.
The iegulai expiession is wiitten in this mannei to accommouate the potential ol AS
path piepenuing within Boignet. This way, even il theie aie 10 instances ol ASN +20
in the pielix, the ioute is still consiueieu to have oiiginateu within that specilic AS.
PBR`s impoit policy is uisplayeu:
[edit policy-options]
lab@PBR# show
policy-statement as_420_import {
term 1 {
from {
protocol bgp;
as-path as_420_originate;
}
then accept;
}
term 2 {
then reject;
}
}
as-path as_420_originate "^420+$";
The liist teim ol the as_420_import policy accepts ioutes liom BGP with an AS path
matching the nameu expiession as_420_originate. The seconu teim ueleats the uelault
BGP impoit policy, which is to accept all (sane) BGP ioutes. The AS path iegulai
Multihome Beer-Co | 297
expiession uses the ^ anu $ anchois to loice a match against the stait anu enu ol the
AS path attiiLute, iespectively. The + multipliei inuicates that the pioceeuing pattein
(+20) must appeai at least once, Lut can appeai multiple times. The comLineu ellect
is a match against any AS path attiiLute that Legins anu enus with the value +20, which
may contain zeio oi moie iepetitions ol that same value. The as_34_import policy at
Yeast is mouilieu to accept all BGP ioutes oiiginating in AS 3+:
[edit]
lab@Yeast# show policy-options policy-statement as_34_import
term slow_peer {
from {
protocol bgp;
neighbor 84.10.113.1;
as-path 34_originate;
}
then {
community add bw_slow;
accept;
}
}
term fast_peer {
from {
protocol bgp;
neighbor 84.10.109.7;
as-path 34_originate;
}
then {
community add bw_fast;
accept;
}
}
term reject-all {
then reject;
}
[edit]
lab@Yeast# show policy-options as-path
34_originate "^34+$";
The ioute liltei was iemoveu, so now, iathei than accepting only a uelault ioute,
Yeast accepts all ioutes that oiiginate in AS 3+. The as-path also was upuateu to allow
multiple occuiiences ol AS 3+.
EBGP Peering to AS 420
Vith the impoit policy uelineu, you neeu a BGP stanza with which to apply it. The
EBGP peeiing uelinition at PBR is pietty stiaightloiwaiu:
[edit]
lab@PBR# show protocols bgp
group as_420 {
type external;
import as_420_import;
neighbor 172.16.1.1 {
298 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
peer-as 420;
}
}
The newly cieateu as_420_import policy has Leen applieu as impoit. The commit lailuie
olleis a liienuly ieminuei that, loi BGP to opeiate, a local ASN is ieguiieu. This is
guickly iemeuieu:
[edit]
lab@PBR# commit
[edit protocols]
'bgp'
Error in neighbor 172.16.1.1 of group as_420:
must define local autonomous system when enabling BGP
error: configuration check-out failed
[edit]
lab@PBR# set routing-options autonomous-system 1282
[edit]
lab@PBR# commit
commit complete
BGP session status is veiilieu with a show bgp summary commanu:
[edit]
lab@PBR# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 806 123 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Damped...
172.16.1.1 420 356 257 0 0 2:06:57
123/806/00/0/0
The EBGP session to Boignet is estaLlisheu, as conliimeu Ly the x/x/x lielu that sum-
maiizes active ioutes, ieceiveu ioutes, anu uampeu ioutes, iespectively. This uisplay
also Legins to valiuate the as_420_import policy, in that only 123 ol the S06 ioutes
ieceiveu aie active. The piesence ol hiuuen ioutes, ostensiLly uue to lilteiing, is
conliimeu:
[edit]
lab@PBR# run show route hidden detail
inet.0: 825 destinations, 826 routes (143 active, 0 holddown, 682 hidden)
64.8.12.1/32 (1 entry, 0 announced)
BGP /-101
Next-hop reference count: 929
Source: 172.16.1.1
Next hop: 172.16.1.1 via ge-0/0/0.412, selected
State: <Hidden Ext>
Local AS: 1282 Peer AS: 420
Age: 2:19:43
Task: BGP_420.172.16.1.1+1530
AS path: 420 666 I
Multihome Beer-Co | 299
Localpref: 100
Router ID: 172.16.1.3
128.3.0.0/16 (1 entry, 0 announced)
BGP /-101
Next-hop reference count: 929
Source: 172.16.1.1
Next hop: 17^C[abort]
---(more)---
. . .
The summaiy poition ol the show route hidden detail commanu conliims Loth a laige
numLei ol hiuuen ioutes (6S2) anu that the hiuuen ioute uisplayeu has an AS path that
docs not inuicate oiigin in AS +20. This shows that the ioute is hiuuen uue to youi AS
path-Laseu impoit lilteiing. The CLI`s AS path iegulai expiession liltei is useu loi linal
conliimation:
[edit]
lab@PBR# run show route aspath-regex ^420+$ | match path
AS path: 420 I
AS path: 420 I
AS path: 420 I
AS path: 420 I
AS path: 420 I
. . .
[edit]
lab@PBR# run show route aspath-regex ^420+$ | match path | countCount: 124 lines
The iegex-lilteieu show route uisplay veiilies that all matching ioutes have an AS path
consisting ol only AS +20. The CLI`s count lunction is then useu to conliim that PBR
has ieceiveu a total ol 12+ ioutes liom Boignet that pass the as_420_import policy. One
ol these shoulu Le a uelault ioute that is useu to ieach BGP uestinations that uo not
oiiginate in eithei AS 3+ oi AS +20:
[edit]
lab@PBR# run show route
inet.0: 825 destinations, 826 routes (143 active, 0 holddown, 682 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 02:24:20, metric 0, tag 0
> to 10.20.130.1 via ge-0/0/0.1241
[BGP/170] 00:28:13, localpref 100
AS path: 420 I
> to 172.16.1.1 via ge-0/0/0.412
The show route uisplay at PBR conliims the ieceipt ol a BGP uelault ioute Lut shows a
potential pioLlem as well; PBR also ieceives the uelault ioute ieuistiiLuteu into OSPF
Ly Yeast, anu it pieleis the OSPF veision uue to gloLal pieleience (known as aumin-
istiative uistance in IOS lanu).
The goal ol youi hyLiiu topological/piimaiy outLounu iouting policy is to have iouteis
loiwaiu to peei customei ioutes using a topology mouel that hanus tiallic uiiectly to
300 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
the AS that owns those ioutes, while a uelault ioute is useu to ieach lilteieu BGP ues-
tinations ovei the piimaiy Boignet peeiing. To meet the ieguiiements, this uelault ioute
shoulu always uiiect tiallic ovei the Boignet link when it is opeiational. Theieloie, in
noimal opeiation, all iouteis must pielei the uelault ioute auveitiseu Ly PBR ovei any
copy auveitiseu Ly Yeast.
In the cuiient setup, a BGP leaineu uelault ioute liom AS 3+ is Leing ieuistiiLuteu into
OSPF at ioutei Yeast. Recall that this was necessaiy Lecause up until now, Yeast was
the only BGP speakei in Beei-Co. Given that you aie now, oi soon will Le, ueploying
IBGP among a set ol Beei-Co`s inteinal iouteis, the neeu to ieuistiiLute the uelault into
OSPF can Le ievisiteu. The stuL aiea iouteis alieauy iely on an OSPF uelault geneiateu
Ly each aiea`s ABR, so this uiscussion centeis on what is uone loi iouteis PBR, Bock,
Stout, Porter, anu Yeast. Figuie 7-10 uetails the plan ol action loi IBGP ueployment
on Beei-Co`s LackLone.
Iigurc 7-10. Bccr-Co |BGP dcp|oyncnt dctai|s
Figuie 7-10 shows that all OSPF aiea 0 iouteis will Le conliguieu to iun IBGP. Recall
liom an eailiei uiscussion that ueciuing which iouteis neeu to iun IBGP is a lunction
ol whethei youi impoit policy accepts only a uelault, anu whethei inteimeuiate iouteis
aie in the loiwaiuing path Letween EBGP speakeis. Also iecall that an EBGP speakei
shoulu always Le enaLleu loi IBGP unless theie is only one BGP speakei in youi net-
woik. Because youi EBGP speakeis aie accepting only specilic pielixes, IBGP shoulu
Le enaLleu on any ioutei that can loiwaiu tiallic Letween the speakeis. In this example,
that means Stout, Bock, anu Porter must suppoit IBGP. Because the LackLone iouteis
will iun BGP, they can leain the uelault ioute thiough BGP; this means that
Multihome Beer-Co | 301
ieuistiiLution ol the BGP uelault into OSPF is no longei necessaiy. Vith this unuei-
stanuing, the ospf_default expoit policy is iemoveu at Yeast:
[edit]
lab@Yeast# delete policy-options policy-statement ospf_default
[edit]
lab@Yeast# delete protocols ospf export
The ellect ol this change is conliimeu at PBR, wheie now only the BGP veision ol the
uelault ioute is piesent anu is theieloie maue active:
[edit]
lab@PBR# run show route
inet.0: 827 destinations, 827 routes (145 active, 0 holddown, 682 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 17:26:08, localpref 100
AS path: 420 I
> to 172.16.1.1 via ge-0/0/0.412
Export Beer-Co Aggregate to Borgnet
The ieguiiements state that PBR shoulu auveitise a single 10/S aggiegate to its EBGP
peeis iepiesenting Beei-Co`s inteinal connectivity. The same appioach useu at Yeast
is Liought to Leai heie. Specilically, an aggiegate ioute is uelineu anu policy is cieateu
to expoit it to Wheat in AS +20:
[edit]
lab@PBR# show routing-options aggregate
route 10.0.0.0/8;
lab@PBR# show policy-options policy-statement as_420_export
term 1 {
from {
protocol aggregate;
route-filter 10.0.0.0/8 exact;
}
then accept;
}
[edit]
lab@PBR# show protocols bgp group as_420 export
export as_420_export;
Valiuation ol the as_420_export policy is stiaightloiwaiu:
[edit]
lab@PBR# run show route advertising-protocol bgp 172.16.1.1
inet.0: 827 destinations, 827 routes (145 active, 0 holddown, 682 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/8 Self I
302 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
Although not shown, a similai state ol EBGP leaineu anu auveitiseu ioutes is also
conliimeu to exist at ioutei Yeast, except that is has leaineu the 129133 anu
192.16S.3+/2+ customei ioutes liom AS 3+. This completes the EBGP peeiing anu
initial impoit policy phases ol the BGP multihoming scenaiio. It is time to auu IBGP
to the netwoik.
Monitor system load
Beloie auuing EBGP to Yeast, system iesouices weie analyzeu using the show chassis
routing-engine anu show task memory commanus. Now that EBGP has Leen auueu, it
is a goou iuea to ieexamine iesouice usage. Il the ioutei is having a haiu time main-
taining its cuiient EBGP loau loi whatevei ieason, oLviously the auuition ol IBGP
sessions will not help matteis. The hiuuen set task accounting commanu is useu to
get a Lettei leel loi how much Luiuen BGP itsell is auuing to the ioutei.
Hiuuen commanus aie hiuuen Lecause ]unipei Netwoiks suppoit en-
gineeis leel inappiopiiate use can cause opeiational pioLlems. As a
geneial iule, you shoulu nevei issue hiuuen commanus on a piouuction
netwoik ioutei unless a suppoit engineei has instiucteu you to uo so.
This commanu uisplays the iesouice consumption ol the vaiious components ol the
iouting uaemon (rpd) anu is hiuuen Lecause it ieguiies the ioutei`s iesouices to iun,
which coulu make a Lau situation woise. Because theie is no ieason to Lelieve that any
ol Beei-Co`s iouteis aie actually iunning shoit on iesouices, task accounting is enaLleu
(note that theie is no CLI auto-completion, hence the teim hiddcn). Altei a lew
moments, the iesults aie uisplayeu, anu task accounting is tuineu Lack oll. Task ac-
counting shoulu Le enaLleu only when neeueu, anu then only long enough to get the
inloimation uesiieu. Also note that set task accounting on is an opeiational moue
commanu:
lab@PBR> set task accounting on
Task accounting enabled.
lab@PBR>
Altei a lew moments, the iesults aie uisplayeu:
lab@PBR> show task accounting
Task accounting is enabled.
Task Started User Time System Time Longest Run
Scheduler 425 0.004 0.007 0.000
LMP Client 75 0.001 0.002 0.000
Memory 6 0.000 0.000 0.000
OSPFv2 I/O./var/run/ppmd_ 120 0.001 0.002 0.000
BGP RT Background 32 0.000 0.000 0.000
OSPFv2 100 0.000 0.001 0.000
BFD I/O./var/run/bfdd_con 29 0.000 0.000 0.000
BGP_420.172.16.1.1+1530 38 0.000 0.001 0.000
Multihome Beer-Co | 303
KRT 12 0.000 0.000 0.000
Redirect 2 0.000 0.000 0.000
MGMT_Listen./var/run/rpd_ 2 0.000 0.000 0.000
SNMP Subagent./var/run/sn 3 0.000 0.000 0.000
The output inuicates that the EBGP peeiing at PBR is not consuming appieciaLle system
iesouices. Note that instaLility anu iesulting ioute llaps (iepeateu ioute withuiawals
anu ieauveitisement) coulu change this situation. BGP ioute uamping is useu to Lullei
the ellects ol llapping ioutes when neeueu. In opeiation, once an unstaLle pielix is
uampeu, suLseguent upuates/withuiawals aie ignoieu loi a specilieu peiiou to pieseive
the local ioutei`s contiol plane iesouices.
Task accounting is again uisaLleu to pievent unnecessaiy iesouice usage:
lab@PBR> set task accounting off
Task accounting disabled.
IBGP Peering Within AS 1282
Releiiing Lack to Figuie 7-10 anu the scenaiio`s uesign ieguiiements, it`s oLvious that
you neeu to conliguie IBGP on the LackLone iouteis. Route iellection is useu to min-
imize the total numLei ol IBGP sessions ieguiieu. Dual ioute iellectois aie ueployeu
loi ieuunuancy, in this case using the same clustei ID. The use ol loopLack-Laseu IBGP
peeiing means that the potential loi session uisiuption to one iellectoi, Lut not the
othei, is viitually nonexistent, making the lack ol clustei 1.2.S.2 upuates ovei the ioute
iellectoi-ioute iellectoi IBGP session a nonissue. Using the same clustei ID on Loth
iellectois ieuuces the BGP iouting inloimation Lase (RIB) size on the iellectois Lecause
they liltei upuates ieceiveu liom each othei that contain the shaieu clustei ID. Note
that the two ioute iellectois peei to each othei as nonclients. The same clustei ID value
is conliguieu on Loth iellectois. In this example, the clustei ID is Laseu on Beei-Co`s
ASN 12S2.
Foi the SRXs anu the ]-seiies iouteis, BGP ioute iellection is a value-
auueu seivice that ieguiies sepaiate licensing. Route iellection will not
opeiate without the Auvanceu BGP leatuie license. You oLtain leatuie
licenses liom the uistiiLutoi that solu you the ioutei. Vithout the li-
cense, the BGP connection will not pass the iule state on the ioute ie-
llectoi. This is a change loi ]unipei. Until a shoit time ago, the license
enloicement was only a waining in the conliguiation, Lut touay the
licenseu leatuies uo not opeiate.
Conliguiation ol ioute iellection Legins with cieation ol the ioute iellectoiioute
iellectoi IBGP peeiing session on Porter:
[edit]
lab@Porter# set routing-options autonomous-system 1282
[edit]
lab@Porter# edit protocols bgp group 1282_rr
304 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
[edit protocols bgp group 1282_rr]
lab@Porter# set type internal neighbor 10.10.12.3
[edit protocols bgp group 1282_rr]
lab@Porter# set local-address 10.20.12.2
[edit protocols bgp group 1282_rr]
lab@Porter# top show routing-options
autonomous-system 1282;
[edit protocols bgp group 1282_rr]
lab@Porter# show
type internal;
local-address 10.20.12.2;
neighbor 10.10.12.3;
Vith uelinition ol the local system`s ASN unuei the routing-options stanza complete,
you cieate a BGP gioup calleu 1282_rr; this gioup is uesignateu as an internal gioup,
making the conliguiation ol a peer-as unnecessaiy. The highlights show how a
loopLack-Laseu peeiing session is uelineu thiough specilication ol the neighLoi`s loop-
Lack auuiess in conjunction with a local-address statement iepiesenting the local
loopLack auuiess. The use ol the local-address statement is ciucial loi piopei loopLack
peeiing. Omitting the local-address, which is known as update-source in IOS, iesults
in a session that is souiceu liom whatevei inteilace the session is iouteu ovei. Because
the iemote ioutei is conliguieu to peei with a loopLack auuiess, the incoming session,
which is now souiceu liom a physical inteilace`s IP, appeais unexpecteu, anu peeiing
is ieluseu. Geneially speaking, you can omit the local-address liom one enu, as Loth
enus tiy to loim a connection Ly uelault, Lut Lest piactices loi loopLack peeiing call
loi Loth enus to Le conliguieu symmetiically.
A similai conliguiation is auueu to Bock:
[edit protocols bgp group 1282_rr]
lab@Bock# show
type internal;
local-address 10.10.12.3;
neighbor 10.10.12.2;
Altei a minute oi two, the iellectoi-to-iellectoi IBGP session status is veiilieu:
[edit]
lab@Porter# run show bgp summary
Groups: 1 Peers: 1 Down peers: 1
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Damped...
10.10.12.3 1282 0 0 0 0 4:35 Idle
Things uo not look goou at Porter. The Idle state implies that the BGP session cannot
even Le iouteu, let alone estaLlisheu. A glance at Bock shows an Active state, meaning
Multihome Beer-Co | 305
that the ioutei is at least aLle to ioute its TCP session towaiu its peei anu is theieloie
actively tiying to estaLlish a TCP connection:
[edit protocols bgp group 1282_rr]
lab@Bock# run show bgp summary
Groups: 1 Peers: 1 Down peers: 1
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Damped...
10.10.12.2 1282 0 8 0 0 2:33 Active
Troubleshoot an IBGP peering problem
Attention is locuseu at Porter Lecause its BGP session status is the lessei/woise ol the
two. Because loopLack-Laseu peeiing ieguiies an IGP to iesolve the loiwaiuing next
hop useu to ieach the session`s taiget loopLack auuiess, it`s ieasonaLle to Legin lault
isolation with the IGP inliastiuctuie. The liist step is to conliim whethei Porter has a
ioute to Bock`s loopLack auuiess:
[edit]
lab@Porter# run show route 10.10.12.3
inet.0: 20 destinations, 21 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.12.3/32 *[OSPF/10] 02:24:59, metric 3
> to 10.20.131.2 via ge-0/0/1.1331
The output conliims that Porter has an OSPF leaineu ioute to Bock`s loopLack auuiess.
A tiaceioute is peiloimeu bctwccn the IBGP peeiing auuiesses. This is achieveu Ly
souicing the tiaceioute liom Porter`s loopLack auuiess, as highlighteu:
[edit]
lab@Porter# run traceroute 10.10.12.3 source 10.10.12.2
traceroute to 10.10.12.3 (10.10.12.3) from 10.10.12.2, 30 hops max,
40 byte packets
1 10.20.131.2 (10.20.131.2) 12.790 ms 14.714 ms 5.128 ms
2 10.20.129.2 (10.20.129.2) 24.976 ms 9.342 ms 9.845 ms
3 10.10.12.3 (10.10.12.3) 10.103 ms 27.564 ms 31.800 ms
The tiaceioute succeeus, anu in so uoing vinuicates the IGP as the souice ol the IBGP
peeiing pioLlem. Fiom a loopLack-Laseu IBGP peispective, all that is ieguiieu ol the
IGP is a ioute Letween loopLack auuiesses, anu cleaily that pait is woiking heie. The
next step is to auu BGP piotocol tiacing to see whethei that sheus any light. Tiacing is
auueu to Porter, anu the tiace lile is monitoieu in ieal time using the monitor start
commanu:
[edit protocols bgp]
lab@Porter# show traceoptions
file bgp_trace;
flag open detail;
306 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
[edit protocols bgp]
lab@Porter# commit
commit complete
[edit protocols bgp]
lab@Porter# run monitor start bgp_trace
BGP tiace output is oLseiveu altei a minute oi so; use the clear bgp neighbor <peer
address> commanu to help expeuite activity when you aie impatient:
*** bgp_trace ***
Sep 1 01:49:02.088247
Sep 1 01:49:02.088247 BGP RECV 10.10.12.3+1601 -> 10.10.12.2+179
Sep 1 01:49:02.088335 BGP RECV message type 1 (Open) length 45
Sep 1 01:49:02.088423 BGP RECV version 4 as 1282 holdtime 90 id
10.10.12.3 parmlen 16
Sep 1 01:49:02.088447 BGP RECV MP capability AFI=1, SAFI=1
Sep 1 01:49:02.088460 BGP RECV Refresh capability, code=128
Sep 1 01:49:02.088469 BGP RECV Refresh capability, code=2
Sep 1 01:49:02.088508
Sep 1 01:49:02.088508 BGP SEND 10.10.12.2+179 -> 10.10.12.3+1601
Sep 1 01:49:02.088537 BGP SEND message type 1 (Open) length 29
Sep 1 01:49:02.088552 BGP SEND version 4 as 1282 holdtime 90 id
10.10.12.2 parmlen 0
Sep 1 01:49:02.088566
Sep 1 01:49:02.088566 BGP SEND 10.10.12.2+179 -> 10.10.12.3+1601
Sep 1 01:49:02.088583 BGP SEND message type 3 (Notification) length 21
Sep 1 01:49:02.088689 BGP SEND Notification code 2 (Open Message
Error) subcode 5 (authentication failure)
Sep 1 01:49:02.089581 bgp_pp_recv: NOTIFICATION sent to 10.10.12.3+1601
proto): code 2 (Opelist
monitor start "bgp_trace" (Last changed Sep 1 01:49:02)
(Message Error) subcode 5(authentication failure), Reason: no group
for 10.10.12.3+1601 (proto) from AS 1282 found (peer idled), dropping
him
The highlights call out key aspects ol the tiace. Things Legin when Porter ieceives a
BGP session open liom Bock. Note that this session is coiiectly souiceu Letween the
loopLack auuiesses associateu with iouteis Bock anu Porter. Porter iesponus with a
notilication message that iepoits an authentication lailuie. In the BGP context, this
type ol message means that an unknown peei has tiieu to estaLlish a peeiing session.
BGP noimally communicates only with explicitly conliguieu peeis (unless you auu
the allow <prefix> keywoiu). The last highlight is tellingthe local system iepoits that
this peei uoes not Lelong to any conliguieu gioups. The lack ol Porter-initiateu BGP
session ieguests is expecteu heie; iecall that its connection is in the iule state, which
means that it cannot Legin to loim a session, so theie woulu Le nothing to tiace.
The IBGP conliguiation is examineu with extia sciutiny, Lecause you aie suie that
Porter has peei 10.10.12.3 conliguieu in the 1282_rr gioup:
[edit protocols bgp]
lab@Porter#
*** monitor and syslog output disabled, press ESC-Q to enable ***
Multihome Beer-Co | 307
[edit protocols bgp]
lab@Porter# show
traceoptions {
file bgp_trace;
flag open detail;
}
group 1282_rr {
type internal;
local-address 10.20.12.2;
neighbor 10.10.12.3;
}
The IBGP conliguiation pioLlem at Porter jumps out anu slaps you in the heau, emit-
ting a u`oh-like sounu that echoes Letween youi eais. The local-address statement
incoiiectly specilies a nonexistent auuiess. This accounts loi the local state ol iule
Lecause the ioutei cannot cieate a packet with a spooleu auuiess! This ellectively puts
the 1282_rr gioup into an iule state, which in tuin leaus to the authentication lailuie
loi the session initiateu Ly Bock. The tiacing conliguiation is iemoveu, the mistake is
coiiecteu, anu session status is conliimeu to Le opeiational a shoit time latei:
[edit protocols bgp]
lab@Porter# delete traceoptions
[edit protocols bgp]
lab@Porter# set group 1282_rr local-address 10.10.12.2
[edit protocols bgp]
lab@Porter# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Damped...
10.10.12.3 1282 5 6 0 0 1:52 0/0/0
0/0/0
Configure route reflection
The conliguiation loi clustei 1.2.S.2 is now auueu to each iellectoi. Heie is Bock`s
1282_clients gioup:
[edit protocols bgp group 1282_clients]
lab@Bock# show
type internal;
local-address 10.10.12.3;
cluster 1.2.8.2;
neighbor 10.20.128.3;
neighbor 10.20.128.4;
neighbor 10.30.1.1
The 1282_rr_clients gioup is similai to the pieviously cieateu 1282_rr gioup, except
loi the inclusion ol a clustei ID, which makes the local ioutei a ioute iellectoi loi all
308 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
peeis in that gioup. All thiee client loopLack auuiesses aie conliguieu, making them
clients loi clustei 1.2.S.2. A similai conliguiation is auueu to Porter.
A note on next-hop self anu ioute iellectois is in oiuei heie. It is com-
mon to have an IBGP expoit policy on EBGP speakeis that sets the au-
veitiseu next hop to the IBGP speakei`s peeiing auuiess to eliminate
issues with othei ioutes not Leing aLle to iesolve the EBGP next hop
oiiginally auveitiseu Ly the iemote AS. Applying such a policy loi ioutes
that aie iellecteu among clients can easily iesult in suLoptimal loiwaiu-
ing, as tiallic will Le loiceu to tiansit the iellectoi. In most cases, you
want the iellection topology to Le inuepenuent ol the loiwaiuing top-
ology, anu leaving the next hop unchangeu on iellecteu ioutes achieves
this goal.
IBGP conliguiation at iouteis PBR, Stout, anu Yeast is similai. Each ioutei gets an IBGP
gioup that uelines loopLack peeiing to each iellectoi. The use ol ieuunuant ioute ie-
lection uouLles the total numLei ol IBGP sessions neeueu loi this netwoik, Liinging
the total to 13. This is still lai lewei than the 20 sessions neeueu to loim a lull mesh
among live iouteis il iellection weie not useu. Heie is the conliguiation ol client Stout:
[edit protocols bgp group 1282_clients]
lab@stout# top show routing-options
autonomous-system 1282;
[edit protocols bgp group 1282_clients]
lab@stout# show
type internal;
local-address 10.20.128.4;
neighbor 10.10.12.3;
neighbor 10.10.12.2;
Altei the new 1282_clients peei gioup is auueu to client iouteis PBR, Stout, anu
Yeast, IBGP session status is conliimeu at client Stout:
[edit protocols bgp group 1282_clients]
lab@stout# run show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Damped...
10.10.12.2 1282 13 14 0 0 6:19 0/0/0 0/0/0
10.10.12.3 1282 20 22 0 0 9:57 0/0/0 0/0/0
[edit protocols bgp group 1282_clients]
lab@stout# run show route protocol bgp
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
The output is a Lit ol a mixeu Lag ol iesults. On the one hanu, Loth IBGP sessions aie
estaLlisheu to the iellectois; on the othei hanu, no ioutes aie Leing leaineu ovei eithei
Multihome Beer-Co | 309
session. Ouuly, a show route advertising-protocol bgp commanu at PBR conliims that
it is ieauveitising its EBGP leaineu ioutes to iellectoi Bock:
[edit protocols bgp group 1282_clients]
lab@PBR# run show route advertising-protocol bgp 10.10.12.2
inet.0: 827 destinations, 827 routes (145 active, 0 holddown, 682 hidden)
Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 172.16.1.1 100 420 I
* 6.1.0.0/16 172.16.1.1 100 420 I
* 6.2.0.0/22 172.16.1.1 100 420 I
. . . .
Il PBR is auveitising ioutes to the iellectoi, why aie these ioutes not Leing iellecteu to
the clustei`s clients?
Troubleshoot BGP next hop reachability
Attention shilts to the iellectois, since the missing ioutes weie last oLseiveu Leing sent
to them, while nothing is seen coming Lack liom them. The show route receive-
protocol bgp commanu output on iellectoi Bock implies that no ioutes aie Leing ie-
ceiveu, which is not possiLle, given that PBR`s output shows it auveitiseu ioutes to
Bock, anu the unueilying TCP tianspoit guaiantees ueliveiy!
[edit protocols bgp group 1282_clients]
lab@Bock# run show route receive-protocol bgp 10.20.128.3
inet.0: 825 destinations, 950 routes (19 active, 0 holddown, 930 hidden)
The piesence ol hiuuen ioutes is noteu, so you investigate Ly auuing the hidden switch:
[edit protocols bgp group 1282_clients]
lab@Bock# run show route receive-protocol bgp 10.20.128.3 hidden
inet.0: 825 destinations, 950 routes (19 active, 0 holddown, 930 hidden)
Prefix Nexthop MED Lclpref AS path
0.0.0.0/0 172.16.1.1 100 420 I
6.1.0.0/16 172.16.1.1 100 420 I
. . .
The output conliims that the BGP ioutes auveitiseu Ly PBR aie in lact hiuuen at Bock.
This explains the lack ol iellection to othei clients, Lecause active ioutes only aie suLject
to auveitisement. The extensive switch is auueu to get as much uetail as possiLle, Lut
the output uoes not contain any auuitional inloimation:
[edit protocols bgp group 1282_clients]
lab@Bock# ...protocol bgp 10.20.128.3 hidden extensive
inet.0: 825 destinations, 950 routes (19 active, 0 holddown, 930 hidden)
0.0.0.0/0 (2 entries, 0 announced)
Nexthop: 172.16.1.1
Localpref: 100
AS path: 420 I
. . .
310 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
The limiteu set ol inloimation uisplayeu uoes incluue the ioute`s associateu BGP next
hop, which heie iepiesents the auuiess assigneu to Wheat loi use on its EBGP peeiing
to PBR. Recalling that the BGP ioute selection piocess Legins with a uecision as to
whethei the next hop is ieachaLle, you uisplay the ioute to 172.16.1.1 at Bock:
[edit protocols bgp group 1282_clients]
lab@Bock# run show route 172.16.1.1
The output, oi moie coiiectly the lack theieol, conliims that the issue is one ol BGP
next hop ieachaLility. The show route resolution unresolved detail commanu is useu
to conliim this lact:
[edit protocols bgp group 1282_clients]
lab@Bock# run show route resolution unresolved detail
Tree Index 1
133.3.0.0/16
Protocol Nexthop: 84.10.109.7
Indirect nexthop: 0 -
132.252.0.0/16
Protocol Nexthop: 84.10.109.7
Indirect nexthop: 0 -
. . . .
The uisplay conliims that ioute iellectoi Bock is unaLle to iesolve the EBGP next hop
attacheu to the ioutes it leains liom Yeast. Theie aie seveial common solutions to this
classic pioLlem. Recall that Ly uelault, the BGP next hop is upuateu only on EBGP
links. You coulu altei this Lehavioi with a next-hop self policy on the EBGP speakeis,
which is then applieu as an IBGP cxport policy to upuate the next hop ol each ioute as
it is ieauveitiseu to othei IBGP speakeis.
Nevei apply a next-hop self policy as impoit loi an EBGP session Le-
cause the iesulting ioutes appeai to Le loopeu anu aie hiuuen.
Anothei way to lix the unieachaLle next hop is to auveitise the EBGP peeiing suLnet
into youi IGP. You shoulu uo this Ly iunning a passive IGP instance on youi EBGP
peeiing links. The passive moue guaiantees that an aujacency cannot loim to the iemote
AS, which coulu Le veiy, veiy Lau (IGPs lack policy contiols loi inteiuomain iouting,
anu comLining two laige IGPs into a single, laigei one may push iouteis Leyonu theii
limits).
An IBGP expoit to allect next-hop self Lehavioi solves the pioLlem. The changes maue
to PBR`s conliguiation aie also placeu into ellect at Yeast:
[edit]
lab@PBR# show policy-options policy-statement next_hop_self
term 1 {
from protocol bgp;
then {
next-hop self;
Multihome Beer-Co | 311
}
}
[edit]
lab@PBR# show protocols bgp group 1282_clients export
export next_hop_self;
The BGP summaiy uisplay Lack at Stout conliims that ioute iellection is woiking:
[edit protocols bgp group 1282_clients]
lab@stout# run show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 1612 806 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Damped...
10.10.12.2 1282 163 84 0 0 41:18 806/806/0
0/0/0
10.10.12.3 1282 259 92 0 0 44:56 0/806/0
0/0/0
The highlights show that Stout is ieceiving the same numLei ol BGP ioutes liom Loth
iellectois, which is expecteu. Recall that BGP tieLieaking iules pielei ioutes leaineu
liom the ioutei with the lowest RID, which is Porter in this case. You coulu enaLle
multipath loi IBGP to install Loth copies ol the ioutes into the loiwaiuing taLle. How-
evei, in this example, it uoes not Luy anything, as Loth copies point to the same loi-
waiuing next hop auuiess. Ve will iely on the IGP to peiloim loau Lalancing il theie
aie multiple egual cost paths. Details loi the customei ioute to Biewei Inc. aie uisplayeu
to conliim vaiious attiiLutes loi the ioute, incluuing why the copy leaineu liom
Porter is pieleiieu:
[edit protocols bgp group 1282_clients]
lab@stout# run show route 192.168.34.0 detail
inet.0: 826 destinations, 1632 routes (826 active, 0 holddown, 0 hidden)
192.168.34.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-121
Next-hop reference count: 2732
Source: 10.10.12.2
Next hop: 10.20.131.1 via ge-0/0/1.1331, selected
Protocol next hop: 10.30.1.1
Indirect next hop: 8791128 262144
State: <Active Int Ext>
Local AS: 1282 Peer AS: 1282
Age: 30 Metric2: 2
Task: BGP_1282.10.10.12.2+179
Announcement bits (2): 0-KRT 4-Resolve tree 1
AS path: 34 I (Originator) Cluster list: 1.2.8.2
AS path: Originator ID: 10.30.1.1
Communities: bandwidth:1287:12500000
Localpref: 120
Router ID: 10.10.12.2
BGP Preference: 170/-121
Next-hop reference count: 2732
312 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
Source: 10.10.12.3
Next hop: 10.20.131.1 via ge-0/0/1.1331, selected
Protocol next hop: 10.30.1.1
Indirect next hop: 8791128 262144
State: <NotBest Int Ext>
Inactive reason: Router ID
Local AS: 1282 Peer AS: 1282
Age: 4:29 Metric2: 2
Task: BGP_1282.10.10.12.3+179
AS path: 34 I (Originator) Cluster list: 1.2.8.2
AS path: Originator ID: 10.30.1.1
Communities: bandwidth:1287:12500000
Localpref: 120
Router ID: 10.10.12.3
Confirm Outbound Policy Operation
The EBGP anu IBGP peeiing is estaLlisheu within youi netwoik, anu ioute iellection
is conliimeu opeiational. The veiilication ol youi output policy is peiloimeu at IBGP
speakei Stout. Recall that Ale anu Lager use the OSPF uelault to loiwaiu packets to
theii iespective ABRs, which in tuin now have BGP iouting state anu aie expecteu to
make the coiiect outLounu loiwaiuing uecision.
Things stait with tiaceioutes to customei netwoiks in peeiing ASs Boignet anu Botnet:
lab@stout> traceroute 192.168.42.1
traceroute to 192.168.42.1 (192.168.42.1), 30 hops max, 40 byte packets
1 10.20.129.2 (10.20.129.2) 6.360 ms 59.843 ms 15.233 ms
2 172.16.1.1 (172.16.1.1) 10.191 ms !N 8.985 ms !N 10.114 ms !N
lab@stout> traceroute 192.168.34.1
traceroute to 192.168.34.1 (192.168.34.1), 30 hops max, 40 byte packets
1 10.20.131.1 (10.20.131.1) 40.976 ms 34.719 ms 2.141 ms
2 10.10.8.2 (10.10.8.2) 10.009 ms 18.695 ms 8.191 ms
3 84.10.109.7 (84.10.109.7) 32.183 ms !N 19.530 ms !N 19.790 ms !N
The iesults match the topological aspects ol Beei-Co`s outLounu policyStout is using
the specilic ioutes it has leaineu liom the EBGP peeiing iouteis to loiwaiu uiiectly to
the peei AS that owns the customei ioute. The point Leing stiesseu heie is that this
aspect ol outLounu policy is a siue ellect ol the ioute lilteiing peiloimeu at the EBGP-
speaking iouteis. Yeast, loi example, lilteis the copy ol Cap-Co`s 192.16S.+2/2+ ioute
when it is ieauveitiseu liom Botnet Lecause that ioute uiu not oiiginate within AS 3+.
This means that although theie aie two copies ol customei ioute 192.16S.+2/2+, Loth
copies iuentily the sanc BGP next hop, which is PBR in this example. Theie aie two
copies ol this ioute Lecause ol the ieuunuant ioute iellectoi uesign. Relei Lack to the
pievious show route uisplay loi lull uetails. The lollowing (lilteieu) uisplay calls out
that Loth copies ol the 192.16S.+2/2+ ioute point to the same BGP egiess point, uespite
Leing leaineu liom two uilleient iellectois:
lab@stout> show route 192.168.42.0 detail | match next
Next-hop reference count: 496
Multihome Beer-Co | 313
Next hop: 10.20.129.2 via ge-0/0/0.3141, selected
Protocol next hop: 10.20.128.3
Indirect next hop: 8791000 262142
Next-hop reference count: 496
Next hop: 10.20.129.2 via ge-0/0/0.3141, selected
Protocol next hop: 10.20.128.3
Indirect next hop: 8791000 262142
Things aie not so peilect when it comes to uestinations that aie lilteieu Ly Loth EBGP
speakeisloi example, the 192.16S.66/2+ Bottle Inc. ioute. Because the BGP speakeis
aie ielying on a leaineu uelault ioute, which has egual specilicity loi all such lilteieu
uestinations, special steps aie ieguiieu to meet the stateu outLounu policy to avoiu a
tieLieakei situation Letween the otheiwise egual-cost veisions ol the uelault ioute.
Recall that in this example, all IBGP speakeis shoulu pielei the uelault ioute leaineu
thiough PBR anu use the one leaineu liom Yeast only when the PBR session is uisiupteu.
The ioute to Bottle Inc. is shown at Stout:
lab@stout> show route 192.168.66.0 detail
inet.0: 577 destinations, 1134 routes (577 active, 0 holddown, 0 hidden)
0.0.0.0/0 (2 entries, 1 announced)
*BGP Preference: 170/-101
Next-hop reference count: 499
Source: 10.10.12.3
Next hop: 10.20.129.2 via ge-0/0/0.3141, selected
Protocol next hop: 10.20.128.3
Indirect next hop: 8791000 262142
State: <Active Int Ext>
Local AS: 1282 Peer AS: 1282
Age: 1:15 Metric2: 1
Task: BGP_1282.10.10.12.3+179
Announcement bits (2): 0-KRT 4-Resolve tree 1
AS path: 420 I (Originator) Cluster list: 1.2.8.2
AS path: Originator ID: 10.20.128.3
Localpref: 100
Router ID: 10.10.12.3
BGP Preference: 170/-101
Next-hop reference count: 1729
Source: 10.10.12.2
Next hop: 10.20.131.1 via ge-0/0/1.1331, selected
Protocol next hop: 10.30.1.1
Indirect next hop: 8791128 262144
State: <Int Ext>
Inactive reason: IGP metric
Local AS: 1282 Peer AS: 1282
Age: 1:15 Metric2: 2
Task: BGP_1282.10.10.12.2+179
AS path: 34 I (Originator) Cluster list: 1.2.8.2
AS path: Originator ID: 10.30.1.1
Communities: bandwidth:1287:12500000
Localpref: 100
Router ID: 10.10.12.2
314 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
The output conliims that Stout ielies on a BGP leaineu uelault to ieach uestinations
in nonaujacent ASs. The highlights show that Stout has leaineu ol two copies ol the
uelault, one iellecteu Ly Bock that oiiginates at PBR anu the othei via Porter, which
oiiginateu at Yeast. In this example, the lailuie to aujust BGP attiiLutes has lelt ioute
selection to the uelault algoiithm, which heie selects the lowest metiic IGP path, given
that all othei lactois up to that uecision step aie the same. Youi goal is to ensuie that
all IBGP speakeis pielei the uelault auveitiseu Ly PBRthis is not the case, so auuitional
policy action is neeueu to meet the uesign ieguiiements. The most uiiect way to altei
which BGP ioutes aie pieleiieu Ly IBGP speakeis is to aujust local pieleience:
lab@PBR# show protocols bgp group 1282_clients export
export [ next_hop_self prefer_Borgnet_transit ];
[edit]
lab@PBR# show policy-options policy-statement prefer_Borgnet_transit
term 1 {
from {
protocol bgp;
route-filter 0.0.0.0/0 exact;
}
then {
local-preference 110;
}
}
Altei committing the change, the iesult is conliimeu Lack at Stout:
lab@stout> show route 192.168.66.0
inet.0: 577 destinations, 1134 routes (577 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 00:02:47, localpref 110, from 10.10.12.2
AS path: 420 I
> to 10.20.129.2 via ge-0/0/0.3141
[BGP/170] 00:02:47, localpref 110, from 10.10.12.3
AS path: 420 I
> to 10.20.129.2 via ge-0/0/0.3141
Why Only Two Copies of the Default?
You may Le wonueiing why a ioutei such as Stout is not ieceiving loui copies ol the
BGP uelault ioute. Given that it ieceives two copies ol the 192.16S.+2/2+ ioute that is
auveitiseu on|y Ly PBR, you might expect twice as many copies loi a ioute that is sent
Ly both PBR anu Yeast. The answei lies in the active ioute selection piocess peiloimeu
Ly the iellectois. Each iellectoi ieauveitises only ioutes that aie locally active. Because
each iellectoi leains ol ioute 192.16S.+2/2+ liom a single souice (PBR), each iellectoi
installs the ioute as active anu Loth iellect it to theii clients. In contiast, the uelault
ioute is leaineu Ly each iellectoi liom Loth PBR anu Yeast, anu each iellectoi chooses
the copy it consiueis Lest, iellecting only that copy to its clients.
Multihome Beer-Co | 315
As a iesult, il the cuiient netwoik weie to lose one ol its EBGP speakeis, theie woulu
sti|| Le two copies ol the uelault ioute at each client. The uilleience is that now Loth
copies will Le the same ioute, as auveitiseu Ly the iemaining EBGP speakei. The same
iesult occuis il the local pieleience ol one uelault ioute is alteieu, causing it to Le
pieleiieu Ly Loth iellectois.
Theie aie still two copies ol the uelault ioute, one leaineu liom each iellectoi, Lut now
Loth copies iuentily PBR as the piotocol next hop. Theieloie, using eithei veision iesults
in a loiwaiuing path that uiiects tiallic to nonaujacent ASs ovei the Boignet peeiing.
Both iellectois now pielei the ioute auveitiseu Ly PBR Lecause ol its highei pieleience
value. A tiaceioute is peiloimeu to conliim a noimal loiwaiuing path, anu then the
EBGP session at PBR is cleaieu to conliim lallLack to Botnet:
lab@stout> traceroute 192.168.66.1
traceroute to 192.168.66.1 (192.168.66.1), 30 hops max, 40 byte packets
1 10.20.129.2 (10.20.129.2) 9.087 ms 8.966 ms 29.973 ms
2 172.16.1.1 (172.16.1.1) 9.289 ms 9.886 ms 9.868 ms
3 172.16.2.2 (172.16.2.2) 30.022 ms !N 15.394 ms !N 23.853 ms !N
The EBGP session is cleai at PBR:
[edit]
lab@PBR# run clear bgp neighbor 172.16.1.1
Cleared 1 connections
Anu now the tiaceioute takes the seconuaiy path via Botnet:
lab@stout> traceroute 192.168.66.1
traceroute to 192.168.66.1 (192.168.66.1), 30 hops max, 40 byte packets
1 10.20.131.1 (10.20.131.1) 39.481 ms 18.973 ms 20.043 ms
2 10.10.8.2 (10.10.8.2) 159.897 ms 199.206 ms 10.097 ms
3 84.10.109.7 (84.10.109.7) 39.908 ms 19.261 ms 13.438 ms
4 84.10.110.1 (84.10.110.1) 16.441 ms !N 44.843 ms !N 34.459 ms !N
Altei a lew minutes, PBR`s EBGP session shoulu Le ieestaLlisheu, making its uelault
once again pieleiieu, causing tiansit tiallic to switch Lack (ieveitive Lehavioi) to the
Boignet peeiing:
lab@stout> traceroute 192.168.66.1
traceroute to 192.168.66.1 (192.168.66.1), 30 hops max, 40 byte packets
1 10.20.129.2 (10.20.129.2) 9.980 ms 8.803 ms 9.848 ms
2 172.16.1.1 (172.16.1.1) 20.031 ms 29.300 ms 19.929 ms
3 172.16.2.2 (172.16.2.2) 9.851 ms !N 9.394 ms !N 29.928 ms !N
The linal veiilication is peiloimeu at stuL ioutei Lager, which has no BGP ioutes anu
uses the stuL aiea uelault to ieach its ABR:
lab@Lager> show route protocol bgp
inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
No BGP ioutes aie piesent Lecause Lager is not iunning BGP:
lab@Lager> show route 192.168.66.0
316 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/10] 05:19:25, metric 11
> to 10.10.131.2 via ge-0/0/0.2131
lab@Lager> show route 192.168.34.0
inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/10] 05:19:30, metric 11
> to 10.10.131.2 via ge-0/0/0.2131
Lager uses the OSPF uelault to ieach all AS exteinal uestinations:
lab@Lager> traceroute 192.168.34.1
traceroute to 192.168.34.1 (192.168.34.1), 30 hops max, 40 byte packets
1 10.10.131.2 (10.10.131.2) 10.507 ms 10.555 ms 9.706 ms
2 10.20.131.1 (10.20.131.1) 17.896 ms 21.192 ms 20.007 ms
3 10.10.8.2 (10.10.8.2) 39.897 ms 19.354 ms 20.043 ms
4 84.10.109.7 (84.10.109.7) 19.780 ms !N 19.619 ms !N 19.887 ms !N
lab@Lager> traceroute 192.168.42.1
traceroute to 192.168.42.1 (192.168.42.1), 30 hops max, 40 byte packets
1 10.10.131.2 (10.10.131.2) 8.841 ms 8.663 ms 9.940 ms
2 10.20.129.2 (10.20.129.2) 19.825 ms 9.554 ms 9.726 ms
3 172.16.1.1 (172.16.1.1) 9.979 ms !N 9.345 ms !N 10.121 ms !N
lab@Lager> traceroute 192.168.66.1
traceroute to 192.168.66.1 (192.168.66.1), 30 hops max, 40 byte packets
1 10.10.131.2 (10.10.131.2) 8.731 ms 8.681 ms 10.097 ms
2 10.20.129.2 (10.20.129.2) 19.732 ms 9.801 ms 9.650 ms
3 172.16.1.1 (172.16.1.1) 9.872 ms 9.606 ms 9.856 ms
4 172.16.2.2 (172.16.2.2) 39.847 ms !N 19.351 ms !N 29.992 ms !N
Lager loiwaius all exteinal tiallic to its ABR. The ABR (PBR in this case) then uses its
BGP knowleuge to make an optimal loiwaiuing uecision that auheies to Beei-Co`s
outLounu iouting policy. This completes the multihomeu outLounu iouting policy
scenaiio.
Dual-Homing and Outbound Policy Summary
In this section, you auueu a seconu EBGP peeiing anu ueployeu IBGP on the necessaiy
suLset ol iouteis within the Beei-Co netwoik. A ieuunuant ioute iellection topology
was useu to minimize the numLei ol IBGP peeiings while eliminating single points ol
lailuie.
Vith multihoming in place, you implementeu an outLounu policy that was a hyLiiu
ol the topology uiiven anu stiict piimaiy/seconuaiy mouels. This was achieveu via an
impoit policy that accepteu only a suLset ol the ioutes auveitiseu Ly youi exteinal BGP
peeis. This lilteiing allows an optimal iouting uecision loi the specilic ioutes that aie
accepteu, while signilicantly ieuucing haiuwaie ieguiiements associateu with hanuling
Multihome Beer-Co | 317
lull BGP leeus. The use ol local pieleience ensuieu that a specilic BGP leaineu uelault
ioute is useu loi all othei uestinations, which in tuin pioviueu the stiict piimaiy/
seconuaiy (with ieveitive Lehavioi) aspect ol the sample outLounu policy.
The next section Luilus upon this lounuation Ly uelving into the mechanics ol imple-
menting a typical inLounu policy Ly manipulating BGP path attiiLutes thiough the use
ol BGP expoit policy.
Inbound Policy
Releiiing Lack to Figuie 7-9, it stiikes you that the Beei-Co netwoik has come a long
way in iecent weeks. The netwoik has migiateu liom Leing single-homeu to one pio-
viuei to Leing multihomeu to multiple pioviueis, anu you have successlully imple-
menteu a hyLiiu outLounu policy Laseu on a topology-uiiven mouel loi peeis anu a
piimaiy/seconuaiy mouel loi tiansit. Vith these aspects ol BGP opeiation in check,
attention is locuseu on youi company`s inLounu policy goals.
The use ol statelul liiewalls anu NAT at the EBGP egiess points gieatly Lenelits liom
symmetiic iouting. By this, we mean that il a packet is iouteu to Destination X out ol
ioutei PBR, iueally the iesponse tiallic will ietuin along the same path to ingiess Lack
on ioutei PBR. The symmetiic iouting paths tenu to piouuce symmetiic peiloimance,
which can Le ieason enough when asymmetiic peeiing links aie piesent, Lut the ieal
goal heie is to ensuie that iesponse tiallic coiiectly matches against the uynamic state
cieateu when the outLounu ieguest was piocesseu Ly the Loiuei ioutei`s statelul
liiewall.
The uesign goals loi inLounu policy inuicate they shoulu miiioi youi outLounu
policynamely, that peeis shoulu ioute uiiectly into youi AS while tiansit tiallic
shoulu aiiive via the peeiing with Boignet when availaLle. In the pievious section, local
pieleience maue steeiing tiallic towaiu the uesiieu EBGP speakei/egiess point a
stiaightloiwaiu mattei. But as pieviously stateu, it`s geneially guite easy to contiol how
tiallic llows within youi own netwoik. The ieal ait anu linesse ol BGP policy comes to
Leai when the goal is to inlluence tiallic llow in a iemote netwoik that is not unuei
youi uiiect contiol. The Beei-Co inLounu policy shoulu pioviue the lollowing Lehavioi:
Topological policy loi peeis, which shoulu ioute uiiectly into Beei-Co when the
peeiing session is up
Reveitive piimaiy/seconuaiy tiallic loi nonaujacent ASs, which shoulu ingiess at
PBR when that peeiing session is up
TaLle 7-2 summaiizes the BGP attiiLutes that can impact the policy/iouting actions ol
a iemote netwoik. As a iule, attiiLutes that aie evaluateu soonei in the path selection
piocess aie moie likely to have an impact than those that aie evaluateu latei. Foi ex-
ample, alteiing local pieleience, which is evaluateu at step 2 ol 10, is likely to have
some impact, wheieas changing oiigin coue, which is evaluateu at step + ol 10, is less
318 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
likely to change a peei`s loiwaiuing Lehavioi. The taLle uses paientheses to iuentily at
which step ol the 10-step uecision piocess a given attiiLute is evaluateu. Relei Lack to
BGP Path Selection on page 253 loi uetails on these steps.
Tab|c 7-2. BGP attributcs that inj|ucncc spca|crs in othcr nctwor|s
Attribute Mechanism Scope/caveat
AS path AS path prepending impacts AS path selection
criteria (step 3 of 10).
Global, in that once added, ASNs cannot be removed from
the AS path list.
Origin Altering origin impacts path selection criteria
(step 4 of 10).
Global, but can be overwritten by intervening networks.
MED Altering MED impacts MED selection criteria
(step 5 of 10).
Adjacent AS only; MEDs are nontransitive. Generally, useful
only for influencing link selection when all links terminate
at the same adjacent AS.
Communities Tagged routes are treated to some pre-agreed
action, such as altered local preference.
Generally adjacent AS only. Many network operators strip all
community tags upon ingress to their network, and again at
egress.
It waiiants iestating that in all cases, the ieceiving ASs` policy can thwait even the most
skilleu attempts at contiolling theii outLounu iouting. Foi example, they can set a
highei local pieleience, which means that AS path length is nevei even consiueieu,
which in tuin negates any AS path piepenuing action you may peiloim in the hope ol
alteiing theii path selection. This is why a uetaileu unueistanuing ol each peei AS`s
policies, anu a goou woiking ielationship with theii auministiatois, is always Lenelicial.
The most uillicult aspect ol the uesiieu inLounu policy is the neeu to inlluence the
iouting actions ol Daiknet, which uoes not peei uiiectly with youi AS. The goal is to
make Daiknet pielei the 10/S aggiegate it leains thiough Boignet such that it uses the
auveitisement leaineu liom Botnet only when the loimei is unavailaLle.
Using MED is out ol the guestion heie Lecause the MED, Leing nontiansitive, uoes not
tiansit the netwoiks you peei with. Also, PBR has a single attachment to Boignet, so
theie is no use loi MED theie. MED coulu Le useu on the Yeast/Botnet peeiing to help
steei ingiess tiallic ovei the high-speeu link, Lut this is not the cuiient locus. Com-
munities aie likely not an option Lecause you aie not a Daiknet customei, anu it`s guite
likely that they uo not take action on communities attacheu to noncustomei ioutes;
Lesiues, communities may Le stiippeu when the ioutes aie exchangeu Letween Boignet
anu Daiknet.
Beloie settling on a solution, it`s noteu that Loth ol Beei-Co`s BGP peeis have a puL-
lisheu policy iegaiuing the use ol customei ioutes with specilic community tags. This
policy iesults in a mouilieu local pieleience setting within that peei`s netwoik.
TaLle 7-3 pioviues the community-to-local pieleience mappings.
Inbound Policy | 319
Tab|c 7-3. Pccr AS connunity-to-|oca| prcjcrcncc nappings
Community value Modified local preference
ASN:110 110
ASN:100 100
ASN:90 90
ASN:80 80
Altei caielul consiueiation, it appeais that the main pioLlem in achieving the uesiieu
inLounu Lehavioi lies with the ioute selection algoiithm in nonaujacent AS Daiknet.
Because you uo not peei uiiectly with this AS, the use ol MED, anu likely communities,
is out. This naiiows youi choice to AS path piepenuing as the piimaiy mechanism loi
inlluencing path selection within AS 666.
Figuie 7-11 shows the state ol allaiis with iegaiu to path selection loi the 10/S pielix
in ioutei Darknet.
Iigurc 7-11. 10/8 routc sc|cction in Dar|nct
The liguie shows that Daiknet ieceives BGP upuates loi Beei-Co`s 10/S aggiegate liom
Loth AS +20 anu AS 3+. Because all attiiLutes aie egual in this example, incluuing the
AS path length, the active path selecteu at Water is ueteimineu Ly which auveitisement
is leaineu liist. To uemonstiate, the 10/S ioute is uisplayeu at Water:
[edit]
lab@Water# run show route 10/8 detail
inet.0: 812 destinations, 1324 routes (812 active, 0 holddown, 0 hidden)
10.0.0.0/8 (2 entries, 1 announced)
320 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
*BGP Preference: 170/-101
Next-hop reference count: 946
Source: 84.10.110.2
Next hop: 84.10.110.2 via ge-0/0/0.3243, selected
State: <Active Ext>
Local AS: 666 Peer AS: 34
Age: 41:35
Task: BGP_34.84.10.110.2+4664
Announcement bits (2): 0-KRT 1-BGP RT Background
AS path: 34 1282 I Aggregator: 1282 10.30.1.1
Localpref: 100
Router ID: 84.10.109.1
BGP Preference: 170/-101
Next-hop reference count: 682
Source: 172.16.2.1
Next hop: 172.16.2.1 via ge-0/0/0.423, selected
State: <Ext>
Inactive reason: Active preferred
Local AS: 666 Peer AS: 420
Age: 39:41
Task: BGP_420.172.16.2.1+179
AS path: 420 1282 I Aggregator: 1282 10.20.128.3
Localpref: 100
Router ID: 172.16.1.3
The output shows that Water installeu the path thiough AS 3+ as the active path, anu
that the uesiieu piimaiy path is cuiiently not pieleiieu, simply Lecause it was not
leaineu liist. Recall that loi an EBGP leaineu ioute, step 9 ol the active ioute selection
piocess, which noimally pieleis the lowei RID, is not peiloimeu uue to MED oscillation
issues. Insteau, EBGP leaineu ioutes eliminate steps 9 anu 10 to simply pielei the ioute
that is leaineu liist. Because this conuition is timing-uepenuent, il something happens
to the 10/S auveitisement liom Botnet, the situation is ieveiseu:
[edit]
lab@hops# run clear bgp neighbor 84.10.110.1
Cleared 1 connections
Altei waiting loi the Botnet/Daiknet EBGP peeiing to ieloim, the path to 10/S is again
uisplayeu at Water:
[edit]
lab@Water# run show route 10/8
inet.0: 812 destinations, 1370 routes (812 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/8 *[BGP/170] 00:43:43, localpref 100
AS path: 420 1282 I
> to 172.16.2.1 via ge-0/0/0.423
[BGP/170] 00:00:29, localpref 100
AS path: 34 1282 I
> to 84.10.110.2 via ge-0/0/0.3243
Inbound Policy | 321
The uisplay conliims that the tieLieaking action ol pielei liist-leaineu is not going to
ieliaLly piouuce the uesiieu inLounu policy; noi woulu ielying on the RID/peeiing
auuiess tieLieakeis, loi that mattei. This looks like a classic example ol how AS path
piepenuing can help to steei path selection Ly iemote netwoiksin this case, one that
you uo not even peei with. Il the expoit policy at Yeast is alteieu to auu an extia instance
ol the local AS numLei, the AS path length selection ciiteiion shoulu iesult in the path
thiough AS +20 always Leing pieleiieu Ly Daiknet iouteis when availaLle.
AS Path Prepend to Influence Nonadjacent AS Path Selection
Pievious analysis ol the policy showeu that incieasing the AS path length loi the 10/S
pielix that Daiknet leains liom Botnet shoulu iesult in the uesiieu Lehavioi ol
nonaujacent ASs iouting to youi netwoik using Botnet as the piimaiy tiansit AS.
The existing as_34_export policy is uisplayeu at Yeast:
[edit]
lab@Yeast# show policy-options policy-statement as_34_export
term 1 {
from {
protocol aggregate;
route-filter 10.0.0.0/8 exact;
}
then accept;
}
The as_34_export policy is mouilieu to auu two extia instances ol ASN 12S2 to the 10/S
upuateLaseu on Figuie 7-11, it appeais that only one instance is ieguiieu, Lut extia
pauuing shoulu help to ensuie that Daiknet pieleis the path thiough Boignet anu pio-
viues an auuitional salety maigin to accommouate the potential loi topology changes
Letween Boignet anu Daiknet. Such a iouting change might iesult in tiansit thiough
auuitional ASs anu a coiiesponuing inciease in the AS path length ovei the pieleiieu
path:
[edit policy-options policy-statement as_34_export]
lab@Yeast# show
term 1 {
from {
protocol aggregate;
route-filter 10.0.0.0/8 exact;
}
then {
as-path-prepend "1282 1282";
accept;
}
}
The ellects aie examineu liom the peispective ol ioutei Water in the Daiknet AS:
[edit]
lab@Water# run show route 10/8 detail
322 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
inet.0: 812 destinations, 1370 routes (812 active, 0 holddown, 0 hidden)
10.0.0.0/8 (2 entries, 1 announced)
*BGP Preference: 170/-101
Next-hop reference count: 684
Source: 172.16.2.1
Next hop: 172.16.2.1 via ge-0/0/0.423, selected
State: <Active Ext>
Local AS: 666 Peer AS: 420
Age: 53:05
Task: BGP_420.172.16.2.1+179
Announcement bits (2): 0-KRT 1-BGP RT Background
AS path: 420 1282 I Aggregator: 1282 10.20.128.3
Localpref: 100
Router ID: 172.16.1.3
BGP Preference: 170/-101
Next-hop reference count: 990
Source: 84.10.110.2
Next hop: 84.10.110.2 via ge-0/0/0.3243, selected
State: <Ext>
Inactive reason: AS path
Local AS: 666 Peer AS: 34
Age: 59
Task: BGP_34.84.10.110.2+4730
AS path: 34 1282 1282 I Aggregator: 1282 10.30.1.1
Localpref: 100
Router ID: 84.10.109.1
The output conliims that chance has Leen iemoveu liom the path selection piocess loi
the 10/S pielix at Water. The longei AS path in the 10/S pielix leaineu liom the Botnet
AS ensuies that AS 666 always pieleis to ioute thiough Boignet to ieach Beei-Co, unless
that path is withuiawn (uue to pioLlems with the PBRWheat peeiing), at which point
it lalls Lack to the Botnet path.
To the casual oLseivei, Beei-Co has met its inLounu policy goals, all with a single-line
auuition to an existing expoit policy to allect AS path piepenuing. BGP policy is not
ieally that haiu, it woulu seem. Beloie heauing out the uooi, you ueciue to conliim
lailovei Lehavioi. This Legins Ly ueactivating the seconuaiy EBGP session to conliim
that all tiallic aiiives at the Boignet peeiing:
[edit]
lab@Yeast# deactivate protocols bgp group as_34
[edit]
lab@Yeast# commit
Tiaceioutes aie now peiloimeu liom iouteis within the aujacent anu nonaujacent ASs.
In most cases, you will neeu to inspect each AS`s iouting view, peihaps thiough a
looking glass seivice, to conliim theii loiwaiuing paths.
Inbound Policy | 323
What Is a Looking Glass?
A looking glass is Lasically a puLlicly accessiLle ioute seivei that allows you to view
Inteinet iouting, liom the peispective ol that paiticulai ioute seivei. You use a looking
glass to see the ellects ol that netwoik`s impoit policy anu active ioute selection piocess,
Ly uisplaying which BGP paths it has installeu as active. You can also gauge the ielative
staLility ol a pielix, liom the view ol that looking glass, Ly examining how long a ioute
has Leen known. The lollowing example makes use ol an ATeT looking glass, telnet
to ioute-seivei.ip.att.net, to uisplay its view ol the ioute to ]unipei Netwoiks:
-------------- route-server.ip.att.net ---------------
User Access Verification Username: rviews
route-server> sho ip rou juniper.net
Routing entry for 207.17.136.0/22, supernet
Known via "bgp 65000", distance 20, metric 0
Tag 7018, type external
Last update from 12.123.1.236 2w3d ago
Routing Descriptor Blocks:
* 12.123.1.236, from 12.123.1.236, 2w3d ago
Route metric is 0, traffic share count is 1
AS Hops 3
Route tag 7018
route-server> sho ip bgp 207.17.136.0/22
BGP routing table entry for 207.17.136.0/22, version 181930
Paths: (18 available, best #13, table Default-IP-Routing-Table)
Not advertised to any peer
7018 2914 14203, (received & used)
12.123.29.249 from 12.123.29.249 (12.123.29.249)
Origin IGP, localpref 100, valid, external
Community: 7018:5000 7018:33051
. . .
The output suggests that ATeT has leaineu this ioute liom 1S uilleient speakeis, that
the pielix is staLle (given that the last upuate was moie than two weeks ago), anu that
the AS path to ieach this pielix liom within ATeT is 701S (ATeT VoiluNet), 291+
(Veiio), anu linally, 1+203 (]unipei Netwoiks itsell).
All iouteis in the test netwoik auveitise theii loopLacks (oi an encompassing aggiegate
ioute) into BGP. All tiaceioutes aie conuucteu Letween loopLack auuiesses Lecause
lull connectivity is expecteu among the pielixes useu loi loopLack auuiessing:
[edit]
lab@Wheat# run traceroute 10.10.12.2 source 172.16.1.3
traceroute to 10.10.12.2 (10.10.12.2), 30 hops max, 40 byte packets
1 172.16.1.2 (172.16.1.2) 17.316 ms 10.118 ms 21.751 ms
2 10.20.129.1 (10.20.129.1) 12.798 ms 9.507 ms 9.711 ms
3 10.10.12.2 (10.10.12.2) 16.981 ms 22.462 ms 19.689 ms
The tiaceioute to Porter`s loopLack auuiess succeeus liom within AS +20:
[edit]
lab@Water# run traceroute 10.10.12.2 source 64.8.12.1
traceroute to 10.10.12.2 (10.10.12.2), 30 hops max, 40 byte packets
1 172.16.2.1 (172.16.2.1) 106.100 ms 17.772 ms 10.472 ms
324 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
D
o
2 172.16.1.2 (172.16.1.2) 9.423 ms 9.373 ms 9.842 ms
3 10.20.129.1 (10.20.129.1) 20.042 ms 39.411 ms 19.786 ms
4 10.10.12.2 (10.10.12.2) 10.109 ms 9.390 ms 94.337 ms
The tiaceioute to Porter`s loopLack auuiess succeeus liom within AS 66:
[edit]
lab@hops# run traceroute 10.10.12.2 source 84.10.109.1
traceroute to 10.10.12.2 (10.10.12.2) from 84.10.109.1, 30 hops max, 40 byte packets
1 84.10.110.1 45.013 ms 125.144 ms 25.062 ms
2 172.16.2.1 8.442 ms 19.978 ms 9.940 ms
3 172.16.1.2 30.019 ms 9.885 ms 9.849 ms
4 10.20.129.1 16.135 ms 10.130 ms 13.433 ms
5 10.10.12.2 15.628 ms 24.492 ms 16.888 ms
Anu linally, the tiaceioute to Porter`s loopLack auuiess succeeus liom within AS 3+.
So lai so goou, so the EBGP peeiing session to AS 3+ is ieactivateu. Altei waiting loi
the EBGP session to Botnet to ie-loim, the tiaceioutes aie iepeateu:
[edit]
lab@Wheat# run traceroute 10.10.12.2 source 172.16.1.3
traceroute to 10.10.12.2 (10.10.12.2), 30 hops max, 40 byte packets
1 172.16.1.2 (172.16.1.2) 9.914 ms 8.950 ms 9.571 ms
2 10.20.129.1 (10.20.129.1) 19.977 ms 19.534 ms 19.824 ms
3 10.10.12.2 (10.10.12.2) 9.886 ms 9.498 ms 9.848 ms
lab@Water> traceroute 10.10.12.2 source 64.8.12.1
traceroute to 10.10.12.2 (10.10.12.2), 30 hops max, 40 byte packets
1 172.16.2.1 (172.16.2.1) 19.317 ms 12.022 ms 16.594 ms
2 172.16.1.2 (172.16.1.2) 9.889 ms 9.364 ms 10.281 ms
3 10.20.129.1 (10.20.129.1) 19.596 ms 19.528 ms 7.891 ms
4 10.10.12.2 (10.10.12.2) 21.967 ms 49.523 ms 9.720 ms
The iesults liom Boignet anu Daiknet aie as Leloie, anu Loth aie as expecteu. Things
aie not iueal liom the peispective loi Botnet, howevei:
[edit]
lab@hops# run traceroute 10.10.12.2 source 84.10.109.1
traceroute to 10.10.12.2 (10.10.12.2) from 84.10.109.1, 30 hops max, 40 byte packets
1 84.10.110.1 (84.10.110.1) 8.589 ms 8.666 ms 10.118 ms
2 172.16.2.1 (172.16.2.1) 29.935 ms 19.230 ms 20.005 ms
3 172.16.1.2 (172.16.1.2) 20.021 ms 19.588 ms 19.710 ms
4 10.20.129.1 (10.20.129.1) 9.916 ms 9.298 ms 10.128 ms
5 10.10.12.2 (10.10.12.2) 21.422 ms 17.796 ms 14.098 ms
The tiaceioute liom Botnet cleaily shows that the tiallic is lailing to aiiive at the peeiing
exchange loi that AS, iesulting in extia AS hops as the tiallic is uiiecteu ovei the piimaiy
path. This is a violation ol the uesiieu inLounu policy. Displaying the ioute to 10/S at
Botnet conliims the pioLlem anu sheus lights on its cause:
[edit]
lab@hops# run show route 10/8 detail
inet.0: 817 destinations, 1069 routes (817 active, 0 holddown, 0 hidden)
10.0.0.0/8 (3 entries, 1 announced)
*BGP Preference: 170/-101
Inbound Policy | 325
Next-hop reference count: 750
Source: 84.10.110.1
Next hop: 84.10.110.1 via ge-0/0/0.3243, selected
State: <Active Ext>
Local AS: 34 Peer AS: 666
Age: 43:41
Task: BGP_666.84.10.110.1+179
Announcement bits (2): 0-KRT 2-BGP RT Background
AS path: 666 420 1282 I Aggregator: 1282 10.20.128.3
Localpref: 100
Router ID: 64.8.12.1
BGP Preference: 170/-101
Next-hop reference count: 126
Source: 84.10.109.8
Next hop: 84.10.109.8 via ge-0/0/0.3233, selected
State: <Ext>
Inactive reason: Active preferred
Local AS: 34 Peer AS: 1282
Age: 4:36
Task: BGP_1282.84.10.109.8+2957
AS path: 1282 1282 1282 I Aggregator: 1282 10.30.1.1
Localpref: 100
Router ID: 10.30.1.1
BGP Preference: 170/-101
Next-hop reference count: 126
Source: 84.10.113.0
Next hop: 84.10.113.0 via t1-2/0/2.0, selected
State: <NotBest Ext>
Inactive reason: Not Best in its group
Local AS: 34 Peer AS: 1282
Age: 4:32
Task: BGP_1282.84.10.113.0+3127
AS path: 1282 1282 1282 I Aggregator: 1282 10.30.1.1
Localpref: 100
Router ID: 10.30.1.1
IP inteinetwoiks aie complicateu systems, anu with any such systems, making a change
in one place can have unexpecteu conseguences somewheie else. Beloie you auueu AS
path piepenuing, Loth peei ASs hau no pioLlems pieleiiing Beei-Co`s 10/S aggiegate
as leaineu uiiectly liom Beei-Co. This was Lecause an AS path length ol 1 is veiy haiu
to Leat. The use ol AS path piepenuing, in an attempt to make Daiknet pielei the path
thiough the Boignet AS, has inauveitently alteieu the path selection in peei AS 3+.
Even woise is that this situation iesults in path selection that is tieu to the oiuei in
which ioutes aie leaineu. Timing-ielateu ioute selection issues aie uillicult to tiouLle-
shoot Lecause auministiative actions on one liontsay, attiiLute mouilicationmay
tiiggei a change in the oiuei that ioutes aie leaineu. This can easily leau to an incoiiect
Leliel that policy changes aie Lehinu the alteieu path selection, when in ieality things
may change Lack at the next outage. Foitunately, theie is a stiaightloiwaiu solution to
this pioLlem: community tags.
326 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
Use Communities to Influence Peer AS
Releiiing Lack to TaLle 7-3, notice that you can allect the local pieleience value within
youi peei ASs Ly attaching a specilic community to youi ioute upuates. Because local
pieleience is evaluateu Leloie AS path length, alteiing the local pieleience ol the 10/S
ioute within AS 3+ shoulu Le just the ticket. This change ensuies that AS 3+ always
pieleis the 10/S leaineu uiiectly liom the Beei-Co peeiing iegaiuless ol the ielateu AS
path length.
Youi changes Legin with the uelinition ol nameu communities. In this example, you
neeu to set the 10/S local pieleience to a value highei than 100, which is the uelault.
Heie, multiple communities aie uelineu, Lut only the 110 community uelinition is
ieguiieu anu useu:
[edit]
lab@Yeast# show policy-options
. . .
community 100 members 1282:100;
community 110 members 1282:110;
community 70 members 1282:70;
community 80 members 1282:80;
community 90 members 1282:90;
community bw_fast members bandwidth:1287:12500000000;
community bw_slow members bandwidth:1287:193000;
as-path 34_originate "^34$";
as-path 34_trans "^34.+$";
The existing as_34_export policy is alteieu to auu the appiopiiate community, which
is 110 in this example:
[edit policy-options policy-statement as_34_export]
lab@Yeast# show
term 1 {
from {
protocol aggregate;
route-filter 10.0.0.0/8 exact;
}
then {
community add 110;
as-path-prepend "1282 1282";
accept;
}
}
The iesults aie conliimeu at ioutei Hops in AS 3+:
[edit]
lab@hops# run show route 10/8 detail
inet.0: 817 destinations, 1069 routes (817 active, 0 holddown, 0 hidden)
10.0.0.0/8 (3 entries, 1 announced)
*BGP Preference: 170/-111
Next-hop reference count: 2
Source: 84.10.109.8
Inbound Policy | 327
Next hop: 84.10.109.8 via ge-0/0/0.3233
Next hop: 84.10.113.0 via t1-2/0/2.0, selected
State: <Active Ext>
Local AS: 34 Peer AS: 1282
Age: 12
Task: BGP_1282.84.10.109.8+2957
Announcement bits (2): 0-KRT 2-BGP RT Background
AS path: 1282 1282 1282 I Aggregator: 1282 10.30.1.1
Communities: 1282:110
Localpref: 110
Router ID: 10.30.1.1
BGP Preference: 170/-111
Next-hop reference count: 126
Source: 84.10.113.0
Next hop: 84.10.113.0 via t1-2/0/2.0, selected
State: <NotBest Ext>
Inactive reason: Update source
Local AS: 34 Peer AS: 1282
Age: 12
Task: BGP_1282.84.10.113.0+3127
AS path: 1282 1282 1282 I Aggregator: 1282 10.30.1.1
Communities: 1282:110
Localpref: 110
Router ID: 10.30.1.1
BGP Preference: 170/-101
Next-hop reference count: 749
Source: 84.10.110.1
Next hop: 84.10.110.1 via ge-0/0/0.3243, selected
State: <Ext>
Inactive reason: Local Preference
Local AS: 34 Peer AS: 666
Age: 1:11:39
Task: BGP_666.84.10.110.1+179
AS path: 666 420 1282 I Aggregator: 1282 10.20.128.3
Localpref: 100
Router ID: 64.8.12.1
Excellent! AS 3+ now pieleis the ioute leaineu uiiectly liom Beei-Co, anu it still has a
valiu alteinate path in the event ol BGP session uisiuption to Beei-Co. The piimaiy
peeiing link is now ueactivateu to veiily lailovei to the seconuaiy anu ieveision Lack
to the piimaiy upon iestoiation:
[edit]
lab@PBR# deactivate protocols bgp group as_420
Tiaceioutes aie now peiloimeu liom aujacent anu nonaujacent ASs:
[edit]
lab@Wheat# run traceroute 10.10.12.2 source 172.16.1.3
traceroute to 10.10.12.2 (10.10.12.2) from 172.16.1.3, 30 hops max, 40 byte packets
1 172.16.2.2 (172.16.2.2) 8.411 ms 8.980 ms 9.840 ms
2 84.10.110.2 (84.10.110.2) 20.057 ms 29.367 ms 9.886 ms
3 84.10.113.0 (84.10.113.0) 19.999 ms 39.343 ms 20.021 ms
4 10.10.12.2 (10.10.12.2) 13.796 ms 15.536 ms 19.873 ms
lab@Water> traceroute 10.10.12.2 source 64.8.12.1
328 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
traceroute to 10.10.12.2 (10.10.12.2) from 64.8.12.1, 30 hops max, 40 byte packets
1 84.10.110.2 (84.10.110.2) 30.620 ms 21.427 ms 19.623 ms
2 84.10.113.0 (84.10.113.0) 30.052 ms 16.285 ms 12.970 ms
3 10.10.12.2 (10.10.12.2) 20.066 ms 35.912 ms 13.312 ms
[edit]
lab@hops# run traceroute 10.10.12.2 source 84.10.109.1
traceroute to 10.10.12.2 (10.10.12.2) from 84.10.109.1, 30 hops max, 40 byte packets
1 84.10.113.0 (84.10.113.0) 8.924 ms 28.830 ms 9.856 ms
2 10.10.12.2 (10.10.12.2) 9.846 ms 9.697 ms 9.795 ms
The iesults piove continueu connectivity loi Loth aujacent anu nonaujacent ASs, with
all tiallic now aiiiving at the only lunctional peeiing exchange. The uesiieu lailovei
Lehavioi is woiking. The Boignet peeiing session is now ieactivateu to test the ieveitive
Lehavioi:
[edit]
lab@PBR# rollback 1
load complete
Altei session estaLlishment, tiaceioutes aie again peiloimeu to veiily ieveitive piimaiy
Lehavioi. Recall that the goal is to have peeis ioute uiiectly into AS 12S2 while non-
aujacent ASs ioute towaiu the Boignet peeiing to ingiess at PBR:
[edit]
lab@Wheat# run traceroute 10.10.12.2 source 172.16.1.3
traceroute to 10.10.12.2 (10.10.12.2) from 172.16.1.3, 30 hops max, 40 byte packets
1 172.16.1.2 (172.16.1.2) 19.252 ms 12.858 ms 16.050 ms
2 10.20.129.1 (10.20.129.1) 9.900 ms 9.498 ms 9.686 ms
3 10.10.12.2 (10.10.12.2) 19.985 ms 19.611 ms 19.615 ms
lab@Water> traceroute 10.10.12.2 source 64.8.12.1
traceroute to 10.10.12.2 (10.10.12.2) from 64.8.12.1, 30 hops max, 40 byte packets
1 172.16.2.1 (172.16.2.1) 9.220 ms 8.755 ms 29.928 ms
2 172.16.1.2 (172.16.1.2) 9.844 ms 9.609 ms 9.873 ms
3 10.20.129.1 (10.20.129.1) 29.962 ms 19.311 ms 20.003 ms
4 10.10.12.2 (10.10.12.2) 9.862 ms 29.366 ms 29.967 ms
[edit]
lab@hops# run traceroute 10.10.12.2 source 84.10.109.1
traceroute to 10.10.12.2 (10.10.12.2) from 84.10.109.1, 30 hops max, 40 byte packets
1 84.10.113.0 (84.10.113.0) 9.691 ms 8.756 ms 9.864 ms
2 10.10.12.2 (10.10.12.2) 19.969 ms 29.445 ms 9.859 ms
The iesults conliim uesiieu inLounu policy Lehavioi, theieLy concluuing the EBGP
multihomeu enteipiise iouting scenaiio. Foi completeness, the complete piotocols anu
policy stanzas loi EBGP iouteis PBR anu Yeast, iellectoi Porter, anu client Stout aie
shown.
Heie is ioutei PBR`s conliguiation:
[edit]
lab@PBR# show policy-options | no-more
policy-statement as_420_export {
term 1 {
Inbound Policy | 329
from {
protocol aggregate;
route-filter 10.0.0.0/8 exact;
}
then accept;
}
}
policy-statement as_420_import {
term 1 {
from {
protocol bgp;
as-path as_420_originate;
}
then accept;
}
term 2 {
then reject;
}
}
policy-statement next_hop_self {
term 1 {
from protocol bgp;
then {
next-hop self;
}
}
}
policy-statement prefer_Borgnet_transit {
term 1 {
from {
protocol bgp;
route-filter 0.0.0.0/0 exact;
}
then {
local-preference 110;
}
}
}
as-path as_420_originate "^420+$";
[edit]
lab@PBR# show protocols
bgp {
group as_420 {
type external;
import as_420_import;
export as_420_export;
neighbor 172.16.1.1 {
peer-as 420;
}
}
group 1282_clients {
type internal;
local-address 10.20.128.3;
export [ next_hop_self prefer_Borgnet_transit ];
330 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
neighbor 10.10.12.3;
neighbor 10.10.12.2;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.3141;
interface ge-0/0/0.1241;
}
area 0.0.0.1 {
stub default-metric 10;
interface ge-0/0/0.1141;
}
}
Heie is ioutei Yeast`s conliguiation:
[edit]
lab@Yeast# show policy-options | no-more
policy-statement as_34_export {
term 1 {
from {
protocol aggregate;
route-filter 10.0.0.0/8 exact;
}
then {
community add 110;
as-path-prepend "1282 1282";
accept;
}
}
}
policy-statement as_34_import {
term slow_peer {
from {
protocol bgp;
neighbor 84.10.113.1;
}
then {
community add bw_slow;
}
}
term fast_peer {
from {
protocol bgp;
neighbor 84.10.109.7;
}
then {
community add bw_fast;
}
}
}
policy-statement as_34_originate {
term 1 {
from {
protocol bgp;
Inbound Policy | 331
as-path 34_originate;
}
then accept;
}
term 2 {
then reject;
}
}
policy-statement lb_per_packet {
then {
load-balance per-packet;
accept;
}
}
policy-statement next_hop_self {
term 1 {
from protocol bgp;
then {
next-hop self;
}
}
}
community 100 members 1282:100;
community 110 members 1282:110;
community 70 members 1282:70;
community 80 members 1282:80;
community 90 members 1282:90;
community bw_fast members bandwidth:1287:12500000000;
community bw_slow members bandwidth:1287:193000;
as-path 34_originate "^34$";
as-path 34_trans "^34.+$";
[edit]
lab@Yeast# show protocols | no-more
bgp {
group as_34 {
type external;
import [ as_34_import as_34_originate ];
export as_34_export;
peer-as 34;
multipath;
neighbor 84.10.109.7;
neighbor 84.10.113.1;
}
group 1282_clients {
type internal;
local-address 10.30.1.1;
export next_hop_self;
neighbor 10.10.12.3;
neighbor 10.10.12.2;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/1.2332;
332 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
}
}
Heie is ioute iellectoi Porter`s conliguiation:
[edit]
lab@Porter# show policy-options
[edit]
lab@Porter# show protocols | no-more
bgp {
group 1282_rr {
type internal;
local-address 10.10.12.2;
neighbor 10.10.12.3;
}
group 1282_clients {
type internal;
local-address 10.10.12.2;
cluster 1.2.8.2;
neighbor 10.20.128.4;
neighbor 10.20.128.3;
neighbor 10.30.1.1;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/1.1331;
interface ge-0/0/1.2332;
interface t1-2/0/2.0;
}
}
Heie is client Stout`s conliguiation:
[edit]
lab@stout# show policy-options
[edit]
lab@stout# show protocols | no-more
bgp {
group 1282_clients {
type internal;
local-address 10.20.128.4;
neighbor 10.10.12.3;
neighbor 10.10.12.2;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.3141;
interface ge-0/0/1.1331;
}
area 0.0.0.2 {
stub default-metric 10;
interface ge-0/0/0.2131;
}
}
Inbound Policy | 333
BGP Inbound Policy Summary
This section uemonstiateu ways in which a uual-homeu enteipiise can manipulate BGP
path attiiLutes to achieve a uesiieu inLounu policy goal. The example uemonstiateu
the neeu loi Loth AS path manipulation anu the use ol BGP communities, which
woikeu togethei to inlluence the iouting uecisions ol Loth aujacent anu nonaujacent
ASs.
Conclusion
BGP can have a uiamatic impact on the opeiation ol an enteipiise netwoik when the
netwoik is multihomeu, anu even moie so when it is multihomeu to multiple pioviueis.
BGP itsell is not a veiy complex piotocol, Lut the myiiau ways in which its attiiLutes
aie acteu upon, anu the cascauing ellects ol auveitising only what the local speakei
consiueis the Lest ioute, olten leau to an unanticipateu iesult. To the uninitiateu, this
olten leaus to conlusion anu what might seem to Le unpieuictaLle Lehavioi. ]unos
soltwaie pioviues a complete set ol uiagnostic tools, liom the CLI`s opeiational moue
uisplays to the extensive piotocol tiacing, which makes most BGP pioLlems easy to
uiagnose. Foi example, the way the soltwaie uisplays why a given BGP path was not
selecteu makes changing the iesults loi that BGP uecision step a stiaightloiwaiu mattei;
that is, whatevei attiiLute causeu the ioute to lose shoulu Le mouilieu.
EBGP anu IBGP aie similai, Lut they have key uilleiences in the way they aie typically
conliguieu anu in how they opeiate. This chaptei uetaileu those uilleiences anu uem-
onstiateu typical EBGP physical peeiing anu IBGP loopLack-Laseu peeiing. Because
IBGP uoes not iewiite the next hop, you will olten neeu a next hop sell-policy oi some
othei methou ol auveitising the exteinal EBGP peeiing auuiess into youi IGP.
Biinging up BGP peeiings is ieally just the stait ol the piocess. BGP is all aLout policy
anu auministiative contiol ovei ioute exchanges, anu theieloie loiwaiuing paths. Out-
Lounu policy contiols how youi netwoik chooses to ieach uestinations anu is ielatively
easy to implement as you contiol all aspects ol youi own netwoik`s opeiation. InLounu
policy is lai tiickiei, Lecause heie you aie attempting to impact uecisions maue in
iemote ASs, ovei which you have no uiiect contiol. A uetaileu unueistanuing ol the
BGP attiiLutes that ieach into, anu Leyonu, othei netwoiks incieases the pioLaLility
that iemote netwoiks will Lenu to youi will, iesulting in ingiess tiallic patteins that
optimize those lactois that mattei most within youi oiganization.
The laige size ol BGP taLles means that caielul consiueiation shoulu Le leveleu as to
which iouteis neeu to iun the piotocol anu on the impoit policy that ueteimines which
pielixes aie accepteu. The caielul application ol policy can easily ieuuce a BGP taLle
liom moie than 230,000 ioutes to a moie manageaLle set that can Le uistiiLuteu among
lowei-enu iouteis. A paitial taLle can Le useu to make intelligent iouting uecisions that
optimize netwoik iesouices anu peiloimance. Vhen a lull BGP taLle is not leasiLle,
334 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
some loim ol a uelault ioute is useu to Lalance the iemaining pielixes oi to uiiect the
netwoik tiallic to a piimaiy egiess point as local policy uictates.
Route iellection is olten useu to ieuuce the Luiuen ol maintaining a lull IBGP mess
among a netwoik`s IBGP speakeis, anu when comLineu with ioute lilteiing, it allows
the ueployment ol BGP on even the smallest ol enteipiise iouteis.
Exam Topics
Ve examineu the lollowing Enteipiise Exam Topics in this chaptei:
Explain the use ol BGP.
Dilleientiate Letween IBGP anu EBGP sessions.
Policies to contiol ioute auveitisement.
Miscellaneous BGP conliguiation options.
Loau-Lalancing BGP ioutes.
ISP multihoming scenaiios.
Conliguie an IBGP ioute iellection topology.
Conliguie EBGP sessions.
Iuentily BGP attiiLutes that can Le mouilieu using policies.
Implement a BGP policy loi iouting tiallic ovei multiple ISP connections.
Chapter Review Questions
1. Vhat BGP attiiLute guaius against loops?
A. MED
B. Baiiing an IBGP speakei liom iesenuing IBGP upuates
C. Clustei ID
D. AS path
2. Vhat BGP attiiLute is most likely to inlluence egiess liom youi AS?
A. AS path
B. Local pieleience
C. MED
D. Clustei length
E. None ol the aLove
Chapter Review Questions | 335
3. Vhat BGP attiiLute is mostly likely to inlluence a iemote AS that you uo not peei
with?
A. This is not possiLle given the local scope ol BGP
B. AS path
C. MED
D. Local pieleience
+. Vhich ol the lollowing coiiectly uesciiLes how IBGP uilleis liom EBGP?
A. IBGP peeis to the inteilace auuiess while EBGP peeis to loopLacks
B. IBGP upuates uo not altei the next hop attiiLute
C. EBGP upuates uo not altei the next hop
D. EBGP ieguiies a lull mesh
5. Vhen expoit policy is specilieu at the gloLal, gioup, anu neighLoi levels, which
policy is executeu?
A. Only the least specilic, which is gloLal expoit
B. Only the most specilic, which is neighLoi-level expoit
C. All thiee aie chaineu, anu the gloLal, gioup, anu neighLoi policies aie executeu
D. None ol the aLove; expoit can Le uelineu only at the gioup level
6. Vhen you issue a show bgp summary commanu, what is inuicateu Ly the Active
state?
A. The ioutei is actively tiying to loim the BGP session; you shoulu wait
B. The session is estaLlisheu anu active; you aie uone
C. The ioutei is unaLle to even ioute the session; you shoulu suspect a iouting
pioLlem
D. At least one ioute has Leen ieceiveu anu maue active
7. Vhat commanu uisplays the ioutes you aie ieceiving liom a BGP peei?
A. show route advertising-protocol bgp
B. show route receive-protocol bgp
C. show route protocol bgp
D. show ip route bgp
S. Vhich type ol ]unos soltwaie policy is noimally applieu at an EBGP speakei to
achieve an oiganization`s outbound policy?
A. Expoit policy
B. Impoit policy
C. InLounu policy
D. OutLounu policy
336 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
9. Vhen implementing loopLack-Laseu peeiing, what is the puipose ol the local-
address statement?
A. It ensuies that the ioutei souices the connection liom its loopLack auuiess
B. It ensuies that the ioutei souices the connection liom the inteilace closest to
the session taiget
C. It eliminates the neeu loi iecuisive ioute lookup in EBGP peeiing
D. It eliminates the neeu loi iecuisive ioute lookup in IBGP peeiing
10. Vhich ol the lollowing is/aie tiue iegaiuing ioute iellection on a ]-seiies ioutei?
A. A license is ieguiieu loi suppoit, not opeiation
B. A single commanu is neeueu on the iellectoi
C. New attiiLutes aie neeueu to pievent ioute looping
D. Rellectois can hiue paits ol the topology Lecause they iellect only theii choice
ol Lest ioute
E. All ol the aLove
11. Vhen conliguiing BGP in the ]unos opeiating system, wheie is the local ioutei`s
AS uelineu?
A. At the [edit protocols bgp] hieiaichy
B. At the [edit routing-options] hieiaichy
C. At the [edit protocols bgp group] hieiaichy
D. At the [edit protocols bgp group <group name> neighbor] hieiaichy
12. In the lollowing uisplay, why is the ioute leaineu liom S+.10.109.S not active?
inet.0: 817 destinations, 1069 routes (817 active, 0 holddown, 0 hidden)
10.0.0.0/8 (3 entries, 1 announced)
*BGP Preference: 170/-101
Next-hop reference count: 750
Source: 84.10.110.1
Next hop: 84.10.110.1 via ge-0/0/0.3243, selected
State: <Active Ext>
Local AS: 34 Peer AS: 666
Age: 43:41
Task: BGP_666.84.10.110.1+179
Announcement bits (2): 0-KRT 2-BGP RT Background
AS path: 666 420 1282 I Aggregator: 1282 10.20.128.3
Localpref: 100
Router ID: 64.8.12.1
BGP Preference: 170/-101
Next-hop reference count: 126
Source: 84.10.109.8
Next hop: 84.10.109.8 via ge-0/0/0.3233, selected
State: <Ext>
Inactive reason: Active preferred
Local AS: 34 Peer AS: 1282
Age: 4:36
Task: BGP_1282.84.10.109.8+2957
Chapter Review Questions | 337
AS path: 1282 1282 1282 I Aggregator: 1282 10.30.1.1
Localpref: 100
Router ID: 10.30.1.1
BGP Preference: 170/-101
Next-hop reference count: 126
Source: 84.10.113.0
Next hop: 84.10.113.0 via t1-2/0/2.0, selected
State: <NotBest Ext>
Inactive reason: Not Best in its group
Local AS: 34 Peer AS: 1282
Age: 4:32
Task: BGP_1282.84.10.113.0+3127
AS path: 1282 1282 1282 I Aggregator: 1282 10.30.1.1
Localpref: 100
Router ID: 10.30.1.1
A. Vhen all else is egual, an EBGP speakei pieleis the liist ioute leaineu
B. Vhen all else is egual, an IBGP speakei pieleis the liist ioute leaineu
C. Vhen all else is egual, the ioutei pieleis the ioute with Lest pieleience
D. The AS path is shoitei
Chapter Review Answers
1. Answei: D. The AS path attiiLute iecoius each AS that a ioute upuate has passeu
thiough, anu is upuateu on EBGP links. A BGP speakei uiscaius ieceiveu upuates
that contain the local ASN in the AS path.
2. Answei: B. The local pieleience attiiLute is evaluateu eaily in the BGP uecision
piocess, Leloie AS path, MED, oiigin, anu so on.
3. Answei: B. The AS path attiiLute has gloLal signilicance; once a value has Leen
auueu, no othei speakei can iemove that ASN liom the list Lecause this woulu
Lieak BGP`s loop pievention. The AS path is consiueieu eaily in the selection
piocess, anu so has a goou chance ol impacting loiwaiuing uecisions in iemote
ASs. MED uoes not tiansit the peei AS, local pieleience is not suppoiteu on EBGP
links, anu communities can Le stiippeu.
+. Answei: B. The next hop is unchangeu on IBGP upuates, Lut it is iewiitten on
EBGP links. EBGP uoes not ieguiie a lull mesh, Lecause the AS path is upuateu on
EBGP links.
5. Answei: B. ]unos applies only the most specilic policy applications, anu a neighLoi
level is moie specilic than a gioup level, which is moie specilic than a gloLal level.
Il you neeu a paiticulai neighLoi to execute what you consiuei a gloLal, gioup,
anu neighLoi policy, all thiee must Le changeu at the neighLoi level.
6. Answei: A. The Iule state inuicates an inaLility to ioute the session, anu an estaL-
lisheu session is uisplayeu with an x/x/x, loi active, ieceiveu, anu uampeu ioutes,
iespectively.
338 | Chapter 7:Border Gateway Protocol and Enterprise Routing Policy
7. Answei: B. The show route protocol bgp commanu shows all ioutes leaineu via
BGP, not those liom a given neighLoi.
S. Answei: B. By lilteiing anu setting attiiLutes in ieceiveu ioutes, you most uiiectly
impact how youi netwoik in tuin senus to exteinal uestinations. Expoit policy is
noimally useu to inlluence peeis in the iemote AS to allect youi inLounu policy
goals.
9. Answei: A. LoopLack-Laseu peeiing ieguiies that the ioutei souice the connection
liom its loopLack inteilace to match the uelinition at the iemote peei. A iecuisive
ioute lookup is always ieguiieu loi a loopLack-Laseu peeiing Lecause the iemote
ioutei`s loopLack auuiess can nevei Le uiiect, anu theieloie must Le iesolveu to a
uiiect loiwaiuing next hop via an IGP, to incluue a static ioute.
10. Answei: E. All ol the options listeu aie tiue.
11. Answei: B. The local ioutei`s autonomous numLei is conliguieu unuei iouting
options. The peei AS numLei is conliguieu at the gioup oi neighLoi level loi EBGP
gioups.
12. Answei: A. The RID anu peeiing auuiess tieLieakeis aie ieplaceu Ly liist-leaineu
loi EBGP leaineu ioutes only. In this example, all thiee ioutes have the same local
pieleience, gloLal pieleience, anu AS path length.
Chapter Review Answers | 339
CHAPTER 8
Access Security
This chaptei uiscusses the technigues ol secuiing the ioutei via uilleient types ol access
secuiity. Acccss sccurity is a Lioau teim that incluues the cieation ol useis with vaiious
authoiization levels oi allowing access to paiticulai seivices oi netwoiks. Also incluueu
in acccss sccurity is veiilying that the ioutei has not Leen compiomiseu anu is pei-
loiming as you expecteu. The topics coveieu incluue:
Secuiity concepts
Secuiing access to the ioutei
Fiiewall lilteis anu policeis
Spool pievention
Routei monitoiing
Security Concepts
EveiyLouy wants to have a secuie netwoik, Lut pioviuing that secuiity is olten a veiy
complex anu uillicult piocess uue to the multiple levels that neeu to Le examineu. Foi
example, it uoes not uo much goou il you pioviue veiy uetaileu lilteis anu access piiv-
ileges on a ioutei, when the physical access is an unlockeu uooi in a wiiing closet at a
iemote location. Secuiity must not Le an alteithought; it must Le uesigneu liteially liom
the giounu up, liom physical access to the netwoik to lilteis that allow only ceitain
types ol tiallic. Vhen implementing secuiity at any layei, uesign towaiu the secuiity
concepts that aie uisplayeu in Figuie S-1: integiity, availaLility, anu conliuentiality.
These concepts will help to Luilu the netwoik`s ciicle ol tiust.
The liist concept ol secuiity uesign is to ensuie the intcgrity ol the uata. In othei woius,
the uata shoulu not Le alteieu in any way without puipose. This incluues uata that
coulu Le mouilieu Ly unauthoiizeu peisonnel, Lut uoes not excluue uata manipulation
Ly authoiizeu peisonnel. Many netwoik Lieaches aie souiceu liom an insiuei, some-
one who eithei woiks oi uiu woik loi the company. This coulu Le a uisgiuntleu em-
ployee who ueciues to wieak havoc on the netwoik Lecause he nevei ieceiveu his new
341
ollice staplei! Also, uata integiity implies that the uata is consistent acioss inteinal anu
exteinal accessthat is, a usei shoulu not have the expeiience ol making changes to a
uevice liom home only to uiscovei that those changes weie nevei piopagateu to the
netwoik.
The next concept is avai|abi|ity, which is acccss to ieliaLle anu consistent uata. You can
uiviue availaLility into two paits: uata that neeus to Le accessiLle anu the netwoik
elements to ieach that system. This ieguiies elements such as system ieuunuancy, along
with Out-ol-Banu (OoB) netwoik access to iouteis anu switches. Foi example, a ioutei
that is unuei a uenial ol seivice (DoS) attack may pievent iemote access liom one
location; howevei, is theie anothei way to ieach the ioutei to thwait the attack? Design
youi netwoik with the coiiect secuiity tools; anu most impoitant, anu olten ovei-
lookeu, make suie the tools actually woik Leloie uisastei stiikes. In othei woius, what
goou uoes it uo to have piotection in place il you cannot log in to the system to imple-
ment youi tools oi monitoi anu tiouLleshoot the uevices? In iecent yeais, hoiiiLle
events such as teiioiist attacks, eaithguakes, anu tsunamis have ieopeneu many peo-
ple`s eyes to the impoitance ol availaLility anu ieuunuancy.
Lastly is the conjidcntia|ity ol the uata; this means ensuiing that unauthoiizeu uisclo-
suie has not Leen unintentionally oi intentionally given. In the mouein age ol thumL
uiives, smaitphones, anu PCs, the aLility to access inloimation has nevei Leen gieatei,
anu so aie the secuiity vulneiaLilities. How many times have useis lelt themselves
loggeu in at a cyLeical somewheie? It takes just a lew seconus loi an evil netwoik
engineei luiking in the shauows to notice the open PC, expanu a ioutei session that
has Leen lelt open, uelete the conliguiation, anu walk away, ecstatic.
Aie you getting scaieu yet? Ve hope so. A secuiity expeit without any leai is a veiy
nave one! Secuiity must take a multiphase anu uynamic appioach; you will make mis-
takes, Lut the oLjective is to leain liom those mistakes, use the tools availaLle to you,
anu make the necessaiy coiiections so that you avoiu those mistakes latei. Always
iememLei: secuiity is a piocess anu not an event! As Homei saiu, Even a lool may Le
wise altei the event. As we examine each topic in the iemaining chapteis, iememLei
Iigurc 8-1. Sccurity circ|c oj trust
342 | Chapter 8:Access Security
to think ol the secuiity ciicle ol tiust anu wheie each leatuie lits anu enaLles youi
secuiity to Le a ciicle without holes.
Summary of Security Concepts
Most people linu the secuiity concepts piesenteu heie to Le somewhat common sense.
The issue is that humans aie inheiently lazy, anu secuiity Ly its veiy uelinition tenus
to get in the way ol oui neeu to access inloimation. The neeu loi connectivity olten
oveishauows the neeu to secuie those communications, until the uamage is uone anu
it is too late to plug the holes. Always keep these secuiity piinciples in minu when
uesigning a new netwoik oi haiuening an existing one.
The next section uetails ways to secuie access to the ioutei itsell, which is a ciitical
aspect ol an oveiall secuiity plan.
Securing Access to the Router
The goal ol this chaptei is to secuie the netwoik in Figuie S-2, which consists ol thiee
iouteisAle, PBR, anu Bockthat aie iunning Open Shoitest Path Fiist (OSPF) as the
Inteiioi Gateway Piotocol (IGP). PBR connects to multiple Inteinet seivice pioviueis
(ISPs) via the Boiuei Gateway Piotocol (BGP). Vaiious types ol tiallic aie sent anu
ieceiveu liom the two ISPs, incluuing weL Liowsing, email, anu a vaiiety ol iemote
accounting anu engineeiing applications. The liist step will Le to secuie access to Ale,
PBR, anu Bock so that only authoiizeu useis have access to each ioutei.
Iigurc 8-2. Nctwor| topo|ogy
User Authentication
Theie aie two types ol useis on a ]unos-Laseu uevicea nonioot usei anu a ioot usei,
Loth ol which must Le secuieu. Recall that usei ioot is the only usei who is pieuelineu
Securing Access to the Router | 343
Ly uelault, accessiLle only via the console poit without any uelault passwoiu. You must
set a ioot passwoiu Leloie the ioutei will allow you to commit the conliguiation. To
set up a ioot passwoiu, issue the root-authentication keywoiu unuei the [edit
system] level:
lab@Bock# set system root-authentication ?
Possible completions:
+ apply-groups Groups from which to inherit configuration
data
+ apply-groups-except Don't inherit configuration data from these
groups
encrypted-password Encrypted password string
load-key-file File (URL) containing one or more ssh keys
plain-text-password Prompt for plain text password (autoencrypted)
> ssh-dsa Secure shell (ssh) DSA public key string
> ssh-rsa Secure shell (ssh) RSA public key string
RememLei that usei root is veiy poweilul. Vhen loggeu in as root, you
aie placeu uiiectly into the keinel in the loim ol a BSD shell! As a iesult,
root can log in only via SSH oi the console poit, Ly uelault.
The passwoiu can eithei Le a plain-text passwoiu that will Le enciypteu automatically
in the conliguiation, an SSH key, oi an enciypteu stiing loi copying anu pasting to
othei iouteis. In this case, a passwoiu ol Bia&abi55a is supplieu (Lut not shown in the
inteilace):
lab@Bock# set system root-authentication plain-text-password
New password:
Retype new password:
Vhen issuing a plain text passwoiu, ]unos has some uelault ieguiie-
ments loi passwoiu length anu content. The passwoiu must Le Letween
six anu 12S chaiacteis anu must contain one change ol case oi special
chaiactei. You can mouily these uelaults unuei [edit system password].
Once the passwoiu is set on Bock, it automatically Lecomes enciypteu:
lab@Bock# show system root-authentication
encrypted-password "$1$i0LTVCdC$2jViYwTCG.kET399/uF/y0";
## SECRET-DATA
The enciypteu stiing is now copieu to othei iouteis (PBR anu Ale) without neeuing
knowleuge ol the actual passwoiu:
[edit system root-authentication]
lab@PBR# load merge terminal relative
[Type ^D at a new line to end input]
encrypted-password "$1$i0LTVCdC$2jViYwTCG.kET399/uF/y0";
## SECRET-DATA
load complete
344 | Chapter 8:Access Security
[edit system root-authentication]
lab@PBR# show
encrypted-password "$1$i0LTVCdC$2jViYwTCG.kET399/uF/y0";
## SECRET-DATA
Next, nonioot useis aie conliguieu. These useis can Le uelineu with local usei pass-
woius anu peimissions, oi an exteinal seivei such as RADIUS oi TACACS coulu Le
useu. In eithei case, thiee items neeu to Le conliguieu loi the usei:
Useiname
Peimissions
Passwoiu
A usei oi usei template must always Le conliguieu on the ioutei, Lut the peimissions
anu passwoiu coulu Le conliguieu on an exteinal seivei. To illustiate the possiLle
options, this scenaiio has the lollowing six ieguiiements:
1. Deline two local useis, doug anu harry, anu pioviue them with maximum access.
2. A gioup will Le cieateu loi the NOC gioup consisting ol 15 engineeis. Each NOC
engineei will have his own useiname, Lut will shaie the same peimissions ol ieau-
only commanus anu maintenance commanus loi tiouLleshooting.
3. A gioup will Le cieateu loi the uesign engineei gioup, consisting ol thiee engineeis.
This gioup will have lull access to all commanu-line inteilace (CLI) commanus,
except loi the restart anu request commanus.
+. All useis will Le authenticateu using a RADIUS seivei with a shaieu seciet ol
LiianLoswoith.
5. Authoiization is uelineu on the local ioutei.
6. Il the RADIUS seivei is uown, only harry anu doug may log in to the ioutei.
One usei that is not exploieu in this case stuuy is the iemote usei. This
is a usei that coulu Le cieateu loi use on the ioutei il the authenticateu
usei uoes not exist on the local ioutei oi il the authenticateu usei`s
iecoiu in the authentication seivei specilies a local usei. You can think
ol this as a uelault lallLack account.
Each usei uelineu must Le associateu with a login class, which assigns the peimissions
loi a usei. The login class can Le one ol the loui uelault classes listeu in TaLle S-1, oi
a custom-uelineu class.
Securing Access to the Router | 345
Tab|c 8-1. Prcdcjincd junos uscr c|asscs
Class Permissions
superuser or super-user All
read-only View
operator Clear, Network, Reset, Trace, View
unauthorized None
Useis harry anu doug ieguiie maximum access, so it makes sense to use a pieuelineu
]unos soltwaie class calleu super-user. Heie we show the step-Ly-step piocess loi
harry only, as usei doug has iuentical steps:
lab@Ale# edit system login user harry
[edit system login user harry]
set class super-user authentication plain-text-password
New password:
Retype new password:
[edit system login user harry]
lab@Ale# show
class super-user;
authentication {
encrypted-password "$1$oOspqmHP$jlxUul0cAgPq3j88/7WQP/";
## SECRET-DATA
}
Foi Lievity anu sanity, the conliguiation examples show one ioutei, Lut
the ieauei shoulu assume that the conliguiation is copieu to all iouteis
in the netwoik.
Next, a gioup ol 15 NOC engineeis aie uelineu. Since conliguiing 15 local useis will
Le a pain to manage anu tiiesome to type, we will use a uscr tcnp|atc. A usei template
allows multiple useis uelineu on the RADIUS seivei with unigue passwoius to Le
gioupeu to a single local ]unipei usei. Since a pieuelineu class will not satisly the au-
thoiization level loi the NOC engineeis ol ieau-only anu maintenance commanus, we
will ueline a custom class:
[edit system login]
lab@Ale# set class ops permissions [view maintenance trace]
Relei to the access-piivilege technical uocumentation to see each com-
manu that is alloweu loi eveiy peimission setting.
346 | Chapter 8:Access Security
Next, we assign the usei ops the new class, also calleu ops:
[edit system login]
lab@Ale# set user ops class ops
[edit system login]
lab@Ale# show class ops
permissions [ trace view maintenance ];
lab@Ale# show user ops
uid 2000;
class ops;
The RADIUS seivei will then have 15 useis uelineu that all map to the same ]unipei-
local usei ol ops. Foi example, the conliguiation loi 2 ol the 15 useis using a RADIUS
seivei woulu Le similai to the lollowing:
bruiser Auth-Type = Local, Password = "iamaDog"
Service-Type = Login-User,
Juniper-Local-User-Name = "ops"
josh Auth-Type = Local, Password = "plumper1"
Service-Type = Login-User,
Juniper-Local-User-Name = "ops"
The uesign engineei gioup ieguiiement will also use a template Lut will make use ol
special allow anu deny commanus that we can also ueline in a class. Il the peimission
Lits that aie set aie too Lioau, we can ueny inuiviuual commanus within the peimission
settings. (Anu vice veisa; il we neeu an auuitional commanu oi set ol commanus that
go Leyonu the peimission setting, we can allow them.) These allow anu deny statements
coulu Le a single commanu oi a gioup ol commanus using iegulai expiessions. They
aie also sepaiateu in allow oi deny opeiational moue commanus oi conliguiation moue:
[edit system login]
lab@Ale# set class design ?
Possible completions:
allow-commands Regular expression for commands to allow explicitly
allow-configuration Regular expression for configure to allow explicitly
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
deny-commands Regular expression for commands to deny explicitly
deny-configuration Regular expression for configure to deny explicitly
idle-timeout Maximum idle time before logout (minutes)
login-alarms Display system alarms when logging in
login-tip Display tip when logging in
+ permissions Set of permitted operation categories
The uesign engineei`s class will have the peimission Lits set to all, anu all commanus
that stait with r (request anu restart) will Le uisalloweu:
[edit system login]
lab@Ale# set class design permissions all
[edit system login]
lab@Ale# set class design deny-commands "^r.*$"
lab@Ale# set user design class design
Securing Access to the Router | 347
Regulai expiessions aie Leyonu the scope ol the Look, Lut heie is a list
ol common opeiatois:
.
Any chaiactei
*
Zeio oi moie chaiacteis
^
Stait ol stiing to which the iegex is applieu
$
Enu ol stiing to which the iegex is applieu
?
Zeio oi one chaiactei
As mentioneu, we can ueline useis locally on the ioutei oi on an exteinal seivei such
as RADIUS oi TACACS. In this chaptei`s case stuuy, we specilieu a RADIUS seivei
eailiei, in ieguiiement +. The RADIUS seivei`s IP auuiess anu seciet passwoiu aie
conliguieu:
[edit system]
design@Ale# set radius-server 10.20.130.5 secret brianbosworth
Foi the system to use the RADIUS seivei, we must conliguie the authentication-
order statement. This inuicates which oiuei ol authentication methou shoulu Le useu,
with the uelault Leing the local ioutei uataLase only. In this section ol oui case stuuy,
we must ueciue Letween the lollowing conliguiation choices:
1. authentication-order [radius password]
2. authentication-order [radius]
In eithei conliguiation, the local uataLase will Le consulteu il the RADIUS seivei is
uown, so the uilleience Letween the two options is eviuent when the RADIUS seivei
ietuins a ieject. This ieject coulu Le causeu Ly a mistypeu passwoiu oi a useiname that
is not uelineu in the RADIUS seivei. In option 1, the RADIUS seivei ietuins the ieject
anu the local uataLase will Le consulteu. Option 2 consults the local uataLase only il
the RADIUS seivei is uniesponsive; piocessing stops il the seivei ietuins a reject mes-
sage. The ieguiiements state that the RADIUS seivei shoulu always Le useu when
availaLle (as specilieu in option 1). Il the RADIUS seivei is not availaLle, useis doug
anu harry will Le alloweu to log in using the local uataLase since they aie the only useis
with locally uelineu passwoius on the ioutei. These useis aie also uelineu on the
RADIUS seivei:
doug Auth-Type = Local, Password = "superbowlshuffle5"
Service-Type = Login-User
Heie is a complete system login conliguiation that meets all six ol the ciiteiia specilieu
eailiei:
348 | Chapter 8:Access Security
[edit system]
design@Ale# show
host-name Ale;
authentication-order radius password;
ports {
console type vt100;
}
root-authentication {
encrypted-password "$1$85xXcov4$fLHtgMlqxRSg24zO8Kbe81"; ##
SECRET-DATA
}
radius-server {
10.20.130.5 secret "$9$KdgW87db24aUcydsg4Dj69A0RSWLN24ZNd.5TFAt";
## SECRET-DATA
}
login {
class design {
permissions all;
deny-commands "^r.*$";
}
class ops {
permissions [ trace view maintenance ];
}
user design {
uid 2004;
class design;
user harry {
uid 2001;
class super-user;
authentication {
encrypted-password "$1$oOspqmHP$jlxUul0cAgPq3j88/7WQP/";
## SECRET-DATA
}
}
user doug {
uid 2003;
class superuser;
authentication {
encrypted-password "$1$ocs3AXkS$JdlQW7z4ZIJblfFZD.fqH/";
## SECRET-DATA
}
}
user ops {
uid 2000;
class ops;
}
}
services {
ftp;
ssh;
telnet;
}
syslog {
user * {
Securing Access to the Router | 349
any emergency;
}
file messages {
any notice;
authorization info;
}
file config-changes {
change-log any;
}
}
Lastly, to veiily that the usei has the coiiect peimissions, log in to the ioutei anu issue
a show cli authorization commanu:
design@Ale> show cli authorization
Current user: 'design ' class 'design'
Permissions:
admin --Can view user accounts
admin-control--Can modify user accounts
clear --Can clear learned network information
configure --Can enter configuration mode
control --Can modify any configuration
edit --Can edit full files
field --Special for field (debug) support
floppy --Can read and write from the floppy
interface --Can view interface configuration
interface-control--Can modify interface configuration
network --Can access the network
reset --Can reset/restart interfaces and daemons
routing --Can view routing configuration
routing-control--Can modify routing configuration
shell --Can start a local shell
snmp --Can view SNMP configuration
snmp-control--Can modify SNMP configuration
system --Can view system configuration
system-control--Can modify system configuration
trace --Can view trace file settings
trace-control--Can modify trace file settings
view --Can view current values and statistics
maintenance --Can become the super-user
firewall --Can view firewall configuration
firewall-control--Can modify firewall configuration
secret --Can view secret configuration
secret-control--Can modify secret configuration
rollback --Can rollback to previous configurations
security --Can view security configuration
security-control--Can modify security configuration
access --Can view access configuration
access-control--Can modify access configuration
view-configuration--Can view all configuration (not including
secrets)
Individual command authorization:
Allow regular expression: none
Deny regular expression: ^r.*$
Allow configuration regular expression: none
Deny configuration regular expression: none
350 | Chapter 8:Access Security
Remote Access
Altei the useis aie conliguieu on the ioutei, we must ueciue what kinu ol iemote access
will Le pioviueu to the ioutei, as all methous aie uisaLleu Ly uelault. Heie aie the
possiLle options:
Dynanic Host Conjiguration Protoco| (DHCP)
Pioviues uynamic IP assignment liom a pool ol auuiesses to clients attacheu to the
inteilace (not availaLle on M-seiies iouteis). This option is most olten useu loi the
auto-installation leatuie.
Iingcr
A piotocol to get inloimation aLout a usei loggeu in to the ioutei. This piotocol
is no longei useu on a laige scale anu shoulu nevei Le enaLleu on the ioutei:
% finger lab@10.20.128.3
[10.20.128.3]
Login: lab Name:
Directory: /var/home/lab Shell: /usr/sbin/cli
On since Mon Sep 24 00:31 (UTC) on ttyd0, idle 0:01
No Mail.
No Plan.
%
ITP
Pioviues lile tianslei seivices. Although FTP is a wiuely useu piotocol, it tiansleis
liles in plain text, which can leau to secuiity issues. Vhen possiLle, you shoulu use
secuie copy (SCP).
R|ogin
The Remote login piotocol, which allows iemote login to the CLI. This Unix utility
has seveial secuiity llaws anu was useu only in piivate enviionments. This utility
is enaLleu Ly a hiuuen commanu on the ioutei anu shoulu nevei Le enaLleu on
the ioutei.
A hiddcn connand is a commanu that uoes not show up when you
use ? in the CLI anu uoes not autocomplete with the Space Lai.
One ol the most lamous hiuuen commanus in ]unos soltwaie is
show version and haiku. Tiy it youisell il you want to ieau some
ieally Lau poetiy!
SSH
Allows loi two uevices to communicate ovei an enciypteu tunnel. This ensuies not
only availaLility, Lut also uata integiity anu conliuentiality. Vhen SSH is enaLleu,
this automatically enaLles SCP.
Tc|nct
A common piotocol to iemotely manage a system uevelopeu in 1969. Telnet tian-
sits all uata in cleai text, so you shoulu use SSH when possiLle.
Securing Access to the Router | 351
Wcb nanagcncnt
EnaLles the use ol the jweL weL GUI on the ioutei loi management anu conligu-
iation. These can Le eithei enciypteu oi unenciypteu Hypeitext Tianslei Piotocol
(HTTP) connections.
junoscript scrvcr
EnaLles the ioutei to ieceive commanus liom a ]unosciipt seivei via cleai text oi
Secuie Sockets Layei (SSL) connections.
Nctconj
The Netwoik Conliguiation piotocol, which is uelineu in RFC +7+1 anu uses XML
loi conliguiation anu messages. Netconl is the Inteinet Engineeiing Task Foice
(IETF) stanuaiu cieateu as a ieplacement loi the Simple Netwoik Management
Piotocol (SNMP) anu is Laseu on ]unosciipt. Netconl SSH is neeueu when the
uevice is going to Le contiolleu Ly ]unipei`s Netwoik anu Secuiity Managei (NSM).
The most secuie methous ol iemote access on the ioutei will Le SSH anu tiansleiiing
liles using SCP. To enaLle any seivice, simply set it unuei the [edit system services]
uiiectoiy:
[edit system services]
lab@Ale# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration
data
+ apply-groups-except Don't inherit configuration data from these
groups
> dhcp Configure DHCP server
> finger Allow finger requests from remote systems
> ftp Allow FTP file transfers
> netconf Allow NETCONF connections
> service-deployment Configuration for Service Deployment (SDXD)
management application
> ssh Allow ssh access
> telnet Allow telnet login
> web-management Web management configuration
> xnm-clear-text Allow clear text-based Junoscript connections
> xnm-ssl Allow SSL-based Junoscript connections
Each seivice will have a vaiiety ol options, such as setting a maximum numLei ol con-
nections, iate-limiting the inLounu connections, anu choosing a ceitain piotocol
veision:
lab@Ale# set system services ssh ?
Possible completions:
<[Enter]> Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
connection-limit Maximum number of allowed connections (1..250)
+ protocol-version Specify ssh protocol versions supported
rate-limit Maximum number of connections per minute
(1..250)
352 | Chapter 8:Access Security
root-login Configure root access via ssh
| Pipe through a command
XML Tags
]unosciipt is a tool you can use to conliguie anu manage the ioutei. Eveiy ]unos output
anu conliguiation contains XML tags that can Le ieleienceu Ly a ]unosciipt client. Heie
is an example ol a conliguiation anu an opeiational commanu that uisplays the XML
tags loi each lielu:
lab@PBR> show system users | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/10.4R1/junos">
<system-users-information xmlns="http://xml.juniper.net/junos/
10.4R1/junos">
<uptime-information>
<date-time junos:seconds="1293056770">8:54AM</date-time>
<up-time junos:seconds="207372">2 days, 9:36</up-time>
<active-user-count junos:format="1 user">1</active-user-
count>
<load-average-1>0.06</load-average-1>
<load-average-5>0.02</load-average-5>
<load-average-15>0.00</load-average-15>
<user-table>
<user-entry>
<user>lab</user>
<tty>d0</tty>
<from>-</from>
<login-time junos:seconds="1190593874">Mon12AM</login-time>
<idle-time junos:seconds="0">-</idle-time>
<command>-cli (cli)</command>
</user-entry>
</user-table>
</uptime-information>
</system-users-information>
<cli>
<banner></banner>
</cli>
</rpc-reply>
lab@PBR> show configuration routing-options | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/10.4R1/junos">
<configuration>
<routing-options>
<static>
<route>
<name>10.10.128.1/32</name>
<next-hop>10.10.111.1</next-hop>
</route>
</static>
</routing-options>
</configuration>
<cli>
<banner></banner>
</cli>
Securing Access to the Router | 353
In this case, SSH is enaLleu on the ioutei using the uelault paiameteis ol 150 connection
attempts anu 75 active sessions pei minute:
[edit]
lab@Ale# set system services ssh
Bock then initiates a session to Ale. The liist connection will neeu to estaLlish the RSA
lingeipiint loi authentication:
lab@Bock> ssh 10.10.128.1
The authenticity of host '10.10.128.1 (10.10.128.1)' can't be
established.
RSA key fingerprint is 5d:f5:51:91:51:0e:ff:54:0c:f4:0a:07:51:3b:70:3a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.10.128.1' (RSA) to the list of known
hosts.
lab@10.10.128.1's password:
--- Junos 10.4R1.9 built 2010-12-08 09:22:36 UTC
lab@Ale> exit
Connection to 10.10.128.1 closed.
Howevei, once Ale is auueu to the list ol known hosts, lutuie sessions uo not ieguiie
ieveiilication:
lab@Bock> ssh 10.10.128.1
lab@10.10.128.1's password:
--- Junos 10.4R1.9 built 2010-12-08 09:22:36 UTC
lab@Ale>
Vhen SSH is enaLleu on the ioutei, it also automatically enaLles SCP to initiate secuie
lile exchanges. You can uploau oi uownloau liles using vaiiations ol the file copy
commanu. In this case, PBR tiansleis a lile calleu tcst to Ale. PBR must auu Ale into its
goou hosts lile:
lab@PBR> file copy test lab@10.10.128.1:test.txt
The authenticity of host '10.10.128.1 (10.10.128.1)' can't be
established.
RSA key fingerprint is 5d:f5:51:91:51:0e:ff:54:0c:f4:0a:07:51:3b:70:3a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.10.128.1' (RSA) to the list of
known hosts.
lab@10.10.128.1's password:
test 100% 9480 9.3KB/s 00:00
Altei Ale is leaineu as a host, lutuie tiansleis will pass the authentication check Lecause
Loth Ale anu PBR know each othei as tiusteu hosts:
lab@PBR> file copy test2 lab@10.10.128.1:test2.txt
lab@10.10.128.1's password:
test 100% 9480 9.3KB/s 00:00
354 | Chapter 8:Access Security
Summary of Access Security
Routeis aie the veiy laLiic ol any IP-Laseu netwoik, making it ciitical that access Le
limiteu to only those useis that aie authoiizeu to access the system, anu only loi those
tasks they aie authoiizeu to peiloim. ]unos soltwaie pioviues a vaiiety ol tools, ianging
liom local anu iemote authentication anu authoiization to secuie access anu lile tians-
lei piotocols, which make it easy to secuie the ioutei liom unauthoiizeu access anu
many loims ol DoS attacks.
The next section uetails packet-Laseu (stateless) liiewall lilteiing anu policing capaLil-
ities, which aie anothei ciitical aspect ol a total secuiity solution.
Firewall Filters
To piotect the ioutei, you can ueploy packet lilteis to allow only ceitain tiallic into the
ioutei`s contiol plane (Routing Engine RE). These lilteis have uilleient names on each
ioutei OS, Lut they still opeiate in the same stateless mannei. On a Cisco uevice, these
lilteis aie calleu acccss |ists, anu on a ]unipei ioutei, they aie calleu jircwa|| ji|tcrs. These
lilteis look similai to the policy we uiscusseu in Chaptei 5; howevei, lilteis opeiate on
the actual uata-loiwaiuing plane. TaLle S-2 pioviues a compaiison ol the two leatuies.
Tab|c 8-2. Iircwa|| ji|tcrs vcrsus routing po|icics
Feature Firewall filter Routing policy
Operates in... Forwarding plane Control plane
Match keyword from from
Action keyword then then
Match attributes Packet fields Route attributes
Default action Discard Depends on default policy
Applied to... Interfaces Routing protocols/tables
Named terms required Yes No
Chains allowed Yes Yes
Absence of from statement Match all Match all
Fiiewall liltei syntax takes a human-liienuly, intuitive loim:
firewall {
family inet {
filter filter-1 {
term term-1 {
from {
protocol tcp;
destination-port telnet;
}
then {
Firewall Filters | 355
accept;
}
}
}
}
}
This liltei matches on Telnet tiallic anu accepts the packets. As oLseiveu, the syntax
is veiy similai to a iouting policy with the match conuitions in the from teim anu the
actions specilieu in a then teim.
Filter Processing
Similai to a policy, a liltei is maue up ol multiple teims, anu each teim is examineu in
the oiuei listeu. Il theie is a match in a teim anu theie is a teiminating action, no othei
teim is examineu (see Figuie S-3). Teiminating actions aie:
accept
Allows the packet thiough the liltei
discard
Silently uiscaius the packet
reject
Discaius the packet with an Inteinet Contiol Message Piotocol (ICMP) eiioi mes-
sage (the uelault is auministiatively piohiLiteu)
Action nodijicr
Any action mouiliei, such as log, count, syslog, anu so on
The piesence ol an action mouiliei such as count without an explicit
accept, discard, oi reject will iesult in a uelault action ol accept. Il the
uesiieu action is to uiscaiu oi ieject the packet, it must Le explicitly
conliguieu.
Iigurc 8-3. Ii|tcr proccssing
Il the packet uoes not match any teims in the liltei, it is uiscaiueu.
356 | Chapter 8:Access Security
You also can apply multiple lilteis to the inteilace in the loim ol a liltei list, anu in this
case it opeiates in the same lashion uown the liltei list until theie is a teiminating action.
Il no match occuiieu in the liltei list, the packet is uiscaiueu (see Figuie S-+).
Iigurc 8-1. Ii|tcr chaining
Filter Match Conditions
Vhen examining the possiLle match conuitions, the geneial iule ol thumL is that il it
is a lielu in the IP, Tiansmission Contiol Piotocol (TCP), Usei Datagiam Piotocol
(UDP), oi ICMP heauei, it is pioLaLly a potential match:
lab@PBR# set firewall family inet filter foo term 1 from ?
Possible completions:
> address Match IP source or destination address
+ apply-groups Groups from which to inherit configuration
data
+ apply-groups-except Don't inherit configuration data from these
groups
> destination-address Match IP destination address
+ destination-port Match TCP/UDP destination port
+ destination-port-except Do not match TCP/UDP destination port
destination-prefix-list Match IP destination prefixes in named
list
+ dscp Match Differentiated Services (DiffServ) code
point
+ dscp-except Do not match Differentiated Services (DiffServ)
code point
+ esp-spi Match IPSec ESP SPI value
+ esp-spi-except Do not match IPSec ESP SPI value
first-fragment Match if packet is the first fragment
+ forwarding-class Match forwarding class
+ forwarding-class-except Do not match forwarding class
fragment-flags Match fragment flags
+ fragment-offset Match fragment offset
+ fragment-offset-except Do not match fragment offset
+ icmp-code Match ICMP message code
+ icmp-code-except Do not match ICMP message code
+ icmp-type Match ICMP message type
+ icmp-type-except Do not match ICMP message type
> interface Match interface name
+ interface-group Match interface group
+ interface-group-except Do not match interface group
> interface-set Match interface in set
+ ip-options Match IP options
Firewall Filters | 357
+ ip-options-except Do not match IP options
is-fragment Match if packet is a fragment
+ packet-length Match packet length
+ packet-length-except Do not match packet length
+ port Match TCP/UDP source or destination port
+ port-except Do not match TCP/UDP source or destination
port
+ precedence Match IP precedence value
+ precedence-except Do not match IP precedence value
> prefix-list Match IP source or destination prefixes in
named list
+ protocol Match IP protocol type
+ protocol-except Do not match IP protocol type
service-filter-hit Match if service-filter-hit is set
> source-address Match IP source address
+ source-port Match TCP/UDP source port
+ source-port-except Do not match TCP/UDP source port
> source-prefix-list Match IP source prefixes in named list
tcp-established Match packet of an established TCP connection
tcp-flags Match TCP flags
tcp-initial Match initial packet of a TCP connection
+ ttl Match IP ttl type
+ ttl-except Do not match IP ttl type
The match conuitions lall into thiee geneial categoiies: numeiic, auuiess, anu Lit lielu
matches (see TaLle S-3).
Tab|c 8-3. Gcncra| natch conditions
Numeric matches Address matches Bit fields
Protocol fields Source address IP options
Port numbers Destination address TCP flags
Class of service (CoS) fields Source-prefix lists IP fragmentation
ICMP type codes Destination-prefix lists Time to Live (TTL)
A teim can have zeio oi many match conuitions specilieu. The aLsence ol a from state-
ment cieates a match all conuition, wheieas multiple match conuitions aie tieateu as
a logical AND oi OR uepenuing on common veisus uncommon match conuitions. A
common match is tieateu as a logical OR, which the ioutei will gioup togethei in sguaie
Liackets. The liltei example matches on TCP oi UDP packets:
filter example {
term common {
from {
protocol [ tcp udp ];
}
}
}
358 | Chapter 8:Access Security
An uncommon match is tieateu as a logical AND. You can comLine these logical ANDs
anu ORs in the same teim with limitless possiLilities. Auuing to the example, the lol-
lowing liltei matches on TCP oi UDP packets anu poit 123:
filter example {
term common {
from {
protocol [ tcp udp ];
port 123;
}
}
}
Also, numeiic matches such as poit oi piotocol values can eithei take the numeiic
match oi the moie usei-liienuly keywoius. Foi example, the liist teim anu seconu teim
ol the liltei calleu same aie eguivalent, Lut the seconu teim is wiitten in a moie ellicient
anu usei-liienuly methou:
firewall {
filter same {
term numbers {
from {
protocol 6;
port 23;
}
then accept;
}
term user-friendly {
from {
protocol tcp;
port telnet;
}
then accept;
}
}
}
Bit lielu matching such as IP options anu TCP llags also suppoit numeiic
values oi moie usei-liienuly teims. In these cases, the numeiic suppoit
must Le wiitten in hex loimat, so a TCP llag match loi SYN packets
coulu Le wiitten with the keywoiu syn oi the value 0x2. No ieason to
Lieak out the hex conveiteimake lile easy anu use the keywoius!
Can your mother read this?
Vhen wiiting a liltei, always tiy to auheie to the KISS (Keep It Shoit anu Simple)
methou. An inuiviuual secuiity element may not Le that uillicult, Lut when comLineu
with othei secuiity lunctions as a whole, it can contiiLute to a laige weL ol complexity.
In othei woius, tiy to cieate a liltei that the aveiage netwoik engineei can unueistanu
without compiomising any secuiity. A gieat stait to ieach this goal is to use the alpha
names loi piotocol, poit numLeis, anu Lit lielus insteau ol the actual numeiical values.
Firewall Filters | 359
Auuitionally, ]unos has even moie to ollei, using text synonyms to map common Lit
mappings. These allow the casual ieauei to guickly unueistanu a liltei at a glance anu
avoiu panickeu anu hysteiical ieseaich to linu what seivice maps to a numeiical value
(see TaLle S-+).
Tab|c 8-1. Tcxt synonyns
Text synonym Match equivalent Common use
first-fragment Offset = 0, MF = 1 Match on the first fragment of a packet for counting and logging.
is-fragment Offset does not equal zero Protect from fragmented DoS attacks.
tcp-established ACK or RST Allow only established TCP sessions over an interface. This option does
not implicitly check that the protocol is TCP. Use the TCP match condition.
tcp-initial SYN and not ACK Allow sessions to be initiated either inbound or outbound.
Filter Actions
Besiues the teiminating actions that we alieauy uiscusseu (accept, discard, anu
reject), othei action mouilieis aie commonly useu. These incluue:
count <counter name>
Counts the total numLei ol packets anu Lytes that match a teim. You can view
counteis with the show firewall commanu.
log
Recoius the packet heauei inloimation anu stoies the inloimation in memoiy on
the ioutei, which limits the size to appioximately +00 entiies anu cleais upon a
ioutei ieLoot. To view the log, issue a show firewall log commanu.
syslog
Recoius the packet heauei inloimation anu stoies the log into a lile oi senus it to
a syslog seivei. The syslog lacility ol the liiewall will allow any local lile to Le cieateu
loi this inloimation.
policer
Rate-limits tiallic Laseu on Lanuwiuth anu Luist size limits (uiscusseu latei in this
chaptei).
forwarding-class
Senus packets to a loiwaiuing class, which maps to a gueue.
sample
Cieates cllowu expoit iecoius.
next term
Allows packets to match a teim anu then move on to the next teim listeu. Since
the piesence ol any action mouiliei implies an accept, this action allows packets
to pass thiough to the next teim. This is olten ueployeu when all packets neeu to
Le counteu Leloie Leing iejecteu laithei in the chain.
360 | Chapter 8:Access Security
Applying a Filter
The linal step altei wiiting the liltei is to actually apply it to the inteilace. You can apply
lilteis to eithei tiansit oi nontiansit tiallic. To apply a liltei to tiansit tiallic, apply the
liltei to any Packet Foiwaiuing Engine (PFE) inteilace as eithei an input oi an output
liltei oi as pait ol a list ol lilteis. Filteis aie applieu on a logical unit Lasis:
lab@hops# set interfaces ge-0/0/0 unit 0 family inet filter ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
group Group to which interface belon
input Name of filter applied to received packets
+ input-list List of filter modules applied to received packets
output Name of filter applied to transmitted packets
+ output-list List of filter modules applied to transmitted packets
You can apply a single liltei with the input oi output commanu, oi a list
with input-list oi output-list, so why the option loi Loth? Histoiically
in ]unos, only a single liltei coulu Le applieu pei uiiection pei unit, Lut
in latei coue the concept ol a list was cieateu. It is iecommenueu that
even il just a single liltei is Leing applieu to an inteilace, to use the
list commanu. This auus llexiLility in auuing moie lilteis to the chain
at a latei time.
To piotect tiallic to the ioutei itsell (local tiallic), you can apply a liltei oi liltei-list to
the loopLack inteilace (see Figuie S-5). Local tiallic is any packet that is uestineu to
the ioutei itsell, such as iouting piotocols, ICMP, SSH, anu othei management
piotocols.
Iigurc 8-5. Transit vcrsus |oopbac| ji|tcrs
Case Study: Transit Filters
It is common to see a liltei applieu to the ioutei`s connection to the Inteinet. Beloie
sitting uown to Legin typing away on the ioutei, always wiite uown the goals ol the
liltei. In this case stuuy, all outLounu tiallic liom the netwoik to the Inteinet is alloweu
while some tiallic liom the Inteinet will Le lilteieu. The goals heie aie as lollows:
Firewall Filters | 361
TCP connections aie only alloweu to Le initiateu outLounu to the Inteinet, except
to access a local weL seivei.
No liagmenteu ICMP oi UDP packets shoulu Le alloweu.
TCP liagments aie alloweu.
UDP packets shoulu Le alloweu inLounu loi tiaceioutes anu ietuin tiallic loi out-
Lounu UDP connections.
Ping anu tiaceioute aie alloweu outLounu.
Tiaceioute is alloweu inLounu.
Fiist cieate a pielix list loi the inteinal suLnets, which in this case aie as lollows:
10.10.128/22
10.20.128/22
10.10.12/22
[edit]
lab@PBR# set policy-options prefix-list internal-subnets 10.10.128/22
[edit]
lab@PBR# set policy-options prefix-list internal-subnets 10.20.128/22
[edit]
lab@PBR# set policy-options prefix-list internal-subnets 10.20.12/22
lab@PBR# show policy-options prefix-list internal-subnets
10.10.128.0/22;
10.10.12.0/22;
10.20.128.0/22;
Now the liltei calleu internet-in will Le examineu with each teim explaineu to match
the live goals stateu at the Leginning ol this case stuuy. Fiist, we ueline oui liist teim
to allow estaLlisheu TCP sessions inLounu, which aie uestineu loi inteinal suLnets.
The keywoiu tcp-established allows only packets with a TCP llag ol ack oi rst. As a
iesult ol the implicit ueny all at the enu ol the liltei list, this teim will also accomplish
task 1, allowing only outLounu TCP sessions. Also, the fragment-offset keywoiu al-
lows loi unliagmenteu packets oi liist packet liagments to Le ieceiveu as only the liist
liagmenteu packet has the heaueis neeueu loi the check:
lab@PBR# show firewall family inet
filter internet-in {
term allow-established-tcp-sessions {
from {
destination-prefix-list {
internal-subnets;
}
fragment-offset 0;
tcp-established;
protocol tcp;
}
then accept;
}
362 | Chapter 8:Access Security
Next, TCP connections aie alloweu to the weL seivei at 10.20.12.9, using poit numLeis
https (++3) anu S0S0. Poit S0 connections aie not alloweu towaiu this weL seivei to
auu an auuitional layei ol secuiity:
term allow-webserver-connections {
from {
destination-address {
10.20.12.9/32;
}
protocol tcp;
destination-port [ https 8080 ];
}
then accept;
}
UDP anu ICMP liagments aie uenieu as these types ol packets aie noimally useu in
populai DoS attacks. The fragment-offset commanu is matching on all ICMP anu UDP
liagments, excluuing the liist packet. Il the liist liagment also weie to Le uioppeu, the
is-fragment anu first-fragment woulu Le useu anu two teims woulu have Leen
ieguiieu:
term deny-udp-icmp-frags {
from {
fragment-offset 1-8191;
protocol [ icmp udp ];
}
then {
discard;
}
}
TCP liagments aie alloweu, howevei. Recall that the is-fragment keywoiu matches on
all liagments except the liist liagment, which was matcheu in the liist teim ol the liltei:
term allow-tcp-frags {
from {
is-fragment;
protocol tcp;
}
then {
accept;
}
}
Next, incoming UDP packets aie alloweu to inteinal suLnets that aie not liagments.
This is to allow ietuin tiallic loi outLounu UDP sessions as well as inLounu tiaceioute
packets that use UDP inLounu:
term allow-udp {
from {
destination-prefix-list {
internal-subnets;
}
protocol udp;
}
Firewall Filters | 363
then accept;
}
Lastly, ping anu tiaceioute aie alloweu outLounu. Since this is an input liltei, the ietuin
tiallic is actually Leing alloweu in loi Loth ping (echo ieplies) anu tiaceioute (time
exceeu messages). Auuitionally, unieachaLle messages aie alloweu in loi any possiLle
outLounu eiioi iesponses:
term allow-some-icmp-outbound {
from {
destination-prefix-list {
internal-subnets;
}
protocol icmp;
icmp-type [ echo-reply time-exceeded unreachable ];
}
then accept;
}
}
The liltei is applieu to Loth VAN inteilaces on ioutei PBR as the input list ol one to
allow loi liltei auuitions at a latei uate:
lab@PBR# show interfaces
ge-0/0/0 {
vlan-tagging;
unit 412 {
description PBR-to-Wheat;
vlan-id 412;
family inet {
filter {
input-list internet-in;
}
address 172.16.1.2/24;
}
}
unit 413 {
description PBR-to-Water;
vlan-id 413;
family inet {
filter {
input-list internet-in; }
address 64.8.12.6/27;
Case Study: Loopback Filters
Next, tiallic uestineu to the ioutei itsell neeus to Le secuieu. The goals ol this case
stuuy aie to allow:
OSPF tiallic
BGP tiallic liom conliguieu peeis only
SSH liom inteinal suLnets
364 | Chapter 8:Access Security
Viitual Routei Reuunuancy Piotocol (VRRP) packets
Ping anu tiaceioute
Domain Name System (DNS) ieplies
SNMP anu Netwoik Time Piotocol (NTP)
Fiist, ueline a pielix list loi the inteinal suLnets in youi netwoik:
lab@PBR# show policy-options
prefix-list internal-subnets {
10.10.128.0/22;
10.10.12.0/22;
10.20.128.0/22;
}
Since BGP tiallic shoulu Le liom conliguieu peeis only, the apply-path commanu is
useu to avoiu any IP change issues oi neighLoi auuitions that may happen in the lutuie.
The apply-path allows conliguiation elements to Le matcheu when the prefix-list is
applieu Ly using iegulai expiessions. In this case, this will cieate a list ol BGP peeis loi
eveiy BGP gioup conliguieu Lecause ol the match all * iegulai expiession:
prefix-list bgp-configured-peers {
apply-path "protocols bgp group <*> neighbor <*>";
}
The filter protect-router is cieateu with the liist teim allowing SSH tiallic to and
liom the ioutei Lecause ol the port commanu, which matches on eithei the souice oi
uestination poit:
filter protect-router {
term allow-ssh {
from {
source-prefix-list {
internal-subnets;
}
protocol tcp;
port ssh;
}
then accept;
}
Cieate a teim to allow loi OSPF packets:
term allow-ospf {
from {
protocol ospf;
}
then accept;
}
Then take auvantage ol the pielix list that was pieviously cieateu to allow only the
conliguieu BGP peei`s tiallic:
term allow-bgp {
from {
Firewall Filters | 365
source-prefix-list {
bgp-configured-peers;
}
protocol tcp;
port bgp;
}
then accept;
}
Allow VRRP tiallic:
term allow-vrrp {
from {
protocol vrrp;
}
then accept;
}
Don`t loiget aLout DNS ieplies. Since these aie stateless, liltei the ietuin tiallic so that
DNS iesolution is alloweu in:
term dns-replies {
from {
protocol udp;
source-port 53;
}
then accept;
}
SNMP is alloweu:
term snmp {
from {
protocol udp;
port [ snmp snmptrap ];
}
then accept;
}
Also alloweu aie UDP packets with a TTL ol 1 loi tiaceioute to opeiate:
term traceroute {
from {
protocol udp;
ttl 1;
}
then accept;
}
Allow pings, tiaceioutes, anu eiioi messages:
term allow-icmp {
from {
protocol icmp;
icmp-type [ echo-request echo-reply time-exceeded
unreachable ];
}
366 | Chapter 8:Access Security
then accept;
}
NTP is also alloweu:
term allow-ntp {
from {
prefix-list {
internal-subnets;
}
protocol udp;
port ntp;
}
then accept;
}
Lastly, theie is a teim that uenies all othei tiallic (which is the uelault) Lut allows this
tiallic to Le counteu as well as loggeu to a syslog lile:
term match-denied {
then {
count bad-packets;
syslog;
discard;
}
}
}
}
The liltei is then applieu to the loopLack inteilace as an input liltei. Even though it is
just a single liltei, it is auueu as a list loi lutuie expansion:
lab@PBR# set interface lo0.0 family inet filter input-list protect-router
This is a goou point to uust oll the commit confirmed to make suie the liltei uoes not
Lieak the cuiient netwoik oi, woise yet, lock you out ol the ioutei:
[edit]
lab@PBR# commit confirmed
commit confirmed will be automatically rolled back in 10 minutes unless
confirmed
commit complete
# commit confirmed will be rolled back in 10 minutes
[edit]
lab@PBR# commit
commit complete
Be veiy awaie when woiking on iemote uevices anu lo0 lilteis. In the
pieceuing example, altei the commit confirmed was enteieu, connectiv-
ity was veiilieu anu a seconu commit issueu. Il theie aie iouting pioto-
cols in use (e.g., OSPF, BGP), the keepalive timeis coulu take ovei a
minute to expiie. It is piuuent to wait a couple ol minutes piioi to issuing
the seconu commit to veiily that the piotocols uo not time out.
Firewall Filters | 367
Policers
To iate-limit tiallic enteiing an inteilace, you can ueploy a po|iccr. The policeis that
aie implementeu in the ]unipei ioutei aie token-Laseu anu use the IP packet to limit
Laseu on Lanuwiuth anu Luists. The Lanuwiuth is measuieu as the aveiage numLei ol
Lits in ovei a one-seconu inteival (see Figuie S-6). The Luist size is the numLei ol Lytes
that can exceeu the Lanuwiuth constiaints.
Iigurc 8-. Bandwidth |init
The Luist size is what implements the policei`s token-Laseu Lehavioi. The Luist size
will set the initial anu maximum sizes ol a Lucket in Lytes (tokens) that woulu Le
accesseu each time uata neeus to Le sent. As a packet is sent, the Lucket Lytes (tokens)
aie iemoveu liom the Lucket. Il theie aie not enough tokens to senu the packet, the
packet will Le policeu. The Lucket is then ieplenisheu at the Lanuwiuth iate.
In Figuie S-7, a packet that Luists aLove the Lanuwiuth limit is nonetheless sent, as
theie aie enough tokens in the Lucket. Altei the packet is sent, the tokens aie uecieaseu
Laseu on the packet size.
Iigurc 8-7. |nitia| burst
368 | Chapter 8:Access Security
Then, some time latei, anothei packet neeus to Le sent that is also aLove the Lanuwiuth
limit. Since theie aie no longei enough tokens lelt in the Lucket, the packet is policeu
(see Figuie S-S).
Iigurc 8-8. Enpty to|cn buc|ct
As time goes Ly, the Lucket will ieplenish at a iate egual to the Lanuwiuth limit. Vhen
a new packet aiiives, it can Le sent, as tokens aie now availaLle in the Lucket. This
piocess continues ovei a one-seconu inteival, anu the iesult is a iate egual to the Lanu-
wiuth limit (see Figuie S-9).
Iigurc 8-9. To|cn buc|ct rcp|cnishing
Burst-size limit mystery
The setting ol the Luist size has always seemeu to Le a mysteiy loi many opeiatois. Set
this value too low, anu potentially all packets will Le policeu. Set the value too high,
anu no packets will Le policeu. The iule ol thumL is that the Luist size shoulu nevei
Le lowei than 10 times the maximum tiansmission unit (MTU). The iecommenueu
Firewall Filters | 369
value is to set the amount ol tiallic that can Le sent ovei the inteilace in live millisec-
onus. So, il youi inteilace is a GigaLit Etheinet inteilace, the minimum is 15,000 Lytes
(10 1,500), anu the iecommenueu value woulu Le 625,000 Lytes (125,000 Lytes/ms
5).
Policer actions
Once the policei limits have Leen conliguieu, you must choose the action taken il a
packet exceeus the policei. Two types ol policing aie availaLle: sojt policing anu hard
policing. Haiu policing specilies that the packet will Le uioppeu il it exceeus the po-
licei`s tiallic piolile. Solt policing simply maiks the packet oi ieclassilies the packet,
which coulu change the pioLaLility ol the packet Leing uioppeu at the egiess inteilace
uuiing times ol congestion. Solt policing is implementeu Ly eithei setting the packet
loss piioiity (PLP) setting on the packet oi Ly placing the packet into a uilleient loi-
waiuing class. Ve will examine these concepts luithei in Chaptei 11.
Configuring and applying policers
Policeis aie conliguieu unuei the [edit firewall] level. The policei will Le nameu anu
then the Luist size will Le applieu in Lytes/seconu, the Lanuwiuth limit in Lits/seconu,
oi the peicentage ol inteilace Lanuwiuth set along with the policei action. Foi example:
policer simple {
if-exceeding {
bandwidth-limit 50m;
burst-size-limit 15k;
}
then discard;
}
Once you have conliguieu the policei, you must apply it to an inteilace. You can uo
this in one ol two ways: eithei Ly applying the policei uiiectly unueineath the inteilace
oi Ly ieleiencing the policei name in the liiewall liltei. Il you apply the policei uiiectly
to the inteilace, no match conuitions can Le useu. Il you ieleience the policei in a liltei,
specilic types ol tiallic can Le policeu as the entiie toolkit ol liltei actions is alloweu.
You can apply Loth an inteilace policei anu a policei in a liltei at the same time. In this
case, a kinu ol hieiaichical policing is useu as inteilace policeis aie evaluateu Leloie
input lilteis anu altei output lilteis. Figuie S-10 shows policei piocessing.
Iigurc 8-10. Po|iccr proccssing
370 | Chapter 8:Access Security
Since you can apply the same liltei to multiple inteilaces, you can apply
the same policei to multiple inteilaces. In this case, the aggiegate Lanu-
wiuth ol all the inteilaces is examineu Leloie any policing paiameteis.
To avoiu this Lehavioi anu cieate a sepaiate instance loi each inteilace,
incluue the interface-specific commanu in the liltei. This will cieate
unigue policeis anu counteis loi each inteilace to which the liltei is
applieu.
Policer example
In this section, we will examine a veiy simple two-level policei that:
Limits viitual LAN (VLAN) 12+1 to 1 MB with a Luist size ol 5,000 Lytes
Limits FTP to 10 ol the Lanuwiuth anu ICMP to 500,000 Lits pei seconu
Fiist, the policeis aie uelineu unuei the liiewall level:
lab@Bock# show firewall
policer total-int {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 5k;
}
then discard;
}
policer limit-ftp {
if-exceeding {
bandwidth-percent 10;
burst-size-limit 625k;
}
then discard;
}
policer police-icmp {
if-exceeding {
bandwidth-limit 500k;
burst-size-limit 62500;
}
then discard;
}
Then a liltei is cieateu to match on FTP anu ICMP tiallic to limit each application to
ceitain thiesholus. The interface-specific keywoiu is useu to cieate a unigue instance
ol the liltei il applieu to multiple inteilaces. This is ieguiieu il a policei is ieleienceu
that uses Lanuwiuth peicentage such as the limit-ftp policei:
firewall {
family inet {
filter police-traffic {
interface-specific;
term police-ftp {
from {
protocol tcp;
port [ ftp ftp-data ];
Firewall Filters | 371
}
then policer limit-ftp;
}
term police-icmp {
from {
protocol icmp;
}
then policer police-icmp;
}
term catch-all {
then accept;
}
}
}
}
Apply the liltei anu policei to the inteilace:
lab@Bock# show interfaces ge-0/0/0
vlan-tagging;
unit 1241 {
description Bock-to-PBR;
vlan-id 1241;
family inet {
filter {
input-list police-traffic;
}
policer {
input total-int;
}
address 10.20.130.1/24;
}
}
To veiily whethei the policei is applieu, issue a show interfaces policers commanu:
lab@Bock>show interfaces policers
Interface Admin Link Proto Input Policer Output Policer
ge-0/0/0 up up
ge-0/0/0.1241 up up inet total-int-ge-0/0/0.1241-inet-i
gr-0/0/0 up up
ip-0/0/0 up up
ls-0/0/0 up up
lt-0/0/0 up up
mt-0/0/0 up up
pd-0/0/0 up up
pe-0/0/0 up up
sp-0/0/0 up up
...
To examine whethei packets aie exceeuing the tiallic paiameteis, view the policei
counteis. Foi inteilace policeis, you can see packet counts with the show policer
commanu:
lab@Bock> show policer total-int-ge-0/0/0.1241-inet-i
Policers:
372 | Chapter 8:Access Security
Name Packets
total-int-ge-0/0/0.1241-inet-i 5
Policeis that aie ieleienceu in a liiewall liltei automatically get counteis cieateu loi
them Laseu on the policei name, inteilace applieu, anu uiiection. You can view these
in the same commanu as noimal counteis loi lilteis, with the show firewall commanu:
lab@Bock> show firewall
Filter: ge-0/0/0.1241-i
Policers:
Name Packets
police-icmp-police-icmp-ge-0/0/0.1241-i 0
limit-ftp-police-ftp-ge-0/0/0.1241-i 0
Filter: _ _default_bpdu_filter_ _
Filter: police-traffic
Policers:
Name Packets
police-icmp-police-icmp 0
limit-ftp-police-ftp 0
A uilliculty is ueteimining how much tiallic the policei is allowing to asceitain il the
exceeuing paiameteis aie too laige oi too small. You can uo this using the policei
counteis, inteilace statistics, anu a little math. Fiist, ueteimine the Lyte-pei-packet size
the policei sees Ly uiviuing the Lytes Ly the numLei ol packets as seen Ly the policei
countei. Then, multiply the egiess iate in packets pei seconu Ly the pei-packet size
anu S Lits to get the Lytes pei seconu.
Foi example, say the policei countei claimeu 1,+06,950 Lytes anu 1S,+9+ packets ex-
ceeueu the policei. This woulu calculate to an aveiage pei-packet size ol 76 Lytes
(1,+06,950/1S,+9+). Then, via the show interfaces commanu, the inteilace iate woulu
Le ueteimineu to Le 203 packets pei seconu (pps). So, 203 pps multiplieu Ly 76 Lytes
uiviueu Ly a packet time ol S Lits pei seconu will pioviue a Lytes-pei-seconu iate ol
123,+2+, which shoulu Le close to the conliguieu Lanuwiuth iate.
Summary of Firewall Filters and Policers
Stateless liiewall lilteis ollei the auvantage ol high-speeu piocessing, which allows you
to maintain local contiol plane anu tiansit secuiity at neai-wiie-iate speeus. The easy-
to-ieau anu intuitive natuie ol ]unos liltei anu policei syntax makes it easy to cieate,
ueploy, monitoi, anu mouily lilteis.
You may also consiuei the use ol statelul liiewall lilteiing, which pioviues loi enhanceu
packet anu application layei piocessing, using the technigues coveieu in Chaptei 12
anu Appenuix A. The llexiLility ol ]unos soltwaie allows you to choose which solution
is Lest loi a specilic set ol neeus anu, when uesiieu, to use Loth types ol lilteiing loi an
optimal secuiity anu peiloimance solution.
The next section uetails ways in which ]unos can help to pievent the use ol Logus souice
auuiessing, which is a common occuiience in a uistiiLuteu DoS (DDoS) attack.
Firewall Filters | 373
Spoof Prevention (uRPF)
Many uistiiLuteu DoS attacks take auvantage ol auuiess spooling Ly ianuomly se-
lecting an auuiess in the souice lielu ol IP packets. In some attacks, this souice auuiess
is ueteiministic to the taiget netwoik unuei attack. In othei woius, this auuiess will Le
taken out ol the netwoik`s auuiess Llock to cieate attacks on othei inteinal machines
geneiating ICMP eiioi messages oi othei tiallic Lack to the spooleu auuiesses. You
can piotect youisell liom these types ol attacks Ly applying ingiess lilteiing at the euge
ol youi netwoik, which uenies incoming packets with auuiesses out ol the netwoik`s
auuiess Llock. This lilteiing has tiauitionally Leen solveu with an inLounu packet liltei.
Releiiing Lack to the topology in Figuie S-2, note that thiee inteinal auuiess Llocks aie
assigneu to PBR, Ale, anu Bock`s netwoik:
10.10.12S/22
10.20.12S/22
10.10.12/22
So, a simple liltei woulu ueny any auuiesses liom those auuiess Llocks coming liom
the VAN connection oll PBR:
[edit firewall]
lab@PBR# show
family inet {
filter spoof-prevention {
term my-addresses {
from {
source-address {
10.10.128.0/22;
10.20.128.0/22;
10.10.12.0/22;
}
}
then {
count spoofs;
log;
discard;
}
}
term allow-rest {
then count no-spoof;
}
}
}
Apply the liiewall liltei as an input liltei on ge-0/0/0.412 anu ge-0/0/0.413:
lab@PBR# show interfaces ge-0/0/0
vlan-tagging;
unit 412 {
description PBR-to-Wheat;
vlan-id 412;
family inet {
374 | Chapter 8:Access Security
filter {
input-list spoof-prevention;
}
address 172.16.1.2/24;
}
}
unit 413 {
description PBR-to-Water;
vlan-id 413;
family inet {
filter {
input-list spoof-prevention;
}
address 64.8.12.6/27;
}
}
Altei applying the liltei, we can see that spooleu auuiesses aie Leing piopeily uenieu
ovei PBR`s ge-0/00.413 inteilace, as shown in the liiewall log:
lab@PBR> show firewall log
Log :
Time Filter Action Interface Protocol Src Addr Dest Addr
01:39:18 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
01:39:17 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
01:39:16 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
01:39:15 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
01:39:14 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
01:39:13 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
01:39:12 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
01:39:11 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
01:39:10 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
01:39:09 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
The pioLlem with ingiess liiewall lilteis is that you must upuate them manually when
an auuiess Llock oi netwoik changes. A moie uynamic methou that has Leen uevelopeu
to pievent spooling is calleu unicast Rcvcrsc Path Iorwarding (uRPF). RPF is a mech-
anism that is useu in multicast netwoiks to avoiu looping Laseu on the souice IP auuiess
(the ieveise path), not the uestination IP auuiess. In essence, the souice IP auuiess is
compaieu against the ioute taLle to see whethei it was leaineu ovei that inteilace. Il
the packet was ieceiveu via the incoming inteilace on which it was leaineu, it is accep-
teu; il not, the packet will Le uioppeu.
This concept has now Leen extenueu to Unicast packets loi spool pievention to cieate
uynamic lilteis Laseu on the ioute taLle. The mechanism will iemain the same, in that
the souice IP auuiess will neeu to Le veiilieu loi incoming packets. Unicast RPF can
opeiate on one ol two moues:
Strict
The incoming packet must Le ieceiveu on the inteilace that woulu Le useu to
loiwaiu tiallic to the souice IP auuiess. Stiict moue is the uelault.
Spoof Prevention (uRPF) | 375
Loosc
The incoming packet`s souice auuiess must Le in the ioute taLle.
Stiict moue pioviues a ieliaLle, simple, last, anu cheap liltei at the euge ol any netwoik.
The conliguiation to enaLle stiict moue is guite simple; just auu the rpf-check com-
manu unuei the piopei inteilace:
lab@PBR# show interfaces ge-0/0/0
vlan-tagging;
unit 412 {
description PBR-to-Wheat;
vlan-id 412;
family inet {
rpf-check;
address 172.16.1.2/24;
}
}
unit 413 {
description PBR-to-Water;
vlan-id 413;
family inet {
rpf-check;
address 64.8.12.6/27;
}
}
Veiily that uRPF is enaLleu Ly looking loi the uRPF llag in the inteilace:
[edit]
lab@PBR# run show interfaces ge-0/0/0.413 | match uRPF
Flags: uRPF
The packets that lail the RPF check aie automatically counteu on the inteilace:
[edit]
lab@PBR# run show interfaces ge-0/0/0.413 extensive | match RPF
Flags: uRPF
RPF Failures: Packets: 8, Bytes: 672
Stiict moue is the pieleiieu solution when possiLle, Lut it uoes iun into some pioLlems
unuei ceitain scenaiios. In paiticulai, it assumes symmetiical tiallic llows. In the case
ol a BGP multihoming enviionment oi ieuunuant IGP paths, this may not always Le
the case.
RememLei that the uelault loau Lalancing loi a ]unipei ioutei is to
choose a single next hop to install in the loiwaiuing taLle pei
uestination.
PBR is multihomeu to two ISPs (see Figuie S-11) anu ieceives the same set ol ioutes liom
each; howevei, only the ioute ieceiveu liom autonomous system (AS) 666 is active:
lab@PBR# run show bgp summary
Groups: 2 Peers: 2 Down peers: 0
376 | Chapter 8:Access Security
D
o
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 497 249 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Damped...
64.8.12.5 666 1239 1114 0 0 9:15:56 248/248/0
0/0/0
172.16.1.1 420 1354 1238 0 0 9:15:26 0/248/0
0/0/0
Iigurc 8-11. Mu|tihoning
This means that any tiallic ieceiveu liom AS +20 that is an inactive ioute will lail the
RPF check. An example is the 12S.3/16 auuiess Llock:
[edit]
lab@PBR# run show route 128.3.3.4
inet.0: 264 destinations, 513 routes (264 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
128.3.0.0/16 *[BGP/170] 09:20:20, localpref 100
AS path: 666 11537 293 16 I
> to 64.8.12.5 via ge-0/0/0.413
[BGP/170] 09:19:50, localpref 100
AS path: 420 666 11537 293 16 I
> to 172.16.1.1 via ge-0/0/0.412
Since ]unos peiloims uRPF against active paths only, in oiuei to allow loi multihoming
oi asymmetiic tiallic llows you can conliguie a leatuie calleu jcasib|c paths. This knoL
allows eveiy possiLle path in the ioute taLle to Le consiueieu, incluuing active anu
inactive paths. You enaLle this gloLal commanu loi the entiie ioutei unuei the [edit
routing-options] stanza:
lab@PBR# show routing-options
aggregate {
route 10.10.128.0/22;
route 10.20.128.0/22;
route 10.10.12.3/32;
Spoof Prevention (uRPF) | 377
}
autonomous-system 1282;
forwarding-table {
unicast-reverse-path feasible-paths;
}
Loose RPF pioviues less secuiity, as it veiilies only that the ioute is in the ioute taLle
anu uoes not check which inteilace it points to. This is moie ol a ioute piesence check
than an actual veiilication ol the ieveise path. The only Lenelit woulu Le loi routc
nartians, oi packets that aie not cuiiently Leing iouteu. One such example coulu Le
a piivate RFC 191S auuiess il only puLlicly ioutaLle auuiesses aie useu in the netwoik.
Since loose moue saciilices uiiectionality, it is not a iecommenueu appioach to spool
pievention anu has limiteu scope.
Anothei pioLlem with loose moue occuis when a uelault ioute is piesent
in the taLle. In this case, eveiy packet woulu pass the check anu thus
uRPF checks woulu Le negateu. Stiict moue with a uelault ioute will
still veiily that the packet enteieu on the inteilace to which the uelault
ioute points.
To enaLle loose moue on an inteilace, specily the loose commanu altei tuining on
uRPF:
lab@PBR# set interfaces ge-0/0/0.412 family inet rpf-check mode loose
Othei lilteis coulu still Le applieu to the inteilace when uRPF moue is enaLleu; in this
case, the input liltei is examineu liist, anu the uRPF checks piocess only the tiallic that
passes this liltei. Because ol this piocessing, it is haiu to peiloim a log action loi packets
that laileu the RPF liltei. In this instance, you can conliguie a jai| liltei. A lail liltei is
peiloimeu altei the RPF check anu on all tiallic that has laileu the RPF check (see
Figuie S-12).
Iigurc 8-12. Iircwa|| ji|tcr and uRPI rc|ationship
You can use a lail liltei to:
Allow tiallic that woulu noimally lail an RPF check, such as DHCP on a LAN
inteilace
Allow tiallic that woulu noimally lail an RPF check to Le accepteu anu counteu
Allow laileu tiallic to Le piocesseu Ly a liltei mouiliei such as counting oi logging
378 | Chapter 8:Access Security
An example ol the liist liltei coulu Le DHCP ieguests that woulu always lail an RPF
check:
filter rpf-dhcp {
term dhcp {
from {
source-address {
0.0.0.0/32;
}
destination-address {
255.255.255.255/32;
}
}
then accept;
}
}
}
Il tiallic that lails the RPF check shoulu Le luithei examineu, you also can use a lail
liltei. The lollowing liltei woulu Le aLle to log all packets that aie lailing the RPF check:
filter match-spoofs {
term 1 {
then {
log;
discard;
}
}
}
Apply the lail liltei to the inteilace:
[edit interfaced ge-0/0/0]
lab@PBR# show
unit 413 {
description PBR-to-Water;
vlan-id 413;
family inet {
rpf-check fail-filter match-spoofs;
address 64.8.12.6/27;
}
}
View the packets that aie lailing uRPF Ly examining the liiewall log:
lab@PBR# run show firewall log
Log :
Time Filter Action Interface Protocol Src Addr Dest Addr
02:23:59 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
02:23:58 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
02:23:57 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
02:23:56 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
02:23:55 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
02:23:54 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
02:23:53 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
02:23:52 pfe D ge-0/0/0.413 ICMP 10.10.12.3 10.20.128.3
Spoof Prevention (uRPF) | 379
Summary of Spoof Prevention
Cuiient Lest piactices suggest that all souice auuiesses shoulu Le valiuateu as close to
the ingiess point ol tiallic as is possiLle. Histoiically, the auueu piocessing leu to pooi
loiwaiuing peiloimance uue to a lack ol piocessing iesouices. This olten iesulteu in a
total lack ol auuiess enloicement, anu the iesulting ease in which DDoS attacks can Le
successlully launcheu.
The unigue uesign ol ]unos soltwaie allows you to enaLle spool pievention leatuies
while still maintaining a high level ol loiwaiuing peiloimance.
The next section uetails ways that ]unos can help monitoi the ioutei to actively anu
pioactively ueteimine the piesence ol attacks.
Monitoring the Router
Once the access conliguiation is in place, you shoulu monitoi the ioutei loi health anu
analysis. The two piimaiy methous ol iemote monitoiing aie via SNMP anu syslog
(system logging). SNMP is a way to gathei statistics anu othei event inloimation oll
the ioutei, wheieas syslog is useu to gathei vaiious log messages oll the ioutei. To
valiuate these types ol messages, you shoulu use piopei time anu uate stamping, which
is olten implementeu Ly using NTP.
Syslog
Syslog was oiiginally uevelopeu as a methou to senu inloimation loi the senumail ap-
plication in BSD, Lut it was so uselul that it was extenueu to othei applications anu
opeiating systems. Essentially, syslog is a stanuaiu way to senu log messages acioss an
IP netwoik.
Syslog uesciiLes the actual tianspoit mechanism useu to senu these messages anu is
olten useu to uesciiLe the actual application that is senuing them. Oiiginally, it was an
inuustiy stanuaiu anu was not attacheu to an inloimational RFC until 2001, with
RFC 5+2+, The BSD Syslog Piotocol.
Syslog messages aie sent ovei UDP with a uestination poit ol 51+. The IP tianspoit
mechanism is uelineu anu not the actual syslog content. It is lelt to the uiscietion ol
the application oi system couei to cieate an inloimative message to the ieceivei. The
message always contains a message seveiity level anu a lacility level. The jaci|ity |cvc|
can Le uelineu as the type ol message that is Leing sent, anu the scvcrity |cvc| inuicates
the message`s impoitance. TaLle S-5 uelines the seveiity levels.
380 | Chapter 8:Access Security
Tab|c 8-5. Sys|og scvcrity |cvc|s
Numerical code Severity
0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
3 Error: error conditions
4 Warning: warning conditions
5 Notice: normal but significant condition
6 Informational: informational messages
7 Debug: debug-level messages
TaLle S-6 lists the lacility levels that aie availaLle in ]unos.
Tab|c 8-. Sys|og jaci|ity |cvc|s
Facility Description
Any All facilities (all messages)
Authorization Authentication and authorization attempts
Change-Log Changes to the configuration
Conflict-Log Specified configuration is invalid on the routing platform type
Daemon Actions performed or errors encountered by system processes
DFC Events related to dynamic flow capture
Firewall Packet filtering actions performed by a firewall filter
FTP Actions performed or errors encountered by the FTP process
Interactive commands Commands executed by the user interface
Kernel Actions performed or errors encountered by the Junos kernel
PFE Actions performed or errors encountered by the Packet Forwarding Engine
User Actions performed or errors encountered by user-space processes
The uelault system log is calleu messages; you can view it with the show log
messages commanu:
lab@PBR> show log messages
Nov 20 06:00:00 PBR newsyslog[2858]: logfile turned over due to size>128K
Nov 21 09:47:59 PBR login: LOGIN_PAM_AUTHENTICATION_ERROR: PAM authentication error
for user lab
Nov 21 09:47:59 PBR login: LOGIN_FAILED: Login failed for user lab from host
Nov 21 09:48:03 PBR login: LOGIN_INFORMATION: User lab logged in from host [unknown]
on device ttyd0
Nov 21 09:48:06 PBR mgd[2978]: UI_DBASE_LOGIN_EVENT: User 'lab' entering
configuration mode
Nov 21 09:54:36 PBR mgd[2978]: UI_DBASE_LOGOUT_EVENT: User 'lab' exiting
Monitoring the Router | 381
configuration mode
Nov 21 09:54:55 PBR mgd[2978]: UI_REBOOT_EVENT: System rebooted by 'lab'
Nov 21 09:55:09 PBR /kernel: KERNEL_MEMORY_CRITICAL: System low on free memory,
notifying init (#1).
Nov 21 09:55:09 PBR rpd[2800]: Received low-memory signal: no job active, 34 free
pages
Nov 21 09:55:09 PBR rpd[2800]: Processing low memory signal
Nov 21 09:55:49 PBR shutdown: reboot by lab:
Nov 21 09:55:49 PBR init: watchdog (PID 2768) terminate signal sent
Nov 21 09:55:49 PBR init: chassis-control (PID 2770) terminate signal sent
Nov 21 09:55:49 PBR init: alarm-control (PID 2771) terminate signal sent
Nov 21 09:55:49 PBR craftd[2772]: craftd_user_conn_shutdown: socket 8, errno = 0
Nov 21 09:55:49 PBR init: craft-control (PID 2772) terminate signal sent
Nov 21 09:55:49 PBR snmpd[2811]: SNMPD_CLOSE_SA_IPC: ipc_free_local: closed IPC
socket /var/run/craft
Nov 21 09:55:49 PBR init: management (PID 2773) terminate signal sent
Nov 21 09:55:49 PBR init: inet-process (PID 2775) terminate signal sent
Nov 21 09:55:49 PBR init: syslogd (PID 2682) terminate signal sent
Nov 21 09:55:49 PBR init: ecc-error-logging (PID 2779) terminate signal sent
Nov 21 09:55:49 PBR init: forwarding (PID 2780) terminate signal sent
Nov 21 09:55:49 PBR init: usb-control (PID 2781) terminate signal sent
Nov 21 09:55:49 PBR init: mib-process (PID 2799) terminate signal sent
Nov 21 09:55:49 PBR snmpd[2811]: SNMPD_CLOSE_SA_IPC: ipc_free_local: closed IPC
socket /var/run/mib2d
Nov 21 09:55:49 PBR init: routing (PID 2800) terminate signal sent
Nov 21 09:55:49 PBR rpd[2800]: RPD_SIGNAL_TERMINATE: first termination signal
received
Nov 21 09:55:49 PBR init: l2-learning (PID 2801) terminate signal sent
Nov 21 09:55:49 PBR init: vrrp (PID 2802) terminate signal sent
Nov 21 09:55:49 PBR snmpd[2811]: SNMPD_CLOSE_SA_IPC: ipc_free_local: closed IPC
socket /var/run/vrrpd
Nov 21 09:55:49 PBR rpd[2800]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.20.130.1
(ge-0/0/0.1241) state changed from Full to Down due to KillNbr
(event reason: interface went down)
Nov 21 09:55:49 PBR init: sampling (PID 2803) terminate signal sent
Nov 21 09:55:49 PBR init: class-of-service (PID 2804) terminate signal se
Many ol the syslog messages will have heaueis specilieu in uppeicase letteis that you
can input into the help commanu specilying which lacility the message was loggeu on,
the seveiity level, a uesciiption, anu a iecommenueu action. Looking at the log entiy
loi NovemLei 21, one such heauei is noteu as RPD_OSPF_NBRDOWN:
Nov 21 09:55:49 PBR rpd[2800]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.20.130.1
(ge-0/0/0.1241) state changed from Full to Down due to KillNbr
(event reason: interface went down)
You can examine this message using the help syslog commanu, which inuicates that
an OSPF neighLoi went uown uue to an event:
lab@PBR> help syslog RPD_OSPF_NBRDOWN
Name: RPD_OSPF_NBRDOWN
Message: OSPF neighbor <neighbor> (<interface>) state changed from
<old-state> to <new-state> due to <event> (event reason:
<event-reason>)
Help: OSPF neighbor adjacency was terminated
382 | Chapter 8:Access Security
Description: An OSPF adjacency with the indicated neighboring router was
terminated. The local router no longer exchanges routing
information with, or directs traffic to, the neighboring router.
Type: Event: This message reports an event, not an error
Severity: notice
You can cieate custom logs Ly specilying a lilename, lacility, message lacility, anu
location to senu the message. The message can eithei Le stoieu in a local lile, sent to a
syslog seivei, sent to the console, oi sent to a usei oi gioup ol useis when loggeu in to
the ioutei.
The lactoiy uelault conliguiation enaLles thiee system logs: two logs that aie sent to a
lile, anu one log that is sent to any usei that is loggeu in. Although the uelault system
log ieceives all inloimation as specilieu with the any keywoiu, you can cieate othei liles
loi easiei log paising:
syslog {
user * {
any emergency;
}
file messages {
any any;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
Case study: Syslog
To avoiu having to specily eveiy syslog option availaLle, let`s examine a iealistic ex-
ample with specilic goals. The goals aie as lollows:
Inciease the uelault size ol the ncssagcs lile to 1 MB anu the numLei ol aichives
to 15.
Senu all messages to a syslog seivei with a uomain name ol syslog.tacoshopsl.com.
Ensuie that all messages sent to the syslog seivei aie in the same loimat as the
Cisco iouteis in youi netwoik.
Cieate a syslog lile to log all liiewall liltei log inloimation.
Each syslog lile that is cieateu on a ]unipei Netwoiks ioutei is stoieu in the lile uiiectoiy
var/|og anu is given a size ol 12S KB on a ]-seiies ioutei oi SRX anu 1 MB on an
M-seiies ioutei. Vhen the lile is lull, the lile is cleaieu, an aichive is cieateu ol the olu
uata, anu the lile is wiitten to again. Foi example, once 12S KB ol uata is wiitten into
the ncssagcs lile, that lile will Le cleaieu anu the inloimation will Le moveu into a
ncssagc.0 lile. Vhen the ncssagcs lile is lilleu up again, the olu uata is aichiveu into
ncssagcs.0 anu the olu ncssagcs.0 now Lecomes ncssagcs.1. This will continue loi 10
aichives until the uata is wiitten. In the case stuuy, you shoulu inciease the uelault
Monitoring the Router | 383
numLei ol aichives to 15 anu the lile size to 1 MB. You can uo this with the lollowing
aichive conliguiation:
[edit system syslog]
lab@PBR# set file messages archive files 15 size 1M
[edit system syslog]
lab@PBR# show file messages
any notice;
authorization info;
archive size 1m files 15;
Next, syslog messages neeu to Le sent to a syslog seivei:
[edit system syslog]
lab@PBR# set host syslog.underdogssf.com any any
The uelault ]unos message uoes not senu the piioiity (lacility value anu seveiity) ol the
syslog message, which coulu cause issues when tiying to paise the output at the ieceivei.
Cisco iouteis Ly uelault uo senu this piioiity lielu; to ensuie that Loth venuois senu
the same message loimat, conliguie the explicit-priority keywoiu:
[edit system syslog]
lab@PBR# set host syslog.tacoshopsf.com explicit-priority
Lastly, a new syslog lile is cieateu to log liiewall entiies:
[edit system syslog]
lab@PBR# set file fw-log firewall info
Heie is the complete stanza:
[edit system syslog]
lab@PBR# show
user * {
any emergency;
}
host syslog.underdogssf.com {
any any;
explicit-priority;
}
file messages {
any notice;
authorization info;
archive size 1m files 15;
}
file interactive-commands {
interactive-commands any;
}
file fw-log {
firewall info;
}
384 | Chapter 8:Access Security
SNMP
SNMP is a stanuaiu piotocol useu loi a netwoik management station to ieceive inloi-
mation loi the ioutei (oi agent; see Figuie S-13). The managei can poll the ioutei loi
ioutei health inloimation such as memoiy utilization, link status, oi liiewall liltei sta-
tistics in the loim ol a GET commanu. The ioutei can also senu event inloimation to
the netwoik managei without polling, in a piocess calleu a TRAP.
Iigurc 8-13. SNMP conccpt
The uata stiuctuie that is useu to caiiy inloimation is calleu a Management Inloimation
Base (MIB). An MIB has a stiuctuie in the loimat ol a tiee that uelines gioups ol oLjects
into ielateu sets. These MIBs aie iuentilieu Ly an OLject Iuentiliei (OID), which names
the oLject. The leal ol the OID contains the actual manageu oLjects. MIBs aie uelineu
into two categoiies: stanuaiu anu enteipiise-specilic. Stanuaiu MIBs aie uelineu Ly the
IETF in vaiious RFCs, wheieas enteipiise-specilic MIBs aie uelineu Ly the venuoi anu
must Le compileu into the management station. Heie is an example ol MIB uata taken
liom a netwoik managei:
SNMPv2-MIB::sysDescr.0 = STRING: M120 - Okemos, MI
SNMPv2-MIB::sysObjectID.0 = OID: JUNIPER-MIB::jnxProductNameM120
SNMPv2-MIB::sysUpTime.0 = Timeticks: (80461526) 9 days, 7:30:15.26
SNMPv2-MIB::sysContact.0 = STRING: Doug Marschke - x8675309
SNMPv2-MIB::sysName.0 = STRING: PBR-3
SNMPv2-MIB::sysLocation.0 = STRING: Okemis, MI USA - Rack 4
SNMPv2-MIB::sysServices.0 = INTEGER: 4
To conliguie SNMP on a ]unipei ioutei, you must specily a community stiing on the
ioutei. This acts as a passwoiu to veiily incoming SNMP inloimation on the manage-
ment station:
[edit snmp]
lab@PBR# set community sample
[edit snmp]
lab@PBR# show
community sample;
]unipei Netwoiks iouteis suppoit SNMP v1, SNMP v2, anu SNMP v3.
Monitoring the Router | 385
Vith this Lasic conliguiation, SNMP GETs can Le ieceiveu on any inteilace liom any
management statement. It is iecommenueu that access is iestiicteu to paiticulai intei-
laces anu clients:
lab@PBR# show
interface ge-0/0/0.1141;
community sample {
clients {
10.10.12.4/32;
0.0.0.0/0 restrict;
}
}
Also, the ioutei may want to initiate some inloimation in the loim ol TRAPs. TRAPs
aie sent to a specilieu list ol taigets anu aie uelineu Ly categoiies. PossiLle categoiies
incluue:
Authcntication
Usei login authentication lailuies
Chassis
Chassis anu enviionmental notilications
Conjiguration
Notilication ol conliguiation changes
Lin|
Link status changes
Rcnotc opcrations
Remote opeiation notilications
Rnon-a|arn
Events loi RMON alaims
Routing
Routing piotocol inloimation such as neighLoi status changes
Scrviccs
Events loi auuitional ]unos seivices such as Netwoik Auuiess Tianslation (NAT)
anu statelul liiewall
Sonct-a|arn
A vaiiety ol SONET alaims such as loss ol light, BER uelects, anu so on
Start-up
Vaim anu colu Loots
\RRP cvcnts
VRRP events such as masteiship changes
In the lollowing example, a TRAP gioup calleu health is auueu to the SNMP conligu-
iation that senus chassis anu link TRAPs to station 10.10.12.+:
lab@PBR# show
interface ge-0/0/0.1141;
386 | Chapter 8:Access Security
community sample {
clients {
10.10.12.4/32;
0.0.0.0/0 restrict;
}
}
trap-group health {
categories {
chassis;
link;
}
targets {
10.10.12.4;
}
}
By uelault, Loth SNMP v1 anu v2 TRAPs aie sent. You can oveiwiite
this Ly specilying a veision unuei the TRAP gioup.
It may also Le uselul to walk uown the MIB tiee to veiily inloimation in the MIB anu
loi tiouLleshooting puiposes. To peiloim an SNMP walk on the ioutei, issue the show
snmp mib <object> commanu. In this case, the system MIB is examineu on the ioutei:
lab@PBR> show snmp mib walk system
sysDescr.0 = Juniper Networks, Inc. jsr2320 internet router, kernel
Junos 10.4R1.90 #0: 2010-04-16 07:17:53 UTC builder@ormonth.juniper.net:/volume/build/
junos/10.4/release/10.4R1.9/
obj-i386/bsd/sys/compile/JSR Build date: 2010-12-08 06:50:00 UTC Copyright (c) 1
sysObjectID.0 = jnxProductNameJ2320
sysUpTime.0 = 332346
sysContact.0
sysName.0 = Lager
sysLocation.0
sysServices.0 = 4
NTP
Vhen examining logs, it is essential to ensuie that the piopei uate anu time aie iecoiueu
loi each event. You can set the time anu uate manually on each ioutei using the set
date commanu:
lab@PBR> set date ?
Possible completions:
<time> New date and time (YYYYMMDDhhmm.ss)
ntp Set system date and time using Network Time Protocol servers
Howevei, since many uevices aie likely to Le manageu at once, each with slightly uil-
leient clock speeus anu uiilt, it is viitually impossiLle to keep all the clocks on eveiy
uevice synchionizeu. NTP was uevelopeu loi the puipose ol clock synchionization.
NTP woiks in one ol thiee moues:
Monitoring the Router | 387
C|icnt
A client has a one-way synchionization with a seivei.
Synnctric activc
Theie is egual peei synchionization with each othei`s local clock.
Broadcast
The seivei senus peiiouic Lioaucast messages on shaieu meuia, anu clients listen
to these messages loi synchionization.
NTP uses a concept ol c|oc| strata to ueline the uistance liom the clock ieleience anu
the accuiacy. A stiatum 0 clock is the ieleience clock (such as an atomic clock), anu
each level ol peeiing ielationship uecieases in accuiacy anu stiatum level (see
Figuie S-1+).
Iigurc 8-11. NTP stratun |cvc|s
All NTP conliguiations aie set unuei [edit system ntp]. In the lollowing conliguiation,
Bock is conliguieu in client moue with a seivei ol 10.20.130.5. Also, a Loot seivei is
conliguieu to allow the initial clock setting to Le set at Loot time:
lab@Bock> show configuration system ntp
boot-server 10.20.130.5;
server 10.20.130.5;
Il a ioutei is conliguieu loi NTP anu the clocks aie moie than 12S seconus apait, the
synchionization piocess will lail. In the past, to iecovei liom that scenaiio, the opeiatoi
eithei ieLooteu the uevice with the Loot seivei conliguiation oi set the uate manually
within 12S seconus. ]unos soltwaie now allows you to synchionize the uevice Ly simply
issuing the set date ntp commanu anu avoiuing a ieLoot:
388 | Chapter 8:Access Security
lab@Bock> set date ntp 10.20.130.5
10 Feb 13:50:21 ntpdate[794]: step time server 10.20.130.5 offset 0.000163 sec
To veiily that NTP has woikeu coiiectly, issue the show ntp associations commanu
anu look loi the * next to the iemote IP:
lab@Bock> show ntp associations
remote refid st t when poll reach delay offset jitter
====================================================================
*10.20.130.5 LOCAL(0) 11 u 10 64 17 0.491 12.991 10.140
Check the coiiect time:
lab@Bock> show system uptime
Current time: 2010-12-22 03:53:35 UTC
System booted: 2010-11-20 04:58:58 UTC (1d 22:54 ago)
Protocols started: 2010-11-20 04:59:24 UTC (1d 22:54 ago)
Last configured: 2010-11-22 03:40:02 UTC (00:13:33 ago) by lab
3:53AM up 1 day, 22:55, 1 user, load averages: 0.19, 0.10, 0.03
You also can change the time zone in the ioutei Ly issuing a set system time-zone
commanu:
lab@Bock# set system time-zone ?
Possible completions:
<time-zone> Time zone name or POSIX-compliant time zone string
Africa/Abidjan
Africa/Accra
Africa/Addis_Ababa
Africa/Algiers
Africa/Asmera
---(more 5%)---[abort]
Is NTP Really Working?
The show ntp associations commanu is olten a souice ol mass conlusion anu teiioi
loi opeiatois, as theie is no uistinct Lioken lielu. The synchionization piocess will
Le inuicateu Ly inteipieting the uelay anu ollset lielus, as well as Ly noting the piesence
oi aLsence ol a * chaiactei.
Heie is an example ol an association that has laileu. Notice the space in liont ol the
10.20.130.5 as well as the zeios in the uelay anu ollset lielus. This is an inuication that
no messages have Leen sent at all!
lab@Bock> show ntp associations
remote refid st t when poll reach delay offset jitter
=====================================================================
10.20.130.5 0.0.0.0 0 u 12 64 0 0.000 0.000 4000.00
In compaiison, heie is anothei association that laileu; howevei, notice that theie aie
values in the uelay anu ollset lielus. These inuicate that NTP messages have Leen
exchangeu Lut synchionization has not Leen achieveu, as no * has Leen uisplayeu next
to the iemote peei. The laige ollset is usually an inuication that the clocks aie too lai
apait (aLove the 12S-seconu thiesholu):
Monitoring the Router | 389
lab@Bock> show ntp associations
remote refid st t when poll reach delay offset jitter
==================================================================
10.20.130.5 LOCAL(0) 11 u 25 64 37 0.492 2542804 4000.00
Altei issuing a set date ntp commanu, the clocks synchionize without having to ieLoot
the ioutei. Note the moie sane ollset value anu the piesence ol the illustiious stai next
to the iemote peei auuiess:
lab@Bock> show ntp associations
remote refid st t when poll reach delay offset jitter
=====================================================================
*10.20.130.5 LOCAL(0) 11 u 10 64 17 0.491 12.991 10.140
3:53AM up 1 day, 22:55, 1 user, load averages: 0.19, 0.10, 0.03
Since NTP uses a step piocess to synchionize the clocks altei issuing the
set date ntp commanu, the association coulu still appeai to Le Lioken.
This is noimal loi NTP, so just sit Lack, enjoy a uiink, anu altei thiee
to live minutes, eveiything shoulu Le woiking as noimal.
Summary of Router Monitoring
Many types ol attacks anu netwoik aLuse leave telltale signs, il the opeiatoi only takes
the time to look loi them. The Unix unueipinnings ol ]unos soltwaie ollei lull syslog-
ging capaLilities, which when synchionizeu to othei iouteis via the NTP piotocols can
pioviue invaluaLle loiensics when pioLlems aie Leing investigateu. Using SNMP to
iemotely monitoi netwoik opeiations to incluue the ieceipt ol asynchionous TRAPs
iepoiting anomalous conuitions pioviues an excellent way to auopt a moie pioactive
stance towaiu secuiing youi netwoik.
Conclusion
Vhen the ioutei is ueployeu in the netwoik, you must secuie it piopeily to piotect
youi netwoik, investments, anu haiu woik. The liist step is to conliguie the piopei
useis with access piivileges. Depenuing on the numLei ol useis, the local ioutei oi an
exteinal seivei uataLase may Le useu to holu this inloimation, oi an exteinal seivei.
Once the useis aie in place, you neeu to ueploy packet lilteis to piotect the ioutei.
These lilteis may Le veiy elaLoiate oi guite simple uepenuing on youi secuiity policies.
Also, you may neeu to iate-limit some applications in youi netwoik using policeis.
It also uoes not uo much goou to have a secuie ioutei il you can`t gathei ioutei health
anu othei statistical inloimation liom it. Theieloie, you also shoulu ueploy stanuaiu
piotocols such as SNMP, syslog, anu NTP to achieve these management goals.
390 | Chapter 8:Access Security
Exam Topics
Ve examineu the lollowing Enteipiise Exam Topics in this chaptei:
List the vaiious usei authentication methous.
DesciiLe the uses ol login classes.
DesciiLe authentication oiuei.
DesciiLe system logging.
Iuentily the conliguiation ol a stateless packet liltei.
Secuie the ioutei Ly applying packet lilteis to piotect the Routing Engine.
Evaluate the iesult ol a given stateless packet liltei.
Conliguie SNMP.
Customize class templates with vaiying peimissions anu commanus.
Conliguie anu opeiate the Netwoik Time Piotocol.
Chapter Review Questions
1. Vhat is the uelault passwoiu on the ioutei?
A. ]unipei
B. Cisco
C. Theie is no passwoiu
D. EnaLle
2. Vhich pieuelineu login class allows the usei to have access iights to any login
commanu?
A. Piivilegeu
B. Supei-usei
C. Piivilegeu exec
D. Powei-usei
3. Vhat is the uelault action at the enu ol a liiewall liltei chain?
A. Discaiu
B. Reject
C. Accept
D. Do nothing
+. Vhich inteilace woulu you apply to a liltei to piotect the ioutei`s local tiallic?
A. fxp1
B. fxp0
C. manage
Chapter Review Questions | 391
D. lo0
5. Vhich commanu is useu to view all liiewall liltei counteis, incluuing counteis
automatically cieateu in policeis?
A. show counters
B. show policer
C. show interfaces filters counters
D. show firewall
6. Vhich two leatuies can you use to piotect youi netwoik against spooleu IP au-
uiesses? (Choose two.)
A. Fiiewall lilteis
B. Spool ioutes
C. Unicast ieveise path loiwaiuing
D. Seconuaiy auuiesses
7. Vhich thiee paiameteis aie specilieu in a policei? (Choose thiee.)
A. Banuwiuth limit
B. Policei action
C. Bucket level
D. Buist size
E. Leak iate
S. Choose two possiLle ieasons loi using a lail liltei using uRPF. (Choose two.)
A. Allow packets to pass thiough RPF
B. Log packets that lail RPF
C. Implement NAT
D. Senu tiallic thiough a tunnel
9. Vhich syslog lacility logs all CLI commanus?
A. cli-commands
B. accounting
C. change-log
D. interactive-commands
10. In which uiiectoiy aie all logliles stoieu?
A. /var/honc/uscr
B. /|og
C. /var/honc/|og
D. /var/|og
E. /sys|og
392 | Chapter 8:Access Security
11. Vhich leatuie ol SNMP v2 acts as a passwoiu to authenticate SNMP messages?
A. MIBs
B. Communities
C. OID
D. TRAPs
12. Vhich commanu allows NTP synchionization without a ioutei ieLoot?
A. set system ntp
B. request system time update
C. set date ntp
D. set ntp boot-server
Chapter Review Answers
1. Answei: C. Theie is no uelault passwoiu on a ]unipei ioutei in the lactoiy uelault
conliguiation. A single usei, root, will Le conliguieu with no passwoiu.
2. Answei: B. The class ol superuser allows useis to issue any commanu that they
uesiie on the ioutei. The othei options listeu aie not suppoiteu classes.
3. Answei: A. At the enu ol a liltei chain, il a packet has not matcheu any othei teim,
it will Le uiscaiueu. Special caie must always Le taken when wiiting a liltei to allow
tiallic that woulu otheiwise Le uenieu Ly the linal implicit uiscaiu at the enu ol
the liltei.
+. Answei D. Il a liltei is applieu to the loopLack inteilace, any tiallic local to the
ioutei can Le piotecteu, incluuing iouting piotocol, ICMP, anu FTP tiallic.
5. Answei: D. You can use the show firewall commanu to view counteis uelineu in
any liiewall liltei. Also, any policei that is ieleienceu in a liltei will have a countei
automatically cieateu anu vieweu Ly this commanu. The show policer commanu
will only show the countei loi policeis applieu uiiectly to the inteilace.
6. Answei: A, C. Both liiewall lilteis anu Unicast RPF will help to avoiu packets with
spooleu IP auuiesses. Unicast RPF coulu pioviue loi moie uynamic anu automatic
lilteiing.
7. Answei: A, B, D. Policeis must specily Lanuwiuth anu Luist size limit. Also, once
a packet hits one ol the limits, an action to eithei haiu- oi solt-police must Le
specilieu.
S. Answei: A, B. A lail liltei matches on packets that lail the RPF check. You coulu
use this to accept packets such as DHCP, which woulu always lail an RPF check,
oi to count oi log packets that have passeu an RPF check.
9. Answei: D. The lacility interactive-commands will log any commanus that weie
typeu via any usei inteilace methou, incluuing the CLI.
Chapter Review Answers | 393
10. Answei: D. This is the uiiectoiy loi all syslog anu tiace-options liles.
11. Answei: B. A community will act as a passwoiu loi SNMP messages. This com-
munity value is sent in cleai text on the wiie, which coulu easily Le captuieu. The
next veision ol SNMP coiiects this issue.
12. Answei: C. Il the NTP seivei is ieachaLle, set date ntp will iestait the NTP upuate
piocess without having to ieLoot the ioutei, thus eliminating the neeu loi a boot-
server conliguiation statement.
394 | Chapter 8:Access Security
CHAPTER 9
Junos Layer 2 Services
Once the iouting aspect ol a netwoik has Leen ueployeu, you`ll want auuitional seivices
to Le auueu to lit youi netwoik ieguiiements. In the past, a sepaiate uevice woulu have
peiloimeu these types ol seivices, Lut in mouein netwoiking these tasks have Leen
moveu to the ioutei itsell. Scrvicc is a Lioau teim that can incluue tasks that aie pei-
loimeu at Layei 2 (such as link Lonuing) oi at Layei 3 (such as Netwoik Auuiess
Tianslation NAT). Ve will examine the Layei 2 seivices in this chaptei.
Because many ol these seivices ieguiie intensive packet piocessing on the ioutei, you
may have to install auuitional haiuwaie to avoiu any uegiauation in packet loiwaiuing
anu thioughput. Although this may seem to Le a slight nuisance at liist, it uoes solve
the pioLlem ol incieaseu seivices causing uecieaseu thioughput, as is oLseiveu in most
othei ioutei implementations.
The seivice topics coveieu in this chaptei incluue:
]unos seivices
Layei 2 seivices
Auuitional seivice options
The inloimation coveieu in this chaptei is Laseu on seivices that aie implementeu via
ASP on the M7i, a DSP on the MX seiies, oi on the ]-seiies oi SRX thiough its emulation
ol ASP lunctionality.
Junos Services
A ]unos soltwaie seivice consists ol a vaiiety ol Layei 2 seivices, incluuing:
Multilink Point-to-Point Piotocol (MLPPP)
Multilink Fiame Relay (MLFR)
Compiesseu Real-Time Tianspoit Piotocol (CRTP)
Multiclass MLPPP
395
Aggiegateu Etheinet (AE)
Etheinet Switching
Statelul liiewall
NAT
Intiusion uetection seivice (IDS)
IPSec
Layei 2 Tunneling Piotocol (L2TP)
Active monitoiing (cllowu)
Tunnel seivices (Geneiic Routing Encapsulation GRE, IP-IP, Physical Inteilace
Mouule PIM iegistei encapsulation)
Data link switching (DLSw)
In an M-seiies ioutei, enaLling these seivices will ieguiie an auuitional piece ol haiu-
waie: a Physical Inteilace Caiu (PIC) loi packet piocessing. A ]-seiies ioutei oi SRX
Seivices Gateway suppoits most ol the leatuies in the pieceuing list anu peiloims the
packet piocessing within the soltwaie, so no special haiuwaie is necessaiy. Depenuing
on the type ol seivice ieguiieu anu the size ol the seivice, uilleient PICs can Le useu.
The cuiient olleiings incluue:
Lin| Scrviccs P|C
Pioviues simultaneous suppoit loi thiee sepaiate capaLilities: enhanceu multilink
Lunuling, tunneling, anu link liagmentation anu inteileaving (LFI) on laigei
M-seiies iouteis.
Encryption Scrviccs P|C
Pioviues IPSec enciyption loi IPSec tunnels.
Monitoring Scrviccs ||| P|C
Pioviues ]-Flow accounting at high speeus anu acioss millions ol llows, using
stanuaius-Laseu cllowu v5 anu vS iecoius loi the laigei M-seiies anu T-seiies
iouteis.
Tunnc| Scrviccs P|C
Pioviues tunnel seivices such as GRE, IP-IP, IPv6 in IPv+, anu multicast tunnels.
Adaptivc Scrviccs P|C (ASP)
The ASP is EOL, Lut still suppoiteu in the M7i. The FIPS veision is still opeiational
loi Layei 2 anu 3 seivices.
Mu|tiscrviccs 100 P|C
Inteinal mouule that suppoits all seivices (loi the M7i only). Can suppoit up to
2,000 seivice sets.
Adaptivc Scrviccs Modu|c (ASM)
The ASM is EOL, Lut still suppoiteu in the M7i.
396 | Chapter 9:Junos Layer 2 Services
Which PIC to Use?
Deciuing which PIC to use is a uelicate Lalance ol leatuie set veisus piice. Foi example,
il all you ieguiie aie IPSec tunnels (which can Le pioviueu on an Enciyption Seivices
PIC 1), you may not neeu to use the moie expensive Multiseivices PIC. Howevei, you
shoulu also consiuei youi neeu loi lutuie seivices. So, il you ieguiie NAT, you woulu
have to use an ASP, oi a Multiseivices PIC since the Multiseivices PIC will uo Loth
NAT anu IPSec; iueally this shoulu Le youi liist choice.
The most common implementation ol seivices will use an MX, ]-seiies, oi SRX without
auuitional haiuwaie, an ASM in an M7i, oi a Monitoiing Seivices PIC in othei M-seiies
iouteis. TaLle 9-1 lists the peiloimance anu scaling values loi these ueployments.
Tab|c 9-1. Scrvicc sca|ing nunbcr
Feature Multiservices 100 ASP ASM
Throughput 920 Mbps 800 Mbps 256 Mbps
Service sets 2,000 2,000 500
Flows 1.6 million 1 million 400,000
MLPPP links 2,048 2,044 2,044
MLPPP bundles 1,023 255 255
IPSec throughput 950 Mbps 640 Mbps 200 Mbps
IPSec tunnels 5,000 2,048 512
In auuition to scaling uilleiences in the vaiious PICs anu platloims, theie aie some
minoi conliguiation uilleiences when ieleiencing the inteilace names loi Layei 2 seiv-
ice, as shown in TaLle 9-2.
Tab|c 9-2. Scrvicc intcrjacc naning
Service interface ASM ASP Multiservice Multilink service SRX/J-series
Layer 2 lsq lsq lsq ml ls
In ]unos 10.0, the inteilace useu loi Multilink lunctionality has Leen
moveu liom the ls-0/0/0 inteilace to the lsq-0/0/0 inteilace loi SRXs
anu ]-seiies iouteis. The conliguiation examples shown aie all lsq in-
teilaces, except loi conliguiations that uo not suppoit the lsq inteilace;
in those cases, the oluei ls inteilace is useu.
Junos Services | 397
Layer 2 Services
Layei 2 seivices aie essentially the seivices that aie enaLleu on a physical inteilace such
as LFI (FRF.12), MLFR (FRF.15), usei-to-netwoik inteilace (UNI) NNI (FRF.16),
MLPPP, anu multiclass MLPPP.
Multilink PPP
MLPPP (RFC 1990) allows the ioutei to comLine multiple links togethei into one laige
logical Lunule (as shown in Figuie 9-1). This was oiiginally cieateu to Lonu multiple
Integiateu Seivices Digital Netwoik (ISDN) Leaiei signals togethei, Lut it is now useu
loi any two systems with multiple links Letween them. Multilink is negotiateu uuiing
the initial Link Contiol Piotocol (LCP) option negotiation. Vhen conliguiing MLPPP
on a ]unipei ioutei, you can comLine into one Lunule any eight PPP links ol the
sanc type on the chassis. To conliguie MLPPP, liist cieate a logical Lunule link:
lsq-0/0/0 {
unit 0 {
encapsulation multilink-ppp;
family inet {
address 166.8.67.30/30;
}
}
}
Iigurc 9-1. MLPPP bund|c
Next, conliguie the physical inteilaces to link the newly cieateu link seivice inteilace.
In the lollowing example, inteilaces t1-1/0/0 anu t1-1/0/1 aie linkeu to the logical
Lunule unit 0 on the lsq-0/0/0 inteilace:
t1-1/0/0 {
unit 0 {
family mlppp {
bundle lsq-0/0/0.0;
}
}
}
t1-2/0/1 {
unit 0 {
family mlppp {
bundle lsq-0/0/0.0;
}
398 | Chapter 9:Junos Layer 2 Services
}
}
Vhen theie aie multiple links in youi Lunule, packets aLove the minimum maximum
tiansmission unit/maximum ieceiveu ieconstiucteu unit (MTU/MRRU) size ol all links
in the Lunule will Le liagmenteu on a packet-Ly-packet Lasis acioss all the physical
links. MRRU is similai to an inteilace MTU except that it applies only to multilink
Lunules. To avoiu out-ol-oiuei issues, a seguence numLei is auueu to each packet. The
ieceiving enu will then ieassemLle the liagments into the lull packet size. The auvantage
ol this appioach is that the high-Lanuwiuth llows aie aLle to use the lull capacity ol all
the egiess links. The uisauvantage ol this pei-packet appioach is that smallei packets
may have to wait loi laigei packets to Le tiansmitteu.
Foi example, imagine you have low uelay-sensitive uata packets tiaveising with a size
ol 1,250 Lytes anu high uelay-sensitive voice tiallic with a size ol 6+ Lytes. Il the uata
packet aiiives liist on a link anu the voice packet aiiives seconu, the voice packet will
have to wait until the uata packet is uone Leloie it can Le sent. On low-speeu inteilaces
with a high seiialization uelay, this coulu gieatly allect the high uelay-sensitive tiallic.
To solve this pioLlem, you can conliguie LFI. Foi link seivices IQ inteilaces (lsg), the
LFI statement is not valiu. Insteau, you can enaLle LFI Ly conliguiing liagmentation
maps.
The liist step is to liagment the laigei-size packets to allow the ioutei to Lalance the
liagments acioss multiple links, thus ieuucing the time it takes to tiansmit the packet:
root@P1R1# set interfaces ls-0/0/0 unit 0 fragment-threshold ?
Possible completions:
<fragment-threshold> Fragmentation threshold (64..16320 bytes)
[edit]
root@P1R1# set interfaces ls-0/0/0 unit 0 fragment-threshold 128
Now that the laigei packets aie liagmenteu, we want to place the nonliagmenteu
packets on the link with the liagmenteu packets. Otheiwise, the voice tiallic will have
to wait loi a|| liagments to tiansmit Leloie Leing sent. To tuin on this Lehavioi, con-
liguie the interleave-fragments commanu unueineath the Lunule conliguiation:
root@P1R1# set interfaces ls-0/0/0 unit 0 interleave-fragments
It is also iecommenueu when LFI is tuineu on that the memLei links
tuin on tiallic shaping to ieuuce jittei. Conliguie the shaping iate to Le
egual to the comLineu physical inteilace Lanuwiuth loi the constituent
links. To apply shaping iates to inteilaces, you must enaLle per-unit
scheduling in the inteilaces.
Since each egiess link may not have the same uelay, the packets that aie not liagmenteu
anu aie pait ol the same tiallic llow may aiiive out ol oiuei at the lai enu. To avoiu
this scenaiio (which will inciease uelay anu jittei), each llow shoulu take the same egiess
link.
Layer 2 Services | 399
By uelault, the ]unos opeiating system chooses a single link loi each
unliagmenteu Tiansmission Contiol Piotocol/Usei Datagiam Piotocol
(TCP/UDP) llow ovei MLPPP links using a hash algoiithm, Laseu on
the souice anu uestination auuiesses, souice anu uestination poit num-
Leis, anu piotocol lielu. This uelault Lehavioi ensuies that llows stay
on the coiiect link anu aiiive in the coiiect oiuei at the lai enu.
The linal issue to think aLout is to enaLle the voice tiallic to have a highei piioiity anu
thus Le tiansmitteu Leloie the uata tiallic. Although we will uiscuss class ol seivice
(CoS) in a latei chaptei, we will pioviue a high-level uiscussion heie.
To ensuie that voice tiallic is tiansmitteu liist, place it into a highei-piioiity gueue. Foi
CRTP tiallic, this mapping occuis automatically, wheieas loi othei tiallic, it will have
to Le conliguieu. Note that the ]-seiies anu M-seiies uillei on this mapping. In a ]-seiies
ioutei, high-piioiity tiallic, incluuing CRTP, shoulu on|y Le mappeu to gueue 2 on an
MLPPP link. Vhen the ioutei maps tiallic to constituent links, tiallic liom gueue 2 ol
the Lunule inteilace will Le mappeu to gueue 2 on the constituent links, wheieas tiallic
liom all othei gueues on the Lunule inteilace will Le mappeu to a uelault gueue ol 0
(as shown in Figuie 9-2). Tiallic that is placeu into othei gueues on the Lunule inteilace
anu that is mappeu into gueue 0 on a constituent link will Le seiviceu accoiuing to the
ielative piioiity. In othei woius, il tiallic on the Lunule inteilace is placeu into gueue
1 with a meuium-high piioiity anu into gueue + with a meuium-low piioiity, gueue 1
will Le scheuuleu liist anu will Le placeu into the constituent link`s gueue 0 liist. In an
M-seiies ioutei using multiclass MLPPP, othei gueues Lesiues gueue 0 anu gueue 2
coulu Le utilizeu.
Iigurc 9-2. j-scrics qucuing and LI|
400 | Chapter 9:Junos Layer 2 Services
Multiclass MLPPP
Sometimes when using LFI, liagments liom uilleient classes cannot Le inteileaveu.
This means that all liagments liom a single packet must Le sent Leloie any liagments
liom anothei packet can Le sent. Using LFI, nonliagmenteu packets can Le inteileaveu
with liagmenteu packets to ieuuce the latency ol the nonliagmenteu packets. The
nonliagmenteu packets can also Le placeu into a uilleient gueue to Le tiansmitteu liist,
which Lasically enaLles two classes ol packets: jragncntcd anu nonjragncntcd. This
mouel extenus to scenaiios in which the uelay-sensitive tiallic compiises the nonliag-
menteu packets, Lut lails il theie is high-piioiity liagmenteu tiallic that must take
pieceuence ovei the nonliagmenteu tiallic. In this case, it woulu make sense to Le aLle
to assign a highei piioiity loi some liagmenteu tiallic ovei nonliagmenteu tiallic Ly
placing some liagmenteu tiallic into a highei-piioiity gueue. This mapping ol liag-
ments to uilleient gueues is ieleiieu to as Multiclass Multilink PPP (MCML).
MCML is suppoiteu only on PICs with link seivices intelligent gueuing
(LSQ) inteilace suppoitthat is, ASPs, ASMs, anu Multiseivices PICs.
It is not suppoiteu on a ]-seiies ioutei.
Also, when using classic LFI on MLPPP, packets that aie nonliagmenteu will Le Lal-
anceu acioss a link on a pei-llow Lasis. This can leau to the hot |in| scenaiio wheie a
single llow will always take the same link anu will not lully utilize the lull-Lunule
Lanuwiuth. MCML can help with this pioLlem Ly allowing packets that aie not liag-
menteu to Le loau-Lalanceu acioss multiple links.
Lastly, MCML can Le useu il you simply neeu moie than two CoSs loi eithei liagmenteu
oi nonliagmenteu packets. In geneial, MCML neeus to Le ueployeu il any ol these
ciiteiia has to Le met:
Some liagmenteu tiallic neeus to Le tiansmitteu Leloie nonliagmenteu tiallic.
Nonliagmenteu tiallic neeus to Le Lalanceu acioss multiple links.
Moie than two gueues (0 anu 2) aie ieguiieu.
To conliguie MCML, you shoulu conliguie a liagmentation map wheie a liagmenta-
tion thiesholu is conliguieu anu a multilink class is assigneu the loiwaiuing class. The
othei option is to uisaLle liagmentation on a pei-loiwaiuing class Lasis using the no-
fragmentation commanu. Il the no-fragmentation commanu is useu, the fragment-
threshold anu multilink-class statements cannot Le conliguieu:
[edit class-of-service fragmentation-maps sample forwarding-class
expedited-forwarding]
lab@PBR# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
fragment-threshold Fragmentation threshold (64..9192 bytes)
Layer 2 Services | 401
multilink-class Multilink-Class assigned to this FC (0..7)
no-fragmentation Don't allow fragmentation
Lastly, the liagmentation map must Le tieu to the Lunule inteilace unuei the class-
of-service stanza:
class-of-service {
interfaces {
lsq-0/3/0 {
unit 1 {
fragmentation-map sample;
}
}
}
}
CRTP
On lowei-speeu inteilaces, seiialization anu gueuing uelay can Le a lactoi loi uelays ol
sensitive tiallic. Scria|ization dc|ay is the time it takes to move the packet out the net-
woik inteilace, anu it uepenus on the clock iate anu the size ol the packet. Foi instance,
loi a 512-Lyte packet on a T1, the seiialization uelay woulu Le:
(512 * 8)bits/1,544,000 bits/sec = 2.65 ms
Queuing uelay is the time it takes loi the packet to Le Lulleieu in the ioutei when othei
packets aie Leing tiansmitteu. This uelay is vaiiaLle Lut is ielateu to the seiialization
uelay, as each packet has to wait loi the pievious packet to Le sent Leloie it can Le
tiansmitteu. So, il the Lullei is thiee packets ueep, the uelay to tiansmit the 512-Lyte
packet is not 2.65 ms, Lut peihaps S ms to 19 ms.
The most common type ol uelay loi sensitive tiallic is voice tiallic, which is olten
tianspoiteu using the Real-Time Tianspoit Piotocol (RTP). RTP is simply a stanuaiu
packet loimat to tianspoit voice oi viueo ovei an IP netwoik, usually using UDP poits
in the iange ol 3S+32,767. It piouuces a heauei ol +0 Lytes: 12 Lytes loi RTP, S Lytes
loi UDP, anu 20 Lytes loi IP.
One guick way to ieuuce seiialization anu, potentially, gueuing uelay is to ieuuce the
packet size. Vhen using RTP, you can compiess the entiie IP/UDP/RTP heauei to a 2-
oi +-Lyte heauei. As explaineu eailiei in this chaptei, this is ieleiieu to as Compiesseu
RTP (CRTP) anu is stanuaiuizeu in RFC 250S.
]unipei Netwoiks iouteis can compiess RTP tiallic in MLPPP Lunules. SRXs anu
]-seiies iouteis can also compiess RTP tiallic on stanuaiu PPP inteilaces.
All CRTP voice tiallic is automatically placeu into gueue 2 on SRXs anu
]-seiies iouteis.
402 | Chapter 9:Junos Layer 2 Services
To enaLle CRTP on any inteilace, conliguie the compiession paiameteis on the link
seivices inteilace. The ioutei maps which tiallic to compiess Ly eithei matching on a
iange ol UDP poit numLeis oi matching on the gueue on which the packet was placeu.
You can conliguie Loth conuitions, anu the ioutei tieats the match as a logical OR. In
the lollowing example, a stanuaiu PPP inteilace is using CRTP with a poit iange ol
3S+32,767:
lsq-0/0/0 {
unit 0 {
compression {
rtp {
port minimum 384 maximum 32767;
}
}
family inet {
address 10.10.10.1/30;
}
}
}
You can then map the physical inteilace to the link seivices compiession inteilace:
t1-2/0/2 {
description Bock-to-porter;
unit 0 {
compression-device lsq-0/0/0.0;
}
}
Il you aie using CRTP with MLPPP, simply auu the compiession con-
liguiation to the existing Lunule.
To veiily that CRTP is woiking, use the show services crtp commanu:
lab@Bock# run show services crtp ?
Possible completions:
<[Enter]> Execute this command
extensive Show CRTP extensive output
flows Show CRTP flow table entries
interface Name of link services interface
| Pipe through a command
Use the show services crtp extensive commanu to veiily coiiect conliguiation as well
as tiack statistics loi packets exiting the inteilace:
[edit]
lab@Bock# run show services crtp extensive
Interface: lsq-0/0/0.0
Port minimum: 384, Port maximum: 32767
Maximum UDP compressed sessions: 256
CRTP maximum period: 256, CRTP maximum time: 5
Compression ratio: 0, Decompression ratio: 0, Discards: 0
Layer 2 Services | 403
CRTP stats Receive Transmit
Sessions 0 0
IP bytes 0 0
Compressed bytes 0 0
CRTP packets 0 0
CUDP/CNTCP packets 0 0
Full header packets 0 0
Context state packets 0 0
IP packets 0 0
Compressed packets 0 0
Multilink Frame Relay
Similai to Lonuing multiple PPP sessions togethei, a ioutei can also Lonu multiple
Fiame Relay ciicuits togethei. These will have the same liagmentation anu inteileaving
chaiacteiistics as pieviously uiscusseu with MLPPP. One Lonuing stanuaiu is FRF.15,
which allows the ioutei to Linu multiple Fiame Relay uata-link connection iuentilieis
(DLCIs) togethei into a single logical inteilace, as shown in Figuie 9-3. The DLCIs
coulu Le on the same physical inteilace oi on multiple physical inteilaces, Lut the
aggiegate Lanuwiuth cannot Le gieatei than a DS3. The auvantage ol FRF.15 is that
the pioviuei uoes not have any knowleuge that link Lonuing has occuiieu, Lut the
uisauvantage is that the each MLFR Lunule can communicate with only a single
enupoint.
Iigurc 9-3. IRI.15
FRF.15 on ]-seiies iouteis is suppoiteu only on T1/E1 inteilaces, as ol
]unos S.0R2.
To conliguie FRF.15, liist cieate a logical unit with the Lunule IP auuiess on the link
seivices inteilace anu specily the uesiie loi FRF.15 with encapsulation multilink-
frame-relay-end-to-end:
lsq-0/0/0 {
unit 1 {
encapsulation multilink-frame-relay-end-to-end;
family inet {
address 84.10.113.1/31;
}
404 | Chapter 9:Junos Layer 2 Services
}
}
Then Lonu the local DLCIs` values togethei to the newly cieateu Lunule inteilace. In
this case, the DLCIs weie on the same physical inteilace Lut coulu have also Leen on
uilleient physical inteilaces:
[edit interfaces t1-2/0/2]
lab@Yeast# show
description Yeast-to-hops2;
encapsulation frame-relay;
unit 101 {
dlci 101;
family mlfr-end-to-end {
bundle lsq-0/0/0.1;
}
}
unit 102 {
dlci 102;
family mlfr-end-to-end {
bundle lsq-0/0/0.1;
}
}
Veiily that the links aie Lonueu Ly viewing the Lunule inteilace:
lab@hops# run show interfaces lsq-0/0/0.1
Logical interface lsq-0/0/0.1 (Index 70) (SNMP ifIndex 37)
Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-FR
Bandwidth: 3072kbps
Statistics Frames fps Bytes bps
Bundle:
Fragments:
Input : 71 0 5030 0
Output: 3 0 264 0
Packets:
Input : 71 0 4604 0
Output: 3 0 270 0
Link:
t1-2/0/2.101
Input : 36 0 2540 0
Output: 2 0 176 0
t1-2/0/2.102
Input : 35 0 2490 0
Output: 1 0 88 0
Protocol inet, MTU: 1500
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 84.10.113.0/31, Local: 84.10.113.1
Anothei type ol Fiame Relay Lonuing is calleu FRF.16, which allows the ioutei to take
multiple physical connections liom the pioviuei anu tie them into a single logical con-
nection, as shown in Figuie 9-+. Once this connection is Lonueu togethei, one oi moie
DLCIs coulu Le conliguieu ovei this single logical connection. This allows loi incie-
mental anu incieaseu Lanuwiuth Fiame Relay connections, while also allowing the
Layer 2 Services | 405
pioviuei to comLine each Lunule into multiple high-speeu Lunules in the netwoik. The
auvantage ovei FRF.15 is that a uilleient enupoint in each Lunule is suppoiteu, Lut the
uisauvantage is that the pioviuei is no longei tianspaient to Lunuling.
To conliguie FRF.16 on a ]unipei ioutei, the link seivices inteilace is conliguieu anu
channc|izcd. A channel is uesignateu, Lut the colon (:) iepiesents the FRF.16 logical
Lunule. You can conliguie a single DLCI oi multiple DLCIs to uilleient enupoints in
this Lunule.
Fiist, to cieate a channelizeu Lunule inteilace, set the mlfr-unu-nni-bundles statement
unuei [edit chassis]. Channels stait counting at zeio, so the lollowing conliguiation
will cieate an lsq-/0/0/0:0:
chassis {
fpc 0 {
pic 0 {
mlfr-uni-nni-bundles 1;
}
}
Heie is a Lunule specilieu as channel 1 with one DLCI specilieu:
lsq-0/0/0:0{
encapsulation multilink-frame-relay-uni-nni;
unit 0 {
dlci 101;
family inet {
address 101.88.77.1/30;
}
}
}
A last point to unueistanu in MLFR is that the physical inteilaces, such as those with
two ]unipei T1s, will neeu to Le Lonueu togethei to the logical Lunule lsq-0/0/0:0
inteilace:
t1-2/0/2 {
encapsulation multilink-frame-relay-uni-nni;
unit 0 {
family mlfr-uni-nni {
bundle lsq-0/0/0:0
}
}
}
t1-2/1/2 {
Iigurc 9-1. IRI.1
406 | Chapter 9:Junos Layer 2 Services
encapsulation multilink-frame-relay-uni-nni;
unit 0 {
family mlfr-uni-nni {
bundle lsq-0/0/0:0
}
}
}
GRE
Heie we examine the conliguiation ol a geneiic iouting encapsulation (GRE) tunnel:
gr-0/0/0 {
unit 0 {
tunnel {
source 10.20.1.38;
destination 172.66.13.1;
}
family inet
}
}
Although vaiious PICs will allow a GRE tunnel to Le cieateu on an M-seiies ioutei,
using an ASP, a Multiseivices PIC, oi a ]-seiies ioutei can enaLle a lew auuitional
leatuies, namely key numLeis (ASP, Monitoiing Seivices only), liagmentation, anu
tunnel MTU.
Although GRE tunnels aie suppoiteu on an M-seiies ioutei using an
ASP in Layei 2 oi Layei 3 moue, liagmentation anu GRE keys aie sup-
poiteu only in Layei 3 moue.
The liist leatuie is taken liom RFC 2S90 anu is calleu Key anu Seguence NumLei
Extensions to GRE. This RFC auus two moie optional lielus that can Le caiiieu in the
GRE heauei: a |cy jic|d anu a scqucncc nunbcr jic|d. The key lielu is inseiteu Ly the
senuei anu is matcheu at the ieceivei to iuentily lielus. Il the key lielus uo not match,
the packet is uioppeu. Cuiiently, only the ASP anu Monitoiing Seivices PIC suppoit
this leatuie, anu only one key is alloweu pei souice anu uestination paii. To enaLle this
leatuie, manually conliguie a key value unuei the logical unit:
lab@Cider set interfaces gr-0/0/0 unit 0 tunnel key 123
A concein when conliguiing any type ol tunnel is making suie the maximum payloau
is no laigei than the MTU acioss the entiie path. By uelault, the gr inteilace has an
unlimiteu physical MTU anu a piotocol MTU that is eguivalent to the MTU ol the next
hop inteilace towaiu the tunnel uestination. So, when an IP packet aiiives at the ingiess
ioutei, the GRE heauei is auueu, with the uo-not-liagment Lit set, anu the IP packet
is sent to the egiess ioutei. Il a tiansit ioutei hau a smallei MTU than the ingiess ioutei,
the packet woulu Le uioppeu.
Layer 2 Services | 407
A lew tools in the ioutei can solve this issue. Foi example, use path MTU uiscoveiy to
ueteimine the MTUs that aie along the path. In the cuiient ]unos ielease, path uis-
coveiy is enaLleu Ly uelault. The lollowing example shows that the maximum IP pio-
tocol MTU can Le 726:
[edit]
lab@Water# run show interfaces gr-0/0/0.0 extensive | match mtu
Type: GRE, Link-level type: GRE, MTU: Unlimited, Speed: 800mbps
Protocol inet, MTU: 726, Generation: 141, Route table: 0
A pioLlem can aiise when tiallic is coming into the ioutei with an MTU that is too
laige anu the uo-not-liagment Lit is set. Il you must senu tiallic with the uo-not-
liagment Lit ovei the tunnel, you can oveiiiue the senuei`s wishes Ly having the ioutei
cleai the uo-not-liagment Lit. In the lollowing example, ioutei Wheat is tiying to senu
tiallic ovei the GRE tunnel that is too laige, anu Water is senuing an Inteinet Contiol
Message Piotocol (ICMP) eiioi message inuicating that the packet is Leing uioppeu:
[edit]
root@Wheat# run ping 5.5.5.5 size 700 do-not-fragment
PING 5.5.5.5 (5.5.5.5): 700 data bytes
36 bytes from 1.1.1.2: frag needed and DF set (MTU 726)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 02d8 3274 2 0000 40 01 f9a5 1.1.1.1 5.5.5.5
36 bytes from 1.1.1.2: frag needed and DF set (MTU 726)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 02d8 3275 2 0000 40^C
--- 5.5.5.5 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
On an SRX oi ]-seiies ioutei oi with the ASP, ASM, oi Monitoiing Seivices PIC, you
can enaLle a clear-dont-fragment commanu, which allows loi ingiess liagmentation
as well as cleaiing the uo-not-liagment Lit on all packets that tiansmit the tunnel. Note,
howevei, that although the oiiginal packets have the uo-not-liagment Lit cleaieu, the
GRE packets still have the DF Lit set. This commanu is set on Water:
[edit]
lab@Water# set interfaces gr-0/0/0 unit 0 clear-dont-fragment-bit
[edit]
lab@Water# commit
[edit interfaces gr-0/0/0]
'unit 0'
gr-0/0/0.0: Must configure INET family MTU
error: configuration check-out failed
To use this commanu, you must also set the MTU value so that the ingiess ioutei knows
which size packets to Legin liagmenting. This MTU value shoulu Le the smallest value
along the entiie path ol the GRE tunnel:
lab@Water# set interfaces gr-0/0/0 unit 0 family inet mtu 726
408 | Chapter 9:Junos Layer 2 Services
Veiily coiiect opeiation Ly ieissuing the ping commanu liom ioutei Wheat:
[edit]
root@Wheat# run ping 5.5.5.5 size 1400 do-not-fragment
PING 5.5.5.5 (5.5.5.5): 700 data bytes
1408 bytes from 5.5.5.5: icmp_seq=0 ttl=63 time=18.449 ms
1408 bytes from 5.5.5.5: icmp_seq=1 ttl=63 time=120.600 ms
1408 bytes from 5.5.5.5: icmp_seq=2 ttl=63 time=30.325 ms
^C
Ethernet Aggregation
In Chaptei 2, we exploieu the uses ol Etheinet link aggiegation in the enteipiise, anu
heie we examine the conliguiations that aie useu to implement this capaLility.
Link aggiegation gioups (LAGs), Laseu on IEEE S02.3au, allow you to aggiegate phys-
ical inteilace links on a uevice to inciease Lanuwiuth anu link availaLility. The Link
Aggiegation Contiol Piotocol (LACP), a suLcomponent ol IEEE S02.3au, pioviues au-
uitional lunctionality loi LAGs. The conliguiation loi Etheinet link aggiegation is
compiiseu ol thiee paits.
The liist is to conliguie the numLei ol aggiegation inteilaces that will Le lounu on the
chassis:
lab@Water# set chassis aggregated-devices ethernet device-count 2
The use ol LACP lailuie moues anu piioiities aie also set at the chassis stanza. In this
case we have set the system piioiity to ueteimine the mastei ol the link anu uelineu the
link piotection as nonieveitive. This setting will ieuuce the numLei ol times that the
link will switch ovei:
lab@Water# set chassis aggregated-devices ethernet lacp system-priority 1
lab@Water# set chassis aggregated-devices ethernet lacp link-protection non-revertive
The seconu step in the conliguiation is the uelinition ol the aggiegateu inteilace. The
inteilace type is an aeX inteilace. The auuiessing anu link options aie set on the intei-
lace. The options consist ol the minimum numLei ol links that aie ieguiieu to keep the
ae inteilace opeiational (the uelault is 1), the uelinition ol the speeu ol the aggiegateu
link, anu LACP options. Heie you set the inteilace link speeu to 1 GLps anu give the
inteilace an auuiess. A similai conliguiation is estaLlisheu at the lai enu:
lab@Water# set interfaces ae0 aggregated-ether-options ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> ethernet-switch-profile Ethernet virtual LAN/media access control-level options
flow-control Enable flow control
> lacp Link Aggregation Control Protocol configuration
link-protection Enable link protection mode
link-speed Link speed of individual interface that joins the AE
loopback Enable loopback
minimum-links Minimum number of aggregated links (1..8)
no-flow-control Don't enable flow control
Layer 2 Services | 409
no-link-protection Don't enable link protection mode
no-loopback Don't enable loopback
no-source-filtering Don't enable source address filtering
> source-address-filter Source address filters
source-filtering Enable source address filtering
lab@Water# set interfaces ae0 aggregated-ether-options link-speed 1g
lab@Water# set interfaces ae0 unit 0 family inet address 10.10.10.1.30
Altei the ae inteilace is set, the thiiu step is to conliguie the physical inteilaces that
compiise the links ol the aggiegate. Heie you auu two gigaLit Etheinet inteilaces to the
LAG:
lab@Water# set interfaces ge-0/0/2 gigether-options 802.3ad ae0
lab@Water# set interfaces ge-0/0/3 gigether-options 802.3ad ae0
You can also conliguie the physical inteilaces loi LACP ioles (active oi passive, the
lattei Leing the uelault).
The uses ol LAGs aie iestiicteu Laseu on the type ol seivice useu anu
the uevice type. These iestiictions aie changing with each ielease ol the
]unos opeiating system. Consult the ielease notes to ueteimine the ie-
stiictions loi youi uevices anu coue ieleases.
Once committeu, the inteilace Lecomes active, anu a ping to the lai enu shows that
tiallic is passing on Loth links ol the aggiegate. In this case, the ping tiallic lelt on one
link anu aiiiveu Lack on the othei:
lab@Water# run show interfaces ae0.0 extensive
Logical interface ae0.0 (Index 72) (SNMP ifIndex 155) (Generation 149)
Flags: SNMP-Traps 0x4000 Encapsulation: ENET2
Bandwidth: 0
Statistics Packets pps Bytes bps
Bundle:
Input : 6 0 504 0
Output: 9 0 770 0
Link:
ge-0/0/2.0
Input : 0 0 0 0
Output: 9 0 770 0
ge-0/0/3.0
Input : 6 0 504 0
Output: 0 0 0 0
Switching Services
The SRXs anu ]-seiies iouteis allow you to conliguie inteilaces to opeiate in Layei 2
moue. This pioviues an Etheinet switching capaLility loi ceitain inteilaces on the
ioutei, theieLy ieuucing the neeu loi auuitional switching eguipment. The switching
capaLilities aie iestiicteu to Univeisal PIMs (uPIMs) on the ]-seiies iouteis anu to the
Luilt-in poits on the Lianch ollice SRX mouels (the SRX650 ieguiies an XPIM). The
410 | Chapter 9:Junos Layer 2 Services
PIMs peiloim the switching opeiation, anu the iouting engine peiloims the iouting
opeiations.
You can set the PIMs to ioutei moue (uelault), oi to eithei a noimal switch moue oi
an enhanceu switcheu moue. In the enhanceu switch moue, the mouule switches oi
ioutes the tiallic uepenuing on the uestination MAC auuiess. The Luilt-in poits uo not
suppoit the enhanceu switching moue.
The switch poits suppoit LLDP anu LLDP-MED loi uevice iuentilication anu vaiious
VLAN tagging options. The conliguiation ol these piotocols is coveieu in uetail in
junos Entcrprisc Switching (O`Reilly).
Consiueiing that oui laL eguipment uoes not have uPIMs, the lollowing conliguiation
example is Loiioweu liom a ]6350 with a uPIM in FPC slot 1:
lab@Water# show chassis
chassis {
fpc 1 {
pic 0 {
ethernet {
pic-mode switching;
}
}
}
}
lab@Water# show interface ge-1/0/0
ge-1/0/0 {
gratuitous-arp-reply;
switch-options {
switch-port 0 {
auto-negotiation;
}
switch-port 1 {
no-auto-negotiation;
link-mode full-duplex;
speed 100m;
}
switch-port 2 {
no-auto-negotiation;
link-mode full-duplex;
speed 100m;
}
switch-port 3 {
no-auto-negotiation;
link-mode full-duplex;
speed 100m;
}
...
}
}
}
Layer 2 Services | 411
Additional Service Options
You can enaLle many othei seivices that aie not as common Lut coulu play a laige iole
in youi netwoik. Ve will Liielly uiscuss these seivices heie, Lut you shoulu consult the
ioutei oi PIC uocumentation at http://www.junipcr.nct/tcchpubs loi moie uetaileu con-
liguiation inloimation.
Layer 2 Tunneling Protocol (L2TP)
L2TP is a tunneling piotocol that tunnels PPP packets acioss a netwoik, acting like a
Layei 2 uata link tunneling piotocol. L2TP heaueis anu payloau aie actually sent in a
UDP uatagiam, so mayLe people claim it to Le a Layei 5 oi Layei +.5 piotocol. Each
enupoint ol the tunnel has its own uesignation, one Leing an LNS anu the othei an
LT2P Access Concentiatoi (LAC). A ]unipei Netwoiks ioutei can act as an LNS.
Only M7i anu M10i iouteis suppoit LT2P.
Real-Time Performance Monitoring (RPM)
RPM is a leatuie loi tiacking anu monitoiing youi netwoik Ly senuing netwoik
probcs to othei uevices. These pioLes coulu Le ICMP, UDP, oi TCP
'
uepenuing on the
conliguiation. You can use these pioLes to measuie packet iounu-tiip times, jittei,
uelay, anu packet (pioLe) loss. You also can use RPM to veiily the path towaiu Boiuei
Gateway Piotocol (BGP) neighLois.
RPM uoes not ieguiie an ASP oi Multiseivices PIC, unless you aie con-
liguiing RPM timestamping, which was ieleaseu in ]unos S.1 loi the
senuei anu in ]unos S.3 loi the iesponuei.
You can conliguie pioLes with a vaiiety ol paiameteis, such as the type oi contents ol
the pioLe. Also, you can set thiesholus to tiiggei syslog messages anu Simple Netwoik
Management Piotocol (SNMP) TRAPs. In the lollowing example, ioutei PBR has a pioLe
to senu an ICMP ping to Porter at 10.10.12.2. Seven pioLes shoulu Le sent eveiy thiee
seconus:
[edit services rpm]
lab@PBR# show
probe foo {
test Porter {
probe-type icmp-ping;
' UDP anu TCP pioLes ieguiie a ]unipei seivei.
412 | Chapter 9:Junos Layer 2 Services
target address 10.10.12.2;
probe-count 7;
probe-interval 3;
}
}
To veiily that pioLes aie Leing sent anu uata is Leing ieceiveu, you can examine SNMP
Management Inloimation Bases (MIBs) oi use the local ioutei senuing the pioLes Ly
issuing show services rpm commanus. The liist commanu, history-results, shoulu
show the time at which the pioLes aie sent anu the iounu-tiip length ol the pioLe:
lab@PBR# run show services rpm history-results
Owner, Test Probe received Round trip time
foo, Porter Wed Aug 8 07:02:54 2010 46097 usec
foo, Porter Wed Aug 8 07:07:41 2010 33662 usec
foo, Porter Wed Aug 8 07:07:44 2010 20133 usec
foo, Porter Wed Aug 8 07:07:47 2010 20112 usec
foo, Porter Wed Aug 8 07:07:50 2010 20112 usec
foo, Porter Wed Aug 8 07:07:53 2010 20104 usec
foo, Porter Wed Aug 8 07:07:56 2010 20092 usec
foo, Porter Wed Aug 8 07:07:59 2010 20104 usec
Veiily the actual pioLe iesults Ly issuing a show services rpm probe-results commanu:
[edit services rpm]
lab@PBR# run show services rpm probe-results
Owner: foo, Test: Porter
Target address: 10.10.12.2, Probe type: icmp-ping, Test size: 7 probes
Probe results:
Response received, Wed Aug 8 07:07:59 2010
Rtt: 20104 usec
Results over current test:
Probes sent: 7, Probes received: 7, Loss percentage: 0
Measurement: Round trip time
Minimum: 20092 usec, Maximum: 33662 usec, Average: 22046 usec,
Jitter: 13570 usec, Stddev: 4742 usec
Results over last test:
Probes sent: 7, Probes received: 7, Loss percentage: 0
Test completed on Wed Aug 8 07:07:59 2010
Measurement: Round trip time
Minimum: 20092 usec, Maximum: 33662 usec, Average: 22046 usec,
Jitter: 13570 usec, Stddev: 4742 usec
Results over all tests:
Probes sent: 7, Probes received: 7, Loss percentage: 0
Measurement: Round trip time
Minimum: 20092 usec, Maximum: 33662 usec, Average: 22046 usec,
Jitter: 13570 usec, Stddev: 4742 usec
You also can examine the paths to conliguieu BGP peeis Ly senuing pioLes to conlig-
uieu peeis. Once RPM is conliguieu, pioLes will Le sent to neighLois conliguieu loi
BGP automatically. In this example, ioutei PBR has one BGP neighLoi to ioutei
Porter. The pioLes will Le ICMP pings with live pioLes sent at an inteival ol one seconu.
They will Le 255 Lytes with ICMP uata ol hex 0123+567S9. The test will iun eveiy 60
seconus:
Additional Service Options | 413
[edit services rpm]
lab@PBR# show
bgp {
probe-type icmp-ping;
probe-count 5;
probe-interval 1;
test-interval 60;
history-size 10;
data-size 255;
data-fill 0123456789;
}
As pieviously mentioneu, you can ietiieve the iesults via show services rpm commanus
oi via SNMP in MIBs such as the lollowing:
pingResultsTable
jnxPingResultsTable
jnxPingProbeHistoryTable
pingProbeHistoryTable
The lollowing, linal example uetails the show services rpm probe-results loi PBR`s
BGP peei:
[edit services rpm]
lab@PBR# run show services rpm probe-results
Owner: Rpm-Bgp-Owner, Test: Rpm-Bgp-Test-0
Target address: 10.10.12.2, Source address: 10.20.128.3,
Probe type: icmp-ping, Test size: 5 probes
Probe results:
Response received, Wed Aug 8 07:20:37 2010
Rtt: 20135 usec
Results over current test:
Probes sent: 5, Probes received: 5, Loss percentage: 0
Measurement: Round trip time
Minimum: 20102 usec, Maximum: 69744 usec, Average: 30049 usec,
Jitter: 49642 usec, Stddev: 19847 usec
Results over last test:
Probes sent: 5, Probes received: 5, Loss percentage: 0
Test completed on Wed Aug 8 07:20:37 2010
Measurement: Round trip time
Minimum: 20102 usec, Maximum: 69744 usec, Average: 30049 usec,
Jitter: 49642 usec, Stddev: 19847 usec
Results over all tests:
Probes sent: 10, Probes received: 10, Loss percentage: 0
Measurement: Round trip time
Minimum: 20102 usec, Maximum: 69744 usec, Average: 25119 usec,
Jitter: 49642 usec, Stddev: 14875 usec
Data Link Switching (DLSw)
DLSw is a piotocol that olleis IP iouting suppoit loi unioutaLle, legacy piotocols such
as System Netwoik Aichitectuie (SNA) anu NETBUI/NetBIOS. Once conliguieu, the
414 | Chapter 9:Junos Layer 2 Services
iouteis set up connections with theii local enu systems, as well as with othei peei
iouteis, anu the tiallic llow liom one enu system to anothei is tianspaient, meaning
the piesence ol the iouteu IP netwoik is not known to the enu stations. Vhen DLSw
is conliguieu, TCP sessions aie estaLlisheu Letween peei iouteis anu capaLilities aie
negotiateu. Then a ciicuit is estaLlisheu Letween the enu system anu the ioutei.
DLSw is suppoiteu only on ]-seiies iouteis.
Foi example, in the SNA example shown in Figuie 9-5, the seguence woulu Le as
lollows:
1. An SNA uevice senus out an exploiei liame looking loi Mainliame 1.
2. The ioutei ieceives this liame anu senus a canureach liame to its peei DLSw iouteis.
3. The iemote iouteis loiwaiu the canureach message to theii attacheu Mainliames.
+. Mainliame 1 senus an icanreach iesponse to its local ioutei, which in tuin loiwaius
the liame towaiu the DLSw peeis.
5. Altei the liames have Leen exchangeu, a ciicuit is estaLlisheu Letween the SNA
uevices anu the local iouteis, as well as Letween the peei iouteis.
Iigurc 9-5. DLSw cxanp|c j|ow
Additional Service Options | 415
Flow Monitoring
]unipei Netwoiks iouteis give you the aLility to take monitoieu tiallic llows anu expoit
this uata in cllowu loimat oi uiiect the llows in theii native loimat to uilleient packet
analyzeis. You can also enciypt the llows when senuing them.
One common type ol monitoiing that you can peiloim is calleu activc nonitoring,
wheieLy the ioutei takes the inLounu tiallic, extiacts the llow into a cllowu loimat,
anu senus the cllowu iecoiu ol the matcheu tiallic to a llow collectoi uevice, as shown
in Figuie 9-6. The oiiginal packet is usually loiwaiueu towaiu the uestination, Lut othei
options uo exist, incluuing discard accounting, wheieLy the cllowu iecoiu is sent to the
llow collectoi anu the oiiginal packet is uiscaiueu, oi port nirroring, wheieLy the entiie
packet is copieu anu sent to an auuitional inteilace anu the oiiginal packet is loiwaiueu
on to its intenueu uestination.
Iigurc 9-. Activc j|ow nonitoring
Theie aie some iestiictions on how many actions can Le peiloimeu on a netwoik llow
in the ioutei:
Sampling (cllowu) to a collectoi or poit miiioiing at one time
Foiwaiuing the oiiginal packet or uiscaiu accounting at one time
Anu only ceitain comLinations ol conliguiations aie alloweu on the sanc set ol tiallic:
Poit miiioiing anu loiwaiuing
Poit miiioiing anu uiscaiu accounting
Sampling anu loiwaiuing
Sampling anu uiscaiu accounting
Sampling (cllowu) anu poit miiioiing can Le peiloimeu at the same time only il they
aie on uilleient sets ol tiallic. Sampling anu miiioiing aie not suppoiteu on the SRX-
seiies gateways.
416 | Chapter 9:Junos Layer 2 Services
Tunnel Services
Ve have alieauy uiscusseu a vaiiety ol uilleient tunnels, anu even moie can Le con-
liguieu. You can use these tunnels loi exteinal connections oi loi connections with the
same ioutei. Any tunnel that is cieateu will get an inteinal inteilace cieateu loi it. These
inteilaces aie as lollows:
ip
Foi conliguiing an IP-IP tunnel that encapsulates one IP packet insiue anothei.
This type ol tunnel is olten seen in moLile enviionments wheie the enupoint au-
uiess changes, anu is migiateu to uilleient netwoiks. This coulu also Le uselul in
tunneling IPv6 packets ovei an IPv+ netwoik.
lt
Cieates inteinal tunnel connections Letween uilleient logical iouteis oi VRs in the
same chassis. In a ]-seiies ioutei, you also can use this inteilace to implement CoS
on DLSw anu RPM.
mt
Useu to cieate multicast tunnels. These tunnels aie automatically cieateu when
iunning multicast in a Layei 3 BGP/Multipiotocol LaLel Switching (MPLS) VPN.
pd
Useu to ue-encapsulate PIM iegistei messages sent liom a uesignateu ioutei to a
ienuezvous point (RP) in a multicast netwoik.
pe
Useu to encapsulate PIM iegistei messages sent liom a uesignateu ioutei to an RP
in a multicast netwoik.
vt
Useu to loop a packet thiough the Packet Foiwaiuing Engine (PFE) as an auuitional
instance. This is noimally useu in a VPN enviionment to concuiiently peiloim
Loth an MPLS lookup anu an IP lookup. This is suppoiteu only on M/T-seiies
iouteis anu not on ]-seiies iouteis.
Conclusion
]unos soltwaie olleis a vast numLei ol Layei 2 seivices that you can iun on youi net-
woik. Not all ol these seivices will likely Le iunning on youi netwoik at the same time,
Lut olten you`ll use them loi the leatuies anu secuiity they ollei. This chaptei examineu
the conliguiation ol those seivices, anu how to ueploy them on a single-seivice leatuie
Lasis.
Conclusion | 417
Exam Topics
Ve examineu the lollowing Enteipiise Exam Topics in this chaptei:
Conliguie MLPPP.
Conliguie Layei 2 seivices to optimize voice tiallic.
Aggiegateu Etheinet.
Layei 2 switching seivices.
Chapter Review Questions
1. Vhich type ol seivice allows loi multiple physical inteilaces iunning Fiame Relay
to Le Lonueu togethei into a single logical Lunule?
A. MLPPP
B. FRF.15
C. FRF.12
D. FRF.16
2. Tiue oi False: All Layei 2 seivices will always use the ls- inteilace.
3. Vhich CLI commanu uisplays the numLei ol alloweu aggiegateu Etheinet
inteilaces?
A. show configuration chassis
B. show interface ae
C. show chassis hardware
D. show layer 2 services
+. Vhat type ol loau Lalancing is useu acioss MLPPP links loi liagmenteu tiallic?
A. Pei packet
B. Pei llow
C. Pei liagment
D. Pei poit
5. Il liagmentation is tuineu on loi MLPPP, what type ol loau Lalancing woulu occui
loi unliagmenteu packets?
A. Pei packet
B. Pei llow
C. Pei liagment
D. Pei poit
418 | Chapter 9:Junos Layer 2 Services
6. Vhich leatuie will help to lowei latency ol voice tiallic on a point-to-point link?
A. CHAP
B. Couecs
C. RTP
D. CRTP
7. Inteilaces ol a uPIM can Le conliguieu into which thiee moues?
A. Routing
B. Switching
C. Enhanceu switching
D. Enhanceu iouting
S. Vhich type ol seivice PIC can Le integiateu on an M7i?
A. ASM
B. ASP
C. Monitoiing Seivices
D. Haiuwaie acceleiation
9. How is tiallic chosen to Le compiesseu when conliguiing CRTP? (Choose two.)
A. IP auuiess
B. Poit numLeis
C. Packet size
D. Queue
Chapter Review Answers
1. Answei: D. FRF.16 allows Lonuing ol physical inteilaces togethei, wheieas
FRF.15 Lonus multiple DLCIs togethei.
2. Answei: False. Some PICs will use an lsq inteilace, anu otheis will use an ls in-
teilace. lsq allows loi moie CoS leatuies than ls.
3. Answei: A. In ]unos soltwaie, you conliguie the total numLei ol aggiegate intei-
laces in the chassis stanza.
+. Answei: C. Vhen MLPPP is enaLleu, packets will Le sent uown each link on a pei-
liagment Lasis. Since each packet liagment will have an MLPPP heauei with a
seguence numLei, oiuei will Le maintaineu Ly the enu uevice.
5. Answei: B. Il liagmentation uoes not occui on an MLPPP link, the packets aie
Lalanceu ovei a llow (souice IP, uestination IP, piotocol, etc.). Since nonliagmen-
teu packets will not contain an MLPPP heauei, pei llow is the only way to maintain
packet oiuei.
Chapter Review Answers | 419
6. Answei: D. Compiesseu RTP uecieases the heauei size to a lew Lytes, which ie-
uuces seiialization anu gueuing uelay.
7. Answei: A, B, C. The uPIM mouule on ]-seiies iouteis anu the XPIM on the SRX650
can Le conliguieu to opeiate in ioutei, switch, oi enhanceu switch moues ol
opeiation.
S. Answei: A. You can integiate ASM into an M7i ioutei only. Foi othei M-seiies
iouteis, you must install a physical PIC into a slot.
9. Answei: B, D. Tiallic can Le classilieu loi RTP compiesseu Laseu on poit numLeis
oi Laseu on which gueue a packet was placeu into. Il Loth match conuitions aie
conliguieu, a packet will Le compiesseu il eithei conuition is met.
420 | Chapter 9:Junos Layer 2 Services
CHAPTER 10
Class of Service
This chaptei uetails class ol seivice (CoS) capaLilities while also uemonstiating typical
CoS conliguiation anu veiilication steps unuei the ]unos opeiating system. A uetaileu
compaiison Letween the ASIC-Laseu anu the soltwaie-Laseu platloim is pioviueu to
claiily theii opeiational uilleiences, which is a common souice ol conlusion given that
they have so many similaiities. The topics coveieu incluue:
Vhat IP CoS is anu why it is neeueu
IP uilleientiateu seivices piimei
CoS capaLilities
DillSeiv-Laseu CoS ueployment anu veiilication
]-seiies viitual channels
]unipei Netwoiks iouteis ollei extensive suppoit loi IP CoS. As ol this wiiting, the list
ol suppoiteu stanuaius incluues:
RFC 2+7+, Delinition ol the Dilleientiateu Seivices Fielu in the IPv+ anu IPv6
Heaueis
RFC 2597, Assuieu Foiwaiuing PHB Gioup
RFC 32+6, An Expeuiteu Foiwaiuing PHB
RFC 269S, A Two Rate Thiee Coloi Maikei
What Is IP CoS, and Why Do I Need It?
Simply put, CoS pioviues a mechanism Ly which ceitain packets aie alloiueu pieleiieu
tieatment in an elloit to pioviue the associateu application with a level ol peiloimance
ieguiieu loi piopei opeiation. Although the pieceuing sentence seems simple enough,
it implies suppoit loi seveial capaLilities that must woik togethei within each noue
anu in a consistcnt mannei netwoik-wiueloi an IP CoS ueployment to Le successlul.
421
Why IP Networks Need CoS
IP netwoiks aie Laseu on the piinciple ol statistical multiplexing (stat MUX), which is
a iesouice-shaiing technigue that allocates iesouices on an as-neeueu Lasis. A stat MUX
pioviues elliciency gains Ly playing the ouus that a given application oi usei will not
Le active at its peak iate 100 ol the time. By allocating Lanuwiuth iesouices only
when neeueu, a laige numLei ol Luisty applications can Le suppoiteu ovei a netwoik
with an aggiegate capacity that is signilicantly less than the potential aggiegate iate ol
its usei Lase.
To make all this woik, some uegiee ol Lulleiing is neeueu to accommouate the occa-
sional synchionizeu Luists. Because no netwoik has inlinite Lulleis, llow contiol (typ-
ically suppoiteu Ly a viitual ciicuit VC technology) oi simple uiscaiu in the case ol
uatagiam opeiation (connectionless) is neeueu uuiing chionic peiious ol congestion.
Thiowing moie Lulleis at the pioLlem only changes the symptom liom one ol uiscaiu
to one ol uelay anu uelay vaiiance, which is known as jittcr. Although non-ieal-time
applications such as an oiuei-entiy system can toleiate loss anu lengthy/vaiiaLle uelays,
the usei will geneially have a uegiaueu expeiience anu piouuctivity can sullei. Moie
uemanuing ieal-time applications such as Voice ovei IP iapiuly Lecome unusaLle when
loss anu uelay/jittei aie not kept within ielatively stiingent Lounus.
IP netwoiks aie Laseu on statistical multiplexing, anu theie is an incieasing tienu to
conveige all communications, Le it uata, voice, viueo, ieal-time simulation, anu so on
ovei a single IP inliastiuctuie to maximize ietuin on investment anu economy ol scale.
Saving money always looks goou on papei, Lut these gains guickly uisappeai il the
iesult is unpiouuctive, angeieu woikeis who can no longei peiloim theii joLs uue to
inteimittent application peiloimance.
Histoiically, netwoik technologies weie ciicuit-Laseu anu weie uesigneu to suppoit
toll-guality voice. Although theie is little to linu sexy in toll-guality voice, these tel-
ephone netwoik aichitects uiu not iealize that what they hau Luilt into theii netwoik
woulu Lecome the panacea ol IP netwoik guality ol seivice (QoS)namely, a seivice
that pioviues (once connecteu) minimal anu jixcd uelays, lieeuom liom congestion,
guaianteeu Lanuwiuth, in-seguence ueliveiy, anu low loss. All these elements hau to
Le auueu to the IP netwoik to hanule the seivices that weie uesigneu to Le caiiieu on
the telephone netwoik. Legacy ciicuit-switcheu netwoiks aie not without theii uiaw-
Lacks, anu all inuications aie that the lutuie ol voice, uata, anu viueo tianspoit will Le
packet- iathei than ciicuit-Laseu.
OveiLuiluing an IP netwoik with excess Lanuwiuth is a viaLle way to ensuie that all
applications woik piopeily, even uuiing peiious ol peak usage oi netwoik outages. The
lact that costs associateu with Lanuwiuth aie constantly uiopping, anu new ways aie
always Leing lounu to uiive existing liLei to incieasingly highei iates, allows the ovei-
Luilu it anu they will Le happy netwoik uesign philosophy to pass the giggle test,
which is to say that theie aie cases wheie auuing Lanuwiuth is moie expeuient, anu
potentially less costly, than ueploying an IP CoS solution. This is especially tiue il
422 | Chapter 10:Class of Service
existing IP inliastiuctuie ieguiies haiuwaie upgiaues to suppoit CoS, which is olten
the case with legacy geai that may Le stiuggling in the Lasic IP iouting iole anu that
uoes not have the capaLility oi iesouices to pioviue auuitional CoS piocessing.
Vhen simply thiowing Lanuwiuth at the pioLlem is not seen as leasiLle, uue to eithei
economic impact oi eguipment limitations, ueploying IP CoS is the key to successlully
conveiging seivices anu applications onto an IP-Laseu inliastiuctuie.
Although theie aie CoS piocessing vaiiances acioss the piouuct line, all cuiient ]unipei
Netwoiks iouting platloims pioviue IP CoS capaLilities you can ueploy in a piouuction
netwoik without impacting Lasic IP packet loiwaiuing peiloimance.
Circuit-switching inefficiencies
Although legacy ciicuit-switcheu netwoiks olleieu some mighty line CoS, ciicuit-
switcheu technologies aie inellicient oi pooily suiteu as a conveigent technology in
numeious aieas. The ioot cause ol this inelliciency is the lack ol statistical multiplexing
in ciicuit-switcheu netwoiks, which pievents the shaiing ol iesouices uuiing natuially
occuiiing iule peiious in communication stieams. The issues with ciicuit switching anu
netwoik elliciency aie outlineu in the lollowing list, anu they holu tiue whethei using
an analog oi newei uigital (ISDN) type ol ciicuit switch:
B|oc|ing during congcstion
EstaLlishment ol new ciicuits is Llockeu when the netwoik ieaches capacity
thiough a call aumission contiol (CAC) lunction (last Lusy). This Lehavioi helps
to pieseive the CoS ol existing useis, Lut lack ol piioiity/pieemption capaLilities
means that ioutine calls can lock out new useis, even when theii communication
neeus aie high piioiity.
Dcdicatcd rcsourccs
Allocating guaianteeu Lanuwiuth in lixeu chunks (6+ KLps DSO) is inellicient,
even loi voice, given that most communication is Luistythe simple lact that voice
communication is inheiently Luisty, that it is hall-uuplex, anu that speech wave-
loims aie pieuictaLle anu consist ol iule peiious is Lehinu most speech compies-
sion algoiithms.
Iixcd bandwidth a||ocation
The lixeu allocation ol Lanuwiuth can Le too coaise, given that it is Laseu on
multiples ol a 3 KHz voice Lanu coueu into a 6+ KLps channel with stanuaiu Pulse
Coue Mouulation (PCM). Foi some applications, this is too much Lanuwiuth, anu
loi otheis, it is not enough. Bonuing multiple voice channels togethei to loim a
highei-speeu link is possiLle, Lut you aie still loiceu to ueal with complete
channelsone channel may not Le enough anu two might Le too much.
Poor survivabi|ity
In most cases, the lailuie ol any link oi noue along a ciicuit-switcheu connection`s
path iesults in the loss ol that connection. The usei noimally has to ieestaLlish his
connection to iesume communications, which can take time. Fuitheimoie,
What Is IP CoS, and Why Do I Need It? | 423
Lecause ol Llocking, peihaps uue to uiminisheu capacity altei eguipment lailuie,
the call may not succeeu.
To uate, most IP netwoiks aie not CoS-enaLleu. This is Lecause the histoiic application
ol IP as an inteinetwoiking piotocol loi LAN anu VAN inteiconnection simply uiu
not waiiant the auueu complexity, Loth in eguipment uesign anu in the netwoik-wiue
conliguiation neeueu loi a woiking CoS solution. In lact, with some eaily (non-]unipei)
ioutei aichitectuies, enaLling CoS seivices consumeu so many iesouices that loiwaiu-
ing peiloimance was actually bcttcr with CoS uisaLleu.
In othei cases, when some level ol peiloimance was actually ieguiieu, engineeis simply
oveiLuilt the netwoik liom a capacity anu Lanuwiuth peispective. The simple tiuth is
that all ol the woilu`s most sophisticateu CoS piocessing uoes no goou loi a packet
that encounteis a ioutei with ielatively empty gueues anyway; CoS matteis only when
link utilization Legins to exceeu S0; otheiwise, packets aie uispatcheu viitually as
soon as they aiiive, as theie is no appieciaLle gueue lill in such conuitions. Put uillei-
ently, enaLling CoS on an unueiutilizeu netwoik is akin to Luying a low-emissions
vehicle just so that you can use a caipool lane, anu then linuing youi commute is at
2:00 a.m., when the ioauways aie empty anyway.
Even though Lanuwiuth piices continue to tienu uownwaiu while the iaw loiwaiuing
iates ol iouteis continue to iise, theie aie piactical limits to the oveiLuilu anu they
will Le happy philosophy ol netwoik uesign. In auuition, the incieasing tienu towaiu
the use ol IP as a mission-ciitical inliastiuctuie suppoiting many, il not all, ol an en-
teipiise`s uata, voice, anu automation/manulactuiing neeus makes the piioiitization
ol ciitical tiallic a piuuent uecision. In the most Lasic sense, consiuei the outLieak ol
a liie that signilicantly ieuuces youi netwoik`s capacity. Vith the oveiLuilu it sale-
guaiu now up in smoke (pun intenueu), you ieach loi the last unmelteu IP phone
hanuset to summon emeigency help. This is not the time that you shoulu have to ask
youisell whethei you leel lucky; with IP CoS, you |now that youi ciitical voice signaling
anu ielateu meuia packets will Le the liist to Le iouteu, assuming, ol couise, that any
iouting is still possiLle.
The use ol IP-Laseu statistical multiplexing comLineu with a sounu CoS ueployment
pioviues the Lest ol all woilusthe elliciency gains ol statistical multiplexing anu easily
extenueu IP-Laseu signaling piotocols that pioviue CAC (RFC 2205, RSVP) anu/oi
pieemption anu piioiity (RFC +5+2, Implementing an Emeigency Telecommunica-
tions Seivice (ETS) loi Real-Time Seivices in the Inteinet Piotocol Suite), comLineu
with the aLility to suppoit viitually all known application types ovei a single, lutuie-
piool netwoik inliastiuctuie.
'
' Although the lutuie ol IP may well iest with IPv6, veision + has shown a iemaikaLle uegiee ol iesiliency anu
has guietly suppoiteu the woilu`s inteinetwoiking neeus while iival altei iival has come anu gone, leaving
only oLsolete iecommenuations in theii wake. Theie aie numeious migiation stiategies to move liom IPv+
to IPv6, anu the CoS mouels aie the same, which allows uiiect application ol this mateiial to an IPv6
inliastiuctuie when neeueu.
424 | Chapter 10:Class of Service
D
o
CoS Terms and Concepts
This section uelines common IP netwoik CoS teims anu opeiational concepts in the
context ol ]unos soltwaie, anu the teiminology useu in the Inteinet QoS woiking
gioup`s suivey titleu Netwoik QoS Neeus ol Auvanceu Inteinet Applications. The
ieauei is encouiageu to consult this uocument loi a uetaileu uesciiption ol application-
specilic chaiacteiistics anu typical CoS neeus; the locus heie is stiictly on those QoS
paiameteis anu concepts associateu with IP layei netwoik opeiation anu packet
hanuling.
It shoulu also Le noteu that the actual measuiement ol IP peiloimance, incluuing the
ellects ol CoS, is uelineu in RFC 25++, Benchmaiking Methouology loi Netwoik
Inteiconnect Devices.
This section exploies the lollowing teims anu concepts:
Netwoik QoS paiameteis
Classilication
Packet maiking
Foiwaiuing classes, gueues, anu scheuuleis
Congestion management
Policing anu shaping
Typical CoS piocessing stages in a ]unipei ioutei
Network QoS parameters
In common veinaculai, the teims CoS anu QoS aie useu inteichangeaLly. To help keep
things cleai, this chaptei ieseives the teim QoS loi inuiviuual netwoik paiameteis such
as uelay oi loss pioLaLility, anu uses CoS to uesciiLe the comLineu ellect ol applying
specilic QoS paiameteis to a packet stieam, which shoulu iesult in a seivice uilleien-
tiation among the suppoiteu tiallic classes in youi netwoik.
By way ol analogy, consiuei commeicial aviation anu the typical coach veisus liist-class
tiaveling expeiience. Fiist, il theie weie no uilleiences Letween these seivice classes,
the aiiline woulu have a haiu time chaiging so much moie loi a liist-class seat. It can
Le saiu that the seivice associateu with these classes ol tiavel is in tuin a lunction ol
vaiious QoS paiameteis, such as the maximum time to get a uiink altei Leing seateu
(uelay), the likelihoou ol having youi luggage make it to youi uestination (loss), anu
Leing tieateu to piopei llatwaie anu ieal loou, as opposeu to the expeiience ol using a
plastic spoik (a comLineu spoon/loik) to choke uown a Lag lunch. The comLineu
ellects ol these aiiline-Laseu QoS paiameteis yielu a paiticulai CoS, anu each such
seivice class is uilleientiateu so as to leave little amLiguity as to which class one happens
to Le tiaveling in at any given time.
To get maximum Lenelit ol netwoik QoS, the usei`s application shoulu Le QoS-awaie
so that it can ieguest the appiopiiate iesouices uuiing CAC (when suppoiteu) anu
What Is IP CoS, and Why Do I Need It? | 425
coiiectly maik its tiallic to ensuie that it maps to the uesiieu seivice class oi classes.
The netwoik also has to ollei CoS on an euge-to-euge Lasis, meaning all netwoik ele-
ments have to suppoit CoS. Il the application is not QoS-awaie, the netwoik euge
uevice must step in to pioviue a capaLility to coiiectly iuentily QoS tiallic anu ensuie
that it is hanuleu with the piopei CoS in the netwoik. It is simplei, less eiioi pione,
anu ieguiies less conliguiation to have the applications QoS-awaie.
The piimaiy netwoik QoS paiameteis aie uelineu as lollows:
Bandwidth
Banuwiuth is a measuie ol each link`s inloimation-caiiying capacity. It is limiteu
Ly the lessei ol the Lanuwiuth suppoiteu Ly each link ciosseu Letween two
enupoints.
Dc|ay
Delay is a measuie ol the time taken to move a packet liom one point to anothei.
Enu-to-enu uelay is a cumulative lunction ol seiialization uelays, piopagation ue-
lays, anu any gueuing uelays (Lulleiing) that the packet may expeiience.
Dc|ay variation (jittcr)
Delay vaiiation, olten calleu jittei, is a measuie ol the vaiiance in tianslei uelays
Letween packets that make up a stieam. ]ittei is signilicant to ieal-time applications
Lecause the ieceivei must uimension its jittei Lullei Laseu on maximum jittei,
which auus uelays loi all packets anu causes eventual loss when jittei values exceeu
Lullei capacity.
Loss
Loss measuies the peicentage ol packets not ueliveieu. Loss can stem liom tians-
mission eiiois oi uiscaiu stemming liom congestion in packet-Laseu netwoiks.
Loss pattcrn
The loss pattein uelines the natuie ol a loss event as eithei Luisty (shoit uuiation)
oi chionic, which is sometimes calleu a dribb|c crror.
Classification
Classilication is the act ol associating ieceiveu packets with a uelineu loiwaiuing class,
which in tuin maps to a gueue. Classilication is a ciitical aspect ol IP CoS, in that the
unueilying piinciple ol CoS is to enloice uilleient loiwaiuing Lehavioi on one packet
veisus anothei, Laseu on the associateu set ol QoS paiameteis uelineu loi each loi-
waiuing class. Eiiois in classilication iesult in incoiiect hanuling ol the associateu
packet stieam, which may negate CoS Lenelits Ly tieating all tiallic the same oi Ly
causing congestion in one oi moie loiwaiuing classes, which in tuin leaus to loss anu
uelay-ielateu pioLlems loi that loiwaiuing class. Figuie 10-1 shows how incoming
packets aie suLjecteu to a classiliei lunction that in tuin maps each packet to a uelineu
loiwaiuing class.
At egiess, the loiwaiuing class is useu to link the packet to the coiiect output gueue/
scheuulei piolile. Classilication can Le a iesouice uiain on a ioutei, Lecause it auus
426 | Chapter 10:Class of Service
piocessing steps to each ieceiveu packet. Mouein IP iouteis suppoit two types ol clas-
silication to help mitigate iesouice consumption conceins:
Mu|tijic|d c|assijication
Multilielu classilieis aie the most llexiLle anu theieloie the most computationally
Luiuensome type ol classiliei. As the name suggests, a multilielu classiliei is Laseu
on matches against multiple lielus with the IP packet, incluuing souice anu uesti-
nation auuiesses, piotocol type, poits, anu so on.
Bchavior aggrcgatc (BA)
A BA classiliei uses a lixeu lielu in the packet heauei to make classilication ueci-
sions. This is highly ellicient Lecause ol the lixeu position, length, anu meaning ol
the Lits useu in the BA classilication lielu. Classilications Laseu on IP pieceuence
oi Dilleientiateu Seivices coue points (DSCPs) aie examples ol BA classilication.
Noimally you ueploy multilielu classilieis at the netwoik`s euges, as close to the tiallic
souice as possiLlethat is, in the access layei. Once coiiectly classilieu, the packets
aie typically iemaikeu to peimit the moie ellicient BA type ol classilication in the ag-
giegation anu coie layeis. ]unipei iouteis use liiewall lilteis to peiloim multilielu clas-
silication anu suppoit vaiious types ol BA classilieis, as uetaileu in BA classilication
capaLilities on page ++7. The highly ellicient mannei in which ]unos soltwaie liiewall
lilteis aie compileu anu optimizeu allows laige-scale use ol multilielu classilication
without incuiiing a signilicant ieuuction in loiwaiuing capacity. Vith that saiu, you
shoulu use BA type classilication wheievei possiLle to keep things stieamlineu.
Many CoS mouels expect that loss will Le lowei in some classes than in
otheis, oi that loss will Le lowei loi tiallic within a class when it conloims to the class`s
associateu iate limit, veisus a highei loss pioLaLility loi nonconloimant tiallic. Tech-
nologies such as ATM anu Fiame Relay achieve this lunctionality with the cell loss
piioiity (CLP) anu uiscaiu-eligiLle (DE) Lits, iespectively.
The IP packet heauei uoes not have a mechanism loi signaling a packet`s loss piioiity.
As a iesult, the loss piioiity status loi an IP packet is an inteinal llag that is set Laseu
on classilication oi policing actions. Once a packet is llaggeu at ingiess as having a low
oi high loss piioiity, othei noues aie expecteu to make the same ueteimination
policing is uone at the euge, anu the iesultant loss status shoulu not Le alteieu once
Loss priority.
Iigurc 10-1. C|assijication
What Is IP CoS, and Why Do I Need It? | 427
set. This is noimally accomplisheu Ly iewiiting the BA lielu. Downstieam noues then
use the alteieu BA value uuiing classilication to ueteimine that packet`s loss piioiity.
Packet marking/rewriting
Once mappeu to a loiwaiuing class, a packet can Le suLjecteu to one oi moie iewiite
iules. Rewiite iules aie useu to maik the packet to lacilitate BA classilication in uown-
stieam noues. Figuie 10-2 shows packet maiking in action.
Iigurc 10-2. Pac|ct nar|ing
Step 1 ol Figuie 10-2 shows an incoming packet with a uelault IP pieceuence lielu that
is suLjecteu to a multilielu classiliei. In this example, the packet matches against the
souice auuiess, piotocol, anu poit iange ciiteiia associateu with the Expeuiteu Foi-
waiuing (EF) class, which iesults in a mapping to loiwaiuing class 2. At egiess, the
packet is suLjecteu to an IP pieceuence iewiite iule that is inuexeu accoiuing to each
packet`s assigneu loiwaiuing class anu uiop piioiity. In this example, packets Lelong-
ing to loiwaiuing class 2 (EF) have theii IP pieceuence lielu iewiitten to a Linaiy 010
the alteieu IP pieceuence lielu can now Le useu loi BA-Laseu classilication in uown-
stieam noues (steps 2 anu 3, iespectively). Though not shown, the packet`s local packet
428 | Chapter 10:Class of Service
loss piioiity (PLP) can also Le lactoieu into a iewiite pattein that enaLleu uownstieam
noues, which typically uo not peiloim policing actions, to make the same uiscaiu pii-
oiity ueteimination.
Geneially speaking, you cannot iely upon usei applications to coiiectly maik the BA
lielus ol theii tiallic stieams; uoing so can easily leau to seivice aLuse Ly savvy useis
who know how to change theii opeiating system`s piotocol stack to altei the uelault
maiking ol theii packets. The cuiient Lest piactice is to peiloim multilielu classilication
anu iemaiking to the appiopiiate loiwaiuing class at the netwoikeu euges to ensuie
that BA tags useu in the coie meet youi oiganization`s acceptaLle use CoS policy. Il
uesiieu, you can iewiite the BA lielu to a uelault value at netwoik egiess, peihaps to
meet the ieceiving application`s expectations oi simply to hiue the maikings useu loi
classilication in the coie.
Forwarding classes, queues, and schedulers
It`s Leen estaLlisheu that packet classilication iesults in the mapping ol each packet to
a loiwaiuing class. So, what is a loiwaiuing class? In ]unipei pailance, a loiwaiuing
class essentially maps to a gueue. Typically, theie is a one-to-one mapping ol loiwaiu-
ing class to gueue numLei, Lut a many-to-one mapping is also possiLle. Foi example,
the uelault CoS conliguiation uelines only two loiwaiuing classesBest Elloit (BE)
anu Netwoik Contiol (NC)anu the uelault IP pieceuence classiliei maps the eight
possiLle pieceuence values into these two loiwaiuing classes (gueues) in a 6:1 anu 2:1
iatio, iespectively. Foiwaiuing classes aie ieleienceu Ly symLolic names, which you
can ieueline il uesiieu. TaLle 10-1 shows the uelault mappings.
Tab|c 10-1. Dcjau|t jorwarding c|ass nancs and qucuc nappings
Forwarding class Symbolic name Queue number
0 Best-effort 0
1 Expedited-forwarding 1
2 Assured-forwarding 2
3 Network-control 3
In IP DillSeiv teiminology, a loiwaiuing class maps to a DS bchavior aggrcgatc, oi in
the newei teiminology, an ordcrcd aggrcgatc. The teim ordcrcd heie ieleis to the lact
that packets classilieu as pait ol the same micio-llow shoulu not Le ieseguenceu, anu
theieloie the associateu BA is expecteu to pieseive seguencing. These teims uesciiLe
the exteinally visiLle Lehavioi ol a DillSeiv-compliant noue loi a given BA, which is a
stieam ol packets with the same DSCP maiking ciossing a link in a paiticulai uiiection.
Stating this uilleiently, anu in English, a loiwaiuing class is a stieam ol packets that,
as a iesult ol classilication, aie placeu into the same egiess gueue anu aie theieloie
seiviceu Ly a common set ol uegueuing paiameteis, iesulting in consistent, anu theie-
loie pieuictaLle, hanuling ol packets within that noue.
What Is IP CoS, and Why Do I Need It? | 429
Packets placeu into an egiess gueue aie seiviceu Ly a scheuulei. The scheu-
ulei algoiithm ueteimines how olten a gueue is seiviceu, anu in which oiuei, Laseu on
an associateu piioiity anu tiansmit iate peicentage. Packet scheuuling comLineu with
iate limiting anu policing aie an impoitant aspect ol IP CoS Lecause togethei they
pioviue the necessaiy isolation Letween loiwaiuing classes. This isolation ensuies that
one misLehaving oi nonconloimant loiwaiuing class uoes not uegiaue the seivice ol
othei (compliant) loiwaiuing classes.
The scheuulei essentially contiols how packets aie uegueueu loi tiansmission, anu it
is theieloie a ciitical component ol the ]unos soltwaie CoS mouel. Figuie 10-3 illus-
tiates the high-level opeiation ol a scheuulei.
Iigurc 10-3. Schcdu|cr opcration
Figuie 10-3 shows how packet notilications aiiiving liom the switch laLiic aie placeu
into notilication gueues, Laseu on theii ingiess classilication. Recall that in the ]unipei
aichitectuie, the packets themselves aie placeu into shaieu memoiy once, anu only a
notilication that points to the packet`s shaieu memoiy auuiess is actually gueueu on
the egiess FlexiLle PIC Concentiatoi/Physical Inteilace Caiu (FPC/PIC). The scheuulei
selects the next packet to uegueue Laseu on a lunction ol tiansmission cieuit anu as-
sociateu piioiity.
The Lasic algoiithm is to seivice all high-piioiity gueues with positive cieuit Leloie
moving on to seivice low-piioiity gueues with positive cieuit. Vhen no gueues with
positive cieuit iemain, the scheuulei uiviues any iemaining Lanuwiuth among those
nonempty gueues, typically using a simple iounu-ioLin algoiithm (this can vaiy Ly
platloim, as uetaileu in Scheuuling anu gueuing on page +55). The net iesult is that
all gueues aie guaianteeu to ieceive at least theii conliguieu tiansmission iate, anu
Schedulers.
430 | Chapter 10:Class of Service
high-piioiity gueues will exhiLit less uelay Lecause the associateu gueue is seiviceu
Leloie low-piioiity gueues as long as it iemains within its conliguieu tiansmit iate.
Figuie 10-3 shows the scheuulei state loi each loiwaiuing class as eithei positive (-)
oi negative (-) anu also inuicates the associateu piioiity setting. In this example,
gueue 3 is set to high piioiity, Lut it is cuiiently in negative cieuitthis means the
gueue has sent moie tiallic than its conliguieu tiansmit peicentage anu must now wait
to accumulate cieuit to go positive again. Queue 1 has no packets penuing, so it is
skippeua woik-conseiving scheuulei uoes not seivice empty gueues. The iesult is
that the high-piioiity gueue (=2) with positive cieuit is seiviceu liist, which iesults in
the uegueuing ol its two packets. Because theie aie no iemaining high-piioiity gueues
with positive cieuit anu penuing notilications, the low-piioiity gueues can Le seiviceu,
anu gueue 0, having penuing tiallic anu positive cieuit, is seiviceu next.
Queue 0 is emptieu altei its two packets aie seiviceu, leaving only gueue 3 with tiallic
penuing. Unless this gueue is iate-limiteu, it will Le seiviceu, uespite its negative cieuit
status, as long as no positive cieuit gueues Lecome active. Howevei, seivicing a gueue
with negative cieuit iesults in an inciease in the gueue`s negative cieuit, up to some
maximum value, which, while allowing a gueue to senu moie than its conliguieu
tiansmit iate, ensuies that othei gueues will Le the liist to Le seiviceu as soon as they
have a notilication penuing.
Congestion management
Statistically multiplexeu netwoiks aie suLject to congestion. This can Le chionic as a
lunction ol uesign oi tiansient uue to eguipment oi ciicuit lailuies oi Lecause ol
synchionizeu Luists liom useis. In any ol these events, a methou is neeueu to ueal with
congestion giacelully, anu in a mannei that is laii to all useis. Because uatagiam net-
woiks uo not suppoit llow contiol, uiscaiu is the only mechanism a ioutei has to
pievent total Lullei meltuown uuiing a congestion event.
Mouein IP iouteis implement some loim ol Active Queue Management (AQM), which
is intenueu to optimize uiscaiu actions to oLtain maximum Lenelit anu to ensuie laii-
ness. AQM loi IP netwoiks is uelineu in RFC 2309, Recommenuations on Queue
Management anu Congestion Avoiuance in the Inteinet.
Put simply, when a gueue is lilling lastei than it can Le emptieu, a ioutei has two choices
as to wheie to uiop. It can wait until the gueue can holu no moie, anu then simply uiop
all packets as they aiiive (which is calleu tai| dropping). Oi it can uetect incipient con-
gestion anu proactivc|y Legin to uiop packets Laseu on a pioLaLility lunction that is in
tuin tieu to aveiage gueue uepth. The lattei technigue is known as randon car|y dc-
tcction (RED) anu has many auvantages ovei simple tail uiopping.
Tail uiopping can allow hypeiactive applications to lock out less Lusy useis, anu it
tenus to iesult in gueues opeiating at neai capacity. A gueue is ieally uselul only when
it is aLle to aLsoiL packet Luist, anu any gueue, no mattei how laige, that is neai its
lill capacity Lecomes useless loi aLsoiLing Luist (it`s alieauy lull), anu theieloie seives
What Is IP CoS, and Why Do I Need It? | 431
only to auu uelay. RED acts Leloie the gueue is lull, anu woiks on the piinciple that
Tiansmission Contiol Piotocol (TCP) souices assume that lost segments stem liom
congestion, anu lowei theii winuow auveitisements as a iesult. This ultimately iesults
in less tiallic liom the ielateu TCP souice.
RED seeks to maintain an aveiage gueue lill Ly taking moie aggiessive uiop actions as
the gueue lill incieases. Using the gueue`s aveiage lill level allows toleiance loi ieceiving
packet Luist, Lecause uiscaius aie pioLaLle only when the avcragc gueue level iises
aLove conliguieu thiesholus. RED Legins to peiloim tail uiops once the gueue ieaches
100 lull, in which case no new notilications can Le gueueu anu they aie uioppeu
upon ieceipt. The ianuom natuie ol RED uiscaius avoius the potential ol gueue lockout
ol ceitain useis, as can occui with simple tail uiops. In lact, Lecause RED makes a
uiscaiu uecision upon ieceipt ol each packet, the Lusiest useis expeiience the most
RED-inuuceu uiops, which is moie than laii.
Figuie 10-+ shows a sample RED conliguiation Llock anu a giaphical uepiction ol the
iesultant piolile.
Iigurc 10-1. RED conjiguration and proji|c
Veighteu RED (VRED) is simply a RED algoiithm that maintains uil-
leient uiop pioLaLility pioliles Laseu upon tiallic type. In the ]unipei implementation,
you can inuex one ol as many as loui RED pioliles, Laseu on tiallic type ol TCP veisus
Usei Datagiam Piotocol (UDP) with a loss piioiity ol high oi low. The iesult is a
weighting ol RED uiop actions, Laseu on tiallic type.
Weighted RED.
432 | Chapter 10:Class of Service
Policing and shaping
Packet-Laseu netwoiks aie capaLle ol inteiconnecting uevices anu links that opeiate at
vaiiaLle speeus. Packet Lulleis aie ciitical when suppoiting mixeu-link speeus Lecause
they pioviue an elastic coupling Letween the high- anu low-speeu links. As noteu pie-
viously, a packet Lullei is most uselul when it opeiates at a low lill level. Any packet
netwoik that constantly opeiates neai Lullei capacity shoulu Le ieuesigneu, Lecause a
lull Lullei has lost its aLility to pioviue auuitional Lulleiing anu leaus only to incieaseu
uelays.
The inheient suppoit ol mismatcheu uevice anu link speeus, comLineu with the many-
to-one natuie ol uatagiam netwoiks, can iesult in a chionic conuition in which moie
tiallic aiiives at a uevice than can Le tiansmitteu uownstieam. Il lelt uncheckeu, this
conuition can leau to inuisciiminate tail uioppingVRED tenus to have little ellect
on UDP-Laseu applications, so cannot Le ielieu on to pievent congestion.
To iesolve this type ol pioLlem, a mechanism is neeueu to limit, oi cap, the amount ol
tiallic that a uevice is aLle to senu. Such a mechanism is calleu po|icing oi ratc |init-
ing, anu seives to limit the oveiall amount ol tiallic that can Le sent ovei a given unit
ol time Ly placing limits on maximum packet iate anu Luist size.
Isolation Letween loiwaiuing classes is a ciitical aspect
ol IP CoS. Class-Laseu isolation is pioviueu Ly the scheuulei via its piioiity anu tiansmit
weight settings. Howevei, isolation Letween classes is not sullicient to ensuie laii seiv-
ice loi useis that shaie the same class. Although policing can Le useu on a loiwaiuing
class Lasis, it`s commonly useu at the inuiviuual uevice, oi even at a micio-llow level,
to limit the amount ol tiallic that is accepteu into the netwoik. Policing pioviues the
necessaiy isolation Letween useis oi applications in the same loiwaiuing class to pie-
vent one usei liom uominating the iesouices associateu with that class.
Useis aie olten conluseu aLout the uilleiences Letween policing
anu shaping. Figuie 10-5 shows the opeiational uilleiences.
The lelthanu siue ol Figuie 10-5 shows a typical token-iate-Laseu policei. The size ol
the token Lucket limits the total numLei ol tokens that can accumulate, which in tuin
limits the maximum Luist size. The iate at which new tokens aie auueu limits the
aveiage tiansmission iate. Policeis uo not smooth tiallic Luists, anu they eithei maik
oi uiscaiu tiallic that exceeus the conliguieu Luist size oi aveiage iate ol token accu-
mulation. A policei uoes not Lullei the actual usei tiallic, anu theieloie uoes not auu
appieciaLle uelays.
On the iighthanu siue ol the liguie, the same input tiallic is suLjecteu to a leaky Lucket-
Laseu shapei. The shapei Lulleis the actual usei uata (not tokens, as in the case ol a
policei), anu the ielateu output is spieau ovei time to eliminate Luiststhe shapei
smoothes the peaks anu valleys Ly Lulleiing tiallic anu letting it leak out at a specilieu
iate. The upsiue to shaping is that packet-Lulleiing ieguiiements aie ieuuceu in
Isolation is needed to preserve CoS.
Policing versus shaping.
What Is IP CoS, and Why Do I Need It? | 433
uownstieam noues, given the lack ol Luisting. The uownsiue is the neeu loi Lulleiing
within the shapei, which auus uelay anu cost.
Geneially speaking, on a macio level theie is no uilleience in the amount ol tiallic
tiansmitteu (oi maikeu/uiscaiueu) Ly a policei veisus a shapei when they aie conlig-
uieu with compatiLle paiameteis. At incieasingly smallei time scales, the uilleience is
manilest Ly the aLsence, oi piesence, ol clumpeu packets (Luists) that instantaneously
exceeu the conliguieu aveiage iate. As long as uownstieam uevices aie not opeiating
neai Lullei capacity, policing is geneially pieleiieu to shaping, given that it is less com-
plex anu less costly (Lulleis aie not liee), anu it uoes not inuuce any auuitional Lulleiing
uelays. Stateu uilleiently, you peiloim shaping at an upstieam uevice to condition tiallic
only when neeueu to meet the ieguiiements ol an attacheu uevice with limiteu Lulleiing
capaLilities. Il the uownstieam uevice is not Lullei/capacity-challengeu, it`s lai moie
ellicient to guickly move tiallic liom point A to point B Ly senuing Luists iathei than
aitilicially uelaying each suLseguent packet to eliminate clumping (Luists).
Iigurc 10-5. Po|icing vcrsus shaping
434 | Chapter 10:Class of Service
Summary of CoS processing steps
Figuie 10-6 pioviues a Lig-pictuie view ol the CoS piocessing stages associateu with
]unipei iouteis. Although uselul in its own iight, Lecause ol its uetaileu uepiction ol
]unos CoS capaLilities, the intent heie is to tie the vaiious teims anu concepts uiscusseu
in this section into a single example to show how the vaiious CoS piocess stages woik
togethei.
Iigurc 10-. Big-picturc CoS wa||through
The uiscussion Legins with a packet aiiiving at the ingiess inteilace. The opeiation anu
geneial capaLilities ol each CoS stage encounteieu as a packet tiavels liom ingiess to
egiess aie uesciiLeu as lollows:
|ngrcss CoS proccssing
BA c|assijication
Packets aiiiving at the ioutei aie liist suLjecteu to the BA classilication stage.
This stage sets the loiwaiuing class anu packet loss piioiity (PLP) using any
ol the suppoiteu BA classiliei types, incluuing IP pieceuence, DillSeiv DSCP,
IEEE S02.1P, anu so on.
Mu|tijic|d c|assijication
The next piocessing stage is multilielu classilication. Heie a liiewall liltei can
Le uelineu to match against numeious packet lielus, incoming inteilaces, anu
so on, in oiuei to set the loiwaiuing class oi PLP oi to oveiiiue the values set
uuiing pievious BA classilication.
|ngrcss po|icing
Vhen uesiieu, a liiewall oi inteilace-level policei can Le applieu to limit
matching tiallic, Ly uiscaiu, Ly ieclassilication, oi Ly maiking excess tiallic
with a loss piioiity ol high. This means that in the event ol congestion, a RED
piolile can Le useu to moie aggiessively uiop PLP high tiallic.
What Is IP CoS, and Why Do I Need It? | 435
Iorwarding po|icy
The last ingiess piocessing stage is loiwaiuing policy. This policy can altei the
existing loiwaiuing class oi PLP setting, anu it can Le useu to select a loi-
waiuing next hop Laseu on a loiwaiuing class, a leatuie calleu Class-Baseu
Foiwaiuing (CBF).
Egrcss CoS proccssing
Egrcss po|icing
Altei encounteiing the switching laLiic, a packet Legins its jouiney towaiu the
selecteu egiess inteilace. The liist egiess CoS piocessing state is output polic-
ing, which is again Laseu on eithei a liiewall oi an inteilace-level policei. Once
again, excess tiallic can Le uiscaiueu oi maikeu with a loss piioiity loi latei
uiscaiu in the event ol congestion.
Rcwritc nar|cr
The iewiite maikei stage allows you to altei one, oi in some cases multiple,
packet lielus, as the packet is tiansmitteu to uownstieam noues. Noimally,
you iewiite packet lielus to accommouate uownstieam BA-Laseu classilica-
tion. Rewiite maikeis aie inuexeu Ly piotocol lamily anu Ly loiwaiuing
classloi example, wiiting a 001 pattein into the pieceuence lielu ol all family
inet packets that aie classilieu as BE.
Qucuing and schcdu|ing
The gueuing stage involves placing packet notilications into the coiiesponuing
loiwaiuing class gueue, wheie they aie seiviceu Ly a scheuulei that lactois
piioiity anu conliguieu weight to ueteimine when a packet shoulu Le ue-
gueueu liom a given gueue.
RED/congcstion contro|
The linal CoS piocessing stage involves a VRED uiop uecision, Laseu on pio-
tocol, loss piioiity, anu aveiage gueue lill level. Recall that RED tenus to
opeiate at the heau ol the gueue, anu a RED uecision is maue against each
packet selecteu loi tiansmission Ly the scheuulei stage.
At this stage, it shoulu Le cleai that ]unipei Netwoiks enteipiise iouteis ollei a iich set
ol IP CoS capaLilities that pioviue numeious points wheie a packet can Le toucheu loi
CoS actions oi manipulations. In most cases, a single ioutei woulu not Le conliguieu
to use all ol these capaLilities at the same time, Lut the ]unipei uesign means that all
CoS leatuies can Le ueployeu with minimal impact to the contiol anu loiwaiuing
planes. As a point ol lact, the uelault out-ol-the-Lox conliguiation incluues IP CoS,
alLeit in a ielatively simplilieu mannei. Details iegaiuing the uelault CoS conliguiation
aie pioviueu in ]unos Soltwaie CoS Delaults on page +70.
A scalaLle CoS uesign stiives to uistiiLute the loauloi example, Ly placing the iela-
tively computationally intensive multilielu classilication lunction at the euges ol the
access layei only. Once classilieu, packets can Le iemaikeu to accommouate stieam-
lineu BA-Laseu classilication in the coie anu uistiiLution layeis, wheie packet iates
436 | Chapter 10:Class of Service
tenu to Le highei anu moie cycles neeu to Le ueuicateu to loiwaiuing tiallic, iathei
than on complex classilication tasks.
Figuie 10-7 illustiates the CoS uiviue anu conguei appioach. It shows the CoS-enaLleu
suLset ol the Beei-Co netwoik, which has Leen uiviueu into access anu uistiiLution/
coie layeis. Geneially speaking, CoS lunctionality is most complex at the euges ol youi
netwoik. This is Lecause the netwoik`s euge has to ueal with inuiviuual uevices/micio-
llows, wheieas the coie acts on tiallic aggiegates. Coie uevices aie noimally not Lui-
ueneu with CPU-intensive opeiations such as multilielu classilication, thus allowing
these uevices to locus theii actions on actual packet loiwaiuing. By policing at the
netwoik`s euge, you thiottle each usei/application at ingiess, making auuitional po-
licing within the uistiiLution anu coie layeis unnecessaiy. Policing aggiegate stieam
iates in the coie is possiLle, Lut it has the seiious uiawLack ol allowing one oi moie
hypeiactive useis to uominate the iesouices ol that loiwaiuing class. By peiloiming
iate limiting anu ielateu uiscaiu at the euges, as tiallic initially ingiesses the netwoik,
you can laiily limit all useis to theii assigneu iate; when comLineu with a piopeily
uimensioneu coie, auuitional policing actions aie unnecessaiy.
Iigurc 10-7. Thc CoS dividc and conqucr approach
What Is IP CoS, and Why Do I Need It? | 437
The coie CoS lunctionality ol classilication anu iesulting gueuing/congestion contiol
is peiloimeu Ly all noues in the netwoik to pioviue the consistent noue-Ly-noue, anu
theieloie enu-to-enu, packet-hanuling Lehavioi neeueu loi a successlul IP CoS
ueployment.
IP CoS Summary
This section uesciiLeu IP CoS anu why it`s Lecoming incieasingly impoitant with the
tienus towaiu IP conveigence. Ve uelineu Lasic netwoik CoS/QoS teiminology, anu
we walkeu thiough the typical CoS piocessing stages ol a mouein IP ioutei.
Although likely not too eaith shatteiing, theie was a laii Lit ol inloimation to uigest
heie. You might consiuei taking a Liiel Lieak Leloie uiving into the next section, which
pioviues a piimei on IP Dilleientiateu Seivices (DillSeiv).
IP Differentiated Services
Ovei the yeais, theie have Leen seveial lalse staits to a stanuaiuizeu IP CoS solution.
This section summaiizes the histoiy ol IP CoS, anu it pioviues a piimei on the cuiient
solution known as IP Dilleientiateu Seivices (DillSeiv).
The oiiginal use ol IP netwoiks was to suppoit ioLust communications in the lace ol
Lattlelielu conuitions, an application to which uatagiam (connectionless) opeiation is
well suiteu. This uiscussion is tempeieu with the knowleuge that the concept ol inte-
giating seivices ovei IP inteinetwoiks was not consiueieu Ly the piotocol`s aichitects,
anu wiue-scale auoption ol IP CoS has yet to occui. Howevei, iecent auvancements in
ioutei platloims have enaLleu the high-Lanuwiuth loiwaiuing iates ieguiieu to make
IP-Laseu conveigence a commeicial ieality. Vith high-capacity loiwaiuing in place,
the linal piece ol the IP CoS puzzle is the intelligent hanuling ol packets to ellectively
piioiitize ceitain packets uuiing times ol ieuuceu capacity oi link congestion.
IP ToS
RFC 791 is the oiiginal RFC specilication ol the Inteinet Piotocol (IP) anu was puL-
lisheu in 19S1. The RFC uelineu an S-Lit lielu in the IP heauei as a Type ol Seivice
(ToS) lielu. Figuie 10-S shows the IP heauei anu uetails the stiuctuie ol the ToS lielu
itsell.
The oiiginal IP ToS lielu is stiuctuieu into a 3-Lit pieceuence lielu, a 3-Lit ToS inuica-
tion lielu, anu two ieseiveu Lits. The ToS Lits weie intenueu to pioviue a clue to the
ioutei as to which type ol link metiic (e.g., uelay, thioughput, oi ieliaLility) shoulu Le
consiueieu when hanuling the packet. This capaLility piesumes a ToS-capaLle iouting
piotocol, one that Luilus a iouting inloimation Lase (RIB) Laseu on specilic link met-
iics. Such a piotocol has nevei seen use in commeicial netwoiks (Open Shoitest Path
Fiist OSPF has this capaLility, Lut it nevei saw actual ueployment).
438 | Chapter 10:Class of Service
Lack ol ToS-capaLle Inteiioi Gateway Piotocols (IGPs) meant that the ToS Lits have
gone histoiically unuseu Ly iouteis. Many applications set these Lits; loi example,
Telnet olten sets the D Lit to inuicate low uelay, Lut iouteis geneially take no specilic
action upon any ToS comLinations.
Vith Lits 6 anu 7 ieseiveu, this lelt only the pieceuence lielu, which at 3 Lits in length
is aLle to coue eight possiLle pieceuence levels (2
3
). IP pieceuence is supposeu to in-
lluence packet lossgeneially speaking, each inciease liom the uelault value, which
is 0, was expecteu to iesult in a ieuuceu pioLaLility loi uiscaiu. Unlike the ToS Lits, IP
pieceuence piocessing has Leen suppoiteu in iouteis loi some time, Lut usually in a
iathei coaise, Linaiy mannei that iesults in two uiscaiu pioLaLilitiesa low pioLa-
Lility loi pieceuence values 6 anu 7, which aie associateu with NC, anu a highei pioL-
aLility loi all othei levels. In the ]unipei implementation, the uelault Lehavioi iesults
in a maximum ol loui uiop pioLaLilities, two loi non-NC classes anu two loi the NC
class, Laseu on a VRED piolile set to act uilleiently on high- veisus low-loss pioLaLility
tiallic.
Most iouting piotocol stacks uo in lact set the pieceuence Lits ol theii contiol packets,
as shown in the lollowing monitor traffic sample, which explains how ]unos tiansmits
an OSPF packet:
Iigurc 10-8. Thc |P ToS bytc
IP Differentiated Services | 439
[edit]
lab@Bock#run monitor traffic interface ge-0/0/1.100 detail
Listening on ge-0/0/1.100, capture size 96 bytes
. . .
02:12:44.430326 Out IP (tos 0xc0, ttl 1, id 3867, offset 0, flags
[none], proto: OSPF (89), length: 68) 10.10.11.3 > 224.0.0.5: OSPFv2,=
Hello, length: 48
Router-ID: 10.10.12.1, Backbone Area, Authentication Type:
none (0)
Options: [External] [|ospf]
The hexauecimal value shown loi the ToS lielu (0xc0) Lieaks uown to a Linaiy 1100
0000, which in tuin coues IP pieceuence level 6 with the D, T, anu R ToS Lits cleaieu
(not set). The uelault ]unipei Lehavioi is to classily Laseu on IP pieceuence, such that
NC messages aie placeu into gueue 3, which is the uelault gueue loi the NC class, as
shown heie:
lab@PBR>edit class-of-service
[edit class-of-service]
Show classifier type inet-precedence name ipprec-compatibility | match network-control
110 network-control low
111 network-control high
A Lieakuown ol IP pieceuence to Linaiy, along with the uecimal eguivalent, is pioviueu.
This can Le uselul when testing CoS using utilities such as ping oi tiaceioute, Lecause
when you incluue the tos switch, the iesultant values aie specilieu in dccina|, not Linaiy
oi hexauecimal. Note that only IP ToS Lits aie suppoiteu with the CLI tos switch
you cannot specily a DSCP value. TaLle 10-2 pioviues a complete Lieakuown ol IP
pieceuence to Linaiy anu the iesultant uecimal eguivalents.
Tab|c 10-2. |P ToS to binary and dccina| cquiva|cnts
Precedence Binary Powers of 10 Decimal
Precedence 7 1110 00xx 128+64+32+0+0+0+x+x 224
Precedence 6 1100 00xx 128+64+0+0+0+0+x+x 192
Precedence 5 1010 00xx 128+0+32+0+0+0+x+x 160
Precedence 4 1000 00xx 128+0+0+0+0+0+x+x 128
Precedence 3 0110 00xx 0+64+32+0+0+0+x+x 96
Precedence 2 0100 00xx 0+64+0+0+0+0+x+x 64
Precedence 1 0010 00xx 0+0+32+0+0+0+x+x 32
Precedence 0 0000 00xx 0+0+0+0+0+0+x+x 0
Enter IP Integrated Services
Recognizing an incieasing neeu loi lunctional IP CoS, the Inteinet Engineeiing Task
Foice (IETF) Legan woik on an Integiateu Seivices (IS, oi IntSeiv) mouel that was liist
puLlisheu in 199+ in RFC 1633, Integiateu Seivices in the Inteinet Aichitectuie: An
440 | Chapter 10:Class of Service
Oveiview. The authois lelt that simple packet classilication anu scheuuling was not
enough to guaiantee ieal-time seivices ovei the Inteinet, anu specilically lelt that some
loim ol aumission contiol anu iesultant iesouice ieseivation was neeueu. Fig-
uie 10-9 shows the IntSeiv concept.
Iigurc 10-9. |P |ntcgratcd Scrviccs
The auueu lunctionality neeueu to suppoit IntSeiv is shown in the uppei-iight poition
ol the ioutei`s contiol plane in Figuie 10-9specilically, the auuition ol the CAC anu
the ieseivation contiol entities, along with the ielateu iesouice ieseivation uataLase
anu ielateu hooks into the ioutei`s management plane.
Put simply, the IntSeiv plan was to incluue the Resouice Reseivation Piotocol (RSVP),
as uelineu in RFC 2205, in iouteis anu hosts, auuing what amounts to a ca|| cstab|ish-
ncnt phase (loi non-BE tiallic). Heie, the usei specilically ieguests iesouices liom the
netwoik, while also chaiacteiizing the natuie ol the ielateu tiallic with paiameteis such
as aveiage anu peak iates, maximum tiansmission unit (MTU), anu so on.
Each netwoik noue then eithei accepts oi iejects the ieseivation ieguest Laseu on its
local CAC lunction, which is iun against that noue`s cuiient iesouice availaLility.
Vhen all noues along the path accept the ieseivation, solt state is estaLlisheu loi the
uuiation ol the ieseivation anu is useu to cieate the uata plane state neeueu to suppoit
IP Differentiated Services | 441
the new ieseivations. Specilically, a classiliei is instantiateu to match tiallic Lelonging
to that ieseivation using the uetails containeu in the RSVP tiallic inloimation. The
ieseivation is toin uown when it is no longei neeueu. This iesults in iemoval ol the
ielateu uata plane state anu the lieeing ol allocateu iesouices to accommouate the next
ieseivation ieguest. Vhen a noue is encounteieu that cannot meet the ieseivation`s
ieguiiements, the session lails with the appiopiiate ieason givenin theoiy, the usei
application will eithei keep tiying, give up, oi ieuuce its iesouice ieguest to impiove
its chances ol success.
Although all this sounus gieat, many piactical issues iesulteu in little to no ieal ue-
ployment ol IntSeiv. Iionically, the RSVP signaling piotocol has seen signilicant com-
meicial success as a Multipiotocol LaLel Switching (MPLS) signaling piotocol within
seivice pioviuei netwoiks, iathei than in its oiiginal QoS signaling iole.
IntSeiv iesults in netwoik Llocking when the netwoik appioaches capacity, meaning
that no new ieseivations can Le placeu. Although not a pioLlem loi those useis lucky
enough to alieauy holu a ieseivation, the total aLsence ol (integiateu) seivice loi the
iemaining useis was seen Ly many as a seiious violation ol the histoiical Inteinet paia-
uigm ol pioviuing the same level ol (uegiaueu) seivice to all useis in the same class.
Vith IntSeiv, useis at the sanc seivice level can Le lockeu out Ly existing ieseivations,
anu the ieal iuL is that this is tiue even when those existing ieseivations aie not tians-
poiting tiallic uue to Luisty souices. Many still have a hostile view towaiu the iuea ol
Llocking useis in the contiol plane (putting asiue the scaling issues ol a contiol plane
that has to inteiact on an enu-usei micio-llow Lasis), when at that veiy moment the
uata plane may well Le iule, leauing to wasteu iesouices.
The commeicial lailuie ol IntSeiv piompteu the uevelopment ol a uata-plane-only sol-
ution known as Dilleientiateu Seivices.
IP Differentiated Services
IP Dilleientiateu Seivices (DillSeiv) was oiiginally uelineu in RFCs 2+7+ anu 2+75 in
199S. Since that time, seveial RFCs have upuateu the oiiginal uelinition ol the DSCP.
RFC 316S auueu explicit congestion notilication (ECN) suppoit, anu RFC 3260 claii-
lieu the teiminology to suppoit MPLS tiallic engineeiing, Lut the essence ol the oiiginal
DillSeiv aichitectuie iemains.
DillSeiv is scalaLle Lecause it is a uata-plane-only solution; theie is no signaling com-
ponent to DillSeiv. DillSeiv ieuelines the oiiginal IP ToS Lyte to suppoit a 6-Lit lielu,
which, as noteu pieviously, is calleu the DillSeiv coue point (DSCP). This pioviues loi
up to 6+ levels ol BA classilication. Figuie 10-10 shows the DillSeiv uelinition ol the
IP ToS lielu. Relateu RFCs ueline the cuiient set ol pei-hop Lehaviois (PHBs), which
aie uesciiLeu latei, anu essentially ueline the exteinally visiLle hanuling chaiacteiistics
associateu with a given loiwaiuing class, oi BA in DillSeiv teiminology.
442 | Chapter 10:Class of Service
Figuie 10-10 also shows a taLle ol the iecommenueu DSCP mappings, most ol which
have yet to Le uelineu. The Class Selectoi (CS) coue points aie uesigneu to mimic the
lunctionality ol IP pieceuence, anu they pioviue Lackwaiu compatiLility loi non-
DillSeiv-awaie iouteis, assuming any still exist. All ol the CS coue points have zeios
wheie the oiiginal ToS uelinition placeu the Delay, Thioughput, anu ReliaLility (DTR)
llags. The 6-Lit DSCP lielu leaves the oiiginal two least-signilicant Lits (LSBs) ol the
oiiginal IP ToS lielu untoucheu, wheie they can Le useu loi ECN signaling as pei RFC
316S, The Auuition ol Explicit Congestion Notilication (ECN) to IP.
DiffServ Terminology
This section uelines key DillSeiv teims anu opeiational concepts. Relei to Fig-
uie 10-11 to match the teims to theii lunctional location in a DillSeiv netwoik.
Iigurc 10-10. Thc DijjScrv codc point
IP Differentiated Services | 443
Iigurc 10-11. DijjScrv tcrnino|ogy and conccpts
BA
This is a classilication Laseu on DSCP packets with a common DSCP Lelonging to
the same BA.
DijjScrv jic|d
This is the oiiginal IPv+ ToS Lyte. DSCPs occupy the six most signilicant Lits ol
the DS lielu.
PHB
This is the exteinally visiLle loiwaiuing tieatment associateu with a given BA.
Vithin a DillSeiv uomain, the set ol PHBs shoulu Le consistent acioss all noues,
iesulting in a consistent enu-to-enu hanuling ol tiallic.
PHB group
This is a set ol one oi moie PHBs that can only Le meaninglully specilieu anu
implementeu simultaneously, uue to a common constiaint applying to all PHBs in
the set, such as a gueue seivicing oi gueue management policy. Cuiiently, the only
stanuaiuizeu gioup Lehavioi ielates to the Assuieu Foiwaiuing (AF) PHB.
444 | Chapter 10:Class of Service
DijjScrv donain
This is a contiguous collection ol noues unuei a common policy with a common
set ol PHBs:
Euge/Lounuaiy uevices classily, metei, shape, police, maik, anu gueue tiallic.
Coie uevices classily anu gueue tiallic.
DijjScrv rcgion
This is a contiguous set ol inteiconnecteu DillSeiv uomains.
DiffServ PHBs
Cuiiently, loui PHBs aie stanuaiuizeu within DillSeiv: the uelault PHB, CS, EF PHBs,
anu the AF PHB gioup:
Thc dcjau|t PHB
The uelault PHB must Le piesent in each DillSeiv-compliant noue, anu it uelines
a BE ueliveiy seivice. Any packets that aie not explicitly classilieu into one ol the
othei PHBs aie consiueieu to Lelong to the uelault gioup. Although the uelault
gioup shoulu not Le staiveu, BE is geneially seiviceu only altei all othei active
PHBs have Leen given theii shaie ol Lanuwiuth.
Thc CS PHB
The CS PHB is uesigneu to suLsume the histoiic uiop Lehavioi associateu with the
oiiginal IP pieceuence lielu uelinition. The PHB Lehavioi set loi the CS PHB is lelt
somewhat vague, in keeping with the lact that IP pieceuence was useu only to
contiol uiop pioLaLility anu not to pioviue any uelay, uelay jittei, oi minimum
thiough guaiantees. To Le compliant, a DillSeiv noue suppoiting the CS PHB must
uemonstiate at least two uilleient loiwaiuing Lehaviois, anu a packet with a CS
value ol 000xxx shoulu Le uioppeu in pieleience ol a packet with a CS coue point
ol 111xxx. Put simply, theie aie no thioughput oi uelay guaiantees in the CS PHB,
anu at a minimum, a noue is expecteu to lavoi CS coue points mapping to IP
pieceuence 6 anu 7 ovei all othei CS values liom a uiop peispective.
Thc EI PHB
The EF PHB is associateu with a low-latency, low-jittei, low-loss, enu-to-enu seiv-
ice. This type ol seivice is suitaLle loi ciicuit emulation, oi the suppoit ol voice,
viueo, oi othei ieal-time seivices. EF suppoit is not manuateu, Lut when olleieu,
the EF PHB ieguiies two inuepenuent lunctions: that each noue is conliguieu with
a minimum uepaituie iate that is inuepenuent ol the activity levels ol othei PHBs
within that noue, anu that the EF BA Le conuitioneu thiough policing oi shaping
to ensuie that the EF aiiival iate at any noue is always less than that noue`s con-
liguieu minimum uepaituie iate. The liist Lehavioi is uelineu within the EF PHB
itsell, anu the seconu is a lunction ol geneial tiallic conuitioning.
Thc AI PHB
The AF PHB is a lamily ol PHBs, calleu a PHB group, which is useu to classily
packets into vaiious uiop pieceuence levels. The uiop pieceuence assigneu to a
IP Differentiated Services | 445
packet ueteimines the ielative impoitance ol a packet within the AF class anu
geneially also inuicates whethei that packet was within, oi aLove, some guaianteeu
iate. Packets within the associateu AF PHB gioup`s minimum iate have the lowest
uiop pioLaLility anu aie expecteu to Le ueliveieu, wheieas packets aLove the min-
imum iate have an incieasing pioLaLility ol loss.
The AF PHB can Le useu to implement a multitieieu mouel consisting ol thiee
classesLionze, silvei, anu goluanu is associateu with loss-sensitive, nonieal-
time applications. A minimal AF PHB implementation is ieguiieu to iecognize all
thiee uiop piioiities within each suppoiteu AF gioup, Lut it has to ollei only a
minimum two-uiop pieceuence within each AF gioup.
Each auministiatoi ol a DillSeiv iegion is liee to choose the
specilic DSCPs that map to suppoiteu PHBs. It`s ciitical that any such mapping Le
consistent acioss all noues in the DillSeiv uomain/iegion. Packet iemaiking can Le
useu to map Letween two iegions that aie pait ol the same uomain, Lut this piocess is
pione to eiioi. The vaiious IETF uocuments uesciiLing DillSeiv PHBs pioviue iecom-
menueu DSCP mappings, which weie shown in Figuie 10-10.
DiffServ Summary
This section pioviueu a Liiel histoiy ol IP CoS, liom the oiiginal ToS uelinition to the
not-guite-successlul IntSeiv mouel on up to the cuiient appioach known as IP Dillei-
entiateu Seivices. The uata-plane-centiic appioach uelineu in DillSeiv pioviues a scal-
aLle solution that is known to woik.
DillSeiv is Laseu on the piinciple ol isolation Letween loiwaiuing classes (BAs) anu a
consistent classilication anu iesultant pei-hop Lehavioi acioss the iouteis in a DillSeiv
uomain, such that pieuictaLle enu-to-enu CoS can Le pioviueu.
The next section pioviues a uetaileu uesciiption ol ]unos CoS capaLilities anu theii
uilleiences. Theie is a lot to covei, so peihaps anothei Lieak is in oiuei Leloie you uive
Lack in.
CoS Capabilities
Vith a thoiough giounuing in IP CoS concepts anu teiminology now unuei youi Lelt,
it`s time to get uown to the paiticulai CoS capaLilities ol ]unipei`s enteipiise iouting
piouucts.
Although all ]unipei iouteis iun pietty much the same ]unos soltwaie, the uesign ol
the ioutei uoes leau to some opeiational uilleiences anu capaLilities. Foitunately, the
vast majoiity ol CoS lunctionality is shaieu Letween all the platloims, anu this section
is stiuctuieu accoiuinglythe common capaLilities aie coveieu liist, lolloweu Ly ue-
tails iegaiuing any specilic exceptions oi uilleiences.
Recommended/default DHCPs.
446 | Chapter 10:Class of Service
The uiscussion ol CoS capaLilities anu uelault settings is piesenteu in the context ol
the CoS packet piocessing steps availaLle loi tiansit tiallic. This is uone to pioviue
stiuctuie anu to ieinloice youi unueistanuing ol CoS piocessing stages within a ]unipei
ioutei. You shoulu ielei Lack to Figuie 10-6 as each CoS piocessing stage is uiscusseu.
You conliguie CoS at the [edit class-of-service] hieiaichy, which has guite a lew
options unuei it. The piimaiy CoS conliguiation options aie uisplayeu:
[edit]
lab@Bock#edit class-of-service
[edit class-of-service]
lab@Bock# set ?
Possible completions:
> adaptive-shapers Define the list of trigger types and associated rates
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> classifiers Classify incoming packets based on code point value
> code-point-aliases Mapping of code point aliases to bit strings
> drop-profiles Random Early Drop (RED) data point map
> forwarding-classes One or more mappings of forwarding class to queue number
> forwarding-policy Class-of-service forwarding policy
> fragmentation-maps Mapping of forwarding class to fragmentation options
> interfaces Apply class-of-service options to interfaces
> loss-priority-maps Map loss priority of incoming packets based on code point value
> rewrite-rules Write code point value of outgoing packets
> scheduler-maps Mapping of forwarding classes to packet schedulers
> schedulers Packet schedulers
> traceoptions Trace options for class-of-service process
> virtual-channel-groups Define list of virtual channel groups
> virtual-channels Define the list of virtual channels
Input Processing
Input piocessing stages incluue BA classilication, multilielu classilication, policing, anu
loiwaiuing policy actions. Each is uiscusseu sepaiately.
BA classification capabilities
The BA classilication stage suppoits classilication Laseu on the lollowing Layei 3 anu
Layei 2 lielus:
DSCP (Layei 3, 6+ levels in upuateu ToS Lyte)
IP pieceuence (Layei 3, eight levels in ToS Lyte)
MPLS EXP (Layei 2, eight levels via expeiimental EXP Lits in MPLS tag)
IEEE S02.1p (Layei 2, eight piioiity levels in S02.1Q viitual LAN VLAN tag)
Il you apply an IEEE S02.1p to a logical inteilace, you cannot apply any othei classiliei
types to othei logical inteilaces on the same PIC poit il you aie using oluei PICs on the
M-seiies iouteis. Some comLinations ol BA classilieis simply make no sense anu aie
mutually exclusive; loi example, you cannot apply Loth an IP pieceuence anu a DSCP
CoS Capabilities | 447
classiliei to the same logical inteilace at the same time. You conliguie a BA classiliei at
the [edit class-of-service classifiers] hieiaichy:
[edit class-of-service classifiers]
lab@Bock#set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> dscp Differentiated Services code point classifier
> dscp-ipv6 Differentiated Services code point classifier IPv6
> exp MPLS EXP classifier
> ieee-802.1 IEEE-802.1 classifier
> ieee-802.1ad IEEE-802.1ad (DEI) classifier
> inet-precedence IPv4 precedence classifier
The lollowing example shows a usei-uelineu IP pieceuence type classiliei nameu
test, with a uelineu coue point that maps to the BE loiwaiuing class with a low-loss
piioiity:
[edit class-of-service classifiers inet-precedence test]
lab@Bock#show
forwarding-class best-effort {
loss-priority low code-points 000;
}
Vhen uesiieu, you can populate a classiliei taLle with uelault values, which is uselul
when youi goal is to mouily only some coue points. The Lest piactice is to always have
complete classilication taLles, even when all possiLle coue point values aie not expec-
teu. Even though unmatcheu coue points map to the BE class Ly uelault, explicitly
stating this with a complete coue point mapping can ieuuce conlusion uown the ioau:
[edit class-of-service classifiers inet-precedence test]
lab@Bock#set import ?
Possible completions:
<import> Include this classifier in this definition
default Default classifier for this code point type
test
[edit class-of-service classifiers inet-precedence test]
lab@Bock# set import default
[edit class-of-service classifiers inet-precedence ]
lab@Bock# show import default;
forwarding-class best-effort {
loss-priority low code-points 000;
The BA classiliei is placeu into seivice when you apply it to one oi moie logical
inteilaces:
[edit class-of-service interfaces]
lab@Bock#set ge-0/0/0 unit 0 classifiers inet-precedence test
[edit class-of-service interfaces]
lab@Bock# show
ge-0/0/0 {
unit 0 {
448 | Chapter 10:Class of Service
classifiers {
inet-precedence test;
}
}
}
Note that a BA classiliei is applieu to an inteilace at the [edit class-
of-service interfaces <interface-name> unit <unit-number>] hieiai-
chy, wheieas multilielu classilieis aie applieu to an inteilace at the [edit
interfaces <interface-name> unit <unit-number>] hieiaichy. Keep this
uistinction in minu to avoiu conlusion uown the ioau.
On MX platloims, a loiwaiuing class can Le assigneu uiiectly to the
logical inteilace without the use ol a classiliei set class-of-service
interface <interface-name> unit <unit-number> forwarding-class
<class> commanu.
Multifield classification
In the ]unipei aichitectuie, multilielu classilication is implementeu via liiewall lilteis,
using a vaiiety ol Layei 2 oi Layei 3 match ciiteiia. Ve uiscuss geneial liiewall liltei
conliguiation anu capaLilities in Chaptei S.
Sullice it to say that you use a liltei to peiloim multilielu classilication Ly associating
a set ol match ciiteiia with a then forwarding-class action. To activate multilielu clas-
silication, the liltei is applieu as an input liltei on an ingiess inteilace. Because BA
classilication is always peiloimeu liist, you can always apply a multilielu classiliei in
comLination with any BA classiliei. In case ol conllict, the loiwaiuing class associateu
with the BA match is oveiwiitten Ly the multilielu classiliei`s choice ol loiwaiuing class.
This example shows a simple multilielu classiliei that classilies a specilic UDP piotocol
anu poit comLination to the BE class with high-loss piioiity, while all othei tiallic is
classilieu as BE with the uelault low-loss piioiity:
[edit firewall filter mf_class]
lab@Bock#show
term udp_port_5555 {
from {
protocol udp;
port 5555;
}
then {
loss-priority high;
forwarding-class best-effort;
accept;
}
}
term default {
then {
loss-priority low;
forwarding-class best-effort;
CoS Capabilities | 449
accept;
}
}
Anothei loim ol liltei that can Le useu loi classilication is the simple liltei. Simple lilteis
aie iestiicteu to specilic haiuwaie, aie input lilteis, suppoit IPv+ lielus only, anu always
have an implieu accept action. They aie conliguieu at the edit firewall family inet
simple-filter stanza. An example simple liltei is:
[edit firewall family inet simple-filter test1]
lab@Bock#show
term 1 {
from {
source-address {
10.10.0.0/16;
}
protocol {
tcp;
}
}
then loss-priority low;
Policing
Policeis aie geneially consiueieu to Le pait ol the ]unos soltwaie liiewall aichitectuie,
in that you noimally link to a policei as a iesult ol a liiewall liltei match. ]unipei also
suppoits policeis that aie applieu uiiectly to piotocol lamilies, on a pei-logical-inteilace
Lasis. Fiom a CoS peispective, inteilace-level policeis aie ieally uselul only when you
classily Laseu on the incoming inteilacethat is, all tiallic ieceiveu on inteilace
<name> is loiwaiuing class x, which is a somewhat coinei case, given that most inteilaces
aie assumeu to caiiy a mix ol loiwaiuing classes.
Ingiess policing is a key component ol the tiallic conuitioning that is neeueu in the
DillSeiv mouel to ensuie inuepenuence Letween loiwaiuing classes anu the associateu
PHBs, anu Letween useis in the same class. You shoulu ueploy policing on the net-
woik`s euges, as close to the tiallic souices as possiLle. The goal is to limit the aggiegate
iate ol all non-BE tiallic to constiain it to a value less than the aggiegate iate ol the
tiansmission iesouices associateu with all non-BE classes. This ensuies that the non-
BE PHBs can Le met locally anu Ly suLseguent coie noues, which geneially aie not
Luiueneu Ly any CoS-ielateu policing.
Vheie possiLle, you shoulu police on a pei-class Lasis loi cach usei]unos soltwaie
leatuies such as highly scalaLle liiewall lilteis, comLineu with ease-ol-use leatuies such
as pei-pielix counting anu policing, geneially make such a line-giaineu level ol policing
piactical. This policing ensuies that a lew uominant useis aie not aLle to monopolize
all the iesouices ol a given loiwaiuing class Ly pioviuing pei-usei isolation within the
same class.
Tiallic that exceeus the policei`s piolile can Le uiscaiueu, ieclassilieu into a uilleient
class, oi maikeu loi incieaseu uiscaiu pioLaLility Ly alteiing the inteinal PLP. The lattei
450 | Chapter 10:Class of Service
appioach pioviues a minimum level ol seivice with the potential loi incieaseu ueliveiy
uuiing peiious ol low netwoik utilization. In contiast, immeuiate uiscaiu caps the usei
at ingiess, which helps to pievent netwoik congestion liom occuiiing in the liist place.
Heie is an example ol a liiewall liltei that Loth classilies anu polices on a pei-loiwaiuing
class Lasis:
[edit firewall]
lab@Bock#show
policer EF_policer {
if-exceeding {
bandwidth-limit 128k;
burst-size-limit 2k;
}
then discard;
}
filter mf_class_and_police {
interface-specific;
term EF_classify {
from {
protocol udp;
port 6000-6100;
}
then {
policer EF_policer;
forwarding-class expedited-forwarding;
}
}
term other {
then forwarding-class best-effort;
}
}
In this example, UDP packets with a matching poit iange (eithei souice oi uestination
poits) aie uiiecteu to a policei nameu EF_policer. Tiallic within the policei piolile is
hanueu Lack to the calling teim, wheie it`s classilieu as EF anu accepteu. In this case,
any excess tiallic is summaiily uioppeu. The linal teim in the liltei classilies all ie-
maining tiallic as BE, which is not policeu in this example.
It may seem ouu that the EF class is policeuwith a iathei uiaconian uiscaiu action,
no lesswhile the BE class, which appeais to Le less impoitant, is lelt to iun uncheckeu.
The ieason loi this seemingly Lackwaiu policei application is uue to the ielateu scheu-
uling piioiity, which loi the EF class is olten stiict, oi stiict-high, anu can leau to the
staivation ol lowei-piioiity loiwaiuing classes when theie is an aLunuance ol this tial-
lic. Ingiess policing with associateu uiscaiu ensuies an aggiegate limit on the EF class,
which pievents this pioLlem. Iionically, it`s ielatively sale to accept all the BE tiallic
useis caie to geneiate, Lecause BE is geneially assigneu a low piioiity (othei classes
cannot Le staiveu) anu a low tiansmit peicentage (so that it uoes not signilicantly im-
pact othei classes), thus excess BE is sent only when one oi moie ol the othei loiwaiuing
classes aie not using theii lull Lanuwiuth allocation anyway.
CoS Capabilities | 451
The auuition ol the interface-specific statement allows the same liltei to Le applieu
to multiple inteilaces, with each such application iesulting in instantiation ol a unigue
policei instance. The enu iesult is that each inteilace to which this liltei is applieu will
Le limiteu to a maximum aveiage EF iate ol 12S KLps. The aggiegate EF class iate
Lecomes a simple lunction ol policei iate multiplieu Ly the numLei ol inteilaces to
which the liltei is applieu. Note that omitting the interface-specific statement anu
applying the same liltei to multiple inteilaces iesults in a shaieu policei, which in this
example woulu cap the aggiegate EF class iate to 12S KLps.
CoS policy
CoS policy is useu in one ol two ways: to pioviue CBF oi to peiloim classilication
oveiiiue. CBF allows you to specily one oi moie next hops Laseu on a packet CoS
classilication. CBF is not uemonstiateu in this chaptei, Lut a goou conliguiation ex-
ample is pioviueu in the usei manual, locateu at http://www.junipcr.nct/tcchpubs/cn
_US/junos10.1/injornation-products/pathway-pagcs/cos/indcx.htn|.
Classilication oveiiiue uoes just what its name implies. This capaLility can Le uselul
when peiloiming CoS-ielateu testing, oi it can mitigate negative impacts that can iesult
liom an upstieam uevice that is suspecteu ol geneiating impiopeily maikeu tiallic. The
conliguiation example peiloims an oveiiiue ol any pievious classilication incluuing
oveiiiuing any loss-piioiity setting, anu it iesets all matching tiallic to the BE class:
[edit]
lab@Bock#show policy-options
policy-statement AF_override {
term 1 {
from interface ge-0/0/0.0;
then class reset_to_be;
}
term 2 {
then accept;
}
}
The AF_override policy is useu to iuentily what tiallic is suLjecteu to classilication
oveiiiue; in this example, all tiallic ieceiveu ovei inteilace ge-0/0/0 is maikeu as Le-
longing to a CoS-ielateu policy class nameu reset_to_be:
[edit]
lab@Bock#show class-of-service
forwarding-policy {
class reset_to_be {
classification-override {
forwarding-class best-effort;
}
}
}
[edit]
lab@Bock# show routing-options forwarding-table
export AF_override;
452 | Chapter 10:Class of Service
A forwarding-policy is cieateu at the [edit class-of-service] hieiaichy that iuentilies
the policy class that is suLject to classilication oveiiiue. In this example, packets maikeu
as Lelonging to the reset_to_be policy class have theii initial classilication, whatevei
that might Le, ieset to the BE class. The loiwaiuing policy must Le applieu at the [edit
routing-options forwarding-table export] hieiaichy to take ellect. Such a policy con-
liguiation might tempoiaiily woik aiounu issues with an upstieam uevice that incoi-
iectly maiks all tiallic as EF, iesulting in EF class congestion anu violation ol the ielateu
seivice level agieements (SLAs). The gioup managing the upstieam uevice will guickly
linu the motivation neeueu to coiiect the conliguiation eiioi when its useis Legin to
complain aLout pooi peiloimance stemming liom suuuenly getting nothing Lut BE
tieatment.
Output Processing
Output CoS piocessing stages incluue egiess policing, iewiite maiking, gueuing/
scheuuling, anu active gueue management thiough RED-Laseu congestion contiol.
Egress policing
Policeis aie, well, policeis, anu theie is ieally nothing unigue aLout an output policei
veisus an input one, othei than the simple lact that the policing action now occuis altei
the ioute lookup, iathei than Leloie. To an exteinal oLseivei, theie is no uilleience
Letween the use ol input veisus output policeis. Consiuei an input policei, unless you
must police Laseu on the iesult ol ioute lookupthat is, Laseu on the loiwaiuing next
hop.
Rewrite marking
The iewiite maiking stage is a ciitical component ol a scalaLle CoS uesign Lecause it`s
one-hall ol the BA classilication stoiy. Foi scalaLility, multilielu classilication shoulu
Le useu only at the netwoik`s access layei, wheie the lunction can Le uistiiLuteu among
the laigest set ol iouteis with the smallest aveiage packet loiwaiuing ieguiiements.
Packet iates neai the coie typically uictate the moie ellicient BA type classilication;
]unipei iouteis aie capaLle ol wiie-iate BA classilication in all scenaiios, wheieas heavy
use ol liiewall lilteis can uegiaue loiwaiuing peiloimance.
You shoulu think ol youi input BA classilieis as a miiioi image ol the coiiesponuing
iewiite maikei. This is to say that loi each entiy in a given BA taLle, theie shoulu Le a
coiiesponuing entiy in the associateu iewiite maikei taLle, anu that entiy is noimally
set to the same valuethis ensuies that the noue uownstieam makes the same classi-
lication uecision as uiu the local noue. The consistent classilication at each noue
Letween enupoints is a ciitical component ol the DillSeiv mouel, which piesumes a
consistent PHB among all noues in a DS iegion. Figuie 10-12 shows the inteiaction
Letween multilielu classilication, maikei iewiite, anu iesultant BA classilication.
CoS Capabilities | 453
The seguence numLeis in Figuie 10-12 take you liom initial ingiess piocessing (wheie
a multilielu classilication is useu at step 1), on to step 2 (wheie the ingiess noue uses a
DSCP iewiite taLle to wiite a specilic DSCP pattein, Laseu on its ingiess classilication).
In this example, we assume EF with low PLP, so the packet`s DSCP lielu is wiitten to
Linaiy 101110. At step 3, the uownstieam noue (which is in the uistiiLution oi coie
layei) peiloims on|y DSCP-Laseu BA classilication. Note that Bock`s DSCP classiliei
entiy loi the EF class with low PLP matches the same value as that useu in PBR`s DSCP
iewiite taLle. The iesult, shown in steps +7, is a consistent classilication, anu theieloie
theie is a iesulting consistency in the PHB acioss each noue in the path.
The conliguiation example shown cieates an IP pieceuence iewiite maikei taLle that
matches the example pioviueu in the section BA classilication capaLili-
ties on page ++7:
Iigurc 10-12. Mu|tijic|d at thc cdgc, BA in thc corc
454 | Chapter 10:Class of Service
[edit class-of-service rewrite-rules inet-precedence test]
lab@Bock#show
import default;
forwarding-class best-effort {
loss-priority low code-point 000;
}
As in the case ol BA classilieis, a iewiite taLle can Le lully populateu Ly impoiting any
entiies not explicitly uelineu Ly the usei liom the uelault set associateu with that clas-
siliei type.
Scheduling and queuing
The scheuuling stage ueteimines when a given gueue is seiviceu, in which oiuei, anu
how much tiallic can Le uiaineu at each seivicing. Scheuuleis anu gueues aie closely
linkeu in the ]unipei aichitectuie. Vhen you conliguie a scheuulei, you can also contiol
ceitain gueue paiameteis such as maximum gueue uepth, anu you also link that gueue
to one oi moie VRED pioliles. You typically altei a gueue`s uelault size, which is Laseu
on the associateu tiansmit weight, to contiol uelaylaigei Lullei sizes lavoi less loss
at the cost ol incieaseu latency.
]unipei iouting platloims implement a mouilieu uelicit iounu-ioLin
(MDRR) scheuulei. Because uilleient tiansmit weights can Le assigneu to each gueue,
the algoiithm is technically a mouilieu weighteu uelicit iounu-ioLin (MVDRR)
appioach.
Scheuuling is one aiea wheie the CoS implementation signilicantly uilleis Letween
mouels. The Lasic scheuuling Lehavioi is uesciiLeu heie, along with geneial scheuuling
capaLilities anu concepts. Dilleiences Between ]unos CoS on page +63 specilically
calls out wheie the platloims uillei in scheuuling Lehavioi.
MDRR extenus the Lasic uelicit iounu-ioLin (DRR) mechanism Ly auuing suppoit loi
a piioiity gueue that exhiLits minimal uelay. The uelicit pait ol the algoiithm`s name
stems liom the allowance ol a small amount ol negative cieuit in an attempt to keep
gueues empty. The iesultant negative Lalance liom one seivicing inteival is caiiieu ovei
to the next guantum`s cieuit allocation, keeping the aveiage uegueuing iate neai the
conliguieu tiansmit value.
An MDRR scheuulei is uelineu Ly loui vaiiaLles:
Bujjcr sizc
This is the uelay Lullei loi the gueue that allows it to accommouate tiallic Luists.
You can conliguie a Lullei size as a peicentage ol the output inteilace`s total Lullei
capacity oi as a tempoial value liom 1 to 200,000 micioseconus, which simply
iepiesents Lullei size as a lunction ol uelay, iathei than Lytes.
Thc quantun
The guantum is the numLei ol cieuits auueu to a gueue eveiy unit ol time anu is
a lunction ol the gueue`s tiansmit weighting. In ]unipei`s implementation, a guan-
Scheduling discipline.
CoS Capabilities | 455
tum is auueu 5,000 times pei seconu (oi once eveiy 200 micioseconus). The
gueue`s tiansmit iate specilies the amount ol Lanuwiuth allocateu to the gueue
anu can Le set Laseu on Lits pei seconu oi as a peicentage ol egiess inteilace Lanu-
wiuth. By uelault, a gueue can Le seiviceu when in negative cieuit, as long as no
othei gueues have tiallic penuing. Vhen uesiieu, you can iate-limit a gueue to its
conliguieu tiansmit iate with inclusion ol the exact keywoiu.
Priority
The piioiity can Le low, meuium-low, meuium-high, high, oi stiict-high, anu it
ueteimines the seguence in which gueues aie seiviceu. The scheuulei seivices high-
piioiity gueues with positive cieuit Leloie it auuiesses any low-piioiity gueues.
A stiict-high piioiity gueue is a special case ol high piioiity, wheie the ellective
tiansmit weight is set to egual egiess inteilace capacity. This means that a stiict-
high gueue can nevei go negative, anu theieloie is seiviceu Leloie any low-piioiity
gueue anytime it has tiallic waiting. The iesult is a type ol low-latency gueuing
(LLQ). Caie shoulu Le useu when a gueue is set to stiict-high to ensuie that the
gueue uoes not staive low-piioiity tiallic; a stiict-high gueue uoes not suppoit
shaping via the exact keywoiu. Noimally, though, ingiess policing/iate limiting is
useu to contiol the aggiegate iate ol tiallic that can Le placeu into the stiict-high
gueue. Vhen you have two oi moie gueues set to high piioiity (two high, oi one
high anu one stiict-high), the MDRR scheuulei simply iounu-ioLins Letween them
until they Loth go negative, oi until the gueue is empty in the case ol stiict-high,
at which time the low-piioiity gueues can Le seiviceu.
Dcjicit countcr
MDRR uses the uelicit countei to ueteimine whethei a gueue has enough cieuits
to tiansmit a packet. It is initializeu to the gueue`s guantum, which is a lunction
ol its tiansmit iate, anu it is the numLei ol cieuits that aie auueu to the gueue eveiy
guantum.
The ]unipei implementation ol MDRR scheuuling suppoits a Lasic uelicit weighteu
iounu-ioLin (DVRR) scheuuling uiscipline, oi a comLination ol stiict-piioiity gueuing
(SPQ) anu DVRR scheuuling when a stiict high-piioiity gueue is conliguieu.
You conliguie the scheuuling anu gueuing stage Ly liist uelining
a scheuulei loi each loiwaiuing class useu in youi netwoik. Scheuuleis aie uelineu at
the [edit class-of-service schedulers] hieiaichy, anu they inuicate a loiwaiuing
class`s piioiity, tiansmit weight, anu Lullei size:
[edit class-of-service]
lab@Bock#show schedulers
be_sched {
transmit-rate percent 30;
priority low;
drop-profile-map loss-priority high protocol any drop-profile be_high_drop;
drop-profile-map loss-priority low protocol any drop-profile be_low_drop;
}
ef_sched {
Scheduler configuration.
456 | Chapter 10:Class of Service
buffer-size temporal 50k;
transmit-rate percent 60 exact;
priority high;
drop-profile-map loss-priority high protocol any drop-profile ef_high_drop;
drop-profile-map loss-priority low protocol any drop-profile ef_low_drop;
}
nc_sched {
transmit-rate percent 10;
priority low;
drop-profile-map loss-priority high protocol any drop-profile nc_high_drop;
drop-profile-map loss-priority low protocol any drop-profile nc_low_drop;
}
This example suppoits thiee loiwaiuing classesBE, EF, anu NCanu each loi-
waiuing class`s scheuulei Llock is associateu with a piioiity anu a tiansmit iate. Piioiity
suppoit takes the loim ol stiict-high, high, meuium-high, meuium-low, anu low.
The uilleiences in scheuulei piioiities anu Lehavioi Letween ]unipei
iouteis aie uiscusseu in Dilleiences Between ]unos
CoS on page +63. Foi example, although all platloims suppoit a
strict-priority scheuulei setting, the ellect is platloim-uepenuent anu
signilicantly uilleient.
The tiansmit iate can Le enteieu as a peicentage ol inteilace Lanuwiuth oi as an aL-
solute value. You can iate-limit (sometimes calleu shapc) a gueue with the exact key-
woiu, which pievents a gueue liom getting any unuseu Lanuwiuth, ellectively capping
the gueue at its conliguieu iate.
Othei options loi the tiansmit iate aie a specilieu iate oi the iemainuei ol the Lanu-
wiuth. Some comLinations aie not alloweu; loi example, you cannot set Loth the ie-
mainuei anu the exact keywoius.
In this example, the EF scheuulei is set to high piioiity anu is iate-limiteu to 60 ol
the inteilace speeu, even when all othei scheuuleis aie iule, thiough the auuition ol the
exact keywoiu. Using exact is a common methou ol pioviuing the necessaiy loiwaiuing
class isolation when a high-piioiity gueue is uelineu, Lecause it caps the total amount
ol EF that can leave each inteilace to which the scheuulei is applieu. Rate-limiting helps
to ensuie that the aggiegate iate ol EF tiallic aiiiving at uownstieam noues is not ex-
cessive, wheieas ingiess policing shoulu limit the aiiiving EF to an aggiegate iate that
is less than the EF scheuulei`s tiansmit iate to ensuie that the local noue meets the
associateu PHB.
Vith the conliguiation shown, each ol the thiee loiwaiuing classes aie guaianteeu to
get at least theii conliguieu tiansmit peicentage. The EF class is limiteu to no moie
than 60, while uuiing iule peiious Loth the BE anu NC classes can use 100 ol egiess
Lanuwiuth. Vhen it has tiallic penuing, the high-piioiity EF gueue is seiviceu as soon
as possiLlethat is, as soon as the BE oi NC packet cuiiently Leing seiviceu has Leen
completely uegueueu.
CoS Capabilities | 457
Assuming a somewhat woist-case T1 link speeu (1.5++ MLps) anu a uelault MTU ol
1,50+ Lytes, the longest time the EF gueue shoulu have to wait to Le seiviceu is only
aLout 7.7 milliseconus (1/1.5++
6
(150+ S)). Vith highei speeus (oi smallei packets),
the seivicing uelay Lecomes incieasingly smallei. Given that the typical iule ol thumL
loi the one-way uelay Luuget ol a Voice ovei IP application is 150 milliseconus, this
PHB can accommouate numeious hops Leloie voice guality Legins to sullei.
The pieceuing example woulu not commit until the uiop pioliles aie uelineu loi these
scheuules. Diop pioliles aie coveieu latei in this chaptei.
Delay Buffer Size
Notilications loi packets penuing tiansmission aie stoieu in a uelay Lanuwiuth Lullei
that is sizeu accoiuing to the inteilace`s speeu anu the platloim`s maximum uelay Lullei
time. The iouteis suppoit at least 100,000 micioseconus (oi 100 milliseconus) ol uelay
Lullei time.
Vhen using low-speeu inteilaces, such as DSOs within a channelizeu
T1/E1, you may want to enaLle laige Lullei suppoit. Vith the q-pic-
large-buffer knoL in conjunction with suppoiteu haiuwaie, you can
inciease uelay Lullei time to as much as + million micioseconus (loui
seconus). The laigei uelay Lullei can Le uselul on slow-speeu inteilaces
uue to the iesultant inciease in seiialization uelay, which is a lunction
ol link speeu anu MTU.
In this example, the uelay Lullei size loi the BE anu NC classes is lelt at the uelault
remainder setting. This means that each is allocateu a peicentage ol the 100-milliseconu
uelay Lullei Laseu on its conliguieu tiansmit weighting, anu is alloweu to giow into
any unallocateu Lullei space, such as can occui when the sum ol conliguieu weights
uoes not auu up to 100.
The loimula to compute the actual uelay Lullei size is:
inteilace speeu (Lps) uelay Lullei size (micioseconus) = uelay Lullei size (Lytes)
Il we assume a ]-seiies platloim with a 100 MLps Fast Etheinet inteilace in this example,
the total scheuulei uelay Lullei size is 100
6
100
-3
= 1.25 MB. By uelault, the BE anu
NC classes aie assigneu 30 anu 10 ol the scheuulei`s uelay Lullei, iespectively.
In contiast, the EF gueue has its Lullei set to peimit no moie than 50,000 micioseconus
(50 milliseconus). Vhen using a tempoial setting, the maximum uelay Lullei size is
computeu Ly multiplying the inteilace speeu Ly the conliguieu tempoial value.
Because the EF class has Leen assigneu 60 ol the tiansmit Lanuwiuth, the uelault
Lehavioi woulu allocate 60 (60,000 micioseconus) ol uelay Lullei; Ly ieuucing the
size ol the uelay Lullei, as shown in the case ol the EF class, you keep the highei tiansmit
peicentage while loicing a smallei Lullei size. Setting a uelay Lullei that is smallei than
458 | Chapter 10:Class of Service
the uelault iesults in a tiaue-oll Letween the iesultant incieaseu pioLaLilities ol
congestion-ielateu loss veisus a ieuuction in maximum uelay anu uelay vaiiance (jittei).
The scheuulei Llock loi each loiwaiuing class also ieleiences VRED uiop pioliles,
which pioviue active gueue management to contiol congestion. Geneially, you will
have a uilleient VRED piolile loi each loiwaiuing classloi example, one aggiessive
piolile that Legins to uiop at a lowei lill, with a gieatei uiop pioLaLility loi the BE
class, anu anothei that waits until a highei gueue lill Leloie less-aggiessive uiops Legin
loi the NC class. Ve will uiscuss uiop pioliles in Congestion contiol on page +60.
Foi each scheuulei, you can conliguie the Lullei size as eithei a peicentage ol the total
Lullei, as the iemaining Lullei availaLle, oi to a tempoial value. The peicentage is a
peicentage ol the total Lullei loi the inteilace. The iemainuei is the Lullei peicentage
that is not assigneu to othei gueues. Foi example, il you assign 30 ol the uelay Lullei
to gueue 0, allow gueue 3 to keep the uelault allotment ol 5, anu assign the iemainuei
to gueue 5, then gueue 5 uses appioximately 65 ol the uelay Lullei. Foi the tempoial
setting, the gueuing algoiithm staits uiopping packets when it gueues moie than the
numLei ol Lytes computeu Ly the tempoial value multiplieu Ly the inteilace speeu.
Scheduler Maps
Once you have uelineu youi scheuuleis, you must link them to one oi moie egiess
inteilaces using a scheduler-map. Scheuulei maps aie uelineu at the [edit class-of-
service scheduler-maps] hieiaichy:
[edit class-of-service]
lab@Bock# show scheduler-maps
three_FC_sched {
forwarding-class best-effort scheduler be_sched;
forwarding-class expedited-forwarding scheduler ef_sched;
forwarding-class network-control scheduler nc_sched;
}
Applying a scheduler-map to an inteilace places the ielateu set ol scheuuleis anu uiop
pioliles into ellect:
[edit class-of-service]
lab@Bock# show interfaces
ge-0/0/0 {
scheduler-map three_FC_sched;
}
Delining scheuulei Llocks that aie Laseu on a tiansmit peicentage iathei than an aL-
solute value, such as in this example, makes it possiLle to apply the same scheduler-
map to all inteilaces without woiiying whethei the sum ol the tiansmit iates exceeus
inteilace capacity, which iesults in a committeu, Lut ellectively ignoieu, CoS conligu-
iation that can Le a ieal pleasuie to ueLug. An example ol this conuition is shown loi
Bock, whose T1 inteilace cannot hanule the 1 GLps ieguiieu when the iate is suLstituteu
loi the same numeiic value, Lut in MLps!
CoS Capabilities | 459
lab@Bock# show class-of-service schedulers ef_sched
transmit-rate 35m exact;
buffer-size temporal 30k;
priority high;
[edit]
lab@Bock# run monitor start log messages
monitor start "messages" (Last changed Oct 29 05:21:00)
[edit]
lab@Bock# commit
Oct 30 05:39:11 Bock mgd[2982]: UI_COMMIT: User 'lab' performed commit: no comment
Oct 30 05:39:15 Bock cosd[1071]: COSD_TX_QUEUE_RATES_TOO_HIGH: Unable to apply
scheduler map af-sched to interface t1-2/0/0: sum of scheduler transmission rates
exceeds interface shaping or transmission rate
. . .
A word on per-unit scheduling
By uelault, when you apply a scheuulei to an inteilace, it takes ellect at the poit, oi
inteilace uevice (ifd) level. This is line when the poit in guestion is conliguieu with a
single logical inteilace (ifl), such as woulu Le the case when iunning Cisco High-Level
Data Link Contiol (HDLC) oi the Point-to-Point Piotocol (PPP). Howevei, when the
inteilace is paititioneu into multiple logical unitsloi example, as the iesult ol auuing
VLAN taggingyou neeu to apply a pei-unit scheuulei. A pei-unit scheuulei pioviues
line-giaineu gueuing Ly cieating a set ol gueues anu an associateu scheuulei loi each
logical inteilace. Pei-unit scheuuling is a lunction ol the haiuwaie, anu some oluei PICs
uo not suppoit this leatuie.
You conliguie pei-unit scheuuling Ly auuing the per-unit-scheduler statement at the
inteilace level. Because some haiuwaie comLinations uo not suppoit line-giaineu
gueuing, you shoulu monitoi the ncssagcs log when committing a pei-unit scheuuling
conliguiation to make suie the conliguiation is compatiLle with installeu haiuwaie:
[edit interfaces ge-0/0/0]
lab@Bock# show
per-unit-scheduler;
vlan-tagging;
unit 0 {
vlan-id 1241;
family inet {
address 10.20.130.1/30;
}
}
Congestion control
The linal CoS piocessing stage in the output uiiection is the VRED congestion contiol
lunction. Ve uesciiLeu the ieasoning Lehinu active gueue management pieviously
we`ll ieiteiate that the geneial goal is to avoiu the inuisciiminate tail uiops that occui
when a gueue ieaches capacity, Ly sensing a gueue that is Leginning to lill anu then
460 | Chapter 10:Class of Service
ianuomly uiscaiuing packets liom the heau ol the gueue. The chance ol actual uiscaiu
iises liom the liist lill level anu uiscaiu pioLaLility point until it ieaches 100 at 100
lill. Conliguiing a uiscaiu piolile with a lill/uiscaiu pioLaLility ol 100/100 ellectively
uisaLles RED on that gueue. This is the uelault setting.
Configure WRED drop profiles
You conliguie a VRED uiop piolile at the [edit class-of-service drop-profiles]
hieiaichy. RED uiop pioliles aie placeu into ellect on an egiess inteilace via application
ol a scheduler-map. Recall that, as shown eailiei, the scheduler-map ieleiences a set ol
scheuuleis, anu each scheuulei uelinition links to one oi moie uiop pioliles. It is an
inuiiect piocess, to Le suie, Lut it guickly Legins to make sense once you have seen it
in action.
Heie aie some examples ol uiop pioliles, as ieleienceu in the pieceuing scheduler-
map example:
[edit class-of-service drop-profiles]
lab@Bock# show
be_high_drop {
fill-level 40 drop-probability 0;
fill-level 50 drop-probability 10;
fill-level 70 drop-probability 20;
}
be_low_drop {
fill-level 70 drop-probability 0;
fill-level 80 drop-probability 10;
}
ef_high_drop {
fill-level 80 drop-probability 0;
fill-level 85 drop-probability 10;
}
ef_low_drop {
fill-level 90 drop-probability 0;
fill-level 95 drop-probability 30;
}
nc_high_drop {
fill-level 40 drop-probability 0;
fill-level 50 drop-probability 10;
fill-level 70 drop-probability 20;
}
nc_low_drop {
fill-level 70 drop-probability 0;
fill-level 80 drop-probability 10;
}
In this example, the uiop pioliles loi the BE anu NC classes aie conliguieu the same,
so technically a single-uiop piolile coulu Le shaieu Letween these two classes. It`s a
Lest piactice to have pei-class pioliles Lecause ongoing CoS tuning may ueteimine that
a paiticulai class will peiloim Lettei with a slightly tweakeu RED thiesholu setting.
CoS Capabilities | 461
Both the BE anu NC gueues Legin to uiop 10 ol high-loss piioiity packets once the
iespective gueues aveiage a 50 lill level. You can specily as many as 6+ uisciete points
Letween the 0 anu 100 loss points, oi use the interpolate option to have all 6+
points automatically calculateu aiounu any usei-supplieu thiesholus. In this example,
only thiee points aie specilieu. At 50 lill, 10 ol PLP 1 BE anu NC tiallic is uioppeu;
when the gueue lill ciosses 70, the next uiscaiu thiesholu is activateu anu 20 ol the
packets aie uiscaiueu. The 20 uiscaiu iate is maintaineu uuiing an aveiage gueue lill
ol 70 to 99. At 100 lill, tail uiop Legins, as the gueue can no longei holu incoming
notilications. The weighteu aspect ol the RED algoiithm is shown with the conliguia-
tion ol a less-aggiessive uiop piolile loi BE/NC tiallic with a low-loss piioiity.
A similai appioach is taken loi the EF class, except it uses a less aggiessive piolile loi
Loth loss piioiities, with uiscaius staiting at S0 anu 90 lill loi high- anu low-loss
piioiities, iespectively. Some CoS ueployments uisaLle RED (100/100) loi ieal-time
classes such as EF Lecause these souices aie noimally UDP-Laseu anu uo not ieact to
loss in the same way that TCP-Laseu applications uo. Some platloims suppoit VRED
pioliles Laseu on TCP veisus UDP, in auuition to loss piioiity, which allows you to
auopt a less aggiessive RED piolile loi those application types that uo not ieact to RED
uiop anyway. Othei platloims suppoit VRED inuexing Laseu on loss piioiity only.
The examples shown aie liom a ]-seiies, which loices the piotocol to any.
Heie`s the be_high uiop piolile:
[edit]
lab@Bock# run show class-of-service drop-profile be_high_drop
Drop profile: be_high_drop, Type: discrete, Index: 27549
Fill level Drop probability
40 0
50 10
70 20
To pioviue contiast, the be_high piolile is alteieu to use interpolate, which lills in all
6+ points Letween 0 anu 100 loss, as constiaineu Ly any usei-specilieu lill/uiop
pioLaLility points:
edit]
lab@Bock# show class-of-service drop-profiles be_high_drop
interpolate {
fill-level [ 40 50 70 ];
drop-probability [ 0 10 20 ];
}
[edit]
lab@Bock# run show class-of-service drop-profile be_high_drop
Drop profile: be_high_drop, Type: interpolated, Index: 27549
Fill level Drop probability
0 0
1 0
2 0
4 0
5 0
. . .
462 | Chapter 10:Class of Service
38 0
40 0
42 2
44 4
45 5
46 6
48 8
49 9
51 10
52 11
54 12
. . .
78 41
80 46
82 52
84 57
85 60
. . .
99 97
100 100
Differences Between Junos CoS
The pieceuing section uetaileu the geneial CoS capaLilities acioss all ]unos-Laseu
iouting platloims. This section calls out aieas wheie the CoS capaLilities uillei. Vith
so many similaiities, the uilleiences aie easy to lose tiack ol, Lut no mattei how similai,
they can have a pionounceu opeiational impact il you uo not unueistanu anu uesign
loi them.
TaLle 10-3 summaiizes the uilleiences Letween CoS Lehavioi on vaiious ]unipei en-
teipiise iouteis. Note that the o]-Seiies column also incluues the SRX210, SRX2+0,
anu SRX650 gateways; the M-Seiies is Loth the M7i anu the M10i; anu the MX-Euge
iouteis incluue all mouels. The SRX3000s anu SRX5000 gateways have special con-
siueiations that aie Leyonu the scope ol this Look. Please ielei to junos Sccurity (O`Re-
illy) loi auuitional inloimation on these uevices.
Tab|c 10-3. Entcrprisc routcr CoS bchavior and capabi|itics
Feature SRX and J- Series M-Series (FPCs)
M-Series
(enhanced FPCs) MX-Edge routers
Schedulers Priority Weight Weight Weight
Classifiers 64 1 8 32
Forwarding classes 8 4 4 16
Queues 8 4 8 8
Loss priorities 4 2 4 4
dscp Yes No Yes Yes
dscp-ipv6 Yes No Yes Yes
ieee-802.1p Yes No Yes Yes
CoS Capabilities | 463
Feature SRX and J- Series M-Series (FPCs)
M-Series
(enhanced FPCs) MX-Edge routers
Schedulers Priority Weight Weight Weight
inet-precedence Yes Yes Yes Yes
mpls-exp Yes Yes Yes Yes
Loss priorities based on the
Frame Relay discard eligible
(DE) bit
Yes No No No
Drop profiles
Maximum 32 2 16 64
Per queue Yes No Yes Yes
Per loss priority Yes Yes Yes Yes
Per Transmission Control Proto-
col (TCP) bit
Yes No Yes No
Per protocol No Yes Yes No
Policing
Adaptive shaping for Frame Re-
lay traffic
Yes No No No
Traffic policing Yes Yes Yes Yes
Virtual channels Yes No No No
Queuing priority Yes No Yes Yes
Per-queue output statistics Yes No Yes Yes
Rewrite markers 64 No maximum No maximum 32
dscp Yes No Yes Yes
dscp-ipv6 Yes No Yes Yes
frame-relay-de Yes No No No
inet-precedence Yes Yes Yes Yes
mpls-exp Yes Yes Yes Yes
TaLle 10-3 uetails the opeiational uilleiences Letween the piouuct lines. Ve will ex-
amine a lew lunctional uilleiences in uetail in the lollowing sections.
Per-unit scheduling
As mentioneu eailiei, the oluei M-seiies platloims uo not suppoit pei-unit scheuuling
unless the platloim is eguippeu with an IQ-style PIC, in which case the actual gueuing
is moveu liom the chassis level onto the PIC itsell when you enaLle pei-unit scheuuling.
The othei platloims suppoit line-giaineu, pei-unit scheuuling on all inteilaces.
464 | Chapter 10:Class of Service
In auuition to logical unit-Laseu gueuing, pei-unit scheuuling also enaLles use ol the
shaping-rate commanu at the logical unit level to shape output tiallic on all inteilaces.
Weight- versus priority-based scheduling
One ol the most pionounceu uilleiences is the way in which the MDRR algoiithm is
implementeu. The uilleiences aie so pionounceu that you will typically linu that an
existing scheuulei conliguiation cannot Le copieu to anothei mouel anu ieceive the
same CoS opeiation!
On ASIC-Laseu iouteis, the MDRR scheuulei is Laseu on
guaianteeu tiansmit weight with any leltovei (unuseu) Lanuwiuth uiviueu on a piioii-
tizeu, iounu-ioLin Lasis, which empties high-piioiity gueues in negative cieuit Leloie
moving on to low-piioiity gueues with negative cieuit. As an example, Figuie 10-13
illustiates the opeiational chaiacteiistics ol the M-seiies scheuulei implementation.
Iigurc 10-13. Thc wcight-bascd schcdu|cr
Figuie 10-13 shows a scheuulei conliguiation suppoiting two piioiities anu thiee loi-
waiuing classes/gueues. The scheuulei liist seivices all high-piioiity gueues with pos-
itive cieuit, anu then moves on to seivice low-piioiity gueues with positive cieuit. Once
The weight-based scheduler.
CoS Capabilities | 465
all gueues have Leen given at least theii assigneu weights, the gueues go negative anu
the scheuulei Legins to allocate unuseu Lanuwiuth. Because the uispatch ol unuseu
Lanuwiuth is allecteu Ly numeious lactois, incluuing the numLei ol piioiities, numLei
ol gueues, anu aveiage packet size, it is sale to say that the algoiithm loi the allocation
ol unuseu Lanuwiuth among negative cieuit gueues is, piactically speaking, nonuetei-
ministic. This uoes not mean the piocess is ianuom, just that it is extiemely uillicult
to pieuict how much extia Lanuwiuth a given gueue will enu up getting.
The top hall ol the liguie shows the scheuulei`s DVRR opeiation when gueues aie in
positive cieuit. The scheuulei seivices the high-piioiity gueue until its tiansmit weight
is satislieu, iesulting in loui loiwaiuing class 2 packets, oi +0 utilization in this ex-
ample. Once the piioiity gueue is in negative cieuit, the scheuulei moves on to the low-
piioiity level, which has two gueues in this example. The scheuulei seivices Loth ol
the low-piioiity gueues accoiuing to theii weight, iesulting in one FC0 anu live FC2
packets Leing tiansmitteu.
The lowei hall ol Figuie 10-13 continues the example Ly showing scheuulei Lehavioi
among gueues with negative cieuit. The leltovei Lanuwiuth is not allocateu accoiuing
to conliguieu weight, Lut iathei using a piioiity-Laseu iounu-ioLin appioach that
empties one packet pei gueue, liist emptying all high-piioiity gueues anu then moving
on to iounu-ioLin Letween negative low-piioiity gueues.
This appioach can leau to some unexpecteu iesults, especially when gueues aie chion-
ically oveiuiiven anu theieloie tenu to iemain in negative cieuit, anu when the aveiage
packet size uilleis within each gueue. The lack ol gianulaiity in the pei-packet iounu-
ioLin hanuling ol negative gueues tenus to lavoi the gueue with the laigei packet size.
This can Le most pionounceu when that gueue is also given the lowest weight, Lecause
it will Le aLle to senu the same numLei ol packets as othei negative gueues at the same
piioiity level. Vhen comLineu with a laigei packet size, such a gueue winus up getting
a laigei peicentage ol the leltovei Lanuwiuth than you might liist assume.
On the ASIC-Laseu systems, the strict-high piioiity is the same as high piioiitythe
strict-high setting simply pioviues that gueue with a 100 tiansmit weight, thus
ensuiing that it is always in positive cieuit anu aLle to senu. You cannot iate-limit a
strict-high gueue with the exact keywoiu Lecause it always gets 100 ol the inteilace
tiansmit weight, anu you can incluue only one strict-high gueue in a given scheduler-
map.
The othei scheuulei implementation is Laseu on stiict piioi-
ity. In this context, the woiu strict means that each piioiity level at value n is consiueieu
a highei piioiity than level n - 1, anu that the scheuulei always seivices highei-piioiity
gueues Leloie lowei-piioiity gueues, even il the highei-piioiity gueue is negative while
the lowei-piioiity gueue is in positive cieuit. This is a ciitical point, so it`s iestateu
uilleiently, a lew times:
The priority-based scheduler.
466 | Chapter 10:Class of Service
VRR/conliguieu weight is honoieu only loi gueues at the same piioiity level.
A high-piioiity gueue can staive all othei piioiities unless it is iate-limiteu. The
same goes loi meuium-high anu meuium, meuium-low anu low, anu so on uown
the piioiity chain.
The strict-high setting is an actual piioiity level, making it, paiuon the pun, highcr
than high. The strict-high setting is specilically olleieu to Lack up the LLQ leatuie.
The strict-high gueue cannot Le iate-limiteu with the exact keywoiu. Insteau, a po-
licei is useu to maik tiallic aLove a conliguieu limit as excess. Excess LLQ tiallic is
peimitteu only when all othei gueues have Leen emptieu, meaning theie is no inteilace
congestion. The iesult is a gueue that is always seiviceu as soon as possiLle, whenevei
it has tiallic penuing (the highest ol all piioiities, anu only one strict-high gueue is
peimitteu pei scheuulei map), with a guaiantee ol at least the conliguieu iate, while
still peimitting excess LLQ tiallic when no othei gueues aie congesteu.
The stiict high-piioiity gueuing leatuie allows you to conliguie tiallic policing that
pievents lowei-piioiity gueues liom Leing staiveu. The stiict-piioiity gueue uoes not
oveiiiue a lowei-piioiity gueue when an output (egiess) policei is uelineu to limit the
tiallic that the stiict gueue can seivice.
Il these uilleiences weie not enough to conluse the innocent, the piioiity-Laseu scheu-
ulei uilleis liom the weight-Laseu Ly honoiing conliguieu weight when seivicing neg-
ative cieuit gueues at the same piioiity. As a siue ellect, you can conliguie shaping
within a policy-Laseu scheuulei. This shaping-rate can Le less than the uelault 100,
Lut moie than the conliguieu tiansmit iate, which shapes the gueue`s output to the
specilieu value while allowing limiteu useu ol unuseu Lanuwiuth, as ueteimineu Ly the
uilleiences Letween the tiansmit anu shaping iates.
Figuie 10-1+ shows the piioiity-Laseu scheuulei Lehavioi.
The uppei poition ol Figuie 10-1+ shows the piioiity-Laseu scheuuling Lehavioi, which
iesults in the complete emptying ol all gueues at piioiity n Leloie it moves to the next
set ol gueues at piioiity n - 1. The conliguieu tiansmit iate is signilicant only Letween
classes at the sanc piioiity level. In this case, the highei-piioiity tiallic associateu with
gueue 1 is shown staiving the two lowei-piioiity gueues. To iesolve this issue, you neeu
to eithei iate-limit the high-piioiity tiallic oi assign all gueues to the same piioiity level.
The lowei hall ol Figuie 10-1+ shows how the piioiity-Laseu scheuulei honois weight
among negative cieuit gueues at the same piioiity. Since no auuitional piioiity packets
aie penuing in this example, the scheuulei continues to seive the low-piioiity gueues
accoiuing to theii weight, iathei than using a simple iounu-ioLin scheme, as is the case
with the M-seiies.
Although it`s likely oLvious, we aie nonetheless explicitly stating heie that, Lecause ol
the uilleiences in scheuulei Lehavioi, you cannot simply copy an existing M-seiies CoS
conliguiation ovei to a ]-seiies anu just expect it to woik the same way. Successlul
CoS Capabilities | 467
tianslation Letween the two scheuulei mouels ieguiies a complete unueistanuing ol
the opeiational uilleiences. The upcoming laL scenaiio pioviues an example ol Loth a
weight-Laseu anu a piioiity-Laseu scheuulei that meet the same ieguiiements, anu
theieloie pioviue similai opeiational Lehavioi.
Virtual channels
SRXs anu ]-seiies iouteis suppoit the notion ol a viitual channel, which in the context
ol CoS is not a logical connection such as an ATM peimanent viitual ciicuit (PVC),
Lut insteau a giouping ol logical channels that shaie a common scheuulei. Ve pioviue
a viitual channel conliguiation example in Viitual channels on page +6S, so a uetaileu
uiscussion is helu until that time. Foi now, it is sullicient to say that viitual channels
aie uesigneu to accommouate Fiame Relay huL anu spoke topologies Ly allowing a
cential site with a high-speeu attachment the aLility to scheuule tiallic into each DLCI
Laseu on some maximum iate, which is typically matcheu to the iemote site`s access
iate.
Iigurc 10-11. Thc priority-bascd schcdu|cr
468 | Chapter 10:Class of Service
Auaptive shaping is an SRX anu ]-seiies specilic leatuie that allows the
use ol two output shapeis, Laseu on the cuiient congestion state ol a Fiame Relay
netwoik. Figuie 10-15 shows the auaptive shaping leatuie in action.
Figuie 10-15 shows a paii ol iouteis connecteu via Fiame Relay. R1 is attacheu via a
T1 inteilace anu has a committeu inloimation iate (CIR) ol 50 ol T1 capacity, oi
77S KLps. The Fiame seivice olleis an extenueu Luist thiough the excess inloimation
iate (EIR). EIR is not guaianteeu, especially when the netwoik expeiiences congestion,
which is inuicateu in the loiwaiu uiiection Ly the ieceipt ol liames with a set FECN
Lit, anu in the Lackwaiu uiiection with a set Lackwaiu explicit congestion notilication
(BECN) Lit.
The shapei loi the BE class is set to 30 ol the inteilace Lanuwiuth. It is guaianteeu
only 30 ol capacity, which eguates to the +60.S KLps ol thioughput in this case.
Vhen othei classes aie not active, the BE class can Luist to its shapeu iate ol S0. The
shapeu iate matches the EIR paiametei, which is goou, Lecause tiallic in excess ol the
EIR can Le uiscaiueu upon ingiess Ly the netwoikthe shaping conliguiation pievents
immeuiate uiscaiu Ly limiting how much unuseu Lanuwiuth the BE class can use. The
Adaptive shaping.
Iigurc 10-15. Adaptivc shaping in rcsponsc to nctwor| congcstion
CoS Capabilities | 469
D
o
maximum (EIR) iate is shown in the top thioughput line anu iepiesents S0 ol a T1`s
usaLle thioughput.
An auaptive shapei is also conliguieu anu applieu to the T1 inteilace. The auaptive
shapei takes ellect when the last liame ieceiveu (assuming theie is tiansmit tiallic liom
R2 to R1) has a set BECN Lit. Vhen activateu, the auaptive shapei enloices the CIR
to pievent congestion-ielateu uiscaius within the netwoik. Vhen a liame is ieceiveu
with a cleaieu BECN Lit, the auaptive shapei is iemoveu anu R1 is again aLle to senu
at the EIR, assuming that no othei classes aie active.
Junos Software CoS Defaults
]unos soltwaie comes with a set ol uelault CoS settings that aie uesigneu to ensuie that
Loth tiansit anu contiol plane tiallic is piopeily classilieu anu loiwaiueu. The uelault
CoS setting suppoits two loiwaiuing classes (BE anu NC) anu implements an IP
pieceuence-style BA classiliei that maps netwoik contiol into gueue 3 while all othei
tiallic is placeu into gueue 0 as BE. A scheuulei is placeu into ellect on all inteilaces
that allocates 95 ol the Lanuwiuth to gueue 0 anu the iemaining 5 to gueue 3. Both
ol the gueues aie low piioiity, which guaiantees no staivation in eithei platloim.
A uelault VRED piolile with a single loss point is placeu into ellect. The 100 uiop
at 100 lill setting ellectively uisaLles VRED.
No IP packet iewiite is peiloimeu with a uelault CoS conliguiation. Packets aie sent
with the same maikeis as when they weie ieceiveu.
Four forwarding classes, but only two queues
The uelault CoS conliguiation uelines loui loiwaiuing classes: BE, EF, AF, anu NC,
which aie mappeu to gueues 0, 1, 2, anu 3, iespectively. Howevei, as noteu eailiei,
theie is no uelault IP classilication that will iesult in any tiallic Leing mappeu to eithei
the AF oi the EF class. This is goou, Lecause as also noteu eailiei, no scheuuling ie-
souices aie allocateu to gueue 1 oi 2 in a uelault CoS conliguiation. It`s woith noting
that the uelault MPLS EXP classiliei taLle is capaLle ol uiiecting tiallic into all loui
gueues, Lut MPLS is not Leing ueployeu in this laL. Some veiy inteiesting anu uillicult-
to-solve pioLlems occui il you Legin to classily AF oi EF tiallic without liist uelining
anu applying scheuuleis loi those classes. Doing so typically iesults in inteimittent
communications (some small tiickle cieuit is given to 0 gueues to pievent total stai-
vation) loi the AF/EF classes; this inteimittency is tieu to the loauing levels ol the BE
anu NC gueues, given that when theie is no BE oi NC tiallic, moie AF/EF can Le sent,
uespite the 0 uelault weighting.
BA and rewrite marker templates
]unos cieates a complete set ol BA classiliei anu iewiite maikei taLles loi each sup-
poiteu piotocol lamily anu type, Lut most ol these taLles aie not useu in a uelault CoS
470 | Chapter 10:Class of Service
conliguiation. Foi example, theie is Loth a uelault IP pieceuence (two actually) anu a
uelault DSCP classiliei anu iewiite taLle. You can view uelault anu custom taLles with
the show class-of-service classifier oi show class-of-service rewrite-rule
commanu.
The uelault values in the vaiious BA classiliei anu iewiite taLles aie chosen to iepiesent
the most common/stanuaiuizeu usage. In many cases, you will Le aLle to simply apply
the uelault taLles. Because you cannot altei the uelault taLles, it is suggesteu that you
always cieate custom taLles, even il they enu up containing the same values as the
uelault taLle. This uoes not involve much woik, as you can copy the contents ol the
uelault taLles into a customei taLle, anu in the lutuie, you will Le aLle to altei the
customei taLles as ieguiiements change.
In a uelault conliguiation, input BA classilication is peiloimeu Ly the ipprec-
compatibility taLle anu IP iewiite is in ellect, meaning the ToS maiking ol packets at
egiess match those at ingiess. The only iewiite taLle in ellect in a uelault conliguiation
is loi MPLS using the exp-default taLle.
CoS Summary
This section uetaileu the many common CoS capaLilities ol the ]unipei ioutei plat-
loims, anu it highlighteu the lew aieas wheie theii opeiation oi capaLilities uillei.
Despite these uilleiences, the use ol a common coue Lase anu CLI, comLineu with
ielatively consistent CoS hanuling, means that the same set ol commanus aie useu to
conliguie anu monitoi CoS opeiation.
The next section applies the knowleuge gaineu thus lai in a piactical CoS ueployment
anu veiilication scenaiio. Despite the lact that the laL sections aie such lun, you shoulu
consiuei taking anothei Lieak to think aLout the mateiial coveieu to this point anu to
ieview any aieas with which you aie not comloitaLle.
DiffServ CoS Deployment and Verification
It was a long time getting heie, Lut you have aiiiveu, anu you aie now ieauy to iush
heaulong into a ]unos soltwaie-Laseu CoS conliguiation anu veiilication laL. Fig-
uie 10-16 pioviues the netwoik topology loi the IP DillSeiv CoS ueployment scenaiio.
Theie aie a lew things to note in Figuie 10-16. The test topology is somewhat simplilieu,
anu the test Leu lacks the exteinal test eguipment neeueu to accuiately measuie anu
veiily uata plane peiloimance. The liist issue is not ieally a pioLlem, Lecause a woik-
aLle CoS conliguiation is somewhat iepetitive, Lasically involving the neeu to put the
same conliguiation Lits, consistently, in lots ol places. As such, any netwoik with a
cleaily maikeu euge anu uistiiLution/coie uevices seivices is a woikaLle mouel with
which to uemonstiate CoS conliguiation anu opeiational veiilication.
DiffServ CoS Deployment and Verification | 471
The suLset ol iouteis selecteu loi the CoS topology was chosen in laige pait Lecause
ol the (ielatively) low-speeu T1 inteilace inteiconnecting Bock anu Porter. Ve noteu
pieviously that CoS matteis only when link utilization Legins to appioach S0.
OLviously, with a given olleieu loau, a slowei link will exhiLit highei utilization than
a lastei oneconsiueiing the lack ol exteinal tiallic geneiatois, it will Le haiu enough
to congest a T1 link, let alone a 1 GLps Etheinet. In lact, to help stack the ouus against
a successlul CoS uemonstiation, the T1 link Letween Bock anu Porter is shapeu to
500 KLps. Although consiueiaLly less than the lull T1 iate ol 1536 KLps, the shapeu
iate still gualilies as a LioauLanu connection, which maintains a laii uegiee ol iealism.
Why Not Test CoS with Control-Plane-Generated Traffic?
The only tiue way to measuie the impact ol any CoS conliguiation is thiough uata
plane stimulation using a rcputab|c exteinal tiallic geneiatoi. Ve stiess the teim rcp-
utab|c heie Lecause any uevice that is useu to uiagnose pioLlems that might ielate to a
lew extia milliseconus ol gueuing uelay has to Le spot-on accuiate anu LelievaLle;
otheiwise, you aie likely to linu that lolks Llame unexpecteu iesults on the test meth-
ouology anu tools iathei than on the ioutei`s CoS peiloimance. Soltwaie-Laseu tiallic
geneiatois exist, anu they aie ceitainly Lettei than tiying to geneiate test tiallic liom a
Iigurc 10-1. DijjScrv CoS dcp|oyncnt topo|ogy
472 | Chapter 10:Class of Service
ioutei`s contiol plane, Lut a ieal ioutei testei, one that is haiuwaie-Laseu, can easily
cost tens ol thousanus ol uollais.
The ]unipei Netwoiks aichitectuie sepaiates the contiol anu uata planes, anu vaiious
iate-limiting anu piioiitization lunctions within the PFE anu iouting engine conspiie
against any attempt to geneiate eithei laige volumes ol tiallic oi test tiallic with a high
uegiee ol time-Laseu accuiacy. To expanu, inteinal RE-Laseu iate limits contiol how
much tiallic the RE can geneiate using iapiu oi lloou pings. The PFE also has a iate
limit as to how many such Inteinet Contiol Message Piotocol (ICMP) echo ieguest
packets it will even tiy to pass up to the host RE. Il that weie not enough, hanuling
ICMP messages is consiueieu a low piioiity within ]unos soltwaie. Given the choice
ol ieplying to a ping oi piocessing a Boiuei Gateway Piotocol (BGP) ioute upuate, a
]unipei ioutei always chooses the lattei. This is not to say that the ioutei will not ieply
to the ping; guite the oppositeit most ceitainly will ieply, Lut only when it`s goou
anu ieauy. Although exceeuingly ieasonaLle, this Lehavioi iesults in signilicant vai-
iance in ping iesponse, even in a netwoik that is laigely iule in the contiol plane anu is
tianspoiting veiy little uata.
Putting issues with time-Laseu inaccuiacies asiue loi the moment, the ]unos soltwaie
contiol plane simply uoes not geneiate enough tiallic to congest most mouein netwoik
links. Vith no congestion, theie is no way to consistently uemonstiate any Lenelit to
a CoS conliguiation.
Consiuei the output taken Letween PBR anu Bock, when the on|y tiallic in the netwoik
is peiiouic OSPF hellos anu the ICMP test tiallic itsell:
[edit]
lab@PBR# run traceroute 10.10.12.3
traceroute to 10.10.12.3 (10.10.12.3), 30 hops max, 40 byte packets
1 10.10.12.3 (10.10.12.3) 10.519 ms 4.800 ms 6.902 ms
The tiaceioute conliims that the uiiect 1 GLps link is useu Letween PBR anu Bock, yet
notice the laige vaiiance in ping iesponse times, which is noimal anu expecteu given
the ]unipei uesign:
[edit]
lab@PBR# run ping 10.10.12.3 count 20
PING 10.10.12.3 (10.10.12.3): 56 data bytes
64 bytes from 10.10.12.3: icmp_seq=0 ttl=64 time=2.926 ms
64 bytes from 10.10.12.3: icmp_seq=1 ttl=64 time=2.153 ms
64 bytes from 10.10.12.3: icmp_seq=2 ttl=64 time=2.137 ms
64 bytes from 10.10.12.3: icmp_seq=3 ttl=64 time=2.147 ms
64 bytes from 10.10.12.3: icmp_seq=4 ttl=64 time=3.969 ms
64 bytes from 10.10.12.3: icmp_seq=5 ttl=64 time=2.152 ms
. . .
64 bytes from 10.10.12.3: icmp_seq=8 ttl=64 time=1.947 ms
64 bytes from 10.10.12.3: icmp_seq=9 ttl=64 time=3.993 ms
64 bytes from 10.10.12.3: icmp_seq=10 ttl=64 time=3.989 ms
64 bytes from 10.10.12.3: icmp_seq=11 ttl=64 time=2.147 ms
64 bytes from 10.10.12.3: icmp_seq=12 ttl=64 time=2.136 ms
64 bytes from 10.10.12.3: icmp_seq=13 ttl=64 time=1.909 ms
DiffServ CoS Deployment and Verification | 473
64 bytes from 10.10.12.3: icmp_seq=14 ttl=64 time=2.137 ms
--- 10.10.12.3 ping statistics ---
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.868/16.122/69.799/14.835 ms
The highlighteu entiies show the uegiee ol iesponse time vaiiance consiueieu pai loi
the couise in the ]unipei uesign. Cleaily, tiying to valiuate CoS using iapiu pings is
simply not woikaLle in ]unos soltwaie, Lecause you will not Le aLle to geneiate enough
tiallic to ieliaLly congest most links. Also, the test iesults will Le all ovei the map,
whethei oi not youi CoS conliguiation is woiking, simply Lecause the enupoints gen-
eiating the test tiallic tieat it as a low-piioiity piocess, theieLy Lieaking the CoS chain
at its liist link.
Cannot control classification of locally generated traffic
Geneially speaking, unless you aie iunning ]unos soltwaie Release S.5 oi latei, you
have viitually no contiol ovei what egiess gueue locally geneiateu tiallic is placeu into.
The Lasic issue heie is that when the RE injects tiallic into the PFE, it Lypasses ingiess
multilielu anu BA classilication anu simply uoes what it leels is Lest.
Foi example, a BGP tiansmission is noimally placeu into the BE gueue (0), unless it is
a ietiansmission, in which case it goes into the NC gueue (3). As anothei example, you
can geneiate a ping with any aiLitiaiy ToS pattein, Lut this ping will Le locally classilieu
as BE anu placeu into gueue 0. Downstieam noues can Le expecteu to coiiectly iec-
ognize the packet`s ToS lielu, Lecause they see the tiallic as tiansit.
The inaLility to apply youi tiansit CoS actions to locally geneiateu tiallic is yet anothei
ieason why you cannot test a local noue`s PHB with tiallic souiceu oi ieceiveu Ly that
same noue.
Staiting on ]unos Release S.5 M-seiies anu MX euge iouteis, the outLounu gueue as-
signments loi iouting-engine-geneiateu tiallic can Le mouilieu liom theii uelaults. The
use ol the class-ol-seivice host-outLounu-tiallic commanus allows an auministiatoi to
change the uelault hanuling ol outgoing tiallic liom the iouting engine. This allows
the use ol gueues othei than 0 anu 3 on the outgoing inteilaces. The changes aie gloLal
in natuie, anu the gueues must Le conliguieu on the inteilaces to have an ellect on the
tiallic.
Enter resource performance monitoring
]unipei iouteis suppoit an SLA monitoiing leatuie that uses Real-Time Peiloimance
Monitoiing (RPM) pioLes to measuie peiloimance, anu il uesiieu, to geneiate Simple
Netwoik Management Piotocol (SNMP) alaims when peiloimance lalls Lelow a con-
liguiaLle thiesholu. In the initial implementation, the RPM uaemon ian as a usei pioc-
ess in the REunloitunately, this iesulteu in inaccuiacies when the RE CPU happeneu
to Le Lusy uoing something else. Routeis can move the timestamp lunction into the
ieal-time thieau loi signilicantly impioveu accuiacy (M10i iouteis ieguiie an Auaptive
474 | Chapter 10:Class of Service
Seivices PIC ASP). The use ol haiuwaie timestamps uoes not cause the actual genei-
ation oi piocessing ol the RPM pioLes to Le any moie accuiate, as the RE will still
scheuule the piocessing as it sees lit, Lut when the RE uoes get aiounu to looking at
the pioLe, the timestamp, alieauy auueu at the haiuwaie layei, allows loi accuiate
peiloimance measuiements.
Although not neaily as uelinitive as a rca| tiallic geneiatoi, the RPM seivice automat-
ically tiacks loss anu summaiizes one-way anu iounu-tiip uelays, incluuing jittei meas-
uiements, which Leats the heck out ol using pings anu a pau ol papei. Also, Lecause
the RPM seivice is instantiateu on a paii ol iouteis that aie cxtcrna| to the CoS test Leu,
maximum accuiacy can Le expecteu. By cxtcrna|, we mean that Wheat anu Hops simulate
attacheu CE uevices anu aie not taxeu with any packet loiwaiuing (othei than the
locally geneiateu RP pioLes themselves) oi any othei piocessing task that coulu leau
to laige vaiiances in RPM test pioLe iesultsthese iouteis aie not iunning any othei
seivices, aie not iunning any iouting piotocols, anu aie not involveu in the FTP tianslei
useu to piouuce congestion. In this laL topology, Wheat anu Hops lunction stiictly as
SLA monitoiing ueviceswhich is actually a iealistic scenaiio, as some seivice pio-
viueis ueploy iouteis in just such a capacity.
Configure DiffServ-Based CoS
Relei Lack to Figuie 10-16 loi the topology uetails ol the IP DillSeiv CoS scenaiio. You
can assume that the netwoik inliastiuctuie is alieauy conliguieu with the inteilace
auuiessing anu single-aiea OSPF topology shown. A passive OSPF instance is enaLleu
on the customei-lacing inteilaces at PBR anu Yeast in oiuei to pioviue ieachaLility Le-
tween theii iespective inteilace auuiesses. Youi goal is to enaLle CoS in accoiuance
with these ciiteiia:
1. Peiloim the lollowing multilielu classilication:
Classily ICMP timestamp messages ieceiveu ovei customei-lacing inteilaces as
EF to suppoit RPM-Laseu SLA monitoiing loi the EF class.
Classily Telnet tiallic ieceiveu ovei customei-lacing inteilaces as Lionze (BR).
Classily OSPF in the coie as NC.
Classily all othei tiallic as BE.
2. Peiloim DSCP-Laseu BA classilication at all othei noues, suppoiting the lollowing
loiwaiuing classes anu gueue assignments:
BE, mappeu to gueue 0
EF, mappeu to gueue 1
BR, mappeu to gueue 2
NC, mappeu to gueue 3
3. Shape tiallic on the Fiame Relay link to 500 KLps, in accoiuance with a 0 CIR
seivice teiminating in a 500 KLps switch poit.
DiffServ CoS Deployment and Verification | 475
+. Deline anu apply the lollowing scheuulei policy:
Pioviue BE at least 50 anu allow use ol excess Lanuwiuth. Conliguie a PLP =
0 RED piolile with 5 uiop pioLaLility at 50, anu 20 uiop pioLaLility at
S0, anu a PLP = 1 RED piolile with 20 uiop pioLaLility at 50, anu 70
uiop pioLaLility at S0.
Limit BR to 10; accept up to 1 MLps/200 KB Luist ol BR liom customeis.
Excess tiallic must Le tieateu as BE with high PLP Ly all noues.
Pioviue EF at least 35 anu ensuie that it`s seiviceu guickly to suppoit low-
latency applications. Tiallic must not expeiience moie than 30 milliseconus ol
Lulleiing pei hop.
Pioviue NC with at least 5 anu ensuie that it cannot Le staiveu. The NC class
must Le aLle to use excess Lanuwiuth.
At liist glance, the long list ol CoS ieguiiements may seem uaunting, Lut when tackleu
in small paits, the oveiall task Lecomes much easiei to manage. CoS-ielateu conligu-
iations tenu to have a lot ol common elements, which allows you to save time Ly con-
liguiing one noue anu then using that conliguiation as a template to Lootstiap the
conliguiation ol the iemaining iouteis.
Because the uelault CoS conliguiation olleis scheuuling suppoit loi the BE anu NC
classes only, it`s a goou iuea to get much ol the CoS inliastiuctuie up anu iunning
Leloie you apply any classilication that coulu iesult in tiallic Leing mappeu into gueues
othei than 0 anu 3. This avoius potential uisiuption iesulting liom tiallic Leing assigneu
to a gueue with no scheuuling iesouices assigneu.
This scenaiio calls loi the use ol DSCP classilication. Pievious sections uetaileu how
the oiiginal IP pieceuence lunctionality is suLsumeu Ly the CS coue point giouping.
The uelault DSCP iewiite anu classiliei taLles suppoit the CS DSCPs. This means you
can use the uelault IP pieceuence classiliei at the netwoik`s euges while the iest ol CoS
is conliguieu, incluuing the DSCP BA classilication anu iewiite in the uistiiLution anu
coie layeis. Stateu uilleiently, the goal is to enaLle CoS loi all loui loiwaiuing classes,
while maintaining the pie-CoS classilication ol only two loiwaiuing classes in an at-
tempt to minimize uisiuptions stemming liom a netwoik with paitial CoS conliguia-
tion. Vhen all noues aie CoS-awaie, MF classilication is activateu at the euge to enaLle
use ol all loui loiwaiuing classes.
Multifield classification and policing (task 1)
The liist set ol CoS lunctions to Le conliguieu aie the multilielu classilieis useu at the
euges to peiloim initial classilication actions on the tiallic ieceiveu liom customeis.
This is accomplisheu with liiewall lilteis, which also pioviue a hook into the policing
neeueu loi the EF class in this example. Because the customei uevices uo not iun any
iouting piotocol, theie is no neeu to suppoit NC classilication at ingiess. Il NC suppoit
is neeueu, it`s a goou iuea to ueline explicit multilielu classiliei suppoit, Lecause the
476 | Chapter 10:Class of Service
iesults ol ingiess BA classilication can Le oveiwiitten Ly a multilielu classiliei, which
coulu leau to NC Leing placeu into the BE gueue.
A multilielu classiliei anu associateu policei meeting the ieguiiements ol this example
aie conliguieu at PBR:
lab@PBR# show
policer police_bronze {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 200k;
}
then {
loss-priority high;
forwarding-class best-effort;
}
}
filter mf_classify {
term classify_ef {
from {
protocol icmp;
icmp-type [ timestamp timestamp-reply ];
}
then {
count ef_in;
forwarding-class expedited-forwarding;
accept;
}
}
term classify_bronze {
from {
protocol tcp;
port telnet;
}
then {
policer police_bronze;
count bronze_in;
forwarding-class bronze;
}
}
term else_be {
then {
forwarding-class best-effort;
accept;
}
}
}
The classify_ef teim matches on ICMP timestamp-ielateu messages, which aie then
classilieu as EF. This teim suppoits the ICMP-Laseu RPM pioLe ieguest that is gen-
eiateu at Wheat, along with the pioLe ieplies geneiateu at Hops. The classify_bronze
teim peiloims a similai lunction loi matching Telnet tiallic, except it also evokes a
policei to limit tiallic in this class. The associateu bronze_policer is set with a tiallic
piolile in accoiuance with the pioviueu ciiteiia loi iate anu Luist size. Conloiming
DiffServ CoS Deployment and Verification | 477
tiallic is hanueu Lack to the calling classify_bronze teim, wheie it is classilieu as BR,
while out-ol-piolile tiallic is classilieu as BE with a high-loss piioiity. Both the EF- anu
BR-ielateu teims evoke a countei action that can Le useu latei when conliiming that
CoS hanuling anu classilication aie woiking as expecteu. The linal teim matches on
eveiything else loi classilication into the BE Lin.
Although not shown, the same multilielu classiliei anu policei conliguiation is also
auueu to Yeast. Also, loi ieasons citeu eailiei, the multilielu classiliei is not yet placeu
into ellect given that iesouices have not yet Leen uelineu loi the EF oi BR class.
BA classification and rewriting (task 2)
Vith multilielu classilication ieauy to Le placeu into ellect, you move on to cieate the
DSCP-Laseu BA taLles useu Ly uistiiLution anu coie layei uevices loi ellicient packet
classilication. This example cieates custom taLles that aie then populateu with the
uelaults. This ensuies lull taLle population, which is a goou housekeeping piactice,
given the ieguiieu Lehavioi ol uispatching unmatcheu tiallic into the BE gueue. Note
that unlike the uelault IP pieceuence classiliei (which is actually in ellect Ly uelault),
the uelault DSCP taLles suppoit loui loiwaiuing classes: BE, AF, EF, anu NC. This
example ieplaces the AF class with a custom-uelineu class calleu bronze (BR). Once
you ueline a loiwaiuing class calleu BR anu map it to gueue 2, the classilication anu
iewiite taLles automatically associate any coue point mapping to that gueue as Le-
longing to the BR class.
The uelault DSCP taLle entiies uo not suppoit a high- anu low-loss piioiity loi BE
tiallic. To convey an ingiess setting ol PLP to othei noues, as ieguiieu in this case stuuy,
you neeu to ueline an entiy loi BE tiallic with high-loss piioiity. It is customaiy to use
the least signilicant Lit ol a given BA lielu to uenote loss piioiity, which is the appioach
taken heie, such that the Linaiy pattein 000000 is inteipieteu as BE with a low-loss
piioiity, anu Linaiy 000001 inuicates BE with a high-loss piioiity. Note how each entiy
in a BA classilication shoulu have a matching entiy in the ielateu iewiite taLle loi
consistent hanuling in uownstieam noues.
The custom loiwaiuing class uelinition anu BA classilication/iewiite conliguiation is
shown at Bock:
[edit class-of-service]
lab@Bock# show forwarding-classes
queue 2 bronze;
[edit class-of-service]
lab@PBR# show classifiers
dscp dscp_classify {
import default;
forwarding-class best-effort {
loss-priority high code-points 000001;
}
}
478 | Chapter 10:Class of Service
[edit class-of-service]
lab@PBR# show rewrite-rules
dscp dscp_rewrite {
import default;
forwarding-class best-effort {
loss-priority high code-point 000001;
}
}
The forwarding-classes statement is useu to ueline a new loiwaiuing class alias calleu
bronze, anu to Linu that alias to a gueue numLei. In this case, only one nonuelault
loiwaiuing class alias is neeueu, anu it is coiiectly mappeu to gueue 2; in a uelault
conliguiation, this gueue numLei is associateu with the AF alias.
The usei-uelineu DSCP BA classiliei anu iewiite taLles aie assigneu names that uenote
theii lunction anu aie initially populateu with the coue point uelaults. A single mouilieu
entiy is auueu to suppoit the conveyance ol loss piioiity loi the BE class to uownstieam
noues.
The custom loiwaiuing class uelinition anu DSCP classilication/iewiite taLles aie
placeu into ellect on all noncustomei-lacing inteilaces at all noues. Theie is no haim
in applying these taLles to the customei-lacing inteilaces, Lut theie isn`t much gain
eithei. The multilielu classilication that will Le useu at the euge makes any BA classiliei
supeilluous, given that the mf_classify liltei is wiitten to classily a|| tiallic that is ie-
ceiveu anu oveiiiues the iesults ol any BA classilication anyway. A iewiite maikei at
the customei euge is geneially useu only when you wish to ieset packet maikings to
some agieeu upon uelault, oi to help oLluscate the maikings that aie signilicant in the
coie, which coulu Le useu as ammunition in a CoS-centeieu uenial ol seivice (DoS)
attack. In this example, packets aie hanueu to the egiess customei uevice, with what-
evei maiking they weie ieceiveu with on the coie-lacing inteilace.
Heie is the application ol the usei-uelineu DSCP classiliei anu iewiite taLles, again at
Bock:
[edit class-of-service]
lab@Bock# show interfaces
ge-0/0/0 {
unit 1241 {
classifiers {
dscp dscp_classify;
}
rewrite-rules {
dscp dscp_rewrite;
}
}
}
t1-2/0/2 {
unit 100 {
classifiers {
dscp dscp_classify;
}
rewrite-rules {
DiffServ CoS Deployment and Verification | 479
dscp dscp_rewrite;
}
}
}
At this stage, the custom loiwaiuing class uelinition anu DSCP BA conliguiation is
ieplicateu to all noues. The DSCP classiliei anu iewiite taLles aie then applieu on all
inteilaces in the CoS topology, with the exception ol the customei-lacing inteilaces,
which uo not use a BA classiliei oi iewiite taLle.
Completing the aloiementioneu steps at all iouteis has accomplisheu a laige poition
ol the neeueu CoS conliguiation. To iecap, you now have a multilielu classiliei with
policing on the netwoik`s euges (not yet activateu, howevei), you have uelineu a custom
loiwaiuing class call bronze, anu you cieateu anu applieu custom DSCP classilieis anu
iewiite iules to suppoit loss piioiity loi the BE class on all noncustomei-lacing
inteilaces.
The DSCP taLles cuiiently use uelault values loi any entiy not explicitly specilieu Ly
the usei Lecause the import default statement is incluueu. The uelault coue points
inheiently suppoit the IP pieceuence-Laseu classilication that is still in ellect at the
netwoik`s euges. The use ol the uelault IP pieceuence classiliei, comLineu with the
inheient compatiLility ol IP pieceuence via the CS DSCPs, iesults in all tiallic Leing
classilieu into eithei the BE oi the NC class at ingiess, just as it was Leloie you Legan
the CoS conliguiation. Impoitantly, the ingiess classilication is maintaineu enu to enu
even though uownstieam uevices classily Laseu on DSCP. It`s noteu again that the
uelault scheuulei conliguiation, which is still in ellect, allocates iesouices only to the
BE anu NC classes, meaning that actions to this point shoulu have hau no opeiational
ellect on the netwoik. It coulu Le saiu that loi the aveiage coie noue, the only changes
aie a newly uelineu Lut still unuseu loiwaiuing class anu the use ol DSCP iathei than
uelault IP pieceuence ingiess classilication. Howevei, the compatiLility Letween the
pieceuence anu DSCP taLles means that the packets aie classilieu into BE oi NC with
Loth the oiiginal anu mouilieu conliguiations.
CoS shaping (task 3)
Shaping, which ieuuces the maximum speeu ol an inteilace to some lessei value, is
uselul loi a vaiiety ol ieasons. You can iate-limit an inteilace using a policei, Lut this
is pioLlematic liom a CoS peispective Lecause the CoS components uo not see the
policeu iate, Lut iathei the iate ol the inteilace itsell. As a iesult, policing a 1 GLps
inteilace to 1 MLps, anu then conliguiing a scheuulei with a 1 tiansmit iate, leaus
the scheuulei to allocate 1 ol 1 GLps, not the policeu iate ol 1 MLps. Shaping pei-
loimeu at the [edit class-of-service] hieiaichy woiks aiounu this issue, Lut is sup-
poiteu on only M-seiies iouteis when using IQ/IQ2 PICs. ]-seiies iouteis suppoit
shaping on all inteilaces Lecause ol theii Luilt-in suppoit loi pei-unit scheuuling.
In this example, Bock anu Porter aie inteiconnecteu via a Fiame Relay seivice piovi-
sioneu with a 0 CIR, which teiminates in a 500 KLps poit. Tiallic sent in excess ol the
480 | Chapter 10:Class of Service
poit speeu iesults in immeuiate uiscaiu, so the T1 inteilaces at Bock anu Porter aie
shapeu to a 500 KLps iate. Latei, when you apply a scheuulei to these inteilaces, the
scheuulei will allocate iesouices Laseu on the shapcd iate ol 500 KLps iathei than the
1.536 MLps physical iate. Vhat lollows aie the Fiame Relay inteilace conliguiation
anu ielateu CoS shaping settings loi Bock:
[edit]
lab@Bock# show interfaces t1-2/0/2
description Bock-to-porter;
per-unit-scheduler;
dce;
encapsulation frame-relay;
unit 100 {
dlci 100;
family inet {
address 10.10.10.1/30;
}
}
[edit]
lab@Bock# show class-of-service interfaces t1-2/0/2
unit 100 {
shaping-rate 500k;
classifiers {
dscp dscp_classify;
}
rewrite-rules {
dscp dscp_rewrite;
}
}
The coue highlights show the per-unit-scheduler statement, which is specilieu at the
inteilace uevice level to Lack up the shaping-rate conliguiation at the [edit class-of-
service interfaces interface-name unit unit-number] hieiaichy. Also highlighteu is
the ielateu Fiame Relay conliguiation; in this case, Bock is set to a uata ciicuit-
teiminating eguipment (DCE) uevice to enaLle use ol ANSI Annex D link integiity
(keepalive) anu PVC status polling liom (uelault) uata teiminal eguipment (DTE)
Porter.
Vith shaping in place, the only CoS lunctionality yet to Le conliguieu is the scheuulei
uelinition anu application to CoS-enaLleu inteilaces.
Scheduler definition and application (task 4)
Up until this stage, the CoS conliguiation examples anu steps shown aie the same
whethei you aie uealing with any platloim. The uilleiences in scheuulei Lehavioi Le-
tween platloims uemanu caielul consiueiationyou will geneially neeu uilleient
scheuulei conliguiations loi a piioiity-Laseu veisus a weight-Laseu to piouuce similai
scheuuling ellects.
DiffServ CoS Deployment and Verification | 481
The scheuuling ieguiiements ol this scenaiio weie ueciueu upon in egual paits Lecause
they aie typical anu Lecause they help to uemonstiate the uilleiences in scheuuling
Lehavioi. TaLle 10-+ summaiizes the scheuuling ieguiiements.
Tab|c 10-1. Sunnary oj schcdu|ing bchavior jor thc DijjScrv sccnario
Class Guaranteed rate Priority; AQM; buffer Excess bandwidth
BE 50% Low; WRED based on PLP; N/A Yes
BR 10% Low; N/A; N/A No/Yes, ingress policing sets excess as BE with PLP = 1
EF 35% High; N/A; 30 msec No
NC 5% High; N/A; N/A Yes
TaLle 10-+ shows that two piioiity levels aie ieguiieu to
help expeuite EF anu NC tiallic ovei BR anu BE, anu also uetails each gueue`s settings
with iegaiu to tiansmit weight, AQM (VRED)enaLleu, Lullei size iestiiction, anu
aLility to use leltovei Lanuwiuth aLove its conliguieu weight.
The lollowing output shows a weight-Laseu scheuulei uelinition that meets all ol the
specilieu ieguiiements:
[edit class-of-service]
lab@M-Series# show schedulers
be_sched {
transmit-rate percent 50;
priority low;
}
ef_sched {
transmit-rate percent 35 exact;
priority high;
buffer-size temporal 30k;
}
nc_sched {
transmit-rate percent 5;
priority high;
}
bronze_sched {
transmit-rate percent 10 exact;
priority low;
}
The EF class uoes not ieguiie use ol excess Lanuwiuth anu is iate-limiteu thiough the
use ol the exact keywoiu. This limits EF tiallic to its conliguieu weight, which helps
to ensuie that the class is not oveisuLsciiLeu in uownstieam noues. Because Loth the
EF anu NC classes aie set to high piioiity, you can guaiantee that neithei can staive
the othei. By not specilying strict-high, you also ensuie no staivation among low-
piioiity gueues shoulu the nonpoliceu NC class Lecome oveiactive. This is Lecause the
weight-Laseu scheuulei iounu-ioLins Letween high-piioiity gueues until theii tiansmit
weight has Leen satislieu, anu then moves on to seivice low-piioiity gueues with pos-
itive cieuit.
Weight-based scheduler definition.
482 | Chapter 10:Class of Service
The EF scheuulei has its Lullei uepth manually set to 30 milliseconus ol uelay Lanu-
wiuth (30,000 micioseconus). This gueue`s ielative high tiansmit weight comLineu
with its high piioiity means it shoulu maintain a low lill level anyway. The ieuuceu
Lullei size anu iate limiting leaus to uiops in the EF gueue uuiing peiious ol excessive
EF tiallic, even when all othei classes aie iule. In most cases, tiying to accept oveillow
EF tiallicloi example, Ly ieclassilying the excess into anothei class oi Ly conliguiing
evei-laigei Lullei uepthsiesults in moie haim than goou. This is Lecause although
you may ieuuce the oveiall numLei ol EF uiops, the iesultant inciease in uelay anu
uelay vaiiance is olten moie uisiuptive to a ieal-time application than the outiight loss
such actions aimeu to pievent. Voise yet, tiouLleshooting this type ol pioLlem is uil-
licult when compaieu to the ielatively stiaightloiwaiu task ol coiielating seivice com-
plaints to excessive EF gueue uiops.
You cannot use the exact keywoiu loi NC scheuuling Lecause ol the ieguiiement that
it Le aLle to use any excess Lanuwiuth. Vithout some loim ol policing/iate limiting,
it is possiLle that excess NC tiallic coulu capitalize on all unuseu Lanuwiuth, pieventing
Loth the BE anu BR classes liom Leing aLle to senu tiallic aLove theii conliguieu
weights. Although it`s easy enough to police NC tiallic, this is seen as unnecessaiy heie
Lecause:
Theie is no ieguiiement that the BE anu BR classes must actually get excess Lanu-
wiuth, just that they shoulu Le aLle to use it when it`s availaLle. Because M-seiies
scheuuling is not stiict-piioiity-Laseu, you neeu to woiiy aLout having high-
piioiity gueues allecting a low-piioiity gueue`s aLility to get at least its conliguieu
weight.
You aie not accepting any NC tiallic liom customei/enu uevices, which means the
only souice ol NC tiallic is within the netwoik, anu you tiust youi netwoik not to
launch an NC-Laseu DoS attack. The only souice ol NC in this netwoik is OSPF,
which unlike a lull BGP taLle leeu, uoes not geneiate appieciaLle volumes ol NC.
This is especially tiue loi a small- to meuium-scale netwoik that is mostly staLle.
The BR scheuulei is also shapeu to its tiansmit iate via the exact keywoiu; iecall that
ingiess policing classilies excess BR as BE, so the BR class gets its excess Lanuwiuth
inuiiectly via the BE class.
Heie is an example ol a piioiity-Laseu scheuulei, lounu
on ]-Seiies iouteis, that closely appioximates the weight-Laseu example just uesciiLeu:
be_sched {
transmit-rate percent 50;
priority low;
}
ef_sched {
transmit-rate percent 35 exact;
priority high;
buffer-size temporal 30k;
}
nc_sched {
Priority-based scheduler definition.
DiffServ CoS Deployment and Verification | 483
transmit-rate percent 5;
shaping-rate percent 20;
priority high;
}
bronze_sched {
transmit-rate percent 10 exact;
priority medium-high;
}
Because ol the stiict piioiity-Lase natuie scheuulei, youi liist concein shoulu Le how
to ensuie that highei-piioiity classes uo not pievent lowei-piioiity classes liom at least
getting theii conliguieu weight. This is accomplisheu in a numLei ol ways.
Fiist the EF anu NC classes aie set to the same piioiity, which is the highest piioiity
conliguieu. This ensuies that the EF anu NC classes cannot Le staiveu, anu that they
cannot staive each othei. The EF class is again cappeu to its conliguieu weight using
exact. In this example, the NC class is shapcd, iathei than iate-limiteu, allowing it to
use up to 20 ol inteilace Lanuwiuth.
Although not aLle to senu at line iate, technically this meets the ieguiiement given
Lecause the NC class is aLle to use excess Lanuwiuth Leyonu its conliguieu weight.
This Lehavioi uilleis liom the weight-Laseu scheuulei example, wheie the NC class
coulu use up to 100 ol availaLle Lanuwiuth when no othei classes aie active, Lut
again, the Lehavioi still meets all ciiteiia specilieu.
Seconu, the shapeu iate ol 20 loi the NC class, comLineu with the maximum 35
iate loi the EF class, accounts loi only 55 ol tiansmit Lanuwiuth. This leaves a guai-
antee that at least +5 ol the Lanuwiuth iemains loi use Ly the BE anu BR classes. The
BR class is seiviceu altei the high-piioiity gueues have ieacheu theii limits, Lut Leloie
the BE class uue to its highei piioiity setting. Because the BR class is limiteu to a max-
imum ol 10, you can guaiantee that the BE class will get at least 35 ol inteilace
Lanuwiuth, using the lollowing loimula:
BE avail = 100 - (EF max - NC max - BR max)
BE avail = 100 - (35 - 20 - 10)
BE avail = 100 - 65
The net iesult ol all this inteiaction is that the BE class is actua||y guaianteeu to get
35 ol tiansmit Lanuwiuth, uespite its conliguieu 50 weight. Howevei, this ieuuc-
tion in BE capacity occuis on|y uuiing peiious ol excessive NC activity, an event that
shoulu Le Loth iaie anu tiansient. Besiues, any negative impacts ol the uesign aie iele-
gateu to the BE class wheie lolks aie useu to Leing tieateu pooily, so who will complain?
An Alternative Priority-Based Scheduler Approach
Although not uemonstiateu heie, you can moie closely appioximate weight-Laseu
scheuulei Lehavioi Ly uelining auuitional loiwaiuing classes that aie useu to suppoit
oveillow tiallic liom highei-piioiity classes anu that aie seiviceu only when no othei
484 | Chapter 10:Class of Service
rca| class has tiallic penuing. This appioach is guite woikaLle on the iouteis, given the
suppoit ol eight gueues/loiwaiuing classes.
Heie is an example ol the alteinative scheuulei appioach:
be_sched {
transmit-rate percent 49;
priority low;
}
ef_sched {
transmit-rate percent 35 exact;
priority high;
buffer-size temporal 30k;
}
nc_sched {
transmit-rate percent 5 exact;
priority high;
}
bronze_sched {
transmit-rate percent 10 exact;
priority medium-high;
}
nc_overflow_sched {
transmit-rate percent 1;
priority low;
}
Note that the scheuulei now suppoits live classes. The new loiwaiuing class is uelineu
as nc_overflow, anu the ielateu scheuulei is assigneu a low piioiity, as well as a minimal
tiansmit iate uesigneu to minimize impact on the BE class. The NC scheuulei is now
conliguieu with an exact tiansmit iate ol 5. The suppoit ol excess NC is now Lackeu
up Ly a policei (not shown) that limits NC to 5 ol the inteilace speeu, which loi
GigaLit Etheinet woulu Le 50 MLps.
To conliguie a policei that is Laseu on a peicentage ol inteilace Lanu-
wiuth, you must auu the interface-specific keywoiu to the liiewall
liltei that calls the policei.
Tiallic exceeuing the policei piolile is classilieu as nc_overflow. Because the nc-
overflow anu BE classes aie assigneu the same piioiity, you ensuie that excessive
amounts ol BE tiallic cannot staive the NC oveillow gueue. This is a mattei ol choice
heie, as the ieguiiements uo not manuate that the NC class a|ways Le aLle to senu moie
than its weight, just that it Le aLle to when excess Lanuwiuth is availaLle.
Vith the alteinative conliguiation, the NC class gets a guaianteeu 5 as NC, anu an
auuitional 1 BE tiansmit iate, anu can Luist up to 100 when no othei classes aie
active (95 ol which will Le tieateu as BE). At the same time, the BE class is now
guaianteeu to get at least +9 when all othei classes aie active anu can Luist to line
iate when they aie not. This conliguiation meets all ieguiiements, anu olleis the
DiffServ CoS Deployment and Verification | 485
auuitional Lenelit ol allowing the NC scheuulei to opeiate at 100 when othei classes
aie iule.
Define RED Profiles
To complete the uelinition ol the BE scheuulei, you must ueline two uiop pioliles
one loi PLP 0 anu anothei loi PLP 1 tiallicanu link them to the be_sched scheuulei.
The uiop pioliles aie shown, anu the BE scheuulei is upuateu to incoipoiate them. The
same VRED conliguiation applies to any ]unipei iouteis Lecause the ieguiiements uo
not expect uiop Lehavioi that is tieu to TCP veisus UDP, which is not suppoiteu on
some mouels. This is an example ol VRED Lecause two uiop pioliles aie uelineu; in
this case, the weighting is towaiu the inteinal loss-piioiity status ol each packet in the
BE gueue:
[edit class-of-service]
lab@PBR# show drop-profiles
be_low_plp {
fill-level 50 drop-probability 5;
fill-level 80 drop-probability 50;
}
be_high_plp {
fill-level 50 drop-probability 50;
fill-level 80 drop-probability 70;
}
[edit class-of-service]
lab@PBR# show schedulers be_sched
transmit-rate percent 50;
priority low;
drop-profile-map loss-priority low protocol any drop-profile be_low_plp;
drop-profile-map loss-priority high protocol any drop-profile be_high_plp;
The iemaining loiwaiuing classes use the uelault RED piolile, which ellectively uisaLles
RED given that the only uiop point specilieu is 100 uiop at 100 lill.
Scheduler application
The piioiity-Laseu veision ol the scheuulei uelinition is useu in this example, in keeping
with the ]-seiies makeup ol the enteipiise iouting laL. You apply a scheuulei to an
inteilace thiough a scheduler-map statement. Heie is a woiking scheuulei map anu its
application to all CoS-enaLleu inteilaces, shown at noue PBR:
[edit class-of-service]
lab@PBR# show scheduler-maps
er_cos_scheduler {
forwarding-class best-effort scheduler be_sched;
forwarding-class expedited-forwarding scheduler ef_sched;
forwarding-class network-control scheduler nc_sched;
forwarding-class bronze scheduler bronze_sched;
}
486 | Chapter 10:Class of Service
[edit class-of-service]
lab@PBR# show interfaces
ge-0/0/0 {
unit 412 {
scheduler-map er_cos_scheduler;
}
unit 1241 {
scheduler-map er_cos_scheduler;
classifiers {
dscp dscp_classify;
}
rewrite-rules {
dscp dscp_rewrite;
}
}
}
The scheduler-map links each uelineu loiwaiuing class to a scheuuling policy. Vhen
applieu to an inteilace, a scheuulei is instantiateu accoiuing to the comLineu policy ol
the statements in the scheduler-map. Note that in this example the use ol VLAN tagging
waiiants the neeu loi pei-unit scheuuling, which enaLles scheuuling at the logical
inteilacethat is, at the VLAN level. By uelault, a pei-unit scheuulei assumes the lull
physical inteilace Lanuwiuth, unless it is shapeu to a lessei value. The scheuulei map
shown will lail to commit unless per-unit-scheduling is also set at the [edit interfaces
interface-name] hieiaichy, as shown:
[edit]
lab@PBR# show interfaces ge-0/0/0
per-unit-scheduler;
vlan-tagging;
unit 412 {
description PBR-to-Wheat;
vlan-id 412;
family inet {
address 172.16.1.2/24;
}
}
unit 1241 {
description PBR-to-Bock;
vlan-id 1241;
family inet {
address 10.20.130.2/24;
}
}
Activate multifield classification
Now that all loiwaiuing classes have Leen uelineu with scheuuling iesouices anu you
have a consistent BA classilication scheme ueployeu thioughout the netwoik, it is sale
to activate the pieviously uelineu multilielu classilication liltei at euge noues PBR anu
Yeast. The liltei anu ielateu policei weie uelineu in a pievious step; all that is lelt now
is to apply the liltei in the input uiiection on all customei-lacing inteilaces:
DiffServ CoS Deployment and Verification | 487
[edit]
lab@PBR# show interfaces ge-0/0/0 unit 412
description PBR-to-Bock;
vlan-id 412;
family inet {
filter {
input mf_classify;
}
address 172.16.1.2/24;
}
The complete configuration
The vaiious paits ol the CoS conliguiation have Leen shown anu uiscusseu inuiviuually.
Heie is the complete CoS conliguiation at ingiess noue PBR, to give you a Lettei pei-
spective ol the Lig pictuie:
[edit]
lab@PBR# show class-of-service | no-more
classifiers {
dscp dscp_classify {
import default;
forwarding-class best-effort {
loss-priority high code-points 000001;
}
}
}
drop-profiles {
be_low_plp {
fill-level 50 drop-probability 5;
fill-level 80 drop-probability 50;
}
be_high_plp {
fill-level 50 drop-probability 50;
fill-level 80 drop-probability 70;
}
}
forwarding-classes {
queue 2 bronze;
}
interfaces {
ge-0/0/0 {
unit 412 {
scheduler-map er_cos_scheduler;
}
unit 1241 {
scheduler-map er_cos_scheduler;
classifiers {
dscp dscp_classify;
}
rewrite-rules {
dscp dscp_rewrite;
}
}
}
488 | Chapter 10:Class of Service
}
rewrite-rules {
dscp dscp_rewrite {
import default;
forwarding-class best-effort {
loss-priority high code-points 000001;
}
}
}
scheduler-maps {
er_cos_scheduler {
forwarding-class best-effort scheduler be_sched;
forwarding-class expedited-forwarding scheduler ef_sched;
forwarding-class network-control scheduler nc_sched;
forwarding-class bronze scheduler bronze_sched;
}
}
schedulers {
be_sched {
transmit-rate percent 50;
priority low;
drop-profile-map loss-priority low protocol any drop-profile be_low_plp;
drop-profile-map loss-priority high protocol any drop-profile be_high_plp;
}
ef_sched {
transmit-rate percent 35 exact;
buffer-size temporal 30k;
priority high;
}
nc_sched {
transmit-rate percent 5;
shaping-rate percent 20;
priority high;
}
bronze_sched {
transmit-rate percent 10 exact;
priority medium-high;
}
}
[edit]
lab@PBR# show interfaces ge-0/0/0per-unit-scheduler;
vlan-tagging;
unit 412 {
description PBR-to-Wheat;
vlan-id 412;
family inet {
filter {
input mf_classify;
}
address 172.16.1.2/24;
}
}
unit 1241 {
description PBR-to-Bock;
DiffServ CoS Deployment and Verification | 489
vlan-id 1241;
family inet {
address 10.20.130.2/24;
}
}
[edit]
lab@PBR# show firewall
policer police_bronze {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 200k;
}
then {
loss-priority high;
forwarding-class best-effort;
}
}
filter mf_classify {
term classify_ef {
from {
protocol icmp;
icmp-type [ timestamp timestamp-reply ];
}
then {
count ef_in;
forwarding-class expedited-forwarding;
accept;
}
}
term classify_bronze {
from {
protocol tcp;
port telnet;
}
then {
policer police_bronze;
count bronze_in;
forwarding-class bronze;
}
}
term else_be {
then {
forwarding-class best-effort;
accept;
}
}
}
Most ol the CoS conliguiation is common to all noues, with the exception ol inteilace
names anu the piesence ol multilielu veisus BA classilication at customei-lacing intei-
laces. Recall that T1 inteilace shaping is also in ellect at noues Bock anu Porter. The
t1-2/0/2 CoS conliguiation is uisplayeu to show the shaping conliguiation, anu the
inteilace is set loi DSCP-Laseu BA classilication anu DSCP iewiite:
490 | Chapter 10:Class of Service
[edit]
lab@Bock# show class-of-service interfaces t1-2/0/2
unit 100 {
scheduler-map er_cos_scheduler;
shaping-rate 500k;
classifiers {
dscp dscp_classify;
}
rewrite-rules {
dscp dscp_rewrite;
}
}
Verify DiffServ-Based CoS
Vith the iouteis conliguieu, it`s time to veiily that all this CoS mumLo jumLo actually
amounts to a hill ol Leans, anu Lettei yet, happy enu useis.
Vhenevei you leel that a CoS-ielateu conliguiation is not uoing what
you expecteu, it is a goou iuea to monitoi the system`s messages anu
cosd logliles while you peiloim a commit. Some misconliguiations (oi
a conliguiation that ieguiies some Lit ol missing haiuwaie to lunction
coiiectly) olten pass the commit check while geneiating a log message,
inuicating that some aspect ol the conliguiation is Leing ignoieu anu
loi what ieason.
A numLei ol opeiational moue commanus uisplay CoS conliguiation, anu moie im-
poitant, opeiational status. Most you can access with the show class-of-service
commanu:
lab@PBR> show class-of-service ?
Possible completions:
<[Enter]> Execute this command
adaptive-shaper Show trigger types and associated rate for adaptive shaper
classifier Show mapping of code point to forwarding class/loss priority
code-point-aliases Show mapping of symbolic name to code point bit pattern
drop-profile Show interpolated data points of named drop profile
forwarding-class Show mapping of forwarding class names to queue numbers
forwarding-table Show forwarding table information
fragmentation-map Show mapping of forwarding classes to fragmentation options
interface Show mapping of CoS objects to interfaces
loss-priority-map Show mapping of code point to loss priority
rewrite-rule Show mapping of forwarding class/loss priority to code point
scheduler-map Show mapping of forwarding classes to schedulers
traffic-control-profile Show traffic control profiles
virtual-channel Show virtual channel names
virtual-channel-group Show virtual channel group information
To save space, we will call upon the vaiious commanus when actually neeueu to veiily
CoS in the test netwoik; we will covei the viitual channel anu auaptive shapei-ielateu
commanus in the next section.
DiffServ CoS Deployment and Verification | 491
You will also linu that geneial liiewall anu the show interface queue commanus come
in paiticulaily hanuy when checking CoS Lehavioithe loimei Lecause liiewall lilteis
aie useu loi multilielu classilication anu to help ueLug CoS thiough match anu count
opeiations, anu the lattei Lecause the iesultant pei-gueue packet anu uiop counts pio-
viue ciitical inloimation neeueu to veiily classilication-geneial gueuing Lehavioi. The
show interface queue commanu is haiuwaie uepenuent anu might not Le availaLle on
some iouteis.
Also note that you have the ielative luxuiy ol a test Leu that, asiue liom OSPF, is
completely guiescent unless stimulateu in some way Ly usei tiallic, which is unuei youi
contiol. This makes it guite easy to conliim packet classilication anu geneial gueuing
Lehavioi anu to test the oveiall ellects ol CoS. This luxuiy is iaiely alloiueu on a pio-
uuction netwoik, anu it is why it is always a goou iuea to stage a new CoS iollout in a
piool-ol-concept test Leu wheie it is easy to valiuate anu ueLug the iesults.
Confirm general CoS configuration
Things stait at euge noue PBR, wheie conliimation ol the ieguiieu loiwaiuing classes
is peiloimeu:
lab@PBR> show class-of-service forwarding-class
Forwarding class ID Queue Policing Priority
best-effort 0 0 normal
expedited-forwarding 1 1 normal
bronze 2 2 normal
network-control 3 3 normal
All loui loiwaiuing classes aie piesent, incluuing the custom bronze class. Goou. You
next veiily CoS-ielateu inteilace paiameteis loi the coie-lacing GigaLit Etheinet intei-
lace at PBR with the show class-of-service interface commanu:
lab@PBR> show class-of-service interface ge-0/0/0.1241
Logical interface: ge-0/0/0.1241, Index: 70
Object Name Type Index
Scheduler-map er_cos_scheduler Output 21207
Rewrite dscp_rewrite dscp 26780
Classifier dscp_classify dscp 25819
The output conliims that the er_cos_scheduler map is in ellect, anu shows that the
custom dscp_classify classiliei anu dscp_rewrite iewiite taLles have Leen applieu. The
inuex numLeis aie useu inteinally when ieleiencing the vaiious taLles oi scheuulei
map instances. The makeup ol the er_cos_scheduler is now conliimeu:
lab@PBR> show class-of-service scheduler-map er_cos_scheduler
Scheduler map: er_cos_scheduler, Index: 21207
Scheduler: be_sched, Forwarding class: best-effort, Index: 54989
Transmit rate: 50 percent, Rate Limit: none, Buffer size: remainder,
Priority: low
Excess Priority: unspecified
Drop profiles:
Loss priority Protocol Index Name
492 | Chapter 10:Class of Service
Low any 45889 be_low_plp
Medium low any 1 <default-drop-profile>
Medium high any 1 <default-drop-profile>
High any 14464 be_high_plp
Scheduler: ef_sched, Forwarding class: expedited-forwarding, Index: 5877
Transmit rate: 35 percent, Rate Limit: exact, Buffer size: 30000 us,
Priority: high
Excess Priority: unspecified
Drop profiles:
Loss priority Protocol Index Name
Low any 1 <default-drop-profile>
Medium low any 1 <default-drop-profile>
Medium high any 1 <default-drop-profile>
High any 1 <default-drop-profile>
Scheduler: bronze_sched, Forwarding class: bronze, Index: 26824
Transmit rate: 10 percent, Rate Limit: exact, Buffer size: remainder,
Priority: medium-high
Excess Priority: unspecified
Drop profiles:
Loss priority Protocol Index Name
Low any 1 <default-drop-profile>
Medium low any 1 <default-drop-profile>
Medium high any 1 <default-drop-profile>
High any 1 <default-drop-profile>
Scheduler: nc_sched, Forwarding class: network-control, Index: 22188
Transmit rate: 5 percent, Rate Limit: none, Buffer size: remainder,
Priority: high
Excess Priority: unspecified
Shaping rate: 20 percent,
Drop profiles:
Loss priority Protocol Index Name
Low any 1 <default-drop-profile>
Medium low any 1 <default-drop-profile>
Medium high any 1 <default-drop-profile>
High any 1 <default-drop-profile>
The output ol the show class-of-service scheduler-map commanu contains a lot ol
golu. The vaiious highlights call out key uilleiences in the scheuulei Lehavioi loi each
loiwaiuing class. Foi example, the BE class is associateu with the two RED uiop pioliles
that aie inuexeu against packet loss piioiity. All othei loiwaiuing classes link to the
uelault RED piolile. The EF scheuulei`s high piioiity is calleu out, as is the time-Laseu
constiaint on its Lullei size.
The BR scheuulei is calleu out loi its medium-high piioiity, anu its iate-limiting thiough
use ol exact. Excess tiallic in this BR class is ieclassilieu as high-loss BE, alloiuing this
class an inuiiect way ol getting unuseu Lanuwiuth. The NC scheuulei has a 20 shap-
ing iate, which caps that gueue at 20 ol the tiansmit Lanuwiuth, even when all othei
loiwaiuing classes aie iule.
DiffServ CoS Deployment and Verification | 493
It`s ciitical to note that in this example, the only mechanism that pievents highei-
piioiity scheuuleis liom staiving lowei-piioiity scheuuleis is the iate limiting achieveu
thiough use ol eithei the exact oi the shaping-rate keywoiu. As an alteinative, you
coulu also use a liiewall-Laseu policei to pioviue the isolation neeueu Letween tiallic
classes loi a successlul DillSeiv ueployment.
The RED pioliles associateu with the BE class aie uisplayeu:
ab@PBR> show class-of-service drop-profile
Drop profile: <default-drop-profile>, Type: discrete, Index: 1
Fill level Drop probability
100 100
Drop profile: be_high_plp, Type: discrete, Index: 14464
Fill level Drop probability
50 50
80 70
Drop profile: be_low_plp, Type: discrete, Index: 45889
Fill level Drop probability
50 5
80 50
The output conliims the 100/100 setting loi the uelault uiop piolile, anu the two
custom RED pioliles iellect the ieguiieu uiop points, which uillei loi high veisus low-
loss piioiity BE tiallic. You now conliim the DSCP BA anu iewiite taLles. Foi Lievity`s
sake, we show only a poition ol the classilication taLle:
lab@PBR>show class-of-service classifier type dscp name dscp_classify
Classifier: dscp_classify, Code point type: dscp, Index: 25819
Code point Forwarding class Loss priority
000000 best-effort low
000001 best-effort high
000010 best-effort low
000011 best-effort low
. . .
The highlighteu coue calls out the custom poition ol the taLle, which uelines a high-
loss piioiity BE class coue point. Vith the Lasic components ol CoS conliguiation
conliimeu, it`s time to move on to conliim uata plane Lehavioi.
Verifying Control and Data Plane Consistency
Most ol the opeiational-moue CoS commanus shown in this chaptei have a loiwaiuing
taLle counteipait. Geneially speaking, the output ol contiol plane veisus uata plane
loiwaiuing taLle-ielateu commanus shoulu agiee. In some cases, a conliguiation may
Le iejecteu, anu as a iesult the changes aie not pusheu into the loiwaiuing taLle. Vhen
tiouLleshooting a CoS pioLlem, it`s always a goou iuea to look loi CoS-ielateu log
messages when you commit, anu to conliim that the loiwaiuing taLle state matches
the conliguiation anu ielateu contiol plane uisplays. The lollowing coue sample taken
liom PBR shows that the loiwaiuing taLle`s view ol the DSCP iewiite lunction uoes in
lact match the conliguiation:
494 | Chapter 10:Class of Service
[edit]
lab@PBR# run show class-of-service forwarding-table rewrite-rule
Rewrite table index: 26780, # entries: 4, Table type: DSCP
FC# Low bits State High bits State Medium State Medium State
Low bits High bits
0 000000 Enabled 000001 Enabled
1 101110 Enabled 101110 Enabled
2 001010 Enabled 001100 Enabled
3 110000 Enabled 111000 Enabled
The output conliims that packets placeu into gueue 0, the BE gueue, will have theii
DSCP iewiitten to Linaiy 000000 when classilieu as low loss, oi 000001 when classilieu
as high loss. The uelault DSCP classiliei suppoits loss piioiity loi the AF (now calleu
bronze) anu NC classes. Usei customization was ieguiieu loi BE loss piioiity suppoit.
The uelault settings loi gueue 1 (EF) iesult in the same maikei iegaiuless ol PLP status.
Confirm classification and queuing
Displayeu heie loi ieleience is the RPM-ielateu conliguiation loi the SLA monitoiing
client Wheat. Ve will uisplay anu analyze the actual RPM pioLe status latei in this
section:
[edit]
lab@Wheat# show services
rpm {
probe test_cos {
test icmp_timestamp_cos {
probe-type icmp-ping-timestamp;
target address 84.10.109.7;
probe-count 2;
probe-interval 1;
test-interval 1;
history-size 15;
data-size 574;
hardware-timestamp;
}
}
probe-limit 100;
}
The RPM conliguiation uelines a test calleu icmp_timestamp_cos that is owneu Ly the
test_cos entity. The taiget auuiess specilies Hops`s ge-0/0/0.3233 inteilace auuiess.
Vaiious othei paiameteis aie specilieu to contiol pioLe lieguency, test count, anu test
iepetition iate. In this case, we expect to see one pioLe geneiateu each seconu, with
two such pioLes constituting a test gioup anu a new test Leginning one seconu latei.
The seivice is conliguieu to ietain 15 histoiy samples, which given these settings, iep-
iesents appioximately 15 seconus` woith ol peiloimance uata.
The SLA pioLe iouteis suppoit timestamping within the ieal-time loiwaiuing thieau,
which is enaLleu with the hardware-timestamp keywoiu. This signilicantly uecouples
geneial contiol plane activity liom the piocessing ol the pioLe message timestamps,
theieLy olleiing signilicantly impioveu accuiacy.
DiffServ CoS Deployment and Verification | 495
No specilic conliguiation is neeueu at the pioLe seivei Lecause ICMP messages aie
ieplieu to Ly uelault; the use ol a TCP oi UDP test pioLe ieguiies a seivei conliguiation
to ensuie that a matching piocess is cieateu to listen loi incoming pioLe ieguests.
CoS is conliguieu in the test netwoik in a symmetiic, Liuiiectional
mannei. Still, it sometimes helps to think in a simplex mannei when veiilying CoS.
Once piopei Lehavioi is veiilieu in the Wheat-to-Hops uiiection, you simply peiloim
the same steps, Lut now in the opposite uiiection, to oLtain lull conliimation ol CoS
opeiation.
You Legin conliimation ol multilielu classilication at PBR Lecause Wheat is the souice
ol EF test pioLes. To ensuie a clean slate, you cleai all liiewall anu inteilace counteis
at PBR, anu the inteilace counteis at all othei noues; heie aie the commanus issueu
on PBR:
lab@PBR> clear firewall all
lab@PBR> clear interfaces statistics all
Altei a lew moments, you uisplay the liiewall counteis associateu with the
mf_classify liltei:
lab@PBR> show firewall filter mf_classify
Filter: mf_classify
Counters:
Name Bytes Packets
ef_in 56488 92
bronze_in 0 0
Policers:
Name Packets
police_bronze-classify_bronze 0
The liiewall countei anu ielateu policei output is a goou inuication that PBR is coiiectly
classilying EF tiallic. The piesence ol ICMP test pioLes is iegisteiing as EF tiallic, anu
the lack ol a Telnet session keeps the bronze class at zeio. The police_bronze policei,
which is calleu liom the classify_bronze teim, has a 0 count, inuicating that no out-
ol-piolile BR tiallic has Leen ieclassilieu as BE. Given that theie is cuiiently no tiallic
in the BR class, this too is in keeping with expectations.
To test the BR classilication, a Telnet session is openeu anu suLseguently closeu, Le-
tween Wheat anu Hops:
lab@Wheat# run telnet 84.10.109.7
Trying 84.10.109.7...
Connected to 84.10.109.7.
Escape character is '^]'.
hops (ttyp0)
login: lab
Password:
--- Junos 10.4R1.9built 2010-10-13 04:50:17 UTC
Multifield classification.
496 | Chapter 10:Class of Service
lab@hops> exit
Connection closed by foreign host.
[edit]
Coiiect multilielu classilication loi the BR class is conliimeu Ly ieuisplaying the coun-
teis associateu with the multilielu classiliei:
lab@PBR> show firewall | match bronze
bronze_in 1986 35
police_bronze-classify_bronze 0
The bronze_in countei coiiectly iellects the geneiateu Telnet tiallic, which conliims
multilielu classilication loi BR tiallic.
Theie is no liiewall countei loi the BE class in this example. To veiily
coiiect BE classilication, anu loi that mattei, geneial BA classilication among all noues
in the loiwaiuing path Letween Wheat anu Hops, you examine egiess gueue statistics
using the show interfaces queue commanu. In this example, the commanu is iun on
the customei-lacing inteilace ol egiess noue Yeast. OLseiving the expecteu gueue sta-
tistics heie goes a long way towaiu conliiming that netwoik-wiue BA classilication is
woiking coiiectly.
Beloie looking at the gueue stats, we stimulate the BE class with some iegulai (not
timestamp ielateu) pings liom Wheat to Hops. Recall that except loi the Lackgiounu
OSPF, this netwoik is otheiwise completely iule, which makes it easiei to coiielate test
tiallic to gueuing statistics:
[edit]
lab@Wheat# run ping 84.10.109.7 rapid count 10
PING 84.10.109.7 (84.10.109.7): 56 data bytes
!!!!!!!!!!
--- 84.10.109.7 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.972/20.469/32.392/7.602 ms
Heie aie the egiess gueuing statistics loi the customei-lacing inteilace at ioutei Yeast:
lab@Yeast# run show interfaces queue ge-0/0/0.3233
Logical interface ge-0/0/0.3233 (Index 69) (SNMP ifIndex 41)
Forwarding classes: 8 supported, 4 in use
Egress queues: 8 supported, 4 in use
Burst size: 0
Queue: 0, Forwarding classes: best-effort
Queued:
Packets : 10 0 pps
Bytes : 1020 0 bps
Transmitted:
Packets : 10 0 pps
Bytes : 1020 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
BA classification.
DiffServ CoS Deployment and Verification | 497
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 0 0 pps
RED-dropped bytes : 0 0 bps
Low : 0 0 bps
Medium-low : 0 0 bps
Medium-high : 0 0 bps
High : 0 0 bps
Queue: 1, Forwarding classes: expedited-forwarding
Queued:
Packets : 130 0 pps
Bytes : 82160 5000 bps
Transmitted:
Packets : 130 0 pps
Bytes : 82160 5000 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 0 0 pps
RED-dropped bytes : 0 0 bps
Low : 0 0 bps
Medium-low : 0 0 bps
Medium-high : 0 0 bps
High : 0 0 bps
Queue: 2, Forwarding classes: bronze
Queued:
Packets : 36 0 pps
Bytes : 2686 0 bps
Transmitted:
Packets : 36 0 pps
Bytes : 2686 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 0 0 pps
RED-dropped bytes : 0 0 bps
Low : 0 0 bps
Medium-low : 0 0 bps
Medium-high : 0 0 bps
High : 0 0 bps
Queue: 3, Forwarding classes: network-control
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
498 | Chapter 10:Class of Service
Medium-high : 0 0 pps
High : 0 0 pps
RED-dropped bytes : 0 0 bps
Low : 0 0 bps
Medium-low : 0 0 bps
Medium-high : 0 0 bps
High : 0 0 bps
The uisplay is long, Lut mostly iepetitive in that the same inloimation is iepeateu loi
each uelineu loiwaiuing class. The commanu output uisplays the numLei ol Lytes/
packets gueueu anu tiansmitteuany uilleiences in these counts inuicate some type
ol uiop. Tail anu RED-inuuceu uiops aie each counteu, allowing you to ueteimine the
natuie ol any uiops that happen to occui.
The sample output shows that no uiops have occuiieu, anu it iellects that the 10 oi-
uinaiy ICMP packets (non-timestamp-ielateu) weie classilieu as BE, that ongoing tial-
lic is Leing tallieu as EF (the RPM pioLes), anu that 36 BR packets have Leen classilieu
(the Telnet session). The NC gueue is shown at zeio, which is expecteu given that OSPF
is not actively senuing hellos on the Hopslacing inteilace. These iesults show that initial
multilielu classilication at the euge is coiiectly conveyeu among all noues in the path
via BA classilication.
Confirm that all this CoS stuff actually does something
To this point the vaiious opeiational moue commanus have ietuineu expecteu iesults,
which imply that CoS is coiiectly conliguieu anu is up anu uoing its thing. But how
can you ieally piove the Lenelit, especially when lacking exteinal packet geneiation
eguipment?
The use ol highly accuiate RPM timestamp pioLes, comLineu with the ielatively low-
speeu link (the 500 KLps shapeu Letween Bock anu Porter), shoulu allow a iepeataLle
uemonstiation ol IP CoS Lenelits.
No CoS benchmark
You Legin Ly oLtaining a no CoS netwoik Laseline. Latei, when CoS is ieenaLleu, the
Leloie anu altei iesults allow you to accuiately gauge what ellects CoS has in the cuiient
test Leu. You iemove CoS Ly stiipping uown the class-of-service stanza at Bock anu
Porter to leave only the 500 KLps shaping iate. RememLei, a CoS chain is only as stiong
as the weakest link, so iemoving CoS-awaie packet hanuling at the 500 KLps choke
point shoulu latally weaken the entiie chain. This actually pioviues an inteiesting
uemonstiation ol how a consistent PHB in a|| nodcs is ciitical to oveiall CoS success
a single misconliguieu ioutei can iuin CoS peiloimance on an enu-to-enu Lasis.
The mouilieu CoS conliguiation is uisplayeu at Bock:
[edit]
lab@Bock# show class-of-service
interfaces {
t1-2/0/2 {
DiffServ CoS Deployment and Verification | 499
unit 100 {
shaping-rate 500k;
}
}
}
Meanwhile, Lack at Wheat, connectivity is conliimeu anu the RPM seivice is tempoiaiily
ueactivateu to ensuie that a liesh histoiy is cieateu:
[edit]
lab@Wheat# run ping 84.10.109.7 rapid count 10
PING 84.10.109.7 (84.10.109.7): 56 data bytes
!!!!!!!!!!
--- 84.10.109.7 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.884/22.581/39.944/9.170 ms
[edit]
lab@Wheat# deactivate services
[edit]
lab@Wheat# commit
An FTP tianslei is staiteu Letween Porter anu Bock. Once the tianslei Legins, the RPM
seivice is activateu at Wheat:
[edit]
lab@Porter# run ftp 10.10.12.3
Connected to 10.10.12.3.
220 Bock FTP server (Version 6.00LS) ready.
Name (10.10.12.3:lab): lab
331 Password required for lab.
Password:
230 User lab logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> mget ju*
mget junos-jseries-10.0R2.8-domestic.tgz? y
200 PORT command successful.
150 Opening BINARY mode data connection for 'junos-jseries-10.0R2.8-domestic.tgz'
(38563456 bytes).
0% 44888 14:19 ETA
Vith the tianslei unueiway, the RPM seivice is ieactivateu:
[edit]
lab@Wheat# activate services
[edit]
lab@Wheat# commit
The pioLes aie alloweu to iun loi 15 to 30 seconus to get some statistical accuiacy.
The RPM histoiy is uisplayeu at Wheat:
[edit]
lab@Wheat# run show services rpm history-results
Owner, Test Probe received Round trip time
500 | Chapter 10:Class of Service
test_cos, icmp_timestamp_cos Mon Oct 29 00:58:53 2010 266417 usec
test_cos, icmp_timestamp_cos Mon Oct 29 00:58:54 2010 265010 usec
test_cos, icmp_timestamp_cos Mon Oct 29 00:58:55 2010 237000 usec
. . .
test_cos, icmp_timestamp_cos Mon Oct 29 00:59:08 2010 268167 usec
test_cos, icmp_timestamp_cos Mon Oct 29 00:59:09 2010 171237 usec
The uisplay conliims some pietty long iounu-tiip times, some as long as 265 millisec-
onus. Given that the one-way taiget uelay loi Voice ovei IP is only 150 milliseconus,
it`s sale to say theie is no joy loi IP telephony useis in the cuiient netwoik.
You can uisplay uetails aLout each pioLe, along with an aveiage loi all completeu tests,
using the show services rpm probe-results commanu:
[edit]
lab@Wheat# run show services rpm probe-results
Owner: test_cos, Test: icmp_timestamp_cos
Target address: 84.10.109.7, Probe type: icmp-ping-timestamp,
Test size: 2 probes
Probe results:
Response received, Mon Oct 29 00:59:17 2010,
Client and server hardware timestamps
Rtt: 300236 usec, Round trip jitter: 283526 usec,
Round trip interarrival jitter: 95059 usec
Results over current test:
Probes sent: 1, Probes received: 0, Loss percentage: 100
. . .
Results over all tests:
Probes sent: 53, Probes received: 49, Loss percentage: 7
Measurement: Round trip time
Samples: 49, Minimum: 16710 usec, Maximum: 300236 usec,
Average: 199529 usec, Peak to peak: 283526 usec, Stddev: 81768 usec
Measurement: Positive round trip jitter
Samples: 25, Minimum: 421 usec, Maximum: 283526 usec,
Average: 82333 usec, Peak to peak: 283105 usec, Stddev: 75539 usec
Measurement: Negative round trip jitter
Samples: 23, Minimum: 1407 usec, Maximum: 280411 usec,
Average: 88507 usec, Peak to peak: 279004 usec, Stddev: 71908 usec
The highlights call out that some pioLes aie Leing lost, anu that the aveiage iounu-tiip
uelay is moie than 199 milliseconus. Note that aveiage one-way jittei is iathei laige at
some S2 milliseconus.
The CoS benchmark
OK, uium ioll, please.a lot ol woik has leu up to this point, anu now it is time loi the
CoS iuLLei to meet the ioau, as it weie. You iestoie the CoS conliguiation at Bock anu
Porter, anu again ueactivate the RPM seivice at Wheat to ieset loi a new test.
A new FTP session is staiteu Letween Porter anu Bock:
[edit]
lab@Porter# run ftp 10.10.12.3
Connected to 10.10.12.3.
220 Bock FTP server (Version 6.00LS) ready.
DiffServ CoS Deployment and Verification | 501
. . .
mget junos-jseries-10.0R2.8-domestic.tgz? y
200 PORT command successful.
150 Opening BINARY mode data connection for 'junos-jseries-10.0R2.8-domestic.tgz'
(38563456 bytes).
0% 31856 40:12 ETA
Vith the new FTP session unueiway, the RPM seivice is again activateu at Wheat:
[edit]
lab@Wheat# activate services
[edit]
lab@Wheat# commit
As Leloie, we again wait 30 seconus oi so to allow some RPM statistics to accumulate.
Altei a long 30 seconus, the iesults aie uisplayeu:
[edit]
lab@Wheat# run show services rpm history-results
Owner, Test Probe received Round trip time
test_cos, icmp_timestamp_cos Mon Oct 29 01:08:52 2010 17236 usec
test_cos, icmp_timestamp_cos Mon Oct 29 01:08:53 2010 20896 usec
. . .
test_cos, icmp_timestamp_cos Mon Oct 29 01:09:06 2010 17769 usec
test_cos, icmp_timestamp_cos Mon Oct 29 01:09:07 2010 18294 usec
test_cos, icmp_timestamp_cos Mon Oct 29 01:09:08 2010 19068 usec
Vell, the histoiy iesults aie lai, lai Lettei than oLseiveu in the no-CoS Lenchmaik. The
iounu-tiip uelays now aveiage only 1S milliseconus, as opposeu to the 200- iesult
oLseiveu with no CoS. Once again, pioLe uetails aie uisplayeu:
[edit]
lab@Wheat# run show services rpm probe-results
Owner: test_cos, Test: icmp_timestamp_cos
Target address: 84.10.109.7, Probe type: icmp-ping-timestamp,
Test size: 2 probes
Probe results:
Response received, Mon Oct 29 01:09:12 2010,
Client and server hardware timestamps
Rtt: 24557 usec, Round trip jitter: 13326 usec,
Round trip interarrival jitter: 8125 usec
Results over current test:
Probes sent: 2, Probes received: 2, Loss percentage: 0
Measurement: Round trip time
Samples: 2, Minimum: 24557 usec, Maximum: 37883 usec,
Average: 31220 usec, Peak to peak: 13326 usec, Stddev: 6663 usec
. . .
Results over all tests:
Probes sent: 58, Probes received: 58, Loss percentage: 0
Measurement: Round trip time
Samples: 58, Minimum: 16455 usec, Maximum: 44654 usec,
Average: 22455
usec, Peak to peak: 28199 usec, Stddev: 7167 usec
Measurement: Positive round trip jitter
Samples: 28, Minimum: 506 usec, Maximum: 26628 usec, Average: 8293 usec,
502 | Chapter 10:Class of Service
Peak to peak: 26122 usec, Stddev: 8134 usec
Measurement: Negative round trip jitter
Samples: 29, Minimum: 7 usec, Maximum: 25318 usec, Average: 7781 usec,
Peak to peak: 25311 usec, Stddev: 6889 usec
The pioLe uetails conliim that CoS has maue a uiamatic impact on netwoik peiloim-
ance, at least when congestion is piesent anu you aie a memLei ol the EF class! The
aveiage iounu-tiip time is 22 milliseconus anu the aveiage one-way jittei is now only
S milliseconus. A guick look at Bock`s T1 inteilace stats conliims that all uiops aie
conlineu to the BE class, anu that the uiops stem liom the low-loss piioiity RED piolile:
lab@Bock# run show interfaces queue t1-2/0/2.100
Logical interface t1-2/0/2.100 (Index 69) (SNMP ifIndex 39)
Forwarding classes: 8 supported, 8 in use
Egress queues: 8 supported, 8 in use
Burst size: 0
Queue: 0, Forwarding classes: best-effort
Queued:
Packets : 32519 0 pps
Bytes : 48570458 0 bps
Transmitted:
Packets : 30047 0 pps
Bytes : 44852756 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 2472 0 pps
Low : 2472 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High 0 0 pps
Note that the total gueueu veisus tiansmitteu packet counteis loi the BE class uillei
Ly the same numLei as uisplayeu unuei RED uiops. This conliims that RED is kicking
in when the BE gueue Legins to lill. The lack ol tail uiops implies that the TCP-Laseu
FTP souice coiiectly senseu the loss as an inuication ol congestion, anu Legan to slow
uown the iate ol tiallic Ly ieuucing the winuow size.
Compaiing pie- anu post-CoS iesults leaves little uouLt that ]unos soltwaie CoS woiks.
The only guestion that iemains is Vhy aie you still heie ieauing this, when you shoulu
Le auuing CoS to youi netwoik now?
DiffServ Deployment Summary
This section uemonstiateu how ]unipei Netwoiks iouteis aie conliguieu to pioviue
enu-to-enu CoS Laseu on the DillSeiv mouel. This involves the use ol multilielu clas-
silication at the netwoik`s euges anu custom BA classilication in the coie to convey loss
piioiity loi the BE class.
The scenaiio also uemonstiateu thiee uilleient appioaches to scheuuling, two ol which
weie Laseu on the piioiity-Laseu scheuules anu one on the weight-Laseu scheuulei.
DiffServ CoS Deployment and Verification | 503
Ve uemonstiateu the use ol shaping, policing, anu iate limiting to pieseive class iso-
lation, as well as the opeiational moue commanus that allow you to conliim piopei
CoS Lehavioi anu opeiation. Ve pioveu that the ]unos soltwaie CoS solution woiks
thiough the use ol exteinal LSA monitoiing pioLes that show a cleai Lenelit to the CoS
conliguiation when link congestion occuiieu.
The next section uetails specilic CoS capaLilities that aie uesigneu to enhance intei-
woiking with Fiame Relay. You shoulu make suie you aie comloitaLle with the con-
liguiation anu conliimation examples useu in this section Leloie pioceeuing.
Adaptive Shapers and Virtual Channels
This section locuses on SRX anu ]-seiies specilic CoS capaLilities that aie uesigneu to
woik with Fiame Relay. The viitual channel anu auaptive shaping leatuies help to
optimize Fiame RelayLaseu tianspoit. Note that cuiiently you cannot comLine the
lunctionality ol an auaptive shapei with that ol a viitual channel.
Configure Adaptive Shaping
Recall that Bock anu Porter aie connecteu via a 0 CIR Fiame Relay seivice teiminating
in a 500 KLps poit. Vith the newly auueu DillSeiv-Laseu CoS inliastiuctuie now in
place, the iuea ol a 0 CIR seivice has Leen ievisiteu. The iesult is a uecision to pay extia
loi a guaianteeu CIR ol 256 KLps, with the aLility to Luist to poit speeu via an EIR ol
2++ KLps (CIR - EIR = poit speeu).
Simply conliguiing a scheuulei oi shapei that allows the ioutei to senu at maximum
speeu, all the time, is pioLlematic Lecause uuiing netwoik congestion only the CIR
tiallic is guaianteeu loi ueliveiy. Iueally, you want to senu at the EIR iate on|y when
the netwoik is not congesteu, anu then lall Lack to the CIR when congestion is uetecteu,
in an elloit to ensuie that congestion-inuuceu uiscaius uo not negate youi CoS SLAs.
This capaLility is exactly what auaptive shaping pioviues.
The conliguiations at Bock anu Porter aie upuateu to suppoit auaptive shaping. The
mouilieu conliguiation at Bock is shown:
[edit class-of-service]
lab@Bock# show adaptive-shapers
becn_shaper {
trigger becn shaping-rate 256k;
}
[edit class-of-service]
lab@Bock# show interfaces t1-2/0/2
unit 100 {
scheduler-map er_cos_scheduler;
adaptive-shaper becn_shaper;
shaping-rate 500k;
classifiers {
504 | Chapter 10:Class of Service
dscp dscp_classify;
}
rewrite-rules {
dscp dscp_rewrite;
}
}
The changes to the conliguiation aie highlighteu, anu they show the uelinition ol an
auaptive shapei calleu becn_shaper. The auaptive shapei is set to tiiggei on ieceipt ol
a set BECN Lit, at which point the scheuulei Legins to shape to 256 KLps. This iate
matches the seivice`s CIR, which pievents uiscaius anu the iesulting impact to youi
CoS SLA. Vhen the last liame ieceiveu has a cleaieu BECN, the inteilace Legins to
scheuule Lack into the 500 KLps iate.
Heie, use the show class-of-service interface anu show class-of-service adaptive-
shaper commanus to veiily auaptive shaping:
[edit class-of-service]
lab@Bock# run show class-of-service adaptive-shaper
Adaptive shaper: becn_shaper, Index: 44416
Trigger type Shaping rate
BECN 256000 bps
[edit class-of-service]
lab@Bock# run show class-of-service interface t1-2/0/2.100
Logical interface: t1-2/0/2.100, Index: 69
Shaping rate: 500000
Object Name Type Index
Scheduler-map er_cos_scheduler Output 21207
Adaptive-shaper becn_shaper 44416
Rewrite dscp_rewrite dscp 26780
Classifier dscp_classify dscp 25819
The uisplays conliim that the auaptive shapei is coiiectly piogiammeu anu placeu into
ellect on Bock`s Fiame Relay inteilace.
Virtual Channels
Viitual channels aie useu to ensuie that a cential site with a high Lanuwiuth connection
uoes not oveiiun iemote sites that access the netwoik at slowei iates. Figuie 10-17
illustiates a typical huL anu spoke Fiame Relay topology. The heauguaiteis site has a
signilicantly highei access iate when compaieu to the Lianch ollice spokes.
The key point ol Figuie 10-17 is that the cential site teiminates at a T1 switch poit in
the seivice pioviuei`s netwoik, while the iemote sites aie teiminateu at signilicantly
lowei speeus. In a Fiame Relay seivice, the aLsolute limit on uata tianslei iate is the
logical poit speeu, which can Le lowei than the tiansmission link`s physical Lit iate;
loi example, Site 1 is using a Fiactional T1 (FT1) ciicuit to access the pioviuei, Lut
pays loi only 12S KLps ol poit speeu anu can use only 12S KLps ol the T1`s capacity.
Regaiuless ol CIR iate oi the state ol netwoik congestion, Site 1 anu Site 2 aie physically
limiteu to the ieception ol no moie that 12S/256 KLps ol tiallic, iespectively.
Adaptive Shapers and Virtual Channels | 505
The pioLlem, il not alieauy oLvious, is that the cential site can easily Luist to lull T1
iates, anu il these Luists aie ol any appieciaLle uuiation, theie will Le massive loss uue
to Lullei oveillow in the netwoik. This causes TCP-Laseu souices to sense congestion
anu thiottle Lack. Il not coiiecteu, this can leau to an ongoing Loom/Lust cycle as the
souices iamp up, sense loss, anu then iamp Lack uown, iesulting in uiminisheu
thioughput anu highei latency uue to Lulleiing within the netwoik. This is moie than
a simple issue ol not knowing each viitual channel`s CIR, as the topology shown in
Figuie 10-17 may well Le Laseu on a 0 CIR seivice. The issue is simply one ol mis-
matcheu poit speeu ovei a netwoik that uoes ollei extensive Lulleiing.
A viitual channel gioup is a collection ol viitual channels that aie applieu to a logical
inteilace. Each viitual channel within the gioup has its own gueues anu scheduler-
map, anu each can Le shapeu to a iate that is less than the physical inteilace speeu. In
some cases, you may choose to shape a viitual channel Laseu on CIR, Lut in most cases
the shaping iate is set to the lessei ol the two poit speeus. Vhen not shapeu, each
viitual channel can Luist to lull inteilace speeu, anu when multiple unshapeu viitual
channels aie active, they each get a iounu-ioLin laii shaie ol the total physical inteilace
Lanuwiuth. Theie is no piioiity scheuuling Letween viitual channels.
Fiiewall lilteis aie useu to uiiect tiallic to the coiiect viitual channel Laseu on some
match conuitionloi example, the uestination auuiess. Unmatcheu tiallic is sent to a
uelault viitual channel. This ieguiies that one viitual channel Le uesignateu as the
uelault within each viitual channel gioup.
Iigurc 10-17. j-scrics virtua| channc|s
506 | Chapter 10:Class of Service
Configure virtual channels
The lack ol Fiame Relay switching iesults in the neeu to use Porter twiceonce as
Site 1 using DLCI 100 anu again as Site 2 with DLCI 200. This is why Figuie 10-17
shows the same lo0 auuiess loi Loth Sites 1 anu 2. Because theie is no viitual channel
conliguiation at iemote sites, this example locuses on Bock, the cential site ioutei. In
this example, we uo not Lothei with a viitual ioutei (VR) instance loi the seconu con-
nection liom Porter to Bock; insteau, a new logical unit is auueu to the t1-2/0/2 inteilace
with a unigue host ID, anu the oiiginal IP auuiess is ieassigneu unuei unit 100 to match
the auuiessing shown in Figuie 10-17:
[edit]
lab@Porter# show interfaces t1-2/0/2
description Porter-to-Bock;
per-unit-scheduler;
encapsulation frame-relay;
unit 100 {
dlci 100;
family inet {
address 10.10.10.1/24;
}
}
unit 200 {
dlci 200;
family inet {
address 10.10.10.2/24;
}
}
The auuiessing iesults in a uuplicate suLnet shaieu Letween units 100 anu 200, Lut
this is not a pioLlem heie:
[edit]
lab@Porter# run show ospf neighbor
Address Interface State ID Pri Dead
10.10.8.2 ge-0/0/1.2332 Full 10.30.1.1 128 31
10.10.10.1 t1-2/0/2.100 Full 10.10.12.3 128 31
10.10.10.1 t1-2/0/2.200 Full 10.10.12.3 128 30
[edit]
lab@Porter# run show route 10.10.10/24
inet.0: 14 destinations, 16 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/24 *[Direct/0] 00:01:46
> via t1-2/0/2.200
[Direct/0] 00:01:46
> via t1-2/0/2.100
[OSPF/10] 00:01:45, metric 65
> via t1-2/0/2.100
10.10.10.1/32 *[OSPF/10] 00:01:45, metric 65
> via t1-2/0/2.200
via t1-2/0/2.100
Adaptive Shapers and Virtual Channels | 507
10.10.10.2/32 *[Local/0] 00:01:46
Local via t1-2/0/2.100
10.10.10.3/32 *[Local/0] 00:01:46
Local via t1-2/0/2.200
The iesult is OSPF aujacencies ovei Loth the 100 anu 200 logical units anu two egual
cost ioutes to Bock`s IP auuiess. Things aie moie inteiesting at Bock, wheie a multipoint
Fiame Relay inteilace is uelineu to cieate the logical connectivity shown in
Figuie 10-17:
[edit]
lab@Bock# show interfaces t1-2/0/2
description Bock-to-porter;
per-unit-scheduler;
dce;
encapsulation frame-relay;
unit 100 {
multipoint;
family inet {
address 10.10.10.3/24 {
multipoint-destination 10.10.10.1 dlci 100;
multipoint-destination 10.10.10.2 dlci 200;
}
}
}
The mouilieu conliguiation maps two locally uelineu DLCIs on the same logical in-
teilace to each associateu IP auuiess; DLCI 100 leaus to Site 1`s 10.10.10.1 auuiess anu
DLCI 200 maps to the auuiess ol Site 2 anu the 10.10.10.2 auuiess. Pei-unit scheuuling
must Le enaLleu on the physical inteilace to suppoit scheuuling into each viitual
channel.
At liist glance, the show route commanu at Bock inuicates that all tiallic loi the
10.10.10/2+ suLnet will use the same link, as inuicateu Ly the aLsence ol logical unit
200:
[edit]
lab@Bock# run show route 10.10.10.2
inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/24 *[Direct/0] 00:13:24
> via t1-2/0/2.100
[OSPF/10] 00:13:12, metric 130
> to 10.10.10.2 via t1-2/0/2.100
The ioute to 10.10.10.2 seems to inuicate that Bock plans to use the wiong DLCI, given
that DLCI 200 maps to Site 2, not Site 3. The loiwaiuing taLle, howevei, coiiectly
iellects the coiiect IP-to-DLCI mapping as conliguieu unuei the multipoint Fiame
Relay inteilace:
[edit]
lab@Bock# run show route forwarding-table destination 10.10.10.1
508 | Chapter 10:Class of Service
Routing table: inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
10.10.10.1/32 dest 0 dlci: 100 ucst 334 5 t1-2/0/2.100
[edit]
lab@Bock# run show route forwarding-table destination 10.10.10.2
Routing table: inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
10.10.10.2/32 dest 0 dlci: 200 ucst 336 1 t1-2/0/2.100
Vith the Fiame Relay aspects conliimeu, you move on to the viitual channel
conliguiation:
[edit class-of-service]
lab@Bock# show virtual-channels
site1_default;
site2;
Two viitual channels aie uelineu, one loi each iemote site. Heie, Site 1 is set as the
uelault viitual channel. Tiallic that is iouteu out the logical inteilace to which the
viitual channel gioup is applieu will uelault to the viitual channel loi Site 1, unless
uiiecteu via a liiewall liltei to Site 2. The viitual channel gioup conliguiation is
uisplayeu:
[edit class-of-service]
lab@Bock# show virtual-channel-groups
er_vc_group {
site1_default {
scheduler-map er_cos_scheduler;
shaping-rate 128k;
default;
}
site2 {
scheduler-map er_cos_scheduler;
shaping-rate 256k;
}
}
A viitual channel gioup conliguiation links multiple viitual channel uelinitions to-
gethei loi application to a logical inteilace. Heie, the er_vc_group conliguiation links
the site1 anu site2 uelinitions, much like a scheduler-map links multiple scheuulei
policies. Vhen applieu to a logical inteilace, eight gueues aie cieateu loi each viitual
channel associateu with the gioup, anu a scheduler-map is useu to contiol scheuuling
into each set ol pei-viitual-channel gueues. This example shapes each viitual channel
to the iemote site`s poit speeu, Lut il uesiieu, some viitual channels can Le lelt unshapeu
to allow Luisting up to physical inteilace speeu.
The viitual channel gioup is applieu to an inteilace, at the logical unit level. You will
not Le aLle to commit the conliguiation unless you iemove any auaptive shaping,
shaping, oi scheduler-map conliguiation on the same logical unit:
Adaptive Shapers and Virtual Channels | 509
[edit class-of-service]
lab@Bock# show interfaces t1-2/0/2
unit 100 {
virtual-channel-group er_vc_group;
classifiers {
dscp dscp_classify;
}
rewrite-rules {
dscp dscp_rewrite;
}
}
The linal step in the viitual channel conliguiation is the uelinition ol the liltei that
uiiects tiallic to the coiiect viitual channel, wheie it is in tuin shapeu accoiuing to the
iemote site`s poit speeu. Recall that one viitual channel in each gioup must Le uesig-
nateu the uelault viitual channel, which means it`s useu when no explicit viitual chan-
nel mapping is lounu. A woiking viitual channel mapping liltei is shown at Bock:
[edit]
lab@Bock# show firewall
filter er_vc_select {
term select_site2 {
from {
destination-address {
10.10.10.2/32;
}
}
then {
virtual-channel site2;
accept;
}
}
term default_to_site1 {
then {
virtual-channel site1_default;
accept;
}
}
}
The er_vc_select liltei matches on packets auuiesseu to Site 2 anu uiiects them to the
scheuulei/shapei associateu with the site2 viitual channel. Any tiallic not matcheu Ly
the select_site2 teim is matcheu Ly the default_to_site1 teim, which iesults in a
mapping to the uelault viitual channel. The er_vc_select liltei is placeu into seivice in
the output uiiection:
[edit]
lab@Bock# show interfaces t1-2/0/2 unit 100 family inet filter
output er_vc_select;
To conliim that youi viitual channel conliguiation is active on a given inteilace, use
the show class-of-service interface commanu:
[edit]
lab@Bock# run show class-of-service interface t1-2/0/2.100
510 | Chapter 10:Class of Service
D
o
Logical interface: t1-2/0/2.100, Index: 70
Object Name Type Index
Virtual-channel-group er_vc_group 55210
Rewrite dscp_rewrite dscp 26780
Classifier dscp_classify dscp 25819
The show class-of-service virtual-channel-group commanu conliims the uetails ol
er_vc_group:
[edit]
lab@Bock# run show class-of-service virtual-channel-group
Virtual channel group: er_vc_group, Index: 55210
Virtual channel: site1_default
Scheduler map: er_cos_scheduler
Shaping rate : 128000 bps
Virtual channel: site2
Scheduler map: er_cos_scheduler
Shaping rate : 256000 bps
Cuiiently, you cannot oLtain pei-viitual-channel gueuing statistics liom the CLI. The
output ol the show interfaces queue t1-2/0/2.100 commanu uisplays the aggiegate
packet counts loi all viitual channels in ellect on the inteilace.
Adaptive Shaping and Virtual Channel Summary
This section uemonstiateu the conliguiation anu opeiational analysis ol the SRX- anu
]-seiies-specilic auaptive shapei anu viitual channel leatuies. The loimei allows uy-
namic switching Letween two shapeis, one Laseu on the seivice`s CIR anu anothei on
the EIR, Laseu on the congestion state ol the netwoik, as signaleu Ly ieceiveu BECN
Lits. By senuing at oi Lelow the CIR uuiing peiious ol netwoik congestion, you avoiu
loss, anu when the congestion cleais, you aie aLle to senu at the EIR iate with a high
pioLaLility ol ueliveiy, given the lack ol congestion.
The viitual channel leatuie is uesigneu to allow a cential site ioute with a high-speeu
attachment to shape into inuiviuual viitual channels, with each such viitual channel
uimensioneu accoiuing to the iemote site`s poit speeu (oi CIR). The goal ol this leatuie
is to pievent Lullei oveiiun anu loss that can occui when a site with a high-speeu access
iate senus to a iemote site that is attacheu at a much slowei speeu.
Conclusion
IP CoS is an enaLling lactoi loi many value-auueu seivices, oi a cost-ellective convei-
gence onto a single netwoik inliastiuctuie. Even though Lanuwiuth may Le ielatively
cheap anu links always seem to get lastei, you can still ueploy CoS to ensuie that you
get the most ol whatevei Lanuwiuth youi netwoik has to woik with. All ]unipei Net-
woiks iouteis suppoit a ioLust anu piactical set ol CoS capaLilities that, given the
geneial uesign ol ]unipei piouucts, can Le enaLleu in any piouuction netwoik without
conceins ol peiloimance uegiauation oi unpieuictaLle Lehavioi.
Conclusion | 511
The lutuie is IP-Laseu, anu moie anu moie seivices aie Leing auapteu to IP tianspoit
each uay. By ueploying an ellective CoS solution eaily, you gain a competitive
auvantage, now anu in the lutuie, Lecause you will linu you can conliuently ioll out
new anu evei-moie-uemanuing applications, knowing that youi netwoik will make the
most ol its iesouices to uelivei the goous that mattei most.
Exam Topics
Ve examineu the lollowing Enteipiise Exam Topics in this chaptei:
DesciiLe the uses ol CoS.
Explain CoS piocessing on ]unos iouteis.
Iuentily the ways tiallic can Le classilieu.
Explain the puipose ol BAs.
Explain the use ol policeis.
DesciiLe how tiallic is mappeu to gueues.
Conliguie the mapping ol loiwaiuing classes to gueues.
Explain the iole ol a scheuulei.
Conliguie a scheuulei to seivice gueues Laseu on a CoS uesign.
Monitoi a CoS implementation.
Conliguie BA anu multilielu classilication.
Congestion management anu avoiuance.
Coue point iewiiting.
Rate-limiting with shaping, policing, oi Loth.
Auaptive shapeis anu viitual channels.
Chapter Review Questions
1. Vhich IP CoS appioach ieguiies signaling to ieseive iesouices?
A. IP ToS
B. IntSeiv
C. DillSeiv
D. ATM
2. In the DillSeiv aichitectuie, what is a BA?
A. A seguence ol packets with a shaieu maiking, ciossing a given link
B. The collective Lehavioi ol all noues in the uomain
512 | Chapter 10:Class of Service
C. The act ol aggiegating multiple ieseivations into a single, laigei one, loi
scalaLility
D. None ol the aLove
3. How uo you convey packet loss piioiity to a uownstieam noue?
A. By implementing the same multilielu classilieis as useu oiiginally at the ingiess
B. This is not possiLle Lecause the IP heauei uoes not suppoit a loss-piioiity llag
C. You must ieclassily all packets with high loss piioiity into a loiwaiuing class
ieseiveu loi that puipose
D. Use a BA iewiite taLle with a matching BA classiliei
+. Vhich ol the lollowing is tiue?
A. On the ]-seiies, stiict-high anu high aie the same piioiity
B. On the M-seiies, stiict-high is a sepaiate piioiity
C. You must use the exact option with a stiict-high gueue to pievent staivation
D. Policing shoulu Le useu when stiict-high is set, especially on the ]-seiies
5. Vhat is the puipose ol the shaping-rate statement in the lollowing coue snippet?
test_sched {
transmit-rate percent 5;
shaping-rate percent 20;
priority high;
}
A. It ensuies that this gueue cannot staive othei gueues ol theii conliguieu weight
B. It limits how much tiallic this gueue can senu, even when all othei gueues aie
iule
C. It shapes the tiallic alloweu Ly the tiansmit iate so that at least 20 ol the
packets aie not clumpeu
D. This is useu in auaptive shaping, in oiuei to set the maximum tiansmit iate
when the netwoik is not congesteu
6. Vhen committing a CoS conliguiation, you notice the lollowing log message.
Vhat uoes it mean?
Oct 30 05:39:15 Bock cosd[1071]: COSD_TX_QUEUE_RATES_TOO_HIGH: Unable to apply
scheduler map af-sched to interface t1-2/0/0: sum of scheduler transmission
rates exceeds interface shaping or transmission rate
A. Theie is a pioLlem in the conliguiation anu the uelault settings aie in ellect
B. Theie is a pioLlem in the conliguiation, causing it to lail commit
C. Theie is a pioLlem in the conliguiation; the soltwaie auapts the conliguiation
to meet the unueilying capaLility
D. The eiioi inuicates that the sum ol the assigneu weights in the scheduler-
map uiu not egual 100
Chapter Review Questions | 513
7. Consiuei the CoS conliguiation at PBR in the DillSeiv scenaiio, as shown in Fig-
uie 10-16, anu select the Lest option:
A. Each logical inteilace on ge-0/0/0 can senu up to 1 G
B. Vhen Loth logical inteilaces aie active, each gets only 50 MLps
C. Both A anu B
D. None ol the aLove
S. Relei to the output pioviueu anu select the Lest answei:
[edit class-of-service drop-profiles test]
lab@PBR# show
fill-level 50 drop-probability 0;
fill-level 70 drop-probability 10;
fill-level 80 drop-probability 20;
fill-level 90 drop-probability 30;
A. Between 70 anu S0 lill, theie is 10 uiop pioLaLility
B. Between 75 anu S0 lill, theie is 15 uiop pioLaLility
C. Between 70 anu S0 lill, theie is 10 uiop pioLaLility loi PLP = 1
D. Between 70 anu S0 lill, theie is 10 uiop pioLaLility loi PLP = 0
9. Vhich ol the lollowing is tiue?
A. BA oveiiiues multilielu classilication
B. Multilielu oveiiiues BA classilication
C. You cannot comLine BA anu multilielu classilication; a packet is classilieu only
once
D. You shoulu peiloim BA anu multilielu classilication on all noues loi
consistency
10. How can the PLP status Le set?
A. Vith multilielu classilication
B. Vith BA classilication
C. Vith a policei
D. Using policy
E. All ol the aLove
Chapter Review Answers
1. Answei: B. Only the Integiateu Seivices (IntSeiv) mouel maue use ol contiol plane
signaling loi iesouice allocation.
2. Answei: A. In the DillSeiv mouel, a BA is a collection ol packets with a shaieu coue
point. It is expecteu that each noue will have the same PHB loi a given BA, anu
theieloie enu-to-enu peiloimance can Le moueleu.
514 | Chapter 10:Class of Service
3. Answei: D. Although you coulu use multilielu classilication eveiywheie, this ap-
pioach uoes not scale. Use a BA classiliei anu associateu iewiite to convey PLP
status Letween noues.
+. Answei: D. Because stiict-high is given 100 ol tiansmit weight, it shoulu Le useu
with a policei to ensuie that othei classes aie not staiveu, especially on the ]-seiies,
wheie stiict-high is an actual piioiity. You cannot use exact with a stiict-high
gueue, Lut on the ]-seiies you can use the shaping iate to cap total usage. Howevei,
a policei is pieleiieu, as this allows excess Lanuwiuth only when othei gueues aie
empty.
5. Answei: B. Suppoiteu on the ]-seiies only, the shaping-rate limits the total amount
ol Lanuwiuth availaLle to the gueue, iegaiuless ol activity in othei gueues. This in
itsell uoes not pievent staivation ol lessei-piioiity gueues, Lut it can help.
6. Answei: A. Many CoS conliguiation eiiois allow a commit, Lut they geneiate a
log waining inuicating that the conliguieu values can Le piogiammeu. This means
the uelault values aie in ellect.
7. Answei: C. Unless you shape at the logical inteilace level, each IFL can senu up to
line iate, anu when multiple IFLs aie active, they shaie availaLle Lanuwiuth. This
is anothei Lenelit to using scheuuleis Laseu on tiansmit peicentage, iathei than
aLsolute values. The lattei woulu iesult in one IFL getting all the Lanuwiuth while
the othei ieceives a uelault scheuulei conliguiation with 95/5 assigneu to
gueue 0 anu 3, iespectively.
S. Answei: A. The piolile uelines a 10 uiop pioLaLility loi lill levels Letween 70
anu S0. You cannot tell liom the uiop piolile itsell whethei it allects PLP 0 oi 1
(oi UDP veisus TCP), Lecause the lunction ol VRED against some ciiteiia is pei-
loimeu via a scheduler-map, which was not shown.
9. Answei: B. Multilielu oveiiiues BA classilication anu geneially is useu only at net-
woik euges.
10. Answei: E. All ol the methous listeu can impact the PLP status ol a given packet.
Chapter Review Answers | 515
CHAPTER 11
IP Multicast in the Enterprise
This chaptei exploies typical enteipiise ueployment scenaiios loi IPv+ multicast. Focus
is placeu on the uesign anu conliguiation ol a scalaLle, lault-toleiant, multicast inlia-
stiuctuie using the ]unos opeiating system. Opeiational analysis anu lault isolation aie
also uemonstiateu. The topics coveieu incluue:
Multicast teiminology anu concepts
Multicast piotocols: gioup management anu iouting
Piotocol Inuepenuent Multicast (PIM) spaise moue using static ienuezvous points
(RPs)
PIM spaise moue with Lootstiap-Laseu RP election
PIM anu Multicast Souice Discoveiy Piotocol (MSDP)-Laseu Anycast-RP
]unipei Netwoiks iouteis ollei extensive suppoit loi IPv+ multicast. Consult the mul-
ticast oveiview in the ]unos uocumentation to conliim the list ol suppoiteu RFC anu
uialts loi youi soltwaie ielease.
What Is Multicast?
Multicast uelines the concept ol a one-to-many communications stieam. To a casual
oLseivei, multicast is similai to Lioaucast in that a single copy ol a packet can Le
ieceiveu Ly multiple noueshowevei, multicast is not uepenuent on an unueilying
multiaccess meuium. It can opeiate netwoik-wiue (unlike Lioaucast tiallic that is not
loiwaiueu Ly iouteis), anu is associateu with piotocols that attempt to automatically
tune the netwoik to eliminate unnecessaiy tianspoit anu ueliveiy ol multicast tiallic.
Routeis use multicast iouting piotocols to contiol the loiwaiuing ol multicast tiallic
to pievent loops anu avoiu inelliciencies associateu with having multiple copies ol a
given packet tiansmitteu ovei the same link multiple times. Multicast gioup memLei-
ship piotocols aie useu Ly hosts to expiess inteiest in one oi moie multicast gioups
multicast tiallic is not loiwaiueu ovei an inteilace with attacheu hosts unless at least
one host has explicitly ieguesteu the ieceipt ol multicast tiallic.
517
Vhen all goes to plan, the piesence ol multicast tiallic is noteu only Ly those noues
that have expiesseu inteiest in that paiticulai stieam, which is in maikeu contiast to a
link-level Lioaucast that loices ieception ol the packet Ly all noues on that link. In
summaiy, Lioaucast is one-to-all with a link-level scope, wheieas multicast is one-to-
many, netwoik-wiue, Lut only when theie is expiess inteiest in ieceiving multicast.
The souices anu uestinations ol multicast content aie geneially hosts, not iouteis. The
iole ol a multicast ioutei entails locating multicast souices, ieplicating packets loi
tiansmission ovei multiple inteilaces, pieventing iouting loops, anu connecting intei-
esteu uestinations with the piopei souice, all while keeping the llow ol unwanteu
packets to a minimum.
Multicast Applications
Theie aie numeious applications loi IP multicast. In many cases, a given application
is capaLle ol opeiating in eithei unicast oi multicast moue, uepenuing on usei settings
anu oveiall scaling neeus. Netwoik applications that can lunction with unicast Lut aie
Lettei suiteu loi multicast incluue collaLoiative gioupwaie, teleconleiencing, anu uis-
tiiLuteu applications such as multiplayei gaming oi viitual ieality. Any IP netwoik
conceineu with ieuucing netwoik iesouice consumption loi one-to-many oi many-to-
many applications, to incluue multimeuia stieams with multiple ieceiveis such as IP-
TV, Lenelits liom multicast.
Multicast-enaLleu netwoiks anu applications pioviue signilicant scaling Lenelits.
Vhen unicast is employeu Ly an Inteinet iauio oi news tickei seivice, loi example,
each iecipient ieguiies a scparatc tiallic session. The piocessing loau at the seivei anu
netwoik Lanuwiuth consumeu inciease lineaily as each new ieceivei attaches to the
seivei. This is extiemely inellicient, whethei uealing with the gloLal scale ol the Inteinet
oi a mouest enteipiise-scale netwoik.
In a Lioaucast mouel, the souice neeus to geneiate only a single stieam using a Lioau-
cast uestination auuiess. Ignoiing loi the moment that the link-level scope ol Lioaucast
makes this mouel unusaLle in a iouteu netwoik, a Lioaucast mouel is extiemely inel-
licient Lecause it consumes maximum Lanuwiuth anu places the Luiuen ol packet
iejection on each host.
Multicast pioviues the most ellicient anu ellective solution loi most one-to-many oi
many-to-many applications, with none ol the uiawLacks anu all ol the auvantages ol
the unicast oi Lioaucast mouel. Vith multicast, a single multicast packet stieam linus
its way to eveiy inteiesteu ieceivei, anu ieplication is peiloimeu in a uistiiLuteu mannei
within each ioutei as neeueu, allowing laige-scale ueployment Lecause no one uevice
is loiceu to ieplicate oi hanule all tiallic associateu with the application. Vith IP mul-
ticast, a senuing host geneiates a single IP packet stieam, whethei theie is one ieceivei
oi 1 million ieceiveis, anu links that connect to suLnets consisting ol entiiely unintei-
esteu ieceiveis caiiy no multicast tiallic at all.
518 | Chapter 11:IP Multicast in the Enterprise
Locating content
Once you have enaLleu multicast in youi netwoik, the liist guestion Lecomes Vhat
new seivices anu applications can I enaLle with it, anu how will useis know? In othei
woius, loi maximum Lenelit, theie neeus to Le a TV Guiuelike lunction availaLle to
the enu usei. The Session Diiectoiy tool (known as SDR) is an enu-usei application
that uses multicast piotocols to locate anu list availaLle sessions in the netwoik. Fig-
uie 11-1 shows the usei inteilace loi the SDR application.
Iigurc 11-1. Thc Scssion Dircctory too|
What Is Multicast? | 519
The tianspoit piotocol useu Ly the Session Diiectoiy tool is the Session Announcement
Piotocol (SAP). SAP messages aie tiansmitteu to the well-known multicast gioup au-
uiess ol 22+.2.127.25+, anu they contain uesciiptions ol cuiiently availaLle sessions
loimatteu using the Session Desciiption Piotocol (SDP). You can uownloau the SDR
application anu get auuitional inloimation at http://www-nicc.cs.uc|.ac.u|/nu|tincdia/
sojtwarc/sdr/.
Multicast Terminology and Concepts
To the uninitiateu, multicast can seem to Le a jumLle ol conlusing teims anu concepts.
It helps to keep in minu that multicast is laigely state-uiiven, which is to say that things
may oi may not happen, Laseu on the piesence oi aLsence oi some othei event. Foi
example, a join message is geneiateu when a ioutei wishes to ieceive multicast tiallic
loi a given gioup. As a iesult ol this join, a multicast uistiiLution tiee is instantiateu,
oi mouilieu, which auus the inteilace on which the join was ieceiveu in the outgoing
inteilace list (OIL) loi that gioup. Altei some peiiou ol time, lack ol continueu join
activity iesults in this state timing out, the iemoval ol the inteilace liom the OIL, anu
the cessation ol multicast loiwaiuing loi that gioup ovei that inteilace. This now you
see it, now you uon`t aspect ol multicast olten leaus to conlusion, at least when com-
paieu to the moie oi less steauy-state natuie ol unicast iouting piotocols. In Open
Shoitest Path Fiist (OSPF), the aLsence oi piesence ol a ioute is not a lunction ol an
actual uesiie oi neeu to use the ioute. In contiast, a multicast ioute is actually a
uynamic entiy that is Laseu on the piesence ol an active senuei anu, to some uegiee,
the piesence ol at least one inteiesteu ieceivei.
Routing turned upside down
Il the uynamic state ol multicast is not ieason enough loi conlusion, consiuei that
multicast loiwaiuing is actually a type ol ieveise iouting. Unicast iouting is Laseu on
longest-matching against the packet`s uestination auuiess, with the oveiall goal Leing
the loiwaiuing ol a packet towaiu its uestination. In contiast, multicast loiwaiuing is
peiloimeu Laseu on the sourcc auuiess, with the goal Leing the loiwaiuing ol the packet
away liom the souice, as opposeu to towaiu any paiticulai uestination. This Lehavioi
is known as ieveise path loiwaiuing (RPF) anu is uetaileu in a latei section.
Multicast terms
The ieauei shoulu Le lamiliai with the lollowing teims anu concepts Leloie uelving
any luithei into multicast. Relei to Figuie 11-2 to see how the teims ielate to an IP
multicast netwoik.
Figuie 11-2 looks complicateu, so let`s tackle each pait inuiviuually:
520 | Chapter 11:IP Multicast in the Enterprise
Mu|ticast sourccs
The multicast souices loi gioups 1 anu 2 aie shown at the top ol Figuie 11-2. A
multicast souice is the entity that geneiates a stieam ol packets auuiesseu to one
oi moie multicast gioups. The set ol auuiesses liom 22+.0.0.0 to 239.255.255.255
(22+/+) aie ieseiveu loi IP multicast use. Any uevice that senus one oi moie packets
to a uestination auuiess in this iange is a multicast senuei. No multicast-specilic
iouting oi gioup management piotocol is ieguiieu Ly a multicast senuei; in lact,
the senuei uoes not even neeu to Le aLle to ieceive multicast tiallic. The senuei is
the ioot ol a shoitest-path tiee (SPT).
Mu|ticast rcccivcrs
Seveial multicast ieceiveis aie shown at the Lottom ol Figuie 11-2. The ieceiveis
loim the leaves ol a multicast uistiiLution tiee. Multicast ieceiveis iun the Inteinet
Gioup Management Piotocol (IGMP), to inloim attacheu iouteis what multicast
gioups they aie inteiesteu in. A noue Lecomes a leal on the uistiiLution tiee when
it joins a given gioup. A Lianch is piuneu liom the multicast tiee when no inteiesteu
hosts iemain; that is, when all ol its leaves have lallen oll. This conuition is shown
loi LAN 3, wheie the sole ieceivei has inuicateu a uesiie to leave Loth multicast
gioups. Note how the gioup management piotocol`s leave messages Lecome a
Iigurc 11-2. Mu|ticast tcrns
What Is Multicast? | 521
multicast iouting piotocol piune message, assuming that the liist hop ioutei has
no othei inteiesteu ieceiveis (leaves) loi the ielateu Lianch. (Oh, the lun ol the
teiminology: a leal senus a leave messages to Le piuneu liom the tiee, so in the
pluial, leaves senus leaves to leave a Lioaucast session.)
Mu|ticast protoco|s
Multicast piotocols contiol the llow ol multicast tiallic Letween souices anu ie-
ceiveis. Foi now, it`s sullicient to note that ieceiveis use a gioup management
piotocol to inloim theii iouteis which gioups they aie inteiesteu in; ieceiveis aie
not awaie ol the actual multicast topology. Routeis iun a gioup management
piotocol to communicate with attacheu ieceiveis, anu a multicast iouting piotocol
when communicating with othei multicast-awaie iouteis. A multicast iouting
piotocol such as PIM is signilicantly moie complex than the gioup management
piotocols useu Ly ieceiveis, anu it is iesponsiLle loi ensuiing loop-liee loiwaiuing
anu management ol the uistiiLution tiee Laseu on the aLsence oi piesence ol
inteiesteu ieceiveis.
Upstrcan/downstrcan
Many opeiations in multicast aie uiiectionally oiienteu. The multicast tiee is ioo-
teu at each souice anu teiminates at the vaiious ieceiveis. Tiallic llows uown-
stieam, along the uistiiLution tiee, liom the souice to each ieceivei. In contiast,
contiol messages that estaLlish a piune/join state aie sent upstieam, in the uiiec-
tion ol the ieceivei to the souice. Figuie 11-2 shows the multicast tiallic liom
gioups 1 anu 2 llowing uownstieam towaiu inteiesteu ieceiveis while the ielateu
contiol messages llow upstieam.
Distribution trccs, branchcs, and |cavcs (oh, ny)
A uistiiLution tiee is the inteiconnection ol noues that lie Letween a senuei anu
inteiesteu ieceiveis. Figuie 11-2 shows two senueis, anu each is associateu with its
own uistiiLution tiee. In oui example the tiee is iooteu at the senuei. Latei in the
chaptei, we will uiscuss the concepts ol shaieu tiees, wheie a ienuezvous point
(RP) Lecomes the ioot ol the tiee. The example in the liguie consists ol two SPTs.
Tiallic llows uownstieam on the tiee while contiol messages llow upstieam to
inlluence multicast llow. Between the ioot anu each leal lies one oi moie Lianches.
A ioutei must ieplicate packets to each Lianch that leaus to a leal, noting, howevei,
that the same elloit is ieguiieu whethei theie is one oi 1,000 leaves on that Lianch.
A leal is a multicast ieceivei with inteiest in a given gioup. A Lianch is piuneu liom
the tiee when it has no iemaining leaves. The liguie shows R3 anu R5 piuning
Lianches liom the tiee in iesponse to the ieceipt ol leave messages that inuicate no
iemaining leaves.
Dcnsc and sparsc nodcs
Theie aie two piimaiy stiategies when it comes to loiming the initial uistiiLution
tiee. Theie is the j|ood jirst, prunc |atcr philosophy known as uense moue, anu
theie is the prunc jirst and j|ood on|y whcn as|cd jor methou known as spaise moue.
Stateu uilleiently, uense moue is like a push mouel that assumes that all ieceiveis
522 | Chapter 11:IP Multicast in the Enterprise
want all multicast, anu spaise moue lunctions in a client pull mannei, wheie it is
assumeu that most ieceiveis uo not want any multicast. In Loth methous, the uis-
tiiLution tiee is ultimately piuneu ol any lealless Lianches, Lut in the loimei, the
expiiation ol state iesults in iesumeu uense moue lloouing, wheieas in the lattei,
an expiiation ol join state iesults in a ietuin to the uelault piuneu moue. Geneially
speaking, oluei multicast iouting piotocols such as the Distance Vectoi Multicast
Routing Piotocol (DVMRP) suppoit only uense moue, wheieas newei piotocols
such as PIM suppoit Loth moues. In some cases, the same piotocol can opeiate in
a sparsc-dcnsc moue, wheieLy ceitain gioups aie hanuleu in uense lashion while
otheis aie tieateu as spaise. Dense moue opeiation is Lest suiteu loi use ovei LANs
Lecause its lloou-liist natuie tenus to consume moie Lanuwiuth. On the upsiue,
uense moue uoes not ieguiie the complexities ol an RP. Recall that in uense moue,
any active souice iesults in lloouing uown all Lianches, which aie then piuneu il
not neeueu; this means that iouteis have no pioLlems leaining aLout active souices
anu gioups. In contiast, spaise moue opeiation cieates somewhat ol a chicken-
Leloie-the-egg pioLlem, in that a ioutei must senu an explicit join Leloie it can
ieceive tiallic loi a given gioup, Lut Leloie it can senu the join it has to know which
gioups anu souices aie active! This pioLlem is iesolveu with the intiouuction ol a
shaieu tiee anu an RP, which we will uetail in a suLseguent section.
Additional multicast building blocks
This section uiscusses IP multicast concepts that aie inuepenuent ol any specilic mul-
ticast iouting piotocol oi moue ol opeiation. Unueistanuing these concepts piepaies
the ieauei loi the upcoming IP multicast conliguiation anu opeiational moue analysis
examples.
Multicast uses the Class D IP auuiess iange, liom 22+.0.0.0 to
239.255.255.255. In mouein veinaculai, the concept ol classlul auuiesses has lost la-
voi, so auuiesses in this iange aie commonly ieleiieu to as simply nu|ticast ad-
drcsscs. A multicast auuiess can Le useu only as the uestination auuiess ol an IP
packetthe souice auuiess must always Le ol the unicast loim. A multicast auuiess
noimally has a /32 pielix length, although othei pielix lengths aie alloweu. Recall that
a multicast auuiess iepiesents a logical giouping ol uevices iathei than a physical col-
lection ol uevices. Multicast auuiesses can still Le uesciiLeu in teims ol pielix length
using tiauitional notation. Foi example, the entiie multicast auuiess iange can Le wiit-
ten as 22+/S. The Lase auuiess 22+.0.0.0 is ieseiveu anu cannot Le assigneu to any
gioup, auuiesses in the 22+.0.0.122+.0.0.255 iange aie ieseiveu loi local wiie use,
anu the 239.0.0.0239.255.255.255 iange is ieseiveu loi auministiatively scopeu
auuiesses.
Inteinet numLeiing authoiities noimally uo not allocate multicast auuiesses to theii
customeis. This is Lecause multicast auuiesses aie conceineu moie with content than
with a given physical uevice. Receiveis uo not ieguiie a multicast auuiess, Lut they neeu
to know the multicast auuiess associateu with the multicast content they aie inteiesteu
Multicast addressing.
What Is Multicast? | 523
in. Multicast souices neeu an assigneu multicast auuiess only to piouuce the content,
not to iuentily theii place in the netwoik. Eveiy souice, ieceivei, anu numLeieu ioutei
inteilace still neeus an oiuinaiy, unicast IP auuiess.
Many applications have Leen assigneu a iange ol multicast auuiesses, eithei Ly the
Inteinet Engineeiing Task Foice (IETF) oi Ly the applications` uevelopeis. Although
statically assigneu multicast auuiessing is ceitainly possiLle, in most cases you can
simply use the application`s uelaults. TaLle 11-1 shows some application-to-multicast
auuiess mappings, as uelineu Ly the Inteinet Assigneu NumLeis Authoiity (IANA) at
http://www.iana.org/assignncnts/nu|ticast-addrcsscs.
Tab|c 11-1. |ANA app|ication-to-nu|ticast addrcss nappings (sc|cct cxanp|cs)
Address Application
224.2.0.0224.2.127.253 Multimedia conference calls
224.4.0.0224.4.0.254 London Stock Exchange
224.0.1.141 Dynamic Host Configuration Protocol (DHCP) servers
224.0.1.39 cisco-rp-announce
Mapping IP Multicast to Link Layer Multicast
On multiaccess netwoiks such as LANs, using the Lioaucast auuiess to loiwaiu IP
multicast iesults in uisiuption to all noues on that LAN segment, whethei they aie
inteiesteu in multicast oi not. Using a unicast auuiess negates the one-to-many elli-
ciency Lenelit ol multicast. The solution is to map a Layei 3 IP multicast auuiess, which
is 32 Lits in length, into a coiiesponuing +S-Lit meuia access contiol (MAC) layei
multicast auuiess. Figuie 11-3 shows a sample ol this mapping.
Given the uilleient auuiess lengths, a uiiect 1:1 mapping Letween Layei 2 anu Layei 3
auuiesses is not possiLle. One-hall ol the IANA-owneu Llock ol Etheinet MAC au-
uiesses, the liist 2+ Lits staiting with 0x 01:00:5E, aie ieseiveu loi multicast, yieluing
the usaLle iange ol 0100.5e00.00000100.5e7l.llll inclusive. This allocation iesults in
a 2+-Lit lielu, Lut Lecause the liist Lit is always set to 0, only 23 Lits iemain to Le
populateu with the IP multicast auuiess. The mapping piocess stiips the +-Lit class D
iuentiliei as well as the 5 high-oiuei Lits liom the gioup ID, which leaves 23 Lits ie-
maining to Le mappeu into the multicast MAC auuiess. Because 5 high-oiuei Lits aie
stiippeu liom the gioup ID, theie is a iesulting loss ol gianulaiity in the Layei 3 to
Layei 2 auuiess mapping iesulting in 32(2
5
) uilleient gioup auuiesses mapping to the
same multicast MAC auuiess, as shown at the Lottom ol Figuie 11-3.
524 | Chapter 11:IP Multicast in the Enterprise
In a Layei 2 netwoik, the shaiing ol a MAC auuiess among as many as 32 IP multicast
gioups iesults in a loss ol elliciency, Lecause tiallic sent to one multicast gioup will Le
ieceiveu Ly all hosts using the same shaieu MAC layei multicast auuiess, even though
they uo not suLsciiLe to that paiticulai gioup. Vheievei possiLle, you shoulu Le caielul
when selecting IP multicast auuiesses to ensuie that they map to a unigue MAC layei
multicast auuiess; otheiwise, host systems will have to expenu cycles ieceiving, anu
then uiscaiuing, multicast tiallic loi gioups that have no local applications listening.
Multicast addressing and administrative scoping
Multicast auuiesses aie categoiizeu accoiuing to theii scope. Scoping is uesigneu to
limit the extent to which a multicast packet can tiavel. Scoping is useu loi Loth pei-
loimance anu auministiative ieasons. TaLle 11-2 uetails cuiiently uelineu IPv+ multi-
cast auuiess scopes.
Iigurc 11-3. Laycr 3 to Laycr 2 nu|ticast napping
What Is Multicast? | 525
Tab|c 11-2. |Pv1 nu|ticast addrcss scopcs
Address Scope Comment
224.0.0.0/24 Link local Confined to a single link, often used for unicast routing proto-
cols; allows same multicast address on each link
239.0.0.0239.255.255.255 Administratively scoped Further subdivided into site-local (239.255.0.0/16) and
organizational (239.192.0.0/14) scopes
224.0.1.0238.255.255.255 Global Addresses with global scope, of which several static assign-
ments exist:
224.1.0.0-224.1.255.255: shared tree multicast groups
224.2.0.0-224.2.127.253: multimedia conference calls
224.2.127.254: SAPv1 announcements
224.2.127.255: SAPv0 announcements
224.2.128.0-224.2.255.255: SAP dynamic assignments
224.252.0.0-224.255.255.255: DIS transient groups
(RFC2365)
232.0.0.0-232.255.255.255: VMTP transient groups
(RFC1045)
Mouein IP netwoiks use auuiess-Laseu scoping iathei than IP Time to Live (TTL)
Laseu scoping. This is Lecause TTL-Laseu technigues aie pione to pioLlems in teims
ol Leing aLle to accuiately pieuict TTL values netwoik-wiue, especially in the lace ol
changes in loiwaiuing topology uuiing lailovei scenaiios. Auuiesses in the link-local
scope cannot Le loiwaiueu Leyonu the Lounuaiies ol a single link. These auuiesses
tenu to Le useu Ly unicast iouting piotocols such as Routing Inloimation Piotocol
veision 2 (RIPv2) anu OSPF. The auministiatively scopeu auuiess iange is Lioken into
site-local anu oiganizational Lounuaiies. An enteipiise might consist ol a single site,
the exact uelinition ol which is lelt to the auministiatois ol the iouting uomain, oi it
may consist ol multiple sites. Geneially, the oiganizational scope is uelineu as the extent
ol a iouting uomain. Auministiatois conliguie site oi gloLal scoping on the appiopiiate
inteilaces to Llock ielateu tiallic liom leaving that inteilace. Figuie 11-+ illustiates a
scoping example.
The appioach shown in Figuie 11-+ is auuiess-Laseu, Lut ]unos also suppoits scoping
Laseu on a scope-policy. Unlike auuiess scoping, which is applieu pei inteilace, a
scope-policy applies to all inteilaces, anu you cannot use it in conjunction with
inteilace-level scoping. You conliim auuiess scoping using the show multicast scope
commanu. The iemaining IP multicast auuiess space is consiueieu to have a gloLal
scope. Some auuiesses within the gloLal iange aie statically assigneu Ly the IANA, as
shown in TaLle 11-2.
It is common to see scoping useu to Llock the multicast auuiesses associateu with the
auto-RP uiscoveiy mechanism (22+.0.1.39 anu 22+.0.1.+0) at auministiative
526 | Chapter 11:IP Multicast in the Enterprise
Lounuaiies to pievent the use ol the local uomain`s RP Ly iouteis outsiue ol local
auministiative contiol.
You cannot use scoping to Llock RP uiscoveiy via the Lootstiap piotocol
Lecause the Lootstiap mechanism opeiates hop Ly hop anu uses the
22+.0.0.13 ALL-PIM-Routeis multicast auuiess, which, il scopeu,
woulu Lieak othei aspects ol PIM opeiation. Noimally, Lootstiap mes-
sages aie scopeu Ly conliguiing inteiuomain inteilaces to iun PIMv1,
which uoes not suppoit Lootstiap, oi thiough uelinition ol Lootstiap
impoit/expoit policy that Llocks ieception oi tiansmission ol Lootstiap
ioutei (BSR) messages, iespectively.
Interface lists
Multicast iouteis maintain state to ueteimine which multicast packets shoulu Le loi-
waiueu, anu ovei which inteilaces copies ol a packet shoulu Le sent. Pait ol this state
is in the loim ol incoming anu outgoing inteilace lists (IILs/OILs) loi each active mul-
ticast souice in the netwoik. Maintaining accuiate inteilace lists is ciitical loi loop
avoiuance.
Iigurc 11-1. Mu|ticast scoping
What Is Multicast? | 527
Loops in any IP netwoik aie a Lau thing. A multicast loop can Le pai-
ticulaily nasty given the ieplication action ol iouteis, which seives to
pioviue an amplilication ellect loi any looping packets.
The inteilace that lies on the shoitest path bac| to the souice is the upstieam (incoming)
inteilace, anu packets aie nevei alloweu to Le loiwaiueu toward the multicast souice.
All iemaining inteilaces coulu Lecome a uownstieam (outgoing) inteilace, uepenuing
upon join state.
A ioutei with multicast loiwaiuing state loi a paiticulai multicast gioup is switcheu
on loi that gioup`s content. Inteilaces on the ioutei`s outgoing inteilace list senu
copies ol the gioup`s packets ieceiveu on the IIL loi that gioup. Figuie 11-5 shows this
conuition.
Iigurc 11-5. |ntcrjacc |ists
The ioutei state that contiols multicast loiwaiuing is ieleiieu to as (S,G) oi (',G). In
(S,G), the S ieleis to the unicast IP auuiess ol the souice loi the multicast tiallic, anu
the G ieleis to the paiticulai multicast gioup IP auuiess loi which S is the souice. All
multicast packets sent liom this souice have S as the souice auuiess anu G as the
528 | Chapter 11:IP Multicast in the Enterprise
uestination auuiess. The asteiisk (') in the (',G) notation is a wilucaiu inuicating that
the state applies to any multicast souice senuing to gioup G. So, il two souices aie
oiiginating content loi multicast gioup 22+.1.1.2, a ioutei coulu use (', 22+.1.1.2) to
iepiesent the state ol a ioutei loiwaiuing tiallic liom Loth souices to memLeis ol that
gioup, as is uone in the case ol a shaieu tiee.
An incoming anu outgoing inteilace list is maintaineu loi each active souice to gioup
tuple. Vhen you consiuei that gioup memLeiship is itsell olten uynamic, anu that this
volatility leaus to a neeu loi ongoing maintenance ol the ielateu inteilace list, it Lecomes
cleai that a ioutei hanuling laige numLeis ol multicast gioups can consume signilicant
contiol plane iesouices maintaining multicast loiwaiuing state. All ]unipei Netwoiks
ioutei aichitectuies aie well suiteu to haiuwaie/ieal-time thieau-Laseu multicast iep-
lication anu can loiwaiu multicast at the same (neai-line-iate) peiloimance level as
unicast. A typical contiol plane scaling guiueline loi a ioutei with 1 GB ol memoiy is
no moie than 120,000 PIM entiies sum ol (',G) anu (S,G), 1,000 PIM neighLois, anu
1,000 uynamic IGMP gioups pei inteilace.
Reverse path forwarding
Conventional iouting is Laseu on a longest match against the uestination auuiess ol a
packet. The unicast ioute taLle is maintaineu Ly unicast iouting piotocols such as the
Routing Inloimation Piotocol (RIP) anu OSPF, anu it is useu when loiwaiuing unicast
packets towaiu theii uestinations. As noteu pieviously, multicast is like iouting tuineu
upsiue uown, in that now the ioutei actually loiwaius packets away liom the souice,
Laseu on the souice iathei than the uestination auuiess. A multicast ioutei`s loiwaiuing
state is thus oiganizeu Laseu on a rcvcrsc path paiauigm. As noteu eailiei, this piocess
is known as ieveise path loiwaiuing (RPF) anu is shown in Figuie 11-6.
An RPF check simply makes suie that a packet aiiives on the same inteilace that woulu
Le useu loi egiess Ly the local ioutei when iouting bac| to that multicast souice using
the Inteiioi Gateway Piotocol`s (IGP`s) shoitest pathin ellect, a multicast packet is
iouteu twice, once Laseu on the souice auuiess anu, il that passes, again Laseu on the
gioup auuiess, this time against the outgoing inteilace list loi that gioup. It`s impoitant
to note that RPF checks occui Loth in the contiol plane when piocessing joins, anu in
the uata plane when ueciuing whethei a packet shoulu Le loiwaiueu. Multicast packets
that lail the RPF check aie uioppeu Lecause the incoming inteilace is not on the shoitest
path Lack to the souice. Figuie 11-6 shows how ioutei R+ uiops a multicast packet
liom souice 10.0.1.1 when it is ieceiveu on an inteilace that woulu not Le useu when
iouting a unicast packet to auuiess 10.0.1.1. The liguie also shows that iouteis geneiate
joins ovei the RPF inteilace Lack to the souice.
What Is Multicast? | 529
Iigurc 11-. Thc nu|ticast RPI chcc|
In some cases, the multicast iouting piotocol maintains its own RPF taLle, which is
useu specilically loi the puipose ol loiwaiuing multicast. DVMRP is an example ol
such a piotocol. PIM, on the othei hanu, makes use ol the existing unicast ioute taLle
to peiloim its RPF checks. This capaLility is why PIM is consiueieu to Le protoco|-
indcpcndcnt; it can use any ioute souice loi its RPF checks, incluuing static, IGP, anu
even Boiuei Gateway Piotocol (BGP) ioutes. ]unos suppoits extensions to unicast
iouting piotocols to accommouate the Luiluing ol a sepaiate RPF taLle. Examples in-
cluue the Multipiotocol Boiuei Gateway Piotocol (MBGP) anu multitopology iouting
in Inteimeuiate SystemtoInteimeuiate System (IS-IS), oi M-IS-IS.
Using the main unicast ioute taLle loi RPF checks pioviues simplicity; using a ueuicateu
ioute taLle loi RPF checks allows a netwoik auministiatoi to set up sepaiate paths anu
iouting policies loi unicast anu multicast tiallic. This allows the multicast netwoik to
lunction moie inuepenuently ol the unicast netwoik.
Distribution trees
Pievious uiscussions have inuicateu that multicast tiallic is uistiiLuteu via a tiee that
is iooteu at the souice anu Lianches as neeueu to pick up all inteiesteu leaves. Seveial
530 | Chapter 11:IP Multicast in the Enterprise
uilleient types ol uistiiLution tiees exist, anu in many cases multiple tiee types aie useu
(ovei time) loi the same multicast stieam.
SPT is a uistiiLution tiee that is iooteu at the souice. This is
sometimes calleu a sourcc trcc. An SPT is loimeu Ly senuing the appiopiiate join mes-
sages ovei the RPF path to the uesiieu souice. Figuie 11-7 shows this piocess.
Iigurc 11-7. An SPT
Things Legin when the ieceivei senus an IGMP join loi souice 10.0.1.1 anu gioup
225.0.0.1. R7, the liist hop (anu, in this case, uesignateu) ioutei, geneiates the appio-
piiate join message out the RPF inteilace loi that souice. This is ieleiieu to as an (S,G)
join, Lecause in this case Loth S anu G aie known. Routei R+ ieceives the (S,G) join,
which tiiggeis the auuition ol the ieceiving inteilace to its OIL loi the 10.0.1.1,
225.0.0.1 tuple. R+ now peiloims its own RPF check on the souice auuiess, anu as a
iesult R+ senus its (S,G) join message out its RPF inteilace loi 10.0.1.1, causing iecep-
tion ol the (S,G) join at R1. The piocess stops when the join message ieaches the ioutei
uiiectly connecteu to the souice oi when it ieaches a ioutei that alieauy has multicast
loiwaiuing state loi this (S,G) tuple. The key point is that RPF hanuling ol (S,G) join
messages iesults in an SPT.
A shaieu multicast tiee is iooteu at an inteimeuiate ioutei, iathei
than at a specilic souice. The use ol a shaieu tiee can ollei the Lenelit ol less oveiall
state, in that a single (',G) entiy can now iepiesent state loi numeious souices that may
Le senuing to this gioup. In the most common multicast piotocol in use touay, PIM,
Shortest-path tree (SPT).
Shared trees and RPs.
What Is Multicast? | 531
the shaieu tiee is shoit-liveu anu useu only to make initial contact Letween senueis anu
ieceiveis, howevei. Once this initial contact is maue, an SPT is estaLlisheu anu the
shaieu tiee is no longei useu loi that (S,G) tuple. In PIM, the ioot ol the shaieu tiee is
the RP, which lunctions to suppoit spaise moue opeiation. Recall that in spaise moue,
multicast is loiwaiueu only as a iesult ol an explicit join loi the ielateu gioup. Vithout
piioi knowleuge ol which senueis aie active loi what gioups, a ioutei cannot geneiate
an (S,G) join towaiu the souice, Lecause the souice is not yet known.
Souice-specilic multicast (SSM) uesciiLes a conuition in which the ie-
ceivei has pieexisting knowleuge ol what souice it wishes to join. This
allows the geneiation ol an SPT without the neeu loi an RP. The use ol
ieceivei joins that uo not specily a paiticulai souice is known as Any
Souice Multicast (ASM).
In a spaise moue Any Souice Multicast (ASM) opeiation, the ioutei geneiates an (',G)
join towaiu the RP, which iesults in joining a tiee that is shaieu among all senueis
associateu with that gioup. Figuie 11-S shows this piocess.
Iigurc 11-8. An RP trcc
532 | Chapter 11:IP Multicast in the Enterprise
In the example in Figuie 11-S, the ieceivei geneiates an IGMP join loi gioup 225.0.0.1
that uoes not specily a paiticulai souice; hence, the any in the teim Any Souice Mul-
ticast anu the use ol a wilucaiu metachaiactei to iepiesent the iesulting state (',G). The
last hop ioutei, which lunctions as a uesignateu ioutei, peiloims an RPF check loi the
RP that hanules this gioup, anu the join is sent towaiu the RP iathei than towaiu any
paiticulai souice.
Figuie 11-S calls out how the souice geneiates native multicast to the liist hop ioutei,
R1 (which also lunctions as a uesignateu ioutei), which in tuin encapsulates the tiallic
into a unicast uatagiam auuiesseu to the RP. Upon ieceipt, the RP stiips the iegistei
message encapsulation anu senus the now native multicast uown the shaieu tiee asso-
ciateu with that gioup.
The puipose ol iegistei encapsulation is to eliminate the neeu loi multicast-enaLleu
iouteis Letween souices anu the RP. The uownsiue is that the liist hop iouteis (those
attacheu uiiectly to multicast souices) anu the RP ieguiie tunneling haiuwaie/soltwaie
suppoit. On M-seiies platloims, this noimally ieguiies the piesence ol a Tunnel Seiv-
ices PICnote that the M7i has a Luilt-in Tunnel Seivices PIC wheieas the M10i uoes
not. SRXs anu ]-seiies platloims peiloim multicast iegistei message encapsulation in
soltwaie, using the inteinal seivices inteilace, making auuitional haiuwaie unneces-
saiy. High-enu SRXs anu the MXs peiloim this lunction natively on the inteilace caius.
In PIM spaise moue opeiation, the shaieu RP tiee
(RPT) is useu only loi uiscoveiy ol active souices. The ieceipt ol tiallic on the RPT
initiates a switchovei to an SPT Ly the last hop ioutei (the ioutei attacheu to the ie-
ceivei), loi each active souice that is uiscoveieu. Once the SPT is loimeu, the last hop
ioutei Legins to ieceive native multicast uiiectly liom the souice, so an (S,G) piune is
sent up the shaieu tiee, towaiu the RP, to pievent ieception ol tiallic ovei Loth the SPT
anu the RPT loi that souice. In some PIM implementations, a usei-conliguiaLle thiesh-
olu can Le set to contiol when the switch to an SPT is instigateu. This capaLility is
uesigneu to pievent cutovei to an SPT loi shoit-liveu sessions, wheie the tiallic may
no longei even Le piesent Ly the time the SPT is estaLlisheu. In ]unos`s PIM imple-
mentation, you can altei the uelault Lehavioi ol immeuiately switching to an SPT in
lavoi ol ncvcr switching to an SPT. You can uo this with the spt-threshold infinity
statement, in conjunction with a policy that specilies one oi moie (S,G) paiis that aie
suLject to the mouilieu Lehavioi. The last hop ioutei will nevei attempt to switch liom
the RPT to an SPT loi matching (S,G) tiallic. This Lehavioi is uesiieu loi applications
that senu veiy low levels ol multicast tiallic, wheie the uelault Lehavioi coulu iesult in
unuesiieu oscillation Letween SPT estaLlishment, a timeout, anu a iesultant switch
Lack to the RPT.
Switching from a shared tree to an SPT.
What Is Multicast? | 533
PIM spaise moue opeiation ieguiies tunnel seivices haiuwaie (oi solt-
waie emulation) to peiloim the iegistei encapsulation anu uecapsula-
tion lunctions. ]-seiies platloims can use the inteinal seivices inteilace
loi this lunctionality, as can the M7i with its Luilt-in ASM haiuwaie.
The M10i ieguiies the installation ol tunnel seivices haiuwaie to sup-
poit iegistei encapsulation. Il youi ioutei lacks tunnel seivices, you can
still commit a PIM spaise moue conliguiation, Lut things will simply
not woik il that ioutei is the liist hop attacheu to a souice oi when it
lunctions as a (iemote) RP, as Loth ol these ioles ieguiie piocessing ol
iegistei messages. A Tunnel Seivices PIC is not ieguiieu loi uense oi
SSM moues ol opeiation. You can also eliminate the neeu loi iegistei
encapsulation anu ielateu tunnel PICs with the coinei-case scenaiio ol
always having the liist hop ioutei also lunction as the RP.
Multicast Terminology Summary
This section uelineu the key teims anu concepts associateu with IP multicast. The next
section exploies multicast iouting anu gioup management piotocols.
Multicast Protocols
This section uesciiLes the opeiation ol gioup management anu multicast iouting
piotocols. Ve will locus on PIM spaise moue Lecause it`s the pieuominate loim ol
multicast iouting piotocol in mouein IP multicast netwoiks. Simply stateu, gioup
management piotocols aie iun Ly hosts to inloim local iouteis ol a host`s inteiest, oi
lack theieol, in a paiticulai multicast gioup. Multicast iouting piotocols aie iun only
on iouteis anu aie conceineu with RPF checks anu the estaLlishment anu maintenance
ol (',G) anu (S,G) loiwaiuing state.
Group Management Protocols
IGMP peiloims multicast gioup management anu is iun on hosts anu on iouteis that
attach to host segments. IGMP veisions 1, 2, anu 3 aie cuiiently uelineu in RFCs 1112,
2236, anu 3376, iespectively. The Lasic mechanics ol IGMP opeiation centei on hosts
geneiating iepoit messages to inloim attacheu iouteis what gioups the host is intei-
esteu in, anu to inloim iouteis geneiating gueiy messages to ueteimine whethei any
active listeneis still iemain loi a paiticulai gioup.
Theie aie thiee veisions ol IGMP]unipei iouteis uelault to veision 2, Lut you can
conliguie them loi veision 1 oi veision 3 as neeueu. Although the vaiious veisions ol
IGMP aie Lackwaiu-compatiLle, this compatiLility is achieveu at the cost ol having to
uiop Lack to the lowest common uenominatoi. Foi example, il one host is iunning
IGMPv1, any ioutei attacheu to the LAN iunning IGMPv2 uiops Lack to IGMPv1
opeiation, ellectively eliminating the auvantages ol IGMPv2. Vheie possiLle, you
534 | Chapter 11:IP Multicast in the Enterprise
shoulu ensuie that all multicast ieceiveis iun the highest veision ol IGMP that is sup-
poiteu anu conliguieu on the iouteis seiving that netwoik segment.
TaLle 11-3 iuentilies the key uilleiences among IGMP veisions.
Tab|c 11-3. |CMP vcrsion conparison
Version Characteristics Comment
IGMPv1 Periodic generation of queries to the all-routers multicast address
(224.0.0.1); hosts reply with list of interested groups; querier
function performed by routing protocol
Join and leave latency stemming from periodic
(60-second) nature of queries
IGMPv2 Lowest IP becomes querier for LAN; group-specific query and
leave-group message
Routing protocol no longer performs the querier
function; improved join/leave latency
IGMPv3 Support for group-source report messages Supports SSM by allowing receivers to specify
(S,G) tuples
Figuie 11-9 uetails key aspects ol IGMPv2 iepoit anu gueiy Lehavioi.
Iigurc 11-9. |GMPv2 opcration
Things Legin in Figuie 11-9 when the ieceivei geneiates an IGMPv2 iepoit, expiessing
inteiest in Lecoming a memLei ol the 225.0.0.1 gioup. Note that the iepoit is sent to
the multicast auuiess eguating to the gioup Leing joineu. Both multicast iouteis see
this iepoit. The ioutei with the lowest IP auuiess is electeu the gueiiei anu peiiouically
geneiates geneial gueiies to upuate its knowleuge ol host-to-gioup Linuings on this
LAN, as shown in step 2. All multicast-capaLle hosts ieceive the geneial gueiy, anu
altei a ianuomizeu uelay, one ol the inteiesteu hosts will iealliim the gioup Linuing Ly
geneiating a coiiesponuing iepoit message, which is shown in step 3. Othei inteiesteu
hosts suppiess theii iepoits upon seeing a matching iepoit sent Ly any othei noue on
Multicast Protocols | 535
the segmentthe same level ol multicast ieplication anu loiwaiuing is neeueu, Le theie
one oi 1,000 inteiesteu hosts on a given segmenttheieloie, only one iepoit is neeueu
to keep the gioup Linuing active.
Figuie 11-10 goes on to show an IGMPv2 leave piocess.
Iigurc 11-10. |GMPv2 |cavc proccss
Latei on, the ieceiving host no longei uesiies content liom gioup 225.0.0.1. It geneiates
an IGMPv2 gioup-leave message, which is auuiesseu to 22+.0.0.2, the all-iouteis mul-
ticast auuiess. The gueiiei ioutei now geneiates a gioup-specilic gueiy, which is au-
uiesseu to the multicast auuiess ol the ielateu gioup, in oiuei to ueteimine whethei
any inteiesteu listeneis iemain. Il so, one will Le the liist to geneiate a gioup iepoit,
which keeps the Linuing active. Otheiwise, altei a small uelay, the gioup join state is
iemoveu liom the associateu inteilace. The suppoit ol gioup leaves anu geneial gueiies
can gieatly ieuuce join anu leave latency. Foi example, in IGMPv1, the iouting piotocol
must geneiate thiee gueiies Leloie iemoving join statewith the uelault 60-seconu
timei, this eguates to 1S0 seconus ol continueu multicast ueliveiy altei the last intei-
esteu host has lelt the gioup.
IGMPv3
IGMPv3 auus the concept ol a souice-specilic join, which in tuin enaLles souice-
specilic multicast (SSM). The new capaLility allows a host to liltei multicast content
Ly gioup, as well as Ly souice. Vith IGMPv1 oi IGMPv2, a host simply has no way to
expiess inteiest in a paiticulai souice, anu theieloie has to ieceive tiallic liom all active
senueis to that gioup. Because a souice-specilic join explicitly iuentilies the uesiieu
souice, an SPT can Le instantiateu without the seivices ol an RP. Figuie 11-11 shows
IGMPv3 SSM opeiation.
In Figuie 11-11, oui tiusty ieceivei (which is now IGMPv3-enaLleu) is tolu Ly its mul-
ticast application to subscribc to the multicast channc| iuentilieu Ly the tuple
536 | Chapter 11:IP Multicast in the Enterprise
10.0.2.1,225.0.0.1. At the same time, the application instiucts the machine to unsuL-
sciiLe liom the 10.0.10.2.225.0.0.1 channel. SSM uses the teim channc| in a mannei
analogous to the woiu group in ASM. Similaily, the teims subscribc anu unsubscribc
uesciiLe what in ASM is calleu join anu |cavc. Note that the same piotocol lielus anu
values aie useu; the mouilieu teiminology simply helps to uisamLiguate which moue
is Leing uiscusseu, anu moie coiiectly uesciiLes ASM opeiation. SuLsciiLing to an (S,G)
is somewhat like tuning into a specilic meuia channel when compaieu to IGMPv2`s
Lehavioi ol uiawing tiallic liom all souices in the gioup. Note that IGMPv3 gioup
iepoit messages aie sent to all IGMPv3-capaLle multicast iouteis with a multicast au-
uiess ol 22+.0.0.22, iathei than to the multicast auuiess ol the gioup specilieu in the
gioup auuiess ol the iepoit message itsell, as is uone in veisions 1 anu 2.
The iesult, shown at step 1, is the ieceivei geneiating an IGMPv3 iepoit that specilically
lists the souices (anu gioups) loi which content is uesiieu. The same message can also
Le useu to iemove any pieviously suLsciiLeu-to souices. The LAN`s uesignateu ioutei
tianslates the IGMP iepoit into the appiopiiate PIM join anu piune messages, which
in this context aie ieleiieu to as suLsciiLe anu unsuLsciiLe, iespectively.
Iigurc 11-11. |GMPv3 SSM opcration
Multicast Protocols | 537
PIM
Seveial multicast iouting piotocols aie still in use, Lut Ly lai the most wiuely ueployeu
is PIM. PIM was uesigneu to avoiu the uense-moue scaling issues ol DVMRP anu the
potential peiloimance pioLlems ol Coie-Baseu Tiee (CBT) at the same time. PIM sup-
poits uense moue, spaise moue, anu spaise-uense moues ol opeiation, anu it has Leen
in piouuction use loi seveial yeais.
PIM is a iapiuly evolving Inteinet specilication. PIM has seen two majoi ievisions to
its piotocol opeiation (anu packet stiuctuie)PIM veision 1 anu PIM veision 2thiee
majoi RFCs (RFC +601 oLsoleteu RFC 2362, which in tuin oLsoleteu RFC 2117), anu
numeious uialts uesciiLing majoi components ol PIM. Voik continues on PIM in a
numLei ol aieas, such as Liuiiectional tiees, anu the iapiu pace ol uevelopment gen-
eiates numeious PIM-ielateu Inteinet uialts.
PIM versions
PIMv1 anu PIMv2 can coexist on the same ioutei, Lut not on the same inteilace. The
main uilleience Letween PIMv1 anu PIMv2 is the packet loimat. PIMv1 messages use
IGMP packets, wheieas PIMv2 has its own IP piotocol numLei (103) anu packet stiuc-
tuie. All iouteis connecting to a shaieu IP suLnet must use the same PIM veision.
Because the uilleience Letween PIMv1 anu PIMv2 simply involves the message loimat,
not the semantics oi message piocessing iules, a ioutei can easily suppoit a mix ol
PIMv1- anu PIMv2-enaLleu inteilaces.
In this chaptei, we aie locusing on PIMv2 opeiating in spaise moue Lecause this iep-
iesents the most common usage ol PIM in mouein IP inteinetwoiks.
PIM components
The components neeueu to iun PIM vaiy uepenuing on opeiational moue. PIM uense
moue ieguiies only multicast souices anu ieceiveis anu a seiies ol inteiconnecteu PIM
uense moue iouteis to allow ieceiveis to oLtain multicast content.
PIM spaise moue is moie complicateu Lecause it ieguiies the seivices ol an RP in the
netwoik coie. The RP is the ioot ol a shaieu tiee anu is the point wheie upstieam join
messages liom inteiesteu ieceiveis meet uownstieam tiallic liom multicast souices. Il
theie is only one RP in a iouting uomain, the RP anu aujacent links might Lecome
congesteu anu loim a single point ol lailuie loi all multicast tiallic. As a iesult, it is
common to see multiple RPs ueployeu within a multicast netwoik, loi Loth peiloim-
ance anu ieliaLility ieasons.
You can view PIM SSM as a suLset ol a special case ol PIM spaise moue, anu it ieguiies
no specializeu eguipment othei than that useu loi PIM spaise moue (anu IGMP
veision 3). Vhen a host senus an IGMPv3 join loi (S,G), the ieceiving uesignateu ioutei
initiates cieation ol the SPT Ly senuing an (S,G) join to its RPF neighLoi loi that souice.
538 | Chapter 11:IP Multicast in the Enterprise
Having one oi moie iouteis conliguieu as RPs is one thing, Lut how uo the
vaiious souices anu ieceiveis come to leain which iouteis aie acting as RPs, anu loi
which multicast gioups? You can take seveial appioaches to piopagate knowleuge ol
the iouting uomain`s RPs to client iouteis. They incluue:
Static
The simplest RP uiscoveiy mechanism is a static uelinition ol the RP`s auuiess anu
gioup ianges on each client. This appioach uoes not ieguiie any uynamic uiscoveiy
piotocols, Lut it is pione to ieliaLility issues in the event that the statically uelineu
RP lails, unless Anycast-RP is Leing useu. PIM veisions 1 anu 2 suppoit static RP
assignments.
Auto-RP
The auto-RP mechanism is a nonstanuaiu appioach (uevelopeu Ly Cisco Systems)
loi the uissemination ol RP inloimation. Despite the lack ol stanuaius, auto-RP is
suppoiteu in ]unos. The main uiawLack to auto-RP, asiue liom its nonstanuaiu
status, is the neeu loi uense-moue hanuling ol the two gioup auuiesses associateu
with auto-RP itsell. This ieguiiement loices spaise-uense moue opeiation on the
netwoik. The two auto-RP gioups aie 22+.0.1.39 (announce), which is useu to
leain which iouteis in the netwoik aie possiLle canuiuate RPs, anu 22+.0.1.+0
(uiscoveiy), which allows PIM iouteis to leain aLout the active gioup-to-RP map-
ping inloimation. In opeiation, one oi moie iouteis aie conliguieu to peiloim the
mapping lunction, which takes as input the set ol canuiuate RPs leaineu in uis-
coveiy messages anu geneiates as output the chosen RP-to-gioup mappings that
all iouteis shoulu use. Auto-RP uoes suppoit lailovei to Lackup RPs, Lut auto-RP
uoes not suppoit the aLility to loau-Lalance among multiple RPs loi the same gioup
iange. Auto-RP is suppoiteu in PIM veisions 1 anu 2.
Bootstrap
The BSR mechanism is the stanuaiuizeu way to uynamically communicate a uo-
main`s RP to gioup auuiess Linuings. Unlike auto-RP, BSR uoes not ieguiie any
uense-moue lloouing. This is Lecause Lootstiap messages aie piopagateu hop Ly
hop iathei than llooueu via multicast, which theieLy eliminates the cait-Leloie-
the-hoise issues ol auto-RP neeuing a woiking uense-moue multicast inliastiuctuie
Leloie an RP can Le communicateu. The Lootstiap mechanism is suppoiteu in PIM
veision 2 only. You can conliguie multiple canuiuate BSRs loi ieuunuancyit is
common to have the same iouteis conliguieu as canuiuate RPs to Le set as canui-
uate BSRs also.
Once the BSR is electeu (the ioutei with the highest BSR piioiity), each canuiuate
RP auveitises its conliguieu gioup ianges. The BSR piocesses the ieceiveu auvei-
tisements, Laseu in pait on lactois such as local policy, gioup iange specilicity,
conliguieu RP piioiity, anu so on. The iesulting RP set is communicateu to all PIM
iouteis, at which point each ioutei is ieguiieu to iun its own hash to ueteimine
the RP loi a given gioup. It is impoitant to note that the hash algoiithm ensuies
that all iouteis select the same RP-to-gioup mappings liom the inloimation in the
RP discovery.
Multicast Protocols | 539
uomain`s RP set, anu when multiple canuiuate RPs aie piesent, the algoiithm au-
tomatically loau-Lalances Letween those RPs. Stateu uilleiently, il two RPs Loth
announce the uelault 22+/+ iange, Lootstiap opeiation iesults in each RP hanuling
one-hall ol the active gioups. The lailuie ol one RP iesults in all gioups Leing shilteu
to the iemaining RPhowevei, at no one time can multiple RPs Le active loi the
same gioup when using Lootstiap.
Anycast-RP
PIM suppoits the notion ol Anycast-RPs, which Lypasses the iestiiction ol having
one active RP pei multicast gioup. Vith Anycast-RP, you can ueploy multiple RPs
loi the same gioup iange. Anycast-RP pioviues ieuunuancy anu loau Lalancing,
Lut unlike Lootstiap, Anycast-RP can Lalance tiallic liom souices within the
sanc gioup. Vith Anycast-RP, the vaiious RPs shaie a common unicast IP auuiess,
such that clients simply choose the metiically closest ioute to the shaieu RP au-
uiess. In the event ol RP lailuie, the IGP simply ieioutes to the next Lest path to
the shaieu IP auuiess, thus pieseiving connectivity. Foi piopei opeiation, is it
ciitical that each Anycast-RP Le awaie ol active souices using othei Anycast-RPs.
This RP-to-RP communication can Le peiloimeu using MSDP, as uelineu in RFC
3++6, oi using the newei, PIM-only appioach uelineu in RFC +610. Both methous
aie suppoiteu in ]unos.
PIM modes
PIM can opeiate in uense, spaise, spaise-uense, oi SSM moue. Although in this chaptei
we aie emphasizing PIM spaise moue in suppoit ol ASM, loi completeness we will
expanu on the vaiious moues heie.
PIM uense moue is uselul loi multicast LAN applications, the main envi-
ionment loi all uense moue piotocols. PIM uense moue uses the same lloou liist, piune
latei appioach associateu with DVMRP. The main uilleience Letween DVMRP anu
PIM uense moue is that PIM pioviues piotocol inuepenuence anu can use the ioute
taLle populateu Ly any unueilying unicast iouting piotocol to peiloim RPF checks.
PIM uense moue suppoits the ASM mouel.
PIM spaise moue is the most common way to ueploy PIM. Spaise moue
opeiation is consiueiaLly moie complex than uense moue, Lut spaise moue olleis the
Lenelit ol Lanuwiuth conseivation, which olten moie than justilies the auueu com-
plexity. The vaiious conliguiation examples shown in this chaptei aie Laseu on PIM
spaise moue. The key aspect ol spaise moue opeiation is the neeu loi an RP to seive
as a liaison Letween active senueis anu any ieceiveis that wish to oLtain theii content.
A PIM spaise moue ioutei joins the RP-Laseu shaieu tiee upon ieceipt ol an IGMP join
liom attacheu ieceiveis. This is known as an (',G) join Lecause it matches any souice
senuing to that gioup. Il any souices aie active loi that gioup, theii packets aie sent
uown the shaieu tiee until they ieach the last hop ioutei (the ioutei uiiectly attacheu
to the ieceivei) anu aie ueliveieu to the ieceivei(s) on that netwoik segment. Receipt
Dense mode.
Sparse mode.
540 | Chapter 11:IP Multicast in the Enterprise
ol tiallic ovei the shaieu tiee allows the last hop ioutei to leain the auuiess ol active
souices, at which point it initiates an SPT Ly senuing an (S,G) ovei the RPF path towaiu
each souice. Once the SPT is estaLlisheu, the last hop ioutei piunes that souice liom
the shaieu tiee Ly senuing an (S,G) piune. This tiansitional aspect ol PIM spaise moue
liom shaieu to souice-Laseu tiee is one ol the majoi attiactions ol PIM. This leatuie
pievents oveiloauing the RP oi suiiounuing coie links, which was the Achilles` heel ol
the CBT appioachwhich has yet to see commeicial ueployment.
PIM spaise moue suppoits the ASM anu SSM mouels.
The oiiginal multicast RFCs specily Loth many-to-many anu one-
to-many mouels. These moues aie now known as ASM Lecause ASM suppoits one oi
many souices loi a multicast gioup`s tiallic. Howevei, ASM opeiation ieguiies that
ieceiveis Le aLle to ueteimine the locations ol a|| souices loi a paiticulai multicast
gioup, no mattei wheie the souices might Le locateu in the netwoik. In ASM, sourcc
discovcry is a ciitical anu complex lunction within the netwoik.
ASM makes sense in a highly uynamic enviionment wheie souices olten come anu go,
as, loi example, in a viueoconleiencing seivice. Howevei, seveial piomising multicast
applications, such as IP-Laseu television, aie Leing Liought to commeicial iealization
guickly anu elliciently thiough an assumption that theie is a longei-liveu single souice
loi some paiticulai content. PIM SSM is simplei than PIM spaise moue Lecause only
the one-to-many mouel is suppoiteu. PIM SSM theieloie loims a suLset ol PIM spaise
moue. It Luilus only SPTs, anu an RP is no longei necessaiy, given that the usei specilies
the souice auuiess as pait ol his IGMPv3 iepoit message.
PIM SSM can coexist with ASM Ly conlining the SSM mouel to a suLset ol the IP
multicast gioup auuiess iange. The IANA has ieseiveu the auuiess iange 232.0.0.0
232.255.255.255 loi SSM opeiation. ]unos allows SSM conliguiation loi the entiie
iange ol IP multicast auuiesses (22+.0.0.0239.255.255.255). Vhen a custom SSM
iange is uelineu, legacy IP multicast applications cannot ieceive any tiallic loi gioups
in that SSM iange, unless the application is mouilieu to suppoit SSM (S,G) channel
suLsciiption.
PIM messages
PIM uses a vaiiety ol message types to uo its joL. The ieauei is encouiageu to consult
the appiopiiate RFC loi an exhaustive uesciiption ol each lielu lounu in the vaiious
PIM messages. Oui puipose heie is to uesciiLe how these PIM messages opeiate to
estaLlish SSM opeiation:
join/prunc
PIM state is estaLlisheu anu withuiawn using join/piune messages. An inuiviuual
message may contain Loth join anu piune inloimation, join inloimation (a join
message) only, oi piune inloimation (a piune message) only. A single join/piune
message can list multiple senueis/gioups to join oi piune.
Source-specific multicast.
Multicast Protocols | 541
Rcgistcr
Routeis connecteu to a multicast souice encapsulate the multicast uata stieam into
unicast packets that aie auuiesseu to the RP that seives that gioup iange. A PIM
iegistei message contains an encapsulateu multicast packet, which can Le sent to
the RP without the neeu loi multicast tianspoit Letween the senuei anu the RP.
Once ieceiveu Ly the RP, the iegistei encapsulation is stiippeu anu the RP loiwaius
native multicast packets uown the shaieu RPT.
Rcgistcr stop
The RP may wish to stop ieceiving the encapsulateu multicast tiallic liom the liist
hop ioutei, anu the iegistei-stop message is useu to accomplish this goal. An RP
may wish to stop ieceiving iegistei-encapsulateu messages loi seveial ieasons:
The RP has no join state loi the gioup auuiess ol the tiallic (theie aie no intei-
esteu listeneis on the RPT).
The RP may have ieceiveu a piune message liom the netwoik loi a gioup Leing
loiwaiueu along the RPT, peihaps as the iesult ol SPT estaLlishment leaving no
inteiesteu ieceiveis.
The RP itsell might Le ieceiving the multicast tiallic natively liom the netwoik
along an SPT.
The designated router
PIM uelines specilic lunctions loi the liist anu last hop iouteis, which aie known as
uesignateu iouteis. The uesignateu ioutei senus iegistei anu join/piune messages on
Lehall ol uiiectly connecteu senueis anu ieceiveis, iespectively. The uesignateu ioutei
may oi may not Le the same ioutei as the IGMP gueiiei.
On multiaccess netwoiks, a uesignateu ioutei is electeu to ensuie that packets anu PIM
contiol state aie not uuplicateu. In opeiation, PIM neighLois on a shaieu LAN peii-
ouically senu PIM Hello messages to each othei. The senuei with the highest IP auuiess
Lecomes the uesignateu ioutei loi that LAN segment.
PIM suppoits an asseit mechanism that pievents ongoing packet uuplica-
tion, which can occui when theie aie paiallel paths to a souice oi the RP. Fig-
uie 11-12 shows the PIM asseit piocess in action.
The liguie shows thiee iouteis, R1R3, connecteu to a shaieu LAN, along with an RP
anu a souice loi gioup 225.0.0.1. The liguie also shows the IGP metiics to ieach the
souice, as seen Ly iouteis R1 anu R2. In this example, Loth R1 anu R2 have auueu the
multicast souice to theii OIL loi theii LAN attacheu inteilace. As a iesult, a packet sent
liom the souice is ieplicateu anu loiwaiueu Ly Loth R1 anu R2, iesulting in an extia
copy ol the packet on the LAN segment. To pievent ongoing occuiiences, the PIM
asseit piocess is staiteu, Ly which the upstieam PIM iouteis asseit theii iight to Le the
uesignateu loiwaiuei Ly senuing asseit messages to the 22+.0.0.13 (ALL-PIM-
ROUTERS) gioup multicast auuiess. Each ioutei places its IGP pieleience anu coiie-
sponuing metiic to the souice in its asseit message. The ioutei with the Lest pieleience,
PIM assert.
542 | Chapter 11:IP Multicast in the Enterprise
oi lowest metiic, wins (metiics aie compaieu only in the event ol a pieleience tie). In
the event ol a metiic tie, the ioutei with the highest IP auuiess wins. Figuie 11-12 also
shows that R1 has a Lettei metiic anu theieloie Lecomes the loiwaiuei loi the LAN
segment. Meanwhile, uownstieam ioutei R3 has eavesuioppeu on the asseit Lattle anu
takes note ol the victoi Lecause this is the ioutei to which R3 will suLseguently senu
joins loi that souice.
PIM asseits aie also neeueu loi (',G) entiies. This is Lecause the RPT anu SPT loi a
given gioup may tiansit a shaieu meuia link such as a LAN. In these cases, the asseit
mechanism ueteimines which ol the two tiees will caiiy the packet on the shaieu links,
again to avoiu unneeueu packet uuplication. Accoiuing to the specilications, an SPT
is always pieleiieu ovei an RPT. Vhen theie aie multiple paths to the RP thiough the
LAN, the uesignateu ioutei may lose the (',G) asseit piocess to anothei ioutei on the
LAN. As a iesult, that ioutei ceases to Le the uesignateu ioutei loi local ieceiveis on
that LAN, anu the victoi Lecomes the last hop ioutei anu is theieloie iesponsiLle loi
senuing (',G) join messages to the RP.
Iigurc 11-12. Thc P|M asscrt proccss
Multicast Protocols | 543
Multicast Protocol Summary
This section uetaileu the lunction ol gioup management piotocols, which allow iouteis
to ueteimine which inteilaces have attacheu listeneis anu allow multicast iouting pio-
tocols that pioviue loi RPF checking anu manage join anu piune states.
Ve also uiscusseu the use ol shaieu anu souice-specilic tiees, as well as the iole ol the
RP in suppoiting ASM anu SSM.
In the next section, we will put multicast theoiy to the test with a PIM spaise moue
ueployment scenaiio using a static RP.
PIM Sparse Mode: Static RP
At this stage, you shoulu have an extensive giounuing in IP multicast theoiy in geneial,
anu in PIM spaise moue opeiation in paiticulai. This knowleuge is soon to Leai liuit
as you conliguie anu valiuate the opeiation ol PIM spaise moue using a statically ue-
lineu RP with ]unipei Netwoiks` iouteis.
The initial PIM spaise moue ueployment goals aie as lollows:
Conliguie ioutei PBR as an RP loi the entiie multicast auuiess iange.
Conliguie all othei iouteis to use PBR as the uomain`s RP without using BSR oi
auto-RP.
Conliguie Cider to lunction as a multicast ieceivei loi gioup 225.1.1.1.
Use Ale as a multicast souice to geneiate tiallic to gioup 225.1.1.1.
Veiily RPT join anu suLseguent tiallic-uiiven switches to SPT.
Figuie 11-13 uetails the poition ol Beei-Co`s netwoik that is to Le enaLleu loi multicast
suppoit. The liguie also highlights key aspects ol the IGP iouting inliastiuctuie now
in place.
Details to note in Figuie 11-13 incluue the lollowing:
The uelault OSPF Lanuwiuth scaling lactoi is in ellect with the exception ol PBR`s
enu ol the PBRLager link (asymmetiic) anu the PBRBock link. The metiic loi these
links has Leen alteieu in an elloit to lavoi the LagerStoutPorter path loi com-
munications Letween Ale anu Cider.
Routei Ale is conliguieu to emulate a host senuing to a multicast gioup. Ale uses
a uelault ioute pointing to the viitual IP (VIP) auuiess associateu with the PBR
Lager Viitual Routei Reuunuancy Piotocol (VRRP) gioup. No iouting oi multicast
piotocols aie enaLleu at Ale.
Cider is useu to simulate a PIM-enaLleu ioutei with a uiiectly attacheu multicast
ieceivei.
544 | Chapter 11:IP Multicast in the Enterprise
Validate the Baseline IGP Forwarding Path
Beloie staiting any multicast conliguiation, a guick conliimation ol IGP connectivity
anu the iesulting loiwaiuing paths thiough the netwoik is peiloimeu. The use ol a
uelault ioute is conliimeu at Ale, as is the use ol the Lager, Stout, anu Porter loiwaiuing
paths loi communications Letween Ale anu Cider:
[edit]
lab@Ale# run show route 10.10.12.1
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 00:00:04
> to 10.10.111.10 via ge-0/0/0.111
[edit]
lab@Ale# run traceroute 10.10.12.1 no-resolve
traceroute to 10.10.12.1 (10.10.12.1), 30 hops max, 40 byte packets
1 10.10.111.3 11.837 ms 9.735 ms 10.115 ms
2 10.10.131.2 19.716 ms 20.203 ms 9.681 ms
3 10.20.131.1 10.109 ms 10.395 ms 9.298 ms
4 10.10.12.1 20.214 ms 9.747 ms 19.893 ms
Symmetiical loiwaiuing in the ietuin path liom Cider to Ale is also conliimeu, as is the
use ol OSPF iouting at Cider; iecall that unlike Ale, which is iunning no iouting pio-
tocols, Cider simulates a PIM/OSPF-enaLleu ioutei with an attacheu ieceivei:
[edit]
lab@Cider# run traceroute 10.10.128.1 no-resolve
traceroute to 10.10.128.1 (10.10.128.1), 30 hops max, 40 byte packets
1 10.10.11.2 9.945 ms 9.711 ms 9.856 ms
2 10.20.131.2 20.054 ms 39.955 ms 19.863 ms
3 10.10.131.1 19.854 ms 18.125 ms 31.839 ms
4 10.10.128.1 19.792 ms 19.949 ms 20.214 ms
[edit]
Iigurc 11-13. Bccr-Co`s nu|ticast topo|ogy
PIM Sparse Mode: Static RP | 545
lab@Cider# run show route 10.10.128.1
inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.128.1/32 *[OSPF/150]
00:20:10, metric 0, tag 0
> to 10.10.11.2 via ge-0/0/1.100
The OSPF ioute to the loopLack auuiess ol Ale is seen as an OSPF exteinal Ly ioutei
Cider. This is Lecause a static ioute iepiesenting Ale`s lo0 auuiess is ieuistiiLuteu into
OSPF at iouteis PBR anu Lager, which is necessaiy heie given that Ale uoes not paitic-
ipate in OSPF iouting. The 111 VRRP gioup shaieu Ly PBR anu Lager is conliguieu to
make Lager the VRRP mastei when its ge-0/0/0.111 inteilace is opeiational via the
preempt keywoiu anu a piioiity ol 100the accept-data option is auueu to peimit
uiagnostic ping testing to the VIP. Accoiuing to the VRRP RFC, the VIP is alloweu to
iesponu only to Auuiess Resolution Piotocol (ARP) ieguests, meaning that unlike
Cisco`s HSRP, Ly uelault you cannot ping the VIP associateu with a VRRP gioup.
Lager`s static ioute, ielateu ieuistiiLution policy, anu VRRP conliguiation aie shown.
PBR has a similai conliguiation, except that its VRRP piioiity is set to 50:
[edit]
lab@Lager# show routing-options
static {
route 10.10.128.1/32 next-hop 10.10.111.1;
}
[edit]
lab@Lager# show policy-options
policy-statement Ale_lo0 {
term 1 {
from {
protocol static;
route-filter 10.10.128.1/32 exact;
}
then accept;
}
}
[edit]
lab@Lager# show interfaces ge-0/0/0 unit 111
description Lager_PBR_Ale;
vlan-id 111;
family inet {
address 10.10.111.3/24 {
vrrp-group 69 {
virtual-address 10.10.111.10;
priority 100;
preempt;
accept-data;
}
}
}
546 | Chapter 11:IP Multicast in the Enterprise
Configure PIM Sparse Mode with Static RP
Vith the unueilying IGP`s opeiation conliimeu, you move on to PIM conliguiation on
the iouteis making up the multicast test Leu. In the ]unos implementation, enaLling
PIM on an inteilace automatically enaLles IGMPv2, making explicit conliguiation ol
IGMP unnecessaiy unless you neeu to mouily uelault settings. IGMP is not ieguiieu
on links that connect only iouteishosts use IGMP to inloim iouteis ol theii gioup
memLeiship. Leaving IGMP enaLleu on these links uoes not leau to appieciaLle ie-
souice consumption anu ensuies that things will woik as expecteu il hosts aie auueu
at a latei time.
PIM conliguiation Legins at ioutei PBR Lecause it`s Leen uesignateu as the RP in the
initial multicast topology; without an RP, PIM spaise moue cannot Legin to opeiate.
PIM is conliguieu at the [edit protocols pim] hieiaichy. The conliguiation options
loi PIM aie uisplayeu:
[edit protocols pim]
lab@PBR# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
assert-timeout Set assert timeout (5..210)
> default-vpn-source Let all VRFs use master loopback address for mt interface
> dense-groups Dense mode groups for sparse-dense mode
disable Disable PIM
dr-election-on-p2p Enable DR election on Point-to-Point Interaces
+ export PIM sparse export join policy
> family Local address family
> graceful-restart Configure graceful restart attributes
+ import PIM sparse import join policy
> interface PIM interface options
> join-load-balance Configure PIM join load balancing
join-prune-timeout Set join/prune timeout (210..420)
no-wildcard-register-stop Disable sending of wildcard register stop message
> nonstop-routing Configure PIM nonstop-routing attributes
> rib-group Routing table group
> rp Router's rendezvous point properties
> spt-threshold Set shortest-path-tree threshold policy
> traceoptions Trace options for PIM
The assert-timeout setting ueteimines how olten the loiwaiuing ioutei ieasseits its
iight to uo so, Laseu on its Leliel that it has the lowest SPF RPF cost loi a given souice
oi RP; the ioutei always geneiates an asseit message when a multicast packet is rc-
ccivcd on an inteilace that is in the outgoing inteilace list loi a given gioup. Inteinal
iate-limiting ol these event-uiiven asseit messages (as with all contiol plane messaging
in ]unos) ensuies that the netwoik anu local piocessing iesouices aie not oveiiun in
the event ol a packet loop oi Lioken multicast loiwaiuing state in an aujacent noue.
The dense-groups conliguiation iuentilies any gioups that aie llooueu in uense moue
ovei inteilaces set loi spaise-uense moue opeiation. This setting is useu when you
opeiate in spaise moue Lut you still want uense moue lloouing on a gioup-Ly-gioup
PIM Sparse Mode: Static RP | 547
D
o
Lasis, anu it is typically useu to suppoit auto-RP`s neeu loi uense moue lloouing ol its
announce (22+.0.1.39) anu uiscoveiy (22+.0.1.+0) messages.
The graceful-restart anu nonstop-routing settings contiol these leatuies loi PIM
when they aie enaLleu gloLally. The import anu export keywoius link to one oi moie
policies that allow lilteiing ol join messages, which pievents the iesulting (',G) oi (S,G)
state, theieloie Llocking the extent ol multicast tiallic uistiiLution Ly pieventing in-
stallation ol ielateu loiwaiuing state in the contiol plane. In contiast, multicast scoping
opeiates in the data plane to pioviue a similai ellect. Geneially speaking, the use ol
scoping is pieleiieu ovei join lilteiing Lecause the loimei scales Lettei, anu it pievents
the tianspoit ol multicast tiallic that coulu iesult liom the use ol uense moue lloouing
oi a packet geneiation tool.
The spt-threshold ueteimines whethei the local ioutei attempts a switch to an SPT
altei the liist packet (uelault), oi nevei when set to inlinity. The use ol multicast uis-
tiiLution tiee (MDT) tunnels anu iouting inloimation Lase (RIB) gioups is Leyonu the
scope ol this Look. Sullice it to say that MDT tunnels aie useu to suppoit PIM spaise
moue in a Layei 3 viitual piivate netwoik (VPN) enviionment, anu that use ol RIB
gioups allows a PIM multicast loiwaiuing topology that is inuepenuent ol the unicast
RPF taLle.
The interface keywoiu allows specilication ol which inteilaces shoulu iun PIM, along
with inteilace-level paiameteis such as PIM veision, hello time, anu so on. The options
availaLle at the [edit protocols pim interface interface-name ] hieiaichy aie:
[edit protocols pim]
lab@PBR# set interface ge-0/0/0.111 ?
Possible completions:
<[Enter]> Execute this command
accept-remote-source Accept traffic from remote source
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> bfd-liveness-detection Bidirectional Forwarding Detection options
disable Disable PIM on this interface
> family Local address family
hello-interval Hello interval (0..255 seconds)
mode Mode of interface
+ neighbor-policy PIM neighbor policy applied to incoming hello messages
priority Hello option DR priority (0..4294967295)
version Force PIM version (1..2)
| Pipe through a command
Most inteilace-level options aie sell-explanatoiy. The piioiity setting specilieu unuei
an inteilace contiols the ioutei`s likelihoou ol Leing electeu the PIM uesignateu ioutei
on that netwoik segment; the uelault setting is 1, making the ioutei least likely to Le
the uesignateu ioutei. The mode keywoiu ueteimines whethei the associateu PIM in-
teilace opeiates in spaise, uense, oi spaise-uense moue. Vhen an inteilace is in spaise-
uense moue, the list ol gioups specilieu with the dense-groups keywoiu is llooueu in
uense moue, anu all othei gioups aie hanuleu as spaise.
548 | Chapter 11:IP Multicast in the Enterprise
You conliguie a ioutei to Le an RP, oi to leain aLout othei RPs using eithei the static,
Lootstiap, auto-RP, oi Anycast-RP mechanism unuei the [edit protocol pim rp] hi-
eiaichy. The conliguiation options availaLle at this hieiaichy aie:
[edit protocols pim]
lab@PBR# set rp ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> auto-rp Set auto-RP mode (IPv4 only)
> bootstrap Bootstrap properties
+ bootstrap-export Bootstrap export policy (IPv4 only)
+ bootstrap-import Bootstrap import policy (IPv4 only)
bootstrap-priority Eligibility to be the bootstrap router (IPv4 only)
+ dr-register-policy DR policy applied to outgoing register messages
> embedded-rp Set embedded-RP mode (IPv6 only)
> local Router's local RP properties
+ rp-register-policy RP policy applied to incoming register messages
> static Configure static PIM RPs
As you woulu expect, the piopeities that contiol auto-RP-Laseu RP election aie con-
liguieu unuei the Auto-RP hieiaichy. Auto-RP is not uemonstiateu heie Lecause it has
lost lavoi to BSR-Laseu election loi ieasons that weie citeu pieviously. Seveial
Lootstiap-ielateu conliguiation keywoius aie useu in Lootstiap-Laseu RP election
we will skip these knoLs loi now Lecause we will exploie them in a suLseguent BSR
conliguiation example.
The dr-register-policy anu rp-register-policy keywoius link to policy statements
that liltei iegistei messages sent Ly the uesignateu ioutei oi liltei iegistei messages
ieceiveu Ly the RP, iespectively. This leatuie allows you to contiol the numLei ol soui-
ces that a given RP can know aLout, anu that might Le useu loi peiloimance oi secuiity-
ielateu ieasons. The embedded-rp hieiaichy contiols the numLei ol emLeuueu RPs, as
well as gioups that can contain an emLeuueu RP auuiess. EmLeuueu RP is useu loi
inteiuomain IPv6 multicast anu is Leyonu the scope ol this Look. Note, howevei, that
IPv+ inteiuomain multicast is noimally associateu with MSDP.
Static uelinition ol an RP is peiloimeu with the static keywoiu. A statically conliguieu
RP eliminates the neeu loi uynamic RP election, Lut this simplicity can come at the cost
ol ieuuceu ieliaLility Lecause iouteis may continue to use an RP that has ceaseu lunc-
tioning. Howevei, the use ol a statically uelineu RP, in conjunction with Anycast-RP,
alleviates many ol these conceins, anu we uiscuss it in uetail in PIM Spaise Moue with
Anycast-RP Summaiy on page 590.
Configure PIM on the RP
Local RP chaiacteiistics aie uelineu unuei the [edit protocols pim local] hieiaichy,
anu aie useu when the local ioutei lunctions as an RP. Because PBR is the PIM uomain`s
RP in this example, youi conliguiation Legins at PBR with the specilication ol its local
PIM Sparse Mode: Static RP | 549
RP piopeities. The commanu-line inteilace`s (CLI`s) ? lunction uisplays the conligu-
iation moue set options availaLle at the [edit protocols pim rp local] hieiaichy:
[edit protocols pim rp local]
lab@PBR# lab@PBR# set ?
Possible completions:
address Local RP address (IPv4 only)
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
disable Disable this RP (IPv4 only)
> family Local RP address family
> group-ranges Group address range for which this router can be an RP
(IPv4 only)
hold-time How long neighbor considers this router to be up, in seconds
(IPv4 only)
priority Router's priority for becoming an RP (IPv4 only) (0..255)
Use the address keywoiu to ueline the local RP auuiess loi IPv+ opeiation. Noimally,
this will Le a gloLally ioutaLle auuiess (i.e., a non-127.x.x.x auuiess) assigneu to the
ioutei`s lo0 inteilace loi maximum ieliaLility, given that the viitual natuie ol a loop-
Lack inteilace tenus to make it the last to lail. The family keywoiu is useu to conliguie
an IPv6-Laseu RP unuei the inet6 lamily. You may wish to uiviue the multicast auuiess
space among multiple RPs using the group-ranges keywoiu to help spieau piocessing
loau oi to impiove oveiall ioLustness Ly eliminating a potential single point ol lailuie
loi all multicast gioups in the uomain.
The conliguieu hold-time value is incluueu in canuiuate RP messages (sent to a uo-
main`s Lootstiap ioutei when using BSR), anu it ueteimines how long the BSR incluues
that RP in the canuiuate RP set Leloie the entiy neeus to Le ieliesheu Ly ieceipt ol a
new canuiuate RP auveitisement loi that same RP. The priority value is useu in the
hash lunction that chooses a paiticulai RP loi a given gioup iange liom the set ol
canuiuate RPs. A numeiically smallei piioiity value is pieleiieuthe iange is liom 0
to 255, with 1 Leing the uelault. Note that a setting ol 0 inuicates that the BSR can
oveiiiue the ieceiveu RP-to-gioup mappings in the canuiuate RP set that it auveitises.
Because you aie conliguiing a static RP enviionment, only the address keywoiu is ol
concein in the cuiient conliguiation. Conliguie PIM Spaise Moue with Bootstiap
RP on page 56S uemonstiates BSR-Laseu RP election. PBR is conliguieu to use its
gloLally ioutaLle loopLack auuiess as the uomain`s RP:
[edit protocols pim rp local]
lab@PBR# set address 10.20.128.3
The inteilaces that shoulu iun PIM aie conliguieu next; theie is no neeu oi Lenelit to
iunning PIM on the lo0 inteilace, so tiansit inteilaces only aie enaLleu loi PIM. The
completeu PIM stanza at PBR is uisplayeu:
[edit protocols pim]
lab@PBR# show
rp {
local {
address 10.20.128.3;
550 | Chapter 11:IP Multicast in the Enterprise
}
}
interface ge-0/0/0.3141;
interface ge-0/0/0.1241;
interface ge-0/0/0.111;
Altei committing the changes to the local RP, status is conliimeu:
lab@PBR# run show pim rps
Instance: PIM.master
Address family INET
RP address Type Holdtime Timeout Groups Group prefixes
10.20.128.3 static 0 None 0 224.0.0.0/4
The output ol the show pim rps commanu shows that PBR is lunctioning as a statically
uelineu RP loi the entiie multicast auuiess 22+/+ gioup iange. You next veiily that PIM
is enaLleu on all tiansit inteilaces useu in the multicast test Leu with a show pim
interfaces commanu:
[edit protocols pim]
lab@PBR# run show pim interfaces
Instance: PIM.master
Name Stat Mode IP V State NbrCnt JoinCnt(sg) JointCnt(*g) DR address
ge-0/0/0.111 Up Sparse 4 2 DR 0 0 0 10.10.111.2
ge-0/0/0.1241 Up Sparse 4 2 DR 0 0 0 10.20.130.2
ge-0/0/0.3141 Up Sparse 4 2 DR 0 0 0 10.20.129.2
pd-0/0/0.32769 Up Sparse 4 2 P2P 0 0 0
The commanu output conliims that PIM is now iunning on all thiee ol PBR`s netwoik
inteilaces useu in the multicast test Leu, anu that spaise is the uelault moue ol opeia-
tion. Because PBR is the liist, anu so lai the only, PIM-enaLleu ioutei, it has won the
uesignateu ioutei election on all ol its multiaccess inteilaces; a uesignateu ioutei is not
ieguiieu on point-to-point inteilaces. The 0 count values inuicate that no PIM neigh-
Lois have Leen uetecteu, which is expecteu until othei iouteis aie enaLleu loi PIM, anu
that no joins have Leen ieceiveu, also expecteu at this point. The show pim neighbors
commanu ietuins an empty list at this time (not shown).
The highlighteu coue in the output calls out that the ioutei has automatically instan-
tiateu a PIM uecapsulation (pd) inteilace using the ]-seiies Luilt-in seivices inteilace
lunctionality. Recall that in spaise moue, the liist hop ioutei encapsulates multicast
into a unicast iegistei message (using a PIM encapsulate pe inteilace), which is then
uecapsulateu Lack to native multicast at the RP loi uistiiLution uown the shaieu tiee.
No explicit conliguiation is neeueu loi these pd anu pe inteilaces; they aie cieateu
automatically when PIM spaise moue is conliguieu anu the ieguiieu tunnel suppoit is
piesent. On some platloims, such as the M10i, you must oiuei anu install tunnel haiu-
waie to suppoit PIM spaise moue iegistei message encapsulation.
As noteu pieviously, in the ]unos OS, enaLling PIM automatically enaLles IGMP on
that inteilace. The output ol the show igmp interface commanu conliims that this is
the case:
PIM Sparse Mode: Static RP | 551
lab@PBR# run show igmp interface
Interface: ge-0/0/0.111
Querier: 10.10.111.2
State State: Up Timeout: None Version: 2 Groups: 2
Immediate leave: Off
Promiscuous mode: Off
Passive: Off
Interface: ge-0/0/0.1241
Querier: 10.20.130.1
State: Up Timeout: None Version: 2 Groups: 2
Immediate leave: Off
Promiscuous mode: Off
Passive: Off
Interface: ge-0/0/0.3141
Querier: 10.20.129.1
State: Up Timeout: None Version: 2 Groups: 2
Immediate leave: Off
Promiscuous mode: Off
Passive: Off
Configured Parameters:
IGMP Query Interval: 125.0
IGMP Query Response Interval: 10.0
IGMP Last Member Query Interval: 1.0
IGMP Robustness Count: 2
Derived Parameters:
IGMP Membership Timeout: 260.0
IGMP Other Querier Present Timeout: 255.
Configure PIM on remaining routers
Vith the uomain`s RP up anu iunning, you move on to auu PIM to the iemaining
iouteis. Asiue liom specilying PIM-enaLleu inteilaces, you must also specily the uo-
main`s RP explicitly, as this is a static RP scenaiio. The PIM conliguiation auueu to
Stout is shown. All iemaining iouteis have a similai PIM conliguiation:
[edit protocols pim]
lab@stout#show
rp {
static {
address 10.20.128.3;
}
}
interface ge-0/0/0.2131;
interface ge-0/0/0.3141;
interface ge-0/0/1.1331;
The key to this PIM spaise moue conliguiation is the static uelinition ol the uomain`s
RP, which in this example is PBR`s lo0 auuiess. Vhen uesiieu, you can luithei ueline a
static RP`s gioup iange anu PIM veision:
[edit protocols pim]
lab@stout# set rp static address 10.20.128.3 ?
Possible completions:
552 | Chapter 11:IP Multicast in the Enterprise
<[Enter]> Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> group-ranges Group address range of RP
version PIM version of RP (1..2)
In this example, the uelault veision 2 anu 22+/+ gioup iange aie uesiieu, so no luithei
changes aie neeueu. Altei the changes aie committeu, you conliim the piesence ol PIM
neighLois at ioutei Stout:
[edit protocols pim]
lab@stout# run show pim interfaces
Instance: PIM.master
Name Stat Mode IP V State NbrCnt JoinCnt(sg) JointCnt(*g) DR address
ge-0/0/0.2131 Up Sparse 4 2 DR 1 0 0 10.10.131.2
ge-0/0/0.3141 Up Sparse 4 2 NotDR 1 0 0 10.20.129.2
ge-0/0/1.1331 Up Sparse 4 2 DR 1 0 0 10.20.131.2
pe-0/0/0.32769 Up Sparse 4 2 P2P 0
The uisplay shows that Stout has uetecteu one PIM neighLoi on all Lut its pe encap-
sulation inteilace, which is expecteu given this setup. The output also shows that the
local ioutei is the uesignateu ioutei loi two ol its thiee netwoik inteilaces. To uisplay
neighLoi inloimation, issue a show pim neighbors commanu:
lab@stout# run show pim neighbors
Instance: PIM.master
Interface IP V Mode Option Uptime Neighbor addr
ge-0/0/0.2131 4 2 HPLG 00:18:12 10.10.131.1
ge-0/0/0.3141 4 2 HPLG 00:18:12 10.20.129.2
ge-0/0/1.1331 4 2 HPLG 00:18:12 10.20.131.1
The uisplay shows the IP auuiess ol each uetecteu PIM neighLoi, the associateu intei-
lace, anu the suppoiteu IP/PIM veision. The Moue column is expecteu to Le empty
when conliguieu loi PIMv2 Lecause v2 suppoits uense, spaise, anu spaise-uense
moues. The Option column uisplays a coueu list ol each neighLoi`s suppoiteu PIM
options. The coues aie inteipieteu as lollows:
B
Biuiiectional-capaLle
H
Hello option holu time
G
Geneiation iuentiliei
P
Hello option uesignateu ioutei piioiity
L
Hello option LAN piune uelay
PIM Sparse Mode: Static RP | 553
Auu the detail switch to view the specilic timeis anu paiameteis associateu with each
neighLoi:
[edit protocols pim]
lab@stout# run show pim neighbors detail
Instance: PIM.master
Interface: ge-0/0/0.2131
Address: 10.10.131.1, IPv4, PIM v2, Mode: Sparse, sg Join Count: 0tsg
Join Count: 0
Hello Option Holdtime: 65535 seconds
Hello Option DR Priority: 1
Hello Option Generation ID: 577499317
Hello Option LAN Prune Delay: delay 500 ms override 2000 ms
Address: 10.10.131.2, IPv4, PIM v2, Mode: Sparse
Hello Option Holdtime: 65535 seconds
Hello Option DR Priority: 1
Hello Option Generation ID: 756451044
Hello Option LAN Prune Delay: delay 500 ms override 2000 ms
The PIM neighLoi state is as expecteu at Stout. RP inloimation is uisplayeu with the
show pim rps commanu:
[edit protocols pim]
lab@stout# run show pim rps
Instance: PIM.master
Address family INET
RP address Type Holdtime Timeout Groups Group prefixes
10.20.128.3 static 0 None 0 224.0.0.0/4
Address family INET6
The output uisplays the loopLack auuiess associateu with ioutei PBR, which is lunc-
tioning as the Beei-Co uomain`s RP. Fuithei, the uisplay conliims that the RP was
leaineu via static conliguiation (hence, no timeout), anu that cuiiently no multicast
gioups aie mappeu to this RP, as inuicateu Ly the 0 in the Gioups column. Given that
theie aie no active gioups (oi souices, loi that mattei) in the cuiient netwoik, the lack
ol any gioup-to-RP mappings is expecteu at this time. As luithei conliimation, PIM
join state is uisplayeu at Stout:
[edit protocols pim]
lab@stout# run show pim join
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Instance: PIM.master Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
The join list is empty, which inuicates that no SPT oi RPT joins have Leen instigateu
Ly the local ioutei. This uisplay conliims that no gioups aie cuiiently mappeu to the
uomain`s RP. The lack ol join state means theie shoulu Le no multicast loiwaiuing
state, which is easily veiilieu with a show multicast route commanu:
554 | Chapter 11:IP Multicast in the Enterprise
[edit protocols pim]
lab@stout# run show multicast route
Family: INET
Family: INET6
As expecteu, theie aie no active multicast ioutes, which is in keeping with no RPT oi
SPT join state. At this stage, the PIM netwoik is awaiting an active souice anu an
inteiesteu ieceivei.
Verify RPF
Beloie you activate any senueis oi multicast ieceiveis, the RPF state ol the cuiient
netwoik is analyzeu. Recall that multicast loiwaiuing anu contiol plane opeiations
tenu to centei on the RPF lunction. An RPF check is, in essence, nothing moie than a
ioute lookup on a packet souice, anu then veiilication that the packet aiiives on the
same inteilace that woulu Le useu when iouting packets auuiesseu to that souice.
Releiiing Lack to Figuie 11-13, it is iestateu that IGP metiics aie alteieu to pielei the
lowei loiwaiuing path consisting ol iouteis Lager, Stout, anu Porter. The netwoik`s
RPF state shoulu iellect the IGP`s pieleiieu loiwaiuing path, which is conliimeu with
a show multicast rpf commanu issueu at ioutei Bock loi the pielix associateu with the
uomain`s RP:
[edit]
lab@Bock# run show multicast rpf 10.20.128.3
Multicast RPF table: inet.0 , 21 entries
10.20.128.3/32
Protocol: OSPF
Interface: ge-0/0/1.100
Neighbor: 10.10.11.2
The output shows that Bock expects to ieceive packets sent liom the 10.20.12S.3 loop-
Lack auuiess ol PBR, via its ge-0/0/1.100 inteilace. Baseu on this RPF state, any packets
liom souice 10.20.12S.3 ieceiveu on any othcr inteilace lail the RPF check, iesulting
in uiscaiu. The OSPF ioute to 10.20.12S.3 is uisplayeu at Bock to conliim that the
shoitest path ioute liom Bock to PBR`s loopLack uoes in lact egiess on its
ge-0/0/1.100 inteilace:
[edit]
lab@Bock# run show route 10.20.128.3
inet.0: 21 destinations, 22 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.20.128.3/32 *[OSPF/10] 01:18:05, metric 4
> to 10.10.11.2 via ge-0/0/1.100
Configure the simulated receiver
The test Leu useu to uevelop this Look uiu not have exteinal multicast senueis oi
ieceiveis. Although unloitunate liom an oveiall ieality peispective, the upsiue is that
PIM Sparse Mode: Static RP | 555
theii aLsence loices the use ol ]unos to simulate theii lunctionality, anu these little-
known technigues olten piove uselul when tiouLleshooting multicast issues Lecause
they allow you to isolate potential pioLlems with attacheu hosts anu theii multicast
applications/piotocol stack.
A Word on Multicast Client Options
Multicast is a somewhat uiy suLject, anu it is always nice to use some meuia content,
such as a multiplayei game oi cool stieaming DVD viueo, to valiuate multicast opeia-
tion anu peiloimance. Il youi test Leu contains multicast-capaLle hosts, we suggest
that you investigate piogiams such as ViueoLAN, which suppoits stieaming viueo ovei
unicast oi multicast, on a vaiiety ol platloims to incluue Vinuows anu vaiious llavois
ol Unix. Foi moie inloimation, see the ViueoLAN uevelopment weLsite at http://www
.vidco|an.org.
Unix platloims can use the ngcn/drcc uti|itics, which iespectively stanu loi multigen-
eiatoi anu uynamic-ieceivei. These utilities aie availaLle loi uownloau at http://down
|oads.pj.itd.nr|.navy.ni|/ngcn/archivc/ngcn3/. The commanu line useu to evoke drec
to lunction as a ieceivei loi gioup 225.1.1.1 in this scenaiio is similai to the example
shown, Lut local inteilace names will vaiy:
%./drec -b 225.1.1.1 -n 1 -p 5000 -i em1 -S NOW /dev/null
DREC: Version 3.1a3
DREC: Loading event queue ...
DREC: Listening for packets ...
(Hit <CTRL-C> to stop)
As loi the commanu-line switches, the -b value specilies the Lase gioup auuiess to join,
anu the -n value ueteimines how many gioups, staiting at the Lase, aie to Le joineu.
The -p value specilies a Usei Datagiam Piotocol (UDP) poit (5000 is the uelault), anu
the -i switch inuicates the local inteilace that shoulu Le joineu. The -S value ueteimines
test stait time; test uuiation can also Le specilieu. Once drec is launcheu, you woulu
expect to see a join loi the associateu gioup, anu woulu then liie up mgen with com-
patiLle settings to geneiate multicast tiallic to that gioup. The commanu example uses
the -t switch to set the uesiieu TTL anu the -r switch to set a iate ol 10 packets pei
seconu:
%./ mgen -b 225.0.0.1:5000 -n 1 -i em1 -p 5000 -t 32 -r 10
MGEN: Version 3.1a3
MGEN: Loading event queue ...
MGEN: Seeding random number generator ...
MGEN: Beginning packet generation ...
(Hit <CTRL-C> to stop)
A numLei ol multicast test utilities aie availaLle loi Vinuows platloims, Lut geneially
speaking, these tenu to Le somewhat ciuue when compaieu to the myiiau options
suppoiteu on Unix systems.
556 | Chapter 11:IP Multicast in the Enterprise
Static IGMP membership
The simplest way to simulate an attacheu multicast ieceivei in ]unos is to conliguie a
static IGMP join. The pioLlem with a simple static join is that the local ioutei uoes not
join the gioup, anu as such it uoes not ieceive any test tiallic, which means that without
an actual exteinal ieceivei on the associateu inteilace, theie can Le no hope ol ieplies
to geneiateu multicast test tiallic. Vith no such exteinal ieceivei in this laL, the only
way to conliim multicast loiwaiuing is to monitoi inteilace tiallic stats on the ieceivei
inteilace while tiying to coiielate the ieceiveu packet count to the geneiateu multicast
test tiallic. In a guiescent laL setup, this may Le woikaLle, Lut in any type ol piouuction
netwoik, theie will likely Le enough Lackgiounu tiallic to make accuiate matching ol
tiansmitteu tiallic to ieceiveu multicast packets all Lut impossiLle. The syntax loi a
static IGMP join is shown, Lut this appioach is not useu Lecause a uilleient technigue
is planneu loi simulating a multicast ieceivei at ioutei Cider:
[edit]
lab@Cider# show protocols igmp
interface ge-0/0/0.0 {
static {
group 225.1.1.1;
}
}
Beloie moving on, it`s noteu that the lack ol multicast hosts means theie will Le no
IGMP activity to monitoi in the laL. Vith the static join in place, you can view IGMP
gioup status to lamiliaiize youisell with the uisplay. Things Legin with the cleaiing ol
any IGMP memLeiship to ensuie that no stale state is uisplayeu:
[edit]
lab@Cider# run clear igmp membership
Clearing Group Membership Info for ge-0/0/1.100
Clearing Group Membership Info for ge-0/0/0.0
[edit]
lab@Cider# run show igmp group
Interface: ge-0/0/0.0
Group: 225.1.1.1
Source: 0.0.0.0
Last reported by: Local
Timeout: 0 Type: Static
Interface: local
Group: 224.0.0.2
Source: 0.0.0.0
Last reported by: Local
Timeout: 0 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Last reported by: Local
Timeout: 0 Type: Dynamic
Group: 224.0.0.6
Source: 0.0.0.0
Last reported by: Local
Timeout: 0 Type: Dynamic
PIM Sparse Mode: Static RP | 557
Group: 224.0.0.22
Source: 0.0.0.0
Last reported by: Local
Timeout: 0 Type: Dynamic
As noteu pieviously, multicast loiwaiuing is all aLout uynamic state,
anu this state can seem to peisist loi an annoyingly long peiiou ol time
il it`s not cleaieu out manually. Vhen testing any multicast enviion-
ment, it is wise to let things cook loi at least live minutes in all opeia-
tional moues to ensuie that things aie ieally woiking the way you expect.
Although Logus multicast state will geneially not cause any negative
impact to the ioutei oi netwoik, it can allect communications loi seveial
minutes il lelt to age out using its own means.
The output ol the show igmp membership commanu conliims the statically conliguieu
memLeiship on inteilace ge-0/0/0 loi the 225.1.1.1 gioup. The lack ol a specilic souice
auuiess shows that this is an (',G), oi shaieu tiee join. Vhen IGMPv3 is enaLleu, you
can specily a souice auuiess when conliguiing static memLeiship to geneiate (S,G) state
anu a iesulting SPT. Dynamic entiies aie associateu with a timeout value inuicating
when the entiy will age out il it is not ieliesheu as a iesult ol a host memLeiship iepoit
loi that gioup. The local entiies iepiesent multicast auuiesses associateu with local
piocesses that neeu to listen to multicast tiallic. The 225.0.0.5 anu 225.0.0.6 auuiesses
iepiesent all OSPF iouteis anu all OSPF uesignateu ioutei gioups, 225.0.0.1 is the all
hosts gioup, 225.0.0.2 is the all iouteis gioup, anu 225.0.0.22 is the multicast gioup
associateu with IGMP iepoits.
Create a listening multicast process
Many multicast applications opeiate in a simplex lashion, meaning that a ieply is not
technically neeueu loi the application to woik. Howevei, in this laL the goal is to use
Inteinet Contiol Message Piotocol (ICMP) echo packets sent to a multicast gioup au-
uiess, with success Leing ueteimineu Ly the ieceipt ol a unicast ieply, Lecause this is
the most expeuient way to conliim that multicast test tiallic is successlully loiwaiueu
all the way to the multicast ieceivei.
You can uisaLle iesponse geneiation to multicast-taigeteu pings Ly in-
cluuing the no-multicast-echo statement at the [edit system] hieiaichy
level, in ]unos OS ieleases S.1 anu latei. This uoes not altei Lehavioi loi
unicast-taigeteu pings.
The tiick to making a ]unipei ioutei initiate a PIM join, while also cieating a piocess
that listens to the associateu gioup in contiast to a static IGMP join, is to enaLle the
SAP piocess on the gioup in guestion. SAP always opeiates on the well-known gioup
auuiess 22+.2.127.25+, using poit 9S75, Lut you can conliguie SAP to opeiate on othei
558 | Chapter 11:IP Multicast in the Enterprise
gioups (anu poits) as well. This is the appioach we`ie taking loi the test Leu`s 225.1.1.1
gioup.
Active multicast souices tiansmit SDP messages inlieguently, olten on
the oiuei ol minutes. This long uelay Letween messages can cause pioL-
lems in a PIM spaise moue netwoik. The ieceipt ol the SAP message Ly
the RP causes it to examine its cuiient join state loi the 22+.2.127.25+
multicast gioup. Il no state is enaLleu, the SAP message is not loiwaiueu
into the netwoik. The enu iesult is that the SDP message uelay makes
it extiemely haiu to get the SDP messages liom the multicast souice to
the inteiesteu clients when opeiating in spaise moue. To ieuuce this
uelay, you can conliguie a SAP piocess on each ioutei uiiectly attacheu
to ieceiveis. This causes the ioutei to geneiate a PIM join loi the SAP
gioup auuiess ol 22+.2.127.25+. The ioutei ielieshes this join state such
that the RP maintains a constant loiwaiuing tiee loi the SAP gioup. This
allows the inlieguent SDP messages to Le loiwaiueu to the inteiesteu
clients anu to populate the Session Diiectoiy tool. Fiankly, it`s haiu to
imagine something this goou still Leing legal.
Beloie alteiing the conliguiation at Cider, a show pim join commanu is issueu to con-
liim that no join state cuiiently exists:
lab@Cider# run show pim join
Instance: PIM.master Family: INET
Instance: PIM.master Family: INET6
Cider`s conliguiation is alteieu to instantiate a SAP piocess that will listen on 225.1.1.1,
poit 5000:
[edit protocols]
lab@Cider# show sap
listen 225.1.1.1 port 5000;
Altei the change is committeu, PIM join state is again uisplayeu. This time the
extensive switch is auueu to view all possiLle uetails:
[edit protocols]
lab@Cider# run show pim join extensive
Instance: PIM.master Family: INET
Group: 224.2.127.254
Source: *
RP: 10.20.128.3
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/1.100
Upstream neighbor: 10.10.11.2
Upstream state: Join to RP
Downstream neighbors:
Interface: Local
PIM Sparse Mode: Static RP | 559
Group: 225.1.1.1
Source: *
RP: 10.20.128.3
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/1.100
Upstream neighbor: 10.10.11.2
Upstream state: Join to RP
Downstream neighbors:
Interface: Pseudo-GMP
ge-0/0/0.0
Instance: PIM.master Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
The output inuicates that the newly cieateu SAP piocess has issueu an RPT (shaieu
tiee oi ',G) join loi Loth the well-known anu usei-conliguieu SAP gioups. The up-
stieam (incoming) inteilace is the RPF inteilace leauing towaiu the uomain`s RP, anu
the uownstieam (outgoing) inteilace list is empty Lecause this join is the iesult ol a
local piocess iathei than a ieceiveu PIM join oi IGMP memLeiship iepoit. The piesence
ol a listening UDP piocess on Loth SAP-associateu poits is now veiilieu. Heie the
commanu makes use ol CLI matching anu logical OR lunctionality to make guick woik
ol the task:
[edit protocols]
lab@Cider# run show system connections | match "(5000|9875)"
udp4 0 0 *.5000 *.*
udp4 0 0 *.9875 *.*
The output conliims the two expecteu UDP-Laseu listening piocesses on the well-
known anu usei-specilieu SAP poits. The lack ol uata activity on the 225.1.1.1 gioup
iesults in no cacheu loiwaiuing state, as eviuenceu Ly the lack ol a multicast ioute loi
the 225.1.1.1 gioup at tiansit noue Porter:
[edit]
lab@Porter# run show multicast route
Family: INET
Family: INET6
Beloie geneiating tiallic, the netwoik`s RPT join state is again analyzeu. Recall that
PIM joins aie sent using RPF towaiu the souice, anu that loi an (',G) join, that souice
is the RP. Given the metiic aujustments in ellect in the multicast topology, the RPF
path liom Cider to PBR (the RP) shoulu consist ol the path Porter, Stout, PBR. The
piesumeu loiwaiuing path is liist conliimeu:
[edit protocols]
lab@Cider# run traceroute 10.20.128.3
traceroute to 10.20.128.3 (10.20.128.3), 30 hops max, 40 byte packets
1 10.10.11.2 (10.10.11.2) 9.235 ms 8.720 ms 9.706 ms
2 10.20.131.2 (10.20.131.2) 10.190 ms 9.147 ms 7.321 ms
3 10.20.128.3 (10.20.128.3) 12.943 ms 38.945 ms 9.847 ms
560 | Chapter 11:IP Multicast in the Enterprise
The tiaceioute iesults show that the unicast loiwaiuing path liom Cider to PBR`s loop-
Lack auuiess is as anticipateutheieloie, an RPT join initiateu at Cider shoulu take
this same path. Shaieu tiee join state is uisplayeu at Porter:
[edit]
lab@Porter# run show pim join 225.1.1.1
Instance: PIM.master Family: INET
Group: 225.1.1.1
Source: *
RP: 10.20.128.3
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/1.1331
The RPT join state at Porter is as expecteu, in that the upstieam inteilace is pointing
towaiu Stout. The join state loi 225.1.1.1 is uisplayeu at Stout:
[edit]
lab@stout# run show pim join 225.1.1.1
Instance: PIM.master Family: INET
Group: 225.1.1.1
Source: *
RP: 10.20.128.3
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/0.3141
As expecteu, RPF loiwaiuing ol the shaieu tiee join at Stout iesults in an upstieam
inteilace ol ge-0/0/0.3141, which is the metiically closest way loi Stout to ieach PBR`s
10.20.12S.3 auuiess.
The cuiient state ol the netwoik coiiectly iepiesents PIM spaise moue state loi a ie-
ceivei inteiesteu in a gioup with no active senueis. In the next section, we will geneiate
multicast tiallic anu examine the impact on netwoik state.
Generate multicast traffic
Vith the ieceivei join state anu iesulting PIM spaise moue RP-iooteu shaieu tiee veii-
lieu, it is time to shake things up Ly actually geneiating some multicast tiallic! In this
example, a ]unipei ioutei is useu to simulate a multicast souice with the ping commanu,
in conjunction with the bypass-routing, ttl, anu interface switches. The bypass-
routing switch is neeueu to avoiu the lact that the inet.1 taLle uoes not have multicast
loiwaiuing state loi the 225.0.0.1 gioup; iememLei, Ale is a ioutei, not a host. Because
theie is no iouting entiy to iely on, you must iuentily the egiess inteilace loi the test
tiallic using the interface switch. By uelault, locally geneiateu multicast ping tiallic
uses a TTL ol 1, which is uone to limit the scope ol the tiallic to the local link. This is
Lecause in a ieal-woilu scenaiio, nuncrous ieceiveis coulu Le listening to the ielateu
gioup, anu this in tuin can iesult in signilicant packet ieplication anu a iesulting ava-
lanche ol ieplies. The test Leu has only one ieceivei loi the test tiallic, making this a
nonissue. A TTL value ol at least 5 is iecommenueu to ensuie that the test tiallic can
make it all the way liom Ale to Cider.
PIM Sparse Mode: Static RP | 561
A TTL value ol + iesults in the test tiallic Leing hanueu to Cider with a
TTL ol 1. Although aueguate loi unicast, in some cases multicast TTL
may Le ueciementeu upon ieceipt, which can leau to inteimittent ieplies
loi packets ieceiveu with a TTL = 1. By setting the TTL highei than
stiictly necessaiy, you guaiantee that you will not encountei this issue.
Ve have spent a lot ol elloit leauing to this point, anu seveial things aie aLout to happen
in iapiu succession once the senuei is liieu up; specilically:
The liist hop ioutei, Lager, encapsulates the native multicast into a unicast packet
sent to 10.20.12S.3, the uomain`s RP.
The RP uecapsulates the tiallic Laseu on join state loi the associateu gioup, anu
then senus the native multicast uown the shaieu tiee. Given the cuiient join state,
the tiallic shoulu Le sent liom the RP to Stout anu Porter, anu then to ieceivei
Cider.
The piesence ol multicast tiallic iesults in the cieation ol a multicast ioute in tiansit
iouteis. This ioute is placeu into the inet.1 taLle, anu you can think ol it as a uata-
uiiven loiwaiuing plane ieaction to the contiol plane`s join state. Note that without
the contiol plane join, the uata plane cannot estaLlish these uynamic multicast
loiwaiuing states.
Upon ieceipt ol tiallic liom souice 10.10.111.1 ovei the shaieu tiee, ioutei
Cider initiates an SPT join towaiu the souice. Once the SPT is estaLlisheu, multicast
liom 10.10.111.1 is tianspoiteu uiiectly ovei the SPT. To pievent uuplicateu pack-
ets, the liist ioutei in the uata path that is on both the SPT anu RPT (Stout in this
case) senus an (S,G) piune towaiu the RP to pievent ieceipt ol packets ovei Loth
the SPT anu the RPT.
Vhen theie aie no inteiesteu ieceiveis on the RPT, the RP senus a iegistei stop
message to the souice.
Once the souice is no longei active, the SPT state will eventually age out, iesulting
in a ietuin to the RPT loi gioup 225.1.1.1.
To help catch some ol this Lehavioi, PIM iegistei message tiacing is auueu to Lager:
[edit protocols pim]
lab@Lager# show traceoptions
file pim;
flag register detail;
Multicast pings aie now initiateu at Lager:
[edit]
lab@Ale# run ping ttl 5 225.1.1.1 interface ge-0/0/0.111 bypass-routing
PING 225.1.1.1 (225.1.1.1): 56 data bytes
64 bytes from 10.10.11.3: icmp_seq=0 ttl=61 time=16.776 ms
64 bytes from 10.10.11.3: icmp_seq=1 ttl=61 time=20.144 ms
. . .
562 | Chapter 11:IP Multicast in the Enterprise
The output conliims that iesponses aie Leing ieceiveu liom 10.10.11.3, the auuiess ol
Cider`s ge-0/0/1.100 inteilace. The piesence ol ieplies is a most auspicious Leginning,
to Le suie. Meanwhile, Lack at Lager, the lollowing tiace output is oLseiveu:
Sep 27 00:55:10.983201 PIM SENT 10.10.128.2 -> 10.20.128.3 V2 Register Flags:
0x40000000 Border: 0 Null: 1 Source 10.10.111.1 Group 225.1.1.1 sum 0x43f1 len 28
Sep 27 00:55:10.993582 PIM ge-0/0/0.2131 RECV 10.20.128.3 -> 10.10.128.2 V2
RegisterStop Source 10.10.111.1 Group 225.1.1.1 sum 0x80d1 len 18
The tiace conliims that, as pieuicteu, the liist hop ioutei sent a iegistei message to the
RP loi souice 10.10.111.1 anu gioup 225.1.1.1, anu the RP latei geneiateu a iegistei
stop loi this (S,G) paii, thus inuicating that no moie listeneis aie piesent on the shaieu
tiee. This is a goou inuication that the SPT cutovei was successlul. Next, the iesulting
(S,G) join state is examineu at Cider:
[edit protocols]
lab@Cider# run show pim join 225.1.1.1 extensive
Instance: PIM.master Family: INET
Group: 225.1.1.1
Source: *
RP: 10.20.128.3
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/1.100
Upstream neighbor: 10.10.11.2
Upstream state: Join to RP
Downstream neighbors:
Interface: Local
Group: 225.1.1.1
Source: 10.10.111.1
Flags: sparse,spt
Upstream interface: ge-0/0/1.100
Upstream neighbor: 10.10.11.2
Upstream state: Join to Source
Keepalive timeout: 355
Downstream neighbors:
Interface: Local
Cider`s uisplay conliims that SPT join state is now also piesent loi the 225.1.1.1 gioup.
Cider iemains on the RPT via its (',G) join in case any othei senuei Lecomes active loi
the 225.1.1.1 gioupthis is an ASM example, altei all. The join state at Stout also
shows an SPT anu RPT, Lut the RPT has Leen piuneu loi this (S,G) paii, given the
piesence ol an SPT Letween the senuei anu ieceivei:
[edit]
lab@stout# run show pim join 225.1.1.1 extensive
Instance: PIM.master Family: INET
Group: 225.1.1.1
Source: *
RP: 10.20.128.3
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/0.3141
Upstream neighbor: 10.20.129.2
PIM Sparse Mode: Static RP | 563
Upstream state: Join to RP
Downstream neighbors:
Interface: ge-0/0/1.1331
10.20.131.1 State: Join Flags: SRW Timeout: 179
Group: 225.1.1.1
Source: 10.10.111.1
Flags: sparse,spt
Upstream interface: ge-0/0/0.2131
Upstream neighbor: 10.10.131.1
Upstream state: Join to Source, Prune to RP
Keepalive timeout: 303
Downstream neighbors:
Interface: ge-0/0/1.1331
10.20.131.1 State: Join Flags: S Timeout: 179
The join state at Stout is as expecteu. It too iemains on the shaieu tiee loi gioup
225.1.1.1, in case any auuitional souices Lecome active, anu it too has geneiateu an
SPT join uiiectly towaiu the souice, as a iesult ol ieceiving an (S,G) join on its uown-
stieam inteilace, as sent Ly Porter. The highlights call out the topology uilleience Le-
tween the shaieu anu souice tiees, with the shaieu tiee at Stout pointing towaiu the
RP while the souice tiee points towaiu the souice. Stout has piuneu souice 10.10.111.1
liom the shaieu tiee, a state that is iellecteu at the RP:
[edit]
lab@PBR# run show pim join 225.1.1.1 extensive
Instance: PIM.master Family: INET
Group: 225.1.1.1
Source: *
RP: 10.20.128.3
Flags: sparse,rptree,wildcard
Upstream interface: Local
Upstream neighbor: Local
Upstream state: Local RP
Downstream neighbors:
Interface: ge-0/0/0.3141
10.20.129.1 State: Join Flags: SRW Timeout: 156
Group: 225.1.1.1
Source: 10.10.111.1
Flags: sparse,spt
Upstream interface: ge-0/0/0.111
Upstream neighbor: Direct
Upstream state: Local Source, Local RP
Keepalive timeout: 337
Downstream neighbors:
Interface: ge-0/0/0.3141 (pruned)
10.20.129.1 State: Prune Flags: SR Timeout: 156
Vith the PIM spaise moue contiol plane looking goou, you examine the uata plane
state as it ielates to the (S,G) llow cuiiently active in the netwoik:
[edit]
lab@stout# run show multicast route detail
564 | Chapter 11:IP Multicast in the Enterprise
Family: INET
Group: 225.1.1.1
Source: 10.10.111.1/32
Upstream interface: ge-0/0/0.2131
Downstream interface list:
ge-0/0/1.1331
Session description: MALLOC
Statistics: 0 kBps, 1 pps, 1966 packets
Next-hop ID: 348
Upstream protocol: PIM
The highlights call out the expecteu upstieam anu uownstieam (incoming/outgoing)
inteilaces. Incluuing the detail switch uisplays cuiient tiallic stats loi each loiwaiuing
cache entiy. Vhen a well-known gioup auuiess is uetecteu, the session uesciiption
iellects the associateu application. In this case, no application is associateu with
225.0.0.1, so the uisplay simply inuicates that the session Lelongs to the multicast
allocation auuiess space (MALLOC). The next hop ID lielu is useu to tie this ioute into
a loiwaiuing taLle entiy in the Packet Foiwaiuing Engine (PFE). You can uisplay the
multicast loiwaiuing taLle to conliim that this next hop ID is associateu with the
10.10.111.1, 225.1.1.1 tuple:
[edit]
lab@stout# run show route forwarding-table multicast destination 225.1.1.1
Routing table: inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
225.1.1.1.10.10.111.1/64
user 0 mcrt 348 1
To actually uisplay what the loiwaiuing taLle uoes with the next hop inuex ol 3+S, you
have to access the PFE uiiectly. The lollowing commanus aie peiloimeu loi illustiative
puiposes, anu they use unsuppoiteu shell commanus. RememLei: you shoulu use hiu-
uen anu shell commanus only unuei uiiect guiuance ol ]TAC:
[edit]
lab@stout# run start shell
% su
Password:
root@stout% vty 1
BSD platform (Pentium processor, 84MB memory, 8192KB flash)
A shell is staiteu anu the usei Lecomes ioot, Lecause only the ioot usei has access to
the vty commanu useu to attach to the loiwaiuing uevices uaemon (lwuu) piocess.
You connect to the soltwaie-Laseu PFE, which on a ]-seiies ioutei is calleu lwuu, Ly
connecting to tnp auuiess 1. Once connecteu to the PFE, inloimation is uisplayeu loi
the next hop value ol 3+S:
FWDD(stout vty)# show nhdb id 348
Nexthop Info:
PIM Sparse Mode: Static RP | 565
ID Type Interface Next Hop Addr Protocol Encap MTU
---- ------- ------------- --------------- -------- --------- ----
348 MultiRT - - IPv4 - 0
ge-0/0/1.1331 IPv4 Ethernet
The PFE output conliims that cuiiently, a single outgoing inteilace is associateu with
next hop ID 3+S. A multicast ioute entiy can have numeious next hop inteilaces when
the topology ieguiies such ieplication. You now exit out ol the vty connection anu the
shell to ietuin to the CLI:
FWDD(stout vty)# exit
root@stout% exit
% exit
[edit]
lab@stout#
Multicast ioutes in a loiwaiuing state aie placeu into the inet.1 ioute taLle. Unlike a
leaineu ioute, inloimation in inet.1 is a cache entiy that is uiiven Ly the actual llow
ol tiallicthe entiy ages out a shoit while altei tiallic cessation:
[edit]
lab@stout# run show route table inet.1 detail
inet.1: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
225.1.1.1.10.10.111.1/64 (1 entry, 1 announced)
*PIM Preference: 105
Next hop type: Multicast (IPv4)
Next-hop reference count: 2
State: <Active Int>
Age: 39:25
Task: PIM.master
Announcement bits (1): 0-KRT
AS path: I
The show multicast usage commanu is also hanuy when you want to ueteimine the
numLei anu ielative activity level ol the vaiious souices in youi netwoik:
[edit]
lab@stout# run show multicast usage
Group Sources Packets Bytes
225.1.1.1 1 2516 211344
Prefix /len Groups Packets Bytes
10.10.111.1 /32 1 2516 211344
Note that multicast usage inloimation is uisplayeu Loth Ly gioup anu Ly (S,G) paiiing.
Multicast tiallic geneiation is stoppeu at Ale:
64 bytes from 10.10.11.3: icmp_seq=7227 ttl=61 time=10.564 ms
^C
--- 225.1.1.1 ping statistics ---
7228 packets transmitted, 7228 packets received, 0% packet loss
round-trip min/avg/max/stddev = 8.079/21.507/201.323/10.705 ms
566 | Chapter 11:IP Multicast in the Enterprise
The lack ol uata plane activity iesults in aging out ol the loiwaiuing state. Because the
ieceivei is still inteiesteu in gioup 225.1.1.1, the contiol plane join state is ieliesheu
anu iemains:
[edit]
lab@stout# run show multicast route extensive source-prefix 10.10.111.1
Family: INET
Group: 225.1.1.1
Source: 10.10.111.1/32
Upstream interface: ge-0/0/0.2131
Downstream interface list:
ge-0/0/1.1331
Session description: MALLOC
Statistics: 0 kBps, 0 pps, 7306 packets
Next-hop ID: 348
Upstream protocol: PIM
Route state: Active
Forwarding state: Forwarding
Cache lifetime/timeout: 171 seconds
Wrong incoming interface notifications: 1
[edit]
lab@stout# run show pim join extensive 225.1.1.1
Instance: PIM.master Family: INET
Group: 225.1.1.1
Source: *
RP: 10.20.128.3
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/0.3141
Upstream neighbor: 10.20.129.2
Upstream state: Join to RP
Downstream neighbors:
Interface: ge-0/0/1.1331
10.20.131.1 State: Join Flags: SRW Timeout: 178
Group: 225.1.1.1
Source: 10.10.111.1
Flags: sparse,spt
Upstream interface: ge-0/0/0.2131
Upstream neighbor: 10.10.131.1
Upstream state: Join to Source, Prune to RP
Keepalive timeout: 169
Downstream neighbors:
Interface: ge-0/0/1.1331
10.20.131.1 State: Join Flags: S Timeout: 178
Altei a lew minutes, the (S,G) loiwaiuing state is llusheu liom the netwoik:
[edit]
lab@stout#run show multicast route extensive source-prefix 10.10.111.1
Family: INET
PIM Sparse Mode: Static RP | 567
This iesult conliims expecteu PIM spaise moue contiol anu uata plane state anu ue-
liveiy ol the multicast test tiallic to the ieceivei Ly the ietuineu echo ieplies. These
iesults complete the PIM spaise moue with static RP conliguiation scenaiio.
PIM Sparse Mode with Static RP Summary
This section uemonstiateu the conliguiation anu opeiational veiilication ol a PIM-
Laseu IP multicast netwoik that useu a statically uelineu RP. In the next section, we
will Luilu on this expeiience Ly auuing uynamic RP electing using the Lootstiap
piotocol.
Configure PIM Sparse Mode with Bootstrap RP
In this section, we will conveit the existing multicast topology liom a statically uelineu
RP to a Lootstiap leaineu RP. As pait ol this conveision, the netwoik is Leing ieuesigneu
to auu a seconu RP loi ieuunuancy. The conliguiation oLjectives aie as lollows:
Remove the static RP uelinition liom all iouteis.
Conliguie Stout as a seconu RP loi the 22+/+ gioup iange.
Use Lootstiap-Laseu RP election, anu make suie that PBR is the BSR when
opeiational.
Ensuie that theie is no single point ol RP/BSR lailuie in the netwoik.
The new ieuunuancy ieguiiements make it cleai that the netwoik will neeu two RPs
anu two canuiuate BSRs. Fuithei, the Lootstiap piioiity will neeu to Le highei (moie
pieleiieu) at PBR to ensuie that it is the BSR when opeiational. Figuie 11-1+ shows the
upuateu topology.
Iigurc 11-11. Bootstrap RP c|cction
568 | Chapter 11:IP Multicast in the Enterprise
The liguie shows that Loth PBR anu Stout aie conliguieu to lunction as canuiuate RPs
anu canuiuate BSRs (C-RP anu C-BSR). Although not technically necessaiy, cuiiently
it is a Lest piactice to make the C-RP anu C-BSR lunctionality collocateu, given that
the loss ol eithei lunction kills PIM spaise moue opeiation anu negates any Lenelits
associateu with uistiiLuting C-BSR anu C-RP lunctionality among uilleient noues. The
highei BSR piioiity setting at PBR iesults in its election as the uomain`s BSR when op-
eiational; otheiwise, Stout steps in to take ovei.
Vhen Loth RPs aie opeiational, the BSR auveitises a canuiuate RP set that lists both
ol the uomain`s RPs. Each PIM ioutei hashes against this set to choose which ol the
two RPs to use loi a specilic gioup iange. The hashing lunction ensuies that all iouteis
choose the same canuiuate RP loi the same gioups, anu that a consecutive set ol loui
gioups always map to the same RP. The lattei lunctionality is uesigneu to accommouate
applications that use consecutive gioups loi vaiious elements that make up a single
sessionloi example, an auuio channel anu the coiiesponuing viueo stieamLy
helping to ensuie similai latency among the session`s component stieams.
The static RP uelinition is iemoveu liom iouteis Lager, Stout, Bock, Porter, anu
Cider (not shown), anu attention is locuseu on the neeu to conliguie canuiuate BSR
lunctionality at PBR. The conliguiation is iathei stiaightloiwaiuall that is ieguiieu is
a single statement to enaLle BSR anu assign a piioiity:
[edit protocols pim]
lab@PBR# show
rp {
bootstrap-priority 100;
local {
address 10.20.128.3;
}
}
interface ge-0/0/0.3141;
interface ge-0/0/0.1241;
interface ge-0/0/0.111;
The piioiity setting ol 100 makes PBR a canuiuate BSRnote that a value ol 0 uoes not
uisaLle BSR lunctionality, Lut such a setting uoes make it less likely that canuiuate
PBR will Lecome the BSR. Once a lowei piioiity is set in the soon-to-Le-conliguieu
Stout, you ensuie that PBR is the uomain`s BSR when opeiational. In this example, the
bootstrap statement is conliguieu uiiectly at the [edit protocols pim rp] hieiaichy.
The same set ol options is availaLle on a pei-lamily Lasis using the family keywoiu:
[edit protocols pim]
lab@PBR# set rp bootstrap family inet ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
+ export Bootstrap export policy
+ import Bootstrap import policy
priority Eligibility to be the bootstrap router (0..255)
Configure PIM Sparse Mode with Bootstrap RP | 569
The import anu export keywoius link to one oi moie policy statements that liltei Loot-
stiap messages liom Leing ieceiveu oi tiansmitteu, iespectively. Noimally, you use
such policy at the euges ol a PIM uomain to pievent iouteis in a iemote uomain liom
using the uomain`s local BSR, anu vice veisa.
Altei committing the change, BSR election Legins anu PBR staits a countuown timei
intenueu to ieuuce thiashing Ly allowing time loi any C-BSR messages to piopagate
thiough the uomain Leloie a uecision is maue as to which C-BSR shoulu win to Lecome
the BSR. Use the show pim bootstrap commanu to uisplay inloimation aLout the uo-
main`s canuiuate BSRs:
[edit protocols pim]
lab@PBR# commit
commit complete
[edit protocols pim]
lab@PBR# run show pim bootstrap
Instance: PIM.master
BSR Pri Local address Pri State Timeout
None 0 10.20.128.3 100 Candidate 54
None 0 (null) 0 InEligible 0
PBR is the only ioutei now conliguieu to Le a C-BSR, anu theieloie it easily wins the
election to Lecome the uomain`s BSR:
[edit protocols pim]
lab@PBR# run show pim bootstrap
Instance: PIM.master
BSR Pri Local address Pri State Timeout
10.20.128.3 100 10.20.128.3 100 Elected 37
None 0 (null) 0 InEligible 0
In the uisplay, each ioutei shows a null entiy, as well as an entiy loi its loopLack auuiess
anu local C-BSR piioiity. C-BSR inloimation that is leaineu is uisplayeu on the lelthanu
siue. The output liom PBR makes it cleai that the local ioutei is also the BSR, anu that
it has a piioiity ol 100.
Foi piopei BSR opeiation, a canuiuate BSR must have a ioutaLle auuiess
assigneu to its lo0 inteilace. This is tiue even when a uilleient auuiess,
peihaps one assigneu to a physical inteilace, is conliguieu as the BSR
auuiess. This ieguiiement stems liom an implementation uecision that
loices C-BSR messages to Le souiceu liom the local ioutei`s lo0
auuiessC-BSR messages cannot Le sent il no lo0 auuiess is conliguieu
oi il the only auuiess conliguieu is a 127.x.x.x loopLack. You can com-
mit such a conliguiation, anu the iesult is not paiticulaily easy to tiou-
Lleshoot, as the symptom is simply a lack ol geneiateu C-BSR
messages.
570 | Chapter 11:IP Multicast in the Enterprise
A lew moments latei, piopei Lootstiap opeiation is conliimeu when all othei iouteis
have chosen the same C-BSR, as shown loi Cider:
[edit]
lab@Cider# run show pim bootstrap
Instance: PIM.master
BSR Pri Local address Pri State Timeout
10.20.128.3 100 10.10.12.1 0 InEligible 112
None 0 (null) 0 InEligible 0
The show pim bootstrap uisplay at Cider conliims that it has ieceiveu the C-BSR mes-
sage that oiiginateu at PBR anu was piopagateu via hop-Ly-hop multicast to all BSR-
enaLleu iouteis. The piesence ol a single C-BSR with piioiity 100 is conliimeu, as is
election ol PBR as the BSR:
[edit]
lab@Cider# run show pim rps
Instance: PIM.master
Address family INET
RP address Type Holdtime Timeout Groups Group prefixes
10.20.128.3 bootstrap 150 125 2 224.0.0.0/4
Address family INET6
The show pim rps uisplay luithei conliims that an RP has Leen leaineu loi the 22+/+
iange via the Lootstiap piotocol. Vith things woiking piopeily at the liist C-BSR/C-
RP, it`s time to Liing up the uomain`s Lackup C-BSR/C-RP. The conliguiation ol
Stout is mouilieu anu uisplayeu:
[edit protocols pim]
lab@stout# show | compare
[edit protocols pim rp]
+ bootstrap-priority 50;
+ local {
+ address 10.20.128.4;
+ }
- static {
- address 10.20.128.3;
- }
Altei waiting a minute oi two loi things to settle uown, veiilication staits at Stout. The
expectation is that Stout conliims PBR as the electeu BSR while also listing itsell as a
viaLle contenuei:
BSR Pri Local address Pri State Timeout
10.20.128.3 100 10.20.128.4 50 Candidate 123
None 0 (null) 0 InEligible 0
The output conliims those expectations anu shows that BSR is opeiating as uesiieu
Letween the uomain`s two canuiuate BSRs. RP set inloimation is uisplayeu next:
[edit protocols pim]
lab@stout# run show pim rps
Instance: PIM.master
Configure PIM Sparse Mode with Bootstrap RP | 571
Address family INET
RP address Type Holdtime Timeout Groups Group prefixes
10.20.128.3 bootstrap 150 137 1 224.0.0.0/4
10.20.128.4 bootstrap 150 137 1 224.0.0.0/4
10.20.128.4 static 0 None 1 224.0.0.0/4
The show pim rps commanu output lists Loth ol the uomain`s RPs as having Leen
leaineu via Lootstiap; the local RP uelinition at Stout is also listeu as leaineu statically.
Back at the last hop ioutei, Cider, the state ol RPs is also as expecteu:
[edit]
lab@Cider# run show pim rps
Instance: PIM.master
Address family INET
RP address Type Holdtime Timeout Groups Group prefixes
10.20.128.3 bootstrap 150 101 1 224.0.0.0/4
10.20.128.4 bootstrap 150 101 1 224.0.0.0/4
Awesome! Anu some lolks think this multicast stull is haiu to unueistanu. PIM join
state is uisplayeu at Cider. The uisplay illustiates the Lootstiap RP hashing lunction,
in that the two joins associateu with the listening SAP piocess hasheu to a uilleient RP:
[edit]
lab@Cider# run show pim join
Instance: PIM.master Family: INET
Group: 224.2.127.254
Source: *
RP: 10.20.128.3
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/1.100
Group: 225.1.1.1
Source: *
RP: 10.20.128.4
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/1.100
Once again, connectivity is veiilieu at the senuei:
[edit]
lab@Ale# run ping ttl 5 225.1.1.1 interface ge-0/0/0.111 bypass-routing
PING 225.1.1.1 (225.1.1.1): 56 data bytes
64 bytes from 10.10.11.3: icmp_seq=0 ttl=61 time=87.388 ms
. . .
So is the uata-uiiven switch to an SPT at the last hop ioutei:
[edit]
lab@Cider# run show pim join 225.1.1.1 detail
Instance: PIM.master Family: INET
Group: 225.1.1.1
Source: *
RP: 10.20.128.4
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/1.100
572 | Chapter 11:IP Multicast in the Enterprise
Group: 225.1.1.1
Source: 10.10.111.1
Flags: sparse,spt
Upstream interface: ge-0/0/1.100
Beloie calling it guits, ieuunuancy is veiilieu Ly ueactivating the RP anu BSR lunction-
ality at PBR. The confirmed option is auueu to the commit to evoke automatic iestoiation
ol the pievious (anu cuiiently active) conliguiation to save some keystiokes:
[edit protocols pim]
lab@PBR# deactivate rp
[edit protocols pim]
lab@PBR# show
inactive: rp {
bootstrap-priority 100;
local {
address 10.20.128.3;
}
}
interface ge-0/0/0.3141;
interface ge-0/0/0.1241;
interface ge-0/0/0.111;
[edit protocols pim]
lab@PBR# commit confirmed 3
commit confirmed will be automatically rolled back in 3 minutes
unless confirmed
commit complete
# commit confirmed will be rolled back in 3 minutes
[edit protocols pim]
Failovei Lehavioi is conliimeu Lack at Cider:
[edit]
lab@Cider# run show pim bootstrap
Instance: PIM.master
BSR Pri Local address Pri State Timeout
10.20.128.4 50 10.10.12.1 0 InEligible 103
None 0 (null) 0 InEligible 0
The uisplay conliims the iemoval ol PBR as a canuiuate RP anu the election ol the
iemaining C-BSR (Stout), which is now the Lest choice. The join state takes a little
while to catch up, Lut altei a shoit while all joins aie pointing to the iemaining RP:
[edit]
lab@Cider# run show pim join
Instance: PIM.master Family: INET
Group: 224.2.127.254
Source: *
RP: 10.20.128.4
Flags: sparse,rptree,wildcard
Configure PIM Sparse Mode with Bootstrap RP | 573
Upstream interface: ge-0/0/1.100
Group: 225.1.1.1
Source: *
RP: 10.20.128.4
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/1.100
Group: 225.1.1.1
Source: 10.10.111.1
Flags: sparse,spt
Upstream interface: ge-0/0/1.100
Once the automatic iollLack occuis at PBR, things ietuin to the expecteu state, which
completes veiilication ol the PIM spaise moue with Lootstiap piotocol scenaiio:
[edit]
lab@Cider# run show pim bootstrap
Instance: PIM.master
BSR Pri Local address Pri State Timeout
10.20.128.3 100 10.10.12.1 0 InEligible 88
None 0 (null) 0 InEligible 0
Troubleshoot a Bootstrap Problem
The Beei-Co topology has Leen alteieu to inteilace to anothei iouting uomain, as
shown in Figuie 11-15.
Iigurc 11-15. P|M BSR troub|cshooting topo|ogy
574 | Chapter 11:IP Multicast in the Enterprise
Figuie 11-15 uetails how PIMv1 has Leen conliguieu on the now cxtcrna| inteilaces at
Bock anu Porter to pievent the leaking ol Lootstiap piotocol messages to anu liom the
othei iouting uomain. Recall that PIMv1 uoes not suppoit Lootstiap, making this a
common appioach to scoping BSR messages. The pioLlem is that Bock uoes not uisplay
any leaineu BSRs, anu theieloie theie is no Lootstiap leaineu RP at Bock:
[edit]
lab@Bock# show protocols pim
interface ge-0/0/0.1241;
interface ge-0/0/1.100 {
version 1;
}
interface t1-2/0/2.0;
[edit]
lab@Bock# run show pim bootstrap
Instance: PIM.master
BSR Pri Local address Pri State Timeout
None 0 10.10.12.3 0 InEligible 0
None 0 (null) 0 InEligible 0
[edit]
lab@Bock# run show pim rps
Instance: PIM.master
All othei iouteis uisplay the expecteu BSR anu RP set inloimation. Bock was woiking
piopeily piioi to the shilt to PIMv1, anu connectivity ovei all ol its inteilaces has Leen
veiilieu with successlul pings to uiiect neighLois.
Lacking any Lettei suggestions, PIM Lootstiap tiacing is auueu to the conliguiation,
anu altei a shoit while tiace output is oLseiveu:
[edit protocols pim]
lab@Bock# show traceoptions
file pim;
flag bootstrap detail;
[edit protocols pim]
lab@Bock# run monitor start pim
*** pim ***
Sep 28 02:27:19.848100 PIM ge-0/0/0.1241 RECV 10.20.130.2 ->
224.0.0.13 V2 Bootstrap sum 0x6ab2 len 46
Sep 28 02:27:19.848182 tag 52078 masklen 30 priority 100 bootstrap
router 10.20.128.3
Sep 28 02:27:19.848208 group 224.0.0.0 count 2 fragcount 2
Sep 28 02:27:19.848230 rp address 10.20.128.3 holdtime 150
priority 1
Sep 28 02:27:19.848247 rp address 10.20.128.4 holdtime 150
priority 1
Sep 28 02:27:19.857917 PIM t1-2/0/2.0 RECV 10.10.10.2 -> 224.0.0.13
V2 Bootstrap sum 0x0cba len 46
Sep 28 02:27:19.858018 tag 10599 masklen 30 priority 100 bootstrap
router 10.20.128.3
Configure PIM Sparse Mode with Bootstrap RP | 575
Sep 28 02:27:19.858042 group 224.0.0.0 count 2 fragcount 2
Sep 28 02:27:19.858060 rp address 10.20.128.3 holdtime 150
priority 1
Sep 28 02:27:19.858073 rp address 10.20.128.4 holdtime 150
priority 1
The tiace output is at once goou anu Lau; goou Lecause it shows that valiu Lootstiap
messages aie Leing ieceiveu on Loth ol Bock`s PIMv2-enaLleu inteilaces, anu Lau Le-
cause no oLvious eiioi oi ieason is uisplayeu as to why the messages uo not iesult in
election ol a BSR at Bock. Given that things woikeu until the shilt to PIMv1 on
ge-0/0/1.100, you ueciue to tempoiaiily ueactivate the ge-0/0/1 inteilace:
[edit]
lab@Bock# deactivate interfaces ge-0/0/1
[edit]
lab@Bock# commit
commit complete
[edit]
lab@Bock# run show pim bootstrap
Instance: PIM.master
BSR Pri Local address Pri State Timeout
10.20.128.3 100 10.10.12.3 0 InEligible 100
None 0 (null) 0 InEligible 0
Quite inteiesting; the output conliims piopei BSR election as long as the PIMv1 intei-
lace is ueactivateuwhich makes little sense given that PIMv1 uoes not even suppoit
the BSR piotocol! The change is iolleu Lack to ieactivate the ge-0/0/1.100 inteilace.
Stiange; veiy stiange inueeuiecalling that RPF checks aie ciitical to multicast opei-
ation, you uisplay the RPF ioute to 10.20.12S.3 liom Bock:
[edit]
lab@Bock# run show multicast rpf 10.20.128.3
Multicast RPF table: inet.0 , 21 entries
10.20.128.3/32
Protocol: OSPF
Interface: ge-0/0/1.100
Neighbor: 10.10.11.2
The uisplay shows that Bock consiueis 10.10.11.2 as the RFP neighLoi loi the
10.20.12S.3 ioute, which is ieachaLle ovei the 10.10.11.0/2+ suLnet. Inteiestingly, this
is also the inteilace that was set to PIMv1, anu this explains the pioLlem: PIM contiol
messages geneially have to Le ieceiveu on the RPF inteilace to theii souice; otheiwise,
they aie ignoieu. Foi the specilic Lehavioi uiscusseu heie, Section 3.1.3 ol RFC 5059
states:
Vhen a Bootstiap message is ieceiveu, the lollowing initial check must Le peiloimeu:
1. Il the message`s auuiess is ALL-PIM-ROUTERS, anu il the souice auuiess is not the
RPF neighLoi auuiess, then it uiops the Bootstiap message silently.
576 | Chapter 11:IP Multicast in the Enterprise
The pioLlem now Lecomes cleaigiven the OSPF metiics in ellect, Bock expects to
ieceive BSR messages on its ge-0.0/1/100 inteilace anu is uiopping BSR messages ie-
ceiveu on those inteilaces that aie not on the RPF path Lack to the BSR. Seveial solu-
tions piesent themselves:
Altei IGP metiics so that Bock no longei sees its ge-0/0/1.100 inteilace as the RPF
inteilace Lack to the BSRthat is, eithei inciease the 10.10.11.0 suLnet metiic oi
ieuuce the 10.20.130.0 oi 10.10.10.0 suLnet metiic.
Reconliguie the netwoik to move BSR lunctionality to a noue whose RPF check
uoes not point to Bock`s ge-0/0/1.100 inteilace. This option is not ieally viaLle in
the sample topology unless a new ioutei is auueu.
Auu a new link, oi auu PIM to a pieviously nonmulticast-enaLleu link, in oiuei to
allect a new RPF topology, again with the intent ol iemoving ge-0/0/1.100 liom
the RPF check Lack to PBR.
Policy-Laseu lilteiing ol Lootstiap messages is not consiueieu heie Lecause in this sce-
naiio, it ielies on the auministiation ol the iemote autonomous system (AS) to apply
impoit policy to liltei Lootstiap messages exchangeu ovei the shaieu LAN Letween
Bock anu Porter; egiess lilteiing at Bock anu Porter uoes not woik Lecause this lilteis
all Lootstiap messages liom the LANcuiiently Bock neeus to ieceive the Lootstiap
messages liom Porter ovei the shaieu LAN.
Extra points for creativity?
The solution uemonstiateu heie is Laseu on the auu anothei link option uiscusseu
eailiei, except the new link is instantiateu as a Geneiic Routing Encapsulation (GRE)
tunnel, meaning no new eguipment oi lacilities aie neeueu! No iouting piotocol op-
eiates ovei the tunnelBock uses two /32 static ioutes to uiiect tiallic uestineu to the
lo0 auuiess ol PBR anu Stout ovei the GRE tunnel. This ensuies that the only tiallic
suLjecteu to the tunnel is that associateu with the loopLack auuiesses ol PBR anu
Stout. All othei tiallic continues to lollow the IGP`s shoitest path, theieLy causing
minimal impact to existing tiallic patteins. Il all this weie not enough, the tunnel is
instantiateu Letween the loopLack auuiess ol Bock anu PBR anu is iouteu Letween these
auuiesses accoiuing to the IGP`s shoitest path. This means the GRE tunnel anu asso-
ciateu static iouting aie not allecteu Ly the lailuies ol inuiviuual links oi inteilaces, anu
that no policy/static ioutes aie neeueu to auveitise ieachaLility to the tunnel enupoints
given that the lo0s ol Bock anu Porter aie alieauy caiiieu in OSPF. Because the static
ioutes aie pieleiieu ovei any OSPF leaineu ioute (uue to pieleience), the pioLlems ol
ieceiving BSR messages on the wiong RPF inteilace aie loievei eliminateu once PIM is
enaLleu ovei the GRE tunnel.
The changes to Bock`s conliguiation aie shown. The changes at Porter aie limiteu to
GRE inteilace uelinition anu enaLling PIM on the iesulting GRE inteilace. No static
ioutes aie neeueu at Porter Lecause the 10.20.12S.3 anu 10.20.12S.+ OSPF ioutes at
Porter alieauy lie on the RPF path Lack to PBR anu Stout, iespectively:
Configure PIM Sparse Mode with Bootstrap RP | 577
[edit]
lab@Bock# show interfaces gr-0/0/0
unit 0 {
tunnel {
source 10.10.12.3;
destination 10.10.12.2;
}
family inet;
}
[edit]
lab@Bock# show routing-options
static {
route 10.20.128.3/32 next-hop gr-0/0/0.0;
route 10.20.128.4/32 next-hop gr-0/0/0.0;
}
[edit]
lab@Bock# show protocols pim
traceoptions {
file pim;
flag bootstrap detail;
}
interface ge-0/0/0.1241;
interface ge-0/0/1.100 {
version 1;
}
interface t1-2/0/2.0;
interface gr-0/0/0.0;
Note that an unnumLeieu GRE tunnel is uelineu, which eliminates the neeu to auveitise
ieachaLility to the tunnel enupoints; local tunnel tiallic is Laseu on the lo0 auuiesses
ol Bock anu Porter, which aie alieauy auveitiseu Ly OSPF. Veiilication Legins Ly ex-
amining Bock`s ioute to the lo0 auuiesses ol PBR anu Stout:
[edit]
lab@Bock#run show route 10.20.128/29
inet.0: 21 destinations, 24 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.20.128.3/32 *[Static/5] 00:04:39
> via gr-0/0/0.0
[OSPF/10] 00:16:27, metric 3
> to 10.10.11.2 via ge-0/0/1.100
10.20.128.4/32 *[Static/5] 00:04:39
> via gr-0/0/0.0
[OSPF/10] 00:16:27, metric 2
> to 10.10.11.2 via ge-0/0/1.100
[edit]
lab@Bock# run show multicast rpf 10.20.128/29
Multicast RPF table: inet.0 , 21 entries
10.20.128.3/32
Protocol: Static
578 | Chapter 11:IP Multicast in the Enterprise
Interface: gr-0/0/0.0
Neighbor: (null)
10.20.128.4/32
Protocol: Static
Interface: gr-0/0/0.0
Neighbor: (null)
The commanu output conliims the piesence ol active static ioutes at Bock anu that the
RPF inteilace to these lo0 auuiesses now points to the GRE tunnel. Note that theie is
no RPF neighLoi (listeu as null) Lecause the tunnel is unnumLeieu in this example.
PIMv2 is conliimeu opeiational on the new GRE inteilace, anu a PIM neighLoi has
Leen uetecteu:
[edit]
lab@Bock# run show pim interfaces
Instance: PIM.master
Name Stat Mode IP V State Count DR address
ge-0/0/0.1241 Up Sparse 4 2 NotDR 1 10.20.130.2
ge-0/0/1.100 Up Sparse 4 1 NotDR 2 10.10.11.3
gr-0/0/0.0 Up Sparse 4 2 P2P 1
pd-0/0/0.32769 Up Sparse 4 2 P2P 0
pe-0/0/0.32770 Up Sparse 4 2 P2P 0
t1-2/0/2.0 Up Sparse 4 2 P2P 1
The RPF issue with ieceiveu Lootstiap messages is iesolveu, thus allowing Bock to leain
the uomain`s C-BSRs. Vith knowleuge ol the uomain`s BSR, Bock goes on to leain the
uomain`s RPs:
[edit]
lab@Bock# run show pim bootstrap
Instance: PIM.master
BSR Pri Local address Pri State Timeout
10.20.128.3 100 10.10.12.3 0 InEligible 125
None 0 (null) 0 InEligible 0
[edit]
lab@Bock# run show pim rps
Instance: PIM.master
Address family INET
RP address Type Holdtime Timeout Groups Group prefixes
10.20.128.3 bootstrap 150 139 1 224.0.0.0/4
10.20.128.4 bootstrap 150 139 1 224.0.0.0/4
IGP connectivity is conliimeu liom Bock to the loopLack auuiess ol PBR:
[edit]
lab@Bock# run traceroute 10.20.128.3
traceroute to 10.20.128.3 (10.20.128.3), 30 hops max, 40 byte packets
1 10.10.12.2 (10.10.12.2) 105.258 ms 71.311 ms 11.741 ms
2 10.20.131.2 (10.20.131.2) 9.808 ms 9.401 ms 9.677 ms
3 10.20.128.3 (10.20.128.3) 10.100 ms 29.484 ms 9.734 ms
Configure PIM Sparse Mode with Bootstrap RP | 579
Anu the use ol PIMv1 on the 10.10.11/2+ suLnet pievents leaining ol the BSR at ioutei
Cider. This completes the PIM Lootstiap tiouLleshooting exeicise:
lab@Cider# run show pim bootstrap
Instance: PIM.master
BSR Pri Local address Pri State Timeout
None 0 10.10.12.1 0 InEligible 26
None 0 (null) 0 InEligible 0
PIM Sparse Mode with Bootstrap RP Summary
In this section, you conliguieu the Lootstiap piotocol to uynamically communicate RP
to gioup mappings. The Lootstiap piotocol allows all iouteis to select the same RP loi
a given gioup, theieLy spieauing the multicast loau among the set ol RPs, with the
hashing lunction ueteimining which gioups aie hanuleu Ly which RP. This section also
showeu how RPF checks can cause contiol plane messages to Le ignoieu, anu it pio-
viueu a cieative solution using a GRE tunnel that ieguiieu no auuitional haiuwaie.
In the next section, you will ueploy Anycast-RP to suppoit uynamic RP election anu
loau Lalancing with this same multicast gioup.
PIM-Based Anycast-RP
The linal multicast conliguiation exeicise in this chaptei involves ueployment ol
Anycast-RP, with emphasis on a PIM-only solution. An alteinative conliguiation using
MSDP is also pioviueu.
Vith Loth auto-RP anu BSR, only one RP is peimitteu to Le active loi any given gioup
at any one time. Anycast-RP ielaxes this iestiiction anu allows multiple RPs to Le active
loi the same gioup at the same time. Anycast-RP ieguiies a mechanism Ly which the
multiple RPs shaie inloimation aLout active souices. This intei-RP communication has
histoiically Leen peiloimeu Ly MSDP, Lut ]unos also suppoits the PIM-only Anycast-
RP solution, as specilieu in RFC +610. The PIM-Laseu solution is attiactive Lecause it
eliminates all neeu loi MSDP within an oiganization, allowing MSDP ueployment as
neeueu, anu then only loi its oiiginal puipose ol inteiuomain multicast suppoit.
Because ol the common RP auuiess that is shaieu among all the RPs, ieceiveis simply
senu theii joins to the metiically closest Anycast-RP, anu they aie unawaie ol the pies-
ence ol multiple RPs.
The conliguiation oLjectives aie as lollows:
Stout anu Bock iemain RPs, Lut Loth must now use 10.255.255.1 loi RP
lunctionality.
Do not use BSR oi auto-RP.
Ensuie no single points ol lailuie.
580 | Chapter 11:IP Multicast in the Enterprise
The ieguiiement that no uynamic RP uiscoveiy mechanisms Le useu may stiike you as
a Lit ouu, especially in light ol the neeu loi netwoik iesiliency to single points ol lailuie.
Recall that with Anycast-RP, all ol the RPs loi a given gioup iange use the same RP
auuiess. Theieloie, as long as at least one Anycast-RP iemains opeiational, the statically
uelineu RP auuiess in non-RP iouteis continues to pioviue the neeueu connectivity. In
an Anycast-RP enviionment, the use ol a uynamic piotocol to piopagate knowleuge ol
the single RP auuiess is a Lit oveikill, Lut ceitainly not illegal.
Figuie 11-16 pioviues a high-level walkthiough ol an Anycast-RP opeiation.
Iigurc 11-1. P|M Anycast-RP opcration
To stait, note how the uomain`s RPs aie saiu to Lelong to an Anycast-RP set. Each RP
within this set must have a unigue, ioutaLle loopLack auuiess that is useu loi RP-RP
(anu othei) communications, as well as a shaieu RP auuiess that, in ellect, iepiesents
all RPs in the set. Fuithei, each RP in the set must have an explicit list ol all othei RPs,
using theii unigue, not shaieu, IP auuiess. Figuie 11-17 shows how R1 anu R+ have a
conliguiation that iuentilies the othei Ly the unigue lo0 IP auuiess.
Step 1 shows Senuei 1 (S1) geneiating native multicast to gioup G1. The uesignateu
ioutei loi S1 encapsulates the multicast into a iegistei message anu senus it to the
Anycast-RP auuiess at step 2. Because all RPs in the set use the same RP auuiess, the
iegistei message is iouteu Ly the IGP to the metiically closest RP, which is R1 in this
PIM-Based Anycast-RP | 581
example. Note that the iegistei message ieceiveu Ly R1 is souiceu Ly R2. Step 3 shows
R1 senuing the now native multicast (iegistei encapsulation has Leen stiippeu) uown
its shaieu tiee towaiu Receivei 1. At step +, R1 cieates its own iegistei message with a
copy ol the oiiginal multicast packet, which is sent to a|| RPs in the Anycast-RP set,
which in this case means that R+ ieceives a iegistei message with R1 as a souice. R+
Lehaves as any othei uesignateu ioutei Ly stiipping the iegistei encapsulation anu
senuing the native multicast uown its shaieu tiee, thus allowing R2 to oLtain a copy.
Configure Anycast-RP
Figuie 11-17 shows the Anycast-RP topology. It uetails how the uomain`s two RPs,
PBR anu Stout, shaie an Anycast-RP auuiess ol 10.255.255.1, in auuition to maintaining
theii unigue loopLack auuiesses. Conliguiation Legins with iemoval ol any existing
RP anu BSR lunctionality at PBR anu Stout (the commit is not shown):
[edit]
lab@PBR# delete protocols pim rp
Iigurc 11-17. Thc Anycast-RP topo|ogy
This action leaves the uomain with no RPsiecall that RP inloimation was Leing uis-
seminateu via Lootstiap, anu the pievious commanu iemoveu all C-RP anu C-BSR
lunctionality liom the uomain.
Configure static RP on non-RP routers
The non-RP iouteis aie a snap to conliguie; a single statement is neeueu to statically
ueline the Anycast-RP auuiess at all iouteis. The conliguiation ol Lager is shown anu
is similai to all othei non-RP noues:
[edit]
lab@Lager#show protocols pim
rp {
582 | Chapter 11:IP Multicast in the Enterprise
static {
address 10.255.255.1;
}
}
interface ge-0/0/0.2131;
interface ge-0/0/0.111;
Altei committing the changes, static RP opeiation is conliimeu at Cider:
[edit]
lab@Cider# run show pim rps
Instance: PIM.master
Address family INET
RP address Type Holdtime Timeout Groups Group prefixes
10.255.255.1 static 0 None 2 224.0.0.0/4
. . .
[edit]
lab@Cider# run show pim join
Instance: PIM.master Family: INET
Group: 224.2.127.254
Source: *
RP: 10.255.255.1
Flags: sparse,rptree,wildcard
Upstream interface: unknown (no route)
Group: 225.1.1.1
Source: *
RP: 10.255.255.1
Flags: sparse,rptree,wildcard
Upstream interface: unknown (no route)
The output shows that the Anycast-RP auuiess is coiiectly conliguieu, Lut theie is
cuiiently no ioute to the Anycast-RP auuiess, which is expecteu given that the Anycast-
RPs have not yet Leen conliguieu.
Configure the Anycast-RPs
Conliguiation ol the Anycast-RP Legins with the auuition ol the shaieu Anycast-RP
auuiess to the lo0 inteilace. The existing (unigue) auuiess is llaggeu as primary to ensuie
no uisiuption to the IGP/BGP contiol plane thiough continueu use ol the unigue lo0
auuiess loi non-PIM-ielateu lunctions, such as OSPF/BGP ioutei ID (RID) selection.
Recall that when not explicitly set unuei routing-options, the RID is oLtaineu liom
the piimaiy auuiess on the system`s uelault inteilace, which is the lowest
non-127.0.0.x auuiess assigneu to the lo0 inteilace:
[edit interfaces lo0 unit 0 family inet]
lab@PBR# set address 10.20.128.3/32 primary
[edit interfaces lo0 unit 0 family inet]
lab@PBR# set address 10.255.255.1
PIM-Based Anycast-RP | 583
By uelault, the numeiically lowest local IP auuiess is consiueieu the
inteilace`s piimaiy auuiess, anu the lo0 inteilace is the uelault inteilace
when a non-127.0.0.x auuiess is conliguieu. The specilics ol this ex-
ample happeneu to use a numeiically highei auuiess loi the Anycast-
RP lunction, making ueclaiation ol the existing lo0 auuiess as piimaiy
technically unnecessaiy. Howevei, making a mistake heie can leau to
the uillicult pioLlem ol tiouLleshooting missing ioutes uue to uuplicate
RIDs, making the extia conliguiation step insuiance that is well woith
having.
The mouilieu lo0 conliguiation is shown:
[edit interfaces lo0 unit 0 family inet]
lab@PBR# show
address 10.20.128.3/32 {
primary;
}
address 10.255.255.1/32;
Similai changes aie also maue to Stout`s lo0 conliguiation. PIM-Laseu Anycast-RP is
conliguieu at the [edit protocols pim rp local family inet] hieiaichy. The upuateu
conliguiation anu ielateu set commanus aie shown loi PBR:
[edit protocols pim rp local family inet]
lab@PBR# show
address 10.255.255.1;
anycast-pim {
rp-set {
address 10.20.128.4;
}
}
[edit protocols pim rp local family inet]
lab@PBR# show | display set
set protocols pim rp local family inet address 10.255.255.1
set protocols pim rp local family inet anycast-pim rp-set address
10.20.128.4
Once again, a similai conliguiation is auueu anu committeu at Stout, whose conligu-
iation coiiectly specilies PBR`s unigue lo0 auuiess unuei its rp-set stanza.
Verify the Anycast-RPs
Altei a lew minutes, PIM join state is examineu at Cider:
[edit]
lab@Cider# run show pim join 225.1.1.1
Instance: PIM.master Family: INET
Group: 225.1.1.1
Source: *
RP: 10.255.255.1
Flags: sparse,rptree,wildcard
Upstream interface: unknown (no route)
584 | Chapter 11:IP Multicast in the Enterprise
D
o
The uisplay inuicates that Cider still uoes not know how to ioute to the Anycast-RP
auuiess. This is guickly conliimeu with a show route commanu:
[edit]
lab@Cider# run show route 10.255.255.1
Going Lack to one ol the Anycast-RPs, the pioLlem is guickly uncoveieu:
[edit]
lab@PBR# run show ospf interface
Interface State Area DR ID BDR ID Nbrs
ge-0/0/0.111 BDR 0.0.0.0 10.10.128.2 10.20.128.3 1
ge-0/0/0.1241 BDR 0.0.0.0 10.10.12.3 10.20.128.3 1
ge-0/0/0.3141 BDR 0.0.0.0 10.20.128.4 10.20.128.3 1
OSPF is not iunning on the lo0 inteilace, which pievents the newly auueu 10.255.255.1
Anycast-RP auuiess liom Leing auveitiseu into OSPF. Recall that ]unos`s uelault is to
auveitise a stuL ioute to the inteilace liom which the ioutei oLtains its RID. The ioutei
uses the piimaiy auuiess on the uelault inteilacewhich is noimally the lo0 inteilace
Ly uelaultas the RID; this is why the 10.20.12S.3 lo0 auuiess at PBR has Leen auvei-
tiseu into OSPF uespite OSPF not Leing enaLleu on that inteilace pieviously.
They automatically auveitise the souice ol the RID Lehavioi changeu in
ielease S.5 uue to PR 229200. In allecteu ieleases, you shoulu iun a
passive OSPF instance on the ioutei`s lo0 to ensuie the ioute is auvei-
tiseu into OSPF, which is neeueu loi piopei PIM lunctioning.
A passive OSPF instance is conliguieu to iun on the lo0 inteilace ol Loth Anycast-RPs
to get Loth ol the assigneu lo0 auuiesses auveitiseu into OSPF:
[edit]
lab@PBR# set protocols ospf area 0 interface lo0 passive
The OSPF uataLase conliims that PBR is now auveitising the 10.255.255.1 auuiess:
[edit]
lab@PBR# show ospf database advertising-router 10.20.128.3 router
detail
OSPF link state database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.20.128.3 10.20.128.3 0x800000b4 41 0x22 0xff76 84
bits 0x2, link count 5
id 10.10.111.3, data 10.10.111.2, Type Transit (2)
TOS count 0, TOS 0 metric 2
id 10.20.130.1, data 10.20.130.2, Type Transit (2)
TOS count 0, TOS 0 metric 68
id 10.20.129.1, data 10.20.129.2, Type Transit (2)
TOS count 0, TOS 0 metric 1
id 10.20.128.3, data 255.255.255.255, Type Stub (3)
TOS count 0, TOS 0 metric 0
id 10.255.255.1, data 255.255.255.255, Type Stub (3)
TOS count 0, TOS 0 metric 0
PIM-Based Anycast-RP | 585
The change allows Cider to ioute towaiu the Anycast-RP auuiess, which in tuin peimits
it to join the shaieu tiee loi 225.1.1.1:
[edit]
lab@Cider# run show pim join
Instance: PIM.master Family: INET
Group: 224.2.127.254
Source: *
RP: 10.255.255.1
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/1.100
Group: 225.1.1.1
Source: *
RP: 10.255.255.1
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/1.100
The cuiient ioute to the Anycast-RP is uisplayeu at Cider:
[edit]
lab@Cider# run show route 10.255.255.1
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.255.255.1/32 *[OSPF/10] 00:03:53, metric 2
> to 10.10.11.2
via ge-0/0/1.100
[edit]
lab@Cider# run traceroute 10.255.255.1
traceroute to 10.255.255.1 (10.255.255.1), 30 hops max, 40 byte packets
1 10.10.11.2 (10.10.11.2) 79.285 ms
98.810 ms 99.739 ms
2 10.255.255.1 (10.255.255.1) 10.293 ms 9.213 ms 29.762 ms
The output shows that Stout is the RP cuiiently useu Ly Cider. Failovei to the metiically
closest Anycast-RP is testeu Ly incieasing the path metiic on the Porter-Stout link to
300:
lab@Porter# set protocols ospf area 0 interface ge-0/0/1.1331 metric 300
Anu the change is veiilieu Lack at Cider, which still thinks it is using the same RP, Lut
in ieality, its join now goes to PBR via Bock:
[edit]
lab@Cider# run show pim join 225.1.1.1
Instance: PIM.master Family: INET
Group: 225.1.1.1
Source: *
RP: 10.255.255.1
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/1.100
586 | Chapter 11:IP Multicast in the Enterprise
[edit]
lab@Cider# run show route 10.255.255.1
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.255.255.1/32 *[OSPF/10] 00:19:02, metric 69
> to 10.10.11.1
via ge-0/0/1.100
[edit]
lab@Cider# run traceroute 10.255.255.1
traceroute to 10.255.255.1 (10.255.255.1), 30 hops max, 40 byte packets
1 10.10.11.1 (10.10.11.1) 19.018 ms
12.334 ms 16.235 ms
2 10.255.255.1 (10.255.255.1) 9.630 ms 29.665 ms 10.108 ms
The linal PIM conliguiation is shown loi Anycast-RP noue Stout:
[edit]
lab@stout# show protocols pim
rp {
local {
family inet {
address 10.255.255.1;
anycast-pim {
rp-set {
address 10.20.128.3;
}
}
}
}
}
interface ge-0/0/0.2131;
interface ge-0/0/0.3141;
interface ge-0/0/1.1331;
The asymmetiic metiics (which is haiu to say) in ellect cause liist hop ioutei Lager to
senu its iegistei message to PBR, while ieceivei Cider senus its join towaiu Stout. Vhen
PBR ieceives the iegistei message liom Lager, it geneiates a copy, souiceu liom its unigue
lo0 auuiess, anu senus it to Anycast-RP set memLei Stout. This allows Stout to uelivei
a copy ol the multicast packet to Cider ovei the shaieu tiee, which in tuin geneiates an
(S,G) join to estaLlish an SPT. Registei message tiacing is auueu to Lager anu Stout to
illustiate Anycast-RP inteiaction:
[edit]
lab@Lager# run traceroute 10.255.255.1
traceroute to 10.255.255.1 (10.255.255.1), 30 hops max, 40 byte
packets
1 10.255.255.1 (10.255.255.1) 29.511 ms 38.646 ms 10.129 ms
PIM-Based Anycast-RP | 587
The tiaceioute conliims that Lager sees PBR as the metiically closest RP. The multicast
souice is staiteu, anu iegistei tiacing is oLseiveu at Lager. Note that the iegistei is
souiceu liom Lager anu sent to the shaieu Anycast-RP auuiess:
[edit]
Sep 29 06:08:13.825061PIM SENT 10.10.128.2 -> 10.255.255.1 V2
Register Flags: 0x40000000 Border: 0 Null: 1 Source 10.10.111.1
Group 225.1.1.1 sum 0x43f1 len 28
The iegistei stop Lack liom the Anycast-RP inuicates that an SPT has Leen estaLlisheu
oi that no moie inteiesteu ieceiveis aie lelt on the shaieu tiee:
lab@Lager# Sep 29 06:06:13.774885 PIM ge-0/0/0.2131 RECV 10.255.255.1
-> 10.10.128.2 V2 RegisterStop Source 10.10.111.1 Group 225.1.1.1 sum
0x80d1 len 18
The iegistei message tiace output is oLseiveu at Stout:
[edit]
lab@stout# Sep 29 06:45:28.549924 PIM ge-0/0/0.3141 RECV 10.20.128.3
-> 10.20.128.4 V2 Register Flags: 0x00000000
Border: 0 Null: 0 Source
10.10.111.1 Group 225.1.1.1 sum 0xdeff len 92
Sep 29 06:45:28.553631 PIM SENT 10.20.128.4 -> 10.20.128.3 V2
RegisterStop Source 10.10.111.1 Group 225.1.1.1 sum 0x80d1 len 18
Stout`s tiace shows that it ieceives a iegistei liom PBRnote how the iegistei message
is sent liom/to the unigue lo0 auuiesses ol PBR anu Stout, iespectively. This mechanism
uilleientiates iegisteis ieceiveu liom liist hop iouteis, which aie sent to the Anycast-
RP auuiess, liom those ieceiveu liom othei RPs. The loimei aie echoeu to all othei
RPs in the RP set, wheieas the lattei aie aLsoiLeu anu acteu upon locally. Lastly, the
show pim source commanu is executeu at Stout to conliim the leaining ol active gioup
225.1.1.1 via an Anycast-RP souice, as inuicateu Ly the 10.255.255.1 auuiess:
[edit]
lab@stout# run show pim source detail
Instance: PIM.master Family: INET
Source 10.10.111.1
Prefix 10.10.111.0/24
Upstream interface ge-0/0/0.2131
Upstream neighbor 10.10.131.1
Active groups:225.1.1.1
Source 10.255.255.1
Prefix 10.255.255.1/32
Upstream interface Local
Upstream neighbor Local
Active groups:225.1.1.1
224.2.127.254
588 | Chapter 11:IP Multicast in the Enterprise
What about MSDP?
Anycast-RP using native PIM is somewhat new, anu you may linu that some ol the
iouteis in youi netwoik uo not suppoit this methou. In this case, you will neeu to
ueploy Anycast-RP using MSDP peeiing Letween all the RPs in the uomain. MSDP
conveys inloimation aLout active souices Letween the uomain`s RPs. A woiking MSDP
conliguiation loi the cuiient Anycast-RP topology is auueu to PBR anu Stout. The con-
liguiation ol MSDP is similai to that ol PIM-Laseu Anycast-RP, anu it involves listing
the unigue neighLoi auuiesses ol all Anycast-RPs in the uomain. The shaieu anu unigue
IP auuiesses assigneu to the lo0 inteilace aie ieuseu liom the pievious PIM-Laseu
Anycast-RP example. The mouilieu conliguiation at PBR is as lollows:
[edit]
lab@PBR# show protocols pim
rp {
local {
address 10.255.255.1;
}
}
interface ge-0/0/0.3141;
interface ge-0/0/0.1241;
interface ge-0/0/0.111;
[edit]
lab@PBR# show protocols msdp
peer 10.20.128.4 {
local-address 10.20.128.3;
}
The local-address statement ensuies that the iemote MSDP peei iecognizes the con-
nection as coming liom one ol its uelineu peeis. As with loopLack-Laseu BGP peeiing,
one enu`s local-address shoulu match the othei enu`s peei uelinition. You can use a
similai statement with PIM-Laseu anycast, Lut we omitteu it Lecause Ly uelault, PIM
messages aie souiceu liom the piimaiy auuiess on the lo0 inteilace.
Altei staiting up the multicast souice, the MSDP session state anu listing ol leaineu
souices is uisplayeu at Stout:
[edit]
lab@stout# run show msdp
Peer address Local address State Last up/down Peer-Group SA Count
10.20.128.3 10.20.128.4 Established 00:07:56 1/1
[edit]
lab@stout# run show msdp source-active
Group address Source address Peer address Originator Flags
225.1.1.1 10.10.111.1 10.20.128.3 10.20.128.3 Accept
These iesults complete the PIM spaise moue Anycast-RP conliguiation anu veiilication
example.
PIM-Based Anycast-RP | 589
PIM Sparse Mode with Anycast-RP Summary
This section uemonstiateu a PIM-Laseu solution to Anycast-RP anu showeu a woiking
example that is Laseu on MSDP. Because Anycast-RP has inheient lault toleiance, it`s
common to use a static RP uelinition on client iouteis to avoiu the complexities ol a
uynamic RP election piotocol such as the Lootstiap oi auto-RP piotocol.
Conclusion
IP multicast olleis the Lest ol all woilus when suppoiting one-to-many oi many-to-
many applications. Using a unicast mouel loi these applications guickly stiesses pio-
cessing powei at the souice uue to ieplication loau, anu maximum netwoik Lanuwiuth
is consumeu. Using Lioaucast is expensive loi all hosts anu is conlineu to a single
segment oi Liiuging uomain. Only IP multicast olleis a scalaLle, stanuaiuizeu way to
hanule multipoint stieams in a mannei that uistiiLutes ieplication loau anu conseives
netwoik Lanuwiuth when Lianches have no inteiesteu listeneis. Many netwoik opei-
atois aie unlamiliai with IP multicast, which limits its wiuespieau use. Multicast shoulu
Le lookeu at any time a netwoik is uesigneu oi ieuesigneu as a potentially poweilul
optimization tool that can also enaLle the iollout ol emeiging viitual simulation oi
multiplayei applications.
PIM spaise moue has Lecome the pieuominant multicast iouting piotocol given its
suppoit ol uense, spaise, anu spaise-uense moues ol opeiation anu the vaiiety ol
mechanisms that can Le useu to uynamically uistiiLute RP inloimation in a lault-
toleiant mannei. This chaptei uemonstiateu typical PIM spaise moue ueployment sce-
naiios using static anu Lootstiap-Laseu RP uissemination, anu it showeu PIM- anu
MSDP-Laseu examples ol Anycast-RP. ]unos suppoits a wiue iange ol IP multicast
stanuaius anu makes multicast conliguiation anu veiilication ielatively
stiaightloiwaiu.
Exam Topics
Ve examineu the lollowing Enteipiise Exam Topics in this chaptei:
Distance Vectoi Multicast Routing Piotocol (DVMRP)
Piotocol Inuepenuent Multicast uense moue (PIM-DM)
Piotocol Inuepenuent Multicast spaise moue (PIM-SM)
Bootstiap, auto-RP, anycast
Souice-specilic multicast (SSM)
590 | Chapter 11:IP Multicast in the Enterprise
Chapter Review Questions
1. Vhich RP uissemination mechanism suppoits loau Lalancing within the same
gioup?
A. Auto-RP
B. Anycast-RP
C. Bootstiap
D. Static
2. Vhich RP uissemination mechanism suppoits loau Lalancing on a gioup-Ly-gioup
Lasis?
A. Auto-RP
B. Anycast-RP
C. Bootstiap
D. Static
3. Vhich methous can you use to scope Lootstiap messages?
A. This is not possiLle given the hop-Ly-hop loiwaiuing using the All PIM Routeis
auuiess
B. By conliguiing Lootstiap impoit oi expoit policy
C. By conliguiing RP iegistei policy
D. By conliguiing PIMv2 on exteinal inteilaces
+. Vhich coiiectly uesciiLes spaise-uense moue opeiation?
A. Floouing all tiallic until a piune is ieceiveu, then switching to spaise moue
B. Opeiating in spaise moue until a join is ieceiveu, then switching to uense moue
C. Opeiating in spaise moue, with the exception ol specilic gioups that aie tiea-
teu as uense
D. Spaise-uense moue is neeueu to suppoit Anycast-RP
5. Vhich coiiectly uesciiLes PIM iegistei policy?
A. It allows you to liltei iegistei messages to contiol RP usage
B. It contiols which C-RPs can iegistei with the BSR loi inclusion in the RP set
C. It suppoits Anycast-RP Ly allowing intei-RP communication iegaiuing active
souices
D. It contiols when the last hop ioutei ueciues to join an SPT
6. Vhich coiiectly uesciiLes the uelault ]unos PIM spaise moue Lehavioi?
A. The liist hop ioutei initiates an SPT join as soon as the liist packet is sent
B. The last hop ioutei initiates an SPT join as soon as the liist packet is ieceiveu
Chapter Review Questions | 591
C. The liist hop ioutei initiates an RPT join Leloie the souice Lecomes active
D. The last hop ioutei initiates an RPT join as soon as tiallic is ieceiveu ovei the
SPT
7. Vhat commanu uisplays uynamic multicast loiwaiuing state in the uata plane?
A. show pim route
B. show multicast route
C. show multicast rpf
D. show route table inet.2
S. Vhich ol the lollowing Lest uesciiLes an RPF check?
A. It uiscaius packets that aie ieceiveu on an inteilace that is not useu when
iouting Lack to that souice
B. It nevei senus a multicast packet out the inteilace useu to ieach the souice
C. It senus an SPT join out the inteilace useu when iouting to that souice
D. All ol the aLove
9. Vhich is tiue iegaiuing Anycast-RP?
A. A shaieu 127.0.0.1 auuiess is auueu to the lo0 inteilace
B. The Anycast-RPs must communicate with each othei using the Anycast-RP
auuiess
C. Anycast-RP messages aie llooueu using spaise-uense moue
D. The Anycast-RPs must communicate with each othei using theii unigue lo0
auuiesses
10. Relei to the output pioviueu anu select the Lest answei:
lab@Porter> show multicast route
Family: INET
Group: 225.1.1.1
Source: 10.10.111.1/32
Upstream interface: ge-0/0/1.1331
Downstream interface list:
ge-0/0/1.100
A. This is an (S,G) entiy on the RPT
B. This is an (',G) entiy on the RPT
C. This entiy is piuneu Lecause only one inteilace exists in the outgoing list
D. This entiy exists in the contiol plane as a iesult ol an (',G) join
E. This entiy exists in the uata plane as a iesult ol multicast tiallic
11. Vhich ol the lollowing is tiue?
A. IGMPv1 suppoits gioup leaves
B. IGMPv3 suppoits gioup leaves anu SSM joins
592 | Chapter 11:IP Multicast in the Enterprise
C. IGMPv2 ielieu on the iouting piotocol to peiloim the gueiiei lunction
D. IGMP must Le explicitly conliguieu to iun on PIM-enaLleu inteilaces
12. The gueiiei ioutei senus a gueiy loi gioup 225.1.1.1. Vhat auuiess is the gueiy
sent to?
A. The All PIM Routeis multicast auuiess
B. The All Hosts multicast auuiess
C. The unicast auuiess ol the host that sent the memLeiship
D. The auuiess associateu with the gioup Leing gueiieu
Chapter Review Answers
1. Answei: B. Only Anycast-RP allows multiple RPs to Le active at the same time loi
the same gioup.
2. Answei: C. The BSR mechanism automatically Lalances, on a gioup-iange Lasis,
among a set ol C-RPs using a uistiiLuteu hash lunction.
3. Answei: B. PIM Lootstiap policy can Le useu to liltei BSR messages Leing sent oi
ieceiveu. Using PIMv1 also Llocks BSR, as it is not suppoiteu in that veision.
+. Answei: C. Spaise-uense opeiation uelaults to spaise moue, except loi gioups ex-
plicitly uesignateu as uense.
5. Answei: A. PIM iegistei policy allows lilteiing ol iegisteis at the liist hop, oi at the
RP, which contiols the numLei ol sessions on the RP.
6. Answei: B. The last hop ioutei is in chaige ol making the switch liom RPT to SPT,
anu in ]unos, this occuis upon ieceipt ol the liist packet.
7. Answei: B. The show multicast route commanu uisplays uynamic uata plane state
that iesults liom multicast tiallic. ]oin-ielateu commanus show contiol plane state.
S. Answei: D. All ol the opeiations uesciiLeu aie Laseu on an RPF check.
9. Answei: D. Anycast-RP ieguiies a shaieu, anu unigue, lo0 auuiess; the unigue
auuiess is useu loi RP-RP communication.
10. Answei: E. This is a multicast ioute, in the uata plane, which is cieateu when
alloweu Ly join state anu when uata activity occuis. This is an (S,G) entiy, anu
theieloie it is not on the RPT.
11. Answei: B. IGMPv3 suppoits v2`s gioup leave as well as SSM.
12. Answei: D. A gioup gueiy is sent to the multicast auuiess ol the gioup itsell.
Chapter Review Answers | 593
CHAPTER 12
Junos Security Services
The ielease ol secuiity seivices incoipoiateu into ]unos iepiesents a signilicant step
loiwaiu in solving the neeus ol enteipiise netwoiks. Vith these seivices, ]unipei iouteis
can lill most ioles in the enteipiise oi act as all-in-one uevices. This chaptei is not
intenueu to pioviue complete coveiage ol the new secuiity capaLilities lounu in ]unos.
The goal is to piepaie the ieauei with enough inloimation so that you can install a
]unipei ioutei as a secuiity uevice in the enteipiise. The leatuies anu capaLilities aie
piesenteu in a case scenaiio that positions the secuiity uevice as an Inteinet egiess
liiewall.
The secuiity topics incluue:
A shoit histoiy ol secuiity leatuies lounu in ]unipei piouucts
A uesciiption ol the scenaiio that is useu to illustiate the vaiious secuiity leatuies
A uesciiption ol llow-Laseu tiallic piocessing
The secuiity leatuies suppoiteu in ]unos
Junos Software and Security
Piioi to Release S.5, ]unipei hau two means to suppoit secuiity leatuies: the Netscieen
uevices anu ]unos seivice sets. Staiting with Release S.5, ]unos engineeis integiateu
these two leatuie sets into the ]unipei iouteis, cieating ]unos soltwaie with enhanceu
seivices. Foi a numLei ol ieleases, two veisions ol ]unos weie suppoiteu, with oi with-
out enhanceu seivices. Staiting with Release 9.+, the two opeiating systems Lecame
one ]unos. Although the secuiity leatuies anu llow-Laseu piocessing can Le tuineu oll,
loi the ]-seiies anu the SRX seiies ol uevices the soltwaie aichitectuie is Laseu upon a
session llow hanuling ol packets.
This is not a secuiity-locuseu Look, anu theieloie, compiehensive coveiage ol secuiity
anu secuiity leatuies is not possiLle. This chaptei coveis those leatuies that aie com-
monly lounu in an enteipiise. A complete tieatment ol secuiity leatuies anu seivices
can Le lounu in junos Sccurity, Ly RoL Cameion et al. (O`Reilly).
595
Do I Need a Router or a Security Device?
In the past, useis weie expecteu to make some tough uecisions when Luiluing out a
new oi existing netwoik. Specilically, they olten hau to choose a uevice Laseu on what
was moie impoitant: woilu-class iouting oi woilu-class seivices. Vhen Loth weie
egually impoitant, a two-Lox, Lest-ol-Lieeu solution was olten pioposeu. In this mouel,
you hau seivices/secuiity uevices that weie ueployeu with a ioutei inliastiuctuie. In a
uiviue-anu-conguei mouel such as this, each uevice was lelt to uo what it uiu Lest, with
the comLineu ellect Leing the Lest ol Loth woilus.
Although the two-Lox solution was woikaLle, anu in lact is olten the iecommenueu
solution touay, such a uesign sulleis liom seveial uiawLacks: two Loxes aie moie ex-
pensive than one; theie is a gieatei chance ol lailuie uue to moie components; anu
geneially, each new Lox auueu to the netwoik incieases oveiall opeiational costs.
Best-of-breed routing and security services
The secuiity leatuies ol ]unos holu the veiy ieal piomise ol eliminating the neeu loi a
two-Lox solution. By comLining the powei anu pioven peiloimance ol ]unos soltwaie
anu its iouting piotocols with enhanceu secuiity anu seivices, useis aie aLle to get the
Lest ol Loth woilus, all in a single Lox.
Security-Based Enterprise Scenario
The lollowing sections explain the secuiity leatuies (NAT, statelul lilteis, VPNs, anu
the like) anu piesent conliguiation examples. It is moie illustiative to give these leatuies
a context. To uo this, we have taken oui laL enteipiise anu auueu a secuiity thieat,
the Inteinet. Figuie 12-1 shows that an Inteinet link has Leen auueu to PBR. Foi sim-
plicity, a single Inteinet link is in use. Beei-Co has a puLlic weLsite that is useu loi
oiueis anu specials. The company has a local email seivei anu an inteinal DNS seivei
that must communicate to the Inteinet, anu all employees have lull Inteinet access.
Beei-Co uses a piivate auuiessing scheme loi inteinal communications Lut has Leen
given a set ol puLlic IP auuiesses Ly the ISP.
The allocation ol the IP auuiesses is:
71.11.12.1
PuLlic weL seivei
71.11.12.2
DNS seivei
71.11.12.3
Email seivei
71.11.12.1
PuLlic NAT entiy
596 | Chapter 12:Junos Security Services
71.11.12.5
PBR puLlic inteilace
Beei-Co has supplieis that use the Inteinet loi connectivity, anu one suppliei,
Oats.com, uses an IPSec-Laseu VPN to inteiact with Beei-Co.
Iigurc 12-1. |ntcrnct acccss jor Bccr-Co |nc.
Packet- Versus Flow-Based Processing
Histoiically, ]unipei Netwoiks iouteis use a packet-Laseu loiwaiuing mouel, in which
each packet is inuiviuually piocesseu anu iouteu. In contiast, the ]unipei secuiity ue-
vices aie Laseu on a llow mouel. Hanuling tiallic as llows olleis signilicant Lenelits loi
statelul seivices. In the llow mouel, the initial packets ol a communication aie suLjecteu
to vaiious levels ol packet secuiity inspections anu valiuity checks, in auuition to a
sing|c ioute lookup. Once the packet is ueemeu peimissiLle, a coiiesponuing session
state is installeu into the loiwaiuing plane to lacilitate expeuiteu loiwaiuing loi suL-
seguent packets Lelonging to the same llow. In ellect, the liist packets aie ueeply sciu-
tinizeu, anu the iemaining packets ol the same session lollow a last path thiough the
piocessing.
A j|ow is a uniuiiectional seguence ol packets. The matching llow in the ietuin uiiection
is gioupeu to loim a session, which is theieloie composeu ol two uniuiiectional llows.
The sessions iellect the applications that tiansit the liiewall.
Junos Software and Security | 597
Architecture Changes
The auuition ol statelul secuiity to ]unos iepiesents some signilicant changes in contiol
plane capaLilities thiough the intiouuction ol new seivice uaemons anu in packet loi-
waiuing Lehavioi with the auuition ol llow-Laseu piocessing. This section pioviues a
high-level oveiview ol these changes.
Adding flow-based forwarding
One ol the piimaiy changes in ]unos is the auuition ol llow-Laseu piocessing. This is
implementeu along with the existing packet-Laseu piocessing capaLilities, such as
stateless liiewall lilteis. The changes in ]unos iesult in a comLination ol packet- anu
llow-Laseu tieatments, as shown in Figuie 12-2.
Iigurc 12-2. Conbincd pac|ct- and j|ow-bascd proccssing
Figuie 12-2 shows the packet anu llow piocessing in ]unos. An incoming packet is
analyzeu at the inteilace as a stateless entity loi policeis anu liiewall lilteis. Il the packet
passes these checks, the llow piocessing Legins.
598 | Chapter 12:Junos Security Services
Flow-Laseu piocessing is peiloimeu Ly the llow uaemon (llwuu). This
piocess iuns in paiallel with the othei piocesses in ]unos anu uses ex-
tensive iesouices. Il llow-Laseu piocessing is uisaLleu on the ioutei,
llwuu uoes not ielease the iesouices ol the piocessoi. Resouice man-
agement is a concein loi systems that peiloim iesouice-heavy tasks
(e.g., lull Inteinet leeus) anu have llwuu. As ol this wiiting, it is not
possiLle to lully uisaLle llwuu.
A llow is a uniuiiectional stieam ol ielateu packets that meet the same matching ciiteiia
anu shaie the same chaiacteiistics. Two llows aie comLineu (ingiess anu egiess) to
loim a session. ]unos tieats packets Lelonging to the same session in the same mannei.
Specilically, conliguiation settings that ueteimine the late ol a packetsuch as the
secuiity policy that applies to it, whethei the packet is sent thiough an IPSec tunnel,
oi whethei NAT is applieuaie assesseu loi the liist packet ol a session. The iesultant
set ol actions anu seivices is applieu to the iest ol the packets in the session. The lol-
lowing ciiteiia aie useu to ueteimine whethei a packet matches an existing session:
Souice auuiess
Destination auuiess
Souice poit
Destination poit
Piotocol
The statelul hanuling ol tiallic ieguiies the cieation ol a session. A
session is cieateu Laseu on the chaiacteiistics ol the liist packet in a llow. Sessions aie
useu loi:
Stoiing secuiity measuies to Le applieu to the packets ol the llow
Caching inloimation aLout the state ol the llowthat is, logging anu counting
uata loi a llow is cacheu in its session
Allocating ieguiieu iesouices loi leatuies such as NAT anu IPSec tunnels
Pioviuing a liamewoik loi leatuies such as Application Layei Gateways (ALGs)
The comLineu ellects ol llow anu session state Liing togethei the lollowing leatuies
anu events that allect a packet as it unueigoes llow-Laseu piocessing:
Flow-Laseu loiwaiuing
Session management, incluuing session aging anu changes in ioutes, policy, anu
inteilaces
Management ol VPNs, ALGs, anu authentication
Management ol policies, NAT, zones, anu scieens
Each session iesulting liom a llow is associateu with a timeout value. Foi example, the
uelault timeout loi the Tiansmission Contiol Piotocol (TCP) is 30 minutes; the uelault
Flows and sessions.
Junos Software and Security | 599
timeout loi the Usei Datagiam Piotocol (UDP) is 1 minute. Vhen a llow is teiminateu,
it is maikeu as invaliu, anu its timeout is ieuuceu to 10 seconus. You can change the
iule timeout value; it is uesigneu to ensuie that system iesouices aie not tieu up inuel-
initely on an otheiwise uelunct llow.
Session timeouts aie associateu with specilic seivices within ]unos.
Changing a timeout loi a pieuelineu seivice can cause unexpecteu ie-
sults anu shoulu Le uone with caution. Foi some seivices (e.g., teiminal
emulation), the session might Le open on a uesktop loi houis without
tiallic. In these cases the seivice timeout can Le extenueu to accommo-
uate this tiallic pattein.
Junos security packet walk
In this section, we will lollow a packet as it tiaveises the ]unos uata plane, wheie it
encounteis a mix ol packet- anu llow-Laseu hanuling steps. Figuie 12-2 shows the steps
uesciiLeu in the lollowing text.
The steps shown loi the liist path iepiesent the lull set ol checks anu seivice instan-
tiations that you can peiloim against the initial packets ol a session. In contiast, the
last path iepiesents the stieamlineu steps executeu loi pieviously piocesseu (anu ac-
cepteu) sessions. The two-stage appioach pioviues the aLility to ueeply inspect initial
packets, which is computationally expensive Lut neeueu loi tiue secuiity, while at the
same time olleiing high thioughput Ly switching peimitteu tiallic Laseu on estaLlisheu
session state. It shoulu Le noteu that not all packets neeu to Le toucheu at all possiLle
piocessing points. Foi example, NAT is optional, anu when not conliguieu, NAT pio-
cessing is not evokeu. The packet piocessing steps aie as lollows:
1. Accept an incoming packet, peiloim class ol seivice (CoS) Lehavioi aggiegate (BA)
classilication, anu note the ingiess inteilace`s zone loi latei policy lookup.
2. Piocess the packet thiough the ingiess policei/shapei.
3. Evoke the multilielu CoS classilication oi the liiewall liltei.
+. Peiloim a lookup session; il no match, lollow the liist path:
a. Conuuct a liiewall scieen check.
L. Peiloim uestination NAT as ieguiieu loi the incoming packet.
c. Peiloim a ioute lookup to ueteimine the egiess inteilace.
u. Locate the uestination (outgoing) zone, Laseu on the ioute lookup iesult.
e. Look up anu execute policy Laseu on incoming anu outgoing zones; iesults
incluue peimit, ueny, anu ieject.
l. Allocate the souice NAT auuiess to the packet.
g. Set up ALGs as neeueu to suppoit iuentilieu applications.
h. Install a session tuple loi last path piocessing ol ielateu packets.
600 | Chapter 12:Junos Security Services
Il a session is matcheu, lollow the last path:
a. Monitoi the tiallic loi scieen violations.
L. Peiloim TCP checks to look loi connection anomalies anu match iesponses.
c. Conuuct NAT tianslation as ieguiieu.
u. Peiloim ALG piocessing as neeueu.
5. Vhethei liist oi last path, peiloim loiwaiuing seivices on the packet Laseu on the
session inloimation.
6. Peiloim egiess liiewall lilteiing, which can evoke a policei action.
7. Peiloim egiess shaping oi inteilace-level policing; scheuule anu tiansmit the
packet.
Junos Security Summary
Integiating secuiity leatuies into ]unos soltwaie is a signilicant milestone in the solt-
waie`s evolution. Looking Lack at Figuie 12-2, you can appieciate the comLineu one-
two punch ol these seivices in ]unos. You can now have the Lest ol all woilus: the
lamiliai ]unos soltwaie CLI, its pioven mouulai uesign that sepaiates the contiol anu
uata planes, the two-stage commit piocess, commit anu opeiational sciipts, anu woilu-
class iouting piotocol implementations. On top ol this, you also get signilicant secuiity
anu seivice leatuies anu enhancements.
The comLineu packet- anu llow-Laseu piocessing means that packet-Laseu leatuies
ielating to liiewall lilteis, policeis, anu shapeis, packet classilication, gueuing, anu CoS
continue to opeiate as Leloie. Likewise, ASP-Laseu platloims such as the M10i anu
M7i will continue to use the seivice conliguiations anu moues uesciiLeu in Chap-
tei 9 anu Appenuix A, which covei Layei 2 anu Layei 3 seivices, iespectively.
Foi useis initially ueploying uevices with these secuiity leatuies, the ieveise stance on
uenying veisus accepting packet llows Ly uelault might take a Lit ol getting useu to.
The choice ol ioutei veisus secuie opeiating contexts helps to mitigate this issue anu
allows you to ueploy your ioutei so that it opeiates like a tiauitional ioutei oi as an
integiateu liiewall ioutei, as ieguiieu Ly the neeus ol youi netwoik.
Understanding Junos Operational Modes
A ]-seiies Seivices Routei oi an SRX Seivices Gateway can opeiate as eithei a statelul
liiewall oi a ioutei, uepenuing on whethei it is in the secuie oi ioutei context:
Sccurc contcxt
This moue allows the uevice to act as a piuuent statelul liiewall. To allow tiallic
to pass thiough the uevice, you must explicitly conliguie a secuiity policy loi that
puipose. In secuie context, the ioutei loiwaius packets only il a secuiity policy
Junos Software and Security | 601
peimits it. All tiansit tiallic is piocesseu as tiallic llows anu assigneu to sessions
when peimitteu Ly the policies.
All ]-seiies iouteis anu SRX Seivices Gateways aie shippeu liom the lactoiy in a
secuie context.
Routcr contcxt
This moue allows a ioutei to act as a packet-Laseu stateless ioutei in which all
management anu tiansit tiallic is alloweu. In ioutei context, tiallic is hanuleu in
a pei-packet moue ol opeiation anu no secuiity policies aie neeueu to pioviue
connectivity.
Switching between secure and router contexts
Switching Letween secuie anu ioutei contexts is peiloimeu Ly auuing the packet moue
commanus to the secuiity stanza. Once these commanus aie enteieu, all tiallic is pio-
cesseu in a stateless mannei. The iemainuei ol the secuiity stanza is ellectively ignoieu.
The commanus aie:
peter@pbr# show security
security {
...
forwarding-options {
family {
inet {
mode packet-based;
}
inet6 {
mode packet-based;
}
mpls {
mode packet-based;
}
}
}
}
Default configurations
The uelault conliguiation on the ]-seiies anu SRX Seivices Gateways is mouel-
uepenuent. Each SRX mouel has a uilleient uelault conliguiation, as uo the ]-seiies
iouteis. Oui laL ]-2320s have the lollowing uelault conliguiation:
The Luilt-in GigaLit Etheinet inteilace, ge-0/0/0, is Lounu to a pieconliguieu zone
calleu trust. All othei inteilaces aie not Lounu to any zone.
The ge-0/0/0 inteilace is conliguieu to allow management access with Secuie Shell
(SSH) anu Hypeitext Tianslei Piotocol (HTTP) seivices enaLleu. The lollowing
host-inLounu seivices aie conliguieu loi the ge-0/0/0 inteilace in the tiust zone:
602 | Chapter 12:Junos Security Services
HTTP
HTTPS
SSH
Telnet
Dynamic Host Conliguiation Piotocol (DHCP)
TCP ieset is enaLleu in the tiust zone, anu the uelault policy loi the tiust zone
allows tiansmission ol tiallic liom the tiust zone to the untiust zone.
All tiallic within the tiust zone is alloweu.
The lollowing scieens aie enaLleu loi the untiust zone:
Inteinet Contiol Message Piotocol (ICMP) Ping ol Death
IP souice ioute options
IP Teaiuiop
TCP Lanu attack
TCP SYN lloou
The uelault policy loi the untiust zone is to ueny all tiallic.
The lollowing commanus loau the lactoiy uelault settings, which place the ioutei into
a secuie context. Theie is no ioot passwoiu in the uelault conliguiation, so you must
assign one using the set system root-authentication commanu Leloie you can
commit:
[edit]
peter@pbr# load factory-default
warning: activating factory configuration
[edit]
peter@pbr# show | no-more
## Last changed: 2010-11-28 15:44:55 PST
system {
autoinstallation {
delete-upon-commit; ## Deletes [system autoinstallation] upon change/commit
traceoptions {
level verbose;
flag {
all;
}
}
}
services {
ssh;
web-management {
http {
interface ge-0/0/0.0;
}
}
}
syslog {
Junos Software and Security | 603
user * {
any emergency;
}
file messages {
any any;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
## Warning: missing mandatory statement(s): 'root-authentication'
}
interfaces {
ge-0/0/0 {
unit 0;
}
}
security {
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
queue-size 2000;
timeout 20;
}
land;
}
}
}
zones {
security-zone trust {
tcp-rst;
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
http;
https;
ssh;
telnet;
dhcp;
}
}
604 | Chapter 12:Junos Security Services
}
}
}
security-zone untrust {
screen untrust-screen;
}
}
policies {
from-zone trust to-zone trust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone trust to-zone untrust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone untrust to-zone trust {
policy default-deny {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
}
}
}
}
}
The uelault conliguiation is the staiting point loi intiouucing all the othei leatuies that
aie useu to secuie oui ioutei. In the lollowing sections, ioutei PBR is set to act as the
Inteinet gateway loi Beei-Co. Although not shown heie, the initial conliguiation ol the
inteilaces anu iouting piotocols is peiloimeu as uesciiLeu in the pievious chapteis ol
this Look. Ve aie going to locus only on the secuiity leatuies.
Junos Software and Security | 605
Operational modes summary
The opeiating system in the ]-seiies iouteis anu SRX Seivices Gateways suppoits se-
cuiity leatuies that weie pieviously lounu only in puipose-Luilt liiewalls. These lea-
tuies allow the iouteis to opeiate as a piuuent liiewall in the enteipiise. The same
uevice can Le conveiteu to a stateless packet moue uevice with the intiouuction ol a
couple ol commanus. This allows these uevices to Le useu in many uilleient ioles in
the enteipiise.
Security Features
In the lollowing sections we exploie the common secuiity leatuies that aie associateu
with ]unos. These leatuies allow us to secuie a netwoik liom Inteinet thieats while
pioviuing connectivity loi useis ol the enteipiise. This Lalancing act is suppoiteu Ly
secuiity policies that peimit oi ueny tiallic thiough the gateway, netwoik auuiess
tianslations that hiue the inteinal stiuctuie ol oui netwoik liom piying eyes, viitual
piivate netwoik tunnels that enciypt tiallic loi tiansmission ovei the Inteinet, anu
thieat uetection schemes that Llock tiallic that makes it thiough the initial lines ol
uelense. Ve piesent only one possiLle scenaiio loi secuiing a netwoik; many othei
possiLilities aie Leing useu in enteipiises touay.
Branch Office and Data Center SRXs
The lull set ol secuiity leatuies suppoiteu in ]unos is lounu in the uevices ieleiieu to
as Bianch Ollice SRX seiies seivices gateways (SRX2+0, SRX650, etc.). A suLset ol these
leatuies can Le lounu in the ]-seiies iouteis anu a luithei suLset lounu in the laigei
Data Centei SRXs (e.g., SRX1+00, SRX3Ks, SRX5Ks). The lull uelinition ol what mou-
els suppoit which leatuies can Le lounu on the ]unipei weLsite.
The leatuies piesenteu in the lollowing sections aie lounu in the Bianch Ollice SRXs
anu the ]-seiies iouteis. Foi a tieatment ol the leatuies that aie lounu exclusively in the
high-enu SRXs, ielei to junos Sccurity (O`Reilly).
Common feature set
The leatuies that Beei-Co is using to piotect theii enteipiise liom the thieats lounu in
the Inteinet incluue a comLination ol statelul secuiity polices, NAT, VPNs, anu thieat
uetection. Ve auu these leatuies to the existing conliguiations that have Leen Luilt into
the enteipiise. Stateless liiewall lilteis anu inteilace policeis aie a pait ol the secuiity
plan loi Beei-Co, Lut these have Leen coveieu pieviously anu will not Le iepeateu heie.
Security policies
Statelul secuiity policies aie Beei-Co`s seconu line ol uelense (the liiewall lilteis that
tiap all oLvious malicious tiallic aie the liist line ol uelense). The statelul policies aie
606 | Chapter 12:Junos Security Services
constiucteu liom a numLei ol ieleienceu oLjects anu aie applieu to tiansient tiallic
thiough the liiewall. The policy components aie:
Zoncs
A secuiity constiuct that gioups inteilaces anu auuiesses that ieguiie the same
secuiity consiueiation. Releiiing to Figuie 12-1, the inteilaces that connect to
Bock anu Stout have the same secuiity consiueiations, wheieas the inteilace that
connects to the Inteinet has a uilleient set ol secuiity consiueiations. The secuiity
policies aie wiitten Letween zones. Given two secuiity zones (Beei-Co anu Intei-
net), loui possiLle sets ol policies can Le cieateu: liom-Beei-Co-to-Inteinet, liom-
Inteinet-to-Beei-Co, liom-Beei-Co-to-Beei-Co, anu liom-Inteinet-to-Inteinet.
Vithin each ol the policy sets a seiies ol policies aie wiitten to allow oi ueny specilic
tiallic.
|ntcrjaccs
To ueteimine what tiallic ieaches which policy, the incoming anu outgoing intei-
lace must Le ueteimineu loi the tiallic. Because all inteilaces aie associateu with
a zone, once the incoming anu outgoing inteilaces aie known, the incoming anu
outgoing zones can Le ueteimineu anu the appiopiiate policies can Le examineu.
Inteilaces that aie not associateu with a zone cannot pass tiansient tiallic.
Addrcsscs
Tiallic-to-policy matching is peiloimeu Ly ueteimining the zones (as uesciiLeu
pieviously) anu Ly matching IP auuiesses in the packets. Specilic auuiesses can Le
iuentilieu loi special tieatment (e.g., the weL seivei auuiess), auuiess pielixes can
Le iuentilieu (e.g., all Beei-Co auuiesses), oi a comLination ol the two can Le cie-
ateu. Any auuiess that is calleu out in a secuiity policy must liist Le uelineu in an
auuiess Look entiy. Auuiess Look entiies aie associateu with a specilic zone. One
pieuelineu auuiess Look entiy exists loi all zones: the any auuiess Look entiy.
Scrviccs
Policy matching uses zones, auuiesses, anu seivices (applications). ]unos has a
pieuelineu set ol seivices, anu custom seivices can Le uelineu as well. The ieuelineu
list can Le ievieweu with the conliguiation commanu show groups Junos-defaults
| find applications.
Actions
Each policy has an associateu action that peimits oi uenies the tiallic thiough the
liiewall. Auuitional actions incluue management lunctions such as logging the
tiallic anu oi counting the tiallic. Policies can Le scheuuleu to Le active at ceitain
times. Vhen tiallic matches a policy that is to Le sent ovei a VPN tunnel, a tunnel
action ieplaces the peimit action.
The cieation ol a policy Legins with the uelinition ol the ieleienceu oLjects. Theie is
no paiticulai oiuei loi the uelinition ol these oLjects, Lut theie is a logical linkage that
shoulu Le oLseiveu: inteilaces, zones, auuiesses, anu linally, seivices. In Beei-Co, the
oLjects aie:
Junos Software and Security | 607
Zonc: Bccr-Co
Inteilaces:
ge-0/0/0.1241 (inteilace to Bock)
ge-0/0/0.3114 (inteilace to Stout)
Auuiesses:
10.0.0.0/S (Beer-Co)
10.10.0.0/16 (Beer-Co_East)
10.20.0.0/17 (Beer-Co_West)
Zonc: |ntcrnct
Inteilace: ge-0/0/1.0 (Inteinet egiess)
Auuiesses: Any
Zonc: DMZ
Inteilace: ge-0/0/2.0
Auuiesses:
10.30.30.100 (weL seivei)
10.30.30.102 (email seivei)
10.30.30.101 (DNS seivei)
Scrviccs
]unos uelaults aie all that aie necessaiy loi this installation.
Fiist, we auu the inteilaces loi the new DMZ zone anu the new Inteinet zone to the
conliguiation. These inteilaces aie untaggeu. The conliguiation is:
[edit]
peter@PBR# show interfaces
ge-0/0/0 {
vlan-tagging;
unit 0;
unit 1241 {
vlan-id 1241;
family inet {
address 10.20.130.1/30;
}
}
unit 3141 {
vlan-id 3141;
family inet {
address 10.20.129.1/30;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 74.116.12.5/28;
}
608 | Chapter 12:Junos Security Services
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 10.30.30.1/24;
}
}
}
Once this conliguiation is piesent, the iemainuei ol the policy oLjects can Le auueu.
Initially the zones aie cieateu, anu then the inteilaces anu auuiesses aie auueu to the
zones. One piece neeueu to complete the zones is the concept ol host-inbound-
traffic. Tiallic geneiateu liom the liiewall is always alloweu out. The ietuin tiallic is
iestiicteu to those seivices anu piotocols that aie iuentilieu at the zone level oi the
inteilace level loi host-inbound-traffic. Foi the Beei-Co zone, all inLounu tiallic anu
seivices will Le accepteu; loi the Inteinet anu DMZ zones, only ping anu traceroute
will Le alloweu. Vith this last piece ol inloimation, the zone conliguiation is:
[edit]
peter@PBR# show security zones
security-zone Beer-Co {
address-book {
address Beer-Co 10.0.0.0/8;
address Beer-Co_East 10.10.0.0/16;
address Beer-Co_West 10.20.0.0/16;
}
interfaces {
ge-0/0/0.1241 {
host-inbound-traffic {
system-services {
any-service;
}
protocols {
all;
}
}
}
ge-0/0/0.3141 {
host-inbound-traffic {
system-services {
any-service;
}
protocols {
all;
}
}
}
}
}
security-zone Internet {
interfaces {
ge-0/0/1.0 {
host-inbound-traffic {
Junos Software and Security | 609
system-services {
traceroute;
ping;
}
}
}
}
}
security-zone DMZ {
address-book {
address Web_Server 10.30.30.100/32;
address E-Mail_Server 10.30.30.102/32;
address DNS_Server 10.30.30.101/32;
}
interfaces {
ge-0/0/2.0 {
host-inbound-traffic {
system-services {
ping;
traceroute;
}
}
}
}
}
Policy creation
Once this conliguiation is enteieu anu committeu, it is time to actually cieate the se-
cuiity policies. This is the easy pait once all the oLjects aie in place. The iules that we
cieate loi Beei-Co aie as lollows:
1. All employees aie alloweu to access the Inteinet loi all puiposes (Inteinet-Access).
2. All Inteinet useis aie alloweu to access the Beei-Co weL seivei (Inteinet-to-VeL).
3. All Inteinet DNS seiveis aie alloweu to access the Beei-Co DNS seivei (Inteinet-
to-DNS).
+. All Inteinet email seiveis aie alloweu to access the Beei-Co email seivei (Inteinet-
to-Email).
5. All employees aie alloweu to access the seiveis on the DMZ (DMZ-Access).
6. The DNS anu email seiveis aie alloweu to access the Inteinet loi theii iespective
seivices (DMZ-Upuates).
7. All employees aie alloweu to tiansit the liiewall to anothei employee (Peimit-All).
The geneial syntax loi a secuiity policy is:
Fiom-zone AAAA To-Zone BBBB Souice-auuiess CCCC Destination-auuiess
DDDD application EEEE peimit/ueny
Consiueiing that the uelault policy loi all tiallic is an implicit ueny, we aie going to
locus on the peimit policies. Il we allow wanteu tiallic, all othei tiallic that is not
610 | Chapter 12:Junos Security Services
specilieu is uenieu Ly uelault. Il we wanteu to get lancy, we coulu cieate ueny anu
peimit statements that tailoi tiallic to veiy specilic iules, Lut loi oui puiposes that
woulu Le oveikill, so we aie going to cieate a seiies ol peimit policies anu leave the
uenies to the uelault policy. Ve look at each iule in tuin anu cieate a policy that matches
that iule.
Associateu with the peimit action loi each policy, we aie going to auu the counting
opeiation. This will help when tiouLleshooting anu testing the policies. Consiueiing
that we aie allowing all tiallic that we want, we see no neeu to log the tiallic that
matches the policies. Il we stait having tiouLle with a seivei oi see aLuse on the system,
then logging can Le enaLleu on specilic policies, which will enaLle us to see who is
causing the pioLlems anu cieate policies to stop that tiallic.
Theie is a set ol uelault policies that allow anu ueny tiallic loi the uelault zones. These
anu the zones that they ieleience aie ueleteu liom the system piioi to auuing the new
conliguiation.
The zones associateu with
this iule aie the Beei-Co zone loi the from-zone anu the Inteinet zone loi the to-zone.
The souice auuiess can Le a couple ol options: it coulu Le the gloLal any, the Beei-Co
10/S auuiess, oi Loth the Beei-CoEast anu Beei-CoVest auuiesses. The most piu-
uent is the most specilic auuiess, so the east anu west auuiesses aie auueu to the policy.
The uestination auuiess anu the seivice in this iule have to Le the gloLal any. The policy
conliguiation is as lollows:
[edit]
peter@PBR# show security policies
from-zone Beer-Co to-zone Internet {
policy Internet-Access {
match {
source-address [ Beer-Co_East Beer-Co_West ];
destination-address any;
application any;
}
then {
permit;
count;
}
}
}
This policy is liom the Intei-
net Zone to the DMZ zone. The souice auuiess is the gloLal any, anu the uestination
auuiess is the auuiess Look entiy loi the weL seivei (Web_Server). The seivices aie the
pieuelineu ]unos seivices loi HTTP anu HTTPS tiallic (poits S0 anu ++3, iespectively).
The policy conliguiation is as lollows:
[edit]
peter@PBR# show security policies from-zone Internet to-zone DMZ
policy Internet-to-Web {
match {
Rule 1: All employees are allowed to access the Internet for all purposes.
Rule 2: All Internet users are allowed to access the Beer-Co web server.
Junos Software and Security | 611
source-address any;
destination-address Web_Server;
application [ Junos-http Junos-https ];
}
then {
permit;
count;
}
}
Vhen cieating policies, it is necessaiy to name auuiesses anu seivices
exactly, anu using ? is a Lig help loi this puipose. I wanteu to know the
exact name ol the weL seivei auuiess Look entiy, so I useu ?, which
shows a list ol availaLle auuiesses in the DMZ zone. I can now Le assuieu
that the spelling is coiiect loi the auuiess:
[edit]
peter@PBR# ...ernet-to-Web match source-address any destination-address ?
Possible completions:
<address> Address from address book or static_nat or
incoming_nat address
DNS_Server [security zones security-zone DMZ address-book address <*>]
E-Mail_Server[security zones security-zone DMZ address-book address <*>]
Web_Server [security zones security-zone DMZ address-book address <*>]
[ Open a set of values
any Any address
[edit]
peter@PBR# ...ource-address any destination-address Web_Server
Because ol the way the
DNS system woiks, we have to allow access to the DNS seivei liom the outsiue as well
as allow the DNS seivei to ieach the Inteinet (see iule 6). Foi this iule, the from-zone
is the Inteinet anu the to-zone is the DMZ. The souice auuiess is the gloLal any, the
uestination auuiess is the DNS seivei`s auuiess-Look entiy (DNS_Server), anu the seiv-
ices aie the pieuelineu DNS piotocols. The policy conliguiation is as lollows:
[edit]
peter@PBR# show security policies
...
policy Internet-to-DNS {
match {
source-address any;
destination-address DNS_Server;
application [ Junos-dns-udp Junos-dns-tcp ];
}
then {
permit;
count;
}
}
}
Rule 3: All Internet DNS servers are allowed to access the Beer-Co DNS server.
612 | Chapter 12:Junos Security Services
This iule is similai to
the iule loi the DNS seivei, Lut with the uestination auuiesses changeu anu the seivices
alteieu loi the email seivei. Il iemote employees wish to use a POP client to ieach the
email seivei, an auuitional seivice coulu Le auueu loi these useis. Ve aie keeping it
simple loi now with just SMTP access. The policy conliguiation is as lollows:
[edit security policies from-zone Internet to-zone DMZ policy Internet-to-Email]
peter@PBR# show
match {
source-address any;
destination-address E-Mail_Server;
application Junos-smtp;
}
then {
permit;
count;
}
Because this iule is loi em-
ployee access to Beei-Co assets, the iules can Le ielaxeu. The from-zone is Beei-Co, anu
the to-zone is the DMZ. The auuiesses coulu Le veiy iestiictive, Lut Lecause we aie
looking at inteinal tiallic, we will Le lax anu use the gloLal any loi all auuiesses anu
the seivices. Oui lack ol piuuence coulu come Lack anu Lite us one uay, Lut we at Beei-
Co aie a tiusting Lunch. The policy conliguiation is:
[edit security policies from-zone Beer-Co to-zone DMZ policy DMZ-Access]
peter@PBR# show
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
count;
}
This is the ieveise policy loi iule 2 anu can Le wiitten as a miiioi image. The from-
zone is the DMZ, the to-zone is the Inteinet, the souice auuiesses aie the seiveis, anu
the uestination auuiesses aie the gloLal any. The seivices aie all the seivices lounu in
the DMZ. Theie aie two ways ol cieating this policy. The liist is the use ol multiple
entities in the auuiesses anu seivices, anu the othei is cieating auuiess sets anu seivice
sets anu iuentilying these oLjects in the policies. Because we have taken the easy way
out loi all othei policies, we have pioviueu the conliguiation that cieates the seivice
anu auuiess sets. The policy conliguiation is as lollows:
[edit security policies from-zone DMZ to-zone Internet policy DMZ-Updates]
peter@PBR# show
match {
source-address DMZ-Servers;
destination-address any;
Rule 4: All Internet email servers are allowed to access the Beer-Co email server.
Rule 5: All employees are allowed to access the servers on the DMZ.
Rule 6: The DNS and email servers are allowed to access the Internet for their respective services.
Junos Software and Security | 613
##
## Warning: application or application-set must be defined
##
application DMZ-Services;
}
then {
permit;
count;
}
Vhen we cieate this anu take an initial look, a waining says that we have to cieate the
seivice set anu the auuiess set. Once these aie cieateu, the wainings aie gone. The
conliguiation loi the seivice set anu the auuiess set aie as lollows:
[edit]
peter@PBR# show applications
application-set DMZ-Services {
application Junos-dns-udp;
application Junos-dns-tcp;
application Junos-smtp;
application Junos-http;
application Junos-https;
}
[edit]
peter@PBR# show security zones security-zone DMZ address-book
address Web_Server 10.30.30.100/32;
address E-Mail_Server 10.30.30.102/32;
address DNS_Server 10.30.30.101/32;
address-set DMZ-Servers {
address E-Mail_Server;
address DNS_Server;
address Web_Server;
}
This linal iule is nec-
essaiy Lecause intia-zone tiallic is Llockeu in ]unos. Il you aie lamiliai with ScieenOS,
you will iememLei that intia-zone Llocking was set with a knoL that coulu Le tuineu
on oi oll as uesiieu. In ]unos, it is to peimanently set to oll, anu so all tiallic-to-tiansit
inteilaces must Le alloweu Ly a policy. This policy is the least piuuent, with the from-
zone anu to-zone set to Beei-Co, anu the auuiess anu seivice set to any. The policy
conliguiation is as lollows:
[edit security policies from-zone Beer-Co to-zone Beer-Co policy Permit-All]
peter@PBR# show
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
count;
}
Rule 7: All employees are allowed to transit the firewall to another employee.
614 | Chapter 12:Junos Security Services
Testing policies
Theie is no specilic commanu that allows you to see what tiallic woulu pass a policy
oi policy set. In lieu ol that, we have tools that can help tiouLleshoot policy pioLlems.
The liist uses the counteis associateu with a policy. The show security policy
detail commanu allows an auministiatoi to see what policies aie Leing hit Ly tiallic.
A sample test scenaiio woulu Le to check the policy counteis, iun a test ping session,
anu then check the counteis again. The counteis shoulu Le inciementeu Ly the ping
tiallic. In the lollowing sample, the Peimit-All policy is testeu to see whethei tiallic
liom Stout is ieaching Bock thiough the liiewall.
Fiist, we issue the show security policy detail commanu to check the state ol the
counteis:
peter@PBR> show security policy from-zone Beer-Co to-zone Beer-Co policy-name
Permit-All detail
Policy: Permit-All, action-type: permit, State: enabled, Index: 13
Sequence number: 1
From zone: Beer-Co, To zone: Beer-Co
Source addresses:
any: 0.0.0.0/0
Destination addresses:
any: 0.0.0.0/0
Application: any
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination port range: [0-0]
Policy statistics:
Input bytes : 0 0 bps
Output bytes : 0 0 bps
Input packets : 0 0 pps
Output packets : 0 0 pps
Session rate : 0 0 sps
Active sessions : 0
Session deletions: 0
Policy lookups : 0
Next, we iun a seiies ol 11 pings liom Stout to Bock. This shoulu geneiate 11 hits on
the policy. The ietuin tiallic is pait ol the existing session, so it is not counteu a seconu
time. Once the pings aie complete, the uetails ol the policy aie oLseiveu again:
peter@PBR> show policy from-zone Beer-Co to-zone Beer-Co policy-name Permit-All detail
Policy: Permit-All, action-type: permit, State: enabled, Index: 13
Sequence number: 1
From zone: Beer-Co, To zone: Beer-Co
Source addresses:
any: 0.0.0.0/0
Destination addresses:
any: 0.0.0.0/0
Application: any
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination port range: [0-0]
Policy statistics:
Junos Software and Security | 615
Input bytes : 1848 27 bps
Output bytes : 1848 27 bps
Input packets : 22 0 pps
Output packets : 22 0 pps
Session rate : 11 0 sps
Active sessions : 0
Session deletions: 11
Policy lookups : 11
Ve can see the counts have inciementeu Ly the numLei ol pings, veiilying that the
tiallic is passing thiough the piopei policy.
A seconu means to test a policy is to view the session taLle anu veiily what policy has
Leen useu to estaLlish a specilic session. Because ping tiallic initiates anu closes sessions
on a seconu-Ly-seconu Lasis, the use ol ping loi this testing is hit oi miss. Insteau, we
will use an FTP session to veiily the policy. On Bock, we enaLle the FTP seivice (set
system services ftp) anu commit the change. On Stout, we use the ltp client to access
Bock (ftp 10.20.130.2). Vhile the FTP session is open, we go Lack to PBR anu look at
the tiansit sessions Letween the two uevices with the commanu show security flow
session destination-prefix 10.20.130.2. The output shows all the sessions that aie
cuiiently going to the inteilace auuiess ol Bock anu shows that the policy useu is
Peimit-All:
peter@PBR> show security flow session destination-prefix 10.20.130.2
Session ID: 33, Policy name: Permit-All/13, Timeout: 1780
In: 10.20.129.2/56902 --> 10.20.130.2/21;tcp, If: ge-0/0/0.3141
Out: 10.20.130.2/21 --> 10.20.129.2/56902;tcp, If: ge-0/0/0.1241
1 sessions displayed
On an opeiational liiewall, the session taLle Lecomes guite laige (tens
ol thousanus ol sessions laige). Using the show security flow session
commanu with a | match can take minutes to linu what you aie looking
loi, wheieas using destination-prefix oi othei mouilieis will pioviue
iesults in a veiy shoit peiiou ol time.
As an asiue, the output ol the show secuiity llow session commanu can
Le saveu to a lile anu openeu in a woiu piocessing oi uataLase applica-
tions loi analysis. This piocess can allow an auministiatoi to get a
snapshot ol what tiallic is going wheie in the netwoik.
The linal tool that we have loi testing policies is a llow tiaceoptions. An inactive tiace-
options loi the secuiity llows is set up in auvance on oui liiewall anu useu whenevei a
tiouLleu policy is encounteieu. Ve can cieate lilteis loi the secuiity llow tiaceoptions
to ieuuce the output to only the tiallic that is unuei stuuy. Foi oui puiposes, the souice
ol the tiallic is Bock anu the uestination is Stout. Ve activate the tiaceoptions, set the
lilteis to the appiopiiate auuiesses, anu commit the changes. Once the commit is com-
plete, the logs aie cleaieu anu the test tiallic (pings in this case) is geneiateu. The
616 | Chapter 12:Junos Security Services
lollowing aie the conliguiations loi the tiaceoptions anu the output ol the tiaceoption
logliles once the test tiallic is complete:
[edit]
peter@PBR# show security flow
traceoptions {
file flow-trace;
flag basic-datapath;
packet-filter STOUT-BOCK {
source-prefix 10.20.129.2/32;
destination-prefix 10.20.130.2/32;
}
}
peter@pbr> clear log flow-trace
The test pings aie geneiateu liom Bock to Stout:
peter@PBR>show log flow-trace
Mar 2 00:29:54 00:29:54.371918:CID-0:RT:<10.20.129.2/0->10.20.130.2/45320;1>
matched filter STOUT-BOCK:
Mar 2 00:29:54 00:29:54.371934:CID-0:RT:packet [84] ipid = 21046, @4b175872
Mar 2 00:29:54 00:29:54.371942:CID-0:RT:---- flow_process_pkt: (thd 0): flow_ctxt
type 0, common flag 0x0, mbuf 0x4b175660, rtbl_idx = 9584
Mar 2 00:29:54 00:29:54.371951:CID-0:RT: flow process pak fast ifl 69 in_ifp
ge-0/0/0.3141
Mar 2 00:29:54 00:29:54.371960:CID-0:RT: ge-0/0/0.3141:10.20.129.2->10.20.130.2,
icmp, (8/0)
Mar 2 00:29:54 00:29:54.371971:CID-0:RT: find flow: table 0x57e72840, hash 76(0xffff),
sa 10.20.129.2, da 10.20.130.2, sp 0, dp 45320, proto 1, tok 576
Mar 2 00:29:54 00:29:54.371984:CID-0:RT: no session found, start first path.
in_tunnel - 0, from_cp_flag - 0
Mar 2 00:29:54 00:29:54.371998:CID-0:RT: flow_first_create_session
Mar 2 00:29:54 00:29:54.372013:CID-0:RT: flow_first_in_dst_nat: in <ge-0/0/0.3141>,
out <N/A> dst_adr 10.20.130.2, sp 0, dp 45320
Mar 2 00:29:54 00:29:54.372023:CID-0:RT: chose interface ge-0/0/0.3141 as incoming
nat if.
Mar 2 00:29:54 00:29:54.372035:CID-0:RT:flow_first_rule_dst_xlate: DST no-xlate:
0.0.0.0(0) to 10.20.130.2(45320)
Mar 2 00:29:54 00:29:54.372045:CID-0:RT:flow_first_routing: call flow_route_lookup():
src_ip 10.20.129.2, x_dst_ip 10.20.130.2, in ifp ge-0/0/0.3141, out ifp N/A sp 0,
dp 45320, ip_proto 1, tos 0
Mar 2 00:29:54 00:29:54.372057:CID-0:RT:Doing DESTINATION addr route-lookup
Mar 2 00:29:54 00:29:54.372084:CID-0:RT: routed (x_dst_ip 10.20.130.2) from Beer-Co
Junos Software and Security | 617
(ge-0/0/0.3141 in 0) to ge-0/0/0.1241, Next-hop: 10.20.130.2
Mar 2 00:29:54 00:29:54.372098:CID-0:RT: policy search from zone Beer-Co-> zone
Beer-Co (0x0,0xb108,0xb108)
...
Mar 2 00:29:54 00:29:54.372271:CID-0:RT: Session (id:42) created for first pak 200
Mar 2 00:29:54 00:29:54.372278:CID-0:RT: flow_first_install_session======> 0x4f875860
...
The output ol the llow tiaceoptions logs shows that the tiallic is alloweu implicitly anu
a session is cieateu. Il the tiallic weie uenieu, that woulu show in the initial policy
check. The lull uecoue ol the tiace is Leyonu the scope ol this Look, anu this tiace is
shoiteneu to show the ielevant lines. Once the analysis ol the logs is peiloimeu, the
secuiity llow tiaceoptions shoulu Le ueactivateu to lessen the chance that the iouting
engine will Le allecteu Ly the auueu piocessing (deactivate security flow
traceoptions).
Security traffic logs
The log opeiation ol the secuiity policies is not hanuleu in the same way as othei syslog
liles. Because ol the size ol the liles, the secuiity tiallic logs aie not stoieu on the liiewall
Lut aie hanueu to a seivei ol some llavoi. The conliguiation loi tiallic logging has two
paits. The liist is auuing the log action on the actual policy. Logs aie cieateu at session
initiation, at session close, oi Loth. Foi policies that have a ueny, the session-close
option shoulu Le useu. Foi peimitteu policies, eithei oi Loth can Le useu.
The seconu pait ol the eguation is iuentilying the secuiity tiallic log seivei (in oui
example, the weL seivei uoes uouLle uuty as oui tiallic log seivei, which is not ieally
a Liight iuea, Lut it will woik in oui laL). The conliguiation loi that is as lollows:
peter@PBR# show security log
mode stream;
format syslog;
source-address 10.20.128.3;
stream PBR {
format sd-syslog;
category all;
host {
10.30.30.100;
}
}
Multiple secuiity stieams can Le uelineu, Lut caution shoulu Le useu heie Lecause each
stieam uses CPU cycles that can cause an oveiloau ol the iouting engine. The output
ol the secuiity tiallic log shows the heaueis ol the packets that tiippeu the policy as
well as the policy anu the othei iesouices useu. The lollowing is an example ol the
output ol a secuiity tiallic log:
618 | Chapter 12:Junos Security Services
Mar 01 12:07:07 10.20.128.3 Mar 2 01:10:09 RT_FLOW: RT_FLOW_SESSION_CREATE:
session created 10.20.129.2/0->10.20.130.2/2244 icmp 10.20.129.2/0->
10.20.130.2/2244
None None 1 Permit-All Beer-Co Beer-Co 1102
Mar 01 12:07:08 10.20.128.3 Mar 2 01:10:10 RT_FLOW: RT_FLOW_SESSION_CREATE:
session created 10.20.129.2/256->10.20.130.2/2244 icmp 10.20.129.2/256->
10.20.130.2/2244
None None 1 Permit-All Beer-Co Beer-Co 1103
Mar 01 12:07:09 10.20.128.3 Mar 2 01:10:11 RT_FLOW: RT_FLOW_SESSION_CREATE:
session created 10.20.129.2/512->10.20.130.2/2244 icmp 10.20.129.2/512->
10.20.130.2/2244
None None 1 Permit-All Beer-Co Beer-Co 1104
Mar 01 12:07:10 10.20.128.3 Mar 2 01:10:11 RT_FLOW: RT_FLOW_SESSION_CREATE:
session created 10.20.129.2/768->10.20.130.2/2244 icmp 10.20.129.2/768->
10.20.130.2/2244
None None 1 Permit-All Beer-Co Beer-Co 1105
Mar 01 12:07:11 10.20.128.3 Mar 2 01:10:13 RT_FLOW: RT_FLOW_SESSION_CREATE:
session created 10.20.129.2/1024->10.20.130.2/2244 icmp 10.20.129.2/1024->
10.20.130.2/2244
None None 1 Permit-All Beer-Co Beer-Co 1106
Security policy summary
Secuiity policies loim the seconu line ol uelense loi an enteipiise netwoik liom the
unknown woilu ol the Inteinet. The ]unos liiewalls use a piuuent policy philosophy
that uenies all tiansit tiallic that is not specilically alloweu. The policies aie Letween
liiewall zones anu can Le maue moie oi less gianulai Ly the use ol auuiesses anu seiv-
ices. Foi a lully open liiewall, a single zone can Le cieateu that houses all inteilaces anu
a single policy can Le cieateu to allow all tiallic liom that zone to that zone. In this
case, the liiewall is ieally a llow-Laseu ioutei. The moie uselul a liiewall Lecomes, the
moie specilic the policies Lecome anu the moie conliguiation woik you must peiloim.
The ]unos liiewalls, like eveiything else, aie only as goou as the woik that is enteieu
into them.
Network Address Translation
Now that we have policies in place anu we have veiilieu that connectivity Letween all
the elements is possiLle, it is time to hiue the Beei-Co netwoik liom piying eyes. Ve
uo this Ly tianslating the inteinal 10.0.0.0 auuiesses to a puLlic 7+.116.12.0 auuiess.
Il a scan ol the Beei-Co netwoik weie peiloimeu, all that woulu Le seen is a single
suLnet with eight hosts associateu with it. The inteinal stiuctuie ol the enteipiise will
Le hiuuen.
An auuitional aspect ol using NAT is the exhaustion ol the IPv+ auuiess pool. As ol
this wiiting, the last Llocks ol unassigneu auuiesses have Leen uistiiLuteu, anu theie
aie no moie IPv+ auuiesses to Le lounu. Unueistanuing this uilemma, Beei-Co is using
an auuiess Llock associateu with theii ISP. The ISP has contiacteu with Beei-Co to use
this auuiess Llock. This aiiangement saves auuiesses anu pioviues secuiity at the same
time.
Junos Software and Security | 619
The ]unos liiewalls suppoit thiee uistinct types ol auuiess tianslation: static NAT,
souice NAT, anu uestination NAT. Each ol these types has many vaiiants anu options,
Lut loi oui puiposes, we look at only the noimal use ol each type.
NAT conliguiation is peiloimeu with iules anu iulesets that aie assigneu to a viitual
ioutei, zone, oi inteilace. In eailiei veisions ol ]unos, theie weie stiict limits on the
numLei ol iules pei set anu the numLei ol iulesets. This seveiely limiteu the possiLle
numLei ol tianslations, anu conliguiation games hau to Le playeu to exceeu these
limits. The cuiient veision ol ]unos has an aLsolute limit to the numLei ol tianslations
that is mouel-uepenuent anu counteu in the thousanus.
Static NAT
Static NAT olleis a one-to-one mapping ol piivate auuiess to puLlic auuiess. Outsiue
tiallic aiiives with a uestination auuiess ol the puLlic siue ol the paii, which is tianslateu
to a piivate auuiess loi inteinal iouting. Vhen the piivately auuiesseu uevice initiates
a session, the piivate souice auuiess is tianslateu to a puLlic auuiess that is useu on the
Inteinet. Static NAT is Liuiiectional in natuie anu is commonly useu loi puLlic-lacing
seiveis. In oui laL setup, the DMZ seiveis all have static NATeu auuiesses ol this loim:
Server Public address Private address
DNS server 74.116.12.2 10.30.30.101
Email server 74.116.12.3 10.30.30.102
Web server 74.116.12.1 10.30.30.100
The conliguiation loi static NAT is peiloimeu in the secuiity stanza anu is composeu
ol a iuleset anu iules. The iuleset ieleiences the inteilace oi zone that ieguiies the
tianslation. In Beei-Co, the tianslation can Le mappeu to eithei the Inteinet zone oi
inteilace ge-0/0/1.0 Lecause they Loth ielei to the exact same entity. Thiee iules aie
cieateu in the iuleset, one loi each ol the static NATs ieguiieu. The conliguiation loi
the static NAT is as lollows:
[edit]
peter@PBR# show security nat
static {
rule-set DMZ {
from zone Internet;
rule DNS {
match {
destination-address 74.116.12.2/32;
}
then {
static-nat prefix 10.30.30.101/32;
}
}
rule Email {
match {
destination-address 74.116.12.3/32;
620 | Chapter 12:Junos Security Services
}
then {
static-nat prefix 10.30.30.102/32;
}
}
rule web {
match {
destination-address 74.116.12.1/32;
}
then {
static-nat prefix 10.30.30.100/32;
}
}
}
}
Each seivei is veiilieu loi incoming anu outgoing tiallic. The session taLle shows that
the NAT is woiking. In the laL, we have a PC connecteu as the Inteinet. This setup
ieguiieu an auuitional step: the entiy ol a proxy-arp setting loi the inteilace. This allows
the Inteinet inteilace (ge-0/0/1.0) to iesponu to aip ieguests loi its auuiess anu the
static NAT auuiesses that aie Lehinu it. The pioxy aip conliguiation is:
[edit security nat proxy-arp]
peter@PBR# show
interface ge-0/0/1.0 {
address {
74.116.12.1/32;
74.116.12.2/32;
74.116.12.3/32;
74.116.12.4/32;
}
}
Once the pioxy-aip is enteieu, the test tiallic is goou in Loth uiiections (loi the puiposes
ol testing, the application set was upuateu to incluue ICMP tiallic). The sessions show
that the incoming tiallic is initially sent to 7+.116.12.1 (puLlic) Lut that the ietuin
tiallic is coming liom 10.30.30.100 (piivate). In the outgoing uiiection, the ieveise is
tiue: the initial tiallic is coming liom the piivate auuiess, Lut the ietuin tiallic is ues-
tineu loi the puLlic auuiess:
peter@PBR> show security flow session source-prefix 74.116.12.10
Session ID: 4206, Policy name: test/5, Timeout: 2
In: 74.116.12.10/25600 --> 74.116.12.1/512;icmp, If: ge-0/0/1.0
Out: 10.30.30.100/512 --> 74.116.12.10/25600;icmp, If: ge-0/0/2.0
Session ID: 4208, Policy name: test/5, Timeout: 2
In: 74.116.12.10/25856 --> 74.116.12.1/512;icmp, If: ge-0/0/1.0
Out: 10.30.30.100/512 --> 74.116.12.10/25856;icmp, If: ge-0/0/2.0
Session ID: 4213, Policy name: test/5, Timeout: 4
In: 74.116.12.10/26112 --> 74.116.12.1/512;icmp, If: ge-0/0/1.0
Out: 10.30.30.100/512 --> 74.116.12.10/26112;icmp, If: ge-0/0/2.0
3 sessions displayed
Junos Software and Security | 621
peter@PBR> show security flow session source-prefix 10.30.30.100
Session ID: 4241, Policy name: DMZ-Updates/12, Timeout: 2
In: 10.30.30.100/189 --> 74.116.12.10/1;icmp, If: ge-0/0/2.0
Out: 74.116.12.10/1 --> 74.116.12.1/189;icmp, If: ge-0/0/1.0
Session ID: 4243, Policy name: DMZ-Updates/12, Timeout: 2
In: 10.30.30.100/190 --> 74.116.12.10/1;icmp, If: ge-0/0/2.0
Out: 74.116.12.10/1 --> 74.116.12.1/190;icmp, If: ge-0/0/1.0
Session ID: 4245, Policy name: DMZ-Updates/12, Timeout: 4
In: 10.30.30.100/191 --> 74.116.12.10/1;icmp, If: ge-0/0/2.0
Out: 74.116.12.10/1 --> 74.116.12.1/191;icmp, If: ge-0/0/1.0
3 sessions displayed
In a pievious section, we uiscusseu the oiuei ol opeiations loi the vai-
ious leatuies. A ieview ol Figuie 12-2 shows that uestination NAT is
peiloimeu Leloie the policy lookup, wheieas souice NAT is peiloimeu
altei the policy lookup. This seguencing coulu allect what auuiess is
put into the policy (piivate oi puLlic).
Source NAT
The souice netwoik auuiess tianslation ieguiiements loi Beei-Co aie guite simple. All
tiallic that oiiginates in the Beei-Co secuiity zone uses a single puLlic auuiess loi all
outgoing sessions. That auuiess (7+.116.12.+) is useu Ly all outgoing tiallic; this Le-
comes moie ol a poit anu auuiess tianslation mechanism iathei than a simple NAT
mechanism. An auuiess pool is cieateu that iuentilies the puLlic auuiess to Le useu loi
outgoing tiallic, anu a iuleset is cieateu with a single iule matching all tiallic. The
conliguiation is as lollows:
[edit]
peter@PBR# show security nat source
pool Beer-Co {
address {
74.116.12.4/32;
}
}
rule-set ALL-Outbound {
from zone Beer-Co;
to zone Internet;
rule All-Out {
match {
source-address 10.0.0.0/8;
}
then {
source-nat {
pool {
Beer-Co;
}
}
622 | Chapter 12:Junos Security Services
}
}
}
The testing ol the souice NAT is veiilieu in the same mannei as the static NATs. Test
tiallic is cieateu, anu the session taLle is vieweu to show that the tianslation is taking
place. In oui laL, we geneiate ping tiallic liom Bock to the Inteinet PC (7+.116.12.10).
The session taLle shows that not only was the souice auuiess tianslateu Lut the souice
poit was changeu as well:
peter@PBR> show security flow session source-prefix 10.20.130.2/32
Session ID: 20, Policy name: self-traffic-policy/1, Timeout: 56
In: 10.20.130.2/1 --> 224.0.0.5/1;ospf, If: ge-0/0/0.1241
Out: 224.0.0.5/1 --> 10.20.130.2/1;ospf, If: .local..0
Session ID: 7377, Policy name: Internet-Access/4, Timeout: 2
In: 10.20.130.2/789 --> 74.116.12.10/54025;icmp, If: ge-0/0/0.1241
Out: 74.116.12.10/54025 --> 74.116.12.4/8420;icmp, If: ge-0/0/1.0
Session ID: 7378, Policy name: Internet-Access/4, Timeout: 2
In: 10.20.130.2/790 --> 74.116.12.10/54025;icmp, If: ge-0/0/0.1241
Out: 74.116.12.10/54025 --> 74.116.12.4/12842;icmp, If: ge-0/0/1.0
Session ID: 7382, Policy name: Internet-Access/4, Timeout: 4
In: 10.20.130.2/791 --> 74.116.12.10/54025;icmp, If: ge-0/0/0.1241
Out: 74.116.12.10/54025 --> 74.116.12.4/27476;icmp, If: ge-0/0/1.0
Session ID: 7383, Policy name: Internet-Access/4, Timeout: 4
In: 10.20.130.2/792 --> 74.116.12.10/54025;icmp, If: ge-0/0/0.1241
Out: 74.116.12.10/54025 --> 74.116.12.4/26135;icmp, If: ge-0/0/1.0
5 sessions displayed
Destination NAT
In the Beei-Co enviionment, no uestination NAT is ieguiieu. Il it weie, the conligu-
iation woulu Le the same as the souice NAT oi static NAT. The tiallic to Le tianslateu
is iuentilieu in a iule that is assigneu to a iuleset. The oiientations ol the auuiesses in
the iule aie the same as loi static NAT: the puLlic auuiesses aie the liom oLjects anu
the piivate auuiesses aie the to oLjects. An example ol a uestination NAT is as lollows:
[edit]
peter@PBR# show security nat destination
pool WEB {
address 10.30.30.100/32;
}
rule-set INBound {
from zone Internet;
rule WEB {
match {
destination-address 74.116.12.1/32;
}
then {
destination-nat pool WEB;
Junos Software and Security | 623
}
}
}
NAT summary
All NAT is conliguieu thiough the use ol NAT iulesets anu iules. The iulesets ueline
wheie the inteiesting tiallic shoulu oiiginate anu teiminate, anu the iules ueline the
inuiviuual tianslations. The opeiation ol NAT can Le veiilieu Ly any ol the tiouLle-
shooting tools uelineu loi the policies uiscusseu eailiei, Lut the session taLle is the
easiest to use.
Virtual Private Networks
The ]unos-Laseu iouteis suppoit numeious viitual piivate netwoik (VPN) piotocols.
The most common piotocol useu loi secuiing tiansmissions is Laseu on the Secuie IP
piotocol, oi IPSec. This piotocol has many options, anu entiie Looks have Leen wiitten
on the conliguiation anu uesciiption ol IPSec. Foi most puiposes the piotocol`s uelaults
aie useu:
Encapsulation ol tiallic in the Secuiity Encapsulation Payloau (ESP) piotocol
Session key exchange using the main moue ol Inteinet Key Exchange (IKE)
Session enciyption using the latest enciyption scheme, AES-256
Session authentication using the latest authentication scheme, SHA-1
The explanation ol these options anu all the uetails ol the IPSec piotocol aie Leyonu
the scope ol this Look.
]unos suppoits two uilleient appioaches loi placing tiallic into an IPSec tunnel: policy-
Laseu tunnels anu ioute-Laseu tunnels. In the policy-Laseu appioach, as the name im-
plies, the inteiesting tiallic is iuentilieu in a secuiity policy that uses a tunnel action in
lieu ol peimit. In a ioute-Laseu tunnel, a tunnel inteilace is cieateu, anu the inteiesting
tiallic is sent to the inteilace Ly means ol ioutes anu is peimitteu Ly policies. The
conliguiation ol the two is veiy similai in all aspects, except that in a ioute-Laseu tunnel,
the VPN is Lounu to a tunnel inteilace.
Theie aie many ieasons loi using one loim oi the othei, Lut loi Beei-Co, the ieason is
inteiopeiaLility. The venuoi that will Le using the tunnel loi tiansactions has a Cisco
ASA to teiminate the secuie tunnel. Vhen a ]unipei liiewall is communicating to a
Cisco liiewall with IPSec, a ioute-Laseu tunnel is useu. The ioute-Laseu liiewall allows
a paiametei calleu the pioxy ID to Le manipulateu easily. The Cisco ASA conliguiation
loi Beei-Co is as lollows:
crypto isakmp policy 1
encr aes 256
hash sha1
authentication pre-share
group 2
624 | Chapter 12:Junos Security Services
lifetime 28800
!
crypto isakmp key abc#123456 address 74.116.12.5
crypto ipsec transform-set AES_256 esp-aes 256 esp-sha-hmac
crypto map VPN 1 ipsec-isakmp
description Beer-Co
set peer 74.116.12.5
set transform-set AES_256
match address OATs_to_Beer-Co
ip access-list extended OATs_to_Beer-Co
permit ip host 192.168.12.1 host 10.10.1.1
permit ip host 192.168.12.2 host 10.10.1.1
This uelines the IPSec context, the tiansloim set, the VPN conliguiation, anu the access
lists. Not shown aie the ioutes that map tiallic to the piopei gateway. The puLlic
inteilace loi the Oats.com ASA is 65.9.13+.12. Ve at Beei-Co, soLei oi not, aie con-
ceineu with the secuiity ol oui netwoik, so all tiallic liom Oats.com is tieateu as un-
tiusteu anu is alloweu only to the seiveis that hanule the tiansactions. This seivei
(10.10.1.1) is locateu in the Beei-Co secuiity zone. Theie aie many ways to piotect this
tiallic, Lut one way is to cieate a zone specilically loi the Oats.com VPN, install the
inteilace into that zone, anu cieate a set ol policies that contiol the tiallic to anu liom
that zone. This is oui appioach Lecause it olleis the most secuiity anu llexiLility loi
the incoming tiallic. The conliguiation loi the inteilace, zone, anu policies is as lollows:
[edit]
peter@PBR# show interfaces st0.0
family inet {
address 10.10.1.100/24;
}
peter@PBR# show security zone security-zone Internet
interfaces {
ge-0/0/1.0 {
host-inbound-traffic {
system-services {
traceroute;
ping;
ike;
}
}
}
}
peter@PBR# show security zones security-zone Oats.com
address-book {
address Oat.com 192.168.12.0/24;
interfaces {
st0.0 {
host-inbound-traffic {
system-services {
ping;
Junos Software and Security | 625
ike;
}
}
}
}
[edit]
peter@PBR# show security policies from-zone Beer-Co to-zone Oats.com
policy Server_Permit {
match {
source-address Intranet_server;
destination-address Oat.com;
application any;
}
then {
permit;
count;
}
}
[edit]
peter@PBR# show security policies from-zone Oats.com to-zone Beer-Co
policy Oat-in {
match {
source-address Oat.com;
destination-address Intranet_server;
application any;
}
then {
permit;
count;
}
}
peter@PBR# show routing-options
static {
route 0.0.0.0/0 next-hop 74.116.12.10;
route 192.168.12.0/24 next-hop st0.0;
}
Theie is no specilic oiuei to the cieation ol the tunnel. The inteilace has to exist piioi
to the IPSec conliguiation pointing to it, Lut othei than that, all the othei conliguiation
can Le uone whenevei. Foi oui puiposes, we like to cieate the inliastiuctuie liist anu
then set up the IPSec anu IKE piotocols. That way, once the tunnel Lecomes active, we
can test it with actual tiallic Letween the souice anu uestination uevices. You might
notice that we have alloweu ping host-inLounu-tiallic (in auuition to IKE) loi the
Oats.com zone; this is loi testing puiposes only, anu it can Le ueleteu once the tunnel
is up anu opeiational.
The liist step in cieating the secuieu VPN tunnel is cieating a phase 1 pioposal that
matches the Cisco ASA isakmp policy:
[edit]
peter@PBR# show security ike proposal oat-ike-proposal
authentication-method pre-shared-keys;
dh-group group2;
626 | Chapter 12:Junos Security Services
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
lifetime-seconds 28800;
Next, we cieate the IKE policy anu ieleience the pioposal that uelines the use ol the
main moue loi key exchange:
[edit]
peter@PBR# show security ike policy oat_ike_policy
mode main;
proposals oat-ike-proposal;
pre-shared-key ascii-text "$9$d/bwgaJDkqfXxUjkqf5RhcSvWNdboZU"; ## SECRET-DATA
The policy is ieleienceu in a IKE gateway stanza that incluues the outgoing inteilace
anu the iemote VPN auuiess:
[edit]
peter@PBR# show security ike gateway oat_ike_gateway
ike-policy oat_ike_policy;
address 65.9.134.12;
external-interface ge-0/0/1.0;
This conliguiation uelines the phase 1 poition ol the secuie tunnel. The phase 2 poition
ol the conliguiation involves a similai set ol steps. Fiist, cieate the IPSec pioposal that
uelines the enciyption algoiithms, the authentication algoiithms, anu the tunneling
piotocols useu loi this tunnel:
[edit]
peter@PBR# show security ipsec proposal oat_ipsec_proposal
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-256-cbc;
As in the IKE conliguiation, the pioposal is ieleienceu in a IPSec policy that incluues
the uelinition ol peilect loiwaiuing secuiity (PFS) loi session key cieation (oui tunnel
is not using PFS, Lut this is wheie it woulu Le piogiammeu):
[edit]
peter@PBR# show security ipsec policy oat_ipsec_policy
proposals oat_ipsec_proposal;
Now the VPN can Le conliguieu to associate these pieces with the proxy-identity anu
the inteilace. Also incluueu in the VPN is a uelinition that specilies when to set up the
tunnel. Shoulu it Le set up immeuiately without waiting loi tiallic, oi shoulu inteiesting
tiallic Le seen piioi to the tunnel Leing estaLlisheu? The lattei is moie secuie, wheieas
the loimei is easiei to tiouLleshoot. Foi now we use the immeuiate setting, Lut latei
we can use the moie secuie on-uemanu setting. The VPN conliguiation is as lollows:
[edit]
peter@PBR# show security ipsec vpn oat_ipsec_vpn
bind-interface st0.0;
ike {
gateway oat_ike_gateway;
proxy-identity {
local 10.10.1.1/32;
Junos Software and Security | 627
remote 192.168.12.0/24;
service any;
}
ipsec-policy oat_ipsec_policy;
}
establish-tunnels immediately;
Once this conliguiation is committeu on the liiewall, we have to veiily that the tunnel
is opeiational. The easiest way to veiily the up/uown status ol the tunnel is to look at
the secuiity association loi the tunnel. Two uilleient secuiity associations (SAs) aie
cieateu when estaLlishing the tunnel: the liist is loi the key exchange, which is a tem-
poiaiy SA, anu the seconu is loi the tiallic session, which is active loi as long as the
tunnel is in place. The commanus to view the secuiity associations aie as lollows:
peter@PBR> show security ike security-associations detail
IKE peer 65.9.134.12, Index 4,
Role: Responder, State: UP
Initiator cookie: 549e06e7b48aa86e, Responder cookie: d076500299672f0f
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 74.116.12.5:500, Remote: 65.9.134.12:500
Lifetime: Expires in 27691 seconds
Algorithms:
Authentication : sha1
Encryption : aes-cbc (256 bits)
Pseudo random function: hmac-sha1
Traffic statistics:
Input bytes : 912
Output bytes : 844
Input packets: 5
Output packets: 4
Flags: Caller notification sent
IPSec security associations: 1 created, 0 deleted
Phase 2 negotiations in progress: 0
peter@PBR> show security ipsec security-associations detail
Virtual-system: Root
Local Gateway: 74.116.12.5, Remote Gateway: 65.9.134.12
Local Identity: ipv4(any:0,[0..3]=10.10.1.1)
Remote Identity: ipv4_subnet(any:0,[0..7]=192.168.12.0/24)
DF-bit: clear
Direction: inbound, SPI: c831a1bb, AUX-SPI: 0
Hard lifetime: Expires in 2438 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 1861 seconds
Mode: tunnel, Type: dynamic, State: installed, VPN Monitoring: -
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
Anti-replay service: enabled, Replay window size: 64
Direction: outbound, SPI: 85304c96, AUX-SPI: 0
Hard lifetime: Expires in 2438 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 1861 seconds
Mode: tunnel, Type: dynamic, State: installed, VPN Monitoring: -
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
Anti-replay service: enabled, Replay window size: 64
628 | Chapter 12:Junos Security Services
Il the SAs aie up anu opeiational, then it is time to senu tiallic ovei the tunnel. You
know they aie up when you see eithei an UP status oi an SPI that is complete. Il the
SAs aie not up, it is time loi some ueepei tiouLleshooting. Ve ping liom oui seivei to
the Oats client anu ieceive a positive iesponse (phew!). To veiily that the tiallic is
actually lollowing the tunnel, we view the tiallic statistics associateu with the tunnel:
peter@PBR> show security ipsec statistics
ESP Statistics:
Encrypted bytes: 5624
Decrypted bytes: 1008
Encrypted packets: 37
Decrypted packets: 12
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
On a ioute-Laseu VPN, you can also view the status ol the inteilace anu monitoi the
tiallic statistics ol the inteilace as you woulu any othei inteilace. In this case, the in-
teilace is st0.0 iathei than an Etheinet oi seiial inteilace. The commanus anu associateu
output aie as lollows:
peter@PBR> show interfaces st0.0 detail
Logical interface st0.0 (Index 70) (SNMP ifIndex 149) (Generation 152)
Flags: Point-To-Point SNMP-Traps Encapsulation: Secure-Tunnel
Traffic statistics:
Input bytes : 8316
Output bytes : 8473
Input packets: 99
Output packets: 74
Local statistics:
Input bytes : 504
Output bytes : 5365
Input packets: 6
Output packets: 37
Transit statistics:
Input bytes : 7812 1000 bps
Output bytes : 3108 900 bps
Input packets: 93 1 pps
Output packets: 37 1 pps
Security: Zone: Oats.com
Allowed host-inbound traffic : ping
Flow Statistics :
Flow Input statistics :
Self packets : 6
ICMP packets : 99
VPN packets : 0
Multicast packets : 0
Bytes permitted by policy : 504
Junos Software and Security | 629
Connections established : 87
Flow Output statistics:
Multicast packets : 0
Bytes permitted by policy : 3108
Flow error statistics (Packets dropped due to):
Address spoofing: 0
Authentication failed: 0
Incoming NAT errors: 0
Invalid zone received packet: 0
Multiple user authentications: 0
Multiple incoming NAT: 0
No parent for a gate: 0
No one interested in self packets: 0
No minor session: 0
No more sessions: 0
No NAT gate: 0
No route present: 0
No SA for incoming SPI: 0
No tunnel found: 0
No session for a gate: 0
No zone or NULL zone binding 0
Policy denied: 6
Security association not active: 0
TCP sequence number out of window: 0
Syn-attack protection: 0
User authentication errors: 0
Protocol inet, MTU: 9192, Generation: 165, Route table: 0
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.40.1/24, Local: 10.40.1.100, Broadcast: Unspecified,
Generation: 174
peter@pbr> monitor interface st0.0
PBR Seconds: 32 Time: 05:44:10
Delay: 0/0/0
Interface: st0.0, Enabled, Link is Up
Flags: Point-To-Point SNMP-Traps
Encapsulation: Secure-Tunnel
Local statistics: Current delta
Input bytes: 504 [0]
Output bytes: 5365 [0]
Input packets: 36 [0]
Output packets: 37 [0]
Remote statistics:
Input bytes: 4620 (664 bps) [2604]
Output bytes: 3108 (0 bps) [2400]
Input packets: 55 (0 pps) [31]
Output packets: 37 (0 pps) [30]
Traffic statistics:
Input bytes: 5124 Output bytes: , [2604]
In oui laL we have the luxuiy ol a contiolleu enviionment anu uiiect access to all the
uevices. Il you aie not so lucky, you will enu up spenuing time tiouLleshooting the
tunnels. The Lasic tool loi tiouLleshooting IPSec tunnels is IKE tiaceoptions. Piioi to
630 | Chapter 12:Junos Security Services
setting up the tiaceoptions, look in the |nd loglile loi status messages. This is the
uelault loglile loi IPSec lunctions, anu the answei to the pioLlem might Le lounu theie.
Il not, set up the IKE tiaceoptions; the most uselul llag is ike. Il no lile is uelineu, the
messages aie lounu in the kmu loglile. The lollowing shows the tiaceoptions conligu-
iation anu the tiace lile output:
[edit]
peter@PBR# show security ike traceoptions
flag ike;
[edit]
peter@PBR# run show log kmd | last 50
Mar 2 06:06:23 ike_encode_packet: Start, SA = { 0x560cde57 d4512fc3 - 44aac029
6ddd365b } / 4255b965, nego = 0
Mar 2 06:06:23 ike_finalize_qm_hash_1: Hash[0..20] = bafd3635 26c44f63 ...
Mar 2 06:06:23 ike_send_packet: Start, send SA = { 560cde57 d4512fc3 - 44aac029
6ddd365b}, nego = 0, src = 74.116.12.5:500, dst = 65.9.134.12:500, routing table
id = 0
Mar 2 06:06:23 ike_send_notify: Connected, SA = { 560cde57 d4512fc3 - 44aac029
6ddd365b}, nego = 1
Mar 2 06:06:23 ike_get_sa: Start, SA = { 560cde57 d4512fc3 - 44aac029 6ddd365b }
/ 4255b965, remote = 65.9.134.12:500
Mar 2 06:06:23 ike_sa_find: Found SA = { 560cde57 d4512fc3 - 44aac029 6ddd365b }
Mar 2 06:06:23 ike_st_o_done: ISAKMP SA negotiation done
Mar 2 06:06:23 ike_send_notify: Connected, SA = { 560cde57 d4512fc3 - 44aac029
6ddd365b}, nego = 1
Mar 2 06:06:23 ike_free_negotiation_isakmp: Start, nego = 1
Mar 2 06:06:23 ike_free_negotiation: Start, nego = 1
Mar 2 06:06:23 ike_decode_packet: Start
Mar 2 06:06:23 ike_decode_packet: Start, SA = { 560cde57 d4512fc3 - 44aac029
6ddd365b} / 4255b965, nego = 0
Mar 2 06:06:23 ike_decode_payload_sa: Start
Mar 2 06:06:23 ike_decode_payload_t: Start, # trans = 1
Mar 2 06:06:23 ike_st_i_encrypt: Check that packet was encrypted succeeded
Mar 2 06:06:23 ike_st_i_qm_hash_2: Start, hash[0..20] = 06a5d05e 1563197c ...
Mar 2 06:06:23 ike_st_i_qm_sa_values: Start
Mar 2 06:06:23 ike_st_i_qm_nonce: Nonce[0..64] = 4c0b89b5 86bb8045 ...
Mar 2 06:06:23 ike_st_i_status_n: Start, doi = 1, protocol = 3, code = unknown
(40001), spi[0..4] = bed09c6b 00000000 ..., data[0..8] = 00010004 c0a90c64 ...
Mar 2 06:06:23 ike_st_i_private: Start
Mar 2 06:06:23 ike_st_o_qm_hash_3: Start
Mar 2 06:06:23 ike_st_o_private: Start
Mar 2 06:06:23 ike_policy_reply_private_payload_out: Start
Mar 2 06:06:23 ike_st_o_encrypt: Marking encryption for packet
Mar 2 06:06:23 74.116.12.5:500 (Initiator) <-> 65.9.134.12:500 { 560cde57
d4512fc3 - 44aac029 6ddd365b [0] / 0x4255b965 } QM; MESSAGE: Phase 2 connection
succeeded, No PFS, group = 0
Mar 2 06:06:23 ike_qm_call_callback: MESSAGE: Phase 2 connection succeeded,
No PFS, group = 0
Mar 2 06:06:23 74.116.12.5:500 (Initiator) <-> 65.9.134.12:500 { 560cde57
d4512fc3 - 44aac029 6ddd365b [0] / 0x4255b965 } QM; MESSAGE: SA[0][0] = ESP aes,
life = 0 kB/3600 sec, group = 0, tunnel, hmac-sha1-96, key len = 256, key rounds = 0
Mar 2 06:06:23 ike_qm_call_callback: MESSAGE: SA[0][0] = ESP aes, life = 0 kB/3600
sec, group = 0, tunnel, hmac-sha1-96, key len = 256, key rounds = 0
Junos Software and Security | 631
Mar 2 06:06:23 ike_st_o_qm_wait_done: Marking for waiting for done
Mar 2 06:06:23 ike_encode_packet: Start, SA = { 0x560cde57 d4512fc3 - 44aac029
6ddd365b } / 4255b965, nego = 0
Mar 2 06:06:23 ike_send_packet: Start, send SA = { 560cde57 d4512fc3 - 44aac029
6ddd365b}, nego = 0, src = 74.116.12.5:500, dst = 65.9.134.12:500, routing table
id = 0
Mar 2 06:06:23 ike_send_notify: Connected, SA = { 560cde57 d4512fc3 - 44aac029
6ddd365b}, nego = 0
Virtual private networks summary
Viitual piivate netwoiks Laseu on the IPSec piotocol ollei secuiity loi sensitive tiallic
that is tiansmitteu ovei a hostile netwoik. The ]unos implementation ol IPSec pioviues
a lull set ol options anu capaLilities to allow inteiopeiaLility with most venuois. In
the pievious sections, we pioviueu the conliguiations anu veiilication loi a single im-
plementation ol this llexiLle piotocol, iepiesenting what we Lelieve is the most com-
mon appioach to secuie tunneling. These conliguiations shoulu suppoit most
implementations.
Attack Detection and Prevention
The ]unos liiewalls have an attack uetection mechanism that is activateu piioi to the
statelul secuiity policies. This mechanism is calleu the attac| scrccn, oi just scrccn.
Scieens can monitoi loi scans, uenial-ol-seivice attacks, anu packet anomalies. They
aie applieu to a secuiity zone anu monitoi all tiallic on all inteilaces loi that zone. In
the lactoiy uelault conliguiation, a numLei ol scieens aie conliguieu on the untiust
secuiity zone. The scieens aie gioupeu Ly attack type:
Scan/Spooj/Swccp Dcjcnsc
Limits the numLei ol poit scans anu auuiess sweeps alloweu liom a single host. It
also monitois anu Llocks auuiess spooling on incoming packets.
MS-Windows Dcjcnsc
Limits the numLei ol VinNuke attacks.
Dcnia|-oj-Scrvicc Dcjcnsc
Limits the numLei ol common uenial ol seivice attacks, incluuing Lanu attack,
Ping ol Death, Laige Pings, Teaiuiop, anu ICMP liagment.
|P Options Anona|ics
Monitois anu limits the numLei ol IP options that aie alloweu, incluuing souice-
ioute, secuiity, iecoiu ioute, anu timestamp.
TCP/|P Anona|ics
Monitois anu limits the numLei ol TCP llag anomalies that can occui.
I|ood Dcjcnsc
Pioviues piotection liom ICMP anu UDP piotocol lloous.
632 | Chapter 12:Junos Security Services
D
o
Configuring screens
The attack scieens aie conliguieu in two paits. Initially, we ueline the scieens to Le
useu, the paiametei settings loi those scieens (timeis, thiesholus, etc.), anu a name loi
this scieen`s ids-options gioup. Next we ieleience the ids-options gioup in a zone.
Ve can ueline multiple gioups anu assign each to a uilleient zone, oi we can ieleience
the same gioup in multiple zones. Rathei than ieinventing the wheel, we aie going to
explain the conliguiation ol the uelault scieens anu apply them to oui Inteinet zone.
The uelault secuiity scieen ids-options aie as lollows:
peter@pbr# show security screen
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
queue-size 2000;
timeout 20;
}
land;
}
}
}
The lull list ol the scieens can Le lounu in the SRX Secuiity Conliguiation Guiue,
availaLle on the ]unipei tech puL site. This guiue pioviues a uesciiption ol the attacks,
the scieen opeiations, anu the paiameteis that can Le set loi each scieen. The scieen
uelinitions that we useu in the pieceuing example aie as lollows:
ping-death
Detects anu iejects oveisizeu (gieatei than 65,507 Lytes ol uata) ICMP packet sizes,
even when liagmenteu.
source-route-option
Blocks packets with eithei the loose oi stiict souice ioute IP option set.
tear-drop
Diops tiallic that has oveilapping liagmentation segments.
syn-flood
Inteicepts, pioxies, oi uiops TCP SYN messages Laseu on the paiameteis set:
Junos Software and Security | 633
alarm-threshold 1024
The point in messages pei seconu at which an alaim is set loi incoming mes-
sages aLove the attack thiesholu.
attack-threshold 200
The point in messages pei seconu at which the liiewall staits pioxying SYN
messages to the same uestination auuiess anu poit numLei.
source-threshold 1024
The point in messages pei seconu at which the liiewall staits uiopping SYN
segments liom a single IP auuiess.
destination-threshold 2048
The point in messages pei seconu at which the liiewall staits uiopping SYN
segments to the same uestination IP auuiess, iegaiuless ol uestination poit
numLei.
queue-size 2000
The total amount ol SYN segments that the liiewall will pioxy waiting loi an
ACK piioi to uiopping all auuitional SYN segments.
timeout 20
The amount ol time in seconus that a SYN segment will Le helu in the gueue
waiting loi an ACK. Vhen this timei expiies, the SYN segment is uioppeu.
land
Diops TCP SYN segments in which the souice anu uestination auuiess aie the
same.
RememLei that Lack in Chaptei S we uiscusseu setting up liiewalls anu policeis loi the
iouteis that monitoi the tiallic Leloie the scieens. Il we set a policei in a liiewall that
limits the amount ol TCP tiallic to the DMZ, the scieens auu no Lenelit. The Lest
piactice is to peiloim the Llocking as close to the ingiess inteilace as possiLle. Il the
same piotection can Le conliguieu in a liiewall liltei oi a scieen, we iecommenu using
the liltei.
Once the scieens aie conliguieu, they aie assigneu to one oi moie zones on the liiewall.
In oui case we assigneu them to the Inteinet zone as the lollowing:
peter@pbr# show security zones security zone internet
screen untrust-screen;
interfaces {
ge-0/0/1.0 {
host-inbound-traffic {
system-services {
ssh;
}
}
}
}
634 | Chapter 12:Junos Security Services
Attack detection and prevention summary
The ]unos liiewalls have many means to piotect the enteipiise netwoik liom attacks,
implementing the concept ol uelense in uepth. Fiiewall lilteis uiop tiallic that is oLvi-
ously malicious, secuiity policies uiop tiallic that uoes not meet the secuiity guiuelines,
anu IDP looks loi alloweu tiallic that contains attacks. The scieen lunctions piotect
against tiallic that woulu not meet any ol these ciiteiia, Lut still poses a thieat in othei
ways. In oui enteipiise, the scieens piotect the inteinal netwoiks liom uenial-ol-seivice
attacks that coulu otheiwise ciash oi uisaLle oui seiveis. In the next section, we look
at the othei enu ol secuiity: the ieuunuancy capaLilities ol ]unos.
Clustering
Secuiity in the enteipiise incluues multiple aieas, specilically inloimational secuiity
anu suivivaLility, anu liiewalls liom ]unipei pioviue suppoit loi Loth. In the pieceuing
sections we conliguieu the liiewall in Beei-Co to pioviue inloimational secuiity. In this
section, we conliguie the liiewalls in a clustei. Clusteiing pioviues suivivaLility loi the
haiuwaie anu soltwaie components ol the liiewall, anu consists ol connecting two
liiewalls with contiol anu uata connections (see Figuie 12-3).
Iigurc 12-3. j2320s c|ustcrcd
Vhen connecteu, the two liiewalls cieate a single extenueu chassis that encompasses
all the inteilaces ol the two liiewalls. The llexiLle PIC concentiatois (FPCs) in a clustei
aie ienumLeieu in the seconu liiewall to Legin wheie the liist chassis leaves oll. To
illustiate this point, a poition ol the show interfaces terse commanu on a clustei ol
]2320s is shown next. The FPCs +, 5, anu 6 aie on the seconu liiewall:
root@PBR> show interfaces terse
Interface Admin Link Proto Local Remote
ge-0/0/0 up down
ge-0/0/0.1241 up down inet 10.20.130.1/30
ge-0/0/0.3141 up down inet 10.20.129.1/30
Junos Software and Security | 635
ge-0/0/0.32767 up down
ge-0/0/1 up up
ge-0/0/1.0 up up aenet --> fab0.0
se-1/0/0 up down
se-1/0/1 up down
t1-2/0/0 up up
t1-2/0/1 up up
ge-4/0/0 up down
ge-4/0/1 up up
ge-4/0/1.0 up up aenet --> fab1.0
se-5/0/0 up down
se-5/0/1 up down
t1-6/0/0 up up
t1-6/0/1 up up
Clustering components
Theie aie loui majoi components when clusteiing ]unos liiewalls: contiol links, laLiic
links, ieuunuant Etheinet inteilaces, anu the clusteiing conliguiation. The contiol anu
the laLiic (laL) links tie the two uevices togethei into a single chassis, the ieuunuant
Etheinet (Reth) inteilaces pioviue HSRP-like ieuunuant seivices to connecteu uevices,
anu the conliguiation contiols the owneiship anu monitoiing ol the chassis clustei:
Contro| |in|s
A single contiol link oi ieuunuant contiol links can Le installeu Letween the liie-
walls. The use ol ieuunuant links is ieseiveu loi the Data Centei SRX uevices. The
contiol link is useu to synchionize the conliguiation Letween the REs ol the uevices
anu to contiol the actual states ol the opeiating systems. The contiol links aie
uelineu uilleiently loi all ]unos liiewalls; ielei to the haiuwaie guiue loi the uevices
you aie clusteiing to ueteimine the location ol theii contiol links. Foi the ]2320s,
the contiol link uses the ge-0/0/3 poit.
Iabric |in|s
A single Etheinet inteilace can Le iuentilieu as the laLiic link. The laL link extenus
the switching laLiic Letween the two uevices anu also passes session inloimation
Letween the uevices. The laL inteilaces aie noimal GigaLit inteilaces that aie con-
liguieu loi the laL puipose.
Rcdundant Ethcrnct (Rcth) intcrjaccs
The Reth inteilaces pioviue ieuunuant links to connecteu uevices. The links neeu
to Le connecteu to a Layei 2 switch to pioviue automatic lailovei capaLility. Reth
inteilaces typically occupy the same poit on the two liiewalls. In oui enviionment,
we aie not going to use the seivices ol Reth inteilaces.
Conjiguration
The clusteiing conliguiation is enteieu on Loth uevices in the clustei. The conlig-
uiation is composeu ol a gioup stanza that iuentilies the unigue aspects ol each
noue (noue name, management poit auuiess, management ioutes), the clustei
iuentiliei, anu the lailovei anu monitoiing paiameteis. The next section shows the
conliguiation useu at Beei-Co.
636 | Chapter 12:Junos Security Services
Vhen these components aie applieu, the clusteieu liiewall olleis ieuunuant REs, an
expanueu switching laLiic, anu the option ol ieuunuant inteilaces.
Clustering configuration
The clusteiing conliguiation is compiiseu ol a numLei ol uistinct entities that might
not Le piesent on all uevice types. Vhen two liiewalls aie clusteieu, only one ol the
REs contiols the extenueu chassis. The othei RE is in stanuLy moue (you can log into
it anu look aiounu, Lut it uoes not have a iouting uaemon opeiating). Because ol this,
the conliguiation is ieau Ly the active RE anu opeiateu upon Ly that uevice. In oiuei
loi the othei uevice to Le manageu, it must have uevice-specilic inloimation. This is
accomplisheu thiough a gioup conliguiation that is specilic pei noue. The gioup con-
liguiation can have many elements, Lut two aie ieguiieu: the host name anu the OOB
management poit (fxp0) auuiess. Relei to the lollowing example anu to Figuie 12-3 loi
the gioup conliguiation:
[edit]
peter@PBR-node0# show groups
node0 {
system {
host-name PBR-node0;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 10.20.128.13/24;
}
}
}
}
}
node1 {
system {
host-name PBR-node1;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 10.20.128.14/24;
}
}
}
}
}
The seconu conliguiation entity is the uelinition ol the laLiic links useu Letween the
uevices. These links must teiminate on the same FPC anu poit on Loth uevices. The
inteilace shoulu Le a gigaLit Etheinet inteilace, although last Etheinet anu 10 Gig poits
can Le useu. Foi the ]-seiies, a gigaLit Etheinet inteilace is ieguiieu. Foi oui setup, the
Junos Software and Security | 637
ge-0/0/1 inteilace is useu loi the laL link. The ielevant inteilace conliguiation settings
aie as lollows:
[edit]
peter@PBR-node0# show interfaces | find fab
fab0 {
fabric-options {
member-interfaces {
ge-0/0/1;
}
}
}
fab1 {
fabric-options {
member-interfaces {
ge-4/0/1;
}
}
}
The contiol poits on the highei-enu SRXs aie vaiiaLle, so these must Le uelineu in the
conliguiation in auuition to the laL links. In the smallei SRXs anu the ]-seiies, the
contiol poits aie lixeu, so no conliguiation is necessaiy.
The clusteiing conliguiation uelines the ieuunuancy gioup piioiities anu the moni-
toieu elements. Il you aie using Reths, a seconu ieuunuancy gioup is conliguieu, so
each gioup switches inuepenuently ol the othei in the case ol a lailuie. In oui conlig-
uiation no Reths aie useu, so we have only the uelault ieuunuancy gioup (gioup 0).
The conliguiation loi the clusteiing is as lollows:
[edit]
peter@PBR-node0# show chassis cluster
redundancy-group 0 {
node 0 priority 1;
node 1 priority 100;
}
The ]unos liiewalls can opeiate in active/active moue oi active/passive
moue. In active/active moue, each ieuunuancy gioup is piimaiy on a
uilleient noue. This spieaus the loau among all the liiewall`s piocessing
powei.
Once the conliguiation is committeu, a set ol opeiational commanus aie useu to ini-
tialize the clustei that uelines the cluster-id anu node-id. The RE ol the noue with the
highei piioiity Lecomes the active RE ol the clustei. The opeiational commanus aie
enteieu on Loth noues ol the clustei anu aie shown heie loi noue 0:
peter@PBR-node0> set chassis cluster cluster-id 1 node 0 reboot
638 | Chapter 12:Junos Security Services
Verifying clustering
Once the clustei is physically connecteu anu the conliguiation is committeu, the two
liiewalls opeiate as a single entity. Ve veiily the opeiation with a couple ol commanus:
{primary:node0}
peter@PBR-node0> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 1
node0 1 primary no no
node1 100 secondary no no
This commanu shows that Loth noues aie up anu opeiational, anu that the ieuunuancy
gioup is active on noue 0. Il a manual switchovei is ieguiieu (to activate the ioute on
the stanuLy RE), the opeiational commanu woulu Le:
peter@PBR-node0> request chassis cluster failover redundancy-group 0 node 1
Reiunning the status commanu now shows that the contiol is given to noue 1, anu the
piompt shows this as well:
{secondary-hold:node0}
peter@PBR-node0> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 2
node0 1 secondary-hold no no
node1 100 primary no no
Theie is a hiuuen commanu that shows much moie inloimation aLout
the status ol the clustei (show chassis cluster information). This com-
manu (anu all hiuuen commanus) shoulu Le useu with cautiontheie
must Le a ieason why it is hiuuen.
Piioi to ietuining contiol to noue 0, we must ieset the lailovei paiameteis anu then
issue the lailovei ieguest again:
peter@PBR-node0> request chassis cluster failover reset redundancy-group 0
node0:
--------------------------------------------------------------------------
No reset required for redundancy group 0.
node1:
--------------------------------------------------------------------------
Successfully reset manual failover for redundancy group 0
{secondary:node0}
peter@PBR-node0> request chassis cluster failover redundancy-group 0 node 0
node0:
--------------------------------------------------------------------------
Junos Software and Security | 639
Initiated manual failover for redundancy group 0
Note: If the Unified threat management feature is being used, please have
have all redundancy-groups primary on the same node.
Theie is a holu-uown timei associateu with the switching ol the active noues; this
pievents llapping Letween the noues. The timei is conliguiaLle anu uelaults to 5 mi-
nutes. Il the pieceuing lailovei is peiloimeu within this timei, an eiioi is piesenteu.
Once the lailLack is peiloimeu, the noimal uisplays ol chassis haiuwaie, sessions, anu
the like will all have noue 0 anu noue 1 sections:
{primary:node0}
peter@PBR-node0> show security flow session
node0:
--------------------------------------------------------------------------
0 sessions displayed
node1:
--------------------------------------------------------------------------
0 sessions displayed
{primary:node0}
peter@PBR-node0> show chassis hardware
node0:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN119F556ADD J2320
Midplane REV 06 710-017558 AABZ1397
System IO REV 10 710-017562 AABW4806 J23X0 System IO
Crypto Module Crypto Acceleration
Routing Engine REV 14 710-017560 AABY9504 RE-J2320-2000
FPC 0 FPC
PIC 0 4x GE Base PIC
FPC 1 REV 17 750-010356 AG10200058 FPC
PIC 0 2x Serial
FPC 2 REV 15 750-010355 AI10250081 FPC
PIC 0 2x T1
Power Supply 0
node1:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN119E4DDADD J2320
Midplane REV 06 710-017558 AABZ1455
System IO REV 10 710-017562 AABW4869 J23X0 System IO
Crypto Module Crypto Acceleration
Routing Engine REV 14 710-017560 AABY9625 RE-J2320-2000
FPC 0 FPC
PIC 0 4x GE Base PIC
FPC 1 REV 17 750-010356 AG10200057 FPC
640 | Chapter 12:Junos Security Services
PIC 0 2x Serial
FPC 2 REV 15 750-010355 AI10250101 FPC
PIC 0 2x T1
Power Supply 0
Clustering summary
Clusteiing ]unos liiewalls pioviues suivivaLility liom uevice, piocessoi, anu link lail-
uies. It allows two liiewalls to act as a single chassis ol inteilaces unuei the contiol ol
a single RE. Tiallic sessions, ioutes, anu conliguiations aie tiackeu Ly Loth REs, anu
in the event ol a lailuie, the Lackup takes contiol ol the chassis. Clusteiing pioviues
anothei level ol secuiity loi youi enteipiise.
Conclusion
The secuiity seivice lounu in ]unos on the ]-seiies anu the SRX uevices iepiesents a
signilicant inciease in secuiity, anu the seivices capaLilities in geneial loi suppoiteu
platloims. Vith ]unos secuiity seivices, useis aie no longei loiceu to compiomise ei-
thei seivices oi iouting when they opt loi a single-Lox solution. Foimeily, this ieguiieu
a multiple-chassis, Lest-ol-Lieeu appioach, which auueu cost anu complexity to the
netwoik.
In auuition to the one-Lox Lenelits, that one Lox iuns ]unos soltwaie, alLeit with se-
cuiity seivices enaLleu. This means that all the Lenelits anu auvantages ol ]unos aie
still availaLle, anu the majoiity ol opeiational expeiience caiiies ovei uiiectly, allowing
you to immeuiately leel at home when using the secuiity seivices.
Exam Topics
Cuiiently, the ]unipei Netwoiks Ceitilieu Inteinet Expeit (]NCIE-ER) examination is
Laseu on ASP seivice sets. This is suLject to change within the next yeai. Canuiuates
shoulu consult the ]unipei Netwoiks weLsite loi up-to-uate inloimation on ceitilica-
tion examination tiacks anu topics.
Chapter Review Questions
1. Vhat is the uelault context ol an SRX oi ]-seiies ioutei?
A. The uelault is the secuie context.
B. The uelault is the iouting context.
C. Both contexts aie theie Ly uelault; it uepenus on whethei policies aie
conliguieu.
D. Both contexts aie theie Ly uelault; it uepenus on the host-inLounu-tiallic
conliguiation.
Chapter Review Questions | 641
2. Vhat is tiue iegaiuing zones?
A. You aie limiteu to no moie than live.
B. Each zone is iestiicteu to a single inteilace.
C. Policy is neeueu to communicate Letween zones, unless in ioutei context.
D. Policy is neeueu to communicate Letween zones.
3. Vhat is the minimal secuiity stanza to allow initial connectivity in a ]unos liiewall?
A. A single zone, with all inteilaces.
B. A single zone, with all inteilaces anu a peimit all policy.
C. A zone pei inteilace anu a lull mesh ol policies.
D. None ol the aLove; no secuiity stanza is necessaiy.
+. Vhat is the name ol the seivices inteilace on a ]unos liiewall?
A. sp-0/0/0
B. st-0/0/0
C. es-0/0/0
D. The zone-Laseu natuie means that a seivices inteilace is not ieguiieu.
5. Does the lollowing session entiy, as taken liom PBR, inuicate that NAT has Leen
peiloimeu?
Session ID: 1285, Policy name: self-traffic-policy/1, Timeout: 1784
In: 172.16.1.2/59024 --> 172.16.1.1/179;tcp, If: .local..0
Out: 172.16.1.1/179 --> 172.16.1.2/59024;tcp, If: ge-0/0/1.0
A. No, NAT is not Leing peiloimeu.
B. Yes, NAT is Leing peiloimeu.
C. Only Souice NAT is Leing peiloimeu.
D. Only Destination NAT is Leing peiloimeu.
6. Vhich platloim oi platloims suppoit ]unos liiewall lunctions?
A. M7i
B. MX2+0
C. ]-seiies
D. SRX
Chapter Review Answers
1. Answei: C. The uelault opeiation is secuie context.
2. Answei: D. Policy is always neeueu to peimit tiallic Letween zones.
3. Answei: B. The minimal secuiity stanza is assigning all inteilaces to a single zone
anu cieating a policy that allows tiallic liom that zone to that zone.
642 | Chapter 12:Junos Security Services
+. Answei: D. The L3 seivices aie no longei neeueu anu have no inteilace suppoit.
5. Answei: A. The use ol 172.16.1.0/2+ auuiessing inuicates that no NAT has Leen
peiloimeu.
6. Answei: C, D. ASIC-Laseu platloims such as the M7i anu MX2+0 uo not suppoit
secuiity seivices. The ]-seiies anu SRX platloims pioviue this suppoit.
Chapter Review Answers | 643
APPENDIX A
Junos Layer 3 Services
Seivice is a Lioau teim that incluues Layei 2 as well as Layei 3 lunctions. In Chap-
tei 9, we lookeu at the Layei 2 seivices lounu in ]unos. Layei 3 seivices have unueigone
a uiamatic change since the liist euition ol this Look. Layei 3 seiviceswhich incluue
NAT, IDP, VPNs, anu statelul policiesaie now conliguieu as pait ol the secuiity
stanza uesciiLeu in Chaptei 12 ol this Look. The legacy Layei 3 seivices (piioi to ]unos
9.+) aie coveieu heie loi completeness. Note that as ol this wiiting, the ]unipei Net-
woiks Ceitilieu Inteinet Expeit (]NCIE-ER) examination is Laseu on the legacy seiv-
ices, anu so ieaueis inteiesteu in passing the ]NCIE-ER examination will neeu to Le
lamiliai with ASP-Laseu seivice uelinitions uesciiLeu heie.
As stateu pieviously loi Layei 2 seivices anu iepeateu heie loi claiity, loi the M-seiies
iouteis, enaLling these seivices will ieguiie an auuitional piece ol haiuwaie: a Physical
Inteilace Caiu (PIC) loi packet piocessing. A ]-seiies oi an MX seiies ioutei suppoits
most ol the Layei 3 leatuies in soltwaie, so no auuitional haiuwaie is necessaiy.
Layer 3 Services
The ]unos Layei 3 seivices incluue statelul liiewall, NAT, IDS, anu IPSec tunnels. Ve
will covei the uetails ol the seivices heie anu the conliguiation latei in this appenuix.
On the ASP oi Multiseivices-100 PIC, you must choose to enaLle ci-
thcr Layei 2 or Layei 3 seivices; the ASM on the M7i anu the ]-seiies
ioutei suppoit both Layei 2 anu Layei 3 concuiiently.
Stateful Firewall
Usually when ceitain tiallic neeus to Le Llockeu on a ioutei, a simple stateless packet
liltei is applieu to an inteilace. On a ]unipei ioutei, these aie calleu jircwa|| ji|tcrs (othei
venuois call these acccss |ists). Regaiuless ol the name, all stateless lilteis lunction in
645
the same manneithey look at a packet anu opeiate on a seiies ol match iules. Il the
packet matches a iule, it can Le eithei accepteu oi uiscaiueu.
The impoitant point aLout a packet liltei is that it woiks on a packet-Ly-packet Lasis
anu uoes not associate a packet with a tiallic llow oi stieam. In othei woius, it uoes
not maintain any connection state. This type ol liltei will woik in many situations when
applications aie using well-known poit numLeis oi TCP applications, wheie the ini-
tiatoi is always in the same uiiection. Stateless packet lilteis Lecome moie uillicult
when the application uses ianuom poit numLeisTCP initiatois aie not always the
sameoi when UDP input anu output llows neeu to Le associateu with each othei.
Foi example, il a Domain Name System (DNS) seivei was locateu outsiue youi net-
woik, you coulu easily wiite a packet liltei that allows outLounu access to UDP poit
53, Lut you woulu neeu to wiite a iule loi the inLounu packet as well. The souice poit
woulu Le poit 53, Lut the uestination poit coulu Le any poit liom 102+ to 6553+,
uepenuing on which ianuom poit the host chose. Allowing this laige ol a UDP poit
opens up a laige hole in youi netwoik.
A statelul liiewall will tiack j|ows ol tiallic loi a given application such as DNS, which
will pioviue loi much stiongei secuiity. This means that il a packet hits the liiewall
iule anu is accepteu Laseu on the match conuitions, the system will calculate the ietuin
packet, so no ieveise iule will have to Le cieateu. A llow is usually uelineu Ly paiameteis
such as souice anu uestination auuiesses, souice anu uestination poit numLeis, anu
piotocol values. A Liuiiectional llow Letween the souice anu uestination uevices is
olten calleu a scssion oi a convcrsation. Once a session oi conveisation is cieateu, it is
stoieu in memoiy, so the liiewall iules uo not neeu to piocess any auuitional packets
that aie pait ol that llow. These conveisations will Le stoieu until a peiiou ol inactivity
occuis, which is 30 seconus Ly uelault loi most piotocols. You can mouily this gloLally
unuei the seivice inteilace:
lab@hops# set interfaces sp-0/0/0 services-options inactivity-timeout ?
Possible completions:
<inactivity-timeout> Inactivity timeout period for established sessions
A llow is iemoveu liom the taLle unuei the lollowing conuitions:
Il a TCP RESET oi FIN packet is ieceiveu. The llow is maikeu loi
ueletion anu is iemoveu in appioximately live seconus.
Il the TCP llow appeais to Le iule (no tiallic). In this case, the ioutei
implements a TCP tickle Ly senuing an ACK message with the last
seen seguence numLei, minus one numeial, to the enu host. This
veiilies whethei the poits aie open. Il no iesponse is ieceiveu, the
llow is maikeu loi ueletion in appioximately live seconus.
Il the loiwaiu llow ol the UDP conveisation ieaches the inactivity
timeout peiiou. Since the ieveise llow will Le cieateu Laseu on the
loiwaiu llow, this llow will not Le tiackeu loi inactivity.
646 | Appendix A:Junos Layer 3 Services
The statelul liiewall will also auu a layei ol piotection Ly checking to make suie theie
aie no stiange piotocol anomalies that coulu inuicate a uenial ol seivice (DoS) attack.
Some examples ol piotocol anomalies that aie checkeu incluue the lollowing:
The Time to Live (TTL) in the IP packet eguals 0.
The souice IP auuiess eguals the uestination IP auuiess.
An IP liagment is misseu.
The TCP oi UDP poit is set to 0.
TCP llags aie set to an invaliu comLination.
A SYN packet is ieceiveu without a SYN-ACK iesponse.
The liist llow packet is not a SYN packet.
ICMP unieachaLle eiiois occui loi SYN oi UDP packets.
This is a small list ol the possiLle anomalies; please consult the ]unipei
Technical Documentation loi a moie complete list.
Application Layer Gateways
Most ol the time, the statelul liiewall will easily Le aLle to pieuict the packets that will
Le ieguiieu loi the ietuin llow ol a conveisation Ly simply ieveising the souice anu
uestination poit numLeis, auuiesses, anu so loith. Howevei, some applications, such
as FTP, H.323, RTSP useu Ly RealAuuio, anu SIP, aie moie uillicult to pieuict Lecause
the application may initiate sepaiate connections loi uata anu contiol llows oi may
geneiate new piotocol llows Laseu on an open connection. In this case, special caie
must Le taken to analyze the packets anu allow the new connections to Le estaLlisheu.
Each application may have a unigue set ol paiameteis that must Le examineu, which
aie implementeu as Application Layei Gateways (ALGs).
The classic example ol why an ALG is neeueu is when you look at an application such
as an active outgoing FTP, which uses Loth a contiol anu a uata channel. Fiist, the TCP
thiee-way hanushake is estaLlisheu Letween the client (S+.10.113.0) anu the seivei
(S+.10.113.1) using a uestination poit ol 21:
02:21:00.500569 In IP 84.10.113.0.4290 > 84.10.113.1.21: Syn
02:21:00.500627 Out IP 84.10.113.1.21 > 84.10.113.0.4290: Syn Ack
02:21:00.510683 In IP 84.10.113.0.4290 > 84.10.113.1.21: . Ack
Then the seivei initiates a new connection loi the uata tianslei using a new souice poit
ol 20 anu a uestination poit that the client gives to the seivei in the initial connection
using a PORT commanu (5695S, in this case):
02:26:28.024058 Out IP 84.10.113.1.20 > 84.10.113.0.56958: Syn
02:26:28.032298 In IP 84.10.113.0.56958 > 84.10.113.1.20: Syn Ack
02:26:28.032362 Out IP 84.10.113.1.20 > 84.10.113.0.56958: . Ack
Layer 3 Services | 647
So, the pioLlem with the active moue FTP application anu stanuaiu liiewall iules is
that the connections aie initiateu Ly Loth the seivei anu the client, anu the connection
initiateu Ly the seivei to the client is using an unpieuictaLle poit numLei.
The ALG solves this pioLlem Ly looking ueep into the packets uuiing the initial con-
nection phase loi the PORT commanu, inuicating which poit numLei the client will Le
expecting liom the seivei uuiing the uata phase anu allowing the liiewall to cieate a
pieuictaLle pinhole loi the seivei-to-client connection.
Il passive FTP is useu, all connections aie initiateu liom the client to the
seivei, Lut the ALG must still monitoi the PORT commanu liom the
seivei to open the uata connection.
Anothei example in which ALG is neeueu is when you`ie using H.323, the umLiella
specilication loi a lamily ol piotocols loi tianspoiting voice anu viueo ovei uata net-
woiks. H.323 involves piotocols that open contiol anu uata channels similai to oui
FTP example. In a common setup anu uata llow, these steps occui:
1. Fiist, an H.225 connection is cieateu loi call signaling, the meuia (auuio anu viueo),
the stieam packetization, the meuia stieam synchionization, anu the contiol mes-
sage loimats.
2. Duiing the H.225 connection, inloimation is exchangeu to also estaLlish an H.2+5
connection.
3. An H.2+5 connection is estaLlisheu to convey contiol inloimation loi the meuia
llow, such as enciyption anu llow contiol as well as poit inloimation loi RTP/
RTCP llows.
+. RTP/RTCP uata tiallic llows Legin.
The ALG that is useu loi H.323 is moie complex than in the FTP example, Lut the
geneial iuea ol watching one conveisation to open moie llows is the same. The ALG
watches the H.225 connection loi inloimation to open the H.2+5 connection anu then
watches this connection to open the meuia connections.
Since these ALGs can Le veiy complex, most ol them aie alieauy cieateu in the ]unipei
Netwoiks ioutei loi you, although you can cieate custom ALGs. You can view all the
]unipei-uelineu ALGs Ly issuing the show groups junos-defaults applications com-
manu liom conliguiation moue. All uelault system applications will Legin with the
junos keywoiu.
Network Address Translation
NAT is simply the changing ol the IP auuiess (souice, uestination, oi Loth) ol the packet
as it tiaveises the ioutei. These tianslations aie stoieu in a taLle to allow loi tiallic
llows liom the souice to the uestination systems. Auuitionally, poit numLeis coulu
648 | Appendix A:Junos Layer 3 Services
also Le tianslateu (olten ieleiieu to as Netwoik Auuiess Poit Tianslation NAPT oi
Poit Auuiess Tianslation PAT). Tiauitionally, NAT was useu to hiue piivate au-
uiesses Lehinu a puLlic netwoik oi to tiy to conseive auuiess space Ly mapping mul-
tiple poit numLeis to a single IP auuiess. Vhen NAT is conliguieu, you must answei
the lollowing guestions:
Vhich IP auuiess is going to Le tianslateu: the souice IP (souice-NAT), the uesti-
nation IP (uestination-NAT), oi Loth (Liuiiectional NAT)?
Does poit tianslation neeu to occui?
Does the mapping neeu to Le the same (static) oi can a pool ol auuiesses anu poits
Le useu (uynamic)?
Next, you must examine the type ol NAT that must Le conliguieu. The NAT types
availaLle on a ]unipei ioutei incluue the lollowing:
Static sourcc NAT
Maps a pool ol piivate IP auuiesses to a pool ol puLlic auuiesses on a one-to-one
Lasis. This means tiallic liom a piivate auuiess, such as 192.16S.2.1, will always
Le mappeu to the same puLlic auuiess, such as 207.12.1S.2.
Dynanic sourcc NAT
Maps a pool ol piivate IP auuiesses to a pool ol puLlic auuiesses. This mapping is
uynamic, so 192.16S.2.1 coulu Le tianslateu to the conliguieu puLlic auuiess pool.
Sourcc NAT with port trans|ation
Maps a pool ol piivate IP auuiesses to a single auuiess oi pool ol puLlic auuiesses,
while also tianslating the poit numLeis. This allows loi one-to-many NAT, when
many piivate IP auuiesses aie tianslateu to a single puLlic auuiess.
Dcstination NAT
Behaves the same as souice NAT, except it opeiates on the incoming llow ol the
uestination auuiess. Destination NAT will tianslate an incoming puLlic auuiess to
one oi many piivate auuiesses. One use ol this is to allow the Inteinet to use a
puLlic auuiess to contact a seivei on the inteinal netwoik that is conliguieu with
a piivate IP auuiess.
Bidircctiona| NAT
A comLination ol a souice NAT anu uestination NAT in which Host A can initiate
a session with Host B anu Host B can also initiate a session with Host A. This is
common when an email seivei is onsite.
Twicc NAT
Delineu in RFC 2663 anu similai to Liuiiectional NAT. The majoi uilleience is
that in twice NAT, the souice anu uestination auuiesses aie tianslateu within the
same llow, wheieas Liuiiectional NAT woulu use uilleient llows.
You can conliguie NAT on a ]unipei Netwoiks ioutei as a stanualone seivice oi com-
Line it with anothei seivice, such as statelul liiewall.
Layer 3 Services | 649
Intrusion Detection Services
Intiusion uetection monitois tiallic llows anu looks loi hostile patteins. Il such a pat-
tein exists, the event can Le loggeu. Intiusion uetection anu pievention (IDP) takes this
one step luithei Ly stopping an attack once a hostile pattein is iecognizeu. The ]unipei
Netwoiks ioutei is limiteu in its IDP implementation, as it uoes not match on any
highei-layei signatuie attacks. Essentially, the IDP implantation can aiu in piotecting
youi netwoik liom attacks such as the lollowing:
Port scanning
Vhen a hostile machine pioLes the netwoik loi open poits to attack.
SYN j|ood attac|s
Vhen a high numLei ol SYN packets aie ieceiveu in an attempt to lloou the
netwoik.
|P jragncntation attac|s
Piotects against packets with the more fragments llag set, such as attacks like Teai-
uiop anu Boink. Teaiuiop attacks exploit the ieassemLly ol liagmenteu IP packets
Ly ollsetting the options in the IP heauei. Vhen the sum ol the ollset anu size ol
one liagmenteu packet uillei liom that ol the next liagmenteu packet, the packets
oveilap, anu the seivei attempting to ieassemLle the packet can ciash.
|CMP j|oods
Vhen ICMP echo ieguests oveiloau its victim with so many ieguests that all its
iesouices iesponu until it can no longei piocess valiu netwoik tiallic.
Vhen any ol these attacks occui, events aie loggeu anu aie sent to a collectoi loi anal-
ysis, oi in the case ol lloou attacks, aie iate-limiteu. You also can pievent SYN lloous
Ly conliguiing SYN cookie piotection that will cause the ioutei to opeiate as a SYN
proxy.
IPSec VPN
Vhen secuiing uata ovei a puLlic netwoik, olten a tunnel is conliguieu Letween the
two netwoiks. A tunnel simply encapsulates youi uata into anothei packet oi liame to
tianspoit it acioss the puLlic netwoik. Foi instance, you can cieate a tunnel to connect
Remote Ollice A to Coipoiate Ollice B ovei the puLlic Inteinet, as shown in Fig-
uie A-1, to cieate a viitual piivate netwoik (VPN).
The puipose ol this Look is not to teach IPSec theoiy; a numLei ol Looks
uo that well, such as |PScc: Thc Ncw Sccurity Standard jor thc |ntcrnct,
|ntrancts, and \irtua| Privatc Nctwor|s (Pientice Hall).
650 | Appendix A:Junos Layer 3 Services
You can use many tunneling piotocols loi this connection, Lut one ol the most wiuely
ueployeu piotocols loi tianspoiting IP tiallic is IPSec. IPSec can pioviue the lollowing
secuiity lunctions:
Sourcc authcntication
Ensuies that the uata is liom the expecteu senuei. This is accomplisheu Ly the
ingiess ioutei ol the IPSec tunnel, cieating a one-way hash value ol ceitain paiam-
eteis ol the packet as well as a passwoiu (pieshaieu key) that is known Ly Loth
enupoints. It will inseit this hash value into the packet so that when the ieceiving
enupoint examines the packet, it can compaie this value with the hash that will Le
locally computeu. Il they aie the same, the authentication passes; il they aie uil-
leient, the authentication lails. Common algoiithms to accomplish this aie Mes-
sage Digest 5 (MD5) anu the Secuie Hash Algoiithm (SHA-1).
A hash junction is a pieuictaLle mathematical calculation that takes
some vaiiaLle-size input anu piouuces a lixeu-size stiing calleu a
hash. A key attiiLute ol a hash is that it is a one-way opeiation
so, the hash value can Le cieateu Laseu on the input Lut the input
cannot Le iecieateu Laseu on the hash value. Hash lunctions aie
useu in Loth authentication anu uata integiity.
Data intcgrity
Ensuies that the uata was not alteieu uuiing packet tiansmission. A hash value is
computeu anu is placeu into the packet Laseu on packet lielus. The ieceiving ioutei
will compute a hash Laseu on the same lielus ol the packet anu then compaie the
computeu hash value with the ieceiveu hash value. Il they aie not eguivalent, the
uata was alteieu anu the packet will Le uioppeu. The hash algoiithm that is useu
is noimally MD5 oi SHA-1.
Iigurc A-1. Connccting a rcnotc ojjicc to thc corporatc ojjicc
Layer 3 Services | 651
Conjidcntia|ity
Ensuies that the uata cannot Le ieau ovei the puLlic inliastiuctuie. IPSec pioviues
conliuentiality Ly enciypting the tiallic using the Data Enciyption Stanuaiu (DES),
Tiiple DES (3DES), oi Auvanceu Enciyption Stanuaiu (AES) algoiithm.
Rcp|ay protcction
Even though uata can Le enciypteu, a hostile uevice can inteicept a packet, ie-
cieate it, anu senu a lloou ol that packet to the enupoint to tiy to cieate a DoS
attack. To piotect against this, seguence numLeis aie veiilieu to avoiu packet
uuplication.
Vhen an IPSec tunnel is maue, the tunnel enupoints cieate a secuiity association (SA)
with each VPN. An SA is a list ol the piotocols, algoiithms, anu piotecteu netwoiks
upon which Loth enupoints have agieeu. These SAs can Le cieateu manually on each
siue, oi uynamically with the use ol the Inteinet Key Exchange (IKE) piotocol. IKE
consists ol two phases: Phase 1 estaLlishes the piotocols anu shaieu seciets neeueu to
cieate a secuie channel; anu Phase 2 uses this secuie channel to exchange the piotocols,
algoiithms, anu othei paiameteis that will Le useu loi the uata exchange, thus cieating
the SAs. Vhen Phase 2 has completeu, uata can llow secuiely Letween the two enu-
points, as shown in Figuie A-2.
Iigurc A-2. |PScc \PN dynanic tunnc| cstab|ishncnt
Layer 3 Services Summary
This section examineu many Layei 3 seivices, incluuing NAT, statelul liiewall, IDP,
anu IPSec-Laseu VPNs. In the next section, we will put this theoiy into piactice as we
conliguie anu opeiationally veiily vaiious netwoik layei seivices.
Layer 3 Services Configuration
The liist step when conliguiing Layei 3 seivices on youi ioutei is to enaLle the haiuwaie
loi those seivices. Il the ASP oi Multiseivices PIC is useu, you must specily the layei ol
seivice as eithei Layei 2 oi Layei 3:
lab@sake# set chassis fpc 1 pic 2 adaptive-services service-package ?
Possible completions:
652 | Appendix A:Junos Layer 3 Services
layer-2 Layer 2 service package
layer-3 Layer 3 service package
[edit]
lab@sake# show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis A1609 M7i
Midplane REV 04 710-008761 CR6773 M7i Midplane
Power Supply 1 Rev 06 740-008537 6039089 AC Power Supply
Routing Engine REV 01 740-011202 1000618737 RE-850
CFEB REV 08 750-010464 CR5380 Internet Processor II
FPC 0 E-FPC
PIC 0 REV 11 750-002992 CT2202 4x F/E, 100 BASE-TX
PIC 2 REV 08 750-005724 CR1650 2x OC-3 ATM-II IQ, MM
FPC 1 E-FPC
PIC 2 REV 07 750-009487 CP5197 ASP - Integrated
PIC 3 REV 10 750-009098 CR4858 2x F/E, 100 BASE-TX
The ASM, MX seiies, anu ]-seiies iouteis uo not contain this limitation anu can suppoit
both types ol seivices concuiiently. The main Luiluing Llock when conliguiing ]unos
seivices is calleu a scrvicc sct, which is a list ol seivice inteilaces, seivice types, anu
seivice iules applieu to eithei an inteilace oi a iouting next hop. A seivice set can
contain one type ol Layei 3 seivice oi a giouping ol seivices such as NAT, IDS, anu
statelul liiewall. Il an IPSec VPN is ieguiieu, you must place it in its own unigue seivice
set.
To match which packet will Le piocesseu Ly each seivice set, you must wiite a set ol
iules with a match conuition anu an action. These iules have a similai loimat to ]unos
policies anu stateless liiewall liltei iules, containing a from statement loi the match
poition anu a then statement loi the action. But a majoi uilleience is that seivice iules
aie always piocesseu in a statelul mannei, so the match clauses uo not neeu to account
loi ietuin tiallic. The match clauses will have a vaiiety ol options uepenuing on the
seivice conliguieu, anu the actions will ueline which seivice to apply. You also can
comLine the iules loi each seivice to loim a iule set, as shown in Figuie A-3.
Iigurc A-3. CL| ru|c, ru|c sct, and scrvicc sct rc|ationship
Vhen you cieate youi seivice set, you`ll neeu to ueciue whethei it shoulu Le applieu
as an inteilace oi a next hop. An inteilace-style seivice set is applieu uiiectly to the
inteilace allecting tiallic as it leaves anu enteis the inteilace.
Layer 3 Services Configuration | 653
An inteilace-style seivice set tiacks session on a pei-seivice-set Lasis.
This means that the same seivice set coulu Le applieu to multiple phys-
ical inteilaces to uesign aiounu asymmetiical tiallic llows.
A next hopstyle seivice set makes use ol two logical seivice inteilaces, calleu the
insidc anu outsidc inteilaces. Tiallic is mappeu to these inteilaces as a iesult ol a iouting
next hop lookup. The tiallic can entei oi exit cithcr the insiue oi the outsiue inteilace
uepenuing on the conliguiation, which uepenus piimaiily on the iouting conliguiation
anu statelul-liiewall iules.
Both types ol seivice styles use the seivice inteilace, nameu sp-, in the uelinition ol the
seivice set. This inteilace is the soltwaie inteilace that the ioutei will senu tiallic to il
a Layei 3 seivice is ieguiieu. The inteilace-style seivice set ieguiies a single logical unit
to Le conliguieu with IPv+ suppoit enaLleu:
lab@Porter# set interfaces sp-0/0/0 unit 0 family inet
lab@Porter# show interfaces
sp-0/0/0 {
unit 0 {
family inet;
Vhen conliguiing the sp- inteilace, the system geneially ieseives
unit 0 loi seivice logging anu othei communication liom the seivice
PIC; howevei, you can use it loi an inteilace-style seivice set not useu
in a viitual ioutei. Next hop seivice sets cannot use unit 0.
The next hop seivice set ieguiies the seivice inteilace to Le logically uiviueu into an
insiue anu outsiue inteilace:
[edit]
lab@Porter# set interfaces sp-0/0/0 unit 1 service-domain inside family inet
[edit]
lab@Porter# set interfaces sp-0/0/0 unit 2 service-domain outside family inet
[edit]
lab@Porter# show interfaces sp-0/0/0
unit 0 {
family inet;
}
unit 1 {
family inet;
service-domain inside;
}
unit 2 {
family inet;
service-domain outside;
}
654 | Appendix A:Junos Layer 3 Services
Altei cieating the seivice inteilaces, you`ll neeu to cieate the seivice iules anu the seivice
sets. Vhen cieating the seivice iules, one item you must conliguie is a uiiection ol
eithei input oi output, as shown in Figuie A-+. The uiiection that is iecoiueu loi a packet
must match loi the seivice iule to match. This uiiection is stiaightloiwaiu loi an
inteilace-style seivice set, as input is loi incoming tiallic to the physical inteilace, anu
output is loi tiallic leaving the physical inteilace.
Iigurc A-1. Dircctions jor intcrjacc-sty|c scrvicc scts
But when you look at a next hopstyle seivice set, the uiiection is a Lit moie complex
Lecause now the next hop coulu point to two possiLle logical inteilaces. Il the next hop
points to the insiue inteilace, the uiiection is input, anu il the next hop points to the
outsiue inteilace, the uiiection is output. The uiiection loi next hopstyle seivice sets
is olten misconliguieu, which causes tiallic to Le seiviceu incoiiectly. Figuie A-5 shows
the piopei uiiections that you shoulu use when cieating seivice iules.
Iigurc A-5. Dircctions jor ncxt hop-sty|c scrvicc scts
Vhen conliguiing seivice iules loi next hopstyle seivice sets, you shoulu consiuei
tiallic llow liom the peispective ol the insiue inteilace. Tiallic that the ioutei ioutes
to the insiue inteilace is consiueieu input tiallic on the insiue inteilace anu is consiueieu
input tiallic Ly the ioutei when it evaluates seivice iules. Tiallic that the ioutei ieceives
on the outsiue inteilace, piocesses, anu then tiansmits out the insiue inteilace is con-
siueieu output tiallic on the outsiue inteilace anu is consiueieu output tiallic Ly the
ioutei when it evaluates seivice iules. In geneial, it may Le much less conlusing to point
tiallic to the insiue inteilace when possiLle, as the uiiections seem to Le as expecteu,
while the outsiue inteilace appeais to Le opposite liom what is expecteu. Although
tiallic mapping to an insiue inteilace may make moie sense in the human minu, the
ioutei makes no logical uistinction, so mapping to eithei the insiue oi the outsiue
conliguiation will woik.
Layer 3 Services Configuration | 655
Since next hopstyle seivice sets aie a little moie complex, it seems as though inteilace-
style seivice sets woulu Le pieleiieu. Each seivice set, howevei, has its own auvantages
anu uisauvantages, as uetaileu in TaLle A-1.
Foi instance, an inteilace-style seivice set has the lollowing limitations:
It cannot suppoit multicast tiallic matcheu thiough the seivice set (incluuing IPSec
tunnels).
It cannot have oveilapping auuiess spaces (such as RFC 191S) that neeu to Le
NATeu.
It cannot iun iouting piotocols ovei the seivice sets, such as IPSec tunnels.
Locally geneiateu tiallic will not match the iules.
So, to solve any ol those loui geneial limitations, you nust use a next hop seivice set.
Inteilace-style seivice sets uo have theii place, though; they aie much easiei to conliguie
loi simple tasks, anu they aie easiei to apply to multiple inteilaces. Il the same seivice
neeus to Le applieu to multiple inteilaces with sepaiate ioute taLles loi inuiviuual cus-
tomeis, a next hop seivice set woulu ieguiie multiple seivice sets, wheieas an inteilace-
style seivice set might ieguiie only a single seivice set. Also, an inteilace-style seivice
set allows loi the use ol an exteinal inteilace auuiess loi ceitain NAT ciicumstances
that a next hop seivice set cannot accomplish. Theieloie, you shoulu choose a seivice
set Laseu on which leatuies neeu to Le suppoiteu. TaLle A-1 can assist you as a geneial
guiueline loi choosing youi seivice style.
You will have to apply the seivice set loi it to take ellect. You can apply it uiiectly to
the inteilace unit (inteilace style) oi ieleience the seivice inteilace (next hop).
Fiist, heie is an example ol a seivice set applieu uiiectly to inteilace t1-2/0/2:
lab@Porter# show interfaces t1-2/0/2
description Porter-to-Bock;
unit 0 {
family inet {
service {
input {
service-set test-rule;
}
output {
service-set test-rule;
}
}
address 10.10.10.2/30;
}
}
656 | Appendix A:Junos Layer 3 Services
Tab|c A-1. Sunnary oj scrvicc-sty|c jcaturc support
Service style
General
configuration
complexity Multicast support
Routing protocols
over IPSec
Overlapping NAT
addresses
Interface Easy No No No
Next hop Hard Yes Yes Yes
Service style
PAT with external
interface in the NAT pool Treat IPSec tunnels as a link
Number of security zones
supported
Interface Yes No One
Next hop No Yes Many
The seivice set test-rule is applieu to the inteilace at the logical unit level anu is applieu
loi family inet (IPv+) tiallic. The stiange piece ol this conliguiation is the lact that the
seivice set must Le applieu as both an input anu an output seivice, anu it nust Le the
same seivice set. This means uiiection is nevei inleiieu when applying a seivice set to
an inteilace. Recall that the uiiection ol a iule is ueciueu in the seivice iule anu not in
the uiiection in which the seivice set is applieu to the inteilace!
Applying the seivice set to Loth the input anu the output ol an inteilace
has no ieal puipose in the cuiient implementation; it was cieateu as pait
ol the oiiginal specilication outline. Theie was a thought that asym-
metiical tiallic with uilleient seivice sets woulu Le suppoiteu, Lut it was
ueciueu latei not to implement that lunction in ]unos.
Il a next hop seivice type is useu, simply conliguie the ioutei to loiwaiu packets to
eithei the insiue oi the outsiue seivice inteilace. This is usually uone Ly cieating a static
ioute that points to the seivice inteilace, which in tuin cieates anothei ioute taLle to
point tiallic to the seivice inteilace oi iuns a iouting piotocol ovei the seivice inteilace.
This example senus all 5.5.0/19 tiallic to the sp-0/0/0.1 (insiue) inteilace:
[edit]
lab@Porter# show routing-options
static {
route 5.5.0.0/19 next-hop sp-0/0/0.1;
}
This veiilies that the ioute is active:
[edit]
lab@Porter# run show route protocol static
inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
5.5.0.0/19 *[Static/5] 00:00:08
> via sp-0/0/0.1
Layer 3 Services Configuration | 657
Logging and Tracing
Since you can conliguie system logging anu tiacing in a vaiiety ol places in the conlig-
uiation lile, it can Le conlusing which statement is actually uoing the logging. The iule
in ]unos is that the moie specilic conliguiation will always oveiiiue the moie gloLal
conliguiation. The levels ol logging possiLle, in oiuei ol gloLal to specilic, aie as
lollows:
|ntcrjacc |ogging
lab@PBR# set sp-0/0/0 services-options syslog host 1.1.1.1 services ?
Possible completions:
<[Enter]> Execute this command
alert Conditions that should be corrected immediately
any All levels
critical Critical conditions
emergency Panic conditions
error Error conditions
info Informational messages
none No messages
notice Conditions that should be handled specially
warning Warning messages
| Pipe through a command
Scrvicc sct |ogging
lab@PBR# set services service-set telnet-set syslog host 1.1.1.1 services ?
Possible completions:
<[Enter]> Execute this command
alert Conditions that should be corrected immediately
any All levels
critical Critical conditions
emergency Panic conditions
error Error conditions
info Informational messages
none No messages
notice Conditions that should be handled specially
warning Warning messages
| Pipe through a command
Icaturc ru|c (statcju| jircwa||, |PScc, ctc.) |ogging
set stateful-firewall rule restricted-telnet term 1 then syslog
So, il logging was enaLleu at the seivice inteilace level anu thiee seivice sets weie con-
liguieu, all thiee seivice sets woulu inheiit the seivice-level logging settings. Il a single
seivice set also enaLleu logging, those settings woulu oveiiiue the seivice-level logging
loi that seivice set. The iemaining seivice sets woulu inheiit the seivice inteilace logging
settings.
Theie aie also uilleient types ol logging: stanuaiu syslog anu tiaceoptions. Syslog will
senu a system log message to a syslog seivei oi the local ioutei, anu tiaceoptions will
only senu inloimation to the local ioutei. Vhen you aie viewing seivices, tiaceoptions
658 | Appendix A:Junos Layer 3 Services
usually gives you a view ol the actual soltwaie opeiations on the Routing Engine (RE)
anu not the seivice PIC itsell.
You can senu syslog inloimation to a iemote syslog seivei Ly inuicating a host, oi senu
it to the local ioutei Ly specilying the keywoiu local:
sp-0/0/0 {
services-options {
syslog {
host local {
services any;
}
}
}
Il you specily that the syslog messages shoulu Le sent to the local ioutei, you can senu
the messages to the uelault system log ol ncssagcs oi to anothei uesignateu lile. Also,
loi those messages to actually appeai, you will have to conliguie the ioutei to accept
messages loi the local2 lacility. To place these syslog entiies in the ncssagcs lile, you
can use this conliguiation:
[edit]
lab@PBR# set system syslog file messages local2 any
An example ol the types ol syslog messages is messages that show which iules have
Leen matcheu anu cieateu. Heie, ioutei PBR is monitoiing the ncssagcs lile in ieal time,
anu you can see that a statelul-liiewall iule was matcheu anu a llow was cieateu Laseu
on that match:
[edit]
lab@PBR# run monitor start messages
*** messages ***
Aug 10 06:45:50 (FPC Slot 0, PIC Slot 0) {telnet-set}[FWNAT]: ASP_SFW
_RULE_ACCEPT: proto 6 (TCP) application: any, ge-0/0/0.413:64.8.12.5:
10.10.12.3:23, Match SFW accept rule-set: , rule: restricted-telnet,
term: 1
Aug 10 06:45:50 (FPC Slot 0, PIC Slot 0) {telnet-set}[FWNAT]: ASP_SFW_CREATE_ACCEPT_
FLOW: proto 6 (TCP) application: any, ge-0/0/0.413:64.8.12.5:3225 -> 10.10.12.3:23,
creating forward or watch
flow
Il you neeu to examine the seivice`s soltwaie opeiation, you can conliguie tiaceoptions
at the PIC level. Il no lile is specilieu, the inloimation will Le placeu into a lile calleu spd:
lab@PBR# set services adaptive-services-pics traceoptions flag ?
Possible completions:
all Trace everything
configuration Trace configuration events
kernel-object Trace kernel object management
routing-protocol Trace routing protocol events
routing-socket Trace routing socket events
snmp Trace SNMP operations
Layer 3 Services Configuration | 659
Heie is an example ol the types ol messages you woulu see in spd. In this coue snippet,
soltwaie sockets have Leen cieateu anu iesouices have Leen assigneu when seivices
weie conliguieu:
lab@PBR# run show log spd
Aug 10 07:13:27 spd process starting, pid 12555
Aug 10 07:13:27 rpd session connected
Aug 10 07:13:27 registered async opaque handler for traps
Aug 10 07:13:27 Added sp-0/0/0 snmpindex 21 fpc_slot 0 pic_slot 0 to database
Aug 10 07:13:27 Loading initial state from kernel...
Aug 10 07:13:27 Processed ASP_CFG_GLOBAL_OPTIONS config object
Aug 10 07:13:27 Adding blob to set: id = 1, type = 16, size = 92, pic = sp-0/0/0 (0)
Aug 10 07:13:27 Blob id = 1, type = 16, size = 92 is new, adding
Aug 10 07:13:27 Imported config object (type 16, id 1)
Aug 10 07:13:27 Adding blob to set: id = 1, type = 16, size = 92, pic = sp-0/0/0 (0)
Aug 10 07:13:27 State initialization from kernel complete
Aug 10 07:13:27 ------ Finished with RTSOCK initialization ------
Aug 10 07:13:28 get_pic_index sp-0/0/0.1 pic index 0
Aug 10 07:13:28 get_pic_index sp-0/0/0.1 pic index 0
Aug 10 07:13:28 Adding blob to set: id = 2, type = 12, size = 912, pic = sp-0/0/0 (0)
Aug 10 07:13:28 get_pic_index sp-0/0/0 pic index 0
Aug 10 07:13:28 Adding blob to set: id = 1, type = 16, size = 92, pic = sp-0/0/0 (0)
Aug 10 07:13:28 Blob id = 1 is not changed, skipping
Aug 10 07:13:28 Blob id = 2, type = 12, size = 912 is new, adding
Aug 10 07:13:28 Added service set telnet-set (id 2, pic sp-0/0/0 (0))
Aug 10 07:13:28 Adding blob to set: id = 2, type = 12, size = 912, pic = sp-0/0/0 (0)
Aug 10 07:13:28 rpd session established
Layer 3 Services Configuration Summary
This section uesciiLeu the vaiious Layei 3 seivice olleiings as well as the CLI conligu-
iation steps that weie neeueu. Ve also uiscusseu the option ol inteilace-style oi next
hopstyle seivice sets. Ve will covei examples ol each ol these seivices in the next
sections.
IPSec VPNs
IPSec VPNs tunnel IP tiallic acioss an IP netwoik to pioviue secuiity leatuies such as
uata piivacy anu integiity. Vhen Luiluing an IPSec tunnel, you must ueciue on a lew
paiameteis:
Piotocol (Encapsulating Secuiity Payloau ESP, authentication heauei AH, oi
Bunule)
Enciyption algoiithm (Auvanceu Enciyption Stanuaiu AES, Data Enciyption
Stanuaiu DES, Tiiple DES 3DES, oi none)
Authentication algoiithm (Message Digest 5 MD5, Secuie Hash Algoiithm
SHA-1)
660 | Appendix A:Junos Layer 3 Services
Peilect loiwaiu seciecy (on/oll)
Anti-ieplay (on/oll)
Togethei, these paiameteis loim a proposa|. The pioposal must Le eguivalent on each
siue ol the tunnel loi the tunnel to Lecome estaLlisheu. These pioposals can Le statically
conliguieu oi uynamically negotiateu using the Inteinet Key Exchange (IKE) piotocol.
Static pioposals aie iaiely useu, as they aie cumLeisome to manage, pione to eiioi,
anu uillicult to change on the lly. IKE uses a methou ol key exchanges to exchange
paiameteis in a secuie mannei ovei two phases. Phase 1 estaLlishes the paiameteis
neeueu to exchange inloimation to loim a secuie IPSec tunnel. Phase 2 estaLlishes the
actual secuiity paiameteis loi that IPSec tunnel. Vhen viewing commanus on the
ioutei, Phase 1 is seen as an IKE secuiity association, anu Phase 2 is seen as an IPSec
secuiity association.
Since multiple tunnels can Le estaLlisheu Letween two peeis, theie has to Le some way
to iuentily which packets Lelong to each tunnel. To uo this, a uataLase is cieateu with
entiies calleu secuiity associations (SAs) loi each tunnel. An SA iuentilies each tunnel
Ly the lollowing paiameteis:
Destination IP auuiess
Secuiity piotocol anu paiameteis (piotocol, enciyption, anu authentication)
Secuiity Paiametei Inuex (SPI)
Seciet keys
Example IPSec Tunnel Configuration
Vhen conliguiing an IPSec tunnel, as with all Layei 3 seivices, you will neeu a seivice
set. These seivice sets contain the iules loi matching tiallic that shoulu tiansit the IPSec
tunnel. The iules can incluue policies that link the vaiious pioposals that the tunnel
will use (see Figuie A-6). Theie can Le sepaiate policies anu pioposals loi the Phase 1
(IKE) anu Phase 2 (IPSec) SAs.
Iigurc A-. |PScc ru|c, po|icy, and proposa| rc|ationships
PBR is going to loim an IPSec tunnel with the extianet Cans loi tiallic to a 12S.3.3/2+
auuiess Llock to secuie tiallic (see Figuie A-7). The iemote enupoint ol the tunnel is
12S.3.3.+ anu the local auuiess on PBR is 172.16.1.2. PBR is leaining the 123.3.3/2+
suLnet via BGP with Wheat.
The tunnel will Le set up with the uelault paiameteis shown in TaLle A-2.
IPSec VPNs | 661
Tab|c A-2. Dcjau|t paranctcrs jor tunnc|
IKE IPSec
Mode Main N/A
Protocol N/A ESP
Encryption 3DES-CBC (cipher block chaining) 3DES-CBC
Authentication SHA-1 Hashed Message Authentication Code (HMAC)-SHA-1-96
Lifetime 3,600 seconds 28,800 seconds
Additional options N/A Antireplay, no Perfect Forward Secrecy (PFS) protocol
Interface-style service set
Fiist we will implement the tunnel as an inteilace-style seivice set anu then as a next
hop seivice set. Begin Ly cieating the seivice inteilace to use loi the inteilace-style
seivice set:
[edit interfaces]
lab@PBR# set sp-0/0/0 unit 0 family inet
Now cieate the iule to match tiallic sent to the tunnel anu, minimally, an IKE policy
to Le applieu. An IKE policy ieleiencing eithei a pieshaieu key oi a ceitilicate is ie-
guiieu, anu IPSec policies aie optional. Vith this conliguiation, the tunnel will inheiit
the uelault paiameteis listeu in TaLle A-2:
[edit services ipsec-vpn]
ike {
policy min-policy {
pre-shared-key ascii-text "$9$BSJ1RSdVYJUH8XGDHkPfIEh";
## SECRET-DATA
Iigurc A-7. Sanp|c topo|ogy
662 | Appendix A:Junos Layer 3 Services
}
}
Cieate the IPSec VPN iule to match on the ieguiieu tiallic anu senu it thiough the
tunnel towaiu the enupoint. The IKE policy will also neeu to Le applieu, along with a
uiiection in which to cncrypt tiallic:
lab@PBRt# show services
ipsec-vpn {
rule secure-extranet {
term 1 {
from {
destination-address {
128.3.3.0/24;
}
}
then {
remote-gateway 128.3.3.4;
dynamic {
ike-policy min-policy;
}
}
}
match-direction output;
}
}
The ioutei automatically cieateu Liuiiectional SAs, so when specilying
tiallic to Le secuieu in the outLounu uiiection, the ioutei automatically
secuies the inLounu uiiection. This means that when specilying an
inteilace-style seivice set, the output uiiection is geneially useu, wheieas
a next hopstyle seivice set will use the input uiiection.
Next, we neeu to cieate the seivice set that maps the IPSec iule anu the seivice inteilace.
Auuitionally, we neeu to conliguie the local gateway loi the IPSec tunnel. This will Le
the auuiess useu to souice all IPSec packets as well as the auuiess to which the iemote
tunnels will connect. You can have only a single gateway auuiess in a seivice set, Lut
you can conliguie multiple iemote gateways in the IPSec iules:
[edit services]
lab@PBR# show service-set basic-vpn
interface-service {
service-interface sp-0/0/0.0;
}
ipsec-vpn-options {
local-gateway 172.16.1.2;
}
ipsec-vpn-rules secure-extranet;
Apply the seivice set to the tunnel`s outLounu inteilace:
lab@PBR# top show interfaces ge-0/0/0 unit 412
description PBR-to-Wheat;
IPSec VPNs | 663
vlan-id 412;
family inet {
service {
input {
service-set basic-vpn;
}
output {
service-set basic-vpn;
}
}
address 172.16.1.2/24;
Altei committing the conliguiation, view the tunnel status with the show service
ipsec commanu. Heie the tunnel appeais to Le uown, as no Phase 2 SAs appeai:
lab@PBR# run show services ipsec-vpn ipsec security-associations
Service set: basic-vpn
Rule: secure-extranet, Term: 1, Tunnel index: 1
Local gateway: 172.16.1.2, Remote gateway: 128.3.3.4
Tunnel MTU: 1500
--- No IPSec SA information available ---
Issuing a ping to the iemote gateway auuiess ol 12S.3.3.+ on PBR inuicates the pioLlem:
lab@PBR# ping 128.3.3.4
PING 128.3.3.4 (128.3.3.4): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- 128.3.3.4 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
n
Recall that the 12S.3.3/2+ netwoik was leaineu via BGP. Vhen viewing the BGP neigh-
Loi status towaiu Wheat, the session appeais to Le uown, as seen Ly the connect state:
lab@PBR# run show bgp summary
Groups: 1 Peers: 1 Down peers: 1
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Damped...
172.16.1.1 420 198 184 0 7 6:30 Connect
The BGP session is uown Lecause the seivice set is applieu to the session`s inteilace.
RememLei that once a seivice set is applieu to an inteilace, any tiallic that uoes not
match the teim is seiviceu Ly uelault. To avoiu this pioLlem, you shoulu apply a seivice
liltei to skip the piocession ol BGP tiallic. The uelault action ol a seivice liltei is
skip, so make suie othei tiallic is seiviceu accoiuingly:
[edit firewall]
lab@PBR# show
family inet {
664 | Appendix A:Junos Layer 3 Services
service-filter allow-bgp {
term 1 {
from {
protocol tcp;
port bgp;
}
then skip;
}
}
term 2 {
then service;
}
}
Apply the seivice liltei to the inteilace in Loth uiiections:
lab@PBR# top show interfaces ge-0/0/0 unit 412
description PBR-to-Wheat;
vlan-id 412;
family inet {
service {
input {
service-set basic-vpn service-filter allow-bgp;
}
output {
service-set basic-vpn service-filter allow-bgp;
}
}
address 172.16.1.2/24;
Altei the seivice liltei has Leen applieu, the BGP session anu the IPSec tunnel will
Lecome estaLlisheu. Veiily the tunnel using the show services ipsec commanu. Fiist,
veiily Phase 1, ensuiing that the state is matuieu:
[edit firewall family inet service-filter allow-bgp]
lab@PBR# run show services ipsec-vpn ike security-associations
Remote Address State Initiator cookie Responder cookie
Exchange type
128.3.3.4 Matured 773036d8a2d22e7b ef23082150245a03
Main
Olten, an opeiatoi will view the IKE SA, anu when nothing appeais, the
opeiatoi will assume that the IPSec tunnel is uown. This is not always
the case, as IKE associations appeai only on an as neeueu Lasis. So,
il the IPSec SA has Leen estaLlisheu, the IKE SA may time out. Using
uelault paiameteis, the liletime ol an IKE SA is 3,600 seconus anu the
liletime ol IPSec is 2S,S00 seconus, which means that a staLle netwoik
may not have an active IKE SA loi up to 7 houis! Make suie that il any
changes occui that coulu pievent two-way IKE communication Letween
the iemote peeis, the IPSec SA is cleaieu to loice a ienegotiation ol the
IKE SA. Otheiwise, a liltei-Llocking IKE message may not Leen seen loi
seveial houis Leloie the IPSec SA ieaches its liletime.
IPSec VPNs | 665
Now veiily that Phase 2 has an inLounu anu outLounu SA loi Liuiiectional tiallic llows:
[edit firewall family inet service-filter allow-bgp]
lab@PBR# run show services ipsec-vpn ipsec security-associations
Service set: basic-vpn
Rule: secure-extranet, Term: 1, Tunnel index: 1
Local gateway: 172.16.1.2, Remote gateway: 128.3.3.4
Tunnel MTU: 1500
Direction SPI AUX-SPI Mode Type Protocol
inbound 2579118494 0 tunnel dynamic ESP
outbound 247425684 0 tunnel dynamic ESP
By uelault, the estaLlishment ol an IPSec tunnel is uata-uiiven. This
means that the tunnel is not estaLlisheu until a packet matches a iule
that ieguiies the tunnel. Il you want to change this Lehavioi, use the
establish-tunnels immediately commanu.
Vhen IPSec is ueployeu on the ioutei, the ioutei must know how to uiiect tiallic to
the seivice Physical Inteilace Caiu (PIC) oi seivice mouule to authenticate, ue-enciypt,
anu ue-encapsulate the packet. The ioutei accomplishes this Ly cieating loiwaiuing
taLle entiies Laseu on the souice IP auuiess, uestination IP auuiess, anu piotocol tuple.
These entiies will Le seen as /72s in the loiwaiuing taLle with a next hop ol service:
[edit firewall family inet service-filter allow-bgp]
lab@PBR# run show route forwarding-table | find /72
172.16.1.2.128.3.3.4.50/72
user 0 service 324 3
172.16.1.2.128.3.3.4.51/72
user 0 service 324 3
172.16.1.3/32 user 0 172.16.1.1 ucst 332 5 ge-0/0/0.412
172.16.1.255/32 dest 0 172.16.1.255 bcst 320 1 ge-0/0/0.412
224.0.0.0/4 perm 1 mdsc 13 1
224.0.0.1/32 perm 0 224.0.0.1 mcst 9 3
224.0.0.5/32 user 1 224.0.0.5 mcst 9 3
255.255.255.255/32 perm 0 bcst 10 1
Routing table: _ _juniper_private1_ _.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 62 1
10.0.0.1/32 intf 1 10.0.0.1 locl 321 2
10.0.0.16/32 intf 0 10.0.0.16 locl 322 1
224.0.0.0/4 perm 0 mdsc 61 1
224.0.0.1/32 perm 0 224.0.0.1 mcst 57 1
255.255.255.255/32 perm 0 bcst 58 1
The conseguence ol these entiies, il you aie using an inteilace-style seivice set, is that
tiallic ieceiveu on any inteilace, iegaiuless ol wheie the seivice set is applieu, will Le
seiviceu.
666 | Appendix A:Junos Layer 3 Services
Next hopstyle service set
The same IPSec VPN is now implementeu using a next hopstyle seivice set. As with
eveiy next hopstyle seivice set, you must conliguie the two legs ol the insiue anu
outsiue seivice sets:
sp-0/0/0 {
unit 0 {
family inet;
}
unit 1 {
family inet;
service-domain inside;
}
unit 2 {
family inet;
service-domain outside;
}
}
Then you neeu to cieate the IPSec iules. These iules will look the same as they uiu in
the pievious example using inteilace-style seivice sets, with one notaLle exception: ru|c
dircction. Since tiallic is going to Le mappeu to the insiue inteilace loi enciyption, a
match-direction ol input shoulu Le useu:
ipsec-vpn {
rule secure-extranet {
term 1 {
from {
destination-address {
128.3.3.0/24;
}
}
then {
remote-gateway 128.3.3.4;
dynamic {
ike-policy min-policy;
}
}
}
match-direction input;
}
Now tiallic is mappeu to the insiue seivice inteilace to Le enciypteu in the IPSec tunnel.
You can accomplish this mapping in a vaiiety ol ways; the simplest is with a static ioute:
lan@PBR set routing-options static route 128.3.3/24 next-hop sp-0/0/0.1
Altei committing the conliguiation anu senuing tiallic liom Bock to the extianet
12S.3.3/2+ suLnet, the IKE anu IPSec SAs aie cieateu:
[edit]
lab@PBR# run show services ipsec-vpn ike security-associations
Remote AddressState Initiator cookie Responder cookie Exchange type
128.3.3.4 Matured 833d31c69f915b75 4326d4b9c69e624f Main
IPSec VPNs | 667
D
o
lab@PBR# run show services ipsec-vpn ipsec security-associations
Service set: basic-vpn
Rule: secure-extranet, Term: 1, Tunnel index: 1
Local gateway: 172.16.1.2, Remote gateway: 128.3.3.4
IPSec inside interface: sp-0/0/0.1, Tunnel MTU: 1500
Direction SPI AUX-SPI Mode Type Protocol
inbound 612210302 0 tunnel dynamic ESP
outbound 1652494959 0 tunnel dynamic ESP
Also veiily that the tiallic liom Bock to the extianet is actually Leing enciypteu and
ueciypteu Ly viewing the IPSec statistics:
lab@PBR# run show services ipsec-vpn ipsec statistics
PIC: sp-0/0/0, Service set: basic-vpn
ESP Statistics:
Encrypted bytes: 4400
Decrypted bytes: 5336
Encrypted packets: 50
Decrypted packets: 63
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
The inteilace-style seivice set ieguiies a seivice liltei to allow the extei-
nal BGP session to Le estaLlisheu; howevei, these lilteis uo not exist in
next hopstyle seivice sets, noi aie they ieguiieu. Simply ensuie that
only tiallic that shoulu Le seiviceu is mappeu to the seivice inteilace.
Besiues the usual show commanu to tiouLleshoot IPSec tunnels, you also
can conliguie IKE tiaceoptions via set services ipsec-vpn traceoptions
flag ike. These messages aie automatically placeu into a lile calleu |nd.
IPSec over GRE
Sometimes the names loi netwoik leatuies seem to Le cieateu out ol thin aii, with no
ihyme oi ieason. This is the case with an IPSec ovei GRE tunnel. The name uoes not
accuiately uesciiLe the leatuie, as it actually is a Geneiic Routing Encapsulation (GRE)
tunnel that is secuieu with IPSec. A Lettei name woulu Le GRE ovei IPSec, Lut as we
all know, netwoik engineeiing can`t Le that logical. The most common usage ol IPSec
ovei GRE tunnels is to inteiopeiate with oluei Cisco IOS coues that uo not suppoit
iouting ovei IPSec tunnels. In these cases, iouting is conliguieu ovei GRE anu then
IPSec is auueu. In ]unos, iouting ovei IPSec tunnels is accomplisheu Ly using next hop
style seivice sets. Howevei, when implementing IPSec ovei GRE, you can use eithei
668 | Appendix A:Junos Layer 3 Services
seivice set type, with one exception. Il the GRE enupoints aie the same as the IPSec
tunnel enupoints, you shoulu use inteilace-style seivice sets.
You coulu use a next hopstyle seivice set il the tunnel enupoints aie
the same anu FBF was useu to map the GRE packets to the IPSec tunnel,
Lut this auus an auuitional level ol complexity that you shoulu avoiu il
possiLle.
As in Figuie A-7, an IPSec ovei GRE tunnel will Le conliguieu Letween PBR anu the
Cans extianet. Fiist, an unnumLeieu GRE inteilace is cieateu liom PBR to Cans:
lab@PBR# show interfaces gr-0/0/0
unit 0 {
tunnel {
source 172.16.1.2;
destination 128.3.3.4;
}
family inet;
}
To aiu in tiouLleshooting, you coulu auu an IP auuiess to the GRE
tunnel, Lut it is not necessaiy.
Tiallic to the extianet is mappeu via a static ioute that points to the gr-0/0/0.0
inteilace:
[edit]
lab@PBR# show routing-options static route 128.3.3.0/24
next-hop gr-0/0/0.0;
Next, you neeu to conliguie unigue pioposals that map to Cisco uelaults:
ipsec {
proposal cisco-interop {
protocol esp;
authentication-algorithm hmac-md5-96;
encryption-algorithm des-cbc;
}
policy ipsecgre {
perfect-forward-secrecy {
keys group1;
}
proposals cisco-interop;
}
}
ike {
proposal cisco-interop-ike {
authentication-method pre-shared-keys;
dh-group group1;
IPSec VPNs | 669
authentication-algorithm md5;
encryption-algorithm des-cbc;
}
policy main_ike {
proposals cisco-interop-ike;
pre-shared-key ascii-text "$9$JhUi.QF/0BEP5BEcyW8ZUjHP5z
36AuO"; ## SECRET-DATA
}
}
Then, you neeu to cieate the iule to map the GRE packets to the IPSec tunnel. You can
uo this Ly matching on the souice IP auuiess anu uestination IP auuiess ol the GRE
tunnel, as well as Ly mapping the Cisco inteiopeiaLle pioposals to the IPSec tunnels:
lab@PBR# show services | find ipsec-vpn
ipsec-vpn {
rule map-gre {
term 1 {
from {
source-address {
172.16.1.2/32;
}
destination-address {
128.3.3.4/32;
}
}
then {
remote-gateway 128.3.3.4;
dynamic {
ike-policy main_ike;
ipsec-policy ipsecgre;
}
}
}
match-direction output;
}
A seivice set is then cieateu anu applieu to the inteilace Letween PBR anu Wheat:
lab@PBR# show services
service-set ipsec-gre {
interface-service {
service-interface sp-0/0/0.0;
}
ipsec-vpn-options {
local-gateway 172.16.1.2;
}
ipsec-vpn-rules map-gre;
}
lab@PBR# show interfaces
ge-0/0/0 {
vlan-tagging;
unit 412 {
description PBR-to-Wheat;
vlan-id 412;
family inet {
670 | Appendix A:Junos Layer 3 Services
service {
input {
service-set ipsec-gre }
output {
service-set ipsec-gre
}
}
address 172.16.1.2/24;
}
}
Two auuitional pieces ol conliguiation shoulu pioLaLly Le auueu: IKE tiaceoptions
anu automatic tunnel estaLlishment. IKE tiaceoptions will Le useu to help tiouLleshoot
il the IPSec tunnel uoes not come up, anu automatic tunnel estaLlishment will Le useu
to avoiu lost packets that coulu iesult when GRE packets aie sent Leloie the IPSec
tunnel is lully estaLlisheu:
[edit]
lab@PBR# set services ipsec-vpn establish-tunnels immediately
[edit]
lab@PBR# set services ipsec-vpn traceoptions flag ike traceoptions {
Altei the conliguiation is committeu, the tunnel is estaLlisheu:
[edit]
lab@PBR# run show services ipsec-vpn ipsec security-associations
Service set: ipsec-gre
Rule: map-gre, Term: 1, Tunnel index: 1
Local gateway: 172.16.1.2, Remote gateway: 128.3.3.4
Tunnel MTU: 1500
Direction SPI AUX-SPI Mode Type Protocol
inbound 4232427354 0 tunnel dynamic ESP
outbound 83055442 0 tunnel dynamic ESP
Howevei, tiallic uoes not llow acioss the tunnel, anu the BGP session to Wheat is uown.
The solution to this pioLlem scieams seivice liltei!
[edit]
lab@PBR# run show bgp summary
Groups: 1 Peers: 1 Down peers: 1
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last
Up/Dwn State|#Active/Received/Damped...
172.16.1.1 420 11892 10737 0 4 11:53 Active
It is oLvious that we neeu to Luilu a seivice liltei to skip the BGP tiallic liom Leing
seiviceu, while also ensuiing that the GRE tiallic gets sent uown the IPSec tunnel. Vhat
might not Le so oLvious is that we neeu a seivice liltei in both uiiections, Lecause when
GRE packets aie encapsulateu insiue the system anu the packets aie ciiculateu, the
input inteilace Lecomes the next hop outgoing inteilace, as shown heie anu latei in
Figuie A-1+:
IPSec VPNs | 671
lab@PBR> show configuration firewall
family inet {
service-filter match-vpn-input {
term service {
from {
source-address {
128.3.3.4/32;
}
destination-address {
172.16.1.2/32;
}
}
then service;
}
term skip {
then skip;
}
}
service-filter match-vpn-output {
term service {
from {
source-address {
172.16.1.2/32;
}
destination-address {
128.3.3.4/32;
}
}
then service;
}
term skip {
then skip;
}
}
}
Apply the seivice lilteis to the VAN inteilace on PBR:
lab@PBR> show configuration interfaces ge-0/0/0 unit 412
description PBR-to-Wheat;
vlan-id 412;
family inet {
service {
input {
service-set ipsec-gre service-filter match-vpn-input;
}
output {
service-set ipsec-gre service-filter match-vpn-output;
}
}
address 172.16.1.2/24;
Geneiate some test tiallic to the extianet on the inteinal ioutei Bock:
lab@Bock> ping 128.3.3.3 rapid count 100
PING 128.3.3.3 (128.3.3.3): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
672 | Appendix A:Junos Layer 3 Services
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--- 128.3.3.3 ping statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.666/18.435/40.117/9.181 ms
Veiily that the packets aie Loth enciypteu anu ueciypteu to anu liom the Cans extianet:
lab@PBR# run show services ipsec-vpn ipsec statistics
PIC: sp-0/0/0, Service set: ipsec-gre
ESP Statistics:
Encrypted bytes: 11200
Decrypted bytes: 11200
Encrypted packets: 100
Decrypted packets: 100
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
Foi ieleience puiposes only, heie is an example ol what the conliguiation may look
like on the Cisco siue in the extianet:
crypto isakmp policy 1
hash md5
authentication pre-share
crypto isakmp key test address 172.16.1.2
crypto isakmp keepalive 10 2 periodic
!
!
crypto ipsec transform-set esp_des_set esp-des esp-md5-hmac
!
!
crypto map gre-to-ipsec 1 ipsec-isakmp
set peer 172.16.1.2
set transform-set esp_des_set
set pfs group1
match address 110
access-list 110 permit ip host 128.3.3.4 host 172.16.1.2
interface tunnel1
tunnel mode gre ip
tunnel destination 172.16.1.2
tunnel source 128.3.3.4
interface fast0
crypto map gre-to-ipsec
IPSec VPNs | 673
Summary of IPSec VPNs
IPSec VPNs pioviue a secuie methou loi piotecting uata ovei a piivate oi puLlic
netwoik. These coulu Le VPNs with uelault pioposals oi VPNs with veiy specilic au-
thentication anu enciyption methous. Also, you can use these VPNs loi a vaiiety ol
applications, incluuing secuiing access to an extianet, pioviuing iemote ollice connec-
tivity, anu pioviuing a Lackup link loi youi inteinal netwoik. Some ol these VPNs may
have uynamic enupoints oi ieguiie GRE tunnels loi inteiopeiaLility with othei venuois.
You can accomplish all ol this using ]unos anu seivices.
The next section uetails anothei seivice that is olleieu: NAT.
NAT
NAT is simply a way to change the souice oi uestination IP auuiess ol a packet Lecause
ol puLlic auuiess exhaustion oi a secuiity mechanism to piotect inteinal hosts. The
inteinal hosts can Le mappeu to theii own inuiviuual puLlic auuiesses, oi a pool ol
auuiesses coulu Le useu. Also, many auuiesses coulu Le mappeu to a single auuiess
utilizing uilleient Tiansmission Contiol Piotocol/Usei Datagiam Piotocol (TCP/UDP)
poit numLeis loi the llow, ieleiieu to as Poit Auuiess Tianslation (PAT). The most
common NAT scenaiios aie listeu heie (anu shown in Figuie A-S):
Dcstination NAT without port napping
The incoming puLlic auuiess is mappeu to a piivate auuiess. This is usually useu
to hiue an inteinal seivei`s auuiess liom the outsiue woilu.
Dcstination NAT with port napping
The incoming uestination auuiess anu poit aie mappeu to a piivate auuiess. This
allows loi many seivices to Le tieu to the same uestination auuiess uilleientiateu
Ly poit numLeis. This is noimally useu when only a single exteinal auuiess is given
that must map to multiple piivate connections.
NAT sourcc without port trans|ation
The outgoing piivate souice IP auuiess is mappeu to a puLlic IP auuiess. This is
useu when insiue hosts want to ieach exteinal netwoiks anu the host inloimation
wants to iemain hiuuen.
NAT sourcc with port trans|ation
The outgoing piivate IP auuiess is mappeu to a puLlic IP anu the poit numLei is
also changeu. This is useu when multiple souices aie mappeu to a lew puLlic IP
auuiesses.
Twicc NAT
This is useu when Loth the souice IP anu the uestination IP neeu to Le changeu.
This coulu Le a mail seivei that neeus Loth inLounu anu outLounu connections.
Twice NAT is suppoiteu in ]unos S.3 anu latei.
674 | Appendix A:Junos Layer 3 Services
The tianslateu auuiess can Le eithei specilieu in the NAT iule oi cieateu as a pool ol
auuiesses. Il PAT is ieguiieu, you must use a pool. You can ieuse a pool in multiple
NAT iules. In the pool, you can specily a single auuiess, a pielix, oi a iange ol auuiesses.
You also can enaLle poit tianslation in the pool to select a iange ol poit values oi have
the system automatically choose a value:
lab@PBR# set services nat pool example ?
Possible completions:
> address Address or address prefix for NAT
> address-range Range of addresses for NAT
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these
groups
> port Specify ports for NAT
[edit]
The pool is then applieu as a souice oi uestination pool in the NAT iule.
You also can conliguie an ovcr|oad poo| il the piimaiy pool Lecomes
exhausteu.
In auuition, you can apply a pielix without using a pool ol auuiesses:
[edit]
lab@PBR# set services nat rule example term 1 then translated ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
destination-pool NAT pool for destination translation
destination-prefix NAT prefix for destination translation
overload-pool NAT pool to be used when source pool is overloaded
Iigurc A-8. Connon NAT dcp|oyncnts
NAT | 675
overload-prefix NAT prefix to be used when source pool is overloaded
source-pool NAT pool for source translation
source-prefix NAT prefix for source translation
> translation-type Type of translation to perform
Vhen ueciuing how to conliguie NAT, seveial guestions uiive the coiiect solutions:
Is the souice IP auuiess anu/oi uestination IP auuiess going to Le tianslateu?
Is poit tianslation going to occui?
Aie the auuiesses going to Le statically mappeu oi uynamically mappeu?
Shoulu an auuiess pool Le useu?
Ve will examine a lew common scenaiios in the lollowing sections.
Source NAT with No PAT
A simple souice NAT loi all piivate auuiesses to an exteinal auuiess pool ol 55.55.5/27
is implementeu on PBR using the pieleiieu solution ol a next hop seivice set, as shown
in Figuie A-9.
Iigurc A-9. Sourcc NAT cxanp|c
Fiist, an auuiess pool calleu ext-block is cieateu without poit tianslation. An auuiess
Llock is not necessaiy Lut is useu loi lutuie scalaLility:
lab@PBR# show services
nat {
pool ext-block {
address 55.55.5.0/27;
}
Then a iule is cieateu to tianslate all souice auuiesses using this auuiess Llock. This
must Le a uynamic tianslation since theie is no matching souice suLnet:
rule basic-source {
match-direction input;
676 | Appendix A:Junos Layer 3 Services
term 1 {
then {
translated {
source-pool ext-block;
translation-type source dynamic;
}
}
}
}
}
A next hop seivice set is cieateu to map the NAT iule:
service-set Trust-Untrust {
nat-rules basic-source;
next-hop-service {
inside-service-interface sp-0/0/0.1;
outside-service-interface sp-0/0/0.2;
}
}
The exteinal auuiess Llock must Le ieachaLle Ly the outsiue woilu. Since PBR alieauy
has a hazy BGP ielationship with AS +20, this auuiess Llock is sent via BGP:
[edit]
lab@PBR# show protocols bgp
export [ send-agg send-ext-block ];
group as_420 {
type external;
neighbor 172.16.1.1 {
peer-as 420;
}
}
lab@PBR# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 7 5 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Damped...
172.16.1.1 420 7852 7077 0 2 2d 7:07:42 5/7/0 0/0/0
lab@PBR# run show route advertising-protocol bgp 172.16.1.1 55/8
inet.0: 21 destinations, 26 routes (20 active, 0 holddown, 5 hidden)
Prefix Nexthop MED Lclpref AS path
* 55.55.5.0/27 Self I
Next, we cieate a VR to iepiesent the inteinal tiust (inteinal) poition ol the netwoik.
The LAN inteilace ol PBR is auueu, as well as the insiue seivice inteilace. Also, the OSPF
conliguiation is moveu ovei the VR. This incluues a policy calleu send-default (not
shown) that senus a uelault ioute into OSPF loi Inteinet connectivity. Also, a loopLack
is auueu loi use in OSPF. Lastly, a uelault ioute is cieateu to senu all non-inteinal tiallic
to the insiue seivice inteilace:
[edit]
lab@PBR# show routing-instances
NAT | 677
trust {
instance-type virtual-router;
interface ge-0/0/0.1241;
interface sp-0/0/0.1;
interface lo0.0;
routing-options {
static {
route 0.0.0.0/0 next-hop sp-0/0/0.1;
}
}
protocols {
ospf {
export send-default;
area 0.0.0.0 {
interface ge-0/0/0.1241;
interface lo0.1;
}
}
}
}
Foi completeness, the policies on PBR aie shown heie. Please ielei to Chaptei 5 loi a
policy uiscussion:
[edit]
lab@PBR# show policy-options
prefix-list internal-subnets {
10.10.12.0/22;
10.10.128.0/22;
10.20.128.0/22;
}
policy-statement send-agg {
from protocol aggregate;
then accept;
}
policy-statement send-default {
from {
route-filter 0.0.0.0/0 exact accept;
}
}
policy-statement send-ext-block {
from {
route-filter 55.55.5.0/27 exact accept;
}
}
Veiily that all the static ioutes aie active on the ioutei in Loth the iouting instance tiust
anu the main ioute taLle. The 55.55.5/27 static ioute in the main instance was auto-
matically cieateu uue to the NAT iule with a veiy low pieleience ol 1, which points to
the outsiue inteilace loi ietuin NAT tiallic. The uelault ioute was manually cieateu
uuiing the VR conliguiation:
lab@PBR# run show route protocol static
inet.0: 21 destinations, 26 routes (20 active, 0 holddown, 5 hidden)
678 | Appendix A:Junos Layer 3 Services
+ = Active Route, - = Last Active, * = Both
55.55.5.0/27 *[Static/1] 00:14:38
> via sp-0/0/0.2
trust.inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 00:19:31
> via sp-0/0/0.1
Also, veiily that all the inteinal ioutes aie ieceiveu via OSPF in the VR`s ioute taLle,
trust.inet.0:
[edit]
lab@PBR# run show route table trust
trust.inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 00:19:59
> via sp-0/0/0.1
10.10.8.0/27 *[OSPF/10] 00:13:32, metric 67
> to 10.20.130.1 via ge-0/0/0.1241
10.10.10.0/30 *[OSPF/10] 00:19:50, metric 66
> to 10.20.130.1 via ge-0/0/0.1241
10.10.11.0/24 *[OSPF/10] 00:19:50, metric 2
> to 10.20.130.1 via ge-0/0/0.1241
10.10.12.1/32 *[OSPF/10] 00:13:32, metric 2
> to 10.20.130.1 via ge-0/0/0.1241
10.10.12.2/32 *[OSPF/10] 00:13:32, metric 66
> to 10.20.130.1 via ge-0/0/0.1241
10.10.12.3/32 *[OSPF/10] 00:19:50, metric 1
> to 10.20.130.1 via ge-0/0/0.1241
10.20.128.4/32 *[OSPF/10] 00:13:32, metric 67
> to 10.20.130.1 via ge-0/0/0.1241
10.20.128.128/32 *[Direct/0] 00:19:59
> via lo0.1
10.20.129.0/24 *[OSPF/10] 00:13:32, metric 68
> to 10.20.130.1 via ge-0/0/0.1241
10.20.130.0/24 *[Direct/0] 00:19:59
> via ge-0/0/0.1241
10.20.130.2/32 *[Local/0] 00:19:59
Local via ge-0/0/0.1241
10.20.131.0/24 *[OSPF/10] 00:13:32, metric 67
> to 10.20.130.1 via ge-0/0/0.1241
10.30.1.1/32 *[OSPF/10] 00:13:32, metric 67
> to 10.20.130.1 via ge-0/0/0.1241
64.8.12.6/32 *[OSPF/150] 00:13:32, metric 0, tag 0
> to 10.20.130.1 via ge-0/0/0.1241
224.0.0.5/32 *[OSPF/10] 00:20:00, metric 1
MultiRecv
Now veiily that the OSPF netwoik is iunning coiiectly in the VR. Don`t loiget the
instance switch!
NAT | 679
[edit]
lab@PBR# run show ospf database instance trust
OSPF link state database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.10.12.1 10.10.12.1 0x8000016d 817 0x22 0x30df 48
Router 10.10.12.2 10.10.12.2 0x8000022a 817 0x22 0x7889 84
Router 10.10.12.3 10.10.12.3 0x8000017b 739 0x22 0x3575 84
Router 10.20.128.4 10.20.128.4 0x800004fc 818 0x22 0xa79b 60
Router *10.20.128.128 10.20.128.128 0x8000000c 160 0x22 0x5f14 48
Router 10.30.1.1 10.30.1.1 0x80000227 818 0x22 0x4ef0 48
Network 10.10.8.1 10.10.12.2 0x800000a1 817 0x22 0x45e7 32
Network 10.10.11.1 10.10.12.3 0x80000003 816 0x22 0xbef1 32
Network *10.20.130.2 10.20.128.128 0x80000004 9 0x22 0x1320 32
Network 10.20.131.2 10.20.128.4 0x8000020b 818 0x22 0xf32f 32
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *0.0.0.0 10.20.128.128 0x80000001 562 0x22 0x7f14 36
Extern 64.8.12.6 10.30.1.1 0x8000009b 818 0x22 0xf84 36
Tiallic is sent to the Inteinet anu veiilieu Ly looking at the show services stateful-
firewall flows output. Vhen a NAT seivice set is applieu, a statelul liiewall that ac-
cepts all tiallic is actually also applieu. Notice that the souice is Leing tianslateu liom
10.20.120.1 to 55.55.5.1 with no poit tianslation, anu the ietuin llow is automatically
cieateu. Also, the state is watch Lecause an ICMP Application Layei Gateway (ALG) is
Leing useu:
[edit]
lab@PBR# run show services stateful-firewall flows
Interface: sp-0/0/0, Service set: Trust-Untrust
Flow State Dir Frm count
ICMP 128.3.3.27:62239 -> 55.55.5.1 Watch O 188
NAT dest 55.55.5.1:62239 -> 10.20.130.1:0
ICMP 10.20.130.1:62239 -> 128.3.3.27 Watch I 196
NAT source 10.20.130.1:62239 -> 55.55.5.1:62239
You also can view the ALG Ly looking at the output ol the conversations commanu,
which is ]unos teiminology loi the tiansit anu ieceive llow:
lab@PBR# run show services stateful-firewall conversations extensive
Interface: sp-0/0/0, Service set: Trust-Untrust
Conversation: ALG protocol: icmp
Number of initiators: 1, Number of responders: 1
Flow State Dir Frm count
ICMP 10.20.130.1:62239 -> 128.3.3.27 Watch I 211
NAT source 10.20.130.1:62239 -> 55.55.5.1:62239
Byte count: 17724
Flow role: Master, Timeout: 30, Protocol detail: echo request
ICMP 128.3.3.27:62239 -> 55.55.5.1 Watch O 203
NAT dest 55.55.5.1:62239 -> 10.20.130.1:0
Byte count: 17052
Flow role: Responder, Timeout: 30, Protocol detail: echo reply
680 | Appendix A:Junos Layer 3 Services
The NAT pool is also examineu, anu although a /27 is conliguieu in the pool, only 30
auuiesses have Leen allocateu, excluuing the 55.55.5.0 anu 55.55.5.31 auuiesses:
lab@PBR# run show services nat pool
Interface: sp-0/0/0, Service set: Trust-Untrust
NAT pool Type Address Port Ports used
ext-block dynamic 55.55.5.1-55.55.5.30
Source NAT with PAT
Now we will auu poit tianslation; ielei Lack to Souice NAT with No
PAT on page 676 to see the VR, iules, seivice setup, anu so on. To enaLle PAT, simply
auu the port commanu in the auuiess pool uelinition:
[edit]
lab@PBR# set services nat pool ext-block port automatic
Altei the change is committeu, it still appeais that the llows aie not peiloiming any
poit tianslation:
[edit]
lab@PBR# run show services stateful-firewall flows
Interface: sp-0/0/0, Service set: Trust-Untrust
Flow State Dir Frm count
ICMP 128.3.3.27:62239 -> 55.55.5.1 Watch O 188
NAT dest 55.55.5.1:62239 -> 10.20.130.1:0
ICMP 10.20.130.1:62239 -> 128.3.3.27 Watch I 196
NAT source 10.20.130.1:62239 -> 55.55.5.1:62239
You can veiily this Ly looking at the NAT pool anu seeing that no poits have Leen
assigneu:
lab@PBR# run show services nat pool
Interface: sp-0/0/0, Service set: Trust-Untrust
NAT pool Type Address Port Ports used
ext-block dynamic 55.55.5.1-55.55.5.30
The poit tianslation is not occuiiing Lecause the change was uone on the lly anu the
session hau not timeu out. To cieate a new session in the llow taLle, you must liist cleai
the llows:
lab@PBR# run clear services stateful-firewall flows
Interface Service set Conv removed
sp-0/0/0 Trust-Untrust 1
Now the poit numLei is Leing changeu liom 62239 to 102+, as expecteu:
[edit services nat pool ext-block]
lab@PBR# run show services stateful-firewall flows
Interface: sp-0/0/0, Service set: Trust-Untrust
Flow State Dir Frm count
ICMP 128.3.3.27:1024 -> 55.55.5.1 Watch O 8
NAT dest 55.55.5.1:1024 -> 10.20.130.1:62239
ICMP 10.20.130.1:62239 -> 128.3.3.27 Watch I 8
NAT source 10.20.130.1:62239 -> 55.55.5.1:1024
NAT | 681
You can veiily this Ly viewing the poit iange alloweu (51265535), anu Ly the lact that
a single poit is shown to Le in use out ol the pool:
[edit services nat pool ext-block]
lab@PBR# run show services nat pool
Interface: sp-0/0/0, Service set: Trust-Untrust
NAT pool Type Address Port Ports used
ext-block dynamic 55.55.5.1-55.55.5.30 512-65535 1
Destination NAT
Anothei common application is to change the incoming puLlic IP auuiess to a piivate
IP auuiess insiue the netwoik. Olten, this is uone to open a paiticulai seivice liom the
VAN inteilace, lieguently ieleiieu to as a pinho|c loi its hopelully uiminutive access.
In this case stuuy, a custom application calleu s|ingbox is iunning ovei TCP anu is using
a poit iange ol +000+050. This will Le coming into puLlic IP auuiess 55.55.5.27 anu
will Le mappeu to inteinal auuiess 10.10.12.3. Destination NAT must always Le ol
type static, so the incoming puLlic auuiess iange must map to the outgoing piivate
auuiess iange.
Since a unigue application must Le useu loi this pinhole, liist you must ueline an
application that will latei Le ieleienceu in the NAT iule. This application is calleu
custom-app:
lab@PBR# show | find applications
applications {
application custom-app {
protocol tcp;
destination-port 4000-4050;
}
}
Cieate the NAT iule Ly ieleiencing the incoming puLlic uestination auuiess 55.55.5.27
anu the custom-app, anu Ly tianslating this auuiess to 10.10.12.3. Use a destination-
prefix insteau ol a destination-pool, as this is a single auuiess mapping. Since this is
a uestination NAT that is auueu to the pieviously cieateu next hop seivice set, specily
a uiiection ol output, Lecause tiallic will Le ieceiveu anu uiiecteu to the outsiue intei-
lace Ly the alieauy cieateu 55.55.5/27 static ioute:
[edit services nat]
lab@PBR# show | find rule
rule pin-hole {
match-direction output;
term 1 {
from {
destination-address {
55.55.5.27/32;
}
applications custom-app;
}
then {
682 | Appendix A:Junos Layer 3 Services
translated {
destination-prefix 10.10.12.3/32;
translation-type destination static;
}
}
}
}
}
Then auu the iule to the pieviously cieateu seivice set:
service-set Trust-Untrust {
nat-rules basic-source;
nat-rules pin-hole;
next-hop-service {
inside-service-interface sp-0/0/0.1;
outside-service-interface sp-0/0/0.2;
}
}
}
RememLei that you can comLine multiple iules into a iule set il uesiieu.
Tiallic is incoming to PBR`s VAN inteilace anu the uestination NAT is veiilieu. This
llow happens to have an incoming poit numLei ol +020, which uoes lall into the custom
application iange:
lab@PBR# run show services stateful-firewall conversations
Interface: sp-0/0/0, Service set: Trust-Untrust
Conversation: ALG protocol: tcp
Number of initiators: 1, Number of responders: 1
Flow State Dir Frm count
TCP 172.16.1.1:4216 -> 55.55.5.27:4020 Forward O 1
NAT dest 55.55.5.27:4020 -> 10.10.12.3:4020
TCP 10.10.12.3:4020 -> 172.16.1.1:4216 Forward I 1
NAT source 10.10.12.3:4020 -> 55.55.5.27:4020
NAT and the stateful firewall
By uelault, when NAT iules aie exclusively applieu in a seivice set, a statelul liiewall
is implicitly applieu. This uelault statelul liiewall matches on all tiallic with an action
ol accept anu is cieateu in both uiiections. Il a statelul-liiewall iule is cieateu latei anu
applieu to the seivice set, the uelault statelul-liiewall iules aie iemoveu. This means
that to allow loi NAT tiallic, you may neeu to cieate new statelul-liiewall iules il a
statelul-liiewall iule is latei applieu to the seivice set. In a simple example, a statelul-
liiewall iule is cieateu to allow all ]unos ALGs anu othei tiallic outLounu liom the
inteinal netwoik to the Inteinet:
NAT | 683
stateful-firewall {
rule allow-outbound {
match-direction input;
term 1 {
from {
application-sets junos-algs-outbound;
}
then {
accept;
}
}
term 2 {
then {
accept;
}
}
}
}
Apply this statelul-liiewall iule to the seivice set that alieauy contains the NAT iules:
service-set Trust-Untrust {
stateful-firewall-rules allow-outbound;
nat-rules basic-source;
nat-rules pin-hole;
next-hop-service {
inside-service-interface sp-0/0/0.1;
outside-service-interface sp-0/0/0.2;
}
}
Veiily the souice NAT anu that all woiks as expecteu since the statelul liiewall is al-
lowing all outLounu llows:
[edit]
lab@PBR# run show services stateful-firewall conversations
Interface: sp-0/0/0, Service set: Trust-Untrust
Conversation: ALG protocol: icmp
Number of initiators: 1, Number of responders: 1
Flow State Dir Frm count
ICMP 10.20.130.1:11552 -> 128.3.3.27 Watch I 31
NAT source 10.20.130.1:11552 -> 55.55.5.1:1024
ICMP 128.3.3.27:1024 -> 55.55.5.1 Watch O 31
NAT dest 55.55.5.1:1024 -> 10.20.130.1:11552
Note that when test tiallic is sent liom ISP ioutei Wheat to PBR loi incoming uestination
NAT, the tiallic is uioppeu Ly the newly applieu statelul liiewall that allows only out-
Lounu llows to Le initiateu, not inLounu llows:
lab@Wheat> telnet 55.55.5.27 port 4020
Trying 55.55.5.27...
lab@PBR# run show services stateful-firewall flows
Interface: sp-0/0/0, Service set: Trust-Untrust
684 | Appendix A:Junos Layer 3 Services
Flow State Dir Frm count
TCP 172.16.1.1:3469 -> 55.55.5.27:4020 Drop O 0
So, to allow incoming NAT piocessing to occui in the output inteilace, the packet must
Le alloweu thiough the statelul liiewall. The incoming seivice llow when multiple
seivice iules aie applieu is:
Statelul liiewallNAT
You cannot set this oiuei at this point, which means that the statelul liiewall must
match on the static NAT auuiess:
[edit service stateful-firewall]
lab@PBR# show | find rule allow-pin-hole
rule allow-pin-hole {
match-direction output;
term 1 {
from {
destination-address {
55.55.5.27/32;
}
}
then {
accept;
}
}
}
Apply the new iule to the seivice set:
lab@PBR# show services service-set Trust-Untrust
stateful-firewall-rules allow-outbound;
stateful-firewall-rules allow-pin-hole;
nat-rules basic-source;
nat-rules pin-hole;
next-hop-service {
inside-service-interface sp-0/0/0.1;
outside-service-interface sp-0/0/0.2;
}
Now uestination NAT woiks as expecteu, anu TV can sling aiounu the woilu with oui
special application:
lab@PBR# run show services stateful-firewall flows
Interface: sp-0/0/0, Service set: Trust-Untrust
Flow State Dir Frm count
TCP 10.10.12.3:4020 -> 172.16.1.1:1059 Forward I 1
NAT source 10.10.12.3:4020 -> 55.55.5.27:4020
TCP 172.16.1.1:1059 -> =55.55.5.27:4020 Forward O 1
NAT dest 55.55.5.27:4020 -> 10.10.12.3:4020
[edit]
NAT | 685
Since multiple statelul-liiewall iules aie applieu, this may Le anothei
place wheie a iule set coulu Le helplul:
service-set Trust-Untrust {
stateful-firewall-rule-sets in-out;
nat-rules basic-source;
nat-rules pin-hole;
next-hop-service {
inside-service-interface sp-0/0/0.1;
outside-service-interface sp-0/0/0.2;
}
}
rule-set in-out {
rule allow-outbound;
rule allow-pin-hole;
}
Twice NAT
Lastly, you can conliguie twice NAT on the ioutei, which involves changing the souice
IP auuiess loi outLounu llows anu the uestination auuiess loi inLounu llows (see
Figuie A-10). This is ieally no uilleient liom the scenaiios we`ve alieauy uiscusseu,
except that you must conliguie a souice anu a uestination auuiess, as well as a souice
pielix oi pool anu a uestination pielix oi pool. In the example that lollows, tiallic that
matches 10.5S.25+.2+ oi 10.5S.25+.35 will Le souice-NAT`u using a static pool calleu
src-pool.
Iigurc A-10. Twicc NAT cxanp|c
686 | Appendix A:Junos Layer 3 Services
Tiallic uestineu loi +1.+1.+1.+1/32 will Le uestination-NAT`u using a NAT pool calleu
dst_pool:
[edit services nat]]
lab@Bock# show
rule twice-nat {
match-direction input;
term my-term1 {
from {
destination-address {
41.41.41.41/32;
}
source-address-range {
low 10.58.254.34 high 10.58.254.35;
}
}
then {
translated {
source-pool src-pool;
destination-pool dst_pool;
translation-type source static destination static;
}
}
}
}
At the time ol this wiiting, you cannot conliguie ALGs when twice NAT
is conliguieu.
Summary of NAT
NAT has Lecome a common language anu ieguiiement loi netwoiks in eveiy lacet ol
the woilu uue to the exhaustion ol IPv+ auuiesses as well as a way to piotect inteinal
iesouices. Vaiious types ol NAT aie uelineu, incluuing souice IP tianslation, uestina-
tion IP tianslation, anu poit tianslation. Vhich methou you choose shoulu uepenu on
a vaiiety ol lactois, such as the numLei ol puLlic IPs that aie assigneu to the netwoik,
the numLei ol incoming Inteinet connections alloweu, anu the level ol invisiLility ie-
guiieu. In lact, you can comLine many ol these concepts into a newei stanuaiu calleu
twice NAT.
IDS
]unos seivices suppoit a limiteu set ol IDSs to help uetect attacks such as poit scanning
anu anomalies in tiallic patteins. It also suppoits some attack pievention Ly limiting
the numLei ol llows, sessions, anu iates. In auuition, it piotects against SYN attacks
Ly implementing a SYN cookie mechanism. Since the intiusion uetection anu
IDS | 687
pievention (IDP) seivice uoes not suppoit highei-layei application signatuies, we must
examine anothei solution.
The IDP solution is ieally moie ol a monitoiing tool than an actual pievention tool. So,
how uoes ]unipei make the IDP claim? One iesponse is that piotection against a SYN
attack can Le conliguieu. To pievent a SYN attack, the ioutei will opeiate as a type ol
SYN pioxy anu will utilize cookie values. Essentially, when this leatuie is tuineu on,
the ioutei will iesponu to the initial SYN packet with a SYN-ACK packet that contains
a unigue cookie value in the seguence numLei lielu. Il the initiatoi iesponus with the
same cookie in the seguence lielu, the TCP llow is accepteu; il the iesponuei uoes not
iesponu oi il it iesponus with the wiong cookie, the llow is uioppeu. To kick oll this
uelense, we must conliguie a SYN cookie thiesholu.
To enaLle the SYN cookie uelense, an IDS iule action must contain a thiesholu that
inuicates when the leatuie shoulu Le enaLleu anu an MSS value to avoiu having the
ioutei manage segmenteu liagments when acting as a SYN pioxy:
[edit]
lab@PBR# set services ids rule simple-ids term 1 then syn-cookie ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these
groups
mss MSS value for TCP delayed binding (128..8192)
threshold Threshold above which SYN cookies are enabled
[edit]
You woulu then apply this iule to a seivice set as you woulu any othei seivice pieviously
uiscusseu.
Since IDP anu statelul liiewalls aie piocesseu in paiallel, you shoulu
conliguie a statelul-liiewall iule alongsiue the IDS iule. Il you loiget a
iule, the uelault statelul liiewall ol allow all will Le useu.
Along with SYN cookie piotection, the IDS is useu to uetect attacks anu gathei inloi-
mation to cieate iules to stop these attacks. Vhen looking at the possiLle IDS iule
actions loi uetection ol attacks, you can:
Set up thiesholus to monitoi ceitain souices, uestinations, oi souice anu uestina-
tion paiis
Foice goou entiies to the IDS taLle loi tiacking puiposes
Log packets when they hit a ceitain thiesholu:
lab@PBR# set services ids rule all term 1 then ?
Possible completions:
> aggregation Define aggregation parameters
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
688 | Appendix A:Junos Layer 3 Services
force-entry Force entries in IDS tables for matching traffic
ignore-entry Ignore IDS events for matching traffic
> logging Define system logging parameters
> session-limit Define IDS session limit parameters
> syn-cookie Define SYN cookie parameters
Foi example, heie is a iule that logs packets as soon as an event happens (thiesholu 1),
enaLles SYN cookie piotection at live SYN packets pei seconu, anu loices all entiies
to Le iecoiueu:
[edit]
lab@PBR# show services
ids {
rule all {
match-direction input;
term 1 {
then {
force-entry;
logging {
threshold 1;
syslog;
}
syn-cookie {
threshold 5;
mss 1500;
}
}
}
}
}
service-set Trust-Untrust {
ids-rules all;
next-hop-service {
inside-service-interface sp-0/0/0.1;
outside-service-interface sp-0/0/0.2;
}
}
The IDS taLles can then Le matcheu Ly souice, uestination, oi paii:
[edit]
lab@PBR# run show services ids ?
Possible completions:
destination-table Show attack destination address table
pair-table Show attack source and destination address pair table
source-table Show attack source address table
Heie is some output (not liom this example) that shows some ol the uilleient types ol
anomalies that can Le tiackeu:
user@underdogs> show services ids destination-table extensive
Interface: sp-1/3/0, Service set: null-sfw
Sorting order: Packets
Source address Dest address Time Flags Application
any -> 10.58.255.146 35m52s SYN cookie
IDS | 689
Bytes: 34.0 m, Packets: 798.0 k, Flows: 266.0 k, Anomalies: 2251.0 k
Anomalies Count Rate(eps) Elapsed
First packet of TCP session not SYN 160.0 k 0 14s
TCP source or destination port zero 634.0 k 154.6 3m37s
UDP source or destination port zero 633.0 k 170.0 3m37s
ICMP header length check failed 2875 0.9 3m37s
IP fragment assembly timeout 820.0 k 12.8 3m18s
UDP header length check failed 385 0.5 3m53s
TCP header length check failed 383 0.5 3m53s
Total IDS table entries:
87
Total failed IDS table entry insertions
0
Total number of
Combining Services
Vhen comLining multiple seivices, the geneial path must Le iememLeieu in the loi-
waiu anu ieveise uiiections (see Figuie A-11). This is especially tiue when NAT is
ueployeu to ueteimine whethei the pie- oi post-NAT auuiess shoulu Le useu to match
a iule. In the loiwaiu path liom a LAN inteilace to a VAN inteilace, IDS anu statelul
liiewall aie peiloimeu liist, then NAT, anu linally IPSec. This means that the statelul
liiewall must match on a pie-NAT auuiess, wheieas the IPSec tunnel woulu match on
the post-NAT auuiess.
Iigurc A-11. Scrvicc path
In the ietuin path, the IPSec packet will Le piocesseu liist, then NAT, anu linally the
statelul liiewall. This still allows IPSec to match a puLlic auuiess anu the statelul liie-
wall to match on a piivate auuiess.
Eveiything Lecomes much moie complicateu when IPSec ovei GRE is implementeu in
the ioutei with othei seivices tuineu on. This is Lecause ]unos tieats GRE packets in
a veiy peculiai lashion altei GRE encapsulation. Altei a packet is encapsulateu in a
GRE packet, it is maikeu with an input inteilace as the next hop outgoing inteilace.
690 | Appendix A:Junos Layer 3 Services
This causes GRE packets to Le Llockeu il any input lilteis oi input seivices aie alloweu
that uo not allow loi this seivice.
In Figuie A-12, an IP packet comes into the ge-1/0/0.42 inteilace anu a ioute lookup
is peiloimeu that uiiects the packet into a GRE tunnel, which has an egiess inteilace
ol se-1/0/0. Altei the GRE encapsulation, the input inteilace changes to the output
inteilace. So, at the linal stage, any statelul-liiewall piocessing oi stateless lilteis aie
going to see the packet coming into inteilace se-1/0/0 anu out ol inteilace se-1/0/0,
which is unexpecteu!
Iigurc A-12. GRE proccssing with scrviccs
Stateful Firewall, NAT, and IPSec over GRE Together
To illustiate the unigueness ol GRE encapsulation, we will again examine the IPSec
ovei GRE tunnel. This is the same tunnel we conliguieu in IPSec ovei
GRE on page 66S. ]ust to iecap, heie is the complete IPSec ovei GRE conliguiation
iule set that is applieu as an inteilace-style seivice set:
service-set ipsec-gre {
interface-service {
service-interface sp-0/0/0.0;
}
ipsec-vpn-options {
local-gateway 172.16.1.2;
}
ipsec-vpn-rules map-gre;
}
ipsec-vpn {
rule map-gre {
term 1 {
from {
source-address {
172.16.1.2/32;
}
destination-address {
128.3.3.4/32;
}
}
then {
Combining Services | 691
remote-gateway 128.3.3.4;
dynamic {
ike-policy main_ike;
ipsec-policy ipsecgre;
}
}
}
match-direction output;
}
ipsec {
proposal cisco-interop {
protocol esp;
authentication-algorithm hmac-md5-96;
encryption-algorithm des-cbc;
}
policy ipsecgre {
perfect-forward-secrecy {
keys group1;
}
proposals cisco-interop;
}
}
ike {
proposal cisco-interop-ike {
authentication-method pre-shared-keys;
dh-group group1;
authentication-algorithm md5;
encryption-algorithm des-cbc;
}
policy main_ike {
proposals cisco-interop-ike;
pre-shared-key ascii-text "$9$JhUi.QF/0BEP5BEcyW8ZUjHP5z
36AuO"; ## SECRET-DATA
}
}
traceoptions {
flag ike;
}
establish-tunnels immediately;
}
Statelul-liiewall anu NAT iules aie to Le conliguieu liom the LAN siue ol ioutei PBR
to the VAN siue ol the ioutei loi all inteinally souiceu tiallic. Since IPSec ieguiies its
own seivice set, a new seivice set calleu trust-untrust will Le cieateu that ieleiences
the same seivice inteilace anu a single NAT anu statelul-liiewall iule:
[edit services]
service-set trust-untrust {
stateful-firewall-rules allow-outbound;
nat-rules basic-source;
interface-service {
service-interface sp-0/0/0.0;
}
}
692 | Appendix A:Junos Layer 3 Services
A statelul-liiewall iule is cieateu to match on tiallic that is souiceu liom the inteinal
netwoik. Notice that only ALGs aie alloweu liom the inteinal suLnet, wheieas the
seconu teim contains no conuition. The seconu teim uoes not contain this conuition
in oiuei to allow some management tiallic anu BGP tiallic to llow Letween the
172.16.1/2+ netwoik Letween PBR anu Wheat:
stateful-firewall {
rule allow-outbound {
match-direction output;
term alg {
from {
source-address {
10.0.0.0/8;
}
application-sets junos-algs-outbound;
}
then {
accept;
}
}
term other {
then {
accept;
}
}
}
}
Also, a souice NAT iule is applieu loi all inteinal tiallic using poit tianslation:
nat {
pool ext-block {
address 55.55.5.0/27;
port automatic;
}
rule basic-source {
match-direction output;
term 1 {
from {
source-address {
10.0.0.0/8;
}
}
then {
translated {
source-pool ext-block;
translation-type source dynamic;
}
}
}
}
}
The new seivice set is applieu to the VAN inteilace on PBR. Take a look at the pievious
example to view the seivice lilteis match-vpn-input anu match-vpn-output:
Combining Services | 693
[edit interfaces ge-0/0/0 unit 412]
lab@PBR# show
description PBR-to-Wheat;
vlan-id 412;
family inet {
service {
input {
service-set ipsec-gre service-filter match-vpn-input;
service-set trust-untrust;
}
output {
service-set ipsec-gre service-filter match-vpn-output;
service-set trust-untrust;
}
}
address 172.16.1.2/24;
Altei the conliguiation is committeu, oLseive the llows thiough the statelul liiewall.
GRE packets aie Leing uioppeu that weie uestineu to 12S.3.3.+. Notice that the uiiec-
tion is input, since altei GRE encapsulation, the packet appeais to Le coming into the
outgoing VAN inteilace. Because the statelul-liiewall iules aie now wiitten to allow
incoming GRE packets, the packets aie uioppeu:
[edit services stateful-firewall rule allow-outbound]
lab@PBR# run show services stateful-firewall flows
Interface: sp-0/0/0, Service set: trust-untrust
Flow State Dir Frm count
TCP 172.16.1.1:179 -> 172.16.1.2:2439 Forward I 11
TCP 172.16.1.2:2439 -> 172.16.1.1:179 Forward O 12
GRE 172.16.1.2:0 -> 128.3.3.4:0 Drop I 0
Since the packets aie Leing uioppeu Ly the statelul liiewall, they aie not even ieaching
the IPSec tunnel. You can see this Ly oLseiving the 0 packet counts on the IPSec
statistics:
[edit services service-set trust-untrust]
lab@PBR# run show services ipsec-vpn ipsec statistics
PIC: sp-0/0/0, Service set: ipsec-gre
ESP Statistics:
Encrypted bytes: 0
Decrypted bytes: 0
Encrypted packets: 0
Decrypted packets: 0
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
694 | Appendix A:Junos Layer 3 Services
Ve must now cieate a seivice liltei to allow the GRE packets to Lypass the statelul
liiewall anu Le encapsulateu into the IPSec packet. This seivice liltei must match on
the souice anu uestination IP auuiesses ol the tunnel, as seen liom the uiscaiu llows.
Don`t loiget to seivice all othei packets Lesiues the GRE packets:
[edit firewall]
lab@PBR# show | find allow-gre
service-filter allow-gre {
term gre {
from {
source-address {
172.16.1.2/32;
}
destination-address {
128.3.3.4/32;
}
}
then skip;
}
term all {
then service;
}
}
}
Apply the seivice liltei as an input seivice liltei loi the statelul liiewall containing the
seivice set:
[edit interfaces ge-0/0/0 unit 412]
lab@PBR# set family inet input service-set trust-untrust service-
filter allow-gre
[edit interfaces ge-0/0/0 unit 412]
lab@PBR# show
description PBR-to-Wheat;
vlan-id 412;
family inet {
service {
input {
service-set ipsec-gre service-filter match-vpn-input;
service-set trust-untrust service-filter allow-gre;
}
output {
service-set ipsec-gre service-filter match-vpn-output;
service-set trust-untrust;
}
}
address 172.16.1.2/24;
}
Altei the liltei has Leen applieu, the seivice liltei packets aie enciypteu anu ueciypteu
in the IPSec tunnel:
lab@PBR> show services ipsec-vpn ipsec statistics
Combining Services | 695
PIC: sp-0/0/0, Service set: ipsec-gre
ESP Statistics:
Encrypted bytes: 51408
Decrypted bytes: 51408
Encrypted packets: 459
Decrypted packets: 459
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
In auuition, othei inteinal llows aie souice-NAT`u as expecteu:
lab@PBR> show services stateful-firewall conversations
Interface: sp-0/0/0, Service set: trust-untrust
Conversation: ALG protocol: icmp
Number of initiators: 1, Number of responders: 1
Flow State Dir Frm count
IC 10.20.130.1:30242 -> 77.7.7.7 Watch O 3
NAT source 10.20.130.1:30242 -> 55.55.5.1:1033
ICMP 77.7.7.7:1033 -> 55.55.5.1 Watch I 3
NAT dest 55.55.5.1:1033 -> 10.20.130.1:30242
Conversation: ALG protocol: tcp
Number of initiators: 1, Number of responders: 1
Flow State Dir Frm count
TCP 172.16.1.2:1075 -> 172.16.1.1:179 Forward O 77
TCP 172.16.1.1:179 -> 172.16.1.2:1075 Forward I 76
The Life of a Packet
Vhen you`ve ueciueu which seivices you neeu in youi netwoik, implementing them
can seem like a uaunting task. Vhich conliguiation uo you apply liist? Vhich auuiesses
uo you apply to a given seivice when applying a iule? How aLout il you have a class ol
seivice (CoS) applieu? Vheie uo packet lilteis lit into the packet llow?
Figuies A-13 anu A-1+ shoulu help you soit thiough this mysteiy anu ueciue wheie
conliguiation piocesses occui. These uiagiams aie not meant to iepiesent eveiy pos-
siLle scenaiio, Lut iathei to give you a geneial leel loi the complex piocessing that coulu
Le involveu. The exact piocessing will uepenu on whethei a next hop oi an inteilace-
style seivice set is applieu (loi moie on CoS concepts, ielei to Chaptei 10).
696 | Appendix A:Junos Layer 3 Services
The steps outlineu in Figuie A-13 aie as lollows:
1. The packet enteis the incoming inteilace.
2. The packet is classilieu Ly a Lehavioi aggiegate (BA) classiliei.
3. The packet is piocesseu Ly an input liltei anu policei (anu may Le ieclassilieu).
+. The packet enteis a seivice liltei, anu it is eithei seiviceu oi skippeu; il it is skippeu,
jump to step 7.
5. The input seivice is peiloimeu.
6. A post-seivice liltei is applieu.
7. The ioute lookup occuis.
S. Il the iesult ol the ioute lookup is a GRE packet, go to step 9; il not, senu on loi
output piocessing.
9. De-encapsulate the GRE packet anu go Lack to step 1.
Altei the packet is uone with the input piocessing, it moves towaiu output piocessing
(see Figuie A-1+).
Iigurc A-13. |nconing pac|ct proccssing
The Life of a Packet | 697
Iigurc A-11. Outbound pac|ct proccssing
The steps outlineu in Figuie A-1+ aie as lollows:
1. The packet is ieceiveu liom input piocessing anu enteis the output policei oi liltei.
2. The packet then goes thiough an output seivice liltei to ueteimine whethei the
packet will Le maikeu loi seivice. Il the packet matches the seivice liltei, the output
inteilace is set to the seivice inteilace; il theie is no match, the output inteilace is
the outgoing physical inteilace.
3. The packet is sent to an output scheuulei.
+. A wiite ol the Type ol Seivice (ToS) Lyte coulu occui. Il the output inteilace is a
seivice inteilace, go Lack to step 3; otheiwise, go to step 5.
5. Il the packet neeus to Le GRE-encapsulateu, go to step 6; otheiwise, go to step 7.
6. GRE encapsulation occuis, anu the packet is sent Lack to the input piocessing
stage, wheie it is sent to step 1 ol Figuie A-13 (input lilteis); altei the GRE encap-
sulation, the input inteilace is the next hop outgoing inteilace ol the GRE tunnel.
7. The packet is sent out the physical output inteilace.
Considerations Regarding Order of Operations
The packet piocessing oiuei just uiscusseu can Le piactically applieu when uesigning
the Lianch ollice connectivity loi youi netwoik (see Figuie A-15). Il connectivity is
pioviueu via IPSec VPNs anu CoS is applieu, wheie shoulu the packet Le classilieu? Il
an IPSec packet enteis a ioutei, the packet can Le classilieu Ly setting the CoS value in
the outei IP heauei using a BA classiliei. Howevei, altei the packet is ue-encapsulateu,
it enteis the input lilteiing stage anu is not sent thiough anothei BA classiliei. That
means that il packet classilication is ieguiieu on the ue-encapsulateu packet, you must
use a multilielu classiliei (a liiewall liltei).
698 | Appendix A:Junos Layer 3 Services
Iigurc A-15. Branch ojjicc conncctivity
In compaiison, il iemote connectivity is pioviueu Ly GRE tunnels, similai to IPSec
tunnels, the incoming GRE packet coulu Le classilieu using a BA classiliei. The uillei-
ence, howevei, is that once the GRE packet is ue-encapsulateu, it senus the innei packet
thiough anothei BA classiliei. This means you shoulu apply the same classiliei to the
incoming inteilace anu the gr- inteilace to avoiu ieclassilication. Also, uon`t loiget that
when a GRE packet is encapsulateu, it is iepiocesseu thiough all input lilteis anu seiv-
ices on the output inteilace.
The possiLle scenaiios coulu lill an entiie Look, so Le suie to consult Figuies A-13 anu
A-1+ loi application to youi netwoik.
Conclusion
IP netwoiks have changeu uiastically since they weie liist ueployeu 25 yeais ago, when
auuiesses weie plentilul anu simple lilteis sulliceu. In touay`s mouein uata netwoiks,
the concepts ol yesteiyeai won`t lloat loi long. Packet lilteis will always have theii place,
Lut without tiacking state, they will always have limitations; thus, the neeu loi statelul
liiewalls. Vith IPv+ exhaustion coming to liuition, NAT has taken a liont seat in net-
woik uesign anu is now almost a ieguiiement.
You can ueploy these seivices inuiviuually oi as a comLineu secuiity uesign. Vhen
comLining these seivices, Le suie to veiily each step along the way to avoiu a Lioken
conliguiation that is a Leai to tiouLleshoot.
Conclusion | 699
Exam Topics
Ve examineu the lollowing Enteipiise Exam Topics in this appenuix:
Conliguie anu apply an inteilace-style seivice set.
Conliguie a next hopstyle seivice set.
Iuentily the match uiiection given a netwoik uiagiam.
Unueistanu anu implement vaiious types ol seivice sets.
DesciiLe NAT anu PAT.
Conliguie a statelul liiewall via the CLI.
Monitoi a statelul liiewall.
Conliguie NAT anu PAT via the CLI.
Monitoi NAT anu PAT via the CLI.
Explain IPSec VPN piocessing on M-seiies anu ]-seiies iouteis.
Conliguie an IPSec VPN via the CLI.
Conliguie a ioute-Laseu GRE tunnel (ovei IPSec) via the CLI.
Monitoi IPSec VPNs.
IPSec tunnels as Lackup links.
Routing ovei an IPSec oi GRE tunnel.
Appendix Review Questions
1. Vhy aie VRs the pieleiieu implementation choice when ueploying next hopstyle
seivice sets? (Choose two.)
A. Auueu secuiity Lenelits
B. Moie leatuies can Le implementeu
C. Simplicity in conliguiation
D. Automatic iules
2. Vhich match uiiection shoulu Le specilieu when cieating an IPSec tunnel?
A. De-encapsulation uiiection
B. Both uiiections
C. Encapsulation uiiection
D. No uiiection
3. Tiue oi False: A single pioposal can Le applieu to an IPSec tunnel.
+. Vhich type ol seivice set woulu allow loi OSPF iouting ovei an IPSec tunnel?
A. Next hop
B. Inteilace
700 | Appendix A:Junos Layer 3 Services
D
o
C. Viitual ioutei
D. Route set
5. Altei an IP packet is encapsulateu Ly a GRE heauei, what is the incoming inteilace
ol the packet set to?
A. service interface
B. gre interface
C. outgoing interface
D. loopback interface
6. Vhich type ol NAT woulu Le useu to hiue all local PCs` auuiesses as they connect
to the Inteinet?
A. Destination
B. Hall-Cone
C. Twice NAT
D. Souice NAT
7. The lollowing souice NAT iule is applieu to a next hop seivice set Lut uoesn`t seem
to Le woiking:
rule basic-source {
match-direction output;
term 1 {
then {
translated {
source-pool ext-block;
translation-type source dynamic;
}
}
}
}
}
Vhat is the possiLle issue?
A. Missing a from statement
B. Can`t use uynamic tianslation loi souice NAT
C. The match uiiection is incoiiect
D. Missing the accept action
S. Tiue oi False: IPSec VPNs must have theii own seivice set.
9. Il packets neeu to Le skippeu in an inteilace-style seivice set, what shoulu Le
conliguieu?
A. A seivice iule allowing tiallic to Le skippeu
B. A post-seivice liltei allowing tiallic to Le skippeu
C. A seivice liltei allowing tiallic to Le skippeu
D. A liiewall liltei allowing tiallic to Le skippeu
Appendix Review Questions | 701
10. Vhich NAT type is not suppoiteu on a ]unipei ioutei?
A. Dynamic souice
B. Static souice
C. Dynamic uestination
D. Static uestination
11. Vhat aie the auvantages ol using a NAT pool? (Choose two.)
A. Can ieuse pool in othei iules
B. Can implement uiscontinuous auuiesses
C. Doesn`t have to ieleience in a iule
D. Can enaLle poit tianslation
12. Vhy might theie not Le an active IKE SA loi a conliguieu anu opeiational VPN?
A. SA is no longei neeueu
B. VPN has yet to time out
C. IKE SA was nevei estaLlisheu
D. GRE tunnel was useu insteau
Appendix Review Answers
1. Answei: A, C. VRs auu a secuiity Lenelit ovei othei solutions Lecause the inteilaces
anu ioute taLles aie sepaiateu liom the main taLle. Also, VRs avoiu the complexity
ol iiL-gioups that plague othei solutions.
2. Answei: C. The uiiection that encapsulates the packet into the IPSec tunnel shoulu
Le useu. In an inteilace-style seivice set, this is noimally set to output wheieas a
next hop seivice set usually uses input.
3. Answei: False. You can apply multiple pioposals to the IPSec tunnel; only one
pioposal has to match on each siue loi tunnel estaLlishment.
+. Answei: A. You must use a next hopstyle seivice set to suppoit iouting piotocols.
5. Answei: C. Stiangely enough, altei a packet gets GRE encapsulation, the incoming
inteilace is set to the next hop outgoing inteilace. This causes the GRE packet to
Le suLject to input lilteis anu seivices on the outgoing inteilace.
6. Answei: D. Il a PC wants to Le hiuuen liom the outsiue woilu, you shoulu ueploy
souice NAT. This changes the piivate souice IP to one oi moie puLlic IP
auuiesses.
7. Answei: C. One ol the most common conliguiation eiiois when making seivice
iules is not specilying the coiiect uiiection, especially when using next hopstyle
seivice sets, anu match uiiections olten seem Lackwaiu when compaieu to
inteilace-style seivice sets. RememLei that tiallic mappeu to the insiue inteilace is
input tiallic anu tiallic mappeu to the outsiue inteilace is output tiallic.
702 | Appendix A:Junos Layer 3 Services
S. Answei: Tiue. At the time ol this wiiting, IPSec VPNs aie always a unigue seivice
set, anu no othei seivice iules can Le comLineu in the set. Il you neeu to implement
othei seivices on top ol IPSec, they must have theii own unigue seivice set.
9. Answei: C. Seivice lilteis allow loi some tiallic to Le skippeu thiough a seivice set.
They also allow ceitain seivices to Le selecteu.
10. Answei: C. At the time ol this wiiting, uynamic uestination NAT is not suppoiteu.
All uestination NAT must Le statically mappeu to the same IP auuiess.
11. Answei: A, D. NAT pools pioviue gieatei scalaLility, as they can Le ieuseu in
multiple teims anu in multiple iules. Also, a pool is ieguiieu il poit tianslation
neeus to Le enaLleu.
12. Answei: A. The IKE SA is neeueu only uuiing the initial tunnel estaLlishment to
negotiate the IPSec tunnel paiameteis. Altei the IPSec tunnel is estaLlisheu, the
IKE SA will time out anu will ieestaLlish only on an as-neeueu Lasis.
Appendix Review Answers | 703
APPENDIX B
Upgrading Junos
This appenuix ieviews a numLei ol options loi upgiauing the ]unos opeiating system
on a ]unipei Netwoiks ioutei.
Migrating to a Newer Version of Junos
Fiom ]unos 9.3 loiwaiu, the compact llash ieguiies a minimum ol 512 MB, anu liom
]unos 9.0, M-seiies uevices ieguiie 1 GB llash. Not having enough liee compact llash
space availaLle to peiloim an upgiaue is common, especially on iouteis that have laige
logs, tiace liles, oi olu soltwaie packages lying aLout in useis` home uiiectoiies. The
migiation guiue pioviues uetaileu instiuctions on how to liee up compact llash space
to enhance the chances ol Leing aLle to upgiaue to ]unos on systems with 256 MB
compact llash chips. The instiuctions have you uelete vaiious tempoiaiy anu unneeueu
liles using comLinations ol CLI anu ioot shell moue commanus, some ol which aie
uemonstiateu on the lollowing pages.
Free Up Space
The limiteu compact llash stoiage space, comLineu with the lack ol a haiu uiive loi
stoiing images that aie Leing unpackeu loi installation, can cieate pioLlems when you
attempt to upgiaue oi uowngiaue ]unos veisions on any ]unipei ioutei. The lollowing
steps aie geneial appioaches to lieeing up compact llash space. You will neeu ioot
access to uelete any liles that aie owneu Ly ioot.
Fiist, we use the CLI cleanup utility to iiu ouiselves ol the low-hanging liuit:
peter@propane> request system storage cleanup
List of files to delete:
Size Date Name
11B Apr 17 07:41 /cf/var/jail/tmp/alarmd.ts
2054B Apr 17 07:58 /cf/var/log/interactive-commands.0.gz
28.1K Apr 17 07:58 /cf/var/log/messages.0.gz
705
4462B Apr 17 07:41 /cf/var/tmp/cleanup-pkgs.log
0B Apr 17 07:41 /cf/var/tmp/eedebug_bin_file
34B Apr 17 07:41 /cf/var/tmp/gksdchk.log
124.0K Mar 2 09:22 /cf/var/tmp/gres-tp/env.dat
0B Mar 2 09:24 /cf/var/tmp/gres-tp/lock
4B Apr 17 07:41 /cf/var/tmp/idp_license_info
76B Apr 17 07:41 /cf/var/tmp/krt_gencfg_filter.txt
4984B Mar 2 08:51 /cf/var/tmp/sampled.pkts
0B Mar 2 09:24 /cf/var/tmp/spu_kmd_init
Delete these files ? [yes,no] (no) yes
Next, uelete the Lackup soltwaie package, il piesent. This package is useu altei an
upgiaue to ieveit Lack to the pievious veision using a request system software roll
back commanu. The iollLack image is no longei neeueu, as the cuiient soltwaie envi-
ionment is Leing upgiaueu:
peter@propane> request system software delete-backup
Delete backup system software package [yes,no] (no) yes
peter@propane>
An alteinative is to use a sciipt that ]unipei cieateu loi the puipose ol lieeing up space
on the compact llash caiu. This sciipt, which is loaueu on the ioutei anu iun, has the
same outcome as iunning the commanus shown pieviously. The instiuctions loi using
the sciipt aie as lollows:
1. Downloau the upgradc-hc|pcr sciipt liom http://|b.junipcr.nct/KB11201 to /root oi
anothei suitaLle location.
2. Execute the sciipt Ly staiting the shell anu enteiing the commanu stiing
root@propane% sh ./upgrade-helper (the assumption is that the commanu is iun
liom the same location as wheie the helpei sciipt was loaueu). The ioutei iesponus
with:
Upgrade helper script started
ATTENTION: PLEASE RUN THIS SCRIPT AGAIN IMMEDIATELY AFTER REBOOTING.
Rebooting system.
The system ieLoots.
3. Once ieLooteu, log in, entei the shell (loi ioot useis this is unnecessaiy), anu ex-
ecute the upgradc-hc|pcr sciipt again.
Confirm that you have enough compact flash space
The ielease notes loi ]unos pioviue the lollowing compact llash space guiuelines:
To copy the soltwaie image to the ioutei anu install using that image, you neeu at least
twice the size ol the image ol availaLle space on the compact llash. Foi example, a ]unos
10.+ OS package ol 197 MB will neeu 39+ MB ol liee compact llash.
To install the soltwaie image to the ioutei you neeu at least the size ol the image. You
use the no-copy, unlink anu no-validate options with the request system software add
commanu to minimize the stoiage ieguiiements.
706 | Appendix B:Upgrading Junos
The lollowing list uesciiLes the options mentioneu in the ielease notes:
The unlink option iemoves the package eaily in the piocess to liee up memoiy
space.
The no-copy option specilies that a copy ol the package is not saveu in /var/sw/p|g.
The no-validate option pievents the ]unos soltwaie liom valiuating the soltwaie
package against the cuiient conliguiation.
The show system storage commanu uisplays useu anu liee space on the compact llash:
peter@propane> root> show system storage
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s1a 920M 326M 589M 36% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/md0 452M 452M 0B 100% /junos
/cf 920M 326M 589M 36% /junos/cf
devfs 1.0K 1.0K 0B 100% /junos/dev/
procfs 4.0K 4.0K 0B 100% /proc
/dev/bo0s1e 19M 15K 19M 0% /config
/dev/md1 168M 15M 140M 10% /mfs
/cf/var/jail 920M 326M 589M 36% /jail/var
/cf/var/log 920M 326M 589M 36% /jail/var/log
devfs 1.0K 1.0K 0B 100% /jail/dev
/dev/md2 39M 4.0K 36M 0% /mfs/var/run/utm
root>
.
In this case, 5S9 MB ol space is availaLle on the llash, which is moie than sullicient
when the no-copy anu unlink switches aie auueu.
Install the Junos Upgrade
You aie now ieauy to upgiaue the ioutei to iun the latest ]unos OS. It is assumeu that
you have oLtaineu the uesiieu package liom the ]unipei suppoit weLsite, anu that the
image is in place on the ioutei Leing migiateu. Goou housekeeping says the package
shoulu Le stoieu in the /var/tnp uiiectoiy, Lut this ieguiies ioot access.
Tips for Freeing More Space
Laige liles lelt in usei uiiectoiies oi in nonstanuaiu places may consume so much space
that you aie not aLle to loau a new soltwaie package. Il you have shell access, tiy this
hanuy commanu:
peter@propane> start shell
% find -x /cf -type f -exec du {} \; | sort -n
find: /cf/var/cron/tabs: Permission denied
. . .
0 /cf/etc/namedb/resolver.cache
. . .
448 /cf/var/log/dcd
1024 /cf/var/log/chassisd
Migrating to a Newer Version of Junos | 707
1440 /cf/var/log/httpd
107776 /cf/var/tmp/junos-jsr-10.4R1.8-domestic.tgz
114512 /cf/packages/junos-10.0R1.8-domestic
The output is soiteu liom smallest to laigest liles lounu, so you want to locus on the
entiies neai the enu ol the uisplay. Once you know wheie the laige liles aie, it is a simple
mattei to uelete oi move them oll the ioutei as uesiieu. In this example, the laigest liles
on the systems aie the soon-to-Le-installeu ]unos OS in /var/tnp anu the cuiiently
installeu ]unos veision in /var/cj. Any othei laige liles in usei uiiectoiies oi in
the /tnp oi /var/tnp uiiectoiy aie goou canuiuates loi ueletion. You can iemove the
liles liom the CLI with the file delete commanu anu the path loi the liles (wilucaius
can Le useu heie) oi alteinately liom the shell with the root@host% rm -rf /var/tmp/
* commanu. (This commanu iemoves all liles in the /var/tnp uiiectoiy anu iecuisively
iemoves uiiectoiies in that uiiectoiy, so Le caielul!)
Note that symLolic links iesult in /var/honc Leing mappeu to /cj/var/honc; theieloie,
you can use eithei path:
peter@propane% cd /var/home/
peter@propane% pwd
/cf/var/home
Once you have lieeu up enough space, it is time to peiloim the upgiaue anu issue
the request system software add commanu, lolloweu Ly the path anu name ol the
]unos package to Le installeu. In this example, you must incluue the no-copy anu
unlink switches Lecause ol space issues uesciiLeu pieviously, anu you shoulu also auu
the no-validate switch. Il the upuate is successlul, the piocess will complete anu ask
loi a ieLoot; il the piocess is not successlul, eiioi messages will Le uisplayeu anu the
olu image will Le useu:
peter@propane> request system software add jsr-10.4r1.8-domestic.tgz no-
copy unlink no-validate
You can mount a noimal USB uiive on a ]unos uevice Ly using the
mount_msdosfs commanu. This allows you to uownloau an image to youi
computei anu use the goou olu sneakeinet to Liing the image to the
ioutei. Foi most uevices, the lull commanu is root% mount_msdosfs /
dev/da0s1 /var/tmp/usb. This will cieate a uiiectoiy on the system liom
which you can copy oi loau an image. Be suie to use the umount com-
manu when you aie linisheu.
Il uesiieu, you can auu the reboot switch to the request system software commanu to
avoiu having to ieLoot the ioutei to complete installation. In this case, we can ieLoot
at oui leisuie, Lut the suspense is getting heavy, so it`s time to get it on, so to speak:
lab@propane> request system reboot
Reboot the system ? [yes,no] (no) yes
708 | Appendix B:Upgrading Junos
Altei a lew minutes, the installation completes, anu youi ioutei is Lack:
RDM Embedded 7 [04-Aug-2006] http://www.birdstep.com
Copyright (c) 1992-2006 Birdstep Technology, Inc. All Rights Reserved.
Unix Domain sockets Lock manager
Lock manager 'lockmgr' started successfully.
Error: Profile database dictionary file missing.
Profile database initialized
Local package initialization:.
starting local daemons:.
kern.securelevel: 1 -> 1
Sun Apr 17 08:35:36 UTC 2011
Amnesiac (ttyd0)
login: peter
Password:
Using a USB drive to load a new image
Vhen you have to upgiaue the image on multiple iouteis in youi netwoik, using a USB
uiive can save you time anu keystiokes. Rathei than copy the image to the compact
llash, ieguesting the auu commanu, anu ieLooting, the USB uiive is inseiteu, the ioutei
is ieLooteu liom it, anu then a snapshot ol the cuiient image is saveu to compact llash.
This piocess assumes that you have auueu the new image to one ol the iouteis using a
piocess similai to the one uesciiLeu pieviously. Once you have a single ioutei with the
new image, cieate a LootaLle USB uiive with a snapshot ol the image, anu inseit a USB
uiive into the poit ol the upgiaueu ioutei. Fiom the CLI, entei the lollowing commanu:
peter@propane> request system snapshot media usb partition as-primary
Clearing current label...
Partitioning usb media (da0) ...
Partitions on snapshot:
Partition Mountpoint Size Snapshot argument
a / 1024MB root-size
e /config 196MB config-size
g /data 693MB data-size
Running newfs (1024MB) on usb media / partition (da0s1a)...
Running newfs (196MB) on usb media /config partition (da0s1e)...
Running newfs (693MB) on usb media /data partition (da0s1g)...
Copying '/dev/ad0s1a' to '/dev/da0s1a' .. (this may take a few minutes)
Copying '/dev/ad0s1e' to '/dev/da0s1e' .. (this may take a few minutes)
The following filesystems were archived: / /config
peter@propane>
At this point you have an image on the USB uiive. Go to the next ioutei to Le upgiaueu,
anu inseit the USB uiive in that uevice. Mount the USB uiive liom the shell with the
mount commanu. Once mounteu, ieLoot the ioutei using the USB uiive. Peiloim a
Migrating to a Newer Version of Junos | 709
snapshot ol the image, anu ieLoot once again liom the compact llash. Heie aie example
commanus anu the ioutei iesponses loi this upgiaue piocess:
peter@propane> start shell
% su
Password:
root@propane% mount /dev/da0s1 /var/tmp/usb
root@propane% exit
exit
% exit
exit
peter@propane> show system storage
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s1a 460M 326M 129M 72% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/md0 452M 452M 0B 100% /junos
/cf 460M 326M 129M 72% /junos/cf
devfs 1.0K 1.0K 0B 100% /junos/dev/
procfs 4.0K 4.0K 0B 100% /proc
/dev/bo0s1e 19M 15K 19M 0% /config
/dev/md1 168M 15M 140M 10% /mfs
/cf/var/jail 460M 326M 129M 72% /jail/var
/cf/var/log 460M 326M 129M 72% /jail/var/log
devfs 1.0K 1.0K 0B 100% /jail/dev
/dev/md2 39M 4.0K 36M 0% /mfs/var/run/utm
/dev/da0s1 856M 152M 696M 18% /cf/var/tmp/usb
peter@propace> request system reboot media usb
Clearing current label...
Trying to boot from USB device ...
Loading /boot/loader
.....
login: peter
Password:
--- JUNOS 10.4R1.9 built 2010-12-04 09:16:15 UTC ---
--- NOTICE: System is running on alternate media device (/dev/da0s1a).
---
Upgrading from a USB drive when the compact flash is not large enough
In some instances it is necessaiy to upgiaue a uevice, even when theie is not enough
ioom on the compact llash to holu the new image. In these cases a USB uiive can Le
useu to pioviue auuitional stoiage loi the ioutei. The piocess involves auuing the USB
uiive to the ioutei memoiy system, copying the image to the USB uiive, anu upgiauing
the image liom that uiive. The pioceuuie listeu heie is loi images that aie newei than
S.5. Foi oluei ]unos images, ielei to http://|b.junipcr.nct/KB8017 (the uevice names aie
uilleientda0c veisus da0in the oluei pioceuuies).
710 | Appendix B:Upgrading Junos
The step-Ly-step pioceuuies aie as lollows:
1. Connect the USB llash uiive to the USB poit ol the ioutei.
2. Log into the uevice as ioot (ieguiieu loi many ol the lollowing commanus), anu
loimat the USB uiive liom the shell (start shell) using the low-level copy dd
commanu:
root@propane> start shell
root@propane % dd if=/dev/zero of=/dev/da0 bs=128k
The dd commanu uoes not pioviue any input to the usei anu might take a couple
ol minutes to complete.
Il the dd commanu lails to loimat the USB uiive, use the snapshot
commanu pioviueu in the pievious section.
3. LaLel the USB llash uiive using the disklabel commanu:
root@propane% disklabel -R -w da0 auto
Foi eailiei veisions ol ]unos, use the r mouiliei iathei than the R shown heie.
+. Cieate the lilesystem on the USB llash uiive Ly using the newfs commanu:
root@pbr% newfs -U /dev/da0
/dev/da0: nanMB (1000944 sectors) block size 16384,
fragment size 2048 using 4 cylinder groups of 122.19MB, 7820 blks,
15744 inodes with soft updates
super-block backups (for fsck -b #) at:
32, 250272, 500512, 750752
Foi eailiei veisions ol ]unos, the uevice name is da0c, not the da0 shown heie.
5. Cieate a uiiectoiy on the llash uiive to Le useu as a mounting iuentiliei loi the
uiive anu a copy location loi the image. Use the mkdir commanu to cieate the
uiiectoiy calleu /var/tnp/usb:
root@pbr% mkdir /var/tmp/usb
6. Now that the uevice is aligneu with the existing lilesystem, we have to mount the
USB uevice using mount commanu:
root@pbr% mount /dev/da0 /var/tmp/usb
Removing the USB llash uiive without issuing the umount commanu
coulu cause opeiational pioLlems oi lilesystem coiiuption.
7. Veiily that the USB uiive has successlully mounteu using commanu df -h:
root@pbr% df -h
Filesystem Size Used Avail Capacity Mounted on
Migrating to a Newer Version of Junos | 711
/dev/ad0s1a 851M 277M 565M 33% /
devfs 1.0K 1.0K 0B 100% /dev
devfs 1.0K 1.0K 0B 100% /dev/
/dev/md0 133M 133M 0B 100% /junos
/cf 851M 277M 565M 33% /junos/cf
devfs 1.0K 1.0K 0B 100% /junos/dev/
procfs 4.0K 4.0K 0B 100% /proc
/dev/bo0s1e 95M 16K 94M 0% /config
/dev/md1 336M 7.2M 302M 2% /mfs
/cf/var/jail 851M 277M 565M 33% /jail/var
devfs 1.0K 1.0K 0B 100% /jail/dev
/dev/da0 481M 4.0K 442M 0% /cf/var/tmp/usb
S. The USB llash uiive now can Le useu loi any puiposes within the ioutei. Oui
puipose is to auu ioom to stoie the upgiaue image. Ve copy the image liom oui
FTP seivei to the new /var/tnp/usb uiiectoiy, theieLy lieeing up space on the com-
pact llash uiive. Ve can copy liom the shell oi the CLI. In the lollowing example,
we aie copying liom the commanu line:
root@pbr> file copy ftp://1.1.1.1/junos-jsr-10.4R1.9-domestic.tgz
/var/tmp/usb
/var/tmp//...transferring.file.........PQ6d3g/100% of
48 MB 4209 kBps 00m00s
9. Veiily that the image is piesent on the USB uiive:
root@pbr> file list detail /var/tmp/usb
/var/tmp/usb:
total 36946
drwxrwxr-x 2 root operator 512 Feb 13 2011 .snap/
-rw-r--r-- 1 root wheel 18874368 Feb 13 23:07 junos-
jsr-10.4R1.9-domestic.tgz
10. Finally, it is time to upgiaue youi ioutei using the USB uiive as the image lile souice.
Use the no-copy anu no-link options to ieuuce the stoiage ieguiiements (see the
eailiei uelinitions ol these knoLs), anu point the loauei to the uiiectoiy on the USB
uiive. RememLei that you can use the TaL key loi auto-complete. Ve auueu the
reboot knoL as well, just to save time:
root@pbr request system software add /var/tmp/usb/
junos-jseries-8.5R2.10-domestic.tgz no-copy no-link reboot
11. Vhen the ioutei ieLoots, the USB uiive is unmounteu liom the lilesystem. It can
Le unmounteu manually using the umount commanu. Because the umount commanu
uoes not have any iesponse, use the file list /var/tmp/usb commanu to veiily
that the uiive is not piesent. Once unmounteu, it is sale to iemove the USB uiive
liom the uevice. The unmount commanu is:
root@pbr% umount /var/tmp/usb
Loading an SRX from a USB drive
Unclusteieu Bianch Ollice SRX uevices (SRX100, SRX210, SRX220, SRX2+0, anu
SRX650) can Le upgiaueu easily, even without access to the commanu line. The SRX
712 | Appendix B:Upgrading Junos
has a leatuie that allows the ieset Lutton to act as an upgiaue Lutton when an appio-
piiate USB uevice is attacheu. An appiopiiate USB uevice is one that has Leen loimatteu
loi ]unos anu has a soltwaie image anu an autoinsta||.conj lile.
The autoinsta||.conj lile is nothing moie than a placeholuei so that the
SRX iecognizes this USB uiive as a LootaLle uevice. It is an empty lile
that simply has the name autoinsta||.conj.
Use the lollowing steps to upgiaue an unclusteieu Bianch Ollice SRX:
1. Foimat a USB uiive as uelineu in the pievious section, anu copy the image to the
uiive.
2. Cieate a lile calleu autoinsta||.conj on youi uesktop, anu copy it to the USB uiive.
3. Assuie that the SRX to Le upgiaueu has enough memoiy to peiloim a noimal
upgiaue. (Il this is not the case, this piocess will not woik.)
+. Inseit the USB llash uiive into the USB poit ol the SRX, anu monitoi the status
LED on the liont panel. Vhen the LED Llinks amLei, then steauily light amLei,
this inuicates that the USB has Leen uetecteu anu is a LootaLle uiive (i.e., it has the
autoinsta||.conj lile piesent). Il the LEDs uo not show amLei, eithei the llash uiive
is not set up coiiectly oi the uevice neeus to Le powei cycleu.
5. Vhen the piopei LED inuications aie seen (steauy amLei), piess the iecesseu Reset
Conlig Lutton. This will cause the SRX to install the image it linus on the USB
uiive. Once the installation is complete, the status LED tuins a steauy gieen.
6. At this point, iemove the USB uiive. The SRX will automatically iestait with the
new ]unos veision.
Il the status LED tuins ieu, an eiioi has occuiieu in the installation. At
this point, console access is ieguiieu to ueteimine what has gone awiy
(coiiupteu image, not enough space, incompatiLle conliguiation, etc.).
Upgrade Summary
Foi multiple ieasons, the noimal piocess ol upgiauing the image on a ]unos-Laseu
uevice might Le impossiLle. The noimal culpiit is a lack ol space on the compact llash
caiu. To siuestep this issue anu otheis, the pioceuuies outlineu in this appenuix will
help.
Migrating to a Newer Version of Junos | 713
Index
Symbols
= (octothoipe) symLol, S
$ chaiactei, 157
> (chevion) symLol, 7
chaiactei, 157
A
ABRs (aiea Loiuei iouteis), 17+
accept action, 356
accept-uata commanu, 10S
access contiol lists (ACLs), 1+3
access layei (thiee-tiei uesign), 3+, 66
access lists, 355, 6+56+S
access iouteis
aLout, 666S
uevice options, 6S
access secuiity
Lasic concepts, 3+13+3
uelineu, 3+1
liiewall lilteis anu, 355373
ieview guestions/answeis, 39139+
iouteis anu, 3+3355, 3S0390
spool pievention, 37+3S0
ACLs (access contiol lists), 1+3
actions
liiewall lilteis, 356, 360
policei, 360, 370
iouting policy, 1+7
secuiity policy, 607
active monitoiing, +16
Active Queue Management (AQM), +31
Auaptive Seivices Mouule, 396
Auaptive Seivices PIC (ASP), 396, +75
auaptive shaping, +69, 50+
auuiess keywoiu, 550
auuiess iesolution piotocol (ARP), 13, 12+
auministiative uistance, 129, 16S, 206
auministiative scoping, multicast auuiessing
anu, 525527
ADSL (asymmetiical uigital suLsciiLei line),
99100
AES algoiithm, 652
AF PHBs, ++5
aggiegate ioutes
contiiLuting ioutes anu, 12+
uelault iouting pieleience, 130
geneiateu ioute compaiison, 125127
next hop types anu, 123
iouting policies anu, 125
static ioute compaiison, 12+
aggiegateu Etheinet, 101102, +09+10
aggiegation layei (thiee-tiei uesign), 3+
ALGs (application layei gateways), 15, 6+7
6+S
allow keywoiu, 307
Any Souice Multicast (ASM), 532, 537
Anycast-RP mechanism, 5+0
conliguiing, 5S3
PIM-Laseu scenaiio, 5S0590
veiilying, 5S+5SS
application layei gateways (ALGs), 15, 6+7
6+S
apply-path commanu, 365
AQM (Active Queue Management), +31
aiea Loiuei iouteis (ABRs), 17+
ARP (auuiess iesolution piotocol), 13, 12+
AS (autonomous system) numLei
aLout, 139, 2+9, 261
intei-AS iouting, 250
Ve`u like to heai youi suggestions loi impioving oui inuexes. Senu email to indcxorci||y.con.
715
poitaLility consiueiations, 262
AS path attiiLute
aLout, 252, 319
community attiiLute anu, 327333
inlluencing path selection, 322326
AS path iegex matching, 15615S
ASBRs (autonomous system Lounuaiy iouteis),
17+
ASM (Any Souice Multicast), 532, 537
ASM iouteis, 532, 653
ASP (Auaptive Seivices PIC), 396, +75
asymmetiic link speeus, 26326S
asymmetiic loau Lalancing
BGP ueployment anu, 26S270, 2S+291
conliguiing geneiateu ioute, 271275
conliguiing initial BGP peeiing, 2752S1
conliguiing initial BGP policy, 2S22S+
valiuating Laseline opeiations, 270
asymmetiical uigital suLsciiLei line (ADSL),
99100
ATM (Asynchionous Tianslei Moue)
aLout, xviii
cell loss piioiity, +27
inteilace example, 99100
authentication
IPSec suppoit, 651
secuiity consiueiations, 15, 3+3350
authoiization, 3+5350
auto-RP mechanism, 539
autonomous system Lounuaiy iouteis (ASBRs),
17+
autonomous system numLei (see AS numLei)
B
BA classilication
aLout, +27, +++
conliiming, +97+99
CoS uelaults, +70
packet seguencing anu, +29, +5+
piocessing capaLilities, ++7
iewiiting anu, +7S+S0
LackLone aieas, 176
LackLone iouteis, 17+
Lackup uesignateu ioutei (BDR), 173
Lanuwiuth
lixeu allocation ol, +23
piice tienus, +2+
as QoS paiametei, +26
BDR (Lackup uesignateu ioutei), 173
BE (Best Elloit) loiwaiuing class, +29
BECN Lit, +69
Lehavioi aggiegate classilication (see BA
classilication)
BFD (Liuiiectional loiwaiuing uetection)
lailovei peiloimance anu, +2, 75
OSPF anu, 179
static iouting anu, 122
BGP (Boiuei Gateway Piotocol)
aLout, 2+9
applying iouting policies, 1+31++
asymmetiic link speeus, 26326S
asymmetiic loauing Lalancing, 2S+291
coie iouteis anu, 6+
uelault ioute taLles, 135
uelault iouting policies, 15+
uelault iouting pieleience, 130
ueployment scenaiio
aLout, 26S
conliguiing geneiateu ioutes, 271275
conliguiing initial BGP peeiing, 275
2S1
conliguiing initial BGP policy, 2S22S+
multihome Beei-Co, 29531S
enteipiise netwoiks anu, 261263
intei-AS iouting, 250
Inteinet Loiuei iouteis anu, 61, 62
netwoik uesign anu, +5
path selection, 253256
ieview guestions/answeis, 335339
ioute attiiLutes, 251253
RPF anu, 530
scieening iouteis anu, 5+
tiansit seivices anu, 265
tiouLleshooting next hop ieachaLility, 310
312
tunnel seivices anu, +17
valiuating Laseline opeiations, 270
Lgp.12vpn.0 taLle, 135
Lgp.13vpn.0 taLle, 135
Liuiiectional loiwaiuing uetection (see BFD)
Liuiiectional NAT, 6+9
Linaiy tiees, 1+S
Boink attacks, 650
Boolean giouping, 159
Lootstiap pioLlems, 57+5S0
Boiuei Gateway Piotocol (see BGP)
Bianch Ollice SRXs
liiewalls anu, 57, 5S
716 | Index
mouels suppoiteu, 23
scieening ioutei iole, 5+
secuiity leatuies, 606
tiansient inteilaces anu, S+
Liiuge uomain, uelineu, 13
BSR RP mechanism
aLout, 527, 539
conliguiing PIM spaise moue, 56S5S0
Lunules, uelineu, 100
C
CAC (call aumission contiol), +23
call estaLlishment phase, ++1
Cameion, RoL, 13, 595
campus aichitectuie
challenges lacing, +9
uesign goals/constiaints, +9
legacy LackLone, +9
netwoik uesign solution, 5052
CBF (Class-Baseu Foiwaiuing), +36, +52
CBT (Coie-Baseu Tiee), 53S
cllowu loimat, +16
chevion (>) symLol, 7
CIDR (classless inteiuomain iouting)
RIPv2 suppoit, 171
slash notation, 93
CIR (committeu inloimation iate), +69
ciicuit-switcheu technologies, +23+2+
Class ol Seivice (see CoS)
Class-Baseu Foiwaiuing (CBF), +36, +52
classilication
conliiming, +95+99
contiolling tiallic anu, +7+
CoS anu, +26+2S, +70
DillSeiv anu, +++
classless inteiuomain iouting (see CIDR)
cleai Lgp neighLoi commanu, 307
cleai-uont-liagment commanu, +0S
CLI (commanu-line inteilace)
? leatuie, 12S, 351
aLout, xix, 6
conliguiation moue, S9
count lunction, 300
uisplay set lunction, 193
lieeing up space, 705707
geneial leatuies, 79
match lunction, 270
opeiational moue, 7
clock stiata concept, 3SS
clocking
uelineu, 90
seiial inteilaces anu, 9S
CLP Lit, +27
clusteiing
aLout, 635
components suppoiteu, 636
conliguiation consiueiations, 63763S
veiilying, 6396+0
commanu-line inteilace (see CLI)
commit anu-guit commanu, 93
commit commanu, 9
commit conliimeu commanu, 367
committeu inloimation iate (CIR), +69
community attiiLute
aLout, 253, 319
inlluencing peei AS, 327333
community iegex matching, 15615S
Compiesseu RTP (CRTP), +02+03
conliguie exclusive commanu, S
conliguie piivate commanu, S
congestion management, +31+32, +60
contiiLuting ioutes, 12+
contiol links, 636
conveisations commanu, 6S0
copy commanu, 9
coie layei (thiee-tiei uesign), 3+
coie iouteis
aLout, 6+
uevice options, 6+65
Coie-Baseu Tiee (CBT), 53S
CoS (Class ol Seivice)
aLout, ++6
ciicuit-switching inelliciencies, +23+2+
classilication anu, +26+2S
conliguiing, ++7, +75+S+, +92+9+
congestion management anu, +31+32,
+60
coie iouteis anu, 6+
uelay Lullei size, +5S+59
uilleiences in Lehavioi, +63+70
DillSeiv ueployment/veiilication, +7150+
loiwaiuing classes anu, +29, +33
input piocessing, ++7+53
IP netwoiks anu, +22+2+
]unos uelaults, +70
loss piioiity, +27
MLPPP anu, +00
output piocessing, +53+5S
Index | 717
packet maiking/iewiiting, +2S, +53, +70
policing anu shaping, +33+3+
policy consiueiations, +52
piocessing steps, +35+3S
gueues anu, +29
ieview guestions/answeis, 512515
scheuuleis anu, +30, +55+5S, +59+62
shaping example, +S0
testing, +72+75
Veighteu RED, +32
count action, 360
count commanu, 93
CRTP (Compiesseu RTP), +02+03
CS PHBs, ++5
CSU/DSU, 97
D
Data Centei SRXs
all-in-one veisus components, 75
liiewalls anu, 57, 5S
mouels suppoiteu, 2+
secuiity leatuies, 606
tianspaient moue, 12
uata centeis
uesign example, +3, +6+S
uesign goals anu constiaints, +5+6
thiee-tiei uesign, 3337
tiallic consiueiations, +3
uata integiity, 651
Data Link Switching (DLSw), +1+
uata-link connection iuentilieis (DLCIs), 91,
+0+
DCE uevices, 96
uu commanu, 711
DDoS (uistiiLuteu uenial ol seivice) attacks,
123
DE Lit, +27
ueactivate secuiity llow tiaceoptions
commanu, 61S
uelault-inloimation oiiginate commanu, 21S
uelicit iounu-ioLin (DRR), +55
uelicit weighteu iounu-ioLin (DVRR), +56,
+66
uelay
uelineu, +26
IP netwoiks anu, +22
uelay Lullei size, +5S+59
uelay vaiiation, +22, +26
uelete commanu, S, 109, 132
uemilitaiizeu zone (DMZ), 5+
uenial ol seivice attacks (see DoS attacks)
uense moue
aLout, 522
PIM suppoit, 5+0
uense poit concentiatois (DPCs), 21, S5
uense-woius keywoiu, 5+S
DES algoiithm, 652
uesign, enteipiise (see netwoik uesign)
uesignateu iouteis, 173, 5+25+3
uestination NAT
aLout, 623, 6+9, 6S2
poit mapping anu, 67+
statelul liiewalls anu, 6S36S5
ul -h commanu, 711
DHCP (Dynamic Host Conliguiation Piotocol)
access iouteis anu, 66
uelault gateway auuiess anu, 10+
DillSeiv iegions anu, ++6
iemote access anu, 351
Dilleientiateu Seivices coue point (see DSCP)
DillSeiv (Dilleientiateu Seivices)
aLout, ++2
conliguiing CoS, +75+S+
CoS ueployment/veiilication, +7150+
loiwaiu class mappings, +29
IP Integiateu Seivices anu, ++0++2
IP ToS anu, +3S++0
teims anu concepts, ++3++6
Dijkstia algoiithm, 172
uisastei iecoveiy, aichitecting, +3+S
uiscaiu accounting, +16
uiscaiu action, 356
uiscaiu next hop, 123
uisklaLel commanu, 711
uistiiLuteu uenial ol seivice (DDoS) attacks,
123
uistiiLution layei (thiee-tiei uesign), 3+, 66
uistiiLution tiees
aLout, 522
shoitest-path tiee, 531
upstieam/uownstieam, 522
DLCIs (uata-link connection iuentilieis), 91,
+0+
DLSw (Data Link Switching), +1+
DMZ (uemilitaiizeu zone), 5+
DoS (uenial ol seivice) attacks
inteilaces anu, S1
scieening iouteis anu, 5+
718 | Index
spool pievention, 37+3S0
statelul liiewalls anu, 6+7
uotteu uecimal notation, xviii
DPCs (uense poit concentiatois), 21, S5
ui-iegistei policy keywoiu, 5+9
uiec tool, 556
uiiLLle eiioi, +26
DRR (uelicit iounu-ioLin), +55
DS (DillSeiv) lielu, +++
DS Lehavioi aggiegates, +29
usc inteilace, S1
DSCP (Dilleientiateu Seivices coue point)
aLout, ++2
BA classilication anu, +27, ++7
DSL connection meuia, 99100
DTE uevices, 96
DTR llags, ++3
DV iouting piotocols, 169, 172
DVMRP (Distance Vectoi Multicast Routing
Piotocol)
uelault ioute taLles, 13+
gloLal ioute pieleience, 130
multicast suppoit, 523
PIM anu, 53S
RPF anu, 530
DVRR (uelicit weighteu iounu-ioLin), +56,
+66
Dynamic Host Conliguiation Piotocol (see
DHCP)
E
EBGP (Exteinal BGP)
Beei-Co example, 30230+
BGP peeiing example, 29S302
gloLal ioute pieleience, 131
IBGP compaiison, 256
monitoiing system loau, 303
multitiei uata centei uesign, ++
ECMP (egual cost multipath) iouting, 11
ECN (explicit congestion notilication), ++2
euge iouteis, MX seiies, 1921, 70
euit commanu, 9
EF PHBs, ++5
EGP (Exteiioi Gateway Piotocol), 16S, 2+9
S0/20 iule, 33
EIGRP (Enhanceu Inteiioi Gateway Routing
Piotocol)
aLout, 1S0
lutuie consiueiations, 1S3
metiics suppoiteu, 1S11S3
OSPF migiation scenaiio, 2292+3
EIR (excess inloimation iate), +69
encapsulation
HDLC example, 96
as inteilace piopeity, 90
tiouLleshooting mismatches, 111113
Enciyption Seivices PIC, 396
Enhanceu Inteiioi Gateway Routing Piotocol
(see EIGRP)
enteipiise uesign (see netwoik uesign)
enteipiise netwoiks
BGP anu, 261263
uesign guiuelines, 2939
uevice ioles, 5371
]unos suppoit, 19
loau Lalancing anu, 2S5
multiseivices gateway, 69
ieview guestions/answeis, 25
iouting leatuies, 912
iouting platloims, 1721
secuiity leatuies, 1+16
SRX seiies seivices gateways, 232+
switching leatuies, 121+
switching platloims, 21
enteipiise iouting
aLout, xvixvii
CoS Lehavioi uilleiences, +63+6+
egual cost multipath (ECMP) iouting, 11
estaLlish-tunnels immeuiately commanu, 666
Etheinet
aLout, xviii
aggiegateu, 101102, +09+10
PPPoE example, 99100
EX seiies uevices
access ioutei options, 6S
coie ioutei options, 65
uevice limitations, 70
viitual chassis switches, 21
exact keywoiu, +S3
exact match type (ioute liltei), 151
excess inloimation iate (EIR), +69
exit commanu, 9
explicit congestion notilication (ECN), ++2
explicit-piioiity keywoiu, 3S+
expoit keywoiu, 192, 5+S, 570
Exteiioi Gateway Piotocol (EGP), 16S, 2+9
Exteinal BGP (see EBGP)
Index | 719
F
laLiic links, 636
lacility level (syslog), 3S0
lamily keywoiu, 550
leasiLle paths leatuie, 377
liLie channel, 75
FIBs (loiwaiuing inloimation Lases), 12
lile list commanu, 712
liltei piotect-ioutei commanu, 365
liltei-Laseu loiwaiuing, 11
lingei piotocol, 351
liiewall lilteis
aLout, 355, 6+56+S
actions suppoiteu, 356, 360
applying, 361
loopLack lilteis case stuuy, 36+367
match conuitions, 357360
policeis anu, 36S373
iouting policies anu, 1+3, 355
scieening iouteis anu, 5+
tiansit lilteis case stuuy, 36136+
liiewalls
uevice limitations, 71
as secuiity gateways, 555S
statelul, 6+56+S, 65S, 6S36S5, 691696
stateless, 55
FlexiLle PIC Concentiatoi (see FPC)
lloating static ioutes, 131
llow contiol
llow-Laseu piocessing, 597, 59S600
monitoiing, +16
viitual ciicuits anu, +22
llwuu (llow uaemon), 59S
loiklilts, uelineu, 31
loiwaiuing classes
aLout, +29
CoS uelaults, +70
isolation Letween, +33
scheuulei example, +57
loiwaiuing inloimation Lases (FIBs), 12
loiwaiuing next hop
aLout, 123
gualilieis loi, 12+
loiwaiuing-class action, 360
FPC (FlexiLle PIC Concentiatoi)
chassis slot numLei, S2
CoS Lehavioi, +63+6+
scheuuleis anu, +30
liagment-ollset keywoiu, 362
Fiame Relay
aLout, xviii, 9S
cell loss piioiity, +27
seiial inteilaces with, 9S
FieeBSD opeiating system
inteilaces anu, S1
]unos suppoit, 2
FTP (File Tianslei Piotocol), 351
lwuu uaemon, 3
lxp0 inteilace, S0
lxp1 inteilace, S0
G
geneiateu ioutes
aggiegate ioute compaiison, 125127
conliguiing, 271275
contiiLuting ioutes anu, 12+
uelault iouting pieleience, 130
next hop types anu, 123
static ioute compaiison, 12+
Geneiic Routing Encapsulation (see GRE)
GigaLit Etheinet
BGP ueployment example, 2SS
conliguiation examples, 9295
with VLAN tagging, 9+
gloLal ioute pieleience, 129131, 206
GRE (Geneiic Routing Encapsulation)
aLout, 103, +07+09
IPSec anu, 66S673, 691696
gioup management piotocols, 53+537
gioup-ianges keywoiu, 550
H
H.323 specilication, 6+S
haiuwaie-timestamp keywoiu, +95
hash lunctions, 651
HDLC (High-Level Data Link Contiol), xviii,
96, +60
help syslog commanu, 3S2
hiuuen commanus, 351
High-Level Data Link Contiol (HDLC), xviii,
96, +60
I
IANA (Inteinet Assigneu NumLeis Authoiity),
52+
IBGP (Inteinal BGP)
BGP peeiing example, 30+312
720 | Index
EBGP compaiison, 256
gloLal ioute pieleience, 131
monitoiing system loau, 303
iouteis anu, 26+26S
scaling with ioute iellection, 25S261
tiouLleshooting peeiing, 30630S
ICMP (Inteinet Contiol Message Piotocol)
aLout, xix
uelault iouting pieleience, 130
uiscaiu next hop anu, 123
liltei match conuitions, 357
inteilace piopeities anu, 91
ieject next hop anu, 123
ICMP lloous, 650
IDP (intiusion uetection anu pievention)
aLout, 650, 6S76S9
secuiity consiueiations, 15, 632635
IEEE S02.1p stanuaiu, ++7
IEEE S02.3au stanuaiu, 1+, 101, +09
IETF (Inteinet Engineeiing Task Foice), 352,
++0, 52+
IGMP (Inteinet Gioup Management Piotocol),
521, 53+537, 557
IGP (Inteiioi Gateway Piotocol), 16S
(see also EIGRP; OSPF; RIP)
aLout, 6+, 16S
BGP anu, 250, 26+
integiation migiation mouel, 211
migiation technigues/conceins, 206
oveilay migiation mouel, 207
ieuistiiLution migiation mouel, 209211
ieview guestions/answeis, 2++2+7
ioute ieuistiiLution, 130, 206
RPF anu, 529
ToS anu, +39
valiuating Laseline loiwaiuing path, 5+5
5+6
IKE (Inteinet Key Exchange)
aLout, 652
IPSec VPNs anu, 661
impoit keywoiu, 192, 5+S, 570
inLounu iouting policy
aLout, 292, 31S322
AS path anu, 322326
community attiiLute anu, 327333
expoit policy anu, 29+
inet.0 taLle, 13+
inet.1 taLle, 13+
inet.2 taLle, 13+
inet.3 taLle, 13+
inet6.0 taLle, 13+
inseit commanu, S
instancename.inet.0 taLle, 13+
integiation migiation mouel, 211
inteilace keywoiu, 5+S
inteilace lists, 527529
inteilace-specilic commanu, 370
inteilace-specilic keywoiu, +S5
inteilace-style seivice sets
aLout, 653657
IPSEC tunnel conliguiation, 662666
inteilaces
ADSL using PPPoE ovei ATM, 99100
aggiegateu Etheinet, 101102
applying policeis, 370
GigaLit Etheinet examples, 9295
GRE anu, 103
HDLC encapsulation anu, 96
Inteinet Loiuei iouteis anu, 62
linking scheuuleis to, +59+62
logging suppoit, 65S
logical piopeities, 9091
loopeu, 115
MLPPP, 100
nontiansit, S0
peimanent, 79S1
physical piopeities, 90
ieview guestions/answeis, 117120
secuiity policies anu, 607
seiial, 9699
seivice set, 65+657
tiansient, S1S9
tiouLleshooting, 10S116
tunnel seivices anu, +17
VRRP anu, 10+10S
Inteiioi Gateway Piotocol (see IGP)
inteileave-liagements commanu, 399
Inteimeuiate SystemtoInteimeuiate System
(see IS-IS)
Inteinal BGP (see IBGP)
inteinal iouteis, 17+
Inteinet access
uesign goals/constiaints, +0
uual uesign example, +1+3
existing uesign example, 39
Inteinet Assigneu NumLeis Authoiity (IANA),
52+
Inteinet Loiuei iouteis
Index | 721
aLout, 59
uevice options, 62
uual link, 61
single link, 61
Inteinet Contiol Message Piotocol (see ICMP)
Inteinet Engineeiing Task Foice (IETF), 352,
++0, 52+
Inteinet Gioup Management Piotocol (IGMP),
521, 53+, 557
Inteinet Key Exchange (IKE)
aLout, 652
IPSec VPNs anu, 661
intiusion uetection anu pievention (see IDP)
IntSeiv (Integiateu Seivices), ++0++2
IP (Inteinet Piotocol)
liltei match conuitions, 357
inteilace piopeities anu, 91
ToS anu, +3S++0
IP auuiessing
aLout, xviii
loiwaiuing next hop anu, 123
Inteinet anu, 59
multicast, 523
secuiity policies anu, 607
tiouLleshooting, 10S110
IP CoS (see CoS)
IP Dilleientiateu Seivices (see DillSeiv)
IP liagmentation attacks, 650
IP Integiateu Seivices (IntSeiv), ++0++2
ip inteilace, S0, +17
IP multicast (see multicast)
IPSec piotocol
GRE anu, 66S673, 691696
logging suppoit, 65S
VPNs anu, 62+632, 650652, 66067+
IPv+ piotocol, 517
(see also multicast)
uelault ioute taLles, 13+
migiation stiategies, +2+
RIP uelault iouting pieleience, 130
IPv6 piotocol
uelault ioute taLles, 13+
inteilace piopeities anu, 91
migiation stiategies, +2+
RIP uelault iouting pieleience, 130
is-liagment keywoiu, 363
IS-IS (Inteimeuiate SystemtoInteimeuiate
System)
applying iouting policies, 1+2
uelault ioute policies, 153
uelault ioute taLles, 135
uelault iouting pieleience, 130
RPF anu, 530
iso.0 taLle, 135
J
]-seiies iouteis
aLout, 17
auaptive shaping anu, +69
CoS Lehavioi, +63+6+
uelault conliguiation, 602605
uevice limitations, 70
liiewalls anu, 57
]unos opeiational moues, 601606
Layei 2 seivices, 396, +10
M-seiies compaiison, 3
ioute iellection anu, 30+
scieening ioutei iole, 5+
seivices suppoiteu, 6+5, 653
tiansient inteilaces anu, S3
viitual channels anu, +6S
]-Tiee
aLout, 1+S
ioute liltei match types anu, 150
jittei, +22, +26
]NTCP (]unipei Netwoiks Technical
Ceitilication Piogiam), xvii
]TAC (]unipei Technical Assistance Centei), 5
]unipei Netwoiks
]unos suppoit, 1
ieview guestions/answeis, 25
iouting leatuies, 912
iouting platloims, 1721
secuiity leatuies, 1+16
SRX seiies seivices gateways, 232+
switching leatuies, 121+
switching platloims, 21
]unipei Netwoiks Technical Ceitilication
Piogiam (]NTCP), xvii
]unipei Technical Assistance Centei (]TAC), 5
junipeipiivate taLle, 135
]unos opeiating system
aLout, 19, 595
CLI suppoit, 69
CoS uelaults, +70
CoS uilleiences, +63+70
opeiational moues, 601606
pieuelineu usei classes, 3+5
722 | Index
ielease tiain loi, +6
ieview guestions/answeis, 6+16+3
iouting leatuies, 912
iouting platloims anu, 1721
secuiity leatuies, 1+16
secuiity-Laseu scenaiio, 596601
suppoit levels pioviueu, 5
switching leatuies, 121+
upgiauing, 705713
]unosciipt, 352, 353
jweL weL GUI, 352
K
keepalive mechanisms, 90, 99
KISS methou, 359
L
L2TP (Layei 2 Tunneling Piotocol), +12
LaLel DistiiLution Piotocol (LDP), 130
laLel-switcheu path (LSP), 123, 13+
laLel-switching ioutei (LSR), 135
LAC (LT2P Access Concentiatoi), +12
LACP (link aggiegation contiol piotocol)
aLout, 1+, 71
aggiegateu Etheinet anu, 102, +09+10
LAGs (link aggiegation gioups), 7172, +09
+10
Layei 1 inteilace piopeities, 90
Layei 2 seivices
aLout, 395397
CRTP, +02+03
DLSw suppoit, +1+
Etheinet aggiegation, +09
llow monitoiing anu, +16
GRE, +07+09
inteilace piopeities, 90
L2TP suppoit, +12
mapping multicasts, 52+533
MLFR, +0++06
MLPPP, 39S+02
ieview guestions/answeis, +1S+20
RPM suppoit, +12+1+
switching, +10
tunnels anu, +17
Layei 2 Tunneling Piotocol (L2TP), +12
Layei 3 seivices
aLout, 6+5
comLining, 690696
conliguiing, 652660
intiusion uetection seivices, 650, 6S76S9
IPSec VPNs, 650652, 66067+
lile ol packets, 696699
logging suppoit, 65S660
mapping multicasts, 52+533
NAT, 6+S, 67+
piotocol lamilies anu, 91
ieview guestions/answeis, 700703
statelul liiewalls, 6+56+S, 65S
tiacing suppoit, 65S660
LCP (Link Contiol Piotocol), 39S
LDP (LaLel DistiiLution Piotocol), 130
legacy netwoik uesign, 3337, 66
LFI (link liagmentation anu inteileaving), 396,
399
link aggiegation contiol piotocol (see LACP)
link aggiegation gioups (LAGs), 7172, +09
+10
Link Contiol Piotocol (LCP), 39S
link liagmentation anu inteileaving (LFI), 396,
399
Link Seivices PIC, 396
link-state auveitisement (see LSA)
link-state uataLase (LSDB), 172
LIR (Local Inteinet Registiy), 262
LLQ (low-latency gueuing), +56, +67
lo0 inteilace, S0, 12+
loau Lalancing
asymmetiic, 26S291
tuining oll, 11
loau-shaiing policy, 29+
Local Inteinet Registiy (LIR), 262
local loops, 115
local pieleience attiiLute, 252
log action, 360
logging
Layei 3 seivices, 65S660
secuiity tiallic, 61S
logical units
Lunules anu, 100
uelineu, S9
VLANs anu, 90
longei match type (ioute liltei), 151
looking glass, uelineu, 32+
loopLack lilteis case stuuy, 36+367
loopeu inteilaces, 115
loss
uelineu, +26
Index | 723
piioiitizing, +27
loss pattein, uelineu, +26
low-latency gueuing (LLQ), +56, +67
LS iouting piotocols, 1+2, 172
LSA (link-state auveitisement)
lloouing packets, 1+2
OSPF anu, 153, 172, 17+17S
piimaiy types, 177
LSDB (link-state uataLase), 172
LSP (laLel-switcheu path), 123, 13+
LSR (laLel-switching ioutei), 135
lt inteilace, +17
LT2P Access Concentiatoi (LAC), +12
M
M-IS-IS piotocol, 530
M-seiies iouteis
aLout, 17
CoS Lehavioi, +63+6+
uevice limitations, 69
]-seiies compaiison, 3
Layei 2 seivices, 396
pei-unit scheuuling, +6+
seivices suppoiteu, 6+5
tiansient inteilaces anu, S2
MAC auuiesses
multicasting anu, 52+
switching anu, 13
VRRP anu, 105
MALLOC (multicast allocation auuiess space),
565
Management Inloimation Base (MIB), 3S5,
3S7
Maischke, Doug, 12, 72
maitian ioutes, 132133
maximum ieceiveu ieconstiucteu unit
(MRRU), 399
maximum tiansmission unit (MTU), 90, 11+
115, 399
MBGP (Multipiotocol Boiuei Gateway
Piotocol), 530
MCML (Multiclass Multilink PPP), +01
MD5 algoiithm, 651
MDRR (mouilieu uelicit iounu-ioLin), +55
+56, +65
MDT (multicast uistiiLution tiee), 5+S
MED (multiple exit uisciiminatoi) attiiLute,
253, 319
messages log, +60
metiic keywoiu, 293
MIB (Management Inloimation Base), 3S5,
3S7
migiation stiategies
EIGRP-to-OSPF, 2292+3
IGP technigues/conceins, 206
integiation mouel, 211
IPv+-to-IPv6, +2+
oveilay mouel, 207, 213229
ieuistiiLution mouel, 209211
RIP ueployment scenaiio, 1S+205
RIP to OSPF, 213229
minimum-links numLei commanu, 101
mkuii commanu, 711
MLFR (Multilink Fiame Relay), +0++06
MLPPP (Multilink Point-to-Point Piotocol),
100, 39S+02
moue keywoiu, 5+S
mouilieu uelicit iounu-ioLin (MDRR), +55
+56, +65
mouilieu weighteu uelicit iounu-ioLin
(MVDRR), +55
mouulai poit concentiatois (MPCs), S5
monitoi inteilace commanu, 112
monitoi list commanu, 202
monitoi stait commanu, 201, 306
monitoi stop commanu, 202
monitoi tiallic commanu, 112, 113, +39
monitoiing
llow, +16
iesouice peiloimance, +7+
iouteis, 3S0390
RPM suppoit, +12+1+
system loau, 303
Monitoiing Seivices III PIC, 396
mountmsuosls commanu, 70S
MPCs (mouulai poit concentiatois), S5
MPLS (Multipiotocol LaLel Switching)
BA classilication anu, ++7
BGP anu, 26+
uelault ioute taLles, 13+
uelault iouting pieleience, 130
inteilace piopeities anu, 91
OSPF anu, 171
RSVP anu, ++2
tunnel seivices anu, +17
mpls.0 taLle, 135
MRRU (maximum ieceiveu ieconstiucteu
unit), 399
724 | Index
MSDP (Multicast Souice Discoveiy Piotocol),
130, 5S9
MSTP (Multiple Spanning Tiee Piotocol), 13
mt inteilace, +17
MTU (maximum tiansmission unit), 90, 11+
115, 399
multicast, 556
(see also PIM spaise moue)
aLout, 517
applications loi, 51S
Luiluing Llocks, 523
client options, 55656S
cieating listening piocess, 55S561
geneiating tiallic, 56156S
inteilace lists, 527529
locating content, 519
mapping, 52+533
ieview guestions/answeis, 591593
RPF anu, 520
teiminology anu concepts, 52052+
multicast auuiessing
aLout, 523
auministiative scoping anu, 525527
multicast allocation auuiess space (MALLOC),
565
multicast uistiiLution tiee (MDT), 5+S
multicast piotocols, 53S
(see also PIM)
aLout, 522
gioup management piotocols, 53+537
multicast ieceiveis, 521
Multicast Souice Discoveiy Piotocol (MSDP),
130, 5S9
multicast souices, 521
Multiclass Multilink PPP (MCML), +01
multilielu classilication
aLout, +27
activating, +S7
conliiming, +96
packet maiking anu, +29, +53
policing anu, +76+7S
piocessing capaLilities, ++9
Multilink Fiame Relay (MLFR), +0++06
Multilink Point-to-Point Piotocol (MLPPP),
100, 39S+02
multiple exit uisciiminatoi (MED) attiiLute,
253, 319
Multiple Spanning Tiee Piotocol (MSTP), 13
multiplexing, statistical, +22
Multipiotocol Boiuei Gateway Piotocol
(MBGP), 530
Multipiotocol LaLel Switching (see MPLS)
multiseivice gateway, 69
Multiseivices 100 PIC, 396
multitopology iouting, 12
MVDRR (mouilieu weighteu uelicit iounu-
ioLin), +55
MX seiies iouteis
access iouteis, 6S
coie iouteis, 6+
CoS Lehavioi, +63+6+
uevice limitations, 70
euge iouteis, 1921, 70
N
naming tiansient inteilaces, S1S9
NAPT (Netwoik Auuiess Poit Tianslation),
6+9
NAT (Netwoik Auuiess Tianslation)
aLout, 6+S, 67+6S7
scieening iouteis anu, 5+
secuiity consiueiations, 15, 596601, 619
62+
statelul liiewalls anu, 6S36S5, 691696
NC (Netwoik Contiol) loiwaiuing class, +29,
++0
negotiate-auuiess commanu, 100
nesteu policy, 15S
Netwoik Auuiess Poit Tianslation (NAPT),
6+9
Netwoik Auuiess Tianslation (see NAT)
Netwoik anu Secuiity Managei (NSM), 352
Netwoik Conliguiation piotocol, 352
Netwoik Contiol (NC) loiwaiuing class, +29,
++0
netwoik uesign
Lest piactices, 52
campus aichitectuie, +952
uata centei aichitectuie, +3+S
uual Inteinet access, 39+3
guiuelines loi, 2930
legacy, 3337, 66
new technologies anu, 3739
iouting policy ciiteiia, 29229+
technological goals ol, 3032
thiee-tiei, 3337
netwoik layei ieachaLility inloimation (NLRI)
attiiLute, 250, 251
Index | 725
Netwoik Time Piotocol (NTP), 3S7390
newls commanu, 711
next hop attiiLute, 252
next hop types
aLout, 123
ioute type compaiisons, 123
next hopstyle seivice sets
aLout, 65+657
IPSec tunnel conliguiation, 66766S
next teim action, 360
NLRI (netwoik layei ieachaLility inloimation)
attiiLute, 250, 251
no-liagmentation commanu, +01
no-pieempt commanu, 10S
no-summaiies keywoiu, 227
nontiansit inteilaces, S0
not-so-stuLLy aieas (NSSAs), 171, 176
NSM (Netwoik anu Secuiity Managei), 352
NSSAs (not-so-stuLLy aieas), 171, 176
NTP (Netwoik Time Piotocol), 3S7390
O
OLject Iuentiliei (OID), 3S5
octothoipe (=) symLol, S
OID (OLject Iuentiliei), 3S5
OIL (outgoing inteilace list), 520
Open Shoitest Path Fiist (OSPF), 10+
Open Systems Inteiconnection (OSI) mouel,
xviii
opeiatoi usei class, 3+6
optional nontiansitive attiiLute, 252
optional tiansitive attiiLute, 252
oi-longei match type (ioute liltei), 151
oiueieu aggiegates, +29
oiigin attiiLute, 253, 319
OSI (Open Systems Inteiconnection) mouel,
xviii
OSPF (Open Shoitest Path Fiist)
aLout, 171173
applying iouting policies, 1+2
aiea types, 176
contiiLuting ioutes anu, 125
coie iouteis anu, 6+
uelault ioute policies, 153
uelault iouting pieleience, 130
uesignateu iouteis, 173
EIGRP migiation scenaiio, 2292+3
GRE anu, 10+
LSAs anu, 153, 172, 17+17S
multicasting anu, 520
neighLois anu aujacencies, 173
oveilay migiation scenaiio, 213229
ioutei types, 17+
RPF anu, 529
staLility/peiloimance tweaks, 17S1S0
outLounu iouting policy
aLout, 292
Beei-Co example, 297
conliiming opeiation, 313317
impoit policy anu, 29+
outgoing inteilace list (OIL), 520
oveilay migiation mouel
aLout, 207
RIP to OSPF, 213229
P
Packet Foiwaiuing Engine (PFE)
aLout, 1
inteilaces anu, S0
packet loss piioiity (see PLP)
packets
classilication anu, +26+2S
liiewalls anu, 56
llow-Laseu piocessing anu, 597, 59S
IP liagmentation attacks, 650
lile ol, 696699
maiking/iewiiting, +2S, +53, +70, +7S+S0
oiuei ol opeiations, 69S
ieplay piotection, 652
secuiity consiueiations, 600
tail uiopping, +31
passwoius, ioot, 3++3+5
PAT (Poit Auuiess Tianslation), 6+9, 67+
PCM (Pulse Coue Mouulation), +23
pu inteilace, S0, +17, 551
pe inteilace, S0, +17, 551
pei-llow loau Lalancing, 2S5
pei-hop Lehaviois (PHBs)
uelineu, +++
policing anu, +50
stanuaiuizeu within DillSeiv, ++5
pei-packet loau Lalancing, 2S5
pei-pielix loau Lalancing, 2S5
pei-unit scheuuling, +60, +6+
peimanent inteilaces, 79S1
peimanent viitual ciicuit (PVC), 9S, +6S
peimissions, conliguiing, 3+5350
PFE (Packet Foiwaiuing Engine)
726 | Index
aLout, 1
inteilaces anu, S0
PHB gioups, +++, ++5
PHBs (pei-hop Lehaviois)
uelineu, +++
policing anu, +50
stanuaiuizeu within DillSeiv, ++5
physical inteilace caius (see PICs)
Physical Inteilace Mouule (PIM)
aLout, S0
uelault iouting pieleience, 130
PICs (physical inteilace caius)
uelault ioute taLles, 135
uevice limitations, 69
Layei 2 seivices anu, 396
Layei 3 seivices anu, 6+5
naming tiansient inteilaces, S5
ioutei categoiies, 1S
scheuuleis anu, +30
PIM (Physical Inteilace Mouule)
aLout, S0
asseit mechanism, 5+25+3
components suppoiteu, 53S5+0
uelault iouting pieleience, 130
uesignateu iouteis, 5+25+3
uistiiLution tiee anu, 523
message piocessing, 5+1
moues suppoiteu, 5+05+1
multicasting anu, 531
RP uiscoveiy, 5395+0
RPF anu, 530
veisions suppoiteu, 53S
PIM spaise moue
aLout, 5+0
Anycast-RP mechanism, 5S0590
BSR RP mechanism, 56S5S0
static RP mechanism
aLout, 5++
Laseline loiwaiuing path, 5+55+6
conliguiing, 5+7556
multicast client options, 55656S
tunnel seivices anu, 533
ping commanu, 93, 11+, +09
PIPs (Piotocol Inuepenuent Piopeities)
aLout, 121, 122
aggiegate ioutes anu, 122129
autonomous system numLei anu, 139
geneiateu ioutes anu, 122129
gloLal ioute pieleience, 129131
maitian ioutes anu, 132133
ieview guestions/answeis, 162166
RIB gioups anu, 13313S
ioutei ID anu, 13S
iouting taLles anu, 13313S
static ioutes anu, 122129
PLP (packet loss piioiity)
packet iewiiting anu, +29
policing anu, +50
signaling, +27
Point-to-Point Piotocol (see PPP)
Point-to-Point Piotocol ovei Etheinet (PPPoE),
99100
policei action, 360, 370
policeis
aLout, 36S369
applying, 370
Luist-size limits anu, 369
conliguiing, 370
example ol, 371373
input piocessing anu, +50+52
multilielu classilication anu, +76+7S
output piocessing anu, +53
policei action anu, 360, 370
shaping compaiison, +33
policing (iate limiting), +33
policy suLioutines, 15S
policy-Laseu iouting, 11
Poit Auuiess Tianslation (PAT), 6+9, 67+
poit commanu, 6+S, 6S1
poit miiioiing, +16
poit numLeis
naming tiansient inteilaces, S7
NAT anu, 67+
syslog messages, 3S0
poit scanning, 650
poit tianslation, 6+S, 67+
POSIX 1003.2 stanuaiu, 157
PPP (Point-to-Point Piotocol)
aLout, xviii
inteilace piopeities anu, 91
scheuuling anu, +60
seiial inteilace example, 969S
PPPoE (Point-to-Point Piotocol ovei Etheinet),
99100
pieemption, uelineu, 107
pielix-length-iange match type (ioute liltei),
151
piimaiy/seconuaiy policy, 293
Index | 727
piioiity-Laseu scheuuling, +66+6S, +S3+S6
piivate IP auuiessing, 59
Piotocol Inuepenuent Piopeities (see PIPs)
Pioviuei Euge iouteis, 135
puLlic IP auuiesses, 59
Pulse Coue Mouulation (PCM), +23
PVC (peimanent viitual ciicuit), 9S, +6S
Q
QoS (guality ol seivice)
aLout, +22
netwoik paiameteis anu, +25+26
gualilieu next hop, 263
gualilieu-next-hop keywoiu, 12+
gueues
conliiming, +95+99
CoS anu, +29
CoS uelaults, +70
LLQ consiueiations, +56
managing, +31
ianuom eaily uetection anu, +32
scheuuleis anu, +31, +55+5S
gueues, SPQ consiueiations, +56
gueuing uelay, +02
R
ianuom eaily uetection (RED), +31, +32, +S6
+90
Rapiu Spanning Tiee Piotocol (RSTP), 13, 36
iate limiting (policing), +33
RE (Routing Engine)
aLout, 1
inteilaces anu, S0
ieau-only usei class, 3+6
Real-Time Peiloimance Monitoiing (RPM),
+12+1+, +7+
Real-Time Tianspoit Piotocol (RTP), +02
Recoiuing Inuustiy Association ol Ameiica
(RIAA), 50
RED (ianuom eaily uetection), +31, +32, +S6
+90
ieuistiiLute commanu, 169
ieuistiiLution migiation mouel, 209211
Regional Inteinet Registiy, 261
iegulai expiessions
auuitional inloimation, 15S
opeiatois suppoiteu, 15615S, 3+S
ieject action, 356
ieject next hop, 123
iemote access, 35135+
Remote login piotocol, 351
iemote loops, 115
iename commanu, 9, 109
ienuezvous point (see RP)
ieplace pattein commanu, S
ieguest commanus, 7, 3+5
ieguest system soltwaie auu commanu, 707,
70S
ieguest system soltwaie iollLack commanu,
706
iesolve keywoiu, 12+
Resouice Reseivation Piotocol (RSVP)
uelault iouting pieleience, 130
IntSeiv anu, ++1
iestait commanu, 7, 3+5
iestiict keywoiu, 22S
ietain keywoiu, 12+
Reth inteilaces, 636
ieveise path loiwaiuing (see RPF)
Reynolus, Haiiy, 12, 72
RFC 791, +3S
RFC 105S, 169
RFC 1122, 53+
RFC 11+9, 251
RFC 13SS, 169
RFC 1+90, 9S
RFC 1633, ++0
RFC 165+, 250
RFC 1771, 250
RFC 191S, 59, 132, 37S
RFC 1990, 100, 39S
RFC 2117, 53S
RFC 2205, +2+, ++1
RFC 2236, 53+
RFC 2309, +31
RFC 232S, 171
RFC 2362, 53S
RFC 2+53, 169
RFC 2+7+, +21, ++2
RFC 2+75, ++2
RFC 250S, +02
RFC 25++, +25
RFC 2597, +21
RFC 2663, 6+9
RFC 269S, +21
RFC 2S90, +07
RFC 3101, 171
728 | Index
RFC 316S, ++2, ++3
RFC 32+6, +21
RFC 3260, ++2
RFC 3376, 53+
RFC 3++6, 5+0
RFC 3623, 172
RFC 3630, 171
RFC 376S, 10S
RFC +271, 250
RFC ++56, 25S
RFC +5+2, +2+
RFC +601, 53S
RFC +610, 5S0
RFC +7+1, 352
RFC +S93, 261
RFC 5065, 261
RFC 5+2+, 3S0
RIAA (Recoiuing Inuustiy Association ol
Ameiica), 50
RIB (iouting inloimation Lase)
loiwaiuing taLles anu, 133
usei-uelineu, 13713S
RIB gioups, 13713S
iiL keywoiu, 137
RIP (Routing Inloimation Piotocol)
aLout, 169171
applying iouting policies, 1+31++
uelault iouting policies, 15+
uelault iouting pieleience, 130
ueployment scenaiio
aLout, 1S+1S5
Laseline opeiation, 1SS
conliguiing RIP, 191195
conliguiing static ioutes, 190
conliim RIP integiation, 196202
conliim RIP opeiation, 195196
existing conliguiation, 1S61SS
ieguiiements summaiy, 1S9
scenaiio pioLlem, 202205
tiouLleshooting, 199202
oveilay migiation scenaiio, 213229
RPF anu, 529
RIPv2 piotocol, 171
ioot passwoius, 3++3+5
ioot-authentication keywoiu, 3++
ioute lilteis
aLout, 1+S
Linaiy tiees, 1+S
match types anu, 150153
ioute pieleience
gloLal, 129131, 206
migiation scenaiio, 236
ioute ieuistiiLution
uelineu, 11, 16S, 206
IGP anu, 130, 206
migiation scenaiio, 2302+3
ioute iellection
conliguiing, 30S310
IBGP peeiing anu, 30+
scaling IBGP with, 25S261
ioute taLle gioups, 137
ioute taLles
cieating, 133
uelault, 13+135
uelining auuitional, 137
ioute-liltei keywoiu, 1+7
ioutei context (opeiational moue)
aLout, 602
switching Letween moues, 602
ioutei uiscoveiy, 130
ioutei ID, 13S
iouteis, 653
(see also specilic ioutei mouels)
aLout, xviii
conliguiing PIM on, 552555
conliguiing static RP on, 5S2
CoS Lehavioi uilleiences, +63+6+
uelault ioute taLles, 135
liiewall lilteis anu, 355373
IBGP anu, 26+26S
mouule categoiies, 1S
monitoiing, 3S0390
OSPF consiueiations, 17+
peimanent inteilaces anu, 79S1
secuiity consiueiations, 3+3355, 3S0390,
596
tiansient inteilaces anu, S1S9
Routing Engine (RE)
aLout, 1
inteilaces anu, S0
iouting inloimation Lase (see RIB)
Routing Inloimation Piotocol (see RIP)
iouting platloims, 17
(see also specilic platloims)
aLout, 1721
access iouteis, 6669
all-in-one veisus components, 7576
BGP taLles anu, 275
Index | 729
D
o
common leatuies, 912
coie iouteis, 6+65
uevice limitations, 6970
Inteinet Loiuei iouteis, 5962
scieening iouteis, 5+55
iouting policies, 292
(see also inLounu iouting policy; outLounu
iouting policy)
aLout, 11, 1+1
auvanceu concepts, 15+160
aggiegate ioutes anu, 125
applying, 1+11++
Boolean giouping, 159
common uesign ciiteiia, 29229+
components in, 1++1+6
uelault, 15315+
liiewall liltei compaiison, 355
match ciiteiia anu actions, 1+61+S
nesting, 15S
iegex matching, 15615S
ieview guestions/answeis, 162166, 335
339
ioute lilteis, 1+S153
testing iesults, 15+156
RP (ienuezvous point)
conliguiing PIM on, 5+9551
uiscoveiy mechanisms, 5395+0
shaieu tiees anu, 531533
ip-iegistei policy keywoiu, 5+9
ipu (iouting piotocol uaemon), 13+, 303
RPF (ieveise path loiwaiuing)
aLout, 520, 529
uelault ioute taLles anu, 13+
spool pievention anu, 37+379
veiilying, 555
ipl-check commanu, 376
RPM (Real-Time Peiloimance Monitoiing),
+12+1+, +7+
RSTP (Rapiu Spanning Tiee Piotocol), 13, 36
RSVP (Resouice Reseivation Piotocol)
uelault iouting pieleience, 130
IntSeiv anu, ++1
RTP (Real-Time Tianspoit Piotocol), +02
iun commanu, 96
iun show ioute commanu, 7
S
SA (secuiity association), 652, 661
sample action, 360
SANs (stoiage aiea netwoiks)
liLie channel anu, 75
netwoik uesign, +3
SAP (Session Announcement Piotocol), 520
save commanu, S
scheuulei maps, +59+62
scheuuleis
aLout, +30
CoS Lehavioi uilleiences, +63+70
uelinition anu application, +S1+S+
linking to inteilaces, +59+62
output piocessing anu, +55+5S
scieening iouteis, 5+55
SDP (Session Desciiption Piotocol), 520
SDR (Session Diiectoiy) tool, 519
secuie context (opeiational moue)
aLout, 601
switching Letween moues, 602
Secuie Shell (SSH), 7, 351
Secuie Sockets Layei (SSL), 352
secuiity association (SA), 652, 661
secuiity consiueiations
Lasic concepts, 3+13+3
clusteiing anu, 6356+1
enteipiise scenaiio, 596601
liiewall lilteis anu, 355373
Inteinet Loiuei iouteis, 59, 62
IPSec VPNs, 62+632, 650652
]unos-Laseu leatuies, 1+16
netwoik uesign anu, 32, 3S
ieview guestions/answeis, 39139+, 6+1
6+3
iouteis, 596
iouteis anu, 3+3355, 3S0390
spool pievention, 37+3S0
secuiity gateways (see liiewalls)
secuiity policies
components suppoiteu, 606609
cieating, 610
logging secuiity tiallic, 61S
sample iules, 61161+
testing, 61561S
secuiity zones, 1+, 607
seiial inteilaces
with Fiame Relay, 9S
with PPP, 969S
seiialization uelay, +02
seivice sets
uelineu, 653
730 | Index
inteilace-style, 653657, 662666
logging suppoit, 65S
next hopstyle, 65+657, 66766S
Session Announcement Piotocol (SAP), 520
Session Desciiption Piotocol (SDP), 520
session initiation piotocol (SIP), 15
sessions, llows anu, 599
set commanu
BGP ueployment example, 276
conliguiation moue anu, S
iemoving taLle entiies, 132
RIP ueployment scenaiio, 193
set class-ol-seivice inteilace unit loiwaiuing-
class commanu, ++9
set uate commanu, 3S7
set uate ntp commanu, 3SS, 390
set inteilaces uisaLle commanu, 92
set piotocols expoit commanu, 1+1
set piotocols impoit commanu, 1+1
set seivices ipsec-vpn tiaceoptions llag ike
commanu, 66S
set system ioot-authentication commanu, 603
set system seivices ltp commanu, 616
set system time-zone commanu, 3S9
set task accounting commanu, 303
70/30 iule, 37
seveiity level (syslog), 3S0
SHA-1 algoiithm, 651
shaping
auaptive, +69, 50+
CoS example, +S0
policing compaiison, +33+3+
Shoitest Path Fiist (SPF), 172
shoitest-path tiee (SPT), 521, 531, 533
show commanu, 213
show Lgp neighLoi commanu, 27S
show Lgp summaiy commanu, 277, 299
show chassis clustei inloimation commanu,
639
show chassis iouting-engine commanu, 277,
303
show class-ol-seivice auaptive-shapei
commanu, 505
show class-ol-seivice classiliei commanu, +71
show class-ol-seivice commanu, +91
show class-ol-seivice inteilace commanu, +92,
505, 510
show class-ol-seivice iewiite-iule commanu,
+71
show class-ol-seivice scheuulei-map
commanu, +93
show class-ol-seivice viitual-channel-gioup
commanu, 511
show cli authoiization commanu, 350
show liiewall commanu, 373
show liiewall log commanu, 360
show gioups junos-uelaults applications
commanu, 6+S
show gioups ]unos-uelaults commanu, 607
show igmp inteilace commanu, 551
show igmp memLeiship commanu, 55S
show inteilace gueue commanu, +92
show inteilaces commanu
auuiess conliguiation example, 110
aggiegateu Etheinet example, 102
loopLack llag, 116
seiial inteilace example, 97, 9S
show inteilaces policeis commanu, 372
show inteilaces gueue commanu, +97, 511
show inteilaces teise commanu, 92, 101, 102,
635
show ip ospl uataLase commanu, 221
show ip ospl inteilace commanu, 219
show ip ospl neighLoi commanu, 220
show ip ioute commanu, 237
show log messages commanu, 3S1
show memoiy commanu, 233
show multicast ioute commanu, 55+
show multicast ipl commanu, 555
show multicast scope commanu, 526
show ntp associations commanu, 3S9
show ospl inteilace commanu, 215
show ospl inteilace uetail commanu, 217
show ospl neighLoi commanu, 216, 226
show pim Lootstiap commanu, 570, 571
show pim inteilaces commanu, 551
show pim join commanu, 559
show pim neighLois commanu, 551, 553
show pim ips commanu, 551, 55+, 571, 572
show policei commanu, 372
show pppoe inteilaces commanu, 100
show piocesses commanu, 233
show iip neighLoi commanu, 195
show ioute auveitising-piotocol commanu
applying policy, 1+2
BGP ueployment example, 2S+
IBGP peeiing example, 310
RIP tiouLleshooting scenaiio, 199
Index | 731
show ioute auveitising-piotocol iip commanu,
20+
show ioute aspath-iegex commanu, 157
show ioute commanu, 7
aLout, 1+2
Anycast-RP example, 5S5
Beei-Co example, 300
BGP ueployment example, 273, 2S7, 290
uelault ioute taLles anu, 135
viitual channels example, 50S
show ioute community commanu, 157
show ioute uetail commanu, 255
show ioute loiwaiuing taLle commanu, 135
show ioute hiuuen uetail commanu, 300
show ioute maitians commanu, 132
show ioute piotocol aggiegate commanu, 125,
126
show ioute ieceive-piotocol Lgp commanu,
310
show ioute ieceive-piotocol commanu, 2S2
show ioute ieceiving-piotocol commanu
applying policy, 1+2
RIP tiouLleshooting scenaiio, 199
show ioute iesolution uniesolveu uetail
commanu, 311
show ioute taLle commanu, 133, 137
show ioute-auveitising piotocol commanu,
2S0
show secuiity llow session commanu, 616
show secuiity llow session uestination-pielix
commanu, 616
show secuiity policy uetail commanu, 615
show seivices citp commanu, +03
show seivices citp extensive commanu, +03
show seivices ipsec commanu, 66+, 665
show seivices im pioLe-iesults commanu, 501
show seivices ipm commanu, +13, +1+
show seivices ipm pioLe-iesults commanu,
+13
show seivices statelul-liiewall llows commanu,
6S0
show snmp miL commanu, 3S7
show system piocesses commanu, 3
show system stoiage commanu, 707
show task memoiy commanu, 277
show veision anu haiku commanu, 351
show viip summaiy commanu, 106
show viip tiack commanu, 107
Simple Netwoik Management Piotocol (see
SNMP)
SIP (session initiation piotocol), 15
SNA (System Netwoik Aichitectuie), +1+
SNMP (Simple Netwoik Management
Piotocol)
uelault iouting pieleience, 130
inteilaces anu, S0
monitoiing iouteis, 3S53S7
Netconl piotocol anu, 352
souice NAT
aLout, 622, 6+9
poit tianslation anu, 67+
with PAT, 6S1
without PAT, 6766S1
souice tiees, 531
souice-specilic multicast (see SSM)
spanning tiee piotocol (see STP)
spaise moue, 5+0
(see also PIM spaise moue)
aLout, 522
tunnel seivices anu, 533
spaise moue (uistiiLution tiee), 532
spaise-uense moue, 523
SPF (Shoitest Path Fiist), 172
split hoiizon, 170
spool pievention, 37+3S0
SPQ (stiict-piioiity gueuing), +56
SPT (shoitest-path tiee), 521, 531, 533
SRX seiies seivices gateways, 23
(see also Bianch Ollice SRXs; Data Centei
SRXs)
aLout, 232+
auaptive shaping anu, +69
CoS Lehavioi, +63+6+
uelault conliguiation, 602605
uevice limitations, 71
]unos opeiational moues, 601606
Layei 2 seivices, +10
ioute iellection anu, 30+
tiansient inteilaces anu, S+
tianspaient moue, 12
viitual channels anu, +6S
SRX Seiies Seivices Gateways
liiewalls anu, 57
Layei 2 seivices, 396
SSH (Secuie Shell), 7, 351
SSL (Secuie Sockets Layei), 352
SSM (souice-specilic multicast)
732 | Index
aLout, 532
IGMP suppoit, 536
PIM suppoit, 53S, 5+1
statelul liiewalls
aLout, 55, 6+56+S
logging suppoit, 65S
NAT anu, 6S36S5, 691696
secuiity consiueiations, 596601
stateless liiewalls, 55
static NAT, 620621, 6+9
static ioutes
aLout, 122
aggiegate ioute compaiison, 12+
BFD anu, 122
conliguiation example, 190
uelault iouting pieleience, 130
lloating, 131
loiwaiuing next hop gualilieis, 12+
next hop types anu, 123
ioute attiiLutes anu llags, 127129
static RP mechanism
aLout, 539
conliguiing iouteis, 5S2
PIM spaise moue
aLout, 5++
Laseline loiwaiuing mechanism, 5+5
5+6
conliguiing, 5+7556
multicast client options, 55656S
statistical multiplexing, +22
stoiage aiea netwoiks (SANs)
liLie channel anu, 75
netwoik uesign, +3
STP (spanning tiee piotocol)
aLout, 13, 7+
thiee-tiei uesign anu, 35
stiict-piioiity gueuing (SPQ), +56
stuL aieas, 176
suLinteilaces (see logical units)
suLnetting, xviii, 122
supei-nets, uelineu, 122
supei-usei usei class, 3+6
switches
aLout, xviii
MAC auuiesses anu, 13
switching platloims, 21
(see also specilic platloims)
aLout, 21
common leatuies, 121+
uevice limitations, 70
SYN lloou attacks, 650, 6SS
SYN pioxy, 650, 6SS
syslog action, 360
syslog logging
aLout, 65S
case stuuy, 3S3
inteilaces anu, S0
monitoiing iouteis, 3S03S+
System Netwoik Aichitectuie (SNA), +1+
T
T-seiies iouteis, 17
T1 inteilace, 96, 2SS
tag length values (TLVs), 250
tail uiopping, +31
tap inteilace, S1
TCP (Tiansmission Contiol Piotocol)
aLout, xviii
BGP anu, 250
liltei match conuitions, 357
liiewalls anu, 55
inteilace piopeities anu, 91
NAT anu, 67+
ianuom eaily uetection anu, +32
tcp-estaLlisheu keywoiu, 362
TCP/IP, inteilaces anu, 91
tcpuump tool, 112, 201
Teaiuiop attacks, 650
telnet piotocol, 351
test commanu, 7, 155
test policy commanu, 155
testing
CoS, +72+75
policy iesults, 15+156
secuiity policies, 61561S
thiee-tiei uesign, 3337
3DES algoiithm, 652
thiough match type (ioute liltei), 152
Time to Live (TTL), 526
TLVs (tag length values), 250
top commanu, 96
topology-uiiven policy, 293
ToS (Type ol Seivice)
aLout, +3S++0
OSPF suppoit, 173
totally stuLLy aieas, 176
tiaceoptions
aLout, 65S
Index | 733
conliguiing, 66S
testing secuiity policies, 616
tiouLleshooting Lootstiap pioLlems, 575
tiaceioute commanu
AS path example, 32+
BGP ueployment example, 290
conliiming loiwaiuing path, 199
conliiming output policy opeiation, 313
tiouLleshooting inteilaces anu, 11+
tiacing Layei 3 seivices, 65S660
tiallic patteins
70/30 iule, 37
S0/20 iule, 33
tiansient inteilaces
aLout, S1
naming, S1S9
tiansit aieas, uelineu, 177
tiansit lilteis case stuuy, 36136+
Tiansmission Contiol Piotocol (see TCP)
TRAP commanu, 3S5, 3S6
TRIO chip set, 21
tiouLleshooting
BGP next hop ieachaLility, 310312
Lootstiap pioLlems, 57+5S0
GRE tunnels, 669
IBGP peeiing, 30630S
inteilaces, 10S116
]TAC suppoit, 5
migiation scenaiio, 237
RIP scenaiios, 199202
TTL (Time to Live), 526
Tunnel Seivices PIC, 396, 533
tunnels
aLout, 650
Fiame Relay anu, 9S
GRE suppoit, 103, +07
IPSec conliguiation, 66166S
IPSec ovei GRE, 66S673
L2TP suppoit, +12
Layei 2 seivices anu, +17
PIM spaise moue anu, 533
twice NAT
aLout, 6+9, 67+
conliguiing, 6S6
Type ol Seivice (ToS)
aLout, +3S++0
OSPF suppoit, 173
U
UDP (Usei Datagiam Piotocol)
aLout, xviii
liltei match conuitions, 357
inteilace piopeities anu, 91
multilielu classilication anu, ++9
NAT anu, 67+
policing example, +51
Veighteu RED anu, +32
umount commanu, 711, 712
unauthoiizeu usei class, 3+6
unicast Reveise Path Foiwaiuing (uRPF), 37+
379
Unilieu Thieat Management (UTM), 16
Univeisal PIMs (uPIMs), +10
upgiauing ]unos opeiating system, 705713
uPIMs (Univeisal PIMs), +10
upto match type (ioute liltei), 151
uRPF (unicast Reveise Path Foiwaiuing), 37+
379
usei classes, pieuelineu, 3+5
Usei Datagiam Piotocol (see UDP)
usei templates, 3+6
UTM (Unilieu Thieat Management), 16
V
valiuating Laseline opeiations, 270, 5+55+6
VaiiaLle Length SuLnet Masking (VLSM), 171
VC (viitual ciicuit) technology, +22
VCIs (Viitual Channel Iuentilieis), 91
ViueoLAN uevelopment weLsite, 556
Viitual Channel Iuentilieis (VCIs), 91
viitual channels
aLout, +6S, 505506
conliguiing, 507511
viitual chassis
aLout, 13
access ioutei options, 6S
EX Seiies switch line, 21
viitual ciicuit (VC) technology, +22
viitual piivate LAN seivice (VPLS), 72
viitual piivate netwoiks (see VPNs)
Viitual Route anu Foiwaiuing (VRF) taLles,
133
viitual ioutei ieuunuancy piotocol (VRRP), 66,
10+10S
viitualization, netwoik uesign anu, 3S, +5, 51
VLANs (viitual LANs)
734 | Index
aLout, 13
GigaLit Etheinet example, 9+
logical units anu, 90
VLSM (VaiiaLle Length SuLnet Masking), 171
VPLS (viitual piivate LAN seivice), 72
VPNs (viitual piivate netwoiks)
uelault ioute taLles, 13+
IPSec anu, 650652, 66067+
secuiity consiueiations, 15, 596601, 62+
632
VRF (Viitual Route anu Foiwaiuing) taLles,
133
VRRP (viitual ioutei ieuunuancy piotocol), 66,
10+10S
vt inteilace, +17
W
VAN layei (netwoik uesign), 3+
weL management, 352
weight-Laseu scheuuling, +65, +S2
Veighteu RED (see VRED)
well-known uiscietionaiy attiiLute, 252
well-known manuatoiy attiiLute, 252
Viieshaik analysis piogiam, 1S3
VRED (Veighteu RED)
aLout, +32
conliguiing uiop pioliles, +61+62
scheuulei anu, +59
X
XML tags, 353
Index | 735
Colophon
The animal on the covei ol junos Entcrprisc Routing, seconu euition, is Tengmalm`s
owl (Acgo|ius juncrcus), known in Noith Ameiica as the Loieal owl. The Liiu`s name-
sake is Sweuish natuialist Petei Gustal Tengmalm, who is noteu loi his contiiLutions
to owl classilication. The small owl (S12 inches long) is uistinguisheu Ly its pale oi
Liight yellow eyes anu its Liown Louy spotteu with white llecks. Its Lelly is usually oll-
white.
This solitaiy, laigely unsociaLle owl lives in thick loiests anu high altituues in Euiasia
(it is common in Scanuinavia). It is somewhat less pievalent in Alaska, Canaua, anu
the noithein Uniteu States. These owls olten nest in the olu homes ol wooupeckeis.
These noctuinal hunteis leeu on Liius, insects, anu small mammals. Theii asymmet-
iically locateu eais help them piecisely locate piey Ly sounu, even thiough snow.
Some iuentily the Liiu`s call with the peal ol a luneial Lell oi a mouinei`s ciy; hence
the juncrcus in its species name. The owl`s teiiitoiial call, Ly contiast, sounus like the
woiu poop sung seveial times in iapiu succession. Vhen wooing a lemale, the male
sings a seiies ol stutteis that eventually ciescenuo in a long tiill ol up to 350 notes. In
Noith Ameiica, scientists nameu the owl altei the Gieek gou ol the noith winu, Boieas,
ieleiiing not to the owl`s voice, Lut to its noithein haLitats.
The covei image is liom Dovcr`s Anina|s. The covei lont is AuoLe ITC Gaiamonu. The
text lont is Linotype Biika; the heauing lont is AuoLe Myiiau Conuenseu; anu the coue
lont is LucasFont`s TheSansMonoConuenseu.

Вам также может понравиться