CCIE Professional Development Routing TCP/IP, Volume I, Second Edition
By Jeff Doyle - CCIE No. 1919, Jennifer Carroll - CCIE No. 1402
...............................................
Publisher: Cisco Pr e ss
Pub Dat e: Oct obe r 1 9 , 2 0 0 5
I SBN: 1 - 5 8 7 0 5 - 2 0 2 - 4
Pages: 9 3 6
Table of Cont ent s | I ndex
A det ailed exam inat ion of int erior rout ing prot ocols - - com plet ely updat ed in a new edit ion
A com plet e revision of t he best - selling first edit ion- - widely considered a prem ier t ext on
TCP/ I P rout ing prot ocols
A core t ext book for CCI E preparat ion and a pract ical reference for net work designers,
adm inist rat ors, and engineers
I ncludes configurat ion and t roubleshoot ing lessons t hat would cost t housands t o learn in a
classroom and num erous real- world exam ples and case st udies
Praised in it s first edit ion for it s approachable st yle and wealt h of inform at ion, t his new edit ion
provides readers a deep underst anding of I P rout ing prot ocols, t eaches how t o im plem ent
t hese prot ocols using Cisco rout ers, and brings readers up t o dat e prot ocol and im plem ent at ion
enhancem ent s. Rout ing TCP/ I P, Volum e 1, Second Edit ion, includes prot ocol changes and Cisco
feat ures t hat enhance rout ing int egrit y, secure rout ers from at t acks init iat ed t hrough rout ing
prot ocols, and provide great er cont rol over t he propagat ion of rout ing inform at ion for all t he I P
int erior rout ing prot ocols. Rout ing TCP/ I P, Volum e 1, Second Edit ion, provides a det ailed
analysis of each of t he I P int erior gat eway prot ocols ( I GPs) . I t s st ruct ure rem ains t he sam e as
t he best - selling first edit ion, t hough inform at ion wit hin each sect ion is enhanced and m odified
t o include t he new developm ent s in rout ing prot ocols and Cisco im plem ent at ions. What 's New
I n This Edit ion? The first edit ion covers rout ing prot ocols as t hey exist ed in 1998. The new
book updat es all covered rout ing prot ocols and discusses new feat ures int egrat ed in t he lat est
version of Cisco I OS Soft ware. I Pv6, it s use wit h int erior rout ing prot ocols, and it s
int eroperabilit y and int egrat ion wit h I Pv4 are also int egrat ed int o t his book. Approxim at ely 200
pages of new inform at ion are added t o t he m ain t ext , wit h som e old t ext rem oved. Addit ional
exercise and solut ions are also included.
CCIE Professional Development Routing TCP/IP, Volume I, Second Edition
By Jeff Doyle - CCIE No. 1919, Jennifer Carroll - CCIE No. 1402
...............................................
Publisher: Cisco Pr e ss
Pub Dat e: Oct obe r 1 9 , 2 0 0 5
I SBN: 1 - 5 8 7 0 5 - 2 0 2 - 4
Pages: 9 3 6
Table of Cont ent s | I ndex
Copyright
About the Authors
About the Technical Reviewers
Acknowledgments
This Book Is Safari Enabled
Icons Used in This Book
Command Syntax Conventions
Foreword
Introduction
Objectives
Audience
Changes from First Edition
Organization
Book Features
Part I: Routing Basics
Chapter 1. TCP/IP Review
TCP/IP Protocol Layers
IP Packet Header
IPv4 Addresses
Address Resolution Protocol (ARP)
Internet Control Message Protocol (ICMP)
Host-to-Host Layer
Looking Ahead
Summary Table: Chapter 1 Command Review
Recommended Reading
Review Questions
Configuration Exercises
Troubleshooting Exercises
Chapter 2. IPv6 Overview
IPv6 Addresses
IPv6 Packet Header Format
Extension Headers
ICMPv6
Neighbor Discovery Protocol
Looking Ahead
Review Questions
Chapter 3. Static Routing
Route Table
Configuring Static Routes
Troubleshooting Static Routes
Looking Ahead
Summary Table: Chapter 3 Command Review
Review Questions
Configuration Exercises
Troubleshooting Exercises
Chapter 4. Dynamic Routing Protocols
Routing Protocol Basics
Distance Vector Routing Protocols
Link State Routing Protocols
Interior and Exterior Gateway Protocols
Static or Dynamic Routing?
Looking Ahead
Recommended Reading
Review Questions
Part II: Interior Routing Protocols
Chapter 5. Routing Information Protocol (RIP)
Operation of RIP
Configuring RIP
Troubleshooting RIP
Looking Ahead
Summary Table: Chapter 5 Command Review
Recommended Reading
Review Questions
Configuration Exercises
Troubleshooting Exercises
Chapter 6. RIPv2, RIPng, and Classless Routing
Operation of RIPv2
Operation of RIPng
Configuring RIPv2
Configuring RIPng
Troubleshooting RIPv2 and RIPng
Looking Ahead
Summary Table: Chapter 6 Command Review
Recommended Reading
Review Questions
Configuration Exercises
Troubleshooting Exercises
Chapter 7. Enhanced Interior Gateway Routing Protocol (EIGRP)
The Roots of EIGRP: An Overview of IGRP
From IGRP to EIGRP
Operation of EIGRP
Configuring EIGRP
Troubleshooting EIGRP
Looking Ahead
Summary Table: Chapter 7 Command Review
Review Questions
Configuration Exercises
Troubleshooting Exercises
Chapter 8. OSPFv2
Operation of OSPF
Configuring OSPF
Troubleshooting OSPF
Looking Ahead
Summary Table: Chapter 8 Command Review
Recommended Reading
Review Questions
Configuration Exercises
Troubleshooting Exercises
Chapter 9. OSPFv3
Operation of OSPFv3
Configuring OSPFv3
Troubleshooting OSPFv3
Looking Ahead
Summary Table: Chapter 9 Command Review
Recommended Reading
Review Questions
Configuration Exercises
Chapter 10. Integrated IS-IS
Operation of Integrated IS-IS
Configuring Integrated IS-IS
Troubleshooting Integrated IS-IS
Looking Ahead
Summary Table: Chapter 10 Command Review
Review Questions
Configuration Exercises
Troubleshooting Exercises
Part III: Route Control and Interoperability
Chapter 11. Route Redistribution
Principles of Redistribution
Configuring Redistribution
Looking Ahead
Summary Table: Chapter 11 Command Review
Review Questions
Configuration Exercises
Troubleshooting Exercises
Chapter 12. Default Routes and On-Demand Routing
Fundamentals of Default Routes
Fundamentals of On-Demand Routing
Configuring Default Routes and ODR
Looking Ahead
Summary Table: Chapter 12 Command Review
Review Questions
Chapter 13. Route Filtering
Configuring Route Filters
Looking Ahead
Summary Table: Chapter 13 Command Review
Configuration Exercises
Troubleshooting Exercises
Chapter 14. Route Maps
Basic Uses of Route Maps
Configuring Route Maps
Looking Ahead
Summary Table: Chapter 14 Command Review
Review Questions
Configuration Exercises
Troubleshooting Exercise
Part IV: Appendixes
Appendix A. Tutorial: Working with Binary and Hex
Working with Binary Numbers
Working with Hexadecimal Numbers
Appendix B. Tutorial: Access Lists
Access List Basics
Standard IP Access Lists
Extended IP Access Lists
Calling the Access List
Reflexive Access Lists
Keyword Alternatives
Named Access Lists
Prefix Lists
Filter Placement Considerations
Access List Monitoring and Accounting
Appendix C. CCIE Preparation Tips
Laying the Foundations
Following the Certification Path
Hands-On Experience
Intensifying the Study
The Final Six Months
Exam Day
Appendix D. Answers to Review Questions
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Chapter 9
Chapter 10
Chapter 11
Chapter 12
Chapter 14
Appendix E. Solutions to Configuration Exercises
Chapter 1
Chapter 3
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Chapter 9
Chapter 10
Chapter 11
Chapter 13
Chapter 14
Appendix F. Solutions to Troubleshooting Exercises
Chapter 1
Chapter 3
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Chapter 10
Chapter 11
Chapter 13
Chapter 14
Index
Copyright
CCIE Professional Development Routing TCP/IP Volume
I Second Edition
Jeff Doyle, CCI E No. 1919, Jennifer Carroll, CCI E No. 1402
Copyright © 2006 Cisco Syst em s, I nc.
Published by:
Cisco Press
800 East 96t h St reet
I ndianapolis, I N 46240 USA
All right s reserved. No part of t his book m ay be reproduced or t ransm it t ed in any form or by any
m eans, elect ronic or m echanical, including phot ocopying, recording, or by any inform at ion
st orage and ret rieval syst em , wit hout writ t en perm ission from t he publisher, except for t he
inclusion of brief quot at ions in a review.
Print ed in t he Unit ed St at es of Am erica 1 2 3 4 5 6 7 8 9 0
First Print ing Oct ober 2005
Library of Congress Cat aloging- in- Publicat ion Num ber: 2004104363
Trademark Acknowledgments
All t erm s m ent ioned in t his book t hat are known t o be t radem arks or service m arks have been
appropriat ely capit alized. Cisco Press or Cisco Syst em s, I nc. cannot at t est t o t he accuracy of t his
inform at ion. Use of a t erm in t his book should not be regarded as affect ing t he validit y of any
t radem ark or service m ark.
Warning and Disclaimer
This book is designed t o provide inform at ion about rout ing TCP/ I P. Every effort has been m ade
t o m ake t his book as com plet e and as accurat e as possible, but no warrant y or fit ness is im plied.
The inform at ion is provided on an " as is" basis. The aut hors, Cisco Press, and Cisco Syst em s,
I nc. shall have neit her liabilit y nor responsibilit y t o any person or ent it y wit h respect t o any loss
or dam ages arising from t he inform at ion cont ained in t his book or from t he use of t he discs or
program s t hat m ay accom pany it .
The opinions expressed in t his book belong t o t he aut hor and are not necessarily t hose of Cisco
Syst em s, I nc.
Corporate and Government Sales
Cisco Press offers excellent discount s on t his book when ordered in quant it y for bulk purchases
or special sales.
For m ore inform at ion please cont act : U.S. Cor por a t e a n d Gove r n m e n t Sa le s 1- 800- 382- 3419
corpsales@pearsont echgroup.com
For sales out side t he U.S. please cont act : I n t e r n a t ion a l Sa le s int ernat ional@pearsoned.com
Feedback Information
At Cisco Press, our goal is t o creat e in- dept h t echnical books of t he highest qualit y and value.
Each book is craft ed wit h care and precision, undergoing rigorous developm ent t hat involves t he
unique expert ise of m em bers from t he professional t echnical com m unit y.
Readers' feedback is a nat ural cont inuat ion of t his process. I f you have any com m ent s regarding
how we could im prove t he qualit y of t his book, or ot herwise alt er it t o bet t er suit your needs,
you can cont act us t hrough e- m ail at feedback@ciscopress.com . Please m ake sure t o include t he
book t it le and I SBN in your m essage.
We great ly appreciat e your assist ance.
Publisher
John Wait
Edit or- in- Chief
John Kane
Execut ive Edit or
Bret t Bart ow
Cisco Represent at ive
Ant hony Wolfenden
Cisco Press Program Manager
Jeff Brady
Product ion Manager
Pat rick Kanouse
Developm ent Edit or
Andrew Cupp
Senior Proj ect Edit or
San Dee Phillips
Copy Edit or
I nt eract ive Com posit ion Corporat ion
Technical Edit ors
Frank Knox, St even Edward Moore,
Rena Yang
Edit orial Assist ant
Tam m i Barnet t
Book and Cover Designer
Louisa Adair
Com posit ion
I nt eract ive Com posit ion Corporat ion
I ndexer
Tim Wright
Cor por a t e H e a dqu a r t e r s
Cisco Syst em s, I nc.
170 West Tasm an Drive
San Jose, CA 95134- 1706
USA
w w w .cisco.com
Tel: 408 526- 4000
800 553- NETS ( 6387)
Fax: 408 526- 4100
Eu r ope a n H e a dqu a r t e r s
Cisco Syst em s I nt ernat ional BV
Haarlerbergpark
Haarlerbergw eg 13- 19
1101 CH Am st erdam
The Net herlands
www- europe.cisco.com
Tel: 31 0 20 357 1000
Fax: 31 0 20 357 1100
Am e r ica s H e a dqu a r t e r s
Cisco Syst em s, I nc.
170 West Tasm an Drive
San Jose, CA 95134- 1706
USA
w w w .cisco.com
Tel: 408 526- 7660
Fax: 408 527- 0883
Asia Pa cific H e a dqu a r t e r s
Cisco Syst em s, I nc.
Capit al Tow er
168 Robinson Road
# 22- 01 t o # 29- 01
Singapore 068912
w w w .cisco.com
Tel: + 65 6317 7777
Fax: + 65 6317 7799
Cisco Syst em s has m ore t han 200 offices in t he following count ries and regions. Addresses,
phone num bers, and fax num bers are list ed on t he Cisco.com W e b sit e a t
w w w .cisco.com / go/ office s.
Argent ina • Aust ralia • Aust ria • Belgium • Brazil
• Bulgaria • Canada • Chile • China PRC •
Colom bia • Cost a Rica • Croat ia • Czech Republic Denm
•
ark • Dubai, UAE • Finland • France •
Germ any • Greece • Hong Kong SAR • Hungary • I ndia
• I ndonesia • I reland • I srael • I t aly •
Japan • Korea • Luxem bourg • Malaysia • Mexico • eTh
Net herlands • New Zealand • Norway •
Peru • Philippines • Poland • Port ugal • Puert o Ric
o • Rom ania • Russia • Saudi Arabia •
Scot land • Singapore • Slovakia • Slovenia • SoutAfrica
h
• Spain • Sweden • Swit zerland •
Taiwan • Thailand • Turkey • Ukraine • Unit ed Kingd
om • Unit ed St at es • Venezuela • Viet nam •
Zim babwe
Copyright © 2003 Cisco Syst em s, I nc. All right s reserved. CCI P, CCSP, t he Cisco Arrow logo, t he
Cisco Powered Net work m ark, t he Cisco Syst em s Verified logo, Cisco Unit y, Follow Me Browsing,
Form Share, iQ Net Readiness Scorecard, Net working Academ y, and Script Share are t radem arks
of Cisco Syst em s, I nc.; Changing t he Way We Work, Live, Play, and Learn, The Fast est Way t o
I ncrease Your I nt ernet Quot ient , and iQuick St udy are service m arks of Cisco Syst em s, I nc.; and
Aironet , ASI ST, BPX, Cat alyst , CCDA, CCDP, CCI E, CCNA, CCNP, Cisco, t he Cisco Cert ified
I nt ernet work Expert logo, Cisco I OS, t he Cisco I OS logo, Cisco Press, Cisco Syst em s, Cisco
Syst em s Capit al, t he Cisco Syst em s logo, Em powering t he I nt ernet Generat ion,
Ent erprise/ Solver, Et herChannel, Et herSwit ch, Fast St ep, GigaSt ack, I nt ernet Quot ient , I OS,
I P/ TV, iQ Expert ise, t he iQ logo, Light St ream , MGX, MI CA, t he Net workers logo, Net work
Regist rar, Packet , PI X, Post - Rout ing, Pre- Rout ing, Rat eMUX, Regist rar, SlideCast , SMARTnet ,
St rat aView Plus, St rat m , Swit chProbe, TeleRout er, TransPat h, and VCO are regist ered
t radem arks of Cisco Syst em s, I nc. and/ or it s affiliat es in t he U.S. and cert ain ot her count ries.
All ot her t radem arks m ent ioned in t his docum ent or Web sit e are t he propert y of t heir respect ive
owners. The use of t he word part ner does not im ply a part nership relat ionship bet ween Cisco
and any ot her com pany. ( 0303R)
Print ed in t he USA
Dedications
I would like t o dedicat e t his book t o m y wife, Sara, and m y children, Anna, Carol, Jam es,
and Kat herine.
Jeff
I would like t o dedicat e t his book t o m y husband, Mike, and sons, Mit chell and Jonat han.
Their pat ience and support helped m e com plet e t his book.
Jennifer
About the Authors
Je ff D oyle ( CCI E No. 1919) specializes in I P rout ing prot ocols, MPLS, and I Pv6. He has designed
or assist ed in t he design of large- scale I P service provider net works t hroughout Nort h Am erica,
Europe, Japan, Korea, and t he People's Republic of China. Jeff has present ed num erous
corporat e sem inars, and has also spoken at NANOG, JANOG, APRI COT, and at I Pv6 Forum
conferences. Jeff holds a BA from Mem phis St at e Universit y, and st udied Elect rical Engineering
at t he Universit y of New Mexico. Jeff lives in Denver, Colorado.
Je n n ife r Ca r r oll ( CCI E No. 1402) is an independent net work consult ant in Redm ond,
Washingt on. She has designed, im plem ent ed, and opt im ized m any TCP/ I P net works, and has
developed and t aught a variet y of net working and int ernet working courses on rout ing prot ocols
and Cisco rout ers over t he past 15 years. Jennifer can be cont act ed at j ennifer.carroll@ieee.org.
About the Technical Reviewers
Fr a n k Kn ox , Chief Technical Officer, has been wit h Skyline Com put er for a lit t le over six years.
He is a dual CCI E ( CCI E No. 3698: SNA/ I P and Rout ing/ Swit ching) as well as a CCSI . I n addit ion
t o his CTO responsibilit ies, Frank t eaches several advanced Cisco- relat ed courses, including a
one- week CCI E Lab Preparat ion Workshop. He is considered t o be an expert in m ainfram e
at t ached rout er t echnologies and in t he t echnologies and issues associat ed wit h int egrat ed
net working ( for exam ple, SNA/ I P and Voice/ Dat a) . He has m ore t han 37 years of net working
experience wit h I BM, GTE ( Verizon) Direct ories, and Skyline Com put er Corp. This experience
includes field service, field support , product planning, m anagem ent , and all facet s of net working
educat ion. I n addit ion, he developed and t aught several courses for t he Universit y of Dallas
Telecom m unicat ions MBA program . Frank also has an MS degree in Telecom m unicat ions from
Pace Universit y ( 4.0 GPA) .
Aft er working in various roles as an engineer wit hin Cisco for t he past 6.5 years, St e ve n
Edw a r d M oor e t ransit ioned t o t he I P Rout ing Prot ocol Scalabilit y Team . There, his focus
encom passes all aspect s of ext ending net work and prot ocol scalabilit y: considering new feat ures
and opt im izat ions t o t he prot ocol archit ect ure, designing t est s t o m easure current prot ocol
scalabilit y, working wit h cust om ers t o im plem ent scaling funct ionalit y in t heir net work, and
part icipat ing in event s such as Net workers t o educat e ot hers on how t o enhance t heir net work's
perform ance and scalabilit y from t he rout ing perspect ive.
Re n a Ya n g is a soft ware engineer at Cisco Syst em s. She has m ore t han six years of experience
im plem ent ing code in Cisco I OS. She current ly works on I S- I S. Before t his, she focused on I Pv4,
UDP, access list s, policy rout ing, and rout ing infrast ruct ure. Rena holds a bachelor's of science
and m ast ers of engineering in com put er science from MI T.
Acknowledgments
Many t hanks t o Bret t Bart ow, Chris Cleveland, Andrew Cupp, San Dee Phillips, and all of t he st aff
of Cisco Press who m ade t his book possible.
The t echnical edit ors, St even Moore, Rena Yang and Frank Knox, did a fant ast ic j ob. We want t o
t hank t hem for t heir out st anding advice and recom m endat ions.
We want t o t hank Frank Knox, Carl Pike, Chris Tonini, and t he rest of t he em ployees of Skylabs
net works. Skylabs' lab set up and access t o t he lab is easy t o use and had everyt hing we needed
t o com plet e all t he configurat ions and case st udies in t his book.
This Book Is Safari Enabled
The Safari ® Enabled icon on t he cover of your favorit e t echnology book m eans t he book is
available t hrough Safari Bookshelf. When you buy t his book, you get free access t o t he online
edit ion for 45 days.
Safari Bookshelf is an elect ronic reference library t hat let s you easily search t housands of
t echnical books, find code sam ples, download chapt ers, and access t echnical inform at ion
whenever and wherever you need it .
To gain 45- day Safari Enabled access t o t his book:
Go t o ht t p: / / www.ciscopress.com / safarienabled
Ent er t he I SBN of t his book ( shown on t he back cover, above t he bar code)
Log in or Sign up ( sit e m em bership is required t o regist er your book)
Ent er t he coupon code MSJJ- PPVL- 4EMT- TVK8- 7JDF
I f you have difficult y regist ering on Safari Bookshelf or accessing t he online edit ion, please em ail cust om er- service@safaribooksonline.com .
Icons Used in This Book
Command Syntax Conventions
The convent ions used t o present com m and synt ax in t his book are t he sam e convent ions used in
t he I OS Com m and Reference. The Com m and Reference describes t hese convent ions as follows:
Boldfa ce indicat es com m ands and keywords t hat are ent ered lit erally as shown. I n act ual
configurat ion exam ples and out put ( not general com m and synt ax) , boldface indicat es
com m ands t hat are m anually input by t he user ( such as a sh ow com m and) .
I t alics indicat e argum ent s for which you supply act ual values.
Vert ical bars ( | ) separat e alt ernat ive, m ut ually exclusive elem ent s.
Square bracket s [ ] indicat e opt ional elem ent s.
Braces { } indicat e a required choice.
Braces wit hin bracket s [ { } ] indicat e a required choice wit hin an opt ional elem ent .
Foreword
I n 1976, when I saw m y first Arpanet I MP at Digit al Equipm ent Corporat ion, net works as we
know t hem t oday were in t heir infancy. SNA, XNS, and DECnet were under early developm ent ,
and packet swit ching versus circuit swit ching was t he hot t opic of t he day. Those of us involved
in t he design of t he swit ching and rout ing algorit hm s were dealing wit h rout ers ( alt hough we
didn't call t hem t hat ) t hat had 64 kilobyt es of m em ory, dat a link of 56 kilobit s were considered
blindingly fast , and net works wit h 256 nodes were big enough t hat if you were t he salesm an who
sold t hose 256 com put ers, you would ret ire fabulously wealt hy.
Thirt y years is a long t im e, and t oday t he individual net works t hat m ake up t he I nt ernet cont ain
t housands or t ens of t housands of nodes, while t he I nt ernet as a whole cont ains hundreds of
m illions of com put ers. Most st riking in t he evolut ion over t his hum an generat ion is t hat t he
foundat ions of t he I nt ernet laid down in t he TCP/ I P prot ocol suit e have survived m ost ly int act
t hrough four or m ore generat ions of com put ing archit ect ures, t hree com plet e generat ions of
operat ing syst em t echnology, and an increase of five orders of m agnit ude in t ransm ission
speeds.
Yet , we st ill t reat rout ing in packet - swit ched net works as a black art . Why is t hat ?
First , designing robust , scalable dist ribut ed algorit hm s is hard. Despit e our best int ent ions t o
m ake t hem sim ple, com plexit y creeps in t o deal wit h t he inevit able special cases, opt im izat ions,
peculiar t opologies, and link t echnologies one encount ers. Because a " fork lift upgrade" of an
ent ire net work is rarely feasible, we have m ult iple generat ions of t echnology present
sim ult aneously, and we m ust m aint ain backward- com pat ibilit y wit h essent ially no disrupt ion t o
deployed services. As policies governing t he rout ing of packet s becom e m ore sophist icat ed, our
abilit y t o devise aut om at ed discovery and configurat ion procedures get s overwhelm ed, and we
fall back on m anual configurat ion and perform ance t uning t echniques. Finally, as t he
environm ent in which t hese net works are operat ed has evolved from a cooperat ive one where
t rust was im plicit t o one in which t he net work is subj ect t o bot h inside and out side at t ack,
designing and deploying rout ing syst em s t hat can be m ade secure has becom e an urgent
priorit y.
Rout ing TCP/ I P t ackles t his black art com prehensively. The present Volum e 1 covers all t he
needed fundam ent als of TCP/ I P net works and gives you all t he t ools needed t o underst and how
rout ing is accom plished wit hin a single adm inist rat ive region of t he I nt ernet . St raight forward
ideas of packet - swit ched rout ing are present ed first in t he chapt ers on addressing and st at ic
rout ing. The m ost popular I GPsRI P, EGRP, OSPF, and I SI Sare covered in dept h. Advanced t opics
in rout e redist ribut ion, rout e filt ering, and policy rout ing round out Volum e 1.
This second edit ion also adds essent ial m at erial on I Pv6 as well as bringing all t he m at erial up t o
dat e wit h exam ples and configurat ions for t he lat est releases of Cisco I OS.
For anyone want ing a com prehensive underst anding of how rout ing in TCP/ I P net works really
works, from t he design principles of rout ing algorit hm s, t o t he evolut ion of addressing schem es,
t o t he pract ical aspect s of designing and configuring t he rout ing of large aut onom ous syst em s,
t his is t he book for you.
David Oran
Cisco Fellow
Introduction
Rout ing is an essent ial elem ent of all but t he sm allest dat a com m unicat ions net works. At one
level, rout ing and t he configurat ion of rout ers are quit e sim ple. But as net works grow in size and
com plexit y, rout ing issues can becom e at once bot h large and subt le. Perversely, perhaps, we
are grat eful for t he difficult problem s large- scale rout ing can present as net work syst em s
consult ant s, t hese problem s are our bread and but t er. Wit hout t hem , t he phrase " You want fries
wit h t hat ?" could be an unfort unat e part of our daily vocabulary.
Cisco Cert ified I nt ernet work Expert s are widely recognized for t heir abilit y t o design,
t roubleshoot , and m anage large net works. This recognit ion com es from t he fact t hat you cannot
becom e a CCI E by at t ending a few classes and t hen regurgit at ing som e m em orized fact s ont o a
writ t en t est . A CCI E has proven expert ise in an int ense, fam ously difficult hands- on lab exam .
Objectives
This book is t he first of t wo volum es t hat focuses on TCP/ I P rout ing issues. Early in t he writ ing of
t he first edit ion, Kim Lew, form er Cisco Syst em s program m anager, said, " Our obj ect ive is t o
m ake CCI Es, not t o m ake people who can pass t he CCI E lab." We ent irely agree wit h t hat
st at em ent and have used it as a guiding principle t hroughout t he writ ing of t his book. Alt hough
t he book includes m any case st udies and exercises t o help you prepare for t he CCI E lab, m y
prim ary obj ect ive is t o increase your underst anding of I P rout ingbot h on a generic level and as it
is im plem ent ed on Cisco rout ers.
Audience
The audience for t his book is any net work designer, adm inist rat or, or engineer who needs a full
underst anding of t he int erior rout ing prot ocols of TCP/ I P. Alt hough t he pract ical aspect s of t he
book focus on t he Cisco I OS, t he inform at ion is applicable t o any rout ing plat form .
The book is not only for readers who plan t o becom e CCI Es, but for people who wish t o advance
t heir knowledge of TCP/ I P rout ing. These readers will fall int o one of t hree cat egories:
The " beginners" who have som e basic net working knowledge and wish t o begin a deep
st udy of net working.
The int erm ediat e- level net working professionals who have experience wit h rout ers, Cisco or
ot herwise, and plan t o advance t hat experience t o t he expert level.
The highly experienced net working expert s. These individuals have ext ensive hands- on
expert ise wit h Cisco rout ers and are ready t o t ake t he CCI E lab; however, t hey want a
st ruct ured review and series of exercises for verificat ion and validat ion.
CCI E Professional Developm ent : Rout ing TCP/ I P, Volum e I focuses prim arily on int erm ediat elevel net working professionals while offering t o beginners a st ruct ured out line of fundam ent al
inform at ion and t o expert s t he required challenges t o hone t heir skills.
Changes from First Edition
There are several fact ors influencing t he changes cont ained in t his second edit ion. The first
fact or is t he CCI E it self. When I ( Jeff) wrot e t he first edit ion of t his book, t he CCI Especifically
what is now called t he Rout ing and Swit ching specialt y of t he CCI Ewas t he only cert ificat ion
Cisco Syst em s offered. Now, t here is a series of cert ificat ions creat ing a pat h t o t he CCI E at t he
pinnacle. Moreover, t he t ypical net working professional is m ore knowledgeable t han in 1997.
Given t his, we have elim inat ed t he first chapt er of t he original book, which covered such very
basic concept s as t he definit ion of bridges and rout ers and net work addresses. ( When was t he
last t im e you even saw a bridge in a net work?)
The second fact or influencing t he changes in t his edit ion is t he changes in t he Cisco Syst em s
I OS. I GRP, which was frequent ly used when t he first edit ion was writ t en, is now a legacy
prot ocol whose m ain significance is as t he ancest or of EI GRP. Therefore t he I GRP chapt er of t he
first edit ion has been elim inat ed and I GRP is covered for hist orical perspect ive early in t he EI GRP
chapt er. The I OS com m and suit e it self has expanded t o accom m odat e new funct ions and
opt ions; we have m ade every effort t o include t he com m ands and prot ocol ext ensions t hat did
not exist in t he lat e 1990s.
Last ly, a prot ocol t hat exist ed m ost ly only in proposal form in 1997I Pv6is now in t he early st ages
of worldwide deploym ent . You can expect t o need a det ailed knowledge of t his prot ocol and t he
ext ensions t o I P rout ing prot ocols t hat support it in t he near fut ure, if not already, so t his second
edit ion delves deeply int o rout ing I Pv6.
Ot her changes in t his edit ion are sem ant ic. For exam ple, in t he first edit ion, I ( Jeff) m ade a point
of different iat ing bet ween a " net work" as a dat a link and an " int ernet work" as a set of net works
connect ed by rout ers. Alt hough t hat t erm inology is cert ainly accurat e, it is clum sy, and
" int ernet work" is seldom used t hese days. I nst ead, " net work" usually refers t o everyt hing from a
local link t o worldwide aut onom ous syst em s operat ed by t he likes of Level 3, NTT, and Sprint .
We have at t em pt ed t o bring t he t erm inology in t his edit ion up t o m odern, com m on usage.
Organization
The 14 chapt ers of t he book are divided int o t hree part s.
Part I , " Rout ing Basics," exam ines t he basics of I Pv4 and I Pv6, and t he basics of rout ing.
Alt hough m ore advanced readers m ay wish t o skip t he first chapt er, we recom m end t hat t hey at
least skim Chapt er 3, " St at ic Rout ing," and Chapt er 4, " Dynam ic Rout ing Prot ocols." And, of
course, if you are not yet fam iliar wit h I Pv6, Chapt er 2, " I Pv6 Overview," is a m ust - read.
Part I I , " I nt erior Rout ing Prot ocols," covers t he I P I nt erior Gat eway Prot ocols. Each prot ocolspecific chapt er begins wit h a discussion of t he t heory, m echanics, and param et ers of t he
prot ocol. This general overview is followed by case st udies on configuring and t roubleshoot ing
t he prot ocol using Cisco Syst em s' I OS in various net work t opologies.
The Ext erior Gat eway Prot ocol, BGP, and t opics such as m ult icast rout ing, Qualit y of Service,
rout er securit y and m anagem ent , and Net work Address Translat ion, are covered in " Rout ing
TCP/ I P, Volum e I I ."
Part I I I , " Rout e Cont rol and I nt eroperabilit y," exam ines t he t ools available for creat ing and
m anaging int eroperabilit y wit h m ult iple I P rout ing prot ocols, and also such t ools as default
rout es and rout e filt ering. As such, t he chapt ers of t his last part provide an int roduct ion t o t he
t ools necessary for building t he com plex rout ing policies int roduced in Volum e I I . These
chapt ers, like t he ones in Part I I , begin wit h concept s and conclude wit h case st udies.
Book Features
Most chapt ers conclude wit h a set of review quest ions, configurat ion exercises, and
t roubleshoot ing exercises. The review quest ions focus on t he t heoret ical aspect s of t he chapt er
t opic, whereas t he configurat ion and t roubleshoot ing exercises address Cisco- specific aspect s of
t he chapt er t opic.
Also at t he end of each chapt er is a t able wit h a brief descript ion of all im port ant Cisco I OS
com m ands used in t hat chapt er. The convent ions used t o present t hese com m ands are t he sam e
convent ions used in t he I OS Com m and Reference and present ed earlier in t his int roduct ion.
Part I: Routing Basics
Chapt er 1 TCP/ I P Review
Chapt er 2 I Pv6 Overview
Chapt er 3 St at ic Rout ing
Chapt er 4 Dynam ic Rout ing Prot ocols
Chapter 1. TCP/IP Review
This chapt er covers t he following subj ect s:
TCP/ I P Prot ocol Layers
I P Packet Header
I Pv4 Addresses
Address Resolut ion Prot ocol ( ARP)
I nt ernet Cont rol Message Prot ocol ( I CMP)
Host - t o- Host Layer
Given t hat t he t it le of t his book is Rout ing TCP/ I P, it is fit t ing t o begin wit h a review of TCP/ I P
before get t ing int o how t o rout e it . Presum ably, if you are preparing for a Cisco Cert ified
I nt ernet work Expert ( CCI E) exam inat ion, or have j ust bought t his book as a rout ing reference,
you already know m ost or all of t he inform at ion in t his chapt er. But reviews never hurt and
som et im es help, so here you have it .
The purpose of t his chapt er is t o review t he prot ocols t hat enable, cont rol, or cont ribut e t o t he
rout ing of TCP/ I P, not t o do an in- dept h st udy of t he TCP/ I P prot ocol suit e. Several books on t he
recom m ended reading list at t he end of t he chapt er cover t he subj ect in dept h. Read at least
one.
Conceived in t he early 1970s by Vint Cerf and Bob Kahn, TCP/ I P and it s layered prot ocol
archit ect ure predat es t he I SO's Open Syst em I nt erconnect ion ( OSI ) reference m odel. A brief
review of TCP/ I P's layers will be useful in underst anding how t he various funct ions and services
exam ined in t his chapt er int errelat e.
TCP/IP Protocol Layers
Figure 1- 1 shows t he TCP/ I P prot ocol suit e in relat ionship t o t he OSI reference m odel. [ 1] The
net work int erface layer, which corresponds t o t he OSI physical and dat a link layers, is not
act ually part of t he specificat ion. However, it has becom e a de fact o layer eit her as shown in
Figure 1- 1 or as separat e physical and dat a link layers. I t is described in t his sect ion in t erm s of
t he OSI physical and dat a link layers.
[1]
The OSI protocol suite itself has become, with some rare exceptions, a relic of early Internet history. Its current
contribution to networking technology seems to be mainly limited to the usefulness of its reference model in illustrating
modular protocol suites to networking studentsand, of course, the IS-IS routing protocol still widely used in large service
provider and carrier networks.
Figu r e 1 - 1 . TCP/ I P pr ot ocol su it e .
The physical layer cont ains t he prot ocols relat ing t o t he physical m edium on which TCP/ I P will be
com m unicat ing. Officially, t he prot ocols of t his layer fall wit hin four cat egories t hat t oget her
describe all aspect s of physical m edia:
Elect rical/ opt ical prot ocols describe signal charact erist ics such as volt age or phot onic levels,
bit t im ing, encoding, and signal shape.
Mechanical prot ocols are specificat ions such as t he dim ensions of a connect or or t he
m et allic m akeup of a wire.
Funct ional prot ocols describe what som et hing does. For exam ple, " Request t o Send" is t he
funct ional descript ion of pin 4 of an EI A- 232- D connect or.
Procedural prot ocols describe how som et hing is done. For exam ple, a binary 1 is
represent ed on an EI A- 232- D lead as a volt age m ore negat ive t han 3 volt s.
The dat a link layer cont ains t he prot ocols t hat cont rol t he physical layer: how t he m edium is
accessed and shared, how devices on t he m edium are ident ified, and how dat a is fram ed before
being t ransm it t ed on t he m edium . Exam ples of dat a- link prot ocols are I EEE 802.3/ Et hernet ,
Fram e Relay, ATM, and SONET.
The int ernet layer, corresponding t o t he OSI net work layer, is prim arily responsible for enabling
t he rout ing of dat a across logical net work pat hs by defining a packet form at and an addressing
form at . This layer is, of course, t he one wit h which t his book is m ost concerned.
The host - t o- host layer , corresponding t o t he OSI t ransport layer, specifies t he prot ocols t hat
cont rol t he int ernet layer, m uch as t he dat a link layer cont rols t he physical layer. Bot h t he host t o- host and dat a link layers can define such m echanism s as flow and error cont rol. The
difference is t hat while dat a- link prot ocols cont rol t raffic on t he dat a linkt he physical m edium
connect ing t wo devicest he t ransport layer cont rols t raffic on t he logical linkt he end- t o- end
connect ion of t wo devices whose logical connect ion t raverses a series of dat a links.
The applicat ion layer corresponds t o t he OSI session, present at ion, and applicat ion layers.
Alt hough som e rout ing prot ocols such as Border Gat eway Prot ocol ( BGP) and rout ing
I nform at ion Prot ocol ( RI P) reside at t his layer, [ 2] t he m ost com m on services of t he applicat ion
layer provide t he int erfaces by which user applicat ions access t he net work.
[2]
BGP is an application layer protocol because it uses TCP to transport its messages, and RIP because it uses UDP for the
same purposes. Other routing protocols such as OSPF are said to operate at the internet layer because they encapsulate
their messages directly into IP packets.
A funct ion com m on t o t he prot ocol suit e of Figure 1- 1 and any ot her prot ocol suit e is
m ult iplexing bet ween layers. Many applicat ions m ight use a service at t he host - t o- host layer,
and m any services at t he host - t o- host layer m ight use t he int ernet layer. Mult iple prot ocol suit es
( I P, I PX, and AppleTalk, for exam ple) can share a physical link via com m on dat a- link prot ocols.
IP Packet Header
Figure 1- 2 shows t he form at of t he I P packet header, specified in RFC 791. Most fields in t his
packet have som e im port ance t o rout ing.
Figu r e 1 - 2 . I P pa ck e t pr ot ocol.
Version ident ifies t he I P version t o which t he packet belongs. This four- bit field is set t o binary
0100 t o indicat e version 4 ( I Pv4) or binary 0110 t o indicat e version 6 ( I Pv6) . This chapt er is
concerned prim arily wit h I Pv4, whereas Chapt er 2, " I Pv6 Overview," focuses on I Pv6. Table 1- 1
shows all current ly assigned version num bers, along wit h a few of t he relevant RFCs. All versions
ot her t han 4 and 6 ( built on an earlier proposal called Sim ple I nt ernet Prot ocol, or SI P, which
also carried a version num ber of 6) now exist only as " cult ure," and it will be left t o t he curious
t o read t heir cit ed RFCs.
Ta ble 1 - 1 . I P ve r sion n u m be r s.
N u m be r
V e r sion
0
Reser v ed
13
Unassigned
4
I nt ernet Prot ocol version 4 ( I Pv4)
RFC
791
N u m be r
V e r sion
RFC
5
ST Dat agram Mode
1190
6
Sim ple I nt ernet Prot ocol ( SI P)
6
I nt ernet Prot ocol version 6 ( I Pv6)
1883
7
TP/ I X
1475
8
P I nt ernet Prot ocol ( PI P)
1621
9
TCP and UDP over Bigger Addresses
( TUBA)
1347
1014
Unassigned
15
Reser v ed
Header Lengt h is a four- bit field t hat t ells, as t he nam e im plies, t he lengt h of t he I P header in
32- bit words. This field is included because t he Opt ions field ( described lat er in t his sect ion) can
vary in size. The m inim um lengt h of t he I P header is 20 oct et s, and t he opt ions m ight increase
t his size up t o a m axim um of 60 oct et st he m axim um lengt h in 32- bit words t hat can be
described by t his field.
Type of Service ( TOS) is an eight - bit field t hat can be used for specifying special handling of t he
packet . This field act ually can be broken down int o t wo subfields: Precedence and TOS.
Precedence set s a priorit y for t he packet , t he way a package m ight be sent overnight , t wo- day
delivery, or general post . TOS allows t he select ion of a delivery service in t erm s of t hroughput ,
delay, reliabilit y, and m onet ary cost . Alt hough t his field is not com m only used ( all t he bit s will
usually be set t o zero) , early specificat ions of t he Open Short est Pat h First ( OSPF) prot ocol called
for TOS rout ing. Also, t he Precedence bit s are occasionally used in qualit y of service ( QoS)
applicat ions. Part ( a) of Figure 1- 3 sum m arizes t he eight TOS bit s; for m ore inform at ion, see
RFC 1340 and RFC 1349.
Figu r e 1 - 3 . Type of Se r vice ( a ) or D iffSe r v a n d ECN ( b) fie ld.
[View full size image]
I n recent years, t he ToS field has been redefined as a part of t he Different iat ed Services
( DiffServ) fram ework. [ 3] This fram ework creat es a m uch m ore flexible handling of I P packet s
t han was allowed by t he relat ively rigid ToS definit ions. Wit h DiffServ, you can define service
classes on a rout er and t hen sort packet s int o t hese classes. The rout er can t hen queue and
forward packet s wit h different levels of priorit y, according t o t heir classificat ion. Each queuing
and forwarding t reat m ent is called a Per- Hop Behavior ( PHB) . While DiffServ defines t he
fram ework or archit ect ure, t he m echanism it self is called Different iat ed Class of Service or
sim ply Class of Service ( COS) .
[3]
K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers," RFC 2474, December 1998.
Part ( b) of Figure 1- 3 shows how t he ToS field has been redefined, so t hat t he first six bit s now
com pose t he DiffServ Code Point ( DSCP) . Wit h t hese six bit s you can define, eit her arbit rarily or
according t o service classes predefined in t he DiffServ archit ect ure, up t o 64 different service
classes t hat can t hen be sort ed int o PHBs. Not e t hat t he field in t he I P header rem ains 8 bit s;
t he DiffServ archit ect ure j ust redefines how a rout er int erpret s t he value in t hat field.
Explicit Congest ion Not ificat ion ( ECN) , in part ( b) of Figure 1- 3 , is used by som e rout ers t o signal
support for Explicit Congest ion Not ificat ion and, when it is support ed, t he bit s can be used t o
signal congest ion ( ECN = 11) . [ 4]
[4]
K. Ramakrishnan, "The Addition of Explicit Congestion Notification (ECN) to IP," RFC 3168, September 2001.
Tot al Lengt h is a 16- bit field specifying t he t ot al lengt h of t he packet , including t he header, in
oct et s. By subt ract ing t he header lengt h, a receiver m ight det erm ine t he size of t he packet 's
dat a payload. Because t he largest decim al num ber t hat can be described wit h 16 bit s is 65,535,
t he m axim um possible size of an I P packet is 65,535 oct et s.
I dent ifier is a 16- bit field used in conj unct ion wit h t he Flags and Fragm ent Offset fields for
fragm ent at ion of a packet . Packet s m ust be fragm ent ed int o sm aller packet s if t he original
lengt h exceeds t he Maxim um Transm ission Unit ( MTU) of a dat a link t hrough which t hey pass.
For exam ple, consider a 5000- byt e packet t raveling t hrough a net work. I t encount ers a dat a link
wit h a 1500 byt e MTU. That is, t he fram e can cont ain a m axim um packet size of 1500 byt es. The
rout er t hat places t he packet ont o t his dat a link m ust first fragm ent t he packet int o chunks of no
m ore t han 1500 oct et s each. The rout er t hen m arks each fragm ent wit h t he sam e num ber in t he
I dent ifier field so t hat a receiving device can ident ify t he fragm ent s t hat go t oget her. [ 5]
[5]
A fragmented packet is not reassembled at the other end of the data link; the packet stays fragmented until it reaches its
final destination.
Flags is a t hree- bit field in which t he first bit is unused. The second is t he Don't Fragm ent ( DF)
bit . When t he DF bit is set t o one, a rout er cannot fragm ent t he packet . I f t he packet cannot be
forwarded wit hout fragm ent ing, t he rout er drops t he packet and sends an error m essage t o t he
source. This funct ion enables t he t est ing of MTUs in a net work. The DF bit can be set using t he
Ext ended Ping ut ilit y in I OS, as shown in Exam ple 1- 1.
Ex a m ple 1 - 1 . Th e I OS Ex t e n de d Pin g u t ilit y a llow s t h e se t t in g of t h e
D F bit t o t e st M TUs a cr oss a n e t w or k . I n t h is pin g Ou t pu t , t h e la r ge st
M TU of t h e pa t h t o de st in a t ion 1 7 2 .1 6 .1 1 3 .1 7 is 1 4 7 8 oct e t s.
Handy#ping
Protocol [ip]:
Target IP address: 172.16.113.17
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [9]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]: y
Sweep min size [76]: 500
Sweep max size [18024]: 2000
Sweep interval [1]: 500
Type escape sequence to abort.
Sending 4, [500..2000]-byte ICMP Echos to 172.16.113.17, timeout is 2 seconds:
Packet has IP options: Total option bytes= 39, padded length=40
Record route: <*> 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Reply to request 0 (16 ms) (size 500). Received packet has options
Total option bytes= 40, padded length=40
Record route: 172.16.192.5 172.16.113.18 172.16.113.17 172.16.113.17
172.16.192.6 172.16.192.5 <*> 0.0.0.0 0.0.0.0 0.0.0.0
End of list
Reply to request 1 (24 ms) (size 1000). Received packet has options
Total option bytes= 40, padded length=40
Record route: 172.16.192.5 172.16.113.18 172.16.113.17 172.16.113.17
172.16.192.6 172.16.192.5 <*> 0.0.0.0 0.0.0.0 0.0.0.0
End of list
Reply to request 2 (28 ms) (size 1500). Received packet has options
Total option bytes= 40, padded length=40
Record route: 172.16.192.5 172.16.113.18 172.16.113.17 172.16.113.17
172.16.192.6 172.16.192.5 <*> 0.0.0.0 0.0.0.0 0.0.0.0
End of list
Unreachable from 172.16.192.6, maximum MTU 1478 (size 2000).
Received packet has options
Total option bytes= 39, padded length=40
Record route: <*> 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Success rate is 75 percent (3/4), round-trip min/avg/max = 16/22/28 ms
Handy#
The t hird bit is t he More Fragm ent s ( MF) bit . When a rout er fragm ent s a packet , it set s t he MF
bit t o one in all but t he last fragm ent so t hat t he receiver knows t o keep expect ing fragm ent s
unt il it encount ers a fragm ent wit h MF = 0.
Fragm ent Offset is a 13- bit field t hat specifies t he offset , in unit s of eight oct et s, from t he
beginning of t he header t o t he beginning of t he fragm ent . [ 6] Because fragm ent s m ight not
always arrive in sequence, t he Fragm ent Offset field allows t he pieces t o be reassem bled in t he
correct order.
[6]
Units of eight octets are used so that a maximum-size packet of 65,535 bytes might be described with 13 bits.
Not e t hat if a single fragm ent is lost during a t ransm ission, t he ent ire packet m ust be resent and
refragm ent ed at t he sam e point in t he net work. Therefore, error- prone dat a links could cause a
disproport ionat e delay. And if a fragm ent is lost because of congest ion, t he ret ransm ission of t he
ent ire series of fragm ent s m ight increase t he congest ion.
Tim e t o Live ( TTL) is an eight - bit field t hat will be set wit h a cert ain num ber when t he packet is
first generat ed. As t he packet is passed from rout er t o rout er, each rout er will decrem ent t his
num ber. I f t he num ber reaches zero, t he packet will be discarded and an error m essage will be
sent t o t he source. This process prevent s " lost " packet s from wandering endlessly t hrough a
net work.
As originally conceived, t he TTL was specified in seconds; if a packet was delayed m ore t han a
second in a rout er, t he rout er would adj ust t he TTL accordingly. However, t his approach is
difficult t o im plem ent and has never been generally support ed. Modern rout ers sim ply
decrem ent t he TTL by one, no m at t er what t he act ual delay, so t he TTL is really a hop count . [ 7]
The recom m ended default TTL is 64, alt hough values such as 15 and 32 are not uncom m on.
[7]
As you will read in Chapter 2, the equivalent field in the IPv6 header has been renamed Hop Limit to more accurately
reflect its true usage.
Som e t race ut ilit ies, such as t he I OS t r a ce com m and, m ake use of t he TTL field. I f t he rout er is
t old t o t race t he rout e t o a host address such as 10.11.12.13, t he rout er will send t hree packet s
wit h t he TTL set t o one; t he first rout er will decrem ent it t o zero, drop t he packet s, and send
back error m essages t o t he source. By reading t he source address of t he error m essages, t he
first rout er on t he pat h is now known. The next t hree packet s will be sent wit h a TTL of t wo. The
first rout er decrem ent s t o one, t he second t o zero, and an error m essage is received from t he
second rout er. The t hird set has a TTL of t hree, and so fort h, unt il t he dest inat ion is found. All
rout ers along t he net work pat h will have ident ified t hem selves. Exam ple 1- 2 shows t he out put
from an I OS t race.
Ex a m ple 1 - 2 . Th e t r a ce u t ilit y u se s t h e TTL fie ld t o ide n t ify r ou t e r s
a lon g a r ou t e . Ast e r isk s in dica t e t im e d- ou t pa ck e t s.
Elvis#traceroute www.cisco.com
Type escape sequence to abort.
Tracing the route to cio-sys.Cisco.COM (192.31.7.130)
1 172.18.197.17 4 msec
4 msec 4 msec
2 ltlrichard-s1-13.hwy51.com (172.18.197.1) 36 msec 44 msec 2536 msec
3 cperkins-rtr-fr2.hwy51.com (10.168.204.3) 104 msec 64 msec *
4 cberry.hwy51.com (10.168.193.1) 92 msec *
5 jllewis-inner.hwy51.com (10.168.207.59) 44 msec * 44 msec
6 bholly-fw-outer-rt.hwy51.com (10.168.207.94) 44 msec *
48 msec
7 sl-stk-14-S10/0:6-512k.sprintlink.net (144.228.214.107) 92 msec *
8 sl-stk-2-F1/0/0.sprintlink.net (144.228.40.2) 52 msec 1156 msec *
9 sl-mae-w-H1/0-T3.sprintlink.net (144.228.10.46) 100 msec 124 msec 2340 msec
10 sanjose1-br1.bbnplanet.net (198.32.136.19) 2264 msec
164 msec *
11 paloalto-br2.bbnplanet.net (4.0.1.10) 64 msec 60 msec
*
12 su-pr2.bbnplanet.net (131.119.0.218) 76 msec 76 msec
76 msec
13 cisco.bbnplanet.net (131.119.26.10) 2560 msec 76 msec
936 msec
14 sty.cisco.com (192.31.7.39) 84 msec 72 msec *
15 cio-sys.Cisco.COM (192.31.7.130) 60 msec *
64 msec
Elvis#
Prot ocol is an eight - bit field t hat gives t he " address," or prot ocol num ber, of t he host - t o- host or
t ransport layer prot ocol for which t he inform at ion in t he packet is dest ined. Table 1- 2 shows a
few of t he m ore com m on of t he 100 or so different prot ocol num bers current ly assigned.
Ta ble 1 - 2 . A fe w w e ll- k n ow n pr ot ocol n u m be r s.
Pr ot ocol N u m be r
H ost - t o- H ost La ye r Pr ot ocol
1
I nt ernet Cont rol Message Prot ocol
( I CMP)
2
I nt ernet Group Managem ent Prot ocol
( I GMP)
4
I P in I P ( encapsulat ion)
6
Transm ission Cont rol Prot ocol ( TCP)
17
User Dat agram Prot ocol ( UDP)
45
I nt er- Dom ain Rout ing Prot ocol ( I DRP)
46
Resource Reservat ion Prot ocol ( RSVP)
47
Generic Rout ing Encapsulat ion ( GRE)
Pr ot ocol N u m be r
H ost - t o- H ost La ye r Pr ot ocol
54
NBMA Next Hop Resolut ion Prot ocol
( NHRP)
88
Cisco I nt ernet Gat eway Rout ing Prot ocol
( I GRP)
89
Open Short est Pat h First ( OSPF)
Header Checksum is t he error det ect ion field for t he I P header. The checksum is not calculat ed
for t he encapsulat ed dat a; UDP, TCP, and I CMP have t heir own checksum s for doing t his. The
field cont ains a 16- bit one's com plem ent checksum , calculat ed by t he originat or of t he packet .
The receiver will again calculat e a 16- bit one's com plem ent sum , including t he original
checksum . I f no errors have occurred during t he packet 's t ravels, t he result ing checksum will be
all ones. Rem em ber t hat each rout er decrem ent s t he TTL; t herefore, t he checksum m ust be
recalculat ed at each rout er. RFC 1141 discusses som e st rat egies for sim plifying t his calculat ion.
Source and Dest inat ion Addresses are t he 32- bit I P addresses of t he originat or of t he packet and
t he dest inat ion of t he packet . The form at of I P addresses is covered in t he next sect ion, "I Pv4
Addr esses."
Opt ions is a variable- lengt h field and, as t he nam e says, is opt ional. Space is added t o t he
packet header t o cont ain eit her source- generat ed inform at ion or for ot her rout ers t o ent er
inform at ion; t he opt ions are used prim arily for t est ing. The m ost frequent ly used opt ions are
Loose source rout ing, in which a series of I P addresses for rout er int erfaces is list ed. The
packet m ust pass t hrough each of t hese addresses, alt hough m ult iple hops m ight be t aken
bet ween t he addresses.
St rict source rout ing, where again a series of rout er addresses is list ed. Unlike loose source
rout ing, t he packet m ust follow t he rout e exact ly. I f t he next hop is not t he next address on
t he list , an error occurs.
Record rout e provides room for each rout er t o ent er t he address of it s out going int erface as
t he packet t ransit s so t hat a record is kept of all rout ers t he packet encount ers. Record
rout e provides a funct ion sim ilar t o t race except t hat t he out going int erfaces, bot h on t he
pat h t o t he dest inat ion and on t he ret urn pat h, are recorded.
Tim est am p is an opt ion sim ilar t o record rout e except each rout er also ent ers a t im est am p:
t he packet not only keeps t rack of where it has been but also records when it was t here.
All t hese opt ions m ight be invoked by using t he Ext ended Ping on Cisco rout ers. Record rout e is
used in Exam ple 1- 1, loose source rout ing and t im est am p are used in Exam ple 1- 3, and st rict
source rout ing is used in Exam ple 1- 4.
Ex a m ple 1 - 3 . Th e Cisco Ex t e n de d Pin g ca n be u se d t o se t pa r a m e t e r s
in t h e Opt ion s fie ld of t h e I P h e a de r . I n t h is e x a m ple , loose sou r ce
r ou t in g a n d t im e st a m p a r e u se d.
Handy#ping
Protocol [ip]:
Target IP address: 172.16.113.9
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: l
Source route: 172.16.113.14 172.16.113.10
Loose, Strict, Record, Timestamp, Verbose[LV]: t
Number of timestamps [ 6 ]: 2
Loose, Strict, Record, Timestamp, Verbose[LTV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.113.9, timeout is 2 seconds:
Packet has IP options: Total option bytes= 23, padded length=24
Loose source route: <*> 172.16.113.14 172.16.113.10
Timestamp: Type 0. Overflows: 0 length 12, ptr 5
>>Current pointer<<
Time= 0
Time= 0
Request 0 timed out
Reply to request 1 (76 ms). Received packet has options
Total option bytes= 24, padded length=24
Loose source route: 172.16.113.13 172.16.192.6 <*>
Timestamp: Type 0. Overflows: 6 length 12, ptr 13
Time= 80FF4798
Time= 80FF4750
>>Current pointer<<
End of list
Request 2 timed out
Reply to request 3 (76 ms). Received packet has options
Total option bytes= 24, padded length=24
Loose source route: 172.16.113.13 172.16.192.6 <*>
Timestamp: Type 0. Overflows: 6 length 12, ptr 13
Time= 80FF4FC0
Time= 80FF4F78
>>Current pointer<<
End of list
Request 4 timed out
Success rate is 40 percent (2/5), round-trip min/avg/max = 76/76/76 ms
Handy#
Ex a m ple 1 - 4 . Ex t e n de d Pin g is u se d h e r e t o se t st r ict sou r ce r ou t in g in
t h e pin g pa ck e t s.
Handy#ping
Protocol [ip]:
Target IP address: 172.16.113.10
Repeat count [5]: 2
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: s
Source route: 172.16.192.6 172.16.113.17 172.16.113.10
Loose, Strict, Record, Timestamp, Verbose[SV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 172.16.113.10, timeout is 2 seconds:
Packet has IP options: Total option bytes= 15, padded length=16
Strict source route: <*> 172.16.192.6 172.16.113.17 172.16.113.10
Reply to request 0 (80 ms). Received packet has options
Total option bytes= 16, padded length=16
Strict source route: 172.16.113.10 172.16.113.17 172.16.192.6 <*>
End of list
Reply to request 1 (76 ms). Received packet has options
Total option bytes= 16, padded length=16
Strict source route: 172.16.113.10 172.16.113.17 172.16.192.6 <*>
End of list
Success rate is 100 percent (2/2), round-trip min/avg/max = 76/78/80 ms
Handy#
Padding ensures t hat t he header ends on a 32- bit boundary by adding zeros aft er t he opt ion
field unt il a m ult iple of 32 is reached.
A prot ocol analyzer capt ure of an I P header is shown in Exam ple 1- 5. Com pare t he inform at ion
shown wit h Figure 1- 2 .
Ex a m ple 1 - 5 . You ca n se e t h e fie lds of a n I P pa ck e t 's h e a de r a n d t h e
va lu e s con t a in e d in e a ch fie ld in t h is pr ot ocol a n a lyze r displa y.
Internet Protocol, Src Addr: 172.16.1.102 (172.16.1.102), Dst Addr: 224.0.0.5
(224.0.0.5)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 64
Identification: 0x6e61 (28257)
Flags: 0x00
Fragment offset: 0
Time to live: 1
Protocol: OSPF IGP (0x59)
Header checksum: 0xbcc8 (correct)
IPv4 Addresses
I Pv4 addresses are 32 bit s long; like all net work- level addresses, t hey have a net work port ion
and a host port ion. The net work port ion uniquely ident ifies a physical or logical link and is
com m on t o all devices at t ached t o t hat link. The host port ion uniquely ident ifies a part icular
device at t ached t o t he link.
There are several ways t o represent t he 32 bit s of an I P address. For inst ance, t he 32- bit I P
address
00001010110101100101011110000011
can be represent ed in decim al as
181,819,267.
The binary form at is cum bersom e, and a decim al form at of t he ent ire 32- bit num ber is t im econsum ing t o calculat e. Figure 1- 4 shows a bet t er form at .
Figu r e 1 - 4 . Th e dot t e d- de cim a l for m a t is a con ve n ie n t w a y t o w r it e
I Pv4 a ddr e sse s, bu t it sh ou ld n ot be con fu se d w it h w h a t t h e r ou t e r ( or
h ost ) se e s: a 3 2 - bit st r in g.
The 32 bit s of t he address com prise four oct et s, each of which can be represent ed wit h a
decim al num ber bet ween 0 and 255, wit h dot s bet ween t he decim al represent at ions. I n Figure
1 - 4, t he 32- bit address is m apped int o a dot t ed- decim al represent at ion. [ 8]
[8]
Dotted decimal is used only with IPv4 addresses. As you will read in Chapter 2, IPv6 addresses are represented entirely
differently.
An im port ant dist inct ion t o rem em ber when working wit h I Pv4 addresses is t hat dot t ed decim al
is j ust an easy way for hum ans t o read and writ e I P addresses. Always rem em ber t hat t he rout er
is not reading an address in t erm s of four oct et s; rat her, t he rout er sees a 32- bit binary st ring.
Many pit falls can be avoided by keeping t his fact firm ly in m ind. I f you have not worked wit h
binary num berspart icularly convert ing bet ween binary and decim alyou m ight want t o read t he
t ut orial in Appendix A, " Tut orial: Working wit h Binary and Hex," before cont inuing on wit h t his
chapt er.
Probably t he m ost dist inct ive charact erist ic of I Pv4 addresses is t hat unlike ot her net work- level
addresses, t he net work and host port ions can vary in size wit hin t he 32- bit boundaries. That is,
t he net work port ion m ight t ake up m ost of t he 32 bit s, or t he host port ion m ight , or t hey m ight
divide t he bit s equally. Prot ocols such as Net Ware and AppleTalk were designed for use in
relat ively sm all net works, and as a result t heir net work- level addresses have fixed- lengt h
net work and host port ions. This arrangem ent cert ainly m akes life easier; a receiving device
knows t o read a cert ain num ber of bit s int o t he address t o find t he net work part , and t he rest is
host address.
TCP/ I P, however, was designed from t he first t o be flexible enough t o be used in any net work,
from t he t iny t o t he colossal. This flexibilit y m akes I P addresses m ore difficult t o m anage. The
basics of adm inist ering I P addresses are present ed in t his sect ion, and t hen som e m ore
advanced t echniques are int roduced in Chapt er 6, " RI Pv2, RI Png, and Classless Rout ing."
First Octet Rule
Wit hout put t ing t oo fine a point on it , it can be said t hat t here are t hree sizes of net works as
m easured by t he num ber of host s: big, m edium , and sm all:
Big net works, by definit ion, have a huge num ber of host s. Relat ively few big net works
exist .
Sm all net works are j ust t he opposit e. Each one is sm all because it has a sm all num ber of
host s; a huge num ber of sm all net works exist .
Medium net works are j ust t hat : a m edium num ber of t hem ( in relat ion t o big and sm all
ones) and a m edium num ber of host s in each one.
This high level of addressing focus requires t hree t ypesclassesof net work address for t he t hree
sizes of net works. Addresses for big net works need t o be capable of addressing m any host s, but
because so few big net works exist , only a few big- net work addresses are required.
The sit uat ion is reversed for sm all net works. Because t here are m any sm all net works, a large
num ber of sm all- net work addresses are needed. But because a sm all net work has a sm all
num ber of host s, each of t he m any net work addresses only requires a few host addresses.
For m edium - sized net works, a m edium num ber of net work addresses and a m edium num ber of
host addresses will be available for each net work address.
Figure 1- 5 shows how t he net work and host port ions of I Pv4 addresses are divided up for t hese
t hree classes.
Figu r e 1 - 5 . Cla ss A, B, a n d C I Pv4 a ddr e ss for m a t s.
The big, m edium , and sm all net works described t hus far m ap t o address classes as follows:
Class A I Pv4 addresses are for big net works. The first oct et is t he net work port ion, and t he
last t hree oct et s are t he host port ion. Only 256 num bers are available in t he eight - bit
net work part , but 2 24 or 16,777,216 num bers are available in t he host part of each of
t hose net work addresses.
Class B addresses are for m edium - size net works. The first t wo oct et s are t he net work
port ion, and t he last t wo oct et s are t he host port ion. There are 2 16 or 65,536 available
num bers in t he net work part and an equal num ber in t he host part .
Class C addresses are j ust t he opposit e of Class A. The first t hree oct et s are t he net work
port ion, and t he last oct et is t he host port ion.
Because all I Pv4 addresses are 32- bit binary st rings, a way of dist inguishing t he class t o which a
part icular address belongs is necessary. The first oct et rule, dem onst rat ed in Table 1- 3, provides
t he m eans t o m ake such a dist inct ion and can be described as follows:
For Class A addresses, t he first bit of t he first oct et t hat is, t he left - m ost bit of t he ent ire 32bit st ringis always set t o zero. Therefore, we can find t he m inim um and m axim um num bers
in t he Class A range by set t ing all t he rem aining bit s in t he first oct et t o zero ( for t he
m inim um ) and one ( for t he m axim um ) . This act ion result s in t he decim al num bers 0 and
127 wit h a few except ions: 0 is reserved as part of t he default address ( Chapt er 12,
" Default Rout es and On- Dem and Rout ing" ) , and 127 is reserved for int ernal loopback
addresses. [ 9] That leaves 1 t hrough 126; any I P address whose first oct et is bet ween 1 and
126 inclusive is a Class A address.
[9]
Devices use loopback addresses (typically 127.0.0.1) to send traffic to themselves. Data might be sent to this
address and returned to the transmitting process without ever leaving the device.
Class B addresses always have t heir left - m ost bit set t o one and t he second bit set t o zero.
Again, finding t he m inim um and m axim um num ber of t he first oct et by set t ing all
rem aining bit s t o zero and t hen t o one, you see in Figure 1- 4 t hat any address whose first
oct et is in t he decim al range 128 t hrough 191 is a Class B address.
I n Class C addresses, t he first t wo bit s are set t o one, and t he t hird bit is set t o zero. The
result is a first oct et range of 192 t hrough 223. [ 10]
[10]
Notice that 223 does not exhaust all available numbers in the first octet. See Configuration Exercise 1 at the end
of this chapter.
Ta ble 1 - 3 . Fir st oct e t r u le .
Ru le
M in im u m a n d M a x im u m
D e cim a l Ra n ge
Class A: First bit is always
0
0 0000000 = 0
1126 [ * ]
0 1111111 = 127
Class B: First t wo bit s are
always 10
1 0 000000 = 128
1 0 111111 = 191
128191
Ru le
M in im u m a n d M a x im u m
Class C: First t hree bit s are 1 1 0 00000 = 192
always 110
1 1 0 11111 = 223
[*]
D e cim a l Ra n ge
192223
0 and 127 are reserved
So far I Pv4 addressing doesn't seem so difficult . A rout er or host could easily det erm ine t he
net work part of an I P address by using t he first oct et rule. I f t he first bit is 0, t hen read t he first
eight bit s t o find t he net work address. I f t he first t wo bit s are 10, t hen read t he first 16 bit s; and
if t he first t hree bit s are 110, t hen read 24 bit s in t o get t he net work address. Unfort unat ely,
t hings are not t hat easy.
Address Masks
The address for an ent ire dat a linka non- host - specific net work addressis represent ed by t he
net work port ion of an I P address, wit h all host bit s set t o zero. For inst ance, an addressing
aut horit y [ 11] m ight assign t o an applicant an address of 172.21.0.0. [ 12] This address is a Class B
address because 172 is bet ween 128 and 191, so t he last t wo oct et s m ake up t he host bit s.
Not ice t hat t hey are all set t o zero. The first 16 bit s ( 172.21.) are assigned, but address owners
are free t o do what ever t hey please wit h t he host bit s.
[11]
The high-level organizations responsible for managing and assigning IP addresses are APNIC in Asia, ARIN in North
America, LACNIC in Central and South America, and RIPE in EMEA.
[12]
Actually, this address would never be assigned. It is from a group of addresses reserved for private use; most of the
addresses used in this book are from this reserved pool, described in RFC 1918. Reserved addresses are
10.0.0.010.255.255.255, 172.16.0.0172.31.255.255, and 192.168.0.0192.168.255.255.
Each device or int erface will be assigned a unique, host - specific address such as 172.21.35.17.
The device, whet her a host or a rout er, obviously needs t o know it s own address, but it also
needs t o be able t o det erm ine t he net work t o which it belongsin t his case, 172.21.0.0.
This t ask is accom plished by m eans of an address m ask. The address m ask is a 32- bit st ring,
one bit for each bit of t he I Pv4 address. As a 32- bit st ring, t he m ask can be represent ed in
dot t ed- decim al form at j ust like an I Pv4 address. This represent at ion t ends t o be a st um bling
block for som e beginners: Alt hough t he address m ask can be writ t en in dot t ed decim al, it is not
an address. Table 1- 4 shows t he st andard address m asks for t he t hree classes of I Pv4 address.
Ta ble 1 - 4 . Addr e ss m a sk s for Cla ss A, B, a n d C
I Pv4 a ddr e sse s.
Cla ss M a sk
D ot t e d D e cim a l
A
11111111000000000000000000000000
255.0.0.0
B
11111111111111110000000000000000
255.255.0.0
C
11111111111111111111111100000000
255.255.255.0
For each bit of t he I Pv4 address, t he device perform s a Boolean ( logical) AND funct ion wit h t he
corresponding bit of t he address m ask. The AND funct ion can be st at ed as follows:
Com pare t wo bit s and derive a result . The result will be one, if and only if, bot h bit s are
one. I f eit her or bot h bit s are zero, t he result will be zero.
Figure 1- 6 shows how, for a given I Pv4 address, t he address m ask is used t o det erm ine t he
net work address. The m ask has a one in every bit posit ion corresponding t o a net work bit of t he
address and a zero in every bit posit ion corresponding t o a host bit . Because 172.21.35.17 is a
Class B address, t he m ask m ust have t he first t wo oct et s set t o all ones and t he last t wo oct et s,
t he host part , set t o all zeros. As Table 1- 4 shows, t his m ask can be represent ed in dot t ed
decim al as 255.255.0.0.
Figu r e 1 - 6 . Ea ch bit of t h is Cla ss B a ddr e ss is AN D e d w it h t h e
cor r e spon din g bit of t h e a ddr e ss m a sk t o de r ive t h e n e t w or k a ddr e ss.
A logical AND is perform ed on t he I Pv4 address and it s m ask for every bit posit ion; t he result is
shown in Figure 1- 6 . I n t he result , every net work bit is repeat ed, and all t he host bit s becom e
0s. So by assigning an address of 172.21.35.17 and a m ask of 255.255.0.0 t o an int erface, t he
device will know t hat t he int erface belongs t o net work 172.21.0.0. Applying t he AND operat or t o
an I Pv4 address and it s address m ask always reveals t he net work address.
An address and m ask are assigned t o an int erface of a Cisco rout er ( in t his exam ple, t he E0
int erface) by m eans of t he following com m ands:
Smokey(config)# interface ethernet 0
Smokey(config-if)# ip address 172.21.35.17 255.255.0.0
But why use address m asks at all? So far, using t he first oct et rule seem s m uch sim pler.
Subnets and Subnet Masks
Never lose sight of why net work- level addresses are necessary in t he first place. For rout ing t o
be accom plished, each and every dat a link ( net work) m ust have a unique address; in addit ion,
each and every host on t hat dat a link m ust have an address t hat bot h ident ifies it as a m em ber
of t he net work and dist inguishes it from any ot her host on t hat net work.
As defined so far, a single Class A, B, or C address can be used only on a single dat a link. To
build a net work, separat e addresses m ust be used for each dat a link so t hat t hose net works are
uniquely ident ifiable. I f a separat e Class A, B, or C address were assigned t o each dat a link,
fewer t han 17 m illion dat a links could be addressed before all I Pv4 addresses were deplet ed.
This approach is obviously im pract ical, [ 13] as is t he fact t hat t o m ake full use of t he host address
space in t he previous exam ple, m ore t han 65,000 devices would have t o reside on dat a link
172.21.0.0!
[13]
Seventeen million data links might seem like a lot until you consider that even a single moderate-size business might
have dozens or hundreds of data links.
The only way t o m ake Class A, B, or C addresses pract ical is by dividing each m aj or address,
such as 172.21.0.0, int o subnet work addresses. Recall t wo fact s:
The host port ion of an I Pv4 address can be used as desired.
The net work port ion of an I Pv4 address is det erm ined by t he address m ask assigned t o
t hat int erface.
Figure 1- 7 shows a net work t o which t he m aj or Class B address 172.21.0.0 has been assigned.
Five dat a links are int erconnect ing t he host s and rout ers, each one of which requires a net work
address. As it st ands, 172.21.0.0 would have t o be assigned t o a single dat a link, and t hen four
m ore addresses would have t o be request ed for t he ot her four dat a links.
Figu r e 1 - 7 . Su bn e t m a sk s a llow a sin gle n e t w or k a ddr e ss t o be u se d
on m u lt iple da t a lin k s by " bor r ow in g" som e of t h e h ost bit s for u se a s
su bn e t bit s.
[View full size image]
Not ice what was done in Figure 1- 7 . The address m ask is not a st andard 16- bit m ask for Class B
addresses; t he m ask has been ext ended anot her eight bit s so t hat t he first 24 bit s of t he I P
address are int erpret ed as net work bit s. I n ot her words, t he rout ers and host s have been given a
m ask t hat causes t hem t o read t he first eight host bit s as part of t he net work address. The result
is t hat t he m aj or net work address applies t o t he ent ire net work, and each dat a link has becom e
a subnet work, or subnet . A subnet is a subset of a m aj or Class A, B, or C address space.
The I Pv4 address now has t hree part s: t he net work part , t he subnet part , and t he host part . The
address m ask is now a subnet m ask , or a m ask t hat is longer t han t he st andard address m ask.
The first t wo oct et s of t he address will always be 172.21, but t he t hird oct et whose bit s are now
subnet bit s inst ead of host bit sm ight range from 0 t o 255. The net work in Figure 1- 6 has
subnet s 1, 2, 3, 4, and 5 ( 172.21.1 .0 t hrough 172.21.5 .0) . Up t o 256 subnet s m ight be
assigned under t he single Class B address, using t he m ask shown.
Two words of caut ion are in order. First , not all rout ing prot ocols can support subnet addresses
in which t he subnet bit s are all zeros or all ones. The reason is t hat t hese prot ocols, called
classful prot ocols, cannot different iat e bet ween an all- zero subnet and t he m aj or net work
num ber. For inst ance, subnet 0 in Figure 1- 7 would be 172.21.0.0; t he m aj or I P address is also
172.21.0.0. The t wo cannot be dist inguished wit hout furt her inform at ion.
Likewise, classful rout ing prot ocols cannot different iat e a broadcast on t he all- ones subnet from
an all- subnet s broadcast address. [ 14] For exam ple, t he all- ones subnet in Figure 1- 7 would be
172.21.255.0. For t hat subnet , t he all- host s broadcast address would be 172.21.255.255, but
t hat is also t he broadcast for all host s on all subnet s of m aj or net work 172.21.0.0. Again, t he
t wo addresses cannot be dist inguished wit hout furt her inform at ion. RI P version 1 and I GRP are
bot h classful rout ing prot ocols; Chapt er 7, " Enhanced I nt erior Gat eway Rout ing Prot ocol
( EI GRP) ," int roduces classless rout ing prot ocols, which can indeed use t he all- zeros and all- ones
subnet s.
[14]
The all-hosts IP broadcast address is all ones: 255.255.255.255. An all-hosts broadcast for a particular subnet would set
all host bits to one; for instance, an all-hosts broadcast for subnet 172.21.1.0 would be 172.21.1.255. Finally, a broadcast
for all hosts on all subnets sets the subnet bits and the host bits to all ones: 172.21.255.255.
The second caut ion has t o do wit h t he verbal descript ion of subnet s and t heir m asks. Subnet t ing
t he t hird oct et of a Class B address, as is done is Figure 1- 7 , is very com m on; also com m on is
hearing people describe such a subnet design as " using a Class C m ask wit h a Class B address,"
or " subnet t ing a Class B address int o a Class C." Bot h descript ions are wrong! Such descript ions
frequent ly lead t o m isunderst andings about t he subnet design or t o a poor underst anding of
subnet t ing it self. The proper way t o describe t he subnet t ing schem e of Figure 1- 6 is eit her as " a
Class B address wit h 8 bit s of subnet t ing," or as " a Class B address wit h a 24- bit m ask."
The subnet m ask m ight be represent ed in any of t he following t hree form at s:
Dot t ed decim al: 255.255.255.0
Bit count : 172.21.0.0/ 24
Hexadecim al: 0xFFFFFF00
Dot t ed decim al is com m only used in soft ware t hat has been around for a while, alt hough t he
bit count form at is becom ing increasingly preferred. Com pared t o dot t ed decim al, t he bit count
form at is easier t o writ e. ( The address is followed by a forward slash and t he num ber of bit s t hat
are m asked for t he net work part .) I n addit ion, t he bit count form at is m ore descript ive of what
t he m ask is really doing and t herefore avoids t he t ype of sem ant ic m isunderst andings described
in t he previous paragraph. Som e UNI X syst em s use t he hexadecim al form at .
Alt hough t he address m ask m ust be specified t o Cisco rout ers in dot t ed decim al, using t he
com m and shown previously, t he m ask m ight be displayed by various sh ow com m ands in any of
t he t hree form at s by using t he com m and ip n e t m a sk - for m a t [ de cim a l| h e x a de cim a l| bit cou n t ] in line configurat ion m ode. For exam ple, t o configure a rout er t o display it s m asks in
bit count form at , use
Gladys(config)# line vty 0 4
Gladys(config-line)# ip netmask-format bit-count
Designing Subnets
As est ablished in t he previous sect ion, subnet bit s cannot be all zeros or all ones in classful
environm ent s. Likewise, an I Pv4 host address cannot have all it s host bit s set t o zerot his set t ing
is reserved for t he address t hat rout ers use t o represent t he net work or subnet it self. And t he
host bit s cannot be set t o all ones, as t his set t ing is t he broadcast address. These rest rict ions
apply t o t he host bit s wit h no except ions and are st art ing point s for designing subnet s. Beyond
t hese st art ing point s, net work designers need t o choose t he m ost appropriat e subnet t ing
schem e in t erm s of m at ching t he address space t o t he part iculars of a net work.
When designing subnet s and t heir m asks, t he num ber of available subnet s under a m aj or
net work address and t he num ber of available host s on each subnet are bot h calculat ed wit h t he
sam e form ula: 2 n 2, where n is t he num ber of bit s in t he subnet or host space and 2 is
subt ract ed t o account for t he unavailable all- zeros and all- ones addresses. For exam ple, given a
Class A address of 10.0.0.0, a subnet m ask of 10.0.0.0/ 16 ( 255.255.0.0) m eans t hat t he 8- bit
subnet space will yield 2 8 2 = 254 available subnet s and 2 16 2 = 65,534 host addresses available
on each of t hose subnet s. On t he ot her hand, a m ask of 10.0.0.0/ 24 ( 255.255.255.0) m eans
t hat a 16- bit subnet space is yielding 65,534 subnet s and an 8- bit host space is yielding 254
host addresses for each subnet .
The following st eps are used t o subnet an I Pv4 address:
St e p 1 .
Det erm ine how m any subnet s are required and how m any host s per subnet are
r equir ed.
St e p 2 .
Use t he 2 n 2 form ula t o det erm ine t he num ber of subnet bit s and t he num ber of host
bit s t hat will sat isfy t he requirem ent s est ablished in St ep 1. I f m ult iple subnet m asks
can sat isfy t he requirem ent s, choose t he one t hat will best scale t o fut ure needs. For
exam ple, if t he net work is m ost likely t o grow by adding subnet s, choose m ore
subnet bit s; if t he net work is m ost likely t o grow by adding host s t o exist ing subnet s,
choose m ore host bit s. Avoid choosing a schem e in which eit her all subnet s or all
host addresses wit hin t he subnet s will be used up im m ediat ely, leaving no room for
fut ure growt h.
St e p 3 .
Working in binary, det erm ine all available bit com binat ions in t he subnet space; in
each inst ance, set all t he host bit s t o zero. Convert t he result ing subnet addresses t o
dot t ed decim al. These are t he subnet addresses.
St e p 4 .
For each subnet address, again working in binary, writ e all possible bit com binat ions
for t he host space wit hout changing t he subnet bit s. Convert t he result s t o dot t ed
decim al; t hese are t he host addresses available for each subnet .
The im port ance of doing t he last t wo st eps in binary cannot be overem phasized. The single
great est source of m ist akes when working wit h subnet s is t rying t o work wit h t hem in dot t ed
decim al wit hout underst anding what is happening at t he binary level. Again, dot t ed decim al is
for convenience in reading and writ ing I Pv4 addresses. Rout ers and host s see t he addresses as
32- bit binary st rings; t o successfully work wit h t hese addresses, t hey m ust be seen t he way t he
rout ers and host s see t hem .
The previous paragraph m ight seem a bit overzealous in light of t he exam ples given so far; t he
pat t erns of subnet and host addresses have been quit e apparent wit hout having t o see t he
addresses and m asks in binary. The next sect ion uses t he four design st eps t o derive a subnet
design in which t he dot t ed- decim al represent at ions are not so obvious.
Breaking the Octet Boundary
I n t he exam ples given so far, t he subnet spaces have fallen on oct et boundaries. This
arrangem ent is not always t he m ost pract ical or efficient choice. What if, for inst ance, you need
t o subnet a Class B address across 500 dat a links, each wit h a m axim um of 100 host s? This
requirem ent is easily m et , but only by using nine bit s in t he subnet field: 2 9 2 = 510 available
subnet s, leaving seven bit s for t he host field, and 2 7 2 = 126 available host s per subnet . No
ot her bit com binat ion will sat isfy t his requirem ent .
Not ice, also, t hat t here is no way t o subnet a class C address on an oct et boundarydoing so
would use up all of t he last byt e, leaving no room for host bit s. The subnet bit s and host bit s
m ust share t he last oct et , as t he following exam ple shows.
Figure 1- 8 shows t he net work of Figure 1- 7 but wit h a Class C address of 192.168.100.0
assigned.
Figu r e 1 - 8 . Th e n e t w or k fr om Figu r e 1 - 7 bu t w it h a Cla ss C pr e fix
a ssign e d. Su bn e t t in g a n e n t ir e oct e t w ill n ot w or k h e r e ; t h e r e w ou ld
be n o spa ce le ft for h ost bit s.
[View full size image]
There are five dat a links; t herefore, t he address m ust be subnet t ed t o provide for at least five
subnet addresses. The illust rat ion also indicat es t he num ber of host s ( including rout er
int erfaces) t hat need t o be addressed on each subnet . The m axim um host address requirem ent
is 25 for t he t wo Et hernet s. Therefore, t he full subnet t ing requirem ent s are at least five subnet s
and at least 25 host addresses per subnet .
Applying t he 2 n 2 form ula, t hree subnet bit s and five host bit s will sat isfy t he requirem ent s: 2 3 2
= 6 and 2 5 2 = 30. A Class C m ask wit h t hree bit s of subnet t ing is represent ed as
255.255.255.224 in dot t ed decim al.
Figure 1- 9 shows t he derivat ion of t he subnet bit s. The subnet m ask derived in St ep 2 is writ t en
in binary, and t he I P address is writ t en below it . Vert ical lines are drawn as m arkers for t he
subnet space, and wit hin t his space all possible bit com binat ions are writ t en by count ing up from
zero in binary.
Figu r e 1 - 9 . Th e su bn e t bit s a r e de r ive d by m a r k in g t h e m a sk e d su bn e t
bit spa ce a n d t h e n w r it in g a ll possible bit com bin a t ion s in t h e spa ce by
cou n t in g u p fr om ze r o in bin a r y.
I n Figure 1- 10, t he unchanged net work bit s are filled in t o t he left of t he subnet space and t he
host bit s, which are all zeros in t he subnet addresses, are filled in t o t he right of t he subnet
space. The result s are convert ed t o dot t ed decim al, and t hese are t he six subnet addresses
( rem em bering t hat t he first and last addresses, which have 000 and 111 in t he subnet space,
cannot be used) .
Figu r e 1 - 1 0 . Th e su bn e t a ddr e sse s a r e de r ive d by fillin g in t h e n e t w or k
a ddr e ss t o t h e le ft of t h e su bn e t spa ce , se t t in g a ll h ost bit s t o ze r o t o
t h e r igh t of t h e su bn e t spa ce , a n d con ve r t in g t h e r e su lt s t o dot t e d
de cim a l.
The last st ep is t o calculat e t he host addresses available t o each subnet . This st ep is done by
choosing a subnet and, keeping t he net work and subnet bit s unchanged, writ ing all bit
com binat ions in t he host space by count ing up from zero in binary. Figure 1- 11 shows t his st ep
for subnet 192.168.100.32.
Figu r e 1 - 1 1 . Th e h ost a ddr e sse s for a su bn e t a r e de r ive d by w r it in g a ll
possible bit com bin a t ion s in t h e h ost spa ce . Th e se a r e t h e h ost bit s for
su bn e t 1 9 2 .1 6 8 .1 0 0 .3 2 .
Not ice t he pat t erns in t he result s: The first address, in which t he host bit s are all zero, is t he
subnet address. The last address, in which t he host bit s are all one, is t he broadcast address for
subnet 192.168.100.32. The host addresses count up from t he subnet address t o t he broadcast
address, and if t he sequence were t o cont inue, t he next address would be t he second subnet ,
192.168.100.64.
The im port ance of underst anding subnet t ing at t he binary level should now be clear. Present ed
wit h an address such as 192.168.100.160, you cannot be sure whet her it is a host address, a
subnet address, or a broadcast address. Even when t he subnet m ask is known, t hings are not
always readily apparent .
Readers are encouraged t o calculat e all host addresses for all t he rem aining subnet s in t he
exam ple and t o observe t he pat t erns t hat result in t he addresses. Underst anding t hese pat t erns
will help in sit uat ions such as t he one present ed in t he next sect ion.
Troubleshooting a Subnet Mask
The necessit y frequent ly arises t o " dissect " a given host address and m ask, usually t o ident ify
t he subnet t o which it belongs. For inst ance, if an address is t o be configured on an int erface, a
good pract ice is t o first verify t hat t he address is valid for t he subnet t o which t he subnet is
connect ed.
Use t he following st eps t o reverse- engineer an I P address:
St e p 1 .
Writ e t he given subnet m ask in binary.
St e p 2 .
Writ e t he I Pv4 host address in binary.
St e p 3 .
Knowing t he class of t he host address, t he subnet bit s of t he m ask should be
apparent . Using t he m ask bit s as a guide, draw a line bet ween t he last net work bit
and t he first subnet bit of t he address. Draw anot her line bet ween t he last subnet bit
and t he first host bit .
St e p 4 .
Writ e t he net work and subnet bit s of t he address, set t ing all host bit s t o zero. The
result is t he address of t he subnet t o which t he host address belongs.
St e p 5 .
Again writ e t he net work and subnet bit s of t he address, t his t im e set t ing all host bit s
t o one. The result is t he broadcast address of t he subnet .
St e p 6 .
Knowing t hat t he subnet address is t he first address in t he sequence and t hat t he
broadcast address is t he last address in t he sequence, you also know t hat all
addresses bet ween t hese t wo are valid host addresses.
Figure 1- 12 shows t hese st eps applied t o 172.30.0.141/ 25.
Figu r e 1 - 1 2 . Give n a n I Pv4 a ddr e ss a n d a su bn e t m a sk , follow t h e se
st e ps t o fin d t h e su bn e t , t h e br oa dca st , a n d t h e h ost a ddr e sse s.
The address is a Class B, so it is known t hat t he first 16 bit s are t he net work bit s; t herefore, t he
last nine bit s of t he 25- bit m ask m ark t he subnet space. The subnet address is found t o be
172.30.0.128, and t he broadcast address is 172.30.0.255. Knowing t hat t he valid host
addresses for t he subnet are bounded by t hese t wo addresses, it is det erm ined t hat t he host
addresses for subnet 172.30.0.128 are 172.30.0.129 t hrough 172.30.0.254.
Several t hings about t his exam ple t end t o bot her folks who are new t o subnet t ing. Som e are
bot hered by t he t hird oct et of t he address, which is all zeros. Som e are bot hered by t he single
subnet bit in t he last oct et . Som e t hink t hat t he broadcast address looks suspiciously invalid. All
of t hese uneasy feelings arise from reading t he addresses in dot t ed decim al. When t he
addresses and t he m ask are seen in binary, t hese suspicions are assuaged and everyt hing is
seen t o be legit im at e; t he m ask set s a nine- bit subnet spaceall of t he t hird oct et , and t he first bit
of t he fourt h oct et . The m oral of t he st ory is t hat if everyt hing is known t o be correct in binary,
don't worry if t he dot t ed- decim al represent at ion looks funny.
Address Resolution Protocol (ARP)
Rout ers pass packet s across a logical pat h, com posed of m ult iple dat a links, by reading and
act ing on t he net work addresses in t he packet s. The packet s are passed across t he individual
dat a links by encapsulat ing t he packet s in fram es, which use dat a- link ident ifiers ( MAC
addresses, for exam ple) t o get t he fram e from source t o dest inat ion on t he link. One of t he
m aj or t opics of t his book concerns t he m echanism s by which rout ers discover and share
inform at ion about net work addresses so t hat rout ing m ight t ake place. Sim ilarly, devices on a
dat a link need a way t o discover t heir neighbors' dat a- link ident ifiers so t hat fram es m ight be
t ransm it t ed t o t he correct dest inat ion.
Several m echanism s can provide t his inform at ion; [ 15] I Pv4 uses t he Address Resolut ion Prot ocol
( ARP) , described in RFC 826. Figure 1- 13 shows how ARP works. A device needing t o discover
t he dat a- link ident ifier of anot her device will creat e an ARP Request packet . This request will
cont ain t he I Pv4 address of t he device in quest ion ( t he t arget ) and t he source I Pv4 address and
dat a- link ident ifier ( MAC address) of t he device m aking t he request ( t he sender) . The ARP
Request packet is t hen encapsulat ed in a fram e wit h t he sender's MAC address as t he source and
a broadcast address for t he dest inat ion ( see Exam ple 1- 6) . [ 16]
[15]
NetWare, for example, makes the MAC address of the device the host portion of the network-level addressa very
sensible thing to do.
[16]
Like an IP broadcast, the MAC broadcast is an address of all ones: ffff.ffff.ffff.
Figu r e 1 - 1 3 . ARP is u se d t o m a p a de vice 's da t a - lin k ide n t ifie r t o it s I P
a ddr e ss.
[View full size image]
Ex a m ple 1 - 6 . An a n a lyze r ca pt u r e of t h e ARP Re qu e st de pict e d in
Figu r e 1 - 1 3 , w it h it s e n ca psu la t in g fr a m e .
Ethernet II, Src: 00:30:65:2c:09:a6, Dst: ff:ff:ff:ff:ff:ff
Destination: ff:ff:ff:ff:ff:ff (Broadcast)
Source: 00:30:65:2c:09:a6 (AppleCom_2c:09:a6)
Type: ARP (0x0806)
Address Resolution Protocol (request)
Hardware type: Ethernet (0x0001)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (0x0001)
Sender MAC address: 00:30:65:2c:09:a6 (AppleCom_2c:09:a6)
Sender IP address: 172.16.1.21 (172.16.1.21)
Target MAC address: 00:00:00:00:00:00 (00:00:00_00:00:00)
Target IP address: 172.16.1.33 (172.16.1.33)
The broadcast address m eans t hat all devices on t he dat a link will receive t he fram e and
exam ine t he encapsulat ed packet . All devices except t he t arget will recognize t hat t he packet is
not for t hem and will drop t he packet . The t arget will send an ARP Reply t o t he source address,
supplying it s MAC address ( see Exam ple 1- 7) .
Ex a m ple 1 - 7 . An a n a lyze r ca pt u r e of t h e ARP Re ply de pict e d in Figu r e
1-13.
Ethernet II, Src: 00:10:5a:e5:0e:e3, Dst: 00:30:65:2c:09:a6
Destination: 00:30:65:2c:09:a6 (AppleCom_2c:09:a6)
Source: 00:10:5a:e5:0e:e3 (3com_e5:0e:e3)
Type: ARP (0x0806)
Trailer: 15151515151515151515151515151515...
Address Resolution Protocol (reply)
Hardware type: Ethernet (0x0001)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: reply (0x0002)
Sender MAC address: 00:10:5a:e5:0e:e3 (3com_e5:0e:e3)
Sender IP address: 172.16.1.33 (172.16.1.33)
Target MAC address: 00:30:65:2c:09:a6 (AppleCom_2c:09:a6)
Target IP address: 172.16.1.21 (172.16.1.21)
Cisco rout ers will display ARP act ivit y when t he debug funct ion de bu g a r p is invoked, as shown
in Exam ple 1- 8.
Ex a m ple 1 - 8 . Rou t e r Ar e t h a ( 1 7 2 .2 1 .5 .1 ) r e spon ds t o a n ARP r e qu e st
fr om h ost 1 7 2 .1 9 .3 5 .2 .
Aretha#debug arp
IP ARP: rcvd req src 172.19.35.2 0002.6779.0f4c, dst 172.21.5.1 Ethernet0
IP ARP: sent rep src 172.21.5.1 0000.0c0a.2aa9,
dst 172.19.35.2 0002.6779.0f4c Ethernet0
Aretha#
Figure 1- 14 shows t he ARP packet form at . As t he fields are described, com pare t hem wit h t he
ARP packet s in Exam ple 1- 6 and Exam ple 1- 7.
Figu r e 1 - 1 4 . ARP pa ck e t for m a t .
Hardware Type specifies t he t ype of hardware, as specified by t he I ETF. [ 17] Table 1- 5 shows
som e exam ples of som e of t he m ore com m on t ype num bers.
[17]
All numbers in use in various fields throughout the TCP/IP protocol suite were originally listed in: J. Postel and J.
Reynolds, "Assigned Numbers," RFC 1700, October 1994. This large document (230 pages) is a valuable reference, but is
now a bit outdated. A current list of assigned numbers can be found at www.iana.org.
Ta ble 1 - 5 . Com m on
h a r dw a r e t ype code s.
N u m be r
H a r dw a r e Type
1
Et hernet
3
X.25
4
Prot eon ProNET Token
Ring
6
I EEE 802 Net works
7
ARCnet
N u m be r
H a r dw a r e Type
11
Apple LocalTalk
14
SMDS
15
Fram e Relay
16
ATM
17
HDLC
18
Fibre Channel
19
ATM
20
Serial Link
Prot ocol Type specifies t he t ype of net work- level prot ocol t he sender is m apping t o t he dat a link
ident ifier; I Pv4 is 0x0800.
Hardware Address Lengt h specifies t he lengt h, in oct et s, of t he dat a link ident ifiers. MAC
addresses would be 6.
Prot ocol Address Lengt h specifies t he lengt h, in oct et s, of t he net work- level address. I Pv4 would
be 4.
Operat ion specifies whet her t he packet is an ARP Request ( 1) or an ARP Reply ( 2) . Ot her values
m ight also be found here, indicat ing ot her uses for t he ARP packet . Exam ples are Reverse ARP
Request ( 3) , Reverse ARP Reply ( 4) , I nverse ARP Request ( 8) , and I nverse ARP Reply ( 9) .
The final 20 oct et s are t he fields for t he sender's and t arget 's dat a- link ident ifiers and I Pv4
addresses.
I n t he t op screen in Exam ple 1- 9, t he I OS com m and sh ow a r p is used t o exam ine t he ARP t able
in a Cisco rout er.
Ex a m ple 1 - 9 . Th e ARP t a ble for t h r e e de vice s con n e ct e d t o t h e sa m e
n e t w or k : a Cisco r ou t e r , a M icr osoft W in dow s h ost , a n d a Lin u x h ost .
Martha#show arp
Protocol Address
Age (min)
Hardware Addr Type Interface
Internet 10.158.43.34
2
0002.6779.0f4c ARPA Ethernet0
Internet 10.158.43.1
0000.0c0a.2aa9 ARPA Ethernet0
Internet 10.158.43.25
18
00a0.24a8.a1a5 ARPA Ethernet0
Internet 10.158.43.100
6
0000.0c0a.2c51 ARPA Ethernet0
Martha#
________________________________________________________________________
C:\WINDOWS>arp -a
Interface: 148.158.43.25
Internet Address
Physical Address
Type
10.158.43.1
00-00-0c-0a-2a-a9
dynamic
10.158.43.34
00-02-67-79-0f-4c
dynamic
10.158.43.100
00-00-0c-0a-2c-51
dynamic
_________________________________________________________________________
Linux:~# arp -a
Address
10.158.43.1
10.158.43.100
10.158.43.25
Linux:~#
HW type
10Mbps Ethernet
10Mbps Ethernet
10Mbps Ethernet
HW address
00:00:0C:0A:2A:A9
00:00:0C:0A:2C:51
00:A0:24:A8:A1:A5
Flags
C
C
C
Mask
*
*
*
Not ice t he Age colum n. As t his colum n would indicat e, ARP inform at ion is rem oved from t he
t able aft er a cert ain t im e t o prevent t he t able from becom ing congest ed wit h old inform at ion.
Cisco rout ers hold ARP ent ries for four hours ( 14,400 seconds) ; t his default can be changed. The
following exam ple changes t he ARP t im eout t o 30 m inut es ( 1800 seconds) :
Martha(config)# interface ethernet 0
Martha(config-if)# arp timeout 1800
The m iddle screen of Exam ple 1- 9 shows t he ARP t able of a Microsoft Windows PC, and t he
bot t om shows t he ARP t able from a Linux m achine. Alt hough t he form at is different from t he I OS
display, t he essent ial inform at ion is t he sam e in all t hree t ables.
ARP ent ries m ight also be perm anent ly placed in t he t able. To st at ically m ap 172.21.5.131 t o
hardware address 0000.00a4.b74c, wit h a SNAP ( Subnet work Access Prot ocol) encapsulat ion
t ype, use t he following:
Martha(config)# arp 172.21.5.131 0000.00a4.b74c snap
The com m and cle a r a r p- ca ch e forces a delet ion of all dynam ic ent ries from t he ARP t able. I t
also clears t he fast - swit ching cache and t he I P rout e cache.
Several variat ions of ARP exist ; at least one, proxy ARP, is im port ant t o rout ing.
Proxy ARP
Som et im es called prom iscuous ARP and described in RFCs 925 and 1027, proxy ARP is a m et hod
by which rout ers m ight m ake t hem selves available t o host s. For exam ple, a host
192.168.12.5/ 24 needs t o send a packet t o 192.168.20.101/ 24, but it is not configured wit h
default gat eway inform at ion and t herefore does not know how t o reach a rout er. I t m ight issue
an ARP Request for 192.168.20.101; t he local rout er, receiving t he request and knowing how t o
reach net work 192.168.20.0, will issue an ARP Reply wit h it s own dat a link ident ifier in t he
hardware address field. I n effect , t he rout er has t ricked t he local host int o t hinking t hat t he
rout er's int erface is t he int erface of 192.168.20.101. All packet s dest ined for t hat address are
t hen sent t o t he rout er.
Figure 1- 15 shows anot her use for proxy ARP. Of part icular int erest here are t he address m asks.
The rout er is configured wit h a 28- bit m ask ( four bit s of subnet t ing for t he Class C address) , but
t he host s are all configured wit h 24- bit , default Class C m ask. As a result , t he host s will not be
aware t hat subnet s exist . Host 192.168.20.66, want ing t o send a packet t o 192.168.20.25, will
issue an ARP Request . The rout er, recognizing t hat t he t arget address is on anot her subnet , will
respond wit h it s own hardware address. Proxy ARP m akes t he subnet t ed net work t opology
t ransparent t o t he host s.
Figu r e 1 - 1 5 . Pr ox y ARP e n a ble s t h e u se of t r a n spa r e n t su bn e t s.
The ARP cache in Exam ple 1- 10 gives a hint t hat proxy ARP is in use. Not ice t hat m ult iple I Pv4
addresses are m apped t o a single MAC ident ifier; t he addresses are for host s, but t he hardware
MAC ident ifier belongs t o t he rout er int erface.
Ex a m ple 1 - 1 0 . Th is ARP t a ble fr om h ost 1 9 2 .1 6 8 .2 0 .6 6 in Figu r e 1 - 1 5
sh ow s m u lt iple I Pv4 a ddr e sse s m a ppe d t o on e M AC ide n t ifie r ,
in dica t in g t h a t pr ox y ARP is in u se .
C:\WINDOWS>arp -a
Interface: 192.168.20.66
Internet Address
Physical Address
192.168.20.17
00-00-0c-0a-2a-a9
192.168.20.20
00-00-0c-0a-2a-a9
192.168.20.25
00-00-0c-0a-2a-a9
192.168.20.65
00-00-0c-0a-2c-51
192.168.20.70
00-02-67-79-0f-4c
Type
dynamic
dynamic
dynamic
dynamic
dynamic
Proxy ARP is enabled by default in I OS and m ight be disabled on a per int erface basis wit h t he
com m and n o ip pr ox y- a r p .
Gratuitous ARP
A host m ight occasionally issue an ARP Request wit h it s own I Pv4 address as t he t arget address.
These ARP Request s, known as gr at uit ous ARPs, have several uses:
A grat uit ous ARP m ight be used for duplicat e address checks. A device t hat issues an ARP
Request wit h it s own I Pv4 address as t he t arget and receives an ARP Reply from anot her
device will know t hat t he address is a duplicat e.
A grat uit ous ARP m ight be used t o advert ise a new dat a- link ident ifier. This use t akes
advant age of t he fact t hat when a device receives an ARP Request for an I Pv4 address t hat
is already in it s ARP cache, t he cache will be updat ed wit h t he sender's new hardware
address.
A rout er running Hot St andby Rout er Prot ocol ( HSRP) t hat has j ust t aken over as t he act ive
rout er from anot her rout er on a subnet issues a grat uit ous ARP t o updat e t he ARP caches of
t he subnet 's host s.
Many I P im plem ent at ions do not use grat uit ous ARP, but you should be aware of it s exist ence. I t
is disabled by default in I OS but can be enabled wit h t he com m and ip gr a t u it ou s- a r ps.
Reverse ARP
I nst ead of m apping a hardware address t o a known I Pv4 address, Reverse ARP ( RARP) m aps an
I Pv4 address t o a known hardware address. Som e devices, such as diskless workst at ions, m ight
not know t heir I Pv4 address at st art up. RARP m ight be program m ed int o firm ware on t hese
devices, allowing t hem t o issue an ARP Request t hat has t heir burned- in hardware address. The
reply from a RARP server will supply t he appropriat e I Pv4 address.
RARP has been largely supplant ed by Dynam ic Host Configurat ion Prot ocol ( DHCP) , an ext ension
Internet Control Message Protocol (ICMP)
The I nt ernet Cont rol Message Prot ocol, or I CMP, described in RFC 792, specifies a variet y of
m essages whose com m on purpose is t o m anage t he net work. I CMP m essages m ight be classified
as eit her error m essages or queries and responses. Figure 1- 16 shows t he general I CMP packet
form at . The packet s are ident ified by t ype; m any of t he packet t ypes have m ore specific t ypes,
and t hese are ident ified by t he code field. Table 1- 6 list s t he various I CMP packet t ypes and t heir
codes, as described in RFC 1700.
Figu r e 1 - 1 6 . Th e I CM P pa ck e t h e a de r in clu de s a t ype fie ld, a code fie ld
t h a t fu r t h e r ide n t ifie s som e t ype s, a n d a ch e ck su m . Th e r e st of t h e
fie lds de pe n d on t h e t ype a n d code .
Ta ble 1 - 6 . I CM P pa ck e t t ype s a n d code fie lds.
Type
Code
Nam e
0
0
ECHO REPLY
3
DESTI NATI ON UNREACHABLE
0
Net work Unreachable
1
Host Unreachable
2
Prot ocol Unreachable
3
Port Unreachable
4
Fragm ent at ion Needed and Don't Fragm ent Flag
Set
5
Source Rout e Failed
6
Dest inat ion Net work Unknown
Type
4
Code
Nam e
7
Dest inat ion Host Unknown
8
Source Host I solat ed
9
Dest inat ion Net work Adm inist rat ively Prohibit ed
10
Dest inat ion Host Adm inist rat ively Prohibit ed
11
Dest inat ion Net work Unreachable for Type of
Service
12
Dest inat ion Host Unreachable for Type of
Service
0
SOURCE QUENCH ( deprecat ed)
5
REDI RECT
0
Redirect Dat agram for t he Net work ( or Subnet )
1
Redirect Dat agram for t he Host
2
Redirect Dat agram for t he Net work and Type of
Service
3
Redirect Dat agram for t he Host and Type of
Service
6
0
ALTERNATE HOST ADDRESS
8
0
ECHO
9
0
ROUTER ADVERTI SEMENT
10
0
ROUTER SELECTI ON
11
TI ME EXCEEDED
0
Tim e t o Live Exceeded in Transit
1
Fragm ent Reassem bly Tim e Exceeded
12
PARAMETER PROBLEM
0
Point er I ndicat es t he Error
1
Missing a Required Opt ion
2
Bad Lengt h
13
0
TI MESTAMP
14
0
TI MESTAMP REPLY
15
0
I NFORMATI ON REQUEST ( Obsolet e)
16
0
I NFORMATI ON REPLY ( Obsolet e)
17
0
ADDRESS MASK REQUEST ( Near- obsolet e)
18
0
ADDRESS MASK REPLY ( Near- obsolet e)
30
-
TRACEROUTE
Exam ple 1- 11 and Exam ple 1- 12 show analyzer capt ures of t wo of t he m ost well- known I CMP
m essagesEcho Request and Echo Reply, which are used by t he ping funct ion.
Ex a m ple 1 - 1 1 . I CM P Ech o m e ssa ge , sh ow n w it h it s I Pv4 h e a de r .
Internet Protocol, Src Addr: 172.16.1.21 (172.16.1.21),
Dst Addr: 198.133.219.25 (198.133.219.25)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 84
Identification: 0xabc3 (43971)
Flags: 0x00
Fragment offset: 0
Time to live: 64
Protocol: ICMP (0x01)
Header checksum: 0x8021 (correct)
Source: 172.16.1.21 (172.16.1.21)
Destination: 198.133.219.25 (198.133.219.25)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xa297 (correct)
Identifier: 0x0a40
Sequence number: 0x0000
Data (56 bytes)
0000
0010
0020
0030
40
10
20
30
fd
11
21
31
ab
12
22
32
c2
13
23
33
00
14
24
34
0e
15
25
35
73
16
26
36
57 08 09 0a 0b 0c 0d 0e 0f
17 18 19 1a 1b 1c 1d 1e 1f
27 28 29 2a 2b 2c 2d 2e 2f
37
@.....sW........
................
!"#$%&'()*+,-./
01234567
Ex a m ple 1 - 1 2 . I CM P Ech o Re ply.
Internet Protocol, Src Addr: 198.133.219.25 (198.133.219.25),
Dst Addr: 172.16.1.21 (172.16.1.21)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 84
Identification: 0xabc3 (43971)
Flags: 0x00
Fragment offset: 0
Time to live: 242
Protocol: ICMP (0x01)
Header checksum: 0xce20 (correct)
Source: 198.133.219.25 (198.133.219.25)
Destination: 172.16.1.21 (172.16.1.21)
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0xaa97 (correct)
Identifier: 0x0a40
Sequence number: 0x0000
Data (56 bytes)
0000
0010
0020
0030
40
10
20
30
fd
11
21
31
ab
12
22
32
c2
13
23
33
00
14
24
34
0e
15
25
35
73
16
26
36
57 08 09 0a 0b 0c 0d 0e 0f
17 18 19 1a 1b 1c 1d 1e 1f
27 28 29 2a 2b 2c 2d 2e 2f
37
@.....sW........
................
!"#$%&'()*+,-./
01234567
Alt hough m ost I CMP t ypes have som e bearing on rout ing funct ionalit y, t hree t ypes are of
part icular im port ance:
Rout er Advert isem ent and Rout er Select ion , t ypes 9 and 10, respect ively, are used by t he
I CMP Rout er Discovery Prot ocol ( I RDP) , a prot ocol used by som e operat ing syst em s ( such
as m ost versions of Microsoft Windows) t o discover local rout ers.
Redirect , I CMP t ype 5, is used by rout ers t o not ify host s of anot her rout er on t he dat a link
t hat should be used for a part icular dest inat ion. Suppose t wo rout ers, Rout er A and Rout er
B, are connect ed t o t he sam e Et hernet . Host X, also on t he Et hernet , is configured t o use
Rout er A as it s default gat eway; t he host sends a packet t o Rout er A, and A sees t hat t he
dest inat ion address of t he packet is reachable via Rout er B ( t hat is, Rout er A m ust forward
t he packet out t he sam e int erface on which it was received) . Rout er A forwards t he packet
t o B but also sends an I CMP redirect t o host X inform ing it t hat in t he fut ure, t o reach t hat
part icular dest inat ion, X should forward t he packet t o Rout er B. Exam ple 1- 13 shows a
rout er sending a redirect .
Ex a m ple 1 - 1 3 . Usin g t h e de bu ggin g fu n ct ion de bu g ip icm p, t h is r ou t e r
ca n be se e n se n din g a r e dir e ct t o h ost 1 0 .1 5 8 .4 3 .2 5 , in for m in g it t h a t
t h e cor r e ct r ou t e r for r e a ch in g de st in a t ion 1 0 .1 5 8 .4 0 .1 is r e a ch a ble
via ga t e w a y ( gw ) 1 0 .1 5 8 .4 3 .1 0 .
Pip#debug ip icmp
ICMP packet debugging is on
ICMP: redirect sent to 10.158.43.25 for dest 10.158.40.1, use gw 10.158.43.10
0
Pip#
An occasionally used t rick t o avoid redirect s on dat a links wit h m ult iple at t ached gat eways is t o
set each host 's default gat eway as it s own I Pv4 address. The host s will t hen ARP for any
address, and if t he address is not on t he dat a link, t he correct rout er should respond via proxy
ARP. The benefit s of using t his t act ic m erely t o avoid redirect s are debat able; redirect s are
Host-to-Host Layer
The host - t o- host layer of t he TCP/ I P prot ocol is apt ly nam ed. Whereas t he int ernet layer is
responsible for t he logical pat hs bet ween net works, t he host - t o- host layer is responsible for t he
full logical pat h bet ween t wo host s on disparat e net works. [ 18] From anot her viewpoint , t he host t o- host layer is an int erface t o t he lower layers of t he prot ocol suit e, freeing applicat ions from
any concern about how t heir dat a is act ually being delivered.
[18]
Similarly, it can be said that the equivalent functions of the OSI session layer, residing above the transport layer, provide
a logical, end-to-end path between two applications across a network.
An analogy t o t his service is a corporat e m ailroom . A package m ight be given t o t he m ailroom
wit h requirem ent s st at ed for it s delivery ( general delivery, overnight ) . The person m aking t he
delivery request does not need t o know, and is probably not int erest ed in, t he act ual m echanics
of delivering t he package. The m ailroom people will arrange for t he proper service ( post al,
FedEx, cross- t own bicycle courier) t o fulfill t he delivery requirem ent s.
The t wo prim ary services offered by t he host - t o- host layer are TCP and UDP.
TCP
The Transm ission Cont rol Prot ocol, or TCP, described in RFC 793, provides applicat ions wit h a
reliable, connect ion- orient ed service. I n ot her words, TCP provides t he appearance of a point - t opoint connect ion.
Point - t o- point connect ions have t wo charact erist ics:
They have only one pat h t o t he dest inat ion. A packet ent ering one end of t he connect ion
cannot becom e lost , because t he only place t o go is t he ot her end.
Packet s arrive in t he sam e order in which t hey are sent .
TCP provides t he appearance of a point - t o- point connect ion, alt hough in realit y t here is no such
connect ion. The int ernet layer TCP uses a connect ionless, best - effort packet delivery service. The
analogy of t his is t he Post al Service. I f a st ack of let t ers is given t o t he m ail carrier for delivery,
t here is no guarant ee t hat t he let t ers will arrive st acked in t he sam e order, t hat t hey will all
arrive on t he sam e day, or indeed t hat t hey will arrive at all. The Post al Service m erely com m it s
t o m aking it s best effort t o deliver t he let t ers.
Likewise, t he int ernet layer does not guarant ee t hat all packet s will t ake t he sam e rout e, and
t herefore t here is no guarant ee t hat t hey will arrive in t he sam e sequence and t im e int ervals as
t hey were sent , or t hat t hey will arrive at all.
On t he ot her hand, a t elephone call is connect ion- orient ed service. Dat a m ust arrive sequent ially
and reliably, or it is useless. Like a t elephone call, TCP m ust first est ablish a connect ion, t hen
t ransfer dat a, and t hen perform a disconnect when t he dat a t ransfer is com plet e.
TCP uses t hree fundam ent al m echanism s t o accom plish a connect ion- orient ed service on t op of a
connect ionless service:
Packet s are labeled wit h sequence num bers so t hat t he receiving TCP service can put out of- sequence packet s int o t he correct sequence before delivering t hem t o t he dest inat ion
applicat ion.
TCP uses a syst em of acknowledgm ent s, checksum s, and t im ers t o provide reliabilit y. A
receiver m ight not ify a sender when it recognizes t hat a packet in a sequence has failed t o
arrive or has errors, or a sender m ight assum e t hat a packet has not arrived if t he receiver
does not send an acknowledgm ent wit hin a cert ain am ount of t im e aft er t ransm ission. I n
bot h cases, t he sender will resend t he packet in quest ion.
TCP uses a m echanism called windowing t o regulat e t he flow of packet s; windowing
decreases t he chances of packet s being dropped because of full buffers in t he receiver.
TCP at t aches a header t o t he applicat ion layer dat a; t he header cont ains fields for t he sequence
num bers and ot her inform at ion necessary for t hese m echanism s, and fields for addresses called
port num bers, which ident ify t he source and dest inat ion applicat ions of t he dat a. The applicat ion
dat a wit h it s at t ached TCP header is t hen encapsulat ed wit hin an I P packet for delivery. Figure
1- 17 shows t he fields of t he TCP header, and Exam ple 1- 14 shows an analyzer capt ure of a TCP
header.
Figu r e 1 - 1 7 . TCP h e a de r for m a t .
Ex a m ple 1 - 1 4 . An a lyze r displa y of a TCP h e a de r .
Ethernet II, Src: 00:0c:41:3c:2b:18, Dst: 00:30:65:2c:09:a6
Internet Protocol, Src Addr: 66.218.71.112 (66.218.71.112),
Dst Addr: 172.16.1.21 (172.16.1.21)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 52
Identification: 0xc0b7 (49335)
Flags: 0x04
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x509d (correct)
Source: 66.218.71.112 (66.218.71.112)
Destination: 172.16.1.21 (172.16.1.21)
Transmission Control Protocol, Src Port: http (80),
Dst Port: 60190 (60190), Seq: 288, Ack: 811, Len: 0
Source port: http (80)
Destination port: 60190 (60190)
Sequence number: 288
Acknowledgement number: 811
Header length: 32 bytes
Flags: 0x0010 (ACK)
Window size: 66608
Checksum: 0xb32a (correct)
Options: (12 bytes)
NOP
NOP
Time stamp: tsval 587733966, tsecr 1425164062
SEQ/ACK analysis
This is an ACK to the segment in frame: 17
The RTT to ACK the segment was: 0.047504000 seconds
Source and Dest inat ion Port are 16- bit fields t hat specify t he source and dest inat ion applicat ions
for t he encapsulat ed dat a. Like ot her num bers used by TCP/ I P, RFC 1700 describes all port
num bers in com m on and not - so- com m on use. A port num ber for an applicat ion, when coupled
wit h t he I P address of t he host t he applicat ion resides on, is called a socket . A socket uniquely
ident ifies every applicat ion in a net work.
Sequence Num ber is a 32- bit num ber t hat ident ifies where t he encapsulat ed dat a fit s wit hin a
dat a st ream from t he sender. For exam ple, if t he sequence num ber of a segm ent is 1343 and
t he segm ent cont ains 512 oct et s of dat a, t he next segm ent should have a sequence num ber of
1343 + 512 + 1 = 1856.
Acknowledgm ent Num ber is a 32- bit field t hat ident ifies t he sequence num ber t he source next
expect s t o receive from t he dest inat ion. I f a host receives an acknowledgm ent num ber t hat does
not m at ch t he next sequence num ber it int ends t o send ( or has sent ) , it knows t hat packet s
have been lost .
Header Lengt h, som et im es called Dat a Offset, is a four- bit field indicat ing t he lengt h of t he
header in 32- bit words. This field is necessary t o ident ify t he beginning of t he dat a because t he
lengt h of t he Opt ions field is variable.
The Reser v ed field is four bit s, which are always set t o zero.
Flags are eight 1- bit flags t hat are used for dat a flow and connect ion cont rol. The flags, from left
t o right , are Congest ion Window Reduced ( CWR) , ECN- Echo ( ECE) , Urgent ( URG) ,
Acknowledgm ent ( ACK) , Push ( PSH) , Reset ( RST) , Synchronize ( SYN) , and Final ( FI N) .
Window Size is a 16- bit field used for flow cont rol. I t specifies t he num ber of oct et s, st art ing wit h
t he oct et indicat ed by t he Acknowledgm ent Num ber, t hat t he sender of t he segm ent will accept
from it s peer at t he ot her end of t he connect ion before t he peer m ust st op t ransm it t ing and wait
for an acknowledgm ent .
Checksum is 16 bit s, covering bot h t he header and t he encapsulat ed dat a, allowing error
det ect ion.
Urgent Point er is used only when t he URG flag is set . The 16- bit num ber is added t o t he
Sequence Num ber t o indicat e t he end of t he urgent dat a.
Opt ions, as t he nam e im plies, specifies opt ions required by t he sender's TCP process. The m ost
com m only used opt ion is Maxim um Segm ent Size, which inform s t he receiver of t he largest
segm ent t he sender is willing t o accept . The rem ainder of t he field is padded wit h zeros t o
ensure t hat t he header lengt h is a m ult iple of 32 oct et s.
UDP
User Dat agram Prot ocol, or UDP, described in RFC 768, provides a connect ionless, best - effort
packet delivery service. At first t ake, it m ight seem quest ionable t hat any applicat ion would
prefer an unreliable delivery over t he connect ion- orient ed TCP. The advant age of UDP, however,
is t hat no t im e is spent set t ing up a connect iont he dat a is j ust sent . Applicat ions t hat send short
burst s of dat a will realize a perform ance advant age by using UDP inst ead of TCP.
Figure 1- 18 shows anot her advant age of UDP: a m uch sm aller header t han TCP. The Source and
Dest inat ion Port fields are t he sam e as t hey are in t he TCP header; t he UDP lengt h indicat es t he
lengt h of t he ent ire segm ent in oct et s. The checksum covers t he ent ire segm ent , but unlike TCP,
t he checksum here is opt ional; when no checksum is used, t he field is set t o all zeros. Exam ple
1- 15 shows an analyzer capt ure of a UDP header.
Figu r e 1 - 1 8 . UD P h e a de r for m a t .
Ex a m ple 1 - 1 5 . An a lyze r displa y of a UD P h e a de r .
Ethernet II, Src: 00:30:65:2c:09:a6, Dst: 00:0c:41:3c:2b:18
Internet Protocol, Src Addr: 172.16.1.21 (172.16.1.21),
Dst Addr: 198.133.219.25 (198.133.219.25)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x8a4d (35405)
Flags: 0x00
Fragment offset: 0
Time to live: 1
Protocol: UDP (0x11)
Header checksum: 0xe0b3 (correct)
Source: 172.16.1.21 (172.16.1.21)
Destination: 198.133.219.25 (198.133.219.25)
User Datagram Protocol, Src Port: 35404 (35404), Dst Port: 33435 (33435)
Source port: 35404 (35404)
Destination port: 33435 (33435)
Length: 20
Checksum: 0x0000 (none)
Data (12 bytes)
0000 01 01 00 00 40 fd ac 74 00 00 d2 45
....@..t...E
Looking Ahead
The focus of t his chapt er has largely been on t he m echanism s by which a device's int ernet layer
( or OSI net work layer) ident ifies it self and how it m aps t o t he net work int erface ( or OSI dat a
link) layer. I nt ernet layer prot ocols such as ARP and I CMP, t hat are im port ant t o rout ing, were
also exam ined. The following chapt er exam ines a newer version of I P, I P version 6, how it differs
from I Pv4, and why a new version of I P is needed.
Summary Table: Chapter 1 Command Review
Com m a n d
D e scr ipt ion
a r p ip- address hardwareaddress t ype [ a lia s]
St at ically m aps an I P address t o a hardware address
a r p t im e ou t seconds
Set s t he am ount of t im e a Cisco rout er holds ARP ent ries
cle a r a r p- ca ch e
Forces t he delet ion of all dynam ic ent ries from t he ARP t able
de bu g ip icm p
Displays I CMP event s as t hey occur on t he rout er
ip a ddr e ss ip- address m ask
[ se con da r y ]
Assigns an I P address and m ask t o an int erface
ip gr a t u it ou s- a r p
Enables grat uit ous ARP
ip n e t m a sk - for m a t { bit cou n t | de cim a l| h e x a de cim a l}
Configures a rout er t o display I P ( address, m ask) pairs in
bit count , dot t ed- decim al, or hexadecim al form at
ip pr ox y- a r p
Enables proxy ARP
ip r e dir e ct s
Enables I CMP redirect s
Recommended Reading
Baker, F., ed. " Requirem ent s for I P Version 4 Rout ers," RFC 1812, June 1995. This paper
docum ent s bot h requirem ent s and recom m endat ions for rout ers t hat will run I P.
Braden, R., ed. " Requirem ent s for I nt ernet Host sCom m unicat ion Layers," RFC 1122, Oct ober
1989. The host - cent ric com panion paper t o RFC 1812.
Com er, D. E. I nt ernet working wit h TCP/ I P, Vol. 1. Englewood Cliffs, New Jersey: Prent ice- Hall;
1991. This book, like Perlm an's, is a classic. Alt hough you don't need t o read bot h Com er and
St evens, doing so cert ainly couldn't hurt .
St evens, W. R. TCP/ I P I llust rat ed, Vol. 1. Reading, Massachuset t s: Addison- Wesley; 1994. This
is an excellent book on TCP/ I P. Along wit h an in- dept h int roduct ion t o t he prot ocols, St evens
offers a wealt h of capt ures from a live net work t hat is diagram m ed inside t he front cover.
Review Questions
1
What are t he five layers of t he TCP/ I P prot ocol suit e? What is t he purpose of each
lay er ?
2
What is t he m ost com m on I P version present ly in use?
3
What is fragm ent at ion? What fields of t he I P header are used for fragm ent at ion?
4
What is t he purpose of t he TTL field in t he I P header? How does t he TTL process
work?
5
What is t he first oct et rule?
6
How are Class A, B, and C I P addresses recognized in dot t ed decim al? How are t hey
recognized in binary?
7
What is an address m ask, and how does it work?
8
What is a subnet ? Why are subnet s used in I P environm ent s?
9
Why can't a subnet of all zeros or all ones be used in a classful rout ing
environm ent ?
10
What is ARP?
11
What is proxy ARP?
12
What is a redirect ?
13
What is t he essent ial difference bet ween TCP and UDP?
14
What m echanism s does TCP use t o provide connect ion- orient ed service?
15
I nst ead of ARP, Novell Net Ware uses a net work address t hat includes a device's
MAC address as t he host port ion. Why can't I P do t his?
16
What purpose does UDP serve by providing a connect ionless service on t op of what
is already a connect ionless service?
Configuration Exercises
1
The first oct et rule says t hat t he highest Class C address is 223, but it is known t hat
for eight bit s t he highest decim al num ber is 255. There are t wo m ore classes: Class
D addresses are for m ult icast , and Class E addresses are for experim ent al usage.
Class D addresses have, as t heir first four bit s, 1110. What is t he decim al range of
t he first oct et of Class D addresses?
2
Select a subnet m ask for 10.0.0.0 so t hat t here will be at least 16,000 subnet s wit h
at least 700 host addresses available on each subnet . Select a subnet m ask for
172.27.0.0 so t hat t here are at least 500 subnet s wit h at least 100 host addresses
available on each subnet .
3
How m any subnet s are available if a Class C address has six bit s of subnet t ing? How
m any host addresses are available per subnet ? I s t here a pract ical use for such a
subnet t ing schem e?
4
Use a 28- bit m ask t o derive t he available subnet s of 192.168.147.0. Derive t he
available host addresses of each subnet .
5
Use a 29- bit m ask t o derive t he available subnet s of 192.168.147.0. Derive t he
available host addresses of each subnet .
6
Use a 20- bit m ask t o derive t he available subnet s of 172.16.0.0. Writ e t he range
( t hat is, t he num erically lowest t o t he num erically highest address) of available host
addresses for each subnet .
Troubleshooting Exercises
1
For t he following host addresses and subnet m asks, find what subnet each address
belongs t o, t he broadcast address of t hat subnet , and t he range of host addresses
for t hat subnet :
10.14.87.60/ 19
172.25.0.235/ 27
172.25.16.37/ 25
2
You have been t old t o configure 192.168.13.175 on an int erface wit h a m ask of
255.255.255.240. I s t here a problem ? I f so, what is it ?
Chapter 2. IPv6 Overview
This chapt er covers t he following subj ect s:
I Pv6 Addresses
I Pv6 Packet Header Form at
Ext ension Headers
I CMPv6
Neighbor Discovery Prot ocol
When t he net works t hat event ually evolved int o what we now call t he I nt ernet were first
launched, t hey were t he exclusive realm of academ ics and researchers. And when Vint Cerf and
Bob Kahn invent ed TCP/ I P for t hese net works, no one envisioned t he I nt ernet as it now is. At t he
t im e a 32- bit address space, yielding alm ost 4.3 billion addresses, seem ed inexhaust ible.
But as t he kids who worked wit h t hese net works in college went out int o t he " real world," t hey
t ook wit h t hem an appreciat ion of t he possibilit ies for what could be done wit h a peer- t o- peer
net work built on open st andards. I ncreasingly useful net work applicat ions began cropping up,
and recognit ion of t he value of corporat e connect ions t o a public net work began t he push for a
com m ercial I nt ernet . At t he sam e t im e t hat all t his was happening, deskt op com put ers were
becom ing com m on not only in t he office but , m ost significant ly, in t he hom e. Yet m odem s were
not a com m on accessory on t hose early hom e com put ers because few hom e users saw t he value
of being connect ed t o a public net work.
That changed wit h t he advent of t he World Wide Web. Suddenly, easy acquisit ion and sharing of
inform at ion exponent ially increased t he value of deskt op com put ers as a t ool for nont echnical
users. As a result , in less t han 20 years t he I nt ernet has changed t he way we com m unicat e, do
business, and learn. I t has m ade t he world a m uch sm aller place, and has had profound im pact
on world econom ics and polit ics.
But t his explosion in t he size and diversit y of t he " I nt ernet populat ion" has int roduced, along
wit h daily nuisances such as spam and viruses, a serious t echnical concern: The once
inexhaust ible supply of I Pv4 addresses has becom e dist inct ly finit e.
The problem of I Pv4 address exhaust ion was recognized in t he early 1990s, when various
expert s m ade proj ect ions showing t hat if t he increasing rat e of t he allot m ent of I Pv4 addresses
cont inued, t he ent ire address space could be deplet ed in j ust a few short years. A new version of
I Pknown in t he developm ent st age as I P Next Generat ion or I Png, and which is now I Pv6was t he
proposed solut ion. But it was recognized t hat developing t he new st andards would t ake t im e,
and t hat a short - t erm solut ion t o I Pv4 address deplet ion also was needed.
That short - t erm solut ion was Net work Address Translat ion ( NAT) , which allows m ult iple host s t o
share one or a few public I P addresses. Behind t he NAT device, privat e I P addresses as specified
in RFC 1918, and which you see in m ost exam ples in t his book, are used. NAT has been so
successful in slowing I Pv4 address deplet ion, and has becom e such a st andard part of m ost
net works, t hat t o t his day m any st ill quest ion t he need for a new version of I P. But t he
widespread use of NAT has changed t he open, t ransparent , peer- t o- peer I nt ernet int o som et hing
m uch m ore like a huge collect ion of client - server net works. Users are seen as being connect ed
around t he " edge" of t he I nt ernet , and services flow out t o t hem . Seldom do users cont ribut e t o
t he overall wealt h of t he I nt ernet . Seen from a m ore econom ic perspect ive, I nt ernet users have
becom e consum ers only, not producers.
Alt hough m ost of t he I Pv6 st andards were com plet ed years ago, it is only recent ly t hat serious
int erest in m igrat ing from I Pv4 t o I Pv6 has been shown. There are t wo fundam ent al drivers
behind t he growing recognit ion of t he need for I Pv6. The first is widespread vision of new
applicat ions using core concept s such as m obile I P, service qualit y guarant ees, end- t o- end
securit y, grid com put ing, and peer- t o- peer net working. NAT st ifles innovat ion in t hese areas,
and t he only way t o get NAT out of t he way is t o m ake public I P addresses abundant and readily
av ailable.
The second fundam ent al driver for I Pv6 is t he rapid m odernizat ion of heavily populat ed count ries
such as I ndia and China. A com pelling st at ist ic is t hat t he num ber of rem aining unallocat ed I Pv4
addresses is alm ost t he sam e as t he populat ion of China: about 1.3 billion. Wit h it s aggressive
expansion of it s I nt ernet infrast ruct ure, China alone in t he near fut ure will represent an
unsupport able pressure on an already st rained I Pv4 address pool. I n I ndia, wit h a populat ion
size close t o China's, 4- and 5- layer NAT hierarchies exist j ust t o support t he present dem ands
for I P addresses.
I Pv6 replaces t he 32- bit I Pv4 address wit h a 128- bit address, m aking 340 t rillion t rillion t rillion
I P addresses available. That num ber will m eet t he dem ands for public I P addresses, and answer
t he needs of t he t wo fundam ent al drivers discussed here, well int o t he foreseeable fut ure. [ 1]
[1]
Given what was unforeseen when IPv4's 4.3 billion addresses were thought to be limitless for all practical purposes, the
almost inconceivably vast IPv6 address space will never be considered inexhaustible.
IPv6 Addresses
I Pv6 addresses are different from I Pv4 addresses in far m ore ways t han j ust t heir lengt h. The
" short hand" for writ ing t hem is different , t hey have significant ly different form at s, and t heir
funct ional organizat ion is different . This sect ion int roduces you t o t hose differences.
Address Representation
You cert ainly already know t hat 32- bit I Pv4 addresses are represent ed by breaking t hem int o
four 8- bit segm ent s and writ ing each of t hose segm ent s in decim al bet ween 0 and 255,
separat ing t hem wit h periods; hence t he t erm dot t ed decim al.
128- bit I Pv6 addresses are represent ed by breaking t hem up int o eight 16- bit segm ent s. Each
segm ent is writ t en in hexadecim al bet ween 0x0000 and 0xFFFF, separat ed by colons. An
exam ple of a writ t en I Pv6 address is
3ffe: 1944: 0100: 000a: 0000: 00bc: 2500: 0d0b
Rem em bering m ore t han a few such addresses is pract ically im possible, and writ ing t hem is not
m uch fun eit her. Fort unat ely, t here are t wo rules for reducing t he size of writ t en I Pv6 addresses.
The first rule is
The leading zeroes in any 16- bit segm ent do not have t o be writ t en; if any 16- bit segm ent has
fewer t han four hexadecim al digit s, it is assum ed t hat t he m issing digit s are leading zeroes.
I n t he exam ple address, t he t hird, fourt h, fift h, sixt h, and eight h segm ent s have leading zeroes.
Using t he first address com pression rule, t he address can be writ t en as
3ffe: 1944: 100: a: 0: bc: 2500: d0b
Not ice t hat only leading zeroes can be om it t ed; t railing zeroes cannot , because doing so would
m ake t he segm ent am biguous. You would not be able t o t ell whet her t he m issing zeroes
belonged before or aft er t he writ t en digit s.
Not ice also t hat t he fift h segm ent in t he exam ple address is all zeroes, and is writ t en wit h a
single zero. Many I Pv6 addresses have long st rings of zeroes in t hem . Take, for exam ple, t he
following address:
ff02: 0000: 0000: 0000: 0000: 0000: 0000: 0005
This address can be reduced as follows:
ff02: 0: 0: 0: 0: 0: 0: 5
However, using t he second rule can reduce t his address even furt her:
Any single, cont iguous st ring of one or m ore 16- bit segm ent s consist ing of all zeroes can be
represent ed wit h a double colon.
Using t his rule, t he exam ple address can be represent ed as t he following:
ff02: : 5
The increased convenience in writ ing such an address is obvious. But not ice t hat t he rule says
only a single cont iguous st ring of all- zero segm ent s can be represent ed wit h a double colon.
Using t he double colon m ore t han once in an I Pv6 address can creat e am biguit y. Take, for
exam ple, t he following address:
2001: 0d02: 0000: 0000: 0014: 0000: 0000: 0095
Eit her of t he following reduct ions of t he address is correct because t hey use a double colon only
once:
2001: d02: : 14: 0: 0: 95
2001: d02: 0: 0: 14: : 95
But t he following reduct ion is illegal because it uses t he double colon t wice:
2001: d02: : 14: : 95
I t is illegal because t he lengt h of t he t wo all- zero st rings is am biguous; it could represent any of
t he following I Pv6 addresses:
2001: 0d02: 0000: 0000: 0014: 0000: 0000: 0095
2001: 0d02: 0000: 0000: 0000: 0014: 0000: 0095
2001: 0d02: 0000: 0014: 0000: 0000: 0000: 0095
Unlike I Pv4, in which t he prefixt he net work port ion of t he addresscan be ident ified by a dot t ed
decim al or hexadecim al address m ask or a bit count , I Pv6 prefixes are always ident ified by
bit count . That is, t he address is followed by a forward slash and a decim al num ber indicat ing
how m any of t he first bit s of t he address are t he prefix bit s. For exam ple, t he prefix of t he
following address is t he first 64 bit s:
3ffe: 1944: 100: a: : bc: 2500: d0b/ 64
When you are writ ing j ust an I Pv6 prefix, you set all t he host bit s t o 0 t he sam e way you do wit h
I Pv4 addresses. For exam ple
3ffe: 1944: 100: a: : / 64
An I Pv6 address consist ing of all zeroes can be writ t en sim ply wit h a double colon. There are t wo
cases where an all- zeroes address is used. The first is a default address, discussed in Chapt er
12 , " Default Rout es and On- Dem and Rout ing," in which t he address is all zeroes and t he prefix
lengt h is zero:
::/0
The second all- zeroes I Pv6 address is an unspecified address, which is used in som e Neighbor
Discovery Prot ocol procedures described lat er in t his chapt er. An unspecified address is a filler,
indicat ing t he absence of a real I Pv6 address. When writ ing an unspecified address, it is
different iat ed from a default address by it s prefix lengt h:
: : / 128
IPv6 Address Types
The t hree t ypes of I Pv6 address follow:
Unicast
Anycast
Mult icast
Unlike I Pv4, t here is no I Pv6 broadcast address. There is, however, an " all nodes" m ult icast
address, which serves essent ially t he sam e purpose as a broadcast address.
Global Unicast Addresses
A unicast address is an address t hat ident ifies a single device. A global unicast address is a
unicast address t hat is globally unique. The general form at of t he I Pv6 unicast address is shown
in Figure 2- 1 . This form at , specified in RFC 3587, obsolet es and sim plifies an earlier form at t hat
divided t he I Pv6 unicast address int o Top Level Aggregat or ( TLA) , Next - Level Aggregat or ( NLA) ,
and ot her fields. However, you should be aware t hat t his obsolescence is relat ively recent and
you are likely t o encount er som e books and docum ent s t hat show t he old I Pv6 address form at .
Figu r e 2 - 1 . Th e I Pv6 ge n e r a l u n ica st a ddr e ss for m a t .
The host port ion of t he address is called t he I nt erface I D. The reason for t his nam e is t hat a host
can have m ore t han one I Pv6 int erface, and so t he address m ore correct ly ident ifies an int erface
on a host t han a host it self. But t hat subt let y only goes so far: A single int erface can have
m ult iple I Pv6 addresses, and can have an I Pv4 address in addit ion, in which case t he I nt erface
I D is only one of t hat int erface's several ident ifiers.
Perhaps t he m ost st riking difference bet ween I Pv4 addresses and I Pv6 addresses, aside from
t heir lengt hs, is t he locat ion of t he Subnet I dent ifier as a part of t he net work port ion of t he
address rat her t han t he host port ion. A legacy of t he I Pv4 address class archit ect ure is t hat t he
subnet port ion of an I Pv4 address is t aken from t he host port ion of t he address. As a result , t he
host port ion of t he I Pv4 address varies not only wit h it s class, but also wit h t he num ber of bit s
you use for subnet ident ificat ion.
The im m ediat e benefit of m aking t he I Pv6 Subnet I D field a part of t he net work port ion of t he
address is t hat t he I nt erface I D can be a consist ent size for all I Pv6 addresses, sim plifying t he
parsing of t he address. And m aking t he Subnet I D a part of t he net work port ion creat es a clear
separat ion of funct ions: The net work port ion provides t he locat ion of a device down t o t he
specific dat a link and t he host port ion provides t he ident it y of t he device on t he dat a link.
The I nt erface I D of t he global I Pv6 address is, wit h very few except ions, 64 bit s long. Also wit h
very few except ions, t he Subnet I D field is 16 bit s ( Figure 2- 2 ) . A 16- bit Subnet I D field provides
for 65,536 separat e subnet s; it seem s t hat using a fixed Subnet I D size such as t his, when in
m ost cases t he capacit y will not be nearly fully used, is wast eful. But given t he overall size of t he
I Pv6 address space, and given t he benefit s of easy address assignm ent , design, m anagem ent ,
and parsing t hat com es from using a fixed size, t he wast e is j ust ified.
Figu r e 2 - 2 . Th e st a n da r d fie ld size s of t h e globa l u n ica st I Pv6 a ddr e ss.
The I ANA and t he Regional I nt ernet Regist ries ( RI Rs) [ 2] assign I Pv6 prefixesnorm ally / 32 or / 35
in lengt ht o t he Local I nt ernet Regist ries ( LI Rs) . The LI Rs, which are usually large I nt ernet
Service Providers, t hen allocat e longer prefixes t o t heir cust om ers. I n t he m aj orit y of cases, t he
prefixes assigned by t he LI Rs are / 48. There are, however, as m ent ioned in t he previous
paragraph, a few except ions in which t he LI R m ight assign a prefix of a different lengt h:
[2]
As of this writing there are five RIRs: Réseaux IP Européens (RIPE) serves Europe, the Middle East, and Central Asia;
Latin American and Caribbean Internet Address Registry (LACNIC) serves Central and South America and the Caribbean;
American Registry for Internet Numbers (ARIN) serves North America and parts of the Caribbean; AfriNIC serves Africa;
and Asia Pacific Network Information Centre serves Asia and the Pacific Ocean nations.
I f t he cust om er is very large, a prefix short er t han / 48 m ight be assigned.
I f one and only one subnet is t o be addressed, a / 64 m ight be assigned.
I f one and only one device is t o be addressed, a / 128 m ight be assigned.
Identifying IPv6 Address Types
The first few bit s of t he address specify t he address t ype. For exam ple, t he first t hree bit s of all
global unicast addresses current ly are 001. As a result , recognizing t he hexadecim al
represent at ions of global unicast addresses is fairly easy: They all st art wit h eit her 2 or 3,
depending on t he value of t he fourt h bit in t he global rout ing prefix. So, for inst ance, current ly
allocat ed prefixes used by t he 6Bone ( t he public I Pv6 research net work) begin wit h 3ffe, and
I Pv6 addresses current ly allocat ed by t he RI Rs begin wit h 2001.
Binary 001 is expect ed t o suffice for global unicast addresses for som e t im e t o com e; a few
ot her bit com binat ions are assigned t o ot her defined address t ypes, and t he m aj orit y of leading
bit com binat ions are reserved. Table 2- 1 list s t he current ly allocat ed leading bit com binat ions,
and t he following subsect ions describe t he ot her m aj or I Pv6 address t ypes.
Ta ble 2 - 1 . H igh - or de r bit s of I Pv6 a ddr e ss t ype s.
Addr e ss Type
H igh - Or de r Bit s ( bin a r y)
H igh - Or de r Bit s ( H e x )
Unspecified
00...0
: : / 128
Loopback
00...1
: : 1/ 128
Mult icast
11111111
FF00: : / 8
Link- Local Unicast
1111111010
FF80: : / 10
Sit e- Local Unicast
( Deprecat ed)
1111111011
FFC0: : / 10
Global Unicast ( Current ly
allocat ed)
001
2xxx: : / 4 or 3xxx: : / 4
Reserved ( Fut ure global
unicast allocat ions)
Everyt hing else
Local Unicast Addresses
When we t alk of global unicast addresses, we m ean an address wit h global scope. That is, an
address t hat is globally unique and can t herefore be rout ed globally wit h no m odificat ion.
I Pv6 also has a link- local unicast address, which is an address whose scope is confined t o a
single link. I t s uniqueness is assured only on one link, and an ident ical address m ight exist on
anot her link, so t he address is not rout able off it s link. As you can see in Table 2- 1, t he first 10
bit s of t he link- local unicast address are always 1111111010 ( FF80: : / 10) .
As subsequent sect ions in t his chapt er dem onst rat e, link- local addresses have great ut ilit y for
funct ions such as t he Neighbor Discovery Prot ocol t hat com m unicat es only on a single link. I t
also allows devices t hat are on links t hat do not have assigned global prefixes, or devices t hat do
not yet know t he global prefix assigned t o t he link, t o creat e I Pv6 addresses t hat allow t hem t o
com m unicat e wit h ot her devices on t he link. The sect ion "Address Aut oconfigurat ion" shows how
link- local prefixes are used in t his sit uat ion.
I Pv6 originally defined a sit e- local unicast address in addit ion t o t he link- local address. A sit elocal address is unique only wit hin a given sit e; devices in ot her sit es can use t he sam e address.
Therefore a sit e- local address is rout able only wit hin t he sit e t o which it is assigned. Sit e- local
I Pv6 addresses are, t hen, funct ionally sim ilar t o privat e I Pv4 addresses as defined in RFC 1918.
Advocat es of sit e- local addresses cit e several applicat ions. One prom inent applicat ion is for
net work operat ors t hat wish t o use NAT, even wit h I Pv6 addresses, t o m aint ain independence of
t heir address archit ect ure from t hat of t heir service providers. Sit e- local addresses are also key
t o several proposed I Pv6 m ult ihom ing m echanism s.
However, t he I ETF I Pv6 Working Group det erm ined t hat sit e- local unicast addresses int roduced a
num ber of difficult ies. Not t he least of t he difficult ies is t he fact t hat t he definit ion of a " sit e" is
vague and can m ean different t hings t o different net work adm inist rat ors. Anot her problem is
concern over, like RFC 1918 I Pv4 addresses, t he adm inist rat ive difficult ies int roduced when such
addresses are m ist akenly " leaked" out side of t heir int ended sit e boundaries. Ot her pot ent ial
problem s cit ed include increased com plexit y for applicat ions and rout ers t hat m ust recognize and
cope wit h sit e- local addresses. As a result of t hese concerns, and aft er som e heat ed debat e, t he
I Pv6 Working Group deprecat ed sit e- local addresses in RFC 3879. An assurance has been given
t o t hose who see advant ages in sit e- local addresses t o int roduce anot her schem e wit h sim ilar
" bigger scope t han link but sm aller scope t han global" benefit s, but as of t his writ ing such a
replacem ent schem e has yet t o be seen.
The first 10 bit s of sit e- local unicast addresses, as shown in Table 2- 1, is 1111111011
( FFC0: : / 10) .
Anycast Addresses
An anycast address represent s a service rat her t han a device, and t he sam e address can reside
on one or m ore devices providing t he sam e service. I n Figure 2- 3 , som e service is offered by
t hree servers, all advert ising t he service at t he I Pv6 address 3ffe: 205: 1100: : 15. The rout er,
receiving advert isem ent s for t he address, does not know t hat it is being advert ised by t hree
different devices; inst ead, t he rout er assum es t hat it has t hree rout es t o t he sam e dest inat ion
and chooses t he lowest - cost rout e. I n Figure 2- 3 t his is t he rout e t o server C wit h a cost of 20.
Figu r e 2 - 3 . An a n yca st a ddr e ss r e pr e se n t s a se r vice t h a t m igh t a ppe a r
on m u lt iple de vice s.
The advant age of anycast addresses is t hat a rout er always rout es t o t he " closest " or " lowest cost " server. [ 3] So servers providing som e com m only used service can be spread across a large
net work and t raffic can be localized or scoped t o t he nearest server, m aking t raffic pat t erns in
t he net work m ore efficient . And if one server becom es unavailable, t he rout er rout es t o t he next
nearest server. I n Figure 2- 3 , for exam ple, if server C becom es unavailable due t o a net work or
server failure, t he rout er chooses t he pat h t o server A as t he next - lowest - cost rout e. From t he
rout er's viewpoint , it is j ust choosing t he next - best rout e t o t he sam e dest inat ion.
[3]
The methods by which a router chooses among multiple routes to the same destination is covered in Chapter 4,
"Dynamic Routing Protocols.
Anycast addresses are defined by t heir service funct ion only, not by form at , and t heoret ically
m ight be any I Pv6 unicast address of any scope. However, t here is a form at for reserved anycast
addresses, defined in RFC 2526. Anycast addresses have been used for som e t im e in I Pv4
net works, but are form alized in t heir definit ion in I Pv6.
Multicast Addresses
A m ult icast address ident ifies not one device but a set of devicesa m ult icast group. A packet
being sent t o a m ult icast group is originat ed by a single device; t herefore a m ult icast packet
norm ally has a unicast address as it s source address and a m ult icast address as it s dest inat ion
address. A m ult icast address never appears in a packet as a source address.
The m em bers of a m ult icast group m ight include only a single device, or even all devices in a
net work. I n fact , I Pv6 does not have a reserved broadcast address like I Pv4, but it does have a
reserved all- nodes m ult icast group, which is essent ially t he sam e t hing: a m ult icast group t o
which all receiving devices belong.
Mult icast ing is essent ial t o t he basic operat ion of I Pv6, part icularly som e of it s plug- and- play
feat ures such as rout er discovery and address aut oconfigurat ion. These funct ions are a part of
t he Neighbor Discovery Prot ocol, discussed lat er in t his chapt er.
The form at of t he I Pv6 m ult icast address is shown in Figure 2- 4 . The first eight bit s of t he
address are always all ones, and t he next four bit s are designat ed as flags. Current ly t he first
t hree of t hese bit s are unused and always set t o 0. The fourt h bit indicat es whet her t he address
is a perm anent , well- known address ( 0) or an adm inist rat ively assigned t ransient address ( 1) .
The next four bit s indicat e t he scope of t he address as shown in Table 2- 2. Table 2- 3 shows
several reserved, well- known I Pv6 m ult icast addresses, all of which are link- local scope. Because
a m ult icast group is always a set of individual nodes, t here is no needor sensefor having a
subnet field in t he m ult icast address. So t he last 112 bit s are used as t he Group- I D, ident ifying
individual m ult icast groups. Current usage set s t he first 80 bit s t o 0 and j ust uses t he last 32
bit s.
Figu r e 2 - 4 . Th e I Pv6 m u lt ica st a ddr e ss for m a t .
Ta ble 2 - 2 . M u lt ica st a ddr e ss
scope s.
Scope Fie ld
Va lu e
Scope
0x0
Reser v ed
0x1
Node- Local
0x2
Link- Local
0x5
Sit e- Local
0x8
Organizat ion Local
0xE
Global
0xF
Reser v ed
Ta ble 2 - 3 . Ex a m ple s of w e llk n ow n I Pv6 m u lt ica st
a ddr e sse s.
Addr e ss
M u lt ica st Gr ou p
FF02: : 1
All Nodes
FF02: : 2
All Rout ers
FF02: : 5
OSPFv3 Rout ers
FF02: : 6
OSPFv3
Designat ed
Rout ers
FF02: : 9
RI Png Rout ers
FF02: : A
EI GRP Rout ers
FF02: : B
Mobile Agent s
FF02: : C
DHCP
Servers/ Relay
Agent s
FF02: : D
All PI M Rout ers
Embedded IPv4 Addresses
There are several t ransit ion t echnologiesm eans of helping t o t ransit ion a net work from I Pv4 t o
I Pv6 or ot herwise help I Pv4 and I Pv6 t o coexist t hat require an I Pv4 address t o be com m unicat ed
wit hin an I Pv6 address. The individual t echnology specifies how t he I Pv4 address is t o be
em bedded in t he I Pv6 address, and t he im plem ent at ion of t he t echnology knows where am ong
t he 128 bit s of t he I Pv6 address t o find t he 32 bit s of t he I Pv4 address. But you will also find
t hat m any of t hese t echnologies have unique form at s for t heir address represent at ions t hat allow
you t o ident ify t he em bedded I Pv4 address. Exam ples of I Pv6 addresses wit h an em bedded I Pv4
address of 10.23.1.5 are
FE80: : 5EfE: 10.23.1.5 ( An I SATAP address)
: : FFFF: 10.23.1.5 and : : FFFF: 0: 10.23.1.5 ( SI I T addresses)
FEC0: 0: 0: 1: : 10.23.1.5 ( TRT address)
I n each of t hese exam ples, t he I Pv4 address is t he last 32 bit s of t he I Pv6 address and is
represent ed in dot t ed decim al.
Ot her t ransit ion t echnologies using em bedded I Pv4 addresses do not use dot t ed decim al but
encode t he I Pv4 address int o hexadecim al. 6t o4, for exam ple, does t his. 10.23.1.5 in
hexadecim al is 0A17: 0105. A 6t o4 prefix wit h 10.23.1.5 em bedded is t hen
IPv6 Packet Header Format
The form at of t he I Pv6 packet header is shown in Figure 2- 5 . There are som e dist inct sim ilarit ies
and som e differencessom e dist inct , som e subt lewit h t he I Pv4 packet header shown in Figure 1.2
of t he previous chapt er.
Figu r e 2 - 5 . Th e I Pv6 pa ck e t h e a de r .
V e r sion is, as wit h t he I Pv4 header, a four- bit field indicat ing t he I P version. Here, of course, it
is set t o binary 0110 t o indicat e version 6.
Traffic Class is an eight - bit field t hat corresponds t o t he eight - bit I Pv4 ToS field. But given t he
evolut ion of t he ToS field over t he years, bot h are now used for Different iat ed Class of Service
( DiffServ) . So even t hough t here is a correspondence of t his field wit h t he old ToS field, it s nam e
m ore accurat ely reflect s t he current usage of t he values carried here.
Flow Label is a field unique t o I Pv6. The int ent ion of t his 20- bit field is t o allow labeling of
part icular flows of t raffic; t hat is, packet s t hat are not j ust originat ed by t he sam e source and
going t o t he sam e dest inat ion, but t hat belong t o t he sam e applicat ions at t he source and
dest inat ion. There are several advant ages t o different iat ing flows, from providing a finer- grained
different iat ed class- of- service t reat m ent t o ensuring, when balancing t raffic loads across m ult iple
pat hs, t hat packet s belonging t o t he sam e flow are always forwarded over t he sam e pat h t o
prevent possible reordering of packet s. Flows ( or m ore accurat ely, m icroflows) t ypically are
ident ified by a com binat ion of source and dest inat ion address plus source and dest inat ion port .
But t o ident ify t he source and dest inat ion port , a rout er m ust look beyond t he I P header and int o
t he TCP or UDP ( or ot her t ransport - layer prot ocol) header, adding t o t he com plexit y of t he
forwarding process and possibly affect ing rout er perform ance. Finding t he t ransport layer header
in an I Pv6 packet can be especially problem at ic because of ext ension headers, described in t he
next sect ion. An I Pv6 rout er m ust st ep t hrough possibly m any ext ension headers t o find t he
t ransport - layer header.
By m arking t he Flow Label field appropriat ely when t he packet is originat ed, rout ers can ident ify
a flow by looking no furt her t han t he packet header. As of t his writ ing, however, t he com plet e
specificat ion of how t o use t he flow label field is st ill being debat ed, and rout ers current ly ignore
t he field. I t nevert heless holds prom ise of allowing I Pv6 t o provide bet t er Qualit y of Service
( QoS) feat ures t han I Pv4 for applicat ions such as Voice over I P ( VoI P) .
Payload Lengt h specifies t he lengt h of t he payload, in byt es, t hat t he packet is encapsulat ing.
Recall from Chapt er 1, " TCP/ I P Review," t hat I Pv4 headers, because of t he Opt ions and Padding
fields, can vary in lengt h. Therefore, t o find t he payload lengt h in an I Pv4 packet , t he value of
t he Header Lengt h field m ust be subt ract ed from t he Tot al Lengt h field. The I Pv6 packet header,
on t he ot her hand, is always a fixed lengt h of 40 byt es, and so t he single Payload Lengt h field is
enough t o find t he beginning and end of t he payload.
Not ice also t hat whereas t he I Pv4 Tot al Lengt h field is 16 bit s, t he I Pv6 Payload Lengt h field is
20 bit s. The im plicat ion here is t hat because a m uch longer payload ( 1,048,575 byt es, versus
65,535 in I Pv4) can be specified in t his field, t he I Pv6 packet it self is t heoret ically capable of
carrying a far larger payload.
Next Header specifies which header follows t he I Pv6 packet header. I n t his, it is very sim ilar t o
t he Prot ocol field in t he I Pv4 header and, in fact , is used for t he sam e purpose when t he next
header is an upper- layer prot ocol header. Like t hat I Pv4 field, t his field is also eight bit s. But in
I Pv6, t he header following t he packet header m ight not be an upper- layer prot ocol header, but
an ext ension header ( again, described in t he next sect ion) . So t he Next Header field is nam ed t o
reflect t his wider range of responsibilit y.
Hop Lim it corresponds exact ly, bot h in lengt h ( eight bit s) and funct ion, t o t he I Pv4 Tim e t o Live
( TTL) field. As you read in Chapt er 1, t he original int ent ion of t he TTL field was t hat it would be
decrem ent ed by t he num ber of seconds a packet is queued in a rout er during forwarding, but
t hat t his funct ion was never im plem ent ed. I nst ead, rout ers decrem ent t he TTL by one no m at t er
how long t he packet is queued ( and in m odern net works it is highly unusual for a packet t o be
queued anywhere near as long as one second) . Therefore, t he TTL has always been a m easure of
t he m axim um rout er hops a packet can t ake on it s way t o a dest inat ion. I f t he TTL decrem ent s
t o 0, t he packet is discarded. Hop Lim it is used for exact ly t he sam e, but is nam ed m ore
appropriat ely for t his funct ion.
Source and Dest inat ion Address correspond t o t he I Pv4 Source and Dest inat ion fields, except of
course t hese fields are 128 bit s each t o accom m odat e I Pv6 addresses.
Not iceably m issing from t he I Pv6 header is a Checksum field like t hat of t he I Pv4 header. Given
t he overall increase in reliabilit y of m odern t ransport m ediawireless perhaps being a not able
except ionalong wit h t he fact t hat upper- layer prot ocols usually carry t heir own error- checking
and recovery m echanism s, checksum m ing of t he I Pv6 header it self adds lit t le value, and is
t herefore elim inat ed.
Extension Headers
Com paring t he I Pv6 header in Figure 2- 5 wit h t he I Pv4 header in Figure 1.2 , you can see t hat
alt hough t he Source and Dest inat ion Address fields are each four t im es as long in t he I Pv6
header, t he I Pv6 header it self is not t hat m uch larger t han an I Pv4 header: 40 byt es for I Pv6
versus a m inim um of 20 byt es for I Pv4. I f ext ensive use is m ade of t he I Pv4 Opt ions field,
alt hough unusual, t he I Pv4 header can act ually be larger t han t he I Pv6 header.
Also not ice t hat in addit ion t o t he Opt ions field, ot her fields t hat are not always used, such as
t hose associat ed wit h fragm ent at ion, are elim inat ed from t he I Pv6 header. So given it s fixed
lengt h and exclusion of all fields t hat do not carry inform at ion necessary for t he forwarding of
every packet , t he I Pv6 header is bot h com pact and efficient .
But what if you do want t o use one of t hose opt ional I P feat ures, such as fragm ent at ion or
source rout ing or aut hent icat ion? When an opt ional funct ion is used in I Pv6, an ext ension header
appropriat e for t he funct ion is added aft er t he packet header. I f, for exam ple, source rout ing,
fragm ent at ion, and aut hent icat ion opt ions are t o be used, t hree ext ension headers form at t ed t o
carry t he inform at ion needed for each of t hose funct ions are added as shown in Figure 2- 6 .
Because of t hese headers, efficiency is added t o I Pv6 packet s in t wo ways:
The packet carries only t he inform at ion required by t hat individual packet . No unused fields
are carried.
New opt ional funct ions can be added t o t he I Pv6 packet by defining new ext ension headers.
Figu r e 2 - 6 . Ex t e n sion h e a de r s a llow I Pv6 pa ck e t s t o ca r r y a ll t h e
in for m a t ion r e qu ir e d for t h a t pa ck e t , bu t on ly t h e in for m a t ion r e qu ir e d
for t h a t pa ck e t .
[View full size image]
Each ext ension header, like t he I Pv6 header, has a Next Header field. So each header t ells which
header follows it . Table 2- 4 shows t he current ly defined ext ension headers and t heir next header
values. So, for exam ple, in Figure 2- 7 , t he Next Header value in t he I Pv6 header indicat es t hat
t he next header is a Rout ing ext ension header ( 43) , t hat header's Next Header field indicat es
t hat t he next header is a Fragm ent at ion ext ension header ( 44) , and so on. The last ext ension
header, AH, indicat es t hat t he next header is a TCP header ( Prot ocol Num ber 6) .
Ta ble 2 - 4 . N e x t H e a de r va lu e s.
H e a de r
N e x t H e a de r Va lu e
Hop- By- Hop Opt ions
0
Rout ing
43
Fragm ent
44
Encapsulat ing Securit y Payload ( ESP)
50
Aut hent icat ion Header ( AH)
51
Dest inat ion Opt ions
60
TCP/ I P Prot ocols
Prot ocol num ber value defined for t hat
prot ocol ( such as TCP = 6, UDP = 17, OSPF =
89, and so on)
No Next Header
59
Figu r e 2 - 7 . Th e N e x t H e a de r fie ld in t h e I Pv6 h e a de r a n d e a ch
e x t e n sion h e a de r spe cifie s w h ich h e a de r follow s it .
[View full size image]
The form at of each of t he ext ension headers is described in RFC 1883. But briefly, t he funct ion of
each ext ension header is as follows:
H op- By- H op Opt ion scarries inform at ion t hat m ust be exam ined by every node along t he
forwarding pat h, such as Rout er Alert and Jum bo Payload opt ions.
Rou t in gprovides source rout ing funct ionalit y by list ing nodes t hat t he packet m ust pass
t hrough on t he way t o it s dest inat ion.
Fr a gm e n t is used when a packet is fragm ent ed, t o provide t he inform at ion necessary for
t he receiving node t o reassem ble t he packet . A significant difference bet ween I Pv4 and
I Pv6 is t hat only originat ing nodes can fragm ent packet s; I Pv6 rout ers do not fragm ent t he
packet s. So originat ing nodes m ust eit her use Pat h MTU Discovery ( PMD) t o find t he lowest
MTU along a pat h t o t he dest inat ion, or never produce packet s larger t han 1280 byt es. PMD
is described in t he next sect ion. I Pv6 specifies t hat all links on which it runs m ust be able t o
support packet sizes of at least 1280 byt es so t hat originat ors can use t he m inim um - size
opt ion rat her t han PMD if t hey so choose.
En ca psu la t in g Se cu r it y Pa yloa d ( ESP) is used when t he payload is encrypt ed.
Au t h e n t ica t ion H e a de r ( AH ) is used when t he packet m ust be aut hent icat ed bet ween
t he source and dest inat ion.
D e st in a t ion Opt ion s carries inform at ion t o be exam ined only by t he dest inat ion node or
possibly by nodes list ed in t he Rout ing header.
RFC 1883 also specifies t he order in which ext ension headers, if t hey are used, should appear.
The only hard- and- fast rule here is t hat if t he Hop- By- Hop Opt ions header is used, it m ust
direct ly follow t he I Pv6 header so t hat it can be easily found by t he t ransit nodes t hat m ust
exam ine it . The recom m ended ext ension header order is as follows:
1 . I Pv6 Header
2 . Hop- By- Hop Opt ions
3 . Dest inat ion Opt ions ( only if int erm ediat e rout ers specified in t he Rout ing header m ust
exam ine t his header)
4 . Rout ing
5 . Fragm ent
6 . Aut hent icat ion
7 . Encapsulat ing Securit y Payload
8 . Dest inat ion Opt ions ( if only t he final dest inat ion m ust exam ine t his header)
9 . Upper- Layer Header
ICMPv6
I Pv6 requires a cont rol prot ocol for exchanging and processing error and inform at ional
m essages, j ust as I Pv4 does. And like I Pv4, it uses I CMP t o do t his. But t he I CMP used by I Pv6 is
not t he sam e I CMP as used by I Pv4. Alt hough I CMP for I Pv4 has a Prot ocol Num ber of 1, I CMPv6
for I Pv6 has a Next Header value of 58.
I CMPv6 is specified in RFC 2463. Many of t he funct ions defined in t his RFC are t he sam e ones
defined for I CMP for I Pv4; but t here are m any I CMP m essages, such as Source Quench and
Tim est am p, t hat have no equivalent in I CMPv6.
Com paring t he I CMPv6 header shown in Figure 2- 8 t o t he I CMP header shown in Figure 1.28,
you can see t hat t hey are ident ical. And like I CMP, I CMPv6 uses a com binat ion of t ype and code
values t o ident ify general t ypes and t hen subt ypes under t hem . The values defined in RFC 1885
are list ed in Table 2- 5.
Figu r e 2 - 8 . Th e I CM Pv6 h e a de r for m a t .
Ta ble 2 - 5 . I CM Pv6 M e ssa ge Type a n d Code fie lds.
Type
Code
1
2
M e ssa ge
DESTI NATI ON UNREACHABLE
0
No rout e t o dest inat ion
1
Com m unicat ion wit h dest inat ion
adm inist rat ively prohibit ed
2
Not a neighbor
3
Address unreachable
4
Port unreachable
0
PACKET TOO BI G
Type
Code
3
M e ssa ge
TI ME EXCEEDED
0
Hop lim it exceeded in t ransit
1
Fragm ent reassem bly t im e exceeded
4
PARAMETER PROBLEM
0
Erroneous header field encount ered
1
Unrecognized Next Header t ype
encount er ed
2
Unrecognized I Pv6 opt ion encount ered
128
0
ECHO REQUEST
129
0
ECHO REPLY
130
0
GROUP MEMBERSHI P QUERY
131
0
GROUP MEMBERSHI P REPORT
132
0
GROUP MEMBERSHI P REDUCTI ON
I n addit ion t o t he basic error and inform at ional funct ions of I CMPv6, t here are m echanism s t hat
use t he I CMPv6 m essages. For exam ple, t he Pat h MTU Discovery m echanism m ent ioned in t he
previous sect ion sends packet s of increasing size t o a dest inat ion. When t he sm allest MTU of t he
links on t he pat h t o t he dest inat ion is exceeded by a given packet size, t he packet is dropped
and a Packet Too Big m essage is sent t o t he source address; t he source t hen knows t he sm allest
MTU on t he pat h. And, as wit h I Pv4, Echo and Echo Reply m essages are used by t he Ping
funct ion.
But in addit ion t o basic error and inform at ion m essages, t here is a separat e set of I CMPv6
m essages defined t hat are used by an essent ial I Pv6 prot ocol: t he Neighbor Discovery Prot ocol,
Neighbor Discovery Protocol
The m ost dist inct charact erist ics of I Pv6 aft er it s increased address space are it s plug- and- play
feat ures. Neighbor Discovery Prot ocol ( NDP) is t he enabler of t hese plug- and- play feat ures,
using t he following funct ions:
Rou t e r D iscove r y A node can discover, when it is connect ed t o an I Pv6 link, t he local
rout ers wit hout t he aid of Dynam ic Host Configurat ion Prot ocol ( DHCP) .
Pr e fix D iscove r y A node can discover, when it is connect ed t o an I Pv6 link, t he prefix or
prefixes assigned t o t hat link.
Pa r a m e t e r D iscove r y A node can discover param et ers such as t he link MTU and hop
lim it s for it s connect ed link.
Addr e ss Au t ocon figu r a t ion A node can det erm ine it s full address, again wit hout t he aid
of DHCP.
Addr e ss Re solu t ion A node can discover t he link- layer addresses of ot her nodes on t he
link wit hout t he use of Address Resolut ion Prot ocol ( ARP) .
N e x t - H op D e t e r m in a t ion A node on a link can det erm ine t he link- layer next hop for a
dest inat ion, eit her as a local dest inat ion or a rout er t o t he dest inat ion.
N e igh bor Un r e a ch a bilit y D e t e ct ion A node can det erm ine when a neighbor on a link,
eit her anot her host or a rout er, is no longer reachable.
D u plica t e Addr e ss D e t e ct ion A node can det erm ine if an address it want s t o use is
already being used by anot her node on t he link.
Re dir e ct A rout er can not ify a host of a bet t er next - hop t han it self t o an off- link
dest inat ion. The redirect funct ion is a part of basic I CMP funct ionalit y in I Pv4, but is
redefined as part of NDP in I Pv6.
NDP m essages should always be link- local in scope, and t herefore t he packet s encapsulat ing
t hem always use eit her link- local I Pv6 addresses or m ult icast addresses wit h a link- local scope.
To add a furt her layer of securit y, t he Hop Lim it of t he I Pv6 packet carrying all NDP m essages is
255. I f one of t hese packet s is received wit h a Hop Lim it less t han t hat value, it m eans t he
packet has passed t hrough at least one rout er, and t he packet is dropped. This prevent s NDP
from being at t acked or spoofed from a source not at t ached t o t he local link.
NDP Messages
NDP is defined in RFC 2461. I t uses I CMPv6 t o exchange t he m essages necessary for it s
funct ions; specifically, five new I CMPv6 m essages are specified in RFC 2461:
Rou t e r Adve r t ise m e n t ( RA) m essages are originat ed by rout ers t o advert ise t heir
presence and link- specific param et ers such as link prefixes, link MTU, and hop lim it s. These
m essages are sent periodically, and also in response t o Rout er Solicit at ion m essages.
Rou t e r Solicit a t ion ( RS) m essages are originat ed by host s t o request t hat a rout er send
an RA.
N e igh bor Solicit a t ion ( NS) m essages are originat ed by nodes t o request anot her node's
link layer address and also for funct ions such as duplicat e address det ect ion and neighbor
unreachabilit y det ect ion.
N e igh bor Adve r t ise m e n t ( N A) m essages are sent in response t o NS m essages. I f a node
changes it s link- layer address, it can send an unsolicit ed NA t o advert ise t he new address.
Re dir e ct m essages are used t he sam e way t hat redirect s are used in I CMP for I Pv4; t hey
have m erely been m oved from being a part of t he base I CMPv6 prot ocol t o being a part of
NDP.
Figure 2- 9 shows t he form at of t he Rout er Advert isem ent m essage. I t s I CMPv6 t ype is 134 and
t he code is 0. The source address of t he I Pv6 packet encapsulat ing t he RA is always t he I Pv6
link- local address of t he int erface from which t he packet originat es. The dest inat ion address is
eit her t he all- nodes m ult icast address ( FF02: : 1) if t he RA is a periodic t ransm it , or t he link- local
address of t he solicit ing node if t he RA is sent in response t o a Rout er Solicit at ion.
Figu r e 2 - 9 . Th e Rou t e r Adve r t ise m e n t m e ssa ge for m a t .
H op Lim it indicat es t he value of t he Hop Lim it field t hat nodes at t ached t o t he link should give
t o any packet s t hey originat e on t he link. I f no Hop Lim it is specified by t his rout er, t he field is
set t o all zeroes.
M is t he Managed Address Configurat ion flag. I f t his bit is set , t he originat ing rout er is t elling
host s on t he link t o use st at eful address aut oconfigurat ion via DHCPv6. I f t he flag is cleared,
host s on t he link should use st at eless address aut oconfigurat ion. Address aut oconfigurat ion is
described lat er in t his chapt er.
O is t he Ot her St at eful Configurat ion flag. When set , t he originat ing rout er is t elling host s on t he
link t o use DHCPv6 for t he acquisit ion of ot her link inform at ion. The M and O flags can be used
t oget her. For exam ple, by clearing t he M flag but set t ing t he O flag, t he rout er is t elling host s t o
use st at eless address aut oconfigurat ion but t hen consult a DHCPv6 server for ot her configurat ion
param et ers.
Rou t e r Life t im e is set t o a value ot her t han 0 only if t he originat ing rout er is a default rout er.
I n t hat case, t his field specifies t he lifet im e of t he default rout er in seconds, up t o a m axim um
value of 18.2 hours.
Re a ch a ble Tim e is used by t he Neighbor Unreachabilit y Det ect ion funct ion of NDP. I t specifies
t he t im e, in m illiseconds, t hat a node should assum e a neighbor is reachable aft er t he node has
confirm ed reachabilit y of t he neighbor.
Re t r a n sm it Tim e r is used by t he Address Resolut ion and Neighbor Unreachabilit y Det ect ion
funct ions of NDP. I t specifies t he m inim um t im e, in m illiseconds, bet ween ret ransm it t ed
Neighbor Solicit at ion m essages.
Possible opt ions t hat can be carried in t he Opt ions field of t he RA include t he following:
The link- layer address of t he int erface from which t he RA is originat ed.
An MTU specificat ion for t he link.
One or m ore prefixes assigned t o t he link. This inform at ion is essent ial t o st at eless address
aut oconfigurat ion, t elling host s on t he link what t he link prefixes are.
Figure 2- 10 shows t he form at of t he Rout er Solicit at ion m essage. I t s I CMPv6 t ype is 133 and t he
code is 0. The source address of t he I Pv6 packet encapsulat ing t he RS is eit her t he I Pv6 address
assigned t o t he originat ing int erface or, if no address has been assigned ( as would be t he case if
t he originat ing host is beginning address aut oconfigurat ion) , an unspecified address of : : ( all
zeroes) . The dest inat ion address is t he all- rout ers m ult icast address ( FF02: : 2) .
Figu r e 2 - 1 0 . Th e Rou t e r Solicit a t ion m e ssa ge for m a t .
The Opt ions field can cont ain t he link- layer address of t he originat ing int erface, if it is known.
However, t he source link- layer address m ust not be included if t he source address of t he
encapsulat ion packet is unspecified, such as when t he originat or is solicit ing a rout er during
address aut oconfigurat ion.
Figure 2- 11 shows t he form at of t he Neighbor Solicit at ion m essage. I t s I CMPv6 t ype is 135 and
t he code is 0. The source address of t he I Pv6 packet encapsulat ing t he NS is eit her t he I Pv6
address assigned t o t he originat ing int erface or, if t he NS is sent for Duplicat e Address
Det ect ion, t he unspecified address of : : ( all zeroes) . The dest inat ion address is eit her a solicit ednode m ult icast address corresponding t o t he t arget address, or t he t arget address.
Figu r e 2 - 1 1 . Th e N e igh bor Solicit a t ion m e ssa ge for m a t .
Ta r ge t Addr e ss is t he I Pv6 address of t he t arget of t he solicit at ion. The t arget address is never
a m ult icast address.
The Opt ions field of t he NS can cont ain t he link- layer address of t he originat ing int erface.
Figure 2- 12 shows t he form at of t he Neighbor Advert isem ent m essage. I t s I CMPv6 t ype is 136
and t he code is 0. The source address of t he I Pv6 packet encapsulat ing t he NS is always t he
I Pv6 address assigned ( or aut oconfigured) t o t he originat ing int erface. The dest inat ion address is
eit her t he source address of t he packet cont aining t he NS t o which t he NA is sent in response, or
t he all- nodes m ult icast address ( FF02: : 1) .
Figu r e 2 - 1 2 . Th e N e igh bor Adve r t ise m e n t m e ssa ge for m a t .
R is t he Rout er flag. When set , it indicat es t hat t he originat or is a rout er. This bit is used during
Neighbor Reachabilit y Det ect ion t o det ect a rout er t hat has changed t o a host .
S is t he Solicit ed flag. This bit is set when t he NA is sent in response t o an NS.
O is t he Override flag. When set , it indicat es t hat t he inform at ion in t he NA should override any
exist ing neighbor cache ent ry and updat e t he cached link- layer address. When t he O bit is
cleared t he NA will not override an exist ing neighbor cache ent ry.
Ta r ge t Addr e ss is, when t he NA is sent in response t o a NS, t he address in t he Target Address
field of t he NS. I f t he NA is unsolicit ed ( t hat is, sent t o advert ise a change of t he originat or's
link- layer address) , t he Target Address is t he originat or's address.
The Opt ions field of t he NA can cont ain t he t arget link- layer addresst hat is, t he link- layer
address of t he NA's originat or.
Figure 2- 13 shows t he form at of t he Redirect m essage. I t s I CMPv6 t ype is 137 and t he code is 0.
The source address of t he I Pv6 packet encapsulat ing t he Redirect is always t he link- local I Pv6
address of t he int erface from which t he m essage is originat ed. The dest inat ion address is always
t he source address of t he packet t hat t riggered t he redirect .
Figu r e 2 - 1 3 . Th e Re dir e ct m e ssa ge for m a t .
Ta r ge t Addr e ss is t he address of t he bet t er first - hopusually t he link- local address of anot her
rout er on t he link.
D e st in a t ion Addr e ss is t he I Pv6 address of t he dest inat ion t hat is redirect ed t o t he t arget
address.
The Opt ions field of t he Redirect m essage can cont ain t he link- layer address of t he t arget , and
as m uch of t he header of t he packet t hat t riggered t he redirect , wit hout m aking t he redirect
packet exceed 1280 byt es.
The Opt ions field of all of t hese five m essages, when it cont ains any inform at ion, consist s of one
or m ore Type/ Lengt h/ Value ( TLV) t riplet s. Each TLV consist s, as shown in Figure 2- 14, of an 8bit Type field specifying t he t ype of inform at ion carried in t he value field, an 8- bit Lengt h field
specifying t he lengt h in unit s of 8 oct et s of t he value field, and t he variable lengt h Value field.
Figu r e 2 - 1 4 . Th e for m a t of t h e TLVs u se d in t h e Opt ion s fie lds of t h e
N D P m e ssa ge s.
Table 2- 6 shows t he possible values and t heir associat ed t ype num bers. The form at of t he
individual value fields is not provided in t his chapt er; consult RFC 2461 for t he det ails on t he
value fields.
Ta ble 2 - 6 . Va lu e fie lds
a n d t h e ir t ype s.
Type
Va lu e
1
Source LinkLayer Address
2
Target LinkLayer Address
3
Prefix
I nform at ion
4
Redir ect ed
Header
5
MTU
Router Discovery
A rout er m akes it s presence known, along wit h any param et ers it has been configured t o
advert ise, by periodically sending RAs on it s at t ached links. Presum ably t he links on which t he
RA do t he m ost good are broadcast links such as Et hernet , where host s can receive t he RAs and
t hus learn necessary inform at ion about t he link.
RFC 2461 specifies t hat t he period bet ween t ransm issions of RAs should be bet ween 4 and 1800
seconds, wit h a default of 600 seconds. I t also specifies a m inim um period bet ween
advert isem ent s of RAs wit h a default of 200 seconds. The advert isem ent s are j it t ered bet ween
t he m axim um and m inim um values t o prevent synchronizat ion on a link.
These unsolicit ed RAs are sent wit h t heir source address set t o t he link- local I Pv6 address of t he
rout er's int erface. The dest inat ion address is t he all- nodes m ult icast address ( FF02: : 1) .
Cisco rout ers aut om at ically send RAs on Et hernet and FDDI int erfaces whenever I Pv6 is enabled
on t he rout er wit h t he com m and ipv6 u n ica st - r ou t in g. The default int erval is 200 seconds, and
can be changed wit h t he com m and ipv6 n d r a - in t e r va l. The Rout er Lifet im e of t he t ransm it t ed
RAs is 1800 seconds by default , and can be changed wit h t he com m and ipv6 n d r a - life t im e . I f
you do not want a rout er t o be a default rout er on a link, you can use t his com m and t o set t he
Rout er Lifet im e value t o 0. The default Reachable Tim e of t he RAs is 0 ( which m eans
unspecified) , and can be changed wit h t he com m and ipv6 n d r e a ch a ble - t im e . The Ret ransm it
Tim er field is set t o a default of 0 m s ( unspecified) and can be changed wit h t he com m and ipv6
n d n s- in t e r va l. The M and O flags can be set wit h t he com m ands ipv6 n d m a n a ge d- con figfla g and ipv6 n d ot h e r - con fig- fla g , respect ively. I f you do not want an int erface t o t ransm it
RAs at all, you can disable t hem wit h t he com m and ipv6 n d su ppr e ss- r a.
By default , Cisco rout ers include in t he RAs all I Pv6 prefixes configured on t he originat ing
int erface. You can cont rol t he prefixes advert ised, and param et ers associat ed wit h t hose
prefixes, wit h t he com m and ipv6 n d pr e fix.
Of course, 200 seconds is a long t im e for a host t hat has j ust at t ached t o an int erface t o wait for
an RA so t hat it can find t he rout ers and learn t he link param et ers. So when a host first becom es
act ive on a link, it can send an RS t o solicit t he im m ediat e t ransm ission of an RA. The source of
t he RS can eit her be t he unspecified address ( : : ) or t he host 's link- local I Pv6 address. The
dest inat ion is always t he all- rout ers m ult icast ( FF02: : 2) .
When a rout er receives an RS, it sends ( aft er a delay of .5 seconds) an RA in response. I f t he
source address of t he RS t hat t riggered t he RA is a host 's link- local address, t he RA is unicast t o
t he host using it s link- local address. I f t he source address of t he RS was unspecified, t he
solicit ed RA is m ult icast t o t he all- nodes address.
When a host receives an RA, it adds t he rout er t o it s default rout er list ( unless t he RA indicat es
by a Rout er Lifet im e value of 0 t hat it cannot be used as a default ) . I f t here is m ore t han one
rout er on t he default rout er list , how t he host select s a default rout er is im plem ent at ion- specific.
I t could eit her rot at e t hrough t he list , or select and keep a single rout er as default . I n eit her
inst ance, t he Redirect funct ion is essent ial for updat ing t he host when a different default t han
t he one it select ed should be used.
Address Autoconfiguration
When an I Pv6 host first becom es act ive on a link, it can self- configure it s own int erface address.
The first st ep in t his process is t he det erm inat ion of t he 64- bit I nt erface I D port ion of t he
address. On broadcast int erfaces ( where host s are m ost likely t o appear) , a m echanism called
MAC- t o- EUI 64 conversion is used. Quit e sim ply, t his m echanism t akes t he 48- bit Media Access
Cont rol ( MAC) address of t he int erfacewhich can norm ally be assum ed t o be globally uniqueand
convert s it int o a 64- bit I nt erface I D by insert ing a reserved 16- bit value of 0xFFFE int o t he
m iddle of t he MAC address and " flipping" t he Universal/ Local ( U/ L) bit of t he MAC address t o 1
( Universal) .
Figure 2- 15 illust rat es t his process. A MAC address, 0000: 0B0A: 2D51, is t o be convert ed. The
first st ep, shown in binary for easier underst anding of what is happening, is t o " split " t he MAC
address in t he m iddle and insert 0xFFFE bet ween t he t wo 24- bit halves. The address is now 64
bit s long. Next , t he U/ L bit of t he original MAC addresswhich is always t he 7t h bit is flipped from
0 t o 1. The result ing address, 0200: 0BFF: FE0A: 2D51, is now a valid 64- bit I nt erface I D.
Figu r e 2 - 1 5 . M AC- t o- EUI 6 4 con ve r sion is u se d t o cr e a t e a 6 4 - bit
I n t e r fa ce I D fr om a n in t e r fa ce 's 4 8 - bit M AC a ddr e ss.
Of course, t he I nt erface I D is only half of t he I Pv6 address; a 64- bit prefix is also required.
Recall from Table 2- 1 t hat t he link- local prefix is a reserved, well- known value of 0xFF80: : / 10.
Using t his as a full 64- bit prefix ( 0xFF80: : / 64) , it can be added ont o t he derived I nt erface I D,
and t he host now has a com plet e I Pv6 address t hat can be used for com m unicat ion wit h ot her
devices on t he sam e link. For exam ple, com bining t he link- local prefix wit h t he I nt erface I D
derived in Figure 2- 15 gives a link- local address of FF80: : 0200: 0BFF: FE0A: 2D51. 2- The
following shows an exam ple of a link- local address, in t his case from an Et hernet int erface " en1"
on a Macint osh OS X host . Using t he link- local prefix FF80: : / 10 and a MAC- t o- EUI 64 conversion,
an I Pv6 int erface derives it s link- local address wit h no help from any ot her device:
[Jeff-Doyles-Computer:~] jdoyle% ifconfig en1
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1300
inet6 fe80::211:24ff:fe23:334e prefixlen 64 scopeid 0x5
inet 10.10.24.13 netmask 0xffffff00 broadcast 10.10.24.255
ether 00:11:24:23:33:4e
media: autoselect status: active
supported media: autoselect
[Jeff-Doyles-Computer:~] jdoyle%
I f t he host only needs t o com m unicat e wit h devices on t he link, aut oconfiguring it s link- local
address is sufficient . But if it needs t o com m unicat e wit h devices off- link, it needs an address
wit h a wider scopenorm ally a global I Pv6 address. There are t wo ways it can acquire t his
addr ess: st at eful or st at eless address aut oconfigurat ion.
I f a host uses st at eful address aut oconfigurat ion, it consult s a DHCPv6 server for t he necessary
address inform at ion. I t m ight eit her be preconfigured t o find a DHCPv6 server, or a received RA
m ight have it s M flag set t elling it t o use DHCPv6. DHCPv6, described in RFC 3315, is not m uch
different in it s end result s t han DHCP for I Pv4.
Much m ore int erest ing is st at eless aut oconfigurat ion. Wit h t his very sim ple process, t he host
acquires one or m ore link prefixes from t he RAs it receives. I t t hen adds t he prefix t o it s
previously det erm ined I nt erface I D, and it now has a globally unique I Pv6 address. For exam ple,
if t he host from Figure 2- 15 received an RA advert ising a prefix of 3FFE: 1104: 404: 1: : / 64, it
would add t hat prefix t o it s I nt erface I D for a global address of 3FFE: 1104:
404: 1: 0200: 0BFF: FE0A: 2D51.
Duplicate Address Detection
Alt hough t he use of MAC addresses t o derive an I nt erface I D alm ost always guarant ees a unique
address of any scope, it is wise t o ensure t hat t he address is unique. So whenever a device
acquires a unicast address, it m ust perform Duplicat e Address Det ect ion before using t he
address. I t does not m at t er whet her t he address was acquired via st at eful or st at eless
configurat ion, or if t he address was st at ically configured. The only except ion t o t he rule is an
anycast address, because anycast addresses by definit ion can appear on m ore t han one device.
There is also an assum pt ion t hat if a Duplicat e Address Det ect ion has been perform ed on a linklocal address t hat has an I nt erface I D t hat was derived from MAC- t o- EUI 64 conversion, and if
t he address passes, ot her addresses using t he sam e I nt erface I D will also be unique, and so t he
Duplicat e Address Det ect ion does not need t o be repeat ed.
A node t hat has acquired a new address classifies t he address as t ent at ive. The address cannot
be used unt il t he Duplicat e Address Det ect ion operat ion has been com plet ed wit h verificat ion
t hat no ot her node on t he link uses t hat address. The node sends an NS wit h t he Target Address
field set t o t he address t o be verified. The source address of t he NS is t he unspecified address,
and t he dest inat ion of t he NS is a solicit ed- node m ult icast address.
A solicit ed- node m ult icast address is form ed by prepending t he prefix FF02: 0: 0: 0: 0: 1:
FF00: : / 104 t o t he last 24 bit s of t he t arget address. For exam ple, given t he I nt erface I D derived
in Figure 2- 15, t he solicit ed- node m ult icast address is FF02: : 1: FF0A: 2D51. The reason for t his is
t hat if a node has aut oconfigured m ore t han one int erface address, t he last 24 bit s of all of it s
addresses should be t he sam e. So t he one NS wit h a solicit ed- node m ult icast address should
m at ch all of it s int erface addresses. More im port ant , using a solicit ed- node m ult icast address
ensures t hat if t wo nodes at t em pt t o do a Duplicat e Address Det ect ion on t he sam e address
sim ult aneously, t hey will det ect each ot her.
I f a node receives an NS and t he t arget address m at ches one of it s assigned addresses, it sends
an NA wit h t he Target Address and t he dest inat ion address set t o t he t ent at ive address. The
node t hat had originat ed t he NS, on receipt of t he NA, knows t hat t he t ent at ive address is
duplicat e and cannot be used.
Neighbor Address Resolution
You know from Chapt er 1 t hat when an I Pv4 node want s t o com m unicat e wit h anot her I Pv4
node on a local link, it m ust first discover t he dest inat ion's link- layer ( or dat a link) address. This
address is t hen used as t he dest inat ion address in t he fram e t hat encapsulat es t he I P packet s t o
t hat node. For exam ple, a node m ight want t o send a packet t o exam plehost .com . A DNS query
ret urns t he address 3FFE: 521: 2400: 15: 211: 24FF: FE23: 334E. The sending node m ust now
discover t he link- layer address t o use as a dest inat ion address of t he fram e for t he local link. As
t he previous chapt er discussed, I Pv4 uses ARP for t his discovery. I Pv6, however, uses NDP.
When t he node exam ines t he prefix of t he I Pv6 address ret urned by DNS, it eit her concludes
t hat t he dest inat ion is a neighbor on t he local link or t hat it is off- link and t herefore reachable
t hrough t he default rout er. I f t he lat t er is t he case, t he node should already know t he link- layer
address of t he default rout er from t he RAs. But if t he dest inat ion is on t he local link, t he node
first looks in it s neighbor cache t o see
very sim ilar t o t he ARP cache in I Pv4;
layer addresses associat ed wit h t hem .
Windows XP host . The neighbor cache
layer addresses:
if t he address is known. The neighbor cache in I Pv6 is
it records known net work- layer addresses and t he linkThe following shows a neighbor cache from a Microsoft
st ores known I Pv6 addresses and t heir associat ed link-
C:\Documents and Settings\Jeff Doyle>ipv6 nc
5: fe80::202:2dff:fe25:5e4c 00-02-2d-25-5e-4c permanent
4: fe80::260:83ff:fe7b:2df3 00-60-83-7b-2d-f3 stale (router)
4: fe80::210:a4ff:fea0:bc97 00-10-a4-a0-bc-97 permanent
4: 3ffe:3700:1100:1:210:a4ff:fea0:bc97 00-10-a4-a0-bc-97 permanent
4: 3ffe:3700:1100:1:d9e6:b9d:14c6:45ee 00-10-a4-a0-bc-97 permanent
4: 2001:468:1100:1:210:a4ff:fea0:bc97 00-10-a4-a0-bc-97 permanent
4: 2001:468:1100:1:d9e6:b9d:14c6:45ee 00-10-a4-a0-bc-97 permanent
3: 2002:c058:6301::c058:6301 192.88.99.1
permanent
3: 2002:836b:213c::836b:213c 131.107.33.60
permanent
3: 2002:4172:a85b::4172:a85b 127.0.0.1
permanent
3: 2002:836b:213c:1:e0:8f08:f020:6 131.107.33.60
permanent
3: 2001:708:0:1::624
incomplete
2:
::65.114.168.91 127.0.0.1
permanent
2: fe80::5efe:65.114.168.91 127.0.0.1
permanent
2: fe80::5efe:169.254.113.126 127.0.0.1
permanent
1:
fe80::1
permanent
1:
::1
permanent
I f t he address is not in t he neighbor cache, it is ent ered but t agged I ncom plet e, indicat ing t hat
address resolut ion is in progress. The node t hen sends an NS t o t he solicit ed- node m ult icast
address associat ed wit h t he t arget node. The NS should include t he Source Link- Layer opt ion
( t ype 1) , so t hat t he solicit ed node would have t he link- layer address of t he solicit ing node, and
t herefore would know where t o send t he responding NA. I f a value ot her t han 0 is included in t he
RAs, m ult iple NSs can be sent at t hat specified int erval. I f t he Ret ransm it Tim er value in t he RAs
is unspecified ( 0) , t he NS is ret ransm it t ed every 1000 m s unt il an NA is received. I f no NA is
received from t he solicit ed node aft er t hree NS t ransm issions, t he neighbor address resolut ion
has failed and an I CMP m essage of t ype 1/ code 3 ( Dest inat ion Unreachable/ Address
Unreachable) is ret urned for each packet queued for t ransm ission t o t he now unknown
dest inat ion.
I f t he solicit ed node exist s and t he NS is valid, it responds wit h an NA. The Target Address field
of t he NA is set t o t he value of t he Target Address field of t he NS t hat t riggered it . The solicit ing
node, upon receipt of t he NA, can add t he t arget node's link- layer address t o t he neighbor cache
ent ry and change t he ent ry from I ncom plet e t o Reachable.
The neighbor cache of a Cisco rout er can be observed wit h t he com m and sh ow ipv6
n e igh bor s, as shown in Exam ple 2- 1.
Ex a m ple 2 - 1 . Th e n e igh bor ca ch e of a Cisco r ou t e r ca n be displa ye d
w it h t h e com m a n d sh ow ipv6 n e igh bor s.
Confucius# show ipv6 neighbors
IPv6 Address
2001:201:1502:1:210:a4ff:fea0:bc97
fe80::210:a4ff:fea0:bc97
fe80::260:83ff:fe4c:5df2
Age
0
0
0
Link-layer Addr
0010.a4a0.bc97
0010.a4a0.bc97
0060.834c.5df2
State
REACH
REACH
REACH
Interface
Ethernet0
Ethernet0
Ethernet0
3ffe:1300:a47:20:d9e6:b9d:14c6:45ee
0
0002.2d25.5e4c
REACH
Ethernet1
Privacy Addresses
The st at eless address aut oconfigurat ion has raised a securit y concern for som e: Even if a device
m oves from subnet t o subnet or even m aj or net work t o m aj or net work, it s I nt erface I D always
rem ains t he sam e; and if t he I nt erface I D rem ains t he sam e, it can be t racked. At t he least , t his
becom es a privacy issue. For exam ple, suppose you are using I Pv6 t o connect t o your com pany
net work. Recording and analyzing packet s com ing int o som e part of t he net work can ident ify you
by your unchanging I nt erface I D. And by furt her analyzing t he different prefixes prepended t o
t hat I nt erface I D, your em ployer can infer where you are at all t im es: at work, at hom e,
t raveling, or what ever. More insidious uses can also be m ade of such t racking, keeping record of
your locat ion and act ivit ies for everyt hing from m arket ing t o crim inal exploit at ion.
RFC 3041 addresses t his securit y concern by defining I Pv6 privacy addresses. A privacy address
is one in which t he I nt erface I D is generat ed by an algorit hm using a pseudo- random num ber.
What is significant about it , and m akes it reasonably privat e, is t hat t he I nt erface I D changes
approxim at ely once a day ( or on som e configurable period) and also whenever t he node acquires
a new I Pv6 prefix.
Of course, a const ant ly changing address is not pract ical for reachabilit y. Nodes t hat want t o
com m unicat e wit h you, and hence DNS servers, m ust know you by only one or a few st at ic
addresses. So t he st andard st at elessly configured I Pv6 address rem ains your public address.
Anyone want ing t o send packet s t o you uses t his address as t he dest inat ion. But when you send
packet s back, you use t he privat e address. This is a bit like having Caller I D in your hom e but
blocking your num ber from appearing on anyone else's Caller I D. You can see who is calling you,
but ot hers cannot see your num ber when you call t hem .
The following shows t he addresses assigned t o a Microsoft Windows XP m achine. There are t wo
public I Pv6 addresses assigned t o t he int erface, and you can see t hat alt hough t he prefixes are
different , t he MAC- t o- EUI 64generat ed I nt erface I Ds are t he sam e. You can easily ident ify t he
public I nt erface I Ds by t he 0xFFFE insert ed in t he m iddle. But for bot h of t hese public addresses
t here is also a privat e address ( which Windows labels as " anonym ous" ) . These privat e addresses
are creat ed by prepending t he RA- discovered I Pv6 prefix ont o t he random ly generat ed I nt erface
I D. Public and privat e ( called " anonym ous" here) are used t oget her t o creat e anonym it y for t he
host but at t he sam e t im e m aint ain reachabilit y:
C:\Documents and Settings\Jeff Doyle>ipv6 if 4
Interface 4: Ethernet: Local Area Connection 2
uses Neighbor Discovery
uses Router Discovery
link-layer address: 00-10-a4-a0-bc-97
preferred global 2001:484:1200:1:d9e6:b9d:14c6:45ee,
life 6d21h14m26s/21h12m4s (anonymous)
preferred global 2001:468:1200:1:210:a4ff:fea0:bc97,
life 29d23h59m25s/6d23h59m25s (public)
preferred global 3ffe:3705:1200:1:d9e6:b9d:14c6:45ee,
life 6d21h14m26s/21h12m4s (anonymous)
preferred global 3ffe:3705:1200:1:210:a4ff:fea0:bc97,
life 29d23h59m25s/6d23h59m25s (public)
preferred link-local fe80::210:a4ff:fea0:bc97, life infinite
multicast interface-local ff01::1, 1 refs, not reportable
multicast link-local ff02::1, 1 refs, not reportable
multicast link-local ff02::1:ffa0:bc97, 3 refs, last reporter
multicast link-local ff02::1:ffc6:45ee, 2 refs, last reporter
link MTU 1500 (true link MTU 1500)
current hop limit 64
reachable time 22000ms (base 30000ms)
retransmission interval 1000ms
DAD transmits 1
Neighbor Unreachability Detection
The discussion of neighbor address resolut ion in a previous sect ion m ade m ent ion of neighbor
cache ent ries being labeled as I ncom plet e or Reachable. I n fact , a neighbor cache ent ry can be
in one of five st at es:
I n com ple t e Neighbor address resolut ion is in progress. An NS has been sent t o t he
solicit ed- node m ult icast address for t he ent ry, but no NA has yet been received.
Re a ch a ble The address has been recent ly confirm ed as reachable. " Recent ly confirm ed"
m eans t hat som e indicat ion of it s reachabilit y has been received wit hin t he t im e specified in
t he Reachable Tim e field of t he RAs. I f no Reachable Tim e has been specified in RAs, a
default Reachable Tim e of 30 seconds is used.
St a le The Reachable Tim e has elapsed since t he last posit ive confirm at ion of reachabilit y
wit h t he dest inat ion has been received.
Pr obe A confirm at ion of reachabilit y is being sought by sending NS t o t he dest inat ion every
Ret ransm it Tim e or ( if no Ret ransm it Tim e has been specified) every 1000 m s.
D e la y An address is put int o t his st at e when a packet is sent t o a dest inat ion t hat was in
t he St ale st at e. I t st ays in t he Delay st at e for 5 seconds, and if no confirm at ion of
reachabilit y is received wit hin t hat t im e, t he st at e is changed t o Probe. This st at e is an
opt im izat ion t o give upper- layer prot ocols a chance t o confirm reachabilit y before a probe
NS is sent .
Reachabilit y of a neighbor is confirm ed in one of t wo ways:
" Hint s" from an upper- layer prot ocol, such as an ACK of a TCP m essage.
A response t o a probe of t he dest inat ion address by solicit ing an RA or NA. This is
necessary because som e upper- layer prot ocols, such as UDP, do not act ively acknowledge
t he receipt of t ransm it t ed m essages.
Neighbor Unreachabilit y Det ect ion confirm s not j ust reachabilit y from t he neighbor's perspect ive,
Looking Ahead
The purpose of t his and t he previous chapt er was t o exam ine t he basics of I P in bot h of it s
versions. Underst anding t he basics of I P addressing and t he fundam ent al processes of I P
provides t he foundat ion for underst anding I P rout ing. The next chapt er delves int o t he
inform at ion a rout er needs t o successfully and accurat ely forward a packet t oward it s
dest inat ion.
Review Questions
1
What is t he lengt h of an I Pv6 address?
2
How are I Pv6 addresses represent ed?
3
What are t he t wo rules for com pact ing I Pv6 addresses?
4
Why is it illegal t o use m ore t han one double colon in an I Pv6 address?
5
What is t he difference bet ween t he I Pv6 addresses : : / 0 and : : / 128?
6
What is t he part of t he unicast I Pv6 address t hat specifies t he host , and what is it s
lengt h?
7
What is t he lengt h of t he Subnet I D port ion of t he unicast I Pv6 address?
8
I f t he first 10 bit s of an I Pv6 address are FF80: : / 10, what t ype of address is it ?
9
What t ype of address is 3FFE: 204: 100: 90: : 1?
10
What is an anycast address?
11
What is a m ult icast address?
12
What is t he lengt h of t he I Pv6 header?
13
What is t he purpose of t he Flow Label field in t he I Pv6 header?
14
To what field in t he I Pv4 header does t he I Pv6 Next Header field correspond?
15
To what field in t he I Pv4 header does t he I Pv6 Hop Lim it field correspond?
16
I n what way is t he I Pv6 Next Header field like t he I Pv4 Prot ocol Num ber field, and in
what way is it different ?
17
How do ext ension headers m ake I Pv6 packet s m ore efficient ?
18
What is t he Next Header value of I CMPv6?
19
What is t he significant difference bet ween I Pv4 fragm ent at ion and I Pv6
fragm ent at ion?
20
What are t he five I CMPv6 m essages used by t he Neighbor Discovery Prot ocol?
21
What is t he purpose of t he M and O flags in t he RA?
22
What is t he purpose of t he Reachable Tim e field of t he RA?
23
What is t he purpose of t he Ret ransm it Tim er field in t he RA?
24
What is indicat ed if t he Rout er Lifet im e field in t he RA is set t o 0?
25
What is t he purpose and effect of t he S flag in t he NA?
26
What is t he difference bet ween st at eful and st at eless address aut oconfigurat ion?
27
What t wo st eps does MAC- t o- EUI 64 conversion use t o derive an I nt erface I D?
28
When a device acquires a unicast I Pv6 address it m ust perform Duplicat e Address
Det ect ion, wit h one except ion. What is t hat except ion?
29
What does t he prefix FF02: 0: 0: 0: 0: 1: FF00: : / 104 signify?
30
What does I Pv6 use in place of ARP and an ARP cache?
31
What is a privacy address?
32
What does an I ncom plet e st at e of an ent ry in t he neighbor cache signify?
33
What does a Probe st at e of an ent ry in t he neighbor cache signify?
34
What t wo ways does Neighbor Unreachabilit y Det ect ion use t o verify t wo- way
reachabilit y of a neighbor?
Chapter 3. Static Routing
This chapt er covers t he following subj ect s:
Rout e Table
Configuring St at ic Rout es
Troubleshoot ing St at ic Rout es
An im port ant observat ion from Chapt er 1, " TCP/ I P Review," is t hat t he dat a link/ physical layers
and t he t ransport / net work layers, as defined by t he OSI m odel, perform very sim ilar dut ies:
They provide t he m eans for conveying dat a from a source t o a dest inat ion across som e pat h.
The difference is t hat t he dat a link/ physical layers provide com m unicat ions across a physical
pat h, whereas t he t ransport / net work layers provide com m unicat ions across a logical or virt ual
pat h m ade up of a series of dat a links.
Furt her, Chapt er 1 showed t hat for com m unicat ions t o t ake place across a physical pat h, cert ain
inform at ion about dat a- link ident ifiers and encapsulat ions m ust be acquired and st ored in a
dat abase such as t he ARP cache. Sim ilarly, inform at ion t hat t he t ransport / net work layers require
t o do t heir j ob m ust also be acquired and st ored. This inform at ion is st ored in t he rout e t able,
also known as t he rout ing inform at ion dat abase ( RI B) .
This chapt er exam ines what sort of inform at ion is required t o rout e a packet , how t hat
inform at ion is st ored in t he rout e t able, how t o ent er t he inform at ion int o t he dat abase, and
som e t echniques for building a rout ed net work by ent ering t he proper inform at ion int o t he
proper rout ers' rout e t ables.
Route Table
To underst and t he kind of inform at ion t hat exist s in t he rout e t able, it is useful t o begin wit h an
exam inat ion of what happens when a fram ed packet arrives at one of a rout er's int erfaces. The
dat a- link ident ifier in t he fram e's dest inat ion address field is exam ined. I f it cont ains eit her t he
ident ifier of t he rout er's int erface or a broadcast ident ifier, t he rout er st rips off t he fram e and
passes t he enclosed packet t o t he net work layer. At t he net work layer, t he dest inat ion address
of t he packet is exam ined. I f t he dest inat ion address is eit her t he I P address of t he rout er's
int erface or an all- host s broadcast address, t he prot ocol field of t he packet is exam ined and t he
enclosed dat a is sent t o t he appropriat e int ernal process. [ 1]
[1]
There is also the special case of a multicast address, which is destined for a group of devices, but not for all devices. An
example of a multicast address is the class D address 224.0.0.5, reserved for all OSPF-speaking routers.
Any ot her dest inat ion address calls for rout ing. The address m ight be for a host on anot her
net work t o which t he rout er is at t ached ( including t he rout er int erface at t ached t o t hat net work)
or for a host on a net work not direct ly connect ed t o t he rout er. The address m ight also be a
direct ed broadcast , in which t here is a dist inct net work or subnet address, and t he rem aining
host bit s are all ones. These addresses are also rout able.
I f t he packet is t o be rout ed, t he rout er will do a rout e t able lookup t o acquire t he correct rout e.
At a m inim um , each rout e ent ry in t he dat abase m ust cont ain t wo it em s:
D e st in a t ion a ddr e ss This is t he address of t he net work t he rout er can reach. As t his
chapt er explains, t he rout er m ight have m ore t han one rout e t o t he sam e address, or a
group of subnet s of t he sam e or of varying lengt hs, grouped under t he sam e m aj or I P
net work address.
Poin t e r t o t h e de st in a t ion This point er eit her will indicat e t hat t he dest inat ion net work is
direct ly connect ed t o t he rout er or it will indicat e t he address of anot her rout er on a direct ly
connect ed link or t he local int erface t o t hat link. That rout er, which will be one rout er hop
closer t o t he dest inat ion, is a next - hop rout er.
The rout er will m at ch t he m ost specific address it can. [ 2] I n descending order of specificit y, t he
address m ay be one of t he following:
[2]
There are two basic procedures for finding the best match, depending upon whether the router is behaving classfully or
classlessly. Classful table lookups are explained in more detail in Chapter 5, "Routing Information Protocol (RIP)," and
classless table lookups are explained in Chapter 6, "RIPv2, RIPng, and Classless Routing."
Host address ( a host rout e)
Subnet
Group of subnet s ( a sum m ary rout e)
Maj or net work num ber
Group of m aj or net work num bers ( a super net)
Default address
This chapt er provides exam ples of t he first four t ypes. Supernet s are covered in Chapt er 6,
" RI Pv2, RI Png, and Classless Rout ing." A default address is considered a least - specific address
and is m at ched only if no ot her m at ch can be found. Default addressing is t he t opic of Chapt er
12 , " Default Rout es and On- Dem and Rout ing."
I f t he dest inat ion address of t he packet cannot be m at ched t o any rout e t able ent ry, t he packet
is dropped and a Dest inat ion Unreachable I CMP m essage is sent t o t he source address.
Figure 3- 1 shows a sim ple net work and t he rout e t able ent ries required by each rout er. Of
prim ary im port ance here is t he " big pict ure," seeing how t he rout e t ables work as a whole t o
t ransport packet s correct ly and efficient ly. The dest inat ion addresses t hat t he rout er can reach
are list ed in t he Net work colum n of t he rout e t ables. The point ers t o t he dest inat ions are in t he
Next Hop colum n.
Figu r e 3 - 1 . Th e m in im u m in for m a t ion n e e de d for e a ch r ou t e t a ble
e n t r y con sist s of t h e de st in a t ion n e t w or k s a n d t h e poin t e r s t o t h ose
n e t w or k s.
[View full size image]
I f rout er Carroll in Figure 3- 1 receives a packet wit h a source address of 10.1.1.97 and a
dest inat ion address of 10.1.7.35, a rout e t able lookup det erm ines t hat t he best m at ch for t he
dest inat ion address is subnet 10.1.7.0, reachable via next - hop address 10.1.2.2, on int erface
S0. The packet is sent t o t hat next rout er ( Dahl) , which does a lookup in it s own t able and sees
t hat net work 10.1.7.0 is reachable via next - hop address 10.1.4.2, out int erface S1. The process
cont inues unt il t he packet reaches rout er Baum . That rout er, receiving t he packet on it s int erface
S0, does a lookup, and sees t hat t he dest inat ion is on one of it s direct ly connect ed subnet s, out
E0. Rout ing is com plet ed, and t he packet is delivered t o host 10.1.7.35 on t he Et hernet link.
The rout ing process, as explained, assum es t hat t he rout er can m at ch it s list ed next - hop
addresses t o it s int erfaces. For exam ple, rout er Dahl m ust know t hat Lewis's address 10.1.4.2 is
reachable via int erface S1. Dahl will know from t he I P address and subnet m ask assigned t o S1
t hat S1 is direct ly connect ed t o subnet 10.1.4.0. I t t hen knows t hat 10.1.4.2, a m em ber of t he
sam e subnet , m ust be connect ed t o t he sam e dat a link.
Not ice t hat every rout er m ust have consist ent and accurat e inform at ion for correct packet
swit ching t o occur. For exam ple, in Figure 3- 1 , an ent ry for net work 10.1.1.0 is m issing from
Dahl's rout e t able. A packet from 10.1.1.97 t o 10.1.7.35 will be delivered, but when a reply is
sent from 10.1.7.35 t o 10.1.1.97, t he packet is passed from Baum t o Lewis t o Dahl. Then, Dahl
does a lookup and finds t hat it has no ent ry for subnet 10.1.1.0, so t he packet is dropped, and
an I CMP Dest inat ion Unreachable m essage is sent t o host 10.1.7.35.
Exam ple 3- 1 shows t he rout e t able from rout er Lewis of Figure 3- 1 . The I OS com m and for
exam ining t he I P rout e t able of a Cisco rout er is sh ow ip r ou t e.
Ex a m ple 3 - 1 . Th e r ou t e t a ble for r ou t e r Le w is of Figu r e 3 - 1 .
Lewis#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP,
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route, o - ODR
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 7 subnets
S
10.1.3.0 [1/0] via 10.1.4.1
S
10.1.2.0 [1/0] via 10.1.4.1
S
10.1.1.0 [1/0] via 10.1.4.1
S
10.1.7.0 [1/0] via 10.1.6.2
C
10.1.6.0 is directly connected, Serial1
C
10.1.5.0 is directly connected, Ethernet0
C
10.1.4.0 is directly connected, Serial0
Lewis#
Exam ine t he cont ent s of t his dat abase and com pare it wit h t he generic t able shown for Lewis in
Figure 3- 1 . A key at t he t op of t he t able explains t he let t ers down t he left side of t he t able.
These let t ers indicat e how each rout e ent ry was learned; in Exam ple 3- 1, all rout es are t agged
wit h eit her a C for " direct ly connect ed," or an S for " st at ic ent ry." The st at em ent " gat eway of last
resort is not set " refers t o a default rout e.
At t he t op of t he t able is a st at em ent indicat ing t hat t he rout e t able knows of seven subnet s of
t he m aj or net work address 10.0.0.0, subnet t ed wit h a 24- bit m ask. For each of t he seven rout e
ent ries, t he dest inat ion subnet is shown; for t he ent ries t hat are not direct ly connect edrout es for
which t he packet m ust be forwarded t o a next - hop rout era bracket ed t uple indicat es
[ adm inist rat ive dist ance/ m et ric] for t hat rout e. Adm inist rat ive dist ances are int roduced lat er in
t his chapt er and are covered in det ail in Chapt er 11, " Rout e Redist ribut ion."
Met rics, discussed in great er det ail in Chapt er 4, " Dynam ic Rout ing Prot ocols," are a way for
m ult iple rout es t o t he sam e dest inat ion t o be rat ed by preferencet he lower t he m et ric, t he
" short er" t he pat h and so t he m ore desirable t he rout e. Not ice t hat t he st at ic rout es shown in
Exam ple 3- 1 have a m et ric of 0. Finally, eit her t he address of t he direct ly connect ed int erface of
t he next - hop rout er or t he int erface t o which t he dest inat ion is connect ed is shown.
Configuring Static Routes
The rout e t able acquires inform at ion in one of t hree ways:
The inform at ion can be ent ered based on what t he rout er knows about it s direct ly
connect ed subnet s.
The inform at ion can be ent ered m anually, by m eans of a st at ic rout e ent ry.
The inform at ion can be ent ered aut om at ically by one of several syst em s of aut om at ic
inform at ion discovery and sharing known as dynam ic rout ing prot ocols.
The bulk of t his book concerns dynam ic I P rout ing prot ocols, but t his discussion of st at ic rout e
configurat ion will prepare you for underst anding t he subsequent chapt ers.
More t o t he point , st at ic rout ing is preferred over dynam ic rout ing in cert ain circum st ances. As
wit h any process, t he m ore aut om at ic it is, t he less cont rol you have over it . Alt hough dynam ic
( aut om at ic) rout ing requires m uch less hum an int ervent ion, st at ic rout ing allows very precise
cont rol over t he rout ing behavior of a net work. The price t o be paid for t his precision is t he
necessit y of m anual reconfigurat ion any t im e t he t opology of t he net work changes.
Case Study: Simple IPv4 Static Routes
Figure 3- 2 shows a net work wit h four rout ers and six dat a links. Not ice t hat t he subnet s of
net work 10.0.0.0 are discont iguoust here is a different m aj or net work subnet ( 192.168.1.192, in
t he Tigger- t o- Piglet link) separat ing 10.1.0.0 from t he ot her 10.0.0.0 subnet s. The subnet s of
10.0.0.0 are also variably subnet t ed t he subnet m asks are not consist ent t hroughout t he
net work: Subnet 10.1.0.0 has a 16- bit m ask, while 10.4.0.0 has a 24- bit m ask. Finally, t he
subnet address of Pooh's Et hernet link is an all- zero subnet . Lat er chapt ers dem onst rat e t hat an
addressing schem e wit h t hese charact erist ics causes problem s for sim pler, classful rout ing
prot ocols such as RI P and I GRP; but st at ic rout es work fine here.
Figu r e 3 - 2 . Rou t in g pr ot ocols su ch a s RI P a n d I GRP ca n n ot e a sily
r ou t e t h is discon t igu ou s, va r ia bly su bn e t t e d n e t w or k , bu t st a t ic
r ou t in g w ill w or k .
[View full size image]
The procedure for st at ically rout ing a net work has t hree st eps:
1 . For each dat a link wit hin t he net work, ident ify all subnet or net work addresses.
2 . For each rout er, ident ify all dat a links not direct ly connect ed t o t hat rout er.
3 . For each rout er, writ e a rout e st at em ent for each address not direct ly connect ed t o
it .
Writ ing r ou t e st at em ent s for a rout er's direct ly connect ed dat a links is unnecessary, because
t he addresses and m asks configured on t he rout er's int erfaces cause t hose net works t o be
recorded in it s rout e t able.
For exam ple, t he net work in Figure 3- 2 has six subnet s:
10.1.0.0/ 16
10.4.6.0/ 24
10.4.7.0/ 24
192.168.1.192/ 27
192.168.1.64/ 27
192.168.1.0/ 27
To configure st at ic rout es for Piglet , t he subnet s t hat are not direct ly connect ed are ident ified as
follows:
10.4.6.0/ 24
10.4.7.0/ 24
192.168.1.64/ 27
192.168.1.0/ 27
These are t he subnet s for which st at ic rout es m ust be writ t en. Exam ple 3- 2 shows t he
com m ands for ent ering Piglet 's st at ic rout es. [ 3]
[3]
For the static routes in this example and the subsequent examples in this chapter to work properly, two global commands
must be added to the routers: ip classless and ip subnet-zero. In IOS 11.3 and later, ip classless is enabled by default.
These commands are introduced in Chapter 6 and are mentioned here for readers who wish to try the configuration
examples in a lab.
Ex a m ple 3 - 2 . Con figu r in g Pigle t 's st a t ic r ou t e s.
Piglet(config)#
Piglet(config)#
Piglet(config)#
Piglet(config)#
ip
ip
ip
ip
route
route
route
route
192.168.1.0 255.255.255.224 192.168.1.193
192.168.1.64 255.255.255.224 192.168.1.193
10.4.6.0 255.255.255.0 192.168.1.193
10.4.7.0 255.255.255.0 192.168.1.193
Following t he sam e st eps, Exam ple 3- 3 shows t he rout e ent ries for t he ot her t hree rout ers.
Ex a m ple 3 - 3 . Rou t e e n t r ie s for Rou t e r s Pooh , Tigge r , a n d Ee yor e .
Pooh(config)# ip route 192.168.1.192 255.255.255.224 192.168.1.66
Pooh(config)# ip route 10.1.0.0 255.255.0.0 192.168.1.66
Pooh(config)# ip route 10.4.6.0 255.255.255.0 192.168.1.66
Pooh(config)# ip route 10.4.7.0 255.255.255.0 192.168.1.66
_________________________________________________________________
Tigger(config)# ip route 192.168.1.0 255.255.255.224 192.168.1.65
Tigger(config)# ip route 10.1.0.0 255.255.0.0 192.168.1.194
Tigger(config)# ip route 10.4.7.0 255.255.255.0 10.4.6.2
_________________________________________________________________
Eeyore(config)# ip route 192.168.1.0 255.255.255.224 10.4.6.1
Eeyore(config)# ip route 192.168.1.64 255.255.255.224 10.4.6.1
Eeyore(config)# ip route 192.168.1.192 255.255.255.224 10.4.6.1
Eeyore(config)# ip route 10.1.0.0 255.255.0.0 10.4.6.1
The rout ing com m ands t hem selves are easily read if t he reader rem em bers t hat each com m and
describes a rout e t able ent ry. The com m and for I Pv4 is ip r ou t e, followed by t he address t o be
ent ered int o t he t able, a m ask for det erm ining t he net work port ion of t he address, and t he
address of t he direct ly connect ed int erface of t he next - hop rout er.
An alt ernat ive configurat ion com m and for I Pv4 st at ic rout es specifies t he int erface out of which
an address is reached inst ead of t he int erface address of t he next - hop rout er. For exam ple,
Exam ple 3- 4 shows t he possible rout e ent ries for Tigger.
Ex a m ple 3 - 4 . Alt e r n a t ive r ou t e e n t r ie s for Tigge r .
ip route 192.168.1.0 255.255.255.224 S0
ip route 10.1.0.0 255.255.0.0 E0
ip route 10.4.7.0 255.255.255.0 S1
Cert ain condit ions m ust be m et before a st at ic rout e is writ t en int o t he rout e t able. I P rout ing
m ust be enabled, t he next - hop address, if used, m ust be reachable, t he exit int erface m ust have
an I P address configured on it , and t he exit int erface m ust be up.
Exam ple 3- 5 com pares t he rout e t able result ing from t his configurat ion wit h t he rout e t able
result ing from ent ries point ing t o a next - hop rout er. Not ice t hat a cert ain inaccuracy is
int roduced: All addresses specified wit h a st at ic rout e referring t o an exit int erface are ent ered
int o t he t able as if t hey are direct ly connect ed t o t hat int erface. The im plicat ions for rout e
redist ribut ion are discussed in Chapt er 11.
A point of int erest in Exam ple 3- 5 is t hat t he header for t he 10.0.0.0 subnet s indicat es t he
variable subnet m asks used in t he net work. Variable- lengt h subnet m asking ( VLSM) can be a
useful t ool and is discussed at lengt h in Chapt er 6.
Ex a m ple 3 - 5 . Th e t op r ou t e t a ble is t h e r e su lt of st a t ic r ou t e e n t r ie s
poin t in g t o t h e n e x t - h op r ou t e r . Th e bot t om r ou t e t a ble is t h e r e su lt of
st a t ic r ou t e s t h a t poin t t o t h e in t e r fa ce a pa ck e t m u st e x it t o r e a ch t h e
de st in a t ion n e t w or k . [ 4 ]
Tigger#show ip route
Gateway of last resort is not set
10.0.0.0 is variably subnetted, 3 subnets, 2 masks
C
10.4.6.0 255.255.255.0 is directly connected, Serial1
S
10.4.7.0 255.255.255.0 [1/0] via 10.4.6.2
S
10.1.0.0 255.255.0.0 [1/0] via 192.168.1.194
192.168.1.0 255.255.255.224 is subnetted, 3 subnets
C
192.168.1.64 is directly connected, Serial0
S
192.168.1.0 [1/0] via 192.168.1.65
C
192.168.1.192 is directly connected, Ethernet0
Tigger#
Tigger#show ip route
Gateway of last resort is not set
10.0.0.0 is variably subnetted, 3 subnets, 2 masks
C
10.4.6.0 255.255.255.0 is directly connected, Serial1
S
10.4.7.0 255.255.255.0 is directly connected, Serial1
S
10.1.0.0 255.255.0.0 is directly connected, Ethernet0
192.168.1.0 255.255.255.224 is subnetted, 3 subnets
C
192.168.1.64 is directly connected, Serial0
S
192.168.1.0 is directly connected, Serial0
C
192.168.1.192 is directly connected, Ethernet0
Tigger#
[4]
The key normally seen at the top of the route table (as in Figure 3-2) has been removed for clarity.
A t hird opt ion for st at ic rout es is t o use a com binat ion of t he out going int erface and t he next - hop
address. The next - hop address is coupled wit h t he specified exit int erface. I f t he exit int erface
goes down, t he rout e is rem oved from t he rout e t able, even if t he next - hop address is
recursively reachable via an alt ernat e rout e. This m inim izes t able lookups associat ed wit h finding
t he out going int erface associat ed wit h a next - hop address and t he ent ry in t he t able appears as
a rout e wit h a dist ance of 1, not a direct ly connect ed net work.
Direct ing a st at ic rout e t o an exit broadcast int erface wit hout specifying t he next - hop address
can cause an excessive am ount of t raffic on t he broadcast net work, and also m ight eat up t he
rout er's m em ory. For exam ple, look at Tigger's ip r ou t e 1 0 .1 .0 .0 2 5 5 .2 5 5 .0 .0 E0 com m and.
The rout er assum es 10.1.0.0 is direct ly connect ed, as we have seen from t he rout e t able.
Therefore, when at t em pt ing t o rout e t o any address on t he 10.1.0.0/ 16 subnet , t he rout er sends
an ARP request t o find t he MAC address t o which t o forward t he packet . Each at t em pt t o reach
an address on t he 10.1.0.0 net work, whet her t he dest inat ion is valid or not , will result in an ARP
request , an ARP response if a rout er on t he broadcast net work is responding on behalf of t he
10.1.0.0 net work ( proxy ARP) , and a pot ent ially large ARP cache on t he rout er. By appending
t he next - hop address t o t he st at ic rout e ent ry, ip r ou t e 1 0 .1 .0 .0 2 5 5 .2 5 5 .0 .0 E0
1 9 2 .1 6 8 .1 .1 9 4 , t he rout er no longer assum es t hat t he dest inat ion is direct ly connect ed. The
only ARP t raffic is for t he next - hop address, which only occurs for t he first packet dest ined t o a
host on net work 10.1.0.0, rat her t han for every packet dest ined t o a new host on net work
10.1.0.0.
Specify t he exit int erface and t he next - hop address t o m inim ize t able lookups associat ed wit h
finding t he exit int erface for a specified next - hop address, and t o m inim ize t raffic on t he
broadcast net work.
Exam ple 3- 6 shows t he difference in t he st at ic rout e ent ries in t he rout e t ables when t he next hop address is used wit h t he exit int erface.
Ex a m ple 3 - 6 . Spe cifyin g a n e x it in t e r fa ce r a t h e r t h a n t h e n e x t - h op
r ou t e r a ddr e ss w it h st a t ic r ou t in g cou ld ge n e r a t e e x ce ssive t r a ffic on a
br oa dca st n e t w or k .
Tigger#show ip route static
10.0.0.0/16 is subnetted, 1 subnets
S
10.1.0.0 is directly connected, Ethernet0
Tigger#show arp
Protocol
Address
Internet
192.168.1.193
Internet
10.1.8.1
Internet
192.168.1.194
Internet
10.1.5.5
Internet
10.1.1.1
Tigger#
Age (min)
0
24
0
0
Hardware Addr
0004.c150.f1c0
0010.7b38.37d5
0010.7b38.37d5
0010.7b38.37d5
0010.7b38.37d5
Type
ARPA
ARPA
ARPA
ARPA
ARPA
Interface
Ethernet0
Ethernet0
Ethernet0
Ethernet0
Ethernet0
Tigger#show ip route static
10.0.0.0/16 is subnetted, 1 subnets
S
10.1.0.0 [1/0] via 192.168.1.194, Ethernet0
Tigger#show arp
Protocol Address
Internet 192.168.1.193
Internet 192.168.1.194
Age (min)
22
Hardware Addr Type
0004.c150.f1c0 ARPA
0010.7b38.37d5 ARPA
Interface
Ethernet0
Ethernet0
The first rout e t able and ARP cache show t hat t he st at ic rout e ent ry was creat ed wit h an exit
int erface and no next - hop address. The rout e is direct ly connect ed and t here are m ult iple ARP
cache ent ries for dest inat ions on t he 10.1.0.0 net work. The MAC address for each ent ry is t he
sam e. I t is t he hardware address of t he rout er wit h I P address 192.168.1.194. The rout er is
sending ARP replies for all host s on t he 10.1.0.0 net work. As discussed in Chapt er 1, t his proxy
ARP is enabled by default in I OS.
The second set of t ables shows t he rout e t able and ARP cache when t he next - hop address is
specified in addit ion t o t he exit int erface. Not ice t he rout e is no longer direct ly connect ed. I t is
known via 192.168.1.194 and t he exit int erface is Et hernet 0. The ARP cache has no ent ries for
t he 10.1.0.0 net work, only for t he addresses t hat act ually exist on t he direct ly connect ed
net work, including 192.168.1.194.
Case Study: Simple IPv6 Static Routes
I Pv6 st at ic rout es are configured t he sam e way as I Pv4 st at ic rout es. The only difference is t hat
t he I Pv6 prefix lengt h of t he dest inat ion net work is ent ered rat her t han t he dot t ed decim al form
of t he I Pv4 net work m ask. Unlike I Pv4, however, I Pv6 rout ing is not enabled by default . Before
ent ering a st at ic rout e, I Pv6 m ust be enabled using t he ipv6 u n ica st - r ou t in g com m and. As
wit h I Pv4, an I Pv6 address m ust be configured on t he exit int erface and t he int erface m ust be up
before t he st at ic ent ry will be added t o t he rout e t able. The com m and used t o creat e a st at ic
rout e is ipv6 r ou t e followed by t he net work t o be ent ered int o t he rout e t able, t he lengt h, in
bit s of t he prefix, and t he address of t he next - hop rout er, or t he exit int erface t o be used t o
reach t his dest inat ion.
To specify t he next - hop address in t he st at ic rout e ent ry, you need t o know what t hat address is.
A det ailed net work drawing will help, but it m ay be out of dat e because of t he dynam ic nat ure of
t he I nt erface I D port ion of t he addresses. When addressing t he I Pv6 net work, if you specify
int erface I Ds m anually rat her t han using t he aut om at ically const ruct ed EUI - 64 form at addresses,
t he next - hop address will be predict able. However, if t he int erfaces on t he dat a link are
configured t o use EUI - 64 int erface I Ds, you only specify t he first 64 bit s of t he address. The
rout er det erm ines t he final 64 bit s based on a MAC address. I f a rout er is replaced, t he new
rout er will have different I Pv6 addresses. ( The first 64 bit s will rem ain t he sam e, but t he final 64
bit s will be different .) One way t o ident ify t he full 128- bit I Pv6 address of a neighbor rout er is t o
use t he Cisco Discovery Prot ocol ( CDP) st at ist ics. CDP displays inform at ion about neighboring
rout ers, such as t he rout er's host nam e, rout er t ype, I OS, and t he I P addresses configured on t he
rem ot e end of t he link. Exam ple 3- 7 displays one form of t he sh ow cdp com m and.
Ex a m ple 3 - 7 . Cisco D iscove r y Pr ot ocol ca n t e ll you a lot of in for m a t ion
a bou t a de vice 's n e igh bor s.
Honeybee#show cdp neighbor detail
------------------------Device ID: Honeytree
Entry address(es):
IP address: 10.4.6.2
IPv6 address: FE80::2B0:64FF:FE30:1DE0 (link-local)
IPv6 address: FEC0::1:2B0:64FF:FE30:1DE0 (site-local)
Platform: cisco 2610, Capabilities: Router
Interface: Serial0/0.2, Port ID (outgoing port): Serial0/0.2
Holdtime : 146 sec
Version :
Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-J1S3-M), Version 12.3(6), RELEASE SOFTWARE (fc3)
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Wed 11-Feb-04 19:24 by kellythw
advertisement version: 2
Exam ple 3- 7 displays a lot of inform at ion about t he neighbor rout er, including t he rout er t ype,
I OS, host nam e and I P addresses. The de t a il keyword is required t o obt ain all t he inform at ion
t hat is displayed.
Anot her way t o det erm ine t he I Pv6 address of a link is t o issue t he sh ow ipv6 in t e r fa ce
com m and. This com m and displays t he I Pv6 inform at ion relevant t o an int erface. Exam ple 3- 8
shows t he out put from t he com m and issued on Honeybee.
Ex a m ple 3 - 8 . sh ow ipv6 in t e r fa ce displa ys I Pv6 in for m a t ion r e le va n t
t o a n in t e r fa ce , in clu din g t h e I Pv6 EUI - 6 4 for m a t t e d a ddr e sse s.
Honeybee#show ipv6 interface serial0/0.1
Serial0/0.1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::204:C1FF:FE50:F1C0
Description: Link to Piglet
Global unicast address(es):
FEC0::3:204:C1FF:FE50:F1C0, subnet is FEC0:0:0:3::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF30:1DE0
Figure 3- 3 shows a sim ple net work wit h I Pv6 addresses. [ 5]
[5]
The interface addresses are configured with EUI-64 addresses. The addresses, therefore, are unique to each router
based on MAC address. To reproduce the configuration, you'd have to determine your router's interface addresses to use
as the next hop.
Figu r e 3 - 3 . St a t ic r ou t in g a lso w or k s w it h I Pv6 .
[View full size image]
Exam ple 3- 9 shows t he com m ands for ent ering Honeypot 's I Pv6 st at ic rout es.
Ex a m ple 3 - 9 . Con figu r in g H on e ypot 's I Pv6 st a t ic r ou t e s.
ipv6 unicast-routing
interface serial 0/0.2 point-to-point
ipv6 address fec0:0:0:3::/64 eui-64
ipv6 route fec0::1:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0
ipv6 route fec0::a:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0
ipv6 route fec0::8:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0
Exam ple 3- 10 and Exam ple 3- 11 show t he rout e ent ries for t he ot her t wo rout ers, Honeyt ree
and Honeybee, respect ively.
Ex a m ple 3 - 1 0 . Con figu r in g I Pv6 st a t ic r ou t e s for H on e yt r e e .
ipv6 route fec0::8:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0
ipv6 route fec0::3:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0
ipv6 route fec0::5:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0
Ex a m ple 3 - 1 1 . Con figu r in g I Pv6 st a t ic r ou t e s for H on e ybe e .
ipv6 route fec0::a:0:0:0:0/64 fec0::1:2b0:64ff:fe30:1de0
ipv6 route fec0::5:0:0:0:0/64 fec0::3:230:94ff:fe24:b780
Look at t he next - hop address used for Honeypot 's rout es, and t he next - hop address used for
Honeyt ree's rout es. Honeypot 's next - hop address for each rout e is fec0: : 3: 204: c1ff: fe50: f1c0.
The next - hop address used for Honeyt ree's rout es is fec0: : 1: 204: c1ff: fe50: f1c0. These
addresses are t hose of Honeybee's int erfaces t o Honeypot and Honeyt ree, respect ively. Not ice
t hat t he last 64 bit s of each of Honeybee's int erface addresses are t he sam e. The rout er uses it s
first encount ered MAC address t o form t he last 64 bit s of t he EUI - 64 form at t ed I Pv6 addresses
on each of it s serial int erfaces.
As wit h I Pv4, I Pv6 st at ic rout es can use t he out bound int erface rat her t han next - hop address.
There is an opt ion t o ent er an address aft er t he int erface as t here is wit h I Pv4. You can put
eit her t he link- local address here or a configured address. This next - hop address should be used
when t he exit int erface is a broadcast int erface, such as Et hernet .
Exam ple 3- 12 displays Honeypot 's I Pv6 rout e t able wit h only t he next - hop address specified in
t he ipv6 r ou t e st at em ent . The com m and sh ow ipv6 r ou t e displays t he I Pv6 rout e t able.
Prefixes, prefix lengt hs, and t he next - hop address or out going int erface are displayed, as are t he
adm inist rat ive dist ance and rout e m et ric.
Ex a m ple 3 - 1 2 . As w it h I Pv4 , t h e I Pv6 st a t ic r ou t e t a ble displa ys t h e
de st in a t ion n e t w or k a n d t h e n e x t - h op a ddr e ss u se d t o r e a ch t h e
de st in a t ion .
Honeypot#show ipv6 route
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
L
C
L
S
S
S
C
L
L
FE80::/10 [0/0]
via ::, Null0
FEC0:0:0:3::/64 [0/0]
via ::, Serial0/0.2
FEC0::3:230:94FF:FE24:B780/128 [0/0]
via ::, Serial0/0.2
FEC0:0:0:A::/64 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
FEC0:0:0:8::/64 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
FEC0:0:0:1::/64 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
FEC0:0:0:5::/64 [0/0]
via ::, Ethernet0/0
FEC0::5:230:94FF:FE24:B780/128 [0/0]
via ::, Ethernet0/0
FF00::/8 [0/0]
via ::, Null0
The st at ic rout es displayed in Exam ple 3- 12 were ent ered using an I Pv6 next - hop address. The
rout er m ust det erm ine t he exit int erface associat ed wit h t his I Pv6 address recursively, as it does
wit h I Pv4. The ent ry for FEC0: 0: 0: A: : / 64 has a next - hop address of
FEC0: : 3: 204: C1FF: FE50: F1C0. Looking furt her int o t he rout e t able, FEC0: 0: 0: 3: : / 64 is
connect ed on Serial0/ 0.2. Not ice t hat t he adm inist rat ive dist ance of t he st at ic rout es ent ered
wit h t he next - hop I Pv6 address is 1 and t he rout e m et ric is 0, t he sam e as I Pv4 st at ic rout e
ent ered in t his way.
Rout es can also be ent ered wit h t he out going int erface t oward t he dest inat ion net work. The
out going int erface and t he next - hop address can be ent ered t oget her, t oo. Exam ple 3- 13 shows
what Honeypot 's st at ic rout e configurat ion could be changed t o.
Ex a m ple 3 - 1 3 . Alt e r n a t ive st a t ic r ou t e con figu r a t ion for H on e ypot .
ipv6
ipv6
ipv6
ipv6
route
route
route
route
fec0::a:0:0:0:0/64 serial 0/0.2
fec0::8:0:0:0:0/64 serial 0/0.2
fec0::1:0:0:0:0/64 serial 0/0.2
fec0::20:0:0:0:0/62 Ethernet0/0 FE80::2B0:64FF:FE30:1DE0
The last ent ry, using t he exit int erface and t he next - hop address will help t o illust rat e t he
difference in t he rout e t able bet ween t he t wo form s of t he com m and. Exam ple 3- 14 displays
Honeypot 's new rout e t able.
Ex a m ple 3 - 1 4 . H on e ypot r ou t e t a ble a ft e r ch a n gin g t h e n e x t h op t o t h e
e x it in t e r fa ce .
Honeypot#show ipv6 route static
S
S
FEC0:0:0:A::/64 [1/0]
via ::, Serial0/0.2
FEC0:0:0:8::/64 [1/0]
via ::, Serial0/0.2
S
S
FEC0:0:0:1::/64 [1/0]
via ::, Serial0/0.2
FEC0:0:0:20::/62 [1/0]
via FE80::2B0:64FF:FE30:1DE0, Ethernet0/0
One t hing t o not ice in t he rout e t able is t he adm inist rat ive dist ance of t he st at ic rout e configured
wit h an exit int erface. The dist ance is 1, unlike I Pv4 st at ic rout es configured t he sam e way. The
rout e does not appear t o be direct ly connect ed as it does wit h I Pv4.
The next - hop address is undet erm ined when you ent er t he out bound int erface unless you specify
t he exit int erface and t he next - hop address. You can see t his in t he rout e t able shown in
Exam ple 3- 14. The first st at em ent , for inst ance, says t hat FEC0: 0: 0: A: : / 64 is known via : : ,
Serial 0/ 0.2. The " : : " m eans t hat t he next hop is unspecified, but t he out going int erface is Serial
0/ 0.2. On a point - t o- point serial int erface, an unspecified next - hop address is not a problem .
There is only one ot her device on t hat point - t o- point net work, and all packet s are forwarded out
t he int erface and reach t he ot her device.
On a broadcast int erface, t he rout er m ust find a neighbor t o which t o send t he packet . The
rout er m ult icast s a neighbor solicit at ion m essage on t he Et hernet and wait s for a neighbor
advert isem ent from t he next - hop device. There is no defined proxy address resolut ion
m echanism wit h I Pv6, ot her t han for m obile I Pv6 nodes. A rout er on t he Et hernet t hat has a
rout e t o t he dest inat ion will not respond t o a neighbor solicit at ion on behalf of anot her device.
For t his reason, when using an exit int erface t o configure a st at ic rout e on a broadcast net work,
a next - hop address m ust also be specified. The recom m ended address t o use as t he next - hop
address is t he link- local address of t he next - hop rout er. One reason t o use t he link- local address
is t hat it is not likely t o change. A link- local address will only change if t he int erface card, or t he
ent ire rout er, is replaced. Even if t he sit e is renum bered wit h a different I Pv6 global prefix, t he
link- local address on t he int erface does not change. Anot her reason t o use t he link- local address
as t he next hop is t o rem ain consist ent wit h t he addresses rout ers advert ise in t he rout er
advert isem ent m essages and so t hat processes using t hose addresses, such as I CMPv6 Redirect ,
will operat e as expect ed.
Rout ers advert ise t heir presence, along wit h t heir link- local addresses, t o all I Pv6 devices on
broadcast net works. Host s use t he rout er list creat ed from t he rout er advert isem ent t o
det erm ine how t o forward packet s off t he net work. I f a host forwards a packet t o a rout er, and
t hat rout er knows t hat a second rout er on t he net work is a bet t er choice for t he host t o use, t he
first rout er will send a redirect t o t he host . The redirect includes t he link- local I Pv6 address of
t he bet t er choice rout er. When t he host processes t he redirect , if t he bet t er rout er is in it s rout er
list , t he host will begin t o forward packet s t o t he bet t er rout er. I f t he bet t er rout er is not in t he
list ( or it is list ed by a different I Pv6 address) , t he host will discard t he redirect .
Case Study: Summary Routes
A sum m ary rout e is an address t hat encom passes several m ore specific addresses in a rout e
t able. I t is t he address m ask used wit h a rout e ent ry t hat m akes st at ic rout es as flexible as t hey
are; by using an appropriat e address m ask, it is som et im es possible t o creat e a single sum m ary
rout e for several dest inat ion addresses.
For exam ple, t he preceding t wo case st udies use a separat e ent ry for each dat a link. The m ask
of each ent ry corresponds t o t he address m ask used on t he device int erfaces connect ed t o t hat
dat a link. Looking again at Figure 3- 2 , you can see t hat subnet s 10.4.6.0/ 24 and 10.4.7.0/ 24
could be specified t o Piglet wit h a single ent ry of 10.4.0.0/ 16, reachable via Tigger. Likewise,
subnet s 192.168.1.0/ 27 and 192.168.1.64/ 27 could be account ed for in it s rout e t able wit h a
single ent ry point ing t o 192.168.1.0/ 24, also reachable via Tigger. These t wo rout e ent ries,
10.4.0.0/ 16 and 192.16.1.0/ 24, are sum m ary rout es.
Using sum m ary rout es, Piglet 's st at ic rout e ent ries are displayed in Exam ple 3- 15.
Ex a m ple 3 - 1 5 . Pigle t 's st a t ic r ou t e e n t r ie s a r e su m m a r ize d in t o on ly
t w o e n t r ie s.
ip route 192.168.1.0 255.255.255.0 192.168.1.193
ip route 10.4.0.0 255.255.0.0 192.168.1.193
All subnet s of net work 10.0.0.0 are reachable from Pooh via Tigger, so a single ent ry t o t hat
m aj or net work address and a corresponding m ask are all t hat is needed ( see Exam ple 3- 16) .
Ex a m ple 3 - 1 6 . Pooh 's st a t ic r ou t e e n t r ie s for a ll of n e t w or k 1 0 .0 .0 .0
su bn e t s a r e su m m a r ize d in t o a sin gle e n t r y.
ip route 192.168.1.192 255.255.255.224 192.168.1.66
ip route 10.0.0.0 255.0.0.0 192.168.1.66
From Eeyore, all dest inat ion addresses beginning wit h 192 are reachable via Tigger. The single
rout e ent ry does not even have t o specify all of t he Class C address bit s [ 6] , as displayed in
Exam ple 3- 17.
[6]
This method of summarizing a group of major network addresses with a mask shorter than the default address mask for
that class is known as supernetting. This is introduced in Chapter 6.
Ex a m ple 3 - 1 7 . Ee yor e su m m a r ize s a ll r ou t e s be gin n in g w it h 1 9 2 in t o a
sin gle e n t r y.
ip route 192.0.0.0 255.0.0.0 10.4.6.1
ip route 10.1.0.0 255.255.0.0 10.4.6.1
Sum m ary rout es can also be applied t o t he I Pv6 dest inat ion addresses in Figure 3- 3 .
Honeypot 's t wo st at ic rout es can be sum m arized int o a group consist ing of fec0: 0: 0: 8: : t hrough
fec0: 0: 0: b: : by changing t he prefix lengt h from 64 t o 62, as in Exam ple 3- 18.
Ex a m ple 3 - 1 8 . H on e ypot su m m a r ize s I Pv6 st a t ic r ou t e s.
ipv6 route fec0::8:0:0:0:0/62 fec0::3:204:c1ff:fe50:f1c0
By sum m arizing a group of subnet s or even m aj or net works, t he num ber of st at ic rout e ent ries
m ay be reduced drast icallyin t his exam ple, by m ore t han one- t hird. However, caut ion m ust be
used when sum m arizing addresses; when done incorrect ly, unexpect ed rout ing behavior m ay
occur ( see " Case St udy: Tracing a Failed Rout e," lat er in t his chapt er) . Sum m arizat ion and t he
problem s t hat can develop from incorrect sum m arizat ion are exam ined in m ore dept h in
Chapt ers 7, " Enhanced I nt erior Gat eway Rout ing Prot ocol ( EI GRP) ," and 8, " OSPFv2."
Case Study: Alternative Routes
I n Figure 3- 4 , a new link has been added bet ween Pooh and Eeyore. All packet s from Pooh t o
t he 10.0.0.0 net works will t ake t his new pat h wit h t he except ion of packet s dest ined for t he host
10.4.7.25; a policy is in place st at ing t hat t raffic t o t his host m ust go t hrough Tigger. The st at ic
rout e com m ands at Pooh will be as displayed in Exam ple 3- 19.
Figu r e 3 - 4 . A m or e dir e ct pa t h fr om Pooh t o t h e 1 0 .4 .0 .0 su bn e t s is
a dde d t o t h e n e t w or k .
[View full size image]
Ex a m ple 3 - 1 9 . Pooh 's st a t ic r ou t e com m a n ds h e lp im ple m e n t a policy
dir e ct in g t r a ffic t h r ou gh spe cific r ou t e r s.
ip route 192.168.1.192 255.255.255.224 192.168.1.66
ip route 10.0.0.0 255.0.0.0 192.168.1.34
ip route 10.4.7.25 255.255.255.255 192.168.1.66
The first t wo rout e ent ries are t he sam e as before except t hat t he second pat h now point s t o t he
new int erface 192.168.1.34 at Eeyore. The t hird ent ry is a host rout e, point ing t o t he single host
10.4.7.25 and m ade possible by set t ing t he address m ask t o all ones. Not ice t hat unlike t he
ent ry for t he ot her 10.0.0.0 subnet s, t his host rout e point s t o Tigger's int erface 192.168.1.66.
The debugging funct ion de bu g ip pa ck e t is t urned on in Pooh ( see Exam ple 3- 20) t o observe
t he pat hs packet s t ake from t he rout er as a result of t he new rout e ent ries. A packet is sent from
a host 192.168.1.15 t o host 10.4.7.25. The first t wo debug t rap m essages show t hat t he packet
is rout ed from int erface E0 t o t he next - hop rout er 192.168.1.66 ( Tigger) out int erface S0, as
required, and t hat t he reply packet was received on S0 and rout ed t o t he host 192.168.1.15 out
E0.
Ex a m ple 3 - 2 0 . D e bu ggin g ve r ifie s t h a t t h e n e w r ou t e e n t r ie s a t Pooh
a r e w or k in g cor r e ct ly.
Pooh#debug ip packet
IP packet debugging is on
Pooh#
IP: s=192.168.1.15 (Ethernet0), d=10.4.7.25 (Serial0), g=192.168.1.66, forward
IP: s=10.4.7.25 (Serial0), d=192.168.1.15 (Ethernet0), g=192.168.1.15, forward
Pooh#
IP: s=192.168.1.15 (Ethernet0), d=10.4.7.100 (Serial1), g=192.168.1.34, forward
IP: s=10.4.7.100 (Serial0), d=192.168.1.15 (Ethernet0), g=192.168.1.15, forward
Pooh#
Next , a packet is sent from host 192.168.1.15 t o host 10.4.7.100. Packet s dest ined for any host
on 10.0.0.0 subnet s, ot her t han host 10.4.7.25, should be rout ed across t he new link t o Eeyore's
int erface 192.186.1.34. The t hird debug m essage verifies t hat t his is indeed happening.
However, t he fourt h m essage shows som et hing t hat at first m ight be surprising. The response
from 10.4.7.100 t o 192.168.1.15 arrived on Pooh's int erface S0 from Tigger.
Rem em ber t hat t he rout e ent ries in t he ot her rout ers have not changed from t he original
exam ple. This result m ight or m ight not be desired, but it does illust rat e t wo charact erist ics of
st at ic rout es:
First , if t he net work t opology changes, t he rout ers t hat are required t o know about t hose
changes m ust be reconfigured.
Second, st at ic rout es can be used t o creat e very specific rout ing behavior. I n t his exam ple,
perhaps it is desirable t o have t raffic t aking one pat h in one direct ion and anot her pat h in
t he opposit e direct ion.
A final observat ion about t his exam ple is t hat packet s rout ed from Pooh t o subnet 10.1.5.0 t ake
a less- t han- opt im al rout e, from Pooh t o Eeyore t o Tigger inst ead of direct ly from Pooh t o Tigger.
Exam ple 3- 21 shows a m ore efficient configurat ion for Rout er Pooh.
Ex a m ple 3 - 2 1 . Con figu r in g a m or e e fficie n t st a t ic r ou t e on Rou t e r
Pooh .
ip
ip
ip
ip
route
route
route
route
192.168.1.192 255.255.255.224 192.168.1.66
10.0.0.0 255.0.0.0 192.168.1.34
10.1.0.0 255.255.0.0 192.168.1.66
10.4.7.25 255.255.255.255 192.168.1.66
The t hird ent ry will now send all packet s for subnet 10.1.5.0 direct ly t o Tigger.
Case Study: Floating Static Routes
Unlike ot her st at ic rout es, a float ing st at ic rout e is less preferred t han ot her rout es in t he rout e
t able. I t appears in t he t able only under t he special circum st ance of t he failure of a m orepreferred rout e.
I n Figure 3- 5 , a new rout er ( Rabbit ) is connect ed t o Piglet wit h t wo parallel links. One link
connect s t heir respect ive Serial 0 int erfaces, and t he second connect ion has been added
bet ween t he t wo Serial 1 int erfaces. This second link has been added for redundancy: I f t he
prim ary link 10.1.10.0 fails, float ing st at ic rout es will direct t raffic across t he backup link
10.1.20.0.
Figu r e 3 - 5 . A n e w r ou t e r h a s be e n con n e ct e d t o Pigle t . Tw o se r ia l lin k s
a r e u se d: on e for t h e pr im a r y lin k a n d on e for t h e ba ck u p lin k .
[View full size image]
Addit ionally, t he m ask on Piglet 's Et hernet int erface has changed from 10.1.5.1/ 16 t o
10.1.5.1/ 24. This change allows t he single rout e ent ry at Tigger
ip route 10.1.0.0 255.255.0.0 192.168.1.194
t o point not only t o 10.1.5.0 but also t o all of t he new subnet s used in associat ion wit h t he new
rout er.
To creat e t he float ing st at ic rout e, Exam ple 3- 22 and Exam ple 3- 23 show t he rout e ent ries for
bot h Piglet and Rabbit , respect ively.
Ex a m ple 3 - 2 2 . Rou t e e n t r ie s for Pigle t t o cr e a t e a floa t in g st a t ic r ou t e .
ip
ip
ip
ip
route
route
route
route
192.168.1.0 255.255.255.0 192.168.1.193
10.4.0.0 255.255.0.0 192.168.1.193
10.1.30.0 255.255.255.0 10.1.10.2
10.1.30.0 255.255.255.0 10.1.20.2 50
Ex a m ple 3 - 2 3 . Rou t e e n t r ie s for Ra bbit t o cr e a t e a floa t in g st a t ic
r ou t e .
ip
ip
ip
ip
ip
route
route
route
route
route
10.4.0.0 255.255.0.0 10.1.10.1
10.4.0.0 255.255.0.0 10.1.20.1 50
10.1.5.0 255.255.255.0 10.1.10.1
10.1.5.0 255.255.255.0 10.1.20.1 50
192.168.0.0 255.255.0.0 10.1.10.1
ip route 192.168.0.0 255.255.0.0 10.1.20.1 50
Two ent ries at Piglet point t o Rabbit 's net work 10.1.30.0; one specifies a next - hop address of
Rabbit 's S0 int erface, and t he ot her specifies a next - hop address of Rabbit 's S1 int erface. Rabbit
has sim ilar double ent ries for every rout e.
Not ice t hat all st at ic rout es using subnet 10.1.20.0 are followed by a 50. This num ber specifies
an adm inist rat ive dist ance, which is a m easure of preferabilit y; when duplicat e pat hs t o t he
sam e net work are known, t he rout er will prefer t he pat h wit h t he lower adm inist rat ive dist ance.
At first t his idea sounds like a m et ric; however, a m et ric specifies t he preferabilit y of a rout e,
whereas an adm inist rat ive dist ance specifies t he preferabilit y of t he m eans by which t he rout e
was discovered.
For exam ple, I Pv4 st at ic rout es point ing t o a next - hop address have an adm inist rat ive dist ance
of 1, and st at ic rout es referencing an exit int erface have an adm inist rat ive dist ance of 0. I f t wo
st at ic rout es point t o t he sam e dest inat ion, but one references a next - hop address and one
references an exit int erface, t he lat t erwit h t he lower adm inist rat ive dist ancewill be preferred.
By increasing t he adm inist rat ive dist ances of t he st at ic rout es t raversing subnet 10.1.20.0 t o 50,
t hey becom e less preferred t han t he rout es t raversing subnet 10.1.10.0. Exam ple 3- 24 shows
t hree it erat ions of Rabbit 's rout e t able. I n t he first t able, all rout es t o nonconnect ed net works
use a next - hop address of 10.1.10.1. The bracket ed num bers associat ed wit h each rout e indicat e
an adm inist rat ive dist ance of 1 and a m et ric of 0 ( because no m et rics are associat ed wit h st at ic
rout es) .
Ex a m ple 3 - 2 4 . W h e n t h e pr im a r y lin k 1 0 .1 .1 0 .0 fa ils, t h e ba ck u p lin k
1 0 .1 .2 0 .0 is u se d. W h e n t h e pr im a r y lin k is r e st or e d, it is a ga in t h e
pr e fe r r e d pa t h .
Rabbit#show ip route
10.0.0.0 is variably subnetted, 5 subnets, 2 masks
C 10.1.10.0 255.255.255.0 is directly connected, Serial0
S 10.4.0.0 255.255.0.0 [1/0] via 10.1.10.1
S 10.1.5.0 255.255.255.0 [1/0] via 10.1.10.1
C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0
C 10.1.20.0 255.255.255.0 is directly connected, Serial1
S 192.168.0.0 255.255.0.0 [1/0] via 10.1.10.1
Rabbit#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down
%LINK-3-UPDOWN: Interface Serial0, changed state to down
Rabbit#show ip route
10.0.0.0 is variably subnetted, 4 subnets, 2 masks
S 10.4.0.0 255.255.0.0 [50/0] via 10.1.20.0
S 10.1.5.0 255.255.255.0 [50/0] via 10.1.20.1
C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0
C 10.1.20.0 255.255.255.0 is directly connected, Serial1
S 192.168.0.0 255.255.0.0 [50/0] via 10.1.20.1
Rabbit#
%LINK-3-UPDOWN: Interface Serial0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to up
Rabbit#show ip route
10.0.0.0 is variably subnetted, 5 subnets, 2 masks
C 10.1.10.0 255.255.255.0 is directly connected, Serial0
S 10.4.0.0 255.255.0.0 [1/0] via 10.1.10.1
S 10.1.5.0 255.255.255.0 [1/0] via 10.1.10.1
C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0
C 10.1.20.0 255.255.255.0 is directly connected, Serial1
S 192.168.0.0 255.255.0.0 [1/0] via 10.1.10.1
Rabbit#
Next , t rap m essages announce t hat t he st at e of t he prim ary link connect ed t o Serial 0 has
changed t o " down," indicat ing a failure. A look at t he second it erat ion of t he rout e t able shows
t hat all nonconnect ed rout es now point t o a next - hop address of 10.1.20.1. Because t he m orepreferred ent ry is no longer available, t he rout er has swit ched t o t he less- preferred backup link,
wit h t he adm inist rat ive dist ance of 50 indicat ed in t he bracket s. And because subnet 10.1.10.0
has failed, it no longer shows up in t he rout e t able as a direct ly connect ed net work.
Before t he t hird it erat ion of t he rout e t able, t rap m essages indicat e t hat t he st at e of t he prim ary
link has changed t o " up." The rout e t able t hen shows t hat subnet 10.1.10.0 is again in t he t able,
and t he rout er is again using t he next - hop address of 10.1.10.1.
Chapt er 11 discusses t he adm inist rat ive dist ances associat ed wit h t he various dynam ic rout ing
prot ocols, but it can be said here t hat t he adm inist rat ive dist ances of all dynam ic rout ing
prot ocols are subst ant ially higher t han 1. Therefore, by default , a st at ic rout e t o a net work will
always be preferred over a dynam ically discovered rout e t o t he sam e net work.
Case Study: IPv6 Floating Static Routes
I Pv6 float ing st at ic rout e st at em ent s work t he sam e way as I Pv4. A second link has been added
t o t he I Pv6 net work of Figure 3- 3 bet ween Honeypot and Honeybee, t o rout e I Pv6 t raffic if t he
prim ary link fails ( see Figure 3- 6 ) .
Figu r e 3 - 6 . Ba ck u p lin k a dde d be t w e e n t w o I Pv6 r ou t e r s ca n be u se d
t o r e cove r fr om a pr im a r y lin k fa ilu r e w it h floa t in g st a t ic r ou t e s.
[View full size image]
Exam ple 3- 25 shows Honeypot 's configurat ion wit h new st at ic rout e ent ries, which have an
adm inist rat ive dist ance great er t han 1. Sim ilar st at ic rout es are ent ered on Honeybee, as shown
in Exam ple 3- 26.
Ex a m ple 3 - 2 5 . H on e ypot is con figu r e d w it h floa t in g st a t ic r ou t e s t o be
u se d ove r t h e n e w r e du n da n t pa r a lle l lin k t o H on e ybe e .
ipv6
ipv6
ipv6
ipv6
route
route
route
route
FEC0::/62 FEC0::3:204:C1FF:FE50:F1C0
FEC0::/62 FEC0::2:204:C1FF:FE50:F1C0 50
FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0
FEC0:0:0:8::/62 FEC0::2:204:C1FF:FE50:F1C0 50
Ex a m ple 3 - 2 6 . H on e ybe e is con figu r e d w it h floa t in g st a t ic r ou t e s t o be
u se d ove r t h e n e w r e du n da n t pa r a lle l lin k t o H on e ypot .
ipv6 route FEC0:0:0:5::/64 FEC0::3:230:94FF:FE24:B780
ipv6 route FEC0:0:0:5::/64 FEC0::2:230:94FF:FE24:B780 50
ipv6 route FEC0:0:0:A::/64 FEC0::1:2B0:64FF:FE30:1DE0
I Pv6 t raffic from Honeypot will cont inue t o be forwarded out Serial0/ 0.2, unless t his link goes
down.
Exam ple 3- 27 shows Honeypot 's rout e t able wit h t he rout es known via t he fec0: : 3: 0: 0: 0: 0/ 64
subnet inst alled. Bot h rout es have an adm inist rat ive dist ance of 1. Then, int erface S0/ 0.2 goes
down. The backup rout es, wit h adm inist rat ive dist ance of 50, get inst alled in t he rout e t able.
Aft er t he int erface S0/ 0.2 com es back up, t he rout ing process learns of bet t er rout es t o t he
dest inat ions and inst alls t he rout es wit h an adm inist rat ive dist ance of 1 back int o t he t able.
Ex a m ple 3 - 2 7 . St a t ic r ou t e s w it h h igh a dm in ist r a t ive dist a n ce s a r e
in st a lle d in t h e I Pv6 r ou t e t a ble on ly w h e n t h e low e r a dm in ist r a t ive
dist a n ce r ou t e s a r e de le t e d.
Honeypot#show ipv6 route static
S
FEC0::/62 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
S
FEC0:0:0:8::/62 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
Honeypot#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2, changed state to down
%LINK-3-UPDOWN: Interface Serial0/2, changed state to down
Honeypot#show ipv6 route static
S
FEC0::/62 [50/0]
via FEC0::2:204:C1FF:FE50:F1C0
S
FEC0:0:0:8::/62 [50/0]
via FEC0::2:204:C1FF:FE50:F1C0
Honeypot#
%LINK-3-UPDOWN: Interface Serial0/2, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2, changed state to up
The default adm inist rat ive dist ance of I Pv6 st at ic rout es, whet her specified wit h an exit int erface
or a next - hop address, is 1. When st at ic rout es t o a dest inat ion are specified bot h ways, t he
rout es are considered equal, and load sharing ( described in t he next case st udy) occurs.
Case Study: Load Sharing
The problem wit h t he configurat ion used in t he previous sect ion is t hat under norm al
circum st ances t he second link is never ut ilized. The bandwidt h available on t he link is wast ed.
Load sharing allows rout ers t o t ake advant age of m ult iple pat hs t o t he sam e dest inat ion by
sending packet s over all t he available rout es.
Load sharing can be equal cost or unequal cost , where cost is a generic t erm referring t o
what ever m et ric ( if any) is associat ed wit h t he rout e:
Equ a l- cost load sharing dist ribut es t raffic equally am ong m ult iple pat hs wit h equal
m et rics. I n t his case, load sharing can also be called load balancing.
Un e qu a l- cost load sharing dist ribut es packet s am ong m ult iple pat hs wit h different
m et rics. The t raffic is dist ribut ed in inverse proport ion t o t he cost of t he rout es. That is,
pat hs wit h lower cost s are assigned m ore t raffic, and pat hs wit h higher cost s are assigned
less t raffic.
Som e rout ing prot ocols support bot h equal- cost and unequal- cost load sharing, whereas ot hers
support only equal cost . St at ic rout es, which have no m et ric, support only equal- cost load
sharing.
To configure t he parallel links in Figure 3- 5 for load sharing using st at ic rout es, Exam ple 3- 28
shows t he rout e ent ries for Piglet and Exam ple 3- 29 shows t he rout e ent ries for Rabbit .
Ex a m ple 3 - 2 8 . Con figu r in g pa r a lle l lin k s for loa d sh a r in g u sin g st a t ic
r ou t e s: r ou t e e n t r ie s for Pigle t .
ip
ip
ip
ip
route
route
route
route
192.168.1.0 255.255.255.0 192.168.1.193
10.4.0.0 255.255.0.0 192.168.1.193
10.1.30.0 255.255.255.0 10.1.10.2
10.1.30.0 255.255.255.0 10.1.20.2
Ex a m ple 3 - 2 9 . Con figu r in g pa r a lle l lin k s for loa d sh a r in g u sin g st a t ic
r ou t e s: r ou t e e n t r ie s for Ra bbit .
ip
ip
ip
ip
ip
ip
route
route
route
route
route
route
10.4.0.0 255.255.0.0 10.1.10.1
10.4.0.0 255.255.0.0 10.1.20.1
10.1.5.0 255.255.255.0 10.1.10.1
10.1.5.0 255.255.255.0 10.1.20.1
192.168.0.0 255.255.0.0 10.1.10.1
192.168.0.0 255.255.0.0 10.1.20.1
These ent ries were also used in t he previous sect ion for float ing st at ic rout es, except bot h links
now use t he default adm inist rat ive dist ance of 1. Rabbit 's rout e t able, shown in Exam ple 3- 30,
now has t wo rout es t o each dest inat ion.
Ex a m ple 3 - 3 0 . Th is r ou t e t a ble in dica t e s t h a t t h e r e a r e t w o pa t h s t o
t h e sa m e de st in a t ion n e t w or k s. Th e r ou t e r w ill ba la n ce t h e loa d a cr oss
t h e se m u lt iple pa t h s.
Rabbit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C
10.1.10.0/24 is directly connected, Serial0
S
10.1.5.0/24 [1/0] via 10.1.10.1
[1/0] via 10.1.20.1
S
10.4.0.0/16 [1/0] via 10.1.10.1
[1/0] via 10.1.20.1
C
10.1.20.0/24 is directly connected, Serial1
S
192.168.0.0/16 [1/0] via 10.1.10.1
[1/0] via 10.1.20.1
Rabbit#
I Pv6 works t he sam e way as I Pv4. The st at ic rout es in Honeypot 's rout e t able, shown in Exam ple
3- 31 , will yield t he rout e t able shown in Exam ple 3- 32.
Ex a m ple 3 - 3 1 . H on e ypot 's I Pv6 st a t ic r ou t e s a r e con figu r e d for loa dba la n cin g, w it h e a ch de st in a t ion pr e fix u sin g t w o diffe r e n t n e x t - h op
a ddr e sse s.
ipv6
ipv6
ipv6
ipv6
route
route
route
route
FEC0::/62 FEC0::2:204:C1FF:FE50:F1C0
FEC0::/62 FEC0::3:204:C1FF:FE50:F1C0
FEC0:0:0:8::/62 FEC0::2:204:C1FF:FE50:F1C0
FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0
Ex a m ple 3 - 3 2 . Th e r ou t e r w ill loa d ba la n ce ove r t h e se t w o I Pv6 pa t h s
t o t h e sa m e de st in a t ion n e t w or k s.
Honeypot#show ipv6 route static
S
FEC0::/62 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
via FEC0::2:204:C1FF:FE50:F1C0
S
FEC0:0:0:8::/62 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
via FEC0::2:204:C1FF:FE50:F1C0
Load sharing is also eit her per dest inat ion or per packet .
Load Sharing and Cisco Express Forwarding
Per dest inat ion load sharing dist ribut es t he load according t o dest inat ion address. Given t wo
pat hs t o t he sam e net work, all packet s for one dest inat ion m ay t ravel over t he first pat h, all
packet s for a second dest inat ion on t he sam e net work m ay t ravel over t he second pat h, all
packet s for a t hird dest inat ion m ay again be sent over t he first pat h, and so on. This is t he
default t ype of load sharing used by Cisco Express Forwarding ( CEF) . On m ost plat form s, CEF is
t he default swit ching m ode for I Pv4, but not I Pv6.
CEF is a very efficient swit ching process. I t s forwarding inform at ion is obt ained and st ored in
t ables before any packet needs t o use t he inform at ion. CEF builds a forwarding inform at ion base
( FI B) wit h inform at ion obt ained from t he rout e t able. All t he dest inat ion net works ent ered in t he
rout e t able are ent ered int o t he CEF FI B. I f t he rout e t able is st able and not changing, t he FI B
will not change. CEF uses a separat e t able, t he adj acency t able, t o m aint ain Layer 2 forwarding
inform at ion for each ent ry in t he FI B. The adj acency t able is creat ed as Layer 2 inform at ion is
learned, t hrough I P ARP or I Pv6 Neighbor Discovery, for inst ance. Bot h t he FI B and adj acency
t able are creat ed before packet s need t o be forwarded. Not even t he first packet t o a dest inat ion
is process swit ched, as is t he case wit h ot her swit ching schem es.
CEF perform s per- dest inat ion load sharing by default . This is act ually per source- dest inat ion pair
load sharing. All t raffic t hat has a part icular source address and is dest ined t o a specific
dest inat ion address will exit t he sam e int erface. Traffic wit h a different source/ dest inat ion
address pair m ay exit t he next int erface.
Per packet load sharing is anot her m et hod available t o CEF swit ched I Pv4 packet s. I Pv6 CEF only
support s per dest inat ion load sharing. Per packet load sharing m eans t hat one packet is sent
over one link, t he next packet is sent over t he next link, even if t his next packet is t o t he sam e
dest inat ion as t he first , and so on, given equal- cost pat hs. I f t he pat hs are unequal cost , t he
load sharing m ay be one packet over t he higher- cost link for every t hree packet s over t he lowercost link, or som e ot her proport ion depending upon t he rat io of cost s. Per packet load sharing
m ay dist ribut e t he load m ore evenly t han per dest inat ion load sharing, depending upon t he
num ber of different source- dest inat ion pairs, but because t he packet s t o a given dest inat ion will
be t aking different pat hs, t he packet s are likely t o arrive out of order, which is unaccept able for
som e applicat ions, such as Voice over I P.
To det erm ine if CEF is enabled globally on a rout er, use t he com m ands sh ow ip ce f and sh ow
ipv6 ce f. I f it is not enabled by default , you can t urn it on globally using t he com m and ip ce f
for I Pv4. To enable CEF for I Pv6, first enable CEF for I Pv4, t hen use t he com m and ipv6 ce f.
Per packet load sharing is enabled for I Pv4 using t he int erface com m and ip load- sharing perpacket . The com m and ip loa d- sh a r in g pe r - de st in a t ion re- enables per dest inat ion load
sharing. You can see which t ype of load sharing is enabled using t he sh ow ce f in t e r fa ce
com m and. This displays t he CEF inform at ion t hat is configured on t he int erface.
The rout er det erm ines whet her t o use CEF swit ching based on t he ingress int erface and t he t ype
of source and dest inat ion address. The ingress int erface m ust be configured wit h CEF swit ching
for t he rout er t o even consider using CEF. I f CEF is configured on t he ingress int erface, CEF will
at t em pt t o swit ch t he packet . I f for som e reason t he packet cannot be CEF swit ched, CEF punt s
t he packet down t o t he next - best and available swit ching m et hod. For I Pv4, t his would be fast
swit ching, if it is enabled on t he int erface. For I Pv6, t his would be process swit ching.
You can verify t hat CEF is enabled on an int erface using t he com m ands sh ow ce f in t e r fa ce
{ int erface} and sh ow ipv6 ce f { int erface} de t a il.
Per Destination Load Sharing and Fast Switching
I OS perform s per dest inat ion load sharing on exit int erfaces configured wit h fast swit ching. Fast
swit ching is t he default I OS swit ching m ode in som e rout ers.
Fast swit ching works as follows:
1 . When a rout er swit ches t he first packet t o a part icular dest inat ion, a rout e t able lookup is
perform ed and an exit int erface is select ed.
2 . The necessary dat a- link inform at ion t o fram e t he packet for t he select ed int erface is t hen
ret rieved ( from t he ARP cache, for inst ance) , and t he packet is encapsulat ed and
t ransm it t ed.
3 . The ret rieved rout e and dat a- link inform at ion is t hen ent ered int o a fast swit ching cache.
4 . As subsequent packet s t o t he sam e dest inat ion ent er t he rout er, t he inform at ion in t he fast
cache allows t he rout er t o im m ediat ely swit ch t he packet wit hout perform ing anot her rout e
t able and ARP cache lookup.
While swit ching t im e and processor ut ilizat ion are decreased, fast swit ching m eans t hat all
packet s t o a specific dest inat ion, not source- dest inat ion pair, are rout ed out t he sam e int erface.
When packet s addressed t o a different host on t he sam e net work ent er t he rout er and an
alt ernat e rout e exist s, t he rout er m ay send all packet s for t hat dest inat ion on t he alt ernat e
rout e. Therefore, t he best t he rout er can do is balance t raffic on a per dest inat ion basis.
Per Packet Load Sharing and Process Switching
Process swit ching sim ply m eans t hat for every packet , t he rout er perform s a rout e t able lookup,
select s an int erface, and t hen looks up t he dat a link inform at ion. Because each rout ing decision
is independent for each packet , all packet s t o t he sam e dest inat ion are not forced t o use t he
sam e int erface. To enable process swit ching on an int erface, use t he com m and n o ip r ou t e ca ch e for I Pv4. You don't have t o do anyt hing t o enable process swit ching for I Pv6. I t is enabled
by default .
I n Exam ple 3- 33, host 192.168.1.15 has sent six pings t o host 10.1.30.25. Using de bu g ip
pa ck e t , t he I CMP echo request and echo reply packet s are observed at Piglet . Looking at t he
exit int erfaces and t he forwarding addresses, it can be observed t hat bot h Piglet and Rabbit are
using S0 and S1 alt ernat ely. Not e t hat t he com m and de bu g ip pa ck e t allows only process
swit ched packet s t o be observed. Fast swit ched packet s are not displayed.
N ot e
The de bu g ip pa ck e t com m and displays only process swit ched packet s.
Ex a m ple 3 - 3 3 . Th is r ou t e r is a lt e r n a t in g be t w e e n S0 a n d S1 t o se n d
pa ck e t s t o t h e sa m e de st in a t ion . N ot ice t h a t t h e r ou t e r on t h e ot h e r
e n d of t h e t w o lin k s is doin g t h e sa m e t h in g w it h t h e r e ply pa ck e t s.
Piglet#debug ip packet
IP packet debugging is on
Piglet#
IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0),
IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0),
IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1),
IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0),
IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0),
IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0),
IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1),
IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0),
IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0),
IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0),
IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1),
IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0),
Piglet#
g=10.1.10.2, forward
g=192.168.1.193, forward
g=10.1.20.2, forward
g=192.168.1.193, forward
g=10.1.10.2, forward
g=192.168.1.193, forward
g=10.1.20.2, forward
g=192.168.1.193, forward
g=10.1.10.2, forward
g=192.168.1.193, forward
g=10.1.20.2, forward
g=192.168.1.193, forward
Like m any design choices, per packet load balancing has a price. The t raffic m ay be dist ribut ed
m ore evenly am ong t he various links t han wit h per dest inat ion load balancing, but t he lower
swit ching t im e and processor ut ilizat ion of fast swit ching are lost .
Which Switching Method Will Be Used?
I OS m akes swit ching decisions based on t he configurat ion of t he inbound int erface first . I f CEF is
configured on an inbound int erface, t he packet will be CEF swit ched regardless of t he
configurat ion on t he out bound int erface.
I f CEF is not enabled on t he inbound int erface, t hen I OS processes and forwards t he packet , and
based on t he configurat ion of t he out bound int erface, subsequent packet s will be fast - swit ched
or process swit ched. Table 3- 1 shows which swit ching m et hod will be used based on
configurat ion of inbound and out bound int erfaces.
Ta ble 3 - 1 . I OS sw it ch in g de t e r m in a t ion is ba se d on
con figu r a t ion of in bou n d a n d ou t bou n d in t e r fa ce s.
I n bou n d Con figu r a t ion
Ou t bou n d
Con figu r a t ion
Sw it ch in g M e t h od Use d
CEF
Pr ocess
CEF
CEF
Fast
CEF
Pr ocess
CEF
Fast ( or process if I Pv6)
Pr ocess
Fast
Fast
Fast
CEF
Fast ( or process if I Pv6)
Fast
Pr ocess
Pr ocess
I OS will swit ch a packet using CEF only if CEF is enabled on t he inbound int erface. I f CEF is not
configured on t he inbound int erface, t he configurat ion of t he exit int erface det erm ines t he
swit ching m et hod. Not ice t hat when process or fast - swit ching is configured inbound and CEF is
configured on t he out bound int erface, fast - swit ching is used. CEF is only used if it is configured
on t he ingress int erface. For I Pv4, fast - swit ching is enabled out bound, even if CEF is enabled on
t he int erface.
There are t im es when a packet will not be swit ched using CEF even if it is enabled ( for exam ple,
if access- list logging is enabled and a packet will be logged) . Packet s will be punt ed down t o t he
next fast est swit ching m et hod. For I Pv4, t he next fast est swit ching m et hod is fast - swit ching. For
I Pv6, t his is process swit ching.
Case Study: Recursive Table Lookups
All rout e ent ries do not necessarily need t o point t o t he next - hop rout er. Figure 3- 7 shows a
sim plified version of t he net work of Figure 3- 5 . I n t his net work, Pooh is configured as displayed
in Exam ple 3- 34.
Figu r e 3 - 7 . To r e a ch n e t w or k 1 0 .1 .3 0 .0 , Pooh m u st pe r for m t h r e e
r ou t e t a ble look u ps.
[View full size image]
Ex a m ple 3 - 3 4 . Pooh 's st a t ic r ou t e e n t r ie s u se va r iou s a ddr e sse s a s t h e
n e x t - h op pa r a m e t e r . Th e a ddr e sse s a r e n ot n e ce ssa r ily t h e a ct u a l
n e x t - h op r ou t e r in t e r fa ce .
ip route 10.1.30.0 255.255.255.0 10.1.10.2
ip route 10.1.10.0 255.255.255.0 192.168.1.194
ip route 192.168.1.192 255.255.255.224 192.168.1.66
I f Pooh needs t o send a packet t o host 10.1.30.25, it will look int o it s rout e t able and find t hat
t he subnet is reachable via 10.1.10.2. Because t hat address is not on a direct ly connect ed
net work, Pooh m ust again consult t he t able t o find t hat net work 10.1.10.0 is reachable via
192.168.1.194. That subnet is also not direct ly connect ed, so a t hird t able lookup is called for.
Pooh will find t hat 192.168.1.192 is reachable via 192.168.1.66, which is on a direct ly connect ed
subnet . The packet can now be forwarded.
Because each t able lookup cost s processor t im e, under norm al circum st ances forcing a rout er t o
perform m ult iple lookups is a poor design decision. Fast swit ching significant ly reduces t hese
adverse effect s by lim it ing t he recursive lookups t o t he first packet t o each dest inat ion, but a
j ust ificat ion should st ill be ident ified before using such a design.
Figure 3- 8 shows an exam ple of an inst ance in which recursive lookups m ight be useful. Here,
Sanderz reaches all net works via Heffalum p. However, t he net work adm inist rat or plans t o
elim inat e Heffalum p and repoint all of Sanderz's rout es t hrough Woozle. The first 12 ent ries
point not t o Heffalum p, but t o t he appropriat e rout er at t ached t o t he 10.87.14.0 subnet . The last
ent ry specifies t hat t he 10.87.14.0 subnet is reached via Heffalum p.
Figu r e 3 - 8 . Con figu r in g Sa n de r z for r e cu r sive look u ps e n a ble s t h e
n e t w or k a dm in ist r a t or t o r e dir e ct a ll of t h a t r ou t e r 's e x it t r a ffic fr om
H e ffa lu m p t o W oozle by ch a n gin g on e r ou t e e n t r y.
[View full size image]
Wit h t his configurat ion, all of Sanderz's ent ries can be repoint ed t hrough Woozle sim ply by
changing t he last st at ic ent ry as in Exam ple 3- 35.
Ex a m ple 3 - 3 5 . Sa n de r z's r ou t in g ca n e a sily be m odifie d t o for w a r d a ll
r ou t e s t h r ou gh a diffe r e n t n e x t - h op r ou t e r sim ply by ch a n gin g on e
st a t ic r ou t e e n t r y.
Sanderz(config)# ip route 10.87.14.0 255.255.255.0 10.23.5.95
Sanderz(config)# no ip route 10.87.14.0 255.255.255.0 10.23.5.20
Had all t he st at ic rout es referenced 10.23.5.20 as t he next - hop address, it would have been
necessary t o delet e all 13 lines and t ype 13 new lines. Nevert heless, t he effort saved in ret yping
st at ic rout es m ust be weighed carefully against t he ext ra processing burden t hat recursive
Troubleshooting Static Routes
Followers of t he assort ed Am erican polit ical scandals of t he past 30 or so years will have heard a
congressional invest igat or ask t he quest ion, " What did he know and when did he know it ?" The
sam e quest ion serves a net working invest igat or well. When t roubleshoot ing rout ing problem s,
t he first st ep should alm ost always be t o exam ine t he rout e t able. What does t he rout er know?
How long has t he inform at ion been in t he rout e t able? Does t he rout er know how t o reach t he
dest inat ion in quest ion? I s t he inform at ion in t he rout e t able accurat e? Knowing how t o t race a
rout e is essent ial t o successfully t roubleshoot ing a net work.
Case Study: Tracing a Failed Route
Figure 3- 9 shows a previously configured net work, wit h each rout er's associat ed st at ic rout es. A
problem has been discovered. Devices on subnet 192.168.1.0/ 27, connect ed t o Pooh's Et hernet
int erface, can com m unicat e wit h devices on subnet 10.1.0.0/ 16 j ust fine. However, when a ping
is sent from Pooh it self t o subnet 10.1.0.0/ 16, t he ping fails ( see Exam ple 3- 36 ) . This seem s
st range. I f packet s being rout ed by Pooh successfully reach t heir dest inat ions, why do packet s
originat ed by t he sam e rout er fail?
Figu r e 3 - 9 . Pa ck e t s fr om su bn e t 1 9 2 .1 6 8 .1 .0 / 2 7 t o su bn e t 1 0 .1 .0 .0 / 1 6
a r e r ou t e d cor r e ct ly, bu t Pooh it se lf ca n n ot pin g a n y de vice on
1 0 .1 .0 .0 / 1 6 .
[View full size image]
Ex a m ple 3 - 3 6 . A de vice on su bn e t 1 9 2 .1 6 8 .1 .0 / 2 7 su cce ssfu lly pin gs
Pigle t 's Et h e r n e t in t e r fa ce , bu t pin gs fr om Pooh fa il.
C:\WINDOWS>ping 10.1.5.1
Pinging 10.1.5.1 with 32 bytes of data:
Reply from 10.1.5.1: bytes=32 time=22ms
Reply from 10.1.5.1: bytes=32 time=22ms
Reply from 10.1.5.1: bytes=32 time=22ms
Reply from 10.1.5.1: bytes=32 time=22ms
TTL=253
TTL=253
TTL=253
TTL=253
Pooh#ping 10.1.5.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echoechoes to 10.1.5.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Pooh#
Addressing t his problem requires t racing t he rout e of t he ping. First , Pooh's rout e t able is
exam ined ( Exam ple 3- 37 ) . The dest inat ion address of 10.1.5.1 m at ches t he rout e ent ry for
10.0.0.0/ 8, which ( according t o t he t able) is reached via t he next - hop address 192.168.1.34one
of Eeyore's int erfaces.
Ex a m ple 3 - 3 7 . A pa ck e t w it h a de st in a t ion a ddr e ss of 1 0 .1 .5 .1
m a t ch e s t h e r ou t e e n t r y for 1 0 .0 .0 .0 / 8 a n d w ill be for w a r de d t o t h e
n e x t - h op r ou t e r a t 1 9 2 .1 6 8 .1 .3 4 .
Pooh#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
10.0.0.0 is variably subnetted, 2 subnets, 2 masks
S
10.0.0.0 255.0.0.0 [1/0] via 192.168.1.34
S
10.4.7.25 255.255.255.255 [1/0] via 192.168.1.66
192.168.1.0 255.255.255.224 is subnetted, 4 subnets
C
192.168.1.64 is directly connected, Serial0
C
192.168.1.32 is directly connected, Serial1
C
192.168.1.0 is directly connected, Ethernet0
S
192.168.1.192 [1/0] via 192.168.1.66
Pooh#
Next t he rout e t able for Eeyore m ust be exam ined ( Exam ple 3- 38 ) . The dest inat ion address
10.1.5.1 m at ches t he ent ry 10.1.0.0/ 16, wit h a next - hop address of 10.4.6.1. This address is
one of Tigger's int erfaces.
Ex a m ple 3 - 3 8 . 1 0 .1 .5 .1 m a t ch e s t h e e n t r y for 1 0 .1 .0 .0 / 1 6 a n d w ill be
for w a r de d t o 1 0 .4 .6 .1 .
Eeyore#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
10.0.0.0 is variably subnetted, 3 subnets, 2 masks
C
C
S
10.4.6.0 255.255.255.0 is directly connected, Serial1
10.4.7.0 255.255.255.0 is directly connected, Ethernet0
10.1.0.0 255.255.0.0 [1/0] via 10.4.6.1
192.168.1.0 255.255.255.224 is subnetted, 1 subnets
C
192.168.1.32 is directly connected, Serial0
S
192.0.0.0 255.0.0.0 [1/0] via 10.4.6.1
Eeyore#
Exam ple 3- 39 shows Tigger's rout e t able. The dest inat ion address m at ches t he ent ry for
10.1.0.0/ 16 and will be forwarded t o 192.168.1.194, which is at Piglet .
Ex a m ple 3 - 3 9 . 1 0 .1 .5 .1 m a t ch e s t h e e n t r y for 1 0 .1 .0 .0 / 1 6 a n d w ill be
for w a r de d t o 1 9 2 .1 6 8 .1 .1 9 4 .
Tigger#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
10.0.0.0 is variably subnetted, 3 subnets, 2 masks
C
10.4.6.0 255.255.255.0 is directly connected, Serial1
S
10.4.7.0 255.255.255.0 [1/0] via 10.4.6.2
S
10.1.0.0 255.255.0.0 [1/0] via 192.168.1.194
192.168.1.0 255.255.255.224 is subnetted, 3 subnets
C
192.168.1.64 is directly connected, Serial0
S
192.168.1.0 [1/0] via 192.168.1.65
C
192.168.1.192 is directly connected, Ethernet0
Tigger#
Piglet 's rout e t able ( Exam ple 3- 40 ) reveals t hat t he t arget net work, 10.1.0.0, is direct ly
connect ed. I n ot her words, t he packet has arrived. The t arget address 10.1.5.1 is Piglet 's own
int erface t o t hat net work. Because t he pat h t o t he address has j ust been verified as good, we
can assum e t hat t he I CMP echo packet s from Pooh are reaching t he dest inat ion.
Ex a m ple 3 - 4 0 . Th e de st in a t ion n e t w or k , 1 0 .1 .0 .0 , is dir e ct ly con n e ct e d
t o Pigle t .
Piglet#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
10.0.0.0 255.255.0.0 is subnetted, 2 subnets
C
10.1.0.0 is directly connected, Ethernet1
S
10.4.0.0 [1/0] via 192.168.1.193
192.168.1.0 is variably subnetted, 2 subnets, 2 masks
S
192.168.1.0 255.255.255.0 [1/0] via 192.168.1.193
C
192.168.1.192 255.255.255.224 is directly connected, Ethernet0
Piglet#
The next st ep is t o t race t he pat h of t he responding I CMP echo reply packet s. To t race t his pat h,
you need t o know t he source address of t he echo packet . That address will be t he dest inat ion
address of t he echo reply packet . The source address of a packet t hat is originat ed from a rout er
is t he address of t he int erface from which t he packet was t ransm it t ed. [ 7] I n t his exam ple, Pooh
originally forwarded t he echo packet t o 192.168.1.34. Figure 3- 9 shows t hat t he source address
of t hat packet is 192.168.1.33. So t his address is t he dest inat ion address t o which Piglet will
send t he echo reply.
[7] Unless
the Extended Ping utility is used to set the source address to something different.
Referring again t o Piglet 's rout e t able in Exam ple 3- 34 , 192.168.1.33 will m at ch t he ent ry for
192.168.1.0/ 24 and be forwarded t o 192.168.1.193, which is anot her of Tigger's int erfaces. A
re- exam inat ion of Tigger's rout e t able in Exam ple 3- 39 at first suggest s t hat t here is an ent ry for
192.168.1.0. But t ake care t o int erpret correct ly t he inform at ion t hat is act ually t here.
Com pare t he ent ries in Tigger's rout e t able for t he 10.0.0.0 subnet s t o t hose of t he 192.168.1.0
subnet s. The heading for t he form er says t hat 10.0.0.0 is variably subnet t ed; in ot her words,
Tigger's st at ic rout e t o subnet 10.4.7.0 uses a 24- bit m ask, and t he st at ic rout e t o subnet
10.1.0.0 uses a 16- bit m ask. The t able records t he correct m ask at each subnet .
The heading for 192.168.1.0 is different . This heading st at es t hat Tigger knows of t hree subnet s
of 192.168.1.0 and t hat t hey all have a m ask of 255.255.255.224. This m ask will be used on t he
dest inat ion address of 192.168.1.33 t o derive a dest inat ion net work of 192.168.1.32/ 27. The
rout e t able has ent ries for 192.168.1.64/ 27, 192.168.1.0/ 27, and 192.168.1.192/ 27. There is no
ent ry for 192.168.1.32/ 27, so t he rout er does not know how t o reach t his subnet .
The problem , t hen, is t hat t he I CMP echo reply packet is being dropped at Tigger. One solut ion is
t o creat e anot her st at ic rout e ent ry for net work 192.168.1.32, wit h a m ask of 255.255.255.224
and point ing t o a next hop of eit her 192.168.1.65 or 10.4.6.2. Anot her solut ion would be t o
change t he m ask in t he exist ing st at ic rout e ent ry for 192.168.1.0 from 255.255.255.224 t o
255.255.255.0.
The m oral of t his st ory is t hat when you are t racing a rout e, you m ust consider t he com plet e
com m unicat ion process.
N ot e
Check bot h t he dest inat ion and ret urn pat h when a rout e fails.
Verify not only t hat t he pat h t o a dest inat ion is good but also t hat t he ret urn pat h is good.
Case Study: A Protocol Conflict
Figure 3- 10 shows t wo rout ers connect ed by t wo Et hernet net works, one of which includes a
sim ple bridge. This bridge handles t raffic for several ot her links not shown and occasionally
becom es congest ed. The host Milne is a m ission- crit ical server; t he net work adm inist rat or is
worried about t raffic t o Milne being delayed by t he bridge, so a st at ic host rout e has been added
in Roo t hat will direct packet s dest ined for Milne across t he t op Et hernet , avoiding t he bridge.
Figu r e 3 - 1 0 . A h ost r ou t e dir e ct s pa ck e t s fr om Roo t o M iln e a cr oss t h e
t op Et h e r n e t , a voidin g t h e occa sion a lly con ge st e d br idge .
This solut ion seem s t o be logical, but it isn't working. Aft er t he st at ic rout e was added, packet s
rout ed t hrough Roo no longer reach t he server. Not only t hat , but packet s rout ed t hrough Kanga
no longer reach t he server, alt hough no changes were m ade t o t hat rout er.
The first st ep, as always, is t o check t he rout e t able. Roo's rout e t able ( Exam ple 3- 41 ) indicat es
t hat packet s wit h a dest inat ion address of 172.16.20.75 will, in fact , be forwarded t o Kanga's E1
int erface, as desired. Kanga is direct ly connect ed t o t he dest inat ion net work, so no m ore rout ing
should be occurring; a quick check verifies t hat t he Et hernet int erfaces are funct ioning at bot h
Kanga and at Milne.
Ex a m ple 3 - 4 1 . Roo's r ou t e t a ble , sh ow in g t h e st a t ic h ost r ou t e t o M iln e
via Ka n ga 's E1 in t e r fa ce .
Roo#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C
172.16.20.0/24 is directly connected, Ethernet0
C
172.16.21.0/24 is directly connected, Ethernet1
S
172.16.20.75/32 [1/0] via 172.16.21.2
Roo#
I n Exam ple 3- 42 , a t race is perform ed from Roo t o Milne, and a sym pt om is found. I nst ead of
delivering t he packet s t o Milne, Kanga is forwarding t hem t o Roo's E0 int erface. Roo forwards
t he packet s t o Kanga's E1 int erface, and Kanga sends t he packet s right back t o Roo. A rout ing
loop seem s t o have occurred, but why?
Ex a m ple 3 - 4 2 . A t r a ce fr om Roo t o M iln e r e ve a ls t h a t Ka n ga is
for w a r din g t h e pa ck e t s ba ck t o Roo in st e a d of de live r in g t h e m t o t h e
cor r e ct de st in a t ion .
Roo#trace 172.16.20.75
Type escape sequence to abort.
Tracing the route to 172.16.20.75
1 172.16.21.2 0 msec 0 msec 0 msec
2 172.16.20.1 4 msec 0 msec 0 msec
3 172.16.21.2 4 msec 0 msec 0 msec
4 172.16.20.1 0 msec 0 msec 4 msec
5 172.16.21.2 0 msec 0 msec 4 msec
6 172.16.20.1 0 msec 0 msec 4 msec
7 172.16.21.2 0 msec 0 msec 4 msec
8 172.16.20.1 0 msec 0 msec 4 msec
9 172.16.21.2 4 msec 0 msec 4 msec
10 172.16.20.1 4 msec 0 msec 4 msec
11 172.16.21.2 4 msec
Roo#
The suspicious aspect of all of t his is t hat Kanga should not be rout ing t he packet , which appears
t o be t he case.
Kanga should recognize t hat t he dest inat ion address of t he packet is for it s direct ly connect ed
net work 172.16.20.0 and should be using t he dat a link t o deliver t he packet t o t he host .
Therefore, suspicion should fall on t he dat a link. Just as t he rout e t able should be exam ined t o
see whet her t he rout er has t he correct inform at ion for reaching a net work across a logical pat h,
t he ARP cache should be exam ined t o see whet her t he rout er has t he correct inform at ion for
reaching a host across a physical pat h.
Exam ple 3- 43 shows t he ARP cache for Kanga. The I P address for Milne is in Kanga's cache as
expect ed, wit h a MAC ident ifier of 00e0.1e58.dc39. When Milne's int erface is checked, t hough, it
shows t hat it has a MAC ident ifier of 0002.6779.0f4c; Kanga has som ehow acquired incorrect
inform at ion.
Ex a m ple 3 - 4 3 . Ka n ga 's ARP ca ch e h a s a n e n t r y for M iln e , bu t t h e
a ssocia t e d da t a - lin k ide n t ifie r is w r on g.
Kanga#show arp
Protocol Address
Age (min)
Internet 172.16.21.1
2
Internet 172.16.20.2
Internet 172.16.21.2
Internet 172.16.20.75
2
Kanga#
Hardware Addr
00e0.1e58.dc3c
00e0.1e58.dcb1
00e0.1e58.dcb4
00e0.1e58.dc39
Type
ARPA
ARPA
ARPA
ARPA
Interface
Ethernet1
Ethernet0
Ethernet1
Ethernet0
Anot her look at Kanga's ARP t able reveals t hat t he MAC ident ifier associat ed wit h Milne is
suspiciously sim ilar t o t he MAC ident ifier of Kanga's own Cisco int erfaces. ( The MAC addr esses
wit h no ages associat ed wit h t hem are for t he rout er's int erfaces.) Because Milne is not a Cisco
product , t he first t hree oct et s of it s MAC ident ifier should be different from t he first t hree oct et s
of Kanga's MAC ident ifier. The only ot her Cisco product in t he net work is Roo, so it s ARP cache is
exam ined ( Exam ple 3- 44 ) ; 00e0.1e58.dc39 is t he MAC ident ifier of Roo's E0 int erface.
Ex a m ple 3 - 4 4 . Roo's ARP ca ch e sh ow s t h a t t h e M AC ide n t ifie r t h a t
Ka n ga h a s for M iln e is a ct u a lly Roo's E0 in t e r fa ce .
Roo#show
Protocol
Internet
Internet
Internet
Internet
Roo#
arp
Address
Age (min)
172.16.21.1
172.16.20.1
172.16.20.2
7
172.16.21.2
7
Hardware Addr
00e0.1e58.dc3c
00e0.1e58.dc39
00e0.1e58.dcb1
00e0.1e58.dcb4
Type
ARPA
ARPA
ARPA
ARPA
Interface
Ethernet0
Ethernet0
Ethernet0
Ethernet1
So Kanga m ist akenly believes t hat t he E0 int erface of Roo is Milne. I t fram es packet s dest ined
for Milne wit h a dest inat ion ident ifier of 00e0.1e58.dc39; Roo accept s t he fram e, reads t he
dest inat ion address of t he enclosed packet , and rout es t he packet back t o Kanga.
But how did Kanga get t he wrong inform at ion? The answer is proxy ARP. When Kanga first
receives a packet for Milne, it will use ARP t o det erm ine t hat device's dat a- link ident ifier. Milne
responds, but Roo also hears t he ARP request on it s E0 int erface. Because Roo has a rout e t o
Milne on a different net work from t he one on which it received t he ARP Request , it issues a proxy
ARP in reply. Kanga receives Milne's ARP reply and ent ers it int o t he ARP cache. The proxy ARP
reply from Roo arrives lat er because of t he delay of t he bridge. The original ARP cache ent ry is
overwrit t en by what Kanga t hinks is new inform at ion.
There are t wo solut ions t o t he problem . The first is t o t urn off proxy ARP at Roo's E0 wit h t he
following com m and sequence:
Roo(config)#interface e0
Roo(config-if)#no ip proxy-arp
The second solut ion is t o configure a st at ic ARP ent ry for Milne at Kanga wit h t he following
com m and:
Kanga(config)#arp 172.16.20.75 0002.6779.0f4c arpa
This ent ry will not be overwrit t en by any ARP reply. Exam ple 3- 45 shows t he st at ic ARP ent ry
being ent ered and t he result ing ARP cache at Kanga. Not e t hat because t he ent ry is st at ic, no
age is associat ed wit h it .
Ex a m ple 3 - 4 5 . A st a t ic ARP e n t r y on Ka n ga cor r e ct s t h e pr oble m
ca u se d by pr ox y ARP.
Kanga(config)#arp 172.16.20.75 0002.6779.0f4c arpa
Kanga(config)#^Z
Kanga#
%SYS-5-CONFIG_I: Configured from console by console
Kanga#show arp
Protocol Address
Age (min)
Hardware Addr
Type
Internet 172.16.21.1
10
00e0.1e58.dc3c
ARPA
Internet 172.16.20.2
00e0.1e58.dcb1
ARPA
Internet 172.16.21.2
00e0.1e58.dcb4
ARPA
Internet 172.16.20.75
0002.6779.0f4c
ARPA
Kanga#
Interface
Ethernet1
Ethernet0
Ethernet1
The circum st ances of t he net work should help det erm ine which of t he t wo solut ions is best . A
st at ic ARP ent ry m eans t hat if t he net work int erface at Milne is ever replaced, som eone m ust
rem em ber t o change t he ARP ent ry t o reflect t he new MAC ident ifier. On t he ot her hand, t urning
off proxy ARP is a good solut ion only if no host s m ake use of it .
Case Study: A Replaced Router
Figure 3- 11 shows t wo rout ers, Honeypot and Honeybee, connect ed via a Fram e Relay link. The
rout ers are configured for bot h I Pv4 and I Pv6, and use st at ic rout es t o creat e t he rout e t ables.
Figu r e 3 - 1 1 . A sim ple n e t w or k w it h bot h I Pv4 a n d I Pv6 .
Exam ple 3- 46 shows t he rout e configurat ions for Honeypot and Exam ple 3- 47 shows t he rout e
configurat ions for Honeybee.
Ex a m ple 3 - 4 6 . Rou t e con figu r a t ion s for H on e ypot .
ip route 10.4.0.0 255.255.0.0 192.168.1.193
ip route 192.168.1.0 255.255.255.0 192.168.1.193
ipv6 route FEC0::/62 Serial 0/0.2
ipv6 route FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0
Ex a m ple 3 - 4 7 . Rou t e con figu r a t ion s for H on e ybe e .
ip route 10.1.0.0 255.255.0.0 192.168.1.194
ipv6 route FEC0:0:0:5::/64 Serial 0/0.1
Exam ple 3- 48 shows pings and t races bet ween t he t wo rout ers are working fine. Bot h I Pv4 and
I Pv6 t raffic is working fine bet ween t he t wo sit es.
Ex a m ple 3 - 4 8 . Pin gs a n d t r a ce s sh ow t w o r ou t e r s ca n su cce ssfu lly
com m u n ica t e w it h e a ch ot h e r .
Honeypot#ping
Protocol [ip]:
Target IP address: 10.4.8.1
Extended commands [n]: y
Source address or interface: 10.1.5.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.8.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.5.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/33 ms
Honeypot#ping fec0:0:0:8:204:c1ff:fe50:f1c0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FEC0::8:204:C1FF:FE50:F1C0, timeout is 2 secon
ds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/33 ms
Honeypot#trace
Protocol [ip]: ipv6
Target IPv6 address: fec0:0:0:8:204:c1ff:fe50:f1c0
Source address: fec0:0:0:5:230:94ff:fe24:b780
Type escape sequence to abort.
Tracing the route to FEC0::8:204:C1FF:FE50:F1C0
1 FEC0::3:204:C1FF:FE50:F1C0 24 msec 24 msec 24 msec
Honeypot#trace
Protocol [ip]: ipv6
Target IPv6 address: fec0::a:0:0:0:1
Source address: fec0::5:230:94ff:fe24:b780
Type escape sequence to abort.
Tracing the route to FEC0:0:0:A::1
1 FEC0::3:204:C1FF:FE50:F1C0 24 msec 24 msec 24 msec
Honeypot can reach Honeybee's Et hernet address from it s own Et hernet address, for bot h I Pv4
and I Pv6. Anot her address, FEC0: 0: 0: A: : 1, is also reachable from Honeypot , via Honeybee.
Honeybee, however, is due t o be replaced wit h a new rout er. The rout er is replaced, Honeybee's
configurat ion is loaded int o t he new rout er, and all t he int erfaces are up. Test ing shows t hat
I Pv4 t raffic is working bet ween t he t wo sit es, but I Pv6 t raffic t o som e addresses fails ( see
Exam ple 3- 49 ) .
Ex a m ple 3 - 4 9 . Aft e r a r ou t e r r e pla ce m e n t , I Pv4 w or k s fin e , w h ile I Pv6
fa ils.
Honeypot#ping
Protocol [ip]:
Target IP address: 10.4.8.1
Extended commands [n]: y
Source address or interface: 10.1.5.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.8.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.5.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/30/32 ms
Honeypot#ping fec0:0:0:8:204:c1ff:fe50:f1c0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FEC0::8:204:C1FF:FE50:F1C0, timeout is 2 seconds:
...H.
Success rate is 0 percent (0/5)
Honeypot#trace
Protocol [ip]: ipv6
Target IPv6 address: fec0::8:204:c1ff:fe50:f1c0
Source address: fec0::5:230:94ff:fe24:b780
Type escape sequence to abort.
Tracing the route to FEC0::8:204:C1FF:FE50:F1C0
1 FEC0::3:2B0:64FF:FE30:1DE0 24 msec 24 msec 24 msec
2 * !H *
Honeypot#trace
Protocol [ip]: ipv6
Target IPv6 address: fec0::a:0:0:0:1
Source address: fec0::5:230:94ff:fe24:b780
Type escape sequence to abort.
Tracing the route to FEC0:0:0:A::1
1 FEC0::3:2B0:64FF:FE30:1DE0 24 msec 20 msec 20 msec
Pings and t races t o t he I Pv6 address FEC0: : 8: 204: c1FF: FE50: F1C0, Honeybee's Et hernet I Pv6
address, fail. A t race t o FEC0: : A: 0: 0: 0: 1 is st ill successful.
Take a look at Honeypot 's rout e t ables in Exam ple 3- 50 . Honeypot 's I Pv6 rout e t able shows a
st at ic rout e ent ry for FEC0: 0: 0: 8: : / 62 via t he next - hop address FEC0: : 3: 204: C1FF: FE50: F1C0.
Ex a m ple 3 - 5 0 . Th e I Pv6 r ou t e t a ble h a s n ot ch a n ge d. St a t ic r ou t e a r e
in st a lle d.
Honeypot#show ipv6 route
IPv6 Routing Table - 8 entries
L
FE80::/10 [0/0]
via ::, Null0
S
FEC0::/62 [1/0]
via ::, Serial0/0.2
C
FEC0:0:0:3::/64 [0/0]
via ::, Serial0/0.2
L
FEC0::3:230:94FF:FE24:B780/128 [0/0]
via ::, Serial0/0.2
C
FEC0:0:0:5::/64 [0/0]
via ::, Ethernet0/0
L
FEC0::5:230:94FF:FE24:B780/128 [0/0]
via ::, Ethernet0/0
S
FEC0:0:0:8::/62 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
FEC0: 0: 0: 8: : / 62 is known via FEC0: : 3: 204: C1FF: FE50: F1C0, and FEC0: 0: 0: 3: : / 64 is connect ed
t o Serial0/ 0.2. Traffic for bot h FEC0: 0: 0: 8: : / 64 and FEC0: 0: 0: A: : / 64 are forwarded out Serial
0/ 0.2 t o Honeybee.
These rout e ent ries are exact ly t he sam e as t hey were before t he rout er Honeybee was replaced.
So what 's t he problem ? Maybe Honeybee's Et hernet didn't com e up aft er t he rout er was
replaced. Exam ple 3- 51 displays t he st at e of Honeybee's Et hernet int erface.
Ex a m ple 3 - 5 1 . sh ow ipv6 in t e r fa ce e t h e r n e t 0 / 0 displa ys t h e st a t u s of
t h e in t e r fa ce a n d som e in for m a t ion a bou t t h e I Pv6 con figu r a t ion .
Honeybee#show ipv6 interface e 0/0
Ethernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::2B0:64FF:FE30:1DE0
Global unicast address(es):
FEC0::8:2B0:64FF:FE30:1DE0, subnet is FEC0:0:0:8::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF30:1DE0
The int erface is up and I Pv6 is configured on it . According t o t he docum ent at ion and diagram s
for t he net work, t his is t he int erface t o which a ping was successful before t he rout er
replacem ent , and now fails.
Look closer at t he Et hernet out put . The last 64 bit s of t he Global Unicast Address have changed.
The address is now FEC0: : 8: 2B0: 64FF: FE30: 1DE0. The I Pv6 address is an EUI - 64 address;
t herefore, t he last 64 bit s of t he address are det erm ined by t he MAC address on t he int erface.
When t he rout er was replaced, t he MAC address changed. FEC0: : 8: 204: C1FF: FE50: F1C0 no
longer exist s on t he rout er. This is why t he address is no longer pingable.
But , Honeypot 's st at ic rout e point s t o t he next - hop address FEC0: : 3: 204: c1FF: FE50: F1C0 for
t he dest inat ion FEC0: 0: 0: 8: : / 62, according t o t he rout e t able ( Exam ple 3- 50 ) , and if t he MAC
addresses have changed, t his address is no longer t he serial int erface's address. Exam ple 3- 52
displays Honeybee's new serial int erface address.
Ex a m ple 3 - 5 2 . All I Pv6 se r ia l in t e r fa ce s on a r ou t e r con figu r e d w it h
EUI - 6 4 a ddr e sse s w ill h a ve t h e sa m e fin a l 6 4 bit s, w h ich a r e de r ive d
fr om a M AC a ddr e ss on t h e r ou t e r .
Honeybee#show ipv6 interface serial0/0.1
Serial0/0.1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::2B0:64FF:FE30:1DE0
Description: Link to Piglet
Global unicast address(es):
FEC0::3:2B0:64FF:FE30:1DE0, subnet is FEC0:0:0:3::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF30:1DE0
Honeypot 's I Pv6 st at ic rout e for addresses in t he range FEC0: 0: 0: 8: : / 62 direct s t raffic t o t he
next - hop address FEC0: : 3: 204: C1FF: FE50: F1C0. The configured next - hop address is t he MAC
address of t he old rout er, yet t raffic using t his rout e ( t raffic dest ined t o FEC0: 0: 0: A: : 1) is st ill
rout ed successfully.
Even t hough a next - hop address is specified, and t he next - hop address is not valid anym ore, t he
old address and t he new address of Honeybee's serial int erface belong t o t he sam e subnet
( FEC0: 0: 0: 3: : / 64) , and as seen in Honeypot 's rout e t able, t his subnet is connect ed t o
Honeypot 's int erface Serial 0/ 0.2. Through recursive forwarding t able lookups, t he t raffic
dest ined for FEC0: 0: 0: A: : 1 is forwarded out Serial 0/ 0.2, even t hough t he specified next - hop
address does not exist .
Whenever a rout er or int erface card is replaced, rem em ber t o m odify any st at ic rout e ent ries
t hat reference an EUI - 64 I Pv6 address on t he old rout er.
Case Study: Tracing An IPv6 Failed Route
A link is added t o t he net work in Figure 3- 3 bet ween Honeypot and Honeyt ree t o have an
alt ernat ive rout e in case t he prim ary rout e becom es unavailable. Figure 3- 12 shows t he new
net work. The I Pv6 applicat ions using t he net work are not sensit ive t o delay, but t hey are
bandwidt h- int ensive, so t he net work adm inist rat or decides t o use t he new link also for load
sharing. St at ic rout es are ent ered in each rout er t o t ake advant age of t he new link.
Figu r e 3 - 1 2 . Alt e r n a t ive r ou t e a dde d t o t h e I Pv6 n e t w or k cr e a t e s a
t r ia n gle , w it h a lt e r n a t e pa t h s t o r e a ch e a ch r ou t e r .
[View full size image]
As Exam ple 3- 53 shows, rout es are added int o Honeypot t o creat e a second rout e for each of t he
rout er's exist ing rout es. Sim ilar rout es are ent ered for Honeyt ree and Honeybee in Exam ple 3- 54
and Exam ple 3- 55 .
Ex a m ple 3 - 5 3 . H on e ypot 's r ou t e r con figu r a t ion s for t h e n e w n e t w or k
in Figu r e 3 - 1 2 .
ipv6
ipv6
ipv6
ipv6
route
route
route
route
FEC0::/62 FEC0::2:2B0:64FF:FE30:1DE0
FEC0::/62 FEC0::3:204:C1FF:FE50:F1C0
FEC0:0:0:8::/62 FEC0::2:2B0:64FF:FE30:1DE0
FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0
Ex a m ple 3 - 5 4 . H on e yt r e e 's r ou t e r con figu r a t ion s for t h e n e w n e t w or k
in Figu r e 3 - 1 2 .
ipv6
ipv6
ipv6
ipv6
ipv6
ipv6
route
route
route
route
route
route
FEC0:0:0:3::/64
FEC0:0:0:3::/64
FEC0:0:0:5::/64
FEC0:0:0:5::/64
FEC0:0:0:8::/64
FEC0:0:0:8::/64
FEC0::2:230:94FF:FE24:B780
FEC0::1:204:C1FF:FE50:F1C0
FEC0::2:230:94FF:FE24:B780
FEC0::1:204:C1FF:FE50:F1C0
FEC0::1:204:C1FF:FE50:F1C0
FEC0::2:230:94FF:FE24:B780
Ex a m ple 3 - 5 5 . H on e ybe e 's r ou t e r con figu r a t ion s for t h e n e w n e t w or k
in Figu r e 3 - 1 2 .
ipv6
ipv6
ipv6
ipv6
ipv6
ipv6
route
route
route
route
route
route
FEC0:0:0:2::/64
FEC0:0:0:2::/64
FEC0:0:0:5::/64
FEC0:0:0:5::/64
FEC0:0:0:B::/64
FEC0:0:0:B::/64
FEC0::1:2B0:64FF:FE30:1DE0
FEC0::3:230:94FF:FE24:B780
FEC0::1:2B0:64FF:FE30:1DE0
FEC0::3:230:94FF:FE24:B780
FEC0::3:230:94FF:FE24:B780
FEC0::1:2B0:64FF:FE30:1DE0
I Pv6 rout ing is now int erm it t ent ly failing. Som et im es pings work, som et im es not . A look at t he
rout e t ables shows all st at ic rout es in place as designed. Pings from Honeypot t o Honeybee's
Et hernet int erface address result in success som et im es, and host unreachable at ot her t im es
( see Exam ple 3- 56 ) .
Ex a m ple 3 - 5 6 . I Pv6 pin gs a r e som e t im e s su cce ssfu l.
Honeypot#ping fec0::8:204:c1ff:fe50:f1c0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FEC0::8:204:C1FF:FE50:F1C0, timeout is 2 secon
ds:
!!HHH
Success rate is 40 percent (2/5), round-trip min/avg/max = 60/90/120 ms
Honeypot#
Debugging I Pv6 I CMP packet s on Honeypot ( see Exam ple 3- 57 ) reveal som e reply packet s
received successfully, and som e I CMP dest inat ion unreachable m essages com ing from
Honeyt ree.
Ex a m ple 3 - 5 7 . D e bu ggin g on H on e ypot sh ow s som e su cce ssfu l
pa ck e t s; ot h e r s fa il.
ICMPv6:
ICMPv6:
ICMPv6:
ICMPv6:
ICMPv6:
ICMPv6:
Sending echo request to FEC0::8:204:C1FF:FE50:F1C0
Received ICMPv6 packet from FEC0::8:204:C1FF:FE50:F1C0, type 129
Received echo reply from FEC0::8:204:C1FF:FE50:F1C0
Sending echo request to FEC0::8:204:C1FF:FE50:F1C0
Received ICMPv6 packet from FEC0::2:2B0:64FF:FE30:1DE0, type 1
Received ICMP unreachable code 3 from FEC0::2:2B0:64FF:FE30:1DE0
Debugging I CMPv6 on Honeyt ree ( see Exam ple 3- 58 ) shows t hat I Pv6 packet s are com ing in
S0/ 0.3 and S0/ 0.2.
Ex a m ple 3 - 5 8 . D e bu ggin g sh ow s pa ck e t s a r r ivin g on t w o diffe r e n t
in t e r fa ce s.
Honeytree#
IPV6: source FEC0::2:230:94FF:FE24:B780 (Serial0/0.3)
dest FEC0::8:204:C1FF:FE50:F1C0 (Serial0/0.2)
traffic class 0, flow 0x0, len 100+4, prot 58, hops 63, forwarding
IPV6: source FEC0::8:204:C1FF:FE50:F1C0 (Serial0/0.2)
dest FEC0::2:230:94FF:FE24:B780 (Serial0/0.3)
traffic class 0, flow 0x0, len 100+4, prot 58, hops 63, forwarding
IPV6: source FEC0::2:230:94FF:FE24:B780 (Serial0/0.3)
dest FEC0::8:204:C1FF:FE50:F1C0 (Serial0/0.3)
traffic class 0, flow 0x0, len 100+4, prot 58, hops 63, destination is not
connected
IPv6: SAS picked source FEC0::2:2B0:64FF:FE30:1DE0 for FEC0::2:230:94FF:FE24:B780
(Serial0/0.3)
ICMPv6: Sending ICMP unreachable code 3 to FEC0::2:230:94FF:FE24:B780 about
FEC0::8:204:C1FF:FE50:F1C0
Packet s wit h a source address fec0: : 2: 230: 94ff: fe24: b780 are arriving at Honeyt ree, int erface
S0/ 0.3 ( from Honeypot over t he link connect ing Honeypot t o Honeyt ree) . The exit int erface, for
dest inat ion fec0: : 8: 204: c1ff: fe50: f1c0, is eit her S0/ 0.2 or S0/ 0.3. Honeyt ree is perform ing perpacket load- sharing, alt ernat ing forwarding packet s bet ween S0/ 0.2 and S0/ 0.3. When t he
out going int erface t o t he dest inat ion is S0/ 0.2 and t he incom ing int erface is S0/ 0.3, t he packet
is forwarded. When I OS forwards t he packet t o S0/ 0.3, t he sam e int erface on which t he packet
arrived, pings fail, t he rout er generat es an I CMP error m essage.
A packet dest ined out t he sam e serial int erface on which it arrived indicat es a rout ing loop. Since
t he rout ers are process swit ching and t hus per packet load sharing, each rout er alt ernat es
forwarding packet s using each of it s t wo rout e ent ries. Som e packet s will t hus arrive on t he
sam e int erface t o which t he packet is dest ined.
Looking Ahead
For precise cont rol over rout ing behavior in a net work, st at ic rout ing is a powerful t ool. However,
if t opology changes are prevalent , t he dem ands of m anual reconfigurat ion m ay m ake st at ic
rout ing adm inist rat ively unfeasible. Dynam ic rout ing prot ocols enable a net work t o respond
quickly and aut om at ically t o t opology changes. Before exam ining t he det ails of specific I P rout ing
prot ocols, t he general issues surrounding all dynam ic prot ocols m ust be exam ined. The next
chapt er int roduces dynam ic rout ing prot ocols.
Summary Table: Chapter 3 Command Review
Com m a n d
D e scr ipt ion
a r p ip- address hardwareaddress
St at ically m aps an I P t ype [ alias] address t o a hardware address.
de bu g ip pa ck e t
Displays inform at ion on I P packet s received, generat ed, and
forwarded. I nform at ion on fast - swit ched packet s will not be
displayed.
de bu g ipv6 pa ck e t
Displays inform at ion on I Pv6 packet s received, generat ed, and
forwarded.
ip ce f
Enables Cisco Express Forwarding for I Pv4.
ip loa d- sh a r in g { pe r pa ck e t | pe r de st in a t ion}
Configures t he t ype of load- sharing on an out bound int erface.
ip pr ox y- a r p
Enables proxy ARP.
ip r ou t e prefix m ask
{ address | int erface [ next hop- address] } [ dist ance]
[ pe r m a n e n t ] [ n a m e
nam e] [ t a g t ag- num ber]
St at ically adds a rout e ent ry t o t he rout e t able.
ip r ou t e - ca ch e
Configures t he t ype of swit ching cache an int erface will use for
I Pv4.
ipv6 ce f
Enables Cisco Express Forwarding for I Pv6. I Pv4 CEF m ust be
enabled before I Pv6 CEF can be enabled.
ipv6 u n ica st - r ou t in g
Enables I Pv6 rout ing. I Pv6 rout ing is not enabled by default .
ipv6 r ou t e prefix/ prefix
lengt h { address | int erface
[ next - hop- address] }
[ dist ance] [ pe r m a n e n t ]
[ n a m e nam e] [ t a g t agnum ber ]
St at ically adds an I Pv6 rout e.
sh ow cdp n e igh bor
de t a il
Displays inform at ion about a neighbor rout er, including I OS
version, and I Pv4 and I Pv6 int erface configurat ion.
sh ow ip ce f
Displays CEF forwarding cache or a m essage indicat ing CEF is not
enabled.
sh ow ipv6 ce f
sh ow ipv6 ce f { int erface}
de t a il
Displays whet her CEF is enabled on an int erface, am ong ot her
t hings.
sh ow ipv6 in t e r fa ce
{ int erface}
Displays int erface and I Pv6 specific int erface inform at ion.
Com m a n d
D e scr ipt ion
sh ow ip r ou t e
Displays t he I P rout e t able.
sh ow ipv6 r ou t e
Displays t he I Pv6 rout e t able.
Review Questions
1
What inform at ion m ust be st ored in t he rout e t able?
2
What does it m ean when a rout e t able says t hat an address is variably subnet t ed?
3
What are discont iguous subnet s?
4
What I OS com m and is used t o exam ine t he I Pv4 rout e t able?
5
What I OS com m and is used t o exam ine t he I Pv6 rout e t able?
6
What are t he t wo bracket ed num bers associat ed wit h t he nondirect ly connect ed
rout es in t he rout e t able?
7
When st at ic rout es are configured t o reference an exit int erface inst ead of a next hop address, how will t he rout e t able be different ?
8
What is a sum m ary rout e? I n t he cont ext of st at ic rout ing, how are sum m ary rout es
useful?
9
What is an adm inist rat ive dist ance?
10
What is a float ing st at ic rout e?
11
What is t he difference bet ween equal- cost and unequal- cost load sharing?
12
How does t he swit ching m ode at an int erface affect load sharing?
13
What is a recursive t able lookup?
Configuration Exercises
1
Configure st at ic rout es for each rout er of t he net work shown in Figure 3- 13. Writ e
t he rout es so t hat every subnet of t he I nt ernet has an individual ent ry.
Figu r e 3 - 1 3 . Th e n e t w or k for Con figu r a t ion Ex e r cise s 1 a n d 2 .
[View full size image]
2
Rewrit e t he st at ic rout es creat ed in Configurat ion Exercise 1 t o use t he m inim um
possible rout e ent ries. [ 8] ( Hint : RTA will have only t wo st at ic rout e ent ries.)
[8]
If this exercise is being implemented in a lab, be sure to add the command ip classless to all six
routers.
3
For t he net work shown in Figure 3- 14, writ e st at ic rout es for each rout er. Assum e
t hat all links are ident ical m edia. Use load balancing on equal cost pat hs and float ing
st at ic rout es for m axim um efficiency and redundancy.
Figu r e 3 - 1 4 . Th e n e t w or k for Con figu r a t ion Ex e r cise 3 .
[View full size image]
Troubleshooting Exercises
1
I n t he net work of Figure 3- 2 and t he associat ed configurat ions, t he rout e ent ries for Piglet are
changed from
Piglet(config)# ip route 192.168.1.0 255.255.255.0 192.168.1.193
Piglet(config)# ip route 10.4.0.0 255.255.0.0 192.168.1.193
to
Piglet(config)# ip route 192.168.1.0 255.255.255.224 192.168.1.193
Piglet(config)# ip route 10.0.0.0 255.255.0.0 192.168.1.193
What is t he result ?
2
Exam ple 3- 59 shows t he st at ic rout e configurat ions for t he rout ers in Figure 3- 15 .
Figu r e 3 - 1 5 . Th e n e t w or k for Tr ou ble sh oot in g Ex e r cise 2 .
Ex a m ple 3 - 5 9 . St a t ic r ou t e con figu r a t ion s for r ou t e r s in Figu r e 3 - 1 5 .
!RTA
ip route 172.20.96.0 255.255.240.0 172.20.20.1
ip route 172.20.82.0 255.255.240.0 172.20.20.1
ip route 172.20.64.0 255.255.240.0 172.20.20.1
ip route 172.20.160.0 255.255.240.0 172.20.30.255
ip route 172.20.144.0 255.255.240.0 172.20.30.255
ip route 172.20.128.0 255.255.240.0 172.20.30.255
_________________________________________________
!RTB
ip route 172.20.192.0 255.255.240.0 172.20.16.50
ip route 172.20.224.0 255.255.240.0 172.20.16.50
ip route 172.20.128.0 255.255.240.0 172.20.16.50
ip route 172.20.160.0 255.255.240.0 172.20.30.255
ip route 172.20.144.0 255.255.240.0 172.20.30.255
ip route 172.20.128.0 255.255.240.0 172.20.30.255
_________________________________________________
!RTC
ip route 172.20.192.0 255.255.240.0 172.20.16.50
ip route 172.20.208.0 255.255.255.0 172.20.16.50
ip route 172.20.224.0 255.255.240.0 172.20.16.50
ip route 172.20.96.0 255.255.240.0 172.20.20.1
ip route 172.20.82.0 255.255.240.0 172.20.20.1
ip route 172.20.64.0 255.255.240.0 172.20.20.1
Users are com plaining of several connect ivit y problem s in t his int ernet . Find t he m ist akes in t he
st at ic rout e configurat ions.
3
Figure 3- 16 shows anot her net work in which users are com plaining of connect ivit y problem s.
Exam ple 3- 60 t hrough Exam ple 3- 63 show t he rout e t ables of t he four rout ers.
Figu r e 3 - 1 6 . Th e n e t w or k for Tr ou ble sh oot in g Ex e r cise 3 .
[View full size image]
Find t he m ist akes in t he st at ic rout e configurat ions.
Ex a m ple 3 - 6 0 . Th e r ou t e t a ble of RTA in Figu r e 3 - 1 6 .
RTA#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U per-user static route
Gateway of last resort is not set
10.0.0.0/8 is subnetted, 9 subnets
S
10.5.9.0 [1/0] via 10.5.3.2
S
10.5.8.0 [1/0] via 10.5.3.2
S
10.5.7.0 [1/0] via 10.5.3.2
S
10.5.6.0 [1/0] via 10.5.3.2
S
10.5.5.0 [1/0] via 10.5.3.2
S
10.5.4.0 [1/0] via 10.5.3.2
C
10.5.3.0 is directly connected, Serial0
C
10.5.2.0 is directly connected, TokenRing1
C
10.5.1.0 is directly connected, TokenRing0
RTA#
Ex a m ple 3 - 6 1 . Th e r ou t e t a ble of RTB in Figu r e 3 - 1 6 .
RTB#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U per-user static route
Gateway of last resort is not set
10.0.0.0/8 is subnetted, 9 subnets
S
10.5.9.0 [1/0] via 10.5.5.2
S
10.5.8.0 [1/0] via 10.5.5.2
S
10.5.7.0 [1/0] via 10.5.5.2
S
10.5.6.0 [1/0] via 10.5.5.2
C
10.5.5.0 is directly connected, Serial1
C
10.5.4.0 is directly connected, TokenRing0
C
10.5.3.0 is directly connected, Serial0
S
10.5.2.0 [1/0] via 10.5.3.1
S
10.5.1.0 [1/0] via 10.5.3.1
RTB#
Ex a m ple 3 - 6 2 . Th e r ou t e t a ble of RTC in Figu r e 3 - 1 6 .
RTC#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U per-user static route, o - ODR
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 8 subnets
S
10.5.9.0 [1/0] via 10.5.7.2
S
10.5.8.0 [1/0] via 10.5.5.1
C
10.5.7.0 is directly connected, Serial1
C
10.5.6.0 is directly connected, Ethernet0
S
10.1.1.0 [1/0] via 10.5.5.1
C
S
S
RTC#
10.5.5.0 is directly connected, Serial0
10.5.3.0 [1/0] via 10.5.5.1
10.5.2.0 [1/0] via 10.5.5.1
Ex a m ple 3 - 6 3 . Th e r ou t e t a ble of RTD in Figu r e 3 - 1 6 .
RTD#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U per-user static route, o - ODR
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 9 subnets
C
10.5.9.0 is directly connected, Ethernet1
C
10.5.8.0 is directly connected, Ethernet0
C
10.5.7.0 is directly connected, Serial0
S
10.5.6.0 [1/0] via 10.5.7.1
S
10.5.5.0 [1/0] via 10.5.7.1
S
10.4.5.0 [1/0] via 10.5.7.1
S
10.5.3.0 [1/0] via 10.5.7.1
S
10.5.2.0 [1/0] via 10.5.7.1
S
10.5.1.0 [1/0] via 10.5.7.1
RTD#
Chapter 4. Dynamic Routing Protocols
This chapt er covers t he following subj ect s:
Rout ing Prot ocol Basics
Dist ance Vect or Rout ing Prot ocols
Link St at e Rout ing Prot ocols
I nt erior and Ext erior Gat eway Prot ocols
St at ic or Dynam ic Rout ing?
The previous chapt er explains what a rout er needs t o recognize t o correct ly swit ch packet s t o
t heir respect ive dest inat ions, and how t hat inform at ion is put int o t he rout e t able m anually. This
chapt er shows how rout ers can discover t his inform at ion aut om at ically and share t hat
inform at ion wit h ot her rout ers via dynam ic rout ing prot ocols. A rout ing prot ocol is t he language
a rout er speaks wit h ot her rout ers t o share inform at ion about t he reachabilit y and st at us of
net works.
Dynam ic rout ing prot ocols not only perform t hese pat h- det erm inat ion and rout e- t able- updat e
funct ions, but also det erm ine t he next - best pat h if t he best pat h t o a dest inat ion becom es
unusable. The capabilit y t o com pensat e for t opology changes is t he m ost im port ant advant age
dynam ic rout ing offers over st at ic rout ing.
Obviously, for com m unicat ion t o occur, t he com m unicat ors m ust speak t he sam e language.
Since t he advent of I P rout ing, t here have been eight m aj or I P rout ing prot ocols from which t o
choose; [ 1] if one rout er speaks RI P and anot her speaks OSPF, t hey cannot share rout ing
inform at ion because t hey are not speaking t he sam e language. Subsequent chapt ers exam ine all
t he I P rout ing prot ocols in current use, and even consider how t o m ake a rout er " bilingual," but
first it is necessary t o explore som e charact erist ics and issues com m on t o all rout ing prot ocolsI P
or ot herwise.
[1]
Of these eight protocols, BGP has obsoleted EGP, the Cisco Systems EIGRP obsoleted its IGRP, and RIPv2 is quickly
replacing RIPv1.
Routing Protocol Basics
All dynam ic rout ing prot ocols are built around an algorit hm . Generally, an algor it hm is a st ep- byst ep procedure for solving a problem . A rout ing algorit hm m ust , at a m inim um , specify t he
following:
A procedure for passing reachabilit y inform at ion about net works t o ot her rout ers
A procedure for receiving reachabilit y inform at ion from ot her rout ers
A procedure for det erm ining opt im al rout es based on t he reachabilit y inform at ion it has and
for recording t his inform at ion in a rout e t able
A procedure for react ing t o, com pensat ing for, and advert ising t opology changes in a
net work
A few issues com m on t o any rout ing prot ocol are pat h det erm inat ion, m et rics, convergence, and
load balancing.
Path Determination
All subnet s wit hin a net work m ust be connect ed t o a rout er, and wherever a rout er has an
int erface on a net work, t hat int erface m ust have an address on t he net work. [ 2] This address is
t he originat ing point for reachabilit y inform at ion.
[2]
Many point-to-point links are configured as "unnumbered" linksthat is, there is no address assigned to the connected
point-to-point interfaceso as to conserve addresses. But unnumbered links do not violate the rule that every interface must
have an address; they use another address on the router, usually the loopback address, as a proxy address.
Figure 4- 1 shows a sim ple t hree- rout er net work. Rout er A recognizes net works 192.168.1.0,
192.168.2.0, and 192.168.3.0 because it has int erfaces on t hose net works wit h corresponding
addresses and appropriat e address m asks. Likewise, Rout er B recognizes 192.168.3.0,
192.168.4.0, 192.168.5.0, and 192.186.6.0; Rout er C recognizes 192.168.6.0, 192.168.7.0, and
198.168.1.0. Each int erface im plem ent s t he dat a link and physical prot ocols of t he net work t o
which it is at t ached, so t he rout er also recognizes t he st at e of t he net work ( up or down) .
Figu r e 4 - 1 . Ea ch r ou t e r k n ow s a bou t it s dir e ct ly con n e ct e d n e t w or k s
fr om it s a ssign e d a ddr e sse s a n d m a sk s.
At first glance, t he inform at ion- sharing procedure seem s sim ple. Look at Rout er A:
1 . Rout er A exam ines it s I P addresses and associat ed m asks and deduces t hat it is at t ached
t o net works 192.168.1.0, 192.186.2.0, and 192.168.3.0.
2 . Rout er A ent ers t hese net works int o it s rout e t able, along wit h som e sort of flag indicat ing
t hat t he net works are direct ly connect ed.
3 . Rout er A places t he inform at ion int o a packet : " My direct ly connect ed net works are
192.168.1.0, 192.186.2.0, and 192.168.3.0."
4 . Rout er A t ransm it s copies of t hese rout e inform at ion packet s, or rout ing updat es, t o
Rout ers B and C.
Rout ers B and C, having perform ed t he sam e st eps, have sent updat es wit h t heir direct ly
connect ed net works t o A. Rout er A ent ers t he received inform at ion int o it s rout e t able, along
wit h t he source address of t he rout er t hat sent t he updat e packet . Rout er A now recognizes all
t he net works and t he addresses of t he rout ers t o which t hey are at t ached.
This procedure does seem quit e sim ple. So why are rout ing prot ocols so m uch m ore com plicat ed
t han t his? Look again at Figure 4- 1 :
What should Rout er A do wit h t he updat es from B and C aft er it has recorded t he
inform at ion in t he rout e t able? Should it , for inst ance, pass B's rout ing inform at ion packet
t o C and pass C's packet t o B?
I f Rout er A does not forward t he updat es, inform at ion sharing m ight not be com plet e. For
inst ance, if t he link bet ween B and C does not exist , t hose t wo rout ers would not recognize
each ot her's net works. Rout er A m ust forward t he updat e inform at ion, but t his st ep opens
a new set of problem s.
I f Rout er A hears about net work 192.168.4.0 from bot h Rout er B and Rout er C, which
rout er should be used t o reach t hat net work? Are t hey bot h valid? Which one is t he best
pat h?
What m echanism will be used t o ensure t hat all rout ers receive all rout ing inform at ion while
prevent ing updat e packet s from circulat ing endlessly t hrough t he net work?
The rout ers share cert ain direct ly connect ed net works ( 192.168.1.0, 192.168.3.0, and
192.168.6.0) . Should t he rout ers st ill advert ise t hese net works?
These quest ions are alm ost as sim plist ic as t he preceding prelim inary explanat ion of rout ing
prot ocols, but t hey should give you an indicat ion for som e of t he issues t hat cont ribut e t o t he
com plexit y of t he prot ocols. Each rout ing prot ocol addresses t hese quest ions one way or
anot her, which will becom e clear in following sect ions and chapt ers.
Metrics
When t here are m ult iple rout es t o t he sam e dest inat ion, a rout er m ust have a m echanism for
calculat ing t he best pat h. A m et r ic is a variable assigned t o rout es as a m eans of ranking t hem
from best t o worst or from m ost preferred t o least preferred. Consider t he following exam ple of
why m et rics are needed.
Assum ing t hat inform at ion sharing has properly occurred in t he net work of Figure 4- 1 , Rout er A
m ight have a rout e t able t hat looks like Table 4- 1.
Ta ble 4 - 1 . Ru dim e n t a r y
r ou t e t a ble for Rou t e r A
of Figu r e 4 - 1 .
N e t w or k
N e x t - H op
Rou t e r
192.168.1.0
Direct ly
connect ed
192.168.2.0
Direct ly
connect ed
192.168.3.0
Direct ly
connect ed
192.168.4.0
B, C
192.168.5.0
B, C
192.168.6.0
B, C
192.168.7.0
B, C
This rout e t able says t hat t he first t hree net works are direct ly connect ed and t hat no rout ing is
needed from Rout er A t o reach t hem , which is correct . The last four net works, according t o t his
t able, can be reached via Rout er B or Rout er C. This inform at ion is also correct . But if net work
192.168.7.0 can be reached via eit her Rout er B or Rout er C, which pat h is t he preferable pat h?
Met rics are needed t o rank t he alt ernat ives.
Different rout ing prot ocols use different m et rics. For exam ple, RI P defines t he " best " rout e as
t he one wit h t he least num ber of rout er hops; EI GRP defines t he " best " rout e based on a
com binat ion of t he lowest bandwidt h along t he rout e and t he t ot al delay of t he rout e. The
following sect ions provide basic definit ions of t hese and ot her com m only used m et rics. Furt her
com plexit iessuch as how som e rout ing prot ocols such as EI GRP use m ult iple param et ers t o
com put e a m et ric and deal wit h rout es t hat have ident ical m et ric valuesare covered lat er, in t he
prot ocol- specific chapt ers of t his book.
Hop Count
A hop- count m et ric sim ply count s rout er hops. For inst ance, from Rout er A, it is one hop t o
net work 192.168.5.0 if packet s are sent out int erface 192.168.3.1 ( t hrough Rout er B) and t wo
hops if packet s are sent out 192.168.1.1 ( t hrough Rout ers C and B) . Assum ing hop count is t he
only m et ric being applied, t he best rout e is t he one wit h t he fewest hops, in t his case, A- B.
But is t he A- B link really t he best pat h? I f t he A- B link is a DS- 0 link and t he A- C and C- B links
are T- 1 links, t he t wo- hop rout e m ight act ually be best , because bandwidt h plays a role in how
efficient ly t raffic t ravels t hrough t he net work.
Bandwidth
A bandwidt h m et ric would choose a higher- bandwidt h pat h over a lower- bandwidt h link.
However, bandwidt h by it self st ill m ight not be a good m et ric. What if one or bot h of t he T1 links
are heavily loaded wit h ot her t raffic and t he 56K link is light ly loaded? Or what if t he higherbandwidt h link also has a higher delay?
Load
This m et ric reflect s t he am ount of t raffic ut ilizing t he links along t he pat h. The best pat h is t he
one wit h t he lowest load.
Unlike hop count and bandwidt h, t he load on a rout e changes, and, t herefore, t he m et ric will
change. Care m ust be t aken here. I f t he m et ric changes t oo frequent ly, rout e flappingt he
frequent change of preferred rout esm ight occur. Rout e flaps can have adverse effect s on t he
rout er's CPU, t he bandwidt h of t he dat a links, and t he overall st abilit y of t he net work.
Delay
Delay is a m easure of t he t im e a packet t akes t o t raverse a rout e. A rout ing prot ocol using delay
as a m et ric would choose t he pat h wit h t he least delay as t he best pat h. There m ight be m any
ways t o m easure delay. Delay m ight t ake int o account not only t he delay of t he links along t he
rout e, but also such fact ors as rout er lat ency and queuing delay. On t he ot her hand, t he delay of
a rout e m ight not be m easured at all; it m ight be a sum of st at ic quant it ies defined for each
int erface along t he pat h. Each individual delay quant it y would be an est im at e based on t he t ype
of link t o which t he int erface is connect ed.
Reliability
Reliabilit y m easures t he likelihood t hat t he link will fail in som e way and can be eit her variable or
fixed. Exam ples of variable- reliabilit y m et rics are t he num ber of t im es a link has failed, or t he
num ber of errors it has received wit hin a cert ain t im e period. Fixed- reliabilit y m et rics are based
on known qualit ies of a link as det erm ined by t he net work adm inist rat or. The pat h wit h highest
reliabilit y would be select ed as best .
Cost
This m et ric is configured by a net work adm inist rat or t o reflect m ore- or less- preferred rout es.
Cost m ight be defined by any policy or link charact erist ic or m ight reflect t he arbit rary j udgm ent
of t he net work adm inist rat or. Therefore, " cost " is a t erm of convenience describing a
dim ensionless m et ric.
The t erm cost is oft en used as a generic t erm when speaking of rout e choices. For exam ple, " RI P
chooses t he lowest - cost pat h based on hop count ." Anot her generic t erm is short est, as in " RI P
chooses t he short est pat h based on hop count ." When used in t his cont ext , eit her lowest - cost ( or
highest - cost) and short est ( or longest) m erely refer t o a rout ing prot ocol's view of pat hs based
on it s specific m et rics.
Convergence
A dynam ic rout ing prot ocol m ust include a set of procedures for a rout er t o inform ot her rout ers
about it s direct ly connect ed net works, t o receive and process t he sam e inform at ion from ot her
rout ers, and t o pass along t he inform at ion it receives from ot her rout ers. Furt her, a rout ing
prot ocol m ust define a m et ric by which best pat hs m ight be det erm ined.
A furt her crit erion for rout ing prot ocols is t hat t he reachabilit y inform at ion in t he rout e t ables of
all rout ers in t he net work m ust be consist ent . I f Rout er A in Figure 4- 1 det erm ines t hat t he best
pat h t o net work 192.168.5.0 is via Rout er C and if Rout er C det erm ines t hat t he best pat h t o t he
sam e net work is t hrough Rout er A, Rout er A will send packet s dest ined for 192.168.5.0 t o C, C
will send t hem back t o A, A will again send t hem t o C, and so on. This cont inuous circling of
t raffic bet ween t wo or m ore dest inat ions is referred t o as a rout ing loop.
The process of bringing all rout e t ables t o a st at e of consist ency is called conver gence. The t im e
it t akes t o share inform at ion across a net work and for all rout ers t o calculat e best pat hs is t he
convergence t im e.
Figure 4- 2 shows a net work t hat was converged, but now a t opology change has occurred. The
link bet ween t he t wo left - m ost rout ers has failed; bot h rout ers, being direct ly connect ed, know
about t he failure from t he dat a link prot ocol and proceed t o inform t heir neighbors of t he
unavailable link. The neighbors updat e t heir rout e t ables accordingly and inform t heir neighbors,
and t he process cont inues unt il all rout ers know about t he change.
Figu r e 4 - 2 . Re con ve r ge n ce a ft e r a t opology ch a n ge t a k e s t im e . W h ile
t h e n e t w or k is in a n u n con ve r ge d st a t e , r ou t e r s a r e su sce pt ible t o ba d
r ou t in g in for m a t ion .
Not ice t hat at t im e t 2 t he t hree left - m ost rout ers recognize t he t opology change but t he t hree
right - m ost rout ers have not yet received t hat inform at ion. Those t hree have old inform at ion and
will cont inue t o swit ch packet s accordingly. I t is during t his int erm ediat e t im e, when t he net work
is in an unconverged st at e, t hat rout ing errors m ight occur. Therefore, convergence t im e is an
im port ant fact or in any rout ing prot ocol. The fast er a net work can reconverge aft er a t opology
change, t he bet t er.
Load Balancing
Recall from Chapt er 3, " St at ic Rout ing," t hat load balancing is t he pract ice of dist ribut ing t raffic
am ong m ult iple pat hs t o t he sam e dest inat ion, so as t o use bandwidt h efficient ly. As an exam ple
of t he usefulness of load balancing, consider Figure 4- 1 again. All t he net works in Figure 4- 1 are
reachable from t wo pat hs. I f a device on 192.168.2.0 sends a st ream of packet s t o a device on
Distance Vector Routing Protocols
Most rout ing prot ocols fall int o one of t wo classes: dist ance vect or or link st at e. The basics of
dist ance vect or rout ing prot ocols are exam ined here; t he next sect ion covers link st at e rout ing
prot ocols. Most dist ance vect or algorit hm s are based on t he work done of R. E. Bellm an, [ 3] L. R.
Ford, and D. R. Fulkerson, [ 4] and for t his reason occasionally are referred t o as Bellm an- Ford or
Ford- Fulkerson algorit hm s. A not able except ion is EI GRP, which is based on an algorit hm
developed by J. J. Garcia Luna Aceves.
[3]
R. E. Bellman. Dynamic Programming. Princeton, New Jersey: Princeton University Press; 1957.
[4]
L. R. Ford Jr. and D. R. Fulkerson. Flows in Networks. Princeton, New Jersey: Princeton University Press; 1962.
The nam e dist ance vect or is derived from t he fact t hat rout es are advert ised as vect ors of
( dist ance, direct ion) , where dist ance is defined in t erm s of a m et ric and direct ion is defined in
t erm s of t he next - hop rout er. For exam ple, " Dest inat ion A is a dist ance of five hops away, in t he
direct ion of next - hop Rout er X." As t hat st at em ent im plies, each rout er learns rout es from it s
neighboring rout ers' perspect ives and t hen advert ises t he rout es from it s own perspect ive.
Because each rout er depends on it s neighbors for inform at ion, which t he neighbors in t urn m ight
have learned from t heir neighbors, and so on, dist ance vect or rout ing is som et im es facet iously
referred t o as " rout ing by rum or."
Dist ance vect or rout ing prot ocols include t he following:
Rout ing I nform at ion Prot ocol ( RI P) for I P
Xerox Net working Syst em 's XNS RI P
Novell's I PX RI P
The Cisco Syst em s I nt ernet Gat eway Rout ing Prot ocol ( I GRP) and Enhanced I nt ernet
Gat eway Rout ing Prot ocol ( EI GRP)
DEC's DNA Phase I V
AppleTalk's Rout ing Table Maint enance Prot ocol ( RTMP)
Common Characteristics
A t ypical dist ance vect or rout ing prot ocol uses a rout ing algorit hm in which rout ers periodically
send rout ing updat es t o all neighbors by broadcast ing t heir ent ire rout e t ables. [ 5]
[5]
A notable exception to this convention is the Cisco Enhanced IGRP. EIGRP is a distance vector protocol, but its updates
are not periodic, are not broadcasted, and do not contain the full route table. EIGRP is covered in Chapter 7, "Enhanced
Interior Gateway Routing Protocol (EIGRP)."
The preceding st at em ent cont ains a lot of inform at ion. Following sect ions consider it in m ore
det ail.
Periodic Updates
Periodic updat es m eans t hat at t he end of a cert ain t im e period, updat es will be t ransm it t ed.
This period t ypically ranges from 10 seconds for AppleTalk's RTMP t o 90 seconds for t he Cisco
I GRP. At issue here is t he fact t hat if updat es are sent t oo frequent ly, congest ion and rout er CPU
overloading m ight occur; if updat es are sent t oo infrequent ly, convergence t im e m ight be
unaccept ably high.
Neighbors
I n t he cont ext of rout ers, neighbors m eans rout ers sharing a com m on dat a link or som e higherlevel logical adj acency. A dist ance vect or rout ing prot ocol sends it s updat es t o neighboring
rout ers [ 6] and depends on t hem t o pass t he updat e inform at ion along t o t heir neighbors. For t his
reason, dist ance vect or rout ing is said t o use hop- by- hop updat es.
[6]
This statement is not entirely true. Hosts also can listen to routing updates in some implementations; but all that is
important for this discussion is how routers work.
Broadcast Updates
When a rout er first becom es act ive on a net work, how does it find ot her rout ers and how does it
announce it s own presence? Several m et hods are available. The sim plest is t o send t he updat es
t o t he broadcast address ( in t he case of I P, 255.255.255.255) . Neighboring rout ers speaking t he
sam e rout ing prot ocol will hear t he broadcast s and t ake appropriat e act ion. Host s and ot her
devices unint erest ed in t he rout ing updat es will sim ply drop t he packet s.
Full Routing Table Updates
Most dist ance vect or rout ing prot ocols t ake t he very sim ple approach of t elling t heir neighbors
everyt hing t hey know by broadcast ing t heir ent ire rout e t able, wit h som e except ions t hat are
covered in following sect ions. Neighbors receiving t hese updat es glean t he inform at ion t hey need
and discard everyt hing else.
Routing by Rumor
Figure 4- 3 shows a dist ance vect or algorit hm in act ion. I n t his exam ple, t he m et ric is hop count .
At t im e t 0 , Rout ers A t hrough D have j ust becom e act ive. Looking at t he rout e t ables across t he
t op row, at t 0 t he only inform at ion any of t he four rout ers has is it s own direct ly connect ed
net works. The t ables ident ify t hese net works and indicat e t hat t hey are direct ly connect ed by
having no next - hop rout er and by having a hop count of 0. Each of t he four rout ers will
broadcast t his inform at ion on all links.
Figu r e 4 - 3 . D ist a n ce ve ct or pr ot ocols con ve r ge h op- by- h op.
[View full size image]
At t im e t 1 , t he first updat es have been received and processed by t he rout ers. Look at Rout er A's
t able at t 1 . Rout er B's updat e t o Rout er A said t hat Rout er B can reach net works 10.1.2.0 and
10.1.3.0, bot h zero hops away. I f t he net works are zero hops from B, t hey m ust be one hop
from A. Rout er A increm ent ed t he hop count by one and t hen exam ined it s rout e t able. I t
already recognized 10.1.2.0, and t he hop count ( zero) was less t han t he hop count B advert ised,
( one) , so A disregarded t hat inform at ion.
Net work 10.1.3.0 was new inform at ion, however, so A ent ered t his in t he rout e t able. The
source address of t he updat e packet was Rout er B's int erface ( 10.1.2.2) so t hat inform at ion is
ent ered along wit h t he calculat ed hop count .
Not ice t hat t he ot her rout ers perform ed sim ilar operat ions at t he sam e t im e t 1 . Rout er C, for
inst ance, disregarded t he inform at ion about 10.1.3.0 from B and 10.1.4.0 from C but ent ered
inform at ion about 10.1.2.0, reachable via B's int erface address 10.1.3.1, and 10.1.5.0,
reachable via C's int erface 10.1.4.2. Bot h net works were calculat ed as one hop away.
At t im e t 2 , t he updat e period has again expired and anot her set of updat es has been broadcast .
Rout er B sent it s lat est t able; Rout er A again increm ent ed B's advert ised hop count s by one and
com pared. The inform at ion about 10.1.2.0 is again discarded for t he sam e reason as before.
10.1.3.0 is already known, and t he hop count hasn't changed, so t hat inform at ion is also
discarded. 10.1.4.0 is new inform at ion and is ent ered int o t he rout e t able.
The net work is converged at t im e t 3 . Every rout er recognizes every net work, t he address of t he
next - hop rout er for every net work, and t he dist ance in hops t o every net work.
I t is t im e for an analogy. You are wandering in t he Sangre de Crist o m ount ains of nort hern New
Mexicoa wonderful place t o wander if you aren't lost . But you are lost . You com e upon a fork in
t he t rail and a sign point ing west , reading " Taos, 15 m iles." You have no choice but t o t rust t he
sign. You have no clue what t he t errain is like over t hat 15 m iles; you don't know whet her t here
is a bet t er rout e or even whet her t he sign is correct . Som eone could have t urned it around, in
which case you will t ravel deeper int o t he forest inst ead of t o safet y!
Dist ance vect or algorit hm s provide road signs t o net works. [ 7] They provide t he direct ion and t he
dist ance, but no det ails about what lies along t he rout e. And like t he sign at t he fork in t he t rail,
t hey are vulnerable t o accident al or int ent ional m isdirect ion. Following are som e of t he
difficult ies and refinem ent s associat ed wit h dist ance vect or algorit hm s.
[7]
The road sign analogy is commonly used. You can find a good presentation in Radia Perlman's Interconnections, pp.
205210.
Route Invalidation Timers
Now t hat t he net work in Figure 4- 3 is fully converged, how will it handle reconvergence when
som e part of t he t opology changes? I f net work 10.1.5.0 goes down, t he answer is sim ple
enoughRout er D, in it s next scheduled updat e, flags t he net work as unreachable and passes t he
inform at ion along.
But what if, inst ead of 10.1.5.0 going down, Rout er D fails? Rout ers A, B, and C st ill have ent ries
in t heir rout e t ables about 10.1.5.0; t he inform at ion is no longer valid, but t here's no rout er t o
inform t hem of t his fact . They will unknowingly forward packet s t o an unreachable dest inat iona
black hole has opened in t he net work.
This problem is handled by set t ing a rout e invalidat ion t im er for each ent ry in t he rout e t able.
For exam ple, when Rout er C first hears about 10.1.5.0 and ent ers t he inform at ion int o it s rout e
t able, C set s a t im er for t hat rout e. At every regularly scheduled updat e from Rout er D, C
discards t he updat e's already- known inform at ion about 10.1.5.0 as described in "Rout ing by
Rum or." But as C does so, it reset s t he t im er on t hat rout e.
I f Rout er D goes down, C will no longer hear updat es about 10.1.5.0. The t im er will expire, C will
flag t he rout e as unreachable and will pass t he inform at ion along in t he next updat e.
Typical periods for rout e t im eout s range from t hree t o six updat e periods. A rout er would not
want t o invalidat e a rout e aft er a single updat e has been m issed, because t his event m ight be
t he result of a corrupt ed or lost packet or som e sort of net work delay. At t he sam e t im e, if t he
period is t oo long, reconvergence will be excessively slow.
Split Horizon
According t o t he dist ance vect or algorit hm as it has been described so far, at every updat e
period each rout er broadcast s it s ent ire rout e t able t o every neighbor. But is t his really
necessary? Every net work known by Rout er A in Figure 4- 3 , wit h a hop count higher t han zero,
has been learned from Rout er B. Com m on sense suggest s t hat for Rout er A t o broadcast t he
net works it has learned from Rout er B back t o Rout er B is a wast e of resources. Obviously, B
already " knows" about t hose net works.
A rout e point ing back t o t he rout er from which packet s were received is called a reverse rout e.
Split horizon is a t echnique for prevent ing reverse rout es bet ween t wo rout ers.
Besides not wast ing resources, t here is a m ore im port ant reason for not sending reachabilit y
inform at ion back t o t he rout er from which t he inform at ion was learned. The m ost im port ant
funct ion of a dynam ic rout ing prot ocol is t o det ect and com pensat e for t opology changesif t he
best pat h t o a net work becom es unreachable, t he prot ocol m ust look for a next - best pat h.
Look yet again at t he converged net work of Figure 4- 3 and suppose t hat net work 10.1.5.0 goes
down. Rout er D will det ect t he failure, flag t he net work as unreachable, and pass t he inform at ion
along t o Rout er C at t he next updat e int erval. However, before D's updat e t im er t riggers an
updat e, som et hing unexpect ed happens. C's updat e arrives, claim ing t hat it can reach 10.1.5.0,
one hop away! Rem em ber t he road sign analogy? Rout er D has no way of recognizing t hat C is
not advert ising a legit im at e next - best pat h. I t will increm ent t he hop count and m ake an ent ry
int o it s rout e t able indicat ing t hat 10.1.5.0 is reachable via Rout er C's int erface 10.1.4.1, j ust
t wo hops away.
Now a packet wit h a dest inat ion address of 10.1.5.3 arrives at Rout er C, which consult s it s rout e
t able and forwards t he packet t o D. Rout er D consult s it s rout e t able and forwards t he packet t o
C, C forwards it back t o D, ad infinit um . A rout ing loop has occurred.
I m plem ent ing split horizon prevent s t he possibilit y of such a rout ing loop. There are t wo
cat egories of split horizon: sim ple split horizon and split horizon wit h poisoned reverse.
The rule for sim ple split horizon is, when sending updat es out a part icular int erface, do not
include net works t hat were learned from updat es received on t hat int erface.
The rout ers in Figure 4- 4 im plem ent sim ple split horizon. Rout er C sends an updat e t o Rout er D
for net works 10.1.1.0, 10.1.2.0, and 10.1.3.0. Net works 10.1.4.0 and 10.1.5.0 are not included
because t hey were learned from Rout er D. Likewise, updat es t o Rout er B include 10.1.4.0 and
10.1.5.0 wit h no m ent ion of 10.1.1.0, 10.1.2.0, and 10.1.3.0.
Figu r e 4 - 4 . Sim ple split h or izon doe s n ot a dve r t ise r ou t e s ba ck t o t h e
n e igh bor s fr om w h om t h e r ou t e s w e r e le a r n e d.
[View full size image]
Sim ple split horizon works by suppressing inform at ion. Split horizon wit h poisoned reverse is a
m odificat ion t hat provides m ore posit ive inform at ion.
The rule for split horizon wit h poisoned reverse is, when sending updat es out a part icular
int erface, designat e any net works t hat were learned from updat es received on t hat int erface as
unreachable.
I n t he scenario of Figure 4- 4 , Rout er C would in fact advert ise 10.1.4.0 and 10.1.5.0 t o Rout er
D, but t he net work would be m arked as unreachable. Figure 4- 5 shows what t he rout e t ables
from C t o B and D would look like. Not ice t hat a rout e is m arked as unreachable by set t ing t he
m et ric t o infinit y; in ot her words, t he net work is an infinit e dist ance away. Coverage of a rout ing
prot ocol's concept of infinit y cont inues in t he next sect ion.
Figu r e 4 - 5 . Split h or izon w it h poison e d r e ve r se a dve r t ise s r e ve r se
r ou t e s bu t w it h a n u n r e a ch a ble ( in fin it e ) m e t r ic.
[View full size image]
Split horizon wit h poisoned reverse is considered safer and st ronger t han sim ple split horizona
sort of " bad news is bet t er t han no news at all" approach. For exam ple, suppose t hat Rout er B in
Figure 4- 5 receives corrupt ed inform at ion, causing it t o proceed as if subnet 10.1.1.0 is
reachable via Rout er C. Sim ple split horizon would do not hing t o correct t his m ispercept ion,
whereas a poisoned reverse updat e from Rout er C would im m ediat ely st op t he pot ent ial loop.
For t his reason, m ost m odern dist ance vect or im plem ent at ions use split horizon wit h poisoned
reverse. The t rade- off is t hat rout ing updat e packet s are larger, which m ight exacerbat e any
congest ion problem s on a link.
Counting to Infinity
Split horizon will break loops bet ween neighbors, but it will not st op loops in a net work such as
t he one in Figure 4- 6 . Again, 10.1.5.0 has failed. Rout er D sends t he appropriat e updat es t o it s
neighbors, Rout er C ( t he dashed arrows) , and Rout er B ( t he solid arrows) . Rout er B m arks t he
rout e via D as unreachable, but Rout er A is advert ising a next - best pat h t o 10.1.5.0, which is
t hree hops away. B post s t hat rout e in it s rout e t able.
Figu r e 4 - 6 . Split h or izon w ill n ot pr e ve n t r ou t in g loops h e r e .
B now inform s D t hat it has an alt ernat ive rout e t o 10.1.5.0. D post s t his inform at ion and
updat es C, saying t hat it has a four- hop rout e t o t he net work. C t ells A t hat 10.1.5.0 is five hops
away. A t ells B t hat t he net work is now six hops away.
" Ah," Rout er B t hinks, " Rout er A's pat h t o 10.1.5.0 has increased in lengt h. Nonet heless, it 's t he
only rout e I 've got , so I 'll use it ! "
B changes t he hop count t o seven, updat es D, and around it goes again. This sit uat ion is t he
count ing- t o- infinit y problem because t he hop count t o 10.1.5.0 will cont inue t o increase t o
infinit y. All rout ers are im plem ent ing split horizon, but it doesn't help.
The way t o alleviat e t he effect s of count ing t o infinit y is t o define infinit y. Most dist ance vect or
prot ocols define infinit y t o be 16 hops. As t he updat es cont inue t o loop am ong t he rout ers in
Figure 4- 6 , t he hop count t o 10.1.5.0 in all rout ers will event ually increm ent t o 16. At t hat t im e,
t he net work will be considered unreachable.
This m et hod is also how rout ers advert ise a net work as unreachable. Whet her it is a poisoned
reverse rout e, a net work t hat has failed, or a net work beyond t he m axim um net work diam et er of
15 hops, a rout er will recognize any 16- hop rout e as unreachable.
Set t ing a m axim um hop count of 15 helps solve t he count ing- t o- infinit y problem , but
convergence will st ill be very slow. Given an updat e period of 30 seconds, a net work could t ake
up t o 7.5 m inut es t o reconverge and is suscept ible t o rout ing errors during t his t im e. Triggered
updat es can be used t o reduce t his convergence t im e.
Triggered Updates
Triggered updat es, also known as flash updat es, are very sim ple: I f a m et ric changes for bet t er
or for worse, a rout er will im m ediat ely send out an updat e wit hout wait ing for it s updat e t im er t o
expire. Reconvergence will occur far m ore quickly t han if every rout er had t o wait for regularly
scheduled updat es, and t he problem of count ing t o infinit y is great ly reduced, alt hough not
com plet ely elim inat ed. Regular updat es m ight st ill occur along wit h t riggered updat es. Thus a
rout er m ight receive bad inform at ion about a rout e from a not - yet - reconverged rout er aft er
having received correct inform at ion from a t riggered updat e. Such a sit uat ion shows t hat
confusion and rout ing errors m ight st ill occur while a net work is reconverging, but t riggered
updat es will help t o iron t hings out m ore quickly.
A furt her refinem ent is t o include in t he updat e only t he net works t hat act ually t riggered it ,
rat her t han t he ent ire rout e t able. This t echnique reduces t he processing t im e and t he im pact on
net work bandwidt h.
Holddown Timers
Triggered updat es add responsiveness t o a reconverging net work. Holddown t im ers int roduce a
cert ain am ount of skept icism t o reduce t he accept ance of bad rout ing inform at ion.
I f t he dist ance t o a dest inat ion increases ( for exam ple, t he hop count increases from t wo t o
four) , t he rout er set s a holddown t im er for t hat rout e. Unt il t he t im er expires, t he rout er will not
accept any new updat es for t he rout e.
Obviously, a t rade- off is involved here. The likelihood of bad rout ing inform at ion get t ing int o a
t able is reduced but at t he expense of t he reconvergence t im e. Like ot her t im ers, holddown
t im ers m ust be set wit h care. I f t he holddown period is t oo short , it will be ineffect ive, and if it is
t oo long, norm al rout ing will be adversely affect ed.
Asynchronous Updates
Figure 4- 7 shows a group of rout ers connect ed t o an Et hernet backbone. The rout ers should not
broadcast t heir updat es at t he sam e t im e; if t hey do, t he updat e packet s will collide. Yet t his
sit uat ion is exact ly what can happen when several rout ers share a broadcast net work. Syst em
delays relat ed t o t he processing of updat es in t he rout ers t end t o cause t he updat e t im ers t o
becom e synchronized. As a few rout ers becom e synchronized, collisions will begin t o occur,
furt her cont ribut ing t o syst em delays, and event ually all rout ers sharing t he broadcast net work
m ight becom e synchronized.
Figu r e 4 - 7 . I f u pda t e t im e r s be com e syn ch r on ize d, collision s m igh t
occu r .
Asynchronous updat es m ight be m aint ained by one of t wo m et hods:
Each rout er's updat e t im er is independent of t he rout ing process and is, t herefore, not
affect ed by processing loads on t he rout er.
A sm all random t im e, or t im ing j it t er, is added t o each updat e period as an offset .
I f rout ers im plem ent t he m et hod of rigid, syst em - independent t im ers, all rout ers sharing a
broadcast net work m ust be brought online in a random fashion. Reboot ing t he ent ire group of
rout ers sim ult aneouslysuch as m ight happen during a widespread power out age, for
exam plecould result in all t he t im ers at t em pt ing t o updat e at t he sam e t im e.
Adding random ness t o t he updat e period is effect ive if t he variable is large enough in proport ion
t o t he num ber of rout ers sharing t he broadcast net work. Sally Floyd and Van Jacobson[ 8] have
calculat ed t hat a t oo- sm all random izat ion will be overcom e by a large enough net work of
rout ers, and t hat t o be effect ive t he updat e t im er should range up t o 50 percent of t he m edian
updat e period.
[8]
S. Floyd and V. Jacobson. "The Synchronisation of Periodic Routing Messages." ACM Sigcomm '93 Symposium,
September 1993.
Link State Routing Protocols
The inform at ion available t o a dist ance vect or rout er has been com pared t o t he inform at ion
available from a road sign. Link st at e rout ing prot ocols are like a road m ap. A link st at e rout er
cannot be fooled as easily int o m aking bad rout ing decisions, because it has a com plet e pict ure
of t he net work. The reason is t hat unlike t he rout ing- by- rum or approach of dist ance vect or, link
st at e rout ers have first hand inform at ion from all t heir peer [ 9] rout ers. Each rout er originat es
inform at ion about it self, it s direct ly connect ed links, t he st at e of t hose links ( hence t he nam e) ,
and any direct ly connect ed neighbors. This inform at ion is passed around from rout er t o rout er,
each rout er m aking a copy of it , but never changing it . The ult im at e obj ect ive is t hat every
rout er has ident ical inform at ion about t he net work, and each rout er will independent ly calculat e
it s own best pat hs.
[9]
That is, all routers speaking the same routing protocol.
Link st at e prot ocols, som et im es called short est pat h first or dist ribut ed dat abase prot ocols, are
built around a well- known algorit hm from graph t heory, E. W. Dij kst ra's short est pat h algorit hm .
Exam ples of link st at e rout ing prot ocols are
Open Short est Pat h First ( OSPF) for I P
The I SO's I nt erm ediat e Syst em - t o- I nt erm ediat e Syst em ( I S- I S) for CLNS and I P
DEC's DNA Phase V
Novell's Net Ware Link Services Prot ocol ( NLSP)
Alt hough link- st at e prot ocols are right ly considered m ore com plex t han dist ance vect or
prot ocols, t he basic funct ionalit y is not com plex at all:
1 . Each rout er est ablishes a relat ionshipan adj acencywit h each of it s neighbors.
2 . Each rout er sends a dat a unit we will call link st at e advert isem ent s ( LSAs) t o each
neighbor. [ 10] The LSA list s each of t he rout er's links, and for each link, it ident ifies t he link,
t he st at e of t he link, t he m et ric cost of t he rout er's int erface t o t he link, and any neighbors
t hat m ight be connect ed t o t he link. Each neighbor receiving an advert isem ent in t urn
forwards (floods) t he advert isem ent t o it s own neighbors.
[ 10] LSA is an OSPF t erm . The corresponding dat a unit creat ed by I S- I S is called link st at e PDU ( LSP) .
But for t his general discussion, " LSA" fit s our needs.
3 . Each rout er st ores a copy of all t he LSAs it has seen in a dat abase. I f all works well, t he
dat abases in all rout ers should be ident ical.
4 . The com plet ed t opological dat abase, also called t he link st at e dat abase, is used by t he
Dij kst ra algorit hm t o com put e a graph of t he net work indicat ing t he short est pat h t o each
rout er. The link st at e prot ocol can t hen consult t he link st at e dat abase t o find what subnet s
are at t ached t o each rout er, and ent er t his inform at ion int o t he rout ing t able.
Neighbors
Neighbor discovery is t he first st ep in get t ing a link st at e environm ent up and running. I n
keeping wit h t he friendly neighbor t erm inology, a Hello prot ocol is used for t his st ep. The
prot ocol will define a Hello packet form at and a procedure for exchanging t he packet s and
processing t he inform at ion t he packet s cont ain.
At a m inim um , t he Hello packet will cont ain a rout er I D ( RI D) and t he address of t he net work on
which t he packet is being sent . The rout er I D is som et hing by which t he rout er originat ing t he
packet can be uniquely dist inguished from all ot her rout ers; for inst ance, an I P address from one
of t he rout er's int erfaces. Ot her fields of t he packet m ight carry a subnet m ask, Hello int ervals, a
specified m axim um period t he rout er will wait t o hear a Hello before declaring t he neighbor
" dead," a descript or of t he circuit t ype, and flags t o help in bringing up adj acencies.
When t wo rout ers have discovered each ot her as neighbors, t hey go t hrough a process of
synchronizing t heir dat abases in which t hey exchange and verify dat abase inform at ion unt il t heir
dat abases are ident ical. The det ails of dat abase synchronizat ion are described in Chapt ers 8,
" OSPFv2," and 10 , " I nt egrat ed I S- I S." To perform t his dat abase synchronizat ion, t he neighbors
m ust be adj acent t hat is, t hey m ust agree on cert ain prot ocol- specific param et ers such as t im ers
and support of opt ional capabilit ies. By using Hello packet s t o build adj acencies, link st at e
prot ocols can exchange inform at ion in a cont rolled fashion. Cont rast t his approach wit h dist ance
vect or, which sim ply broadcast s updat es out any int erface configured for t hat rout ing prot ocol.
Beyond building adj acencies, Hello packet s serve as keepalives t o m onit or t he adj acency. I f
Hellos are not heard from an adj acent neighbor wit hin a cert ain est ablished t im e, t he neighbor is
considered unreachable and t he adj acency is broken. A t ypical int erval for t he exchange of Hello
packet s is t en seconds, and a t ypical dead period is four t im es t hat .
Link State Flooding
Aft er t he adj acencies are est ablished, t he rout ers m ight begin sending out LSAs. As t he t erm
flooding im plies, t he advert isem ent s are sent t o every neighbor. I n t urn, each received LSA is
copied and forwarded t o every neighbor except t he one t hat sent t he LSA. This process is t he
source of one of link st at e's advant ages over dist ance vect or. LSAs are forwarded alm ost
im m ediat ely, whereas dist ance vect or prot ocols based on t he Bellm an- Ford algorit hm m ust run
it s algorit hm and updat e it s rout e t able before rout ing updat es, even t he t riggered ones, can be
forwarded. As a result , link st at e prot ocols converge m uch fast er t han dist ance vect or prot ocols
converge when t he t opology changes.
The flooding process is t he m ost com plex piece of a link st at e prot ocol. There are several ways
t o m ake flooding m ore efficient and m ore reliable, such as using unicast and m ult icast
addresses, checksum s, and posit ive acknowledgm ent s. These t opics are exam ined in t he
prot ocol- specific chapt ers, but t wo procedures are vit ally im port ant t o t he flooding process:
sequencing and aging.
Sequence Numbers
A difficult y wit h flooding, as described so far, is t hat when all rout ers have received all LSAs, t he
flooding m ust st op. A t im e- t o- live value in t he packet s could sim ply be relied on t o expire, but it
is hardly efficient t o perm it LSAs t o wander t he net work unt il t hey expire. Take t he net work in
Figure 4- 8 . Subnet 172.22.4.0 at Rout er A has failed, and A has flooded an LSA t o it s neighbors
B and D, advert ising t he new st at e of t he link. B and D dut ifully flood t o t heir neighbors, and so
on.
Figu r e 4 - 8 . W h e n a t opology ch a n ge occu r s, LSAs a dve r t isin g t h e
ch a n ge w ill be floode d t h r ou gh ou t t h e n e t w or k .
Look next at what happens at Rout er C. An LSA arrives from Rout er B at t im e t 1 , is ent ered int o
C's t opological dat abase, and is forwarded t o Rout er F. At som e lat er t im e t 3 , anot her copy of
t he sam e LSA arrives from t he longer A- D- E- F- C rout e. Rout er C sees t hat it already has t he LSA
in it s dat abase; t he quest ion is, should C forward t his LSA t o Rout er B? The answer is no
because B has already received t he advert isem ent . Rout er C knows t his because t he sequence
num ber of t he LSA it received from Rout er F is t he sam e as t he sequence num ber of t he LSA it
received earlier from Rout er B.
When Rout er A sent out t he LSA, it included an ident ical sequence num ber in each copy. This
sequence num ber is recorded in t he rout ers' t opological dat abases along wit h t he rest of t he
LSA; when a rout er receives an LSA t hat is already in t he dat abase and it s sequence num ber is
t he sam e, t he received inform at ion is discarded. I f t he inform at ion is t he sam e but t he sequence
num ber is great er, t he received inform at ion and new sequence num ber are ent ered int o t he
dat abase and t he LSA is flooded. I n t his way, flooding is abat ed when all rout ers have seen a
copy of t he m ost recent LSA.
As described so far, it seem s t hat rout ers could m erely verify t hat t heir link st at e dat abases
cont ain t he sam e LSA as t he newly received LSA and m ake a flood/ discard decision based on
t hat inform at ion, wit hout needing a sequence num ber. But im agine t hat im m ediat ely aft er Figure
4 - 8's net work 172.22.4.0 failed, it cam e back up. Rout er A m ight send out an LSA advert ising
t he net work as down, wit h a sequence num ber of 166; t hen it sends out a new LSA announcing
t he sam e net work as up, wit h a sequence num ber of 167. Rout er C receives t he down LSA and
t hen t he up LSA from t he A- B- C pat h, but t hen it receives a delayed down LSA from t he A- D- EF- C pat h. Wit hout t he sequence num bers, C would not know whet her or not t o believe t he
delayed down LSA. Wit h sequence num bers, C's dat abase will indicat e t hat t he inform at ion from
Rout er A has a sequence num ber of 167; t he lat e LSA has a sequence num ber of 166 and is
t herefore recognized as old inform at ion and discarded.
Because t he sequence num bers are carried in a set field wit hin t he LSAs, t he num bers m ust
have som e upper boundary. What happens when t his m axim um sequence num ber is reached?
Linear Sequence Number Spaces
One approach is t o use a linear sequence num ber space so large t hat it is unlikely t he upper lim it
will ever be reached. I f, for inst ance, a 32- bit field is used, t here are 2 32 = 4,294,967,296
available sequence num bers st art ing wit h zero. Even if a rout er was creat ing a new link st at e
packet every 10 seconds, it would t ake 1361 years t o exhaust t he sequence num ber supply; few
rout ers are expect ed t o last so long.
I n t his im perfect world, unfort unat ely, m alfunct ions occur. I f a link st at e rout ing process
som ehow runs out of sequence num bers, it m ust shut it self down and st ay down long enough for
it s LSAs t o age out of all dat abases before st art ing over at t he lowest sequence num ber ( see t he
sect ion " Aging," lat er in t his chapt er) .
A m ore com m on difficult y present s it self during rout er rest art s. I f Rout er A rest art s, it probably
will have no way of rem em bering t he sequence num ber it last used and m ust begin again at ,
say, one. But if it s neighbors st ill have Rout er A's previous sequence num bers in t heir dat abases,
t he lower sequence num bers will be int erpret ed as older sequence num bers and will be ignored.
Again, t he rout ing process m ust st ay down unt il all old LSAs are aged out of t he net work. Given
t hat a m axim um age m ight be an hour or m ore, t his solut ion is not very at t ract ive.
A bet t er solut ion is t o add a new rule t o t he flooding behavior described t hus far: I f a rest art ed
rout er issues t o a neighbor an LSA wit h a sequence num ber t hat appears t o be older t han t he
neighbor's st ored sequence num ber, t he neighbor will send it s own st ored LSA and sequence
num ber back t o t he rout er. The rout er will t hus learn t he sequence num ber it was using before it
rest art ed and can adj ust accordingly.
Care m ust be t aken, however, t hat t he last - used sequence num ber was not close t o t he
m axim um ; ot herwise, t he rest art ing rout er will sim ply have t o rest art again. A rule m ust be set
lim it ing t he " j um p" t he rout er m ight m ake in sequence num bersfor inst ance, a rule m ight say
t hat t he sequence num bers cannot m ake a single increase m ore t han one- half t he t ot al
sequence num ber space. ( The act ual form ulas are m ore com plex t han t his exam ple, t aking int o
account age const raint s.)
I S- I S uses a 32- bit linear sequence num ber space.
Circular Sequence Number Spaces
Anot her approach is t o use a circular sequence num ber space, where t he num bers " wrap" t hat is,
in a 32- bit space, t he num ber following 4,294,967,295 is 0. Malfunct ions can cause int erest ing
dilem m as here, t oo. A rest art ing rout er m ight encount er t he sam e believabilit y problem as
discussed for linear sequence num bers.
Circular sequence num bering creat es a curious bit of illogic. I f x is any num ber bet ween 1 and
4,294,967,295 inclusive, t hen 0 < x < 0. This sit uat ion can be m anaged in well- behaved
net works by assert ing t wo rules for det erm ining when a sequence num ber is great er t han or less
t han anot her sequence num ber. Given a sequence num ber space n and t wo sequence num bers a
and b, a is considered m ore recent ( of larger m agnit ude) in eit her of t he following sit uat ions:
a > b, and ( a b)
n/ 2
a < b, and ( b a) > n/ 2
For t he sake of sim plicit y, t ake a sequence num ber space of six bit s, shown in Figure 4- 9 :
n = 2 6 = 64
so n/ 2 = 32.
Figu r e 4 - 9 . Six - Bit Cir cu la r Addr e ss Spa ce
Given t wo sequence num bers 48 and 18, 48 is m ore recent because by rule ( 1)
48 > 18 and ( 48 18) = 30 and 30 < 32.
Given t wo sequence num bers 3 and 48, 3 is m ore recent because by rule ( 2)
3 < 48 and ( 48 3) = 45 and 45 > 32.
Given t wo sequence num bers 3 and 18, 18 is m ore recent because by rule ( 1)
18 > 3 and ( 18 3) = 15 and 15 < 32.
So t he rules seem t o enforce circularit y.
But what about a not - so- well- behaved net work? I m agine a net work running a six- bit sequence
num ber space. Now im agine t hat one of t he rout ers on t he net work m alfunct ions, but as it does
so, it blurt s out t hree ident ical LSAs wit h a sequence num ber of 44 ( 101100) . Unfort unat ely, a
neighboring rout er is also m alfunct ioningit is dropping bit s. The neighbor drops a bit in t he
sequence num ber field of t he second LSA, drops yet anot her bit in t he t hird LSA, and floods all
t hree. The result is t hree ident ical LSAs wit h t hree different sequence num bers:
44 ( 101100)
40 ( 101000)
8
( 001000)
Applying t he circularit y rules reveals t hat 44 is m ore recent t han 40, which is m ore recent t han
8, which is m ore recent t han 44! The result is t hat every LSA will be cont inuously flooded, and
dat abases will be cont inually overwrit t en wit h t he " lat est " LSA, unt il finally buffers becom e
clogged wit h LSAs, CPUs becom e overloaded, and t he ent ire net work com es crashing down.
This chain of event s sounds quit e far- fet ched. I t is, however, fact ual. The ARPANET, t he
precursor of t he m odern I nt ernet , ran an early link st at e prot ocol wit h a six- bit circular sequence
num ber space; on Oct ober 27, 1980, t wo rout ers experiencing t he m alfunct ions j ust described
brought t he ent ire ARPANET t o a st andst ill. [ 11]
[11]
E. C. Rosen. "Vulnerabilities of Network Control Protocols: An Example." Computer Communication Review, July 1981.
Lollipop-Shaped Sequence Number Spaces
This whim sically- nam ed const ruct was proposed by Dr. Radia Perlm an. [ 12] Lollipop- shaped
sequence num ber spaces are a hybrid of linear and circular sequence num ber spaces; if you
t hink about it , a lollipop has a linear com ponent and a circular com ponent . The problem wit h
circular spaces is t hat t here is no num ber less t han all ot her num bers. The problem wit h linear
spaces is t hat t hey arewellnot circular. That is, t heir set of sequence num bers is finit e.
[12]
R. Perlman. "Fault-Tolerant Broadcasting of Routing Information." Computer Networks, Vol. 7, December 1983, pp.
395405.
When Rout er A rest art s, it would be nice t o begin wit h a num ber a t hat is less t han all ot her
num bers. Neighbors will recognize t his num ber for what it is, and if t hey have a pre- rest art
num ber b in t heir dat abases from Rout er A, t hey can send t hat num ber t o Rout er A and Rout er A
will j um p t o t hat sequence num ber. Rout er A m ight be able t o send m ore t han one LSA before
hearing about t he sequence num ber it had been using before rest art ing. Therefore, it is
im port ant t o have enough rest art num bers so t hat A cannot use t hem all before neighbors eit her
inform it of a previously used num ber, or t he previously used num ber ages out of all dat abases.
These linear rest art num bers form t he st ick of t he lollipop. When t hey have been used up, or
aft er a neighbor has provided a sequence num ber t o which A can j um p, A ent ers a circular
num ber space, t he candy part of t he lollipop.
One way of designing a lollipop address space is t o use signed sequence num bers, where k < 0 <
k. The negat ive num bers count ing up from k t o 1 form t he st ick, and t he posit ive num bers from
0 t o k are t he circular space. Perlm an's rules for t he sequence num bers are as follows. Given t wo
num bers a and b and a sequence num ber space n, b is m ore recent t han a if and only if
a < 0 and a < b, or
a > 0, a < b, and ( b a) < n/ 2, or
a > 0, b > 0, a > b, and ( a b) > n/ 2
Figure 4- 10 shows an im plem ent at ion of t he lollipop- shaped sequence num ber space. A 32- bit
signed num ber space N is used, yielding 2 31 posit ive num bers and 2 31 negat ive num bers. N
( 2 31 , or 0x80000000) and N 1 ( 2 31 1, or 0x7FFFFFFF) are not used. A rout er com ing online will
begin it s sequence num bers at N + 1 ( 0x80000001) and increm ent up t o zero, at which t im e it
has ent ered t he circular num ber space. When t he sequence reaches N 2 ( 0x7FFFFFFE) , t he
sequence wraps back t o zero ( again, N 1 is unused) .
Figu r e 4 - 1 0 . Lollipop- sh a pe d se qu e n ce n u m be r spa ce .
Next , suppose t he rout er rest art s. The sequence num ber of t he last LSA sent before t he rest art
is 0x00005de3 ( part of t he circular sequence space) . As it synchronizes it s dat abase wit h it s
neighbor aft er t he rest art , t he rout er sends an LSA wit h a sequence num ber of 0x80000001 ( N +
1) . The neighbor looks int o it s own dat abase and finds t he pre- rest art LSA wit h a sequence
num ber of 0x00005de3. The neighbor sends t his LSA t o t he rest art ed rout er, essent ially saying,
" This is where you left off." The rest art ed rout er t hen records t he LSA wit h t he posit ive sequence
num ber. I f it needs t o send a new copy of t he LSA at som e fut ure t im e, t he new sequence
num ber will be 0x00005de6.
Lollipop sequence spaces were used wit h t he original version of OSPF, OSPFv1 ( RFC 1131) .
Alt hough t he use of signed num bers was an im provem ent over t he linear num ber space, t he
circular part was found t o be vulnerable t o t he sam e am biguit ies as a purely circular space. The
deploym ent of OSPFv1 never progressed beyond t he experim ent al st age. The current version of
OSPF, OSPFv2 ( originally specified in RFC 1247) , adopt s t he best feat ures of linear and lollipop
sequence num ber spaces. I t uses a signed num ber space like lollipop sequence num bers,
beginning wit h 0x80000001. However, when t he sequence num ber goes posit ive, t he sequence
space cont inues t o be linear unt il it reaches t he m axim um of 0x7FFFFFFF. At t hat point , t he
OSPF process m ust flush t he LSA from all link st at e dat abases before rest art ing.
Aging
The LSA form at should include a field for t he age of t he advert isem ent . When an LSA is creat ed,
t he rout er set s t his field t o one. As t he packet is flooded, each rout er increm ent s t he age of t he
advert isem ent . [ 13]
[13]
Of course, another option would be to start with some maximum age and decrement. OSPF increments; IS-IS
decrements.
This process of aging adds anot her layer of reliabilit y t o t he flooding process. The prot ocol
defines a m axim um age difference ( MaxAgeDiff) value for t he net work. A rout er m ight receive
m ult iple copies of t he sam e LSA wit h ident ical sequence num bers but different ages. I f t he
difference in t he ages is lower t han t he MaxAgeDiff, it is assum ed t hat t he age difference was
t he result of norm al net work lat encies; t he original LSA in t he dat abase is ret ained, and t he
newer LSA ( wit h t he great er age) is not flooded. I f t he difference is great er t han t he MaxAgeDiff
value, it is assum ed t hat an anom aly has occurred in t he net work in which a new LSA was sent
wit hout increm ent ing t he sequence num ber. I n t his case, t he newer LSA will be recorded, and
t he packet will be flooded. A t ypical MaxAgeDiff value is 15 m inut es ( used by OSPF) .
The age of an LSA cont inues t o be increm ent ed as it resides in a link st at e dat abase. I f t he age
for a link st at e record is increm ent ed up t o som e m axim um age ( MaxAge) again defined by t he
specific rout ing prot ocolt he LSA, wit h age field set t o t he MaxAge value, is flooded t o all
neighbors and t he record is delet ed from t he dat abases.
I f t he LSA is t o be flushed from all dat abases when MaxAge is reached, t here m ust be a
m echanism t o periodically validat e t he LSA and reset it s t im er before MaxAge is reached. A link
st at e refresh t im e ( LSRefreshTim e) [ 14] is est ablished; when t his t im e expires, a rout er floods a
new LSA t o all it s neighbors, who will reset t he age of t he sending rout er's records t o t he new
received age. OSPF defines a MaxAge of 1 hour and an LSRefreshTim e of 30 m inut es.
[14]
LSRefreshTime, MaxAge, and MaxAgeDiff are OSPF architectural constants.
Link State Database
I n addit ion t o flooding LSAs and discovering neighbors, a t hird m aj or t ask of t he link st at e
rout ing prot ocol is est ablishing t he link st at e dat abase. The link st at e or t opological dat abase
st ores t he LSAs as a series of records. Alt hough a sequence num ber and age and possibly ot her
inform at ion are included in t he LSA, t hese variables exist m ainly t o m anage t he flooding process.
The im port ant inform at ion for t he short est pat h det erm inat ion process is t he advert ising rout er's
I D, it s at t ached net works and neighboring rout ers, and t he cost associat ed wit h t hose net works
or neighbors. As t he previous sent ence im plies, LSAs m ight include t wo t ypes of generic
inform at ion: [ 15]
[15]
Actually, there can be more than two types of information and multiple types of link state packets. They are covered in
the chapters on specific link state protocols.
Rout er link inform at ion advert ises a rout er's adj acent neighbors wit h a t riple of ( Rout er I D,
Neighbor I D, Cost ) , where cost is t he cost of t he link t o t he neighbor.
St ub net work inform at ion advert ises a rout er's direct ly connect ed st ub subnet s ( subnet s
wit h no neighbors) wit h a t riple of ( Rout er I D, Net work I D, Cost ) .
The short est pat h first ( SPF) algorit hm is run once for t he rout er link inform at ion t o est ablish
short est pat hs t o each rout er, and t hen st ub net work inform at ion is used t o add t hese net works
t o t he rout ers. Figure 4- 11 shows a net work of rout ers and t he links bet ween t hem ; st ub
net works are not shown for t he sake of sim plicit y. Not ice t hat several links have different cost s
associat ed wit h t hem at each end. A cost is associat ed wit h t he out going direct ion of an
int erface. For inst ance, t he link from RB t o RC has a cost of 1, but t he sam e link has a cost of 5
in t he RC t o RB direct ion.
Figu r e 4 - 1 1 . Lin k cost s a r e ca lcu la t e d for t h e ou t goin g dir e ct ion fr om
a n in t e r fa ce a n d do n ot n e ce ssa r ily h a ve t o be t h e sa m e a t a ll
in t e r fa ce s on a lin k .
Table 4- 2 shows a generic link st at e dat abase for t he net work of Figure 4- 11, a copy of which is
st ored in every rout er. As you read t hrough t his dat abase, you will see t hat it com plet ely
describes t he net work. Now it is possible t o com put e a t ree t hat describes t he short est pat h t o
each rout er by running t he SPF algorit hm .
Ta ble 4 - 2 . Topologica l
da t a ba se for t h e
n e t w or k in Figu r e 4 11.
Rou t e r
ID
N e igh bor
Cost
RA
RB
2
RA
RD
4
RA
RE
4
RB
RA
2
Rou t e r
ID
N e igh bor
Cost
RB
RC
1
RB
RE
10
RC
RB
5
RC
RF
2
RD
RA
4
RD
RE
3
RD
RG
5
RE
RA
5
RE
RB
2
RE
RD
3
RE
RF
2
RE
RG
1
RE
RH
8
RF
RC
2
RF
RE
2
RF
RH
4
RG
RD
5
RG
RE
1
RH
RE
8
RH
RF
6
SPF Algorithm
I t is unfort unat e t hat Dij kst ra's algorit hm is so com m only referred t o in t he rout ing world as t he
short est pat h first algorit hm . Aft er all, t he obj ect ive of every rout ing prot ocol is t o calculat e
short est pat hs. I t is also unfort unat e t hat Dij kst ra's algorit hm is oft en m ade t o appear m ore
esot eric t han it really is; m any writ ers j ust can't resist put t ing it in set t heory not at ion. The
clearest descript ion of t he algorit hm com es from E. W. Dij kst ra's original paper. Here it is in his
own words, followed by a " t ranslat ion" for t he link st at e rout ing prot ocol:
Const ruct [ a] t ree of m inim um t ot al lengt h bet ween t he n nodes. ( The t ree is a graph wit h one
and only one pat h bet ween every t wo nodes.)
I n t he course of t he const ruct ion t hat we present here, t he branches are divided int o t hree set s:
I.
I . t he branches definit ely assigned t o t he t ree under const ruct ion ( t hey will be in a subt ree) ;
I I . t he branches from which t he next branch t o be added t o set I , will be select ed;
I I I . t he rem aining branches ( rej ect ed or not considered) .
The nodes are divided int o t wo set s:
A. t he nodes connect ed by t he branches of set I ,
B. t he rem aining nodes ( one and only one branch of set I I will lead t o each of t hese nodes) .
We st art t he const ruct ion by choosing an arbit rary node as t he only m em ber of set A, and by
placing all branches t hat end in t his node in set I I . To st art wit h, set I is em pt y. From t hen
onwards we perform t he following t wo st eps repeat edly.
St e p 1 .
The short est branch of set I I is rem oved from t his set and added t o set I . As a result ,
one node is t ransferred from set B t o set A.
St e p 2 .
Consider t he branches leading from t he node, which has j ust been t ransferred t o set
A, t o t he nodes t hat are st ill in set B. I f t he branch under const ruct ion is longer t han
t he corresponding branch in set I I , it is rej ect ed; if it is short er, it replaces t he
corresponding branch in set I I , and t he lat t er is rej ect ed.
We t hen ret urn t o st ep 1 and repeat t he process unt il set s I I and B are em pt y. The branches in
set I form t he t ree required. [ 16]
[16]
E. W. Dijkstra. "A Note on Two Problems in Connexion with Graphs." Numerische Mathematik, Vol. 1, 1959, pp. 269271.
Adapt ing t he algorit hm for rout ers, first not e t hat Dij kst ra describes t hree set s of branches: I , I I ,
and I I I . I n t he rout er, t hree dat abases represent t he t hree set s:
The Tree Dat abase This dat abase represent s set I . Links ( branches) are added t o t he
short est pat h t ree by adding t hem here. When t he algorit hm is finished, t his dat abase will
describe t he short est pat h t ree.
The Candidat e Dat abase This dat abase corresponds t o set I I . Links are copied from t he link
st at e dat abase t o t his list in a prescribed order, where t hey becom e candidat es t o be added
t o t he t ree.
The Link St at e Dat abase The reposit ory of all links, as has been previously described. This
t opological dat abase corresponds t o set I I I .
Dij kst ra also specifies t wo set s of nodes, set A and set B. Here t he nodes are rout ers.
Specifically, t hey are t he rout ers represent ed by Neighbor I D in t he Rout er Links t riples ( Rout er
I D, Neighbor I D, Cost ) . Set A com prises t he rout ers connect ed by t he links in t he Tree dat abase.
Set B is all ot her rout ers. Since t he whole point is t o find a short est pat h t o every rout er, set B
should be em pt y when t he algorit hm is finished.
Here's a version of Dij kst ra's algorit hm adapt ed for rout ers:
1 . A rout er init ializes t he Tree dat abase by adding it self as t he root . This ent ry shows t he
1.
rout er as it s own neighbor, wit h a cost of 0.
2 . All t riples in t he link st at e dat abase describing links t o t he root rout er's neighbors are
added t o t he Candidat e dat abase.
3 . The cost from t he root t o each link in t he Candidat e dat abase is calculat ed. The link in t he
Candidat e dat abase wit h t he lowest cost is m oved t o t he Tree dat abase. I f t wo or m ore
links are an equally low cost from t he root , choose one.
4 . The Neighbor I D of t he link j ust added t o t he Tree dat abase is exam ined. Wit h t he
except ion of any t riple whose Neighbor I D is already in t he Tree dat abase, t riples in t he link
st at e dat abase describing t hat rout er's neighbors are added t o t he Candidat e dat abase.
5 . I f ent ries rem ain in t he Candidat e dat abase, ret urn t o st ep 3. I f t he Candidat e dat abase is
em pt y, t erm inat e t he algorit hm . At t erm inat ion, a single Neighbor I D ent ry in t he Tree
dat abase should represent every rout er, and t he short est pat h t ree is com plet e.
Table 4- 3 sum m arizes t he process and result s of applying Dij kst ra's algorit hm t o build a short est
pat h t ree for t he net work in Figure 4- 11. Rout er RA from Figure 4- 11 is running t he algorit hm ,
using t he link st at e dat abase of Table 4- 2. Figure 4- 12 shows t he short est pat h t ree const ruct ed
for Rout er RA by t his algorit hm . Aft er each rout er calculat es it s own t ree, it can exam ine t he
ot her rout ers' net work link inform at ion and add t he st ub net works t o t he t ree fairly easily. From
t his inform at ion, ent ries m ight be m ade int o t he rout ing t able.
Ta ble 4 - 3 . D ij k st r a 's Algor it h m Applie d t o t h e D a t a ba se of Ta ble 4 - 2
Ca n dida t e
Cost t o Root
RA,RB,2
2
RA,RD,4
4
RA,RE,4
4
RA,RD,4
4
RA,RE,4
4
RB,RC,1
3
RB,RE,10
12
RA,RD,4
4
RA,RE,4
4
RC,RF,2
5
RA,RE,4
4
RC,RF,2
5
RD,RE,3
7
Tr e e
D e scr ipt ion
RA,RA,0
Rout er A adds it self t o t he t ree as root .
RA,RA,0
The links t o all of RA's neighbors are
added t o t he candidat e list .
RA,RA,0
RA,RB,2
( RA,RB,2) is t he lowest - cost link on t he
candidat e list , so it is added t o t he t ree.
All of RB's neighbors except t hose already
in t he t ree are added t o t he candidat e list .
( RA,RE,4) is a lower- cost link t o RE t han
( RB,RE,10) , so t he lat t er is dropped from
t he candidat e list .
RA,RA,0
RA,RB,2
RB,RC,1
( RB,RC,1) is t he lowest - cost link on t he
candidat e list , so it is added t o t he t ree.
All of RC's neighbors except t hose already
on t he t ree becom e candidat es.
RA,RA,0
RA,RB,2
RB,RC,1
RA,RD,4
( RA,RD,4) and ( RA,RE,4) are bot h a cost
of 4 from RA; ( RC,RF,2) is a cost of 5.
( RA,RD,4) is added t o t he t ree and it s
neighbors becom e candidat es. Two pat hs
t o RE are on t he candidat e list ;
Ca n dida t e
Cost t o Root
Tr e e
D
scrare
ipt ion
t oeRE
on t he candidat e list ;
( RD,RE,3) is a higher cost from RA and is
dr opped.
RD,RG,5
9
RC,RF,2
5
RA,RA,0
RA,RB,2
RB,RC,1
RA,RD,4
RA,RE,4
( RF,RE,1) is added t o t he t ree. All of RE's
neighbors not already on t he t ree are
added t o t he candidat e list . The highercost link t o RG is dropped.
RD,RG,5
9
RE,RF,2
6
RE,RG,1
5
RE,RH,8
12
RE,RF,2
6
RA,RA,0
RE,RG,1
5
RA,RB,2
RE,RH,8
12
RB,RC,1
RF,RH,4
9
RA,RD,4
( RC,RF,2) is added t o t he t ree, and it s
neighbors are added t o t he candidat e list .
( RE,RG,1) could have been select ed
inst ead because it has t he sam e cost ( 5)
from RA. The higher- cost pat h t o RH is
dr opped.
RA,RE,4
RC,RF,2
RF,RH,4
9
RA,RA,0
RA,RB,2
RB,RC,1
RA,RD,4
RA,RE,4
RC,RF,2
RE,RG,1
( RE,RG,1) is added t o t he t ree. RG has no
neighbors t hat are not already on t he
t ree, so not hing is added t o t he candidat e
list .
RA,RA,0
RA,RB,2
RB,RC,1
RA,RD,4
RA,RE,4
RC,RF,2
RE,RG,1
RF,RH,4
( RF,RH,4) is t he lowest - cost link on t he
candidat e list , so it is added t o t he t ree.
No candidat es rem ain on t he list , so t he
algorit hm is t erm inat ed. The short est
pat h t ree is com plet e.
Figu r e 4 - 1 2 . Sh or t e st pa t h t r e e de r ive d by t h e a lgor it h m in Ta ble 4 - 3 .
Areas
An area is a subset of t he rout ers t hat m ake up a net work. Dividing a net work int o areas is a
response t o t hree concerns com m only expressed about link st at e prot ocols:
The necessary dat abases require m ore m em ory t han a dist ance vect or prot ocol requires.
The com plex algorit hm requires m ore CPU t im e t han a dist ance vect or prot ocol requires.
The flooding of link st at e packet s adversely affect s available bandwidt h, part icularly in
unst able net works.
Modern link st at e prot ocols and t he rout ers t hat run t hem are designed t o reduce t hese effect s,
but cannot elim inat e t hem . The last sect ion exam ined what t he link st at e dat abase m ight look
like, and how an SPF algorit hm m ight work, for a sm all eight - rout er net work. Rem em ber t hat t he
st ub net works t hat would be connect ed t o t hose eight rout ers and t hat would form t he leaves of
t he SPF t ree were not t aken int o considerat ion. Now, im agine an 8000- rout er net work, and you
can underst and t he concern about t he im pact on m em ory, CPU, and bandwidt h.
This im pact can be great ly reduced by t he use of areas, as in Figure 4- 13. When a net work is
subdivided int o areas, t he rout ers wit hin an area need t o flood LSAs only wit hin t hat area and
t herefore need t o m aint ain a link st at e dat abase only for t hat area. The sm aller dat abase m eans
less required m em ory in each rout er and fewer CPU cycles t o run t he SPF algorit hm on t hat
dat abase. I f frequent t opology changes occur, t he result ing flooding will be confined t o t he area
of t he inst abilit y.
Figu r e 4 - 1 3 . Use of a r e a s r e du ce s lin k st a t e 's de m a n d for syst e m
r e sou r ce s.
The rout ers connect ing t wo areas ( Area Border Rout ers, in OSPF t erm inology) belong t o bot h
areas and m ust m aint ain separat e t opological dat abases for each. Just as a host on one net work
t hat want s t o send a packet t o anot her net work only needs t o know how t o find it s local rout er, a
rout er in one area t hat want s t o send a packet t o anot her area only needs t o know how t o find
it s local Area Border Rout er. I n ot her words, t he int ra- area rout er/ int er- area rout er relat ionship
is t he sam e as t he host / rout er relat ionship but at a higher hierarchical level.
Dist ance vect or prot ocols, such as RI P and I GRP, do not use areas. Given t hat t hese prot ocols
have no recourse but t o see a large net work as a single ent it y, m ust calculat e a rout e t o every
net work, and m ust broadcast t he result ing huge rout e t able every 30 or 90 seconds, it becom es
clear t hat link st at e prot ocols ut ilizing areas can conserve syst em resources.
Interior and Exterior Gateway Protocols
Areas int roduce a hierarchy t o t he net work archit ect ure. Anot her layer is added t o t his
hierarchical st ruct ure by grouping areas int o larger areas. These higher- level areas are called
aut onom ous syst em s in t he I P world and rout ing dom ains in t he I SO world.
An aut onom ous syst em was once defined as a group of rout ers under a com m on adm inist rat ive
dom ain running a com m on rout ing prot ocol. Given t he fluidit y of m odern net working life, t he
lat t er part of t he definit ion is no longer very accurat e. Depart m ent s, divisions, and even ent ire
com panies frequent ly m erge, and net works t hat were designed wit h different rout ing prot ocols
m erge along wit h t hem . The result is t hat m any net works nowadays com bine m ult iple rout ing
prot ocols wit h m ult iple degrees of inelegance, all under com m on adm inist rat ions. So a
cont em porary definit ion of an aut onom ous syst em is a net work under a com m on adm inist rat ion.
The rout ing prot ocols t hat run wit hin an aut onom ous syst em are referred t o as I nt erior Gat eway
Pr ot ocols ( I GP) . All t he prot ocols given in t his chapt er as exam ples of dist ance vect or or link
st at e prot ocols are I GPs.
Rout ing prot ocols t hat rout e bet ween aut onom ous syst em s or rout ing dom ains are referred t o as
Ext erior Gat eway Prot ocols ( EGP) . Whereas I GPs discover pat hs bet ween net works, EGPs
discover pat hs bet ween aut onom ous syst em s. Exam ples of EGPs include t he following:
Border Gat eway Prot ocol ( BGP) for I P
Ext erior Gat eway Prot ocol ( EGP) for I P ( yes, an EGP nam ed EGP)
The I SO's I nt erDom ain Rout ing Prot ocol ( I DRP)
Novell also incorporat es an EGP funct ionalit y, called Level 3 Rout ing, int o NLSP.
Having given t hese definit ions, it m ust be said t hat t he com m on usage of t he t erm aut onom ous
syst em is not so absolut e. Various st andards docum ent s, lit erat ure, and people t end t o give
various m eanings t o t he t erm . As a result , it is im port ant t o underst and t he cont ext in which one
is reading or hearing t he t erm .
This book uses aut onom ous syst em in one of t wo cont ext s:
Aut onom ous syst em m ight refer t o a rout ing dom ain, as defined at t he beginning of t his
sect ion. I n t his cont ext , an aut onom ous syst em is a syst em of one or m ore I GPs t hat is
aut onom ous from ot her syst em s of I GPs. An EGP is used t o rout e bet ween t hese
aut onom ous syst em s.
Aut onom ous syst em m ight also refer t o a process dom ain, or a single I GP process t hat is
aut onom ous from ot her I GP processes. For exam ple, a syst em of OSPF- speaking rout ers
m ight be referred t o as an OSPF aut onom ous syst em . EI GRP also uses aut onom ous syst em
in t his cont ext . Redist ribut ion is used t o rout e bet ween t hese aut onom ous syst em s.
The cont ext will indicat e which form of aut onom ous syst em is under discussion at different
point s t hroughout t his book.
Static or Dynamic Routing?
When reading ( or being lect ured about ) all t he glorious det ails of dynam ic rout ing prot ocols, it 's
hard not t o com e away wit h t he im pression t hat dynam ic rout ing is always bet t er t han st at ic
rout ing. I t 's im port ant t o keep in m ind t hat t he prim ary dut y of a dynam ic rout ing prot ocol is t o
aut om at ically det ect and adapt t o t opological changes in t he net work. The price of t his
" aut om at ion" is paid in bandwidt h and m aybe queue space, in m em ory, and in processing t im e.
Anot her price of dynam ic rout ing is a reduced cont rol of rout ing choices. The rout ing prot ocol
decides what t he best pat h is t o a given dest inat ion, you don't . I f precise cont rol of pat h
select ion is im port ant , part icularly when t he pat h you want is different from t he pat h a rout ing
prot ocol would choose, st at ic rout ing is a bet t er choice.
A frequent obj ect ion t o st at ic rout ing is t hat it is hard t o adm inist er. This crit icism m ight be t rue
of m edium t o large t opologies wit h m any alt ernat ive rout es, but it is cert ainly not t rue of sm all
net works wit h few or no alt ernat ive rout es.
The net work in Figure 4- 14 has a hub- and- spoke t opology popular in sm aller net works. I f a
spoke t o any rout er breaks, is t here anot her rout e for a dynam ic rout ing prot ocol t o choose? This
net work is an ideal candidat e for st at ic rout ing. Configure one st at ic rout e in t he hub rout er for
each spoke rout er and a single default rout e in each spoke rout er point ing t o t he hub, and t he
net work is ready t o go. ( Default rout es are covered in Chapt er 12, " Default Rout es and OnDem and Rout ing." )
Figu r e 4 - 1 4 . Th is h u b- a n d- spok e n e t w or k is ide a l for st a t ic r ou t in g.
When designing a net work, t he sim plest solut ion is alm ost always t he best solut ion. I t is good
pract ice t o choose a dynam ic rout ing prot ocol only aft er det erm ining t hat st at ic rout ing is not a
pract ical solut ion for t he design at hand.
Looking Ahead
Now t hat t he basics of dynam ic rout ing prot ocols have been exam ined, it is t im e t o exam ine
specific rout ing prot ocols. The following chapt er looks at RI P, t he oldest and sim plest of t he
dynam ic rout ing prot ocols.
Recommended Reading
Perlm an, R. I nt erconnect ions: Bridges and Rout ers. Reading, Massachuset t s: Addison- Wesley;
1992.
Review Questions
1
What is a rout ing prot ocol?
2
What basic procedures should a rout ing algorit hm perform ?
3
Why do rout ing prot ocols use m et rics?
4
What is convergence t im e?
5
What is load balancing? Nam e four different t ypes of load balancing.
6
What is a dist ance vect or rout ing prot ocol?
7
Nam e several problem s associat ed wit h dist ance vect or prot ocols.
8
What are neighbors?
9
What is t he purpose of rout e invalidat ion t im ers?
10
Explain t he difference bet ween sim ple split horizon and split horizon wit h poisoned
reverse.
11
What is t he count ing- t o- infinit y problem , and how can it be cont rolled?
12
What are holddown t im ers, and how do t hey work?
13
What are t he differences bet ween dist ance vect or and link st at e rout ing prot ocols?
14
What is t he purpose of a t opological dat abase?
15
Explain t he basic st eps involved in converging a link st at e net work.
16
Why are sequence num bers im port ant in link st at e prot ocols?
17
What purpose does aging serve in a link st at e prot ocol?
18
Explain how an SPF algorit hm works.
19
How do areas benefit a link st at e net work?
20
What is an aut onom ous syst em ?
21
What is t he difference bet ween an I GP and an EGP?
Part II: Interior Routing Protocols
Chapt er 5 Rout ing I nform at ion Prot ocol ( RI P)
Chapt er 6 RI Pv2, RI Png, and Classless Rout ing
Chapt er 7 Enhanced I nt erior Gat eway Rout ing Prot ocol ( EI GRP)
Chapt er 8 OSPFv2
Chapt er 9 OSPFv3
Chapt er 10 I nt egrat ed I S- I S
Chapter 5. Routing Information Protocol
(RIP)
This chapt er covers t he following subj ect s:
Operat ion of RI P
Configuring RI P
Troubleshoot ing RI P
The oldest of t he dist ance vect or I P rout ing prot ocols st ill in widespread use, RI P current ly exist s
in t wo versions. This chapt er deals wit h version 1 of RI P. Chapt er 6, " RI Pv2, RI Png, and
Classless Rout ing," covers Version 2, which adds several enhancem ent s t o RI Pv1. Most not ably,
RI Pv1 is a classful rout ing prot ocol, whereas RI Pv2 is classless. This chapt er int roduces classful
rout ing, and Chapt er 6 int roduces classless rout ing. Chapt er 6 also int roduces RI Png, which is an
adapt at ion of RI Pv2 for support of I Pv6.
Dist ance vect or prot ocols, based on t he algorit hm s developed by Bellm an, [ 1] Ford, and
Fulkerson, [ 2] were im plem ent ed beginning in 1969 in net works such as ARPANET and
CYCLADES. I n t he m id- 1970s Xerox developed a prot ocol called PARC[ 3] Universal Prot ocol, or
PUP, t o run on it s 3- Mbps experim ent al predecessor t o m odern Et hernet . PUP was rout ed by t he
Gat eway I nform at ion Prot ocol ( GWI NFO) . PUP evolved int o t he Xerox Net work Syst em s ( XNS)
prot ocol suit e; concurrent ly, t he Gat eway I nform at ion Prot ocol becam e t he XNS Rout ing
I nform at ion Prot ocol. I n t urn, XNS RI P has becom e t he precursor of such com m on rout ing
prot ocols as Novell's I PX RI P, AppleTalk's Rout ing Table Maint enance Prot ocol ( RTMP) , and, of
course, I P RI P.
[1]
R. E. Bellman. Dynamic Programming. Princeton, New Jersey: Princeton University Press; 1957.
[2]
L. R. Ford Jr. and D. R. Fulkerson. Flows in Networks. Princeton, New Jersey: Princeton University Press; 1962.
[3]
Palo Alto Research Center.
The 4.2 Berkeley Soft ware Dist ribut ion of UNI X, released in 1982, im plem ent ed RI P in a daem on
called rout ed; m any m ore recent versions of UNI X are based on t he popular 4.2BSD and
im plem ent RI P in eit her rout ed or gat ed.[ 4] Oddly enough, a st andard for RI P was not released
unt il 1988, aft er t he prot ocol was in ext ensive deploym ent . That was RFC 1058, writ t en by
Charles Hedrick, and it rem ains t he only form al st andard of RI Pv1.
[4]
Pronounced "route-dee" and "gate-dee."
Depending on t he lit erat ure you reads, RI P is eit her unj ust ly m aligned or undeservedly popular.
Alt hough it lacks t he capabilit ies of m any of it s successors, it s sim plicit y and widespread use
m ean t hat com pat ibilit y problem s bet ween im plem ent at ions are rare. RI P was designed for
sm aller net works in which t he dat a links are fairly hom ogeneous. Wit hin t hese const raint s, and
especially wit hin m any UNI X environm ent s, RI P cont inues t o be a popular rout ing prot ocol.
Operation of RIP
The RI P process operat es from UDP port 520; all RI P m essages are encapsulat ed in a UDP ( User
Dat agram Prot ocol) segm ent wit h bot h t he Source and Dest inat ion Port fields set t o t hat value.
RI P defines t wo m essage t ypes: Request m essages and Response m essages. A Request m essage
is used t o ask neighboring rout ers t o send an updat e. A Response m essage carries t he updat e.
The m et ric used by RI P is hop count , wit h 1 signifying a direct ly connect ed net work of t he
advert ising rout er and 16 signifying an unreachable net work.
On st art up, RI P broadcast s a packet carrying a Request m essage out each RI P- enabled int erface.
The RI P process t hen ent ers a loop, list ening for RI P Request or Response m essages from ot her
rout ers. Neighbors receiving t he Request send a Response cont aining t heir rout e t able.
When t he request ing rout er receives t he Response m essages, it processes t he enclosed
inform at ion. I f a part icular rout e ent ry included in t he updat e is new, it is ent ered int o t he rout e
t able along wit h t he address of t he advert ising rout er, which is read from t he source address
field of t he updat e packet . I f t he rout e is for a net work t hat RI P has already ent ered in t he t able,
t he exist ing ent ry will be replaced only if t he new rout e has a lower hop count . I f t he advert ised
hop count is higher t han t he recorded hop count and t he updat e was originat ed by t he recorded
next - hop rout er, t he rout e will be m arked as unreachable for a specified holddown period. I f at
t he end of t hat t im e t he sam e neighbor is st ill advert ising t he higher hop count , t he new m et ric
will be accept ed. [ 5]
[5]
Holddowns are used by Cisco IOS, but are not part of the stability features specified in RFC 1058.
RIP Timers and Stability Features
Aft er st art up, t he rout er grat uit ously sends a Response m essage out every RI P- enabled int erface
every 30 seconds, on average. The Response m essage, or updat e, cont ains t he rout er's full
rout e t able wit h t he except ion of ent ries suppressed by t he split horizon rule. The updat e t im er
init iat ing t his periodic updat e includes a random variable t o prevent t able synchronizat ion. [ 6] As
a result , t he t im e bet ween individual updat es from a t ypical RI P process m ight be from 25 t o 35
seconds. The specific random variable used by Cisco I OS, RI P_JI TTER, subt ract s up t o 15
percent ( 4.5 seconds) from t he updat e t im e. Therefore, updat es from Cisco rout ers vary
bet ween 25.5 and 30 seconds ( Figure 5- 1 ) . The dest inat ion address of t he updat e is t he all- host s
broadcast 255.255.255.255. [ 7]
[6]
Synchronization of route tables is discussed in Chapter 4, "Dynamic Routing Protocols."
[7]
Some implementations of RIP might broadcast only on broadcast media and send updates to the directly connected
neighbor on point-to-point links. The Cisco RIP will broadcast on any link type unless configured to do otherwise.
Figu r e 5 - 1 . RI P a dds a sm a ll r a n dom va r ia ble t o t h e u pda t e t im e r a t
e a ch r e se t t o h e lp a void r ou t e t a ble syn ch r on iza t ion . Th e RI P u pda t e s
fr om Cisco r ou t e r s va r y fr om 2 5 .5 t o 3 0 se con ds, a s sh ow n in t h e de lt a
t im e s of t h e se u pda t e s.
[View full size image]
Several ot her t im ers are em ployed by RI P. Recall from Chapt er 4 t he invalidat ion t im er, which
dist ance vect or prot ocols use t o lim it t he am ount of t im e a rout e can st ay in a rout e t able
wit hout being updat ed. RI P calls t his t im er t he ex pir at ion t im er, or t im eout. The Cisco I OS calls
it t he invalid t im er . The expirat ion t im er is init ialized t o 180 seconds whenever a new rout e is
est ablished and is reset t o t he init ial value whenever an updat e is heard for t hat rout e. I f an
updat e for a rout e is not heard wit hin t hat 180 seconds ( six updat e periods) , t he hop count for
t he rout e is changed t o 16, m arking t he rout e as unreachable.
Anot her t im er, t he garbage collect ion or flush t im er, is set t o 240 seconds60 seconds longer t han
t he expirat ion t im e. [ 8] The rout e will be advert ised wit h t he unreachable m et ric unt il t he garbage
collect ion t im er expires, at which t im e t he rout e will be rem oved from t he rout e t able. Exam ple
5 - 1 shows a rout e t able in which a rout e has been m arked as unreachable but has not yet been
flushed.
[8]
Cisco routers use a 60-second garbage collection timer, although RFC 1058 prescribes 120 seconds.
Ex a m ple 5 - 1 . Th is r ou t e r h a s n ot h e a r d a n u pda t e for su bn e t 1 0 .3 .0 .0
for m or e t h a n six u pda t e pe r iods. Th e r ou t e h a s be e n m a r k e d
u n r e a ch a ble bu t h a s n ot ye t be e n flu sh e d fr om t h e r ou t e t a ble .
Mayberry#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
10.0.0.0 255.255.0.0 is subnetted, 4 subnets
C
10.2.0.0 is directly connected, Serial0
R
10.3.0.0 255.255.0.0 is possibly down,
routing via 10.1.1.1, Ethernet0
C
10.1.0.0 is directly connected, Ethernet0
R
10.4.0.0 [120/1] via 10.2.2.2, 00:00:00, Serial0
Mayberry#
The t hird t im er is t he holddown t im er, alt hough RFC 1058 does not call for t he use of holddowns.
The Cisco im plem ent at ion of RI P does use t hem . An updat e wit h a hop count higher t han t he
m et ric recorded in t he rout e t able will cause t he rout e t o go int o holddown for 180 seconds
( again, six updat e periods) .
These four t im ers can be m anipulat ed wit h t he com m and:
timers basic update invalid holddown flush
This com m and applies t o t he ent ire RI P process. I f t he t im ing of one rout er is changed, t he
t im ing of all t he rout ers in t he RI P dom ain m ust be changed. Therefore, t hese t im ers should not
be changed from t heir default values wit hout a specific, carefully considered reason.
RI P em ploys split horizon wit h poison reverse and t riggered updat es. A t riggered updat e occurs
whenever t he m et ric for a rout e is changed and, unlike regularly scheduled updat es, m ight
include only t he ent ry or ent ries t hat changed. Also unlike regular updat es, a t riggered updat e
does not cause t he receiving rout er t o reset it s updat e t im er; if it did, a t opology change could
cause m any rout ers t o reset at t he sam e t im e and t hus cause t he periodic updat es t o becom e
synchronized. To avoid a " st orm " of t riggered updat es aft er a t opology change, anot her t im er is
em ployed. When a t riggered updat e is t ransm it t ed, t his t im er is random ly set bet ween one and
five seconds; subsequent t riggered updat es cannot be sent unt il t he t im er expires.
Som e host s m ight em ploy RI P in a " silent " m ode. These so- called silent host s do not generat e
RI P updat es, but list en for t hem and updat e t heir int ernal rout e t ables accordingly. As an
exam ple, using rout ed wit h t he - q opt ion enables RI P in silent m ode on a UNI X host .
RIP Message Format
The RI P m essage form at is shown in Figure 5- 2 . Each m essage cont ains a com m and and a
version num ber and can cont ain ent ries for up t o 25 rout es. Each rout e ent ry includes an
address fam ily ident ifier, t he I P address reachable by t he rout e, and t he hop count for t he rout e.
I f a rout er m ust send an updat e wit h m ore t han 25 ent ries, m ult iple RI P m essages m ust be
produced. Not e t hat t he init ial port ion of t he m essage is 4 oct et s, and each rout e ent ry is 20
oct et s. Therefore, t he m axim um m essage size is 4 + ( 25 x 20) = 504 oct et s. I ncluding an eight byt e UDP header will m ake t he m axim um RI P dat agram size ( not including t he I P header) 512
oct et s.
Figu r e 5 - 2 . Th e RI P m e ssa ge for m a t .
Com m and will always be set t o eit her one, signifying a Request m essage, or t wo, signifying a
Response m essage. There are ot her com m ands, but t hey are all eit her obsolet e or reserved for
privat e use.
Version will be set t o one for RI Pv1.
Address Fam ily I dent ifier is set t o t wo for I P. The only except ion t o t his is a request for a rout er's
( or host 's) full rout e t able, as discussed in t he following sect ion.
I P Address is t he address of t he dest inat ion of t he rout e. This ent ry m ight be a m aj or net work
address, a subnet , or a host rout e. The sect ion t it led " Classful Rout ing" exam ines how RI P
dist inguishes am ong t hese t hree t ypes of ent ries.
Met ric is, as previously m ent ioned, a hop count bet ween 1 and 16.
An analyzer decode of a RI P m essage is shown in Figure 5- 3 .
Figu r e 5 - 3 . An Et h e r e a l de code of a RI Pv1 m e ssa ge sh ow s t h e va lu e s
in t h e m e ssa ge fie lds of t h is spe cific Re spon se m e ssa ge .
[View full size image]
Several hist orical influences cont ribut ed t o t he inelegant form at of t he RI P m essage in which far
m ore bit spaces are unused t han are used. These influences range from RI P's original
developm ent as an XNS prot ocol, and t he developer's int ent ions for it t o adapt t o a large set of
address fam ilies, t o t he influence of BSD, and it s use of socket addresses, t o t he need for fields
t o fall on 32- bit word boundaries. What ever t he original m ot ivat ions, you will see in Chapt er 6
t hat t hese unused fields have since been put t o good use.
Request Message Types
A RI P Request m essage m ight request eit her a full rout e t able or inform at ion on specific rout es
only. I n t he form er case, t he Request m essage will have a single rout e ent ry in which t he
address fam ily ident ifier is set t o zero, t he address is all zeros ( 0.0.0.0) , and t he m et ric is 16. A
device receiving such a request responds by unicast ing it s full rout e t able t o t he request ing
address, honoring such rules as split horizon and boundary sum m arizat ion ( discussed in
" Classful Rout ing: Sum m arizat ion at Boundary Rout ers," lat er in t his chapt er) .
Som e diagnost ic processes m ight need t o know inform at ion about a specific rout e or rout es. I n
t his case, a Request m essage m ight be sent wit h ent ries specifying t he addresses in quest ion. A
device receiving t his request will process t he ent ries one by one, building a Response m essage
from t he Request m essage. I f t he device has an ent ry in it s rout e t able corresponding t o an
address in t he request , it will ent er t he m et ric of it s own rout e ent ry int o t he m et ric field. I f not ,
t he m et ric field will be set t o 16. The response will t ell exact ly what t he rout er " knows," wit h no
considerat ion given t o split horizon or boundary sum m arizat ion.
As not ed previously, host s m ight run RI P in silent m ode. This approach allows t hem t o keep t heir
rout e t ables up t o dat e by list ening t o RI P updat es from rout ers wit hout having t o send RI P
Response m essages uselessly on t he net work. However, diagnost ic processes m ight need t o
exam ine t he rout e t able of t hese silent host s. Therefore, RFC 1058 specifies t hat if a silent host
receives a request from a UDP port ot her t han t he st andard RI P port of 520, t he host m ust send
a response.
Classful Routing
The rout e t able in Exam ple 5- 2 cont ains RI P- derived rout es, which are recognized from t he key
t o t he left of each ent ry. Of significance in t hese ent ries are t he bracket ed t uples; as discussed
in Chapt er 3, " St at ic Rout ing," t he first num ber is t he adm inist rat ive dist ance, and t he second
num ber is t he m et ric. I t is readily seen t hat RI P has an adm inist rat ive dist ance of 120, and as
already st at ed, t he m et ric for RI P is hop count . Therefore, net work 10.8.0.0 is t wo hops away,
via eit her E0 or S1. I f m ore t han one rout e exist s t o t he sam e dest inat ion wit h equal hop count s,
equal- cost load balancing will be perform ed. The rout e t able of Exam ple 5- 2 cont ains several
m ult iple, equal- cost rout es.
Ex a m ple 5 - 2 . Th is r ou t e t a ble con t a in s su bn e t s of n e t w or k s 1 0 .0 .0 .0
a n d 1 7 2 .2 5 .0 .0 . All n e t w or k s n ot dir e ct ly con n e ct e d w e r e de r ive d by
RI P.
MtPilate#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
10.0.0.0 255.255.0.0 is subnetted, 9 subnets
R
10.10.0.0 [120/3] via 10.5.5.1, 00:00:20, Serial1
[120/3] via 10.1.1.1, 00:00:21, Ethernet0
R
10.11.0.0 [120/3] via 10.5.5.1, 00:00:21, Serial1
[120/3] via 10.1.1.1, 00:00:21, Ethernet0
R
10.8.0.0 [120/2] via 10.1.1.1, 00:00:21, Ethernet0
[120/2] via 10.5.5.1, 00:00:21, Serial1
R
10.9.0.0 [120/2] via 10.5.5.1, 00:00:21, Serial1
[120/2] via 10.1.1.1, 00:00:21, Ethernet0
R
10.3.0.0 [120/1] via 10.1.1.1, 00:00:21, Ethernet0
[120/1] via 10.5.5.1, 00:00:21, Serial1
C
10.1.0.0 is directly connected, Ethernet0
R
10.6.0.0 [120/1] via 10.1.1.1, 00:00:21, Ethernet0
[120/1] via 10.5.5.1, 00:00:22, Serial1
R
10.7.0.0 [120/2] via 10.1.1.1, 00:00:22, Ethernet0
[120/2] via 10.5.5.1, 00:00:22, Serial1
C
10.5.0.0 is directly connected, Serial1
172.25.0.0 255.255.255.0 is subnetted, 3 subnets
R
172.25.153.0 [120/1] via 172.25.15.2, 00:00:03, Serial0
R
172.25.131.0 [120/1] via 172.25.15.2, 00:00:03, Serial0
C
172.25.15.0 is directly connected, Serial0
When a packet ent ers a RI P- speaking rout er and a rout e t able lookup is perform ed, t he various
choices in t he t able are pruned unt il a single pat h rem ains. First , t he net work port ion of t he
dest inat ion address is read and t he rout e t able is consult ed for a m at ch. I t is t his first st ep of
reading t he m aj or class A, B, or C net work num ber t hat defines a classful rout e t able lookup. I f
t here is no m at ch for t he m aj or net work, t he packet is dropped and an I CMP Dest inat ion
Unreachable m essage is sent t o t he packet 's source. I f t here is a m at ch for t he net work port ion,
t he subnet s list ed for t hat net work are exam ined. I f a m at ch can be found, t he packet is rout ed.
I f a m at ch cannot be m ade, t he packet is dropped and a Dest inat ion Unreachable m essage is
sent .
Classful Routing: Directly Connected Subnets
Classful rout e lookups can be illust rat ed wit h t hree exam ples ( referring t o Exam ple 5- 2) :
1 . I f a packet wit h a dest inat ion address of 192.168.35.3 ent ers t his rout er, no m at ch for
net work 192.168.35.0 is found in t he rout e t able, and t he packet is dropped.
2 . I f a packet wit h a dest inat ion address of 172.25.33.89 ent ers t he rout er, a m at ch is m ade
t o class B net work 172.25.0.0/ 24. The subnet s list ed for t his net work are t hen exam ined;
no m at ch can be m ade for subnet 172.25.33.0, so t hat packet , t oo, is dropped.
3 . Finally, a packet dest ined for 172.25.153.220 ent ers t he rout er. This t im e 172.25.0.0/ 24 is
m at ched, t hen subnet 172.25.153.0 is m at ched, and t he packet is forwarded t o next - hop
address 172.25.15.2.
Anot her look at Figure 5- 2 reveals t hat t here is no provision for RI P t o advert ise a subnet m ask
along wit h each rout e ent ry. And accordingly, no m asks are associat ed wit h t he individual
subnet s in t he rout e t able. Therefore, if t he rout er whose forwarding dat abase is depict ed in
Exam ple 5- 2 receives a packet wit h a dest inat ion address of 172.25.131.23, t here is no posit ive
way t o det erm ine where t he subnet bit s end and t he host bit s begin, or even if t he address is
subnet t ed at all.
The rout er's only recourse is t o assum e t hat t he m ask configured on one of it s int erfaces
at t ached t o 172.25.0.0 is used consist ent ly t hroughout t he net work. I t will use it s own m ask for
172.25.0.0 t o derive t he subnet of t he dest inat ion address. As t he rout e t ables t hroughout t his
chapt er illust rat e, a rout er t hat is direct ly connect ed t o a net work will list t he net work in a
heading along wit h t he subnet m ask of t he connect ing int erface and will t hen list all t he known
subnet s of t he net work. I f t he net work is not direct ly connect ed, t here is a list ing only for t he
m aj or- class net work and no associat ed m ask.
Because t he dest inat ion addresses of packet s being rout ed by a classful rout ing prot ocol are
int erpret ed according t o t he subnet m asks locally configured on t he rout er's int erfaces, all
subnet m asks wit hin a m aj or, class- level net work m ust be consist ent .
Classful Routing: Summarization at Boundary Routers
A quest ion arises from t he preceding discussion: How does a RI P process int erpret t he subnet of
a m aj or net work if it has no int erfaces at t ached t o t hat net work? Wit hout an int erface on t he
class A, B, or C net work of t he dest inat ion, t he rout er has no way of recognizing t he correct
subnet m ask t o use and t herefore no way of correct ly ident ifying t he subnet .
The solut ion is sim ple: I f a rout er has no direct at t achm ent s t o t he net work, it needs only a
single rout e ent ry point ing t oward a rout er t hat is direct ly at t ached.
Figure 5- 4 shows a rout er t hat is at t ached at t he boundary of t wo m aj or net works, t he class A
net work 10.0.0.0 and t he class C net work 192.168.115.0. This boundary rout er does not send
det ails of t he subnet s of one m aj or net work int o t he ot her m aj or net work. As t he illust rat ion
shows, it aut om at ically perform s sum m arizat ion, or subnet hiding . I t advert ises only t he address
10.0.0.0 int o net work 192.168.115.0 and advert ises only t he address.
Figu r e 5 - 4 . Th is r ou t e r , a t t h e bou n da r y of t w o m a j or n e t w or k s, doe s
n ot a dve r t ise t h e su bn e t s of on e n e t w or k t o r ou t e r s w it h in t h e ot h e r
n e t w or k .
I n t his way, t he rout e t ables for rout ers wit hin net work 192.168.115.0 have only a single ent ry
t hat direct s packet s for 10.0.0.0 t oward t he boundary rout er. The boundary rout er has an
int erface direct ly on net work 10.0.0.0 and, t herefore, has a subnet m ask wit h which t o derive
t he subnet for rout ing a packet wit hin t hat net work's " cloud." Exam ple 5- 3 shows what t he rout e
t able of a rout er wit hin 192.168.115.0 would look like wit h a single, subnet less ent ry for
10.0.0.0.
Ex a m ple 5 - 3 . Th is r ou t e r h a s a sin gle e n t r y poin t in g t ow a r d n e t w or k
1 0 .0 .0 .0 . Th e n e x t - h op a ddr e ss is t h e bou n da r y r ou t e r , be ca u se t h e
n e t w or k is r e cor de d a s be in g on e h op a w a y.
Raleigh#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
R
10.0.0.0 [120/1] via 192.168.115.40, 00:00:10, Ethernet1
192.168.115.0 255.255.255.240 is subnetted, 6 subnets
C
192.168.115.32 is directly connected, Ethernet1
R
192.168.115.64 [120/1] via 192.168.115.99, 00:00:13, Ethernet0
C
192.168.115.96 is directly connected, Ethernet0
C
192.168.115.128 is directly connected, Serial0
R
192.168.115.192 [120/1] via 192.168.115.99, 00:00:13, Ethernet0
R
192.168.115.224 [120/1] via 192.168.115.130, 00:00:25, Serial0
Raleigh#
Chapt er 3's brief discussion of discont iguous subnet ssubnet s of a m aj or net work address
separat ed by a different m aj or net worknot es t hat t hey present a problem for classful rout ing
prot ocols such as RI P and I GRP. The problem occurs when discont iguous subnet s are
aut om at ically sum m arized at net work boundaries. A case st udy in t he configurat ion sect ion of
t his chapt er dem onst rat es t he problem and a solut ion.
Classful Routing: Summary
The defining charact erist ic of a classful rout ing prot ocol is t hat it does not advert ise an address
m ask along wit h t he advert ised dest inat ion address. Therefore, a classful rout ing prot ocol m ust
first m at ch t he m aj or class A, B, or C net work port ion of a dest inat ion address. For every packet
passing t hrough t he rout er
1 . I f t he dest inat ion address is a m em ber of a direct ly connect ed m aj or net work, t he subnet
m ask configured on t he int erface at t ached t o t hat net work will be used t o det erm ine t he
subnet of t he dest inat ion address. Therefore, t he sam e subnet m ask m ust be used
consist ent ly t hroughout t hat m aj or net work.
2 . I f t he dest inat ion address is not a m em ber of a direct ly connect ed m aj or net work, t he
rout er will t ry t o m at ch only t he m aj or class A, B, or C port ion of t he dest inat ion address.
Configuring RIP
I n keeping wit h t he sim ple nat ure of RI P, configurat ion is an easy t ask. There is one com m and t o
enable t he RI P process and one com m and for each net work on which RI P is t o run. Beyond t hat ,
RI P has few configurat ion opt ions.
Case Study: A Basic RIP Configuration
Only t wo st eps are necessary t o configure RI P:
1.
Enable RI P wit h t he com m and r ou t e r r ip .
2.
Specify each m aj or net work on which t o run RI P wit h t he n e t w or k com m and. Figure 5- 5 shows
a four- rout er net work, wit h four m aj or net work num bers. Rout er Goober is at t ached t o t wo
subnet s of net work 172.17.0.0.
Figu r e 5 - 5 . Bot h An dy a n d Ba r n e y a r e bor de r r ou t e r s be t w e e n cla ssle ve l n e t w or k s.
[View full size image]
The com m ands necessary t o enable RI P are displayed in Exam ple 5- 4 .
Ex a m ple 5 - 4 . Th e RI P con figu r a t ion of Goobe r .
router rip
network 172.17.0.0
Sim ilarly, Opie has t wo subnet s of t he sam e net work and will configure wit h t he com m ands in
Exam ple 5- 5 .
Ex a m ple 5 - 5 . Opie 's RI P con figu r a t ion .
router rip
network 172.17.0.0
Execut ing any r ou t e r com m and put s t he rout er int o con fig- r ou t e r m ode, indicat ed in t he
prom pt . The classful nat ure of RI P and t he subnet hiding at net work boundaries m ean t hat no
subnet s can be specified wit h t he n e t w or k com m andonly m aj or class A, B, or C net work
addresses. RI P can run on any int erface configured wit h any address belonging t o t he net work
specified wit h t he n e t w or k com m and.
Barney is at t ached t o t wo net works10.0.0.0 and 192.168.83.0. Therefore, bot h net works m ust
be specified as in Exam ple 5- 6 .
Ex a m ple 5 - 6 . Ba r n e y's RI P con figu r a t ion .
router rip
network 10.0.0.0
network 192.168.83.0
Andy has one at t achm ent t o net work 192.168.83.0, at t achm ent s t o t wo subnet s of
192.168.12.0, and at t achm ent s t o t wo subnet s of 172.17.0.0. Exam ple 5- 7 shows it s
configurat ion.
Ex a m ple 5 - 7 . An dy's RI P con figu r a t ion .
router rip
network 172.17.0.0
network 192.168.12.0
network 192.168.83.0
I n Exam ple 5- 8 , t he com m and de bu g ip r ip has been t urned on in Andy. Of part icular int erest
here is t he subnet hiding t hat t he rout er is perform ing. The subnet s 192.168.12.64 and
192.168.12.192 are advert ised bet ween int erfaces E0 and E2, which are bot h at t ached t o
net work 192.168.12.0, but t he net work is sum m arized out E1, S0, and S1, which are all
at t ached t o different net works. Likewise, net works 192.168.83.0 and 172.17.0.0 are being
sum m arized across classful boundaries. Not ice also t hat Andy is receiving a sum m ary rout e for
net work 10.0.0.0 from Barney. Finally, split horizon can be observed here. For exam ple, t he
advert isem ent t o Barney out E1 cont ains no ent ries for 10.0.0.0 or 192.168.83.0.
Ex a m ple 5 - 8 . Th e se de bu g m e ssa ge s sh ow t h e RI P u pda t e s r e ce ive d
a n d se n t by Rou t e r An dy. Th e r e su lt s of bot h n e t w or k su m m a r iza t ion
a n d split h or izon ca n be obse r ve d in t h e u pda t e e n t r ie s.
Andy#debug ip rip
RIP protocol debugging is on
Andy#
RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.12.65)
RIP: build update entries
subnet 192.168.12.192, metric 1
network 10.0.0.0, metric 2
network 192.168.83.0, metric 1
network 172.17.0.0, metric 1
RIP: sending v1 update to 255.255.255.255 via Ethernet1 (192.168.83.1)
RIP: build update entries
network 192.168.12.0, metric 1
network 172.17.0.0, metric 1
RIP: sending v1 update to 255.255.255.255 via Ethernet2 (192.168.12.195)
RIP: build update entries
subnet 192.168.12.64, metric 1
network 10.0.0.0, metric 2
network 192.168.83.0, metric 1
network 172.17.0.0, metric 1
RIP: sending v1 update to 255.255.255.255 via Serial0 (172.17.1.1)
RIP: build update entries
subnet 172.17.4.0, metric 2
subnet 172.17.2.0, metric 1
network 10.0.0.0, metric 2
network 192.168.83.0, metric 1
network 192.168.12.0, metric 1
RIP: sending v1 update to 255.255.255.255 via Serial1 (172.17.2.1)
RIP: build update entries
subnet 172.17.1.0, metric 1
subnet 172.17.3.0, metric 2
network 10.0.0.0, metric 2
network 192.168.83.0, metric 1
network 192.168.12.0, metric 1
RIP: received v1 update from 172.17.1.2 on Serial0
172.17.3.0 in 1 hops
RIP: received v1 update from 192.168.83.244 on Ethernet1
10.0.0.0 in 1 hops
RIP: received v1 update from 172.17.2.2 on Serial1
172.17.4.0 in 1 hops
Case Study: Passive Interfaces
The Rout er Floyd has been added t o t he net work ( Figure 5- 6 ) .
Figu r e 5 - 6 . N e t w or k policy ca lls for n o RI P e x ch a n ge s be t w e e n An dy
a n d Floyd.
I t is desired t hat no RI P advert isem ent s be exchanged bet ween Floyd and Andy. This is easy
enough at Floyd, as displayed in Exam ple 5- 9 .
Ex a m ple 5 - 9 . Floyd's RI P con figu r a t ion
router rip
network 192.168.100.0
By not including a net work st at em ent for 192.168.12.0, Floyd will not advert ise on int erface
192.168.12.66. Andy, however, has t wo int erfaces at t ached t o 192.168.12.0; t he net work m ust
be included under RI P. To block RI P broadcast s on an int erface connect ed t o a subnet of a RI Penabled net work, add t he pa ssive - in t e r fa ce com m and t o t he RI P process. Andy's RI P
configurat ion is displayed in Exam ple 5- 10 .
Ex a m ple 5 - 1 0 . An dy's RI P con figu r a t ion w it h a pa ssive in t e r fa ce .
router rip
passive-interface Ethernet0
network 172.17.0.0
network 192.168.12.0
network 192.168.83.0
pa ssive - in t e r fa ce is not a RI P- specific com m and; it m ight be configured under any I P rout ing
prot ocol. Using t he pa ssive - in t e r fa ce com m and essent ially m akes a rout er a silent host on t he
dat a link specified. Like ot her silent host s, it st ill list ens t o RI P broadcast s on t he link and
updat es it s rout e t able accordingly. I f t he desired result is t o prevent t he rout er from learning
rout es on t he link, it m ust be achieved by m ore int ricat e cont rol of rout ing updat es, nam ely by
filt ering out updat es. ( Rout e filt ers are discussed in Chapt er 13 , " Rout e Filt ering." ) Unlike a
silent host , t he rout er does not respond t o a RI P Request received on a passive int erface.
Case Study: Configuring Unicast Updates
Next , Rout er Bea is added t o t he Et hernet link t hat Andy and Floyd share ( Figure 5- 7 ) . The noRI P policy bet ween Andy and Floyd rem ains in place, but now Bea and Andy, like Bea and Floyd,
m ust exchange RI P advert isem ent s.
Figu r e 5 - 7 . N o RI P u pda t e s sh ou ld be e x ch a n ge d be t w e e n An dy a n d
Floyd, bu t bot h sh ou ld e x ch a n ge u pda t e s w it h Be a .
[View full size image]
The configurat ion of Bea is st raight forward ( see Exam ple 5- 11 ) .
Ex a m ple 5 - 1 1 . Be a 's RI P con figu r a t ion .
router rip
network 192.168.12.0
network 192.168.200.0
The addit ion of a n e igh bor com m and under t he RI P processes of Andy enables RI P t o send a
unicast advert isem ent t o Bea's int erface while t he pa ssive - in t e r fa ce com m and cont inues t o
prevent broadcast updat es on t he link. [ 9]
[9] Another
use of neighbor is to enable unicast updates on nonbroadcast media such as Frame Relay.
Andy's configurat ion is displayed in Exam ple 5- 12 .
Ex a m ple 5 - 1 2 . An dy's RI P con figu r a t ion in clu de s a pa ssive in t e r fa ce
w it h a n e igh bor st a t e m e n t t o e n a ble u n ica st u pda t e s.
router rip
passive-interface Ethernet0
network 172.17.0.0
network 192.168.12.0
network 192.168.83.0
neighbor 192.168.12.67
Because Floyd m ust now send advert isem ent s t o Bea, a net work com m and for 192.168.12.0
m ust be added. pa ssive - in t e r fa ce is also added t o prevent broadcast updat es, and a n e igh bor
com m and is added t o enable unicast updat es t o Bea ( see Exam ple 5- 13 ) .
Ex a m ple 5 - 1 3 . Floyd's RI P con figu r a t ion w it h u n ica st u pda t e s t o
n e igh bor 1 9 2 .1 6 8 .1 2 .6 7 .
router rip
passive-interface Ethernet0
network 192.168.12.0
network 192.168.100.0
neighbor 192.168.12.67
By enabling de bu g ip r ip e ve n t s at Andy, t he result s of t he new configurat ion can be verified
( Exam ple 5- 14 ) . Andy is receiving updat es from Bea, but not from Floyd, and is sending
updat es direct ly t o Bea's int erface but is not broadcast ing on it s E0.
Ex a m ple 5 - 1 4 . Th e on ly u pda t e s An dy is se n din g ou t in t e r fa ce E0 a r e
u n ica st s t o Be a . Upda t e s a r e be in g r e ce ive d fr om Be a bu t n ot fr om
Floyd.
Andy#debug ip rip events
RIP event debugging is on
Andy#
RIP: received v1 update from 192.168.12.67 on Ethernet0
RIP: Update contains 1 routes
RIP: sending v1 update to 255.255.255.255 via Ethernet1 (192.168.83.1)
RIP: Update contains 4 routes
RIP: Update queued
RIP: Update sent via Ethernet1
RIP: sending v1 update to 255.255.255.255 via Ethernet2 (192.168.12.195)
RIP: Update contains 6 routes
RIP: Update queued
RIP: Update sent via Ethernet2
RIP: sending v1 update to 255.255.255.255 via Serial0 (172.17.1.1)
RIP: Update contains 7 routes
RIP: Update queued
RIP: Update sent via Serial0
RIP: sending v1 update to 255.255.255.255 via Serial1 (172.17.2.1)
RIP: Update contains 7 routes
RIP: Update queued
RIP: Update sent via Serial1
RIP: sending v1 update to 192.168.12.67 via Ethernet0 (192.168.12.65)
RIP: Update contains 4 routes
RIP: Update queued
RIP: Update sent via Ethernet0
RIP: received v1 update from 172.17.1.2 on Serial0
RIP: Update contains 1 routes
RIP: received v1 update from 172.17.2.2 on Serial1
RIP: Update contains 1 routes
RIP: received v1 update from 192.168.12.67 on Ethernet0
RIP: Update contains 1 routes
Alt hough Bea has learned rout es from bot h Andy and from Floyd, and is broadcast ing updat es on
t he shared Et hernet , t he policy st ill works because split horizon prevent s Bea from advert ising
t he rout es learned from t hose t wo rout ers back ont o t he Et hernet .
Case Study: Discontiguous Subnets
I n Figure 5- 8 , anot her rout er has been added t o t he net work wit h a subnet 10.33.32.0/ 20 on it s
E1 int erface. The problem is t hat t he ot her subnet of net work 10.0.0.0, 10.33.0.0/ 20, is
connect ed t o Barney, and t he only rout e bet ween t he subnet s is via 192.168.83.0 and
192.168.12.0t wo ent irely different net works. As a result , net work 10.0.0.0 is discont iguous.
Figu r e 5 - 8 . Cla ssfu l pr ot ocols su ch a s RI P a n d I GRP ca n n ot r ou t e a
t opology in w h ich t h e su bn e t s of n e t w or k 1 0 .0 .0 .0 a r e se pa r a t e d by
diffe r e n t n e t w or k s.
Barney will consider it self a border rout er bet ween net work 10.0.0.0 and net work 192.168.83.0;
likewise, Ernest _T will consider it self a border rout er bet ween 10.0.0.0 and 192.168.12.0. Bot h
will advert ise a sum m ary rout e of 10.0.0.0, and as a result Andy will be " fooled int o t hinking"
t hat it has t wo equal- cost pat hs t o t he sam e net work. Andy will load share on t he links t o Barney
and Ernest _T, and t here is now only a 50- 50 chance t hat packet s t o net work 10.0.0.0 will reach
t he correct subnet .
The solut ion is t o configure subnet s of net work 10.0.0.0 on t he sam e links on which
192.168.83.0/ 24 and 192.168.12.192/ 27 reside. This is accom plished wit h secondary I P
addresses, as displayed in Exam ple 5- 15 , Exam ple 5- 16 , and Exam ple 5- 17 .
Ex a m ple 5 - 1 5 . Ba r n e y is con figu r e d w it h se con da r y I P a ddr e sse s.
interface e0
ip address 10.33.55.1 255.255.240.0 secondary
Ex a m ple 5 - 1 6 . An dy is con figu r e d w it h se con da r y I P a ddr e sse s, a n d a
n e w n e t w or k is a dde d t o RI P.
interface e1
ip address 10.33.55.2 255.255.240.0 secondary
interface e2
ip address 10.33.75.1 255.255.240.0 secondary
router rip
network 10.0.0.0
Ex a m ple 5 - 1 7 . Er n e st _ T is con figu r e d w it h se con da r y I P a ddr e sse s.
interface e0
ip address 10.33.75.2 255.255.240.0 secondary
Because Andy did not previously have an int erface on net work 10.0.0.0, a net work st at em ent is
added t o t he RI P process. The result of t he configurat ion is shown in Figure 5- 9 . The exist ing
logical net work st ruct ure rem ains in place, and a cont iguous net work 10.0.0.0 is " overlaid" ont o
it .
Figu r e 5 - 9 . Se con da r y a ddr e sse s a r e u se d t o con n e ct t h e su bn e t s of
n e t w or k 1 0 .0 .0 .0 a cr oss t h e sa m e lin k s on w h ich ot h e r n e t w or k
a ddr e sse s e x ist .
[View full size image]
Exam ple 5- 18 shows Ernest _T's rout e t able. Of int erest here are t he dual, equal- cost rout es
associat ed wit h next - hop addresses 10.33.75.1 and 192.168.12.195.
Ex a m ple 5 - 1 8 . Th e r ou t in g pr oce ss in t h is r ou t e r se e s t h e su bn e t s
1 9 2 .1 6 8 .1 2 .1 9 2 / 2 7 a n d 1 0 .3 3 .6 4 .0 / 2 0 a s se pa r a t e lin k s, a lt h ou gh
t h e y r e side on t h e sa m e ph ysica l in t e r fa ce .
Ernest_T#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
10.0.0.0 255.255.240.0 is subnetted, 4 subnets
C
10.33.32.0 is directly connected, Ethernet1
R
10.33.48.0 [120/1] via 10.33.75.1, 00:00:05, Ethernet0
R
10.33.0.0 [120/2] via 10.33.75.1, 00:00:05, Ethernet0
C
10.33.64.0 is directly connected, Ethernet0
R
192.168.83.0 [120/1] via 192.168.12.195, 00:00:05, Ethernet0
[120/1] via 10.33.75.1, 00:00:05, Ethernet0
192.168.12.0 255.255.255.224 is subnetted, 2 subnets
R
192.168.12.64 [120/1] via 192.168.12.195, 00:00:05, Ethernet0
C
192.168.12.192 is directly connected, Ethernet0
R
192.168.200.0 [120/2] via 192.168.12.195, 00:00:05, Ethernet0
[120/2] via 10.33.75.1, 00:00:05, Ethernet0
R
172.17.0.0 [120/1] via 192.168.12.195, 00:00:06, Ethernet0
[120/1] via 10.33.75.1, 00:00:06, Ethernet0
Ernest_T#
Because t he rout ing process sees secondary addresses as separat e dat a links, caut ion should be
used when planning t hem on RI P or I GRP net works. A separat e RI P updat e will be broadcast on
each subnet ; if t he updat es are large and t he bandwidt h of t he physical link is lim it ed ( such as
on serial links) , t he m ult iple updat es can cause congest ion. Mult iple updat es on a link configured
wit h secondary addresses can be observed in Exam ple 5- 21 , lat er in t his chapt er.
Type caut iously when ent ering secondary addresses. I f you om it t he keyword se con da r y , t he
rout er will assum e t hat t he prim ary address is t o be replaced wit h t he new address. Making t his
m ist ake on an in- service int erface will have serious consequences.
Case Study: Manipulating RIP Metrics
A serial link, t o be used as a backup, has been added bet ween Ernest _T and Barney ( Figure 5- 10
) . This link should be used only if t he rout e via Andy fails. The problem is t hat t he pat h bet ween
Barney's 10.33.0.0 subnet and Ernest _T's 10.33.32.0 subnet is one hop via t he serial link and
t wo hops via t he preferred Et hernet links. Under norm al circum st ances, RI P will choose t he serial
link.
Figu r e 5 - 1 0 . RI P m e t r ics m u st be m a n ipu la t e d so t h a t t h e t w o- h op
Et h e r n e t r ou t e be t w e e n Ba r n e y a n d Er n e st _ T w ill be pr e fe r r e d ove r
t h e on e - h op se r ia l r ou t e .
[View full size image]
The rout e m et rics can be m anipulat ed wit h t he offse t - list com m and. The com m and specifies a
num ber t o add t o t he m et ric of a rout e ent ry and references an access list [ 10] t o det erm ine
which rout e ent ries t o m odify. The synt ax of t he com m and is as follows:
[10] See
Appendix B for a tutorial on access lists.
offset-list {access-list-number | name} { in | out} offset [type number]
The configurat ion of Ernest _T is in Exam ple 5- 19 .
Ex a m ple 5 - 1 9 . Er n e st _ T's RI P con figu r a t ion w it h a n in bou n d offse t
list .
access-list 1 permit 10.33.0.0 0.0.0.0
router rip
network 192.168.12.0
network 10.0.0.0
offset-list 1 in 2 Serial0
An access list is writ t en t hat ident ifies t he rout e t o subnet 10.33.0.0. The synt ax of t he offset list
says, " Exam ine RI P advert isem ent s incom ing from int erface S0. For rout e ent ries m at ching t he
addresses specified in access list 1, add 2 hops t o t he m et ric."
Aft er Barney is configured, it will have t he ent ries in Exam ple 5- 20 in it s configurat ion file.
Ex a m ple 5 - 2 0 . Ba r n e y's RI P con figu r a t ion w it h a n in bou n d offse t list .
router rip
offset-list 5 in 2 Serial0
network 10.0.0.0
network 192.168.83.0
!
access-list 5 permit 10.33.32.0 0.0.0.0
Exam ple 5- 21 shows t he result s of t he configurat ion at Ernest _T.
Ex a m ple 5 - 2 1 . Th e a ddit ion of t h e h ops spe cifie d in t h e offse t list
ch a n ge s t h e h op cou n t t o su bn e t 1 0 .3 3 .0 .0 / 2 0 via S0 fr om on e t o
t h r e e . N ow t h e t w o- h op r ou t e via E0 is u se d.
Ernest_T#debug ip rip
RIP protocol debugging is on
Ernest_T#
RIP: received v1 update from 192.168.12.195 on Ethernet0
192.168.12.64 in 1 hops
10.0.0.0 in 1 hops
192.168.83.0 in 1 hops
192.168.200.0 in 2 hops
172.17.0.0 in 1 hops
RIP: received v1 update from 10.33.75.1 on Ethernet0
10.33.48.0 in 1 hops
10.33.0.0 in 2 hops
192.168.83.0 in 1 hops
192.168.12.0 in 1 hops
192.168.200.0 in 2 hops
172.17.0.0 in 1 hops
RIP: received v1 update from 10.33.25.1 on Serial0
10.33.32.0 in 3 hops
10.33.48.0 in 1 hops
10.33.0.0 in 3 hops
192.168.83.0 in 1 hops
192.168.200.0 in 3 hops
172.17.0.0 in 2 hops
RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.12.196)
RIP: build update entries
network 10.0.0.0, metric 1
RIP: sending v1 update to 255.255.255.255 via Ethernet0 (10.33.75.2)
RIP: build update entries
subnet 10.33.32.0, metric 1
subnet 10.33.16.0, metric 1
RIP: sending v1 update to 255.255.255.255 via Ethernet1 (10.33.35.1)
RIP: build update entries
subnet 10.33.48.0, metric 2
subnet 10.33.0.0, metric 3
subnet 10.33.16.0, metric 1
subnet 10.33.64.0, metric 1
network 192.168.83.0, metric 2
network 192.168.12.0, metric 1
network 192.168.200.0, metric 3
network 172.17.0.0, metric 2
RIP: sending v1 update to 255.255.255.255 via Serial0 (10.33.25.2)
RIP: build update entries
subnet 10.33.32.0, metric 3
subnet 10.33.0.0, metric 3
subnet 10.33.64.0, metric 1
network 192.168.12.0, metric 1
network 192.168.200.0, metric 3
network 172.17.0.0, metric 2
Alt ernat ively, inst ead of having t he t wo rout ers m odify incom ing rout es, t he rout ers can be
configured t o m odify t heir out going rout es. The configurat ions in Exam ple 5- 22 and Exam ple 523 will have t he sam e effect s as t he previous configurat ions.
Ex a m ple 5 - 2 2 . Er n e st _ T's RI P con figu r a t ion u se s ou t bou n d offse t list s.
router rip
offset-list 3 out 2 Serial0
network 192.168.12.0
network 10.0.0.0
!
access-list 3 permit 10.33.32.0 0.0.0.0
Ex a m ple 5 - 2 3 . Ba r n e y's RI P con figu r a t ion u se s ou t bou n d offse t list s.
router rip
offset-list 7 out 2 Serial0
network 10.0.0.0
network 192.168.83.0
!
access-list 7 permit 10.33.0.0 0.0.0.0
Several ot her opt ions are available for configuring offset list s. I f no int erface is ident ified, t he list
will m odify all incom ing or out going updat es specified by t he access list on any int erface. I f no
access list is called ( by using a zero as t he access list num ber) , t he offset list will m odify all
incom ing or out going updat es.
Caut ion should be applied when choosing whet her t o use offset list s on incom ing or out going
advert isem ent s. I f m ore t han t wo rout ers are at t ached t o a broadcast net work, considerat ion
m ust be given t o whet her a single rout er should broadcast a m odified advert isem ent t o all it s
neighbors or whet her a single rout er should m odify a received advert isem ent .
Care m ust also be exercised when im plem ent ing offset list s on rout es t hat are in use. When an
offset list causes a next - hop rout er t o advert ise a higher m et ric t han it had been advert ising, t he
rout e will be m arked unreachable unt il t he holddown t im er expires.
Case Study: Minimizing the Impact of Updates
There are t im es when you will want t o m inim ize net work t raffic caused by rout ing updat es.
Regular RI P updat es, by default , occur every 30 seconds and include t he full rout e t able, in
addit ion t o t he flash updat es t hat are t ransm it t ed when t here is a change in t he m et ric of rout e
ent ries. I n a net work wit h m any subnet s, rout ing updat es can affect t raffic, especially on low
bandwidt h links. You also m ight want t o m inim ize rout ing updat es if you are paying for t raffic
t raversing a link.
Suppose ut ilizat ion on t he new serial link from Barney t o Ernest _T, in Figure 5- 10 , is high. The
RI P rout ing t raffic can be reduced in t wo ways t o m inim ize t he t raffic caused by t he rout ing
prot ocol: The t im ers can be adj ust ed so t he updat es don't occur as frequent ly, but t his will cause
longer convergence t im e when t he prim ary link fails. Or t riggered ext ensions can be configured
t o elim inat e periodic RI P updat es.
The int erface com m and ip r ip t r igge r e d enables t he t riggered ext ensions of RI P. [ 11] Aft er t wo
rout ers on a serial link det erm ine bot h are configured for t riggered RI P, rout e t able updat es are
m inim ized t o include only t he init ial exchange of rout e t ables and updat es when changes t o t he
rout e t ables occur. This com m and is only available on serial links and m ust be configured on
bot h ends of t he link before t aking affect .
[11] Triggered
Extensions are defined in RFC 2091 and were first introduced into IOS in release 12.0(1)T.
The t riggered ext ensions are configured on Barney's serial link t o Ernest _T wit h t he configurat ion
in Exam ple 5- 24 .
Ex a m ple 5 - 2 4 . Ba r n e y is con figu r e d w it h t r igge r e d, r a t h e r t h e n
pe r iodic, u pda t e s.
interface serial 0
ip rip triggered
Debugging on Barney shows t hat Barney at t em pt s t o est ablish a t riggered relat ionship wit h t he
rout er on t he ot her end of t he link. Barney sends polls and wait s for acknowledgm ent s. When it
doesn't receive any acknowledgm ent s, Barney begins sending regular RI Pv1 updat es. Out put
from de bu g ip r ip and de bu g ip r ip t r igge r is shown in Exam ple 5- 25 .
Ex a m ple 5 - 2 5 . W h e n a r ou t e r is in it ia lly con figu r e d w it h t r igge r e d RI P,
it polls t o de t e r m in e if it s n e igh bor is a lso con figu r e d for t r igge r e d
RI P.
Barney#debug ip rip
RIP protocol debugging is
Barney#debug ip rip trigger
RIP trigger debugging is on
Barney(config)#interface serial 0
Barney(config-if)#ip rip triggered
* 13:22:10.223: RIP: sending triggered request on Serial0 to 255.255.255.255
* 13:22:10.223: RIP: Start poll timer from 10.33.25.1 on Serial0
* 13:22:15.223: RIP-TIMER: polling timer on Serial0(10.33.25.1) expired
* 13:22:15.223: RIP: sending triggered request on Serial0 to 255.255.255.255
* 13:22:15.223: RIP: Start poll timer from source 10.33.25.1 on Serial0
* 13:22:16.733: RIP: received v1 update from 10.33.25.2 on Serial0
* 13:22:16.733:
172.17.8.0 in 1 hops
* 13:22:16.733:
172.17.9.0 in 1 hops
* 13:22:16.737:
172.17.10.0 in 1 hops
* 13:22:16.737:
172.17.11.0 in 1 hops
* 13:22:19.466: RIP-TIMER: sending timer on Serial0 expired
* 13:22:20.223: RIP-TIMER: polling timer on Serial0(10.33.25.1) expired
* 13:22:20.223: RIP: sending triggered request on Serial0 to 255.255.255.255
* 13:22:20.223: RIP: Start poll timer from source 10.33.25.1 on Serial0
* 13:22:25.223: RIP-TIMER: polling timer on Serial0(10.33.25.1) expired
* 13:22:25.223: RIP: sending triggered request on Serial0 to 255.255.255.255
* 13:22:25.223: RIP: Start poll timer from source 10.33.25.1 on Serial0
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
13:22:30.224:
13:22:30.224:
13:22:30.224:
13:22:35.224:
13:22:35.224:
13:22:35.224:
13:22:40.224:
13:22:40.224:
13:22:46.126:
13:22:46.126:
13:22:46.126:
13:22:46.130:
13:22:46.130:
13:22:49.054:
13:22:49.054:
13:22:49.054:
13:22:49.054:
13:22:49.054:
13:22:49.054:
13:22:49.058:
13:22:49.058:
13:22:49.058:
13:23:13.070:
13:23:13.070:
13:23:13.074:
13:23:13.074:
13:23:13.074:
13:23:17.385:
13:23:17.385:
13:23:17.385:
13:23:17.385:
13:23:17.385:
13:23:17.385:
13:23:17.389:
13:23:17.389:
13:23:17.389:
RIP-TIMER: polling timer on Serial0(10.33.25.1) expired
RIP: sending triggered request on Serial0 to 255.255.255.255
RIP: Start poll timer from source 10.33.25.1 on Serial0
RIP-TIMER: polling timer on Serial0(10.33.25.1) expired
RIP: sending triggered request on Serial0 to 255.255.255.255
RIP: Start poll timer from source 10.33.25.1 on Serial0
RIP-TIMER: polling timer on Serial0(10.33.25.1) expired
RIP: Poll 6 times on Serial0 thru 10.33.25.1 without any ack
RIP: received v1 update from 10.33.25.2 on Serial0
172.17.8.0 in 1 hops
172.17.9.0 in 1 hops
172.17.10.0 in 1 hops
172.17.11.0 in 1 hops
RIP-TIMER: sending timer on Serial0 expired
RIP: sending v1 update to 255.255.255.255 via Serial0(10.33.25.1)
RIP: build update entries
network 10.0.0.0 metric 2
subnet 172.17.0.0 metric 2
subnet 172.17.2.0 metric 1
subnet 172.17.4.0 metric 2
network 192.168.12.0 metric 1
network 192.168.83.0 metric 1
RIP: received v1 update from 10.33.25.2 on Serial0
172.17.8.0 in 1 hops
172.17.9.0 in 1 hops
172.17.10.0 in 1 hops
172.17.11.0 in 1 hops
RIP-TIMER: sending timer on Serial0 expired
RIP: sending v1 update to 255.255.255.255 via Serial0(10.33.25.1)
RIP: build update entries
network 10.0.0.0 metric 2
subnet 172.17.0.0 metric 2
subnet 172.17.2.0 metric 1
subnet 172.17.4.0 metric 2
network 192.168.12.0 metric 1
network 192.168.83.0 metric 1
The debug out put shows t hat t he configured rout er sends six t riggered request s. For each one,
t he rout er set s a poll t im er, which expires in five seconds. I f no acknowledgm ent is received
wit hin t he five seconds, anot her t riggered request is sent . I f no acknowledgm ent is received
aft er six t riggered request s have been sent and t he polls have expired, t he rout er wait s for t he
next regular updat e t im e and broadcast s a RI P updat e. While Barney is sending t riggered
request s, Ernest _T cont inues t o broadcast it s own RI P updat es, which Barney processes.
Now, Ernest _T's serial link t o Barney is configured wit h t riggered RI P. Through debugging on
Ernest _T, Exam ple 5- 26 shows t he init ializat ion process bet ween Barney and Ernest _T.
Ex a m ple 5 - 2 6 . D e bu g ou t pu t sh ow s t w o r ou t e r s e st a blish in g a
t r igge r e d RI P r e la t ion sh ip.
*
*
*
*
13:35:04.612:
13:35:04.616:
13:35:04.616:
13:35:04.616:
RIP:
RIP:
RIP:
RIP:
received v1 triggered request from 172.17.1.2 on Serial0
Trigger rip running on network 172.17.0.0 thru Serial0
172.17.1.2 change state from DOWN to INIT
172.17.1.2 change state from INIT to LOADING
* 13:35:04.616:
* 13:35:04.616:
* 13:35:04.616:
* 13:35:04.620:
* 13:35:04.620:
* 13:35:04.620:
* 13:35:04.620:
* 13:35:04.620:
* 13:35:04.620:
* 13:35:04.624:
* 13:35:04.624:
* 13:35:04.680:
* 13:35:04.684:
* 13:35:04.688:
* 13:35:04.688:
seq# 14
* 13:35:04.736:
* 13:35:04.740:
* 13:35:04.740:
* 13:35:04.740:
* 13:35:04.740:
* 13:35:04.744:
* 13:35:52.879:
* 13:36:21.907:
* 13:36:47.421:
RIP: send v1 triggered flush update to 172.17.1.2 on Serial0
RIP: assigned sequence number 25 on Serial0
RIP: build update entries
route 202: network 192.168.12.0 metric 1
route 206: subnet 172.17.2.0 metric 1
route 208: network 192.168.83.0 metric 1
route 210: network 10.0.0.0 metric 2
route 215: subnet 172.17.4.0 metric 2
route 217: subnet 172.17.0.0 metric 2
RIP: Update contains 6 routes, start 202, end 226
RIP: start retransmit timer of 172.17.1.2
RIP: received v1 triggered ack from 172.17.1.2 on Serial0 flush seq# 25
RIP: 172.17.1.2 change state from LOADING to FULL
RIP: received v1 triggered update from 172.17.1.2 on Serial0
RIP: sending v1 ack to 172.17.1.2 via Serial0 (172.17.1.1), flush,
RIP: received v1 triggered update from 172.17.1.2 on Serial0
RIP: sending v1 ack to 172.17.1.2 via Serial0 (172.17.1.1), seq# 15
172.17.9.0 in 1 hops
172.17.8.0 in 1 hops
172.17.11.0 in 1 hops
172.17.10.0 in 1 hops
RIP-TIMER: sending timer on Serial0 expired
RIP-TIMER: sending timer on Serial0 expired
RIP-TIMER: sending timer on Serial0 expired
The t riggered st at e goes from DOWN, t hrough I NI T and LOADI NG, t o FULL. Rout e inform at ion is
exchanged and updat es are acknowledged. At t he end of t he out put , you can see t hat t he RI P
updat e t im ers are expiring, but no new updat es are sent , nor are updat es received.
Troubleshooting RIP
Troubleshoot ing RI P is relat ively sim ple. Most difficult ies wit h classful prot ocols such as RI P
involve eit her m isconfigured subnet m asks or discont iguous subnet s. I f a rout e t able cont ains
inaccurat e or m issing rout es, check all subnet s for cont iguit y and all subnet m asks for
consist ency.
A final com m and can be useful when a high- speed rout er is sending m ult iple RI P m essages t o a
low- speed rout er. I n such a case, t he low- speed rout er m ight not be able t o process updat es as
quickly as t hey are received, and rout ing inform at ion m ight be lost . ou t pu t - de la y delay can be
used under t he RI P com m and t o set an int erpacket gap of bet ween 8 and 50 m illiseconds. ( The
default is 0 m illiseconds.)
Looking Ahead
The sim plicit y, m at urit y, and widespread accept ance of RI P ensure t hat it will be in service for
m any years t o com e. However, you saw in t his chapt er t he lim it at ions of it s classful nat ure. The
next chapt er cont inues t o exam ine RI P, and you see bot h how t he prot ocol has been ext ended t o
support classless rout ing and also how it has been ext ended t o support I Pv6.
Summary Table: Chapter 5 Command Review
Com m a n d
D e scr ipt ion
de bu g ip r ip [ e ve n t s]
Sum m arizes RI P t raffic t o and from t he rout er
ip a ddr e ss ip- addr ess
m ask se con da r y
Configures an int erface wit h t he indicat ed I P address as a
secondary address
ip r ip t r igge r e d
Configures t riggered ext ensions t o RI P on an int erface
n e igh bor ip- addr ess
Est ablishes t he link indicat ed by t he I P address as a neighbor of
t he int erface
n e t w or k net w ork- num ber
Specifies t he indicat ed net work as one t hat will run RI P
offse t - list { access- list num ber | n am e} { in |
ou t } offset [ t ype num ber ]
St ipulat es t hat a rout e ent ry belonging t o t he indicat ed access list
will have t he indicat ed offset num ber added t o it s m et ric
ou t pu t - de la y delay
Set s an int erpacket gap of t he indicat ed delay lengt h t o
accom m odat e processing delays bet ween high- speed and lowspeed rout ers
pa ssive - in t e r fa ce t ype
num ber
Blocks RI P broadcast s on t he int erface indicat ed by t ype and
num ber
r ou t e r r ip
Enables RI P
t im e r s ba sic updat e
invalid holddown flush
Manipulat es t he value of t he indicat ed t im er
Recommended Reading
Hedrick, C. " Rout ing I nform at ion Prot ocol." RFC 1058, June 1988.
Meyer, G. and Sherry, S. " Triggered Ext ensions t o RI P t o Support Dem and Circuit s." RFC 2091,
January 1997.
Review Questions
1
What port does RI P use?
2
What m et ric does RI P use? How is t he m et ric used t o indicat e an unreachable
net work?
3
What is t he updat e period for RI P?
4
How m any updat es m ust be m issed before a rout e ent ry will be m arked as
unreachable?
5
What is t he purpose of t he garbage collect ion t im er?
6
Why is a random t im er associat ed wit h t riggered updat es? What is t he range of t his
t im er?
7
What is t he difference bet ween a RI P Request m essage and a RI P Response
m essage?
8
Which t wo t ypes of Request m essages does RI P use?
9
Under what circum st ances will a RI P response be sent ?
10
Why does RI P hide subnet s at m aj or net work boundaries?
Configuration Exercises
1
Writ e configurat ions for t he six rout ers in Figure 5- 11 t o rout e t o all subnet s via RI P.
Figu r e 5 - 1 1 . N e t w or k for Con figu r a t ion Ex e r cise s 1 t h r ou gh 4 .
[View full size image]
2
Change t he configurat ions of Configurat ion Exercise 1 so t hat RI P updat es are
unicast bet ween RTC and RTD, inst ead of broadcast .
3
The bandwidt h of t he serial link bet ween RTC and RTD in Figure 5- 11 is very lim it ed.
Configure RI P t o send updat es across t his link every t wo m inut es. Carefully consider
what t im ers m ust be changed and on what rout ers t he t im ers m ust be changed.
4
A policy has been est ablished t hat dict at es t hat net work 192.168.4.0 should be
unreachable from RTA and t hat net work 192.168.5.0 should be unreachable from
RTB. Use one or m ore offset list s t o im plem ent t his policy.
5
According t o t he sect ion, "Classful Rout ing: Direct ly Connect ed Subnet s," subnet
m asks wit hin a m aj or, class- level net work m ust be consist ent . The sect ion does not ,
however, say t hat subnet m asks wit hin a m aj or, class- level net work m ust be
ident ical. The RI P configurat ion for bot h rout ers in Figure 5- 12 follows:
router rip
network 192.168.20.0
Figu r e 5 - 1 2 . N e t w or k for Con figu r a t ion Ex e r cise 5 .
Will packet s be rout ed correct ly in t his sm all net work? Explain why or why not .
Troubleshooting Exercises
1
I n t he first offset list exam ple, t he access list in Barney is changed from
access-list 5 permit 10.33.32.0 0.0.0.0
to
access-list 5 deny 10.33.32.0 0.0.0.0
access-list 5 permit any
What is t he result ?
2
Figure 5- 13 shows a net work in which t he I P address m asks on one rout er have been
m isconfigured. Exam ple 5- 27 t hrough Exam ple 5- 29 show t he rout e t ables of RTA, RTB, and
RTC, respect ively. Based on what you know about t he way RI P advert ises and receives updat es,
explain each ent ry in RTB's rout e t able. Explain why RTB's ent ry for subnet 172.16.26.0
indicat es a 32- bit m ask. I f any ent ries are m issing in any of t he rout e t ables, explain why.
Figu r e 5 - 1 3 . N e t w or k for Tr ou ble sh oot in g Ex e r cise s 2 a n d 3 .
Ex a m ple 5 - 2 7 . Rou t e t a ble of RTA in Figu r e 5 - 1 3 .
RTA#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route
Gateway of last resort is not set
172.16.0.0/16 is subnetted, 4 subnets
R
172.16.24.0 [120/1] via 172.16.18.3, 00:00:01, Ethernet0
R
172.16.26.0 [120/2] via 172.16.18.3, 00:00:01, Ethernet0
C
172.16.20.0 is directly connected, Ethernet1
C
172.16.18.0 is directly connected, Ethernet0
RTA#
Ex a m ple 5 - 2 8 . Rou t e t a ble of RTB in Figu r e 5 - 1 3 .
RTB#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route, o - ODR
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
R
172.16.24.0/22 [120/1] via 172.16.18.3, 00:00:20, Ethernet0
R
172.16.26.0/32 [120/2] via 172.16.18.3, 00:00:20, Ethernet0
C
172.16.20.0/22 is directly connected, Ethernet1
C
172.16.16.0/22 is directly connected, Ethernet0
RTB#
Ex a m ple 5 - 2 9 . Rou t e t a ble of RTC in Figu r e 5 - 1 3 .
RTC#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route, o - ODR
Gateway of last resort is not set
172.16.0.0/23 is subnetted, 4 subnets
C
172.16.24.0 is directly connected, Serial0
R
172.16.26.0 [120/1] via 172.16.24.2, 00:00:09, Serial0
R
172.16.20.0 [120/1] via 172.16.18.5, 00:00:25, Ethernet0
C
172.16.18.0 is directly connected, Ethernet0
RTC#
3
Users on subnet 172.16.18.0/ 23 in Figure 5- 13 are com plaining t hat connect ivit y t o subnet
172.16.26.0/ 23 is int erm it t ent som et im es it can be reached, som et im es it can't . ( The bad subnet
m asks of RTB have been correct ed.) A first exam inat ion of t he rout e t ables of RTC and RTD
( Exam ple 5- 30 ) seem s t o show no problem s. All subnet s are in bot h t ables. Yet a m inut e or so
lat er, RTC shows subnet 172.16.26.0/ 23 t o be unreachable ( Exam ple 5- 31 ) , whereas RTD st ill
shows all subnet s. A few m inut es aft er t hat , t he subnet is back in RTC's rout e t able ( Exam ple 532 ) . I n each of t he t hree figures, t he rout e t able of RTD shows no change. A careful
exam inat ion of t he rout e t ables in Exam ple 5- 30 t hrough Exam ple 5- 32 will reveal t he problem .
What is it ?
Ex a m ple 5 - 3 0 . Rou t e t a ble s of RTC a n d RTD in Figu r e 5 - 1 3 .
RTC#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route, o - ODR
Gateway of last resort is not set
172.16.0.0/23 is subnetted, 5 subnets
C
172.16.24.0 is directly connected, Serial0
R
172.16.26.0 [120/1] via 172.16.24.2, 00:02:42, Serial0
R
172.16.20.0 [120/1] via 172.16.18.5, 00:00:22, Ethernet0
R
172.16.22.0 [120/1] via 172.16.18.4, 00:00:05, Ethernet0
C
172.16.18.0 is directly connected, Ethernet0
________________________________________________________________________________
RTD#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route
Gateway of last resort is not set
172.16.0.0/16 is subnetted, 5 subnets
C
172.16.24.0 is directly connected, Serial0
C
172.16.26.0 is directly connected, TokenRing0
R
172.16.20.0 [120/2] via 172.16.24.1, 00:00:00, Serial0
R
172.16.22.0 [120/2] via 172.16.24.1, 00:00:00, Serial0
R
172.16.18.0 [120/1] via 172.16.24.1, 00:00:00, Serial0
Ex a m ple 5 - 3 1 . Rou t e t a ble s of RTC a n d RTD , e x a m in e d a ppr ox im a t e ly
6 0 se con ds a ft e r Ex a m ple 5 - 3 0 .
RTC#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route, o - ODR
Gateway of last resort is not set
172.16.0.0/23 is subnetted, 5 subnets
C
172.16.24.0 is directly connected, Serial0
R
172.16.26.0/23 is possibly down,
routing via 172.16.24.2, Serial0
R
172.16.20.0 [120/1] via 172.16.18.5, 00:00:19, Ethernet0
R
172.16.22.0 [120/1] via 172.16.18.4, 00:00:24, Ethernet0
C
172.16.18.0 is directly connected, Ethernet0
________________________________________________________________________________
RTD#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route
Gateway of last resort is not set
172.16.0.0/16 is subnetted, 5 subnets
C
172.16.24.0 is directly connected, Serial0
C
172.16.26.0 is directly connected, TokenRing0
R
172.16.20.0 [120/2] via 172.16.24.1, 00:00:15, Serial0
R
172.16.22.0 [120/2] via 172.16.24.1, 00:00:15, Serial0
R
172.16.18.0 [120/1] via 172.16.24.1, 00:00:15, Serial0
Ex a m ple 5 - 3 2 . Rou t e t a ble s of RTC a n d RTD , e x a m in e d a ppr ox im a t e ly
1 2 0 se con ds a ft e r Ex a m ple 5 - 3 1 .
RTC#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route, o - ODR
Gateway of last resort is not set
172.16.0.0/23 is subnetted, 5 subnets
C
172.16.24.0 is directly connected, Serial0
R
172.16.26.0 [120/1] via 172.16.24.2, 00:00:09, Serial0
R
172.16.20.0 [120/1] via 172.16.18.5, 00:00:11, Ethernet0
R
172.16.22.0 [120/1] via 172.16.18.4, 00:00:18, Ethernet0
C
172.16.18.0 is directly connected, Ethernet0
________________________________________________________________________________
RTD#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route
Gateway of last resort is not set
172.16.0.0/16 is subnetted, 5 subnets
C
172.16.24.0 is directly connected, Serial0
C
172.16.26.0 is directly connected, TokenRing0
R
172.16.20.0 [120/2] via 172.16.24.1, 00:00:19, Serial0
R
R
172.16.22.0 [120/2] via 172.16.24.1, 00:00:19, Serial0
172.16.18.0 [120/1] via 172.16.24.1, 00:00:19, Serial0
Chapter 6. RIPv2, RIPng, and Classless
Routing
This chapt er covers t he following subj ect s:
Operat ion of RI Pv2
Operat ion of RI Png
Configuring RI Pv2
Configuring RI Png
Troubleshoot ing RI Pv2 and RI Png
RI P Version 2 ( RI Pv2) is defined in RFC 1723 [ 1] and is support ed in I OS Versions 11.1 and lat er.
RI Pv2 is not a new prot ocol; rat her, it is RI Pv1 wit h som e ext ensions t o bring it m ore up t o dat e
wit h m odern rout ing environm ent s. These ext ensions are
[1]
Supplemental to this RFC are RFC 1721, "RIP Version 2 Protocol Analysis," and RFC 1722, "RIP Version 2 Protocol
Applicability Statement."
Subnet m asks carried wit h each rout e ent ry
Aut hent icat ion of rout ing updat es
Next - hop addresses carried wit h each rout e ent ry
Ext ernal rout e t ags
Mult icast rout e updat es
The m ost im port ant of t hese ext ensions is t he addit ion of a Subnet Mask field t o t he rout ing
updat e ent ries, enabling t he use of variable- lengt h subnet m asks and qualifying RI Pv2 as a
classless rout ing prot ocol.
RI Pv2 is t he first of t he classless rout ing prot ocols discussed in t his book. As such, t his chapt er
serves as an int roduct ion t o classless rout ing, and t o RI Pv2.
RI P next generat ion ( RI Png) , a m odificat ion of RI Pv2 for rout ing I Pv6, is also covered in t his
chapt er. Unlike I Pv4, I Pv6 is inherent ly classless; t here are no class A, B, and C, or sim ilar
address groupings. Therefore RI Png is also a classless rout ing prot ocol.
Operation of RIPv2
All of t he operat ional procedures, t im ers, and st abilit y funct ions of RI Pv1 rem ain t he sam e in
Version 2, wit h t he except ion of t he broadcast updat es. RI Pv2 m ult icast s updat es t o ot her
RI Pv2- speaking rout ers, using t he reserved class D address 224.0.0.9. The advant age of
m ult icast ing is t hat devices on t he local net work t hat are not concerned wit h RI P rout ing do not
have t o spend t im e " unwrapping" broadcast packet s from t he rout er. The m ult icast updat es are
exam ined furt her in t he sect ion, "Com pat ibilit y wit h RI Pv1."
Aft er a look at how t he RI P m essage form at accom m odat es t he Version 2 ext ensions, t his
sect ion focuses on t he operat ion and benefit s of t hese addit ional feat ures.
RIPv2 Message Format
The RI Pv2 m essage form at is shown in Figure 6- 1 ; t he basic st ruct ure is t he sam e as for RI Pv1.
All t he ext ensions t o t he original prot ocol are carried wit hin what were unused fields. Like
Version 1, RI Pv2 updat es can cont ain ent ries for up t o 25 rout es. Also like Version 1, RI Pv2
operat es from UDP port 520 and has a m axim um dat agram size ( wit h an eight - byt e UDP header)
of 512 oct et s.
Figu r e 6 - 1 . RI Pv2 t a k e s a dva n t a ge of t h e u n u se d fie lds of t h e Ve r sion
1 m e ssa ge so t h a t t h e e x t e n sion s do n ot ch a n ge t h e ba sic for m a t .
Com m a n d will always be set t o eit her one, signifying a request m essage, or t wo, signifying
a response m essage.
V e r sion will be set t o t wo for RI Pv2. I f it is set t o zero, or if it is set t o one but t he
m essage is not a valid RI Pv1 form at , t he m essage will be discarded. RI Pv2 will process
valid RI Pv1 m essages.
Addr e ss Fa m ily I de n t ifie r is set t o t wo for I Pv4. The only except ion is a request for a
rout er's ( or host 's) full rout ing t able, in which case it will be set t o zero.
Rou t e Ta g provides a field for t agging ext ernal rout es or rout es t hat have been
redist ribut ed int o t he RI Pv2 process. One suggest ed use of t his 16- bit field is t o carry t he
aut onom ous syst em num ber of rout es t hat have been im port ed from an ext ernal rout ing
prot ocol. Alt hough RI P it self does not use t his field, ext ernal rout ing prot ocols connect ed t o
a RI P dom ain in m ult iple locat ions m ay use t he rout e t ag field t o exchange inform at ion
across t he RI P dom ain. The field m ay also be used t o group cert ain ext ernal rout es for
easier cont rol wit hin t he RI P dom ain. The use of rout e t ags is discussed furt her in Chapt er
14 , " Rout e Maps."
I P Addr e ss is t he I Pv4 address of t he dest inat ion of t he rout e. I t m ay be a m aj or net work
address, a subnet , or a host rout e.
Su bn e t M a sk is 32- bit m ask t hat ident ifies t he net work and subnet port ion of t he I Pv4
address. The significance of t his field is discussed in t he sect ion "Variable- Lengt h Subnet
Masking."
N e x t H op ident ifies a bet t er next - hop address, if one exist s, t han t he address of t he
advert ising rout er. That is, it indicat es a next - hop address, on t he sam e subnet , t hat is
m et rically closer t o t he dest inat ion t han t he advert ising rout er is. I f t he field is set t o all
zeros ( 0.0.0.0) , t he address of t he advert ising rout er is t he best next - hop address. An
exam ple of where t his field would be useful is given at t he end of t his sect ion.
M e t r ic is a hop count bet ween 1 and 16.
Figure 6- 2 shows four rout ers connect ed t o an Et hernet link. [ 2] Jicarilla, Mescalero, and
Chiricahua are all in aut onom ous syst em num ber 65501 and are speaking RI Pv2. Chiricahua is a
border rout er bet ween aut onom ous syst em 65501 and aut onom ous syst em 65502; in t he
second aut onom ous syst em , it speaks BGP t o Lipan.
[2]
This figure is an adaptation of an example presented by Gary Malkin in RFC 1722.
Figu r e 6 - 2 . Alt h ou gh t h e y sh a r e a com m on da t a lin k , Jica r illa a n d
M e sca le r o spe a k on ly RI Pv2 ; Lipa n spe a k s on ly BGP. Ch ir ica h u a is
r e spon sible for in for m in g t h e fir st t w o r ou t e r s of a n y r ou t e s le a r n e d
fr om t h e la t t e r .
Here, Chiricahua is advert ising rout es it learns from BGP t o t he RI P- speaking rout ers ( Figure 63) . [ 3] I n it s RI Pv2 advert isem ent s, Chiricahua will use t he Rout e Tag field t o indicat e t hat subnet
10.3.3.0, wit h a m ask of 255.255.255.0, is in aut onom ous syst em 65502 ( 0xFFDE) . Chiricahua
will also use t he Next Hop field t o inform Jicarilla and Mescalero t hat t he best next - hop address
t o 10.3.3.0 is Lipan's int erface, 10.1.1.3, rat her t han it s own int erface. Not e t hat because Lipan
does not run RI P, and Jicarilla and Mescalero do not run BGP, Jicarilla and Mescalero have no
way of knowing direct ly t hat Lipan is t he best next - hop rout er, even t hough it is reachable on
t he sam e subnet .
[3]
Redistribution refers to the practice of advertising routes learned from one protocol to another protocol; it is discussed in
detail in Chapter 11, "Route Redistribution."
Figu r e 6 - 3 . Th is pr ot ocol ca pt u r e of a RI Pv2 u pda t e fr om Ch ir ica h u a
sh ow s t h e Rou t e Ta g, Su bn e t M a sk , a n d N e x t H op fie lds be in g u se d t o
a dve r t ise su bn e t 1 0 .3 .3 .0 .
[View full size image]
Compatibility with RIPv1
RI Pv1 handles updat es in a flexible m anner. I f t he Version field indicat es Version 1 but any bit s
of any unused fields are set t o one, t he updat e is discarded. I f t he version is great er t han one,
t he fields defined as unused in Version 1 are ignored and t he m essage is processed. As a result ,
newer edit ions of t he prot ocol, like RI Pv2, can be backward- com pat ible wit h RI Pv1.
RFC 1723 defines a " com pat ibilit y swit ch" wit h four set t ings, which allows Versions 1 and 2 t o
int eroperat e:
1 . RI P- 1 , in which only RI Pv1 m essages are t ransm it t ed
2 . RI P- 1 Com pat ibilit y, which causes RI Pv2 t o broadcast it s m essages inst ead of m ult icast
t hem so t hat RI Pv1 m ay receive t hem
3 . RI P- 2 , in which RI Pv2 m essages are m ult icast t o dest inat ion address 224.0.0.9
4.
4 . None, in which no updat es are sent
The RFC recom m ends t hat t hese swit ches be configurable on a per int erface basis. The Cisco
com m ands for set t ings 1 t hrough 3 are present ed in t he sect ion " Configuring RI Pv2" ; set t ing 4 is
accom plished by using t he pa ssive - in t e r fa ce com m and.
Addit ionally, RFC 1723 defines a " receive cont rol swit ch" t o regulat e t he recept ion of updat es.
The four recom m ended set t ings of t his swit ch are
1 . RI P- 1 Only
2 . RI P- 2 Only
3 . Bot h
4 . None
This swit ch should also be configurable on a per int erface basis. The Cisco com m ands for
set t ings 1 t hrough 3 are also present ed in t he configurat ion sect ion of t his chapt er. Set t ing 4 can
be accom plished by using an access list t o filt er UDP source port 520, by not including a net work
st at em ent for t he int erface, [ 4] or by configuring a rout e filt er as discussed in Chapt er 13, " Rout e
Filt ering."
[4]
This method would work only if no other interface on the router on which RIP should run is attached to the same major
network.
Classless Route Lookups
Chapt er 5, " Rout ing I nform at ion Prot ocol ( RI P) ," explains classful rout e lookups, in which a
dest inat ion address is first m at ched t o it s m aj or net work address in t he rout ing t able and is t hen
m at ched t o a subnet of t he m aj or net work. I f no m at ch is found at eit her of t hese st eps, t he
packet is dropped.
Classful rout e lookup was t he default I OS behavior unt il 11.3, when t he default rout e lookup
behavior was changed t o classless. For earlier I OS versions you can enable classless rout e
lookup, even for classful rout ing prot ocols such as RI Pv1 and I GRP, by ent ering t he global
com m and ip cla ssle ss. When a rout er perform s classless rout e lookups, it does not pay
at t ent ion t o t he class of t he dest inat ion address. I nst ead, it perform s a bit - by- bit best m at ch
bet ween t he dest inat ion address and all it s known rout es. This capabilit y can be very useful
when working wit h default rout es, as dem onst rat ed in Chapt er 12, " Default Rout es and OnDem and Rout ing." When coupled wit h t he ot her feat ures of classless rout ing prot ocols, classless
rout e lookups can be very powerful.
Classless Routing Protocols
The t rue defining charact erist ic of classless rout ing prot ocols is t he capabilit y t o carry subnet
m asks in t heir rout e advert isem ent s. One benefit of having a m ask associat ed wit h each rout e is
t hat t he all- zeros and all- ones subnet s are now available for use. Chapt er 1, " TCP/ I P Review,"
explained t hat classful rout ing prot ocols cannot dist inguish bet ween an all- zeros subnet
( 172.16.0.0, for exam ple) and t he m aj or net work num ber ( 172.16.0.0) . Likewise, t hey cannot
dist inguish bet ween a broadcast on t he all- ones subnet ( 172.16.255. 255) and an all- subnet s
broadcast ( 172.16.255.255) .
I f t he subnet m asks are included, t his difficult y disappears. You can readily see t hat
172.16.0.0/ 16 is t he m aj or net work num ber and t hat 172.16.0.0/ 24 is an all- zeros subnet .
172.168.255.255/ 16 and 172.16.255.255/ 24 are j ust as dist inguishable.
By default , t he Cisco I OS rej ect s an at t em pt t o configure an all- zeros subnet as an invalid
address/ m ask com binat ion even if a classless rout ing prot ocol is running. To override t his default
behavior, ent er t he global com m and ip su bn e t - ze r o.
A m uch great er benefit of having a subnet m ask associat ed wit h each rout e is being able t o use
variable- lengt h subnet m asking ( VLSM) and t o sum m arize a group of m aj or net work addresses
wit h a single aggregat e address. Variable- lengt h subnet m asks are exam ined in t he following
sect ion, and address aggregat ion ( or supernet t ing) is int roduced in Chapt er 7, " Enhanced
I nt erior Gat eway Rout ing Prot ocol ( EI GRP) ."
Variable-Length Subnet Masking
I f a subnet m ask can be individually associat ed wit h each dest inat ion address advert ised
t hroughout a net work, t here is no reason why all t he m asks m ust be of equal lengt h. That fact is
t he basis for VLSM.
A sim ple applicat ion of VLSM is shown in Figure 6- 4 . Each dat a link of t he net work shown m ust
have a uniquely ident ifiable subnet address, and each subnet address m ust cont ain enough host
addresses t o accom m odat e t he devices at t ached t o t he dat a link.
Figu r e 6 - 4 . Usin g VLSM , t h e cla ss C a ddr e ss sh ow n ca n be su bn e t t e d
t o a ccom m oda t e t h is n e t w or k a n d t h e h ost s on e a ch of it s da t a lin k s.
Given t he class C net work address assigned t o t his net work, subnet t ing cannot be accom plished
at all wit hout VLSM. The t oken ring, wit h it s need for 100 host addresses, requires a 25- bit m ask
( 1 bit of subnet t ing) ; a m ask any longer would not leave enough host bit s. But if all m asks m ust
be of equal lengt h, only one m ore subnet can be creat ed from t he class C address. [ 5] There
would not be enough subnet s t o go around.
[5]
This statement assumes that the all-zeros and all-ones subnetsthe only subnets available with a single bit of
subnettingcan be routed.
Wit h VLSM t he widely varying host address requirem ent s of t he net work of Figure 6- 4 can be
m et using a class C net work address. Table 6- 1 shows t he subnet s and t he address ranges
available wit hin each.
Ta ble 6 - 1 . Th e su bn e t s of Figu r e 6 - 4 .
Su bn e t / M a sk
Addr e ss Ra n ge
Br oa dca st Addr e ss
192.168.50.0/ 25
192.168.50.1192.168.50.126
192.168.50.127
192.168.50.128/ 26
192.168.50.129192.168.50.190 192.168.50.191
192.168.50.192/ 27
192.168.50.193192.168.50.222 192.168.50.223
192.168.50.224/ 28
192.168.50.225192.168.50.238 192.168.50.239
192.168.50.240/ 30
192.168.50.241192.168.50.242 192.168.50.243
192.168.50.244/ 30
192.168.50.245192.168.50.246 192.168.50.247
Many people, including m any who work wit h VLSM, m ake t he t echnique m ore com plicat ed t han it
is. The com plet e key t o VLSM is t his: Aft er a net work address is subnet t ed in t he st andard
fashion, t hose subnet s can t hem selves be subnet t ed. I n fact , one will occasionally hear VLSM
referred t o as " sub- subnet t ing."
A close exam inat ion of t he addresses in Table 6- 1 ( in binary, as always) will reveal how VLSM
works. [ 6] First , a 25- bit m ask is used t o divide t he net work address int o t wo subnet s:
192.168.50.0/ 25 and 192.168.50.128/ 25. The first subnet provides 126 host addresses t o m eet
t he needs of t he t oken ring in Figure 6- 4 .
[6]
The reader is strongly encouraged to work through this entire example in binary.
From Chapt er 1, you know t hat subnet t ing involves expanding t he default net work m ask so t hat
som e host bit s are int erpret ed as net work bit s. This sam e procedure is applied t o t he rem aining
subnet 192.168.50.128/ 25. One of t he Et hernet s requires 50 host addresses, so t he m ask of t he
rem aining subnet is expanded t o 26 bit s. This st ep provides t wo sub- subnet s,
192.168.50.128/ 26 and 192.168.192/ 26, each wit h 62 available host addresses. The first subsubnet is t aken for t he larger Et hernet , leaving t he second t o again be subnet t ed for t he ot her
dat a links.
This procedure is repeat ed t wice m ore t o provide t he necessary subnet s of t he necessary size for
t he sm aller Et hernet and t he FDDI ring. A subnet of 192.168.50.240/ 28 rem ains, as do t wo
serial links requiring subnet s. Any point - t o- point link will, by it s very nat ure, require only t wo
host addressesone at each end. Thirt y- bit m asks are used t o creat e t he t wo serial link subnet s,
each wit h j ust t wo available host addresses.
Point - t o- point links, requiring a subnet address but only t wo host addresses per subnet , are one
j ust ificat ion for using VLSM. For exam ple, Figure 6- 5 shows a t ypical WAN t opology wit h rem ot e
rout ers connect ed via Fram e Relay PVCs t o a hub rout er. Modern pract ice usually calls for each
of t hese PVCs t o be configured on a point - t o- point subint erface. [ 7] Wit hout VLSM, equal- size
subnet s would be necessary; t he size would be dict at ed by t he subnet wit h t he largest num ber
of host devices.
[7]
Subinterfaces are logical interfaces configured on a physical interface. Many subinterfaces can be configured on a single
physical interface, and each subinterface can have its own IP address; routing protocols treat them the same as physical
interfaces. Subinterfaces are particularly useful with Frame Relay, ATM, and VLANs. Readers who are not already familiar
with these useful tools are referred to the Cisco Configuration Guide.
Figu r e 6 - 5 . VLSM a llow s e a ch of t h e se PVCs t o be con figu r e d a s a
se pa r a t e su bn e t w it h ou t w a st in g h ost a ddr e sse s.
Suppose a class B address is used for t he net work in Figure 6- 5 and each rout er is at t ached t o
several LANs, each of which m ay have up t o 175 at t ached devices. A 24- bit m ask would be
necessary for each subnet , including each PVC. Consequent ly, for every PVC in t he net work, 252
addresses are wast ed. Wit h VLSM, a single subnet can be select ed and sub- subnet t ed wit h a 30bit m ask; enough subnet s will be creat ed for up t o 64 point - t o- point links ( Figure 6- 6 ) .
Figu r e 6 - 6 . Th is cla ss B a ddr e ss h a s be e n su bn e t t e d w it h a 2 4 - bit
m a sk . 1 7 2 .1 7 .1 1 .0 h a s be e n su b- su bn e t t e d w it h a 3 0 - bit m a sk ; t h e
r e su lt in g 6 4 su bn e t s ca n be a ssign e d t o poin t - t o- poin t lin k s.
Exam ples of VLSM address designs appear in t his and subsequent chapt ers. Chapt er 7
int roduces anot her m aj or j ust ificat ion for using VLSM, hierarchical addressing, and address
aggregat ion.
Authentication
A securit y concern wit h any rout ing prot ocol is t he possibilit y of a rout er accept ing invalid
rout ing updat es. The source of invalid updat es m ay be an at t acker t rying t o m aliciously disrupt
t he net work or t rying t o capt ure packet s by t ricking t he rout er int o sending t hem t o t he wrong
dest inat ion. A m ore m undane source of invalid updat es m ay be a m alfunct ioning rout er. RI Pv2
includes t he capabilit y t o aut hent icat e t he source of a rout ing updat e by including a password.
Aut hent icat ion is support ed by m odifying what would norm ally be t he first rout e ent ry of t he RI P
m essage, as shown in Figure 6- 7 . Wit h aut hent icat ion, t he m axim um num ber of ent ries a single
updat e can carry is reduced t o 24. The presence of aut hent icat ion is indicat ed by set t ing t he
Address Fam ily I dent ifier field t o all ones ( 0xFFFF) . The Aut hent icat ion Type for sim ple password
aut hent icat ion is t wo ( 0x0002) , and t he rem aining 16 oct et s carry an alphanum eric password of
up t o 16 charact ers. The password is left - j ust ified in t he field, and if t he password is less t han 16
oct et s, t he unused bit s of t he field are set t o zero.
Figu r e 6 - 7 . Th e RI Pv2 a u t h e n t ica t ion in for m a t ion , w h e n con figu r e d, is
ca r r ie d in t h e fir st r ou t e e n t r y spa ce .
Figure 6- 8 shows an analyzer capt ure of a RI Pv2 m essage wit h aut hent icat ion. The figure also
shows a difficult y wit h t he default RI P aut hent icat ion: The password is t ransm it t ed in plain t ext .
Anyone who can capt ure a packet cont aining a RI Pv2 updat e m essage can read t he
aut hent icat ion password.
Figu r e 6 - 8 . W h e n sim ple pa ssw or d a u t h e n t ica t ion is u se d, t h e
pa ssw or d is ca r r ie d in pla in t e x t a n d ca n be r e a d by a n yon e w h o ca n
" sn iff" t h e pa ck e t ca r r yin g t h e u pda t e .
[View full size image]
Alt hough RFC 1723 describes only sim ple password aut hent icat ion, foresight is shown by
including t he Aut hent icat ion Type field. Cisco I OS t akes advant age of t his feat ure and provides
t he opt ion of using MD5 aut hent icat ion inst ead of sim ple password aut hent icat ion. [ 8]
[8]
MD5 is described in RFC 1321. A good discussion of MD5 can also be found in the following book: Charlie Kaufman,
Radia Perlman, and Mike Spencer, Network Security: Private Communication in a Public World. Prentice Hall, 1995, pp.
120122.
Cisco uses t he first and last rout e ent ry spaces for MD5 aut hent icat ion purposes.
MD5 is a one- way m essage digest or secure hash funct ion, produced by RSA Dat a Securit y, I nc.
I t is also occasionally referred t o as a crypt ographic checksum because it works in som ewhat t he
sam e way as an arit hm et ic checksum . MD5 com put es a 128- bit hash value from a plain t ext
m essage of arbit rary lengt h ( a RI Pv2 updat e, for inst ance) and a password. This " fingerprint " is
t ransm it t ed along wit h t he m essage. The receiver, knowing t he sam e password, calculat es it s
own hash value. I f not hing in t he m essage has changed, t he receiver's hash value should m at ch
t he sender's value t ransm it t ed wit h t he m essage.
Figure 6- 9 shows an updat e from t he sam e rout er of Figure 6- 8 , but wit h MD5 aut hent icat ion.
The aut hent icat ion t ype is 3, and no password can be seen.
Figu r e 6 - 9 . Th is u pda t e w a s or igin a t e d fr om t h e sa m e r ou t e r a s t h e
u pda t e in Figu r e 6 - 8 , bu t M D 5 a u t h e n t ica t ion is be in g u se d.
[View full size image]
Operation of RIPng
RI Png for I Pv6 is based on RI Pv2, but it is not an ext ension of RI Pv2; it is an ent irely separat e
prot ocol. RI Png does not support I Pv4, so t o use RI P t o rout e bot h I Pv4 and I Pv6, you m ust run
RI Pv1 or v2 for I Pv4 and RI Png for I Pv6.
RI Png uses t he sam e t im ers, procedures, and m essage t ypes as RI Pv2. For exam ple, like RI Pv2
it uses a 30- second updat e t im er j it t ered t o prevent m essage synchronizat ion, a 180- second
t im eout period, a 120- second garbage- collect ion t im er, and a 180- second holddown t im er. I t
uses t he sam e hop- count m et ric, wit h 16 indicat ing an unreachable value. And, it uses Request
and Response m essages in t he sam e way t hat RI Pv2 does. And, like RI Pv2, Request and
Response m essages are m ult icast wit h t he sam e few unicast except ions t hat RI Pv1 and v2 use.
The I Pv6 m ult icast address used by RI Png is FF02: : 9.
An except ion t o t hese parallel funct ions is aut hent icat ion. RI Png does not have an aut hent icat ion
m echanism of it s own, but inst ead relies on t he aut hent icat ion feat ures built int o I Pv6.
There is, of course, no need for t he RI Pv1 com pat ibilit y swit ches used by RI Pv2, because t here is
no backward support for I Pv4.
Figure 6- 10 shows t he RI Png m essage form at . Unlike RI Pv1 and v2, which run at UDP port 520,
RI Png sends and receives it s m essages at UDP port 521. Also unlike RI Pv1 and v2, t here is no
set m essage size. The m essage size is dependent only on t he MTU of t he link on which it is being
sent .
Figu r e 6 - 1 0 . Th e RI Pn g m e ssa ge for m a t .
Com m a n d is always set t o 1, indicat ing a Request m essage, or t o 2, indicat ing a Response
m essage.
V e r sion is always set t o 1, t hat is, t he current version of RI Png in RI Pngv1.
I Pv6 Pr e fix is t he 128- bit I Pv6 dest inat ion prefix of t he rout e ent ry.
Rou t e Ta g is used in t he sam e way t he 16- bit RI Pv2 Rout e Tag field is used: for
t ransport ing ext ernal rout e at t ribut es across t he RI P dom ain.
Pr e fix Le n gt h is an 8- bit field specifying, in bit s, t he significant part of t he address in t he
I Pv6 Prefix field. For exam ple, if t he advert ised prefix is 3ffe: 2100: 1201: : / 48, t he value in
t he Prefix Lengt h field is 48 ( 0x30) . I f t he advert ised rout e ent ry is a default rout e, t he
I Pv6 prefix is 0: 0: 0: 0: 0: 0: 0: 0 and t he Prefix Lengt h is 0.
M e t r ic is t he sam e hop count m et ric used by RI Pv1 and v2. But as t he m axim um possible
value is 16, t he field is reduced t o 8 bit s from t he unnecessarily large 16 bit s of RI Pv1 and
v2.
RI Png specifies a next - hop address t he sam e way t hat RI Pv2 does. That is, a valid non- zero
next - hop address specifies a next - hop rout er ot her t han t he originat or of t he Response m essage
and a next - hop address of 0: 0: 0: 0: 0: 0: 0: 0 specifies t he originat or of t he Response m essage.
But rat her t han associat e a next - hop address wit h each rout e ent ry as RI Pv2 does, RI Png
specifies t he next - hop address in a special rout e ent ry and t hen groups all rout e ent ries t hat use
t he next - hop address aft er it . That is, t he next - hop address specified in a next - hop rout e ent ry
applies t o all of t he rout e ent ries following it , eit her t o t he end of t he Response m essage or unt il
anot her special next - hop rout e ent ry is found.
Figure 6- 11 shows t he form at of t he next - hop rout e ent ry. The 128- bit address is eit her t he I Pv6
address of anot her rout er or, if it is : : , specifies t he address of t he originat or. The Rout e Tag and
Prefix Lengt h fields are set t o all zeroes. Receiving rout ers recognize t he next - hop rout e ent ry
because it s Met ric field is set t o all ones ( 0xFF) .
Figu r e 6 - 1 1 . A m e t r ic va lu e of a ll on e s spe cifie s t h a t t h e r ou t e e n t r y is
a n e x t - h op r ou t e e n t r y. All r ou t e e n t r ie s follow in g t h is on e , u n t il t h e
e n d of t h e m e ssa ge or u n t il a n ot h e r n e x t - h op r ou t e e n t r y is
e n cou n t e r e d, u se t h is n e x t - h op a ddr e ss.
Configuring RIPv2
Because RI Pv2 is m erely an enhancem ent of RI Pv1 and not a separat e prot ocol, t he com m ands
int roduced in Chapt er 5, " Rout ing I nform at ion Prot ocol ( RI P) ," for m anipulat ing t im ers and
m et rics, and for configuring unicast updat es or no updat es at all, are used in exact ly t he sam e
way. Aft er a brief look at configuring a RI Pv2 process, t he rest of t his sect ion concent rat es on
configuring t he new ext ensions.
Case Study: A Basic RIPv2 Configuration
By default , a RI P process configured on a Cisco rout er sends only RI Pv1 m essages but list ens t o
bot h RI Pv1 and RI Pv2. This default is changed wit h t he ve r sion com m and, as in Exam ple 6- 1.
Ex a m ple 6 - 1 . Th e ve r sion 2 com m a n d ca u se s RI P t o se n d a n d list e n t o
RI Pv2 m e ssa ge s on ly.
router rip
version 2
network 172.25.0.0
network 192.168.50.0
I n t his m ode, t he rout er sends and receives only RI Pv2 m essages. Likewise, t he rout er can be
configured t o send and receive only RI Pv1 m essages, as in Exam ple 6- 2.
Ex a m ple 6 - 2 . Th e ve r sion 1 com m a n d ca u se s RI P t o se n d a n d list e n t o
RI Pv1 m e ssa ge s on ly.
router rip
version 1
network 172.25.0.0
network 192.168.50.0
The default behavior can be rest ored by ent ering t he com m and n o ve r sion in config- rout er
m ode.
Case Study: Compatibility with RIPv1
The int erface- level " com pat ibilit y swit ches" recom m ended by RFC 2453 are im plem ent ed in
Cisco I OS wit h t he com m ands ip r ip se n d ve r sion and ip r ip r e ce ive ve r sion .
The net work in Figure 6- 12 cont ains rout ers speaking bot h RI Pv1 and RI Pv2. Addit ionally,
Poj oaque is a Linux host running rout ed, which underst ands only RI Pv1. The configurat ion of
Taos is displayed in Exam ple 6- 3.
Figu r e 6 - 1 2 . Ta os is r u n n in g RI Pv2 bu t m u st a lso spe a k Ve r sion 1 t o
som e de vice s.
Ex a m ple 6 - 3 . Ta os's con figu r a t ion .
interface Ethernet0
ip address 192.168.50.129 255.255.255.192
ip rip send version 1
ip rip receive version 1
!
interface Ethernet1
ip address 172.25.150.193 255.255.255.240
ip rip send version 1 2
!
interface Ethernet2
ip address 172.25.150.225 255.255.255.240
!
router rip
version 2
network 172.25.0.0
network 192.168.50.0
Because rout er Laguna is a RI Pv1 speaker, E0 of Taos is configured t o send and receive RI Pv1
updat es. E1 is configured t o send bot h Version 1 and 2 updat es, t o accom m odat e t he RI Pv1 at
Poj oaque and t he RI Pv2 at Sandia. E2 has no special configurat ion; it sends and receives Version
2 by default .
I n Exam ple 6- 4, de bu g ip r ip is used t o observe t he m essages sent and received by Taos. There
are several point s of int erest here. First , not ice t he difference bet ween t he t raps for RI Pv1 and
RI Pv2 m essages. The address m ask and t he Next Hop and Rout e Tag fields ( bot h set t o all
zeros, in t his case) of t he RI Pv2 updat es can be observed. Second, it can be observed t hat
int erface E1 is broadcast ing RI Pv1 updat es and m ult icast ing RI Pv2 updat es. Third, because Taos
has not been configured t o receive RI Pv1, t he updat es from Poj oaque ( 172.25.150.206) are
being ignored. ( Poj oaque has been m isconfigured and is broadcast ing it s rout ing t able.) [ 9]
[9]
Intentionally misconfigured for this example actually, with the routed -s option.
Ex a m ple 6 - 4 . Usin g de bu ggin g, t h e RI P ve r sion s se n t a n d r e ce ive d by
Ta os ca n be obse r ve d.
Taos#debug ip rip
RIP protocol debugging is on
Taos#
RIP: received v2 update from 172.25.150.194 on Ethernet1
172.25.150.32/28 - 0.0.0.0 in 1 hops
RIP: ignored v1 packet from 172.25.150.206 (illegal version)
RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.50.129)
network 172.25.0.0, metric 1
RIP: sending v1 update to 255.255.255.255 via Ethernet1 (172.25.150.193)
subnet 172.25.150.224, metric 1
network 192.168.50.0, metric 1
RIP: sending v2 update to 224.0.0.9 via Ethernet1 (172.25.150.193)
172.25.150.224/28 - 0.0.0.0, metric 1, tag 0
192.168.50.0/24 - 0.0.0.0, metric 1, tag 0
RIP: sending v2 update to 224.0.0.9 via Ethernet2 (172.25.150.225)
172.25.150.32/28 - 0.0.0.0, metric 2, tag 0
172.25.150.192/28 - 0.0.0.0, metric 1, tag 0
192.168.50.0/24 - 0.0.0.0, metric 1, tag 0
RIP: received v1 update from 192.168.50.130 on Ethernet0
192.168.50.64 in 1 hops
RIP: received v2 update from 172.25.150.194 on Ethernet1
172.25.150.32/28 - 0.0.0.0 in 1 hops
Perhaps t he m ost im port ant observat ion t o be m ade from Exam ple 6- 4 concerns t he updat e
being broadcast t o Poj oaque: I t does not include subnet 172.25.150.32. Taos knows t his subnet ,
having learned it via m ult icast RI Pv2 updat es from Sandia. But Poj oaque cannot receive t hose
m ult icast s because it speaks only RI Pv1. Moreover, alt hough Taos knows t he subnet , t he split
horizon rule prevent s Taos from advert ising it out t he sam e int erface on which it was learned.
So, Poj oaque does not know about subnet 172.25.150.32. Two rem edies are available: First ,
Sandia could be configured t o send bot h RI P versions. Second, split horizon can be t urned off at
Taos's E1 int erface wit h t he configurat ion in Exam ple 6- 5.
Ex a m ple 6 - 5 . Split h or izon is t u r n e d off h e r e , in Ta os's con figu r a t ion .
interface Ethernet1
ip address 172.25.150.193 255.255.255.240
ip rip send version 1 2
no ip split-horizon
Exam ple 6- 6 shows t he result s. Taos is now including subnet 172.25.150.32 in it s updat es.
Som e foret hought m ust be given t o t he possible consequences of disabling split horizon; Taos is
now not only advert ising 172.25.150.32 t o Poj oaque but also advert ising it back t o Sandia.
Ex a m ple 6 - 6 . W it h split h or izon disa ble d on E1 , Ta os n ow in clu de s
su bn e t 1 7 2 .2 5 .1 5 0 .3 2 in it s u pda t e s t o Poj oa qu e .
Taos#debug ip rip
RIP protocol debugging is on
Taos#
RIP: ignored v1 packet from 172.25.150.206 (illegal version)
RIP: received v2 update from 172.25.150.194 on Ethernet1
172.25.150.32/28 -> 0.0.0.0 in 1 hops
RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.50.129)
network 172.25.0.0, metric 1
RIP: sending v1 update to 255.255.255.255 via Ethernet1 (172.25.150.193)
subnet 172.25.150.32, metric 2
subnet 172.25.150.224, metric 1
subnet 172.25.150.192, metric 1
network 192.168.50.0, metric 1
RIP: sending v2 update to 224.0.0.9 via Ethernet1 (172.25.150.193)
172.25.150.32/28 -> 172.25.150.194, metric 2, tag 0
172.25.150.224/28 -> 0.0.0.0, metric 1, tag 0
172.25.150.192/28 -> 0.0.0.0, metric 1, tag 0
192.168.50.0/24 -> 0.0.0.0, metric 1, tag 0
Case Study: Using VLSM
Referring again t o Figure 6- 12, t he subnet 172.25.150.0/ 24 has been assigned t o t he I nt ernet
shown. That subnet has been furt her subnet t ed t o fit t he various dat a links by expanding t he
m ask t o 28 bit s; t he available sub- subnet s, in binary and dot t ed decim al, are shown in Table 62. Each of t he subnet s [ 10] will have, according t o t he 2 n 2 form ula, 14 host addresses. Out of
t hese, 172.25.150.32, 172.25.150.192, and 172.25.150.224 have been used.
[10]
Now that the concept should be firmly in place, from here on the single term subnet will be used for a subnet, a subsubnet, a sub-sub-subnet, or whatever.
Ta ble 6 - 2 . VLSM is a pplie d t o su bn e t
1 7 2 .2 5 .1 5 0 .0 / 2 4 .
Bin a r y Re pr e se n t a t ion
D ot t e d D e cim a l
11111111111111111111111111110000 255.255.255.240
10101100000110011001011000000000 172.25.150.0/ 28
10101100000110011001011000010000 172.25.150.16/ 28
10101100000110011001011000100000 172.25.150.32/ 28
10101100000110011001011000110000 172.25.150.48/ 28
10101100000110011001011001000000 172.25.150.64/ 28
Bin a r y Re pr e se n t a t ion
D ot t e d D e cim a l
10101100000110011001011001010000 172.25.150.80/ 28
10101100000110011001011001100000 172.25.150.96/ 28
10101100000110011001011001110000 172.25.150.112/ 28
10101100000110011001011010000000 172.25.150.128/ 28
10101100000110011001011010010000 172.25.150.144/ 28
10101100000110011001011010100000 172.25.150.160/ 28
10101100000110011001011010110000 172.25.150.176/ 28
10101100000110011001011011000000 172.25.150.192/ 28
10101100000110011001011011010000 172.25.150.208/ 28
10101100000110011001011011100000 172.25.150.224/ 28
10101100000110011001011011110000 172.25.150.240/ 28
I n Figure 6- 13, a new Et hernet segm ent , Et hernet 3, has been added t o Taos, wit h 60 host s. A
subnet wit h at least six host bit s is required t o accom m odat e t his dat a link. A classful rout ing
prot ocol would require t hat five of t he subnet s from Table 6- 2 be assigned t o Et hernet 3 [ 5 x ( 2 4
2) = 70] , using secondary addresses. Wit h classless prot ocols and VLSM, four of t he subnet s
from Table 6- 2 can be com bined int o a single subnet wit h a 26- bit m ask. This st ep will provide
six host bit s ( 62 host addresses) , and no secondary addressing is necessary. Four subnet s,
172.25.150.64/ 28 t o 172.25.150.112/ 28, are com bined under one 26- bit m ask:
172.25.150.64/ 26. Not ice t hat t he four subnet s are not select ed at random ; t he first 26 m asked
bit s are ident ical and are unique wit hin t he group of 16 subnet s. [ 11]
[11]
The technique used here to combine several addresses into one address serves as an introduction to address
aggregation, covered in Chapter 7.
Figu r e 6 - 1 3 . VLSM ca n be u se d t o a da pt a ddr e sse s t o t h e r e qu ir e m e n t s
of in dividu a l da t a lin k s.
[View full size image]
Also, in Figure 6- 13, four serial links and four rout ers have been added t o t he net work. Wit hout
VLSM, four of t he subnet s from Table 6- 2 would have t o be used for t he four serial links. Wit h
VLSM, a single subnet from Table 6- 2 can be used for all four serial links. 172.25.150.240 is
select ed, and a 30- bit m ask is used t o creat e t he subnet s in Table 6- 3. Each of t he result ing four
subnet s cont ains t wo host addresses.
Ta ble 6 - 3 . A 3 0 - bit m a sk is a pplie d t o su bn e t
1 7 2 .2 5 .1 5 0 .2 4 0 .
Bin a r y Re pr e se n t a t ion
D ot t e d D e cim a l
11111111111111111111111111111100 255.255.255.252
101011000001100110010110111100 00 172.25.150.240/ 30
101011000001100110010110111101 00 172.25.150.244/ 30
101011000001100110010110111110 00 172.25.150.248/ 30
101011000001100110010110111111 00 172.25.150.252/ 30
The fundam ent al obj ect ive of subnet t ing is always t he sam e: A rout er m ust be able t o ident ify
every dat a link wit h a unique address, dist inct from any ot her address in t he net work. That is
t he com m on goal in t he preceding t wo exam ples. I n t he first exam ple, m ult iple addresses were
com bined int o a single address by reducing t he size of t he m ask unt il only t he bit s com m on t o all
of t he addresses rem ain. Not e t hat t his result also happens when subnet s are sum m arized by
t he m aj or net work address. I n t he second exam ple, m ult iple subnet s were creat ed from a single
subnet by expanding t he subnet m ask.
Case Study: Discontiguous Subnets and Classless Routing
Figure 6- 14 shows t hat t wo Et hernet s are connect ed t o each of t he four new rout ers. At each
sit e, one Et hernet is a m em ber of subnet 172.25.150.0/ 24 and will have no m ore t han 12 host s.
This is easy enough. Four unused subnet s are chosen from Table 6- 2 and assigned.
Figu r e 6 - 1 4 . Coch it i, I sle t a , Je m e z, a n d Te su qu e a r e e a ch a t t a ch e d t o
t w o Et h e r n e t s. On e Et h e r n e t a t e a ch r ou t e r is a m e m be r of su bn e t
1 7 2 .2 5 .1 5 0 .0 / 2 4 , a n d t h e ot h e r is a m e m be r of n e t w or k
1 9 2 .1 6 8 .5 0 .0 / 2 4 .
[View full size image]
The ot her Et hernet at each sit e is a m em ber of net work 192.168.50.0 and will have no m ore
t han 25 host s. Subnet s 192.168.50.64/ 26 and 192.168.50.128/ 26 are being used, which leaves
192.168.50.0/ 26 and 192.168.50.192/ 26. By increasing t he m ask t o 27 bit s, t hese t wo subnet s
can be divided int o four, each wit h five host bit senough for 30 host addresses per subnet . Table
6 - 4 shows t he four subnet s in binary.
Ta ble 6 - 4 . Su bn e t 1 9 2 .1 6 9 .5 0 .0 / 2 6 is fu r t h e r
su bn e t t e d w it h a 2 7 - bit m a sk .
Bin a r y Re pr e se n t a t ion
D ot t e d D e cim a l
11111111111111111111111111100000 255.255.255.224
11000000101010001100100000000000 192.169.50.0/ 27
Bin a r y Re pr e se n t a t ion
D ot t e d D e cim a l
11000000101010001100100000100000 192.168.50.32/ 27
11000000101010001100100011000000 192.168.50.192/ 27
11000000101010001100100011100000 192.168.50.224/ 27
Having assigned all subnet addresses, t he next concern is t he fact t hat t he subnet s of
192.168.50.0 are discont iguous. Chapt er 5 present s a case st udy on discont iguous subnet s and
dem onst rat es how t o use secondary int erfaces t o connect t hem . Classless rout ing prot ocols have
no such difficult ies wit h discont iguous subnet s. Because each rout e updat e includes a m ask,
subnet s of one m aj or net work can be advert ised int o anot her m aj or net work.
The default behavior of RI Pv2, however, is t o sum m arize at net work boundaries t he sam e as
RI Pv1. To t urn off sum m arizat ion and allow subnet s t o be advert ised across net work boundaries,
use t he com m and n o a u t o- su m m a r y wit h t he RI P process. The configurat ion for Cochit i is
displayed in Exam ple 6- 7.
Ex a m ple 6 - 7 . Coch it i's con figu r a t ion w it h n o a u t om a t ic su m m a r iza t ion .
interface Ethernet0
ip address 192.168.50.1 255.255.255.224
!
interface Ethernet1
ip address 172.25.150.1 255.255.255.240
!
interface Serial0
ip address 172.25.150.242 255.255.255.252
!
router rip
version 2
network 172.25.0.0
network 192.168.50.0
no auto-summary
I slet a, Jem ez, and Tesuque will have sim ilar configurat ions. Sum m arizat ion m ust also be t urned
off at Taos and at Acom a. Recall from Figure 6- 12 t hat Laguna was running RI Pv1. For t his
configurat ion t o work, it m ust be changed t o Version 2.
Careful considerat ion should be given t o what effect t he variable m asks will have on Poj oaque,
where RI Pv1 cont inues t o run. The debug m essages in Exam ple 6- 8 show t he Version 1 and
Version 2 updat es sent from Taos ont o subnet 172.25.150.192/ 28. The Version 1 updat es will
include only t hose subnet s whose m asks are 28 bit s, t he sam e as t he subnet on which t he
updat es are being broadcast . Alt hough Poj oaque will not receive advert isem ent s for
172.25.150.64/ 26 or any of t he serial link subnet s, an analysis of t hose subnet addresses shows
t hat Poj oaque will, in t his case, correct ly int erpret t he addresses as being different from it s own
subnet . Packet s dest ined for t hese subnet s will be sent t o Taos for rout ing.
Ex a m ple 6 - 8 . Alt h ou gh t h e RI Pv2 u pda t e fr om Ta os in clu de s a ll
su bn e t s in t h e n e t w or k , t h e RI Pv1 u pda t e in clu de s on ly a su m m a r y
r ou t e t o n e t w or k 1 9 2 .1 6 8 .5 0 .0 a n d on ly t h ose su bn e t s of 1 7 2 .2 5 .1 5 0 .0
w h ose m a sk s a r e t h e sa m e a s t h e in t e r fa ce on w h ich t h e u pda t e is
be in g se n t .
Taos#debug ip rip
RIP protocol debugging is on
RIP: sending v1 update to 255.255.255.255 via Ethernet0 (172.25.150.193)
subnet 172.25.150.0, metric 3
subnet 172.25.150.16, metric 3
subnet 172.25.150.32, metric 2
subnet 172.25.150.48, metric 3
subnet 172.25.150.128, metric 3
subnet 172.25.150.192, metric 1
subnet 172.25.150.224, metric 1
network 192.168.50.0, metric 1
RIP: sending v2 update to 224.0.0.9 via Ethernet0 (172.25.150.193)
172.25.150.0/28 -> 0.0.0.0, metric 3, tag 0
172.25.150.16/28 -> 0.0.0.0, metric 3, tag 0
172.25.150.32/28 -> 0.0.0.0, metric 2, tag 0
172.25.150.48/28 -> 0.0.0.0, metric 3, tag 0
172.25.150.64/26 -> 0.0.0.0, metric 1, tag 0
172.25.150.128/28 -> 0.0.0.0, metric 3, tag 0
172.25.150.192/28 -> 0.0.0.0, metric 1, tag 0
172.25.150.224/28 -> 0.0.0.0, metric 1, tag 0
172.25.150.240/30 -> 0.0.0.0, metric 2, tag 0
172.25.150.244/30 -> 0.0.0.0, metric 2, tag 0
172.25.150.248/30 -> 0.0.0.0, metric 2, tag 0
172.25.150.252/30 -> 0.0.0.0, metric 2, tag 0
192.168.50.0/27 -> 0.0.0.0, metric 3, tag 0
192.168.50.32/27 -> 0.0.0.0, metric 3, tag 0
192.168.50.64/26 -> 0.0.0.0, metric 2, tag 0
192.168.50.128/26 -> 0.0.0.0, metric 1, tag 0
192.168.50.192/27 -> 0.0.0.0, metric 3, tag 0
192.168.50.224/27 -> 0.0.0.0, metric 3, tag 0
Case Study: Authentication
The Cisco im plem ent at ion of RI Pv2 m essage aut hent icat ion includes t he choice of sim ple
password or MD5 aut hent icat ion, and t he opt ion of defining m ult iple keys, or passwords, on a
" key chain." The rout er m ay t hen be configured t o use different keys at different t im es.
The st eps for set t ing up RI Pv2 aut hent icat ion follow:
St e p 1 .
Define a key chain wit h a nam e.
St e p 2 .
Define t he key or keys on t he key chain.
St e p 3 .
Enable aut hent icat ion on an int erface and specify t he key chain t o be
used.
St e p 4 .
Specify whet her t he int erface will use clear t ext or MD5 aut hent icat ion.
St e p 5 .
Opt ionally configure key m anagem ent .
I n Exam ple 6- 9, a key chain nam ed Tewa is configured at Taos. Key 1, t he only key on t he
chain, has a password of Kachina; int erface E0 t hen uses t he key, wit h MD5 aut hent icat ion, t o
validat e updat es from Laguna.
Ex a m ple 6 - 9 . Ta os's a u t h e n t ica t ion con figu r a t ion .
key chain Tewa
key 1
key-string Kachina
interface Ethernet 0
ip rip authentication key-chain Tewa
ip rip authentication mode md5
A key chain m ust be configured, even if t here is only one key on it . Alt hough any rout ers t hat
will exchange aut hent icat ed updat es m ust have t he sam e password, t he nam e of t he key chain
has significance only on t he local rout er. Laguna, for inst ance, m ight have a key chain nam ed
Keres, but t he key st ring m ust be Kachina t o speak t o Taos.
I f t he com m and ip r ip a u t h e n t ica t ion m ode m d5 is not added, t he int erface will use t he
default clear t ext aut hent icat ion. Alt hough clear t ext aut hent icat ion m ay be necessary t o
com m unicat e wit h som e RI Pv2 im plem ent at ions, it is alm ost always wise t o use t he far m ore
secure MD5 aut hent icat ion whenever possible.
Key m anagem ent is used t o m igrat e from one aut hent icat ion key t o anot her. I n Exam ple 6- 10,
Laguna is configured t o begin using t he first key at 4: 30 p.m . on July 1, 2004, for 12 hours
( 43200 seconds) . The second key becom es valid at 4: 00 a.m . on July 2, 2004, and will be used
unt il 1: 00 p.m . on Decem ber 31, 2004. The t hird key becom es valid at 12: 30 p.m . on Decem ber
31, 2004, and will rem ain valid perm anent ly aft er t hat .
Ex a m ple 6 - 1 0 . La gu n a 's a u t h e n t ica t ion con figu r a t ion .
key chain Keres
key 1
key-string Kachina
accept-lifetime 16:30:00 Jul 1 2004 duration 43200
send-lifetime 16:30:00 Jul 1 2004 duration 43200
key 2
key-string Kiva
accept-lifetime 04:00:00 Jul 2 2004 13:00:00 Dec 31 2004
send-lifetime 04:00:00 Jul 2 2004 13:00:00 Dec 31 2004
key 3
key-string Koshare
accept-lifetime 12:30:00 Dec 31 2004 infinite
send-lifetime 12:30:00 Dec 31 2004 infinite
!
interface Ethernet0
ip address 198.168.50.130 255.255.255.192
ip rip authentication key-chain Keres
ip rip authentication mode md5
As t he configurat ion shows, t he password t hat is accept ed from ot her rout ers and t he password
t hat is used wit h t ransm it t ed m essages are m anaged separat ely. Bot h t he a cce pt - life t im e and
t he se n d- life t im e com m ands m ust have a specified st art t im e and m ay have eit her a specified
durat ion or end t im e or t he keyword in fin it e . The key num bers are exam ined from t he lowest t o
t he highest , and t he first valid key is used.
Alt hough t his configurat ion uses a 30- m inut e overlap t o com pensat e for differences in syst em
t im es, it is highly recom m ended t hat a t im e synchronizat ion prot ocol such as Net work Tim e
Prot ocol ( NTP) be used wit h key m anagem ent . [ 12]
Configuring RIPng
The st eps for configuring RI Png are t he sam e as RI Pv1 and v2: Creat e t he rout ing process,
enable t he rout ing prot ocol on int erfaces, and perform any desired cust om izat ion. The
com m ands, however, are very different . I n fact , t he creat ion of t he rout ing process and enabling
t he rout ing prot ocol on t he first int erface is accom plished in one st ep, using an int erface
com m and. The case st udies for RI Png will be sim ilar t o t hose of RI Pv1 and v2 t o illust rat e t he
sim ilarit ies in t he processes and t he differences in configurat ion.
Case Study: Basic RIPng Configuration
Aft er I Pv6 unicast rout ing is enabled on t he rout er, only one com m and is required t o enable
RI Png for I Pv6 rout ing. I t is an int erface com m and: ipv6 r ip process- nam e e n a ble . This
creat es t he RI Png process called process- nam e and enables RI Png on t he int erface at t he sam e
t im e. The com m and is ent ered on each int erface t hat will run RI Png.
Figure 6- 15 shows t hat I Pv6, RI Png, and som e new Et hernet int erfaces have been added t o a
port ion of t he net work in Figure 6- 14 .
Figu r e 6 - 1 5 . I Pv6 a ddr e sse s a r e con figu r e d on La gu n a , Ta os, a n d
Sa n dia 's in t e r fa ce s t h a t a r e t o r u n RI Pn g.
[View full size image]
Exam ple 6- 11 shows Taos's configurat ion.
Ex a m ple 6 - 1 1 . Ta os's I Pv6 a n d RI Pn g con figu r a t ion .
ipv6 unicast-routing
interface Ethernet0
ipv6 address 2001:db8:0:6::1/64
ipv6 rip bigMountain enable
interface Ethernet1
ipv6 address 2001:db8:0:4::1/64
ipv6 rip bigMountain enable
interface Ethernet2
ipv6 address 2001:db8:0:5::1/64
ipv6 rip bigMountain enable
The RI Png process is creat ed and act ivat ed on an int erface wit h a single int erface com m and.
This is t he difference bet ween configuring RI Pv1 and v2, and configuring RI Png. Recall t hat t he
RI Pv1 and v2 configurat ion requires a global com m and ( r ou t e r r ip ) t o creat e t he process, and
t he n e t w or k < address > st at em ent t o specify t he int erfaces on which t o run t he RI P process.
Wit h RI Png, when t he int erface com m and ipv6 r ip bigM ou n t a in e n a ble is configured on t he
first int erface, t he RI Png process called bigMount ain is aut om at ically creat ed. I n addit ion, I OS
aut om at ically creat es an ent ry in t he configurat ion ( ipv6 r ou t e r r ip bigM ou n t a in ) for t he
rout ing process.
The process nam e specified on Taos is bigMount ain. Not ice t hat t he process nam e is specified on
each int erface. This nam e is relevant only t o t he local rout er, and is used t o dist inguish bet ween
m ult iple RI Png processes t hat m ight be running on t he rout er. Different int erfaces can each run
a unique RI Png process, wit hout exchanging inform at ion bet ween t hese int erfaces, or m ult iple
processes m ight be running on a single int erface. Only a single RI Pv1 or RI Pv2 process, on t he
ot her hand, can run on a rout er, and an int erface eit her belongs t o t his process, or it doesn't run
RI P. [ 13]
[13] MPLS
VPNs allow multiple RIP processes to run on a single provider edge router. A single RIP process is configured for
a given VPN. MPLS and VPNs are outside the scope of this book.
Exam ple 6- 12 shows Sandia's I Pv6 rout e t able. All t he addresses in t he net work are list ed
because Taos is configured wit h a single RI Png process on each of it s I Pv6 int erfaces.
Ex a m ple 6 - 1 2 . Ta os's I Pv6 r ou t e t a ble .
Sandia#show ipv6 route
IPv6 Routing Table - 16 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C
2001:DB8:0:4::/64 [0/0]
via ::, Ethernet0
L
2001:DB8:0:4::2/128 [0/0]
via ::, Ethernet0
R
2001:DB8:0:5::/64 [120/2]
via FE80::205:5EFF:FE6B:50A1, Ethernet0
R
2001:DB8:0:6::/64 [120/2]
via FE80::205:5EFF:FE6B:50A1, Ethernet0
C
2001:DB8:0:10::/64 [0/0]
via ::, Ethernet1
L
2001:DB8:0:10:2B0:64FF:FE30:1DE0/128 [0/0]
via ::, Ethernet1
C
2001:DB8:0:11::/64 [0/0]
via ::, Ethernet2
L
2001:DB8:0:11:2B0:64FF:FE30:1DE0/128 [0/0]
via ::, Ethernet2
C
L
C
L
R
L
L
2001:DB8:0:12::/64 [0/0]
via ::, Ethernet3
2001:DB8:0:12:2B0:64FF:FE30:1DE0/128 [0/0]
via ::, Ethernet3
2001:DB8:0:13::/64 [0/0]
via ::, Ethernet4
2001:DB8:0:13:2B0:64FF:FE30:1DE0/128 [0/0]
via ::, Ethernet4
2001:DB8:0:18::/64 [120/3]
via FE80::205:5EFF:FE6B:50A1, Ethernet0
FE80::/10 [0/0]
via ::, Null0
FF00::/8 [0/0]
via ::, Null0
Two new Et hernet int erfaces have been added t o Acom a, as shown in Figure 6- 16 . New net work
policy st at es t hat I Pv6 t raffic in t he net work of Figure 6- 16 should be segm ent ed according t o
t he following policy: Host s on t he LANs connect ed t o Sandia access each ot her, and t hey also
access devices on Et hernet 1 connect ed t o Acom a. Host s connect ed t o t he Laguna rout er access
t he devices on Et hernet 2 of Acom a. Sandia and Laguna host s do not need t o access each ot her.
Acom a Et hernet 1 and Et hernet 2 do not access each ot her.
Figu r e 6 - 1 6 . Acom a h a s be e n a dde d t o t h e n e t w or k , w it h t w o I Pv6 e n a ble d Et h e r n e t u se r LAN se gm e n t s.
[View full size image]
The configurat ion in Exam ple 6- 13 is loaded int o Taos.
Ex a m ple 6 - 1 3 . Ta os's con figu r a t ion t o su ppor t n e t w or k policy t o
se gm e n t I Pv6 n e t w or k t r a ffic by cr e a t in g m u lt iple RI Pn g r ou t in g
pr oce sse s.
Interface Ethernet0
ipv6 rip bigMountain enable
Interface Ethernet1
no ipv6 rip bigMountain enable
ipv6 rip smallMountain enable
interface Ethernet2
ipv6 rip bigMountain enable
ipv6 rip smallMountain enable
ipv6 router rip smallMountain
port 527 multicast ff02::9
I nt erface Et hernet 0, t he link t o Laguna, st ill belongs t o t he bigMount ain RI Png process. A new
process, sm allMount ain, is now enabled on Et hernet 1, t he link t o Sandia, and bigMount ain has
been disabled on t he int erface. Bot h processes are enabled on Et hernet 2, connect ing t o Acom a.
No t wo RI Png rout ing processes can use t he sam e UDP port num ber if bot h processes are going
t o be act ive on a single int erface. By changing t he port num ber on t he sm allMount ain process,
Taos sends updat es for sm allMount ain t o UDP port 527, and updat es for t he bigMount ain process
t o t he default RI Png port , UDP 521. Receiving rout ers use t he port num ber t o dist inguish which
rout ing process a received updat e belongs t o. A RI Png rout er running a single rout ing process,
receiving updat es from m ore t hen one RI Png process running on a rout er using ident ical UDP
port num bers, will process each updat e. I f t here is conflict ing inform at ion about an address in
bot h updat es, such as a differing m et ric, t he receiving rout e t able m ay be changing wit h each
updat e. I f a receiving rout er is running m ult iple RI Png processes and t he sam e UDP port num ber
is used on bot h, t he receiving rout er will not be able t o dist inguish which RI Png process should
receive t he updat e. Changing t he UDP port num ber on t he second and subsequent RI Png
process elim inat es t hese problem s. All rout ers and host s t hat need t o part icipat e in t he RI Png
process wit h t he m odified UDP port num ber m ust use t he sam e UDP port num ber. Because
rout ers and ot her TCP/ I P devices use port num bers ident ify which UDP process t he packet s need
t o be forwarded t o, and RI Png updat es are m ult icast t o all RI Png rout ers, t he new UDP port
num ber m ust not be t he sam e as any ot her process running on any RI Png rout er. The
sm allMount ain process is configured t o use port 527 in t his exam ple. The port num ber m ust be
changed on t he rout ers exchanging RI Png updat es wit h t he sm allMount ain RI Png process.
Sandia and Acom a's configurat ion changes follow in Exam ple 6- 14 and Exam ple 6- 15 ,
respect ively.
Ex a m ple 6 - 1 4 . Sa n dia 's RI Pn g con figu r a t ion w it h a m odifie d UD P por t
n u m be r .
ipv6 router rip smallMountain
port 527 multicast-group FF02::9
Ex a m ple 6 - 1 5 . Acom a 's RI Pn g con figu r a t ion w it h a m odifie d UD P por t
n u m be r .
interface Ethernet0
ipv6 address 2001:DB8:0:5::2/64
ipv6 rip hill enable
ipv6 rip summit enable
interface Ethernet1
ipv6 address 2001:DB8:0:20::/64
ipv6 rip hill enable
interface Ethernet2
ipv6 address 2001:DB8:0:21::/64
ipv6 rip summit enable
ipv6 router rip hill
port 527 multicast-group FF02::9
Not ice t hat t he process nam es on Acom a are not t he sam e as t hose on Taos. RI Png process
nam es are relevant only t o t he local rout er. They are not exchanged in rout e updat es. Acom a's
Et hernet 0 is connect ed t o Taos's Et hernet 2. I t is running t wo rout ing processes: hill and sum m it .
hill is also running on int erface Et hernet 1. Et hernet 1's I Pv6 address is advert ised t o Taos using
t he m odified UDP port num ber 527. This is associat ed wit h t he sm allMount ain RI Png process on
Taos, and t herefore, t he I Pv6 address get s advert ised t o Sandia, not Laguna.
Exam ple 6- 16 displays inform at ion about t he RI Png rout ing processes running on Taos. The
com m and sh ow ipv6 r ip displays each process individually. Not ice t hat t he default m axim um
num ber of parallel pat hs is 16, and t he t im er values have not been m odified from t he default .
Ex a m ple 6 - 1 6 . sh ow ipv6 r ip displa ys in for m a t ion a bou t e a ch RI Pn g
pr oce ss r u n n in g on a r ou t e r .
Taos#show ipv6 rip
RIP process "bigMountain", port 521, multicast-group FF02::9, pid 104
Administrative distance is 120. Maximum paths is 16
Updates every 30 seconds, expire after 180
Holddown lasts 0 seconds, garbage collect after 120
Split horizon is on; poison reverse is off
Default routes are not generated
Periodic updates 1078, trigger updates 5
Interfaces:
Ethernet2
Ethernet0
Redistribution:
None
RIP process "smallMountain", port 527, multicast-group FF02::9, pid 117
Administrative distance is 120. Maximum paths is 16
Updates every 30 seconds, expire after 180
Holddown lasts 0 seconds, garbage collect after 120
Split horizon is on; poison reverse is off
Default routes are not generated
Periodic updates 1080, trigger updates 5
Interfaces:
Ethernet1
Ethernet2
Redistribution:
None
The process bigMount ain is running on int erfaces Et hernet 0 and Et hernet 2. I nt erfaces Et hernet 1
and Et hernet 2 belong t o t he sm allMount ain process, using UDP port num ber 527.
The I Pv6 rout e t able shows t hat Taos has inst alled rout es from bot h processes int o it s rout e
t able ( Exam ple 6- 17 ) .
Ex a m ple 6 - 1 7 . I Pv6 r ou t e t a ble displa ys a ll k n ow n r ou t e s fr om e a ch
a ct ive RI Pn g pr oce ss.
Taos#show ipv6 route
IPv6 Routing Table - 15 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
C
L
C
L
C
L
R
R
R
R
R
R
R
L
L
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
2001:DB8:0:4::/64 [0/0]
via ::, Ethernet1
2001:DB8:0:4::1/128 [0/0]
via ::, Ethernet1
2001:DB8:0:5::/64 [0/0]
via ::, Ethernet2
2001:DB8:0:5::1/128 [0/0]
via ::, Ethernet2
2001:DB8:0:6::/64 [0/0]
via ::, Ethernet0
2001:DB8:0:6::1/128 [0/0]
via ::, Ethernet0
2001:DB8:0:10::/64 [120/2]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
2001:DB8:0:11::/64 [120/2]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
2001:DB8:0:12::/64 [120/2]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
2001:DB8:0:13::/64 [120/2]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
2001:DB8:0:18::/64 [120/2]
via FE80::204:C1FF:FE50:F1C0, Ethernet0
2001:DB8:0:20::/64 [120/2]
via FE80::204:C1FF:FE50:E700, Ethernet2
2001:DB8:0:21::/64 [120/2]
via FE80::204:C1FF:FE50:E700, Ethernet2
FE80::/10 [0/0]
via ::, Null0
FF00::/8 [0/0]
via ::, Null0
Taking a look at Laguna and Sandia's rout e t ables in Exam ple 6- 18 and Exam ple 6- 19 , you can
see t hat each rout er learns about t he rout es belonging t o t he appropriat e RI Png process. Taos
does not forward sm allMount ain addresses int o t he bigMount ain process, and vice versa.
Ex a m ple 6 - 1 8 . I Pv6 r ou t e t a ble displa ys La gu n a 's r ou t e s le a r n e d fr om
t h e bigM ou n t a in RI Pn g pr oce ss on Ta os.
Laguna#show ipv6 route rip
IPv6 Routing Table - 8 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R
2001:DB8:0:5::/64 [120/2]
via FE80::205:5EFF:FE6B:50A0, Ethernet0
R
2001:DB8:0:21::/64 [120/3]
via FE80::205:5EFF:FE6B:50A0, Ethernet0
Ex a m ple 6 - 1 9 . I Pv6 r ou t e t a ble displa ys Sa n dia 's r ou t e s le a r n e d fr om
t h e sm a llM ou n t a in RI Pn g pr oce ss on Ta os.
Sandia#show ipv6 route rip
IPv6 Routing Table - 14 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R
2001:DB8:0:5::/64 [120/2]
via FE80::205:5EFF:FE6B:50A1, Ethernet0
R
2001:DB8:0:20::/64 [120/3]
via FE80::205:5EFF:FE6B:50A1, Ethernet0
Exam ple 6- 17 shows t hat Taos has learned four addresses from Sandia on Et hernet 1, which
belongs t o t he sm allMount ain RI Png process: 2001: db8: 0: 10: : / 64, 2001: db8: 0: 11: : / 64,
2001: db8: 0: 12: : / 64, and 2001: db8: 0: 13: : / 64. 2001: db8: 0: 5: : / 64, connect ed t o Et hernet 2, is
advert ised int o bot h t he sm allMount ain and t he bigMount ain processes. Laguna's rout e t able in
Exam ple 6- 18 shows t hat no sm allMount ain rout es have been inst alled.
Debugging RI Png on Taos ( Exam ple 6- 20 ) shows t he RI Png updat es t hat are sent out and
received int o each int erface for each process.
Ex a m ple 6 - 2 0 . de bu g ipv6 r ip displa ys t h e RI Pn g u pda t e s on e a ch
in t e r fa ce for e a ch a ct ive pr oce ss.
Taos#debug ipv6 rip
RIP Routing Protocol debugging is on
Taos#
RIPng: Sending multicast update on Ethernet2 for bigMountain
src=FE80::205:5EFF:FE6B:50A0
dst=FF02::9 (Ethernet2)
sport=521, dport=521, length=72
command=2, version=1, mbz=0, #rte=3
tag=0, metric=1, prefix=2001:DB8:0:5::/64
tag=0, metric=1, prefix=2001:DB8:0:6::/64
tag=0, metric=2, prefix=2001:DB8:0:18::/64
RIPng: Sending multicast update on Ethernet0 for bigMountain
src=FE80::205:5EFF:FE6B:50A0
dst=FF02::9 (Ethernet0)
sport=521, dport=521, length=72
command=2, version=1, mbz=0, #rte=3
tag=0, metric=1, prefix=2001:DB8:0:5::/64
tag=0, metric=1, prefix=2001:DB8:0:6::/64
tag=0, metric=2, prefix=2001:DB8:0:21::/64
RIPng: response received from FE80::2B0:64FF:FE30:1DE0 on Ethernet1 for
smallMountain
src=FE80::2B0:64FF:FE30:1DE0 (Ethernet1)
dst=FF02::9
sport=527, dport=527, length=112
command=2, version=1, mbz=0, #rte=5
tag=0, metric=1, prefix=2001:DB8:0:4::/64
tag=0, metric=1, prefix=2001:DB8:0:10::/64
tag=0, metric=1, prefix=2001:DB8:0:11::/64
tag=0, metric=1, prefix=2001:DB8:0:12::/64
tag=0, metric=1, prefix=2001:DB8:0:13::/64
RIPng: response received from FE80::204:C1FF:FE50:E700 on Ethernet2 for
smallMountain
src=FE80::204:C1FF:FE50:E700 (Ethernet2)
dst=FF02::9
sport=527, dport=527, length=52
command=2, version=1, mbz=0, #rte=2
tag=0, metric=1, prefix=2001:DB8:0:5::/64
tag=0, metric=1, prefix=2001:DB8:0:20::/64
RIPng: response received from FE80::204:C1FF:FE50:F1C0 on Ethernet0 for bigMountain
src=FE80::204:C1FF:FE50:F1C0 (Ethernet0)
dst=FF02::9
sport=521, dport=521, length=52
command=2, version=1, mbz=0, #rte=2
tag=0, metric=1, prefix=2001:DB8:0:6::/64
tag=0, metric=1, prefix=2001:DB8:0:18::/64
RIPng: response received from FE80::204:C1FF:FE50:E700 on Ethernet2 for bigMountain
src=FE80::204:C1FF:FE50:E700 (Ethernet2)
dst=FF02::9
sport=521, dport=521, length=52
command=2, version=1, mbz=0, #rte=2
tag=0, metric=1, prefix=2001:DB8:0:5::/64
tag=0, metric=1, prefix=2001:DB8:0:21::/64
RIPng: Sending multicast update on Ethernet1 for smallMountain
src=FE80::205:5EFF:FE6B:50A1
dst=FF02::9 (Ethernet1)
sport=527, dport=527, length=72
command=2, version=1, mbz=0, #rte=3
tag=0, metric=1, prefix=2001:DB8:0:4::/64
tag=0, metric=1, prefix=2001:DB8:0:5::/64
tag=0, metric=2, prefix=2001:DB8:0:20::/64
RIPng: Sending multicast update on Ethernet2 for smallMountain
src=FE80::205:5EFF:FE6B:50A0
dst=FF02::9 (Ethernet2)
sport=527, dport=527, length=132
command=2, version=1, mbz=0, #rte=6
tag=0, metric=1, prefix=2001:DB8:0:4::/64
tag=0, metric=1, prefix=2001:DB8:0:5::/64
tag=0, metric=2, prefix=2001:DB8:0:10::/64
tag=0, metric=2, prefix=2001:DB8:0:11::/64
tag=0, metric=2, prefix=2001:DB8:0:12::/64
tag=0, metric=2, prefix=2001:DB8:0:13::/64
sm allMount ain updat es are sent out Et hernet 1, t o Sandia, and Et hernet 2, t o Acom a. bigMount ain
updat es are sent out Et hernet 0, t o Laguna, and Et hernet 2, t o Acom a. Two updat es are received
on Et hernet 2 from Acom a. One uses t he default UDP port 521. The ot her uses UDP port 527, t he
UDP port associat ed wit h sm allMount ain. The updat e t hat uses port 527 includes t he prefix
2001: DB8: 0: 20: : / 64. This is t he prefix assigned t o Et hernet 1 on Acom a, t he prefix which Sandia
is perm it t ed t o access. The updat e received on Et hernet 2 using UDP port 521 includes prefix
2001: DB8: 0: 21: : / 64. This prefix is assigned t o Et hernet 2 on Acom a and is dist ribut ed int o t he
bigMount ain process on Taos, and sent t o Laguna.
Case Study: RIPng Process Customization
Som e cust om izat ion t o t he rout ing process is achieved in a way sim ilar t o RI Pv1 and v2. The
global configurat ion com m and ipv6 r ou t e r r ip pr ocess_nam e let s you configure global
param et ers t o t hat RI Png process.
The adm inist rat ive dist ance, t he m axim um num ber of pat hs t he rout ing process will use for load
sharing, and RI P t im ers were discussed in Chapt er 5 . These param et ers are used t he sam e way
for RI Png as t hey are for RI Pv1 and v2. RI Png's default adm inist rat ive dist ance is 120, t he sam e
as RI Pv1 and v2. The default m axim um num ber of pat hs over which RI Png will load share is 16.
RI Png can load share on up t o 64 pat hs. The t im er param et ers, alt hough not all t he values, are
t he sam e as for RI Pv1 and v2: updat e every 30 seconds, expire aft er 180 seconds, holddown is
0, garbage collect ion is 120 seconds.
A configurat ion for Taos t hat m odifies t he dist ance, m axim um - pat hs, and t im ers is shown in
Exam ple 6- 21 .
Ex a m ple 6 - 2 1 . Ta os's con figu r a t ion m odifie s t h e a dm in ist r a t ive
dist a n ce , t h e m a x im u m n u m be r of pa t h s for loa d sh a r in g, a n d t h e
pr ot ocol t im e s.
ipv6 router rip bigMountain
timers 10 30 30 60
maximum-paths 8
distance 200
Exam ple 6- 22 shows t he out put of sh ow ipv6 r ip and displays t he new param et er values.
Ex a m ple 6 - 2 2 . Th e sh ow ipv6 r ip com m a n d on Ta os sh ow s t h e
m odifie d RI Pn g va lu e s.
Taos#show ipv6 rip
RIP process "bigMountain", port 521, multicast-group FF02::9, pid 104
Administrative distance is 200. Maximum paths is 8
Updates every 10 seconds, expire after 30
Holddown lasts 30 seconds, garbage collect after 60
Split horizon is on; poison reverse is off
Default routes are not generated
Periodic updates 2513, trigger updates 7
Interfaces:
Ethernet2
Ethernet0
Redistribution:
None
RIP process "smallMountain", port 527, multicast-group FF02::9, pid 122
Administrative distance is 120. Maximum paths is 16
Updates every 30 seconds, expire after 180
Holddown lasts 0 seconds, garbage collect after 120
Split horizon is on; poison reverse is off
Default routes are not generated
Periodic updates 2511, trigger updates 0
Interfaces:
Ethernet2
Ethernet1
Redistribution:
None
Taos#
Com pare t he values in t he bigMount ain process wit h t hose in t he sm allMount ain process, which
st ill has t he default values. Be careful m odifying t he t im ers and t he adm inist rat ive dist ance. All
rout ers running t he sam e RI Png process m ust have t he sam e t im er values. The adm inist rat ive
dist ance is only relevant t o t he local rout er, but consider carefully t he consequence of changing
t he adm inist rat ive dist ance if m ult iple rout ing prot ocols or rout ing processes are running on t he
rout er and addresses are being learned from m ult iple rout ing processes. Changing t he
adm inist rat ive dist ance changes t he degree of preference for t he rout ing process. An address
learned via a process wit h a lower dist ance will get insert ed int o t he rout ing t able. I f t he sam e
address is learned via a higher adm inist rat ive dist ance process, t he address will get insert ed int o
t he rout ing t able only if t he first ent ry fails. The configurat ion in Exam ple 6- 23 changes t he
values back t o t he default s.
Ex a m ple 6 - 2 3 . Ta os's RI Pn g pa r a m e t e r s a r e ch a n ge d ba ck t o t h e
de fa u lt va lu e s in t h is con figu r a t ion .
ipv6 router rip bigMountain
no timers 10 30 30 60
no maximum-paths 8
no distance 200
Case Study: Metric Manipulation
As wit h RI Pv1 and v2, RI Png m et rics are adj ust ed by adding an offset . RI Png does not , however,
increm ent t he m et rics of each ent ry in a list of prefixes. RI Png m odifies t he hop count t hat is
associat ed wit h an int erface. This increm ent s t he m et ric of every prefix t hat is advert ised t o t he
rout er via t his int erface by t he am ount of t he hop count configured on t he int erface. By default ,
RI Png adds a single hop t o t he m et ric of prefixes advert ised by a neighboring rout er. Exam ple 624 shows t he RI Png rout e t able on Taos and a RI Png updat e received from Sandia. Not ice t hat
each of t he m et rics in t he rout e t able has a value of t wo. Each RI Png rout e in t he t able is direct ly
connect ed t o a rout er t hat is one hop away, eit her Sandia or Laguna. Sandia and Laguna
advert ise t heir prefixes wit h a m et ric of one. Taos adds a hop count of one t o each of t he
received m et rics. To change t he value t hat Taos adds t o t he received m et ric, use t he m e t r icoffse t com m and, as in Exam ple 6- 25 .
Ex a m ple 6 - 2 4 . RI Pn g r ou t e t a ble a n d de bu g ipv6 r ip sh ow in g a
r e ce ive d u pda t e illu st r a t e s t h e m e t r ic offse t a dde d t o a r e ce ive d
m e t r ic.
Taos#show ipv6 route rip
IPv6 Routing Table - 15 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R
2001:db8:0:18::/64[120/2]
via FE80::204:C1FF:FE50:F1C0, Ethernet0
R
2001:db8:0:10::/64 [120/2]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R
2001:db8:0:11::/64 [120/2]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R
2001:db8:0:12::/64 [120/2]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R
2001:db8:0:13::/64 [120/2]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R
2001:DB8:0:20::/64 [120/2]
via FE80::204:C1FF:FE50:E700, Ethernet2
R
2001:DB8:0:21::/64 [120/2]
via FE80::204:C1FF:FE50:E700, Ethernet2
Taos#debug ipv6 rip
RIP Routing Protocol debugging is on
RIPng: response received from FE80::2B0:64FF:FE30:1DE0 on Ethernet1 for
smallMountain
src=FE80::2B0:64FF:FE30:1DE0 (Ethernet1)
dst=FF02::9
sport=521, dport=521, length=112
command=2, version=1, mbz=0, #rte=4
tag=0, metric=1, prefix=2001:db8:0:10::/64
tag=0, metric=1, prefix=2001:db8:0:11::/64
tag=0, metric=1, prefix=2001:db8:0:12::/64
tag=0, metric=1, prefix=2001:db8:0:13::/64
Ex a m ple 6 - 2 5 . Th e RI Pn g m e t r ic- offse t is in cr e a se d t o t h r e e on Ta os's
Et h e r n e t 1 in t e r fa ce .
interface Ethernet1
ipv6 rip smallMountain metric-offset 3
Exam ple 6- 26 shows t he new rout e t able on Taos. Taos has added a hop count of 3 t o each of
t he prefixes t he rout er received on Et hernet 1.
Ex a m ple 6 - 2 6 . RI Pn g r ou t e t a ble a ft e r t h e m e t r ic offse t h a s be e n
m odifie d on t h e r e ce ivin g in t e r fa ce sh ow s a h igh e r m e t r ic va lu e for
e a ch pr e fix le a r n e d via t h e m odifie d in t e r fa ce .
Taos#show ipv6 route rip
IPv6 Routing Table - 15 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R
2001:DB8:0:10::/64 [120/4]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R
2001:DB8:0:11::/64 [120/4]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R
2001:DB8:0:12::/64 [120/4]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R
2001:DB8:0:13::/64 [120/4]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R
2001:DB8:0:18::/64 [120/2]
R
R
via FE80::204:C1FF:FE50:F1C0, Ethernet0
2001:DB8:0:20::/64 [120/2]
via FE80::204:C1FF:FE50:E700, Ethernet2
2001:DB8:0:21::/64 [120/2]
via FE80::204:C1FF:FE50:E700, Ethernet2
This com m and allows you t o adj ust t he hop count associat ed wit h a given link. All addresses
received by t he adj ust ed int erface will have t he adj ust ed m et ric. By cont rast , RI Pv1 and v2 allow
you t o add t he offset t o a subset ( or all) of t he addresses received by t he int erface before t hey
are added t o t he rout e t able, or t he offset can be added t o t he addresses j ust before t hey are
advert ised out of t he int erface.
Case Study: Route Summarization
As wit h RI Pv2, RI Png rout es can be sum m arized before t hey are advert ised t o neighbors. Sandia
advert ises rout es for 2001: DB8: 0: 10: : / 64, 2001: DB8: 0: 11: : / 64, 2001: DB8: 0: 12: : / 64, and
2001: DB8: 0: 13: : / 64. The rout es can be sum m arized int o a single ent ry: 2001: DB8: 0: 10: : / 62.
Sandia's configurat ion is in Exam ple 6- 27 .
Ex a m ple 6 - 2 7 . Sa n dia is con figu r e d t o su m m a r ize a dve r t ise d RI Pn g
a ddr e sse s.
interface Ethernet0
ipv6 address 2001:DB8:0:4::2/64
ipv6 rip bigMountain enable
ipv6 rip bigMountain summary-address 2001:DB8:0:10::/62
The m ore specific prefixes are aut om at ically suppressed when an encom passing sum m ary
address is configured. Exam ple 6- 28 shows Taos's new rout e t able.
Ex a m ple 6 - 2 8 . Fou r con se cu t ive pr e fix e s w it h a le n gt h of 6 4 bit s h a ve
be e n su m m a r ize d in t o a sin gle e n t r y w it h a le n gt h of 6 2 bit s.
Taos#show ipv6 route rip
IPv6 Routing Table - 12 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R
2001:DB8:0:10::/62 [120/4]
via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R
2001:DB8:0:18::/64 [120/2]
via FE80::204:C1FF:FE50:F1C0, Ethernet0
R
2001:DB8:0:20::/64 [120/2]
via FE80::204:C1FF:FE50:E700, Ethernet2
R
2001:DB8:0:21::/64 [120/2]
via FE80::204:C1FF:FE50:E700, Ethernet2
Troubleshooting RIPv2 and RIPng
Two configurat ion problem s com m on t o RI Pv2 are m ism at ched versions and m isconfigured
aut hent icat ion. Bot h difficult ies are easy t o discover wit h debugging, as Exam ple 6- 29 shows.
Ex a m ple 6 - 2 9 . D e bu ggin g r e ve a ls m ism a t ch e d ve r sion s a n d
m iscon figu r e d a u t h e n t ica t ion .
Jemez#debug ip rip events
RIP event debugging is on
Jemez#
RIP: ignored v1 packet from 172.25.150.249 (illegal version)
RIP: ignored v2 packet from 172.25.150.249 (invalid authentication)
Jemez#
A m ore likely source of t rouble wit h RI Pv2 or RI Png, or any classless rout ing prot ocol, is a
m isconfigured variable- lengt h subnet m ask. VLSM is not difficult , but if a VLSM schem e is not
designed and m anaged carefully it can cause som e unusual rout ing difficult ies.
Case Study: Misconfigured VLSM
Host C in Figure 6- 17 cannot com m unicat e across t he net work, and it cannot even ping t he ot her
host s or rout ers on t he local dat a link. Host s A and B have no com m unicat ion problem s wit h
each ot her or wit h any ot her host across t he net work, but t hey cannot com m unicat e wit h C. All
host s are configured t o use 172.19.35.1 as t he default gat eway address.
Figu r e 6 - 1 7 . H ost s A a n d B ca n com m u n ica t e a cr oss t h e n e t w or k , bu t
h ost C ca n n ot .
[View full size image]
When an at t em pt is m ade t o ping host C from host A or B, t he first ping is successful and
subsequent pings fail ( Figure 6- 18) . Because at least one I CMP Echo Request packet reached C,
and at least one Echo Reply packet was ret urned, t he problem probably is not relat ed t o t he
hardware or dat a link.
Figu r e 6 - 1 8 . W h e n h ost B pin gs h ost C, t h e fir st pin g is su cce ssfu l a n d
su bse qu e n t pin gs fa il.
[View full size image]
The st range ping behavior leads t o t he hypot hesis t hat aft er t he first successful packet ,
subsequent packet seit her t he Echo Request s from B or t he Echo Replies from Care som ehow
being m isdirect ed. Because t his behavior is happening on t he local dat a link, t he Address
Resolut ion Prot ocol ( ARP) caches should be exam ined.
Exam ple 6- 30 and Figure 6- 19 show t he ARP caches for C and B, respect ively. The suspicions
about ARP are confirm ed here. C's cache cont ains t he correct MAC address for B
( 00a0.2470.febd) , but B's cache has a MAC address of 0000.0c0a.2aa9 associat ed wit h C. A
closer look at bot h caches shows t hat 0000.0c0a.2aa9 is t he MAC address of San_Felipe's locally
at t ached int erface. This inform at ion can be deduced because t he sam e MAC address is m apped
t o I Pv4 address 172.19.35.2 and t o t he I Pv4 addresses reachable via t hat rout er.
Figu r e 6 - 1 9 . H ost B's ARP ca ch e sh ow s t h a t C's I Pv4 a ddr e ss is
m a ppe d t o t h e M AC a ddr e ss of Sa n _ Fe lipe 's in t e r fa ce 1 7 2 .1 9 .3 5 .2 .
[View full size image]
Ex a m ple 6 - 3 0 . H ost C's ARP ca ch e sh ow s t h e cor r e ct M AC a ddr e ss
a ssocia t e d w it h a ll a ddr e sse s.
Linux 1.2.13 (Zuni.pueblo.com) (ttyp0)
Zuni login: root
Password:
Last login: Sat Nov 29 11:21:57 on tty1
Linux 1.2.13.
Zuni:~# arp -a
Address
HW type
HW address
172.19.35.112
10Mbps Ethernet
00:00:0C:0A:2A:A9
172.19.35.1
10Mbps Ethernet
00:00:0C:76:5B:7C
172.19.35.33
10Mbps Ethernet
00:A0:24:70:FE:BD
172.19.35.2
10Mbps Ethernet
00:00:0C:0A:2A:A9
172.19.35.3
10Mbps Ethernet
00:00:0C:0A:2C:51
172.19.35.9
10Mbps Ethernet
00:A0:24:A8:26:28
172.19.35.91
10Mbps Ethernet
00:00:0C:0A:2A:A9
Zuni:~#
Flags
C
C
C
C
C
C
C
Mask
*
*
*
*
*
*
*
The ping result s begin t o m ake sense. B broadcast s an ARP Request for 172.19.35.72. C sends
an ARP Reply, and B sends it s first ping correct ly. I n t he m eant im e, San_Felipe has received t he
ARP Request and apparent ly believes t hat it has a rout e t o 172.19.35.72. I t responds wit h a
proxy ARP ( lat er t han C because it has t o perform a rout e lookup first ) , which causes B t o
overwrit e C's MAC address. Subsequent Echo Request packet s are sent t o San_Felipe, where
t hey are rout ed off t he local dat a link and lost . A prot ocol analyzer at t ached t o t he Et hernet
proves t he point (Figure 6- 20) .
Figu r e 6 - 2 0 . A pr ot ocol a n a lyze r , filt e r in g for ARP pa ck e t s, sh ow s B's
ARP r e qu e st t o C a n d r e plie s fr om bot h h ost C ( 0 0 a 0 .2 4 a 8 .a 1 a 5 ) a n d
r ou t e r Sa n _ Fe lipe ( 0 0 0 0 .0 c0 a .2 a a 9 ) .
[View full size image]
I f you know t hat t he t rouble is a rout ing problem , it rem ains only t o find t he cause. First , t he
subnet addresses for each dat a link should be det erm ined (Figure 6- 21) . Next , C's I Pv4 address
should be com pared wit h all t he subnet s reachable via San_Felipe, in binary, t o find any
conflict s. Table 6- 5 shows t he addresses wit h t he subnet bit s of t he last oct et in bold.
Figu r e 6 - 2 1 . W h e n a n a lyzin g a n y a ddr e ssin g sch e m e , a n d e spe cia lly a
VLSM de sign , t h e su bn e t s for e ve r y da t a lin k sh ou ld be de t e r m in e d so
t h a t con flict s a n d ove r la ps m a y be discove r e d.
Ta ble 6 - 5 . C's I Pv4 a ddr e sse s w it h su bn e t
bit s of t h e la st oct e t h igh ligh t e d.
Bin a r y Re pr e se n t a t ion
D ot t e d D e cim a l
10101100000100110010001101001000 172.19.35.72/ 25
10101100000100110010001100000000 172.19.35.0/ 25
10101100000100110010001101000000 172.19.35.64/ 27
10101100000100110010001101100000 172.19.35.96/ 27
101011000001001100100011110010 00 172.19.35.200/ 30
101011000001001100100011110011 00 172.19.35.204/ 30
A com parison shows t hat t he first t hree bit s of 172.19.35.72/ 25 m at ch subnet 172.19.35.64/ 27.
San_Felipe has rout es t o bot h 172.19.35.0/ 25 and t o 172.19.35.64/ 27 ( Exam ple 6- 31) . When it
receives a packet dest ined for host C, it will be able t o m at ch one bit t o subnet 172.19.35.0/ 25
but t hree bit s t o 172.19.35.64/ 27. As a result , t he rout er will choose t he m ore specific subnet
and rout e t he packet off t he local dat a link and int o oblivion.
Ex a m ple 6 - 3 1 . Sa n _ Fe lipe h a s r ou t e s t o bot h 1 7 2 .1 9 .3 5 .0 / 2 5 a n d t o
1 7 2 .1 9 .3 5 .6 4 / 2 7 ; t h e se con d r ou t e is a be t t e r m a t ch of h ost C's
a ddr e ss t h a n is t h e fir st r ou t e .
San_Felipe#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,
U - per-user static route
Gateway of last resort is 172.19.35.1 to network 0.0.0.0
172.19.0.0/16 is variably subnetted, 10 subnets, 3 masks
R
172.19.35.128/27 [120/1] via 172.19.35.3, 00:00:07, Ethernet0
R
172.19.35.160/27 [120/1] via 172.19.35.3, 00:00:08, Ethernet0
R
172.19.35.212/30 [120/1] via 172.19.35.3, 00:00:08, Ethernet0
R
172.19.35.208/30 [120/1] via 172.19.35.3, 00:00:08, Ethernet0
C
172.19.35.204/30 is directly connected, Serial0
C
172.19.35.200/30 is directly connected, Serial1
R
172.19.35.196/30 [120/1] via 172.19.35.1, 00:00:17, Ethernet0
C
172.19.35.0/25 is directly connected, Ethernet0
R
172.19.35.64/27 [120/1] via 172.19.35.206, 00:00:11, Serial0
R
172.19.35.96/27 [120/1] via 172.19.35.202, 00:00:23, Serial1
R* 0.0.0.0/0 [120/1] via 172.19.35.1, 00:00:18, Ethernet0
San_Felipe#
The solut ion t o t his t rouble is t o readdress eit her host C or subnet 172.19.35.64. This st ep
sounds easy on paper. I n real life, it m ay involve som e difficult decisions, as it did for t he client
on whose net work t his case st udy is based.
Table 6- 6 shows all t he subnet s of 172.19.35.0, based on a 27- bit m ask. The int ent ion was t o
com bine t he first four subnet s int o a single subnet wit h a 25- bit m ask t o accom m odat e up t o 85
host s on t he " backbone" Et hernet . This decision is valid because t he grouping will use all t he
subnet s whose first bit is zero; no ot her address can cause a conflict . Next , 172.19.35.192/ 27 is
subnet t ed wit h a 30- bit m ask t o be used on t he serial links. Again, t his design decision is valid.
Subnet s 172.19.35.128/ 27 and 172.19.35.160 are used as is. The error occurred when subnet s
172.19.35.64/ 27 and 172.19.35.96/ 27 were select ed t o be used on t wo " rem ot e" net works.
These subnet s had already been spoken for.
Ta ble 6 - 6 . A 2 7 - bit su bn e t m a sk is a pplie d t o
su bn e t 1 7 2 .1 9 .3 5 .0 .
Bin a r y Re pr e se n t a t ion
D ot t e d D e cim a l
11111111111111111111111111111111 255.255.255.224
10101100000100110010001100000000 172.19.35.0/ 27
10101100000100110010001100100000 172.19.35.32/ 27
10101100000100110010001101000000 172.19.35.64/ 27
10101100000100110010001101100000 172.19.35.96/ 27
10101100000100110010001110000000 172.19.35.128/ 27
10101100000100110010001110100000 172.19.35.160/ 27
10101100000100110010001111000000 172.19.35.192/ 27
10101100000100110010001111100000 172.19.35.224/ 27
The difficult decision is in deciding whet her t o re- address t he backbone, giving up som e address
space t here, or t o re- address t he t wo rem ot e subnet s and give up address space on each of
t hem . The second opt ion was chosen, using a 28- bit m ask t o divide 172.19.35.224/ 27 int o t wo
subnet s for t he rem ot e sit es.
Looking Ahead
Alt hough RI Pv2 present s som e decided im provem ent s over RI Pv1, it is st ill lim it ed t o a
m axim um of 15 hops and, t herefore, t o sm all net works. Chapt er 7, " Enhanced I nt erior Gat eway
Rout ing Prot ocol ( EI GRP) ," Chapt er 8, " OSPFv2," and Chapt er 10, " I nt egrat ed I S- I S," exam ine
t hree prot ocols t hat can be used in m uch larger net works and wit h which design st rat egies such
as VLSM becom e very powerful t ools for cont rolling t hem .
Summary Table: Chapter 6 Command Review
Com m a n d
D e scr ipt ion
a cce pt - life t im e st ar t - t im e Specifies t he t im e period during which t he aut hent icat ion key on a
{ in fin it e | end- t im e|
key chain is received as valid
du r a t ion seconds}
a u t o- su m m a r y
Toggles t he aut om at ic sum m arizat ion of rout es on net work
boundaries
de bu g ip r ip [ e ve n t s]
Enables t he display of m essages on RI P t ransact ions
de bu g ipv6 r ip
Enables t he display of RI Png t ransact ions
ip cla ssle ss
Enables t he forwarding of packet s on t he rout e for which t he
rout er can find t he best m at ch wit hout considerat ion of t he class
of t he dest inat ion address
ip r ip a u t h e n t ica t ion
k e y - ch a in nam e- of- chain
Enables RI Pv2 aut hent icat ion on an int erface and specifies t he
nam e of t he key chain t o be used
ip r ip a u t h e n t ica t ion
m ode { t e x t | m d5 }
Specifies whet her an int erface will use clear t ext or MD5
aut hent icat ion
ip r ip r e ce ive ve r sion [ 1 ]
[ 2]
Specifies t he version or versions of RI P m essages t hat an
int erface will accept
ip r ip se n d ve r sion [ 1 ]
[ 2]
Specifies t he version or versions of RI P m essages t hat an
int erface will send
ip split - h or izon
Toggles t he split horizon funct ion on an int erface
ip su bn e t - ze r o
Allows t he use of all- zeros subnet s for int erface addresses and
rout ing updat es
ipv6 r ip process- nam e
e n a ble
Enables t he I Pv6 RI Png process wit h t he given nam e on t he
int erface on which t his com m and is issued
ipv6 r ip process- nam e
m e t r ic- offse t value
Modifies t he m et ric associat ed wit h an inbound int erface
ipv6 r ip process- nam e
su m m a r y- a ddr e ss prefix
Sum m arizes longer prefix lengt h prefixes int o short er prefixes
ipv6 r ou t e r r ip processn am e
Enables t he I Pv6, RI Png process on a rout er, and ent ers t he
configurat ion m ode t o change global RI Png param et ers
por t port - num m u lt ica st
m ult icast - value
Changes t he UDP port num ber and/ or m ult icast address for a
RI Png process
k e y num ber
Specifies a key on a key chain
k e y ch a in nam e- of- chain
Specifies a group of keys
k e y- st r in g t ext
Specifies t he aut hent icat ion st ring, or password, used by a key
Com m a n d
D e scr ipt ion
n e t w or k net w ork- num ber
Specifies t he net work address of one or m ore direct ly connect ed
int erfaces on which I GRP, EI GRP, or RI P processes should be
enabled
pa ssive - in t e r fa ce t ype
num ber
Disables t he t ransm ission of rout ing updat es on an int erface
r ou t e r r ip
Enables t he RI P rout ing process on a rout er
se n d- life t im e st ar t - t im e
{ in fin it e | end- t im e|
du r a t ion seconds}
Specifies t he t im e period during which t he aut hent icat ion key on a
key chain m ay be sent
sh ow ip r ou t e [ address
[ m ask] ] [ prot ocol
[ process- I D] ]
Displays t he current rout ing t able as a whole or by ent ry
sh ow ipv6 r ip
Displays t he RI Png prot ocol inform at ion
sh ow ipv6 r ou t e r ip
Displays rout es inst alled int o t he I Pv6 rout e t able from t he RI Png
process
ve r sion
Specifies t he version of t he RI P rout ing process
Recommended Reading
Malkin, G. " RI P Version 2." RFC 2453, Novem ber 1998.
Malkin, G., and R. Minnear. " RI Png for I Pv6." RFC 2080, January 1997.
Review Questions
1
Which t hree fields are new t o t he RI Pv2 m essage form at ?
2
Besides t he ext ensions defined by t he t hree fields of quest ion 1, what are t he ot her
t wo m aj or changes from RI Pv1?
3
What is t he m ult icast address used by RI Pv2? What is t he advant age of m ult icast ing
m essages over broadcast ing t hem ?
4
What is t he purpose of t he Rout e Tag field in t he RI Pv2 m essage?
5
What is t he purpose of t he Next Hop field?
6
What is t he UDP port num ber used by RI Pv2?
7
What is t he UDP port num ber used by RI Png?
8
Which one feat ure m ust a rout ing prot ocol have t o be a classless rout ing prot ocol?
9
Which one feat ure m ust a rout ing prot ocol have t o use VLSM?
10
Which t wo t ypes of aut hent icat ion are available wit h t he Cisco RI Pv2? Are t hey bot h
defined in RFC 2453?
Configuration Exercises
1
I n t he exam ple of Figure 6- 12, rout er Taos was configured t o send bot h Version 1
and Version 2 updat es so t hat t he rout ed process in t he Linux host Poj oaque would
underst and t he updat es from Taos. I s t here anot her way t o configure Taos besides
using t he ip r ip se n d ve r sion com m and?
2
A net work has been assigned t he address 192.168.100.0. Subnet t his address t o
m eet t he following requirem ent s:
One subnet wit h 50 host s
Five subnet s wit h 10 host s
One subnet wit h 25 host s
Four subnet s wit h 5 host s
Ten serial links
3
Configure t he four rout ers in Figure 6- 22 t o run RI P. RTC is running I OS 10.3 and
for corporat e policy reasons cannot be upgraded, t herefore can only run RI Pv1.
Figu r e 6 - 2 2 . Th e n e t w or k for Con figu r a t ion Ex e r cise s 3
t h r ou gh 6 .
4
Configure RTB and RTD in Figure 6- 22 t o aut hent icat e t he RI P updat es being
exchanged over t he serial link.
5
Configure RTB and RTD in Figure 6- 22 t o change t o a new aut hent icat ion key t hree
days from t he t im e t he key in Configurat ion Exercise 4 went int o effect . Have t he
new key st ay in effect for 10 hours and t hen have t he rout ers change t o yet anot her
key.
6
Configure RTA and RTB in Figure 6- 22 t o run RI Png. The following I Pv6 prefixes are
t o be assigned t o int erfaces:
RTA:
2001: DB8: 0: 1: : / 64
2001: DB8: 0: 2: : / 64
RTB:
2001: DB8: 0: 3: : / 64
2001: DB8: 0: 2: : / 64
Troubleshooting Exercises
1
Exam ple 6- 32 t hrough Exam ple 6- 34 show t he configurat ions for t he t hree rout ers
in Figure 6- 23. Which subnet s are in t he rout ing t ables of each rout er? From each
rout er, which subnet s are reachable and which subnet s ( if any) are unreachable?
Figu r e 6 - 2 3 . Th e n e t w or k for Tr ou ble sh oot in g Ex e r cise s 1 a n d
2.
Ex a m ple 6 - 3 2 . Th e con figu r a t ion of RTA in Figu r e 6 - 2 3 .
RTA#show running-config
Building configuration...
Current configuration:
!
version 11.2
no service udp-small-servers
no service tcp-small-servers
!
hostname RTA
!
!
!
interface Ethernet0
ip address 192.168.13.86 255.255.255.248
!
interface Serial0
no ip address
shutdown
!
interface Serial1
no ip address
shutdown
!
interface TokenRing0
ip address 192.168.13.34 255.255.255.224
ring-speed 16
!
router rip
version 2
network 192.168.13.0
!
no ip classless
!
!
line con 0
line aux 0
line vty 0 4
login
!
end
RTA#
Ex a m ple 6 - 3 3 . Th e con figu r a t ion of RTB in Figu r e 6 - 2 3 .
RTB#show running-config
Building configuration...
Current configuration:
!
version 11.2
no service udp-small-servers
no service tcp-small-servers
!
hostname RTB
!
!
!
interface Ethernet0
ip address 192.168.13.90 255.255.255.240
!
interface Serial0
no ip address
shutdown
!
interface Serial1
no ip address
shutdown
!
interface TokenRing0
ip address 192.168.13.35 255.255.255.224
ring-speed 16
!
router rip
version 2
network 192.168.13.0
!
no ip classless
!
!
line con 0
line aux 0
line vty 0 4
login
!
end
RTB#
Ex a m ple 6 - 3 4 . Th e con figu r a t ion of RTC in Figu r e 6 - 2 3 .
RTC#show running-config
Building configuration...
Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname RTC
!
!
!
interface Ethernet0
ip address 192.168.13.75 255.255.255.224
!
interface Serial0
no ip address
shutdown
!
interface Serial1
no ip address
shutdown
!
interface TokenRing0
ip address 192.168.13.33 255.255.255.224
ring-speed 16
!
router rip
network 192.168.13.0
!
no ip classless
!
line con 0
line 1 8
line aux 0
line vty 0 4
login
!
end
RTC#
2
The configurat ions of RTA and RTB in Figure 6- 23 are changed as follows: [ 14]
[14]
The configuration shown is for RTB. RTA is identical, except for the IP address, which is 192.168.13.34.
interface Ethernet0
ip address 192.168.13.35 255.255.255.224
ip rip receive version 1 2
Will any subnet s be added t o any rout ing t ables as a result of t his change? Explain
why or why not .
Chapter 7. Enhanced Interior Gateway
Routing Protocol (EIGRP)
This chapt er covers t he following subj ect s:
The Root s of EI GRP: An Overview of I GRP
From I GRP t o EI GRP
Operat ion of EI GRP
Configuring EI GRP
Troubleshoot ing EI GRP
First released in I OS 9.21, Enhanced I nt erior Gat eway Rout ing prot ocol ( EI GRP) is, as t he nam e
says, an enhancem ent of t he Cisco I nt erior Gat eway Rout ing Prot ocol ( I GRP) . The nam e is apt
because unlike RI Pv2, EI GRP is far m ore t han t he sam e prot ocol wit h som e added ext ensions.
Like I GRP, EI GRP is a dist ance vect or prot ocol and uses t he sam e com posit e m et rics as I GRP
uses. Beyond t hat , t here are few sim ilarit ies.
I GRP was discont inued as of I OS releases 12.2( 13) T and 12.2( Rls4) S. Alt hough innovat ive in it s
t im e, m odern net work operat ors who desire m ore capabilit y t han RI P provides m ove t o EI GRP or
OSPF, not t he m oderat ely m ore capable I GRP. However, t o underst and EI GRP, it is useful t o first
exam ine t he prot ocol from which it evolved.
The Roots of EIGRP: An Overview of IGRP
Cisco developed I GRP in t he m id- 1980s as an answer t o t he lim it at ions of RI P, t he m ost
significant of which are t he hop count m et ric and t he 15- hop net work size. I GRP calculat ed a
com posit e m et ric from a variet y of rout e variables and provided " knobs" for weight ing t he
variables t o reflect t he specific charact erist ics and needs of t he net work. Alt hough hop count is
not one of t hese variables, I GRP did t rack hop count , and could be im plem ent ed on net works of
up t o 255 hops in diam et er.
The ot her advant ages t hat I GRP present ed over RI P are
Unequal- cost load sharing
An updat e period t hree t im es longer t han RI P's
A m ore efficient updat e packet form at
The chief disadvant age of bot h I GRP and EI GRP is t hat t hey are propriet ary t o Cisco and
t herefore lim it ed t o Cisco product s, whereas RI P is a part of any I P rout ing process on any
plat form .
The Cisco obj ect ive when developing I GRP was t o creat e a versat ile, robust prot ocol capable of
being adapt ed t o a variet y of rout ed prot ocol suit es. I n addit ion t o rout ing I P, I GRP could also
rout e t he I SO Connect ionless Net work Prot ocol ( CLNP) . This m ult iprot ocol capabilit y was also
adapt ed in EI GRP, which can rout e not only I P but also I PX and AppleTalk.
From a high- alt it ude view, I GRP shares m any operat ional charact erist ics wit h RI P. I t is a classful
dist ance vect or prot ocol t hat periodically broadcast s it s ent ire rout ing t ablewit h t he except ion of
rout es suppressed by split horizont o all it s neighbors. Like RI P, I GRP broadcast s a request
packet out all I GRP- enabled int erfaces upon st art up and perform s a sanit y check on received
updat es t o verify t hat t he source address of t he packet belongs t o t he sam e subnet on which t he
updat e was received.[ 1] New updat e ent ries wit h reachable m et rics are placed in t he rout ing
t able, and an ent ry replaces an older ent ry t o t he sam e dest inat ion only if t he m et ric is sm aller.
Split horizon wit h poisoned reverse, t riggered updat es, and holddown t im ers are used for
st abilit y; I GRP sum m arizes addresses at net work boundaries.
[1]
This sanity check can be disabled with the command no validate-update-source.
Unlike RI P, which is accessed via UDP, t he I GRP process is accessed direct ly from t he I P layer as
prot ocol 9.
Process Domains
I GRP also uses t he concept of process dom ains. By defining and t racking m ult iple process
dom ains, you can isolat e t he com m unicat ions wit hin one dom ain from t he com m unicat ions
wit hin anot her dom ain. Traffic bet ween t he dom ains can t hen be closely regulat ed by
redist ribut ion ( Chapt er 11, " Rout e Redist ribut ion" ) and rout e filt ering ( Chapt er 13, " Rout e
Filt ering" ) .
Figure 7- 1 illust rat es t he cont rast bet ween process dom ains and rout ing dom ains. Here t wo
aut onom ous syst em s ( AS) are defined: AS 10 and AS 40. These syst em s are rout ing dom ainsa
set of rout ers running one or m ore I GPs under a com m on adm inist rat ion. They com m unicat e via
an Ext erior Gat eway Prot ocol ( in t his case, Border Gat eway Prot ocol, or BGP) .
Figu r e 7 - 1 . An a u t on om ou s syst e m n u m be r m a y spe cify a r ou t in g
dom a in , w h ich is a gr ou p of r ou t e r s r u n n in g on e or m or e I GP
pr oce sse s u n de r a sin gle a dm in ist r a t ive dom a in . Un de r I GRP, a n
a u t on om ou s syst e m n u m be r m a y a lso spe cify a pr oce ss dom a in , w h ich
is a gr ou p of r ou t e r s sh a r in g r ou t in g in for m a t ion by m e a n s of a sin gle
r ou t in g pr oce ss.
[View full size image]
Wit hin AS 10 are t wo I GRP process dom ains: I GRP 20 and I GRP 30. Under I GRP, t he 20 and 30
are defined as aut onom ous syst em num bers. I n t his cont ext , t he num bers serve t o dist inguish
t wo rout ing processes wit hin t he sam e rout ing dom ain. I GRP 20 and I GRP 30 com m unicat e via
t he single rout er connect ed t o bot h dom ains. This rout er runs bot h I GRP processes and
aut om at ically redist ribut es bet ween t hem .
Wit hin it s updat es, I GRP classifies rout e ent ries int o one of t hree cat egories: int erior rout es,
syst em rout es, and ext erior rout es.
An int erior rout e is a pat h t o a subnet of t he net work address of t he dat a link on which t he
updat e is being broadcast . I n ot her words, a subnet advert ised as an int erior rout e is " local" t o
t he m aj or net work t o which t he advert ising rout er and t he receiving rout er are com m only
connect ed.
A syst em rout e is a pat h t o a net work address, which has been sum m arized by a net work
boundary rout er.
An ext erior rout e is a pat h t o a net work t hat has been flagged as a default net work . A default
net work is an address t o which a rout er will send any packet t hat cannot be m at ched t o a m ore
specific dest inat ion. [ 2] Default net works and t heir configurat ion are covered in Chapt er 12,
" Default Rout es and On- Dem and Rout ing."
[2]
Classifying a default network as an external route is unique to IGRP and EIGRP. Open protocols such as RIP and OSPF
advertise default networks with the address 0.0.0.0.
Figure 7- 2 shows how I GRP uses t hese t hree cat egories. The rout ers LeHand and Tully are
connect ed t o subnet 192.168.2.64/ 26, so m aj or net work 192.168.2.0 is considered t he " local"
net work shared by t hose t wo rout ers. LeHand is also at t ached t o 192.168.2.192/ 26, which is
anot her subnet of t he net work connect ing t he t wo rout ers. Therefore, LeHand advert ises t hat
subnet t o Tully as an int ernal rout e.
Figu r e 7 - 2 . Le H a n d a dve r t ise s su bn e t 1 9 2 .1 6 8 .2 .1 9 2 / 2 6 t o Tu lly a s a n
in t e r n a l r ou t e . N e t w or k 1 9 2 .1 6 8 .3 .0 is a dve r t ise d t o Tu lly a s a syst e m
r ou t e , a n d 1 9 2 .1 6 8 .1 .0 is a dve r t ise d a s a n e x t e r n a l r ou t e .
However, t he local net work for LeHand and Thom pson is 192.168.3.0. LeHand is t he boundary
rout er bet ween m aj or net works 192.168.2.0 and 192.168.3.0, so 192.168.2.0 will be advert ised
t o Thom pson as a syst em rout e. Likewise, 192.168.3.0 is advert ised t o Tully as a syst em rout e.
192.168.1.0 is a net work in anot her aut onom ous syst em , and LeHand has been configured t o
advert ise t hat net work address as a default rout e. 192.168.1.0 will t herefore be advert ised t o
bot h Thom pson and Tully as an ext ernal rout e.
IGRP Timers and Stability Features
The I GRP updat e period is 90 seconds. A random j it t er variable of up t o 20 percent is subt ract ed
from each updat e t im e t o prevent updat e t im er synchronizat ion, so t he t im e elapsed bet ween
individual updat es will vary from 72 t o 90 seconds.
When a rout e is first learned, t he invalid t im er for t hat rout e is set for 270 seconds, or t hree
t im es t he updat e period. The flush t im er is set for 630 secondsseven t im es t he updat e period.
Each t im e an updat e is received for t he rout e, t hese t im ers are reinit ialized. I f t he invalid t im er
expires before an updat e is heard, t he rout e is m arked as unreachable. I t will be held in t he
rout ing t able and advert ised as unreachable unt il t he flush t im er expires, at which t im e t he rout e
will be delet ed from t he t able.
The 90- second t im er used by I GRP, in com parison t o t he 30- second t im er used by RI P, m eans
t hat com pared t o RI P, I GRP uses less bandwidt h for periodic updat es. However, t he t rade- off is
t hat in som e cases I GRP m ight be slower t o converge t han RI P. For exam ple, if a rout er goes
offline, I GRP t akes t hree t im es as long as RI P t o det ect t he dead neighbor.
I f a dest inat ion becom es unreachable or if t he next - hop rout er increases t he m et ric of a
dest inat ion enough t o cause a t riggered updat e, t he rout e will be placed in holddown for 280
seconds ( t hree updat e periods plus 10 seconds) . Unt il t he holddown t im er expires, no new
inform at ion will be accept ed about t his dest inat ion. I GRP holddown m ay be disabled wit h t he
com m and n o m e t r ic h olddow n . I n loop- free t opologies, where holddown has no real benefit ,
disabling t he funct ion can reduce reconvergence t im e.
The default t im ers can be changed wit h t he following com m and:
timers basic update invalid holddown flush [sleeptime]
This com m and is also used t o m anipulat e RI P t im ers wit h t he except ion of t he sleept im e opt ion.
Sleept im e is a t im er used t o specify a period, in m illiseconds, t o delay a regular rout ing updat e
aft er receiving a t riggered updat e.
IGRP Metrics
One of t he m ost significant changes from RI P t hat I GRP int roduces, and which carries over int o
EI GRP, is t he use of m ult iple m et ric param et ers, based on link charact erist ics. I t is useful t o
st udy how I GRP handles t hese m et rics t o underst and how EI GRP handles it s m et rics.
The link charact erist ics from which I GRP calculat es it s com posit e m et ric are bandwidt h, delay,
load, and reliabilit y. By default , I GRP chooses a rout e based on bandwidt h and delay. I f a dat a
link is t hought of as a pipe, t hen bandwidt h is t he widt h of t he pipe and delay is t he lengt h of t he
pipe. I n ot her words, bandwidt h is a m easure of t he carrying capacit y, and delay is a m easure of
t he end- t o- end t ravel t im e. Load and reliabilit y are t aken int o considerat ion only if t he rout er is
configured t o do so. I GRP also t racks t he sm allest Maxim um Transm ission Unit ( MTU) along each
rout e, alt hough t he MTU is not used in t he com posit e m et ric calculat ion. The quant it ies
associat ed wit h I GRP's com posit e m et ric on a specific int erface can be observed wit h t he sh ow
in t e r fa ce s com m and ( Exam ple 7- 1) .
Ex a m ple 7 - 1 . Th e ou t pu t of e ve r y sh ow in t e r fa ce com m a n d in clu de s
m e t r ic st a t ist ics for t h e in t e r fa ce . Th is Et h e r n e t in t e r fa ce sh ow s M TU =
1 5 0 0 byt e s, ba n dw idt h = 1 0 m e ga bit s pe r se con d, de la y = 1 0 0 0
m icr ose con ds, r e lia bilit y = 1 0 0 pe r ce n t , a n d loa d = 3 9 pe r ce n t
( m in im u m loa d) .
Newfoundland#show interfaces ethernet 0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c76.5b7c (bia 0000.0c76.5b7c)
Internet address is 10.2.1.2/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:07, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
601753 packets input, 113607697 bytes, 0 no buffer
Received 601753 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
693494 packets output, 557731861 bytes, 0 underruns
0 output errors, 5 collisions, 13 interface resets
0 babbles, 0 late collision, 48 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Newfoundland#
Bandwidt h is expressed in unit s of kilobit s per second. I t is a st at ic num ber used for m et ric
calculat ion only and does not necessarily reflect t he act ual bandwidt h of t he linkt hat is,
bandwidt h is not m easured dynam ically. For exam ple, t he default bandwidt h of a serial int erface
is 1544, whet her t he int erface is at t ached t o a T1 or a 56K line. This bandwidt h num ber m ay be
changed from t he default wit h t he ba n dw idt h com m and.
I GRP updat es use a t hree- oct et num ber, referred t o in t his book as BW I GRP, which is t he inverse
of t he bandwidt h scaled by a fact or of 10 7 . So if t he bandwidt h of an int erface is 1544, t hen
BW I GRP = 10 7 / 1544 = 6476, or 0x00194C.
Delay, like bandwidt h, is a st at ic figure and is not m easured dynam ically. I t is displayed by t he
sh ow in t e r fa ce com m and as DLY, in unit s of m icroseconds. The default delay of an int erface
m ay be changed wit h t he de la y com m and, which specifies t he delay in t ens of m icroseconds.
Exam ple 7- 2 shows t he ba n dw idt h and de la y com m ands used t o change t he default s of t he
int erface of Exam ple 7- 1.
Ex a m ple 7 - 2 . Th e ba n dw idt h a n d de la y com m a n ds a r e u se d t o ch a n ge
t h e m e t r ic de fa u lt s of t h e e 0 in t e r fa ce . Th e n e w qu a n t it ie s ca n be se e n
in t h e ou t pu t of t h e sh ow in t e r fa ce s com m a n d.
Newfoundland(config)#interface e0
Newfoundland(config-if)#bandwidth 75000
Newfoundland(config-if)#delay 5
Newfoundland(config-if)#^Z
Newfoundland#
%SYS-5-CONFIG_I: Configured from console by console
Newfoundland#show interfaces ethernet0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c76.5b7c (bia 0000.0c76.5b7c)
Internet address is 10.2.1.2/24
MTU 1500 bytes, BW 75000 Kbit, DLY 50 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:02, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
601888 packets input, 113637882 bytes, 0 no buffer
Received 601888 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
693646 packets output, 557884632 bytes, 0 underruns
0 output errors, 5 collisions, 13 interface resets
0 babbles, 0 late collision, 48 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Newfoundland#
When carried in an I GRP updat e, delay is a t hree- oct et num ber expressed in t he sam e 10m icrosecond unit s as specified by t he de la y com m and. To avoid confusion, t his num ber will be
referred t o as DLYI GRP, t o different iat e it from DLY, in m icroseconds, observed wit h sh ow
in t e r fa ce. For exam ple, if DLY is 50, t hen
DLYI GRP = DLY/ 10 = 50/ 10 = 5, or 0x000005.
I GRP also uses delay t o indicat e an unreachable rout e by set t ing DLYI GRP = 0xFFFFFF. This
num ber t ranslat es t o approxim at ely 167.8 seconds, so t he m axim um end- t o- end delay of an
I GRP rout e is 167 seconds.
Because I GRP uses bandwidt h and delay as it s default m et rics, t hese quant it ies m ust be
configured correct ly and consist ent ly on all int erfaces of all I GRP rout ers.
Changing t he bandwidt h or delay of an int erface should be done only for good reasons and only
wit h a full underst anding of t he result s of t hose changes. I n m ost cases, it is best t o leave t he
default values unchanged. A not able except ion is serial int erfaces. As not ed earlier in t his
sect ion, serial int erfaces on Cisco rout ers have a default bandwidt h of 1544 no m at t er what t he
bandwidt h is of t he connect ed link. The ba n dw idt h com m and should be used t o set t he
int erface t o t he act ual bandwidt h of t he serial link.
I t is im port ant t o not e t hat OSPF also uses t he bandwidt h st at em ent t o calculat e it s m et ric.
Therefore, if I GRP ( or EI GRP) m et rics are t o be m anipulat ed in a net work where OSPF is also
running, use t he de la y t o influence I GRP. Changing t he bandwidt h will affect bot h I GRP and
OSPF.
Table 7- 1 list s t he bandwidt hs and delays for a few com m on int erfaces. ( The default bandwidt h
of a serial int erface is always 1544; Table 7- 1 shows t he figures t hat would result from using t he
ba n dw idt h com m and t o reflect t he act ual connect ed bandwidt h.)
Ta ble 7 - 1 . Com m on BW I GRP a n d D LY I GRP
qu a n t it ie s.
M e dia
Ba n dw idt h BW I GRP
D e la y
D LY I GRP
100M ATM
100000K
100
100m S
10
Fast
Et hernet
100000K
100
100m S
10
FDDI
100000K
100
100m S
10
HSSI
45045K
222
20000m S
2000
16M Token
Ring
16000K
625
630m S
63
Et hernet
10000K
1000
1000m S
100
T1
1544K
6476
20000m S
2000
DS0
64K
156250
20000m S
2000
56K
56K
178571
20000m S
2000
Tunnel
9K
1111111
500000 m S 50000
Reliabilit y is m easured dynam ically and is expressed as an eight - bit num ber, where 255 is a 100
percent reliable link and 1 is a m inim ally reliable link. I n t he out put of sh ow in t e r fa ce,
reliabilit y is shown as a fract ion of 255, for exam ple, 234/ 255 ( see Exam ple 7- 3) .
Ex a m ple 7 - 3 . Th is in t e r fa ce sh ow s a r e lia bilit y of 2 3 4 / 2 5 5 , or 9 1 .8
pe r ce n t .
Casablanca#show interface ethernet0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c76.5b7c (bia 0000.0c76.5b7c)
Internet address is 172.20.1.1 255.255.255.0
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 234/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 4:00:00
Last input 0:00:28, output 0:00:06, output hang never
Last clearing of "show interface" counters 0:06:05
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
22 packets input, 3758 bytes, 0 no buffer
Received 21 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 input packets with dribble condition detected
125 packets output, 11254 bytes, 0 underruns
39 output errors, 694 collisions, 0 interface resets, 0 restarts
0 output buffer failures, 0 output buffers swapped out
Casablanca#
Load, in an I GRP updat e, is an eight - bit num ber. Load is represent ed in t he out put of sh ow
in t e r fa ce as a fract ion of 255, such as 40/ 255 ( Exam ple 7- 4) ; 1 is a m inim ally loaded link, and
255 is a 100 percent loaded link.
Ex a m ple 7 - 4 . Th is in t e r fa ce sh ow s a loa d of 4 0 / 2 5 5 , or 1 5 .7 pe r ce n t .
Yalta#show interface serial 1
Serial1 is up, line protocol is up
Hardware is HD64570
Internet address is 172.20.20.2 255.255.255.0
MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec, rely 255/255, load 40/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 0:00:08, output 0:00:00, output hang never
Last clearing of "show interface" counters 0:05:05
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 10000 bits/sec, 1 packets/sec
5 minute output rate 9000 bits/sec, 1 packets/sec
456 packets input, 397463 bytes, 0 no buffer
Received 70 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
428 packets output, 395862 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets, 0 restarts
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
I f reliabilit y or load is t o be used as a m et ric or as part of a com posit e m et ric, t he algorit hm for
calculat ing t he m et ric m ust not allow sudden changes in t he error rat e or channel occupancy t o
dest abilize t he net work. As an exam ple, if a " raw," or inst ant aneous, m easure of load is used, a
burst of heavy t raffic could cause a rout e t o go int o holddown and an abrupt drop in t raffic could
t rigger an updat e. To prevent frequent m et ric changes, reliabilit y and load are calculat ed based
on an exponent ially weight ed average wit h a five- m inut e t im e const ant , which is updat ed every
five seconds.
The com posit e m et ric for each I GRP rout e is calculat ed as
m et ric = [ k1* BW I GRP( m in) + ( k2* BWI GRP( m in) ) / ( 256- LOAD) + k3* DLYI GRP( sum ) ]
x [ k5/ ( RELI ABI LI TY + k4) ] ,
where BWI GRP( m in) is t he m inim um BW I GRP of all t he out going int erfaces along t he rout e t o t he
dest inat ion and DLYI GRP( sum ) is t he t ot al DLYI GRP of t he rout e.
The values k1 t hrough k5 are configurable weight s; t heir default values are k1= k3= 1 and
k2= k4= k5= 0. These default s can be changed wit h t he com m and: [ 3]
[3]
tos is a relic of the Cisco original intention to have IGRP do type of service routing; this plan was never adopted, and tos
in this command is always set to zero.
metric weights tos k1 k2 k3 k4 k53
I f k5 is set t o zero, t he [ k5/ ( RELI ABI LI TY+ k4) ] t erm is not used.
Given t he default values for k1 t hrough k5, t he com posit e m et ric calculat ion used by I GRP
reduces t o t he default m et ric:
m et ric = BW I GRP( m in) + DLYI GRP( sum )
The net work exam ple in Figure 7- 3 shows t he bandwidt hs and delays configured on each
int erface and a forwarding dat abase from one of t he rout ers wit h t he derived I GRP m et rics. [ 4]
[4]
Also notice the administrative distance, which is 100 for IGRP.
Figu r e 7 - 3 . By de fa u lt , t h e t ot a l de la y is a dde d t o t h e m in im u m
ba n dw idt h t o de r ive t h e I GRP m e t r ic.
[View full size image]
The rout ing t able it self shows only t he derived m et ric, but t he act ual variables recorded by I GRP
for each rout e can be seen by using t he com m and sh ow ip r ou t e address, as in Exam ple 7- 5.
Here t he m inim um bandwidt h on t he rout e from Casablanca t o subnet 172.20.40.0/ 24 is 512K,
at Quebec. The t ot al delay of t he rout e is ( 1000 + 20000 + 20000 + 5000) = 46000
m icroseconds:
BW I GRP( m in) = 10 7 / 512 = 19531
DLYI GRP( sum ) = 46000/ 10 = 4600
m et ric = BW I GRP( m in) + DLYI GRP( sum ) = 19531 + 4600 = 24131
Ex a m ple 7 - 5 . Th e m e t r ic for t h e r ou t e fr om Ca sa bla n ca t o su bn e t
1 7 2 .2 0 .4 0 .0 is ca lcu la t e d fr om t h e m in im u m ba n dw idt h of 5 1 2 K a n d
t h e t ot a l de la y of 4 6 0 0 0 m icr ose con ds.
Casablanca#show ip route 172.20.40.0
Routing entry for 172.20.40.0 255.255.255.0
Known via "igrp 1", distance 100, metric 24131
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 172.20.1.2 on Ethernet0, 00:00:54 ago
Routing Descriptor Blocks:
* 172.20.1.2, from 172.20.1.2, 00:00:54 ago, via Ethernet0
Route metric is 24131, traffic share count is 1
Total delay is 46000 microseconds, minimum bandwidth is 512 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
Exam ple 7- 5 shows t hat I GRP also records t he sm allest MTU along t he rout e in addit ion t o t he
hop count . MTU is not used in t he m et ric calculat ion. Hop count is t he hop count report ed by t he
next - hop rout er and is used only t o lim it t he diam et er of t he net work. By default , t he m axim um
hop count is 100 and can be configured from 1 t o 255 wit h t he com m and m e t r ic m a x im u m h ops. I f t he m axim um hop count is exceeded, t he rout e will be m arked unreachable by set t ing
t he delay t o 0xFFFFFF.
Not e t hat all m et rics are calculat ed from t he out going int erfaces along t he rout e. For exam ple,
t he m et ric for t he rout e from Yalt a t o subnet 172.20.4.0/ 24 is different from t he m et ric for t he
From IGRP to EIGRP
The original m ot ivat ion for developing EI GRP was sim ply t o m ake I GRP classless. But early in t he
developm ent t he engineers working on t he proj ect recalled som e academ ic proposals for a new
kind of convergence algorit hm and decided t o use t hat algorit hm in t heir ext ension of I GRP. The
result was a prot ocol t hat , while ret aining som e concept s int roduced wit h I GRP such as m ult iple
m et rics, prot ocol dom ains, and unequal- cost load balancing, is dist inct ly different from I GRP.
EI GRP is occasionally described as a dist ance vect or prot ocol t hat act s like a link- st at e prot ocol.
To recap t he ext ensive discussion in Chapt er 4, " Dynam ic Rout ing Prot ocols," a dist ance vect or
prot ocol shares everyt hing it knows, but only wit h direct ly connect ed neighbors. Link- st at e
prot ocols announce inform at ion only about t heir direct ly connect ed links, but t hey share t he
inform at ion wit h all rout ers in t heir rout ing dom ain or area.
All t he dist ance vect or prot ocols discussed so far run som e variant of t he Bellm an- Ford ( or FordFulkerson) algorit hm . These prot ocols are prone t o rout ing loops and count ing t o infinit y. As a
result , t hey m ust im plem ent loop- avoidance m easures such as split horizon, rout e poisoning,
and hold- down t im ers. Because each rout er m ust run t he rout ing algorit hm on received rout es
before passing t hose rout es along t o it s neighbors, larger net works m ight be slow t o converge.
More im port ant , dist ance vect or prot ocols advert ise rout es; t he change of a crit ical link m ight
m ean t he advert isem ent of m any changed rout es.
Com pared t o dist ance vect or prot ocols, link- st at e prot ocols are far less suscept ible t o rout ing
loops and bad rout ing inform at ion. The forwarding of link- st at e packet s is not dependent on
perform ing t he rout e calculat ions first , so large net works m ight converge fast er. And only links
or prefixes and t heir st at es are advert ised, not rout es, which m eans t he change of a link will not
cause t he advert isem ent of all rout es using t hat link.
Regardless of whet her ot her rout ing prot ocols perform rout e calculat ions before sending dist ance
vect or updat es t o neighbors or aft er building a t opological dat abase, t heir com m on denom inat or
is t hat t hey perform t he calculat ions individually. I n cont rast t o t he Bellm an- Ford algorit hm s
used by m ost ot her dist ance vect or prot ocols, EI GRP uses a syst em of diffusing
com put at ionsrout e calculat ions t hat are perform ed in a coordinat ed fashion am ong m ult iple
rout erst o at t ain fast convergence while rem aining loop- free at every inst ant .
Alt hough EI GRP updat es are st ill vect ors of dist ances t ransm it t ed t o direct ly connect ed
neighbors, t hey are nonperiodic, part ial, and bounded. Nonper iodic m eans t hat updat es are not
sent at regular int ervals; rat her, updat es are sent only when a m et ric or t opology change occurs.
Part ial m eans t hat t he updat es will include only rout es t hat have changed, not every ent ry in t he
rout e t able. Bounded m eans t hat t he updat es are sent only t o affect ed rout ers. These
charact erist ics m ean t hat EI GRP uses m uch less bandwidt h t han t ypical dist ance vect or prot ocols
use. This feat ure can be especially im port ant on low- bandwidt h, high- cost Wide Area Net work
( WAN) links.
Anot her concern when rout ing over low- bandwidt h WAN links is t he m axim um am ount of
bandwidt h used during periods of convergence, when rout ing t raffic is high. By default , EI GRP
uses no m ore t han 50 percent of t he bandwidt h of a link. Lat er I OS releases allow t his
percent age t o be changed wit h t he com m and ip ba n dw idt h - pe r ce n t e igr p .
EI GRP is a classless prot ocol ( t hat is, each rout e ent ry in an updat e includes a subnet m ask) .
Variable- lengt h subnet m asks m ay be used wit h EI GRP not only for sub- subnet t ing as described
in Chapt er 6, " RI Pv2, RI Png, and Classless Rout ing," but also for address aggregat iont he
sum m arizat ion of a group of m aj or net work addresses.
EI GRP packet s can be aut hent icat ed using an MD5 crypt ographic checksum . The basics of
aut hent icat ion and MD5 are covered in Chapt er 6; an exam ple of configuring EI GRP
aut hent icat ion is included in t his chapt er.
Finally, a m aj or feat ure of EI GRP is t hat it can rout e not only I P but also I PX and AppleTalk.
Operation of EIGRP
EI GRP uses t he sam e form ula t hat I GRP uses t o calculat e it s com posit e m et ric. However, EI GRP
scales t he m et ric com ponent s by 256 t o achieve a finer m et ric granularit y. So if t he m inim um
configured bandwidt h on t he pat h t o a dest inat ion is 512K and t he t ot al configured delay is
46000 m icroseconds, I GRP would calculat e a com posit e m et ric of 24131. EI GRP, however, will
m ult iply t he bandwidt h and delay com ponent s by 256 for a m et ric of 256 x 24131 = 6177536.
EI GRP has four com ponent s (Figure 7- 4 ) :
Prot ocol- Dependent Modules
Reliable Transport Prot ocol ( RTP)
Neighbor Discovery/ Recovery
Diffusing Updat e Algorit hm ( DUAL)
Figu r e 7 - 4 . Th e fou r m a j or com pon e n t s of EI GRP. RTP a n d n e igh bor
discove r y a r e low e r - le ve l pr ot ocols t h a t e n a ble t h e cor r e ct ope r a t ion
of D UAL. D UAL ca n pe r for m r ou t e com pu t a t ion s for m u lt iple r ou t e d
pr ot ocols.
This sect ion exam ines each EI GRP com ponent , wit h part icular em phasis on DUAL, and ends wit h
a discussion of address aggregat ion.
Protocol-Dependent Modules
EI GRP im plem ent s m odules for I P, I PX, and AppleTalk, which are responsible for t he prot ocolspecific rout ing t asks. For exam ple, t he I PX EI GRP m odule is responsible for exchanging rout e
inform at ion about I PX net works wit h ot her I PX EI GRP processes and for passing t he inform at ion
t o t he DUAL. Addit ionally, t he I PX m odule will send and receive SAP inform at ion.
As Figure 7- 4 shows, t he t raffic for t he individual m odules is encapsulat ed wit hin t heir respect ive
net work layer prot ocols. EI GRP for I PX, for exam ple, is carried in I PX packet s.
EI GRP aut om at ically redist ribut es wit h ot her prot ocols in m any cases:
I PX EI GRP aut om at ically redist ribut es wit h I PX RI P and NLSP.
AppleTalk EI GRP aut om at ically redist ribut es wit h AppleTalk RTMP.
I P EI GRP aut om at ically redist ribut es rout es wit h I GRP if t he I GRP process is in t he sam e
aut onom ous syst em .
Redist ribut ion wit h ot her I P rout ing prot ocols is t he subj ect of Chapt er 11.
Configurat ion of EI GRP for I PX and AppleTalk is out side t he scope of t his book. Refer t o t he Cisco
Configurat ion Guide for m ore inform at ion.
Reliable Transport Protocol
The Reliable Transport Prot ocol ( RTP) m anages t he delivery and recept ion of EI GRP packet s.
Reliable delivery m eans t hat delivery is guarant eed and t hat packet s will be delivered in order.
Guarant eed delivery is accom plished by m eans of a Cisco- propriet ary algorit hm known as
reliable m ult icast , using t he reserved class D address 224.0.0.10. Each neighbor receiving a
reliably m ult icast packet unicast s an acknowledgm ent .
Ordered delivery is ensured by including t wo sequence num bers in t he packet . Each packet
includes a sequence num ber assigned by t he sending rout er. This sequence num ber is
increm ent ed by one each t im e t he rout er sends a new packet . I n addit ion, t he sending rout er
places in t he packet t he sequence num ber of t he last packet received from t he dest inat ion
rout er.
I n som e cases, RTP m ay use unreliable delivery. No acknowledgm ent is required, and no
sequence num ber will be included for unreliably delivered EI GRP packet s.
EI GRP uses m ult iple packet t ypes, all of which are ident ified by prot ocol num ber 88 in t he I P
header:
H e llos are used by t he neighbor discovery and recovery process. Hello packet s are
m ult icast and use unreliable delivery.
Ack n ow le dgm e n t s ( ACKs) are Hello packet s wit h no dat a in t hem . ACKs are always
unicast and use unreliable delivery.
Upda t e s convey rout e inform at ion. Unlike RI P and I GRP updat es, t hese packet s are
t ransm it t ed only when necessary, cont ain only necessary inform at ion, and are sent only t o
rout ers t hat require t he inform at ion. When updat es are required by a specific rout er, t hey
are unicast . When updat es are required by m ult iple rout ers, such as upon a m et ric or
t opology change, t hey are m ult icast . Updat es always use reliable delivery.
Qu e r ie s a n d Re plie s are used by t he DUAL finit e st at e m achine t o m anage it s diffusing
com put at ions. Queries can be m ult icast or unicast , and replies are always unicast . Bot h
queries and replies use reliable delivery.
Re qu e st s were a t ype of packet originally int ended for use in rout e servers. This
applicat ion was never im plem ent ed, and request packet s are not ed here only because t hey
are m ent ioned in som e older EI GRP docum ent at ion.
I f any packet is reliably m ult icast and an ACK is not received from a neighbor, t he packet will be
ret ransm it t ed as a unicast t o t hat unresponding neighbor. I f an ACK is not received aft er 16 of
t hese unicast ret ransm issions, t he neighbor will be declared dead.
The t im e t o wait for an ACK before swit ching from m ult icast t o unicast is specified by t he
m ult icast flow t im er. The t im e bet ween t he subsequent unicast s is specified by t he
ret ransm ission t im eout ( RTO) . Bot h t he m ult icast flow t im er and t he RTO are calculat ed for each
neighbor from t he sm oot h round- t rip t im e ( SRTT) . The SRTT is t he average elapsed t im e,
m easured in m illiseconds, bet ween t he t ransm ission of a packet t o t he neighbor and t he receipt
of an acknowledgm ent . The form ulas for calculat ing t he exact values of t he SRTT, t he RTO, and
t he m ult icast flow t im er are propriet ary.
The following t wo subsect ions discuss t he EI GRP com ponent s t hat use t he various packet t ypes.
Neighbor Discovery/Recovery
Because EI GRP updat es are nonperiodic, it is especially im port ant t o have a process whereby
neighborsEI GRP- speaking rout ers on direct ly connect ed net worksare discovered and t racked. On
m ost net works, Hellos are m ult icast every five seconds, m inus a sm all random t im e t o prevent
synchronizat ion. On m ult ipoint X.25, Fram e Relay, and ATM int erfaces, wit h access link speeds
of T1 or slower, Hellos are unicast every 60 seconds. [ 5] This longer Hello int erval is also t he
default for ATM SVCs and for I SDN PRI int erfaces. I n all cases, t he Hellos are unacknowledged.
The default Hello int erval can be changed on a per int erface basis wit h t he com m and ip h e lloin t e r va l e igr p.
[5]
Point-to-point subinterfaces send Hellos every 5 seconds.
When a rout er receives a Hello packet from a neighbor, t he packet will include a hold t im e. The
hold t im e t ells t he rout er t he m axim um t im e it should wait t o receive subsequent Hellos. I f t he
hold t im er expires before a Hello is received, t he neighbor is declared unreachable and DUAL is
inform ed of t he loss of a neighbor. By default , t he hold t im e is t hree t im es t he Hello int erval180
seconds for low- speed nonbroadcast m ult iaccess ( NBMA) net works and 15 seconds for all ot her
net works. The default can be changed on a per int erface basis wit h t he com m and ip h old- t im e
e igr p . The capabilit y t o det ect a lost neighbor wit hin 15 seconds, as opposed t o 180 seconds for
RI P and 270 seconds for I GRP, is one fact or cont ribut ing t o EI GRP's fast reconvergence.
I nform at ion about each neighbor is recorded in a neighbor t able. As Exam ple 7- 6 shows, t he
neighbor t able records t he I P address of t he neighbor and t he int erface on which t he neighbor's
Hellos are received. The hold t im e advert ised by t he neighbor is recorded, as is t he SRTT and
t he upt im et he t im e since t he neighbor was added t o t he t able. The RTO is t he t im e, in
m illiseconds, t hat t he rout er will wait for an acknowledgm ent of a unicast packet sent aft er a
m ult icast has failed. I f an EI GRP updat e, query, or reply is sent , a copy of t he packet will be
queued. I f t he RTO expires before an ACK is received, anot her copy of t he queued packet is
sent . The Q Count indicat es t he num ber of enqueued packet s. The sequence num ber of t he last
updat e, query, or reply packet received from t he neighbor is also recorded in t he neighbor t able.
The RTP t racks t hese sequence num bers t o ensure t hat packet s from t he neighbor are not
received out of order. Finally, t he H colum n records t he order in which t he neighbors were
lear ned.
Ex a m ple 7 - 6 . Th e com m a n d sh ow ip e igr p n e igh bor s is u se d t o obse r ve
t h e I P EI GRP n e igh bor t a ble .
Wright#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H
Address
Interface
Hold Uptime
SRTT
(sec)
(ms)
3
10.1.1.2 Et0
10 09:01:27
12
2
10.1.4.2 Se1
13 09:02:11
23
1
10.1.2.2 Et1
14 09:02:12
8
0
10.1.3.2 Se0
12 09:02:12
21
Wright#
RTO
200
200
200
200
Q
Cnt
0
0
0
0
Seq
Num
5
11
15
13
Diffusing Update Algorithm
DUAL is a convergence algorit hm t hat replaces t he Bellm an- Ford or Ford- Fulkerson algorit hm s
used by ot her dist ance vect or prot ocols. The design philosophy behind DUAL is t hat even
t em porary rout ing loops are det rim ent al t o t he perform ance of a net work. DUAL uses diffusing
com put at ions, first proposed by E. W. Dij kst ra and C. S. Scholt en,[ 6] t o perform dist ribut ed
short est - pat h rout ing while m aint aining freedom from loops at every inst ant . Alt hough m any
researchers have cont ribut ed t o t he developm ent of DUAL, t he m ost prom inent work is t hat of J.
J. Garcia- Luna- Aceves. [ 7]
[6]
Edsger W. Dijkstra and C. S. Scholten. "Termination Detection for Diffusing Computations." Information Processing
Letters, Vol. 11, No. 1, pp. 14: 29 August 1980.
[7]
J. J. Garcia-Luna-Aceves. "A Unified Approach for Loop-Free Routing Using Link States or Distance Vectors," ACM
SIGCOMM Computer Communications Review, Vol. 19, No. 4, pp. 212223: September 1989.
J. J. Garcia-Luna-Aceves. "Loop-Free Routing Using Diffusing Computations," IEEE/ACM Transactions on Networking, Vol.
1, No. 1, February 1993.
DUAL: Preliminary Concepts
For DUAL t o operat e correct ly, a lower- level prot ocol m ust ensure t hat t he following condit ions
are m et : [ 8]
[8]
J. J. Garcia-Luna-Aceves. "Area-Based, Loop-Free Internet Routing." Proceedings of IEEE INFOCOMM 94. Toronto,
Ontario, Canada, June 1994.
A node det ect s wit hin a finit e t im e t he exist ence of a few neighbor or t he loss of
connect ivit y wit h a neighbor.
All m essages t ransm it t ed over an operat ional link are received correct ly and in t he proper
sequence wit hin a finit e t im e.
All m essages, changes in t he cost of a link, link failures, and new- neighbor not ificat ions are
processed one at a t im e wit hin a finit e t im e and in t he order in which t hey are det ect ed.
The Cisco EI GRP uses Neighbor Discovery/ Recovery and RTP t o est ablish t hese precondit ions.
Before t he operat ion of DUAL can be exam ined, a few t erm s and concept s m ust be described.
Upon st art up, a rout er uses Hellos t o discover neighbors and t o ident ify it self t o neighbors. When
a neighbor is discovered, EI GRP will at t em pt t o form an adj acency wit h t hat neighbor. An
adj acency is a logical associat ion bet ween t wo neighbors over which rout e inform at ion is
exchanged. When adj acencies have been est ablished, t he rout er will receive updat es from it s
neighbors. The updat es will cont ain all rout es known by t he sending rout ers and t he m et rics of
t hose rout es. For each rout e, t he rout er will calculat e a dist ance based on t he dist ance
advert ised by t he neighbor and t he cost of t he link t o t hat neighbor.
The lowest calculat ed m et ric t o each dest inat ion will becom e t he feasible dist ance ( FD) of t hat
dest inat ion. For exam ple, a rout er m ay be inform ed of t hree different rout es t o subnet
172.16.5.0 and m ay calculat e m et rics of 380672, 12381440, and 660868 for t he t hree rout es.
380672 will becom e t he FD because it is t he lowest calculat ed dist ance.
The feasibilit y condit ion ( FC) is a condit ion t hat is m et if a neighbor's advert ised dist ance t o a
dest inat ion is lower t han t he rout er's FD t o t hat sam e dest inat ion.
I f a neighbor's advert ised dist ance t o a dest inat ion m eet s t he FC, t he neighbor becom es a
feasible successor [ 9] for t hat dest inat ion. For exam ple, if t he FD t o subnet 172.16.5.0 is 380672
and a neighbor advert ises a rout e t o t hat subnet wit h a dist ance of 355072, t he neighbor will
becom e a feasible successor; if t he neighbor advert ises a dist ance of 380928, it will not sat isfy
t he FC and will not becom e a feasible successor.
[9]
Successor simply means a router that is one hop closer to a destinationin other words, a next-hop router.
The concept s of feasible successors and t he FC are cent ral t o loop avoidance. Because feasible
successors are always " downst ream ," ( t hat is, a short er m et ric dist ance t o t he dest inat ion t han
t he FD) a rout er will never choose a pat h t hat will lead back t hrough it self, creat ing a loop. Such
a pat h would have a dist ance larger t han t he FD.
Every dest inat ion for which one or m ore feasible successors exist will be recorded in a
t opological t able, along wit h t he following it em s:
The dest inat ion's FD
All feasible successors
Each feasible successor's advert ised dist ance t o t he dest inat ion
The locally calculat ed dist ance t o t he dest inat ion via each feasible successor, based on t he
feasible successor's advert ised dist ance and t he cost of t he link t o t hat successor
The int erface connect ed t o t he net work on which each feasible successor is found [ 10]
[10]
Actually, the interface is not explicitly recorded in the route table. Rather, it is an attribute of the neighbor itself.
This convention implies that the same router, seen across multiple parallel links, will be viewed by EIGRP as multiple
neighbors.
For every dest inat ion list ed in t he t opological t able, t he rout e wit h t he lowest m et ric is chosen
and placed int o t he rout e t able. The neighbor advert ising t hat rout e becom es t he successor, or
t he next - hop rout er t o which packet s for t hat dest inat ion are sent .
An exam ple will help clarify t hese t erm s, but first a brief discussion of t he net work used in t he
exam ples in t his sect ion is necessary. Figure 7- 5 shows t he EI GRP- based net work t hat is used
t hroughout t his and t he next t hree subsect ions.[ 11] The com m and m e t r ic w e igh t s 0 0 0 1 0 0
has been added t o t he EI GRP process so t hat only delay is used in t he m et ric calculat ions. The
de la y com m and has been used wit h t he num bers shown at each link; for exam ple, t he
int erfaces of rout ers Wright and Langley, connect ed t o subnet 10.1.3.0, have been configured
wit h a delay of 2. These st eps have been t aken t o sim plify t he exam ples t hat follow.
[11]
Several of the illustrations in this and the following section, and in the network example used throughout, are adapted
from Dr. Garcia-Luna-Aceves's "Loop-Free Routing Using Diffusing Computations," with his permission.
Figu r e 7 - 5 . Th e e x a m ple s a n d illu st r a t ion s of t h is a n d t h e n e x t t w o
su bse ct ion s a r e ba se d on t h is EI GRP n e t w or k .
I t should be point ed out t hat alt hough t he delay param et ers used here sacrifice realism for
sim plicit y, t he way t he m et rics are m anipulat ed is realist ic. Many param et ers are calculat ed from
an int erface's ba n dw idt h specificat ion; som e, such as t he ip ba n dw idt h - pe r ce n t e igr p , apply
direct ly t o EI GRP. Ot hers, such as OSPF cost , do not . As a result , changes of t he configured
bandwidt h should be avoided except t o set serial links t o t heir act ual bandwidt h. I f int erface
m et rics need t o be m anipulat ed t o influence EI GRP ( or I GRP) rout ing, use de la y. Many
unexpect ed headaches can be avoided.
I n Exam ple 7- 7, t he com m and sh ow ip e igr p t opology is used t o observe t he t opology t able of
rout er Langley. Each of t he seven subnet s shown in Figure 7- 5 is list ed, along wit h t he feasible
successors for t he subnet s. For exam ple, t he feasible successors for subnet 10.1.6.0 are
10.1.3.1 ( Wright ) and 10.1.5.2 ( Chanut e) , via int erfaces S0 and S1, respect ively.
Ex a m ple 7 - 7 . Topology t a ble of r ou t e r La n gle y.
Langley#show ip eigrp topology
IP-EIGRP Topology Table for process 1
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 10.1.3.0/24, 1 successors, FD is 512
via Connected, Serial0
P 10.1.2.0/24, 1 successors, FD is 768
via 10.1.3.1 (768/256), Serial0
via 10.1.5.2 (1280/256), Serial1
P 10.1.1.0/24, 1 successors, FD is 768
via 10.1.3.1 (768/256), Serial0
via 10.1.5.2 (1536/512), Serial1
P 10.1.7.0/24, 1 successors, FD is 256
via Connected, Ethernet0
P 10.1.6.0/24, 1 successors, FD is 1024
via 10.1.3.1 (1024/512), Serial0
via 10.1.5.2 (1792/768), Serial1
P 10.1.5.0/24, 1 successors, FD is 1024
via Connected, Serial1
P 10.1.4.0/24, 1 successors, FD is 5632
via 10.1.3.1 (5632/5120), Serial0
via 10.1.5.2 (6400/5376), Serial1
Langley#
Two m et rics in parent heses are also associat ed wit h each feasible successor. The first num ber is
t he locally calculat ed m et ric from Langley t o t he dest inat ion. The second num ber is t he m et ric
advert ised by t he neighbor. For exam ple, in Figure 7- 5 t he m et ric from Langley t o subnet
10.1.6.0 via Wright is 256 x ( 2 + 1 + 1) = 1024, and t he m et ric advert ised by Wright for t hat
dest inat ion is 256 x ( 1 + 1) = 512. The t wo m et rics for t he sam e dest inat ion via Chanut e are
256 x ( 4 + 1 + 1 + 1) = 1792 and 256 x ( 1 + 1 + 1) = 768.
The lowest m et ric from Langley t o subnet 10.1.6.0 is 1024, so t hat is t he FD. Exam ple 7- 8
shows Langley's rout e t able, wit h t he chosen successors.
Ex a m ple 7 - 8 . La n gle y's r ou t e t a ble sh ow s t h a t a sin gle su cce ssor h a s
be e n ch ose n for e a ch k n ow n de st in a t ion , ba se d on t h e low e st m e t r ic
dist a n ce .
Langley#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route
Gateway of last resort is not set
10.0.0.0/8 is subnetted, 7 subnets
C
10.1.3.0 is directly connected, Serial0
D
10.1.2.0 [90/768] via 10.1.3.1, 00:32:06, Serial0
D
10.1.1.0 [90/768] via 10.1.3.1, 00:32:07, Serial0
C
10.1.7.0 is directly connected, Ethernet0
D
10.1.6.0 [90/1024] via 10.1.3.1, 00:32:07, Serial0
C
10.1.5.0 is directly connected, Serial1
D
10.1.4.0 [90/5632] via 10.1.3.1, 00:32:07, Serial0
Langley#
Langley has only one successor for every rout e. The t opology t able of Cayley (Exam ple 7- 9)
shows t hat t here are t wo successors for 10.1.4.0 because t he locally calculat ed m et ric for bot h
rout es m at ches t he FD. Bot h rout es are ent ered int o t he rout e t able ( Exam ple 7- 10) , and Cayley
will perform equal- cost load balancing.
Ex a m ple 7 - 9 . Topology t a ble of Ca yle y, sh ow in g t w o su cce ssor s t o
su bn e t 1 0 .1 .4 .0 .
Cayley#show ip eigrp topology
IP-EIGRP Topology Table for process 1
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 10.1.3.0/24, 1 successors, FD is 768
via 10.1.1.1 (768/512), Ethernet0
P 10.1.2.0/24, 1 successors, FD is 512
via 10.1.1.1 (512/256), Ethernet0
P 10.1.1.0/24, 1 successors, FD is 256
via Connected, Ethernet0
P 10.1.7.0/24, 1 successors, FD is 1024
via 10.1.1.1 (1024/768), Ethernet0
P 10.1.6.0/24, 1 successors, FD is 256
via Connected, Serial0
P 10.1.5.0/24, 1 successors, FD is 1536
via 10.1.1.1 (1536/1280), Ethernet0
P 10.1.4.0/24, 2 successors, FD is 5376
via 10.1.6.1 (5376/5120), Serial0
via 10.1.1.1 (5376/5120), Ethernet0
Cayley#
Ex a m ple 7 - 1 0 . Equ a l- cost loa d sh a r in g w ill be pe r for m e d be t w e e n t h e
t w o su cce ssor s t o 1 0 .1 .4 .
Cayley#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 7 subnets
D
10.1.3.0 [90/768] via 10.1.1.1, 00:01:19, Ethernet0
D
10.1.2.0 [90/512] via 10.1.1.1, 00:01:19, Ethernet0
C
10.1.1.0 is directly connected, Ethernet0
D
10.1.7.0 [90/1024] via 10.1.1.1, 00:01:19, Ethernet0
C
10.1.6.0 is directly connected, Serial0
D
10.1.5.0 [90/1536] via 10.1.1.1, 00:01:19, Ethernet0
D
10.1.4.0 [90/5376] via 10.1.1.1, 00:01:19, Ethernet0
[90/5376] via 10.1.6.1, 00:01:19, Serial0
Cayley#
The t opology t able of Chanut e ( Exam ple 7- 11) shows several rout es for which t here is only one
feasible successor. For exam ple, t he rout e t o 10.1.6.0 has an FD of 768, and Wright ( 10.1.2.1)
is t he only feasible successor. Langley has a rout e t o 10.1.6.0, but it s m et ric is 256 x ( 2 + 1 +
1) = 1024, which is great er t han t he FD. Therefore, Langley's rout e t o 10.1.6.0 does not sat isfy
t he FC, and Langley does not qualify as a feasible successor.
Ex a m ple 7 - 1 1 . Se ve r a l of t h e su bn e t s r e a ch a ble fr om Ch a n u t e h a ve
on ly on e fe a sible su cce ssor .
Chanute#show ip eigrp topology
IP-EIGRP Topology Table for process 1
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 10.1.3.0/24, 1 successors, FD is 768
via 10.1.2.1 (768/512), Ethernet0
via 10.1.5.1 (1536/512), Serial0
P 10.1.2.0/24, 1 successors, FD is 256
via Connected, Ethernet0
P 10.1.1.0/24, 1 successors, FD is 512
via 10.1.2.1 (512/256), Ethernet0
P 10.1.7.0/24, 1 successors, FD is 1024
via 10.1.2.1 (1024/768), Ethernet0
via 10.1.5.1 (1280/256), Serial0
P 10.1.6.0/24, 1 successors, FD is 768
via 10.1.2.1 (768/512), Ethernet0
P 10.1.5.0/24, 1 successors, FD is 1024
via Connected, Serial0
P 10.1.4.0/24, 1 successors, FD is 5376
via 10.1.2.1 (5376/5120), Ethernet0
Chanute#
I f a feasible successor advert ises a rout e for which t he locally calculat ed m et ric is lower t han t he
m et ric via t he present successor, t he feasible successor will becom e t he successor. The following
condit ions can cause t his sit uat ion t o occur:
A newly discovered rout e
The cost of a successor's rout e increasing beyond t hat of a feasible successor
The cost of a feasible successor's rout e decreasing t o below t he cost of t he successor's
rout e
For exam ple, Exam ple 7- 12 shows t hat Lilient hal's successor t o subnet 10.1.3.0 is Cayley
( 10.1.6.2) . Suppose t he cost of t he link bet ween Lilient hal and Wright is decreased t o one.
Wright ( 10.1.4.1) is advert ising a dist ance of 512 t o subnet 10.1.3.0; wit h t he new cost of t he
link t o Wright , Lilient hal's locally calculat ed m et ric t o t he subnet via t hat rout er is now 768.
Wright will replace Cayley as t he successor t o subnet 10.1.3.0.
Ex a m ple 7 - 1 2 . Topology t a ble for Lilie n t h a l.
Lilienthal#show ip eigrp topology
IP-EIGRP Topology Table for process 1
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 10.1.3.0/24, 1 successors, FD is 1024
via 10.1.6.2 (1024/768), Serial0
via 10.1.4.1 (5632/512), Serial1
P 10.1.2.0/24, 1 successors, FD is 768
via 10.1.6.2 (768/512), Serial0
via 10.1.4.1 (5376/256), Serial1
P 10.1.1.0/24, 1 successors, FD is 512
via 10.1.6.2 (512/256), Serial0
via 10.1.4.1 (5376/256), Serial1
P 10.1.7.0/24, 1 successors, FD is 1280
via 10.1.6.2 (1280/1024), Serial0
via 10.1.4.1 (5888/768), Serial1
P 10.1.6.0/24, 1 successors, FD is 256
via Connected, Serial0
P 10.1.5.0/24, 1 successors, FD is 1792
via 10.1.6.2 (1792/1536), Serial0
via 10.1.4.1 (6400/1280), Serial1
P 10.1.4.0/24, 1 successors, FD is 5120
via Connected, Serial1
Lilienthal#
Next , suppose Lilient hal discovers a new neighbor t hat is advert ising a dist ance of 256 t o subnet
10.1.3.0. This dist ance is lower t han t he FD, so t he new neighbor will becom e a feasible
successor. Suppose furt her t hat t he cost of t he link t o t he new neighbor is 256. Lilient hal's
locally calculat ed m et ric t o 10.1.3.0 via t he new neighbor will be 512. This m et ric is lower t han
t he dist ance via Wright , so t he new neighbor will becom e t he successor t o 10.1.3.0.
Feasible successors are im port ant because t hey reduce t he num ber of diffusing com put at ions
and t herefore increase perform ance. Feasible successors also cont ribut e t o lower reconvergence
t im es. I f a link t o a successor fails, or if t he cost of t he link increases beyond t he FD, t he rout er
will first look int o it s t opology t able for a feasible successor. I f one is found, it will becom e t he
successor; t his select ion norm ally occurs in t he sub- second range. The rout er will begin a
diffusing com put at ion only if a feasible successor cannot be found. The key t o successful EI GRP
design, t hen, is ensuring t hat a feasible successor always exist s for all dest inat ions.
The following sect ion gives a m ore form al set of rules for when and how a rout er will search for
feasible successors. This set of rules is called t he DUAL finit e st at e m achine.
DUAL Finite State Machine
When an EI GRP rout er is perform ing no diffusing com put at ions, each rout e is in t he passiv e
st at e. Referring t o any of t he t opology t ables in t he previous sect ion, a key t o t he left of each
rout e indicat es a passive st at e.
A rout er will reassess it s list of feasible successors for a rout e, as described in t he last sect ion,
any t im e an input event occurs. An input event can be t he following:
A change in t he cost of a direct ly connect ed link
A change in t he st at e ( up or down) of a direct ly connect ed link
The recept ion of an updat e packet
The recept ion of a query packet
The recept ion of a reply packet
The first st ep in it s reassessm ent is a local com put at ion in which t he dist ance t o t he dest inat ion
is recalculat ed for all feasible successors. The possible result s are
I f t he feasible successor wit h t he lowest dist ance is different from t he exist ing successor,
t he feasible successor will becom e t he successor.
I f t he new dist ance is lower t han t he FD, t he FD will be updat ed.
I f t he new dist ance is different from t he exist ing dist ance, updat es will be sent t o all
neighbors.
While t he rout er is perform ing a local com put at ion, t he rout e rem ains in t he passive st at e. I f a
feasible successor is found, an updat e is sent t o all neighbors and no st at e change occurs.
I f a feasible successor cannot be found in t he t opology t able, t he rout er will begin a diffusing
com put at ion and t he rout e will change t o t he act ive st at e. Unt il t he diffusing com put at ion is
com plet ed and t he rout e t ransit ions back t o t he passive st at e, t he rout er cannot
Change t he rout e's successor
Change t he dist ance it is advert ising for t he rout e
Change t he rout e's FD
Begin anot her diffusing com put at ion for t he rout e
A rout er begins a diffusing com put at ion by sending queries t o all of it s neighbors ( Figure 7- 6 ) .
The query will cont ain t he new locally calculat ed dist ance t o t he dest inat ion. Each neighbor,
upon receipt of t he query, will perform it s own local com put at ion:
I f t he neighbor has one or m ore feasible successors for t he dest inat ion, it will send a reply
t o t he originat ing rout er. The reply will cont ain t hat neighbor's m inim um locally calculat ed
dist ance t o t he dest inat ion.
I f t he neighbor does not have a feasible successor, it t oo will change t he rout e t o t he act ive
st at e and will begin a diffusing com put at ion.
Figu r e 7 - 6 . A diffu sin g com pu t a t ion gr ow s a s qu e r ie s a r e se n t a n d
sh r in k s a s r e plie s a r e r e ce ive d.
[View full size image]
For each neighbor t o which a query is sent , t he rout er will set a reply st at us flag ( r) t o keep
t rack of all out st anding queries. The diffusing com put at ion is com plet e when t he rout er has
received a reply t o every query sent t o every neighbor.
I n som e cases, a rout er does not receive a reply t o every query sent . For exam ple, t his m ight
happen in large net works wit h m any low- bandwidt h or low- qualit y links. At t he beginning of t he
diffusing com put at ion, an Act ive t im er is set for t hree m inut es. I f all expect ed replies are not
received before t he Act ive t im e expires, t he rout e is declared st uck- in- act ive ( SI A) . The neighbor
or neighbors t hat did not reply will be rem oved from t he neighbor t able, and t he diffusing
com put at ion will consider t he neighbor t o have responded wit h an infinit e m et ric.
The default t hree- m inut e Act ive t im e can be changed or disabled wit h t he com m and t im e r s
a ct ive - t im e . The delet ion of a neighbor because of a lost query obviously can have disrupt ive
result s, and SI As should never occur in a st able, well- designed net work. The t roubleshoot ing
sect ion of t his chapt er discusses SI As in m ore det ail. That sam e sect ion describes a recent
enhancem ent t o t he SI A procedures, using t wo new EI GRP m essagesSI A Query and SI A
Replyt hat bot h reduce t he chance of occurrences of SI As and, when t hey do occur, m ake t hem
easier t o t roubleshoot .
At t he com plet ion of t he diffusing com put at ion, t he originat ing rout er will set FD t o infinit y t o
ensure t hat any neighbor replying wit h a finit e dist ance t o t he dest inat ion will m eet t he FC and
becom e a feasible successor. For each of t hese replies, a m et ric is calculat ed based on t he
dist ance advert ised in t he reply plus t he cost of t he link t o t he neighbor who sent t he reply. A
successor is select ed based on t he lowest m et ric, and FD is set t o t his m et ric. Any feasible
successors t hat do not sat isfy t he FC for t his new FD will be rem oved from t he t opology t able.
Not e t hat a successor is not chosen unt il all replies have been received.
Because t here are m ult iple t ypes of input event s t hat can cause a rout e t o change st at e, som e of
which m ight occur while a rout e is act ive, DUAL defines m ult iple act ive st at es. A query origin flag
( O) is used t o indicat e t he current st at e. Figure 7- 7 and Table 7- 2 show t he com plet e DUAL finit e
st at e m achine.
Figu r e 7 - 7 . Th e D UAL fin it e st a t e m a ch in e . Th e qu e r y or igin fla g ( O)
m a r k s t h e cu r r e n t st a t e of t h e diffu sin g ca lcu la t ion . Se e Ta ble 7 - 2 for a
de scr ipt ion of e a ch in pu t e ve n t ( I E) .
[View full size image]
Ta ble 7 - 2 . I n pu t e ve n t s for t h e D UAL fin it e st a t e m a ch in e .
I n pu t Eve n t
D e scr ipt ion
I E1
Any input event for which FC is sat isfied or t he dest inat ion is unreachable
I E2
Query received from t he successor; FC not sat isfied
I E3
I nput event ot her t han a query from t he successor; FC not sat isfied
I E4
I nput event ot her t han last reply or a query from t he successor
I E5
I nput event ot her t han last reply, a query from t he successor, or an
increase in dist ance t o dest inat ion
I E6
I nput event ot her t han last reply
I E7
I nput event ot her t han last reply or increase in dist ance t o dest inat ion
I E8
I ncrease in dist ance t o dest inat ion
I E9
Last reply received; FC not m et wit h current FD
I E10
Query received from t he successor
I E11
Last reply received; FC m et wit h current FD
I n pu t Eve n t
D e scr ipt ion
I E12
Last reply received; set FD t o infinit y
Two exam ples can help clarify t he DUAL process. Figure 7- 8 shows t he exam ple net work,
focusing only on each rout er's pat h t o subnet 10.1.7.0; refer t o Figure 7- 5 for specific addresses.
On t he dat a links, an arrow indicat es t he successor each rout er is using t o reach 10.1.7.0. I n
parent heses are each rout er's locally calculat ed dist ance t o t he subnet , t he rout er's FD, t he reply
st at us flag ( r) , and t he query origin flag ( O) , respect ively. Act ive rout ers are indicat ed wit h a
circle in subsequent figures and exam ples using t his net work.
Figu r e 7 - 8 . All r ou t e s t o su bn e t 1 0 .1 .7 .0 a r e in t h e pa ssive st a t e ,
in dica t e d by r = 0 a n d O = 1 .
[View full size image]
Diffusing Computation: Example 1
This exam ple focuses only on Cayley and it s rout e t o subnet 10.1.7.0. I n Figure 7- 9 , t he link
bet ween Cayley and Wright ( 10.1.1.1) has failed. EI GRP int erpret s t he failure as a link wit h an
infinit e dist ance. [ 12] Cayley checks it s t opology t able for a feasible successor t o 10.1.7.0 and
finds none ( refer t o Exam ple 7- 9) .
[12]
An infinite distance is indicated by a delay of 0xFFFFFFFF, or 4294967295.
Figu r e 7 - 9 . Th e lin k be t w e e n W r igh t a n d Ca yle y h a s fa ile d, a n d Ca yle y
doe s n ot h a ve a fe a sible su cce ssor t o su bn e t 1 0 .1 .7 .0 .
[View full size image]
Cayley's rout e becom es act ive ( Figure 7- 10) . The dist ance and t he FD of t he rout e are changed
t o unreachable, and a query cont aining t he new dist ance is sent t o Cayley's neighbor, Lilient hal.
Cayley's reply st at us flag for Lilient hal is set t o one, indicat ing t hat a reply is expect ed. Because
t he input event was not t he recept ion of a query ( I E3) , O= 1.
Figu r e 7 - 1 0 . Ca yle y's r ou t e t o 1 0 .1 .7 .0 t r a n sit ion s t o a ct ive , a n d
Lilie n t h a l is qu e r ie d for a fe a sible su cce ssor .
[View full size image]
Upon receipt of t he query, Lilient hal perform s a local com put at ion ( Figure 7- 11) . Because
Lilient hal has a feasible successor for 10.1.7.0 ( refer t o Exam ple 7- 12) , t he rout e does not
becom e act ive. Wright becom es t he new successor, and a reply is sent wit h Lilient hal's dist ance
t o 10.1.7.0 via Wright . Because t he dist ance t o 10.1.7.0 has increased and t he rout e did not
becom e act ive, t he FD is unchanged at Lilient hal.
Figu r e 7 - 1 1 . Lilie n t h a l h a s a fe a sible su cce ssor t o 1 0 .1 .7 .0 . A loca l
com pu t a t ion is pe r for m e d, a r e ply is se n t t o Ca yle y w it h t h e dist a n ce
via W r igh t , a n d a n u pda t e is se n t t o W r igh t .
[View full size image]
Upon receipt of t he reply from Lilient hal, Cayley set s r= 0 and t he rout e becom es passive ( Figure
7- 12 ) . Lilient hal becom es t he new successor, and t he FD is set t o t he new dist ance. Finally, an
updat e is sent t o Lilient hal wit h Cayley's locally calculat ed m et ric. Lilient hal will also send an
updat e advert ising it s new m et ric.
Figu r e 7 - 1 2 . Ca yle y's r ou t e t o 1 0 .1 .7 .0 be com e s pa ssive , a n d a n
u pda t e is se n t t o Lilie n t h a l.
EI GRP packet act ivit y can be observed wit h t he debug com m and de bu g e igr p pa ck e t s. By
default , all EI GRP packet s are displayed. Because Hellos and ACKs can m ake t he debug out put
hard t o follow, t he com m and allows t he use of opt ional keywords so t hat only specified packet
t ypes are displayed. I n Exam ple 7- 13, de bu g e igr p pa ck e t s qu e r y r e ply u pda t e is used t o
observe t he packet act ivit y at Cayley for t he event s described in t his exam ple.
Ex a m ple 7 - 1 3 . Th e EI GRP pa ck e t e ve n t s de scr ibe d in t h is e x a m ple ca n
be obse r ve d in t h e se de bu g m e ssa ge s.
Cayley#debug eigrp packet update query reply
EIGRP Packets debugging is on
(UPDATE, QUERY, REPLY)
B#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down
EIGRP: Enqueueing QUERY on Serial0 iidbQ un/rely 0/1 serno 45-49
EIGRP: Enqueueing QUERY on Serial0 nbr 10.1.6.1 iidbQ un/rely 0/0 peerQ un/rely
0/0 serno 45-49
EIGRP: Sending QUERY on Serial0 nbr 10.1.6.1
AS 1, Flags 0x0, Seq 45/64 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno
45-49
EIGRP: Received REPLY on Serial0 nbr 10.1.6.1
AS 1, Flags 0x0, Seq 65/45 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
EIGRP: Enqueueing UPDATE on Serial0 iidbQ un/rely 0/1 serno 50-54
EIGRP: Enqueueing UPDATE on Serial0 nbr 10.1.6.1 iidbQ un/rely 0/0 peerQ un/rely
0/0 serno 50-54
EIGRP: Sending UPDATE on Serial0 nbr 10.1.6.1
AS 1, Flags 0x0, Seq 46/66 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno
50-54
EIGRP: Received UPDATE on Serial0 nbr 10.1.6.1
AS 1, Flags 0x0, Seq 67/46 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Flags, in t he debug m essages, indicat e t he st at e of t he flags in t he EI GRP packet header ( see t he
sect ion " EI GRP Packet Header " lat er in t his chapt er) . 0x0 indicat es t hat no flags are set . 0x1
indicat es t hat t he init ializat ion bit is set . This flag is set when t he enclosed rout e ent ries are t he
first in a new neighbor relat ionship. 0x2 indicat es t hat t he condit ional receive bit is set . This flag
is used in t he propriet ary Reliable Mult icast ing algorit hm :
Se q is t he Packet Sequence Num ber/ Acknowledged Sequence Num ber.
idbq indicat es packet s in t he input queue/ packet s in t he out put queue of t he int erface.
iidbq indicat es unreliable m ult icast packet s await ing t ransm ission/ reliable m ult icast
packet s await ing t ransm ission on t he int erface.
pe e r Q indicat es unreliable unicast packet s await ing t ransm ission/ reliable unicast packet s
await ing t ransm ission on t he int erface.
se r n o is a point er t o a doubly linked serial num ber for t he rout e. This is used by an
int ernal ( and propriet ary) m echanism for t racking t he correct rout e inform at ion in a rapidly
changing t opology.
Diffusing Computation: Example 2
This exam ple focuses on Wright and it s rout e t o subnet 10.1.7.0. Alt hough t he com binat ion of
input event s port rayed here ( t he delay of a link changing t wice during a diffusing com put at ion)
is unlikely t o occur in real life, t he exam ple shows how DUAL handles m ult iple m et ric changes.
I n Figure 7- 13, t he cost of t he link bet ween Wright and Langley changes from 2 t o 10. The
dist ance t o 10.1.7.0 via Langley now exceeds Wright 's FD, causing t hat rout er t o begin a local
com put at ion. The m et ric is updat ed, and Wright sends updat es t o all it s neighbors except t he
neighbor on t he link whose cost changed (Figure 7- 14) .
Figu r e 7 - 1 3 . Ca yle y's r ou t e t o 1 0 .1 .7 .0 be com e s pa ssive , a n d a n
u pda t e is se n t t o Lilie n t h a l.
Figu r e 7 - 1 4 . W r igh t se n ds u pda t e s con t a in in g t h e n e w m e t r ic t o a ll
n e igh bor s e x ce pt La n gle y.
Not e t hat Langley was t he only feasible successor t o subnet 10.1.7.0 because Chanut e's locally
calculat ed m et ric is higher t han Wright 's FD ( 1024 > 768) . The m et ric increase on t he Wright Langley link causes Wright t o look in it s t opology t able for a new successor. Because t he only
feasible successor t hat Wright can find in it s t opology t able is Langley, t he rout e becom es act ive.
Queries are sent t o t he neighbors (Figure 7- 15) .
Figu r e 7 - 1 5 . W r igh t 's r ou t e t o 1 0 .1 .7 .0 be com e s a ct ive , a n d it qu e r ie s
it s n e igh bor s for a fe a sible su cce ssor . I n r e spon se t o t h e e a r lie r
u pda t e fr om W r igh t , Ca yle y m a k e s it s r ou t e a ct ive a n d qu e r ie s it s
n e igh bor s; a lso, Ch a n u t e ch a n ge s it s m e t r ic a n d se n ds u pda t e s.
At t he sam e t im e, t he updat es sent by Wright in Figure 7- 14 cause Cayley, Lilient hal, and
Chanut e t o perform a local calculat ion.
At Cayley, t he rout e via Wright now exceeds Cayley's FD ( 2816 > 1024) . The rout e goes act ive
and queries are sent t o t he neighbors.
Lilient hal is using Cayley as a successor and in Figure 7- 15 has not yet received t he query from
Cayley. Therefore, Lilient hal m erely recalculat es t he m et ric of t he pat h via Wright , finds t hat it
no longer m eet s t he FC, and drops t he pat h from t he t opology t able.
At Chanut e, Wright is t he successor. Because Wright 's advert ised dist ance no longer m eet s t he
FC at Chanut e ( 2816 > 1024) and because Chanut e does have a feasible successor ( refer t o
Exam ple 7- 11) , Wright is delet ed from Chanut e's t opology t able. Langley becom es t he successor
at Chanut e; t he m et ric is updat ed, and Chanut e sends updat es t o it s neighbors ( refer t o Figure
7- 15 ) . The rout e at Chanut e never becom es act ive.
Cayley, Lilient hal, and Chanut e each respond different ly t o t he queries from Wright (Figure 716 ) .
Figu r e 7 - 1 6 . Ca yle y ( a ) r e plie s t o W r igh t 's qu e r y. Lilie n t h a l ( b) r e plie s
t o W r igh t 's qu e r y a n d ( c) goe s a ct ive for t h e r ou t e , se n din g qu e r ie s in
r e spon se t o Ca yle y's qu e r y. Ch a n u t e ( d) r e plie s t o W r igh t 's qu e r y.
W r igh t ( e ) r e plie s t o Ca yle y's qu e r y.
Cayley is already act ive. Because t he input event is a query from t he successor, t he query origin
flag will be 2 ( O= 2) ( refer t o Figure 7- 7 and Table 7- 2) .
Lilient hal, upon t he receipt of Wright 's query, sends a response wit h it s dist ance via Cayley.
However, j ust aft er t he reply is sent , Lilient hal receives t he query from Cayley. The FD is
exceeded, t he m et ric is updat ed, and t he rout e goes act ive. Lilient hal queries it s neighbors.
Chanut e, which has already swit ched t o Langley as it s successor, m erely sends a reply.
While all t his is going on, Figure 7- 16 shows t hat t he cost of t he link bet ween Wright and
Langley again increases, from 10 t o 20. Wright will recalculat e t he m et ric t o 10.1.7.0 based on
t his new cost , but because t he rout e is act ive, neit her t he FD nor t he dist ance it advert ises will
change unt il t he rout e becom es passive.
According t o Figure 7- 7 and Table 7- 2, an increase in t he dist ance t o t he dest inat ion while t he
rout e is act ive will cause O= 0 ( Figure 7- 17) . Wright responds t o t he query from Lilient hal. The
dist ance it report s is t he dist ance it had when t he rout e first becam e act ive ( rem em ber, t he
advert ised dist ance cannot change while t he rout e is act ive) . Cayley also sends a reply t o
Lilient hal's query.
Figu r e 7 - 1 7 . W r igh t ca n n ot ch a n ge t h e m e t r ic it a dve r t ise s u n t il t h e
r ou t e be com e s pa ssive .
Lilient hal, having received replies t o all it s queries, will t ransit ion t he rout e t o passive ( Figure 718 ) . A new FD is set for t he rout e. Cayley rem ains t he successor because it s advert ised rout e is
lower t han t he FD at Lilient hal. Lilient hal also sends a reply t o Cayley's query.
Figu r e 7 - 1 8 . H a vin g r e ce ive d t h e la st e x pe ct e d r e ply, Lilie n t h a l
ch a n ge s it s r ou t e t o t h e pa ssive st a t e ( r = 0 , O= 1 ) .
Figure 7- 18 also shows t hat t he dist ance has changed again, from 20 t o 15. Wright recalculat es
it s local dist ance for t he rout e again, t o 4096 ( Figure 7- 19) . I f it were t o receive a query before
going passive, t he rout e would st ill be advert ised wit h a dist ance of 2816t he dist ance when t he
rout e went act ive.
Figu r e 7 - 1 9 . H a vin g r e ce ive d it s la st e x pe ct e d r e ply, Ca yle y ch a n ge s
it s r ou t e t o t h e pa ssive st a t e .
When Cayley receives t he reply t o it s query, it s rout e t o 10.1.7.0 also becom es passive ( Figure
7- 19 ) and a new FD is set . Alt hough Wright 's locally calculat ed m et ric is 4096, t he last m et ric it
advert ised was 2816. Therefore, Wright m eet s t he FC at Cayley and becom es t he successor t o
10.1.7.0. A reply is sent t o Wright .
I n Figure 7- 20, Wright has received a reply t o every query it sent , and it s rout e becom es
passive. I t chooses Chanut e as it s new successor and changes t he FD t o t he sum of Chanut e's
advert ised dist ance and t he cost of t he link t o t hat neighbor. Wright sends an updat e t o all it s
neighbors, advert ising t he new locally calculat ed m et ric.
Figu r e 7 - 2 0 . W r igh t t r a n sit ion s t o pa ssive , ch oose s Ch a n u t e a s t h e
su cce ssor , ch a n ge s t h e FD , a n d u pda t e s a ll n e igh bor s.
Cayley is already using Wright as t he successor. When it receives t he updat e from Wright wit h a
lower cost , it changes it s locally calculat ed m et ric and FD accordingly and updat es it s neighbors
( Figure 7- 21) .
Figu r e 7 - 2 1 . Ca yle y r e ca lcu la t e s it s m e t r ic, ch a n ge s t h e FD ba se d on
t h e low e r cost a dve r t ise d by W r igh t , a n d u pda t e s it s n e igh bor s.
The updat e from Cayley has no effect at Wright because it does not sat isfy t he FC t here. At
Lilient hal t he updat e causes a local com put at ion. Lilient hal lowers t he m et ric, lowers t he FD, and
updat es it s neighbors ( Figure 7- 22) .
Figu r e 7 - 2 2 . Lilie n t h a l r e ca lcu la t e s it s m e t r ic, ch a n ge s t h e FD ba se d on
t h e u pda t e fr om Ca yle y, a n d u pda t e s it s n e igh bor s.
Alt hough t hey are rat her elaborat e and m ight t ake several readings t o fully underst and, t his and
t he previous exam ple cont ain t he im port ant core behavior of diffusing com put at ions:
Any t im e an input event occurs, perform a local calculat ion.
I f one or m ore feasible successors are found in t he t opology t able, t ake t he ones wit h t he
lowest m et ric cost as t he successors.
I f no feasible successor can be found, m ake t he rout e act ive and query t he neighbors for a
feasible successor.
Keep t he rout e act ive unt il all queries are answered by reply or by t he expirat ion of t he
act ive t im er.
I f t he diffusing calculat ion does not result in t he discovery of a feasible successor, declare
t he dest inat ion unreachable.
EIGRP Packet Formats
The I P header of an EI GRP packet specifies prot ocol num ber 88, and t he m axim um lengt h of t he
packet will be t he I P m axim um t ransm ission unit ( MTU) of t he int erface on which it is
t ransm it t edusually 1500 oct et s. Following t he I P header is an EI GRP header followed by various
Type/ Lengt h/ Value ( TLV) t riplet s. These TLVs will not only carry t he rout e ent ries but also m ay
provide fields for t he m anagem ent of t he DUAL process, m ult icast sequencing, and I OS soft ware
versions.
EIGRP Packet Header
Figure 7- 23 shows t he EI GRP header, which begins every EI GRP packet .
Figu r e 7 - 2 3 . EI GRP pa ck e t h e a de r .
V e r sion specifies t he part icular version of t he originat ing EI GRP process. The version of
t he EI GRP process it self has not changed since it s release.
Op cod e specifies t he EI GRP packet t ype, as shown in Table 7- 3. Alt hough t he I PX SAP
packet t ype is included in t he t able, a discussion of I PX EI GRP is out side t he scope of t his
book.
Ta ble 7 - 3 .
EI GRP pa ck e t
t ype s.
Op cod e Type
1
Updat e
3
Quer y
4
Reply
5
Hello
Op cod e Type
6
I PX SAP
10
SI A Query
11
SI A Reply
Ch e ck su m is a st andard I P checksum . I t is calculat ed for t he ent ire EI GRP packet ,
excluding t he I P header.
Fla g s current ly include j ust t wo flags. The right - m ost bit is I nit, which when set
( 0x00000001) indicat es t hat t he enclosed rout e ent ries are t he first in a new neighbor
relat ionship. The second bit ( 0x00000002) is t he Condit ional Receive bit , used in t he
propriet ary Reliable Mult icast ing algorit hm .
Se qu e n ce is t he 32- bit sequence num ber used by t he RTP.
ACK is t he 32- bit sequence num ber last heard from t he neighbor t o which t he packet is
being sent . A Hello packet wit h a nonzero ACK field will be t reat ed as an ACK packet rat her
t han as a Hello. Not e t hat an ACK field will only be nonzero if t he packet it self is unicast
because acknowledgm ent s are never m ult icast .
Au t on om ou s Syst e m N u m be r is t he ident ificat ion num ber of t he EI GRP dom ain.
Following t he header are t he TLVs, whose various t ypes are list ed in Table 7- 4. I PX and
AppleTalk t ypes are included, alt hough t hey are not discussed in t his book. Each TLV includes
one of t he t wo- oct et t ype num bers list ed in Table 7- 4, a t wo- oct et field specifying t he lengt h of
t he TLV, and a variable field whose form at is det erm ined by t he t ype.
Ta ble 7 - 4 . Type / Le n gt h / Va lu e
( TLV) t ype s.
N u m be r
TLV Type
General TLV Types
0x0001
EI GRP Param et ers
0x0003
Sequence
0x0004
Soft ware
Version [ * ]
0x0005
Next Mult icast
Sequence
I P- Specific TLV Types
0x0102
I P I nt ernal Rout es
0x0103
I P Ext ernal Rout es
N u m be r
TLV Type
AppleTalk- Specific TLV Types
0x0202
AppleTalk I nt ernal
Rout es
0X0203
AppleTalk Ext ernal
Rout es
0x0204
AppleTalk Cable
Configurat ion
I PX- Specific TLV Types
0x0302
I PX I nt ernal Rout es
0x0303
I PX Ext ernal
Rout es
[*]
This packet indicates whether the older software release is running (software version 0) or the newer release, as of IOS
10.3(11), 11.0(8), and 11.1(3), is running (version 1).
General TLV Fields
These TLVs carry EI GRP m anagem ent inform at ion and are not specific t o any one rout ed
prot ocol. The Param et ers TLV, which is used t o convey m et ric weight s and t he hold t im e, is
shown in Figure 7- 24. The Sequence, Soft ware Version, and Next Mult icast Sequence TLVs are
used by t he Cisco propriet ary Reliable Mult icast algorit hm and are beyond t he scope of t his book.
Figu r e 7 - 2 4 . EI GRP Pa r a m e t e r s TLV.
IP-Specific TLV Fields
Each I nt ernal and Ext ernal Rout es TLV cont ains one rout e ent ry. Every Updat e, Query, and Reply
packet cont ains at least one Rout es TLV.
The I nt ernal and Ext ernal Rout es TLVs include m et ric inform at ion for t he rout e. As not ed earlier,
t he m et rics used by EI GRP are t he sam e m et rics used by I GRP, alt hough scaled by 256.
IP Internal Routes TLV
An int ernal rout e is a pat h t o a dest inat ion wit hin t he EI GRP aut onom ous syst em . The form at of
t he I nt ernal Rout es TLV is shown in Figure 7- 25.
Figu r e 7 - 2 5 . Th e I P I n t e r n a l Rou t e s TLV.
[View full size image]
N e x t H op is t he next - hop I P address. This address m ight or m ight not be t he address of
t he originat ing rout er.
D e la y is t he sum of t he configured delays expressed in unit s of 10 m icroseconds. Not ice
t hat unlike t he 24- bit delay field of t he I GRP packet , t his field is 32 bit s. This larger field
accom m odat es t he 256 m ult iplier used by EI GRP. A delay of 0xFFFFFFFF indicat es an
unreachable rout e.
Ba n dw idt h is 256 x BW I GRP( m in) , or 2,560,000,000 divided by t he lowest configured
bandwidt h of any int erface along t he rout e. Like Delay, t his field is also eight bit s larger
t han t he I GRP field.
M TU is t he sm allest Maxim um Transm ission Unit of any link along t he rout e t o t he
dest inat ion. Alt hough an included param et er, it has never been used in t he calculat ion of
m et rics.
H op Cou n t is a num ber bet ween 0x01 and 0xFF indicat ing t he num ber of hops t o t he
dest inat ion. A rout er will advert ise a direct ly connect ed net work wit h a hop count of 0;
subsequent rout ers will record and advert ise t he rout e relat ive t o t he next - hop rout er.
Re lia bilit y is a num ber bet ween 0x01 and 0xFF t hat reflect s t he t ot al out going error rat es
of t he int erfaces along t he rout e, calculat ed on a five- m inut e exponent ially weight ed
average. 0xFF indicat es a 100 percent reliable link.
Loa d is also a num ber bet ween 0x01 and 0xFF, reflect ing t he t ot al out going load of t he
int erfaces along t he rout e, calculat ed on a five- m inut e exponent ially weight ed average.
0x01 indicat es a m inim ally loaded link.
Re se r ve d is an unused field and is always 0x0000.
Pr e fix Le n gt h specifies t he num ber of net work bit s of t he address m ask. Dest inat ion is t he
dest inat ion address of t he rout e. Alt hough t he field is shown as a t hree- oct et field in Figure
7- 25 and Figure 7- 26 ( see next sect ion) , t he field varies wit h t he specific address. For
exam ple, if t he rout e is t o 10.1.0.0/ 16, t he prefix lengt h will be 16 and t he dest inat ion will
be a t wo- oct et field cont aining 10.1. I f t he rout e is t o 192.168.17.64/ 27, t he prefix lengt h
will be 27 and t he dest inat ion will be a four- oct et field cont aining 192.168.16.64. I f t his
field is not exact ly t hree oct et s, t he TLV will be padded wit h zeros t o m ake it end on a fouroct et boundary.
Figu r e 7 - 2 6 . Th e I P Ex t e r n a l Rou t e s TLV.
[View full size image]
IP External Routes TLV
An ext ernal rout e is a pat h t hat leads t o a dest inat ion out side of t he EI GRP aut onom ous syst em
and t hat has been redist ribut ed int o t he EI GRP dom ain. Figure 7- 26 shows t he form at of t he
Ext ernal Rout es TLV:
N e x t H op is t he next - hop I P address. On a m ult iaccess net work, t he rout er advert ising t he
rout e m ight not be t he best next - hop rout er t o t he dest inat ion. For exam ple, an EI GRPspeaking rout er on an Et hernet link m ight also be speaking BGP and m ight be advert ising a
BGP- learned rout e int o t he EI GRP aut onom ous syst em . Because ot her rout ers on t he link
do not speak BGP, t hey m ight have no way of knowing t hat t he int erface t o t he BGP
speaker is t he best next - hop address. The Next Hop field allows t he " bilingual" rout er t o t ell
it s EI GRP neighbors, " Use address A.B.C.D as t he next hop inst ead of using m y int erface
address."
Or igin a t in g Rou t e r is t he I P address or rout er I D of t he rout er t hat redist ribut ed t he
ext ernal rout e int o t he EI GRP aut onom ous syst em .
Or igin a t in g Au t on om ou s Syst e m N u m be r is t he aut onom ous syst em num ber of t he
rout er originat ing t he rout e.
Ar bit r a r y Ta g m ay be used t o carry a t ag set by rout e m aps. See Chapt er 14 for
inform at ion on he use of rout e m aps.
Ex t e r n a l Pr ot ocol M e t r ic is, as t he nam e im plies, t he m et ric of t he ext ernal prot ocol. This
field is used, when dist ribut ing wit h I GRP, t o t rack t he I GRP m et ric.
Re se r ve d is an unused field and is always 0x0000.
Ex t e r n a l Pr ot ocol I D specifies t he prot ocol from which t he ext ernal rout e was learned.
Table 7- 5 list s t he possible values of t his field.
Ta ble 7 - 5 . Va lu e s of
t h e Ex t e r n a l
Pr ot ocol I D fie ld.
Code
Ex t e r n a l
Pr ot ocol
0x01
I GRP
0x02
EI GRP
0x03
St at ic Rout e
0x04
RI P
0x05
Hello
0x06
OSPF
0x07
I S- I S
0x08
EGP
0x09
BGP
Code
Ex t e r n a l
Pr ot ocol
0x0A
I DRP
0x0B
Connect ed Link
Fla g s current ly const it ut e j ust t wo flags. I f t he right - m ost bit of t he eight - bit field is set
( 0x01) , t he rout e is an ext ernal rout e. I f t he second bit is set ( 0x02) , t he rout e is a
candidat e default rout e. Default rout es are discussed in Chapt er 12.
The rem aining fields describe t he m et rics and t he dest inat ion address. The descript ions of t hese
fields are t he sam e as t hose given in t he discussion of t he I nt ernal Rout es TLV.
Address Aggregation
Chapt er 1, "Rout ing Basics," int roduced t he pract ice of subnet t ing, in which t he address m ask is
ext ended int o t he host space t o address m ult iple dat a links under one m aj or net work address.
Chapt er 6 int roduced t he pract ice of variable- lengt h subnet m asking, in which t he address m ask
is ext ended even m ore t o creat e subnet s wit hin subnet s.
From an opposit e perspect ive, a subnet address m ay be t hought of as a sum m arizat ion of a
group of sub- subnet s. And a m aj or net work address m ay be t hought of as a sum m arizat ion of a
group of subnet addresses. I n each case, t he sum m arizat ion is achieved by reducing t he lengt h
of t he address m ask.
Address aggregat ion t akes sum m arizat ion a st ep furt her by breaking t he class lim it s of m aj or
net work addresses. An aggregat e address represent s a num erically cont iguous group of net work
addresses, known as a supernet . [ 13] Figure 7- 27 shows an exam ple of an aggregat e address.
[13]
An aggregate is, more correctly, any summarized group of addresses. For clarity, in this book the term aggregate refers
to a summarization of a group of major network addresses.
Figu r e 7 - 2 7 . Th is gr ou p of n e t w or k a ddr e sse s ca n be r e pr e se n t e d w it h
a sin gle a ggr e ga t e a ddr e ss, or su bn e t .
Figure 7- 28 shows how t he aggregat e address of Figure 7- 27 is derived. For a group of net work
addresses, find t he bit s t hat are com m on t o all of t he addresses and m ask t hese bit s. The
m asked port ion is t he aggregat e address.
Figu r e 7 - 2 8 . Th e a ggr e ga t e a ddr e ss is de r ive d by m a sk in g a ll t h e
com m on bit s of a gr ou p of n u m e r ica lly con t igu ou s n e t w or k a ddr e sse s.
When designing a supernet , it is im port ant t hat t he m em ber addresses should form a com plet e,
cont iguous set of t he form erly m asked bit s. I n Figure 7- 28, for exam ple, t he 20- bit m ask of t he
aggregat e address is four bit s less t han t he m ask of t he m em ber addresses. Of t he four
" difference" bit s, not ice t hat t hey include every possible bit com binat ion from 0000 t o 1111.
Failure t o follow t his design rule could m ake t he addressing schem e confusing, could reduce t he
efficiency of aggregat e rout es, and m ight lead t o rout ing loops and black holes.
The obvious advant age of sum m ary addressing is t he conservat ion of net work resources.
Bandwidt h is conserved by advert ising fewer rout es, and CPU cycles are conserved by processing
fewer rout es. Most im port ant , m em ory is conserved by reducing t he size of t he rout e t ables.
Classless rout ing, VLSM, and aggregat e addressing t oget her provide t he m eans t o m axim ize
resource conservat ion by building address hierarchies. Unlike I GRP, EI GRP support s all of t hese
addressing st rat egies. I n Figure 7- 29, t he engineering division of Treet op Aviat ion has been
assigned 16 class C addresses. These addresses have been assigned t o t he various depart m ent s
according t o need.
Figu r e 7 - 2 9 . At Tr e e t op Avia t ion , se ve r a l de pa r t m e n t s w it h in a la r ge r
division a r e a ggr e ga t in g a ddr e sse s. I n t u r n , t h e e n t ir e division ca n be
a dve r t ise d w it h a sin gle a ggr e ga t e a ddr e ss ( 1 9 2 .1 6 8 .1 6 .0 / 2 0 ) .
The aggregat e addresses of t he engines, elect rical, and hydraulics depart m ent s are t hem selves
aggregat ed int o a single address, 192.168.16.0/ 21. That address and t he aggregat e address of
t he airfram e depart m ent are aggregat ed int o t he single address 192.168.16.0/ 20, which
represent s t he ent ire engineering division.
Ot her divisions m ay be sim ilarly represent ed. For exam ple, if Treet op Aviat ion had a t ot al of
eight divisions and if t hose divisions were all addressed sim ilarly t o t he engineering division, t he
backbone rout er at t he t op of t he hierarchy m ight have only eight rout es (Figure 7- 30) .
Figu r e 7 - 3 0 . Alt h ou gh t h e r e a r e 1 2 8 m a j or n e t w or k a ddr e sse s a n d
possibly m or e t h a n 3 2 ,0 0 0 h ost s in t h is n e t w or k , t h e ba ck bon e r ou t e r
h a s on ly e igh t a ggr e ga t e a ddr e sse s in it s r ou t e t a ble .
The hierarchical design is cont inued wit hin each depart m ent of each division by subnet t ing t he
individual net work addresses. VLSM m ay be used t o furt her divide t he subnet s. The rout ing
prot ocols will aut om at ically sum m arize t he subnet s at net work boundaries, as discussed in
previous chapt ers.
Address aggregat ion also allows bot h address conservat ion and address hierarchies in t he
I nt ernet . Wit h t he exponent ial growt h of t he I nt ernet , t wo increasing concerns have been t he
deplet ion of available I P addresses ( part icularly class B addresses) and t he huge dat abases
needed t o st ore t he I nt ernet rout ing inform at ion.
A solut ion t o t his problem is Classless I nt erdom ain Rout ing ( CI DR) . [ 14] Under CI DR, aggregat es
of class C addresses are allocat ed by t he I ANA t o t he various worldwide address assignm ent
aut horit ies such as Asia Pacific Net work I nform at ion Cent re ( APNI C) in Asia, Am erican Regist ry
for I nt ernet Num bers ( ARI N) in Nort h Am erica, and Réseaux I P Européens ( RI PE) in Europe. The
aggregat es are organized geographically, as shown in Table 7- 6.
[14]
V. Fuller, T. Li, J. I. Yu, and K. Varadhan. "Classless Inter-Domain Routing (CIDR): An Address Assignment and
Aggregation Strategy," RFC 1519. September 1993.
Ta ble 7 - 6 . CI D R a ddr e ss a lloca t ion s by
ge ogr a ph ic r e gion .
Re gion
Addr e ss Ra n ge
Re gion
Addr e ss Ra n ge
Mult iregional
192.0.0.0193.255.255.255
Europe
194.0.0.0195.255.255.255
Ot hers
196.0.0.0197.255.255.255
Nort h Am erica
198.0.0.0199.255.255.255
Cent r al/ Sout h
Am erica
200.0.0.0201.255.255.255
Pacific Rim
202.0.0.0203.255.255.255
Ot hers
204.0.0.0205.255.255.255
Ot hers
206.0.0.0207.255.255.255
The address assignm ent aut horit ies in t urn divide t heir port ions am ong t he regional I nt ernet
Service Providers ( I SPs) . When an organizat ion applies for an I P address and requires
addressing for fewer t han 32 subnet s and 4096 host s, it will be given a cont iguous group of class
C addresses called a CI DR block.
I n t his way, t he I nt ernet rout ers of individual organizat ions m ight advert ise a single sum m ary
address t o t heir I SP. The I SP, in t urn, aggregat es all of it s addresses, and ideally all I SPs in a
region of t he world m ay be sum m arized by t he addresses of Table 7- 6. Knowing t hat t he current
size of t he I nt ernet rout ing t able is approaching 200,000 rout es, it is obvious t hat CI DR has not
been adhered t o as well as int ended. Nonet heless, t he concept is a good one. Sim ilar effort s are
under way t o const rain I Pv6 address assignm ent s geographically; we can only hope t hat t he
effort s are m ore successful t han t hey were wit h I Pv4.
EIGRP and IPv6
Configuring EIGRP
The case st udies in t his sect ion dem onst rat e a basic EI GRP configurat ion and t hen exam ine
sum m arizat ion t echniques and int eroperabilit y wit h I GRP.
Case Study: A Basic EIGRP Configuration
EI GRP requires only t wo st eps t o begin t he rout ing process:
St e p 1 .
Enable EI GRP wit h t he com m and r ou t e r e igr p pr ocess- id.
St e p 2 .
Specify each m aj or net work on which t o run EI GRP wit h t he n e t w or k
com m and.
The process I D m ay be any num ber bet ween 1 and 65535 ( 0 is not allowed) , and it m ay be
arbit rarily chosen by t he net work adm inist rat or, if it is t he sam e for all EI GRP processes in all
rout ers t hat m ust share inform at ion. Alt ernat ively, t he num ber m ight be a publicly assigned
aut onom ous syst em num ber. Figure 7- 31 shows a sim ple net work; t he configurat ions for t he
t hree rout ers are displayed in Exam ple 7- 14, Exam ple 7- 15, and Exam ple 7- 16.
Figu r e 7 - 3 1 . Un lik e I GRP, EI GRP w ill su ppor t t h e VLSM r e qu ir e m e n t s
of t h is n e t w or k .
Ex a m ple 7 - 1 4 . Ea r h a r t .
router eigrp 15
network 172.20.0.0
Ex a m ple 7 - 1 5 . Coch r a n .
router eigrp 15
network 172.20.0.0
network 192.167.17.0
Ex a m ple 7 - 1 6 . Lin dbe r gh .
router eigrp 15
network 172.20.0.0
network 192.167.16.0
Earhart 's rout e t able is shown in Exam ple 7- 17. The t able shows t hat t he default EI GRP
adm inist rat ive dist ance is 90 and t hat net work 172.20.0.0 is variably subnet t ed.
Ex a m ple 7 - 1 7 . Ea r h a r t 's r ou t e t a ble .
Earhart#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, 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
172.20.0.0/16 is variably subnetted, 4 subnets, 2 masks
C
172.20.10.0/24 is directly connected, Ethernet0
C
172.20.15.4/30 is directly connected, Serial0.1
C
172.20.15.0/30 is directly connected, Serial0.2
D
192.168.17.0/24 [90/2195456] via 172.20.15.6, 00:00:01, Serial0.1
D
192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:01, Serial0.2
Earhart#
The net work of Figure 7- 31 uses default m et rics, unlike t he earlier exam ples in t his chapt er, so a
review of t he EI GRP m et ric calculat ion in a m ore realist ic scenario m ight be useful.
Tracing t he rout e from Earhart t o net work 192.168.16.0, t he pat h t raverses a serial int erface
and an Et hernet int erface, each wit h default m et ric values. The m inim um bandwidt h of t he rout e
will be t hat of t he serial int erface, [ 15] and t he delay will be t he sum of t he t wo int erface delays.
Referring back t o Table 7- 1:
[15]
Remember that the default bandwidth of a serial interface is 1544K.
BW EI GRP( m in) = 256 x 6476 = 1657856
DLYEI GRP( sum ) = 256 x ( 2000 + 100) = 537600
Therefore,
Met ric = 1657856 + 537600 = 2195456
Case Study: Unequal-Cost Load Balancing
Given up t o 16 parallel rout es of equal cost , [ 16] EI GRP will do equal- cost load balancing under
t he sam e CEF/ fast / process swit ching const raint s as RI P. Unlike RI P, EI GRP can also perform
unequal- cost load balancing. An addit ional serial link has been added bet ween Earhart and
Cochran in Figure 7- 32, wit h a configured bandwidt h of 256K. The goal is t o have Earhart
perform unequal- cost load balancing across t hese t wo linksspreading t he t raffic load inversely
proport ional t o t he m et rics of t he link.
[16]
The default is four paths. See the case study on setting maximum paths for further details.
Figu r e 7 - 3 2 . EI GRP ca n be con figu r e d t o pe r for m u n e qu a l- cost loa d
ba la n cin g a cr oss lin k s su ch a s t h e t w o be t w e e n Ea r h a r t a n d Coch r a n .
Exam ining t he rout e from Earhart 's S0.1 int erface t o net work 192.168.17.0, t he m inim um
bandwidt h is 1544K ( assum ing Cochran's Et hernet int erface is using t he default 100000K
bandwidt h for Fast Et hernet ) . Referring t o Table 7- 1, DLYEI GRP( sum ) for t he serial int erface and
t he Fast Et hernet int erface is 256 x ( 2000 + 10 ) = 514560. BW EI GRP( m in) is 256 x ( 10 7 / 1544) =
1657856, so t he com posit e m et ric of t he rout e is 514560 + 1657856) = 2172416.
The m inim um bandwidt h on t he rout e via Earhart 's S0.3 t o 192.168.17.0 is 256K; DLYEI GRP( sum )
is t he sam e as on t he first rout e. Therefore, t he com posit e m et ric for t his rout e is 256 x
( 1 0 7 / 256) + 514560 = 10514432. Wit hout furt her configurat ion, EI GRP will sim ply select t he
pat h wit h t he lowest m et ric cost . Exam ple 7- 18 shows t hat Earhart is using only t he pat h via
Serial 0.1, wit h a m et ric of 2172416.
Ex a m ple 7 - 1 8 . Ea r h a r t is u sin g on ly t h e low e st - cost lin k t o n e t w or k
1 9 2 .1 6 8 .1 7 .0 . Addit ion a l con figu r a t ion is n e e de d t o e n a ble u n e qu a lcost loa d ba la n cin g.
Earhart#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E EGP
i - IS-IS, 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
172.20.0.0/16 is variably subnetted, 4 subnets, 2 masks
C
172.20.10.0/27 is directly connected, Ethernet0
C
172.20.15.4/30 is directly connected, Serial0.1
C
172.20.15.0/30 is directly connected, Serial0.2
C
172.20.15.8/30 is directly connected, Serial0.3
D
192.168.17.0/24 [90/2172416] via 172.20.15.6, 00:00:09, Serial0.1
D
192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:09, Serial0.2
Earhart#
The va r ia n ce com m and is used t o det erm ine which rout es are feasible for unequal- cost load
sharing. Variance defines a m ult iplier by which a m et ric m ay differ, or vary, from t he m et ric of
t he lowest - cost rout e. Any rout e whose m et ric exceeds t he m et ric of t he lowest - cost rout e,
m ult iplied by t he variance, will not be considered a feasible rout e.
The default variance is one, m eaning t hat t he m et rics of m ult iple rout es m ust be equal, t o load
balance. Variance m ust be specified in whole num bers.
The m et ric of Earhart 's rout e t hrough S0.3 is 10514432/ 2172416 = 4.8 t im es larger t han t he
m et ric of t he S0.1 rout e. So t o conduct unequal- cost load balancing over bot h links, t he variance
at Earhart should be five. The EI GRP configurat ion is in Exam ple 7- 19.
Ex a m ple 7 - 1 9 . Ea r h a r t 's con figu r a t ion u se s a va r ia n ce of five t o
pe r for m u n e qu a l- cost loa d sh a r in g u sin g EI GRP.
router eigrp 15
network 172.20.0.0
variance 5
Aft er specifying a variance of five at Earhart , it s rout e t able will include t he second, higher- cost
rout e ( Exam ple 7- 20) . The following t hree condit ions m ust be m et for a rout e t o be included in
unequal- cost load sharing:
The m axim um - pat hs lim it m ust not be exceeded as a result of adding t he rout e t o a loadsharing " group."
The next - hop rout er m ust be m et rically closer t o t he dest inat ion. That is, it s m et ric for t he
rout e m ust be sm aller t han t he local rout er's m et ric. A next - hop rout er, being closer t o t he
dest inat ion, is oft en referred t o as t he downst ream rout er.
The m et ric of t he lowest - cost rout e, when m ult iplied by t he variance, m ust be great er t han
t he m et ric of t he rout e t o be added.
Ex a m ple 7 - 2 0 . Th e com posit e m e t r ic of t h e se con d pa t h t o
1 9 2 .1 6 8 .1 7 .0 fr om Ea r h a r t is 1 0 5 1 4 4 3 2 , or 4 .8 t im e s t h e m e t r ic of t h e
low e st - cost r ou t e . EI GRP w ill e n t e r t h e se con d pa t h in t o t h e r ou t e
t a ble if t h e va r ia n ce is se t t o a t le a st five .
Earhart(config)#router eigrp 15
Earhart(config-router)#variance 5
Earhart(config-router)#^Z
Earhart#clear ip route *
Earhart#show ip route
Gateway of last resort is not set
172.20.0.0/16 is variably subnetted, 4 subnets, 2 masks
C
172.20.10.0/24 is directly connected, Ethernet0
C
172.20.15.4/30 is directly connected, Serial0.1
C
172.20.15.0/30 is directly connected, Serial0.2
C
172.20.15.8/30 is directly connected, Serial0.3
D
192.168.17.0/24 [90/2172416] via 172.20.15.6, 00:00:02, Serial0.1
[90/10514432] via 172.20.15.10, 00:00:02, Serial0.3
D
192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:02, Serial0.2
Earhart#
The rules concerning per dest inat ion versus per packet load sharing, discussed in Chapt er 3,
" St at ic Rout ing," apply here as well. Load sharing is per dest inat ion if t he packet is fast swit ched
or CEF swit ched using t he default CEF configurat ion, and per packet if process swit ching is used
or if t he CEF configurat ion was m odified. Exam ple 7- 21 shows a debug out put result ing from 20
ping packet s being sent t hrough Earhart ; CEF and fast swit ching have been t urned off wit h n o ip
ce f and n o ip r ou t e - ca ch e , and t he rout er is perform ing unequal- cost , per packet load
balancing. For every five packet s sent over t he 1544K link ( t o next hop 172.20.15.6) , one
packet is sent over t he 256K link ( t o next hop 172.20.15.10) . This corresponds t o t he
approxim at ely five- t o- one variance of t he m et rics of t hese t wo pat hs.
Ex a m ple 7 - 2 1 . Pe r pa ck e t loa d sh a r in g is be in g pe r for m e d, w it h on e
pa ck e t be in g se n t ove r t h e h igh - cost lin k for e ve r y five pa ck e t s se n t
ove r t h e low - cost lin k .
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.3), g=172.20.15.10,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.3), g=172.20.15.10,
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
IP: s=172.20.15.2 (Serial
len 100, forward
Earhart#
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
2), d=192.168.17.1 (Serial0.3), g=172.20.15.10,
I f variance is set at one, EI GRP ent ers only t he lowest - cost rout e t o a dest inat ion int o t he rout e
t able. I n som e sit uat ions, howeverfor exam ple, t o decrease reconvergence t im e or aid in
t roubleshoot ingall feasible rout es should be ent ered int o t he t able, even t hough no load
balancing should occur. All packet s should use t he lowest - cost rout e and swit ch t o t he next - best
pat h only if t he prim ary fails. There is an im plicit default com m and ( t hat is, it exist s, but is not
observed in t he configurat ion file) of t r a ffic- sh a r e ba la n ce d. To configure t he rout er t o only
use t he m inim um - cost pat h even when m ult iple pat hs are shown in t he rout e t able, change t his
default t o t r a ffic- sh a r e m in. I f t here are m ult iple m inim um - cost pat hs and t r a ffic- sh a r e m in
is configured, EI GRP will perform equal- cost load balancing.
Case Study: Setting Maximum Paths
The m axim um num ber of rout es over which EI GRP can load balance is set wit h t he m a x im u m pa t h s pat hs com m and. pat hs m ay be any num ber from 1 t o 16 in I OS 12.3( 2) T and lat er
12.3( T) releases and any num ber from 1 t o 6 in earlier versions. The default for all versions is 4.
Figure 7- 33 shows t hree parallel pat hs of varying cost s from Earhart t o address 172.18.0.0. The
net work adm inist rat or want s t o load balance over a m axim um of only t wo of t hese rout es while
ensuring t hat if eit her of t hese pat hs should fail, t he t hird rout e will replace it .
Figu r e 7 - 3 3 . Th e m a x im u m - pa t h s a n d va r ia n ce com m a n ds ca n be u se d
t oge t h e r t o con figu r e loa d ba la n cin g ove r on ly t w o of t h e t h r e e lin k s
be t w e e n Ea r h a r t a n d Joh n son . I f e it h e r lin k fa ils, t h e t h ir d w ill t a k e it s
pla ce .
The m et rics from Earhart are
Via S0.4: 256 x ( 9765 + ( 2000 + 10) ) = 3014400
Via S0.5: 256 x ( 19531 + ( 2000 + 10) ) = 5514496
Via S0.6: 256 x ( 78125 + ( 2000 + 10) ) = 20514560
The m et ric of t he S0.6 rout e is 6.8 t im es as large as t he lowest - cost m et ric, so t he variance is
seven.
Earhart 's EI GRP configurat ion is displayed in Exam ple 7- 22.
Ex a m ple 7 - 2 2 . Ea r h a r t 's con figu r a t ion u se s t h e va r ia n ce com m a n d a n d
t h e m a x im u m - pa t h s com m a n d t o pr ovide u n e qu a l- cost loa d sh a r in g
ove r a spe cifie d m a x im u m n u m be r of pa t h s.
router eigrp 15
variance 7
network 172.20.0.0
maximum-paths 2
The va r ia n ce com m and ensures t hat any of t he t hree rout es t o 172.18.0.0 is feasible; t he
m a x im u m - pa t h s com m and lim it s t he load- sharing group t o only t he t wo best rout es. The
result s of t his configurat ion can be seen in Exam ple 7- 23. The first rout e t able shows t hat
Earhart was load balancing over t he t wo links wit h t he lowest of t he t hree m et rics, S0.4 and
S0.5. Aft er a failure of t he S0.4 link, t he second rout e t able shows t hat t he rout er is now load
balancing over t he S0.5 and S0.6 links. I n each inst ance, t he rout er will load balance inversely
proport ional t o t he m et rics of t he t wo pat hs.
Ex a m ple 7 - 2 3 . Th e r ou t e t a ble for Ea r h a r t , be for e a n d a ft e r t h e fa ilu r e
of on e of t h r e e lin k s, sh ow s t h e r e su lt s of u sin g t h e va r ia n ce a n d
m a x im u m - pa t h s com m a n ds t o con figu r e loa d sh a r in g t o 1 7 2 .1 8 .0 .0 .
Earhart#debug eigrp neighbor
EIGRP Neighbors debugging is on
Earhart#show ip route
Gateway of last resort is not set
D
172.18.0.0/16 [90/5514496] via 172.20.15.18, 00:00:16, Serial0.5
[90/3014400] via 172.20.15.14, 00:00:16, Serial0.4
172.20.0.0/16 is variably subnetted, 7 subnets, 2 masks
C
172.20.15.20/30 is directly connected, Serial0.6
C
172.20.15.16/30 is directly connected, Serial0.5
C
172.20.10.0/24 is directly connected, Ethernet0
C
172.20.15.4/30 is directly connected, Serial0.1
C
172.20.15.0/30 is directly connected, Serial0.2
C
172.20.15.12/30 is directly connected, Serial0.4
C
172.20.15.8/30 is directly connected, Serial0.3
D
192.168.17.0/24 [90/2195456] via 172.20.15.6, 00:00:18, Serial0.1
[90/10537472] via 172.20.15.10, 00:00:18, Serial0.3
D
192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:19, Serial0.2
Earhart#
1w6d: EIGRP: Holdtime expired
1w6d: EIGRP: Neighbor 172.20.15.14 went down on Serial0.4
Earhart#show ip route
Gateway of last resort is not set
D
172.18.0.0/16 [90/5514496] via 172.20.15.18, 00:00:09, Serial0.5
[90/20514560] via 172.20.15.22, 00:00:09, Serial0.6
172.20.0.0/16 is variably subnetted, 7 subnets, 2 masks
C
172.20.15.20/30 is directly connected, Serial0.6
C
172.20.15.16/30 is directly connected, Serial0.5
C
172.20.10.0/24 is directly connected, Ethernet0
C
172.20.15.4/30 is directly connected, Serial0.1
C
172.20.15.0/30 is directly connected, Serial0.2
C
172.20.15.12/30 is directly connected, Serial0.4
C
172.20.15.8/30 is directly connected, Serial0.3
D
192.168.17.0/24 [90/2195456] via 172.20.15.6, 00:00:26, Serial0.1
[90/10537472] via 172.20.15.10, 00:00:26, Serial0.3
D
192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:26, Serial0.2
Earhart#
Care should be t aken when configuring m ult iple parallel pat hs in a net work. Too m any parallel
pat hs can increase t he am ount of t im e it t akes for EI GRP t o converge when a link fails, because
t he num ber of neighboring rout ers has increased, t herefore increasing t he querying scope.
Case Study: Multiple EIGRP Processes
Two new rout ers, Bleriot and Post , have been added t o t he net work. A decision has been m ade
t o creat e t wo EI GRP process dom ains in t he net work wit h no com m unicat ions bet ween t he t wo.
Figure 7- 34 shows t he t wo aut onom ous syst em s and t he relat ed links for each.
Figu r e 7 - 3 4 . Th e r ou t e r s Ble r iot a n d Coch r a n w ill e a ch r u n m u lt iple
EI GRP pr oce sse s t o fa cilit a t e t h e cr e a t ion of se pa r a t e a u t on om ou s
syst e m s ( AS 1 0 a n d AS 1 5 ) w it h in t h is I GP.
[View full size image]
The configurat ions for Post , Johnson, Lindbergh, and Earhart are st raight forward: Johnson,
Earhart , and Lindbergh will run EI GRP 15, and Post will run EI GRP 10. At Bleriot , t he
configurat ion will be as displayed in Exam ple 7- 24.
Ex a m ple 7 - 2 4 . Ble r iot 's con figu r a t ion for EI GRP 1 5 a n d EI GRP 1 0 .
router eigrp 15
network 172.20.0.0
!
router eigrp 10
network 10.0.0.0
Each process will run only on t he int erfaces of t he net works specified. At Cochran, all int erfaces
ot her t hen FA0/ 0 belong t o net work 172.20.0.0 ( see Exam ple 7- 25) .
Using t he pa ssive - in t e r fa ce com m and prevent s EI GRP Hellos from being sent on dat a links
where t hey don't belong. Not e t hat because Cochran's int erfaces are in net work 172.20.0.0, t he
pa ssive - in t e r fa ce com m and is used t o rest rict unnecessary rout ing prot ocol t raffic. For EI GRP,
t his com m and blocks unnecessary Hellos. No adj acencies will be form ed; t herefore, no ot her
EI GRP t raffic will be sent .
Ex a m ple 7 - 2 5 . Coch r a n 's EI GRP 1 5 a n d EI GRP 1 0 con figu r a t ion
r e qu ir e s pa ssive in t e r fa ce s be ca u se t h e sa m e m a j or n e t w or k n u m be r
is u se d on bot h of Coch r a n 's con n e ct e d in t e r fa ce s.
router eigrp 15
passive-interface Fastethernet0/1
network 172.20.0.0
!
router eigrp 10
passive-interface Serial0/0.1
passive-interface Serial 0/0.2
network 172.20.0.0
Bleriot 's neighbor t able ( Exam ple 7- 26) shows t hat t here is one neighbor for EI GRP process 10,
10.108.16.2, and one neighbor for process 15, 172.20.33.1.
Ex a m ple 7 - 2 6 . Th e n e igh bor s a ssocia t e d w it h e a ch of t h e m u lt iple
EI GRP pr oce sse s a r e displa ye d u sin g t h e sh ow ip e igr p n e igh bor
com m a n d.
Bleriot#show ip eigrp neighbors
IP-EIGRP neighbors for process 15
H
Address
Interface
0
172.20.33.1
Fa0/0
IP-EIGRP neighbors for process 10
H
Address
Interface
0
10.108.16.2
Bleriot#
Fa0/1
Hold Uptime
(sec)
11 00:31:19
SRTT
(ms)
34
RTO
Hold Uptime
(sec)
10 00:19:21
SRTT
(ms)
289
RTO
204
1734
Q
Cnt
0
Seq
Num
44
Q
Cnt
0
Seq
Num
6
I n lieu of passive int erfaces, t he net work st at em ent for EI GRP can be configured wit h wildcard
bit s. The wildcard bit s specify which bit s of t he address are t o be used when ident ifying
int erfaces t o include in t he EI GRP process.
Cochran's configurat ion is m odified t o t hat shown in Exam ple 7- 27.
Ex a m ple 7 - 2 7 . Coch r a n 's EI GRP 1 5 a n d EI GRP 1 0 con figu r a t ion u se s
w ildca r d bit s w it h t h e n e t w or k t o n a r r ow dow n t h e in t e r fa ce s t h a t w ill
r u n EI GRP for a give n pr oce ss.
router eigrp 15
network 172.20.15.0 0.0.0.255
!
router eigrp 10
network 172.20.32.0 0.0.0.255
Cochran's configurat ion in Exam ple 7- 27 specifies t hat int erfaces wit h addresses wit h t he first
t hree oct et s equal t o 172.20.15 run EI GRP process 15, and int erfaces wit h t he first t hree oct et s
equal t o 172.20.32 run EI GRP process 10.
Case Study: Disabling Automatic Summarization
By default , EI GRP sum m arizes at net work boundaries as do t he prot ocols covered in previous
chapt ers. Unlike t hose prot ocols, however, EI GRP's aut om at ic sum m arizat ion can be disabled.
Look at Bleriot 's rout e t able in Exam ple 7- 28. Not ice t hat t he ent ry for address 172.20.32.0 is
known via Fast Et hernet 0/ 0, even t hough t hat pat h goes t hrough one Fast Et hernet link and one
serial link, from Bleriot , t hrough Earhart t o Cochran. The pat h via Post , at t ached t o Fast Et hernet
0/ 1, is only one Fast Et hernet hop away. Look m ore closely at t he rout e t able, and you'll see t he
only ent ry for an address ot her t hen 10.108.16.0 known via Fast Et hernet 0/ 1 is 172.20.0.0/ 16.
Post has sum m arized t he 172.20.32.0 address before it advert ises it t o Bleriot over t he 10.0.0.0
net work boundary. To enable Bleriot t o forward t raffic t o 172.20.32.0 via Post , disable aut om at ic
sum m arizat ion on Post using t he com m and n o a u t o- su m m a r y .
Ex a m ple 7 - 2 8 . EI GRP a u t om a t ic su m m a r iza t ion ca n ca u se , in som e
ca se s, su b- opt im a l r ou t e ch oice s.
Bleriot#show ip route
Gateway of last resort is not set
D
172.18.0.0/16 [90/3016960] via 172.20.33.1, 00:26:42, FastEthernet0/0
172.20.0.0/16 is variably subnetted, 10 subnets, 4 masks
D
172.20.32.0/24 [90/2174976] via 172.20.33.1, 00:14:46, FastEthernet0/0
C
172.20.33.0/24 is directly connected, FastEthernet0/0
D
172.20.15.20/30
[90/20514560] via 172.20.33.1, 00:20:28, FastEthernet0/0
D
172.20.15.16/30
[90/5514496] via 172.20.33.1, 00:20:28, FastEthernet0/0
D
172.20.10.0/27 [90/284160] via 172.20.33.1, 00:43:34, FastEthernet0/0
D
172.20.15.4/30 [90/2172416] via 172.20.33.1, 00:26:59, FastEthernet0/0
D
172.20.15.0/30 [90/2172416] via 172.20.33.1, 00:27:18, FastEthernet0/0
D
172.20.0.0/16 [90/284160] via 10.108.16.2, 00:14:50, FastEthernet0/1
D
172.20.15.12/30
[90/3014400] via 172.20.33.1, 00:26:49, FastEthernet0/0
D
172.20.15.8/30
[90/10514432] via 172.20.33.1, 00:20:47, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
C
10.108.16.0 is directly connected, FastEthernet0/1
D
192.168.16.0/24 [90/2198017] via 172.20.33.1, 00:27:33, FastEthernet0/0
D
192.168.17.0/24 [90/2174976] via 172.20.33.1, 00:00:38, FastEthernet0/0
Bleriot#
Post 's configurat ion is displayed in Exam ple 7- 29.
Ex a m ple 7 - 2 9 . Post 's con figu r a t ion disa ble s a u t om a t ic su m m a r iza t ion
for EI GRP.
router eigrp 10
network 10.0.0.0
network 172.20.0.0
no auto-summary
Bleriot 's new rout e t able is shown in Exam ple 7- 30.
Ex a m ple 7 - 3 0 . Aft e r disa blin g EI GRP a u t om a t ic su m m a r iza t ion ,
su bn e t s of dist a n t a ddr e sse s ca n be se e n in t h e r ou t e t a ble s.
Bleriot#show ip route
Gateway of last resort is not set
D
172.18.0.0/16 [90/3016960] via 172.20.33.1, 00:35:27, FastEthernet0/0
172.20.0.0/16 is variably subnetted, 9 subnets, 3 masks
D
172.20.32.0/24 [90/284160] via 10.108.16.2, 00:00:55, FastEthernet0/1
C
172.20.33.0/24 is directly connected, FastEthernet0/0
D
172.20.15.20/30
[90/20514560] via 172.20.33.1, 00:29:13, FastEthernet0/0
D
172.20.15.16/30
[90/5514496] via 172.20.33.1, 00:29:13, FastEthernet0/0
D
172.20.10.0/27 [90/284160] via 172.20.33.1, 00:52:19, FastEthernet0/0
D
172.20.15.4/30 [90/2172416] via 172.20.33.1, 00:35:44, FastEthernet0/0
D
172.20.15.0/30 [90/2172416] via 172.20.33.1, 00:36:03, FastEthernet0/0
D
172.20.15.12/30
[90/3014400] via 172.20.33.1, 00:35:34, FastEthernet0/0
D
172.20.15.8/30
[90/10514432] via 172.20.33.1, 00:29:20, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
C
10.108.16.0 is directly connected, FastEthernet0/1
D
192.168.16.0/24 [90/2198016] via 172.20.33.1, 00:36:06, FastEthernet0/0
D
192.168.17.0/24 [90/2174976] via 172.20.33.1, 00:00:38, FastEthernet0/0
Bleriot#
Figure 7- 35 shows anot her sit uat ion in which disabling sum m arizat ion is useful.
Figu r e 7 - 3 5 . D isa blin g a u t om a t ic su m m a r iza t ion a t Coch r a n a n d
Lin dbe r gh pr e ve n t s a m bigu ou s r ou t in g t o n e t w or k 1 9 2 .1 6 8 .1 8 .0 .
New Et hernet links have been added t o rout ers Cochran and Lindbergh, and t heir addresses
creat e a discont iguous subnet . The default behavior of bot h rout ers is t o see t hem selves as
border rout ers bet ween m aj or net works 172.20.0.0 and 192.168.18.0. As a result , Earhart will
receive sum m ary advert isem ent s t o 192.168.18.0 on it s serial int erfaces t o bot h Lindbergh and
Cochran. The result is an am biguous rout ing sit uat ion in which Earhart records t wo equal- cost
pat hs t o 192.168.18.0; a packet dest ined for one of t he subnet s m ight or m ight not be rout ed t o
t he correct link.
Aft er disabling aut om at ic sum m arizat ion, Lindbergh's configurat ion will be as in Exam ple 7- 31.
Ex a m ple 7 - 3 1 . Lin dbe r gh 's con figu r a t ion disa ble s a u t om a t ic
su m m a r iza t ion .
router eigrp 15
network 172.20.0.0
network 192.168.16.0
network 192.168.18.0
no auto-summary
By t urning off sum m arizat ion at Lindbergh and Cochran, t he individual subnet s
192.168.18.24/ 29 and 192.168.18.128/ 25 will be advert ised int o net work 172.20.0.0,
elim inat ing t he am biguit ies at Earhart .
Case Study: Stub Routing
Recall t he discussion of DUAL earlier in t his chapt er. When an ent ry in a rout er's EI GRP t opology
t able changes for t he worse ( eit her t he m et ric increases, or t he successor is no longer
accessible) , if t here is no feasible successor for t he address, t he ent ry goes int o Act ive st at e, and
t he rout er sends query packet s t o all it s neighbors. I f Earhart 's link t o Yeager, in Figure 7- 36,
goes down, Earhart sends queries t o all it s neighbors, including Johnson and Lindbergh, t o find
out if any neighbors have a pat h t o Yeager. Earhart cannot m odify it s act ive ent ries in t he
t opology t able unt il it hears responses from all it s queries regarding t hat ent ry. I f a problem
develops on t he link t o Lindbergh before Earhart has received a response t o t he query it sent
about Yeager's addresses, Yeager's addresses will rem ain Act ive, even if t he link bet ween
Earhart and Yeager com es back up.
Figu r e 7 - 3 6 . Ye a ge r is a dde d t o t h e n e t w or k w it h a sin gle lin k t o
Ea r h a r t .
Johnson and Lindbergh, in Figure 7- 36, do not have back- door rout es t o any ot her sit e in t he
net work. They are spoke rout ers in a hub- and- spoke design. The rout ers are not used t o provide
t ransit pat hs t o any addresses in t he net work. When Lindbergh or Johnson need t o forward a
packet t o an address t hat is not local t o it s sit e, t he packet is forwarded t o Earhart . Lindbergh
knows of one pat h t o 172.20.10.0, for inst ance, and t hat pat h is via Earhart . There is no need t o
send Johnson queries about addresses in ot her locat ions of t he net work and risk causing net work
inst abilit ies. Johnson and Lindbergh can be configured wit h st ub rout ing.
A rout er t hat has EI GRP St ub neighbors will not send queries t o t he st ubs, t hereby elim inat ing
t he chance t hat a st ub- configured rem ot e sit e will cause st uck in act ive condit ions, and rout ing
inst abilit ies in ot her part s of t he net work.
Johnson is configured as an EI GRP st ub rout er. Johnson's st ub rout er configurat ion is displayed
in Exam ple 7- 32.
Ex a m ple 7 - 3 2 . Joh n son 's EI GRP st u b r ou t e r con figu r a t ion .
router eigrp 15
eigrp stub
No configurat ion changes are required on Earhart , t he hub rout er.
The com m and e igr p st u b causes Johnson t o send updat es cont aining it s connect ed and
sum m ary rout es only. Johnson can be configured t o include any com binat ion of connect ed
rout es, sum m ary rout es, st at ic rout es, or rout es t hat have been redist ribut ed int o EI GRP, wit h
t he com m and:
eigrp stub {connected | redistributed | static | summary | receive-only}
Johnson can also be configured t o not send any rout e inform at ion in updat es, wit h t he r e ce ive on ly opt ion. Wit h t he r e ce ive - on ly opt ion, t he rem ot e rout er will not include any addresses in
an updat e. Addresses connect ed t o t he Johnson rout er would have t o be advert ised t o t he rest of
t he net work in som e ot her way t o ensure t hat t raffic can reach t he sit e, perhaps wit h st at ic
rout es configured on Earhart .
To verify a neighbor is configured as a st ub rout er, use t he com m and sh ow ip e igr p n e igh bor
de t a il on t he hub rout er, as shown in Exam ple 7- 33. Earhart 's out put shows t hat Johnson is
configured as a st ub.
Ex a m ple 7 - 3 3 . sh ow ip e igr p n e igh bor de t a il displa ys w h ich n e igh bor
r ou t e r s a r e con figu r e d a s EI GRP st u bs.
Earhart#show ip eigrp neighbor detail
IP-EIGRP neighbors for process 15
H
Address
Interface
Hold Uptime
(sec)
7
172.20.33.2
Et1
11 00:00:10
Version 12.1/1.2, Retrans: 0, Retries: 0
6
10.15.15.253
Et2
11 00:00:10
Version 12.3/1.2, Retrans: 1, Retries: 0
5
172.20.15.22
Se0.6
11 00:00:13
Version 12.3/1.2, Retrans: 0, Retries: 0
Stub Peer Advertising ( CONNECTED SUMMARY ) Routes
4
172.20.15.14
Se0.4
11 00:00:13
Version 12.3/1.2, Retrans: 0, Retries: 0
Stub Peer Advertising ( CONNECTED SUMMARY ) Routes
3
172.20.15.18
Se0.5
10 00:00:13
Version 12.3/1.2, Retrans: 0, Retries: 0
Stub Peer Advertising ( CONNECTED SUMMARY ) Routes
0
172.20.15.2
Se0.2
11 00:15:48
Version 12.3/1.2, Retrans: 0, Retries: 0
2
172.20.15.10
Se0.3
13 00:45:40
Version 12.3/1.2, Retrans: 0, Retries: 0
1
172.20.15.6
Se0.1
11 00:46:01
Version 12.3/1.2, Retrans: 0, Retries: 0
Earhart#
SRTT
(ms)
12
RTO
200
Q
Cnt
0
12
200
0
6
298
1788
0
73
927
5000
0
81
817
4902
0
80
274
1644
0
13
72
570
0
59
61
366
0
57
Earhart has t hree st ub neighbors. They are connect ed t o t he t hree links t o Johnson:
Seq Type
Num
13
172.20.15.22, 172.20.15.14, and 172.20.15.17.
Now, suppose a new link is added bet ween Lindbergh and Cochran t o add redundancy for t raffic
connect ed t o Lindbergh's LAN t raveling int o t he core of t he net work, as shown in Figure 7- 37.
Before Lindbergh is configured as a st ub, when t he links bet ween Cochran and Earhart fail,
Cochran will send queries t o Lindbergh regarding alt ernat e pat hs t o t he addresses in it s t opology
t able, 172.20.10.0 for inst ance. Lindbergh responds wit h a posit ive reply, because Lindbergh has
an ent ry in it s t opology t able for 172.20.10.0 via Earhart . Traffic from Cochran t o 172.20.10.1
t ravels via Lindbergh.
Figu r e 7 - 3 7 . A n e w lin k is a dde d be t w e e n Lin dbe r gh a n d Coch r a n t o
a dd r e du n da n cy for t r a ffic con n e ct e d t o Lin dbe r gh 's LAN t r a ve lin g in t o
t h e cor e of t h e n e t w or k .
Alt hough t his is an alt ernat e pat h, forwarding t raffic t hrough a rem ot e sit e is not always
desirable. I n t his case, Lindbergh's links are t here t o allow redundancy from Lindbergh's
addresses t o core addresses, not t o enable Lindbergh t o act as a t ransit rout er. The bandwidt h
m ight not be sufficient t o provide t ransit rout ing. St ub rout ing easily solves t his problem . As a
st ub, no queries are sent t o Lindbergh, so Lindbergh will not m ake it self available t o Cochran as
an alt ernat e pat h. Furt herm ore, Lindbergh only sends updat es cont aining connect ed, sum m ary,
st at ic, or redist ribut ed rout es, not rem ot e rout es, such as 172.20.10.0.
Exam ple 7- 34 shows Cochran's EI GRP neighbors when Lindbergh ( connect ed t o Serial 0/ 0.4) is
not configured as a st ub rout er. Cochran's t wo links t o Earhart are brought down. Cochran's
subsequent t opology t able (Exam ple 7- 35) shows all addresses are accessible via Lindbergh
( Serial 0/ 0.4) .
Ex a m ple 7 - 3 4 . Coch r a n 's EI GRP n e igh bor t a ble sh ow s it s n e igh bor s.
Lin dbe r gh is n ot a st u b.
Cochran#show ip eigrp neighbor detail
IP-EIGRP neighbors for process 15
H
Address
Interface
2
Hold Uptime
(sec)
10 00:00:18
172.20.15.26
Se0/0.4
Version 12.3/1.2, Retrans: 0, Retries: 0
1
172.20.15.9
Se0/0.2
14 00:41:58
Version 12.1/1.2, Retrans: 1, Retries: 0
0
172.20.15.5
Se0/0.1
11 00:49:12
Version 12.1/1.2, Retrans: 2, Retries: 0
IP-EIGRP neighbors for process 10
H
Address
Interface
Hold Uptime
(sec)
0
172.20.32.2
Fa0/1
13 00:42:01
Version 12.1/1.2, Retrans: 2, Retries: 0
Cochran#
SRTT
(ms)
1152
RTO
5000
Q
Cnt
0
Seq
Num
34
104
624
0
205
99
594
0
206
SRTT
(ms)
60
RTO
Q
Cnt
0
Seq
Num
14
360
Ex a m ple 7 - 3 5 . Aft e r fa ilu r e of t h e pr im a r y lin k s be t w e e n Coch r a n a n d
Ea r h a r t , a ll a ddr e sse s a r e a cce ssible via t h e du a l con n e ct e d spok e
r ou t e r , Lin dbe r gh .
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 15: Neighbor 172.20.15.5 (Serial0/0.1) is down:
interface down
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 15: Neighbor 172.20.15.9 (Serial0/0.2) is down:
interface down
Cochran#show ip eigrp topology
IP-EIGRP Topology Table for AS(15)/ID(192.168.17.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.0.0.0/8, 1 successors, FD is 2707456
via 172.20.15.26 (2707456/2195456), Serial0/0.4
P 192.168.18.24/29, 1 successors, FD is 2195456
via 172.20.15.26 (2195456/281600), Serial0/0.4
P 192.168.16.0/24, 1 successors, FD is 2195456
via 172.20.15.26 (2195456/281600), Serial0/0.4
P 192.168.17.0/24, 1 successors, FD is 28160
via Connected, FastEthernet0/0
P 172.20.32.0/24, 1 successors, FD is 28160
via Connected, FastEthernet0/1
P 172.20.33.0/24, 1 successors, FD is 2707456
via 172.20.15.26 (2707456/2195456), Serial0/0.4
P 172.20.15.20/30, 1 successors, FD is 21536000
via 172.20.15.26 (21536000/21024000), Serial0/0.4
P 172.20.15.16/30, 1 successors, FD is 6535936
via 172.20.15.26 (6535936/6023936), Serial0/0.4
P 172.20.15.24/30, 1 successors, FD is 2169856
via Connected, Serial0/0.4
P 172.20.10.0/27, 1 successors, FD is 2707456
via 172.20.15.26 (2707456/2195456), Serial0/0.4
P 172.20.15.4/30, 1 successors, FD is 3193856
via 172.20.15.26 (3193856/2681856), Serial0/0.4
P 172.20.15.0/30, 1 successors, FD is 2681856
via 172.20.15.26 (2681856/2169856), Serial0/0.4
P 172.20.15.12/30, 1 successors, FD is 4035840
via 172.20.15.26 (4035840/3523840), Serial0/0.4
P 172.18.0.0/16, 1 successors, FD is 4038400
via 172.20.15.26 (4038400/3526400), Serial0/0.4
P 172.20.15.8/30, 1 successors, FD is 11535872
via 172.20.15.26 (11535872/11023872), Serial0/0.4
P 192.168.18.128/25, 1 successors, FD is 28160
via Connected, FastEthernet0/2
P 10.108.16.0/24, 1 successors, FD is 284160
via 172.20.32.2 (284160/281600), FastEthernet0/1
P 172.20.15.24/30, 1 successors, FD is 2169856
via Connected, Serial0/0.4
Cochran#
Now, Lindbergh is configured as an EI GRP st ub in Exam ple 7- 36.
Ex a m ple 7 - 3 6 . Lin dbe r gh is con figu r e d a s a n EI GRP st u b r ou t e r .
router eigrp 15
eigrp stub
Exam ple 7- 37 shows Cochran's EI GRP neighbor t able, and Exam ple 7- 38 shows Cochran's EI GRP
t opology t able aft er t he sam e t wo links t o Earhart fail again.
Ex a m ple 7 - 3 7 . Coch r a n 's EI GRP n e igh bor t a ble sh ow s it s n e igh bor s.
Lin dbe r gh is a st u b. Coch r a n is r u n n in g a la t e r I OS r e le a se ( 1 2 .3 ) t h e n
Ea r h a r t . N ot ice t h a t t h e fa ct t h a t qu e r ie s a r e su ppr e sse d is e x plicit ly
st a t e d.
Cochran#show ip eigrp neighbor detail
IP-EIGRP neighbors for process 15
H
Address
Interface
2
Hold Uptime
(sec)
10 00:01:08
172.20.15.26
Se0/0.4
Version 12.3/1.2, Retrans: 2, Retries: 0
Stub Peer Advertising ( CONNECTED SUMMARY ) Routes
Suppressing queries
1
172.20.15.9
Se0/0.2
11 00:29:46
Version 12.1/1.2, Retrans: 1, Retries: 0
0
172.20.15.5
Se0/0.1
10 00:37:00
Version 12.1/1.2, Retrans: 2, Retries: 0
IP-EIGRP neighbors for process 10
H
Address
Interface
Hold Uptime
(sec)
0
172.20.32.2
Fa0/1
13 00:29:50
Version 12.1/1.2, Retrans: 2, Retries: 0
Cochran#
SRTT
(ms)
56
RTO
336
Q
Cnt
0
Seq
Num
20
96
576
0
111
96
576
0
110
Q
Cnt
0
Seq
Num
10
SRTT
(ms)
51
RTO
306
Ex a m ple 7 - 3 8 . Aft e r fa ilu r e of t h e pr im a r y lin k s be t w e e n Coch r a n a n d
Ea r h a r t , on ly a ddr e sse s con n e ct e d t o Lin dbe r gh a r e r e a ch a ble via
Se r ia l 0 / 0 .4 .
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 15: Neighbor 172.20.15.5 (Serial0/0.1) is down:
interface down
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 15: Neighbor 172.20.15.9 (Serial0/0.2) is down:
interface down
Cochran#show ip eigrp topology
IP-EIGRP Topology Table for AS(15)/ID(192.168.17.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.18.24/29, 1 successors, FD is 2195456
via 172.20.15.26 (2195456/281600), Serial0/0.4
P 192.168.16.0/24, 1 successors, FD is 2195456
via 172.20.15.26 (2195456/281600), Serial0/0.4
P 192.168.17.0/24, 1 successors, FD is 28160
via Connected, FastEthernet0/0
P 172.20.32.0/24, 1 successors, FD is 28160
via Connected, FastEthernet0/1
P 172.20.15.24/30, 1 successors, FD is 2169856
via Connected, Serial0/0.4
P 172.20.15.0/30, 1 successors, FD is 2681856
via 172.20.15.26 (2681856/2169856), Serial0/0.4
P 192.168.18.128/25, 1 successors, FD is 28160
via Connected, FastEthernet0/2
P 10.108.16.0/24, 1 successors, FD is 284160
via 172.20.32.2 (284160/281600), FastEthernet0/1
P 172.20.15.24/30, 1 successors, FD is 2169856
via Connected, Serial0/0.4
Cochran#
Configuring Lindbergh as an EI GRP st ub prevent s it from becom ing a t ransit rout er during a
failure of core links.
Configuring st ub rout ing wit h EI GRP great ly increases t he scalabilit y of an EI GRP net work, by
m inim izing queries, and t hus t he am ount of t im e t hat net work out ages require addresses t o be
in an act ive st at e.
St ub rout ing elim inat es queries sent t o t he st ub rout er, but it does not hing t o hide t he t opology
of t he rest of t he net work from t he st ub's point of view. Earhart can hide t he t opology of t he rest
of t he net work from t he st ubs. They don't need t o know about every individual subnet because
all packet s for each of t he subnet s are always forwarded t o t he hub. Earhart can accom plish t his
by sum m arizing addresses.
Case Study: Address Summarization
Rout er Yeager, shown in t he net work in Figure 7- 37, has a single link t o Earhart . The six
addresses t hat Earhart m ust advert ise t o Yeager can be sum m arized wit h t wo aggregat e
addresses. Earhart 's configurat ion will be as shown in Exam ple 7- 39.
Ex a m ple 7 - 3 9 . Ea r h a r t 's con figu r a t ion su m m a r ize s r ou t e s t o Ye a ge r .
interface Ethernet2
ip address 10.15.15.254 255.255.255.252
ip summary-address eigrp 15 172.0.0.0 255.0.0.0
ip summary-address eigrp 15 192.168.16.0 255.255.240.0
The ip su m m a r y- a ddr e ss e igr p com m and will aut om at ically suppress t he advert isem ent of t he
m ore specific net works t o Yeager. Exam ple 7- 40 shows t he rout e t able of Yeager before and
aft er t he aggregat e addresses are configured. Even in t his sm all net work, t he num ber of EI GRPlearned ent ries has been reduced by half; in a large net work, t he im pact on rout e t ables and t he
m em ory required t o st ore t hem can be significant .
Ex a m ple 7 - 4 0 . Ye a ge r 's r ou t e t a ble be for e a n d a ft e r a ggr e ga t e
a ddr e sse s a r e con figu r e d a t Ea r h a r t .
Yeager#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, 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
D
C
C
D
D
D
D
172.18.0.0/16 [90/3040000] via 10.15.15.254, 00:13:07, Ethernet0
172.20.0.0/16 [90/307200] via 10.15.15.254, 00:13:07, Ethernet0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
10.10.1.0/24 is directly connected, Ethernet1
10.15.15.252/30 is directly connected, Ethernet0
192.168.17.0/27 is subnetted, 1 subnets
192.168.17.0 [90/2198016] via 10.15.15.254, 00:03:57, Ethernet0
192.168.16.0/24 [90/2221056] via 10.15.15.254, 00:01:51, Ethernet0
192.168.18.0/24 is variably subnetted, 2 subnets, 2 masks
192.168.18.24/29 [90/2221056] via 10.15.15.254, 00:13:09, Ethernet0
192.168.18.128/25 [90/2198016] via 10.15.15.254, 00:13:09, Ethernet0
Yeager#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, 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
C
C
D
D
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
10.10.1.0/24 is directly connected, Ethernet1
10.15.15.252/30 is directly connected, Ethernet0
172.0.0.0/8 [90/307200] via 10.15.15.254, 00:00:57, Ethernet0
192.168.16.0/20 [90/2198016] via 10.15.15.254, 00:00:57, Ethernet0
Authentication
MD5 crypt ographic checksum s are t he only aut hent icat ion support ed in EI GRP, which on first
considerat ion m ight seem less flexible t han RI Pv2 and OSPF, which support bot h MD5 and cleart ext passwords. However, clear- t ext password aut hent icat ion should be used only when a
neighboring device does not support t he m ore secure MD5. Because EI GRP will be spoken only
bet ween t wo Cisco devices, t his sit uat ion will never arise.
The st eps for configuring EI GRP aut hent icat ion are
St e p 1 .
Define a key chain wit h a nam e.
St e p 2 .
Define t he key or keys on t he key chain.
St e p 3 .
Enable aut hent icat ion on an int erface and specify t he key chain t o be
used.
St e p 4 .
Opt ionally configure key m anagem ent .
Key- chain configurat ion and m anagem ent are described in Chapt er 6. EI GRP aut hent icat ion is
enabled and linked t o a key chain on an int erface wit h t he com m ands ip a u t h e n t ica t ion k e ych a in e igr p and ip a u t h e n t ica t ion m ode e igr p m d5 .[ 17]
[17]
Although MD5 is the only authentication mode available, the ip authentication mode eigrp md5 command anticipates
the possibility of another mode being available in the future.
Referring t o Figure 7- 37, t he configurat ion in Exam ple 7- 41 enables EI GRP aut hent icat ion on
Cochran's int erface t o Earhart .
Ex a m ple 7 - 4 1 . Coch r a n is con figu r e d t o u se M D 5 a u t h e n t ica t ion w it h
Ea r h a r t .
key chain Edwards
key 1
key-string PanchoBarnes
!
interface Serial0/0.1
ip address 172.20.15.6 255.255.255.252
ip authentication key-chain eigrp 15 Edwards
ip authentication mode eigrp 15 md5
interface Serial0/0.2
ip address 172.20.15.10 255.255.255.252
ip authentication key-chain eigrp 15 Edwards
ip authentication mode eigrp 15 md5
A sim ilar configurat ion would be necessary on Earhart . The com m ands a cce pt - life t im e and
Troubleshooting EIGRP
Troubleshoot ing t he exchange of RI P rout e inform at ion is a reasonably sim ple procedure.
Rout ing updat es are eit her propagat ed or t hey are not , and t hey eit her cont ain accurat e
inform at ion or t hey do not . The added com plexit y of EI GRP m eans an added com plexit y t o t he
t roubleshoot ing procedure. Neighbor t ables and adj acencies m ust be verified, t he
query/ response procedure of DUAL m ust be followed, and t he influences of VLSM on aut om at ic
sum m arizat ion m ust be considered.
This sect ion's case st udy describes a sequence of event s t hat t ypically can be used when
pursuing an EI GRP problem . Following t he case st udy is a discussion of an occasional cause of
inst abilit ies in larger EI GRP int ernet s.
Case Study: A Missing Neighbor
Figure 7- 38 shows a sm all EI GRP net work. Users are com plaining t hat subnet
192.168.16.224/ 28 is unreachable. An exam inat ion of t he rout e t ables reveals t hat som et hing is
wrong at rout er Grissom ( Exam ple 7- 42) . [ 18]
[18]
When troubleshooting a network, it is a good practice to verify that the addresses of all router interfaces belong to the
correct subnet.
Figu r e 7 - 3 8 . Su bn e t 1 9 2 .1 6 8 .1 6 .2 2 4 / 2 8 is n ot r e a ch a ble t h r ou gh
Gr issom in t h is e x a m ple of a n EI GRP n e t w or k .
Ex a m ple 7 - 4 2 . Th e r ou t e t a ble s of Sh e pa r d a n d Gr issom sh ow t h a t
Gr issom 's EI GRP pr oce ss is n ot a dve r t isin g or r e ce ivin g r ou t e s on
su bn e t 1 9 2 .1 6 8 .1 6 .1 6 / 2 8 .
Grissom#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
192.168.16.0/24 is variably subnetted, 3 subnets, 2 masks
C
192.168.16.40/30 is directly connected, Serial0
C
192.168.16.16/28 is directly connected, Ethernet0
D
192.168.16.224/28 [90/2195456] via 192.168.16.42, 01:07:26, Serial0
_______________________________________________________________________________
Shepard#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
192.168.16.0/24 is variably subnetted, 4 subnets, 2 masks
C
192.168.16.36/30 is directly connected, Serial0
C
192.168.16.16/28 is directly connected, Ethernet0
D
192.168.16.192/28 [90/2297856] via 192.168.16.38, 01:07:20, Serial0
D
192.168.16.128/28 [90/307200] via 192.168.16.17, 01:07:20, Ethernet0
The following observat ions are m ade from t he t wo rout e t ables of Exam ple 7- 42:
Shepard does not have subnet s 192.168.16.40/ 30 and 192.168.16.224/ 28 in it s rout e
t able, alt hough Grissom does.
Grissom 's rout e t able does not cont ain any of t he subnet s t hat should be advert ised by
Glenn or Shepard.
Shepard's rout e t able cont ains t he subnet s advert ised by Glenn ( and Glenn's t able cont ains
t he subnet s advert ised by Shepard, alt hough it s rout e t able is not included in Exam ple 742 ) .
The conclusion t o be drawn from t hese observat ions is t hat Grissom is not advert ising or
receiving rout es correct ly over subnet 192.168.16.16/ 28.
Am ong t he possible causes, t he sim plest causes should be exam ined first . These follow:
An incorrect int erface address or m ask
An incorrect EI GRP process I D
A m issing or incorrect net work st at em ent
I n t his case, t here are no EI GRP or address configurat ion errors.
Next , t he neighbor t ables should be exam ined. Looking at t he neighbor t ables at Grissom ,
Shepard, and Glenn ( Exam ple 7- 43) , t wo fact s st and out :
Grissom ( 192.168.16.19) is in it s neighbors' t ables, but it s neighbors are not in Grissom 's
neighbor t able.
The ent ire net work has been up for m ore t han five hours; t his inform at ion is reflect ed in
t he upt im e st at ist ic for all neighbors except Grissom . However, Grissom 's upt im e shows
approxim at ely one m inut e.
Ex a m ple 7 - 4 3 . Sh e pa r d a n d Gle n n se e Gr issom a s a n e igh bor , bu t
Gr issom doe s n ot se e t h e m . Th is su gge st s t h a t Sh e pa r d a n d Gle n n a r e
r e ce ivin g H e llos fr om Gr issom , bu t Gr issom is n ot r e ce ivin g H e llos
fr om Sh e pa r d a n d Gle n n .
Grissom#show ip eigrp neighbors
IP-EIGRP neighbors for process 75
H
Address
Interface
Hold
Uptime
SRTT
RTO
Q
Seq
(sec)
(ms)
Cnt
Num
0
192.168.16.42
Se0
11
05:27:11
23
200
0
8
___________________________________________________________________________
Shepard#show ip eigrp neighbors
IP-EIGRP neighbors for process 75
H
Address
Interface
Hold
Uptime
SRTT
RTO
Q
Seq
(sec)
(ms)
Cnt
Num
1
192.168.16.19
Et0
12
00:01:01
0
5000
1
0
2
192.168.16.17
Et0
11
05:27:33
8
200
0
6
0
192.168.16.38
Se0
14
05:27:34
22
200
0
10
___________________________________________________________________________
Glenn#show ip eigrp neighbors
IP-EIGRP neighbors for process 75
H
Address
Interface
Hold
Uptime
SRTT
RTO
Q
Seq
(sec)
(ms)
Cnt
Num
1
192.168.16.19
Et0
14
00:00:59
0
8000
1
0
2
192.168.16.18
Et0
10
05:30:11
9
20
0
7
0
192.168.16.130
Et1
12
05:30:58
6
20
0
7
I f Grissom is in Shepard's neighbor t able, Shepard m ust be receiving Hellos from it . Grissom ,
however, is apparent ly not receiving Hellos from Shepard. Wit hout t his t wo- way exchange of
Hello packet s, an adj acency will not be est ablished and rout e inform at ion will not be exchanged.
A closer exam inat ion of Shepard's and Glenn's neighbor t ables reinforces t his hypot hesis:
The SRTT for Grissom is 0, indicat ing t hat a packet has never m ade t he round t rip.
The RTO for Grissom has increased t o five and eight seconds, respect ively.
There is a packet enqueued for Grissom ( Q Cnt ) .
The sequence num ber recorded for Grissom is 0, indicat ing t hat no reliable packet s have
ever been received from it .
These fact ors indicat e t hat t he t wo rout ers are t rying t o send a packet reliably t o Grissom , but
are not receiving an ACK.
I n Exam ple 7- 44, de bu g e igr p pa ck e t s is used at Shepard t o get a bet t er look at what is
happening. All EI GRP packet t ypes will be displayed, but a second debug com m and is used wit h
it : de bu g ip e igr p n e igh bor 7 5 1 9 2 .1 6 8 .1 6 .1 9 . This com m and adds a filt er t o t he first
com m and. I t t ells de bu g e igr p pa ck e t t o display only I P packet s of EI GRP 75 ( t he process I D
of t he rout ers in Figure 7- 38) and only t hose packet s t hat concern neighbor 192.168.16.19
( Grissom ) .
Ex a m ple 7 - 4 4 . Th e com m a n d de bu g ip e igr p n e igh bor is u se d t o
con t r ol t h e pa ck e t s displa ye d by de bu g e igr p pa ck e t s.
Shepard#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK)
Shepard#debug ip eigrp neighbor 75 192.168.16.19
IP Neighbor target enabled on AS 75 for 192.168.16.19
IP-EIGRP Neighbor Target Events debugging is on
EIGRP: Sending UPDATE on Ethernet0 nbr 192.168.16.19, retry 14, RTO 5000
AS 75, Flags 0x1, Seq 22/0 idbQ 1/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno
1-4
EIGRP: Received HELLO on Ethernet0 nbr 192.168.16.19
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
EIGRP: Sending UPDATE on Ethernet0 nbr 192.168.16.19, retry 15, RTO 5000
AS 75, Flags 0x1, Seq 22/0 idbQ 1/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno
1-4
EIGRP: Received HELLO on Ethernet0 nbr 192.168.16.19
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
EIGRP: Sending UPDATE on Ethernet0 nbr 192.168.16.19, retry 16, RTO 5000
AS 75, Flags 0x1, Seq 22/0 idbQ 1/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno
1-4
EIGRP: Received HELLO on Ethernet0 nbr 192.168.16.19
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
EIGRP: Retransmission retry limit exceeded
EIGRP: Received HELLO on Ethernet0 nbr 192.168.16.19
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0
EIGRP: Enqueueing UPDATE on Ethernet0 nbr 192.168.16.19 iidbQ un/rely 0/1 peerQ
un/rely 0/0 serno 1-4
EIGRP: Sending UPDATE on Ethernet0 nbr 192.168.16.19
AS 75, Flags 0x1, Seq 23/0 idbQ 1/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno
1-4
Exam ple 7- 44 shows t hat Hello packet s are being received from Grissom . I t also shows t hat
Shepard is at t em pt ing t o send updat es t o Grissom ; Grissom is not acknowledging t hem . Aft er
t he 16t h ret ry, t he m essage " Ret ransm ission ret ry lim it exceeded" is displayed. This exceeded
lim it account s for t he low upt im e shown for Grissom in t he neighbor t ableswhen t he
ret ransm ission ret ry lim it is exceeded, Grissom is rem oved from t he neighbor t able. But because
Hellos are st ill being received from Grissom , it quickly reappears in t he t able and t he process
begins again.
Exam ple 7- 45 shows t he out put from de bu g e igr p n e igh bor s at Shepard. This com m and is not
I P specific, but inst ead shows EI GRP neighbor event s. Here, t wo inst ances of t he event s
described in t he previous paragraph are displayed: Grissom is declared dead as t he
ret ransm ission lim it is exceeded but is im m ediat ely " revived" when it s next Hello is received.
Ex a m ple 7 - 4 5 . de bu g e igr p n e igh bor s displa ys n e igh bor e ve n t s.
Shepard#debug eigrp neighbors
EIGRP Neighbors debugging is on
Shepard#
EIGRP: Retransmission retry limit exceeded
EIGRP: Holdtime expired
EIGRP: Neighbor 192.168.16.19 went down on Ethernet0
EIGRP: New peer 192.168.16.19
EIGRP: Retransmission retry limit exceeded
EIGRP: Holdtime expired
EIGRP: Neighbor 192.168.16.19 went down on Ethernet0
EIGRP: New peer 192.168.16.19
Alt hough Exam ple 7- 44 shows t hat updat e packet s are being sent t o Grissom , observat ion of
EI GRP packet s at t hat rout er shows t hat t hey are not being received ( Exam ple 7- 46) .
Ex a m ple 7 - 4 6 . Gr issom is e x ch a n gin g H e llos w it h Coope r via in t e r fa ce
S0 a n d is se n din g H e llos ou t E0 . H ow e ve r , Gr issom is n ot r e ce ivin g a n y
EI GRP pa ck e t s on in t e r fa ce EO.
Grissom#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP,
Grissom#
EIGRP: Sending HELLO on Serial0
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
EIGRP: Received HELLO on Serial0 nbr 192.168.16.42
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
EIGRP: Sending HELLO on Ethernet0
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
EIGRP: Sending HELLO on Serial0
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
EIGRP: Received HELLO on Serial0 nbr 192.168.16.42
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
EIGRP: Sending HELLO on Ethernet0
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
EIGRP: Sending HELLO on Serial0
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
EIGRP: Sending HELLO on Ethernet0
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
EIGRP: Received HELLO on Serial0 nbr 192.168.16.42
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
EIGRP: Sending HELLO on Serial0
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
EIGRP: Sending HELLO on Ethernet0
AS 75, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
PROBE, ACK)
0/0
0/0 peerQ un/rely 0/0
0/0
0/0
0/0 peerQ un/rely 0/0
0/0
0/0
0/0
0/0 peerQ un/rely 0/0
0/0
0/0
Because Grissom is successfully exchanging Hellos wit h Cooper, Grissom 's EI GRP process m ust
be working. Suspicion t herefore falls on Grissom 's Et hernet int erface. An inspect ion of t he
configurat ion file shows t hat an access list is configured as an incom ing filt er on E0 in Exam ple
7- 47 .
Ex a m ple 7 - 4 7 . An in com in g a cce ss- list is de n yin g EI GRP pa ck e t s.
interface Ethernet0
ip address 192.168.16.19 255.255.255.240
ip access-group 150 in
!
!
access-list 150 permit tcp any any established
access-list 150 permit tcp any host 192.168.16.238 eq ftp
access-list 150 permit tcp host 192.168.16.201 any eq telnet
access-list 150 permit tcp any host 192.168.16.230 eq pop3
access-list 150 permit udp any any eq snmp
access-list 150 permit icmp any 192.168.16.224 0.0.0.15
When EI GRP packet s are received at Grissom 's E0 int erface, t hey are first filt ered t hrough access
list 150. They will not m at ch any ent ry on t he list and are t herefore being dropped. The problem
is resolved (Exam ple 7- 48) by adding t he following ent ry t o t he access list :
access-list 150 permit eigrp 192.168.16.16 0.0.0.15 any
Ex a m ple 7 - 4 8 . W h e n a n e n t r y is a dde d t o t h e a cce ss list t o pe r m it
EI GRP pa ck e t s, Gr issom 's n e igh bor a n d r ou t e t a ble s sh ow t h a t it n ow
h a s r ou t e s t o a ll su bn e t s.
Grissom#show ip eigrp neighbors
IP-EIGRP neighbors for process 75
H
Address
Interface
Hold Uptime
SRTT
(sec)
(ms)
10 00:06:20
4
14 00:06:24
15
10 06:22:56
22
RTO
Q
Cnt
0
0
0
Seq
Num
41
85
12
2
192.168.16.17
Et0
200
1
192.168.16.18
Et0
200
0
192.168.16.42
Se0
200
Grissom#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
192.168.16.0/24 is variably subnetted, 6 subnets, 2 masks
C
192.168.16.40/30 is directly connected, Serial0
D
192.168.16.36/30 [90/2195456] via 192.168.16.18, 00:06:27, Ethernet0
C
192.168.16.16/28 is directly connected, Ethernet0
D
192.168.16.224/28 [90/2195456] via 192.168.16.42, 00:06:12, Serial0
D
192.168.16.192/28 [90/2323456] via 192.168.16.18, 00:06:27, Ethernet0
D
192.168.16.128/28 [90/307200] via 192.168.16.17, 00:06:12, Ethernet0
Grissom#
Stuck-in-Active Neighbors
When a rout e goes act ive and queries are sent t o neighbors, t he rout e will rem ain act ive unt il a
reply is received for every query. But what happens if a neighbor is dead or ot herwise
incapacit at ed and cannot reply? The rout e would st ay perm anent ly act ive. The act ive t im er and
SI A- ret ransm it t im er are designed t o prevent t his sit uat ion. Bot h t he act ive t im er and t he SI Aret ransm it t im er are set when a query is sent . I f t he SI A- ret ransm it t im er is not support ed by
t he rout er's I OS ( I OS versions earlier t hen 12.2[ 4.1] ) , only t he act ive t im er is used. I f t he t im ers
expire before a reply t o t he query is received, t he rout e is declared st uck- in- act ive, t he neighbor
is presum ed dead, and it is flushed from t he neighbor t able. [ 19] The SI A rout e and any ot her
rout es via t hat neighbor are elim inat ed from t he rout e t able. DUAL will be sat isfied by
considering t he neighbor t o have replied wit h an infinit e m et ric.
[19]
As mentioned previously, the default active time is three minutes. It can be changed with the command timers activetime.
I n realit y, t his sequence of event s should never happen. The loss of Hellos should ident ify a
disabled neighbor long before t he act ive t im er expires.
But what happens in large EI GRP net works where a query m ight , like t he bunny in t he bat t ery
advert isem ent , keep going and going? Rem em ber t hat queries cause t he diffusing calculat ion t o
grow larger, whereas replies cause it t o grow sm aller ( refer t o Figure 7- 6 ) . Queries m ust
event ually reach t he edge of t he net work, and replies m ust event ually begin com ing back, but if
t he diam et er of t he diffusing calculat ion grows large enough, an act ive t im er m ight expire before
all replies are received. The result , flushing a legit im at e neighbor from t he neighbor t able, is
obviously dest abilizing.
When neighbors m yst eriously disappear from neighbor t ables and t hen reappear, or users
com plain of int erm it t ent ly unreachable dest inat ions, SI A rout es m ight be t he culprit . Checking
t he error logs of rout ers is a good way t o find out whet her SI As have occurred ( Exam ple 7- 49) .
Ex a m ple 7 - 4 9 . Th e fin a l e n t r y of t h is e r r or log sh ow s a SI A m e ssa ge .
Gagarin#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 3369 messages logged
Monitor logging: level debugging, 0 messages logged
Trap logging: level informational, 71 message lines logged
Buffer logging: level debugging, 3369 messages logged
Log Buffer (4096 bytes):
...
...
...
DUAL: dual_rcvupdate(): 10.51.1.0/24 via 10.1.2.1 metric 409600/128256
DUAL: Find FS for dest 10.51.1.0/24. FD is 4294967295, RD is 4294967295 found
DUAL: RT installed 10.51.1.0/24 via 10.1.2.1
DUAL: Send update about 10.51.1.0/24. Reason: metric chg
DUAL: Send update about 10.51.1.0/24. Reason: new if
DUAL: dual_rcvupdate(): 10.52.1.0/24 via 10.1.2.1 metric 409600/128256
DUAL: Find FS for dest 10.52.1.0/24. FD is 4294967295, RD is 4294967295 found
%DUAL-3-SIA: Route 10.11.1.0/24 stuck-in-active state in IP-EIGRP 1. Cleaning up
Gagarin#
When chasing t he cause of SI As, close at t ent ion should be paid t o t he t opology t able in rout ers.
I f rout es can be " caught " in t he act ive st at e, t he neighbors from whom queries have not yet
been received should be not ed. For exam ple, Exam ple 7- 50 shows a t opology t able in which
several rout es are act ive. Not ice t hat m ost of t hem have been act ive for 15 seconds and t hat
one ( 10.6.1.0) has been act ive for 41 seconds.
Ex a m ple 7 - 5 0 . Th is t opology t a ble sh ow s se ve r a l a ct ive r ou t e s, a ll of
w h ich a r e w a it in g for a r e ply fr om n e igh bor 1 0 .1 .2 .1 .
Gagarin#show ip eigrp topology
IP-EIGRP Topology Table for process 1
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply
r - Reply Status
A 10.11.1.0/24, 0 successors, FD is 3072128000, Q
1 replies, active 00:00:15, query-origin: Local origin
Remaining replies:
via 10.1.2.1, r, Ethernet0
A 10.10.1.0/24, 0 successors, FD is 3584128000, Q
1 replies, active 00:00:15, query-origin: Local origin
Remaining replies:
via 10.1.2.1, r, Ethernet0
A 10.9.1.0/24, 0 successors, FD is 4096128000, Q
1 replies, active 00:00:15, query-origin: Local origin
Remaining replies:
via 10.1.2.1, r, Ethernet0
A 10.2.1.0/24, 1 successors, FD is Inaccessible, Q
1 replies, active ve 00:00:15, query-origin: Local origin
Remaining res:
via 10.1.2.1, r, Ethernet0
P 10.1.2.0/24, 1 successors, FD is 281600
via Connected, Ethernet0
A 10.6.1.0/24, 0 successors, FD is 3385160704, Q
1 replies, active 00:00:41, query-origin: Local origin
Remaining replies:
via 10.1.2.1, r, Ethernet0
A 10.27.1.0/24, 0 successors, FD is 3897160704, Q
--More-
Not ice also t hat in each case, t he neighbor 10.1.2.1 has it s reply st at us flag ( r) set . That is t he
neighbor from which replies have not yet been received. There m ight be no problem wit h t he
neighbor it self or wit h t he link t o t he neighbor, but t his inform at ion point s t o t he direct ion wit hin
t he net work t opology in which t he invest igat ion should proceed.
Com m on causes of SI As in larger EI GRP net works are heavily congest ed, low- bandwidt h dat a
links and rout ers wit h low m em ory or overut ilized CPUs. The problem will be exacerbat ed if
t hese lim it ed resources m ust handle very large num bers of queries.
The careless adj ust m ent of t he bandwidt h param et er on int erfaces m ight be anot her cause of
SI As. Recall t hat EI GRP is designed t o use no m ore t han 50 percent of t he available bandwidt h
of a link. This rest rict ion m eans t hat EI GRP's pacing is keyed t o t he configured bandwidt h. I f t he
bandwidt h is set art ificially low in an at t em pt t o m anipulat e rout ing choices, t he EI GRP process
m ight be st arved. I f I OS 11.2 or lat er is being run, t he com m and ip ba n dw idt h - pe r ce n t e igr p
m ay be used t o adj ust t he percent age of bandwidt h used.
For exam ple, suppose t hat an int erface is connect ed t o a 56K serial link, but t he bandwidt h is set
t o 14K. EI GRP would lim it it self t o 50 percent of t his am ount , or 7K. The com m ands in Exam ple
7- 51 adj ust t he EI GRP bandwidt h percent t o 200 percent 200 percent of 14K, which is 50 percent
of t he act ual bandwidt h of t he 56K link.
Ex a m ple 7 - 5 1 . Rou t e r con figu r a t ion a dj u st s t h e pe r ce n t a ge of t h e
con figu r e d ba n dw idt h t h a t EI GRP w ill u se .
interface Serial 3
ip address 172.18.107.210 255.255.255.240
bandwidth 14
ip bandwidth-percent eigrp 1 200
I ncreasing t he act ive t im er period wit h t he t im e r s a ct ive - t im e com m and m ight help avoid SI As
in som e sit uat ions, but t his st ep should not be t aken wit hout careful considerat ion of t he effect s
it m ight have on reconvergence.
A new t im er, t he SI A- ret ransm it t im er, and t he t wo new EI GRP packet t ypes, SI A- query and
SI A- reply, help t o m inim ize SI As and t o push t he reset of t he neighbor t o link t hat is act ually
having t he problem responding t o queries.
Consider t he net work in Figure 7- 39. From rout er Mercury, EI GRP will rout e t raffic t o net work
172.16.100.0 via Apollo. Vost ok is not a feasible successor because t he m et ric from Vost ok t o
172.16.100.0 is t oo high. Vost ok rout es t raffic t o 172.16.100.0 via Mercury and Apollo. Soyuz is
not a feasible successor because t he m et ric from Soyuz t o 172.16.100.0 is t oo high.
Figu r e 7 - 3 9 . M e r cu r y doe s n ot list Vost ok a s a fe a sible su cce ssor t o
1 7 2 .1 6 .1 0 0 .0 / 2 4 .
When t he link bet ween Mercury and Apollo fails, as shown in Figure 7- 40, Mercury places t he
address 172.16.100.0 ( and any ot her address known via neighbor Apollo) int o Act ive, and sends
a query t o Vost ok. Vost ok also places t he address int o Act ive st at e, and sends a query t o Soyuz.
The Act ive t im ers are set . I n addit ion, t he SI A- ret ransm it t im ers are set . The SI A- ret ransm it
t im er is set t o one- half t he value of t he Act ive t im er, t ypically 90 seconds.
Figu r e 7 - 4 0 . SI A- qu e r ie s a n d SI A- r e plie s a r e u se d t o a void SI A
con dit ion s.
When t he SI A- ret ransm it t im er expires, Mercury sends an SI A- query t o Vost ok. Vost ok sends an
SI A- query t o Soyuz. Vost ok responds t o t he SI A- query from Mercury wit h an SI A- reply. Mercury
reset s t he Act ive t im er and t he SI A- ret ransm it t im er. The rout ers will send up t o t hree SI Aqueries ( assum ing no reply has been received from t he original address query) as long as SI Areplies are received, before reset t ing a neighbor. So as long as a neighbor rout er responds t o
t he SI A- queries, it won't be declared st uck- in- act ive and reset , for six m inut es, assum ing a
default Act ive t im e of 180 seconds. This gives am ple t im e for a large net work t o respond t o
quer ies.
But , say t here is a problem on t he link from Vost ok t o Soyuz t hat is allowing enough Hellos t o
get t hrough t o keep t he neighbors act ive, but t he SI A- reply is not received by Vost ok wit hin t he
SI A- ret ransm it t im e. I f no SI A- reply is received wit hin 90 seconds of a SI A- query, and no
response t o t he original address query has been received, Vost ok will reset neighbor Soyuz and
reply t o Mercury's original query t hat t he address is unreachable.
The SI A- ret ransm it t im er does t wo t hings. I f neighbors are responding t o SI A- queries, large
net works are given m ore t im e t o respond t o address queries. I f neighbors are not responding,
t he neighbor is reset . Only t he rout er t hat is not receiving responses from it s neighbor will reset
t he adj acency. Before t he SI A- ret ransm it t im er was int roduced, any rout er t hat did not receive a
response t o an act ive query aft er t he Act ive t im er expired would reset t he neighbor adj acency,
even if t he problem was som ewhere downst ream in t he net work.
A good net work design is t he best solut ion t o inst abilit ies such as SI A rout es. By using a
com binat ion of int elligent address assignm ent , rout e filt ering, default rout es, st ub rout ing, and
sum m arizat ion, boundaries m ay be const ruct ed in a large EI GRP net work t o rest rict t he size and
scope of diffusing com put at ions. Chapt er 13 includes an exam ple of such a design.
Looking Ahead
When com paring EI GRP and OSPF, it is oft en said t hat an advant age of EI GRP is t hat it is sim pler
t o configure. This observat ion is t rue for m any net works, but t his chapt er's discussion of
t roubleshoot ing shows t hat as a net work grows, effort s m ust be m ade t o " com part m ent alize" t he
EI GRP t opology. I ronically, t he very com plexit y of OSPF m ight m ake it easier t o configure in
large net works, as t he next chapt er shows.
Summary Table: Chapter 7 Command Review
Com m a n d
D e scr ipt ion
a cce pt - life t im e st ar t - t im e Specifies t he t im e period during which t he aut hent icat ion key on a
{ in fin it e | end- t im e |
key chain is received as valid.
du r a t ion seconds}
a u t o- su m m a r y
Enables aut om at ic sum m arizat ion at net work boundaries. This
com m and is enabled by default .
ba n dw idt h kilobit s
Specifies t he bandwidt h param et er, in kilobit s per second, on an
int erface.
de bu g e igr p pa ck e t s
Displays EI GRP packet act ivit y.
de bu g ip e igr p n e igh bor
process- id address
Adds a filt er t o t he de bu g e igr p pa ck e t s com m and, t elling it t o
display only I P packet s for t he indicat ed process and neighbor.
de la y t ens- ofm icroseconds
Specifies t he delay param et er, in t ens of m icroseconds, on an
int erface.
e igr p st u b { con n e ct e d |
r e dist r ibu t e d | st a t ic |
su m m a r y | r e ce ive - on ly}
Configures a spoke rout er as an EI GRP st ub.
ip a u t h e n t ica t ion k e ych a in e igr p pr ocess- id
key- chain
Configures a key chain on an EI GRP int erface and specifies t he
nam e of t he key chain t o be used.
ip a u t h e n t ica t ion m ode
e igr p pr ocess- id m d5
Enables EI GRP aut hent icat ion on an int erface.
ip ba n dw idt h - pe r ce n t
e igr p process- id percent
Configures t he percent age of bandwidt h used by EI GRP; t he
default is 50 percent .
ip h e llo- in t e r va l e igr p
process- id seconds
Configures t he EI GRP hello int erval.
ip h old- t im e e igr p
process- id seconds
Configures t he EI GRP hold t im e.
ip su m m a r y- a ddr e ss
e igr p process- id address
m ask
Configures a rout er t o send a sum m ary EI GRP advert isem ent .
k e y num ber
Specifies a key on a key chain.
k e y ch a in nam e- of- chain
Specifies a group of aut hent icat ion keys.
k e y- st r in g t ext
Specifies t he aut hent icat ion st ring, or password, used by a key.
m e t r ic w e igh t s t os k1 k2
k3 k4 k5
Specifies how m uch weight t he bandwidt h, load, delay, reliabilit y,
and MTU size param et ers should be given in t he I GRP and EI GRP
m et ric calculat ions.
Com m a n d
D e scr ipt ion
n e t w or k net w ork- num ber
Specifies t he net work address of one or m ore int erfaces on which
I GRP, EI GRP, or RI P processes should be enabled.
pa ssive - in t e r fa ce t ype
num ber
Disables t he t ransm ission of broadcast or m ult icast rout ing
updat es on an int erface.
r ou t e r e igr p pr ocess- id
Enables an EI GRP process.
se n d- life t im e st ar t - t im e
{ in fin it e | end- t im e |
du r a t ion seconds}
Specifies t he t im e period during which t he aut hent icat ion key on a
key chain m ay be sent .
sh ow ip e igr p n e igh bor s
[ t ype num ber ]
Displays t he EI GRP neighbor t able.
sh ow ip e igr p t opology
[ pr ocess- id | [ [ ip address]
m ask] ]
Displays t he EI GRP t opology t able.
t im e r s a ct ive - t im e
{ m inut es | disa ble d}
Changes or disables t he default 3- m inut e act ive t im e.
t r a ffic- sh a r e { ba la n ce d
| m in }
Specifies whet her an I GRP or EI GRP rout ing process should use
unequal- cost load balancing or equal- cost load balancing only.
va r ia n ce m ult iplier
Specifies a rout e m ult iplier by which a rout e m et ric can vary from
t he lowest - cost m et ric and st ill be included in an unequal- cost
load balancing group.
Review Questions
1
I s EI GRP a dist ance vect or or a link- st at e rout ing prot ocol?
2
What is t he m axim um configured bandwidt h EI GRP will use on a link? Can t his
percent age be changed?
3
How do EI GRP and I GRP differ in t he way t hey calculat e t he com posit e m et ric?
4
What are t he four basic com ponent s of EI GRP?
5
I n t he cont ext of EI GRP, what does t he t erm reliable delivery m ean? Which t wo
m et hods ensure reliable delivery of EI GRP packet s?
6
Which m echanism ensures t hat a rout er is accept ing t he m ost recent rout e ent ry?
7
What is t he m ult icast I P address used by EI GRP?
8
What are t he packet t ypes used by EI GRP?
9
At what int erval, by default , are EI GRP Hello packet s sent ?
10
What is t he default hold t im e?
11
What is t he difference bet ween t he neighbor t able and t he t opology t able?
12
What is a feasible dist ance?
13
What is t he feasibilit y condit ion?
14
What is a feasible successor?
15
What is a successor?
16
What is t he difference bet ween an act ive rout e and a passive rout e?
17
What causes a passive rout e t o becom e act ive?
18
What causes an act ive rout e t o becom e passive?
19
What does st uck- in- act ive m ean?
20
What is t he difference bet ween subnet t ing and address aggregat ion?
Configuration Exercises
1
Writ e EI GRP configurat ions for Rout ers A, B, and C in Figure 7- 41. Use process I D 5.
Figu r e 7 - 4 1 . N e t w or k for Con figu r a t ion Ex e r cise s 1 a n d 2 .
2
The serial int erfaces connect ing Rout ers A and B in Figure 7- 41 are bot h S0.
Configure aut hent icat ion bet ween t hese t wo rout ers, using t he first key t wo days
from t oday's dat e. Configure a second key t o be used beginning 30 days aft er t he
first key.
Figu r e 7 - 4 2 . N e t w or k for Con figu r a t ion Ex e r cise 3 .
3
Rout er D is added in Figure 7- 42. Add t his rout er t o t he configurat ions writ t en in
Configurat ion Exercise 2.
4
Rout er F has been added in Figure 7- 43. Configure t his rout er t o run EI GRP wit h t he
rout ers configured in Configurat ion Exercises 2 and 3.
Figu r e 7 - 4 3 . N e t w or k for Con figu r a t ion Ex e r cise s 4 a n d 5 .
[View full size image]
5
Configure rout e sum m arizat ion wherever possible in t he net work of Figure 7- 43.
Troubleshooting Exercises
1
Table 7- 7 shows t he values displayed in t he sh ow in t e r fa ce com m and for every
int erface in Figure 7- 44. Which rout er will rout er F use as t he successor t o subnet A?
Ta ble 7 - 7 . M e t r ic va lu e s for
a ll in t e r fa ce s in Figu r e 7 - 4 4 ,
a s displa ye d in t h e sh ow
in t e r fa ce com m a n d.
Rou t e r I n t e r fa ce BW ( k )
D LY( m S)
A
1000
B
C
D
E
F
G
E0
10000
F0
100000 100
T0
16000
630
S0
512
20000
S1
1544
20000
TO
16000
630
S0
1544
20000
E0
10000
1000
S0
1544
20000
E0
10000
1000
F0
100000 100
S0
1544
20000
E0
10000
1000
S0
1544
20000
F0
100000 100
S0
512
20000
E0
10000
1000
E1
10000
1000
F0
100000 100
S0
56
20000
Figu r e 7 - 4 4 . N e t w or k for Tr ou ble sh oot in g Ex e r cise s 1
t h r ou gh 5 .
[View full size image]
2
I n Figure 7- 44, what is rout er C's feasible dist ance t o subnet A?
3
I n Figure 7- 44, what is rout er G's feasible dist ance t o subnet A?
4
I n Figure 7- 44, which rout ers will rout er G show in it s t opology t able as feasible
successors?
Chapter 8. OSPFv2
This chapt er covers t he following subj ect s:
Operat ion of OSPF
Configuring OSPF
Troubleshoot ing OSPF
Open Short est Pat h First ( OSPF) was developed by t he I nt ernet Engineering Task Force ( I ETF) as
a replacem ent for t he problem at ic RI P and is now t he I ETF- recom m ended I nt erior Gat eway
Prot ocol ( I GP) . OSPF is a link- st at e prot ocol t hat , as t he nam e im plies, uses Dij kst ra's Short est
Pat h First ( SPF) algorit hm and t hat is opent hat is, it isn't propriet ary t o any vendor or
organizat ion. OSPF has evolved t hrough several RFCs, all of which were writ t en by John Moy.
Version 1 of t he prot ocol was specified in RFC 1131; t his version never progressed beyond t he
experim ent al st age. Version 2, which is st ill t he current version for I Pv4, was first specified in
RFC 1247, and t he m ost recent specificat ion is RFC 2328.
Like all link- st at e prot ocols, OSPF's m aj or advant ages over dist ance vect or prot ocols are fast
reconvergence, scalabilit y t o m uch larger net works, and less suscept ibilit y t o bad rout ing
inform at ion. Ot her feat ures of OSPF are
The use of areas, which reduces t he prot ocol's im pact on CPU and m em ory, cont ains t he
flow of rout ing prot ocol t raffic, and m akes possible t he const ruct ion of hierarchical net work
t opologies
Fully classless behavior, elim inat ing such classful problem s as discont iguous subnet s
Support of classless rout e t able lookups, VLSM, and supernet t ing for efficient address
m anagem ent
A dim ensionless, arbit rary m et ric
Equal- cost load balancing for m ore efficient use of m ult iple pat hs [ 1]
[1]
More accurately, the RFC calls for equal-cost multipath, the discovery and use of multiple equal-cost paths,
without prescribing how the protocol should route individual packets across these multiple paths. The Cisco OSPF
implementation performs equal-cost load balancing as described in previous chapters.
The use of reserved m ult icast addresses t o reduce t he im pact on non- OSPFspeaking
dev ices
Support of aut hent icat ion for m ore secure rout ing
The use of rout e t agging for t he t racking of ext ernal rout es
OSPF also has t he capabilit y of support ing Type of Service ( TOS) rout ing, alt hough it was never
widely im plem ent ed. RFC 2328 has delet ed t he TOS rout ing opt ion for t his reason.
Operation of OSPF[2]
[2]
Because of the interrelationship of OSPF terms and concepts, this chapter frequently uses terms before they are fully
defined. The reader is advised to read this section more than once to ensure a complete understanding of OSPF operation.
It will also be useful to review the section "Link State Routing Protocols" in Chapter 4, "Dynamic Routing Protocols."
At a very high level, t he operat ion of OSPF is easily explained:
1 . OSPF- speaking rout ers send Hello packet s out all OSPF- enabled int erfaces. I f t wo rout ers
sharing a com m on dat a link agree on cert ain param et ers specified in t heir respect ive Hello
packet s, t hey will becom e neighbors.
2 . Adj acencies, which can be t hought of as virt ual point - t o- point links, are form ed bet ween
som e neighbors. OSPF defines several net work t ypes and several rout er t ypes. The
est ablishm ent of an adj acency is det erm ined by t he t ypes of rout ers exchanging Hellos and
t he t ype of net work over which t he Hellos are exchanged.
3 . Each rout er sends link- st at e advert isem ent s ( LSAs) over all adj acencies. The LSAs describe
all of t he rout er's links, or int erfaces, t he rout er's neighbors, and t he st at e of t he links.
These links m ight be t o st ub net works ( net works wit h no ot her rout er at t ached) , t o ot her
OSPF rout ers, t o net works in ot her areas, or t o ext ernal net works ( net works learned from
anot her rout ing process) . Because of t he varying t ypes of link- st at e inform at ion, OSPF
defines m ult iple LSA t ypes.
4 . Each rout er receiving an LSA from a neighbor records t he LSA in it s link- st at e dat abase and
sends a copy of t he LSA t o all of it s ot her neighbors.
5 . By flooding LSAs t hroughout an area, all rout ers will build ident ical link- st at e dat abases.
6 . When t he dat abases are com plet e, each rout er uses t he SPF algorit hm t o calculat e a loopfree graph describing t he short est ( lowest cost ) pat h t o every known dest inat ion, wit h it self
as t he root . This graph is t he SPF t ree.
7 . Each rout er builds it s rout e t able from it s SPF t ree. [ 3]
[ 3]
This fundam ent al procedure of calculat ing rout es from t he link- st at e dat abase, rat her t han by
exchanging rout es wit h neighbors, has repercussions for rout e filt ering. See Chapt er 13 , " Rout e
Filt ering," for m ore inform at ion.
When all link- st at e inform at ion has been flooded t o all rout ers in an area and neighbors have
verified t hat t heir dat abases are ident icalt hat is, t he link- st at e dat abases have been
synchronizedand t he rout e t ables have been built , OSPF is a quiet prot ocol. Hello packet s are
exchanged bet ween neighbors as keepalives, and LSAs are ret ransm it t ed every 30 m inut es. I f
t he net work t opology is st able, no ot her act ivit y should occur.
Neighbors and Adjacencies
Before any LSAs can be sent , OSPF rout ers m ust discover t heir neighbors and est ablish
adj acencies. The neighbors will be recorded in a neighbor t able, along wit h t he link ( int erface)
on which each neighbor is locat ed and which cont ains ot her inform at ion necessary for t he
m aint enance of t he neighbor ( Exam ple 8- 1) .
Ex a m ple 8 - 1 . Th e n e igh bor t a ble r e cor ds a ll OSPF- spe a k in g n e igh bor s.
Monet#show ip ospf neighbor
Neighbor ID
Pri
State
192.168.30.70
1
FULL/DR
192.168.30.254
1
FULL/DR
192.168.30.70
1
FULL/BDR
192.168.30.30
1
FULL/ 192.168.30.10
1
FULL/ 192.168.30.68
1
FULL/ 192.168.30.18
1
FULL/ 192.168.30.78
1
FULL/ -
Dead Time
00:00:34
00:00:34
00:00:34
00:00:33
00:00:32
00:00:39
00:00:30
00:00:36
Address
192.168.17.73
192.168.32.2
192.168.32.4
192.168.17.50
192.168.17.9
192.168.21.134
192.168.21.142
192.168.21.170
Interface
Ethernet0
Ethernet1
Ethernet1
Serial0.23
Serial1
Serial2.824
Serial2.826
Serial2.836
The t racking of ot her OSPF rout ers requires t hat each rout er have a Rout er I D, an I P address by
which t he rout er is uniquely ident ified wit hin t he OSPF dom ain. Cisco rout ers derive t heir Rout er
I Ds by t he following m eans:
1 . I f t he Rout er I D has been m anually configured using t he r ou t e r - id com m and, t hat Rout er
I D is used.
2 . I f no Rout er I D has been m anually configured, t he rout er chooses t he num erically highest
I P address on any of it s loopback int erfaces.
3 . I f no loopback int erfaces are configured wit h I P addresses, t he rout er chooses t he
num erically highest I P address on any of it s physical int erfaces. The int erface from which
t he Rout er I D is t aken does not have t o be running OSPF.
Using addresses associat ed wit h loopback int erfaces has t wo advant ages:
The loopback int erface is m ore st able t han any physical int erface. I t is act ive when t he
rout er boot s up, and it only fails if t he ent ire rout er fails.
The net work adm inist rat or has m ore leeway in assigning predict able or recognizable
addresses as t he Rout er I Ds.
The Cisco OSPF will cont inue t o use a Rout er I D learned from a physical int erface even if t he
int erface subsequent ly fails or is delet ed ( see " Case St udy: Set t ing Rout er I Ds wit h Loopback
I nt erfaces," lat er in t his chapt er) . Therefore, t he st abilit y of a loopback int erface is only a m inor
advant age. The prim ary benefit is t he abilit y t o cont rol t he Rout er I D.
The OSPF rout er begins a neighbor relat ionship by advert ising it s Rout er I D in Hello packet s.
Hello Protocol
The Hello prot ocol serves several purposes:
I t is t he m eans by which neighbors are discovered.
I t advert ises several param et ers on which t wo rout ers m ust agree before t hey can becom e
neighbors.
Hello packet s act as keepalives bet ween neighbors.
I t ensures bidirect ional com m unicat ion bet ween neighbors.
I t elect s Designat ed Rout ers ( DRs) and Backup Designat ed Rout ers ( BDRs) on Broadcast
and Nonbroadcast Mult iaccess ( NBMA) net works.
OSPF- speaking rout ers periodically send a Hello packet out each OSPF- enabled int erface. This
period is known as t he HelloI nt erval and is configured on a per int erface basis. Cisco uses a
default HelloI nt erval of 10 seconds for broadcast net works and 30 seconds for non- broadcast ;
t he value can be changed wit h t he com m and ip ospf h e llo- in t e r va l. I f a rout er has not heard a
Hello from a neighbor wit hin a period of t im e known as t he Rout erDeadI nt erval, it will declare
t he neighbor down. The Cisco default Rout erDeadI nt erval is four t im es t he HelloI nt erval and can
be changed wit h t he com m and ip ospf de a d- in t e r va l. [ 4]
[4]
RFC 2328 does not set a required value for either the HelloInterval or the RouterDeadInterval, although it does suggest
respective values of 10 seconds and 4X HelloInterval.
Each Hello packet cont ains t he following inform at ion:
Rout er I D of t he originat ing rout er.
Area I D of t he originat ing rout er int erface.
Address m ask of t he originat ing int erface.
Aut hent icat ion t ype and aut hent icat ion inform at ion for t he originat ing int erface.
HelloI nt erval of t he originat ing int erface.
Rout erDeadI nt erval of t he originat ing int erface.
Rout er Priorit y.
DR and BDR.
Five flag bit s signifying opt ional capabilit ies.
Rout er I Ds of t he originat ing rout er's neighbors. This list cont ains only rout ers from which
Hellos were heard on t he originat ing int erface wit hin t he last Rout erDeadI nt erval.
This sect ion overviews t he m eaning and use of m ost of t he inform at ion list ed. Subsequent
sect ions discuss t he DR, BDR, and Rout er Priorit y, and illust rat e t he precise form at of t he Hello
packet . When a rout er receives a Hello from a neighbor, it will verify t hat t he Area I D,
Aut hent icat ion, Net work Mask, HelloI nt erval, Rout erDeadI nt erval, and Opt ions values m at ch t he
values configured on t he receiving int erface. I f t hey do not , t he packet is dropped and no
adj acency is est ablished.
I f everyt hing m at ches, t he Hello packet is declared valid. I f t he I D of t he originat ing rout er is
already list ed in t he neighbor t able for t hat receiving int erface, t he Rout erDeadI nt erval t im er is
reset . I f t he Rout er I D is not list ed, it is added t o t he neighbor t able.
Whenever a rout er sends a Hello, it includes in t he packet t he Rout er I Ds of all neighbors list ed
for t he link on which t he packet is t o be t ransm it t ed. I f a rout er receives a valid Hello in which it
finds it s own Rout er I D list ed, t he rout er knows t hat t wo- way com m unicat ion has been
est ablished.
Aft er t wo- way com m unicat ion has been est ablished, adj acencies m ay be est ablished. However,
as m ent ioned earlier, not all neighbors will becom e adj acent . Whet her an adj acency is form ed or
not depends on t he t ype of net work t o which t he t wo neighbors are at t ached. Net work t ypes also
influence t he way in which OSPF packet s are t ransm it t ed; t herefore, before discussing
adj acencies, it is necessary t o discuss net work t ypes.
Network Types
OSPF defines five net work t ypes:
Point - t o- point net works
Broadcast net works
Nonbroadcast Mult iaccess ( NBMA) net works
Point - t o- m ult ipoint net works
Virt ual links
Point - t o- point net works, such as a T1, DS- 3, or SONET link, connect a single pair of rout ers.
Valid neighbors on point - t o- point net works will always becom e adj acent . The dest inat ion address
of OSPF packet s on t hese net works will always be t he reserved class D address 224.0.0.5,
known as AllSPFRout ers. [ 5]
[5]
The exception to this rule is retransmitted LSAs, which are always unicast on all network types. This exception is covered
later, in the section "Reliable Flooding: Acknowledgments."
Broadcast net works, such as Et hernet , Token Ring, and FDDI , m ight be bet t er defined as
broadcast m ult i- access net works t o dist inguish t hem from NBMA net works. Broadcast net works
are m ult i- access in t hat t hey are capable of connect ing m ore t han t wo devices, and t hey are
broadcast in t hat all at t ached devices can receive a single t ransm it t ed packet . OSPF rout ers on
broadcast net works will elect a DR and a BDR, as described in t he next sect ion, " Designat ed
Rout ers and Backup Designat ed Rout ers." Hello packet s are m ult icast wit h t he AllSPFRout ers
dest inat ion address 224.0.0.5, as are all OSPF packet s originat ed by t he DR and BDR. The
dest inat ion Media Access Cont rol ( MAC) ident ifier of t he fram es carrying t hese packet s is
0100.5E00.0005. All ot her rout ers will m ult icast link- st at e updat e and link- st at e
acknowledgm ent packet s ( described lat er) t o t he reserved class D address 224.0.0.6, known as
AllDRout er s. The dest inat ion MAC ident ifier of t he fram es carrying t hese packet s is
0100.5E00.0006.
NBMA net works, such as X.25, Fram e Relay, and ATM, are capable of connect ing m ore t han t wo
rout ers but have no broadcast capabilit y. A packet sent by one of t he at t ached rout ers would not
be received by all ot her at t ached rout ers. As a result , ext ra configurat ion m ight be necessary for
rout ers on t hese net works t o acquire t heir neighbors. OSPF rout ers on NBMA net works elect a
DR and BDR, and all OSPF packet s are unicast .
Point - t o- m ult ipoint net works are a special configurat ion of NBMA net works in which t he net works
are t reat ed as a collect ion of point - t o- point links. Rout ers on t hese net works do not elect a DR
and BDR, and t he OSPF packet s are unicast t o each known neighbor.
Virt ual links, described in a lat er sect ion, are special configurat ions t hat are int erpret ed by t he
rout er as unnum bered point - t o- point net works. OSPF packet s are unicast over virt ual links.
I n addit ion t o t hese five net work t ypes, it should be not ed t hat all net works fall int o one of t wo
m ore- general t ypes:
Tr a n sit net works have t wo or m ore at t ached rout ers. They m ight carry packet s t hat are
" j ust passing t hrough" packet s t hat were originat ed on and are dest ined for a net work ot her
t han t he t ransit net work.
St u b net works have only a single at t ached rout er. [ 6] Packet s on a st ub net work always
have eit her a source or a dest inat ion address belonging t o t hat net work. That is, all packet s
were eit her originat ed by a device on t he net work or are dest ined for a device on t he
net work. OSPF advert ises host rout es ( rout es wit h a m ask of 255.255.255.255) as st ub
net works. Loopback int erfaces are also considered st ub net works and are advert ised as
host rout es. [ 7]
[6]
Do not confuse stub networks with stub areas, discussed later in the chapter.
[7]
Beginning with IOS 11.3, this default behavior can be changed by adding the command ip ospf network point-topoint to the loopback interface. This will cause the loopback interface's address to be advertised as a subnet route.
Designated Routers and Backup Designated Routers
Mult iaccess net works present t wo problem s for OSPF, relat ing t o t he flooding of LSAs ( described
in a lat er sect ion) :
The form at ion of an adj acency bet ween every at t ached rout er would creat e m any
unnecessary LSAs. I f n is t he num ber of rout ers on a m ult iaccess net work, t here would be
n( n 1) / 2 adj acencies ( Figure 8- 1 ) . Each rout er would flood n 1 LSAs for it s adj acent
neighbors, plus one LSA for t he net work, result ing in n 2 LSAs originat ing from t he net work.
Figu r e 8 - 1 . Te n a dj a ce n cie s w ou ld be r e qu ir e d for e a ch of t h e five
r ou t e r s on t h is OSPF n e t w or k t o be com e fu lly a dj a ce n t w it h a ll of
it s n e igh bor s; 2 5 LSAs w ou ld be or igin a t e d fr om t h e n e t w or k .
Flooding on t he net work it self would be chaot ic and excessive. A rout er would flood an LSA
t o all it s adj acent neighbors, which in t urn would flood it t o all t heir adj acent neighbors,
creat ing m any copies of t he sam e LSA on t he sam e net work.
To prevent t hese problem s, a DR is elect ed on m ult i- access net works. The DR has t he following
dut ies:
To represent t he m ult i- access net work and it s at t ached rout ers t o t he rest of t he OSPF area
To m anage t he flooding process on t he m ult i- access net work
The concept behind t he DR is t hat t he broadcast link it self is considered a " pseudonode," or a
virt ual rout er. When t he SPF t ree is calculat ed, t he link appears as a node and t he rout ers
at t ached t o t he link are at t ached t o t hat node. The cost from an at t ached rout er t o t he
pseudonode is t he out going cost of t hat rout er's int erface t o t he broadcast link, but t he cost
from t he pseudonode t o any at t ached rout er is 0. This way, t he overall pat h cost is not affect ed
by t he pseudonode.
Each rout er on t he net work form s an adj acency wit h t he DR ( Figure 8- 2 ) , which represent s t he
pseudonode wit h a special Net work LSA. Keep in m ind t hat a rout er m ight be a DR on one of it s
at t ached m ult i- access net works, and it m ight not be t he DR on anot her of it s at t ached m ult iaccess net works. I n ot her words, t he DR is a propert y of a rout er's int erface, not t he ent ire
rout er.
Figu r e 8 - 2 . Th e D R r e pr e se n t s t h e m u lt i- a cce ss n e t w or k . Ot h e r r ou t e r s
on t h e n e t w or k w ill for m a dj a ce n cie s w it h t h e D R, n ot w it h e a ch ot h e r .
A significant problem wit h t he DR schem e as described so far is t hat if t he DR fails, a new DR
m ust be elect ed. New adj acencies m ust be est ablished, and all rout ers on t he net work m ust
synchronize t heir dat abases wit h t he new DR ( part of t he adj acency- building process) . While all
t his is happening, t he net work is unavailable for t ransit packet s.
To prevent t his problem , a BDR is elect ed in addit ion t o t he DR. All rout ers form adj acencies not
only wit h t he DR but also wit h t he BDR. The DR and BDR also becom e adj acent wit h each ot her.
I f t he DR fails, t he BDR becom es t he new DR. Because t he ot her rout ers on t he net work are
already adj acent wit h t he BDR, net work unavailabilit y is m inim ized.
The elect ion of t he DR and BDR is t riggered by t he int erface st at e m achine, which is described in
a lat er sect ion. For t he elect ion process t o funct ion properly, t he following precondit ions m ust
exist :
Each m ult i- access int erface of each rout er has a Rout er Priorit y, which is an 8- bit unsigned
int eger ranging from 0 t o 255. The default priorit y on Cisco rout ers is 1 and can be
changed on a per m ult i- access- int erface basis wit h t he com m and ip ospf pr ior it y . Rout ers
wit h a priorit y of 0 are ineligible t o becom e t he DR or BDR.
Hello packet s include fields for t he originat ing rout er t o specify it s Rout er Priorit y and for
t he I P addresses of t he connect ed int erfaces of t he rout ers it considers t he DR and BDR.
When an int erface first becom es act ive on a m ult i- access net work, it set s t he DR and BDR
t o 0.0.0.0. I t also set s a wait t im er wit h a value equal t o t he Rout erDeadI nt erval.
Exist ing int erfaces on a m ult i- access net work record t he addresses of t he DR and t he BDR
in t he int erface dat a st ruct ure, described in a lat er sect ion.
The elect ion procedure of t he DR and BDR is as follows:
1 . Aft er t wo- way com m unicat ion has been est ablished wit h one or m ore neighbors, exam ine
t he Priorit y, DR, and BDR fields of each neighbor's Hello. List all rout ers eligible for elect ion
( t hat is, rout ers wit h priorit y great er t han 0 and whose neighbor st at e is at least t wo- way) ;
all rout ers declaring t hem selves t o be t he DR ( t heir own int erface address is in t he DR field
of t he Hello packet ) ; and all rout ers declaring t hem selves t o be t he BDR ( t heir own int erface
address is in t he BDR field of t he Hello packet ) . The calculat ing rout er will include it self on
t his list unless it is ineligible.
2 . From t he list of eligible rout ers, creat e a subset of all rout ers not claim ing t o be t he DR
( rout ers declaring t hem selves t o be t he DR cannot be elect ed BDR) .
3 . I f one or m ore neighbors in t his subset include it s own int erface address in t he BDR field,
t he neighbor wit h t he highest priorit y will be declared t he BDR. I n a t ie, t he neighbor wit h
t he highest Rout er I D will be chosen.
4 . I f no rout er in t he subset claim s t o be t he BDR, t he neighbor wit h t he highest priorit y will
becom e t he BDR. I n a t ie, t he neighbor wit h t he highest Rout er I D will be chosen.
5 . I f one or m ore of t he eligible rout ers include t heir own address in t he DR field, t he neighbor
wit h t he highest priorit y will be declared t he DR. I n a t ie, t he neighbor wit h t he highest
Rout er I D will be chosen.
6 . I f no rout er has declared it self t he DR, t he newly elect ed BDR will becom e t he DR.
7 . I f t he rout er perform ing t he calculat ion is t he newly elect ed DR or BDR, or if it is no longer
t he DR or BDR, repeat st eps 2 t hrough 6.
I n sim pler language, when an OSPF rout er becom es act ive and discovers it s neighbors, it checks
for an act ive DR and BDR. I f a DR and BDR exist , t he rout er accept s t hem . I f t here is no BDR, an
elect ion is held in which t he rout er wit h t he highest priorit y becom es t he BDR. I f m ore t han one
rout er has t he sam e priorit y, t he one wit h t he num erically highest Rout er I D wins. I f t here is no
act ive DR, t he BDR is prom ot ed t o DR and a new elect ion is held for t he BDR.
I t should be not ed t hat t he priorit y can influence an elect ion, but will not override an act ive DR
or BDR. That is, if a rout er wit h a higher priorit y becom es act ive aft er a DR and BDR have been
elect ed, t he new rout er will not replace eit her of t hem . So t he first t wo DR- eligible rout ers t o
init ialize on a m ult iaccess net work will becom e t he DR and BDR.
Aft er t he DR and BDR have been elect ed, t he ot her rout ers ( known as DRot hers) will est ablish
adj acencies wit h t he DR and BDR only. All rout ers cont inue t o m ult icast Hellos t o t he
AllSPFRout ers address 224.0.0.5 so t hat t hey can t rack neighbors, but DRot hers m ult icast
updat e packet s t o t he AllDRout ers address 224.0.0.6. Only t he DR and BDR will list en t o t his
address; in t urn, t he DR will flood t he updat es t o t he DRot hers on 224.0.0.5.
Not e t hat if only one eligible rout er is at t ached t o a m ult iaccess net work, t hat rout er will becom e
t he DR and t here will be no BDR. Any ot her rout ers will form adj acencies only wit h t he DR. I f
none of t he rout ers at t ached t o a m ult i- access net work are eligible, t here will be no DR or BDR
and no adj acencies will form . The neighbor st at es of all rout ers will rem ain t wo- way ( explained
lat er, in "Neighbor St at e Machine" ) .
The dut ies perform ed by t he DR and BDR are described m ore fully in subsequent sect ions.
OSPF Interfaces
The essence of a link- st at e prot ocol is t hat it is concerned wit h links and t he st at e of t hose links.
Before Hellos can be sent , before adj acencies can be form ed, and before LSAs can be sent , an
OSPF rout er m ust underst and it s own links. A rout er's int erfaces are t he m eans by which OSPF
int erpret s links. As a result , when speaking of OSPF, it is not uncom m on t o hear t he t erm s
int erface and link used synonym ously. This sect ion exam ines t he dat a st ruct ure OSPF associat es
wit h each int erface and t he various st at es of an OSPF int erface.
Interface Data Structure
An OSPF rout er m aint ains a dat a st ruct ure for each OSPF- enabled int erface. I n Exam ple 8- 2, t he
com m and sh ow ip ospf in t e r fa ce has been used t o observe t he com ponent s of an int erface
dat a st ruct ure.[ 8]
[8]
Depending on the version of IOS you are running, the output of this command might show more information than is
discussed here; but this information is essential to every OSPF interface.
Ex a m ple 8 - 2 . Th e OSPF- spe cific da t a r e la t e d t o a n in t e r fa ce ca n be
obse r ve d w it h t h e com m a n d sh ow ip ospf in t e r fa ce. I n t h is e x a m ple ,
t h e in t e r fa ce is a t t a ch e d t o a poin t - t o- poin t n e t w or k t ype .
Renoir#show ip ospf interface Serial1.738
Serial1.738 is up, line protocol is up
Internet Address 192.168.21.21/30, Area 7
Process ID 1, Router ID 192.168.30.70, Network Type POINT_TO_POINT, Cost: 781
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:07
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 192.168.30.77
Message digest authentication enabled
Youngest key id is 10
The com ponent s of t he int erface dat a st ruct ure are as follows:
I P Addr e ss a n d M a sk This com ponent is t he configured address and m ask of t he
int erface. OSPF packet s originat ed from t his int erface will have t his source address. I n
Exam ple 8- 2, t he address/ m ask pair is 192.168.21.21/ 30.
Ar e a I D The area t o which t he int erface, and t he net work t o which it is at t ached, belong.
OSPF packet s originat ed from t his int erface will have t his Area I D. I n Exam ple 8- 2, t he area
I D is 7.
Pr oce ss I D This Cisco- specific feat ure is not part of t he open st andard. Cisco rout ers are
capable of running m ult iple OSPF processes and use t he Process I D t o dist inguish t hem .
The Process I D has no significance out side t he rout er on which it is configured. I n Exam ple
8 - 2, t he Process I D is 1.
Rou t e r I D I n Exam ple 8- 2, t he Rout er I D is 192.168.30.70.
N e t w or k Type The t ype of net work t o which t he int erface is connect ed: broadcast , point t o- point , NBMA, point - t o- m ult ipoint , or virt ual link. I n Exam ple 8- 2, t he net work t ype is
point - t o- point . [ 9]
[9]
Depending on the version of IOS you are running, the output of this command might show more information than
is discussed here; but this information is essential to every OSPF interface.
Cost The out going cost for packet s t ransm it t ed from t his int erface. Cost is t he OSPF
m et ric, expressed as an unsigned 16- bit int eger in t he range of 1 t o 65535. Cisco uses a
default cost of 10 8 / BW, expressed in whole num bers, where BW is t he configured
bandwidt h of t he int erface and 10 8 is t he reference bandwidt h. The int erface in Exam ple 82 has a configured bandwidt h of 128K ( not shown in t he exam ple) , so t he cost is 10 8 / 128K
= 781.
The cost can be changed wit h t he com m and ip ospf cost . This com m and is especially im port ant
when configuring Cisco rout ers in a m ult ivendor environm ent . Anot her vendor, for exam ple,
m ight use a default cost of 1 on all int erfaces ( essent ially m aking OSPF cost reflect hop count s) .
I f all rout ers do not assign cost s in t he sam e m anner, OSPF can rout e im properly, subopt im ally,
or in som e ot her unexpect ed way.
The reference bandwidt h of 10 8 creat es a problem for som e m odern m edia wit h bandwidt hs
higher t han 100M ( such as OC- 3 or above and Gigabit Et hernet ) . 10 8 / 100M = 1, m eaning t hat
higher bandwidt hs calculat e t o a fract ion of 1, which is not allowed. So any cost t hat is
calculat ed t o a fract ion of 1 is rounded up t o 1. However, t his m eans t hat if your net work
consist s of high- bandwidt h links, all int erfaces wind up wit h a cost of 1 and t he calculat ed
short est pat hs becom e based on least rout er hops. To rem edy t his, Cisco provides t he com m and
a u t o- cost r e fe r e n ce - ba n dw idt h, which allows t he default reference bandwidt h t o be changed.
Ot her com ponent s of t he int erface dat a st ruct ure are as follows:
I n fTr a n sD e la y The seconds by which LSAs exit ing t he int erface will have t heir ages
increm ent ed. I n Exam ple 8- 2, t his is displayed as Transm it Delay and is shown t o be t he
Cisco default , 1 second. I nfTransDelay can be changed wit h t he com m and ip ospf
t r a n sm it - de la y .
St a t e The funct ional st at e of t he int erface, which is described in t he following sect ion,
" I nt erface St at e Machine."
Rou t e r Pr ior it y This 8- bit unsigned int eger in t he range of 0 t o 255 elect s t he DR and
BDR. The priorit y is not displayed in Exam ple 8- 2 because t he net work t ype is point - t opoint ; no DR or BDR is elect ed on t his net work t ype. Exam ple 8- 3 shows anot her OSPF
int erface in t he sam e rout er. This int erface shows an at t ached net work t ype of broadcast ,
so a DR and BDR are elect ed. The priorit y shown is 1, t he Cisco default . The com m and ip
ospf pr ior it y is used t o change t he Rout er Priorit y.
Ex a m ple 8 - 3 . Th is in t e r fa ce is a t t a ch e d t o a br oa dca st n e t w or k t ype ,
a n d t h e r ou t e r is t h e D R on t h is n e t w or k .
Renoir#show ip ospf interface Ethernet0
Ethernet0 is up, line protocol is up
Internet Address 192.168.17.73/29, Area 0
Process ID 1, Router ID 192.168.30.70, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 192.168.30.70, Interface address 192.168.17.73
Backup Designated router (ID) 192.168.30.80, Interface address 192.168.17.74
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:03
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 192.168.30.80 (Backup Designated Router)
Message digest authentication enabled
Youngest key id is 10
D e sign a t e d Rou t e r The DR for t he net work t o which t he int erface is at t ached is recorded
bot h by it s Rout er I D and by t he address of t he int erface at t ached t o t he shared net work.
Not e t hat no DR is displayed in Exam ple 8- 2; it will be displayed only for m ult i- access
net work t ypes. I n Exam ple 8- 3, t he DR is 192.168.30.70. The address of it s at t ached
int erface is 192.168.17.73. A look at t he Rout er I D, t he int erface address, and t he int erface
st at e shows t hat Renoir is t he DR.
Ba ck u p D e sign a t e d Rou t e r The BDR for t he net work t o which t he int erface is at t ached is
also recorded bot h by it s Rout er I D and by t he address of t he at t ached int erface. I n
Exam ple 8- 3, t he BDR is 192.168.30.80, and it s int erface address is 192.168.17.74.
H e lloI n t e r v a l The period, in seconds, bet ween t ransm issions of Hello packet s on t he
int erface. This period is advert ised in Hello packet s t hat are t ransm it t ed from t he int erface.
Cisco uses a default of 10 seconds on broadcast net works and 30 seconds on nonbroadcast net works, which can be changed wit h t he com m and ip ospf h e llo- in t e r va l.
Exam ple 8- 3 displays HelloI nt erval as Hello and shows t hat t he default is being used.
Rou t e r D e a dI n t e r va l The period, in seconds, t hat t he rout er will wait t o hear a Hello from
a neighbor on t he net work t o which t he int erface is connect ed before declaring t he
neighbor down. The Rout erDeadI nt erval is advert ised in Hello packet s t ransm it t ed from t he
int erface. Cisco uses a default of four t im es t he HelloI nt erval; t he default can be changed
wit h t he com m and ip ospf de a d- in t e r va l. Exam ple 8- 3 displays t he Rout erDeadI nt erval
as Dead and shows t hat t he default is being used.
W a it Tim e r The lengt h of t im e t he rout er will wait for a DR and BDR t o be advert ised in a
neighbor's Hello packet before beginning a DR and BDR select ion. The period of t he wait
t im er is t he Rout erDeadI nt erval. I n Exam ple 8- 2, t he wait t im e is irrelevant because t he
int erface is at t ached t o a point - t o- point net work; no DR or BDR will be used.
Rx m t I n t e r va l The period, in seconds, t he rout er will wait bet ween ret ransm issions of
OSPF packet s t hat have not been acknowledged. Exam ple 8- 3 displays t his period as
ret ransm it and shows t hat t he Cisco default of five seconds is being used. An int erface's
Rxm t I nt erval can be changed wit h t he com m and ip ospf r e t r a n sm it - in t e r va l.
H e llo Tim e r A t im er t hat is set t o t he HelloI nt erval. When it expires, a Hello packet is
t ransm it t ed from t he int erface. Exam ple 8- 3 shows t hat t he Hello t im er will expire in t hree
seconds.
N e igh bor in g Rou t e r s A list of all valid neighbors ( neighbors whose Hellos have been seen
wit hin t he past Rout erDeadI nt erval) on t he at t ached net work. Exam ple 8- 4 shows yet
anot her int erface on t he sam e rout er. Here, five neighbors are known on t he net work, but
only t wo are adj acent ( t he Rout er I Ds of only t he adj acent neighbors are displayed) . As a
DRot her on t his net work, t he rout er has est ablished an adj acency only wit h t he DR and t he
BDR, in keeping wit h t he DR prot ocol.
Ex a m ple 8 - 4 . On t h is n e t w or k , t h e r ou t e r se e s five n e igh bor s bu t h a s
on ly for m e d a dj a ce n cie s w it h t h e D R a n d t h e BD R.
Renoir#show ip ospf interface Ethernet1
Ethernet1 is up, line protocol is up
Internet Address 192.168.32.4/24, Area 78
Process ID 1, Router ID 192.168.30.70, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DROTHER, Priority 1
Designated Router (ID) 192.168.30.254, Interface address 192.168.32.2
Backup Designated router (ID) 192.168.30.80, Interface address 192.168.32.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:01
Neighbor Count is 5, Adjacent neighbor count is 2
Adjacent with neighbor 192.168.30.80 (Backup Designated Router)
Adjacent with neighbor 192.168.30.254 (Designated Router)
Message digest authentication enabled
Youngest key id is 10
Au Ty p e Describes t he t ype of aut hent icat ion used on t he net work. The aut hent icat ion t ype
m ay be Null ( no aut hent icat ion) , Sim ple Password, or Crypt ographic ( Message Digest ) .
Exam ple 8- 4 shows t hat Message Digest aut hent icat ion is being used. I f Null aut hent icat ion
is used, no aut hent icat ion t ype or key inform at ion will be displayed when sh ow ip ospf
in t e r fa ce is invoked.
Au t h e n t ica t ion Ke y A 64- bit password if sim ple aut hent icat ion has been enabled for t he
int erface or a m essage digest key if Crypt ographic aut hent icat ion is used. Exam ple 8- 4
shows t hat t he " youngest key I D" is 10. This alludes t o t he fact t hat Crypt ographic
aut hent icat ion allows t he configurat ion of m ult iple keys on an int erface t o ensure sm oot h
and secure key changes.
Exam ple 8- 5 shows an int erface t hat is connect ed t o an NBMA net work. Not ice t hat t he
HelloI nt erval is 30 seconds, t he default for NBMA, and t hat t he Rout erDeadI nt erval is at t he
default of four t im es t he HelloI nt erval.
Ex a m ple 8 - 5 . Th is in t e r fa ce is a t t a ch e d t o a N BM A Fr a m e Re la y
n e t w or k a n d is t h e BD R for t h is n e t w or k .
Renoir#show ip ospf interface Serial3
Serial3 is up, line protocol is up
Internet Address 192.168.16.41/30, Area 0
Process ID 1, Router ID 192.168.30.105, Network Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 192.168.30.210, Interface address 192.168.16.42
Backup Designated router (ID) 192.168.30.105, Interface address 192.168.16.41
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
Hello due in 00:00:08
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 192.168.30.210 (Designated Router)
I t is wort hwhile t o spend som e t im e com paring Exam ple 8- 2 t hrough Exam ple 8- 5. All four
int erfaces are on t he sam e rout er, yet on each net work t he rout er perform s a different role. I n
each case, t he int erface st at e dict at es t he role of t he OSPF rout er on a net work. The next sect ion
describes t he various int erface st at es and t he int erface st at e m achine.
Interface State Machine
An OSPF- enabled int erface will t ransit ion t hrough several st at es before it becom es fully
funct ional. Those st at es are Down, Point - t o- Point , Wait ing, DR, Backup, DRot her, and Loopback.
D ow n This is t he init ial int erface st at e. The int erface is not funct ional, all int erface
param et ers are set t o t heir init ial values, and no prot ocol t raffic is t ransm it t ed or received
on t he int erface.
Poin t - t o- Poin t This st at e is applicable only t o int erfaces connect ed t o point - t o- point ,
point - t o- m ult ipoint , and virt ual link net work t ypes. When an int erface t ransit ions t o t his
st at e, it is fully funct ional. I t will begin sending Hello packet s every HelloI nt erval and will
at t em pt t o est ablish an adj acency wit h t he neighbor at t he ot her end of t he link.
W a it in g This st at e is applicable only t o int erfaces connect ed t o broadcast and NBMA
net work t ypes. When an int erface t ransit ions t o t his st at e, it will begin sending and
receiving Hello packet s and will set t he wait t im er. The rout er will at t em pt t o ident ify t he
net work's DR and BDR while in t his st at e.
D R I n t his st at e, t he rout er is t he DR on t he at t ached net work and will est ablish
adj acencies wit h t he ot her rout ers on t he m ult i- access net work.
Ba ck u p I n t his st at e, t he rout er is t he BDR on t he at t ached net work, and will est ablish
adj acencies wit h t he ot her rout ers on t he m ult i- access net work.
D Rot h e r I n t his st at e, t he rout er is neit her t he DR nor t he BDR on t he at t ached net work. I t
will form adj acencies only wit h t he DR and BDR, alt hough it will t rack all neighbors on t he
net work.
Loopba ck I n t his st at e, t he int erface is looped back via soft ware or hardware. Alt hough
packet s cannot t ransit an int erface in t his st at e, t he int erface address is st ill advert ised in
Rout er LSAs ( described lat er) so t hat t est packet s can find t heir way t o t he int erface.
Figure 8- 3 shows t he OSPF int erface st at es and t he input event s t hat will cause a st at e
t ransit ion. The input event s are described in Table 8- 1.
Figu r e 8 - 3 . Th e OSPF in t e r fa ce st a t e m a ch in e ; se e Ta ble 8 - 1 for a
de scr ipt ion of in pu t e ve n t s ( I Es) .
[View full size image]
Ta ble 8 - 1 . I n pu t e ve n t s for t h e in t e r fa ce st a t e m a ch in e .
I n pu t Eve n t
D e scr ipt ion
I E1
Lower- level prot ocols indicat e t hat t he net work int erface is operat ional.
I E2
Lower- level prot ocols indicat e t hat t he net work int erface is not operat ional.
I E3
Net work m anagem ent or lower- level prot ocols indicat e t hat t he int erface is
looped up.
I E4
Net work m anagem ent or lower- level prot ocols indicat e t hat t he int erface is
looped down.
I E5
A Hello packet is received in which eit her t he originat ing neighbor list s it self
as t he BDR or t he originat ing neighbor list s it self as t he DR and indicat es no
BDR.
I E6
The wait t im er has expired.
I E7
The rout er is elect ed as t he DR for t his net work.
I E8
The rout er is elect ed as t he BDR for t his net work.
I E9
The rout er has not been elect ed as t he DR or BDR for t his net work.
I E10
A change has occurred in t he set of valid neighbors on t his net work. This
change m ay be one of t he following:
1 . The est ablishm ent of t wo- way com m unicat ion wit h a neighbor
2 . The loss of t wo- way com m unicat ion wit h a neighbor
3 . The receipt of a Hello in which t he originat ing neighbor newly list s
it self as t he DR or BDR
4.
I n pu t Eve n t
D e scr ipt ion
4 . The receipt of a Hello from t he DR in which t hat rout er is no longer
list ed as t he DR
5 . The receipt of a Hello from t he BDR in which t hat rout er is no longer
list ed as t he BDR
6 . The expirat ion of t he Rout erDeadI nt erval wit hout having received a
Hello from t he DR or t he BDR or bot h
OSPF Neighbors
The preceding sect ion discussed a rout er's relat ionship wit h t he at t ached dat a link. Alt hough a
rout er's int eract ion wit h ot her rout ers was discussed in t he cont ext of elect ing DRs and BDRs,
t he purpose of t he DR elect ion process is st ill t o est ablish a relat ionship wit h a link. This sect ion
discusses a rout er's relat ionship wit h t he neighbors on t he net work. The ult im at e purpose of t he
neighbor relat ionship is t he form at ion of adj acencies over which t o pass rout ing inform at ion.
An adj acency is est ablished in four general phases:
1 . Neighbor discovery.
2 . Bidirect ional com m unicat ion. This com m unicat ion is accom plished when t wo neighbors list
each ot her's Rout er I Ds in t heir Hello packet s.
3 . Dat abase synchronizat ion. Dat abase Descript ion, Link St at e Request , Link St at e Updat e,
and Link St at e Acknowledgem ent packet s ( described in a lat er sect ion) are exchanged t o
ensure t hat bot h neighbors have ident ical inform at ion in t heir link- st at e dat abases. For t he
purposes of t his process, one neighbor will becom e t he m ast er and t he ot her will becom e
t he slave. As t he nam e im plies, t he m ast er will cont rol t he exchange of Dat abase
Descript ion packet s.
4 . Full adj acency.
As previously discussed, neighbor relat ionships are est ablished and m aint ained t hrough t he
exchange of Hello packet s. On broadcast and point - t o- point net work t ypes, Hellos are m ult icast
t o AllSPFRout ers ( 224.0.0.5) . On NBMA, point - t o- m ult ipoint , and virt ual link net work t ypes,
Hellos are unicast t o individual neighbors. The im plicat ion of unicast ing is t hat t he rout er m ust
first learn of t he exist ence of it s neighbors eit her t hrough m anual configurat ion or an underlying
m echanism such as I nverse ARP. The configurat ion of neighbors on t hese net work t ypes is
covered in t he appropriat e sect ions.
Hellos are sent every HelloI nt erval on every net work t ype, wit h one except ion: On NBMA
net works, a rout er will send Hellos t o neighbors whose neighbor st at e is down every PollI nt erval.
On Cisco rout ers, t he default PollI nt erval is 120 seconds.
Neighbor Data Structure
An OSPF rout er builds t he Hello packet s for each net work using t he inform at ion st ored in t he
int erface dat a st ruct ure of t he at t ached int erface. By sending t he Hello packet s cont aining t his
inform at ion, t he rout er inform s neighbors about it self. Likewise, for each neighbor t he rout er will
m aint ain a neighbor dat a st ruct ure consist ing of t he inform at ion learned from ot her rout ers'
Hello packet s.
I n Exam ple 8- 6, t he com m and sh ow ip ospf n e igh bor is used t o observe som e of t he
inform at ion in t he neighbor dat a st ruct ure for a single neighbor. [ 10]
[10]
Compare this usage with Example 8-1.
Ex a m ple 8 - 6 . An OSPF r ou t e r de scr ibe s e a ch con ve r sa t ion w it h e a ch
n e igh bor by a n e igh bor da t a st r u ct u r e .
Seurat#show ip ospf neighbor 10.7.0.1
Neighbor 10.7.0.1, interface address 10.8.1.2
In the area 0 via interface Ethernet0/0
Neighbor priority is 1, State is FULL, 6 state changes
DR is 10.8.1.1 BDR is 10.8.1.2
Options is 0x52
LLS Options is 0x1 (LR)
Dead timer due in 00:00:30
Neighbor is up for 09:55:04
Index 1/3, retransmission queue length 0, number of retransmission 1
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 1, maximum is 1
Last retransmission scan time is 0 msec, maximum is 0 msec
Act ually, t he dat a st ruct ure records m ore inform at ion about each neighbor t han is shown in t he
exam ple. [ 11] The com ponent s of t he neighbor dat a st ruct ure are as follows:
[11]
And as with show ip ospf interface, you might see somewhat different information than what is shown in Example 8-6
depending on what version of IOS you are running.
N e igh bor I D The rout er I D of t he neighbor. I n Exam ple 8- 6, t he neighbor I D is 10.7.0.1.
N e igh bor I P Addr e ss The I P address of t he neighbor's int erface at t ached t o t he net work.
When OSPF packet s are unicast ed t o t he neighbor, t his address will be t he dest inat ion
address. I n Exam ple 8- 6, t he neighbor's I P address is 10.8.1.2.
Ar e a I D For t wo rout ers t o becom e neighbors, t he Area I D carried in a received Hello
packet m ust m at ch t he Area I D of t he receiving int erface. The Area I D of t he neighbor in
Exam ple 8- 6 is 0 ( 0.0.0.0) .
I n t e r fa ce The int erface at t ached t o t he net work on which t he neighbor is locat ed. I n
Exam ple 8- 6, t he neighbor is reached via Et hernet 0/ 0.
N e igh bor Pr ior it y This com ponent is t he Rout er Priorit y of t he neighbor, as advert ised in
t he neighbor's Hello packet s. The priorit y is used in t he DR/ BDR elect ion process. The
neighbor in Exam ple 8- 6 has a priorit y of 1, t he Cisco default .
St a t e This com ponent is t he rout er's view of t he funct ional st at e of t he neighbor, as
described in t he following sect ion, " Neighbor St at e Machine." The st at e of t he neighbor in
Exam ple 8- 6 is Full.
D e sign a t e d Rou t e r This address is included in t he DR field of t he neighbor's Hello
packet s. The DR in Exam ple 8- 6 is 10.8.1.1.
Ba ck u p D e sign a t e d Rou t e r This address is included in t he BDR field of t he neighbor's
Hello packet s. The BDR in Exam ple 8- 6 is 10.8.1.2.
PollI n t e r v a l This value is recorded only for neighbors on NBMA net works. Because
neighbors m ight not be aut om at ically discovered on NBMA net works, if t he neighbor st at e
is Down, a Hello will be sent t o t he neighbor every PollI nt ervalsom e period longer t han t he
HelloI nt erval. The neighbor in Exam ple 8- 6 is on an NBMA net work, as indicat ed by t he
default Cisco PollI nt erval of 120 seconds.
N e igh bor Opt ion s The opt ional OSPF capabilit ies support ed by t he neighbor. Opt ions are
discussed in t he sect ion describing t he Hello packet form at . The value of t he Opt ions field
in Exam ple 8- 6 is 0x52.
I n a ct ivit y Tim e r A t im er whose period is t he Rout erDeadI nt erval, as defined in t he
int erface dat a st ruct ure. The t im er is reset whenever a Hello is received from t he neighbor.
I f t he inact ivit y t im er expires before a Hello is heard from t he neighbor, t he neighbor is
declared Down. I n Exam ple 8- 6, t he inact ivit y t im er is shown as t he Dead Tim er and will
expire in 30 seconds.
Com ponent s of t he neighbor dat a st ruct ure t hat are not displayed by t he sh ow ip ospf
n e igh bor com m and are as follows:
M a st e r / Sla ve The m ast er/ slave relat ionship, negot iat ed wit h neighbors in t he ExSt art
st at e, est ablishes which neighbor will cont rol t he dat abase synchronizat ion.
D D Se qu e n ce N u m be r The Sequence Num ber of t he Dat abase Descript ion ( DD) packet
current ly being sent t o t he neighbor.
La st Re ce ive d D a t a ba se D e scr ipt ion Pa ck e t The I nit ialize, More, and Mast er bit s; t he
opt ions; and t he sequence num ber of t he last received Dat abase Descript ion packet are
recorded. This inform at ion is used t o det erm ine whet her t he next DD packet is a duplicat e.
Lin k St a t e Re t r a n sm ission List This com ponent is a list of LSAs t hat have been flooded
on t he adj acency, but have not yet been acknowledged. The LSAs are ret ransm it t ed every
Rxm t I nt erval, as defined in t he int erface dat a st ruct ure, unt il t hey are acknowledged or
unt il t he adj acency is dest royed. While t he display in Exam ple 8- 6 does not show t he LS
Ret ransm ission List , it does show t he num ber of LSAs current ly on t he list ( " ret ransm ission
queue lengt h" ) , which is 0.
D a t a ba se Su m m a r y List This com ponent is t he list of LSAs sent t o t he neighbor in
Dat abase Descript ion packet s during dat abase synchronizat ion. These LSAs m ake up t he
link- st at e dat abase when t he rout er goes int o exchange st at e.
Lin k St a t e Re qu e st List This list records LSAs from t he neighbor's Dat abase Descript ion
packet s t hat are m ore recent t han t he LSAs in t he link- st at e dat abase. Link St at e Request
packet s are sent t o t he neighbor for copies of t hese LSAs; as t he request ed LSAs are
received in Link St at e Updat e packet s, t he Request List is deplet ed.
Neighbor State Machine
An OSPF rout er t ransit ions a neighbor ( as described in t he neighbor dat a st ruct ure) t hrough
several st at es before t he neighbor is considered fully adj acent :
D ow n The init ial st at e of a neighbor conversat ion indicat es t hat no Hellos have been heard
from t he neighbor in t he last Rout erDeadI nt erval. Hellos are not sent t o down neighbors
unless t hose neighbors are on NBMA net works; in t his case, Hellos are sent every
PollI nt erval. I f a neighbor t ransit ions t o t he Down st at e from som e higher st at e, t he link
st at e Ret ransm ission, Dat abase Sum m ary, and Link St at e Request list s are cleared.
At t e m pt This st at e applies only t o neighbors on NBMA net works, where neighbors are
m anually configured. A DR- eligible rout er t ransit ions a neighbor t o t he At t em pt st at e when
t he int erface t o t he neighbor first becom es Act ive or when t he rout er is t he DR or BDR. A
rout er sends packet s t o a neighbor in At t em pt st at e at t he HelloI nt erval inst ead of t he
PollI nt erval.
I n it This st at e indicat es t hat a Hello packet has been seen from t he neighbor in t he last
Rout erDeadI nt erval, but t wo- way com m unicat ion has not yet been est ablished. A rout er
includes t he Rout er I Ds of all neighbors in t his st at e or higher in t he Neighbor field of t he
Hello packet s.
2 - W a y This st at e indicat es t hat t he rout er has seen it s own Rout er I D in t he Neighbor field
of t he neighbor's Hello packet s, which m eans t hat a bidirect ional conversat ion has been
est ablished. On m ult i- access net works, neighbors m ust be in t his st at e or higher t o be
eligible t o be elect ed as t he DR or BDR. The recept ion of a Dat abase Descript ion packet
from a neighbor in t he init st at e also causes a t ransit ion t o 2- Way.
Ex St a r t I n t his st at e, t he rout er and it s neighbor est ablish a m ast er/ slave relat ionship and
det erm ine t he init ial DD sequence num ber in preparat ion for t he exchange of Dat abase
Descript ion packet s. The neighbor wit h t he highest Rout er I D becom es t he m ast er.
Ex ch a n ge The rout er sends Dat abase Descript ion packet s describing it s ent ire link- st at e
dat abase t o neighbors t hat are in t he Exchange st at e. The rout er m ay also send Link St at e
Request packet s, request ing m ore recent LSAs, t o neighbors in t his st at e.
Loa din g The rout er sends Link St at e Request packet s t o neighbors t hat are in t he Loading
st at e, request ing m ore recent LSAs t hat have been discovered in t he Exchange st at e but
have not yet been received.
Fu ll Neighbors in t his st at e are fully adj acent , and t he adj acencies appear in Rout er LSAs
and Net work LSAs.
Figure 8- 4 t hrough Figure 8- 6 show t he OSPF neighbor st at es and t he input event s t hat cause a
st at e t ransit ion. The input event s are described in Table 8- 2, and t he decision point s are defined
in Table 8- 3. Figure 8- 4 shows t he norm al progression from t he least funct ional st at e t o t he fully
funct ional st at e, and Figure 8- 5 and Figure 8- 6 show t he com plet e OSPF neighbor st at e m achine.
Figu r e 8 - 4 . Th e n or m a l se r ie s of t r a n sit ion s in t h e OSPF n e igh bor st a t e
m a ch in e t h a t t a k e a n e igh bor fr om D ow n t o Fu ll.
Figu r e 8 - 5 . Th e n e igh bor st a t e m a ch in e , fr om D ow n t o I n it .
Figu r e 8 - 6 . Th e n e igh bor st a t e m a ch in e , fr om I n it t o Fu ll.
[View full size image]
Ta ble 8 - 2 . I n pu t e ve n t s for Figu r e 8 - 4 t h r ou gh Figu r e 8 - 6 .
I n pu t Eve n t
D e scr ipt ion
I E1
This event occurs only for NBMA- connect ed neighbors. The input event will
be t riggered under eit her of t he following condit ions:
1 . The int erface t o t he NBMA net work first becom es act ive, and t he
neighbor is eligible for DR elect ion.
2 . The rout er becom es eit her DR or BDR, and t he neighbor is not eligible
for DR elect ion.
I E2
A valid Hello packet has been received from t he neighbor.
I E3
The neighbor is no longer reachable, as det erm ined by t he lower level
prot ocols, by an explicit inst ruct ion from t he OSPF process it self, or by t he
expirat ion of t he inact ivit y t im er.
I E4
The rout er first sees it s own Rout er I D list ed in t he Neighbor field of t he
neighbor's Hello packet or receives a Dat abase Descript ion packet from t he
neighbor.
I E5
The neighbor should not becom e adj acent .
I n pu t Eve n t
D e scr ipt ion
I E6
This input event occurs under eit her of t he following condit ions:
( 1) The neighbor st at e first t ransit ions t o 2- Way.
( 2) The int erface st at e changes.
I E7
An adj acency should be form ed wit h t his neighbor.
I E8
The m ast er/ slave relat ionship has been est ablished and DD sequence
num bers have been exchanged.
I E9
The exchange of Dat abase Descript ion packet s has been com plet ed.
I E10
Ent ries exist in t he Link St at e Request list .
I E11
The Link St at e Request list is em pt y.
I E12
The adj acency should be broken and t hen rest art ed. This input event m ight
be t riggered by any of t he following:
( 1) The recept ion of a Dat abase Descript ion packet wit h an unexpect ed DD
sequence num ber
( 2) The recept ion of a Dat abase Descript ion packet wit h t he Opt ions field set
different ly t han t he Opt ions field of t he last DD packet
( 3) The recept ion of a Dat abase Descript ion packet , ot her t han t he first
packet , in which t he I nit bit is set
( 4) The recept ion of a Link St at e Request packet for an LSA t hat is not in t he
dat abase
I E13
A Hello packet has been received from t he neighbor in which t he receiving
rout er's Rout er I D is not list ed in t he Neighbor field.
I E14
This event occurs when t he int erface st at e changes.
I E15
The exist ing or form ing adj acency wit h t his neighbor should cont inue.
I E16
The exist ing or form ing adj acency wit h t his neighbor should not cont inue.
Ta ble 8 - 3 . D e cision poin t s for Figu r e 8 - 4 a n d Figu r e 8 - 6 .
D e cision
D e scr ipt ion
DP1
Should an adj acency be est ablished wit h t he neighbor? An adj acency should
be form ed if one or m ore of t he following condit ions is t rue:
( 1) The net work t ype is point - t o- point .
( 2) The net work t ype is point - t o- m ult ipoint .
( 3) The net work t ype is virt ual link.
( 4) The rout er is t he DR for t he net work on which t he neighbor is locat ed.
( 5) The rout er is t he BDR for t he net work on which t he neighbor is locat ed.
( 6) The neighbor is t he DR.
( 7) The neighbor is t he BDR.
DP2
I s t he Link St at e Request list for t his neighbor em pt y?
DP3
Should t he exist ing or form ing adj acency wit h t he neighbor cont inue?
Building an Adjacency
Neighbors on point - t o- point , point - t o- m ult ipoint , and virt ual link net works always becom e
adj acent unless t he param et ers of t heir Hellos don't m at ch. On broadcast and NBMA net works,
t he DR and BDR becom e adj acent wit h all neighbors, but no adj acencies exist bet ween
DRot hers.
The adj acency building process uses t hree OSPF packet t ypes:
Dat abase Descript ion packet s ( t ype 2)
Link St at e Request packet s ( t ype 3)
Link St at e Updat e packet s ( t ype 4)
The form at s of t hese packet t ypes are described in det ail in a subsequent sect ion, " OSPF Packet
For m at s."
The Dat abase Descript ion packet is of part icular im port ance t o t he adj acency- building process.
As t he nam e im plies, t he packet s carry a sum m ary descript ion of each LSA in t he originat ing
rout er's link- st at e dat abase. These descript ions are not t he com plet e LSAs, but m erely t heir
headersenough inform at ion for t he receiving rout er t o decide whet her it has t he lat est copy of
t he LSA in it s own dat abase. I n addit ion, t hree flags in t he DD packet are used t o m anage t he
adj acency building process:
The I - bit , or I nit ial bit , which when set indicat es t he first DD packet sent
The M- bit , or More bit , which when set indicat es t hat t his is not t he last DD packet t o be
sent
The MS- bit , or Mast er/ Slave bit , which is set in t he DD packet s originat ed by t he m ast er
When t he m ast er/ slave negot iat ion begins in t he ExSt art st at e, bot h neighbors will claim t o be
t he m ast er by sending an em pt y DD packet wit h t he MS- bit set t o one. The DD sequence
num ber in t hese t wo packet s will be set t o t he originat ing rout er's idea of what t he sequence
num ber should be. The neighbor wit h t he lower Rout er I D will becom e t he slave and will reply
wit h a DD packet in which t he MS- bit is zero and t he DD sequence num ber is set t o t he m ast er's
sequence num ber. This DD packet will be t he first packet populat ed wit h LSA sum m aries. When
t he m ast er/ slave negot iat ion is com plet ed, t he neighbor st at e t ransit ions t o Exchange.
I n t he Exchange st at e, t he neighbors synchronize t heir link- st at e dat abases by describing all
ent ries in t heir respect ive link- st at e dat abases. The Dat abase Sum m ary List is populat ed wit h
t he headers of all LSAs in t he rout er's dat abase; Dat abase Descript ion packet s cont aining t he
list ed LSA headers are sent t o t he neighbor.
I f eit her rout er sees t hat it s neighbor has an LSA t hat is not in it s own dat abase, or t hat t he
neighbor has a m ore recent copy of a known LSA, it places t he LSA on t he Link St at e Request
list . I t t hen sends a Link St at e Request packet asking for a com plet e copy of t he LSA in quest ion.
Link St at e Updat e packet s convey t he request ed LSAs. As t he request ed LSAs are received, t hey
are rem oved from t he Link St at e Request list .
All LSAs sent in Updat e packet s m ust be individually acknowledged. Therefore, t he t ransm it t ed
LSAs are ent ered int o t he Link St at e Ret ransm ission list . As t hey are acknowledged, t hey are
rem oved from t he list . The LSA m ay be acknowledged by one of t wo m eans:
Ex plicit Ack n ow le dgm e n t A Link St at e Acknowledgm ent packet cont aining t he LSA
header is received.
I m plicit Ack n ow le dgm e n t An Updat e packet t hat cont ains t he sam e inst ance of t he LSA
( neit her LSA is m ore recent t han t he ot her) is received.
The m ast er cont rols t he synchronizat ion process and ensures t hat only one DD packet is
out st anding at a t im e. When t he slave receives a DD packet from t he m ast er, t he slave
acknowledges t he packet by sending a DD packet wit h t he sam e sequence num ber. I f t he m ast er
does not receive an acknowledgm ent of an out st anding DD packet wit hin t he Rxm t I nt erval, as
specified in t he int erface dat a st ruct ure, t he m ast er sends a new copy of t he packet .
The slave sends DD packet s only in response t o DD packet s it receives from t he m ast er. I f t he
received DD packet has a new sequence num ber, t he slave sends a DD packet wit h t he sam e
sequence num ber. I f t he received sequence num ber is t he sam e as a previously acknowledged
DD packet , t he acknowledging packet is re- sent .
When t he dat abase synchronizat ion process is com plet e, one of t wo st at e t ransit ions will occur:
I f t here are st ill ent ries of t he Link St at e Request list , t he rout er t ransit ions t he st at e of t he
neighbor t o Loading.
I f t he Link St at e Request list is em pt y, t he rout er t ransit ions t he st at e of t he neighbor t o
Full.
The m ast er knows t hat t he synchronizat ion process is com plet e when it has sent all t he DD
packet s necessary t o fully describe it s link- st at e dat abase and has received a DD packet wit h t he
M- bit set t o zero. The slave knows t hat t he process is com plet e when it receives a DD packet
wit h t he M- bit set t o zero and sends an acknowledging DD packet t hat also has it s M- bit set t o
zero ( t hat is, t he slave has fully described it s own dat abase) . Because t he slave m ust
acknowledge each received DD packet , t he slave will always be t he first t o know t hat t he
synchronizat ion process is com plet e.
Figure 8- 7 shows t he adj acency- building process. This exam ple is t aken direct ly from RFC 2328.
Figu r e 8 - 7 . Th e lin k - st a t e da t a ba se syn ch r on iza t ion pr oce ss a n d
a ssocia t e d n e igh bor st a t e s.
[View full size image]
The following st eps are illust rat ed in Figure 8- 7 :
1.
RT1 becom es act ive on t he m ult i- access net work and sends a Hello packet . I t has not yet
heard from any neighbors, so t he Neighbor field of t he packet is em pt y, and t he DR and
BDR fields are set t o 0.0.0.0.
2.
Upon recept ion of t he Hello from RT1, RT2 creat es a neighbor dat a st ruct ure for RT1 and
set s RT1's st at e t o I nit . RT2 sends a Hello packet wit h RT1's Rout er I D in t he Neighbor
field; as t he DR, RT2 also includes it s own int erface address in t he DR field.
3.
Seeing it s Rout er I D in t he received Hello packet ( I E 4 in Table 8- 2) , RT1 creat es a neighbor
dat a st ruct ure for RT2 and set s RT2's st at e t o ExSt art for t he m ast er/ slave negot iat ion. I t
t hen generat es an em pt y ( no LSA sum m aries) Dat abase Descript ion packet ; t he DD
sequence num ber is set t o x, t he I - bit is set t o indicat e t hat t his is RT1's init ial DD packet
for t his exchange, t he M- bit is set t o indicat e t hat t his is not t he last DD packet , and t he
MS- bit is set t o indicat e t hat RT1 is assert ing it self as t he m ast er.
4.
RT2 t ransit ions RT1's st at e t o ExSt art upon recept ion of t he DD packet . I t t hen sends a
responding DD packet wit h a DD sequence num ber of y; RT2 has a higher rout er I D t han
RT1, so it set s t he MS- bit . Like t he first DD packet , t his one is used for t he m ast er/ slave
negot iat ion and t herefore is em pt y.
5.
Agreeing t hat RT2 is t he m ast er, RT1 t ransit ions RT2's st at e t o Exchange. RT1 will generat e
a DD packet wit h RT2's DD sequence num ber of y and t he MS = 0, indicat ing t hat RT1 is
t he slave. This packet will be populat ed wit h LSA headers from RT1's Link St at e Sum m ary
list .
6.
RT2 t ransit ions it s neighbor st at e t o Exchange upon receipt of RT1's DD packet . I t will send
a DD packet cont aining LSA headers from it s Link St at e Sum m ary list and will increm ent
t he DD sequence num ber t o y + 1.
7.
RT1 sends an acknowledging packet cont aining t he sam e sequence num ber as in t he DD
packet t hat it j ust received from RT2. The process cont inues, wit h RT2 sending a single DD
packet and t hen wait ing for an acknowledging packet from RT1 cont aining t he sam e
sequence num ber before sending t he next packet . When RT2 sends t he DD packet wit h t he
last of it s LSA sum m aries, it set s M = 0.
8.
Receiving t his packet and knowing t hat t he acknowledging packet it will send cont ains t he
last of it s own LSA sum m aries, RT1 knows t he Exchange process is done. However, it has
ent ries in it s Link St at e Request list ; t herefore, it will t ransit ion t o Loading.
9.
When RT2 receives RT1's last DD packet , RT2 t ransit ions RT1's st at e t o Full because it has
no ent ries in it s Link St at e Request list .
1 0 . RT1 sends Link St at e Request packet s, and RT2 sends t he request ed LSAs in Link St at e
Updat e packet s, unt il RT1's Link St at e Request list is em pt y. RT1 will t hen t ransit ion RT2's
st at e t o Full.
Not e t hat if eit her rout er has ent ries in it s Link St at e Request list , it does not need t o wait for t he
Loading st at e t o send Link St at e Request packet s; it m ay do so while t he neighbor is st ill in t he
Exchange st at e. Consequent ly, t he synchronizat ion process is not as t idy as depict ed in Figure 87, but it is m ore efficient .
Figure 8- 8 shows an analyzer capt ure of an adj acency being built bet ween t wo rout ers. Alt hough
Link St at e Request and Link St at e Updat e packet s are being sent while bot h neighbors are st ill in
t he Exchange st at e, at t ent ion t o t he I - , M- , and MS- bit s and t he sequence num bers reveals t hat
t he real- life process follows t he generic procedure of Figure 8- 7 .
Figu r e 8 - 8 . Th is a n a lyze r ca pt u r e sh ow s a n a dj a ce n cy be in g bu ilt .
[View full size image]
I n Exam ple 8- 7, t he out put of t he com m and de bu g ip ospf a dj shows t he adj acency of Figure
8 - 8 being built from t he perspect ive of one of t he rout ers ( rout er I D 192.168.30.175) .
Ex a m ple 8 - 7 . Th is de bu g ou t pu t sh ow s t h e a dj a ce n cy e ve n t s of Figu r e
8 - 8 fr om t h e pe r spe ct ive of on e of t h e r ou t e r s.
Degas#debug ip ospf adj
OSPF adjacency events debugging is on
OSPF: Rcv DBD from 192.168.30.70 on Ethernet0 seq 0x20E0 opt 0x2 flag 0x7 len 32
state INIT
OSPF: 2 Way Communication to 192.168.30.70 on Ethernet0,
state 2WAY
OSPF: Neighbor change Event on interface Ethernet0
OSPF: DR/BDR election on Ethernet0
OSPF: Elect BDR 192.168.30.70
OSPF: Elect DR 192.168.30.175
DR: 192.168.30.175 (Id) BDR: 192.168.30.70 (Id)
OSPF: Send DBD to 192.168.30.70 on Ethernet0 seq 0xB17 opt 0x2 flag 0x7 len 32
OSPF: First DBD and we are not SLAVE
OSPF: Rcv DBD from 192.168.30.70 on Ethernet0 seq 0xB17 opt 0x2 flag 0x2 len 92
state
OSPF:
OSPF:
OSPF:
OSPF:
state
OSPF:
OSPF:
state
OSPF:
OSPF:
state
EXSTART
NBR Negotiation Done. We are the MASTER
Send DBD to 192.168.30.70 on Ethernet0 seq 0xB18 opt 0x2 flag 0x3 len 72
Database request to 192.168.30.70
Rcv DBD from 192.168.30.70 on Ethernet0 seq 0xB18 opt 0x2 flag 0x0 len 32
EXCHANGE
Send DBD to 192.168.30.70 on Ethernet0 seq 0xB19 opt 0x2 flag 0x1 len 32
Rcv DBD from 192.168.30.70 on Ethernet0 seq 0xB19 opt 0x2 flag 0x0 len 32
EXCHANGE
Exchange Done with 192.168.30.70 on Ethernet0
Synchronized with 192.168.30.70 on Ethernet0,
FULL
At t he end of t he synchronizat ion process in Figure 8- 8 , a series of Link St at e Updat e and Link
St at e Acknowledgm ent packet s can be observed. These are part of t he LSA flooding process,
discussed in t he next sect ion.
Flooding
The ent ire OSPF t opology can be depict ed as a group of rout ers, or nodes, int erconnect ed not by
physical links but by logical adj acencies ( Figure 8- 9 ) . For t he nodes t o rout e properly over t his
logical t opology, each node m ust possess an ident ical m ap of t he t opology. This m ap is t he
t opological dat abase.
Figu r e 8 - 9 . A gr ou p of r ou t e r s in t e r con n e ct e d by da t a lin k s w ill be
vie w e d by OSPF a s a gr ou p of n ode s in t e r con n e ct e d by a dj a ce n cie s.
The OSPF t opological dat abase is bet t er known as t he link- st at e dat abase. This dat abase consist s
of all t he LSAs t he rout er has received. A change in t he t opology is represent ed as a change in
one or m ore of t he LSAs. Flooding is t he process by which t hese changed or new LSAs are sent
t hroughout t he net work, t o ensure t hat t he dat abase of every node is updat ed and rem ains
ident ical t o all ot her nodes' dat abases.
Flooding m akes use of t he following t wo OSPF packet t ypes:
Link St at e Updat e packet s ( t ype 4)
Link St at e Acknowledgm ent packet s ( t ype 5)
As Figure 8- 10 shows, each Link St at e Updat e and Acknowledgm ent packet m ay carry m ult iple
LSAs. Alt hough t he LSAs t hem selves are flooded t hroughout t he area, t he Updat e and
Acknowledgm ent packet s t ravel only bet ween t wo nodes across an adj acency.
Figu r e 8 - 1 0 . LSAs a r e se n t a cr oss a dj a ce n cie s w it h in lin k - st a t e u pda t e
pa ck e t s.
On point - t o- point net works, updat es are sent t o t he m ult icast address AllSPFRout ers
( 224.0.0.5) . On point - t o- m ult ipoint and virt ual link net works, updat es are unicast ed t o t he
int erface addresses of t he adj acent neighbors.
On broadcast net works, DRot hers form adj acencies only wit h t he DR and BDR. Therefore,
updat es are sent t o t he address AllDRout ers ( 224.0.0.6) . The DR in t urn m ult icast s an Updat e
packet cont aining t he LSA t o all adj acent rout ers on t he net work using t he address
AllSPFRout ers. All rout ers t hen flood t he LSA out all ot her int erfaces ( Figure 8- 11) . Alt hough t he
BDR hears and records LSAs m ult icast from DRot hers, it does not reflood or acknowledge t hem
unless t he DR fails t o do so. The sam e DR/ BDR funct ionalit y exist s on NBMA net works, except
t hat LSAs are unicast from DRot hers t o t he DR and BDR, and t he DR unicast s a copy of t he LSA
t o all adj acent neighbors.
Figu r e 8 - 1 1 . On a br oa dca st n e t w or k , a D Rot h e r se n ds a n LSA on ly t o
t h e D R a n d BD R ( a ) ; t h e D R r e floods t h e LSA t o a ll a dj a ce n t n e igh bor s
( b) ; a ll r ou t e r s t h e n flood t h e LSA on a ll ot h e r in t e r fa ce s ( c) .
Because ident ical link- st at e dat abases are essent ial t o correct OSPF operat ion, flooding m ust be
reliable. Transm it t ing rout ers m ust know t hat t heir LSAs were received successfully, and
receiving rout ers m ust know t hat t hey are accept ing t he correct LSAs.
Reliable Flooding: Acknowledgments
Each individual t ransm it t ed LSA m ust be acknowledged. This m ay be accom plished by eit her an
im plicit acknowledgm ent or an explicit acknowledgm ent .
A neighbor can im plicit ly acknowledge t he receipt of an LSA by including a duplicat e of t he LSA
in an updat e back t o t he originat or. I m plicit acknowledgm ent s are m ore efficient t han explicit
acknowledgm ent s in som e sit uat ions, such as when t he neighbor was int ending t o send an
updat e t o t he originat or anyway.
A neighbor explicit ly acknowledges t he receipt of an LSA by sending a Link St at e
Acknowledgm ent packet . A single Link St at e Acknowledgm ent packet is capable of
acknowledging m ult iple LSAs. The packet carries only LSA headersenough t o com plet ely ident ify
t he LSAnot t he com plet e LSA.
When a rout er first sends an LSA, a copy of t he LSA is ent ered int o t he Link St at e
Ret ransm ission list of every neighbor t o which it was sent . The LSA is ret ransm it t ed every
Rxm t I nt erval unt il it is acknowledged or unt il t he adj acency is broken. The Link St at e Updat e
packet s cont aining ret ransm issions are always unicast , regardless of t he net work t ype.
Acknowledgm ent s m ight be eit her delayed or direct . By delaying an acknowledgm ent , m ore
LSAs can be acknowledged in a single Link St at e Acknowledgm ent packet ; on a broadcast
net work, LSAs from m ult iple neighbors can be acknowledged in a single m ult icast Link St at e
Acknowledgm ent packet . The period by which an acknowledgm ent is delayed m ust be less t han
t he Rxm t I nt erval t o prevent unnecessary ret ransm issions. Under norm al circum st ances, t he
unicast / m ult icast addressing convent ions used for Link St at e Updat e packet s on various net work
t ypes also apply t o Link St at e Acknowledgm ent s.
Direct acknowledgm ent s are always sent im m ediat ely and are always unicast . Direct
acknowledgm ent s are sent whenever t he following condit ions occur:
A duplicat e LSA is received from a neighbor, possibly indicat ing t hat it has not yet received
an acknowledgm ent .
The LSA's age is MaxAge ( described in t he next sect ion) , and t here is no inst ance of t he
LSA in t he receiving rout er's link- st at e dat abase.
Reliable Flooding: Sequencing, Checksums, and Aging
Each LSA cont ains t hree values t hat are used t o ensure t hat t he m ost recent copy of t he LSA
exist s in every dat abase. These values are sequence num ber, checksum , and age.
OSPF uses a 32- bit signed, linear sequence num ber space ( discussed in Chapt er 4, " Dynam ic
Rout ing Prot ocols" ) ranging from I nit ialSequenceNum ber ( 0x80000001) t o MaxSequenceNum ber
( 0x7fffffff) . When a rout er originat es an LSA, t he rout er set s t he LSA's sequence num ber t o
I nit ialSequenceNum ber. Each t im e t he rout er produces a new inst ance of t he LSA, t he rout er
increm ent s t he sequence num ber by one.
I f t he present sequence num ber is MaxSequenceNum ber and a new inst ance of t he LSA m ust be
creat ed, t he rout er m ust first flush t he old LSA from all dat abases. This is done by set t ing t he
age of t he exist ing LSA t o MaxAge ( defined lat er in t his sect ion) and reflooding it over all
adj acencies. As soon as all adj acent neighbors have acknowledged t he prem at urely aged LSA,
t he new inst ance of t he LSA wit h a sequence num ber of I nit ialSequenceNum ber m ay be flooded.
The checksum is a 16- bit int eger calculat ed using a Flet cher algorit hm . [ 12] The checksum is
calculat ed over t he ent ire LSA wit h t he except ion of t he Age field ( which changes as t he LSA
passes from node t o node and would t herefore require recalculat ion of t he checksum at each
node) . The checksum of each LSA is also verified every five m inut es as it resides in t he link- st at e
dat abase, t o ensure t hat it has not been corrupt ed in t he dat abase.
[12]
Alex McKenzie, "ISO Transport Protocol Specification ISO DP 8073," RFC 905, April 1984, Annex B.
The age is an unsigned 16- bit int eger t hat indicat es t he age of t he LSA in seconds. The range is
0 t o 3600 ( one hour, known as MaxAge) . When a rout er originat es an LSA, t he rout er set s t he
age t o 0. As t he flooded LSA t ransit s a rout er, t he age is increm ent ed by a num ber of seconds
specified by I nfTransDelay. Cisco rout ers have a default I nfTransDelay of one second, which can
be changed wit h t he com m and ip ospf t r a n sm it - de la y. The age is also increm ent ed as it
resides in t he dat abase.
When an LSA reaches MaxAge, t he LSA is reflooded and t hen flushed from t he dat abase. When a
rout er needs t o flush an LSA from all dat abases, it prem at urely set s t he age t o MaxAge and
refloods it . Only t he rout er t hat originat ed t he LSA can prem at urely age it .
Exam ple 8- 8 shows a port ion of a link- st at e dat abase; t he age, sequence num ber, and checksum
of each LSA can be observed. More det ailed discussion of t he dat abase and t he various LSA
t ypes is in "Link- St at e Dat abase," lat er in t his chapt er.
Ex a m ple 8 - 8 . Th e a ge , se qu e n ce n u m be r , a n d ch e ck su m for e a ch LSA
a r e r e cor de d in t h e lin k - st a t e da t a ba se . Th e a ge is in cr e m e n t e d in
se con ds.
Manet#show ip ospf database
OSPF Router with ID (192.168.30.43) (Process ID 1)
Router Link States (Area 3)
Link ID
ADV Router
Age
Seq#
Checksum Link Count
192.168.30.13 192.168.30.13 910
0x80000F29 0xA94E
2
192.168.30.23 192.168.30.23 1334 0x80000F55 0x8D53
3
192.168.30.30 192.168.30.30 327
0x800011CA 0x523
8
192.168.30.33 192.168.30.33 70
0x80000AF4 0x94DD
3
192.168.30.43 192.168.30.43 1697 0x80000F2F 0x1DA1
2
When m ult iple inst ances of t he sam e LSA are received, a rout er det erm ines which is t he m ost
recent by t he following algorit hm :
1 . Com pare t he sequence num bers. The LSA wit h t he highest sequence num ber is m ore
recent .
2 . I f t he sequence num bers are equal, t hen com pare t he checksum s. The LSA wit h t he highest
unsigned checksum is t he m ore recent .
3 . I f t he checksum s are equal, t hen com pare t he age. I f only one of t he LSAs has an age of
MaxAge ( 3600 seconds) , it is considered t he m ore recent .
4 . I f t he ages of t he LSAs differ by m ore t han 15 m inut es ( known as MaxAgeDiff) , t he LSA
wit h t he lower age is m ore recent .
5 . I f none of t he preceding condit ions are m et , t he t wo LSAs are considered ident ical.
Areas
The reader should by now have a good feel for why OSPF, wit h it s m ult iple dat abases and
com plex algorit hm s, can put great er dem ands on t he m em ory and processors of a rout er t han
t he previously exam ined prot ocols can. As a net work grows, t hese dem ands can becom e
significant or even crippling. And alt hough flooding is m ore efficient t han t he periodic, full- t able
updat es of RI P, it can st ill place an unaccept able burden on t he dat a links of a large net work.
Cont rary t o popular belief, t he SPF algorit hm it self is not part icularly processor- int ensive.
Rat her, t he relat ed processes, such as flooding and dat abase m aint enance, burden t he CPU.
OSPF uses areas t o reduce t hese adverse effect s. I n t he cont ext of OSPF, an area is a logical
grouping of OSPF rout ers and links t hat effect ively divide an OSPF dom ain int o sub- dom ains
( Figure 8- 12) . Rout ers wit hin an area will have no det ailed knowledge of t he t opology out side of
t heir area. Because of t his condit ion
A rout er m ust share an ident ical link- st at e dat abase only wit h t he ot her rout ers in it s area,
not wit h t he ent ire OSPF dom ain. The reduced size of t he dat abase reduces t he im pact on a
rout er's m em ory.
The sm aller link- st at e dat abases m ean fewer LSAs t o process and t herefore less im pact on
t he CPU.
Because t he link- st at e dat abase m ust be m aint ained only wit hin an area, m ost flooding is
also lim it ed t o t he area.
Figu r e 8 - 1 2 . An OSPF a r e a is a logica l gr ou pin g of OSPF r ou t e r s. Ea ch
a r e a is de scr ibe d by it s ow n lin k - st a t e da t a ba se , a n d e a ch r ou t e r m u st
m a in t a in a da t a ba se on ly for t h e a r e a t o w h ich it be lon gs.
Areas are ident ified by a 32- bit Area I D. As Figure 8- 12 shows, t he Area I D m ay be expressed
eit her as a decim al num ber or in dot t ed decim al, and t he t wo form at s m ay be used t oget her on
Cisco rout ers. The choice usually depends on which form at is m ore convenient for ident ifying t he
part icular Area I D. For exam ple, area 0 and area 0.0.0.0 are equivalent , as are area 16 and area
0.0.0.16, and area 271 and area 0.0.1.15. I n each of t hese cases, t he decim al form at would
probably be preferred. However, given t he choice of area 3232243229 and area 192.168.30.29,
t he lat t er would probably be chosen.
Three t ypes of t raffic m ay be defined in relat ion t o areas:
I n t r a - a r e a t raffic consist s of packet s t hat are passed bet ween rout ers wit hin a single area.
I n t e r - a r e a t raffic consist s of packet s t hat are passed bet ween rout ers in different areas.
Ex t e r n a l t raffic consist s of packet s t hat are passed bet ween a rout er wit hin t he OSPF
dom ain and a rout er wit hin anot her rout ing dom ain.
Area I D 0 ( or 0.0.0.0) is reserved for t he backbone. The backbone is responsible for
sum m arizing t he t opologies of each area t o every ot her area. For t his reason, all int er- area
t raffic m ust pass t hrough t he backbone; non- backbone areas cannot exchange packet s direct ly.
Many OSPF designers have a favorit e rule of t hum b concerning t he m axim um num ber of rout ers
t hat an area can handle. This num ber m ight range from 30 t o 200. However, t he num ber of
rout ers has lit t le act ual bearing on t he m axim um size of an area. Far m ore im port ant fact ors
include t he num ber of links in an area, t he st abilit y of t he t opology, t he m em ory and horsepower
of t he rout ers, t he use of sum m arizat ion, and t he num ber of sum m ary LSAs ent ering t he area.
Because of t hese fact ors, 25 rout ers m ight be t oo m any for som e areas, and ot her areas m ight
accom m odat e well over 500 rout ers.
I t is perfect ly reasonable t o design a sm all OSPF net work wit h only a single area. Regardless of
num ber of areas, a pot ent ial problem arises when an area is so underpopulat ed t hat no
redundant links exist wit hin it . I f such an area becom es part it ioned, service disrupt ions m ight
occur. Part it ioned areas are discussed in m ore det ail in a lat er sect ion.
Router Types
Rout ers, like t raffic, can be cat egorized in relat ion t o areas. All OSPF rout ers will be one of four
rout er t ypes, as shown in Figure 8- 13:
I n t e r n a l Rou t e r s are rout ers whose int erfaces all belong t o t he sam e area. These rout ers
have a single link- st at e dat abase.
Ar e a Bor de r Rou t e r s ( ABRs) connect one or m ore areas t o t he backbone and act as a
gat eway for int er- area t raffic. An ABR always has at least one int erface t hat belongs t o t he
backbone, and m ust m aint ain a separat e link- st at e dat abase for each of it s connect ed
areas. For t his reason, ABRs oft en have m ore m em ory and perhaps m ore powerful
processors t han int ernal rout ers. An ABR sum m arizes t he t opological inform at ion of it s
at t ached areas int o t he backbone, which t hen propagat es t he sum m ary inform at ion t o t he
ot her areas.
Figu r e 8 - 1 3 . All OSPF r ou t e r s ca n be cla ssifie d a s a n I n t e r n a l
Rou t e r , a Ba ck bon e Rou t e r , a n Ar e a Bor de r Rou t e r ( ABR) , or a n
Au t on om ou s Syst e m Bou n da r y Rou t e r ( ASBR) . N ot e t h a t a n y of t h e
fir st t h r e e r ou t e r t ype s m igh t a lso be a n ASBR.
[View full size image]
Ba ck bon e Rou t e r s are rout ers wit h at least one int erface at t ached t o t he backbone.
Alt hough t his requirem ent m eans t hat ABRs are also Backbone Rout ers, Figure 8- 13 shows
t hat not all Backbone Rout ers are ABRs. An I nt ernal Rout er whose int erfaces all belong t o
area 0 is also a Backbone Rout er.
Au t on om ou s Syst e m Bou n da r y Rou t e r s ( ASBRs) are gat eways for ext ernal t raffic,
inj ect ing rout es int o t he OSPF dom ain t hat were learned ( redist ribut ed) from som e ot her
prot ocol, such as t he BGP and EI GRP processes shown in Figure 8- 13. An ASBR can be
locat ed anywhere wit hin t he OSPF aut onom ous syst em except wit hin st ub areas; it m ay be
an I nt ernal, Backbone, or ABR.
Partitioned Areas
A part it ioned area is an area in which a link failure causes one part of t he area t o becom e
isolat ed from anot her. I f a non- backbone area becom es part it ioned and if all rout ers on eit her
side of t he part it ion can st ill find an ABR, as in Figure 8- 14, no service disrupt ions will occur. The
backbone m erely t reat s t he part it ioned area as t wo separat e areas. I nt ra- area t raffic from one
side of t he part it ion t o t he ot her side will becom e int er- area t raffic, passing t hrough t he
backbone t o circum vent t he part it ion. Not e t hat a part it ioned area is not t he sam e as an isolat ed
area, in which no pat h exist s t o t he rest of t he OSPF dom ain.
Figu r e 8 - 1 4 . ( a ) Ar e a 3 is con n e ct e d t o t h e ba ck bon e ( a r e a 0 ) by t w o
ABRs. ( b) A lin k fa ilu r e in a r e a 3 cr e a t e s a pa r t it ion e d a r e a , bu t a ll
r ou t e r s w it h in a r e a 3 ca n st ill r e a ch a n ABR. I n t h e se cir cu m st a n ce s,
t r a ffic ca n st ill be r ou t e d be t w e e n t h e t w o side s of t h e pa r t it ion e d
area.
A part it ion of t he backbone it self is a m ore serious m at t er. As Figure 8- 15 shows, a part it ioned
backbone area isolat es t he areas on each side of t he part it ion, creat ing t wo separat e OSPF
dom ains.
Figu r e 8 - 1 5 . I f a ba ck bon e be com e s pa r t it ion e d, e a ch side of t h e
pa r t it ion a n d a n y con n e ct e d a r e a s be com e isola t e d fr om t h e ot h e r
side .
Figure 8- 16 shows som e bet t er area designs. Bot h area 0 and area 2 are designed so t hat
neit her of t hem can be part it ioned by a single link failure. The vulnerabilit y of area 2, however,
is t hat if t he ABR fails, t he area will be isolat ed. Area 3 uses t wo ABRs; here, neit her a single link
failure nor a single ABR failure can isolat e any part of t he area.
Figu r e 8 - 1 6 . I n a r e a s 0 a n d 2 , n o sin gle lin k fa ilu r e ca n pa r t it ion t h e
a r e a . I n a r e a 3 , n o sin gle ABR or lin k fa ilu r e ca n isola t e t h e a r e a .
Virtual Links
A virt ual link is a link t o t he backbone t hrough a non- backbone area. Virt ual links are used for
t he following purposes:
1 . To link an area t o t he backbone t hrough a non- backbone area (Figure 8- 17)
Figu r e 8 - 1 7 . A vir t u a l lin k con n e ct s a r e a 2 3 t o t h e ba ck bon e
t h r ou gh a r e a 1 2 .
2 . To connect t he t wo part s of a part it ioned backbone t hrough a nonbackbone area (Figure 818 )
Figu r e 8 - 1 8 . A vir t u a l lin k r e con n e ct s a pa r t it ion e d ba ck bon e
t h r ou gh a n on ba ck bon e a r e a .
I n bot h exam ples, t he virt ual link is not associat ed wit h a part icular physical link. The virt ual link
is a t unnel t hrough which packet s m ay be rout ed on t he opt im al pat h from one endpoint t o t he
ot her.
Several rules are associat ed wit h t he configurat ion of virt ual links:
Virt ual links m ust be configured bet ween t wo ABRs.
The area t hrough which t he virt ual link is configured, known as t he t ransit area, m ust have
full rout ing inform at ion.
The t ransit area cannot be a st ub area.
As m ent ioned previously, OSPF classifies a virt ual link as a net work t ype. Specifically, t he link is
considered an unnum beredt hat is, unaddressedlink, belonging t o t he backbone, bet ween t wo
ABRs. These ABRs are considered neighbors by virt ue of t he virt ual link bet ween t hem , alt hough
t hey are not linked physically. Wit hin each ABR, t he virt ual link will t ransit ion t o t he fully
funct ional point - t o- point int erface st at e when a rout e t o t he neighboring ABR is found in t he
rout e t able. The cost of t he link is t he cost of t he rout e t o t he neighbor. When t he int erface st at e
becom es point - t o- point , an adj acency is est ablished across t he virt ual link.
Virt ual links add a layer of com plexit y and t roubleshoot ing difficult y t o any net work. I t is best t o
avoid t he need for t hem by ensuring t hat areas, part icularly backbone areas, are designed wit h
redundant links t o prevent part it ioning. When t wo or m ore net works are m erged, sufficient
planning should t ake place beforehand so t hat no area is left wit hout a direct link t o t he
backbone.
I f a virt ual link is configured, it should be used only as a t em porary fix t o an unavoidable
t opology problem . A virt ual link is a flag m arking a part of t he net work t hat needs t o be
reengineered. Perm anent virt ual links are virt ually always a sign of a poorly designed net work.
Link-State Database
All valid LSAs received by a rout er are st ored in it s link- st at e dat abase. The collect ed LSAs will
describe a graph of t he area t opology. Because each rout er in an area calculat es it s short est
pat h t ree from t his dat abase, it is im perat ive for accurat e rout ing t hat all area dat abases are
ident ical.
A list of t he LSAs in a link- st at e dat abase can be observed wit h t he com m and sh ow ip ospf
da t a ba se, as shown in Exam ple 8- 9. This list does not show all of t he inform at ion st ored for
each LSA, but shows only t he inform at ion in t he LSA header. Not e t hat t his dat abase cont ains
LSAs from m ult iple areas, indicat ing t hat t he rout er is an ABR.
Ex a m ple 8 - 9 . Th e com m a n d sh ow ip ospf da t a ba se displa ys a list of a ll
LSAs in t h e lin k - st a t e da t a ba se .
Homer#show ip ospf database
OSPF Router with ID (192.168.30.50) (Process ID 1)
Router Link States (Area 0)
Link ID
192.168.30.10
192.168.30.20
192.168.30.70
192.168.30.80
ADV Router
192.168.30.10
192.168.30.20
192.168.30.70
192.168.30.80
Age
1010
677
857
1010
Seq#
0x80001416
0x800013C9
0x80001448
0x800014D1
Checksum
0xA818
0xDE18
0xFD79
0xEB5C
Net Link States (Area 0)
Link ID
ADV Router
Age
Seq#
Checksum
Link count
3
3
3
5
192.168.17.18
192.168.17.34
192.168.17.58
192.168.17.73
192.168.30.20
192.168.30.60
192.168.30.40
192.168.30.70
677
695
579
857
0x800001AD
0x800003E2
0x8000113C
0x8000044F
0x849A
0x4619
0xF0D
0xB0E7
Summary Net Link States (Area 0)
Link ID
172.16.121.0
172.16.121.0
10.63.65.0
10.63.65.0
ADV Router
192.168.30.60
192.168.30.70
192.168.30.10
192.168.30.80
Age
421
656
983
962
Seq#
0x8000009F
0x8000037F
0x80000004
0x80000004
Checksum
0xD52
0x86A
0x1EAA
0x780A
Summary ASB Link States (Area 0)
Link ID
192.168.30.12
192.168.30.12
172.20.57.254
172.20.57.254
ADV Router
192.168.30.20
192.168.30.30
192.168.30.70
192.168.30.80
Age
584
56
664
963
Seq#
0x80000005
0x80000004
0x800000CE
0x80000295
Checksum
0xFC4C
0x45BA
0xF2CF
0x23CC
Router Link States (Area 4)
Link ID
192.168.30.14
192.168.30.24
192.168.30.50
192.168.30.54
ADV Router
192.168.30.14
192.168.30.24
192.168.30.50
192.168.30.54
Age
311
685
116
1213
Seq#
0x80000EA5
0x80001333
0x80001056
0x80000D1F
Checksum
0x93A0
0x6F56
0x42BF
0x3385
Link count
7
6
2
2
Summary Net Link States (Area 4)
Link ID
172.16.121.0
172.16.121.0
10.63.65.0
10.63.65.0
ADV Router
192.168.30.40
192.168.30.50
192.168.30.40
192.168.30.50
Age
1231
34
1240
42
Seq#
0x80000D88
0x800003F4
0x80000003
0x80000005
Checksum
0x73BF
0xF90D
0x5110
0x1144
Summary ASB Link States (Area 4)
Link ID
192.168.30.12
192.168.30.12
172.20.57.254
172.20.57.254
ADV Router
192.168.30.40
192.168.30.50
192.168.30.40
192.168.30.50
Age
1240
42
1241
43
Seq#
0x80000006
0x80000008
0x8000029B
0x800002A8
Checksum
0x6980
0xC423
0xEED8
0x9818
AS External Link States
Link ID
10.83.10.0
10.1.27.0
10.22.85.0
10.22.85.0
Homer#
ADV Router
192.168.30.60
192.168.30.62
192.168.30.70
192.168.30.80
Age
459
785
902
1056
Seq#
0x80000D49
0x800000EB
0x8000037D
0x800001F7
Checksum
0x9C0B
0xB5CE
0x1EC0
0x6B4B
Tag
0
0
65502
65502
Most of t he ent ries in Exam ple 8- 9 have been delet ed for brevit y; t he act ual link- st at e dat abase
cont ains 1,445 ent ries and four areas, as shown in Exam ple 8- 10.
Ex a m ple 8 - 1 0 . Th e com m a n d sh ow ip ospf da t a ba se da t a ba se su m m a r y displa ys t h e n u m be r of LSAs in a lin k - st a t e da t a ba se by a r e a
a n d by LSA t ype .
Homer#show ip ospf database database-summary
OSPF Router with ID (192.168.30.50) (Process ID 1)
Area ID
0
4
5
56
AS External
Total
Homer#
Router
8
7
7
2
Network
4
0
0
1
Sum-Net
185
216
107
236
Sum-ASBR
27
26
13
26
24
5
744
92
Subtotal
224
249
127
265
580
1445
Delete
0
0
0
0
0
Maxage
0
0
0
0
0
As m ent ioned earlier in " Reliable Flooding: Sequencing, Checksum s, and Aging," t he LSAs are
aged as t hey reside in t he link- st at e dat abase. I f t hey reach MaxAge ( 1 hour) , t hey are flushed
from t he OSPF dom ain. The im plicat ion here is t hat t here m ust be a m echanism for prevent ing
legit im at e LSAs from reaching MaxAge and being flushed. This m echanism is t he link- st at e
refresh. Every 30 m inut es, known as t he LSRefreshTim e, t he rout er t hat originat ed t he LSA
floods a new copy of t he LSA wit h an increm ent ed sequence num ber and an age of zero. Upon
receipt , t he ot her OSPF rout ers replace t he old copy of t he LSA and begin aging t he new copy.
So t he link- st at e refresh process can be t hought of as a keepalive for each LSA. An addit ional
benefit is t hat any LSAs t hat m ight have becom e corrupt ed in a rout er's LS dat abase are
replaced wit h t he refreshed copy of t he legit im at e LSA.
The idea behind associat ing an individual refresh t im er wit h each LSA is t hat t he LSRefreshTim e
of t he LSAs do not expire all at once, reflooding all LSAs every 30 m inut es. I nst ead, t he
reflooding is spread out in a sem i- random pat t ern. The problem wit h t his approach is t hat wit h
each individual LSA being reflooded as it s LSRefreshTim e expires, bandwidt h is used inefficient ly.
Updat e packet s can be t ransm it t ed wit h only a few, or even a single, LSA.
Prior t o I OS 11.3, Cisco chose t o have a single LSRefreshTim e associat ed wit h t he ent ire LS
dat abase. Every 30 m inut es, each rout er refreshes all of t he LSAs it originat ed, regardless of
t heir act ual age. Alt hough t his st rat egy avoids t he problem of inefficiency, it reint roduces t he
problem t he individual refresh t im ers were m eant t o solve. I f t he LS dat abase is large, each
rout er can creat e spikes in t he area t raffic and CPU usage every half hour.
Therefore a m echanism known as LSA group pacing was int roduced t o reach a com prom ise
bet ween t he problem s of individual refresh t im ers and a single m onolit hic t im er. Each LSA has
it s own refresh t im er, but as t he individual refresh t im ers expire, a delay is int roduced before t he
LSAs are flooded. By delaying t he refresh, m ore LSAs can be grouped t oget her before being
flooded, so t hat Updat e packet s are carrying a larger num ber of LSAs. By default , t he grouppacing int erval is 240 seconds ( 4 m inut es) . Depending on t he I OS version, t he default can be
changed wit h eit her t im e r s lsa - gr ou p- pa cin g or t im e r s pa cin g lsa - gr ou p.[ 13] I f t he
dat abase is very large ( 10,000 or m ore LSAs) , decreasing t he group pacing int erval is beneficial;
if t he dat abase is sm all, increasing t he int erval m ight be useful. The range of t he group pacing
t im er is 10 t o 1800 seconds.
[13]
Group pacing was introduced in IOS 11.3AA with the command timers lsa-group-pacing; beginning with IOS 12.2(4)T,
the command changed to timers pacing lsa-group.
LSA Types
Because of t he m ult iple rout er t ypes defined by OSPF, m ult iple t ypes of LSA are also necessary.
For exam ple, a DR m ust advert ise t he m ult i- access link and all t he rout ers at t ached t o t he link.
Ot her rout er t ypes would not advert ise t his t ype of inform at ion. Bot h Exam ple 8- 9 and Exam ple
8- 10 show t hat t here are m ult iple t ypes of LSAs. Each t ype describes a different aspect of an
OSPF net work. Table 8- 4 list s t he LSA t ypes and t he t ype codes t hat ident ify t hem .
Ta ble 8 - 4 . LSA t ype s.
Type
Code
D e scr ipt ion
1
Rout er LSA
2
Net work LSA
3
Net work Sum m ary LSA
4
ASBR Sum m ary LSA
5
AS Ext ernal LSA
6
Group Mem bership LSA
7
NSSA Ext ernal LSA
8
Ext ernal At t ribut es LSA
9
Opaque LSA ( link- local scope)
10
Opaque LSA ( area- local scope)
11
Opaque LSA ( AS scope)
Rout er LSAs are produced by every rout er (Figure 8- 19) . This m ost fundam ent al LSA list s all of a
rout er's links, or int erfaces, t he st at e and out going cost of each link, and any known OSPF
neighbors on t he link. These LSAs are flooded only wit hin t he area in which t hey are originat ed.
The com m and sh ow ip ospf da t a ba se r ou t e r will list all of t he Rout er LSAs in a dat abase.
Exam ple 8- 11 shows a variant of t he com m and, in which a single rout er LSA is observed by
specifying t he rout er's I D. As t his and t he subsequent illust rat ions show, t he com plet e LSA is
recorded in t he link- st at e dat abase. For a descript ion of all t he LSA fields, see t he " OSPF Packet
For m at s" sect ion lat er in t his chapt er.
Figu r e 8 - 1 9 . Th e Rou t e r LSA de scr ibe s a ll of a r ou t e r 's in t e r fa ce s.
Ex a m ple 8 - 1 1 . Th e com m a n d sh ow ip ospf da t a ba se r ou t e r displa ys
Rou t e r LSAs fr om t h e lin k - st a t e da t a ba se .
Homer#show ip ospf database router 192.168.30.10
OSPF Router with ID (192.168.30.50) (Process ID 1)
Router Link States (Area 0)
Routing Bit Set on this LSA
LS age: 680
Options: (No TOS-capability)
LS Type: Router Links
Link State ID: 192.168.30.10
Advertising Router: 192.168.30.10
LS Seq Number: 80001428
Checksum: 0x842A
Length: 60
Area Border Router
Number of Links: 3
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 192.168.30.80
(Link Data) Router Interface address: 192.168.17.9
Number of TOS metrics: 0
TOS 0 Metrics: 64
Link connected to: a Stub Network
(Link ID) Network/subnet number: 192.168.17.8
(Link Data) Network Mask: 255.255.255.248
Number of TOS metrics: 0
TOS 0 Metrics: 64
Link connected to: a Transit Network
(Link ID) Designated Router address: 192.168.17.18
(Link Data) Router Interface address: 192.168.17.17
Number of TOS metrics: 0
TOS 0 Metrics: 10
Homer#
One line you will not ice in Exam ple 8- 11 and in several subsequent LSA displays is t he st at em ent
" Rout ing Bit Set on t his LSA." The rout ing bit is not a part of t he LSA it self; it is an int ernal
m aint enance bit used by I OS indicat ing t hat t he rout e t o t he dest inat ion advert ised by t his LSA
is valid. So when you see " Rout ing Bit Set on t his LSA," it m eans t hat t he rout e t o t his
dest inat ion is in t he rout ing t able.
Net work LSAs are produced by t he DR on every m ult i- access net work (Figure 8- 20) . As
discussed earlier, t he DR represent s t he m ult i- access net work and all at t ached rout ers as a
pseudonode, or a single virt ual rout er. I n t his sense, a Net work LSA represent s a pseudonode
j ust as a Rout er LSA represent s a single physical rout er. The Net work LSA list s all at t ached
rout ers, including t he DR it self. Like Rout er LSAs, Net work LSAs are flooded only wit hin t he
originat ing area. I n Exam ple 8- 12, t he com m and sh ow ip ospf da t a ba se n e t w or k is used t o
observe a Net work LSA.
Figu r e 8 - 2 0 . A D R or igin a t e s a N e t w or k LSA t o r e pr e se n t a m u lt ia cce ss n e t w or k a n d a ll a t t a ch e d r ou t e r s.
Ex a m ple 8 - 1 2 . N e t w or k LSAs ca n be obse r ve d w it h t h e com m a n d sh ow
ip ospf da t a ba se n e t w or k .
Homer#show ip ospf database network 192.168.17.18
OSPF Router with ID (192.168.30.50) (Process ID 1)
Net Link States (Area 0)
Routing Bit Set on this LSA
LS age: 244
Options: (No TOS-capability)
LS Type: Network Links
Link State ID: 192.168.17.18 (address of Designated Router)
Advertising Router: 192.168.30.20
LS Seq Number: 800001BF
Checksum: 0x60AC
Length: 32
Network Mask: /29
Attached Router: 192.168.30.20
Attached Router: 192.168.30.10
Attached Router: 192.168.30.30
Homer#
Not ice t hat unlike t he Rout er LSA, t here is no m et ric field in t he Net work LSA. This is because, as
explained earlier in t his chapt er, t he cost from t he pseudonode represent ed by t he LSA t o any
at t ached rout er is always 0.
Net work Sum m ary LSAs are originat ed by ABRs. They are sent int o a single area t o advert ise
dest inat ions out side t hat area ( Figure 8- 21) . I n effect , t hese LSAs are t he m eans by which an
ABR t ells t he int ernal rout ers of an at t ached area what dest inat ions t he ABR can reach. An ABR
also advert ises t he dest inat ions wit hin it s at t ached areas int o t he backbone wit h Net work
Sum m ary LSAs. Default rout es ext ernal t o t he area, but int ernal t o t he OSPF aut onom ous
syst em , are also advert ised by t his LSA t ype. The com m and sh ow ip ospf da t a ba se su m m a r y
is used t o display t he net work sum m ary LSAs in t he dat abase, as shown in Exam ple 8- 13.
Figu r e 8 - 2 1 . An ABR w ill or igin a t e a N e t w or k Su m m a r y LSA t o de scr ibe
in t e r - a r e a de st in a t ion s.
Ex a m ple 8 - 1 3 . N e t w or k Su m m a r y LSAs ca n be obse r ve d w it h t h e
com m a n d sh ow ip ospf da t a ba se su m m a r y.
Homer#show ip ospf database summary 172.16.121.0
OSPF Router with ID (192.168.30.50) (Process ID 1)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA
LS age: 214
Options: (No TOS-capability)
LS Type: Summary Links(Network)
Link State ID: 172.16.121.0 (summary Network Number)
Advertising Router: 192.168.30.60
LS Seq Number: 800000B1
Checksum: 0xE864
Length: 28
Network Mask: /24
TOS: 0 Metric: 791
When an ABR originat es a Net work Sum m ary LSA, it includes t he cost from it self t o t he
dest inat ion t he LSA is advert ising. The ABR will originat e only a single Net work Sum m ary LSA for
each dest inat ion even if it knows of m ult iple rout es t o t he dest inat ion. Therefore, if an ABR
knows of m ult iple rout es t o a dest inat ion wit hin it s own at t ached area, it originat es a single
Net work Sum m ary LSA int o t he backbone wit h t he lowest cost of t he m ult iple rout es. Likewise, if
an ABR receives m ult iple Net work Sum m ary LSAs from ot her ABRs across t he backbone, t he
original ABR will choose t he lowest cost advert ised in t he LSAs and advert ise t hat one cost int o
it s at t ached non- backbone areas.
When anot her rout er receives a Net work Sum m ary LSA from an ABR, it does not run t he SPF
algorit hm . Rat her, it sim ply adds t he cost of t he rout e t o t he ABR and t he cost included in t he
LSA. A rout e t o t he advert ised dest inat ion, via t he ABR, is ent ered int o t he rout e t able along wit h
t he calculat ed cost . This behaviordepending on an int erm ediat e rout er inst ead of det erm ining t he
full rout e t o t he dest inat ionis dist ance vect or behavior. So, while OSPF is a link- st at e prot ocol
wit hin an area, it uses a dist ance vect or algorit hm t o find int er- area rout es. [ 14]
[14]
This distance vector behavior is the reason for requiring a backbone area and requiring that all inter-area traffic pass
through the backbone. By forming the areas into what is essentially a hub-and-spoke topology, the route loops to which
distance vector protocols are prone are avoided.
ASBR Sum m ary LSAs are also originat ed by ABRs. ASBR Sum m ary LSAs are ident ical t o Net work
Sum m ary LSAs except t hat t he dest inat ion t hey advert ise is an ASBR ( Figure 8- 22) , not a
net work. The com m and sh ow ip ospf da t a ba se a sbr - su m m a r y is used t o display ASBR
Sum m ary LSAs (Exam ple 8- 14) . Not e in t he illust rat ion t hat t he dest inat ion is a host address,
and t he m ask is zero; t he dest inat ion advert ised by an ASBR Sum m ary LSA will always be a host
address because it is a rout e t o a rout er.
Figu r e 8 - 2 2 . ASBR Su m m a r y LSAs a dve r t ise r ou t e s t o ASBRs.
Ex a m ple 8 - 1 4 . ASBR Su m m a r y LSAs ca n be obse r ve d w it h t h e
com m a n d sh ow ip ospf da t a ba se a sbr - su m m a r y.
Homer#show ip ospf database asbr-summary
OSPF Router with ID (192.168.30.50) (Process ID 1)
Summary ASB Link States (Area 0)
Routing Bit Set on this LSA
LS age: 1640
Options: (No TOS-capability)
LS Type: Summary Links (AS Boundary Router)
Link State ID: 192.168.30.12 (AS Boundary Router address)
Advertising Router: 192.168.30.20
LS Seq Number: 80000009
Checksum: 0xF450
Length: 28
Network Mask: /0
TOS: 0 Metric: 64
--More-
Aut onom ous Syst em Ext ernal LSAs, or Ext ernal LSAs, are originat ed by ASBRs. They advert ise
eit her a dest inat ion ext ernal t o t he OSPF aut onom ous syst em , or a default rout e [ 15] ext ernal t o
t he OSPF aut onom ous syst em ( Figure 8- 23) . Referring back t o Exam ple 8- 9, you can see t hat
t he AS Ext ernal LSAs are t he only LSA t ypes in t he dat abase t hat are not associat ed wit h a
part icular area; ext ernal LSAs are flooded t hroughout t he aut onom ous syst em . The com m and
sh ow ip ospf da t a ba se e x t e r n a l displays AS Ext ernal LSAs ( Exam ple 8- 15) .
[15]
Default routes are routes that are chosen if no more specific route exists in the route table. OSPF and RIP use an IP
address of 0.0.0.0 to identify a default route. See Chapter 12, "Default Routes and On-Demand Routing" for more
information.
Figu r e 8 - 2 3 . AS Ex t e r n a l LSAs a dve r t ise de st in a t ion s e x t e r n a l t o t h e
OSPF a u t on om ou s syst e m .
Ex a m ple 8 - 1 5 . AS Ex t e r n a l LSAs ca n be obse r ve d w it h t h e com m a n d
sh ow ip ospf da t a ba se e x t e r n a l.
Homer#show ip ospf database external 10.83.10.0
OSPF Router with ID (192.168.30.50) (Process ID 1)
AS External Link States
Routing Bit Set on this LSA
LS age: 1680
Options: (No TOS-capability)
LS Type: AS External Link
Link State ID: 10.83.10.0 (External Network Number)
Advertising Router: 192.168.30.60
LS Seq Number: 80000D5A
Checksum: 0x7A1C
Length: 36
Network Mask: /24
Metric Type: 1 (Comparable directly to link state metric)
TOS: 0
Metric: 10
Forward Address: 172.20.57.254
External Route Tag: 0
Homer#
Group Mem bership LSAs are used in an enhancem ent of OSPF known as Mult icast OSPF
( MOSPF) . [ 16] MOSPF rout es packet s from a single source t o m ult iple dest inat ions, or group
m em bers, which share a class D m ult icast address. Alt hough Cisco support s ot her m ult icast
rout ing prot ocols, MOSPF is not support ed as of t his writ ing. For t his reason, neit her MOSPF nor
t he Group Mem bership LSA is covered in t his book.
[16]
John Moy, "Multicast Extensions to OSPF," RFC 1584, March 1994.
NSSA Ext ernal LSAs are originat ed by ASBRs wit hin not - so- st ubby areas ( NSSAs) . NSSAs are
described in t he following sect ion. An NSSA Ext ernal LSA is alm ost ident ical t o an AS Ext ernal
LSA, as t he sect ion on OSPF packet form at s shows. Unlike AS Ext ernal LSAs, which are flooded
t hroughout an OSPF aut onom ous syst em , NSSA Ext ernal LSAs are flooded only wit hin t he not so- st ubby area in which it was originat ed. The com m and sh ow ip ospf da t a ba se n ssa e x t e r n a l displays NSSA Ext ernal LSAs (Exam ple 8- 16) .
Ex a m ple 8 - 1 6 . N SSA Ex t e r n a l LSAs ca n be obse r ve d w it h t h e com m a n d
sh ow ip ospf da t a ba se n ssa - e x t e r n a l.
Morisot#show ip ospf database nssa-external
OSPF Router with ID (10.3.0.1) (Process ID 1)
Type-7 AS External Link States (Area 15)
LS age: 532
Options: (No TOS-capability, No Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 10.0.0.0 (External Network Number)
Advertising Router: 10.3.0.1
LS Seq Number: 80000001
Checksum: 0x9493
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 100
Forward Address: 10.3.0.1
External Route Tag: 0
--More-
Ext ernal At t ribut es LSAs were proposed as an alt ernat ive t o running I nt ernal BGP ( iBGP) , t o
t ransport BGP inform at ion across an OSPF dom ain. This LSA has never been deployed on a wide
scale, and is not support ed in I OS.
Opaque LSAs are a class of LSAs t hat consist of a st andard LSA header followed by applicat ionspecific inform at ion. [ 17] The I nform at ion field can be used direct ly by OSPF or indirect ly by ot her
applicat ions t o dist ribut e inform at ion t hroughout t he OSPF dom ain. Opaque LSAs have been
used t o add various ext ensions t o OSPF, such as t raffic engineering param et ers for Mult iprot ocol
Label Swit ching ( MPLS) net works.
[17]
Rob Coltun, "The OSPF Opaque LSA Option," RFC 2370, July 1998.
Stub Areas
An ASBR learning ext ernal dest inat ions will advert ise t hose dest inat ions by flooding AS Ext ernal
LSAs t hroughout t he OSPF aut onom ous syst em . I n m any cases, t hese Ext ernal LSAs m ay m ake
up a large percent age of t he LSAs in t he dat abases of every rout er. For exam ple, Exam ple 8- 10
shows t hat 580 of t he LSAs in t hat dat abase40 percent are ext ernal LSAs.
I n Figure 8- 24, not every rout er needs t o know about all t he ext ernal dest inat ions. The rout ers
in area 2 m ust send a packet t o an ABR t o reach t he ASBR, no m at t er what t he ext ernal
dest inat ion m ight be. For t his reason, area 2 can be configured as a st ub area.
Figu r e 8 - 2 4 . M e m or y ca n be con se r ve d a n d pe r for m a n ce im pr ove d by
m a k in g a r e a 2 a st u b a r e a .
A st ub area is an area int o which AS Ext ernal LSAs are not flooded. And if t ype 5 LSAs are not
known inside an area, t ype 4 LSAs are unnecessary; t hese LSAs are also blocked. ABRs at t he
edge of a st ub area use Net work Sum m ary ( t ype 3) LSAs t o advert ise a single default rout e
( dest inat ion 0.0.0.0) int o t he area. Any dest inat ion t hat t he int ernal rout ers cannot m at ch t o an
int ra- or int er- area rout e will m at ch t he default rout e. Because t he default rout e is carried in
t ype 3 LSAs, it will not be advert ised out side of t he area.
The perform ance of rout ers wit hin a st ub area can be im proved, and m em ory conserved, by t he
reduced size of t heir dat abases. Of course, t he im provem ent will be m ore m arked in OSPF
dom ains wit h a large num ber of t ype 5 LSAs. There are, however, four rest rict ions on st ub
areas:
1 . As in any area, all rout ers in a st ub area m ust have ident ical link- st at e dat abases. To
ensure t his condit ion, all st ub rout ers will set a flag ( t he E- bit ) in t heir Hello packet s t o
zero; t hey will not accept any Hello from a rout er in which t he E- bit is set t o one. As a
result , adj acencies will not be est ablished wit h any rout er t hat is not configured as a st ub
rout er.
2 . Virt ual links cannot be configured wit hin, nor t ransit , a st ub area.
3 . No rout er wit hin a st ub area can be an ASBR. This rest rict ion is int uit ively underst andable
because ASBRs produce t ype 5 LSAs, and t ype 5 LSAs cannot exist wit hin a st ub area.
4 . A st ub area m ight have m ore t han one ABR, but because of t he default rout e, t he int ernal
4.
rout ers cannot det erm ine which rout er is t he opt im al gat eway t o t he ASBR.
Totally Stubby Areas
I f m em ory is saved by blocking t he propagat ion of t ype 5 and t ype 4 LSAs int o an area, wouldn't
m ore m em ory be saved by blocking t ype 3 LSAs? I n addressing t his quest ion, Cisco carries t he
concept of st ub areas t o it s logical conclusion wit h a schem e known as t ot ally st ubby areas.
Tot ally st ubby areas use a default rout e t o reach not only dest inat ions ext ernal t o t he
aut onom ous syst em but also all dest inat ions ext ernal t o t he area. The ABR of a t ot ally st ubby
area will block not only AS Ext ernal LSAs but also all Sum m ary LSAswit h t he except ion of a
single t ype 3 LSA t o advert ise t he default rout e.
Not-So-Stubby Areas
I n Figure 8- 25, a rout er wit h a few st ub net works m ust be at t ached t o t he OSPF dom ain via one
of t he area 2 rout ers. The rout er support s only RI P, so t he area 2 rout er will run RI P and
redist ribut e t he net works int o OSPF. Unfort unat ely, t his configurat ion m akes t he area 2 rout er
an ASBR, and t herefore area 2 can no longer be a st ub area.
Figu r e 8 - 2 5 . Be ca u se a fe w e x t e r n a l de st in a t ion s m u st be
r e dist r ibu t e d in t o OSPF a t on e of t h e a r e a 2 r ou t e r s, a ll of a r e a 2 is
in e ligible t o be a st u b a r e a .
The RI P speaker does not need t o learn rout es from OSPFa default rout e point ing t o t he area 2
rout er is all it needs. But all OSPF rout ers m ust know about t he net works at t ached t o t he RI P
rout er t o rout e packet s t o t hem .
Not - so- st ubby areas ( NSSAs) [ 18] allow ext ernal rout es t o be advert ised int o t he OSPF
aut onom ous syst em while ret aining t he charact erist ics of a st ub area t o t he rest of t he
aut onom ous syst em . To do t his, t he ASBR in an NSSA will originat e t ype 7 LSAs t o advert ise t he
ext ernal dest inat ions. These NSSA Ext ernal LSAs are flooded t hroughout t he NSSA but are
blocked at t he ABR.
[18]
Rob Coltun and Vince Fuller, "The OSPF NSSA Option," RFC 1587, March 1994.
The NSSA Ext ernal LSA has a flag in it s header known as t he P- bit . The NSSA ASBR has t he
opt ion of set t ing or clearing t he P- bit . I f t he NSSA's ABR receives a t ype 7 LSA wit h t he P- bit set
t o one, it will t ranslat e t he t ype 7 LSA int o a t ype 5 LSA and flood it t hroughout t he ot her areas
( see Figure 8- 26) . I f t he P- bit is set t o zero, no t ranslat ion will t ake place and t he dest inat ion in
t he t ype 7 LSA will not be advert ised out side of t he NSSA. This opt ion allows you t o design an
NSSA in which t he ext ernal dest inat ions learned in t hat area are known only in t hat area.
Figu r e 8 - 2 6 . An ASBR w it h in a n N SSA w ill or igin a t e N SSA Ex t e r n a l
LSAs. I f t h e P- bit of a n N SSA Ex t e r n a l LSA is se t , t h e ABR w ill t r a n sla t e
t h e LSA in t o a n AS Ex t e r n a l LSA.
NSSAs are support ed in I OS 11.2 and lat er.
Table 8- 5 sum m arizes which LSAs are allowed in which areas.
Ta ble 8 - 5 . LSA t ype s a llow e d pe r a r e a
t ype .
Ar e a Type
1&2
3
4
5
7
Backbone ( area
0)
Yes
Yes
Yes
Yes
No
Non- backbone,
non- st ub
Yes
Yes
Yes
Yes
No
St ub
Yes
Yes
No
No
No
Tot ally st ubby
Yes
No [ * ] No
No
No
Not - so- st ubby
Yes
Yes
No
Yes
[*]
Yes
Except for a single type 3 LSA per ABR, advertising the default route.
Route Table
The Dij kst ra algorit hm is used t o calculat e t he Short est Pat h Tree from t he LSAs in t he link st at e
dat abase. Chapt er 4 has a som ewhat det ailed discussion of t he Dij kst ra algorit hm ; for a full
descript ion of t he OSPF calculat ion of t he SPF t ree, see sect ion 16.1 of RFC 2328.
OSPF det erm ines t he short est pat h based on an arbit rary m et ric called cost , which is assigned t o
each int erface. The cost of a rout e is t he sum of t he cost s of all t he out going int erfaces t o a
dest inat ion. RFC 2328 does not specify any values for cost . Cisco rout ers calculat e a default
OSPF cost as 10 8 / BW, where BW is t he configured bandwidt h of t he int erface and 10 8 is t he
reference bandwidt h. As discussed previously, t he default reference bandwidt h can be changed
wit h t he com m and a u t o- cost r e fe r e n ce - ba n dw idt h. Fract ional cost s are rounded down t o t he
nearest whole num ber. Table 8- 6 shows t he default cost s calculat ed by t his form ula for som e
t ypical int erfaces.
Ta ble 8 - 6 . Cisco de fa u lt in t e r fa ce cost s.
I n t e r fa ce Type
Cost ( 1 0 8 / BW )
FDDI , Fast Et hernet , any int erface >
100M
1
HSSI ( 45M)
2
16M Token Ring
6
Et hernet
10
4M Token Ring
25
T1 ( 1.544M)
64
DS0 ( 64K) [ * ]
1562
56K [ * ]
1785
Tunnel ( 9K)
11111
[*]
Assumes the default bandwidth of the serial interface has been changed.
The com m and ip ospf cost can be used t o override t he default aut om at ic cost calculat ions and
assign a fixed cost t o an int erface. For exam ple, a large net work wit h hom ogeneous backbone
link speeds m ight assign link cost s based on line of sight or wire/ fiber dist ance. LSAs record cost
in a 16- bit field, so t he t ot al cost of an int erface can range from 1 t o 65535.
Destination Types
Each rout e ent ry is classified according t o a dest inat ion t ype. The dest inat ion t ype will be eit her
net work or rout er.
Net work ent ries are t he addresses of net works t o which packet s can be rout ed. These are t he
dest inat ions t hat are ent ered int o t he rout e t able ( Exam ple 8- 17) .
Ex a m ple 8 - 1 7 . Th e OSPF e n t r ie s in t h e r ou t e t a ble a r e n e t w or k
de st in a t ion t ype s.
Homer#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route
Gateway of last resort is 192.168.32.2 to network 0.0.0.0
O
O
O
O
E1
E1
E1
E2
192.168.118.0/24 [110/94] via 192.168.17.74, 02:15:01, Ethernet0
10.0.0.0/8 [110/84] via 192.168.17.41, 02:15:01, Serial0.19
192.168.119.0/24 [110/94] via 192.168.17.74, 02:15:01, Ethernet0
172.19.0.0/16 [110/21] via 192.168.32.2, 02:15:01, Ethernet1
172.21.0.0/16 is variably subnetted, 2 subnets, 2 masks
O E2
172.21.0.0/16 [110/801] via 192.168.21.6, 02:15:01, Serial1.724
O
172.21.121.0/24 [110/791] via 192.168.21.6, 04:18:30, Serial1.724
172.16.0.0/16 is variably subnetted, 104 subnets, 7 masks
O
172.16.21.48/30 [110/844] via 192.168.21.10, 04:18:48, Serial1.725
O IA
172.16.30.61/32 [110/856] via 192.168.17.74, 02:15:19, Ethernet0
O IA
172.16.35.0/24 [110/865] via 192.168.17.74, 02:15:19, Ethernet0
C
172.16.32.0/24 is directly connected, Ethernet1
O
172.16.17.48/29 [110/74] via 192.168.17.74, 06:19:46, Ethernet0
O E1
172.16.46.0/24 [110/30] via 192.168.32.2, 02:15:19, Ethernet1
O
172.16.45.0/24 [110/20] via 192.168.32.2, 3d10h, Ethernet1
O IA
172.16.30.54/32 [110/1061] via 192.168.17.74, 02:15:21, Ethernet0
O
172.16.17.56/29 [110/84] via 192.168.17.74, 06:19:48, Ethernet0
O
172.16.54.0/24 [110/11] via 192.168.32.2, 3d10h, Ethernet1
O
172.16.55.0/24 [110/11] via 192.168.32.2, 3d10h, Ethernet1
O
172.16.52.0/24 [110/11] via 192.168.32.2, 3d10h, Ethernet1
O
172.16.53.0/24 [110/11] via 192.168.32.2, 3d10h, Ethernet1
C
172.16.25.28/30 is directly connected, Tunnel29
--More-
Rout er ent ries are rout es t o ABRs and ASBRs. I f a rout er needs t o send a packet t o an int er- area
dest inat ion, it m ust know how t o find an ABR; if a packet m ust go t o an ext ernal dest inat ion, t he
rout er m ust know how t o find an ASBR. Rout er ent ries cont ain t his inform at ion, and are kept in a
separat e, int ernal rout e t able. This t able can be observed wit h t he com m and sh ow ip ospf
bor de r - r ou t e r s (Exam ple 8- 18) .
Ex a m ple 8 - 1 8 . Rou t e r e n t r ie s, k e pt in a se pa r a t e t a ble fr om n e t w or k
e n t r ie s, a r e r ou t e s t o ABRs a n d ASBRs.
Homer#show ip ospf border-routers
OSPF Process 1 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 192.168.30.10 [74] via 192.168.17.74, Ethernet0, ABR, Area 0, SPF 391
I 192.168.30.12 [148] via 192.168.17.74, Ethernet0, ASBR, Area 0, SPF 391
I 192.168.30.18 [205] via 192.168.17.74, Ethernet0, ASBR, Area 0, SPF 391
i 192.168.30.20 [84] via 192.168.17.74, Ethernet0, ABR, Area 0, SPF 391
i 192.168.30.27 [781] via 192.168.21.6, Serial1.724, ASBR, Area 7, SPF 631
i 192.168.30.30 [74] via 192.168.17.74, Ethernet0, ABR/ASBR, Area 0, SPF 391
I 192.168.30.38 [269] via 192.168.17.74, Ethernet0, ASBR, Area 0, SPF 391
i 192.168.30.37 [390] via 192.168.21.10, Serial1.725, ASBR, Area 7, SPF 631
i 192.168.30.40 [84] via 192.168.17.74, Ethernet0, ABR/ASBR, Area 0, SPF 391
i 192.168.30.47 [400] via 192.168.21.10, Serial1.725, ASBR, Area 7, SPF 631
i 192.168.30.50 [74] via 192.168.17.41, Serial0.19, ABR/ASBR, Area 0, SPF 391
I 192.168.30.62 [94] via 192.168.17.74, Ethernet0, ASBR, Area 0, SPF 391
i 192.168.30.60 [64] via 192.168.17.41, Serial0.19, ABR/ASBR, Area 0, SPF 391
i 192.168.30.60 [790] via 192.168.21.10, Serial1.725, ABR/ASBR, Area 7, SPF 631
i 192.168.30.80 [10] via 192.168.32.5, Ethernet1, ABR/ASBR, Area 78, SPF 158
i 192.168.30.80 [10] via 192.168.17.74, Ethernet0, ABR/ASBR, Area 0, SPF 391
i 172.20.57.254 [10] via 192.168.32.2, Ethernet1, ASBR, Area 78, SPF 158
Homer#
As Exam ple 8- 18 shows, t he int ernal rout e t able looks very sim ilar t o any ot her rout e t ablet here
are dest inat ions, m et rics, next - hop addresses, and exit int erfaces. The difference is t hat all
dest inat ions are t he Rout er I Ds of ABRs and ASBRs. Each ent ry is t agged as int ra- area ( i) or
int er- area ( I ) , and t he ent ry indicat es whet her t he dest inat ion is an ABR, an ASBR, or bot h. The
area is recorded, as is t he it erat ion of t he SPF algorit hm t hat inst alled t he ent ry.
Path Types
Each rout e t o a net work dest inat ion is also classified as one of four pat h t ypes. These pat h t ypes
are int ra- area, int er- area, t ype 1 ext ernal, and t ype 2 ext ernal:
I n t r a - a r e a pa t h s are t o dest inat ions wit hin one of t he rout er's at t ached areas.
I n t e r - a r e a pa t h s are t o dest inat ions in anot her area but wit hin t he OSPF aut onom ous
syst em . An int er- area pat h, t agged wit h an I A in Exam ple 8- 17, always passes t hrough at
least one ABR.
Type 1 e x t e r n a l pa t h s ( E1 in Exam ple 8- 17) are t o dest inat ions out side t he OSPF
aut onom ous syst em .
When an ext ernal rout e is redist ribut ed int o any aut onom ous syst em , it m ust be assigned a
m et ric t hat is m eaningful t o t he rout ing prot ocol of t he aut onom ous syst em . Wit hin OSPF,
t he ASBR is responsible for assigning a cost t o t he ext ernal rout es t hey advert ise. Type 1
ext ernal pat hs have a cost t hat is t he sum of t his ext ernal cost plus t he cost of t he pat h t o
t he ASBR. Configuring an ASBR t o advert ise an ext ernal ( redist ribut ed) rout e wit h an E1
m et ric is covered in Chapt er 11, " Rout e Redist ribut ion."
Type 2 e x t e r n a l pa t h s ( E2) are also t o dest inat ions out side t he OSPF aut onom ous
syst em , but do not t ake int o account t he cost of t he pat h t o t he ASBR.
E1 and E2 rout es provide t he net work adm inist rat or wit h t he opt ion of choosing whet her t he
int ernal cost t o t he ASBR is im port ant or whet her only t he ext ernal cost of an ext ernal rout e,
disregarding t he int ernal cost of reaching t he ASBR, is m ore im port ant . For exam ple, " hot
pot at o" rout ingget t ing packet s t o ext ernal dest inat ions out of t he net work at t he closest exit
point usually requires E1 m et rics, whereas if you want packet s t o exit your net work at t he closest
point t o t heir ext ernal dest inat ion, use E2 m et rics. OSPF ext ernal rout es are, by default , E2
pat hs.
I n Figure 8- 27, rout er A has t wo pat hs t o ext ernal dest inat ion 10.1.2.0. I f t he dest inat ion is
advert ised as E1, t he A- B- D pat h will have a cost of 35 ( 5 + 20 + 10) and will be preferred over
t he A- C- D pat h whose cost is 50 ( 30 + 10 + 10) . I f t he dest inat ion is advert ised as E2, t he cost
of t he t wo int ernal links t o t he ASBRs will be disregarded. I n t his case, t he A- B- D pat h has a cost
of 30 ( 20 + 10) and t he A- C- D pat h has a cost of 20 ( 10 + 10) . The lat t er will be t he preferred
pat h.
Figu r e 8 - 2 7 . I f t h e r ou t e t o e x t e r n a l n e t w or k 1 0 .1 .2 .0 is a dve r t ise d
w it h a n E1 m e t r ic, r ou t e r A w ill ch oose B a s t h e " close st " ASBR. I f t h e
de st in a t ion is a dve r t ise d w it h a n E2 m e t r ic, C w ill be ch ose n a s t h e
ASBR.
Route Table Lookups
When an OSPF rout er exam ines t he dest inat ion address of a packet , it t akes t he following st eps
t o select t he best rout e: [ 19]
[19]
The lookup procedure described here adheres to RFC 2328. The earlier OSPF RFCs specify creating a set of matching
routes first, then choosing the preferred path type, and choosing the longest match last.
1 . Select t he rout e or rout es wit h t he m ost specific m at ch t o t he dest inat ion address. For
exam ple, if t here are rout e ent ries for 172.16.64.0/ 18, 172.16.64.0/ 24, and
172.16.64.192/ 27, and t he dest inat ion address is 172.16.64.205, t he last ent ry will be
chosen. The m ost specific m at ch should always be t he longest m at cht he rout e wit h t he
longest address m ask. The ent ries m ay be host , subnet , net work, supernet , or default
addresses. I f no m at ch can be found, an I CMP Dest inat ion Unreachable m essage will be
sent t o t he source address and t he packet will be dropped.
2 . Prune t he set of select ed ent ries by elim inat ing less- preferred pat h t ypes. Pat h t ypes are
priorit ized in t he following order, wit h 1 being t he m ost preferred and 4 being t he least
preferred:
1. I nt ra- area pat hs
2. I nt er- area pat hs
3. E1 ext ernal pat hs
4. E2 ext ernal pat hs
I f m ult iple equal- cost , equal- pat h- t ype rout es exist in t he final set , OSPF ut ilizes t hem . By
default , t he Cisco OSPF im plem ent at ion load balances over a m axim um of 16 equal- cost pat hs
( four in older versions of I OS) ; t his num ber can be changed wit hin t he range of one t o six wit h
t he com m and m a x im u m - pa t h s.[ 20]
[20]
As this edition is being produced, Cisco is increasing the maximum supported by the maximum-paths command from 6
to 16.
Authentication
OSPF has t he capabilit y of aut hent icat ing all packet s exchanged bet ween neighbors.
Aut hent icat ion m ay be by sim ple passwords or by MD5 crypt ographic checksum s. These
aut hent icat ion m et hods are discussed in Chapt er 6, " RI Pv2, RI Png, and Classless Rout ing," and
exam ples of configuring OSPF aut hent icat ion are given in t he configurat ion sect ion.
OSPF over Demand Circuits
OSPF sends Hellos every 10 seconds and refreshes it s LSAs every 30 m inut es. These funct ions
m aint ain t he neighbor relat ionships, ensure t hat t he link- st at e dat abases are accurat e, and use
less bandwidt h t han t radit ional dist ance vect or prot ocols such as RI P. However, even t his
m inim al t raffic is undesirable on dem and circuit susage- sensit ive connect ions such as X.25 SVCs,
I SDN, and dialup lines. The recurring charges for such links m ay be det erm ined by connect t im e
or t raffic volum e or bot h, t hus m ot ivat ing t he net work m anager t o m inim ize t heir upt im e.
An enhancem ent t hat m akes OSPF pract ical over dem and circuit s is t he capabilit y of suppressing
t he Hello and LSA refresh funct ions so t hat a link does not have t o be const ant ly up. [ 21]
Alt hough t his enhancem ent is designed specifically for usage- sensit ive circuit s, it m ight be useful
on any bandwidt h- lim it ed link. [ 22]
[21]
[22]
John Moy, "Extending OSPF to Support Demand Circuits," RFC 1793, April 1995.
Although OSPF over demand circuits may be configured on any interface, Hellos are not suppressed on multi-access
network types; doing so would prevent the DR processes from functioning properly. As a result, the enhancement is really
useful only on point-to-point and point-to-multipoint network types.
OSPF over dem and circuit s brings up a dem and link t o perform t he init ial dat abase
synchronizat ion and subsequent ly brings up t he link t o flood only LSAs in which cert ain changes
have occurred. These LSA changes are
A change in t he LSA Opt ions field.
A new inst ance of an exist ing LSA is received in which t he age is MaxAge.
A change in t he Lengt h field of t he LSA header.
A change in t he cont ent s of t he LSA, excluding t he 20- oct et header, t he checksum , or t he
sequence num ber.
Because no periodic Hellos are exchanged ( Hellos are used only t o bring up t he link) , OSPF m ust
m ake a presum pt ion of reachabilit y. That is, it m ust presum e t hat t he dem and circuit will be
available when needed. I n som e inst ances, however, t he link m ight not be im m ediat ely
accessible. For exam ple, a dialup link m ight be in use, bot h B channels of a BRI link m ight be in
use, or t he m axim um num ber of allowed X.25 SVCs m ay already be up. I n t hese sit uat ions,
where t he link is unavailable not because it is down but because of norm al operat ional
charact erist ics, t he link is oversubscribed.
OSPF will not report an oversubscribed dem and link as down, and packet s rout ed t o an
oversubscribed link will be dropped rat her t han being queued. This behavior m akes sense
because t here is no way t o predict when t he link will again becom e available; a st ream of
packet s t o an unavailable int erface could overflow t he buffers.
Several changes t o t he int erface and neighbor st at e m achines and t o t he flooding procedure
m ust be m ade t o support OSPF over dem and circuit s ( see RFC 1793 for m ore det ails) . Wit hin t he
LSA form at , t wo changes are m ade.
First , if LSAs are not periodically refreshed across a dem and circuit , no rout ers on t he ot her side
of t he link should declare t he LSA invalid aft er MaxAge. The sem ant ics of t he LSA's Age field are
changed t o accom plish t his by designat ing t he high bit as t he DoNot Age bit . When an LSA is
flooded over a dem and circuit , t he t ransm it t ing rout er will set DoNot Age = 1. As t he LSA is
flooded t o all rout ers on t he ot her side of t he link, t he Age field will be increm ent ed norm ally by
I nfTransDelay seconds.[ 23] However, aft er being inst alled in a dat abase, an LSA will not be aged
like t he ot her LSAs.
[23]
Note that this means MaxAge will actually be MaxAge + DoNotAge.
The second change derives from t he first change. Because all rout ers m ust be capable of
correct ly int erpret ing t he DoNot Age bit , a new flag known as t he Dem and Circuit bit ( DC- bit ) is
added t o all LSAs. By set t ing t his flag in all LSAs it originat es, a rout er signals t o t he ot her
rout ers t hat it is capable of support ing OSPF over dem and circuit s.
A peripheral benefit of t he enhancem ent s m ade by OSPF over Dem and Circuit snam ely,
designat ing t he high bit of t he Age field as t he DoNot Age bit is t hat you can now reduce flooding
in st able t opologies. Wit h t he com m and ip ospf flood- r e du ct ion ent ered for an int erface, t he
DoNot Age bit is set on LSAs advert ised out t he int erface and t he LSAs are not refreshed unless
t hey change.
OSPF Packet Formats
The OSPF packet consist s of m ult iple encapsulat ions, and deconst ruct ing one is like peeling an
onion. As shown in Figure 8- 28, t he out side of t he onion is t he I P header. Encapsulat ed wit hin
t he I P header is one of five OSPF packet t ypes. Each packet t ype begins wit h an OSPF packet
header, whose form at is t he sam e for all packet t ypes. The OSPF packet dat a following t he
header varies according t o t he packet t ype. Each packet t ype has a num ber of t ype- specific
fields, followed by m ore dat a. The dat a cont ained in a Hello packet is a list of neighbors. LS
Request packet s cont ain a series of fields describing t he request ed LSAs. LS Updat e packet s
cont ain a list of LSAs, as shown in Figure 8- 28. These LSAs in t urn have t heir own headers and
t ype- specific dat a fields. Dat abase Descript ion and LS Acknowledgm ent packet s cont ain a list of
LSA headers.
Figu r e 8 - 2 8 . An OSPF pa ck e t is com pose d of a se r ie s of
e n ca psu la t ion s.
Not e t hat OSPF packet s are exchanged only bet ween neighbors on a net work. They are never
rout ed beyond t he net work on which t hey originat e.
Figure 8- 29 shows an analyzer capt ure of an I P header for a packet carrying OSPF dat a,
indicat ed by t he prot ocol num ber of 89. When OSPF packet s are m ult icast , t heir TTL is set t o 1,
as can be seen here. Because an OSPF packet should never be rout ed past an im m ediat e
neighbor, set t ing t he TTL t o 1 helps t o ensure t hat t he packet never t ravels m ore t han a single
hop. Som e rout ers run processes t hat priorit ize packet s according t o t he Precedence bit s
( Weight ed Fair Queuing and Weight ed Random Early Det ect ion, for exam ple) . OSPF set s t he
Precedence bit s t o I nt ernet work Cont rol ( 110b) , as shown in Figure 8- 29, so t hat t hese
processes will give a high priorit y t o OSPF packet s.
Figu r e 8 - 2 9 . OSPF u se s a pr ot ocol n u m be r of 8 9 . I t a lso se t s t h e TTL
va lu e in t h e I P h e a de r t o 1 a n d t h e Pr e ce de n ce bit s t o I n t e r n e t w or k
Con t r ol.
[View full size image]
This sect ion det ails t he five OSPF packet t ypes, beginning wit h t he header. The following sect ion
det ails t he LSA t ypes. An Opt ions field is carried in Hello, Dat abase Descript ion packet s, and in
all LSAs. The form at of t his field is t he sam e in all cases and is det ailed in it s own sect ion.
Packet Header
All OSPF packet s begin wit h a 24- oct et header, as shown in Figure 8- 30.
Figu r e 8 - 3 0 . Th e OSPF pa ck e t h e a de r .
V e r sion is t he OSPF version num ber. The OSPF version num ber is 2. There is an OSPF
version 3, creat ed for rout ing I Pv6; OSPFv3 is covered in t he next chapt er.
Type specifies t he packet t ype following t he header. Table 8- 7 list s t he five packet t ypes by
t he num ber appearing in t he Type field.
Ta ble 8 - 7 . OSPF pa ck e t t ype s.
Type Code
D e scr ipt ion
1
Hello
2
Dat abase Descript ion
3
Link St at e Request
4
Link St at e Updat e
5
Link St at e
Acknow ledgm ent
Pa ck e t le n gt h is t he lengt h of t he OSPF packet , in oct et s, including t he header.
Rou t e r I D is t he I D of t he originat ing rout er.
Ar e a I D is t he area from which t he packet originat ed. I f t he packet is sent over a virt ual
link, t he Area I D will be 0.0.0.0, t he backbone Area I D, because virt ual links are considered
part of t he backbone.
Ch e ck su m is a st andard I P checksum of t he ent ire packet , including t he header.
Au Ty p e is t he aut hent icat ion m ode being used.
Table 8- 8 list s t he possible aut hent icat ion m odes.
Ta ble 8 - 8 . OSPF a u t h e n t ica t ion t ype s.
Au Ty p e
Au t h e n t ica t ion Type
0
Null ( no aut hent icat ion)
1
Sim ple ( clear t ext ) Password
Aut hent icat ion
2
Crypt ographic ( MD5) Checksum
Au t h e n t ica t ion is t he inform at ion necessary for t he packet t o be aut hent icat ed by
what ever m ode is specified in t he AuType field. I f AuType = 0, t he field is not exam ined
and t herefore m ay cont ain anyt hing. I f AuType = 1, t he field cont ains a password of up t o
64 bit s. I f AuType = 2, t he Aut hent icat ion field cont ains a Key I D, t he Aut hent icat ion Dat a
Lengt h, and a nondecreasing Crypt ographic sequence num ber. The m essage digest is
appended t o t he end of t he OSPF packet , and is not considered part of t he packet it self.
Ke y I D ident ifies t he aut hent icat ion algorit hm and t he secret key used t o creat e t he
m essage digest .
Au t h e n t ica t ion D a t a Le n gt h specifies t he lengt h, in oct et s, of t he m essage digest
appended t o t he end of t he packet .
Cr ypt ogr a ph ic Se qu e n ce N u m be r is a nondecreasing num ber used t o prevent replay
at t acks.
Hello Packet
The Hello packet (Figure 8- 31) est ablishes and m aint ains adj acencies. The Hello carries
param et ers on which neighbors m ust agree in order t o form an adj acency.
Figu r e 8 - 3 1 . Th e OSPF H e llo pa ck e t .
N e t w or k M a sk is t he address m ask of t he int erface from which t he packet was sent . I f
t his m ask does not m at ch t he m ask of t he int erface on which t he packet is received, t he
packet will be dropped. This t echnique ensures t hat rout ers becom e neighbors only if t hey
agree on t he exact address of t heir shared net work.
H e llo I n t e r va l, as discussed earlier, is t he period, in seconds, bet ween t ransm issions of
Hello packet s on t he int erface. I f t he sending and receiving rout ers don't have t he sam e
value for t his param et er, t hey do not est ablish a neighbor relat ionship.
Op t ion s are described in " Opt ions Field," lat er in t his chapt er. This field is included in t he
Hello packet t o ensure t hat neighbors have com pat ible capabilit ies. A rout er m ight rej ect a
neighbor because of a capabilit ies m ism at ch.
Rou t e r Pr ior it y is used in t he elect ion of t he DR and BDR. I f set t o zero, t he originat ing
rout er is ineligible t o becom e t he DR or BDR.
Rou t e r D e a d I n t e r va l is t he num ber of seconds t he originat ing rout er will wait for a Hello
from a neighbor before declaring t he neighbor dead. I f a Hello is received in which t his
num ber does not m at ch t he Rout erDeadI nt erval of t he receiving int erface, t he packet is
dropped. This t echnique ensures t hat neighbors agree on t his param et er.
D e sign a t e d Rou t e r is t he I P address of t he int erface of t he DR on t he net work ( not it s
Rout er I D) . During t he DR elect ion process, t his m ay only be t he originat ing rout er's idea of
t he DR, not t he finally elect ed DR. I f t here is no DR ( because one has not been elect ed or
because t he net work t ype does not require DRs) , t his field is set t o 0.0.0.0.
Ba ck u p D R is t he I P address of t he int erface of t he BDR on t he net work. Again, during t he
DR elect ion process, t his m ay only be t he originat ing rout er's idea of t he BDR. I f t here is no
BDR, t his field is set t o 0.0.0.0.
N e igh bor is a recurring field t hat list s all RI Ds of all neighbors on t he net work from which
t he originat ing rout er has received a valid Hello in t he past Rout erDeadI nt erval.
Database Description Packet
The Dat abase Descript ion packet ( Figure 8- 32) is used when an adj acency is being est ablished
( see " Building an Adj acency," earlier in t his chapt er) . The prim ary purpose of t he DD packet is t o
describe som e or all of t he LSAs in t he originat or's dat abase so t hat t he receiver can det erm ine
whet her it has a m at ching LSA in it s own dat abase. This is done by list ing t he headers of t he
LSAs; t he LSA header cont ains enough inform at ion t o ident ify not only a part icular LSA but also
t he m ost recent inst ance of t hat LSA. Because m ult iple DD packet s m ay be exchanged during
t he dat abase descript ion process, flags are included for m anaging t he exchange via a
m ast er/ slave polling relat ionship.
Figu r e 8 - 3 2 . Th e OSPF D a t a ba se D e scr ipt ion pa ck e t .
I n t e r fa ce M TU is t he size, in oct et s, of t he largest I P packet t hat can be sent out t he
originat or's int erface wit hout fragm ent at ion. This field is set t o 0x0000 when t he packet is
sent over virt ual links.
Op t ion s are described in " Opt ions Field," lat er in t his chapt er. The field is included in t he
Dat abase Descript ion packet so t hat a rout er m ay choose not t o forward cert ain LSAs t o a
neighbor t hat doesn't support t he necessary capabilit ies.
The first five bit s of t he next oct et are unused and are always set t o 00000b.
I - b it , or I nit ial bit , is set t o 1 when t he packet is t he init ial packet in series of DD packet s.
Subsequent DD packet s have I - bit = 0.
M - bit , or More bit , is set t o 1 t o indicat e t hat t he packet is not t he last in a series of DD
packet s. The last DD packet has M- bit = 0.
M S- bit , or Mast er/ Slave bit , is set t o 1 t o indicat e t hat t he originat or is t he m ast er ( t hat is,
is in cont rol of t he polling process) during a dat abase synchronizat ion. The slave has MS- bit
= 0.
D D Se qu e n ce N u m be r ensures t hat t he full sequence of DD packet s is received in t he
dat abase synchronizat ion process. The sequence num ber is set by t he m ast er t o som e
unique value in t he first DD packet , and t he sequence is increm ent ed in subsequent
packet s.
LSA H e a de r s list som e or all of t he headers of t he LSAs in t he originat or's link- st at e
dat abase. See t he sect ion " Link St at e Header," for a full descript ion of t he LSA header; t he
header cont ains enough inform at ion t o uniquely ident ify t he LSA and t he part icular inst ance
of t he LSA.
Link State Request Packet
As Dat abase Descript ion packet s are received during t he dat abase synchronizat ion process, a
rout er t akes not e of any list ed LSAs t hat are not in it s dat abase or are m ore recent t han it s own
LSA. These LSAs are recorded in t he Link St at e Request list . The rout er t hen sends one or m ore
Link St at e Request packet s (Figure 8- 33) asking t he neighbor for it s copy of t he LSAs on t he Link
St at e Request list . Not e t hat t he packet uniquely ident ifies t he LSA by Type, I D, and Advert ising
Rout er fields of it s header, but it does not request a specific inst ance of t he LSA ( ident ified by
t he header's sequence num ber, checksum , and age) . Therefore, t he request is for t he m ost
recent inst ance of t he LSA, whet her t he request er is aware of t hat inst ance or not . This
procedure prot ect s against a sit uat ion in which t he neighbor m ight acquire or originat e a m ore
recent copy of t he LSA bet ween t he t im e it last described t he LSA and t he t im e a copy of it is
request ed.
Figu r e 8 - 3 3 . Th e OSPF Lin k St a t e Re qu e st pa ck e t .
Lin k St a t e Type is t he LS t ype num ber, which ident ifies t he LSA as a Rout er LSA, Net work
LSA, and so on. Type num bers are list ed in Table 8- 4.
Lin k St a t e I D is a t ype- dependent field of t he LSA header. See t he sect ion " Link St at e
Header" and t he LSA- specific sect ions for a full descript ion of how t he various LSAs use t his
field.
Adve r t isin g Rou t e r is t he Rout er I D of t he rout er t hat originat ed t he LSA.
Link State Update Packet
The Link St at e Updat e packet , shown in Figure 8- 34, is used in t he flooding of LSAs and t o send
LSAs in response t o Link St at e Request s. Recall t hat OSPF packet s do not leave t he net work on
which t hey were originat ed. Consequent ly, a Link St at e Updat e packet , carrying one or m any
LSAs, carries t he LSAs only t o t he originat ing rout er's connect ed neighbors. The receiving
neighbor is responsible for re- encapsulat ing t he appropriat e LSAs in new LS Updat e packet s for
furt her flooding t o it s own neighbors.
Figu r e 8 - 3 4 . Th e OSPF Lin k St a t e Upda t e pa ck e t .
N u m be r of LSAs specifies t he num ber of LSAs included in t his packet .
LSAs are t he full LSAs as described in OSPF LSA form at s. Each updat e can carry m ult iple
LSAs, up t o t he m axim um packet size allowed on t he link.
Link State Acknowledgment Packet
Link St at e Acknowledgm ent packet s are used t o m ake t he flooding of LSAs reliable. Each LSA
received by a rout er from a neighbor m ust be explicit ly acknowledged in a Link St at e
Acknowledgem ent packet . The LSA being acknowledged is ident ified by including it s header in
t he LS ACK packet , and m ult iple LSAs can be acknowledged in a single packet . As Figure 8- 35
shows, t he LS ACK packet consist s of not hing m ore t han an OSPF packet header and a list of LSA
headers.
Figu r e 8 - 3 5 . Th e OSPF Lin k St a t e Ack n ow le dgm e n t pa ck e t .
OSPF LSA Formats
This sect ion det ails t he fields of LSA t ypes 1- 5 and 7. The Group Mem bership LSA ( t ype 6) is not
discussed because MOSPF is not covered in t his book. Sim ilarly, LSA t ypes 8 t hrough 11 are not
covered because t hey eit her are not in general deploym ent ( t ype 8) or because t hey are used t o
support capabilit ies t hat are out side of t he scope of t his book.
LSA Header
The LSA header ( Figure 8- 36) begins all LSAs and is also used by it self in Dat abase Descript ion
and Link St at e Acknowledgm ent packet s. Three fields in t he header uniquely ident ify every LSA:
t he Type, Link St at e I D, and Advert ising Rout er. Addit ionally, t hree ot her fields uniquely ident ify
t he m ost recent inst ance of an LSA: t he Age, Sequence Num ber, and Checksum .
Figu r e 8 - 3 6 . Th e OSPF LSA h e a de r .
Age is t he t im e, in seconds, since t he LSA was originat ed. As t he LSA is flooded, t he age is
increm ent ed by I nfTransDelay seconds at each rout er int erface it exit s. The age is also
increm ent ed in seconds as it resides in a link- st at e dat abase.
Op t ion s is described in t he sect ion "Opt ions Field." I n t he LSA header, t he Opt ions field
specifies t he opt ional capabilit ies support ed by t he port ion of t he OSPF dom ain described
by t he LSA.
Type is t he LSA t ype. The t ype codes are shown in Table 8- 4.
Lin k St a t e I D ident ifies t he port ion of t he OSPF dom ain being described by t he LSA. The
specific usage of t his field varies according t o t he LSA t ype; t he descript ions of each LSA
include a descript ion of how t he LSA uses t his field.
Adve r t isin g Rou t e r is t he rout er I D of t he rout er t hat originat ed t he LSA.
Se qu e n ce N u m be r is increm ent ed each t im e a new inst ance of t he LSA is originat ed, so
t hat ot her rout ers can ident ify t he m ost recent inst ance of t he LSA.
Ch e ck su m is t he Flet cher checksum of t he com plet e cont ent s of t he LSA except for t he
Age field. I f t he Age field were included, t he checksum would have t o be recalculat ed every
t im e t he age was increm ent ed.
Le n g t h is t he num ber of oct et s of t he LSA, including t he header.
Router LSA
A Rout er LSA ( Figure 8- 37) is produced by every rout er. I t list s a rout er's links, or int erfaces,
along wit h t he st at e and t he out going cost of each link and any known neighbors on t he link.
These LSAs are flooded only wit hin t he area in which t hey are originat ed. The com m and sh ow
ip ospf da t a ba se r ou t e r ( refer t o Exam ple 8- 11) list s t he Rout er LSAs in a dat abase. Not e t hat
Rout er LSAs advert ise host rout es as st ub net works; t he Link I D field carries t he host I P
address, and t he Link Dat a field carries t he host address m ask of 255.255.255.255.
Figu r e 8 - 3 7 . OSPF Rou t e r LSA.
Lin k St a t e I D for Rout er LSAs is t he originat ing rout er's Rout er I D.
V, or Vir t u a l Lin k En dpoin t bit , is set t o one when t he originat ing rout er is an endpoint of
one or m ore fully adj acent virt ual links having t he described area as t he t ransit area.
E, or Ex t e r n a l bit , is set t o one when t he originat ing rout er is an ASBR.
B, or Bor de r bit , is set t o one when t he originat ing rout er is an ABR.
N u m be r of Lin k s specifies t he num ber of rout er links t he LSA describes. The Rout er LSA
m ust describe all of t he originat ing rout er's links, or int erfaces, t o t he area in which t he LSA
is flooded.
Subsequent fields in t he Rout er LSA describe each link and appear one or m ore t im es,
corresponding t o t he num ber in t he Num ber of Links field. This discussion covers t he Link
Type field first , alt hough t hat field does not appear unt il aft er t he Link Dat a field.
Underst anding link t ype first is im port ant because t he descript ions of t he Link I D and Link
Dat a fields vary according t o t he value of t he Link Type field.
Lin k Type describes t he general t ype of connect ion t he link provides. Table 8- 9 list s t he
possible values of t he field and t he associat ed connect ion t ypes.
Ta ble 8 - 9 . Lin k t ype va lu e s.
Lin k Type
Con n e ct ion
1
Point - t o- point connect ion t o anot her
rout er
2
Connect ion t o a t ransit net work
Lin k Type
Con n e ct ion
3
Connect ion t o a st ub net work
4
Virt ual link
Lin k I D ident ifies t he obj ect t o which t he link connect s. This is dependent on t he link t ype,
as shown in Table 8- 10 . Not e t hat when t he connect ed obj ect is anot her rout er, t he Link I D
is t he sam e as t he Link St at e I D in t he header of t he neighboring rout er's LSA. During t he
rout ing t able calculat ion, t his value is used t o find t he neighbor's LSA in t he link- st at e
dat abase.
Ta ble 8 - 1 0 . Lin k I D va lu e s.
Lin k
Type
Va lu e of Lin k I D Fie ld
1
Neighboring rout er's Rout er I D
2
I P address of t he DR's int erface
3
I P net work or subnet address
4
Neighboring rout er's Rout er I D
Lin k D a t a also depends on t he value of t he Link Type field, as shown in Table 8- 11 .
Ta ble 8 - 1 1 . Lin k da t a va lu e s.
Lin k Type
Va lu e of Lin k D a t a Fie ld
1
I P address of t he originat ing rout er's int erface t o t he
net work [ * ]
2
I P address of t he originat ing rout er's int erface t o t he
net work
3
Net work's I P address or subnet m ask
4
The MI B- I I ifI ndex value for t he originat ing rout er's
int erface
[*]
If the point-to-point link is unnumbered, this field will instead carry the MIB-II ifIndex value of the interface.
N u m be r of TOS specifies t he num ber of Type of Service m et rics list ed for t his link.
Alt hough TOS is no longer support ed in RFC 2328, t he TOS fields are st ill included for
backward com pat ibilit y wit h earlier OSPF im plem ent at ions. I f no TOS m et rics are
associat ed wit h a link, t his field is set t o 0x00.
M e t r ic is t he cost of t he link ( int erface) .
The next t wo fields are associat ed wit h a link corresponding t o t he num ber ( # ) of TOS field.
For exam ple, if # of TOS = 3, t here will be t hree 32- bit words cont aining t hree inst ances of
t hese fields. I f # of TOS = 0, t here will be no inst ances of t hese fields.
Not e t hat Cisco support s only TOS = 0.
TOS specifies t he Type of Service t o which t he following m et ric refers. [ 24] Table 8- 12 list s
t he TOS values ( as specified in RFC 1349) , t he bit values of t he corresponding TOS field in
t he I P header, and t he corresponding value used in t he OSPF TOS field.
[24]
Philip Almquist, "Type of Service in the Internet Protocol Suite," RFC 1349, July 1992.
Ta ble 8 - 1 2 . OSPF TOS va lu e s.
RFC TOS Va lu e
I P H e a de r TOS Fie ld
OSPF TOS En codin g
Norm al Service
0000
0
Minim ize Monet ary
Cost
0001
2
Maxim ize Reliabilit y
0010
4
Maxim ize Throughput
0100
8
Minim ize Delay
1000
16
TOS M e t r ic is t he m et ric associat ed wit h t he specified TOS value.
Network LSA
Net work LSAs ( Figure 8- 38) are originat ed by DRs. These LSAs advert ise t he m ult i- access
net work, and all rout ers ( including t he DR) at t ached t o t he net work. Like Rout er LSAs, Net work
LSAs are flooded only wit hin t he originat ing area. The com m and sh ow ip ospf da t a ba se
n e t w or k (Exam ple 8- 12) is used t o observe a Net work LSA.
Figu r e 8 - 3 8 . Th e OSPF N e t w or k LSA.
Lin k St a t e I D for Net work LSAs is t he I P address of t he DR's int erface t o t he net work.
N e t w or k M a sk specifies t he address or subnet m ask used on t his net work.
At t a ch e d Rou t e r list s t he Rout er I Ds of all rout ers on t he m ult i- access net work t hat are
fully adj acent wit h t he DR, and t he Rout er I D of t he DR it self. The num ber of inst ances of
t his field ( and hence t he num ber of rout ers list ed) can be deduced from t he LSA header's
Lengt h field.
Network and ASBR Summary LSAs
The Net work Sum m ary LSA ( t ype 3) and t he ASBR Sum m ary LSA ( t ype 4) have an ident ical
form at , shown in Figure 8- 39. The only difference in field cont ent s is t he Type and t he Link St at e
I D. ABRs produce bot h t ypes of Sum m ary LSA; Net work Sum m ary LSAs advert ise net works
ext ernal t o an area ( including default rout es) , whereas ASBR Sum m ary LSAs advert ise ASBRs
ext ernal t o an area. Bot h t ypes are flooded only int o a single area. The Net work Sum m ary LSAs
in a rout er's dat abase can be observed wit h t he com m and sh ow ip ospf da t a ba se su m m a r y
( Exam ple 8- 13) , and ASBR Sum m ary LSAs can be observed wit h sh ow ip ospf da t a ba se a sbr su m m a r y (Exam ple 8- 14) .
Figu r e 8 - 3 9 . Th e OSPF Su m m a r y LSA. Th e for m a t is t h e sa m e for bot h
t ype 3 a n d t ype 4 Su m m a r y LSAs.
Lin k St a t e I D , for t ype 3 LSAs, is t he I P address of t he net work or subnet being
advert ised. I f t he LSA is t ype 4, t he Link St at e I D is t he Rout er I D of t he ASBR being
advert ised.
N e t w or k M a sk is t he address or subnet m ask of t he net work being advert ised in t ype 3
LSAs. I n t ype 4 LSAs, t his field has no m eaning and is set t o 0.0.0.0.
I f a t ype 3 LSA is advert ising a default rout e, bot h t he Link St at e I D and t he Net work Mask
fields will be 0.0.0.0.
M e t r ic is t he cost of t he rout e t o t his dest inat ion.
The TOS and TOS Met ric fields are opt ional and are described in "Rout er LSA." Again, Cisco
support s only TOS = 0.
Autonomous System External LSA
Aut onom ous Syst em Ext ernal LSAs ( Figure 8- 40) are originat ed by ASBRs. These LSAs are used
t o advert ise dest inat ions ext ernal t o t he OSPF aut onom ous syst em , including default rout es t o
ext ernal dest inat ions, and are flooded int o all nonst ub areas of t he OSPF dom ain. The com m and
sh ow ip ospf da t a ba se e x t e r n a l is used t o display AS Ext ernal LSAs ( Exam ple 8- 15) .
Figu r e 8 - 4 0 . Th e OSPF Au t on om ou s Syst e m Ex t e r n a l LSA.
Lin k St a t e I D for AS Ext ernal LSAs is t he I P address of t he dest inat ion.
N e t w or k M a sk is t he address or subnet m ask for t he dest inat ion being advert ised.
I f t he t ype 5 LSA is advert ising a default rout e, t he Link St at e I D and t he Net work Mask are
bot h 0.0.0.0.
E, or Ex t e r n a l M e t r ic bit , specifies t he t ype of ext ernal m et ric t o be used wit h t his rout e.
I f t he E- bit is set t o 1, t he m et ric t ype is E2. I f t he E- bit = 0, t he m et ric t ype is E1. See t he
sect ion " Pat h Types," earlier in t his chapt er, for m ore inform at ion on E1 and E2 ext ernal
m et rics.
M e t r ic is t he cost of t he rout e, as set by t he ASBR.
For w a r din g Addr e ss is t he address t o which packet s for t he advert ised dest inat ion should
be forwarded. I f t he forwarding address is 0.0.0.0, packet s are forwarded t o t he originat ing
ASBR.
Ex t e r n a l Rou t e Ta g is an arbit rary t ag t hat m ay be applied t o t he ext ernal rout e. This
field is not used by t he OSPF prot ocol it self, but is inst ead provided for ext ernal rout e
m anagem ent . The set t ing and use of such t ags are discussed in Chapt er 14, " Rout e Maps."
Opt ionally, TOS fields m ay be associat ed wit h t he dest inat ion. These fields are t he sam e as
discussed previously, except each TOS m et ric also has it s own E- bit , Forwarding Address, and
Ext ernal Rout e Tag.
NSSA External LSA
NSSA Ext ernal LSAs are originat ed by ASBRs wit hin an NSSA ( not - so- st ubby area) . All fields of
t he NSSA Ext ernal LSA ( Figure 8- 41) are ident ical t o an AS Ext ernal LSA's fields, wit h t he
except ion of t he Forwarding Address field. Unlike AS Ext ernal LSAs, which are flooded
t hroughout an OSPF aut onom ous syst em , NSSA ext ernal LSAs are flooded only wit hin t he not so- st ubby area in which it was originat ed. The com m and sh ow ip ospf da t a ba se n ssa e x t e r n a l is used t o display NSSA Ext ernal LSAs (Exam ple 8- 16) .
Figu r e 8 - 4 1 . OSPF N SSA Ex t e r n a l LSA.
Forwarding Address, if t he net work bet ween t he NSSA ASBR and t he adj acent aut onom ous
syst em is advert ised as an int ernal rout e, is t he next hop address on t he net work. I f t he net work
is not advert ised as an int ernal rout e, t he forwarding address will be t he NSSA ASBR's Rout er
I D.
Options Field
The Opt ions field ( Figure 8- 42) is present in every Hello and Dat abase Descript ion packet and in
every LSA. The Opt ions field allows rout ers t o com m unicat e t heir opt ional capabilit ies t o ot her
rout ers.
Figu r e 8 - 4 2 . Th e OSPF Opt ion s fie ld.
DN is used wit h MPLS- based layer 3 Virt ual Privat e Net works ( VPN) , com m only called RFC 2547
VPNs aft er t he RFC t hat specifies t hem . When a rout e is learned from a cust om er net work via
OSPF, is advert ised across t he RFC 2547 VPN using Mult iprot ocol BGP, and t hen is advert ised
back t o a cust om er net work via OSPF, a loop can occur in which t he OSPF rout e is redist ribut ed
back t o t he VPN provider net work in BGP. The DN bit prevent s t his looping. When t he DN bit is
set in a t ype 3, 5, or 7 LSA, t he receiving rout er cannot use t hat LSA in it s OSPF rout e
calculat ions.
O is set t o indicat e t hat t he originat ing rout er support s Opaque ( t ype 9, 10, and 11) LSAs.
DC is set when t he originat ing rout er is capable of support ing OSPF over dem and circuit s.
EA is set when t he originat ing rout er is capable of receiving and forwarding Ext ernal At t ribut es
LSAs. These LSAs are not in general usage and are not covered in t his book.
N is used only in Hello packet s. A rout er set s N- bit = 1 t o indicat e support for NSSA Ext ernal
LSAs. I f N- bit = 0, t he rout er will not accept or send t hese LSAs. Neighboring rout ers wit h
m ism at ched N- bit s will not becom e adj acent ; t his rest rict ion ensures t hat all rout ers in an area
support NSSA capabilit ies equally. I f t he N- bit = 1, t he E- bit m ust be 0.
P is used only in NSSA Ext ernal LSA headers. ( For t his reason, t he N- and P- bit can use t he
sam e posit ion.) This bit t ells t he ABR of a not - so- st ubby area t o t ranslat e t ype 7 LSAs int o t ype
5 LSAs.
MC is set when t he originat ing rout er is capable of forwarding I P m ult icast packet s. This bit is
used by MOSPF.
E is set when t he originat ing rout er is capable of accept ing AS Ext ernal LSAs. I t will be set t o 1 in
all AS Ext ernal LSAs and in all LSAs originat ed in t he backbone and nonst ub areas. E- bit = 0 in
all LSAs originat ed wit hin a st ub area. Addit ionally, t he bit is used in t he Hello packet t o indicat e
an int erface's capabilit y of sending and receiving t ype 5 LSAs. Neighboring rout ers wit h
m ism at ched E- bit s will not becom e adj acent ; t his rest rict ion ensures t hat all rout ers in an area
support st ub capabilit ies equally.
MT, when set , indicat es t hat t he originat ing rout er support s Mult it opology OSPF ( MT- OSPF) . MTOSPF, as of t his writ ing, is only a proposal and has not yet found general adopt ion.
Older OSPF st andards specified t hat t he opt ions bit posit ion now occupied by t he MT bit was t he
T bit . T was set when t he originat ing rout er is capable of support ing TOS. However, because t he
TOS capabilit y was never deployed, t he T bit was also never used.
Configuring OSPF
The m any opt ions and configurat ion variables available t o OSPF frequent ly m ake it t he I GP of
choice in large I P net works. However, t he opinion is occasionally expressed t hat OSPF
configurat ion is " t oo com plex" t o be a good choice for sm all int ernet s. This is nonsense. As t he
first case st udy shows, get t ing a basic OSPF configurat ion up and running involves only a few
ext ra keyst rokes in t he n e t w or k com m and; if t he operat ion of OSPF is reasonably well
underst ood, t hese ext ra keyst rokes will be int uit ive.
Case Study: A Basic OSPF Configuration
The t hree st eps necessary t o begin a basic OSPF process are
St e p 1 .
Det erm ine t he area t o which each rout er int erface will be at t ached.
St e p 2 .
Enable OSPF wit h t he com m and r ou t e r ospf process- id.
St e p 3 .
Specify t he int erfaces on which t o run OSPF, and t heir areas, wit h t he n e t w or k a r e a com m and.
Unlike t he process I D associat ed wit h I GRP and EI GRP, t he OSPF process I D is not an
aut onom ous syst em num ber. The process I D can be any posit ive int eger and has no significance
out side t he rout er on which it is configured. Cisco I OS allows m ult iple OSPF processes t o run on
t he sam e rout er; [ 25] t he process I D m erely dist inguishes one process from anot her wit hin t he
device.
[25] Although
the use of multiple processes on one router is possible, it is highly discouraged because of the demands that
the multiple databases will place on router resources.
The n e t w or k com m and used wit h RI P allows only t he specificat ion of a m aj or net work address.
I f som e int erfaces wit hin t he net work should not run t he rout ing prot ocol, t he pa ssive in t e r fa ce com m and has t o be used wit h t hose prot ocols. As is t he n e t w or k com m and used wit h
t he wildcard m ask for EI GRP, t he n e t w or k a r e a com m and is m uch m ore flexible t hen t he
n e t w or k com m and used for RI P and EI GRP before t he wildcard opt ion was int roduced, reflect ing
t he fully classless nat ure of OSPF. Any address range can be specified wit h an ( address, inverse
m ask) pair. The inverse m ask is t he sam e as t he inverse m ask used wit h access list s. [ 26] The
area can be specified in eit her decim al or dot t ed decim al.
[26] See
Appendix B , "Tutorial: Access Lists," for a tutorial on the use of inverse masks.
Figure 8- 43 shows an OSPF net work. Not e t hat each area has an assigned I P address from which
it s subnet s are derived. Lim it ing an area t o a single address or subnet is not necessary, but
doing so has significant advant ages, as will be seen in a lat er case st udy on address
sum m arizat ion. Not e also t hat t his exam ple is designed t o dem onst rat e t he configurat ion of
m ult iple areas. I n " real life," it would be m uch wiser t o put such a sm all net work wit hin a single
area. Furt her, t hat single area does not have t o be area 0. The rule is t hat all areas m ust
connect t o t he backbone; t herefore, a backbone area is needed only if t here is m ore t han one
area.
Figu r e 8 - 4 3 . Ch a r din a n d Goya a r e ABRs; Ru be n s a n d M a t isse a r e
I n t e r n a l Rou t e r s.
Each of t he four rout ers in Figure 8- 43 is configured different ly t o dem onst rat e t he flexibilit y of
t he n e t w or k a r e a com m and. The configurat ions are displayed in Exam ple 8- 19 t hrough
Exam ple 8- 22 :
Ex a m ple 8 - 1 9 . Ru be n s's OSPF n e t w or k a r e a con figu r a t ion .
router ospf 10
network 0.0.0.0 255.255.255.255 area 1
Ex a m ple 8 - 2 0 . Ch a r din 's OSPF n e t w or k a r e a con figu r a t ion .
router ospf 20
network 192.168.30.0 0.0.0.255 area 1
network 192.168.20.0 0.0.0.255 area 0
Ex a m ple 8 - 2 1 . Goya 's OSPF n e t w or k a r e a con figu r a t ion .
router ospf 30
network 192.168.20.0 0.0.0.3 area 0.0.0.0
network 192.168.10.0 0.0.0.31 area 192.168.10.0
Ex a m ple 8 - 2 2 . M a t isse 's OSPF n e t w or k a r e a con figu r a t ion .
router ospf 40
network 192.168.10.2 0.0.0.0 area 192.168.10.0
network 192.168.10.33 0.0.0.0 area 192.168.10.0
The first t hing t o not e is t hat t he process I Ds are different for each rout er. Usually t hese
num bers are t he sam e across an int ernet for consist ency of configurat ion. Here t he process I Ds
are configured different ly m erely t o dem onst rat e t hat t hey have no m eaning out side of t he
rout er. These four different ly num bered processes are able t o com m unicat e.
The next t hing t o not ice is t he form at of t he n e t w or k a r e a com m and. Following t he n e t w or k
port ion is an I P address and an inverse m ask. When t he OSPF process first becom es act ive, it
will " run" t he I P addresses of all act ive int erfaces against t he ( address, inverse m ask) pair of t he
first net work st at em ent . All int erfaces t hat m at ch will be assigned t o t he area specified by t he
a r e a port ion of t he com m and. The process will t hen run t he addresses of any int erfaces t hat did
not m at ch t he first net work st at em ent against t he second net work st at em ent . The process of
running I P addresses against net work st at em ent s cont inues unt il all int erfaces have been
m at ched or unt il all net work st at em ent s have been used. I t is im port ant t o not e t hat t his process
is consecut ive, beginning wit h t he first net work st at em ent . As a result , t he order of t he
st at em ent s can be im port ant , as is shown in t he t roubleshoot ing sect ion.
Rubens's net work st at em ent will m at ch all int erfaces on t he rout er. The address 0.0.0.0 is really
j ust a placeholder; t he inverse m ask of 255.255.255.255 is t he elem ent t hat does all of t he work
here. Wit h " don't care" bit s placed across t he ent ire four oct et s, t he m ask will find a m at ch wit h
any address and place t he corresponding int erface int o area 1. This m et hod provides t he least
precision in cont rolling which int erfaces will run OSPF.
Chardin is an ABR bet ween area 1 and area 0. This fact is reflect ed in it s net work st at em ent s.
Here t he ( address, inverse m ask) pairs will place any int erface t hat is connect ed t o any subnet
of m aj or net work 192.168.30.0 in area 1 and any int erface t hat is connect ed t o any subnet of
m aj or net work 192.168.20.0 in t he backbone area.
Goya is also an ABR. Here t he ( address, inverse m ask) pairs will m at ch only t he specific subnet s
configured on t he t wo int erfaces. Not ice also t hat t he backbone area is specified in dot t ed
decim al. Bot h t his form at and t he decim al form at used at Chardin will cause t he associat ed area
fields of t he OSPF packet s t o be 0x00000000, so t hey are com pat ible.
Mat isse has one int erface, 192.168.10.65/ 26, which is not running OSPF. The net work
st at em ent s for t his rout er are configured t o t he individual int erface addresses, and t he inverse
m ask indicat es t hat all 32 bit s m ust m at ch exact ly. This m et hod provides t he m ost precise
cont rol over which int erfaces will run OSPF.
Finally, not e t hat alt hough Mat isse's int erface 192.168.10.65/ 26 is not running OSPF, t hat
address is num erically t he highest on t he rout er. As a result , Mat isse's Rout er I D is
192.168.10.65 ( Exam ple 8- 23 ) .
Ex a m ple 8 - 2 3 . Th e com m a n d sh ow ip ospf pr oce ss- id displa ys pr oce ssspe cific in for m a t ion .
Matisse#show ip ospf 40
Routing Process "ospf 40" with ID 192.168.10.65
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
External flood list length 0
Area 192.168.10.0
Number of interfaces in this area is 2
Area has no authentication
SPF algorithm last executed 00:47:42.792 ago
SPF algorithm executed 4 times
Area ranges are
Number of LSA 5. Checksum Sum 0x02A444
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Case Study: Setting Router IDs with Loopback Interfaces
Suppose rout er Mat isse from Figure 8- 43 has been configured in a st aging cent er and t hen sent
t o t he field t o be inst alled. During t he boot up, t he rout er report s t hat it cannot allocat e a Rout er
I D, and it seem s t o report t he n e t w or k a r e a com m ands as configurat ion errors ( Exam ple 8- 24
) . Worse, t he OSPF com m ands are no longer in t he running configurat ion.
Ex a m ple 8 - 2 4 . OSPF w ill n ot boot if it ca n n ot fin d a n a ct ive I P a ddr e ss
for it s Rou t e r I D .
Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-J1S3-M), Version 12.3(6), RELEASE SOFTWARE (fc3)
Copyright (c) 1986-2004 by Cisco Systems, Inc.
Compiled Wed 11-Feb-04 19:24 by kellythw
Image text-base: 0x80008098, data-base: 0x8199F778
cisco 2621 (MPC860) processor (revision 0x200) with 61440K/4096K bytes of memory
Processor board ID JAD05090PW2 (1141326406)
M860 processor: part number 0, mask 49
Bridging software.
X.25 software, Version 3.0.0.
TN3270 Emulation software.
2 FastEthernet/IEEE 802.3 interface(s)
1 Serial network interface(s)
32K bytes of non-volatile configuration memory.
16384K bytes of processor board System flash (Read/Write)
network 192.168.10.2 0.0.0.0 area 192.168.10.0
^
% Invalid input detected at '^' marker.
network 192.168.10.33 0.0.0.0 area 192.168.10.0
^
% Invalid input detected at '^' marker.
Press RETURN to get started!
%OSPF-4-NORTRID: OSPF process 40 cannot start. There must
be at least one "up" IP interface, for OSPF to use as router ID
The problem here is t hat during boot up all t he int erfaces on t he rout er were adm inist rat ively
shut down. I f OSPF cannot find an act ive I P address for it s Rout er I D, it cannot st art . And if t he
OSPF process isn't act ive, t he subsequent n e t w or k a r e a com m ands will be invalid.
The solut ion t o t his problem ( assum ing you have a valid reason for having all physical int erfaces
in shut down) is t o use a loopback int erface. The loopback int erface, which is a virt ual, soft wareonly int erface, is always up. Therefore, it s I P address is always available.
The m ore com m on reason for using loopback int erfaces on OSPF rout ers is t hat t he int erfaces
allow t he net work adm inist rat or t o cont rol t he Rout er I Ds. When t he OSPF process looks for a
Rout er I D, OSPF will prefer t he address of a loopback int erface over t he addresses of all physical
int erfaces, regardless of t he num erical order. I f t here are m ult iple loopback int erfaces wit h I P
addresses, OSPF will choose t he num erically highest loopback address.
Cont rolling t he Rout er I Ds so t hat individual OSPF rout ers are m ore easily ident ified facilit at es
m anagem ent and t roubleshoot ing. The Rout er I Ds are usually m anaged by one of t wo m et hods:
Set aside a legit im at e net work or subnet address t o be used st rict ly for Rout er I Ds.
Use a " bogus" I P address range.
The first m et hod has t he disadvant age of using up t he assigned net work address space. The
second m et hod will preserve t he legit im at e addresses, but one m ust rem em ber t hat what is
bogus in one int ernet is legit im at e in anot her. Using easily recognized addresses such as 1.1.1.1,
2.2.1.1, and so on is fine as long as you rem em ber t hat t hese are not public addresses. Care
m ust be t aken t hat t he bogus addresses do not leak out t o t he public I nt ernet .
The configurat ions of t he last sect ion are m odified t o use loopback addresses as displayed in
Exam ple 8- 25 t hrough Exam ple 8- 28 .
Ex a m ple 8 - 2 5 . A Loopba ck in t e r fa ce is a dde d t o Ru be n s's
con figu r a t ion .
interface Loopback0
ip address 192.168.50.1 255.255.255.255
!
router ospf 10
network 192.168.30.0 0.0.0.255 area 1
Ex a m ple 8 - 2 6 . A Loopba ck in t e r fa ce is a dde d t o Ch a r din 's
con figu r a t ion .
interface Loopback0
ip address 192.168.50.2 255.255.255.255
!
router ospf 20
network 192.168.30.0 0.0.0.255 area 1
network 192.168.20.0 0.0.0.255 area 0
Ex a m ple 8 - 2 7 . A Loopba ck in t e r fa ce is a dde d t o Goya 's con figu r a t ion .
interface Loopback0
ip address 192.168.50.3 255.255.255.255
!
router ospf 30
network 192.168.20.0 0.0.0.3 area 0.0.0.0
network 192.168.10.0 0.0.0.31 area 192.168.10.0
Ex a m ple 8 - 2 8 . A Loopba ck in t e r fa ce is a dde d t o M a t isse 's
con figu r a t ion .
interface Loopback0
ip address 192.168.50.4 255.255.255.255
!
router ospf 40
network 192.168.10.2 0.0.0.0 area 192.168.10.0
network 192.168.10.33 0.0.0.0 area 192.168.10.0
For t his exam ple, t he net work address 192.168.50.0 has been set aside for exclusive use as
Rout er I Ds. Rout er I Ds are t hus easily dist inguished from ot her I P addresses in t his int ernet .
The first t hing t o not e about t his configurat ion is t he address m asks used wit h t he loopback
addresses: Each m ask is configured as a host address. This st ep is not really necessary, because
OSPF t reat s a loopback int erface as a st ub host ; what ever ( address, m ask) pair is configured,
t he address of t he loopback int erface will be advert ised as a host rout e. The host m ask is used
m erely t o keep t hings neat , and t o reflect t he way in which t he address is advert ised.
However, t he second point of int erest m akes t he first som ewhat irrelevant . Rem em ber t hat OSPF
does not have t o be running on an int erface for it s I P address t o be used as t he Rout er I D. I n
fact , having OSPF advert ise t he loopback addresses j ust creat es unnecessary LSAs. I n t he
exam ple shown, not ice t hat t he n e t w or k a r e a st at em ent s do not refer t o t he loopback
addresses. I n fact , t he configurat ion at Rubens had t o be changed. Rubens's previous com m and,
n e t w or k 0 .0 .0 .0 2 5 5 .2 5 5 .2 5 5 .2 5 5 a r e a 1 , would have picked up t he loopback address.
I n addit ion t o aiding m anagem ent and t roubleshoot ing, using loopback int erfaces will also m ake
an OSPF int ernet m ore st able. I n som e early versions of I OS, if a physical int erface from which
t he Rout er I D was t aken experiences a hardware failure, [ 27] if t he int erface is adm inist rat ively
shut down, or if t he I P address is inadvert ent ly delet ed, t he OSPF process m ust acquire a new
Rout er I D. Therefore, t he rout er m ust prem at urely age and flood it s old LSAs and t hen flood
LSAs cont aining t he new I D. A loopback int erface has no hardware com ponent s t o fail. The
current I OS behavior is t o obt ain t he Rout er I D; if t he int erface associat ed wit h t he Rout er I D
fails or t he I P address is delet ed, t he rout er ret ains t he Rout er I D unt il t he rout er is reloaded or
t he OSPF process is reset .
[27] Merely
disconnecting the interface will not cause the Router ID to change.
Anot her opt ion is t o m anually assign a Rout er I D t o t he rout er wit h t he OSPF com m and r ou t e r id . As wit h t he Rout er I D address assignm ent using loopback int erfaces, you can arbit rarily
choose an I P address t o use as t he value of t he r ou t e r - id com m and. I f a Rout er I D is configured
using t his com m and, t his com m and's value will becom e t he rout er I D when t he OSPF process is
reset or t he rout er is reloaded. When t he rout er is reloaded, however, t here st ill has t o be an
int erface wit h an I P address t hat com es up before t he OSPF process can st art . Aft er t he OSPF
process st art s, t he address assigned wit h t he r ou t e r - id com m and will becom e t he Rout er I D.
Case Study: Domain Name Service Lookups
Loopback int erfaces sim plify t he m anagem ent and t roubleshoot ing of OSPF int ernet s by
providing predict able Rout er I Ds. This sim plificat ion can be t aken even furt her by recording t he
Rout er I Ds in a Dom ain Nam e Service ( DNS) dat abase. The rout er can t hen be configured t o
consult t he server address- t o- nam e m appings, or Reverse DNS lookups, and t hen display t he
rout ers by nam e inst ead of by Rout er I D ( Exam ple 8- 29 ) .
Ex a m ple 8 - 2 9 . OSPF ca n be con figu r e d t o u se D N S t o m a p Rou t e r I D s
t o n a m e s for u se in som e sh ow com m a n ds.
Goya#show ip ospf neighbor
Neighbor ID
Pri
State
chardin
0
FULL/
matisse
0
FULL/
Goya#show ip ospf database
-
Dead Time
00:00:36
00:00:34
Address
192.168.20.1
192.168.10.2
Interface
Serial0/0.2
Serial0/0.1
OSPF Router with ID (192.168.50.3) (Process ID 30)
Router Link States (Area 0.0.0.0)
Link ID
192.168.50.2
192.168.50.3
ADV Router
chardin
goya
Age
78
78
Seq#
Checksum Link count
0x80000007 0x005A70 2
0x80000008 0x004C7B 2
Summary Net Link States (Area 0.0.0.0)
Link ID
192.168.10.0
192.168.10.32
192.168.30.0
192.168.30.8
ADV Router
goya
goya
chardin
chardin
Age
74
54
85
100
Seq#
0x80000001
0x80000001
0x80000001
0x80000001
Checksum
0x00B356
0x00DCFB
0x007766
0x001DB9
Router Link States (Area 192.168.10.0)
Link ID
192.168.50.3
192.168.50.4
--More-
ADV Router
goya
matisse
Age
68
67
Seq#
Checksum Link count
0x80000007 0x0024D3 2
0x80000007 0x00E080 3
Goya was configured t o perform DNS lookups as shown in Exam ple 8- 30 .
Ex a m ple 8 - 3 0 . Goya is con figu r e d t o pe r for m D N S look u ps.
ip name-server 172.19.35.2
!
ip ospf name-lookup
The first com m and specifies t he address of t he DNS server, and t he second enables t he OSPF
process t o perform DNS lookups. I n som e cases, a rout er is ident ified by an int erface address
inst ead of a Rout er I D. Adding ent ries t o t he DNS dat abase for t he rout er int erfaces, such as
rubens- e0 , allows t he int erfaces t o also be ident ified by nam e while different iat ing t hem from
t he Rout er I Ds.
The address of t he nam e server used in t his exam ple does not belong t o one of t he subnet s
shown in Figure 8- 43 . The m et hod by which t his net work is reached is t he subj ect of t he next
case st udy.
Case Study: OSPF and Secondary Addresses
Two rules are relat ed t o t he use of secondary addresses in an OSPF environm ent :
OSPF will advert ise a secondary net work or subnet only if it is also running on t he prim ary
net work or subnet .
OSPF sees secondary net works as st ub net works ( net works on which t here are no OSPF
neighbors) and t herefore will not send Hellos on t hem . Consequent ly, no adj acencies can
be est ablished on secondary net works.
Figure 8- 44 shows t he DNS server and an addit ional rout er at t ached t o t he FA0/ 0 int erface of
Mat isse. The server and t he new rout er have addresses in subnet 172.19.35.0/ 25, so Mat isse's
FA0/ 0 has been given a secondary address of 172.19.35.15/ 25 ( see Exam ple 8- 31 ) .
Figu r e 8 - 4 4 . Rou t e r D a li a n d t h e D N S se r ve r a r e n ot pa r t of t h e OSPF
dom a in a n d a r e a t t a ch e d t o M a t isse via a se con da r y n e t w or k a ddr e ss.
Ex a m ple 8 - 3 1 . M a t isse is con figu r e d w it h a se con da r y a ddr e ss.
interface FastEthernet0/0
ip address 172.19.35.15 255.255.255.128 secondary
ip address 192.168.10.33 255.255.255.240
!
router ospf 40
network 192.168.10.2 0.0.0.0 area 192.168.10.0
network 192.168.10.33 0.0.0.0 area 192.168.10.0
network 172.19.35.15 0.0.0.0 area 192.168.10.0
Wit h t his configurat ion, Mat isse will advert ise subnet 172.19.35.0/ 25 t o it s neighbors. However,
if t he n e t w or k a r e a st at em ent for 192.168.10.33 should be delet ed, subnet 172.19.35.0/ 25 will
no longer be advert ised. Because Mat isse is at t ached t o subnet 172.19.35.0/ 25 via a secondary
address, it cannot est ablish an adj acency wit h any rout ers on t hat subnet ( Figure 8- 45 ) .
However, t he DNS server uses Dali as it s default gat eway. Therefore Mat isse and Dali m ust be
able t o rout e packet s t o each ot her.
Figu r e 8 - 4 5 . Th is a n a lyze r ca pt u r e is fr om t h e n e t w or k t o w h ich
M a t isse , D a li, a n d t h e D N S se r ve r a r e a t t a ch e d. Th e sm a lle r w in dow
sh ow s t h a t H e llos a r e on ly be in g sou r ce d fr om M a t isse 's pr im a r y
a ddr e ss of 1 9 2 .1 6 8 .1 0 .3 3 . Th e la r ge r w in dow sh ow s a de code of on e
of t h e H e llos.
[View full size image]
An assessm ent of t he int ernet as described so far shows t hat
Subnet 172.19.35.0/ 25 is being advert ised int o t he OSPF dom ain; a packet wit h a
dest inat ion address of 172.19.35.2 will be rout ed t o Mat isse's FA0/ 0 int erface and from
t here direct ly t o t he DNS server ( Exam ple 8- 32 ) .
Because t he DNS server m ust send replies t o net work addresses different t han it s own, it
will send t he replies t o Dali for rout ing.
Dali is not exchanging rout ing inform at ion wit h Mat isse, so it does not know how t o reach
t he net works wit hin t he OSPF aut onom ous syst em .
Ex a m ple 8 - 3 2 . Th e M AC ide n t ifie r of t h e D N S se r ve r is r e cor de d in
M a t isse 's ARP ca ch e , in dica t in g t h a t t h e se r ve r ca n be r e a ch e d
dir e ct ly. I f pa ck e t s de st in e d for t h e se r ve r h a d t o be r ou t e d t h r ou gh
D a li, t h e M AC ide n t ifie r for bot h t h e se r ve r a n d for D a li w ou ld be
0 0 0 0 .0 c0 a .2 a a 9 in t h is ca ch e .
Matisse#show arp
Protocol Address
Age (min)
Internet 192.168.10.65
Internet 192.168.10.33
Internet 172.19.35.15
Internet 172.19.35.1
1
Internet 172.19.35.2
22
Hardware Addr
0005.5e6b.50a1
0005.5e6b.50a0
0005.5e6b.50a0
0010.7b3c.6bd3
0002.6779.0f4c
Type
ARPA
ARPA
ARPA
ARPA
ARPA
Interface
FastEthernet0/1
FastEthernet0/0
FastEthernet0/0
FastEthernet0/0
FastEthernet0/0
So t he one st ep needed t o " close t he circuit " is t o t ell Dali how t o reach t he OSPF net works. This
is easily done wit h a st at ic rout e:
Dali(config)#ip route 192.168.0.0 255.255.0.0 172.19.35.15
Not e t hat st at ic rout es are classless, so t he one supernet ent ry can be used t o m at ch all
addresses wit hin t he OSPF aut onom ous syst em .
I n t his exam ple, Mat isse is not an ASBR. Alt hough it sends packet s t o dest inat ions out side of t he
aut onom ous syst em , it is not accept ing any inform at ion about ext erior dest inat ions and
t herefore is not originat ing any t ype 5 LSAs.
Figure 8- 46 shows a new set of dest inat ions reachable via Dali. Mat isse m ust now becom e an
ASBR and advert ise t he rout es int o t he OSPF dom ain. However, it m ust first learn t he rout es.
This t ask can be done by configuring st at ic rout es or by running a rout ing prot ocol t hat will
com m unicat e over t he secondary net work. I n eit her case, t he rout es m ust t hen be redist ribut ed
int o OSPF.
Figu r e 8 - 4 6 . Th e OSPF a u t on om ou s syst e m m u st le a r n a bou t t h e
de st in a t ion s r e a ch a ble via D a li, bu t M a t isse 's se con da r y a ddr e ss t o
D a li pr e ve n t s t h e t w o r ou t e r s fr om sh a r in g in for m a t ion via OSPF.
[View full size image]
RI P, which has no difficult ies wit h secondary addresses, is chosen t o com m unicat e wit h Dali.
Mat isse's configurat ion is as shown in Exam ple 8- 33 .
Ex a m ple 8 - 3 3 . RI P is a dde d t o M a t isse 's con figu r a t ion .
interface FastEthernet0/0
ip address 172.19.35.15 255.255.255.128 secondary
ip address 192.168.10.33 255.255.255.240
!
router ospf 40
redistribute rip metric 10 subnets
network 192.168.10.2 0.0.0.0 area 192.168.10.0
network 192.168.10.33 0.0.0.0 area 192.168.10.0
!
router rip
network 172.19.0.0
This configurat ion enables RI P on t he secondary net work of FA0/ 0, allowing Mat isse t o learn
rout es from Dali ( Exam ple 8- 34 ) . The rout es are redist ribut ed int o OSPF ( which is no longer
running on t he secondary address) and assigned an OSPF cost of 10, wit h t he com m and
r e dist r ibu t e r ip m e t r ic 1 0 su bn e t s . See Chapt er 11 , " Rout e Redist ribut ion," for m ore det ails
on redist ribut ion. Exam ple 8- 35 shows t hat t he rout es are advert ised int o t he OSPF dom ain wit h
default ext ernal t ype 2 ( E2) m et rics; not ice t hat at Rubens t he cost of t hese rout es is st ill 10.
Mat isse advert ises t hese ext ernal dest inat ions wit h t ype 5 LSAs, m aking it an ASBR ( Exam ple 836 ) .
Ex a m ple 8 - 3 4 . D a li h a s pa sse d it s r ou t in g in for m a t ion t o M a t isse via
RI P.
Matisse#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
R
R
192.168.90.0/24 [120/1] via 172.19.35.1, 00:00:09, FastEthernet0/0
192.168.105.0/24 [120/1] via 172.19.35.1, 00:00:09, FastEthernet0/0
192.168.30.0/29 is subnetted, 2 subnets
O IA
192.168.30.0 [110/193] via 192.168.10.1, 02:12:53, Serial0/0.1
O IA
192.168.30.8 [110/192] via 192.168.10.1, 02:12:53, Serial0/0.1
R
192.168.60.0/24 [120/1] via 172.19.35.1, 00:00:09, FastEthernet0/0
192.168.10.0/24 is variably subnetted, 3 subnets, 3 masks
C
192.168.10.64/26 is directly connected, FastEthernet0/1
C
192.168.10.32/28 is directly connected, FastEthernet0/0
C
192.168.10.0/27 is directly connected, Serial0/0.1
172.19.0.0/25 is subnetted, 1 subnets
C
172.19.35.0 is directly connected, FastEthernet0/0
R
192.168.80.0/24 [120/1] via 172.19.35.1, 00:00:10, FastEthernet0/0
O IA
C
R
R
R
192.168.20.0/30 is subnetted, 1 subnets
192.168.20.0 [110/128] via 192.168.10.1, 02:13:06, Serial0/0.1
192.168.50.0/32 is subnetted, 1 subnets
192.168.50.4 is directly connected, Loopback0
192.168.70.0/24 [120/1] via 172.19.35.1, 00:00:13, FastEthernet0/0
192.168.100.0/24 [120/1] via 172.19.35.1, 00:00:13, FastEthernet0/0
192.168.101.0/24 [120/1] via 172.19.35.1, 00:00:13, FastEthernet0/0
Ex a m ple 8 - 3 5 . Th e RI P- le a r n e d r ou t e s a r e r e dist r ibu t e d in t o t h e OSPF
a u t on om ou s syst e m a s pa t h t ype E2 .
Rubens#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 192.168.90.0/24 [110/10] via 192.168.30.10, 02:25:59, Serial0/0.1
O E2 192.168.105.0/24 [110/10] via 192.168.30.10, 02:25:59, Serial0/0.1
192.168.30.0/29 is subnetted, 2 subnets
C
192.168.30.0 is directly connected, FastEthernet0/0
C
192.168.30.8 is directly connected, Serial0/0.1
O E2 192.168.60.0/24 [110/10] via 192.168.30.10, 02:25:59, Serial0/0.1
192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
O IA
192.168.10.32/28 [110/193] via 192.168.30.10, 02:26:04, Serial0/0.1
O IA
192.168.10.0/27 [110/192] via 192.168.30.10, 02:26:11, Serial0/0.1
172.19.0.0/25 is subnetted, 1 subnets
O E2
172.19.35.0 [110/10] via 192.168.30.10, 00:00:27, Serial0/0.1
O E2 192.168.80.0/24 [110/10] via 192.168.30.10, 02:26:00, Serial0/0.1
192.168.20.0/30 is subnetted, 1 subnets
O IA
192.168.20.0 [110/128] via 192.168.30.10, 02:26:17, Serial0/0.1
192.168.50.0/32 is subnetted, 1 subnets
C
192.168.50.1 is directly connected, Loopback0O E2 192.168.70.0/24 [110/10]
via 192.168.30.10, 02:26:03, Serial0/0.1
O E2 192.168.100.0/24 [110/10] via 192.168.30.10, 02:26:03, Serial0/0.1
O E2 192.168.101.0/24 [110/10] via 192.168.30.10, 02:26:03, Serial0/0.
Ex a m ple 8 - 3 6 . M a t isse ( RI D = 1 9 2 .1 6 8 .5 0 .4 ) is n ow a n ASBR be ca u se
it is or igin a t in g a u t on om ou s syst e m e x t e r n a l LSAs t o a dve r t ise t h e
e x t e r n a l r ou t e s.
Rubens#show ip ospf border-routers
OSPF Process 10 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 192.168.50.2 [64] via 192.168.30.10, Serial0/0.1, ABR, Area 1, SPF 7
I 192.168.50.4 [192] via 192.168.30.10, Serial0/0.1, ASBR, Area 1, SPF 7
Case Study: Stub Areas
Because no t ype 5 LSAs are being originat ed wit hin area 1 of Figure 8- 46 , it can be configured
as a st ub area. Not e t hat when an at t ached area is configured as a st ub area, t he Hellos
originat ed by t he rout er int o t hat area will have E = 0 in t he Opt ions field. Any rout er receiving
t hese Hellos, which is not sim ilarly configured, will drop t he packet s, and an adj acency will not
be est ablished. I f t here is an exist ing adj acency, it will be broken. Consequent ly, if an
operat ional area is going t o be reconfigured as a st ub area, downt im e should be scheduled;
rout ing will be disrupt ed unt il all rout ers are reconfigured.
A st ub area is configured by adding t he a r e a st u b com m and t o t he OSPF process as displayed in
Exam ple 8- 37 and Exam ple 8- 38 .
Ex a m ple 8 - 3 7 . Ru be n s is con figu r e d t o m a k e a r e a 1 a st u b a r e a .
router ospf 10
network 0.0.0.0 255.255.255.255 area 1
area 1 stub
Ex a m ple 8 - 3 8 . Ch a r din is con figu r e d t o m a k e a r e a 1 a st u b a r e a .
router ospf 20
network 192.168.30.0 0.0.0.255 area 1
network 192.168.20.0 0.0.0.255 area 0
area 1 stub
Com paring t he link- st at e dat abase of Rubens before ( Exam ple 8- 39 ) and aft er ( Exam ple 8- 40 )
t he configured st ub area shows t hat all aut onom ous syst em ext ernal LSAs and ASBR sum m ary
LSAs have been elim inat ed from t he dat abase. I n t his case, t he size of t he dat abase has been
reduced by m ore t han 50 percent .
Ex a m ple 8 - 3 9 . Ru be n s's da t a ba se h a s a t ot a l of 1 4 LSAs be for e a r e a 1
is con figu r e d a s a st u b a r e a .
Rubens#show ip ospf database database-summary
OSPF Router with ID (192.168.50.1) (Process ID 10)
Area 1 database
LSA Type
Router
Network
Summary Net
Summary ASBR
Type-7 Ext
Opaque Link
Opaque Area
Subtotal
summary
Count
2
0
3
1
0
0
0
6
Delete
0
0
0
0
0
0
0
0
Maxage
0
0
0
0
0
0
0
0
Process 10 database summary
LSA Type
Count
Delete
Router
2
0
Network
0
0
Summary Net
3
0
Summary ASBR 1
0
Type-7 Ext
0
0
Opaque Link
0
0
Opaque Area
0
0
Type-5 Ext
8
0
Maxage
0
0
0
0
0
0
0
0
Opaque AS
Total
0
14
0
0
0
0
Ex a m ple 8 - 4 0 . Th e st u b a r e a con figu r a t ion e lim in a t e s t h e e igh t t ype 5
LSAs a n d t h e sin gle t ype 4 LSA fr om Ru be n s's da t a ba se . On e t ype 3
LSA, w h ich a dve r t ise s t h e de fa u lt r ou t e , h a s be e n a dde d.
Rubens#show ip ospf database database-summary
OSPF Router with ID (192.168.50.1) (Process ID 10)
Area 1 database
LSA Type
Router
Network
Summary Net
Summary ASBR
Type-7 Ext
Opaque Link
Opaque Area
Subtotal
summary
Count
2
0
4
0
0
0
0
6
Delete
0
0
0
0
0
0
0
0
Maxage
0
0
0
0
0
0
0
0
Process 10 database summary
LSA Type
Count
Delete
Router
2
0
Network
0
0
Summary Net
4
0
Summary ASBR 0
0
Type-7 Ext
0
0
Opaque Link
0
0
Opaque Area
0
0
Maxage
0
0
0
0
0
0
0
Type-5 Ext
Opaque AS
Total
0
0
6
0
0
0
0
0
0
When a st ub area is at t ached t o an ABR, t he rout er will aut om at ically advert ise a default rout e
( dest inat ion 0.0.0.0) int o t he area via a Net work Sum m ary LSA. The dat abase sum m ary in
Exam ple 8- 40 indicat es t his addit ional t ype 3 LSA. The last ent ry in Rubens's rout e t able
( Exam ple 8- 41 ) shows t he default rout e advert ised by Chardin.
Ex a m ple 8 - 4 1 . Ru be n s's r ou t e t a ble sh ow s t h a t a ll e x t e r n a l r ou t e s
h a ve be e n e lim in a t e d ( com pa r e t h is t o Ex a m ple 8 - 3 5 ) a n d t h a t a
de fa u lt r ou t e h a s be e n a dde d.
Rubens#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 192.168.30.10 to network 0.0.0.0
C
C
O IA
O IA
O IA
C
O*IA
192.168.30.0/29 is subnetted, 2 subnets
192.168.30.0 is directly connected, FastEthernet0/0
192.168.30.8 is directly connected, Serial0/0.1
192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
192.168.10.32/28 [110/193] via 192.168.30.10, 00:05:24, Serial0/0.1
192.168.10.0/27 [110/192] via 192.168.30.10, 00:05:24, Serial0/0.1
192.168.20.0/30 is subnetted, 1 subnets
192.168.20.0 [110/128] via 192.168.30.10, 00:05:24, Serial0/0.1
192.168.50.0/32 is subnetted, 1 subnets
192.168.50.1 is directly connected, Loopback0
0.0.0.0/0 [110/65] via 192.168.30.10, 00:05:25, Serial0/0.1
The ABR will advert ise a default rout e wit h a cost of 1. The cost of t he serial link bet ween
Rubens and Chardin is 64; Exam ple 8- 41 shows t he t ot al cost of t he default rout e t o be 64 + 1 =
65. This default cost can be changed wit h t he a r e a de fa u lt - cost com m and. For exam ple,
Chardin can be configured t o advert ise t he default rout e wit h a cost of 20 as shown in Exam ple
8- 42 .
Ex a m ple 8 - 4 2 . Ch a r din 's con figu r a t ion se t s t h e cost of t h e a dve r t ise d
de fa u lt r ou t e .
router ospf 20
network 192.168.30.0 0.0.0.255 area 1
network 192.168.20.0 0.0.0.255 area 0
area 1 stub
area 1 default-cost 20
The result ing cost increase, 64 + 20 = 84, can be seen in Exam ple 8- 43 . Changing t he cost of
t he default rout e has no real benefit here, but m ight be useful in st ub areas wit h m ore t han one
ABR. Norm ally, each I nt ernal Rout er would m erely choose t he default rout e wit h t he lowest cost .
By m anipulat ing t he advert ised cost , t he net work adm inist rat or could cause all I nt ernal Rout ers
t o use t he sam e ABR. The second ABR, advert ising a higher cost , would be used only if t he first
were t o fail.
Ex a m ple 8 - 4 3 . Ru be n s's r ou t e t a ble r e fle ct s t h e r e su lt s of ch a n gin g
t h e cost of t h e de fa u lt r ou t e .
Rubens#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 192.168.30.10 to network 0.0.0.0
C
C
192.168.30.0/29 is subnetted, 2 subnets
192.168.30.0 is directly connected, FastEthernet0/0
192.168.30.8 is directly connected, Serial0/0.1
192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
192.168.10.32/28 [110/193] via 192.168.30.10, 00:18:49, Serial0/0.1
192.168.10.0/27 [110/192] via 192.168.30.10, 00:18:49, Serial0/0.1
192.168.20.0/30 is subnetted, 1 subnets
O IA
192.168.20.0 [110/128] via 192.168.30.10, 00:18:49, Serial0/0.1
192.168.50.0/32 is subnetted, 1 subnets
C
192.168.50.1 is directly connected, Loopback0
O*IA 0.0.0.0/0 [110/84] via 192.168.30.10, 00:10:36, Serial0/0.1
O IA
O IA
Case Study: Totally Stubby Areas
Tot ally st ubby areas are configured by placing t he keyword n o- su m m a r y at t he end of t he a r e a
st u b com m and. This st ep is necessary only at t he ABR; t he I nt ernal Rout ers use t he st andard
st ub area configurat ion. To m ake area 1 in Figure 8- 46 a t ot ally st ubby area, Chardin's
configurat ion would be as shown in Exam ple 8- 44 .
Ex a m ple 8 - 4 4 . Ch a r din is con figu r e d t o m a k e a r e a 1 a t ot a lly st u bby
area.
router ospf 20
network 192.168.30.0 0.0.0.255 area 1
network 192.168.20.0 0.0.0.255 area 0
area 1 stub no-summary
Exam ple 8- 45 shows t hat t he LSAs in Rubens's dat abase have been reduced t o t hree; Exam ple
8- 46 shows t he rout e t able.
Ex a m ple 8 - 4 5 . Ch a n gin g a r e a 1 t o a t ot a lly st u bby a r e a e lim in a t e s a ll
bu t on e of t h e t ype 3 LSAs ( t h e de fa u lt r ou t e ) .
Rubens#show ip ospf database database-summary
OSPF Router with ID (192.168.50.1) (Process ID 10)
Area 1 database
LSA Type
Router
Network
Summary Net
Summary ASBR
Type-7 Ext
Opaque Link
Opaque Area
Subtotal
summary
Count
2
0
1
0
0
0
0
3
Delete
0
0
0
0
0
0
0
0
Maxage
0
0
0
0
0
0
0
0
Process 10 database summary
LSA Type
Count
Delete
Router
2
0
Network
0
0
Summary Net
1
0
Summary ASBR 0
0
Type-7 Ext
0
0
Maxage
0
0
0
0
0
Opaque Link
Opaque Area
0
0
0
0
0
0
Type-5 Ext
Opaque AS
Total
0
0
3
0
0
0
0
0
0
Ex a m ple 8 - 4 6 . A r ou t e t a ble in a t ot a lly st u bby a r e a w ill con t a in on ly
in t r a - a r e a r ou t e s a n d t h e de fa u lt r ou t e .
Rubens#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 192.168.30.10 to network 0.0.0.0
192.168.30.0/29 is
192.168.30.0 is
192.168.30.8 is
192.168.50.0/32 is
C
192.168.50.1 is
O*IA 0.0.0.0/0 [110/84]
C
C
subnetted, 2 subnets
directly connected, FastEthernet0/0
directly connected, Serial0/0.1
subnetted, 1 subnets
directly connected, Loopback0
via 192.168.30.10, 00:15:52, Serial0/0.1
Case Study: Not-So-Stubby Areas
The earlier case st udy, " OSPF and Secondary Addresses ," left off wit h Mat isse accept ing rout es
from Dali via RI P and redist ribut ing t hem int o t he OSPF dom ain ( see Figure 8- 46 ) . This st ep
m akes Mat isse an ASBR, and by ext ension m akes area 192.168.10.0 ineligible t o becom e a st ub
or t ot ally st ubby area. However, t here is no need for AS Ext ernal LSAs t o ent er t he area from
t he backbone area; t herefore area 192.168.10.0 can be configured as an NSSA. Exam ple 8- 47
shows t he configurat ion at Mat isse.
Ex a m ple 8 - 4 7 . M a t isse is con figu r e d t o m a k e a r e a 1 9 2 .1 6 8 .1 0 .0 a n ot so- st u bby a r e a .
router ospf 40
redistribute rip metric 10
network 192.168.10.2 0.0.0.0 area 192.168.10.0
network 192.168.10.33 0.0.0.0 area 192.168.10.0
area 192.168.10.0 nssa
!
router rip
network 172.19.0.0
The sam e a r e a n ssa st at em ent shown here is configured at Goya. Because Goya is an ABR, it
will t ranslat e t ype 7 LSAs received on t he NSSA- at t ached int erface int o t ype 5 LSAs. These
t ranslat ed LSAs will be flooded int o t he backbone and hence t o t he ot her areas. Com paring t he
rout e t ables of Goya and Chardin shows t hat Goya has t agged t he ext ernal rout es as NSSA [ 28]
( Exam ple 8- 48 ) . Chardin has t agged t he rout es as E2 ( Exam ple 8- 49 ) , indicat ing t hat t hey
have been learned from t ype 5 LSAs.
[28] N2
indicates the same metric calculation as E2that is, only the external cost is used. A subsequent example will
demonstrate E1 and N1 metric types.
Ex a m ple 8 - 4 8 . Th e e x t e r n a l r ou t e s le a r n e d fr om M a t isse a r e t a gge d a s
N SSA r ou t e s a t Goya .
Goya#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 N2 192.168.90.0/24 [110/10] via 192.168.10.2, 00:00:41, Serial0/0.1
O N2 192.168.105.0/24 [110/10] via 192.168.10.2, 00:00:41, Serial0/0.1
192.168.30.0/29 is subnetted, 2 subnets
O IA
192.168.30.0 [110/129] via 192.168.20.1, 00:00:41, Serial0/0.2
O IA
192.168.30.8 [110/128] via 192.168.20.1, 00:00:41, Serial0/0.2
O N2 192.168.60.0/24 [110/10] via 192.168.10.2, 00:00:41, Serial0/0.1
192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
O
192.168.10.32/28 [110/65] via 192.168.10.2, 00:00:43, Serial0/0.1
C
192.168.10.0/27 is directly connected, Serial0/0.1
172.19.0.0/25 is subnetted, 1 subnets
O N2
172.19.35.0 [110/10] via 192.168.10.2, 00:00:43, Serial0/0.1
O N2 192.168.80.0/24 [110/10] via 192.168.10.2, 00:00:43, Serial0/0.1
192.168.20.0/30 is subnetted, 1 subnets
C
192.168.20.0 is directly connected, Serial0/0.2
192.168.50.0/32 is subnetted, 1 subnets
C
192.168.50.3 is directly connected, Loopback0
O N2 192.168.70.0/24 [110/10] via 192.168.10.2, 00:00:55, Serial0/0.1
O N2 192.168.100.0/24 [110/10] via 192.168.10.2, 00:00:56, Serial0/0.1
O N2 192.168.101.0/24 [110/10] via 192.168.10.2, 00:00:56, Serial0/0.1
Ex a m ple 8 - 4 9 . Ch a r din h a s t a gge d t h e sa m e r ou t e s a s E2 , in dica t in g
t h e y h a ve be e n le a r n e d fr om a u t on om ou s syst e m e x t e r n a l LSAs.
Chardin#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 192.168.90.0/24 [110/10] via 192.168.20.2, 00:02:49, Serial0/0.2
O E2 192.168.105.0/24 [110/10] via 192.168.20.2, 00:02:49, Serial0/0.2
192.168.30.0/29 is subnetted, 2 subnets
O
192.168.30.0 [110/65] via 192.168.30.9, 00:08:41, Serial0/0.1
C
192.168.30.8 is directly connected, Serial0/0.1
O E2 192.168.60.0/24 [110/10] via 192.168.20.2, 00:02:49, Serial0/0.2
192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
O IA
192.168.10.32/28 [110/129] via 192.168.20.2, 00:02:55, Serial0/0.2
O IA
192.168.10.0/27 [110/128] via 192.168.20.2, 00:03:16, Serial0/0.2
172.19.0.0/25 is subnetted, 1 subnets
O E2
172.19.35.0 [110/10] via 192.168.20.2, 00:02:50, Serial0/0.2
O E2 192.168.80.0/24 [110/10] via 192.168.20.2, 00:02:50, Serial0/0.2
192.168.20.0/30 is subnetted, 1 subnets
C
192.168.20.0 is directly connected, Serial0/0.2
192.168.50.0/32 is subnetted, 1 subnets
C
192.168.50.2 is directly connected, Loopback0
O E2 192.168.70.0/24 [110/10] via 192.168.20.2, 00:02:52, Serial0/0.2
O E2 192.168.100.0/24 [110/10] via 192.168.20.2, 00:02:52, Serial0/0.2
O E2 192.168.101.0/24 [110/10] via 192.168.20.2, 00:02:52, Serial0/0.2
This t ranslat ion can also be observed by exam ining Goya's dat abase. Exam ple 8- 50 shows t hat
t he dat abase cont ains bot h t ype 7 and t ype 5 LSAs t o t he sam e ext ernal rout es. The originat ing
rout er for t he t ype 7 LSAs is Mat isse, whereas t he originat ing rout er for t he t ype 5 LSAs is Goya.
Ex a m ple 8 - 5 0 . Goya 's lin k - st a t e da t a ba se in dica t e s t h a t t h e t ype 7
LSAs fr om M a t isse ( 1 9 2 .1 6 8 .5 0 .4 ) h a ve be e n t r a n sla t e d in t o t ype 5
LSAs by Goya ( 1 9 2 .1 6 8 .5 0 .3 ) .
Type-7 AS External Link States (Area 192.168.10.0)
Link ID
172.19.35.0
192.168.60.0
192.168.70.0
192.168.80.0
192.168.90.0
192.168.100.0
192.168.101.0
192.168.105.0
ADV Router
192.168.50.4
192.168.50.4
192.168.50.4
192.168.50.4
192.168.50.4
192.168.50.4
192.168.50.4
192.168.50.4
Age
371
371
371
371
371
371
371
371
Seq#
0x80000001
0x80000001
0x80000001
0x80000001
0x80000001
0x80000001
0x80000001
0x80000001
Checksum
0x00C444
0x00A521
0x003785
0x00C8E9
0x005A4E
0x00EBB2
0x00E0BC
0x00B4E4
Tag
0
0
0
0
0
0
0
0
Checksum
0x005FB4
0x004091
0x00D1F5
0x00635A
0x00F4BE
0x008623
0x007B2D
0x004F55
Tag
0
0
0
0
0
0
0
0
Type-5 AS External Link States
Link ID
172.19.35.0
192.168.60.0
192.168.70.0
192.168.80.0
192.168.90.0
192.168.100.0
192.168.101.0
192.168.105.0
ADV Router
192.168.50.3
192.168.50.3
192.168.50.3
192.168.50.3
192.168.50.3
192.168.50.3
192.168.50.3
192.168.50.3
Age
305
306
306
306
390
390
390
390
Seq#
0x80000001
0x80000001
0x80000001
0x80000001
0x80000001
0x80000001
0x80000001
0x80000001
Several configurat ion opt ions are available for t he ABR. First , t he n o- su m m a r y opt ion can be
used wit h t he a r e a n ssa com m and t o block t he flooding of t ype 3 and t ype 4 LSAs int o t he
NSSA. To t urn area 192.168.10.0 int o a som ewhat schizophrenically nam ed " t ot ally st ubby not so- st ubby" area, Goya's configurat ion would be as shown in Exam ple 8- 51 .
Ex a m ple 8 - 5 1 . Goya is con figu r e d t o m a k e a r e a 1 9 2 .1 6 8 .1 0 .0 a t ot a lly
st u bby n ot - so- st u bby a r e a .
router ospf 30
network 192.168.20.0 0.0.0.3 area 0
network 192.168.10.0 0.0.0.31 area 192.168.10.0
area 192.168.10.0 nssa no-summary
Mat isse's rout e t able ( Exam ple 8- 52 ) shows t he elim inat ion of all int er- area rout es and t he
addit ion of a default rout e advert ised by Goya.
Ex a m ple 8 - 5 2 . All in t e r - a r e a r ou t e s h a ve be e n r e pla ce d w it h a de fa u lt
r ou t e t o t h e ABR.
Matisse#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 192.168.10.1 to network 0.0.0.0
R
R
R
C
C
C
C
R
C
R
192.168.90.0/24 [120/1] via 172.19.35.1, 00:00:20, FastEthernet0/0
192.168.105.0/24 [120/1] via 172.19.35.1, 00:00:20, FastEthernet0/0
192.168.60.0/24 [120/1] via 172.19.35.1, 00:00:20, FastEthernet0/0
192.168.10.0/24 is variably subnetted, 3 subnets, 3 masks
192.168.10.64/26 is directly connected, FastEthernet0/1
192.168.10.32/28 is directly connected, FastEthernet0/0
192.168.10.0/27 is directly connected, Serial0/0.1
172.19.0.0/25 is subnetted, 1 subnets
172.19.35.0 is directly connected, FastEthernet0/0
192.168.80.0/24 [120/1] via 172.19.35.1, 00:00:21, FastEthernet0/0
192.168.50.0/32 is subnetted, 1 subnets
192.168.50.4 is directly connected, Loopback0
192.168.70.0/24 [120/1] via 172.19.35.1, 00:00:21, FastEthernet0/0
R
192.168.100.0/24 [120/1] via 172.19.35.1, 00:00:22, FastEthernet0/0
R
192.168.101.0/24 [120/1] via 172.19.35.1, 00:00:22, FastEthernet0/0
O*IA 0.0.0.0/0 [110/65] via 192.168.10.1, 00:11:40, Serial0/0.1
I n Figure 8- 47 , t he link t o Dali has been m oved from Mat isse t o Goya; t he I P address has also
m oved. Goya is now an ASBR redist ribut ing RI P- learned rout es int o OSPF.
Figu r e 8 - 4 7 . Th e lin k t o D a li h a s m ove d t o Goya , w h ich n ow spe a k s
RI P t o D a li a n d r e dist r ibu t e s t h e le a r n e d r ou t e s in t o OSPF.
[View full size image]
When an ABR is also an ASBR and is connect ed t o a not - so- st ubby area, t he default behavior is
t o advert ise t he redist ribut ed rout es int o t he NSSA as shown in Exam ple 8- 53 .
Ex a m ple 8 - 5 3 . An ABR t h a t is a lso a n ASBR w ill a dve r t ise t h e e x t e r n a l
r ou t e s in t o a n N SSA w it h t ype 7 LSAs. I n t h is e x a m ple , Goya is
a dve r t isin g t h e e x t e r n a l r ou t e s w it h a n N 1 m e t r ic t ype .
Matisse#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 N1 192.168.90.0/24 [110/74] via 192.168.10.1, 00:00:07, Serial0/0.1
O N1 192.168.105.0/24 [110/74] via 192.168.10.1, 00:00:07, Serial0/0.1
192.168.30.0/29 is subnetted, 2 subnets
O IA
192.168.30.0 [110/193] via 192.168.10.1, 00:03:11, Serial0/0.1
O IA
192.168.30.8 [110/192] via 192.168.10.1, 00:03:11, Serial0/0.1
O N1 192.168.60.0/24 [110/74] via 192.168.10.1, 00:00:07, Serial0/0.1
192.168.10.0/24 is variably subnetted, 3 subnets, 3 masks
C
192.168.10.64/26 is directly connected, FastEthernet0/1
C
192.168.10.32/28 is directly connected, FastEthernet0/0
C
192.168.10.0/27 is directly connected, Serial0/0.1
172.19.0.0/25 is subnetted, 1 subnets
O N1
172.19.35.0 [110/74] via 192.168.10.1, 00:03:07, Serial0/0.1
O N1 192.168.80.0/24 [110/74] via 192.168.10.1, 00:00:08, Serial0/0.1
192.168.20.0/30 is subnetted, 1 subnets
O IA
192.168.20.0 [110/128] via 192.168.10.1, 00:03:14, Serial0/0.1
192.168.50.0/32 is subnetted, 1 subnets
C
192.168.50.4 is directly connected, Loopback0
O N1 192.168.70.0/24 [110/74] via 192.168.10.1, 00:00:10, Serial0/0.1
O N1 192.168.100.0/24 [110/74] via 192.168.10.1, 00:00:10, Serial0/0.1
O N1 192.168.101.0/24 [110/74] via 192.168.10.1, 00:00:10, Serial0/0.1
The default redist ribut ion m ay be t urned off on an ABR/ ASBR by adding t he st at em ent n or e dist r ibu t ion t o t he a r e a n ssa com m and. I n t he sam ple int ernet , no t ypes 3, 4, 5, or 7 LSAs
should be sent int o area 192.168.10.0 from t he ABR. The desired redist ribut ion is accom plished
by t he Exam ple 8- 54 configurat ion at Goya: [ 29]
[29] Note
the metric-type 1 statement in the redistribution command. This statement causes the external destinations to be
advertised with an E1 metric; within the NSSA, the metric type becomes N1, as shown in Example 8.53 .
Ex a m ple 8 - 5 4 . Goya is con figu r e d t o n ot r e dist r ibu t e RI P r ou t e s in t o
t h e N SSA 1 9 2 .1 6 8 .1 0 .0 .
interface Ethernet0/0
ip address 172.19.35.15 255.255.255.128
!
router ospf 30
redistribute rip metric 10 metric-type 1 subnets
network 192.168.20.0 0.0.0.3 area 0
network 192.168.10.0 0.0.0.31 area 192.168.10.0
area 192.168.10.0 nssa no-redistribution no-summary
!
router rip
network 172.19.0.0
Here t he a r e a n ssa com m and blocks t ype 5 LSAs from ent ering t he area t hrough Goya; n or e dist r ibu t ion blocks t ype 7 LSAs, and n o- su m m a r y blocks t ypes 3 and 4. As before, t he n osu m m a r y com m and also causes Goya t o send a single t ype 3 LSA int o t he area t o advert ise a
default rout e. Exam ple 8- 55 shows Mat isse's rout e t able aft er t ype 7 redist ribut ion is disabled at
Goya. Not e t hat t he ext ernal net works are st ill reachable, even t hough t hey are not in t he t able,
because of t he default rout e.
Ex a m ple 8 - 5 5 . Aft e r n o- r e dist r ibu t ion is a dde d t o Goya 's a r e a n ssa
com m a n d, t h e r ou t e t a ble of Ex a m ple 8 - 5 3 n o lon ge r con t a in s r ou t e s
le a r n e d fr om t ype 7 LSAs.
Matisse#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 192.168.10.1 to network 0.0.0.0
192.168.10.0/24 is variably subnetted, 3 subnets, 3 masks
192.168.10.64/26 is directly connected, FastEthernet0/1
192.168.10.32/28 is directly connected, FastEthernet0/0
192.168.10.0/27 is directly connected, Serial0/0.1
192.168.50.0/32 is subnetted, 1 subnets
C
192.168.50.4 is directly connected, Loopback0
O*IA 0.0.0.0/0 [110/65] via 192.168.10.1, 00:00:51, Serial0/0.1
C
C
C
I n t he final exam ple, Goya is t o allow t ypes 3 and 4 LSAs int o t he NSSA, but not t ypes 5 and 7.
The problem is t hat when t he n o- su m m a r y st at em ent is rem oved, t he ABR will no longer
originat e a t ype 3 LSA advert ising a default rout e. Wit hout a default rout e, t he ext erior
dest inat ions will not be reachable from wit hin t he NSSA. The st at em ent de fa u lt - in for m a t ion or igin a t e , added t o t he a r e a n ssa com m and, will cause t he ABR t o advert ise a default rout e
int o t he NSSAt his t im e, wit h a t ype 7 LSA. Using t his st at em ent , Goya's OSPF configurat ion is
displayed in Exam ple 8- 56 .
Ex a m ple 8 - 5 6 . D e fa u lt r ou t e is or igin a t e d a t Goya w it h t h e de fa u lt in for m a t ion - or igin a t e com m a n d.
router ospf 30
redistribute rip metric 10 metric-type 1 subnets
network 192.168.20.0 0.0.0.3 area 0
network 192.168.10.0 0.0.0.31 area 192.168.10.0
area 192.168.10.0 nssa no-redistribution default-information-originate
Exam ple 8- 57 shows Mat isse's rout e t able aft er t he reconfigurat ion. The t able cont ains int er- area
rout es and a default rout e wit h an N2 t ag indicat ing t hat t he rout e was learned from a t ype 7
LSA.
Ex a m ple 8 - 5 7 . Addin g t h e de fa u lt - in for m a t ion - or igin a t e st a t e m e n t t o
t h e a r e a n ssa com m a n d ca u se s t h e ABR t o a dve r t ise a de fa u lt r ou t e
in t o a n N SSA.
Matisse#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 192.168.10.1 to network 0.0.0.0
O IA
O IA
C
C
C
192.168.30.0/29 is subnetted, 2 subnets
192.168.30.0 [110/193] via 192.168.10.1, 00:00:26, Serial0/0.1
192.168.30.8 [110/192] via 192.168.10.1, 00:00:26, Serial0/0.1
192.168.10.0/24 is variably subnetted, 3 subnets, 3 masks
192.168.10.64/26 is directly connected, FastEthernet0/1
192.168.10.32/28 is directly connected, FastEthernet0/0
192.168.10.0/27 is directly connected, Serial0/0.1
192.168.20.0/30 is subnetted, 1 subnets
O IA
192.168.20.0 [110/128] via 192.168.10.1, 00:00:27, Serial0/0.1
192.168.50.0/32 is subnetted, 1 subnets
C
192.168.50.4 is directly connected, Loopback0
O*N2 0.0.0.0/0 [110/1] via 192.168.10.1, 00:00:22, Serial0/0.1
Case Study: Address Summarization
Alt hough st ub areas conserve resources wit hin non- backbone areas by prevent ing cert ain LSAs
from ent ering, t hese areas do not hing t o conserve resources on t he backbone. All addresses
wit hin an area are st ill advert ised out t o t he backbone. This sit uat ion is where address
sum m arizat ion can help. Like st ub areas, address sum m arizat ion conserves resources by
reducing t he num ber of LSAs flooded. I t also conserves resources by hiding inst abilit ies. For
exam ple, a " flapping" subnet will cause LSAs t o be flooded t hroughout t he net work at each st at e
t ransit ion. However, if t hat subnet address is subsum ed by a sum m ary address, t he individual
subnet and it s inst abilit ies are no longer advert ised.
The Cisco OSPF can perform t wo t ypes of address sum m arizat ion: int er- area sum m arizat ion and
ext ernal rout e sum m arizat ion. I nt er- area sum m arizat ion is, as t he nam e im plies, t he
sum m arizat ion of addresses bet ween areas; t his t ype of sum m arizat ion is always configured on
ABRs. Ext ernal rout e sum m arizat ion allows a set of ext ernal addresses t o be redist ribut ed int o
an OSPF dom ain as a sum m ary address and is configured on ASBRs. I nt er- area sum m arizat ion is
covered in t his sect ion, and ext ernal rout e sum m arizat ion is covered in Chapt er 11 .
I n Figure 8- 48 , area 15 cont ains eight subnet s: 10.0.0.0/ 16 t hrough 10.7.0.0/ 16. Figure 8- 49
shows t hat t hese addresses can be represent ed wit h t he single sum m ary address 10.0.0.0/ 13.
Figu r e 8 - 4 8 . Th e a ddr e sse s in a r e a s 1 5 a n d 2 5 ca n be su m m a r ize d in t o
t h e ba ck bon e a r e a .
[View full size image]
Figu r e 8 - 4 9 . Th e su m m a r y a ddr e ss 1 0 .0 .0 .0 / 1 3 r e pr e se n t s t h e r a n ge
of a ddr e sse s fr om 1 0 .0 .0 .0 / 1 6 t o 1 0 .7 .0 .0 / 1 6 .
11111111111111110000000000000000
00001010000000000000000000000000
00001010000000010000000000000000
00001010000000100000000000000000
00001010000000110000000000000000
00001010000001000000000000000000
00001010000001010000000000000000
00001010000001100000000000000000
00001010000001110000000000000000
00001010000000000000000000000000
= 16- bit m ask
= 10.0.0.0/ 16
= 10.1.0.0/ 16
= 10.2.0.0/ 16
= 10.3.0.0/ 16
= 10.4.0.0/ 16
= 10.5.0.0/ 16
= 10.6.0.0/ 16
= 1 0 .7 .0 .0 / 1 6
= 10.0.0.0/ 13
An ABR can be configured t o advert ise a sum m ary address eit her int o t he backbone area or int o
a non- backbone area. Best pract ice dict at es t hat a non- backbone area's addresses should be
sum m arized int o t he backbone by it s own ABR, as opposed t o having all ot her ABRs sum m arize
t he area int o t heir areas. Then, from t he backbone area, t he sum m ary will be advert ised across
t he backbone and int o t he ot her areas. This bot h sim plifies t he rout er configurat ions and reduces
t he size of t he LS dat abase in t he backbone.
The a r e a r a n ge com m and specifies t he area t o which t he sum m ary address belongs, t he
sum m ary address, and t he address m ask. Recall from Chapt er 7 , " Enhanced I nt erior Gat eway
Rout ing Prot ocol ( EI GRP) ," t hat when a sum m ary rout e is configured for EI GRP, a rout e t o t he
null int erface is aut om at ically ent ered int o t he rout e t able t o prevent black holes and rout e
loops. [ 30] OSPF also ent ers t his rout e aut om at ically. I n t he I OS m ainline versions earlier t hen
12.1, however, t he rout e t o t he null int erface will not be ent ered aut om at ically. I n addit ion, in
I OS releases t hat have t he capabilit y of creat ing t his rout e, t he rout er can be configured t o not
inst all it in t he rout e t able using t he com m and n o disca r d- r ou t e . Therefore, whenever you are
configuring sum m ary rout es wit hin an OSPF dom ain, be sure t o verify t hat t he rout e for t he
sum m ary address, point ing t o t he null int erface, is creat ed. I f it is not aut om at ically creat ed, be
sure t o add it or t o issue t he disca r d- r ou t e com m and.
[30] The
reasons for this route are discussed in more detail, with examples, in Chapters 11 , "Route Redistribution," and 12 ,
"Default Routes and On-Demand Routing."
Exam ple 8- 58 shows Pena's OSPF configurat ion.
Ex a m ple 8 - 5 8 . Pe n a 's OSPF con figu r a t ion .
router ospf 1
network 10.0.0.0 0.7.255.255 area 15
network 10.8.0.0 0.7.255.255 area 0
area 15 range 10.0.0.0 255.248.0.0
!
ip route 10.0.0.0 255.248.0.0 Null0
Figure 8- 49 shows t hat t he range of addresses represent ed by 10.0.0.0/ 13 is cont iguoust hat is,
t he t hree bit s t hat are sum m arized const it ut e every com binat ion from 000 t o 111. The addresses
in area 25 are different . These do not form a cont iguous range. They m ay, however, st ill be
sum m arized wit h t he Exam ple 8- 59 configurat ion at Hurd.
Ex a m ple 8 - 5 9 . H u r d's OSPF con figu r a t ion .
router ospf 1
network 10.8.0.0 0.0.255.255 area 0
network 172.20.0.0 0.0.255.255 area 25
area 25 range 172.16.0.0 255.240.0.0
!
ip route 172.16.0.0 255.240.0.0 Null0
This sum m ary will work, even if som e of t he addresses in t he range appear elsewhere in t he
net work. I n Figure 8- 48 , net work 172.17.0.0/ 16 is in area 15, alt hough it belongs t o t he set of
addresses being sum m arized from area 25. Pena advert ises t his address int o t he backbone area,
where Hurd learns it and advert ises it int o area 25. The accom panying m ask is m ore specific
( t hat is, longer) t han t he m ask of t he sum m ary address 172.16.0.0/ 12; because OSPF is
classless, it will rout e dest inat ion addresses belonging t o 172.17.0.0 t o t he correct dest inat ion.
Alt hough t he address configurat ion of Figure 8- 48 will work, it is an undesirable design pract ice.
The point of sum m arizat ion is t o conserve resources; net work 172.17.1.0/ 24 m ust be advert ised
across t he backbone independent ly of 172.16.0.0/ 12. Such a design also creat es t he pot ent ial
for rout e loops if default addresses are used. This problem is discussed in Chapt er 12 .
Not ice also in Figure 8- 48 t hat subnet s 172.16.27.0/ 25 ( at Gorm an) and 172.16.27.192/ 29 ( at
Okeeffe) are discont iguous. Again because OSPF is a classless rout ing prot ocol, Gorm an and
Okeeffe do not act as net work border rout ers. The subnet s and t heir m asks are advert ised int o
net work 172.20.0.0, and no rout ing am biguit ies will occur.
The default behavior of t he a r e a r a n ge com m and is t o advert ise t he range specified. I t m ight be
desirable t o suppress t he advert isem ent of a range of addresses. The a r e a r a n ge com m and
wit h t he keyword n ot - a dv e r t ise causes prefixes in t he specified range t o be suppressed. They
are not advert ised in LSAs.
Pena is configured t o suppress t he range 172.17.0.0/ 16. Pena's configurat ion becom es as
displayed in Exam ple 8- 60 .
Ex a m ple 8 - 6 0 . Pe n a is con figu r e d t o su ppr e ss t h e a dve r t ise m e n t of a
r a n ge of a ddr e sse s.
router ospf 1
area 15 range 10.0.0.0 255.248.0.0
area 15 range 172.17.0.0 255.255.0.0 not-advertise
network 10.0.0.0 0.7.255.255 area 15
network 10.8.0.0 0.7.255.255 area 0
network 172.17.0.0 0.0.255.255 area 15
This com m and has t he desired affect of suppressing t he 172.17.0.0/ 16 range, but it has an
undesirable consequence. Look at t he rout e t able on Hurd before ( Exam ple 8- 61 ) and aft er
( Exam ple 8- 62 ) ent ering t he com m and.
Ex a m ple 8 - 6 1 . H u r d's r ou t e t a ble be for e Pe n a su ppr e sse d a n a ddr e ss
r a n ge sh ow s t w o e x t e r n a l r ou t e s.
Hurd#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
172.17.0.0/16 is variably subnetted, 2 subnets, 2 masks
172.17.1.0/24 [110/11] via 10.8.1.2, 00:03:29, Ethernet0/0
172.17.0.1/32 [110/12] via 10.8.1.2, 00:03:29, Ethernet0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
O
172.16.27.192/29 [110/65] via 172.20.1.6, 00:03:29, Serial0/0.2
O
172.16.27.0/25 [110/65] via 172.20.1.2, 00:03:29, Serial0/0.1
172.20.0.0/30 is subnetted, 2 subnets
C
172.20.1.0 is directly connected, Serial0/0.1
C
172.20.1.4 is directly connected, Serial0/0.2
10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C
10.8.1.0/24 is directly connected, Ethernet0/0
O IA
10.0.0.0/13 [110/11] via 10.8.1.2, 00:03:30, Ethernet0/0
O E2
10.100.0.0/16 [110/10] via 10.8.1.2, 00:03:30, Ethernet0/0
O E2
10.101.0.0/16 [110/10] via 10.8.1.2, 00:03:32, Ethernet0/0
S
172.16.0.0/12 is directly connected, Null0
O IA
O IA
Ex a m ple 8 - 6 2 . H u r d's r ou t e t a ble a ft e r Pe n a su ppr e sse s a r a n ge sh ow s
t h e e x t e r n a l r ou t e s a r e n o lon ge r in t h e r ou t e t a ble .
Hurd#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
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
172.16.27.192/29 [110/65] via 172.20.1.6, 00:06:11, Serial0/0.2
172.16.27.0/25 [110/65] via 172.20.1.2, 00:06:11, Serial0/0.1
172.20.0.0/30 is subnetted, 2 subnets
C
172.20.1.0 is directly connected, Serial0/0.1
C
172.20.1.4 is directly connected, Serial0/0.2
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C
10.8.1.0/24 is directly connected, Ethernet0/0
O IA
10.0.0.0/13 [110/11] via 10.8.1.2, 00:06:12, Ethernet0/0
S
172.16.0.0/12 is directly connected, Null0
O
O
The ext ernal rout es learned via RI P on Wyet h, 10.100.0.0 and 10.101.0.0, are no longer in
Hurd's rout e t able. Exam ple 8- 63 displays t he OSPF dat abase for 10.100.0.0 on Hurd. Not ice t he
specified forwarding address.
Ex a m ple 8 - 6 3 . Th e t ype 5 e x t e r n a l lin k st a t e sh ow s t h e for w a r din g
a ddr e ss t o be t h e a ddr e ss of t h e r ou t e r t h a t or igin a t e d t h e e x t e r n a l
r ou t e .
Hurd#show ip ospf data external
OSPF Router with ID (172.20.1.5) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 421
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.100.0.0 (External Network Number )
Advertising Router: 172.17.0.1
LS Seq Number: 80000001
Checksum: 0xF1CC
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 10
Forward Address: 172.17.0.1
External Route Tag: 0
The forwarding address is t he loopback int erface of Wyet h. I f t he forwarding address in an
ext ernal LSA is specified, and t his address is not reachable, t he address cont ained in t he LSA is
not insert ed int o t he rout e t able. When Pena t ranslat es t ype 7 NSSA LSAs int o t ype 5 LSAs, by
default t he forwarding address is t ransferred from t he t ype 7 t o t he t ype 5. The ABR can be
configured t o suppress t he forwarding address during t he t ranslat ion, replacing t he specified
address wit h t he address 0.0.0.0. When anot her rout er receives t he t ype 5 ext ernal LSA wit h t he
forwarding address suppressed, inst ead of t rying t o direct t raffic for t he ext ernal address t o t he
forwarding address, t he receiving rout er will at t em pt t o direct t he t raffic t o t he t ype 7 t o t ype 5
t ranslat ing ABR rout er.
Exam ple 8- 64 has Pena's new configurat ion.
Ex a m ple 8 - 6 4 . Pe n a 's con figu r a t ion su ppr e sse s t h e in clu sion of a
for w a r din g a ddr e ss in t r a n sla t e d t ype 5 LSAs.
router ospf 1
area 15 range 10.0.0.0 255.248.0.0
area 15 range 172.17.0.0 255.255.0.0 not-advertise
network 10.0.0.0 0.7.255.255 area 15
network 10.8.0.0 0.7.255.255 area 0
network 172.17.0.0 0.0.255.255 area 15
area 15 nssa translate type7 suppress-fa
Exam ple 8- 65 shows Hurd's ext ernal dat abase ent ry for 10.100.0.0, and Exam ple 8- 66 shows
Hurd's new rout e t able.
Ex a m ple 8 - 6 5 . Th e e x t e r n a l OSPF da t a ba se e n t r y sh ow s a su ppr e sse d
for w a r din g a ddr e ss.
Hurd#show ip ospf data external
OSPF Router with ID (172.20.1.5) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 13
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.100.0.0 (External Network Number )
Advertising Router: 172.17.0.1
LS Seq Number: 80000002
Checksum: 0xA9D2
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 10
Forward Address: 0.0.0.0
External Route Tag: 0
Ex a m ple 8 - 6 6 . Th e e x t e r n a l r ou t e s for 1 0 .1 0 0 .0 .0 a n d 1 0 .1 0 1 .0 .0 a r e
in se r t e d in t o t h e r ou t e t a ble a ft e r su ppr e ssin g t h e for w a r din g a ddr e ss.
Hurd#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
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
172.16.27.192/29 [110/65] via 172.20.1.6, 00:09:32, Serial0/0.2
172.16.27.0/25 [110/65] via 172.20.1.2, 00:09:32, Serial0/0.1
172.20.0.0/30 is subnetted, 2 subnets
C
172.20.1.0 is directly connected, Serial0/0.1
C
172.20.1.4 is directly connected, Serial0/0.2
10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C
10.8.1.0/24 is directly connected, Ethernet0/0
O IA
10.0.0.0/13 [110/11] via 10.8.1.2, 00:09:33, Ethernet0/0
O E2
10.100.0.0/16 [110/10] via 10.8.1.2, 00:00:46, Ethernet0/0
O E2
10.101.0.0/16 [110/10] via 10.8.1.2, 00:00:46, Ethernet0/0
S
172.16.0.0/12 is directly connected, Null0
O
O
The forwarding address displayed in Hurd's dat abase is now 0.0.0.0 and t he t wo ext ernal rout es
are back in t he rout e t able.
Case Study: Filtering Between Areas
Anot her LAN is added t o Okeeffe. Devices on t he LAN are t o be accessed by ot her devices wit hin
area 25, but not from t he rest of t he net work. Anot her way t o lim it and cont rol t he addresses
t hat are exchanged bet ween areas is t o configure LSA t ype 3 filt ering on ABRs. The ABRs can
filt er net work addresses being advert ised by t ype 3 LSAs eit her int o or out of an area.
A LAN wit h address 192.168.1.0/ 24 is added t o Okeeffe in area 25. This address is advert ised in
LSAs t hroughout t he net work even t hough it is only t o be accessed by ot her devices in area 25.
To prevent t he address from being advert ised out side area 25, t ype 3 LSA filt ering is configured
on Hurd as shown in Exam ple 8- 67 .
Ex a m ple 8 - 6 7 . H u r d u se s t ype 3 LSA filt e r in g.
router ospf 1
area 25 filter-list prefix area25outbound out
!
ip prefix-list area25outbound seq 10 deny 192.168.1.0/24
ip prefix-list area25outbound seq 20 permit 0.0.0.0/0 le 32
The OSPF com m and a r e a PI D filt e r - list pr e fix specifies t he nam e of a filt er list t o apply t o
out bound or inbound LSAs. Out bound list s filt er LSAs sent int o areas ot her t hen t he one specified
by t he com m and. I n our exam ple, t he list filt ers LSAs wit h addresses originat ing in area 25 and
being sent int o non- area 25 areas, such as area 0. I nbound list s filt er LSAs as t hey are sent int o
area 25.
The first line of t he prefix list is clear. The st at em ent denies address 192.168.1.0/ 24 from being
advert ised in a t ype 3 LSA. The second line perm it s everyt hing else: every address wit h a m ask
from lengt h 0 t o lengt h 32 bit s. This second line is required because t here is a im plicit " deny all"
st at em ent at t he end of t he prefix list . 192.168.1.0/ 24 is prevent ed from being sent in t ype 3
LSAs out side of area 25. Every ot her address is perm it t ed.
Case Study: Authentication
OSPF packet s can be aut hent icat ed t o prevent inadvert ent or int ent ional int roduct ion of bad
rout ing inform at ion. Table 8- 8 list s t he t ypes of aut hent icat ion available. Null aut hent icat ion
( t ype 0) , which m eans no aut hent icat ion inform at ion is included in t he packet header, is t he
default . Aut hent icat ion using sim ple clear- t ext passwords ( t ype 1) or MD5 crypt ographic
checksum s ( t ype 2) can be configured. When aut hent icat ion is configured, it m ust be configured
for an ent ire area.
I f increased net work securit y is t he obj ect ive, t ype 1 aut hent icat ion should be used only when
devices wit hin an area cannot support t he m ore secure t ype 2 aut hent icat ion. Clear- t ext
aut hent icat ion leaves t he net work vulnerable t o a " sniffer at t ack," in which packet s are capt ured
by a prot ocol analyzer and t he passwords are read ( see Chapt er 6 and especially Figure 6.8 ) .
However, t ype 1 aut hent icat ion can be useful when perform ing OSPF reconfigurat ions. For
exam ple, separat e passwords can be used on " old" OSPF rout ers and " new" OSPF rout ers
sharing a com m on broadcast net work t o prevent t hem from t alking t o each ot her.
To configure t ype 1 aut hent icat ion for an area, t he com m and ip ospf a u t h e n t ica t ion - k e y is
used t o assign a password of up t o eight oct et s t o each int erface at t ached t o t he area. The
passwords do not have t o be t he sam e t hroughout t he area, but m ust be t he sam e bet ween
neighbors. Type 1 aut hent icat ion is t hen enabled by ent ering t he a r e a a u t h e n t ica t ion
com m and t o t he OSPF configurat ion.
Referring t o Figure 8- 48 , t ype 1 aut hent icat ion is enabled for areas 0 and 25. Exam ple 8- 68
displays Hurd's configurat ion.
Ex a m ple 8 - 6 8 . H u r d is con figu r e d t o u se cle a r t e x t a u t h e n t ica t ion .
interface Ethernet 0/0
ip address 10.8.1.1 255.255.255.0
ip ospf authentication-key santafe
interface Serial 0/0.1
ip address 172.20.1.1 255.255.255.252
ip ospf authentication-key taos
interface Serial 0/0.2
ip address 172.20.1.5 255.255.255.252
ip ospf authentication-key abiquiu
router ospf 1
network 10.8.0.0 0.0.255.255 area 0
network 172.20.0.0 0.0.255.255 area 25
area 25 range 172.16.0.0 255.240.0.0
area 0 authentication
area 25 authentication
ip route 172.16.0.0 255.240.0.0 null0
The password " sant afe" is used bet ween Hurd and Pena; " t aos" is used bet ween Hurd and
Gorm an, and " abiquiu" is used bet ween Hurd and Okeeffe.
The MD5 algorit hm , used by t ype 2 aut hent icat ion, com put es a hash value from t he OSPF packet
cont ent s and a password ( or key) . This hash value is t ransm it t ed in t he packet , along wit h a key
I D and a non- decreasing sequence num ber. The receiver, knowing t he sam e password, will
calculat e it s own hash value. I f not hing in t he m essage has changed, t he receiver's hash value
should m at ch t he sender's value t ransm it t ed wit h t he m essage. The key I D allows rout ers t o
reference m ult iple passwords, m aking password changes easier and m ore secure. An exam ple of
password m igrat ion is included in t his case st udy. The sequence num ber prevent s " replay
at t acks," in which OSPF packet s are capt ured, m odified, and ret ransm it t ed t o a rout er.
To configure t ype 2 aut hent icat ion for an area, t he com m and ip ospf m e ssa ge - dige st - k e y
m d5 assigns a password of up t o 16 byt es and key I D bet ween 1 and 255 t o each int erface
at t ached t o t he area. Like t ype 1, t he passwords do not have t o be t he sam e t hroughout t he
area, but bot h t he key I D and t he password m ust be t he sam e bet ween neighbors. Type 2
aut hent icat ion is t hen enabled by ent ering t he a r e a a u t h e n t ica t ion m e ssa ge - dige st
com m and t o t he OSPF configurat ion.
Hurd is configured t o use t ype 2 aut hent icat ion as shown in Exam ple 8- 69 .
Ex a m ple 8 - 6 9 . H u r d is con figu r e d t o u se M D 5 a u t h e n t ica t ion .
interface Ethernet 0/0
ip address 10.8.1.1 255.255.255.0
ip ospf message-digest-key 5 md5 santafe
interface Serial 0/0.1
ip address 172.20.1.1 255.255.255.252
ip ospf message-digest-key 10 md5 taos
interface Serial 0/0.2
ip address 172.20.1.5 255.255.255.252
ip ospf message-digest-key 15 md5 abiquiu
router ospf 1
network 10.8.0.0 0.0.255.255 area 0
network 172.20.0.0 0.0.255.255 area 25
area 25 range 172.16.0.0 255.240.0.0
area 0 authentication message-digest
area 25 authentication message-digest
ip route 172.16.0.0 255.240.0.0 null0
The key allows t he password t o be changed wit hout having t o disable aut hent icat ion. For
exam ple, t o change t he password bet ween Hurd and Okeeffe, t he new password would be
configured wit h a different key. Exam ple 8- 70 shows Hurd's configurat ion.
Ex a m ple 8 - 7 0 . H u r d is con figu r e d w it h a n e w M D 5 k e y.
interface Serial0/0.2
ip address 172.20.1.5 255.255.255.252
ip ospf message-digest-key 15 md5 abiquiu
ip ospf message-digest-key 20 md5 steiglitz
Hurd will now send duplicat e copies of each OSPF packet out S0/ 0.2; one will be aut hent icat ed
wit h key 15, t he ot her wit h key 20. When Hurd begins receiving OSPF packet s from Okeeffe
aut hent icat ed wit h key 20, it will st op sending packet s wit h key 15. Once t he new key is in use,
t he old key can be rem oved from bot h rout ers wit h t he com m and n o ip ospf m e ssa ge - dige st k e y 1 5 m d5 a biqu iu .
The passwords in an operat ional net work should never be as predict able as t he ones used in
t hese exam ples. Adding t he com m and se r vice pa ssw or d- e n cr ypt ion t o t he configurat ion file
of all rout ers using aut hent icat ion is also wise. This change will cause t he rout er t o encrypt t he
passwords in any display of t he configurat ion file, t hereby guarding against t he password being
learned by sim ply observing a t ext copy of t he rout er's configurat ion. Wit h encrypt ion, Exam ple
8- 71 is a display of what Hurd's configurat ion would include.
Ex a m ple 8 - 7 1 . Pa ssw or d e n cr ypt ion is con figu r e d on H u r d t o e n cr ypt
t h e pa ssw or d in t h e displa y of t h e con figu r a t ion file .
service password-encryption
!
interface Ethernet0/0
ip address 10.8.1.1 255.255.255.0
ip ospf message-digest-key 5 md5 7 001712008105A0D03
!
interface Serial0/0.1
ip address 172.20.1.1 255.255.255.252
ip ospf message-digest-key 10 md5 7 03105A0415
!
interface Serial0/0.2
ip address 172.20.1.5 255.255.255.252
ip ospf message-digest-key 20 md5 7 070E23455F1C1010
I n t he aut hent icat ion configurat ion of t he ot her prot ocols discussed in t his book, key- chains were
used t o configure t he passwords, or key- st rings as t hey are called. OSPF does not support keychain configurat ion at t he t im e of t his writ ing.
Case Study: Virtual Links
Figure 8- 50 shows an net work wit h a poorly designed backbone area. I f t he link bet ween rout ers
Hokusai and Hiroshige fails, t he backbone will be part it ioned. As a result , rout ers Sesshiu and
Okyo will be unable t o com m unicat e wit h each ot her. I f t hese t wo rout ers are ABRs t o separat e
areas, int er- area t raffic bet ween t hose areas will also be blocked.
Figu r e 8 - 5 0 . A fa ilu r e of t h e lin k be t w e e n H ok u sa i a n d H ir osh ige w ill
pa r t it ion t h e ba ck bon e a r e a .
The best solut ion t o t his vulnerabilit y is t o add anot her link t o t he backbone areabet ween
Sesshiu and Okyo, for inst ance. An int erim solut ion, unt il t he backbone can be im proved, is t o
creat e a virt ual link bet ween Hokusai and Hiroshige t hrough area 100.
Virt ual links are always creat ed bet ween ABRs, at least one of which m ust be connect ed t o area
0. [ 31] At each ABR, t he a r e a vir t u a l- lin k com m and, added t o t he OSPF configurat ion, specifies
t he area t hrough which t he virt ual link will t ransit and t he Rout er I D of t he ABR at t he far end of
t he link. A virt ual link is configured bet ween Hokusai and Hiroshige as shown in Exam ple 8- 72
and Exam ple 8- 73 .
[31] When
a virtual link is used to connect an area to the backbone through a non-backbone area, one of the ABRs will be
between the two non-backbone areas.
Ex a m ple 8 - 7 2 . H ok u sa i's vir t u a l lin k con figu r a t ion .
router ospf 10
network 192.168.100.1 0.0.0.0 area 0
network 192.168.100.29 0.0.0.0 area 0
network 192.168.100.21 0.0.0.0 area 100
area 100 virtual-link 192.168.100.33
Ex a m ple 8 - 7 3 . H ir osh ige 's vir t u a l lin k con figu r a t ion .
router ospf 10
network 192.168.100.2 0.0.0.0 area 0
network 192.168.100.33 0.0.0.0 area 0
network 192.168.100.25 0.0.0.0 area 100
area 100 virtual-link 192.168.100.29
Packet s will norm ally t ravel bet ween Sesshiu and Okyo on t he backbone link bet ween Hokusai
and Hiroshige. I f t hat link fails, t he virt ual link will be used. Alt hough each rout er sees t he link as
an unnum bered point - t o- point net work ( Exam ple 8- 74 ) , in realit y t he packet s are being rout ed
via Kuj om ot o. [ 32]
[32] The
output of the show ip ospf virtual-link command might be slightly different, depending upon which IOS version you
are using.
Ex a m ple 8 - 7 4 . Th e st a t e of a vir t u a l lin k ca n be obse r ve d w it h t h e
com m a n d sh ow ip ospf vir t u a l- lin k .
Hokusai#show ip ospf virtual-link
Virtual Link OSPF_VL1 to router 192.168.100.33 is up
Run as demand circuit
DoNotAge LSA not allowed (Number of DCbitless LSA is 2).
Transit area 100, via interface Serial0, Cost of using 128
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:00
Adjacency State FULL (Hello suppressed)
Hokusai#
Case Study: OSPF on NBMA Networks
Nonbroadcast m ult iaccess net works such as X.25, Fram e Relay, and ATM present a problem for
OSPF. Mult iaccess m eans t hat t he NBMA " cloud" is a single net work t o which m ult iple devices are
at t ached, t he sam e as Et hernet or Token Ring net works ( Figure 8- 51 ) . But unlike Et hernet and
Token Ring, which are broadcast net works, non- br oadcast m eans a packet sent int o t he net work
m ight not be seen by all ot her rout ers at t ached t o t he net work. Because an NBMA net work is
m ult i- access, OSPF will want t o elect a DR and BDR. But because an NBMA net work is nonbroadcast , t here is no guarant ee t hat all at t ached rout ers will receive t he Hellos of all ot her
rout ers. Therefore, all rout ers m ight not aut om at ically learn about all it s neighbors, and DR
elect ion would not funct ion correct ly.
Figu r e 8 - 5 1 . Rou t in g pr ot ocols vie w N BM A n e t w or k s a s a sin gle su bn e t
t o w h ich m u lt iple de vice s a r e con n e ct e d. Bu t w h e n a n N BM A n e t w or k
is pa r t ia lly m e sh e d, a s it is h e r e , n ot a ll a t t a ch e d r ou t e r s h a ve dir e ct
con n e ct ivit y w it h a ll ot h e r a t t a ch e d r ou t e r s.
This sect ion exam ines several solut ions t o t he NBMA problem . The select ion of a part icular
solut ion depends on t he charact erist ics of t he net work upon which t he solut ion is t o be
im plem ent ed.
The oldest solut ion, pert inent t o pre- 10.0 versions of t he Cisco I OS, is t o m anually ident ify each
rout er's neighbors and est ablish t he DR, using t he n e igh bor com m and. Figure 8- 52 shows a
Fram e Relay net work wit h four at t ached rout ers.
Figu r e 8 - 5 2 . Se ve r a l opt ion s e x ist for con figu r in g OSPF on t h is N BM A
n e t w or k .
Because of t he part ially m eshed hub- and- spoke configurat ion of t he PVCs in Figure 8- 52 ,
Rem brandt m ust becom e t he DR. As t he hub, it is t he only rout er direct ly connect ed t o all t he
ot her rout ers. The configurat ions of t he four rout ers are shown in Exam ple 8- 75 t hrough
Exam ple 8- 78 .
Ex a m ple 8 - 7 5 . Re m br a n dt 's con figu r a t ion .
interface Serial0
encapsulation frame-relay
ip address 172.16.2.1 255.255.255.0
frame-relay map ip 172.16.2.2 100
frame-realy map ip 172.16.2.3 300
frame-relay map ip 172.16.2.4 500
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
neighbor 172.16.2.2
neighbor 172.16.2.3
neighbor 172.16.2.4
Ex a m ple 8 - 7 6 . H a ls's con figu r a t ion spe cifyin g a n e igh bor pr ior it y.
interface Serial0
encapsulation frame-relay
ip address 172.16.2.2 255.255.255.0
frame-relay map ip 172.16.2.1 600
frame-relay map ip 172.16.2.3 600
frame-relay map ip 172.16.2.4 600
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
neighbor 172.16.2.1 priority 10
Ex a m ple 8 - 7 7 . Va n dyck 's con figu r a t ion spe cifyin g a n e igh bor pr ior it y.
interface Serial0
encapsulation frame-relay
ip address 172.16.2.3 255.255.255.0
frame-relay map ip 172.16.2.1 400
frame-relay map ip 172.16.2.2 400
frame-relay map ip 172.16.2.4 400
!
router ospf 1
network 172.16.0.0 0.0.255.255 are a 0
neighbor 172.16.2.1 priority 10
Ex a m ple 8 - 7 8 . Br u e gh e l's con figu r a t ion spe cifyin g a n e igh bor pr ior it y.
interface Serial0
encapsulation frame-relay
ip address 172.16.2.4 255.255.255.0
frame-relay map ip 172.16.2.1 200
frame-relay map ip 172.16.2.2 200
frame-relay map ip 172.16.2.3 200
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
neighbor 172.16.2.1 priority 10
The n e igh bor com m and configures Rem brandt wit h t he I P addresses of t he int erfaces of it s
t hree neighbors. The default priorit y is zero; by not changing t he default at Rem brandt , none of
it s neighbors is eligible t o becom e t he DR or BDR.
The ot her t hree rout ers are configured wit h only Rem brandt as a neighbor; t he priorit y is set t o
10, which m eans Rem brandt will becom e t he DR. By m aking Rem brandt t he DR, t he PVCs
exact ly em ulat e t he adj acencies t hat would have form ed if t he four rout ers had been connect ed
t o a broadcast m ult i- access net work. OSPF packet s will now be unicast t o t he configured
neighbor addresses.
To repeat , t he n e igh bor com m and is necessary only wit h old ( pre- 10.0) versions of I OS. A
newer solut ion is t o use t he ip ospf n e t w or k com m and t o change t he default OSPF net work
t ype.
One opt ion wit h t his com m and is t o change t he net work t ype t o broadcast , wit h ip ospf
n e t w or k br oa dca st ent ered at every Fram e Relay int erface. This change will cause t he NBMA
cloud t o be viewed as a broadcast net work; t he configurat ions of t he four rout ers are shown in
Exam ple 8- 79 t hrough Exam ple 8- 82 .
Ex a m ple 8 - 7 9 . Re m br a n dt 's Fr a m e Re la y in t e r fa ce is con figu r e d a s a n
OSPF br oa dca st n e t w or k .
interface Serial0
encapsulation frame-relay
ip address 172.16.2.1 255.255.255.0
ip ospf network broadcast
ip ospf priority 10
frame-relay map ip 172.16.2.2 100 broadcast
frame-realy map ip 172.16.2.3 300 broadcast
frame-relay map ip 172.16.2.4 500 broadcast
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
Ex a m ple 8 - 8 0 . H a ls's Fr a m e Re la y in t e r fa ce is con figu r e d a s a n OSPF
br oa dca st n e t w or k .
interface Serial0
encapsulation frame-relay
ip address 172.16.2.2 255.255.255.0
ip ospf network broadcast
ip ospf priority 0
frame-relay map ip 172.16.2.1 600 broadcast
frame-relay map ip 172.16.2.3 600 broadcast
frame-relay map ip 172.16.2.4 600 broadcast
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
Ex a m ple 8 - 8 1 . Va n dyck 's Fr a m e Re la y in t e r fa ce is con figu r e d a s a n
OSPF br oa dca st n e t w or k .
interface Serial0
encapsulation frame-relay
ip address 172.16.2.3 255.255.255.0
ip ospf network broadcast
ip ospf priority 0
frame-relay map ip 172.16.2.1 400 broadcast
frame-relay map ip 172.16.2.2 400 broadcast
frame-relay map ip 172.16.2.4 400 broadcast
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
Ex a m ple 8 - 8 2 . Br u e gh e l's Fr a m e Re la y in t e r fa ce is con figu r e d a s a n
OSPF br oa dca st n e t w or k .
interface Serial0
encapsulation frame-relay
ip address 172.16.2.4 255.255.255.0
ip ospf network broadcast
ip ospf priority 0
frame-relay map ip 172.16.2.1 200 broadcast
frame-relay map ip 172.16.2.2 200 broadcast
frame-relay map ip 172.16.2.3 200 broadcast
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
Not e in t his exam ple t hat t he priorit y of Rem brandt 's int erface is set t o 10, and t he priorit y of
t he ot her int erfaces is set t o 0. This will, again, ensure t hat Rem brandt is t he DR. Not e also t hat
t he st at ic Fram e Relay m apping com m ands are set t o forward broadcast and m ult icast
addresses.
An alt ernat ive t o influencing t he DR elect ion is t o im plem ent a fully m eshed t opology in which
every rout er has a PVC t o every ot her rout er. From t he st andpoint of t he rout er, t his solut ion is
act ually t he m ost efficient of all t he NBMA im plem ent at ion alt ernat ives. The obvious drawback of
t his approach is m onet ary cost . I f t here are n rout ers, n (n 1) / 2 PVCs will be necessary t o creat e
a fully m eshed t opology. For exam ple, t he 4 rout ers of Figure 8- 52 would need 6 PVCs for a full
m esh; 16 rout ers would require 120 PVCs.
Anot her opt ion is t o avoid t he DR/ BDR elect ion process alt oget her, by changing t he net work t ype
t o point - t o- m ult ipoint . Point - t o- m ult ipoint net works t reat t he PVCs as a collect ion of point - t opoint links; t herefore, no DR/ BDR elect ion t akes place. I n m ult ivendor environm ent s, point - t om ult ipoint m ight be t he only alt ernat ive t o broadcast net works.
I n t he configurat ions in Exam ple 8- 83 t hrough Exam ple 8- 86 , t he OSPF net work t ype associat ed
wit h each int erface is changed t o point - t o- m ult ipoint .
Ex a m ple 8 - 8 3 . Re m br a n dt 's Fr a m e Re la y in t e r fa ce is con figu r e d a s a n
OSPF poin t - t o- m u lt ipoin t n e t w or k .
interface Serial0
encapsulation frame-relay
ip address 172.16.2.1 255.255.255.0
ip ospf network point-to-multipoint
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
Ex a m ple 8 - 8 4 . H a ls's Fr a m e Re la y in t e r fa ce is con figu r e d a s a n OSPF
poin t - t o- m u lt ipoin t n e t w or k .
interface Serial0
encapsulation frame-relay
ip address 172.16.2.2 255.255.255.0
ip ospf network point-to-multipoint
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
Ex a m ple 8 - 8 5 . Va n dyck 's Fr a m e Re la y in t e r fa ce is con figu r e d a s a n
OSPF poin t - t o- m u lt ipoin t n e t w or k .
interface Serial0
encapsulation frame-relay
ip address 172.16.2.3 255.255.255.0
ip ospf network point-to-multipoint
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
Ex a m ple 8 - 8 6 . Br u e gh e l's Fr a m e Re la y in t e r fa ce is con figu r e d a s a n
OSPF poin t - t o- m u lt ipoin t n e t w or k .
interface Serial0
encapsulation frame-relay
ip address 172.16.2.4 255.255.255.0
ip ospf network point-to-multipoint
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
These configurat ions t ake advant age of t he Fram e Relay inverse ARP funct ion t o dynam ically
m ap net work- level addresses t o t he DLCI s, inst ead of using t he st at ic m ap com m ands shown in
t he previous exam ples. St at ic m aps can st ill be used if desired.
The OSPF point - t o- m ult ipoint net work t ype t reat s t he underlying net work as a collect ion of
point - t o- point links rat her t han a m ult i- access net work, and OSPF packet s are m ult icast t o t he
neighbors. This sit uat ion can be problem at ic for net works whose connect ions are dynam ic, such
as Fram e Relay SVCs or ATM SVCs. Beginning wit h I OS 11.3AA, t his problem can be solved by
declaring a net work t o be bot h point - t o- m ult ipoint and non- broadcast , as in t he configurat ions in
Exam ple 8- 87 t hrough Exam ple 8- 90 .
Ex a m ple 8 - 8 7 . Re m br a n dt 's Fr a m e Re la y in t e r fa ce is con figu r e d a s a n
OSPF poin t - t o- m u lt ipoin t , n on - br oa dca st n e t w or k .
interface Serial0
ip address 172.16.2.1 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint non-broadcast
map-group Leiden
frame-relay lmi-type q933a
frame-relay svc
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
neighbor 172.16.2.2 cost 30
neighbor 172.16.2.3 cost 20
neighbor 172.16.2.4 cost 50
Ex a m ple 8 - 8 8 . H a ls's Fr a m e Re la y in t e r fa ce is con figu r e d a s a n OSPF
poin t - t o- m u lt ipoin t , n on - br oa dca st n e t w or k .
interface Serial0
ip address 172.16.2.2 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint non-broadcast
map-group Haarlem
frame-relay lmi-type q933a
frame-relay svc
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
neighbor 172.16.2.1 priority 10
Ex a m ple 8 - 8 9 . Va n dyck 's Fr a m e Re la y in t e r fa ce is con figu r e d a s a n
OSPF poin t - t o- m u lt ipoin t , n on - br oa dca st n e t w or k .
interface Serial0
ip address 172.16.2.3 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint non-broadcast
map-group Antwerp
frame-relay lmi-type q933a
frame-relay svc
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
neighbor 172.16.2.1 priority 10
Ex a m ple 8 - 9 0 . Br u e gh e l's Fr a m e Re la y in t e r fa ce is con figu r e d a s a n
OSPF poin t - t o- m u lt ipoin t , n on - br oa dca st n e t w or k .
interface Serial0
ip address 172.16.2.4 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint non-broadcast
map-group Brussels
frame-relay lmi-type q933a
frame-relay svc
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
neighbor 172.16.2.1 priority 10
Because t he net work is non- broadcast , neighbors are not discovered aut om at ically and m ust be
m anually configured. Anot her feat ure int roduced in I OS 11.3AA can be seen in Rem brandt 's
configurat ion: Cost can be assigned on a per VC basis wit h t he n e igh bor com m and.
The last solut ion is t o est ablish each PVC as an individual point - t o- point net work wit h it s own
subnet ( Figure 8- 53 ) . This solut ion is accom plished wit h subint erfaces as shown in Exam ple 891 t hough Exam ple 8- 94 .
Figu r e 8 - 5 3 . Poin t - t o- poin t su bin t e r fa ce s a llow e a ch PVC t o be
con figu r e d a s a n in dividu a l su bn e t a n d e lim in a t e t h e pr oble m of
D R/ BD R e le ct ion on N BM A n e t w or k s.
Ex a m ple 8 - 9 1 . Re m br a n dt is con figu r e d w it h poin t - t o- poin t
su bin t e r fa ce s.
interface Serial0
no ip address
encapsulation frame-relay
interface Serial0.100 point-to-point
description -------------------------- to Hals
ip address 172.16.2.1 255.255.255.252
frame-relay interface-dlci 100
interface Serial0.300 point-to-point
description -------------------------- to Vandyck
ip address 172.16.2.5 255.255.255.252
frame-relay interface-dlci 300
interface Serial0.500 point-to-point
description -------------------------- to Brueghels
ip address 172.16.2.9 255.255.255.252
frame-relay interface-dlci 500
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
Ex a m ple 8 - 9 2 . H a ls is con figu r e d w it h poin t - t o- poin t su bin t e r fa ce s.
interface Serial0
no ip address
encapsulation frame-relay
interface Serial0.600
description --------------------------- to Rembrandt
ip address 172.16.2.2 255.255.255.252
frame-relay interface-dlci 600
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
Ex a m ple 8 - 9 3 . Va n dyck is con figu r e d w it h poin t - t o- poin t
su bin t e r fa ce s.
interface Serial0
no ip address
encapsulation frame-relay
interface Serial0.400
description ---------------------------- to Rembrandt
ip address 172.16.2.6 255.255.255.252
frame-relay interface-dlci 400
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
Ex a m ple 8 - 9 4 . Br u e gh e l is con figu r e d w it h poin t - t o- poin t
su bin t e r fa ce s.
interface Serial0
no ip address
encapsulation frame-relay
interface Serial0.200
description ---------------------------- to Rembrandt
ip address 172.16.2.10 255.255.255.252
frame-relay interface-dlci 200
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
This configurat ion is t he m ost easily m anaged of all t he configurat ions of OSPF over NBMA
net works. Som e of t he advant ages are evident in t he configurat ion code, such as t he abilit y t o
use an int erface num ber t hat corresponds t o t he DLCI and t he inclusion of a descript ion line. The
m aj or advant age, however, is t he sim ple one- t o- one relat ionship bet ween rout ers.
An occasional obj ect ion t o t he use of subint erfaces is t hat each PVC m ust have it s own subnet
address. I n m ost cases, t his requirem ent should not be a problem , because OSPF support s
VLSM. As t he exam ple shows, creat ing sub- subnet s from t he subnet address t hat was assigned
t o t he cloud is an easy m at t er. And because t he PVCs are now point - t o- point links, I P
unnum bered m ay be used as an alt ernat ive t o subnet addresses. Anot her significant advant age
is in t he rout er's failure det ect ion. On point - t o- point subint erfaces, t he rout ers on bot h ends of
t he point - t o- point net work can det ect a failed virt ual circuit ( if t he Fram e Relay cloud provides
sufficient signaling) , and t he rout ing prot ocol can converge t o an alt ernat e rout e, if one exist s.
A m ore serious concern wit h subint erfaces is t hat t hey require m ore m em ory. The burden can be
significant on sm all rout ers wit h lim it ed m em ory.
Case Study: OSPF over Demand Circuits
OSPF over dem and circuit s is easily configured by adding t he com m and ip ospf de m a n d- cir cu it
t o t he int erface connect ed t o t he dem and circuit . Only one end of a point - t o- point circuit , or t he
m ult ipoint side of a point - t o- m ult ipoint circuit , needs t o be declared a dem and circuit . I n m ost
cases, OSPF over dem and circuit s should not be im plem ent ed across a broadcast m edium . On
such a net work, t he Hello packet s cannot be suppressed, and t he link will st ay up.
I f t he virt ual circuit s in Figure 8- 52 are Fram e Relay SVCs, Rem brandt 's configurat ion m ight be
as shown in Exam ple 8- 95 .
Ex a m ple 8 - 9 5 . Re m br a n dt 's OSPF de m a n d- cir cu it con figu r a t ion .
interface Serial0/0
ip address 172.16.2.1 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint non-broadcast
ip ospf demand-circuit
map-group Leiden
frame-relay lmi-type q933a
frame-relay svc
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
neighbor 172.16.2.2 cost 30
neighbor 172.16.2.3 cost 20
neighbor 172.16.2.4 cost 50
Keep t he following point s in m ind when im plem ent ing OSPF over dem and circuit s:
LSAs wit h t he DoNot Age bit set will be allowed int o an area only if all LSAs in t he area's
link- st at e dat abase have t he DC- bit set . This set t ing ensures t hat all rout ers in t he area are
capable of underst anding t he DoNot Age bit .
All rout ers of an area in which OSPF over dem and circuit s is im plem ent ed m ust be capable
of support ing it .
I f OSPF over dem and circuit s is im plem ent ed in a non- st ub area, t he rout ers in all non- st ub
areas m ust support it . The reason is t hat t he DC- bit in t ype 5 LSAs will be set , and t hese
LSAs are flooded int o all non- st ub areas.
An effort should be m ade t o im plem ent dem and circuit s only wit hin st ub, t ot ally st ubby, or
NSSA areas. Such an im plem ent at ion negat es t he need for all rout ers wit hin t he OSPF
dom ain t o support OSPF over dem and circuit s. I t also m inim izes t he num ber of changed
LSAs received as t he result of t opology changes in ot her areas, and hence prevent s excess
upt im e of t he dem and circuit .
I f OSPF over dem and circuit s is configured and a virt ual link is configured t o cross t he
dem and circuit , t he virt ual link will also be t reat ed as a dem and circuit . Ot herwise, t he
virt ual link t raffic would keep t he circuit up.
OSPF refreshes it s LSAs every 30 m inut es t o guard against an LSA becom ing corrupt ed
while it resides in t he link- st at e dat abase. Because DoNot Age LSAs are not refreshed across
a dem and circuit , t his robust ness feat ure is lost .
The refresh process occurs on each side of a dem and circuit out all ot her int erfaces, but
LSAs are not refreshed across t he link. As a result , t he sequence num bers of ot herwise
ident ical LSAs on each side of t he link m ight be different . Net work m anagem ent st at ions
m ay use cert ain MI B variables[ 33] t o verify dat abase synchronizat ion; if t he sequence
num bers do not m at ch across t he dat abases, an error m ight be falsely report ed.
[33] Specifically,
ospfExternLSACksumSum and ospfAreaLSACksumSum. These are sums of the individual LSA
checksum fields. Because the checksum calculation includes the sequence number, and because the sequence
numbers might be different, the checksums will also be different.
Troubleshooting OSPF
Troubleshoot ing OSPF can som et im es be daunt ing, especially in a large net work. However, a
rout ing problem wit h OSPF is no different t han a rout ing problem wit h any ot her rout ing
prot ocol; t he cause will be one of t he following:
Missing rout e inform at ion
I naccurat e rout e inform at ion
An exam inat ion of t he rout e t able is st ill t he prim ary source of t roubleshoot ing inform at ion.
Using t he sh ow ip ospf da t a ba se com m and t o exam ine t he various LSAs will also yield
im port ant inform at ion. For exam ple, if a link is unst able, t he LSA advert ising will change
frequent ly. This condit ion is reflect ed in a sequence num ber t hat is conspicuously higher t han
t hat of t he ot her LSAs. Anot her sign of inst abilit y is an LSA whose age never get s very high.
Keep in m ind t hat t he link- st at e dat abase of every rout er wit hin an area is t he sam e. So unless
you suspect t hat t he dat abase it self is being corrupt ed on som e rout ers, you can exam ine t he
link- st at e dat abase for t he ent ire area by exam ining a single rout er's link- st at e dat abase.
Anot her good pract ice is t o keep a copy ( hard or soft ) of t he link- st at e dat abase for each area.
When exam ining an individual rout er's configurat ion, consider t he following:
Do all int erfaces have t he correct addresses and m asks?
Do t he n e t w or k a r e a st at em ent s have t he correct inverse m asks t o m at ch t he correct
int erfaces?
Do t he n e t w or k a r e a st at em ent s put all int erfaces int o t he correct areas?
Are t he n e t w or k a r e a st at em ent s in t he correct order?
When exam ining adj acencies ( or t he lack t hereof) , consider t hese quest ions:
Are Hellos being sent from bot h neighbors?
Are t he t im ers set t he sam e bet ween neighbors?
Are t he opt ional capabilit ies set t he sam e bet ween neighbors?
Are t he int erfaces configured on t he sam e subnet ( t hat is, do t he address/ m ask pairs
belong t o t he sam e subnet ) ?
Are t he neighboring int erfaces of t he sam e net work t ype?
I s a rout er at t em pt ing t o form an adj acency wit h a neighbor's secondary address?
I f aut hent icat ion is being used, is t he aut hent icat ion t ype t he sam e bet ween neighbors? Are
t he passwords and ( in t he case of MD5) t he keys t he sam e? I s aut hent icat ion enabled on
all rout ers wit hin t he area?
Are any access list s blocking OSPF?
I f t he adj acency is across a virt ual link, is t he link configured wit hin a st ub area?
I f a neighbor or adj acency is suspect ed of being unst able, adj acencies can be m onit ored wit h t he
com m and de bu g ip ospf a dj . However, t his com m and can oft en present m ore inform at ion
t han you want , as Exam ple 8- 96 shows. The st at e changes of a neighbor are recorded in great
det ail. I f m onit oring is t o be perform ed over an ext ended period, t his wealt h of inform at ion can
overflow a rout er's int ernal logging buffers. Beginning wit h I OS 11.2, adj acencies can be
m onit ored by adding t he com m and log- a dj a ce n cy- ch a n ge s [ de t a il ] under a rout er's OSPF
configurat ion. This com m and will keep a sim pler log of adj acency changes, as shown in Exam ple
8- 97 and Exam ple 8- 98 .
Ex a m ple 8 - 9 6 . Th is de bu g ou t pu t fr om de bu g ip ospf a dj sh ow s t h e
r e su lt of t e m por a r ily discon n e ct in g a n d t h e n r e con n e ct in g a n e igh bor 's
Et h e r n e t in t e r fa ce .
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down
OSPF: Interface Ethernet0/0 going Down
OSPF: 172.16.2.2 address 10.8.1.1 on Ethernet0/0 is dead, state DOWN
OSPF: Neighbor change Event on interface Ethernet0/0
OSPF: DR/BDR election on Ethernet0/0
OSPF: Elect BDR 0.0.0.0
OSPF: Elect DR 172.16.2.3
OSPF: Elect BDR 0.0.0.0
OSPF: Elect DR 172.16.2.3
DR: 172.16.2.3 (Id) BDR: none
OSPF: 172.16.2.3 address 10.8.1.2 on Ethernet0/0 is dead, state DOWN
OSPF: Neighbor change Event on interface Ethernet0/0
OSPF: DR/BDR election on Ethernet0/0
OSPF: Elect BDR 0.0.0.0
OSPF: Elect DR 0.0.0.0
DR: none BDR: none
OSPF: Remember old DR 172.16.2.3 (id)
OSPF: Build router LSA for area 0, router ID 172.16.2.2, seq 0x80000035
OSPF: Build router LSA for area 25, router ID 172.16.2.2,
seq 0x80000005
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
OSPF: Interface Ethernet0/0 going Up
OSPF: Send with youngest Key 5
OSPF: Build router LSA for area 0, router ID 172.16.2.2, seq 0x80000036
OSPF: Build router LSA for area 25, router ID 172.16.2.2, seq 0x80000006
OSPF: Send with youngest Key 5
OSPF: Send with youngest Key 5
OSPF: Send with youngest Key 5
OSPF: Rcv DBD from 172.16.2.3 on Ethernet0/0 seq 0x728 opt 0x52 flag 0x7 len 32 mtu
1500 state INIT
OSPF: 2 Way Communication to 172.16.2.3 on Ethernet0/0, st ate 2WAY
OSPF: Nbr state is 2WAY
OSPF: Rcv DBD from 172.16.2.3 on Ethernet0/0 seq 0x728 opt 0x52 flag 0x7 len 32 mtu
1500 state 2WAY
OSPF: Nbr state is 2WAY
OSPF: end of Wait on interface Ethernet0/0
OSPF: DR/BDR election on Ethernet0/0
OSPF:
OSPF:
OSPF:
OSPF:
Elect BDR 172.16.2.2
Elect DR 172.16.2.3
Elect BDR 172.16.2.2
Elect DR 172.16.2.3
DR: 172.16.2.3 (Id) BDR: 172.16.2.2 (Id)
OSPF: Send DBD to 172.16.2.3 on Ethernet0/0 seq 0x1B85 opt 0x52 flag 0x7 len 32
OSPF: Send with youngest Key 5
OSPF: Send with youngest Key 5
OSPF: Rcv DBD from 172.16.2.3 on Ethernet0/0 seq 0x728 opt 0x52 flag 0x7 len 32 mtu
1500 state EXSTART
OSPF: NBR Negotiation Done. We are the SLAVE
OSPF: Send DBD to 172.16.2.3 on Ethernet0/0 seq 0x728 opt 0x52 flag 0x2 len 292
OSPF: Send with youngest Key 5
OSPF: Rcv DBD from 172.16.2.3 on Ethernet0/0 seq 0x729 opt 0x52 flag 0x3 len 272
mtu 1500 state EXCHANGE
OSPF: Send DBD to 172.16.2.3 on Ethernet0/0 seq 0x729 opt 0x52 flag 0x0 len 32
OSPF: Send with youngest Key 5
OSPF: Send with youngest Key 5
OSPF: Database request to 172.16.2.3
OSPF: sent LS REQ packet to 10.8.1.2, length 12
OSPF: Send with youngest Key 5
OSPF: Rcv DBD from 172.16.2.3 on Ethernet0/0 seq 0x72A opt 0x52 flag 0x1 len 32 mtu
1500 state EXCHANGE
OSPF: Exchange Done with 172.16.2.3 on Ethernet0/0
OSPF: Send DBD to 172.16.2.3 on Ethernet0/0 seq 0x72A opt 0x52 flag 0x0 len 32
OSPF: Send with youngest Key 5
OSPF: Synchronized with 172.16.2.3 on Ethernet0/0, state FULL
OSPF: Build router LSA for area 0, router ID 172.16.2.2, seq 0x80000037
Ex a m ple 8 - 9 7 . Th e se loggin g m e ssa ge s, r e su lt in g fr om t h e OSPF
con figu r a t ion com m a n d log- a dj a ce n cy- ch a n ge s, sh ow t h e sa m e
n e igh bor fa ilu r e a s de pict e d in Ex a m ple 8 - 9 6 , bu t w it h m u ch le ss
det a il.
Hurd#show logging
Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0 flushes,
0 overruns, xml disabled)
Console logging: level debugging, 248 messages logged, xml disabled
Monitor logging: level debugging, 0 messages logged, xml disabled
Buffer logging: level debugging, 5 messages logged, xml disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
Trap logging: level informational, 99 message lines logged
Log Buffer (4096 bytes):
%OSPF-5-ADJCHG: Process 1, Nbr 172.16.2.3 on Ethernet0/0 from FULL to DOWN,
Neighbor Down: Interface down or detached
%OSPF-5-ADJCHG: Process 1, Nbr 172.16.2.3 on Ethernet0/0 from LOADING to FULL,
Loading Done
Ex a m ple 8 - 9 8 . Th e se loggin g m e ssa ge s, r e su lt in g fr om t h e OSPF
con figu r a t ion com m a n d log- a dj a ce n cy- ch a n ge s a lso sh ow t h e sa m e
n e igh bor fa ilu r e a s de pict e d in Ex a m ple 8 - 9 6 , bu t h a ve m or e de t a il
t h a n t h e log in Ex a m ple 8 - 9 7 .
Hurd#show logging
Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0 flushes,
0 overruns, xml disabled)
Console logging: level debugging, 248 messages logged, xml disabled
Monitor logging: level debugging, 0 messages logged, xml disabled
Buffer logging: level debugging, 5 messages logged, xml disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
Trap logging: level informational, 99 message lines logged
Log Buffer (4096 bytes):
%OSPF-5-ADJCHG: Process 1, Nbr
Neighbor Down: Interface down
%OSPF-5-ADJCHG: Process 1, Nbr
Received Hello
%OSPF-5-ADJCHG: Process 1, Nbr
2-Way Received
%OSPF-5-ADJCHG: Process 1, Nbr
AdjOK?
%OSPF-5-ADJCHG: Process 1, Nbr
EXCHANGE, Negotiation Done
%OSPF-5-ADJCHG: Process 1, Nbr
LOADING, Exchange Done
%OSPF-5-ADJCHG: Process 1, Nbr
Loading Done
172.16.2.3 on Ethernet0/0 from FULL to DOWN,
or detached
172.16.2.3 on Ethernet0/0 from DOWN to INIT,
172.16.2.3 on Ethernet0/0 from INIT to 2WAY,
172.16.2.3 on Ethernet0/0 from 2WAY to EXSTART,
172.16.2.3 on Ethernet0/0 from EXSTART to
172.16.2.3 on Ethernet0/0 from EXCHANGE to
172.16.2.3 on Ethernet0/0 from LOADING to FULL,
I f you suspect t hat a link- st at e dat abase is corrupt ed or t hat t wo dat abases are not
synchronized, you can use t he sh ow ip ospf da t a ba se da t a ba se - su m m a r y com m and t o
observe t he num ber of LSAs in each rout er's dat abase. For a given area, t he num ber of each
LSA t ype should be t he sam e in all rout ers. Next , t he com m and sh ow ip ospf da t a ba se will
show t he checksum s for every LSA in a rout er's dat abase. Wit hin a given area, each LSA's
checksum should be t he sam e in every rout er's dat abase. Verifying t his st at us can be
excruciat ingly t edious for all but t he sm allest dat abases. Luckily, t here are MI Bs, [ 34] which can
report t he sum of a dat abase's checksum s t o an SNMP m anagem ent plat form . I f all dat abases in
an area are synchronized, t his sum should be t he sam e for each dat abase.
[34] Namely,
ospfExternLsaCksumSum and ospfAreaLsaCksumSum.
When exam ining an area- wide problem , consider t he following issues:
I s t he ABR configured correct ly?
Are all rout ers configured for t he sam e area t ype? For exam ple, if t he area is a st ub area,
all rout ers m ust have t he a r e a st u b com m and.
I f address sum m arizat ion is configured, is it correct ?
I f perform ance is a problem , check t he m em ory and CPU ut ilizat ion on t he rout ers. I f m em ory
ut ilizat ion is above 70 percent , t he link- st at e dat abase m ight be t oo large; if CPU ut ilizat ion is
consist ent ly above 60 percent , inst abilit ies could exist in t he t opology. I f m em ory or CPU
surpasses t he 50 percent m ark, t he net work adm inist rat or should analyze t he cause of t he
perform ance st ress and, based on t he result s of t he analysis, should begin planning correct ive
upgrades.
St ub areas and address sum m arizat ion can help t o bot h reduce t he size of t he link- st at e
dat abase and t o cont ain inst abilit ies. The processing of LSAs, not t he SPF algorit hm , put s t he
m ost burden on an OSPF rout er. Taken individually, t ype 1 and t ype 2 LSAs would be m ore
processor- int ensive t han sum m ary LSAs. However, t ype 1 and 2 LSAs t end t o be grouped,
whereas sum m ary LSAs are sent in individual packet s. As a result , in realit y, sum m ary LSAs are
m ore processor- int ensive.
The following case st udies dem onst rat e t he m ost frequent ly used t echniques and t ools for
t roubleshoot ing OSPF.
Case Study: An Isolated Area
I nt ra- area packet s can be rout ed wit hin area 1 of Figure 8- 54 , but all at t em pt s at int er- area
com m unicat ions fail. Suspicion should im m ediat ely fall on area 1's ABR. This suspicion is
reinforced by t he fact t hat t he I nt ernal Rout ers have no rout er ent ry for an ABR ( Exam ple 8- 99
).
Figu r e 8 - 5 4 . Th e e n d syst e m s a n d r ou t e r s w it h in a r e a 1 ca n
com m u n ica t e , bu t n o t r a ffic is be in g pa sse d t o or fr om a r e a 0 .
Ex a m ple 8 - 9 9 . Th e com m a n d sh ow ip ospf bor de r - r ou t e r s ch e ck s t h e
in t e r n a l r ou t e t a ble of t h e I n t e r n a l Rou t e r s. N o r ou t e r e n t r y for a n ABR
is sh ow n .
National#show ip ospf border-routers
OSPF Process 8 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route
National#
The next st ep is t o verify t hat t he physical link t o t he ABR is operat ional and t hat OSPF is
working properly. The sam e I nt ernal Rout er's neighbor t able ( Exam ple 8- 100 ) shows t hat t he
neighbor st at e of t he ABR is full, indicat ing t hat an adj acency exist s. I n fact , t he ABR is t he DR
for t he Token Ring net work. The exist ence of an adj acency confirm s t hat t he link is good and
t hat OSPF Hellos are being exchanged wit h t he proper param et ers.
Ex a m ple 8 - 1 0 0 . Th e n e igh bor t a ble of r ou t e r N a t ion a l in dica t e s t h a t
t h e ABR ( 1 .1 .1 .1 ) is fu lly a dj a ce n t .
National#show ip ospf neighbor
Neighbor ID Pri
State
Dead Time
1.1.1.1
1
FULL/DR
00:00:33
1.1.1.3
1
FULL/BDR 00:00:34
1.1.1.4
1
FULL/ 00:00:30
National#
Address
172.16.192.6
172.16.192.4
172.16.192.3
Interface
TokenRing0
TokenRing0
TokenRing0
Ot her evidence relevant t o t he problem can be found in Nat ional's dat abase and it s rout e t able.
The dat abase ( Exam ple 8- 101 ) cont ains only Rout er ( t ype 1) and Net work ( t ype 2) LSAs. No
Net work Sum m ary ( t ype 3) LSAs, which advert ise dest inat ions out side of t he area, are recorded.
At t he sam e t im e, t here are LSAs originat ed by Whit ney ( 1.1.1.1) . This inform at ion again
indicat es t hat Whit ney is adj acent but is not passing inform at ion from area 0 int o area 1.
Ex a m ple 8 - 1 0 1 . N a t ion a l's lin k - st a t e da t a ba se a lso sh ow s t h a t
W h it n e y is a dj a ce n t , bu t is n ot a dve r t isin g in t e r - a r e a de st in a t ion s.
National#show ip ospf database
OSPF Router with ID (1.1.1.2) (Process ID 8)
Router Link States (Area 1)
Link ID
172.16.192.6
172.16.219.120
ADV Router
1.1.1.1
1.1.1.2 1
Age
132
458
Seq#
0x80000034
0x8000002B
Checksum
0xAC4D
0x6B46
Net Link States (Area 1)
Link ID
ADV Router
Age
Seq#
Checksum
Link count
3
2
172.16.192.6
National#
1.1.1.1
132
0x8000002E
0x2078
The only dest inat ions out side of area 1 in Nat ional's rout e t able ( Exam ple 8- 102 ) are t he serial
links at t ached t o Whit ney. Yet anot her clue is revealed here: The rout e ent ries are t agged as
int ra- area rout es ( O) ; if t hey were in area 0, as Figure 8- 54 shows t hey should be, t hey would
be t agged as int er- area rout es ( O I A) . The problem is apparent ly on t he area 0 side of t he ABR.
Ex a m ple 8 - 1 0 2 . W h it n e y is a dve r t isin g t h e su bn e t s of it s se r ia l
in t e r fa ce s, bu t t h e y a r e be in g a dve r t ise d a s in t r a - a r e a de st in a t ion s.
National#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
C
C
O
172.16.0.0/16 is variably subnetted, 4 subnets, 3 masks
172.16.219.112/28 is directly connected, Serial0
172.16.192.0/29 is directly connected, TokenRing0
172.16.113.12/30 [110/70] via 172.16.192.6, 09:32:15, TokenRing0
O
172.16.113.16/30 [110/70] via 172.16.192.6, 09:32:15, TokenRing0
National#
An exam inat ion of Whit ney's serial int erfaces ( Exam ple 8- 103 ) reveals t he problem , if not t he
cause of t he problem . Bot h int erfaces, which should be in area 0, are inst ead in area 1. Bot h
int erfaces are connect ed t o t opological neighbors ( Louvre and Herm it age) , but no OSPF
neighbors are recorded. Error m essages are being displayed regularly, indicat ing t hat Whit ney is
receiving Hellos from Louvre and Herm it age; t hose Hellos have t heir Area fields set t o zero,
causing a m ism at ch.
Ex a m ple 8 - 1 0 3 . W h it n e y's se r ia l in t e r fa ce s a r e con figu r e d in a r e a 1
in st e a d of a r e a 0 ; t h is con figu r a t ion is ca u sin g e r r or m e ssa ge s w h e n
a r e a 0 H e llos a r e r e ce ive d.
Whitney#show ip ospf interface serial 0
Serial0 is up, line protocol is up
Internet Address 172.16.113.18/30, Area 1
Process ID 8, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:03
Index 1/3, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 2, maximum is 2
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Whitney#show ip ospf interface serial 1
Serial0 is up, line protocol is up
Internet Address 172.16.113.14/30, Area 1
Process ID 8, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:06
Index 1/3, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 2, maximum is 2
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Whitney#
%OSPF-4-ERRRCV: Received invalid packet: mismatch area ID,
from backbone area must be virtual-link but not found from 172.16.113.13, Serial1
%OSPF-4-ERRRCV: Received invalid packet: mismatch area ID,
from backbone area must be virtual-link but not found from 172.16.113.17, Serial0
Whit ney's OSPF configurat ion is shown in Exam ple 8- 104 .
Ex a m ple 8 - 1 0 4 . W h it n e y's OSPF con figu r a t ion .
router ospf 8
network 172.16.0.0 0.0.255.255 area 1
network 172.16.113.0 0.0.0.255 area 0
At first glance, t his configurat ion m ight appear t o be fine. However, recall from t he first
configurat ion case st udy t hat t he n e t w or k a r e a com m ands are execut ed consecut ively. The
second n e t w or k a r e a com m and affect s only int erfaces t hat do not m at ch t he first com m and.
Wit h t his configurat ion, all int erfaces m at ch t he first n e t w or k a r e a com m and and are placed
int o area 1. The second com m and is never applied.
A correct configurat ion is shown in Exam ple 8- 105 .
Ex a m ple 8 - 1 0 5 . W h it n e y's cor r e ct e d OSPF con figu r a t ion .
router ospf 8
network 172.16.192.0 0.0.0.255 area 1
network 172.16.113.0 0.0.0.255 area 0
There are, of course, several valid configurat ions. The im port ant point is t hat t he first n e t w or k
a r e a com m and m ust be specific enough t o m at ch only t he address of t he area 1 int erface, and
not t he addresses of t he area 0 int erfaces.
Case Study: Misconfigured Summarization
Figure 8- 55 shows a backbone area and t hree at t ached areas. To reduce t he size of t he linkst at e dat abase and t o increase t he st abilit y of t he net work, sum m arizat ion will be used bet ween
ar eas.
Figu r e 8 - 5 5 . Th e su m m a r y a ddr e sse s sh ow n for e a ch a r e a w ill be
a dve r t ise d in t o a r e a 0 . Ar e a 0 w ill a lso be su m m a r ize d in t o t h e ot h e r
a r e a s.
The individual subnet s of t he t hree nonbackbone areas are sum m arized wit h t he addresses
shown in Figure 8- 55 . For exam ple, a few of t he subnet s of area 1 m ay be
172.16.192.0/ 29
172.16.192.160/ 29
172.16.192.248/ 30
172.16.217.0/ 24
172.16.199.160/ 29
172.16.210.248/ 30
Figure 8- 56 shows t hat t hese subnet addresses can all be sum m arized wit h 172.16.192.0/ 19.
Figu r e 8 - 5 6 . A fe w of t h e su bn e t a ddr e sse s t h a t a r e su m m a r ize d w it h
1 7 2 .1 6 .1 9 2 .0 / 1 9 . Th e bold t ype in dica t e s t h e n e t w or k bit s of e a ch
a ddr e ss.
10101100000100001100000000000000
10101100000100001100000011111000
10101100000100001101100100000000
10101100000100001100011110100000
10101100000100001101001011111000
10101100000100001100000000000000
=
=
=
=
=
=
172.16.192.0/ 29
172.16.192.248/ 30
172.16.217.0/ 24
172.16.199.160/ 29
172.16.210.248/ 30
172.16.192.0/ 19
Whit ney's configurat ion is shown in Exam ple 8- 106
Ex a m ple 8 - 1 0 6 . W h it n e y's OSPF con figu r a t ion w it h a ddr e ss
su m m a r iza t ion .
router ospf 8
network 172.16.192.0 0.0.0.255 area 1
network 172.16.113.0 0.0.0.255 area 0
area 1 range 172.16.192.0 255.255.224.0
area 0 range 172.16.113.0 255.255.224.0
The ot her t hree ABRs are configured sim ilarly. Each ABR will advert ise t he sum m ary address of
it s at t ached non- backbone area int o area 0 and will also sum m arize area 0 int o t he nonbackbone area.
Exam ple 8- 107 shows t hat t here is a problem . When t he rout e t able of one of area 1's I nt ernal
Rout ers is exam ined, area 0 is not being sum m arized properly ( area 1's int ernal subnet s are not
shown, for clarit y) . Alt hough t he sum m ary addresses for areas 2 and 3 are present , t he
individual subnet s of area 0 are in t he t able inst ead of it s sum m ary address.
Ex a m ple 8 - 1 0 7 . Th e in dividu a l su bn e t s of a r e a 0 , in st e a d of t h e
e x pe ct e d su m m a r y a ddr e ss, a r e r e cor de d in t h e r ou t e t a ble of on e of
a r e a 1 's in t e r n a l r ou t e r s.
National#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 IA
O IA
172.16.0.0/16 is variably subnetted, 7 subnets, 4 masks
172.16.160.0/19 [110/80] via 172.16.192.6, 09:32:15, TokenRing0
172.16.128.0/19 [110/80] via 172.16.192.6, 09:32:15, TokenRing0
C
172.16.192.0/29 is directly connected, TokenRing0
O IA
172.16.113.12/30 [110/70] via 172.16.192.6, 09:32:15, TokenRing0
O IA
172.16.113.8/30 [110/134] via 172.16.192.6, 09:32:15, TokenRing0
O IA
172.16.113.16/30 [110/70] via 172.16.192.6, 09:32:15, TokenRing0
National#
You can see t hat t he a r e a r a n ge com m and for area 0 is t he problem when you exam ine t he
t hree subnet s of area 0 in binary ( Figure 8- 57 ) .
Figu r e 8 - 5 7 . Th e su bn e t s of a r e a 0 , t h e con figu r e d su m m a r y m a sk , a n d
t h e cor r e ct su m m a r y a ddr e ss.
10101100000100000111000100001000
10101100000100000111000100001100
10101100000100000111000100010000
11111111111111111110000000000000
10101100000100000110000000000000
=
=
=
=
=
172.16.113.8/ 30
172.16.113.12/ 30
172.16.113.16/ 30
255.255.224.0
172.16.96.0
The problem is t hat t he sum m ary address specified in t he a r e a r a n ge com m and ( 172.16.113.0)
is m ore specific t han t he accom panying m ask ( 255.255.224.0) . The correct address t o use wit h
t he 19- bit m ask is 172.16.96.0 ( see Exam ple 8- 108 ) .
Ex a m ple 8 - 1 0 8 . W h it n e y's OSPF con figu r a t ion w it h cor r e ct e d a ddr e ss
su m m a r iza t ion .
router ospf 8
network 172.16.192.0 0.0.0.255 area 1
network 172.16.113.0 0.0.0.255 area 0
area 1 range 172.16.192.0 255.255.224.0
area 0 range 172.16.96.0 255.255.224.0
Exam ple 8- 109 shows t he result ing rout e t able. There are ot her opt ions for area 0's sum m ary
address. For exam ple, 172.16.113.0/ 24 and 172.16.113.0/ 27 are bot h legit im at e. The m ost
appropriat e sum m ary address depends on t he priorit ies of t he net work design. I n t he case of t he
net work of Exam ple 8- 101 , 172.16.96.0/ 19 m ight be select ed for consist encyall sum m ary
addresses have a 19- bit m ask. On t he ot her hand, 172.16.113.0/ 27 m ight be select ed for bet t er
scalabilit y; five m ore subnet s can be added t o t he backbone under t his sum m ary address,
leaving a wider range of addresses t o be used elsewhere in t he net work.
Ex a m ple 8 - 1 0 9 . Ar e a 0 is n ow be in g su m m a r ize d cor r e ct ly.
National#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 IA
O IA
C
O IA
172.16.0.0/16 is variably subnetted, 5 subnets, 3 masks
172.16.160.0/19 [110/80] via 172.16.192.6, 00:25:09, TokenRing0
172.16.128.0/19 [110/80] via 172.16.192.6, 09:32:15, TokenRing0
172.16.192.0/29 is directly connected, TokenRing0
172.16.96.0/19 [110/70] via 172.16.192.6, 00:00:10, TokenRing0
National#
Looking Ahead
When link- st at e rout ing prot ocols are m ent ioned, m ost people first t hink of OSPF. However, it is
not t he only link- st at e prot ocol for I P. The I SO's I nt erm ediat e- Syst em t o I nt erm ediat e- Syst em
( I S- I S) , alt hough designed t o rout e ot her prot ocols, can rout e I P. Chapt er 10, " I nt egrat ed I SI S," exam ines t his lesser known link- st at e rout ing prot ocol.
Summary Table: Chapter 8 Command Review
Com m a n d
D e scr ipt ion
a r e a ar ea- id
a u t h e n t ica t ion [ m e ssa ge dige st ]
Enables t ype 1 or t ype 2 aut hent icat ion for an area.
a r e a ar ea- id de fa u lt - cost
cost
Specifies a cost for t he default rout e sent int o a st ub area by an
ABR.
a r e a ar ea- id filt e r - list
Defines an LSA t ype 3 filt er list .
pr e fix prefix_list _nam e [ ou t
| in ]
a r e a ar ea- id n ssa [ n or e dist r ibu t ion] [ de fa u lt in for m a t ion - or igin a t e ]
[ n o- su m m a r y ] [ t r a n sla t e
t ype 7 su ppr e ss- fa ]
Configures an area as not - so- st ubby ( NSSA) .
a r e a ar ea- id r a n ge address
m ask[ a dve r t ise | n ot a dve r t ise ] [ cost ]
Sum m arizes addresses int o or out of an area. The cost of t he
sum m ary address can be specified.
a r e a a r e a - id st ub [ n osu m m a r y]
Configures an area as a st ub or t ot ally st ubby area.
a r e a ar ea- id vir t u a l- lin k
rout er- id
Defines a virt ual link bet ween ABRs.
de bu g ip ospf a dj
Shows t he event s involved in t he building or breaking of an
OSPF adj acency.
[ n o] disca r d- r ou t e
{ in t e r n a l | e x t e r n a l}
N o disca r d- r ou t e rem oves t he aut om at ically creat ed st at ic
rout e t o t he Null int erface.
ip ospf a u t h e n t ica t ion - k e y Assigns a password t o an OSPF int erface for use wit h t ype 1
password
aut hent icat ion.
ip ospf cost cost
Specifies t he out going cost of an OSPF int erface.
ip ospf de a d- in t e r va l
seconds
Specifies t he OSPF Rout erDeadI nt erval for an int erface.
ip ospf de m a n d- cir cu it
Configures an int erface as an OSPF dem and circuit .
ip ospf h e llo- in t e r va l
seconds
Specifies t he OSPF HelloI nt erval for an int erface.
ip ospf m e ssa ge - dige st k e y key- id m d5 key
Specifies an int erface's key I D and key ( password) for use wit h
t ype 2 aut hent icat ion.
ip ospf n a m e - look u p
Enables t he reverse DNS lookup of nam es t o m at ch Rout er I Ds
in cert ain sh ow com m ands.
Com m a n d
D e scr ipt ion
ip ospf n e t w or k
[ br oa dca st ]
[ n on br oa dca st ] [ poin t - t om u lt ipoin t ]
Configures t he OSPF net work t ype.
ip ospf pr ior it y num ber
Set s t he rout er priorit y of an int erface for use in t he DR/ BDR
elect ion process.
ip ospf r e t r a n sm it in t e r va l seconds
Set s an int erface's OSPF Rxm t I nt erval.
ip ospf t r a n sm it - de la y
seconds
Set s an int erface's OSPF I nfTransDelay.
ip pr e fix - list
prefix_list _nam e [ se q num ]
{ d e n y | pe r m it}
address/ lengt h
Defines which addresses t o perm it or deny in a prefix list .
log- a dj a ce n cy- ch a n ge s
[ de t a il]
Logs neighbor st at e changes.
m a x im u m - pa t h s
Set s t he num ber of pat hs over which OSPF perform s load
balancing.
n e igh bor ipaddress[ pr ior it y num ber ]
[ poll- in t e r v a l seconds]
[ cost cost ]
Manually inform s a rout er of it s neighbors on a non- broadcast
net work.
n e t w or k address inversem ask a r e a ar ea- id
Specifies t he int erfaces on which OSPF is t o run and specifies
t he area t o which t he int erface is connect ed.
ospf a u t o- cost r e fe r e n ce ba n dw idt h referencebandwidt h
Changes t he default OSPF reference bandwidt h used for t he
calculat ion of link cost s.
r ou t e r ospf pr ocess- id
Enables an OSPF rout ing process.
sh ow ip ospf [ pr ocess- id]
Displays general inform at ion about an OSPF rout ing process.
sh ow ip ospf bor de r r ou t e r s
Displays a rout er's int ernal OSPF rout e t able.
sh ow ip ospf [ pr ocess- id
ar ea- id] da t a ba se
Displays all ent ries in t he OSPF link- st at e dat abase.
sh ow ip ospf [ pr ocess- id
ar ea- id] da t a ba se r ou t e r
[ link st at e- id]
Displays t ype 1 LSAs in t he OSPF link- st at e dat abase.
sh ow ip ospf [ pr ocess- id
ar ea- id] da t a ba se n e t w or k
[ link st at e- id]
Displays t ype 2 LSAs in t he OSPF link- st at e dat abase.
sh ow ip ospf [ pr ocess- id
ar ea- id] da t a ba se
su m m a r y [ link st at e- id]
Displays t ype 3 LSAs in t he OSPF link- st at e dat abase.
Com m a n d
D e scr ipt ion
sh ow ip ospf [ pr ocess- id
ar ea- id] da t a ba se a sbr su m m a r y [ link st at e- id]
Displays t ype 4 LSAs in t he OSPF link- st at e dat abase.
sh ow ip ospf [ pr ocess- id
ar ea- id] da t a ba se n ssa e x t e r n a l [ link st at e- id]
Displays t ype 7 LSAs in t he OSPF link- st at e dat abase.
sh ow ip ospf [ pr ocess- id]
da t a ba se e x t e r n a l [ link
st at e- id]
Displays t ype 5 LSAs in t he OSPF link- st at e dat abase.
sh ow ip ospf [ pr ocess- id
ar ea- id] da t a ba se
da t a ba se - su m m a r y
Displays t he num ber of LSAs in t he OSPF link- st at e dat abase by
t ype and by area I D.
sh ow ip ospf in t e r fa ce
[ t ype num ber ]
Displays OSPF- specific inform at ion about an int erface.
sh ow ip ospf n e igh bor
[ t ype num ber ] [ neighbor- id]
[ de t a il]
Displays inform at ion from t he OSPF neighbor t able.
sh ow ip ospf vir t u a l- lin k s
Displays inform at ion about OSPF virt ual links.
t im e r lsa - gr ou p- pa cin g
seconds or t im e r pa cin g
lsa - gr ou p seconds
Set s t he m inim um pacing t im e bet ween t wo groups of LSAs
whose refresh t im ers have expired.
Recommended Reading
Moy, J. " OSPF Version 2." RFC 2328: April 1998.
Moy, J. OSPF: Anat om y of an I nt ernet Rout ing Prot ocol. Reading, Massachuset t s: AddisonWesley; 1998. Writ t en by one of t he original designers of OSPF and t he aut hor of t he RFCs, t his
book is good reading not only for it s excellent coverage of t he prot ocol but also for it s hist oric
perspect ive. Chapt er 3 is especially int erest ing, wit h it s insider's perspect ive on t he design,
t est ing, and st andardizat ion of a rout ing prot ocol.
Review Questions
1
What is an OSPF neighbor?
2
What is an OSPF adj acency?
3
What are t he five OSPF packet t ypes? What is t he purpose of each t ype?
4
What is an LSA? How does an LSA differ from an OSPF Updat e packet ?
5
What are LSA t ypes 1 t o 5 and LSA t ype 7? What is t he purpose of each t ype?
6
What is a link- st at e dat abase? What is link- st at e dat abase synchronizat ion?
7
What is t he default HelloI nt erval?
8
What is t he default Rout erDeadI nt erval?
9
What is a Rout er I D? How is a Rout er I D det erm ined?
10
What is an area?
11
What is t he significance of area 0?
12
What is MaxAge?
13
What are t he four OSPF rout er t ypes?
14
What are t he four OSPF pat h t ypes?
15
What are t he five OSPF net work t ypes?
16
What is a Designat ed Rout er?
17
How does a Cisco rout er calculat e t he out going cost of an int erface?
18
What is a part it ioned area?
19
What is a virt ual link?
20
What is t he difference bet ween a st ub area, a t ot ally st ubby area, and a not - sost ubby area?
21
What is t he difference bet ween OSPF net work ent ries and OSPF rout er ent ries?
22
Why is t ype 2 aut hent icat ion preferable over t ype 1 aut hent icat ion?
23
Which t hree fields in t he LSA header dist inguish different LSAs? Which t hree fields in
t he LSA header dist inguish different inst ances of t he sam e LSA?
Configuration Exercises
1
Table 8- 13 shows t he int erfaces and addresses of 14 rout ers. Also shown is t he
OSPF area t o which each int erface is connect ed. The following fact s apply:
All int erfaces of each rout er are shown in t he t able.
I f no area is shown ( - ) , OSPF should not be running on t he associat ed int erface.
The second oct et of t he subnet address is t he sam e as t he area I D.
The first 16 bit s of t he address of every OSPF int erface are specific t o t he area. For
exam ple, addresses wit h t he prefix 10.30.x.x will be found only wit hin area 30.
Writ e OSPF configurat ions for t he rout ers in Table 8- 13 . ( Tip: Draw a pict ure of t he
rout ers and subnet s first .)
Ta ble 8 - 1 3 . Th e r ou t e r in for m a t ion for
Con figu r a t ion Ex e r cise s 1 t h r ou gh 6
Rou t e r
I n t e r fa ce
Addr e ss/ M a sk
Ar e a I D
A
L0
10.100.100.1/ 32
-
E0
10.0.1.1/ 24
0
E1
10.0.2.1/ 24
0
E2
10.0.3.1/ 24
0
E3
10.0.4.1/ 24
0
L0
10.100.100.2/ 32
-
E0
10.0.1.2/ 24
0
E1
10.5.1.1/ 24
5
S0
10.5.255.13/ 30
5
S1
10.5.255.129/ 30
5
L0
10.100.100.3/ 32
-
E0
10.0.2.2/ 24
0
E1
10.10.1.1/ 24
10
B
C
Rou t e r
D
E
F
G
H
I
J
K
L
I n t e r fa ce
Addr e ss/ M a sk
Ar e a I D
S0
10.30.255.249/ 30 30
L0
10.100.100.4/ 32
-
E0
10.0.3.2/ 24
0
E1
10.20.1.1/ 24
20
L0
10.100.100.5/ 32
-
E0
10.0.4.2/ 24
0
S0
10.15.255.1/ 30
15
L0
10.100.100.6/ 32
-
E0
10.5.5.1/ 24
5
S0
10.5.255.130/ 30
5
S1
10.5.255.65/ 30
5
L0
10.100.100.7/ 32
-
E0
10.10.1.58/ 24
10
S0
10.10.255.5/ 30
-
L0
10.100.100.8/ 32
-
E0
10.20.1.2/ 24
20
E1
10.20.100.100/ 27 20
S0
10.20.255.225/ 30 -
L0
10.100.100.9/ 32
-
E0
10.35.1.1/ 24
35
S0
10.5.255.66/ 30
5
L0
10.100.100.10/ 32 -
E0
10.15.227.50/ 24
15
S0
10.15.225.2
15
L0
10.100.100.11/ 32 -
E0
10.30.1.1/ 24
S0 [ * ]
10.30.254.193/ 26 30
L0
10.100.100.12/ 32 -
E0
10.30.2.1/ 24
30
30
Rou t e r
M
N
I n t e r fa ce
Addr e ss/ M a sk
Ar e a I D
S0 [ * ]
10.30.254.194/ 26 30
L0
10.100.100.13/ 32 -
E0
10.30.3.1/ 24
S0 [ * ]
10.30.254.195/ 26 30
S1
10.30.255.250/ 30 30
L0
10.100.100.14/ 32 -
E0
10.30.4.1/ 24
S0 [ * ]
10.30.254.196/ 26 30
30
30
2
Configure sum m arizat ion on all ABRs in Table 8- 13 .
3
Modify t he configurat ions t o m ake area 15 a st ub area.
4
Modify t he configurat ions t o m ake area 30 a t ot ally st ubby area.
5
I nt erface S0 of rout er H is connect ed t o a rout er running anot her rout ing prot ocol,
and t he rout es learned from t hat prot ocol are being redist ribut ed int o OSPF. Modify
t he configurat ions as necessary t o allow t hese redist ribut ed rout es t o be advert ised
t hroughout t he OSPF dom ain, but do not allow any t ype 5 LSAs t o ent er area 20.
6
The serial link bet ween rout ers C and M is a very low bandwidt h link. Modify t he
configurat ions so t hat OSPF t reat s t his link as a dem and circuit .
Troubleshooting Exercises
1
OSPF is not working bet ween t wo rout ers. When debugging is t urned on, t he m essages shown in
Exam ple 8- 110 are received every 10 seconds. What is t he problem ?
Ex a m ple 8 - 1 1 0 . Th e de bu g m e ssa ge s for Tr ou ble sh oot in g Ex e r cise 1 .
RTR_EX1#debug ip ospf adj
OSPF adjacency events debugging
RTR_EX1#
OSPF: Rcv pkt from 172.16.27.1,
network
OSPF: Rcv pkt from 172.16.27.1,
network
OSPF: Rcv pkt from 172.16.27.1,
network
OSPF: Rcv pkt from 172.16.27.1,
network
OSPF: Rcv pkt from 172.16.27.1,
network
is on
TokenRing0, area 0.0.0.25 : src not on the same
TokenRing0, area 0.0.0.25 : src not on the same
TokenRing0, area 0.0.0.25 : src not on the same
TokenRing0, area 0.0.0.25 : src not on the same
TokenRing0, area 0.0.0.25 : src not on the same
2
Explain what problem is indicat ed by t he debug m essages in Exam ple 8- 111 .
Ex a m ple 8 - 1 1 1 . Th e de bu g m e ssa ge s for Tr ou ble sh oot in g Ex e r cise 2 .
RTR_EX2#debug ip ospf adj
OSPF adjacency events debugging is on
RTR_EX2#
OSPF: Hello from 172.16.27.195 with mismatched Stub/Transit area option bit
OSPF: Hello from 172.20.1.1 with mismatched Stub/Transit area option bit
OSPF: Hello from 172.16.27.195 with mismatched Stub/Transit area option bit
OSPF: Hello from 172.20.1.1 with mismatched Stub/Transit area option bit
OSPF: Hello from 172.16.27.195 with mismatched Stub/Transit area option bit
OSPF: Hello from 172.20.1.1 with mismatched Stub/Transit area option bit
OSPF: Hello from 172.16.27.195 with mismatched Stub/Transit area option bit
OSPF: Hello from 172.20.1.1 with mismatched Stub/Transit area option bit
3
Explain what problem is indicat ed by t he error m essages in Exam ple 8- 112 .
Ex a m ple 8 - 1 1 2 . Th e e r r or m e ssa ge s for Tr ou ble sh oot in g Ex e r cise 3 .
RTR_EX3#
OSPF: Send with youngest Key 10
OSPF: Rcv pkt from 10.8.1.1, Ethernet0 : Mismatch Authentication type. Input
packet specified type 0, we use type 2
OSPF: Send with youngest Key 10
OSPF: Rcv pkt from 10.8.1.1, Ethernet0 : Mismatch Authentication type. Input
packet specified type 0, we use type 2
RTR_EX3#
4
Explain what problem is indicat ed by t he error m essages in Exam ple 8- 113 .
Ex a m ple 8 - 1 1 3 . Th e e r r or m e ssa ge s for Tr ou ble sh oot in g Ex e r cise 4 .
RTR_EX4#
OSPF: Send with youngest Key
OSPF: Rcv pkt from 10.8.1.1,
igest Key 10
OSPF: Send with youngest Key
OSPF: Rcv pkt from 10.8.1.1,
igest Key 10
RTR_EX4#
10
Ethernet0 : Mismatch Authentication Key - Message D
10
Ethernet0 : Mismatch Authentication Key - Message D
5
Explain what problem is indicat ed by t he error m essages in Exam ple 8- 114 .
Ex a m ple 8 - 1 1 4 . Th e e r r or m e ssa ge s for Tr ou ble sh oot in g Ex e r cise 5 .
RTR_EX5#
%OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must
be virtual-link
but not found from 10.8.1.1, Ethernet0
%OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must
be virtual-link
but not found from 10.8.1.1, Ethernet0
RTR_EX5#
6
The configurat ions for t he rout ers in Figure 8- 58 follow.
A:
router ospf 15
network 192.168.50.224 0.0.0.31 area 192.168.50.0
network 192.168.50.240 0.0.0.15 area 0.0.0.0
area 192.168.50.0 authentication message-digest
B:
router ospf 51
network 192.168.50.0 0.0.0.255 area 0
Rout ers A and B are not form ing an adj acency. What is wrong?
Figu r e 8 - 5 8 . Th e n e t w or k for Tr ou ble sh oot in g Ex e r cise 6 .
7
Exam ple 8- 115 shows a link- st at e dat abase from an area in which an unst able link exist s. Based
on t he inform at ion shown, which link is t he likely culprit ?
Ex a m ple 8 - 1 1 5 . Th e lin k - st a t e da t a ba se for Tr ou ble sh oot in g Ex e r cise
7.
RTR_EX7#show ip ospf database
OSPF Router with ID (10.8.20.1) (Process ID 1)
Router Link States (Area 0)
Link ID
10.3.0.1
10.8.5.1
10.8.20.1
ADV Router
10.3.0.1
10.8.5.1
10.8.20.1
Age
18
15
478
Seq#
0x8000001B
0x80000267
0x8000001E
Checksum
0x6AF8
0xFDA0
0xD451
Seq#
0x80000013
Checksum
0xA747
Net Link States (Area 0)
Link ID
10.8.1.2
RTR_EX2#
ADV Router
10.3.0.1
Age
18
Link count
5
6
4
Chapter 9. OSPFv3
This chapt er covers t he following subj ect s:
Operat ion of OSPFv3
Configuring OSPFv3
Troubleshoot ing OSPFv3
As you have seen in previous chapt ers, rout ing I Pv6 requires m odificat ions t o a prot ocol;
prim arily, t he prot ocol m essages m ust be m odified t o carry addresses four t im es as long as I Pv4
addresses. I n t heory, t his also could be done wit h Open Short est Pat h First ( OSPF) , eit her by
m odifying t he exist ing Link St at e Advert isem ent s ( LSA) or by defining new LSAs. But
developm ent of OSPF began in t he very lat e 1980s, when rout er perform ance was low, lat ency
was high, and m em ory was expensive. None of t hese are valid now, and several charact erist ics
of OSPFv2 t hat were int ended t o accom m odat e or com pensat e for t hose early net working
realit ies are now irrelevant . Furt her, ext ensive operat ional experience wit h OSPFv2 revealed
several areas of inefficiency.
So when ext ension of OSPF t o support I Pv6 was first considered, it was recognized t hat t here
was an opport unit y t o im prove t he prot ocol it self. The result is t hat rat her t han j ust ext ending
OSPFv2 for I Pv6, a new and im proved version of OSPFOSPF version 3has been creat ed.
Operation of OSPFv3
OSPFv3 is specified in RFC 2740. There are som e high- level sim ilarit ies bet ween t he
relat ionships of RI Png t o RI Pv2 and OSPFv3 t o OSPFv2. Most im port ant , OSPFv3 uses t he sam e
fundam ent al m echanism s as OSPFv2t he SPF algorit hm , flooding, DR elect ion, areas, and so on.
Const ant s and variables such as t im ers and m et rics are also t he sam e.
Anot her sim ilarit y t o t he relat ionship of RI Png t o RI Pv2 is t hat OSPFv3 is not backwardcom pat ible wit h OSPFv2. So if you want t o use OSPF t o rout e bot h I Pv4 and I Pv6, you m ust run
bot h OSPFv2 and OSPFv3. As t his chapt er is being writ t en, t here is discussion of adding I Pv4
support t o OSPFv3, but no specificat ions have yet been com plet ed. I , for one, hope t his support
is added, because OSPFv3 is a significant ly im proved prot ocol.
I t is assum ed t hat you have read t he previous chapt er and underst and t he operat ion of OSPFv2.
This sect ion does not repeat t hat inform at ion, but present s t he significant differencesprim arily
operat ional and LSA form at sof OSPFv3.
OSPFv3 Differences from OSPFv2
I n addit ion t o t he changes in LSAs, described in t he next sect ion, t here are several changes t o
OSPF procedures t hem selves. This sect ion describes t he m ost im port ant of t hose changes:
Pe r lin k pr ot ocol pr oce ssin g You have already seen t hat an int erface t o a link can have
m ore t han one I Pv6 address. I n fact , a single link can belong t o m ult iple subnet s, and t wo
int erfaces at t ached t o t he sam e link but belonging t o different I Pv6 subnet s can st ill
com m unicat e. OSPFv3 changes t he OSPFv2 language of " subnet " t o " link," and allows t he
exchange of packet s bet ween t wo neighbors on t he sam e link but belonging t o different
I Pv6 subnet s.
Re m ova l of a ddr e ssin g se m a n t ics As you will see in t he subsequent sect ions, OSPFv3
Rout er and Net work LSAs do not carry I P addresses. A new LSA is defined for t hat purpose.
This has som e scaling advant ages. However, 32- bit RI Ds, AI Ds, and LSA I Ds are
m aint ained in I Pv6. Keep in m ind t hat alt hough t hese I Ds are writ t en in dot t ed decim al,
and are oft en derived in OSPFv2 net works from working I Pv4 addresses, t hey are not I Pv4
addresses. These OSPFv3 I Ds are st ill expressed in dot t ed decim al, allowing easy overlay of
an OSPFv3 net work on an exist ing OSPFv2 net work.
N e igh bor s a r e a lw a ys ide n t ifie d by Rou t e r I D OSPFv2 neighbors on broadcast and
NBMA links are ident ified by t heir int erface addresses, whereas neighbors on ot her t ypes of
links are ident ified by RI D. OSPFv3 rem oves t his inconsist ency, so t hat all neighbors on all
link t ypes are ident ified by RI D.
Addit ion of a lin k - loca l floodin g scope OSPFv3 ret ains t he dom ain ( or AS) and area
flooding scopes of OSPFv2, but adds a link- local flooding scope. You already
knowpart icularly from Chapt er 2, " I Pv6 Overview" t hat I Pv6 m akes m uch use of t he linklocal scope. As you will see in t he subsequent sect ions, a new LSAt he Link LSAhas been
added, for carrying inform at ion t hat is only relevant t o neighbors on a single link. This LSA
has link- local flooding scope, m eaning it cannot be flooded beyond any at t ached rout er.
Use of lin k - loca l a ddr e sse s You already know t hat OSPFv2 packet s have a link- local
scope; t hey are not forwarded by any rout er. OSPFv3 uses a rout er's link- local I Pv6
address ( recall from Chapt er 2 t hat t hese addresses always begin wit h FF80: : / 10) as t he
source address, and as next - hop addresses.
Su ppor t for m u lt iple in st a n ce s pe r lin k There are applicat ions in which m ult iple OSPF
rout ers can be at t ached t o a single broadcast link but should not form a single adj acency
am ong t hem . An exam ple of t his is a shared Net work Access Point ( NAP) . For exam ple,
suppose four rout ers are at t ached t o an Et hernet link. Rout ers 1 and 2 belong t o one OSPF
dom ain, and rout ers 3 and 4 belong t o a different OSPF dom ain. There should be
adj acencies bet ween 1 and 2 and bet ween 3 and 4, but not , for inst ance, bet ween 1 and 3.
You can accom plish t his kind of separat ion of adj acencies wit h OSPFv2 by m anipulat ing
aut hent icat ion, but it is not ideal. Am ong ot her t hings, t he rout ers belonging t o one
adj acency will be cont inuously logging aut hent icat ion failures from t he rej ect ed Hellos of
t he ot her adj acency. OSPFv3 allows for m ult iple inst ances per link by adding an I nst ance
I D t o t he OSPF packet header t o dist inguish inst ances. An int erface assigned t o a given
I nst ance I D will drop OSPF packet s whose I nst ance I D does not m at ch.
Re m ova l of OSPF- spe cific a u t h e n t ica t ion I Pv6 has, using t he Aut hent icat ion ext ension
header, a st andard aut hent icat ion procedure. Because of t his, OSPFv3 has no need for it s
own aut hent icat ion of OSPFv3 packet s; it j ust uses I Pv6 aut hent icat ion.
M or e fle x ible h a n dlin g of u n k n ow n LSA t ype s Where OSPFv2 always discards unknown
LSA t ypes, OSPFv3 can eit her t reat t hem as having link- local flooding scope, or st ore and
flood t hem as if t hey are underst ood, while ignoring t hem in t heir own SPF algorit hm s. This
can result in easier net work changes and easier int egrat ion of new capabilit ies in OSPFv3
t han in OSPFv2.
OSPFv3 Messages
OSPFv2 and OSPFv3 bot h have t he sam e prot ocol num ber of 89, alt hough OSPFv3, being an
I Pv6 prot ocol, m ore accurat ely has a Next Header value of 89. And like OSPFv2, OSPFv3 uses
m ult icast whenever possible. The I Pv6 AllSPFRout ers m ult icast address is FF02: : 5, and t he
AllDRout ers m ult icast address is FF02: : 6. Bot h have link- local scope. You can easily see t he
sim ilarit y in t he last bit s wit h t he OSPFv2 addresses of 224.0.0.5 and 224.0.0.6.
OSPFv3 uses t he sam e five m essage t ypesHello, DD, LS Dat abase Request , LS Dat abase Updat e,
and LS Acknowledgm ent as OSPFv2, and num bers t hem t he sam e. The m essage header, shown
in Figure 9- 1 , is som ewhat different from t he OSPFv2 m essage header. The version num ber, of
course, is 3 rat her t han 2. But m ore im port ant , t here are no fields for aut hent icat ion. As
discussed in t he previous sect ion, OSPFv3 uses t he Aut hent icat ion ext ension header of t he I Pv6
packet it self rat her t han it s own aut hent icat ion process. And t here is an I nst ance I D, which
allows m ult iple OSPFv3 inst ances t o run on t he sam e link. The I nst ance I D has local link
significance only, because t he OSPFv3 m essage is not forwarded beyond t he link on which it is
or iginat ed.
Figu r e 9 - 1 . OSPFv3 pa ck e t h e a de r .
Aside from t he m essage header, t he form at of only t wo of t he OSPFv3 m essages is different
from t heir OSPFv2 count erpart s: Hellos and Dat abase Descript ion m essages.
Figure 9- 2 shows t he form at of t he OSPFv3 Hello m essage. Unlike OSPFv2, t here is no Net work
Mask field because I Pv6 has no need for it . Beyond t hat , t he sam e fields ( below t he header)
appear in bot h packet s. The Opt ions field increases in size t o 24 bit s, and t he Rout er Dead
I nt erval is decreased from 32 bit s t o 16 bit s. The im plicat ion of t his second field is t hat t he
t heoret ical m axim um Rout er Dead int erval is decreased from 4.3 billion seconds t o 65,535
seconds. This change has lit t le or no bearing on operat ional net works. The m axim um
configurable Rout er Dead int erval on t he m ost com m on OSPF im plem ent at ions has long been
65,535 anyway, and int elligent OSPF designs do not approach even t his m axim um ; so t he
change in t he field size is only for conservat ion of unused space.
Figu r e 9 - 2 . OSPFv3 H e llo m e ssa ge .
[View full size image]
Figure 9- 3 shows t he form at of t he OSPFv3 Dat abase Descript ion packet . I t differs from it s
OSPFv2 count erpart only in t he larger Opt ions field.
Figu r e 9 - 3 . OSPFv3 D a t a ba se D e scr ipt ion m e ssa ge .
[View full size image]
The ot her t hree m essage t ypesLink St at e Request , Link St at e Updat e, and Link St at e
Acknowledgm ent have form at s t hat do not differ from t hose of OSPFv2, and so are not shown in
t his chapt er.
An Overview of OSPFv3 LSAs
The OSPFv3 LSA header is shown in Figure 9- 4 . Com paring it wit h t he OSPFv2 LSA header in
Figure 8- 54, you can see t hat it is alm ost ident ical, except t hat t here is no Opt ions field, and t he
Link St at e Type field is 16 bit s rat her t han t he 8- bit Type field of OSPFv2.
Figu r e 9 - 4 . OSPFv3 LSA h e a de r .
[View full size image]
The reason t hat t he Link St at e Type field is longer is t hat it includes t hree preceding bit s, as
shown in Figure 9- 5 .
Figu r e 9 - 5 . Lin k St a t e Type fie ld of t h e OSPFv3 LSA h e a de r .
U indicat es how a rout er should handle t he LSA if it does not recognize t he LSA's Funct ion Code.
I f t he bit is cleared, t he unknown LSA is t o be t reat ed as if it had link- local flooding scope. I f t he
U bit is set , t he unknown LSA is t o be st ored and flooded as if it is underst ood.
S2 and S1 indicat e t he LSA's flooding scope. Table 9- 1 shows t he possible values of t hese t wo
bit s and t he associat ed flooding scopes.
Ta ble 9 - 1 . S bit s in t h e
OSPFv3 LSA Lin k St a t e
Type fie ld a n d t h e ir
a ssocia t e d floodin g
scope s.
S 2 S 1 Floodin g Scope
0
0
Link- Local
0
1
Area
1
0
AS ( Rout ing Dom ain)
1
1
Reser v ed
LSA Funct ion Code, t he last 13 bit s of t he LS Type field, corresponds t o t he OSPFv2 Type field.
Table 9- 2 shows t he com m on LSA t ypes used by OSPFv3 and t he values of t heir corresponding
LS Types. I f you decode t he hex values, you will see t hat t he default U bit of all of t hem is 0. The
S bit s of all LSAs except t wo indicat e area scope. Of t he rem aining t wo, AS Ext ernal LSAs have
an AS flooding scope and Link LSAs have a link- local flooding scope. Most of t he OSPFv3 LSAs
have funct ional count erpart s in OSPFv2; t hese OSPFv2 LSAs and t heir t ypes are also shown in
Table 9- 2.
Ta ble 9 - 2 . OSPFv3 LSA t ype s a n d t h e ir OSPFv2
cou n t e r pa r t s.
OSPFv3 LSAs
OSPFv2 LSAs
LS Type
Nam e
Type
Nam e
0x2001
Rout er LSA
1
Rout er LSA
0x2002
Net work LSA
2
Net work LSA
0x2003
I nt er- Area Prefix
LSA
3
Net work Sum m ary
LSA
0x2004
I nt er- Area Rout er
LSA
4
ASBR Sum m ary LSA
0x4005
AS- Ext ernal LSA
5
AS- Ext ernal LSA
0x2006
Group Mem bership
LSA
6
Group Mem bership
LSA
0x2007
Type- 7 LSA
7
NSSA Ext ernal LSA
0x0008
Link LSA
No Corresponding
LSA
0x2009
I nt ra- Area Prefix
LSA
No Corresponding
LSA
Alt hough Rout er and Net work LSAs have t he sam e nam es, t here is a significant difference in how
t he OSPFv3 and OSPFv2 Rout er and Net work LSAs funct ion. Specifically, OSPFv3 Rout er and
Net work LSAs do not advert ise prefixes. This is an im port ant im provem ent in t he scaling of t he
prot ocol. These LSAs are, as you know from Chapt er 8, " OSPFv2," prim arily t o represent t he
rout er as a node on t he SPF t ree. So when a Rout er or Net work LSA is flooded, t here is an
assum pt ion t hat a t opological change has t aken place and all rout ers in t he area, on receipt of
t he LSA, rerun SPF. But because OSPFv2 rout ers also use t hese LSAs t o advert ise t heir
connect ed subnet s, if a subnet changes, t he LSA m ust also be flooded t o advert ise t he change.
Even t hough som et hing like an address change does not affect t he SPF t opology, t he recept ion
of a Rout er or Net work LSA t riggers an SPF run anyway. This can be part icularly problem at ic for
edge or access rout ers t hat have m any st ub links t hat change regularly.
OSPFv3 rem oves t he prefix advert isem ent funct ion from Rout er and Net work LSAs, and put s it in
t he new I nt ra- Area Prefix LSA. Now Rout er and Net work LSAs only represent t he rout er's node
inform at ion for SPF and are only flooded if inform at ion pert inent t o t he SPF algorit hm changes. I f
a prefix changes, or t he st at e of a st ub link changes, t hat inform at ion is flooded in an I nt ra- Area
Prefix LSA t hat does not t rigger an SPF run.
Anot her difference bet ween Rout er and Net work LSAs bet ween OSPFv2 and OSPFv3 is in t he
exchange of som e inform at ion t hat is only relevant t o direct ly connect ed neighbors. OSPFv2 put s
t his inform at ion in Rout er or Net work LSAs; and alt hough only t he direct ly connect ed neighbors
care about t he inform at ion, it is flooded wit h t he LSAs t hroughout t he area. OSPFv3 t akes t his
neighbor- specific inform at ion and put s it in t he new Link LSA, which has link- local flooding
scope. Alt hough m inor, t he int roduct ion of t he Link LSA does add an efficiency im provem ent
over OSPFv2.
I nt er- Area Prefix, I nt er- Area Rout er, and Type- 7 LSAs, alt hough t heir nam es have changed,
have t he sam e funct ion as OSPFv2 Net work Sum m ary, ASBR Sum m ary, and NSSA LSAs,
respect ively. AS- Ext ernal and Group Mem bership LSAs have bot h t he sam e nam es and t he sam e
funct ions in bot h OSPFv2 and OSPFv3.
OSPFv3 LSA Formats
This sect ion det ails t he form at s of t he first five OSPFv3 LSA t ypes, and t he t wo new LSA t ypes
shown in Table 9- 2. Alt hough t here is a specified Group Mem bership LSA for Mult icast OSPF
( MOSPF) , t hat prot ocol is not covered in t his book, and so t he LSA is also not det ailed. I n m ost
cases, only fields t hat differ from t heir OSPFv2 count erpart s are discussed; you are encouraged
t o com pare t hose LSAs t hat have corresponding OSPFv2 LSAs wit h t he figures in Chapt er 8.
The Router LSA
Figure 9- 6 shows t he form at of t he OSPFv3 Rout er LSA. As discussed in t he previous sect ion,
prefix inform at ion is not included in t he Rout er LSA as it is in it s OSPFv2 count erpart . The
OSPFv3 Rout er LSA only describes t he originat ing rout er and it s links t o neighbors, for use in
SPF calculat ions. Prefix inform at ion is carried in t he I nt ra- Area Prefix LSA.
Figu r e 9 - 6 . OSPFv3 Rou t e r LSA.
[View full size image]
Also not ice t hat t he ToS m et ric fields, obsolet e already in OSPFv2, are not included in t his LSA.
Opt ions, alt hough in a different posit ion wit hin t he LSA form at and a longer lengt h ( 24 bit s) t han
t he OSPFv2 Opt ions field, perform s t he sam e funct ion of ident ifying opt ional capabilit ies. The
Opt ions field, carried in several packet s and LSAs, is described separat ely in a lat er sect ion.
Following t he Opt ions field is a set of fields t hat can appear m ult iple t im es, t o describe each of
t he at t ached int erfaces:
Type specifies t he int erface t ype. Table 9- 3 list s t he possible int erface t ype values.
Ta ble 9 - 3 . I n t e r fa ce t ype s spe cifie d
in t h e Type fie ld of t h e Rou t e r LSA.
Type
D e scr ipt ion
1
Point - t o- point connect ion t o anot her
rout er
2
Connect ion t o a t ransit net work
3
Reser v ed
4
Virt ual link
M e t r ic specifies t he out bound cost of t he int erface.
I n t e r fa ce I D is a 32- bit value dist inguishing t he int erface from ot her int erfaces on t he
originat ing rout er.
N e igh bor I n t e r fa ce I D is t he I nt erface I D advert ised by neighbors on t he link in t heir
Hellos or, in t he case of t ype 2 links, t he I nt erface I D of t he link's DR.
N e igh bor Rou t e r I D is t he neighbor's RI D or, in t he case of t ype 2 links, t he DR's RI D.
Network LSA
The OSPFv3 Net work LSA is shown in Figure 9- 7 . Funct ionally it is ident ical t o t he OSPFv2
Net work LSA ( originat ed by t he DR t o represent a pseudonode, 0 cost t o at t ached neighbors is
assum ed, and so on) . The only significant differences are t he locat ion of t he Opt ions field and
t he elim inat ion of t he Net work Mask field, which has no m eaning in I Pv6.
Figu r e 9 - 7 . OSPFv3 N e t w or k LSA.
[View full size image]
Inter-Area Prefix LSA
The I nt er- Area Prefix LSA ( Figure 9- 8 ) perform s t he sam e funct ion as t he OSPFv2 t ype 3
Sum m ary LSAABRs originat e t hem int o an area t o advert ise net works t hat are out side t he area
but inside t he OSPF dom ain. Only t he nam e, m ore descript ive in OSPFv3, has changed. An ABR
originat es a separat e I nt er- Area Prefix LSA for each I Pv6 prefix t hat m ust be advert ised int o an
area. An ABR can also originat e an I nt er- Area Prefix LSA t o advert ise a default rout e int o a st ub
area.
Figu r e 9 - 8 . OSPFv3 I n t e r - Ar e a Pr e fix LSA.
[View full size image]
Inter-Area Router LSA
The I nt er- Area Rout er LSA perform s t he sam e dut ies for OSPFv3 as t he t ype 4 Sum m ary LSA
perform s for OSPFv2. An ABR originat es an I nt er- Area Rout er LSA int o an area t o advert ise an
ASBR t hat resides out side of t he area. The ABR originat es a separat e I nt er- Area Rout er LSA for
each ASBR it advert ises.
Figure 9- 9 shows t he form at of t he I nt er- Area Rout er LSA. Even t hough t he OSPFv2 t ype 3 and
t ype 4 Sum m ary LSAs have t he sam e form at s, you can see by com paring Figure 9- 8 and Figure
9 - 9 t hat t he I nt er- Area Net work and I nt er- Area Rout er LSAs are different . The fields are selfdescript ive:
Op t ion s specifies opt ional capabilit ies of t he ASBR.
M e t r ic specifies t he cost t o t he ASBR.
D e st in a t ion Rou t e r I D is t he ASBR RI D.
Figu r e 9 - 9 . OSPFv3 I n t e r - Ar e a Rou t e r LSA.
[View full size image]
AS-External LSA
As wit h OSPFv2, t he AS- Ext ernal LSA advert ises prefixes ext ernal t o t he OSPF rout ing dom ain;
one LSA is required for each ext ernal prefix advert ised. However, t he form at of t he OSPFv3 AsExt ernal LSA ( Figure 9- 10) is different from it s OSPFv2 count erpart .
Figu r e 9 - 1 0 . OSPFv3 AS- Ex t e r n a l LSA.
[View full size image]
The E flag perform s t he sam e funct ion in t he OSPFv3 LSA as in t he OSPFv2 LSA. I f set , t he
m et ric is a t ype 2 ext ernal m et ric. I f t he bit is cleared, t he m et ric is a t ype 1 ext ernal m et ric.
The F flag indicat es, when set , t hat a forwarding address is included in t he LSA.
The T flag indicat es, when set , t hat an ext ernal rout e t ag is included in t he LSA.
Met ric, of course, specifies t he cost of t he rout e. Whet her it is t ype 1 or t ype 2 depends on t he
value of t he E flag.
Prefix Lengt h, Prefix Opt ions, and Address Prefix com plet ely describe t he enclosed prefix.
Forwarding Address, if included, is a fully specified 128- bit I Pv6 address represent ing t he next hop address t o t he dest inat ion prefix. I t is included only if t he F flag is set .
Ext ernal Rout e Tag, if included, perform s t he sam e funct ion as t he Ext ernal Rout e Tag field in
t he OSPFv2 AS- Ext ernal LSA. I t is included only if t he T flag is set .
Referenced Link St at e I D and Referenced Link St at e Type, if included, allow addit ional
inform at ion about t he prefix t o be included in anot her LSA. I f used, t hese t wo fields describe t he
link st at e I D and t he t ype of t he LSA carrying t he addit ional inform at ion. The Advert ising Rout er
field of t he referenced LSA m ust also m at ch t he value of t he Advert ising Rout er field in t he ASExt ernal LSA. The addit ional inform at ion has, as wit h t he Ext ernal Rout e Tag, no relevance t o
OSPFv3 it self, but is used t o com m unicat e inform at ion across t he OSPF dom ain bet ween border
rout ers. I f t his funct ion is not used, t he Referenced Link St at e Type field is set t o all zeroes.
Link LSA
The Link LSA is used for com m unicat ing inform at ion t hat is significant only t o t wo direct ly
connect ed neighbors. The form at of t he Link LSA is shown in Figure 9- 11. A separat e Link LSA is
originat ed on each of a rout er's at t ached links belonging t o an OSPFv3 dom ain, and a receiving
rout er, because of t he link- local flooding scope, never forwards t he LSA t o any ot her link.
Figu r e 9 - 1 1 . OSPFv3 Lin k LSA.
[View full size image]
The LSA perform s t hree funct ions:
I t provides t he originat ing rout er's link- local address t o all ot her rout ers at t ached t o t he
link.
I t provides a list of I Pv6 prefixes associat ed wit h t he link.
I t provides a set of Opt ion bit s t o associat e wit h Net work LSAs originat ed on t he link.
Rout er Priorit y specifies t he rout er priorit y assigned t o t he int erface of t he originat ing rout er.
Opt ions specifies t he opt ions bit s t hat t he originat ing rout er would like t o set in t he Net work LSA
t hat will be originat ed for t he link. This is t he sam e 24- bit Opt ions field carried in OSPFv3 Hello
and DD packet s, in a num ber of OSPFv3 LSAs. The Opt ions field is det ailed in t he lat er sect ion,
" The Opt ions Field."
Link- Local Prefix Address specifies t he 128- bit link- local prefix of t he originat ing rout er's
int erface at t ached t o t he link.
Num ber of Prefixes specifies t he num ber of I Pv6 prefixes cont ained in t he LSA, as described by
t he following Prefix Lengt h, Prefix Opt ions, and Address Prefix fields.
Prefix Lengt h, Prefix Opt ions, and Address Prefix describe one or m ore I Pv6 prefixes associat ed
wit h t he link by t he originat ing rout er. This set of fields is used not only in t he Link LSA, but also
t he I nt ra- Area- Prefix, I nt er- Area- Prefix, and AS- Ext ernal LSAs. The advert ised prefix can be any
lengt h bet ween 0 and 128. When t he prefix is not an even m ult iple of 32 bit s, it is padded out
wit h zeroes t o fit t he 32- bit boundaries of t he Address Prefix field. The Prefix Lengt h field
specifies t he lengt h of t he unpadded prefix, in bit s. The Prefix Opt ions field, shown in Figure 912 , specifies opt ional handling of t he prefix during rout ing calculat ions.
Figu r e 9 - 1 2 . Pr e fix Opt ion s fie ld.
The Propagat e ( P) bit is set on NSSA area prefixes t hat should be re- advert ised at t he NSSA
area border.
The Mult icast ( MC) bit , when set , specifies t hat t he prefix should be included in m ult icast rout ing
calculat ions.
The Local Address ( LA) bit , when set , specifies t hat t he prefix is an int erface address of t he
advert ising rout er.
The No Unicast ( NU) bit , when set , specifies t hat t he prefix should be excluded from unicast
rout e calculat ions.
Intra-Area Prefix LSA
The I nt ra- Area Prefix LSA is shown in Figure 9- 13. Recall from t he previous discussion of t his
LSA t hat at t ached prefixes, which in OSPFv2 are carried in Rout er and Net work LSAs, in OSPFv3
are carried in I nt ra- Area Prefix LSAs. Prefix changesincluding addit ions and delet ionsdo not
influence t he branches of t he SPF t ree in any way. But OSPFv2 advert ises prefixes in Rout er and
Net work LSAs, causing an SPF calculat ion in all rout ers in t he area whenever a prefix change
occurs. Wit h OSPFv3, however, when a link or it s prefix changes, t he connect ed rout er originat es
an I nt ra- Area Prefix LSA t o flood t he inform at ion t hroughout t he area. This LSA does not t rigger
an SPF calculat ion; t he receiving rout ers sim ply associat e t he new prefix inform at ion wit h t he
originat ing rout er. Rout er and Net work LSAs, in OSPFv3, serve only t o provide t opological
inform at ion. As a result , t his new LSA should m ake OSPFv3 significant ly m ore scalable for
net works wit h large num bers of frequent ly changing prefixes.
Figu r e 9 - 1 3 . I n t r a - Ar e a Pr e fix LSA.
[View full size image]
N u m be r of Pr e fix e s specifies t he num ber of prefixes cont ained in t he LSA.
Re fe r e n ce d Lin k St a t e Type , Re fe r e n ce d Lin k St a t e I D, and Re fe r e n ce d Adve r t isin g
Rou t e r ident ify t he Rout er or Net work LSA wit h which t he cont ained prefixes should be
associat ed.
I f t he prefixes are associat ed wit h a Rout er LSA, t he Referenced Link St at e Type is 1, t he
Referenced Link St at e I D is 0, and t he Referenced Advert ising Rout er is t he RI D of t he
originat ing rout er. I f t he prefixes should be associat ed wit h a net work LSA, t he Referenced Link
St at e Type is 2, t he Referenced Link St at e I D is t he int erface I D [ 1] of t he link's DR, and t he
Referenced Advert ising Rout er is t he RI D of t he DR.
[1]
The interface ID used in this and other OSPFv3 LSAs should not be confused with the 64-bit Interface ID portion of an
IPv6 address. This field is a 32-bit value distinguishing this interface from other interfaces on the originating router. RFC
2740 suggests using the MIB-II If Index for the interface ID value.
Each prefix is t hen represent ed by a Prefix Lengt h, Prefix Opt ions, and Address Prefix field, as
described previously for t he Link LSA. Added t o t hese t hree fields is t he Met ric field, which is t he
cost of t he prefix.
Options Field
The 24- bit Opt ions field, specifying opt ional capabilit ies of t he originat ing rout er, is carried in
Rout er, Net work, I nt er- Area Rout er, and Link LSAs. This field is also carried in t he Hello and
Dat abase Descript ion packet s. Figure 9- 14 shows t he form at of t he Opt ions field. As of t his
writ ing, only t he six right m ost bit s are defined as opt ions flags, and m ost of t hose are t he sam e
flags you are fam iliar wit h from OSPFv2. OSPFv3 rout ers ignore unrecognized opt ions flags.
Figu r e 9 - 1 4 . Opt ion s fie ld.
D C specifies support for dem and circuit s capabilit y.
R indicat es whet her t he originat or is an act ive rout er. When cleared, rout es t ransit ing t he
originat ing node cannot be com put ed. The R flag t herefore adds a capabilit y sim ilar t o t he
Configuring OSPFv3
The configurat ion opt ions of OSPFv3 are t he sam e as t hose for OSPFv2. Process I Ds and areas
need t o be specified. I nt erfaces and addresses need t o be included in t he process. Areas can be
defined as st ubs, t ot ally st ubby or not so st ubby area ( NSSA) . Prefixes can be sum m arized
bet ween areas. OSPFv3 can be configured over dem and circuit s and on NBMA net works. Much of
t he configurat ion for OSPFv3 is t he sam e as for OSPFv2. An I Pv6 keyword is added in som e
cases, and an I Pv6 prefix or address is used in place of t he I Pv4 subnet or address. This sect ion
cont ains case st udies t hat show t he OSPFv3 configurat ions t hat are different from OSPFv2 and
som e t hat are very sim ilar, but need t o be em phasized.
Case Study: A Basic OSPFv3 Configuration
The configurat ion of OSPFv3 is sim ilar t o OSPFv2 wit h t wo except ions. Recall from Chapt er 8
t hat t o configure OSPFv2 on a rout er and an int erface, you first creat e t he OSPF process using
t he r ou t e r ospf com m and. Then, you specify address ranges t hat encom pass int erface
addresses t hat are t o part icipat e in OSPF, using t he n e t w or k a r e a com m and. The int erfaces
configured wit h I Pv4 addresses t hat fall wit hin t he address range specified wit h t he n e t w or k
a r e a com m and part icipat e in OSPFv2. I f an int erface has an I Pv4 address t hat is not part of t he
address range, t hat int erface, or t hat address ( if t here is m ore t hen one I Pv4 address on an
int erface) will not part icipat e in t he OSPFv2 process. OSPFv3 for I Pv6 is enabled by specifying an
OSPF process I D and an area at t he int erface configurat ion level. I f an OSPFv3 process has not
yet been creat ed, it is creat ed aut om at ically. All I Pv6 addresses configured on t he int erface are
included in t he specified OSPF process. Figure 9- 15 displays an OSPFv3 net work.
Figu r e 9 - 1 5 . Ex a m ple of a n OSPFv3 n e t w or k .
[View full size image]
Hedwig's and Pigwidgeon's configurat ions are displayed in Exam ple 9- 1 and Exam ple 9- 2.
Ex a m ple 9 - 1 . OSPFv3 is con figu r e d on H e dw ig w it h t h e in t e r fa ce
com m a n d ipv6 ospf 1 a r e a 1 .
interface Serial 0/0
ipv6 address 2001:db8:0:8::1/64
ipv6 ospf 1 area 1
interface Ethernet0/0
ipv6 address 2001:db8:0:4::1/64
ipv6 ospf 1 area 0
Ex a m ple 9 - 2 . Pigw idge on is con figu r e d for OSPFv3 .
interface Ethernet 0/0
ipv6 address 2001:db8:0:5::3/64
ipv6 ospf 1 area 0
interface Serial 0/0
ipv6 address 2001:db8:0:10::1/64
ipv6 ospf 1 area 0
The com m and ipv6 ospf a r e a enables OSPFv3 on Serial0/ 0 and Et hernet 0/ 0, places Hedwig's
serial int erface in area 1 and t he Et hernet int erface in area 0, and creat es t he OSPFv3 process
wit h I D '1' on t he rout er, as shown in Exam ple 9- 3. Wit h OSPFv2, t wo com m ands are required t o
accom plish t he sam e t asks: t he r ou t e r ospf 1 com m and creat es t he OSPF process, t hen t he
n e t w or k a r e a com m and enables OSPFv2 on int erfaces. One t hing t o not e, t hough, is t hat t he
n e t w or k a r e a com m and can enable OSPFv2 on m ult iple int erfaces wit h t he single com m and,
whereas t he ipv6 ospf a r e a com m and has t o be configured on each int erface t hat will be
running OSPFv3.
Ex a m ple 9 - 3 . sh ow ipv6 pr ot ocol displa ys t h e OSPF for I Pv6 pr oce ss
I D a n d t h e in t e r fa ce s con figu r e d in e a ch a r e a on t h e r ou t e r .
Hedwig#show ipv6 protocol
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "ospf 1"
Interfaces (Area 0):
Ethernet0/0
Interfaces (Area 1):
Serial0/0
Redistribution:
None
Hedwig#
All I Pv6 addresses on an int erface are included in t he OSPF process t hat is creat ed on t he
int erface. For exam ple, a second I Pv6 address is added t o Hedwig's Et hernet port in Exam ple 94.
Ex a m ple 9 - 4 . A se con d I Pv6 a ddr e ss is a dde d t o H e dw ig's
Et h e r n e t 0 / 0 . Bot h I Pv6 a ddr e sse s a r e in clu de d in t h e OSPFv3 pr oce ss
be ca u se OSPFv3 is con figu r e d on t h a t in t e r fa ce .
interface Ethernet0/0
ipv6 address 2001:db8:0:4::1/64
ipv6 address 2001:db8:0:5::1/64
ipv6 ospf 1 area 0
This second address is included aut om at ically in t he OSPFv3 process t hat is configured on t he
int erface. No addit ional OSPFv3 com m ands need t o be ent ered t o m ake t he new address part of
t he rout ing process. I Pv6 addresses on an int erface cannot be select ively included in OSPFv3.
Eit her all t he addresses are included, by configuring t he int erface wit h OSPFv3, or OSPFV3 is not
configured on t he int erface and none of t he addresses are included.
OSPFv3 rout ers use t heir link- local addresses as t he source of hello packet s. No I Pv6 prefix
inform at ion is cont ained in hello packet s. Mult iple I Pv6 addresses can be configured on a link.
None of t he addresses are defined as secondary addresses, as is done wit h I Pv4 t o configure
m ult iple addresses on a single link. Two rout ers will becom e adj acent even if no I Pv6 prefix is
com m on bet ween t he neighbors except t he link- local address. This is different from OSPFv2 for
I Pv4. OSPFv2 neighbors will only becom e adj acent if t he neighbors belong t o t he sam e I P
subnet , and t he com m on subnet is configured as t he prim ary I P address on t he neighboring
int erfaces. I n Figure 9- 15, Hedwig is configured wit h bot h 2001: db8: 0: 4: : / 64 and
2001: db8: 0: 5: : / 64 on it s Et hernet int erface. Pigwidgeon is configured wit h 2001: db8: 0: 5: : / 64
and Crookshanks is configured wit h 2001: db8: 0: 4: : / 64 on t heir Et hernet int erfaces. Exam ple 95 shows t hat Crookshanks is adj acent t o bot h Hedwig ( 10.1.1.1) and Pigwidgeon ( 10.1.3.1) .
Pigwidgeon is t he backup designat ed rout er.
Ex a m ple 9 - 5 . sh ow ipv6 ospf n e igh bor sh ow s Cr ook sh a n k s's n e igh bor s
a r e a ll in t h e FULL st a t e , e ve n t h ou gh t h e y don 't sh a r e a com m on I Pv6
pr e fix , ot h e r t h e n t h e lin k - loca l a ddr e ss.
Crookshanks#show ipv6 ospf neighbor
Neighbor ID
10.1.1.1
10.1.3.1
Crookshanks#
Pri
1
1
State
FULL/DROTHER
FULL/BDR
Dead Time
00:00:30
00:00:37
Interface ID
3
3
Interface
Ethernet0/0
Ethernet0/0
Ot her param et ers m ust m at ch bet ween t wo neighbors before t hey will becom e adj acent . These
param et ers are t he sam e as I Pv4: The neighbors m ust share t he sam e area id, t hey m ust have
t he sam e Hello int erval and dead t im e, and t hey bot h m ust have t he sam e value in t he E- bit ,
indicat ing whet her t he area is a st ub area or not . An OSPFv3 packet m ust also have t he sam e
I nst ance I D as t he receiving int erface, or t he OSPFv3 packet s will be dropped. I nst ance I D will
be discussed lat er in t his chapt er, in t he case st udy, Mult iple I nst ances on a Link.
OSPFv3 uses a 32- bit num ber for a Rout er I D. I f I Pv4 is configured on t he rout er, by default , t he
RI D is chosen in t he sam e way it is by OSPFv2 for I Pv4. The highest I Pv4 address configured on
a loopback int erface will becom e t he RI D, or if no loopback int erfaces are configured, t he highest
address on any ot her int erface will becom e t he RI D.
I Pv6 neighbors are always known by t heir RI Ds, unlike I Pv4, where point - t o- point net work
neighbors are known by RI Ds and broadcast , NBMA and point - t o- m ult ipoint net work neighbors
are known by t heir int erface I P addresses. The neighbor I Ds shown in Exam ple 9- 5 show t hat
t he rout er I Ds are obt ained from configured I Pv4 addresses.
I f I Pv4 is not configured in t he net work, and you don't want t o configure I Pv4 j ust t o est ablish a
rout er I D, t he rout er I D m ust be configured using t he I Pv6 OSPF rout ing process com m and
r ou t e r - id before t he OSPF process will st art .
When OSPFv3 is configured on an int erface, t he rout ing process is creat ed. I nt erface
param et ers, such as t he cost of a link, are m odified at t he int erface configurat ion, but global
param et ers are m odified at t he OSPF process level.
Case Study: Stub Areas
The ipv6 r ou t e r ospf com m and t akes you int o t he global process configurat ion m ode, j ust as
r ou t e r ospf does for I Pv4. The sam e configurat ion cust om izat ion can be done wit h I Pv6 as wit h
I Pv4. St ub, NSSA, and t ot ally st ubby are support ed and configured in t he exact sam e way as for
OSPFv2 for I Pv4, using t he a r e a st u b, a r e a n ssa, and a r e a st u b n o- su m m a r y com m ands.
Area 1 in Figure 9- 15 is configured as a t ot ally st ubby area wit h t he configurat ions in Exam ple 96 and Exam ple 9- 7 at Hedwig and Scabbers.
Ex a m ple 9 - 6 . On H e dw ig, a r e a 1 is con figu r e d a s a t ot a lly st u bby a r e a .
n o- su m m a r y is on ly con figu r e d on t h e ABR.
ipv6 router ospf 1
area 1 stub no-summary
Ex a m ple 9 - 7 . Ar e a 1 on Sca bbe r s is a lso con figu r e d a s a st u b be ca u se
a ll r ou t e r s in t h e st u b a r e a m u st be con figu r e d a s a st u b.
ipv6 router ospf 1
area 1 stub
Exam ple 9- 8 shows Scabbers's I Pv6 rout e t able before area 1 becom es t ot ally st ubby, and
Exam ple 9- 9 shows t he rout e t able of Scabbers as part of t he t ot ally st ubby area.
Ex a m ple 9 - 8 . Th e I Pv6 r ou t e t a ble a t Sca bbe r s con t a in s 1 0 OSPF
e n t r ie s, a ll k n ow n via H e dw ig.
Scabbers#show ipv6 route
IPv6 Routing Table - 16 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
OI 2001:DB8:0:4::/64 [110/74]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:5::/64 [110/74]
via FE80::202:FDFF:FE5A:E40, Serial0/0
C
2001