IS-IS Network Design Solutions

Citation preview

IS-IS Network Design Solutions By Abe Martey , Scot t Sturgess

The definit ive I S-I S r efer ence and design guide.

•

Ext ensive cover age of bot h under lying concept s and pr act ical applicat ions of t he I S-I S pr ot ocol

•

Det ailed ex planat ion of how t he I S-I S d atabase w or k s and r elev ant

•

Com prehensive t ut orial on configuring and t roubleshoot ing I S-I S on Cisco r out er s

•

Advanced infor m at ion on I P net w or k design and per for m ance opt im izat ion st rat egies using I S-I S

•

Net w or k design case st udies pr ov ide a pr act ical per spect iv e of v ar ious design st r at egies

•

Com pr ehensiv e ov er v iew of r out ing and pack et -swit ching m echanism s

insight s int o t he oper at ion of t he shor t est pat h fir st ( SPF) algor it hm

on m oder n r out er s

•

A collect ion of I S-I S packet for m at s and analyzer decodes usefu l for m ast er ing t he nut s and bolt s of t he I S-I S pr ot ocol and t r oubleshoot ing com plex problem s

I nt er ior gat ew ay pr ot ocols such as I nt er m ediat e Syst em-t o-I nt erm ediat e Syst em ( I S-I S) are used in conj unct ion w it h t he Border Gat ew ay Prot ocol ( BGP) t o provide robust , resilient perform ance and int elligent rout ing capabilit ies required in large -scale and com plex int ernet w orking environm ent s. Despit e t he popularit y of t he I S-I S prot ocol, however, net working professionals have depended on rout er configurat ion m anuals , prot ocol specificat ions, I ETF RFCs, and draft s. Mast ering I S-I S, r egar dless of it s sim plicit y , has been a daunt ing t ask for m any. I S-I S Net w or k Design Solut ions provides t he first com prehensive coverage available on t he I S-I S prot ocol. Net working profess ionals of all lev els now hav e a single sour ce for all t he infor m at ion needed t o becom e t r ue ex per t s on t he I SI S prot ocol, part icularly for I P rout ing applicat ions. You'll learn about t he origins of t he I S-I S prot ocol and t he fundam ent al underlying concept s and t hen m ov e t o com plex prot ocol m echanism s involving building, m aint aining, and dissem inat ion of t he inform at ion found in t he I S-I S dat abase on a r out er . Subsequent discussions on I P net w ork design issues include configurat ion and t r oubleshoot ing t echniques, as w ell as case st udies w it h pr act ical design scenar ios.

1

Copyright Abe Mar t ey Copyright © 2002 Cisco Press Published by: Cisco Pr ess 201 West 103r d St r eet I ndianapolis, I N 46290 USA All r ight s r eser v ed. No par t of t his book m ay be r epr oduced or t ransm it t ed in any form or by any m eans, elect r onic or m echanical, including phot ocopying, r ecor ding, or by any infor m at ion st orage and ret rieval syst em , w it hout w rit t en perm ission from t he publisher, except for t he inclusion of brief quot at ions in a review . Pr int ed in t he Unit ed St at es of Am er ica 1 2 3 4 5 6 7 8 9 0 Fir st Pr in t in g Fe br u a r y 2 0 0 2 Libr a r y of Con gr e ss Ca t a login g- in- Pu blica t ion N u m be r : 9 9 - 6 7 9 3 8

Warning and Disclaimer This book is designed t o pr ovide infor m at ion about I S-I S. Ev er y effor t has been m ade t o m ake t his book as com plet e and as accur at e as possible, but no w ar r ant y or fit ness is im plied. The infor m at ion is pr ovided on an " as is" basis. The aut hor , Cisco Pr ess, and Cisco Syst em s, I nc. shall hav e neit her liabilit y nor r esponsibilit y t o any per son or ent it y w it h r espect t o any loss or dam ages ar ising fr om t he infor m at ion cont ained in t his book or fr om t he use of t he discs or pr ogr am s t hat m ay accom pany it . The opinions expr essed in t his book belong t o t he aut hor and ar e not necessar ily t hose of Cisco Syst em s, I nc.

Feedback Information At Cisco Pr ess, our goal is t o cr eat e in -dept h t echnical books of t he highest qualit y and value. Each book is cr aft ed w it h car e and pr ecision, under going r igor ous dev elopm ent t hat inv olv es t he unique expert ise o f 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 r egar ding how w e can im pr ove t he qualit y of t his book, or ot her w ise alt er it t o bet t er suit your

2

needs, you can cont a ct us t hrough em ail at

[email protected] .

Please m ak e sur e t o include

t he book t it le and I SBN in your m essage. We gr eat ly appr eciat e your assist ance.

Trademark Acknowledgments All t erm s m ent ioned in t his book t hat ar e know n t o be t r adem ar ks or ser vice m ar ks have been appr opr iat ely capit alized. Cisco Pr ess or Cisco Sy st em s, I nc. cannot at t est t o t he accur acy of t his infor m at ion. Use of a t er m in t his book should not be r egar ded as affect ing t he v alidit y of any t r adem ar k or ser vice m ar k.

Credits Publishe r John Wait Edit or- i n- Chie f John Kane Cisco Syst e m s M a na ge m e nt Michael Hak k er t Tom Geit ner William Warren Pr oduct ion M a na ge r Pat r ick Kanouse Acquisit ions Edit or Tracy Hughes D e ve lopm e nt Edit or Howard Jones Pr oj e ct Edit or San Dee Phillips

3

Copy Edit or Keit h Cline Te chnica l Edit or s Blair Buchanan Thom as Kr am er Te a m Coor dina t or Tam m i Ross Book D e signe r Gina Rexrode Cove r D e signe r Louisa Klucznik Com posit or Oct al Publishing, I nc. I nde x e r s Tim Wr ight Brad Herrim an Cor por a t e H e a dqua r t e r s Cisco Syst em s, I nc. 170 West Tasm an Dr iv e San Jose, CA 95134-1706 USA ht t p: / / www.cisco.com

Tel: 408 526-4000

4

800 553-NETS ( 6387) Fax : 408 526-4100 Eur ope a n H e a dqua r t e r s Cisco Syst em s Eur ope 11 Rue Cam ille Desm oulins 9 2 7 8 2 I ssy-les-Moulineaux Cedex 9 France ht t p: / / www- europe.cisco.com

Tel: 3 3 1 5 8 0 4 6 0 0 0 Fax : 33 1 58 04 61 00 Am e r ica s H e a dqua r t e r s Cisco Syst em s, I nc. 170 West Tasman Drive San Jose, CA 95134-1706 USA ht t p: / / www.cisco.com

Tel: 408 526-7660 Fax : 4 0 8 5 2 7 -0883 Asia Pa cific H e a dqua r t e r s Cisco Syst em s Aust r alia, Pt y., Lt d Lev el 17, 99 Walk er St r eet Nor t h Sy dney NSW 2059 Aust ralia

5

ht t p: / / www.cisco.com

Tel: + 61 2 8448 7100 Fax : + 61 2 9957 4350 Cisco Syst e m s ha s m or e t ha n 2 0 0 office s in t he follow ing count r ie s. Addr e sse s, ph on e n u m be r s, a n d fa x n u m be r s a r e list e d on t h e Cisco W e b sit e a t www.cisco.com / go/ offices

Ar gent ina • Aust r alia • Aust r ia • Belgium • Br azil • Bulgar ia • Canada • Chile • China • Colom bia • Cost a Rica • Cr oat ia • Czech Republic • Denm ar k • Dubai, UAE • Finland • Fr ance • Ger m any • Gr eece • Hong Kong • Hungar y • I ndia • I n donesia • I r eland I sr ael • I t aly • Japan • Kor ea • Lux em bour g • Malay sia • Mex ico • The Net h er lands • New Zealand • Nor w ay • Per u • Philippines Poland • Por t ugal • Puer t o Rico • Rom ania • Russia • Saudi Ar abia • Scot land • Singapor e • Slov ak ia • Slov enia • Sout h Afr ica • Sp ain Sw eden • Sw it zer land • Taiw an • Thailand • Turkey • Ukraine • Unit ed Kingdom • Unit ed St at es • Venezuela • Viet nam • Zim babwe Copyright © 2000, Cisco Syst em s, I nc. All right s reserved. Access Regist rar, AccessPat h, Are You Ready, ATM Dir ect or , Br ow se w it h Me, CCDA, CCDE, CCDP, CCI E, CCNA, CCNP, CCSI , CDPAC, CiscoLink, t he Cisco Net Works logo, t he Cisco Pow ered Net w ork logo, Cisco Syst em s Net working Academ y, Fast St e p, FireRunner, Follow Me Browsing, Form Share, GigaSt ack, I GX, I nt elligence in t he Opt ical Core, I nt ernet Quot ient , I P/ VC, iQ Breakt hrough, iQ Expert ise, iQ Fast Track, iQuick St udy, iQ Readiness Scorecard, The iQ Logo, Kernel Proxy, MGX, Nat ural Net work View er, Net w ork Regist rar, t he Net w orkers logo, Packet , PI X, Point and Click I nt ernet working, Policy Builder, Rat eMUX, ReyMast er, ReyView, Script Share, Secure Script , Shop wit h Me, SlideCast , SMARTnet , SVX, TrafficDirect or, TransPat h, VlanDirect or, Voice LAN, Wavelengt h Rout er , Wor kgr oup Dir ect or , and Wor kgr oup St ack ar e t r adem ar ks of Cisco Sy st em s, I nc.; Changing t he Way We Wor k , Liv e, Play , and Lear n, Em pow er ing t he I nt er net Gener at ion, ar e ser vice m ar ks of Cisco Syst em s, I nc.; and Air onet , ASI ST, BPX, Cat aly st , Cisco, t he Cisco Cert ified I nt ernet w ork 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, Collision Free, Ent erprise/ Solver, Et herChannel, Et herSwit ch, Fast Hub, Fast Link, Fast PAD, I OS, I P/ TV, I PX, Light St ream , Light Swit ch, MI CA, Net Ranger, Post -Rout ing, Pre -Rout ing, Regist rar, St rat aView Plus, St rat m , Sw it chProbe, TeleRout er, are regist ered t radem arks of Cisco Syst em s, I nc. or it s affiliat es in t he U.S. and cer t ain ot her count r ies. All ot her br ands, nam es, or t r adem ar k s m ent ioned in t his docum ent or Web sit e ar e t he pr oper t y of t heir r espect iv e ow ner s. The use of t he w or d par t ner does not im ply a par t ner ship r elat ionship bet w een Cisco and any ot her com pany. ( 0010R)

Dedication Th is book is dedicat ed t o m y affect ionat e m om , Em elia, for giving m e her best .

6

About the Authors Abe M a r t e y , CCI E # 2 3 7 3 , is a pr oduct m anager at t he Cisco I nt er net PoP Sy st em s Business Unit ( I PSBU) , w hich is t he hom e of t he Cisco 12000 I nt er net Rout er Ser ies. Abe focuses on high-speed I P rout ing syst em s and relat ed t echnologies. Prior t o t his posit ion, Abe held var ious suppor t engineer ing posit ions, including t im e at t he Cisco Technical Assist ance Cent er on t he I P Rout ing Pr ot ocols Team and lat er on t he I SP Team ( now I nt er net Engineer ing Services Team ) , w here he developed special int erest in t he I S-I S r out ing pr ot ocol. Abe holds a m ast er s degr ee in elect r ical engineer ing and has been w it h Cisco Syst em s for six year s. Scot t St u r ge ss, CCI E # 2 3 4 6 , is a t echnical leader w it hin t he Cor e I P Engineer ing's Deploy m ent and Scalabilit y Team , w her e he is pr im ar ily inv olv ed in t he adv ancem ent of linkst at e r out ing pr ot ocols. Now in his sixt h year at Cisco Syst em s, Scot t held var ious r oles fr om cust om er support t o consult ancy, focusing on I P r out ing pr ot ocols and I nt er net ar chit ect ur e, pr im ar ily w it hin t he I nt er net ser vice pr ovider ar ena. Scot t holds a fir st class honor s degr ee in elect r ical and elect r onic engineer ing.

About the Technical Reviewers Bla ir Bu ch a n a n , CCI E # 1 4 2 7 , is an int er net w or k ar chit ect w ho bases his consult ing pr act ice in Ot t aw a, Canada. For alm ost 30 year s, Mr . Buchanan's car eer in dat a com m unicat ion includes soft w are developm ent , st andards part icipat ion, int ernet w ork design, and educat ion. Mr . Buchanan holds a bachelor 's degr ee in com put er science, has been a cer t ified Cisco Sy st em s I nst r uct or since 1992, and ear ned his CCI E in 1995. Th om a s Kr a m e r , CCI E # 2 6 6 2 , has been w or k ing ov er t he past sev en y ear s at Cisco Syst em s on I P rout ing and core t echnologies. Aft er se ver al year s w or king in Br ussels, he r elocat ed r ecent ly t o Mex ico Cit y , w her e he w or k s in a consult ing funct ion for Cisco in t he Lat in Am erican t heat er. He holds a m ast er's degree in elect rical engineering and t elecom m unicat ion and is a r ecer t ified CCI E in I P r out ing and sw it ching.

Acknowledgments Fir st of all, I 'd like t o expr ess sincer e t hanks t o Scot t St ur gess for pr oviding t im ely cont r ibut ions t o Chapt ers 7 and 8 , helping t o m ake t he proj ect deadline. Scot t also review ed som e of t he ot her chapt er s. The edit or ial t eam at Cisco Pr ess w as phenom enal, and m any folk s w or k ed har d on v ar ious aspect s of t he book t o br ing it t o fr uit ion. I 'd like t o sincer ely t hank ev er y one of t hem and also m ent ion t he follow ing indiv iduals w it h w hom I int er act ed t he m ost : Alicia Buckley encouraged m e t o t ake up t he proj ect ; Tracy Hughes w as alw ays ready t o for giv e m e y et ano t her t im e w henever I fell behind schedule. Writ ing part -t im e w as v er y challenging, and Tracy's ext rem e pat ience and underst anding w as very helpful. Many t hanks t o John Kane for his m ent or ship and also t o How ar d Jones and San Dee Phillips for t heir ent husia sm and t horoughness in review ing t he m anuscript s. The t echnical r eview er s, Thom as Kr am er and Blair Buchanan, w er e fant ast ic; and alt hough t heir t ough r eview s com pelled m e t o w or k har der and longer t han I expect ed, I count m yself

7

v er y luck y t o hav e had t heir k now ledge and ex per ience at m y disposal! I w ish t o t hank t hem for t heir t im e and gr eat feedback for im pr oving t he t ext , and for m aking m e a bet t er w r it er . Henk Sm it influenced m y int erest in I S-I S w hile he w as at Cisco as an I S-I S pr ot ocol dev elopm ent engineer, and I 'd like t o t hank him for his t ut orials and insight s during our m any int er act ions w hen I w as a suppor t engineer . I also w ant t o ack now ledge Henk 's significant cont r ibut ions t o t he enhancem ent of t he I S-I S pr ot ocol w hile at Cisco Sy st em s and as a cur r ent act iv e par t icipant in t he I ETF's I S-I S Wor k ing Gr oup. I 'd like t o t hank sever al individuals, pr ofessional colleagues, and fr iends w it hin and out side of Cisco Syst em s w ho have been r esour ceful and suppor t ive in diver se w ays, eit her t hr oughout t his pr oj ect , or have gener ally helped shape m y car eer . They ar e nam ed in r andom or der as follow s: Jeff Zirker, Tony Bat es, Bala Nagesh, Richard Harvey, Praveen Akkiraj u, Chris Whyt e, Ferdinand Sales, Scot t Yow , Niklas Mont in, Kevin Macaluso, Jean Nicolas, Heba I brahim , Hassan Kassem , Sam pson Asiedu, Sandra Bell, Bill Ware, Tom Snyder, Bob Collet , Rob Saileanu, and m any ot her s. To all m y m any for m er colleagues in t he Cisco TAC, t hank s a lot for shar ing y our k now ledge and ex per t ise. Finally, I 'd like t o expr ess grat it ude and love t o m y fam ily for support ing t his effort and for endur ing m any ev enings and w eek ends w it hout m e, w hen I engulfed m y self in t his pr oj ect . Thanks again for all t he love, car ing, and suppor t ! Abe Mar t ey

Foreword Wit h t he I nt er net cont inuing t o expand, t he need for r obust and flexible I P r out ing pr ot ocols t o sust ain t he ex pansiv e global r out ing sy st em can nev er be ov er em phasized. Of all t he I P r out ing pr ot ocols t hat evolved alongside t he I nt er net , only t hr ee of t hem sur vived t he t est of t im e a nd ar e cur r ent ly w idely deployed: BGP for ext er ior r out ing, and OSPF and I S-I S for int er ior r out ing. The I S-I S Pr ot ocol has em er ged as one of t he univer sally adopt ed and w idely used I nt er ior Gat ew ay Pr ot ocols, besides OSPF. BGP r em ains t he de fact o Ext er io r Gat ew ay Prot ocol for int erdom ain rout ing. I S-I S is used as an I GP by m ost of t he Tier 1 and Tier 2 I nt er net ser v ice providers for bot h pract ical and hist orical reasons. The w isdom and insight of t he original pr ot ocol designer s and subsequent pr agm at ic co nt ribut ions by t he I ETF m anifest in t he pr ot ocol's flexibilit y can be easily adapt ed for m any em er ging applicat ions, such as MPLS Tr affic Engineer ing and I Pv6. The scalabilit y and ext ensibilit y of t he I S-I S pr ot ocol m ade it an obv ious choice for I GP w hen I dir ect ed t he design and deploym ent of one of t he lar gest exist ing I P backbones sever al year s ago. Our high confidence and com for t level allow ed us t o r un bot h I P and I SO r out ing in a single inst ance of I S-I S. Many net w orking professionals have longed for a r eadable t ut or ial and design guide on t his popular pr ot ocol. The or iginal specificat ion of t he I S-I S pr ot ocol, I SO 10589, is a t ough indoct rinat ion for m ost people int erest ed in grasping fundam ent als of operat ion of I S-I S.

8

Addit ionally, several enhancem e nt s t o t he original I S-I S pr ot ocol, including RFC 1195 and m any r ecent r elat ed RFCs and I ETF dr aft s, ar e not capt ur ed in one place for easy access by int er est ed r eader s. This book provides t he first , m ost ext ensive coverage of t he I S-I S prot ocol, writ t en a nd r eview ed by net w or king exper t s w it h m any year s of pr act ical exper ience designing, deploying, and t roubleshoot ing I S-I S-based net w or k s and also w or k ing w it h adv anced r out ing sy st em s. Hav ing fir st hand ex per ience w it h t he challenges and fun in deploy ing and using I S-I S t o it s full pot ent ial, I only w ish t his excellent book had been available sooner. I S-I S Net w or k Design Solut ions by Abe Mar t ey cer t ainly augm ent s t he list of excellent lit erat ure on int ernet w orking t echnology brought t o m any net w orking professionals w or ldw ide by Cisco Pr ess in fulfilling one of it s pr im ar y goals —shar ing Cisco's net w or k ing ex per t ise! This book is a k ey r efer ence for any one int er est ing in I GP deploy m ent and ev olut ion. Ton y Bat es, VP/ GM I nt er net PoP Syst em s Business Unit Cisco Syst em s, I nc.

9

Introduction The I nt er m ediat e Sy st em-t o-I nt erm ediat e Syst em ( I S-I S) Rout ing Pr ot ocol is a v er sat ile and r obust r out ing pr ot ocol suit able for bot h I P and CLNP applicat ions. I n t he I P w or ld, it has em er ged as t he only p ract ical alt ernat ive t o t he Open Short est Pat h First Prot ocol for I nt erior Gat ew ay Prot ocol ( I GP) applicat ions in I nt ernet Service Provider ( I SP) net w orks. I S-I S is t he I GP of choice in m ost t ier one I SP env ir onm ent s and it s significance cer t ainly ex plains w hy it feat ur es in t he CCI E Rout ing and Sw it ching, as w ell as t he CCI E I P r ecer t ificat ion exam s. Despit e t he im port ance of I S-I S in I P net w orking, it has received lit t le coverage in t he t echnical pr ess and net w or k ing lit er at ur e. Most user s and net w or k ing professionals rely on scant y lit erat ure and t he configurat ion m anuals from Cisco and ot her m aj or rout er vendors t o boost t heir k now ledge on I S-I S. Many rout ing prot ocol t ext s from Cisco Press cover I S-I S in sect ions, yet OSPF is covered in m any book t it les . This fir st book t it le on I S-I S br eak s t r adit ion of inadequat e I S-I S coverage by focusing prim arily on I S-I S. I S-I S Net w or k Design Solut ions follows t he m uch -cher ished Cisco Pr ess appr oach of com bining t heor y and pr act ice w it hin t he set up of t he Cisco Rout ing envir onm ent . The t ext also includes elabor at e com par ison w it h it s com pet it or, OSPF.

Objectives The over all obj ect ive of t his book is t o br ing com pr ehensive know ledge about t he I S-I S r out ing prot ocol t o t he I P net w orking professional at any career leve l. Coverage of t he I S-I S pr ot ocol in t his book st ret ches from basic t o advanced concept s. Like m ost I P rout ing prot ocols, I S-I S is st ill evolving w it h var ious enhancem ent s st ill being discussed and for m alized w it hin t he I ETF. This book builds a br idge bet w een t he or iginal I S-I S pr ot ocol, w hich w as specified for rout ing of t he I SO Connect ionless Net work Prot ocol ( CLNP) , and all t he recent I P-relat ed enhancem ent s. I t s pr act ical slant , w hich ex ploit s t he ubiquit ous Cisco I OS env ir onm ent , is designed t o provide you hands -on experience for usage and configurat ion of t he I S-I S pr ot ocol. I n t he gr and schem e, t he m at er ial pr esent ed should pr ovide you w it h t he necessar y advanced skills for underst anding, designing, and applicat ion of I S-I S as an I GP in I P environm ent s. The num erous t ables, references, and t roubleshoot ing inform at ion m akes t his book an excellent r efer ence.

Audience The t ar get audience of t his book is net w or k ing pr ofessionals w it h div er se lev els of ex per ience. I t is w r it t en for any one w ho is new t o I S-I S or has a decent lev el of fam iliar it y , as w ell as t he experienced rout ing prot ocol expert . The reader is expect ed t o have knowledge of t he basics of t he TCP/ I P Pr ot ocol suit e, as w ell as I P r out ing concept s. The fir st chapt er of t he book pr ovides an over view of I P r out ing and elabor at es on how I P r out er s w or k and should be int er est ing t o any net w or king pr ofessional. Even t hough a fair am ount of t he t ext is dedicat ed t o t he basics of I S-I S, a lar ge sect ion of t he book cov er s adv anced concept s including t r oubleshoot ing, design, deploym ent , and m aint enance of I S-I S net w or ks. The advanced sect ions ar e useful for net w or king pr ofessionals pr epar ing for t he Cisco Cer t ified I nt er net w or k Expert ( CCI E) Rout ing and Sw it ching Lab Exam , t he CCI E I P Recert ificat ion Exam or sim ilar professional cert ificat ion t est s.

10

Organization This book is or ganized int o t hr ee par t s and t w o appendix es.

Part I

discusses I P rout ing

t echnology and cov er s t he t heoret ical foundat ions of t he I S-I S prot ocol including prot ocol concept s, feat ures, im plem ent at ion specifics, prot ocol m echanism s, t im ers, m et rics, and ot her par am et er s. Par t I I

builds on t he m at erial discussed in Part I and pr ovides advanced infor m at ion on I P net w or k

design st rat egies using t he I S-I S prot ocol. This sect ion also provides cases st udies t o elaborat e and precipit at e t he design principles present ed here. provides configurat ion and t roubleshoot ing inform at ion wit h a hands -on appr oach using

Par t I I I

Cis co r out er s. Appendix A

is a collect ion of I S-I S packet for m at s and analyzer capt ur es t hat ar e pr esent ed as

supplem ent ar y or r efer ence infor m at ion t o assist w it h under st anding t he m at erial covered in Part I

. This inform at ion is useful for st udying and m ast ering com plicat ed I S-I S pr oblem s, such

as im plem ent at ion or int er oper abilit y issues. The follow ing is a list of chapt er s in each m aj or sect ion: Part I:

IS-IS Protocol: Design Specification and Features

•

Chapter 1 :

Ov er v iew of I P Rout ing

•

Chapter 2 :

I nt roduct ion t o t he I S-I S Rout ing Pr ot ocol

•

Chapter 3 :

I nt egrat ed I S-I S Rout ing Pr ot ocol Concept s

•

Chapter 4 :

Addressing in I nt egrat ed I S-I S

Chapter 5 :

The I S-I S Link-St at e Dat abase

Chapter 6 :

The Short est Pat h First Algorit hm

• • Part II:

Integrated IS-IS Network Design for IP Internets

•

Chapter 7 :

General Net work Design I ssues

•

Chapter 8 :

Net work Design Scenarios

Part III:

Configuring and Troubleshooting Integrated IS-IS

•

Chap ter 9 :

•

Chapt er 10 :

Part IV:

Configuring I S-I S for I P Rout ing on Cisco Rout ers Troubleshoot ing t he I S-I S Rout ing Pr ot ocol

Appendixes

•

Appendix A

•

Appendix B :

: I S-I S Packet Form at s Answ er s t o Rev iew Quest ions

11

How to Read This Book This book is or ganized logically w it h t he subj ect m at t er get t ing pr ogr essively advanced, yet flex ible enough t o allow r eader s t o access sect ions or chapt er s of int er est accor ding t o t heir lev el of I S-I S k now ledge or int er act ion w it h t he pr ot ocol. Advanced user s m ight w ant t o br ow se t hr ough Chapter 1 t o r efr esh t heir know ledge on t he fundam ent als of I P r out ing and spend m or e t im e st udying t he chapt ers in Part I t o m ast er advanced knowledge about t he I S-I S prot ocol. Ot her readers m ay com bine t he concept s present ed in Part I w it h t h e design an d deploym ent m at erial present ed in Par t I I . Readers int erest ed in t roubleshoot ing can focus on Par t I I I and also r ev iew Part I in order t o underst and how I S-I S w or ks. For t he lat t er t ype of r eader s, t he par am et er t ables in Part I and t he pack et for m at s and analy zer capt ur es in Appendix A p rov ide a good reference for regular t roubleshoot ing sit uat ions and relat ed responsibilit ies in oper at ions envir onm ent s. This book also pr ov ides num er ous r efer ences and Web link s t o r elev ant m at er ial t hat is not elabor at ed her e because of space lim it at ion or because it is bey ond t he scope of t he book . Readers are encouraged t o consult included references for addit ional inform at ion t hat augm ent s t he present ed m at erial.

Command Syntax Conventions Com m and synt ax in t his book conform s t o t he follow ing convent ions :

•

Com m ands, keyw ords, and act ual values for argum ent s are bold.

•

Ar gum ent s ( w hich need t o be r eplaced w it h an act ual v alue) ar e italic.

•

Opt ional keyw or ds and/ or ar gum ent s ( or a choice of opt ional keyw or ds, and/ or argum ent s) are in bracket s [ ] .

•

Choice of m a ndat or y k ey w or ds and/ or ar gum ent s ar e in br aces { } .

•

These conv ent ions ar e for sy nt ax only . Act ual configur at ions and ex am ples do not follow t hese conv ent ions.

12

Part I: IS-IS Protocol: Design Specification and Features Par t I I S- I S Prot ocol: Design Specificat ion and Feat ures Chapt er 1 Overview of I P Rout ing Chapt er 2 I nt roduct ion t o t he I S- I S Rout ing Prot ocol Chapt er 3 I nt egrat ed I S- I S Rout ing Prot ocol Concept s Chapt er 4 Addressing in I nt egrat ed I S- I S Chapt er 5 The I S- I S Link- St at e Dat abase Chapt er 6 The Short est Pat h First Algorit hm

13

Chapter 1. Overview of IP Routing This chapt er focuses on t he gener al design and oper at ion of r out ing pr ot ocols for t he I nt er net Pr ot ocol ( I P) . I t also pr ovides backgr ound infor m at ion on t he I P pr ot ocol, as w ell as insight s int o how I P pack et s ar e r out ed t hr ough a dat a com m unicat ions net w or k . The ensuing discussions span I P r out ing pr inciples and pack et-sw it ching m echanism s av ailable on I P r out er s. Obviously, t his chapt er has a br oader char t er t han t he int ended focus of t his book. I SI S-focused cov er age st ar t s in Chapt er 2 , " I nt roduct ion t o t he I S-I S Rout ing Pr ot ocol." This chapt er cover s t he follow ing m aj or t opics:

•

I P r out ing and for w ar ding

•

Essent ials of I P addr essing

•

Classificat ion of I P rout ing prot ocols

•

Unicast versus m ult icast rout ing

•

Cisco pack et-swit ching m echanism s

•

Com m ent s on I Pv 6

The elabor at e cover age of gener al I P r out ing issues should help r em ove m any m isconcept ions held by m ost readers. For ot her readers, t he m at erial provides an excellent refresher on I P r out ing pr inciples.

IP Routing and Forwarding I P has em er ged as t he dom inant Lay er 3 pr ot ocol for connect ionless net w or k ing. I P is par t of a suit e of prot ocols referred t o as t he Transm ission Cont rol Prot ocol/ I nt ernet Prot ocol ( TCP/ I P) pr ot ocol suit e ( or sim ply as t he I nt er net Pr ot ocol suit e) . The I P suit e em br aces m any pr ot ocols, som e of w hich ar e list ed in RFC 1800, " I nt er net Official Pr ot ocol St andar ds." This list of I P-r elat ed pr ot ocols cont inues t o gr ow as new applicat ions em er ge. Som e k ey I P prot ocols include t he follow ing:

•

I nt er net Pr ot ocol ( I P)

•

Tr ansm ission Cont r ol Pr ot ocol ( TCP)

•

User Dat agr am Pr ot ocol ( UDP)

•

I nt er net Message Cont r ol Pr ot ocol ( I CMP)

•

Address Resolut ion Prot ocol ( ARP)

TCP and UDP pr ov ide t r anspor t for applicat ions and r un over t he I P lay er . I CMP is a cont r ol pr ot ocol t hat w or k s alongside I P at t he net w or k lay er . ARP pr ov ides addr ess r esolut ion bet w een t he net w or k layer and t he under lying dat a link layer . Num er ous applicat ions use t he t r anspor t ser vices of TCP and UDP. Som e co m m on exam ples include t he following:

•

Te lne t— A vir t ual t er m inal applicat ion t hat uses TCP for t r anspor t

•

File Tr a n spor t Pr ot ocol ( FTP) — A file t r ansfer applicat ion t hat uses TCP for t r anspor t

14

•

Tr ivia l File Tr a n sfe r Pr ot ocol ( TFTP) — A file t r ansfer applicat ion t hat uses UDP for t r anspor t

•

D om a in N a m e Se r vice ( D N S) — A nam e -t o-addr ess t r anslat ion applicat ion t hat uses bot h TCP and UDP t r anspor t

I P is lar gely r esponsible for t he cont inuing success of t he TCP/ I P suit e. The popular it y of I P is m ainly cent er ed on it s sim plicit y and high efficiency for dat a t ransfer. As a connect ionless prot ocol, I P forw ards dat a in self-cont ained r out able unit s k now n as dat agram s or packet s. Each pack et cont ains infor m at ion, such as sour ce and dest inat ion addr esses, w hich is used by rout er s w hen m ak ing for w ar ding and policy decisions. I n connect ionless net w or king, t her e is no need for pr ior set up of an end -t o-end pat h bet w een t he source and dest inat ion before dat a t ransm ission is init iat ed. A file can be t ransm it t ed from one end of t he net w or k t o anot her by br eaking it dow n int o packet s, each of w hich is forw arded independent ly along t he best pat h by rout ers locat ed bet w een t he source and dest inat ion. I P for w ar ding is pr im ar ily based on t he dest inat ion addr ess, even t hough t he sou r ce addr ess and ot her par am et er s in t he I P header can be used for policy-based for w ar ding. I P forw arding is, t herefore, com m only referred t o as dest inat ion -based. Rout ing and for w ar ding essent ially m ean t he sam e t hing w it h r egar d t o I P, ev en t hough t hey 'v e t ak en differ ent shades in m eaning along w it h t he ev olut ion of r out er s. A rout er is a net w or k dev ice t hat essent ially consist s of a collect ion of net w or k int er faces linked t oget her by a high-speed bus or a com plex int er connect ion sy st em , such as a cr ossbar-sw it ch or shared m em ory fabric. A rout er has t w o funct ional planes: dat a and cont rol. Frequent ly, bot h funct ions are perform ed by an int elligent subsy st em k now n as t he rout e processor. Most m odern high -speed r out er s ar e designed w it h a clear separ at ion bet w een t he cont r ol and dat a planes ( see Figure 1 - 1 ) . The con t r ol plane funct ions ar e cent er ed on building t he necessar y int elligence about t he st at e of t he net w or k and a r out er 's int er faces. I P r out ing applicat ions or pr ot ocols pr ovide t he fr am ew or k for gat her ing t his int elligence. The dat a plane handles act ual pack et pr ocessing and for w ar ding by r ely ing on t he int elligence of t he cont r ol plane. Figur e 1 - 1 . D ist r ibut e d r out e r a r chit e ct ur e .

15

I P rout ing is t h e b roader pr ocess of collect ing r out ing infor m at ion about t he net w or k, a funct ion t hat is per for m ed in t he cont r ol plane. I P r out ing pr ot ocols pr ocess t his infor m at ion t o det er m ine t he best pat hs t o know n dest inat ions in t he net w or k. The know n best pat hs ar e st or ed in t he rout ing t able or t h e rout ing inform at ion base ( RI B) . The r out ing t able is t hen used for for w ar ding packet s, m oving t hem out of t he r out er ont o t he best pat hs t o t he next hop and t ow ar d t heir int ended dest inat ions. The best pat h is fr equent ly the pat h w it h t he low est value of m et r ic or cost t o t he dest inat ion. I P forwarding involves pr ocessing infor m at ion in t he header of an I P packet t o det er m ine how t o adv ance it t ow ar d t he t ar get dest inat ion. This includes act iv it ies such as look ing up t he d est inat ion address in a forw arding dat abase for t he exit int erface, reducing t he I P t im e -t o-live ( TTL) value, calculat ing t he I P checksum value, queuing t he packet at t he exit int er face, and ev ent ually get t ing t he pack et out of t he r out er ont o t he link t o the nex t -hop rout er. Sim ilar for w ar ding funct ions ar e per for m ed independent ly on t he r out er at t he nex t hop and at ev er y rout er in t he pat h, each t im e get t ing t he packet closer t o it s dest inat ion unt il it finally arrives t h er e. Figure 1 - 1

illust rat es t he archit ect ure of a rout er w it h dist ribut ed forw arding capabilit ies. I n t his

archit ect ure, each int erface processor ( or line card) feat ures an independent forwarding engine, w hich is responsible for I P forw arding. The int erface processors direct ly sw it ch packet s bet w een each ot her . I P for w ar ding engines ar e opt im ized for fast er packet pr ocessing and sw it ching from t he source int erface t o t he dest inat ion int erface on a rout er. The I P rout ing funct ionalit y is perform ed on t he rout e processor, w hich has a rout ing engine for calculat ing rout es. The rout e processor runs a r out ing pr ot ocol t hat allow s it t o int er act w it h ot her rout ers, gat her and process rout ing inform at ion, and build t he rout ing t able. The

16

r out e pr ocessor is opt im ized for gat her ing r out ing infor m at ion, w hich it event ually shar es w it h t he int er face pr ocessor s. The Cisco 12000 Ser ies r out er s have a fully dist r ibut ed ar chit ect ur e. Figure 1 - 2

show s an alt er nat iv e r out er ar chit ect ur e w it h a dedicat ed packet processor feat ur ing a

high-speed for w ar ding engine designed t o pr ov ide cent r alized pack et sw it ching for t he w hole sy st em . Also show n is a separ at e r out e processor . As in t he dist r ibut ed ar chit ect ur e, t he dat a and cont rol planes are separat ed. I nt erface processors in t he cent ralized archit ect ure do not have forw arding int elligence t o exchange packet s direct ly but , inst ead, direct all packet s t o t he packet pro cessor w here act ual forw arding is done. This t ype of rout er archit ect ure is described as cent ralized. Figur e 1 - 2 . Ce nt r a lize d r out e r a r chit e ct ur e .

Fully dist r ibut ed and cent r alized r out er designs ar e t he ext r em es of r out er ar chit ect ur e opt ions, and t her e ar e v ar ious hy br id opt ions in bet w een t hem . One opt ion is t o int egr at e t he pack et and r out e pr ocessor s show n in Figure 1 - 2 int o a single hardware elem ent , com m only r efer r ed t o as a r out e sw it ch pr ocessor. Ot her opt ions m ix cent r alized and dist r ibut ed for w ar ding capabilit ies in t he sam e r out er as in t he ar chit ect ur e of t he Cisco 7500 Ser ies rout ers. These rout ers feat ure hardware m odules called versat ile int erface processors (VI P) and r out e sw it ch pr ocessors ( RSP) . The VI P pr ovides dist r ibut ed for w ar ding, w her eas t he RSP com bines r out ing and cent r alized pack et-processing capabilit ies. The r out ing infor m at ion collect ed by a r out er and shar ed w it h ot her r out er s in t he net w or k consist s of I P subnet s or addr ess pr efix es t hat ar e associat ed w it h v ar ious link s in t he net w or k . The host s in a net w or k w her e m ost applicat ions r eside ar e t y pically connect ed t o local-ar ea net w or k ( LAN) m edia. The I P addr ess of a host is based on t he subnet assigned t o it s LAN.

17

The follow ing sect ion br iefly discusses I P addr essing in gener al and pr ov ides a r efr esher for I P subnet t ing and r elat ed subj ect s, such as variable- lengt h subnet m asking ( VLSM) an d classless int erdom ain rout ing ( CI DR) . Lat er discussions focus on v ar ious cat egor ies of I P r out ing pr ot ocols and pack et-sw it ching m echanism s used for I P for w ar ding on Cisco r out er s.

Essentials of IP Addressing Addressing and rout ing are inext ricably linked. To provide a dat agram ( packet ) delivery ser v ice, I P needs t o hav e an addr essing schem e t o denot e t he sour ce of a pack et and it s int ended dest inat ion. Having a nat ive addr essing schem e enables I P, w hich oper at es at Layer 3, t o be independent of t he under lying LAN or w ide -area net work ( WAN) t ransport m edium . The or iginal ar chit ect s of t he I P prot ocol chose a 32 -bit addr essing schem e, w hich in r aw value allows 2 32 ( 4,294,967,295) unique host addr esses t o be defined. Alt hough t his num ber seem ed reasonably large at t he init ial st ages of deploym ent of t he I nt er net , t he 32-bit addr essing schem e has t ur ned out t o be one of t he significant short com ings of I P version 4 ( I Pv4) . This is because of t he unexpect ed large -scale, m ult inat ional expansion of t he I nt er net . Var ious clever schem es, such as Net work Address Translat ion ( NAT) , h av e been adopt ed by t he I nt er net com m unit y t o slow dow n t he pace of deplet ion of t he I Pv4 address space. NAT allow s t ranslat ion bet w een t he privat e address space and public space, m aking it possible for a lar ge num ber of host s using pr ivat e addr esses t o shar e a few public addr esses on an as -needed basis. Also building m om ent um and gaining popular it y is a new I P addr essing schem e r efer r ed t o as I P version 6 ( I Pv6) . I Pv 6 pr ov ides a lar ger addr ess space w it h 128-bit -w ide addr esses. Wit h an addr ess size four t im es longer , I Pv6 can suppor t a far lar ger num ber of addr esses t han it s pr edecessor , I Pv4. The follow ing subsect ions discuss various concept s relat ed t o I P addressing, including t he follow ing:

•

I Pv4 addr ess classes

•

Privat e I Pv4 address space

• •

I Pv 4 subnet t ing and v ar iable subnet m asking CI DR

Classful and Classless Addressing I n gener al, an im por t ant aspect of net w or k design involves m anagem ent of t he allocat ed addr ess space t hr ough fr ugal assignm ent of gr oups of addr esses of v ar y ing sizes. The concept of address classes was int ro duced int o I P net w orking t o assist m anageabilit y of t he I Pv4 addr ess space by car ving it int o pr edefined " chunks." Five addr ess classes ( A, B, C, D, and E) w er e defined and dist inguished by t he set t ing of t he m ost significant bit s of t he m ost significant b y t e in t he I P addr ess. These set t ings allow ed t he addr ess space t o be car v ed int o gr oups or classes of addr esses, each of w hich suppor t ed a cer t ain num ber of host s. I P net w or k s w er e t hen allocat ed a gr oup of addr esses fr om t he v ar ious addr ess classes t o m at ch t heir cur r ent size and fut ur e gr ow t h pot ent ial. Adm inist r at or s of t hese net w or ks w er e, in t ur n, supposed t o assign addresses t o t he connect ed host s, t hus facilit at ing m anagem ent of t he

18

addr ess space. Thr ee of t he fiv e addr ess classes ( A, B, and C) delineat ed t he associat ed 32-bit I P addr esses int o net w or k ident ifier ( net w or k I D) bit s and host ident ifier ( host I D) bit s as follow s:

•

Cla ss A— 8 -bit net w or k I D, 24-bit host I D

• •

Cla ss B— 1 6 -bit net w or k I D, 16-bit host I D Cla ss C— 2 4 -bit net work I D, 8 -bit host I D

Class D addr esses w er e set aside for I P m ult icast , and Class E addr esses w er e for experim ent al use.

Figure 1 - 3

illust r at es t he assignm ent of bit s in Class A addr esses.

Figur e 1 - 3 . Assignm e nt of Cla ss A a ddr e ss bit s.

The dot t ed -decim al not at ion used for represent ing 32 -bit binar y I P addr esses m akes t hem readable by hum ans. I n t he dot t ed -decim al r epr esent at ion, t he bit s ar e gr ouped int o oct et s and separ at ed by dot s. Each oct et of binar y bit s is t hen convert ed int o t he decim al equivalent . Table 1 - 1

show s t he addr ess r anges in dot t ed decim al for all classes. These r eflect only host

r anges, and net w or k num ber r anges ar e im plied. Var ious r ules guide t he act ual addr ess assignm ent for net w or k devices. RFC 1700 provides inform at ion on reserved addresses and o t her I nt er net-relat ed prot ocol par am et er s.

Table 1 - 1 . I P Addr e ss Cla sse s a nd Re pr e se nt a t ion

A B

0xxxxxxx 10xxxxxx

Fir st Byt e D e cim a l Ra nge 1–127 128–191

C

110xxxxx

192–223

D

1110xxxx

224–239

E

11110xxx

240–255

Addr e ss Cla ss

Bit Pa t t e r n of First Byt e

H ost Assign m e n t Ra n ge in D ot t e d D e cim a l 1.0.0.1 – 126.255.255.254 128.0.0.1 – 191.255.255.255.254 192.0.0.1 – 223.255.255.254 224.0.0.1 – 239.255.255.254 240.0.0.1 – 255.255.255.255

19

The foregoing discussion relat es t o w hat is described as classful addressing, so called because of t he class-relat ed int erpret at ion of t he I P address space. The flip side of classful addressing is classless addressing. Classless I P addr essing abandons t he not ion of I P addr ess classes by denot ing t he " w ould -be" net w or k num ber of an I P addr ess as som e pr efix of a specific lengt h. This m et hod of int erpret ing I P addresses allow s for m ore flexibilit y in address allocat ion and cont ribut es t o efficient usage of t he I Pv 4 addr ess space. Classless int er pr et at ion of I P addr esses allow s a lar ge addr ess block ( Class A, for exam ple) t o be split am ong m ult iple or ganizat ions inst ead of being allocat ed t o a single or ganizat ion t hat doesn't have enough host s and gr ow t h pot ent ial for t he w hole class. I n t he r ev er se dir ect ion, classless addressing allow s m ult iple Class C addr esses t o be aggr egat ed int o a lar ger block and adver t ised as a single addr ess pr efix. Addr ess aggr egat ion using CI DR pr ovides gr eat m em or y-saving oppor t unit ies on r out er s connect ed t o t he I nt er net , w hich is necessar y for scaling r out ing on t he I nt er net .

Private Address Space The pr iv at e addr ess space w as or iginally set aside for I P net w or k s t hat ar e not connect ed t o t he public I nt er net . NAT has em er ged as one of t he innovat ive w ays t o conser ve I P addr esses by conv er t ing bet w een public I nt er net and pr iv at e addr esses. This pr ocedur e allow s som e net w or ks w it h pr ivat e addr esses t o connect t o t he public I nt er net . The follow ing t hr ee blocks of addr esses ar e r eser ved for pr ivat e I nt er net s by RFC 1918:

•

10.0.0.0 – 1 0 .255.255.255

• •

172.16.0.0 – 172.31.255.255 192.168.0.0 – 192.168.255.255

Subnetting and Variable-Length Subnet Masks I P addr ess subnet t ing ex ist ed befor e t he int r oduct ion of classless addr essing and pr ov ided a w ay t o split a classful I P net w ork num ber int o m ult iple sm aller addr ess gr oups t hat can be applied t o differ ent segm ent s of a net w or k. Subnet t ing int r oduced anot her level of hier ar chy int o t he st r uct ur e of I P addr ess classes, by t ak ing a couple of bit s fr om t he host I D field t o ext end t he net work I D, creat ing subnet works ( or sim ply subnet ) . For ex am ple, one oct et of t h e t w o-oct et host bit s of a Class B addr ess m ight be used t o cr eat e 255 subnet s, each w it h only an oct et of host bit s ( see Figure 1 - 4 ).

20

Figur e 1 - 4 . Cla ss B subne t e x a m ple .

Subnet t ing an or iginal I P net w or k num ber int o sm aller block s allow s efficient assignm ent of addr esses t o t he sm aller segm ent s of a net w or k. An I P subnet m ask is used w it h I P addr esses t o dem arcat e t he host bit s. A subnet m ask uses a cont iguous st r ing of 1s t o r epr esent t he net w or k and subnet bit s and 0s for t he host bit s. The subnet m ask is also r epr esent ed in dot t ed-decim al form at . The m ask for t he subnet t ed Class B in

Figure 1 - 3

is illust rat ed in Figure 1 - 5 .

Figur e 1 - 5 . Su bn e t m a sk e x a m ple .

As show n in

Figure 1 - 5 ,

t he r ange of subnet s for 172.16.0.0, w hich has an or iginal m ask of

255.255.0.0 w hen subnet t ed by 8 bit s, is 172.16.1.0, 172.16.2.0, 172.16.3.0,…,172.16.255.0, each w it h a m ask of 255. 255. 255. 0.

21

A com m on w ay t o r epr esent an I P addr ess and it s m ask is by s pecify ing t he addr ess and j ust t he num ber of bit s in t he m ask. For exam ple, 172.16.1.0 255.255.255.0 can be r epr esent ed as 172.16.1.0/ 24 and 172.16.0.0 255.255.0.0 as 172.16.0.0/ 16. VLSM is an abst r act ion of subnet t ing t hat allow s differ ent m ask s t o be applied t o one net work num ber , pr oviding m or e flexibilit y and efficiency in t he use of I P addr esses. I n essence, VLSM uses m ult iple subnet m ask s t o subnet an addr ess m ult iple t im es and int o differ ent sizes as needed. For exam ple, you can t ake 172.16.0.0/ 16, subnet it t o 8 bit s, t ak e one of t he subnet s ( 172.16.1.0/ 24) , and subnet it furt her t o anot her 4 bit s t o obt ain sm aller blocks, such as 172.16.1.0/ 28, 172.16.1.16/ 28, 172.16.1.32/ 28, and so on.

Classless Interdomain Routing As discussed in t he pr evious sect ion, VLSM helps im pr ov e efficiency of addr ess usage w it hin a net w or k . Yet anot her pr oblem , w hich becam e appar ent in t he ear ly 1990s, w as t he im m inent deplet ion of I Pv4 addresses because of an inefficient allocat ion m et hod, w hich assigned large classful chunks of t he I P address space ( t ypically Class B addresses) t o not -large -enough or ganizat ions. To alleviat e t his pr oblem , or ganizat ions w er e inst ead assigned m ult iple Class C addresses t hat w ould m eet t heir im m ediat e needs. As t he I nt ernet grew in size, how e ver, r out ing soft w ar e and har dw ar e becam e st r ained by t he gr ow ing size of t he I nt er net r out ing t ables because of t he m any individual Class C ent r ies. The int r oduct ion of CI DR allow ed t he I P net w or k num ber in addr esses t o be any lengt h, obsolescing t he not ion addr ess classes and paving t he way for resource -saving ( m em ory and processing cycles) efficient aggregat ion of r out es in t he I nt er net t ables. How ever , elim inat ing t he st r ict boundar ies enfor ced by I P addr ess classes allow ed split t ing of classful net w or k addresses, such as Class A net w ork num ber s, over m ult iple net w or k dom ains. Wit h CI DR, a gr oup of Class C addr ess, such as 192.168.0.0 – 192.168.255.0, can be aggr egat ed as 192.168.0.0/ 16 inst ead of float ing in t he r out ing t ables as 256 individual Class C addresses. Such an aggregat ion ( 192.168.0.0/ 16) is frequent ly referred t o as a CI DR block or a super net . Sim ilar ly , CI DR allow s an addr ess such as 131.108.0.0/ 16 t o be div ided and allocat ed t o four differ ent or ganizat ions r at her t han one, as follow s: 131.1 08.0.0/ 22, 131.108.64.0/ 22, 131.108.128.0/ 22, and 131.108.192.0/ 22 ( see Figure 1 - 6 ) . See t he sect ion, " References ," for suggest ed reading on CI DR.

22

Figur e 1 - 6 . CI DR block s.

Classification of IP Routing Protocols Rout ing bet w een t he var ious segm ent s of a net w or k can be achieved by pr ogr am m ing t he rout ers w it h m anual rout ing inform at ion, com m only referred t o as st at ic r out es, or by using a dynam ic prot ocol t o aut om at e t he collect ion of rout ing inform at ion and int elligence. The applicat ions or pr ot ocols used in t he lat t er case ar e r efer r ed t o as dynam ic rout ing prot ocols. I n addit ion, a r out er can j ust use a default rout e for forwarding packet s heading t o nondirect ly connect ed subnet s. The nex t hop along t he default r out e is r efer r ed t o as t he default gat eway. Default rout es can be generat ed by eit her st at ic or dynam ic m et hods. Som e com m on dynam ic I P r out ing prot ocols in use t oday are t he Rout ing I nform at ion Prot ocol ( RI P) version 1 and version 2, I nt erior Gat eway Rout ing ( I GRP) , Enhanced I nt erior Gat eway Prot ocol ( EI GRP) , I nt egr at ed I nt er m ediat e Sy st em-t o-I nt erm ediat e Syst em Rout ing Prot ocol ( I S-I S) , Open Sh ort est Pat h Rout ing Prot ocol ( OSPF) , and t he Border Gat eway Prot ocol ( BGP) . The differ ent br eeds of r out ing pr ot ocols have differ ent capabilit ies r elat ed t o bot h ar chit ect ur al design and em bedded funct ionalit y. The follow ing sect ions differ ent iat e bet w een com m only used rout ing prot ocols. The m at erial covered focuses m ost ly on unicast rout ing pr ot ocols and dist inct ions ar e pr im ar ily pr ov ided for such pr ot ocols. The follow ing classificat ions ar e cover ed:

23

•

Classful versus classless prot ocols

•

I nt radom ain versus int erdom ain prot ocols

•

Dist ance -v ect or v er sus link-st at e prot ocols

Classful Versus Classless Protocols Dynam ic I P r out ing pr ot ocols can be cat egor ized int o classful and classless pr ot ocols, as show n in

Table 1 - 2 .

Table 1 - 2 . Cla ssful a nd Cla ssle ss Pr ot ocols

Cla ssfu l Rou t in g Pr ot ocols RI P version 1 I GRP

Cla ssle ss Rou t in g Pr ot ocol RI P version 2 EI GRP I nt egr at ed I S- I S OSPF BGP

Classful pr ot ocols obt ain r out ing infor m at ion t hr ough t he exchange of net w or k num ber s w it hout m ask infor m at ion and ar e designed t o deal w it h only classful I P addr esses. Whe n I P subnet w orks are exchanged, classful prot ocols arbit rarily apply know n m asks for m at ching classful ent ries t hat are locally configured. Therefore, such prot ocols are confused by t he not ion of a variable prefix lengt h em bodied in CI DR. How ever, classless pr ot ocols ex change m asking inform at ion in addit ion t o net work num bers when collect ing rout ing inform at ion, allow ing t hem t o w or k flex ibly w it h VLSMs or classless addr essing.

Table 1 - 3

sum m ar izes t he

differ ences bet w een classful and classless pr ot ocols.

Table 1 - 3 . At t r ibut e s of Cla ssful a nd Cla ssle ss Pr ot ocols

Cla ssfu l Rou t in g Pr ot ocols Do not support supernet s Do not carry subnet m asks in updat es Cannot handle VLSMs Do not support discont iguous subnet s Most ly periodic updat es Sim ple t o configure and t roubleshoot on Cisco rout ers

Cla ssle ss Rou t in g Pr ot ocols Support supernet s Advert ise rout es t oget her wit h subnet m ask s Support VLSMs Support discont iguous subnet s Most ly increm ent al updat es Sim ple t o com plex t o configure on Cisco rout ers, and com plex t o t roubleshoot

24

Intradomain Versus Interdomain Routing A net w ork of int erconnect ed rout ers and relat ed syst em s m anaged and m aint ained t oget her by a com m on adm inist r at ion is oft en r efer r ed t o as a net work dom ain. A net w or k dom ain is also som et im es called an aut onom ous syst em . The I nt ernet con sist s of sever al int er connect ed net w or k dom ains spanning t he w hole w or ld. Rout ing pr ot ocols ar e designed and opt im ized for use w it hin a dom ain ( int radom ain) or bet w een dom ains ( int erdom ain) .

Figure 1 - 7

show s t hr ee

net w ork dom ains ( AS1, AS2, and AS3) int erconnect ed int o a global rout ing syst em . Also depict ed in t he diagram are inst ances of int radom ain and int erdom ain rout ing. Figur e 1 - 7 . I n t r a dom a in a n d in t e r dom a in r ou t in g.

All t he r out ing pr ot ocols listed in t he pr eceding sect ion, w it h t he ex cept ion of BGP, ar e opt im ized for int radom ain funct ionalit y. I nt radom ain rout ing prot ocols t ypically do not offer flexibilit y for policy im plem ent at ion and also cannot deal w it h a lar ge num ber of r out es, such as in t he global I nt ernet rout ing t able. Obviously, m ore com plex policies w ill be required t o cont r ol t he ex change of r out ing infor m at ion bet w een t w o separ at e dom ains, and t his is cert ainly w hat BGP is opt im ized for. Because of t he v ast ness of t he global I nt er net, t he num ber of r out es t hat need t o be handled globally is lar ge. The size of t he global I nt er net r out ing t able is cur r ent ly in t he or der of 100,000.00 rout es and is slat ed t o grow furt her. Therefore, an int erdom ain rout ing prot ocol m ust provide t he follow ing basic capabilit ies:

•

Support configurat ion of com plex policies, such as rout e filt ering, t agging, and so on

•

Handle a lar ge num ber of r out es under bot h st able and unst able condit ions

•

Respond reasonably fast t o net work changes —t hat is, sending updat es, re ceiving and processing updat es, and select ing alt ernat ive rout es

An int er dom ain pr ot ocol also m ust handle m ult iple peer s, w it h each peer pr esent ing a differ ent v iew of t he sam e lar ge t ables. Cur r ent ly , only BGP can deliv er on all t hese r equir em ent s, and

25

it rem ains t he de fact o int erdom ain rout ing prot ocol on t he I nt ernet . The current version of BGP for unicast I P r out ing, ver sion 4, is specified by RFC 1771. BGP is st ill evolving and has had m any enhancem ent s in r ecent t im es, including t he addit ion of m ult iprot ocol capabilit ies in RFC 2858. RFC 2858 specifies m ult iprot ocol ext ensions t o BGP4, providing t he archit ect ural fram ew ork for m ult iprot ocol label-sw it ching virt ual privat e net w orks ( MPLS VPNs) , int erdom ain m ult icast rout ing, and support for I Pv6 int erd om ain r out ing.

Distance-Vector Versus Link-State Protocols This chapt er discusses t he classificat ion of r out ing pr ot ocols based on ar chit ect ur al design ( dist ance -v ect or and link-st at e prot ocols) . Essent ially, t his cat egorizat ion applies t o int radom ain prot ocols, also k now n as I nt erior Gat eway Prot ocols ( I GPs) . The only sur v iv ing int er dom ain pr ot ocol, BGP, w as discussed in t he pr eceding sect ion. BGP is nor m ally consider ed a pat h -v ect or pr ot ocol because a k ey at t r ibut e it ascr ibes t o r out es is a v ect or of path infor m at ion k now n as AS Pat h. An AS Pat h is a v ect or of aut onom ous sy st em s t hat a r out e has t r av er sed. Table 1 - 4

shows t he classificat ion of I GPs int o dist ance -v ect or and link-st at e pr ot ocols. I GPs ar e

easily placed int o t hese t wo cat egories. Dist ance -vect or pr ot ocols ar e sim pler in design and t end t o be classful. This classful at t ribut e disqualifies t hem from being viable opt ions for rout ing in m ost large m odern net works. Dist ance -vect or pr ot ocols use per iodic updat e m echanism s t hat consum e a lot of bandw idt h r esour ces. Link-st at e prot ocols send only incr em ent al updat es for any net w or k changes. I n gener al, link-st at e pr ot ocols r equir e a lot m or e pr ocessing and m em or y r esour ces t han dist ant -vect or pr ot ocols. They don't have som e of t he inher ent pr oblem s associat ed w it h dist ance -vect or prot ocols, however, such as periodic updat es, t r ansient loops, count t o infinit y, and slow conver gence issues. Lin k-st at e pr ot ocols ar e m or e pr ocessor-int ensive t han dist ance -vect or prot ocols. This is t rue because a change in t he t opology of an ar ea w ould nor m ally t r igger a com plet e SPF r un over t he ent ir e link-st at e dat abase, w her eas dist ance -vect or prot ocols perform t heir com put at ion on t he basis of individual r out es, r equir ing less com put at ion for m inor t opology changes. A cr it ical adv ant age of link-st at e pr ot ocols ov er distance -vect or prot ocols is t he capabilit y t o support hierarchical net w ork archit ect ures, giving t hem high pot ent ial t o scale. Dist ance vect or pr ot ocols w or k in only flat net w or k ar chit ect ur es and gener ally have lim it ed scaling capabilit ies.

Table 1 - 4 . D ist a n ce- V e ct or a n d Lin k- St a t e Prot ocols

Pr ot ocol Ca t e gor y RI P v1 Dist ance Vect or RI P v2 Dist ance Vect or

Met ric Hop count

Algor it h m Bellm an- Ford

Hop count

Bellm an- Ford

26

I GRP

OSPF

Dist ance Vect or Dist ance Vect or Link St at e

I S- I S

Link St at e

EI GRP

Com posit e

Bellm an- Ford

Composit e

Diffusing Updat e Algorit hm Short est Pat h First

Bandw idt h- based cost Manual cost

Short est Pat h First

I GRP a n d EI GRP I GRP and EI GRP are propriet ary prot ocols developed by Cisco Syst em s. As indicat ed by t he ir nam es, EI GRP is based on I GRP and feat ur es cr it ical enhancem ent s, such as suppor t for VLSM, classless r out ing. EI GRP uses a differ ent algor it hm for r out e com put at ion, as indicat ed in Table 1-4.

Anot her im provem ent over I GRP is increm ent al updat es and fast er convergence using t he

concept of feasible successor. EI GRP also feat ures m ult iprot ocol capabilit ies, support ing rout ing for I P, I nt ernet Packet Exchange Prot ocol ( I PX) , and AppleTalk, whereas I GRP is lim it ed t o only I P.

RI P v1 a nd RI P v2 RI P ver sion 1 and ver sion 2 have or igins in t he I ETF. Ver sion 2 int r oduces enhancem ent s, such as m ult icast updat es and advert isem ent of rout es, w it h m ask inform at ion t o support VLSMs and classless addr essing.

OSPF OSPF also or iginat ed fr om t he I ETF and is pr obably t he m ost popular and w ell-underst ood I GP because of it s originalit y as an I P prot ocol and ext ensive coverage in int ernet w orking lit er at ur e. OSPF has evolved over t im e int o a r obust pr ot ocol, acquir ing t he necessar y capabilit ies t o build com plex rout ing infrast ruct ures in bot h ent erprise and service provider envir onm ent s. Alt hough t he ent ir et y of t he OSPF pr ot ocol is com plex, it s basic concept s and capabilit ies ar e not difficult t o under st and and configur e on Cisco r out er s.

I n t e gr a t e d I S- I S This book is about t he I S-I S prot ocol and t he following chapt ers provide insight s int o t his prot ocol's innards and capabilit ies. I S-I S ( I SO 10589) w as or iginally specified by t he I nt ernat ional Telecom m unicat ions Union ( I TU) , form ally t he I nt ernat ional Organizat ion for St andar dizat ion ( I SO) , as a r out ing pr ot ocol for connect ionless net work layer prot ocol ( CLNP) . I S-I S w as fir st im plem ent ed for r out ing w it hin t he DECnet Phase V ar chit ect ur e at Digit al Equipm ent Cor por at ion ( DEC) . I t w as lat er adapt ed t o suppor t I P r out ing by t he I ETF in RFC 1195. Despit e t heir different funct io nal designs and origins, I S-I S and OSPF shar e a lot in com m on. Bot h ar e link-st at e prot ocols and use t he SPF algorit hm for rout e com put at ion.

27

Unicast Versus Multicast Routing I P r out ing is needed t o dir ect unit s of dat a k now n as packet s t hr ough a net w or k. I n a pack etbased net w or k, a lar ge file is br oken dow n int o packet s befor e it is t r ansm it t ed fr om one end of t he net w or k t o t he ot her . Rout ing is r equir ed in net w or k envir onm ent s w her e m ult iple segm ent s ar e pat ched t oget her over a lar ge ar ea. The segm ent s, w hich can pot ent ially be different t ransport m edia, are linked by rout ers. No rout ing is required w hen nodes are connect ed t o t he sam e net w or k segm ent , such as a LAN or a point -t o-point link. The follow ing t w o k inds of r out ing ar e dist inguishable by t heir differ ent appr oaches t o packet for w ar ding:

• •

Unicast rout ing Mult icast r out ing

I n unicast rout ing, packet s are forw arded t ow ard t he single -host addr esses in t heir dest inat ion fields. I n m ult icast rout ing, however, t he address in a packet 's dest inat ion field is a m ult icast gr oup addr ess. This allow s a single pack et t o be for w ar ded t o m ult iple r eceiv er s in t he m ult icast group, effect ively forw arding t he sam e dat a once t o m ult iple host s. The discussion so far in t his chapt er is biased t oward unicast prot ocols because t he obj ect ive is t o provide background m at erial for I S-I S, w hich is a unicast rout ing prot ocol. I P unicast forw arding is designed on a dest inat ion -based "forward -t o-nex t - hop" paradigm . This m eans t hat each r out er in t he pat h looks at t he dest inat ion in a pack et and for w ar ds it t o t he nex t hop along t he best know n pat h t he dest inat ion. Except in t he case of special policy-based for w ar ding schem es, t he sour ce addr ess of a packet is ir r elevant in for w ar ding and exist s for t he t w o -w ay handshak e bet w een t he origin and dest inat ion com m unicat ion w here necessary. I n cont rast , m ult icast forw arding inherent ly depends on bot h t he source and dest inat ion addr esses. A m et hod k now n as reverse pat h forwarding ( RPF) is used t o check t he m ult icast r out ing t able, for t he best pat h t o t he sour ce addr ess of a pack et t hr ough t he int er face on w hich t he pack et w as r eceiv ed, befor e t he pack et is accept ed. The dest inat ion addr ess in t he m ult icast pack et is a m ult icast gr oup addr ess. Each m ult icast gr oup has an associat ed out go ing int erface list ( OI F) t hat det erm ines t he locat ion of receivers t hat have j oined t he gr oup. Aft er t he RPF check is done on t he sour ce, copies of t he packet ar e for w ar ded t o t he int er faces in t he OI F list associat ed w it h t he gr oup addr ess in t he packet . Ex am ples of m ult icast prot ocols are Dist ance -Vect or Rout ing Pr ot ocol ( DVMRP) , Pr ot ocol-I ndependent Mult icast ing ( PI M) , Mult icast OSPF ( MOSPF) , and Mult icast Source Discovery Prot ocol. Mult icast r out ing is not fur t her discussed in t his sect ion; for m or e infor m at ion on m ult icast r out ing, r ead Developing I P Mult icast Net works , Volum e I ( Cisco Press, 2000. I SBN: 1 -5 7 8 7 0 0 7 7 -9) . A recent ly int roduced Cisco I OS securit y feat ure know n as Unicast Reverse Pat h For w ar ding ( Unicast RPF) uses t he concept of r ever se path checking for cont rolling unicast for w ar ding in a m anner t hat successfully addr esses I nt er net Denial of Ser vice ( DoS) at t acks based on sour ce addr ess spoofing.

Unicast Routing As m ent ioned pr ev iously , t he essence of I P unicast r out ing is t o help r out er s figur e out t he nex t hop t o pass on pack et s, along t he best pat h t o a t ar get dest inat ion. Choice of t he best

28

pat h is det er m ined by choosing t he pat h w it h t he low est cost . This best pat h det er m inat ion boils dow n t o det erm inat ion of t he dat a -link or MAC addres s of t he nex t hop. Each non -dir ect ly connect ed ent r y in t he r out ing t able consist s of a pr efix , t he I P addr ess of t he nex t hop, and t he out going int er face t o t he nex t hop. Act ual forwarding m ay involve ext ra st eps t o det erm ine t he corresponding dat a -link a ddr ess of t he next hop fr om t he ARP t able or an equivalent addr ess m ap t able for t he specific m edia. I f t he dest inat ion is direct ly connect ed, t he address resolut ion ret rieves t he dat a -link addr ess of t he dest inat ion; ot herwise, t he dat a -link addr ess of t he r out er at t he nex t hop is obt ained. Dur ing for w ar ding, t he or iginal dest inat ion I P addr ess of t he packet does not change, but t he dat a -link addr ess keeps changing as t he packet t r aver ses differ ent links unt il it ar r ives at it s dest inat ion. The dat a -link infor m at ion t hat a r out er appends t o a pack et befor e sending it off t o t he nex t hop is r efer r ed t o as t he Layer 2 rew rit e st ring ( or as j ust t he MAC rewrit e in t h e case of LANs) .

IP Unicast Forwarding Example Figure 1 - 8

show s a sim ple I P net w or k t hat consist s of t hr ee net w or k segm ent s. Each segm ent is

assigned a unique I P subnet . To get t o dest inat ions on t he segm ent or sam e subnet , t he ARP pr ot ocol is used t o r esolve t he dat a -link addr ess associat ed w it h t he dest inat ion I P addr ess. To get t o a r em ot e segm ent , how ev er , r out ing is r equir ed. I f Host 1 needs t o for w ar d dat a t o Host 2, for exam ple, it r elies on ARP t o obt ain t he cor r esponding MAC addr ess of Host 2. I f Host 1 needs t o send dat a t o Host 3, w hich is on anot her segm ent , how ev er , it for w ar ds t he dat a fir st t o RT1, w hich t hen for w ar ds t he dat a on t o RT2, w hich finally delivers t he packet s t o Host 3 . Figur e 1 - 8 . I llust r a t ion of I P for w a r ding.

I n sum m ar y, r out ing w or ks by finding t he cor r esponding Layer 2 r ew r it e of t he next hop t o t he dest inat ion address in t he packet . The I P packet is t hen encapsulat ed in a dat a -link fram e w it h t he Layer 2 rew rit e and forw arded on t o t he next hop. The next hop can be t he ult im at e

29

dest inat ion of t he pack et or a r out er on the pat h t oward t he dest inat ion.

Figure 1 - 9

show s a

flow ch ar t of I P pack et-forw arding process. Figur e 1 - 9 . I P pa ck e t- r out ing pr oce ss.

Det er m inat ion of t he Lay er 2 r ew r it e st r ing is one of t he m ost im port ant st eps in packet forwarding. Ot her act ivit ies relat ed t o forwarding include validat ion of t he I P header checksum and reduct ion of t he I P TTL value. I P packet processing also m ight involve policy enforcem ent , such as packet filt ering, t raffic rat e lim it ing, congest ion cont r ol, lat ency cont r ol t hr ough

30

various qualit y-o f-ser v ice queuing schem es, and set t ing of t he t y pe of ser v ice bit s in t he I P header. All of t his addit ional packet processing t akes t im e and processing resources, requiring t he assist ance of v ar ious pack et-sw it ching opt im izat ion schem es in high-speed r out er s t o achieve line -r at e for w ar ding at 10 gigabit s per second and bey ond. Cisco r out er s hav e ev olv ed t hr ough v ar ious pack et-sw it ching m echanism s: Process, Fast , and Cisco Express Forw arding. These sw it ching m et hods ar e br iefly cover ed in t he sect ion " Cisco Packet - Switching Mechanism s ."

Longest Match Routing I n m any cases, befor e a r out er select s t he best pat h t o a dest inat ion, it m ight r un int o sever al sim ilar r out es t hat differ only in t heir pr efix lengt h. Recall fr om t he pr evious discussion t hat in t oday 's w or ld of classless r out ing, r out es ar e no longer differ ent iat ed by t heir classes but by t heir pr efix lengt h, as det er m ined by t he subnet m ask s. For ex am ple, t he addr ess 192.168.1.1 can m at ch bot h 192.168.0.0/ 16 and 192.168.1.0/ 24 if t hey are bot h in t he rout ing t able. However, one im port ant rule for m at ching rout es, longest m at ch rout ing, dict at es t hat t he m at ching r out e w it h t he longest pr efix lengt h, 192.168.1.0/ 24, should be pr efer r ed over t he less -specific ent ry, 192.168.0.0/ 16. This m akes sense because t he less-specific r out e is nor m ally a sum m ar y r out e t hat m ight hav e lost specific det ails during aggregat ion. Therefore, t he m or e specific ent r y m ust be pr efer r ed. This basic look up r ule is cr it ical for a r out er t o suppor t VLSMs.

Cisco Packet-Switching Mechanisms At t he beginning of t his chapt er , t he dist inct ion bet w een I P for w ar ding and I P r out in g is discussed, and t he separ at ion bet w een t he for w ar ding plane and t he cont r ol plane in m oder n rout ers is m ent ioned. As not ed, t he cont rol plane is associat ed w it h t he rout e processor, w hich r uns t he r out ing pr ot ocols. As illust r at ed in Figure 1 - 9 , act ual forwarding of packet s is perform ed by dedicat ed hardware -based for w ar ding engines, w hich ar e m ainly im plem ent ed in applicat ion -specific int egrat ed circuit s ( ASI Cs). ASI C-based for w ar ding engines ar e necessar y t o achiev e high for w ar ding r at es. CPU-based forwarding is relat ively slow; however, over t he year s, Cisco has developed var ious m et hods for speeding up t he lookup pr ocess on CPU-based rout er processors. Fast sw it ching is one such m echanism . Fast sw it ching lat er ev olv ed int o Cisco Ex pr ess For w ar ding ( CEF) . The pr edecessor of bot h fast sw it ching and CEF sw it ching is r efer r ed t o as process swit ching.

Process Switching Pr ocess sw it ching r efer s t o sw it ching packet s b y queuing t hem t o t he CPU on t he r out e pr ocessor at t he pr ocess lev el. I n t his case, ev er y pack et-sw it ching request is queued alongside ot her applicat ions and ser viced, in t ur n, by t he CPU on t he r out e pr ocessor . The CPU per for m s r out e lookup for ever y packet t o det er m ine t he Layer 2 r ew r it e st r ing befor e t he pack et is sw it ched t o t he nex t hop or dest inat ion. Obv iously , pr ocess sw it ching is slow and can b e CPU-int ensive. Process sw it ching is illust rat ed in Figure 1 - 1 0 .

31

Figur e 1 - 1 0 . I llust r a t ion of pr oce ss sw it ching.

Fast Switching Fast sw it ching is an enhancem ent of pr ocess sw it ching in w hich any pack et-swit ching request is first perform ed at t he process level, and t he Layer 2 rew rit e inform at ion obt ained is cached for r euse. When fast sw it ching is enabled, t he CPU r eceiv es an int er r upt for any for w ar ding r equest t o check t he I P cache for a m at ching ent r y t o t he dest inat ion. I f an ent r y is found, t he Lay er 2 r ew r it e is r et r iev ed and t he pack et is sw it ched im m ediat ely. I f no ent ry exist s, t he pack et is queued for pr ocess sw it ching. Aft er it is pr ocess sw it ched, t he Lay er 2 r ew r it e is t hen cached for r euse. Not e t hat t he fast -sw it ching cache is built by pr ocess sw it ching t he fir st packet t o any dest inat ion.

Figure 1 - 11

show s t he fast -sw it ching pr ocess.

Figu r e 1 - 1 1 . I llust r a t ion of fa st sw it ching.

Cisco Express Forwarding CEF t akes fast sw it ching a st ep fur t her by abandoning t he lat t er 's dem and -based m ech anism s and dependence on pr ocess sw it ching t o build t he fast -sw it ching cache ( see Figure 1 - 12 ). I nst ead, CEF pr edet er m ines all t he Layer 2 r ew r it e infor m at ion, w her e possible, for all know n ent r ies in t he r out ing t able. This allow s CEF t o sw it ch at int er r upt cont ext for even t he fir st pack et t o any dest inat ion. An except ion exist s for dest inat ions on connect ed m ult ipoint m edia such as LANs, w her e an ARP pr ocess is r equir ed for t he fir st packet t o any connect ed host , t o obt ain Lay er 2 r ew r it e infor m at ion for t he dest inat ion. CEF also opt im izes st or age by using t w o

32

dat abases: one for pr efixes, called t he forwarding inform at ion base ( FI B) ; and t he ot her for Layer 2 rew rit e inform at ion, called t he adj acency dat abase. Figur e 1 - 1 2 . I llust r a t ion of CEF sw it ching.

Cur r ent ly, m ost Cisco r out er s have only one act ive r out e pr ocessor if even m or e t han one ar e inst alled; t her efor e, w her e pr ocess sw it ching is allow ed, it is done at only a cent r al locat ion. I n rout ers w it h dist ribut ed archit ect ure, such as t he Cisco 7500 Series, how ever, t he fast sw it ching cache and t he CEF t ables can be dist r ibut ed t o int elligent int er face pr ocessor s know n as versat ile int erface processors (VI P) t o enable concur r ent dist r ibut ed for w ar ding at m any locat ions in t he rout er. The Cisco 12000 Series rout ers have a fully dist ribut ed archit ect ure and also suppor t only dist r ibut ed CEF sw it ching t o achieve high for w ar ding r at es. For m or e infor m at ion on packet sw it ching on Cisco r out er s, r ead I nside Cisco I OS Soft ware Archit ect ure ( Cisco Press. 2000. I SBN: 1 -5 7 8 7 0 -1 8 1 -3) and Large-Scale I P Net work Solut ions ( Cisco Pr ess. 2000. I SBN: 1 -5 7 8 7 0 -084-1) .

Comments on IPv6 Deplet ion of t he I Pv 4 addr ess space has been st eep w it h t he t r em endous gr ow t h of t he I nt ernet . Efficient and innovat ive schem es for cont rolling address usage, such as CI DR, Net w ork Address Translat ion ( NAT) , and Dynam ic Host Configurat ion Prot ocol ( DHCP) , have helped cont ain t he problem . A lim it at ion of I Pv4 is challenges w it h renum bering, especially in cases w her e a m edium-size net w or k changes ser v ice pr ov ider s. I Pv 4 addr esses ar e assigned t o ser vice pr ovider s and por t abilit y is an issue. The inabilit y of m any sit es t o r enum ber as t hey m igrat e t heir net w orks t o new service providers has le d t o sev er e fr agm ent at ion of t he I Pv 4 addr ess space, ex acer bat ing t he alr eady high gr ow t h r at e of t he global I nt er net r out ing t able. The gr ow t h of t he I nt er net r out ing t able and t he incr easing num ber of pr efixes car r ied w it hin service provider net works pla ce undue dem and for m em ory and rout e com put at ion resources on I nt er net r out er s. These issues and m any ot her lim it at ions of I Pv4 led t o sever al enhancem ent pr oposals. These pr oposals w er e event ually consolidat ed int o t he I ETF st andar d I Pv 6. I n t ack ling one of t he cr it ical lim it at ions of I Pv 4 ( size of t he addr ess space) , I Pv 6 proposes a larger 128 -bit addr ess size, com par ed t o t he 32-bit size of I Pv 4 addr esses. Pr esum ably , t he four-t im es lar ger addr ess should be lar ge enough t o suppor t pr edict ed fut ur e gr ow t h of t he I nt ernet . I t m ight be int erest ing t o not e t hat I Pv6 does not com plet ely overhaul t he I Pv4 ar chit ect ur e but r at her im pr oves it in t he follow ing key ar eas:

33

•

Lar ger addr ess space w it h flex ible r enum ber ing capabilit y

•

Sim plified header for m at w it h im pr oved ex t ensions and opt ions

• •

Flow labeling for im proved qualit y-o f-service handling I m proved securit y capabilit ies for aut hent icat ion and dat a -int egrit y verificat ion

I P m obile net w or king is one of t he key dr iver s behind I Pv6. I t is envisaged t hat r apid evolut ion of m obile com m unicat ions and r elat ed applicat ions w ill r esult in num er ous per sonal com m unicat ion dev ices, such as cellular phones and per sonal digit al assist ant s connect ing t o t he I nt er net . This, in t ur n, should dr ive t he need for m or e I P addr esses, different iat ed ser v ices, and secur ed dat a t r ansm ission. An incr easing num ber of dat a com m unicat ions equipm ent vendor s ar e deliver ing bot h r out er and host im plem ent at ions of I Pv6 at t he sam e t im e as t he int ernat ional I Pv6 t est bed ( 6bone) expands t o em br ace m o r e sit es w or ldw ide. The t hree im port ant prot ocols used on t he I nt ernet ( BGP, I S-I S, and OSPF) , as w ell as RI P, ar e being enhanced t o suppor t I Pv 6.

IPv6 Addressing I Pv 6 r et ains t he I Pv 4 not ions of unicast and m ult icast addr essing but r em ov es t he concept of br oadcast addr essing w hile int r oducing anot her t y pe of addr ess, r efer r ed t o as any cast . Th e funct ions of br oadcast addr esses hav e been folded int o t hose of m ult icast addr esses. An anycast addr ess r epr esent s a gr oup of addr esses, w her e dat a t o t he gr oup is deliv er ed t o only one of t he addr esses in t he gr oup. Any cast addr esses cannot be used as dat a sour ces and should be assigned only t o r out er s. I Pv 6 em ploy s a const r ained hier ar chy in assigning addr esses t o pr om ot e efficient aggr egat ion. Concept s such as t op -level aggregat or ( TLA) , next -level aggregat or ( NLA) , and sit e -lev el aggr egat or ( SLA) have been adopt ed in t he addr essing m odel. The gener al for m at of I Pv6 addr esses is show n in Figure 1 - 1 3 . The 48 left m ost bit s r epr esent a public r out ing t opology ( PRT) pr efix . A sit e obt ains a PRT fr om it s I nt er net ser v ice pr ov ider and uses it as it s base pr efix t o aut oconfigure host s. Renum bering also involves j ust changing t he sit e's PRT using a new ly int roduced Rout er Renum bering ( RR) prot ocol.

34

Figur e 1 - 1 3 . I Pv6 a ddr e ss for m a t .

To support I Pv6, I P prot ocols originally designed for I Pv4 need form at changes t o m odify all occur r ences of t he 32-bit I Pv4 addressing t o 128-bit I Pv6 fields. I n part icular, t he I S-I S p rot ocol lends it self t o carrying addit ional inform at ion because of t he flexibilit y in it s packet for m at s and ar chit ect ur al design. Repr esent at ion of I Pv6 addr esses is done in hexadecim al because of t he addr ess size. Thr ee m et hods of r epr esent at ion ar e pr op osed. The first is preferred for norm al represent at ion, anot her allow s for com pr ession of an addr ess w hen it consist s of a cont inuous st r ing of 0s, and t he last enables concat enat ion of I Pv 6 and I Pv 4 addr esses in a m ix ed for m at . This schem e suggest s gr ouping t he bit s,16 in a gr oup w it h a colon separ at ing t hem . Each 16-bit ( 2 -byt e) gr oup is r epr esent ed in hexadecim al, as follow s:

FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 Because of t he lengt h of I Pv6 addr esses and t heir encoding in hexadecim al, hum ans have a g reat er level of difficult y w hen handling I pv6 as com pared t o t he dot t ed-decim al represent at ion of I Pv4. Nam e -t o-address resolut ion w ill be key for operat or int erface r equir em ent s. Consequent ly, w or k is alr eady in place for ext ensions t o t he I Pv4 DNS t o sup port I Pv6. I n an analogy t o t he I Pv4 DNS A record, t he new resource record defined for I Pv6 is sym bolically AAAA ( code 28) .

Summary This br oad chapt er on I P r out ing concept s pr ovides r eader s w it h an over view of I P r out ing pr ot ocols and an under st anding of t he underlying m echanism s involved in rout ing packet s gener ally in any I P net w or k and specifically on Cisco r out er s. Addr essing is a key aspect of r out ing, and I P addr essing bear s sim ilar im por t ance in I P r out ing. Subnet t ing and classless not ions in I P addr essing ar e int ended t o pr ov ide efficient allocat ion schem es, w hich effect ively r esult in efficient use of assigned addr esses fr om t he public I P addr ess space, as w ell as conser vat ion of net w or k r esour ces in m aint aining I P r out ing inform at ion on rout ers. Classless addressing provides t he fram ework for prefix-lengt h -based I P addr essing schem es, such as CI DR and VLSM. Var ious t y pes of I P r out ing pr ot ocols ex ist , differing in prot ocol design as w ell as funct ional capabilit ies. I n general, rout ing prot ocols can

35

be classified int o various cat egories, as follows: unicast versus m ult icast , classful versus classless, int radom ain versus int erdom ain, and dist ance -v ect or v er sus link-st at e pr ot ocols. These classificat ions provide insight s int o t he capabilit ies of w ell-know n rout ing prot ocols, em phasizing st r engt hs and w eak nesses t hat should be consider ed w hen select ing t he appr opr iat e r out ing pr ot ocol for a net w or k design pr oj ect . The subt le dist inct ion bet w een I P rout ing and I P forw arding is im port ant for underst anding t he ar chit ect ur e of m oder n r out er s. I P r out ing ext ends t he not ion of I P for w ar ding t o include t he pr ocess of gat her ing r out ing int elligence in a net w or k. The concept of next -hop rout ing, using t he dest inat ion addr ess in packet s, is t he basic for w ar ding paradigm of I P, even t hough m odern rout ers can use policy-based m echanism s as w ell, based on t he sour ce addr ess for forw arding. The follow ing t hree basic I P forw arding m et hods are support ed in Cisco I OS Soft w ar e: pr ocess sw it ching, fast sw it ching, and CEF. Process sw it ching is CPU-based for w ar ding, and it is m uch slow er t han t he ot her sw it ching m et hods. Fast sw it ching uses a dem and-based for w ar ding cache t o speed up t he sw it ching pr ocess, w her eas CEF opt im izes furt her by precom put ing t he inform at ion used for sw it ching pack et s ov er t he w hole of t he r out ing t able. I P net w or king is st ill evolving w it h I Pv6 being a fair ly r ecent int r oduct ion t hat is not yet w idely accept ed. I Pv 6 pr ov ides enhancem ent s t o t he I Pv 4 ar chit ect ur e by addr essing som e of t he lim it at ions of t he lat t er , such as t he size of t he I Pv 4 addr ess space and pr oblem s w it h r enum ber ing net w or k s. I Pv 6 addr esses ar e 128 bit s long com par ed t o t he 32 bit s of I Pv 4 and should pr ov ide a lar ge enough addr ess space for fur t her gr ow t h of t he global I nt er net .

Review Questions Com plet e t he follow ing review quest ions t o t est your underst anding of t he concept s covered in t his chapt er . The answ er s ar e list ed in Appendix B , " Answers t o Review Quest ions."

1:

Nam e t he t wo planes of operat ion in a m odern rout er.

2:

I P forwarding and I P rout ing are relat ed concept s. What is t he difference bet ween t hem ?

3:

Nam e com m on classificat ions of I P rout ing prot ocols.

4:

Nam e t he t hree swit ching m echanism s support ed in Cisco I OS Soft ware.

5:

What is t he crit ical short com ing of t he I Pv4 archit ect ure t hat I Pv6 t ries t o address and how it is addressed?

References Bennet t , Geoff.. Designing TCP/ I P I nt ernet works . John Wiley & Sons, 1997. I SBN 0 -4 7 1 2 8 6 4 3 -5 .

36

Bollapragada, V., Murphy, C., Whit e, R. I nside Cisco I OS Soft ware Archit ect ure. Cisco Pr ess, 2000. I SBN 1 -57870-181 -3 . Christ ian Huit em a. I Pv6, The New I nt ernet Prot ocol. Prent ice Hall, 1996. I SBN 0 -1 3 -241936 -X. Christ ian Huit em a. Rout ing in t he I nt ernet . 2nd Edit ion Prent ice Hall, 2000. I SBN 0 -1 3 0 2 2 647-5 . Default _XREF_st yleREF

http: / / www.cisco.com / warp/ custom er/ 701/ 3.htm l .

" Underst anding I P Addresses"

Halabi, Bassam . I nt ernet Rout ing Archit ect ures . Cisco Pr ess, 2000. I SBN 157870233x. Hopps, Chr ist ian E. " Rout ing I Pv6 wit h I S-I S." I ETF DRAFT 2001.

ht t p: / / search.iet f.org/ int ernet-

drafts/ draft - iet f- isis- ipv6 -02.txt .

http: / / www.cisco.com / warp/ public/ 103/ index.shtm l

ht t p: / / www.6bone.net /

I ETF RFC 1700, "Assigned Num bers." Raynold, J, Post el, Jon.. 1994. I ETF 1992, RFC 1519, " Classless I nt er-Dom ain Rout ing ( CI DR) : An Address Assignm ent and Aggregat ion St rat egy." Fuller , V., Li, T., Yu, J., Var adhan, K. ht t p: / / www.iet f.org/ rfc/ rfc1519.t xt ?num ber=1 5 1 9

I ETF RFC 2328, " OSPF version 2," Moy , J. 1998. I EFT RFC 1800, "I nt ernet Official Prot ocol St andards," Post el, Jon. 1995. I ETF 1996 RFC 1918, " Address Allocat ion for Privat e I nt ernet s," Rekht er, Y., Moskowit z, B., Karrenberg, D. de Groot , D. J. Lear, E. I ETF 1999 RFC 2545P, "Use of BGP-4 Mult iprot ocol Ext ensions for I Pv6 I nt er-Dom ain," Marques, P., Dupont , F. I SO 10589, " I nt erm ediat e Syst em t o I nt erm ediat e Syst em I nt ra-Dom ain Rout ing I nform at ion Exchange Prot ocol for Use in Conj unct ion wit h t he Prot ocol for Providing t he Connect ionlessm ode Net work Service" ( I SO 8473) . I ETF 1990 RFC 1195, "Use of OSI I S-I S for Rout ing in TCP/ I P and Dual Environm ent s," Callon, R. I ETF RFC 2545, "Use of BGP-4 Mult iprot ocol Ext ensions for I Pv6 I nt er-Dom ain Rout ing," Marques, P., Dupont , F. I ETF RFC 2740, "OSPF for I Pv6," Colt un, R., Fer guson, D., Moy, J.

37

I ETF RFC 2080, "RI Png for I Pv6," Malkin, G., Minnear, R. Khalid Raza, Mike T. Lar ge Scale I P Net w or k Solut ions. Cisco Press. 2000. I SBN 1 -5 7 8 7 0 -0841. Miller, Phillip. TCP/ I P Explained . Digit al Press. 1997. I SBN 1 -55558 -1 6 6 -8 . Naugle, Mat hew . Net work Prot ocol Handbook. McGraw Hill. 1994. I SBN 0 -0 7 -0 4 6 4 6 1 -8 . RFC 1771, " Border Gat eway Prot ocol Version 4 ( BGP 4) ," Li, Rek ht er , 1995. RFC 2858, " Mult i-Prot ocol Ext ensions for BGP4 ," Bat es, T., Chandra, R., Rekht er, Y., Kat z, D. 2000. RFC 1058, " Rout ing I nform at ion Prot ocol, STD 34," Hedr ick , C. 1988. RFC 1723, " RI P v2 carrying Addit ional I nform at ion," Malk in, G. 1994. RFC 2373, " I P Version 6 Addressing Archit ect ure," Deering, S., Hinden, R. July 1998. RFC 2546, " 6Bone Rout ing Pract ice," Durand, A., Buclin, B. William son, Beau. Developing I P Mult icast Net works . Cisco Press, 2000. I SBN 1 -57870 -0 7 7 -9 .

38

Chapter 2. Introduction to the IS-IS Routing Protocol To underst and t he in nards and underlying operat ional principles of t he I nt erm ediat e Syst emt o-I nt erm ediat e Syst em ( I S-I S) r out ing pr ot ocol, it is im por t ant t o place it in per spect ive w it hin t he overall schem e of int ernet w orking prot ocols and relat ed t echnologies. This chapt er provides insight int o t he root s of t he I S-I S pr ot ocol and discusses t he connect ionless net w orking environm ent t hat it w as envisioned t o support by t he I nt ernat ional Organizat ion for St andardizat ion ( I SO) . The chapt er begins w it h an int r oduct ion t o t he Open Syst em I nt erconnect ion ( OSI ) reference m odel and t hen br iefly discusses t he t w o t ypes of dat a com m unicat ions ser vices specified by I SO w it hin t he fram ew ork of t he OSI reference m odel: Connect ion Net work Service ( CONS) and Connect ionless Net work Service ( CLNS) . I S-I S w as designed as par t of t he CLNS envir onm ent t o pr ovide t he necessar y int elligence for aut om at ic and dynam ic r out ing of dat a packet s in I SO CLNS net w orking environm ent s. From it s incept ion, t he I S-I S pr ot ocol has been adapt ed for I P rout ing an d ot her capabilit ies, such as t r affic engineer ing w it h Mult ipr ot ocol Label Swit ching ( MPLS) .

ISO Connectionless Network Service Th e I nt ernat ional Organizat ion for St andardizat ion ( I SO) , cur r ent ly k now n as t he I nt ernat ional Telecom m unicat ions Union ( I TU) , laid t he foundat ion for st andardizat ion of com put er net w or king by defining t he seven-layer OSI reference m odel ( see Figure 2 - 1 ) . The OSI r efer ence m odel, also know n as t he OSI st ack, is specified in I SO 7498. ( The I SO st andar ds docum ent s cit ed in t his chapt er can be found at

www.itu.org/ .)

Figur e 2 - 1 . Th e OSI r e fe r e n ce m ode l.

39

The OSI reference m odel is a significant cont ribut ion t o t he foundat ions and subsequent evolut ion of dat a com m unicat ions and inform at ion t echnology. I t provides t he archit ect ural fram ew ork for developing open st andards t hat allow flexible int erconnect ivit y and int eroperabilit y bet ween com m unicat ions devices from different m anufact urers. Alt hough t he OSI reference m odel does not specify t he int ernal det ails of any com m unicat ions prot ocol or syst em , it pr ovides gener al guidance r egar ding design and ar chit ect ur e of such syst em s. Each of t he seven layer s in t he OSI r efer ence m odel defines a single service capabilit y and provides a prem ise for grouping relat ed funct ional elem ent s int o funct ional layers, t hus sim plifying and facilit at ing prot ocol design. Each funct ional layer defines specific services provided t o t he adj acent higher layer . For exam ple, t he net w or k layer pr ovides ser vices for t he t r anspor t layer ( see

Figure 2 - 1 ) ,

w hereas t he t ransport layer provides dat a t ransport services t o t he higher

layers, t hus helping t ransport user dat a bet ween com m unicat ing devices. Furt herm ore, dat a t r anspor t ser v ices can be eit her connect ion-orient ed or connect ionless. Connect ion-orient ed ser vices r equir e pr ior set up of a connect ion along a specific pat h bet w een com m unicat ing nodes befor e dat a can be t r ansm it t ed bet w een t hem , w her eas connect ionless ser vices do not . Or iginally, only connect ion -or ient ed com m unicat ion ser v ices ( CONS) w er e specified by t he net w or k ser v ice definit ion com ponent in t he OSI r efer ence m odel. CONS w as defined by t w o specificat ions: X.25 Pack et-Level Prot ocol for Dat a Term inal Equipm ent ( I SO 8208) and Net w or k Ser vice Definit ion ( I SO 8348) . Lat er am endm ent s t o t he net w or k ser vices specificat ion, w hich appear ed in " Net w or k Ser vice Definit ion, Am endm ent 1," defined t he capabilit ies for enabling connect ionless com m unicat ion bet w een net w ork devices, referred t o as Connect ionless Net work Services ( CLNS) . Unlike CONS, CLNS does not r equir e a pr edefined and pr eset up of t he end-to-end pat h for for w ar ding dat a packet s bet w een t w o com m unicat ing devices. I nst ead, it pr ovides a dat agr am ser vice in w hich each dat a pack et is for w arded independent ly by r out er s along t he cur r ent ly know n best pat h bet w een t he source and dest inat ion. The connect ionless dat agram service defined by CLNS is suppor t ed by t he follow ing I SO pr ot ocols ( see Figure 2 - 2 ): Figur e 2 - 2 . D ia gr a m of I SO pr ot ocols a nd spe cifica t ions.

40

•

I SO 8 4 7 3 — Connect ionless Net w ork Prot ocol ( CLNP) for providing t he CLNS

•

I SO 9 5 4 2 — End Sy st em-t o-I nt erm ediat e Syst em ( ES-I S) r out ing exchange pr ot ocol for use in conj unct ion w it h t he prot ocol for providing t he CLNS

•

I SO 1 0 5 8 9 — I nt er m ediat e Syst em-t o-I nt erm ediat e Syst em ( I S-I S) int r adom ain r out ing exchange pr ot ocol for use in conj unct ion w it h t he pr ot ocol for pr oviding t he connect ionless -m ode service

CLNP, ES-I S, and I S-I S are spe cified as separ at e net w or k layer pr ot ocols, coexist ing at Layer 3 of t he OSI r efer ence m odel. They ar e differ ent iat ed by t he value of t he I nit ial Pr ot ocol I dent ifier ( I PI ) field in t he fir st oct et of t heir encoded pr ot ocol for m at s, as follow s:

CLNP: ES- I S: I S- I S:

10000001 ( 0x81) 10000010 ( 0x82) 10000011 ( 0x83)

CLNP The Connect ionless Net w ork Prot ocol is sim ilar t o t he I nt ernet Prot ocol ( I P) , but specified for providing net w ork services for I SO t ransport prot ocols rat her t han t he t ransport prot ocols in t he TCP/ I P suit e. Like I P, CLNP is defined t o rely m inim ally on t he underlying dat a link layer, which m akes it virt ually independent of t he underlying physical m edium . The physical m edium can be eit her point -to-point ( as is t he case w it h m ost w ide-ar ea net work [ WAN] connect ivit y) or br oadcast ( as in local-ar ea net w or k [ LAN] connect iv it y ) . Unlik e I P, how ev er , w hich is t he only net w ork layer prot ocol of TCP/ I P and ult im at ely encapsulat es all higher layer prot ocols, including r out ing and user applicat ions, CLNP coexist s at t he net w ork layer, ES-I S an d ES-I S, all of w hich ar e defined t o suppor t t he I SO CLNS env ir onm ent . That is, CLNP, ES-I S, and I S-I S are all net w ork layer prot ocols and are encapsulat ed independent ly in dat a -link fram es. The I SO net w ork laye r prot ocol fam ily is ident ified at t he dat a -link lay er by pr ot ocol t y pe 0x FEFE.

41

This book does not delv e int o CLNP fur t her , ex cept t o t he ex t ent t hat it per t ains t o t he subj ect m at t er at hand: t he I S-I S r out ing pr ot ocol.

ES-IS The End Sy st em-t o-I nt er m ediate Syst em ( ES-I S) r out ing ex change pr ot ocol aut om at es inform at ion exchange and facilit at es adj acency discovery bet w een I SO end syst em s and r out er s connect ed t o t he sam e net w or k segm ent or link. The r out er s t r ansm it int er m ediat e syst em hello ( I SH) m essages and t he host s t r ansm it end syst em hello ( ESH) m essages as par t of t h e ES-I S pr ot ocol. The hellos, w hich ar e t r ansm it t ed bet w een dir ect ly connect ed nodes, convey net work and dat a -link addr esses of t he com m unicat ing nodes. The hellos ar e also r efer r ed t o as configurat ion inform at ion. The end syst em s forw ard packet s t o nonconnect ed dev ices t hr ough t he r out er s. Anot her t y pe of pack et used w it hin t he ES-I S pr ot ocol is called rout e redirect ion ( RD) . A r ou t e r edir ect ion pack et is sent by a r out er t o an end sy st em t o infor m it of a bet t er pat h t o r each a specific dest inat ion of int er est . The funct ion of I SO RDs is sim ilar t o t hose of I nt er net Cont r ol Message Pr ot ocol ( I CMP) r edir ect s used in I P envir onm ent s. Basically, t he oper at ion of t he ESI S prot ocol bet ween rout er s and end sy st em s in t he I SO env ir onm ent can be r elat ed t o t he com bined oper at ion of t he I CMP, Addr ess Resolut ion Pr ot ocol ( ARP) , and Dynam ic Host Configurat ion Prot ocol ( DHCP) wit hin t he I P fram ework. ES-I S is not relevant t o I P workst at ions and servers t hat ar e inv olv ed in pr ocessing and t ransfer of only I P dat agram s. For such I P devices, I P ARP provides t he necessary net w ork-t odat a -link address resolut ion t hat m ight be needed t o locat e rout ers and ot her direct ly connect ed host s. I P host s also usually use st at ic default rout es for t heir default gat ew ay, even t hough it is not uncom m on for som e advanced ser ver s t o suppor t sim ple I P r out ing pr ot ocols, such as t he Rout ing I nfor m at ion Pr ot ocol ( RI P) . Som e m oder n I P ser v er s ev en suppor t t he m ore sophist icat ed Open Shor t est Pat h Fir st ( OSPF) Pr ot ocol for I P r out ing. Som e aspect s of t he oper at ion of t he I S-I S prot ocol are dependent on funct ions provided by t h e ES-I S pr ot ocol; t her efor e, even in sit uat ions w her e I S-I S is used for r out ing only I P on Cisco r out er s, t h e ES-I S prot ocol is needed t o provide background support . For exam ple, I S-I S point -t o-point adj acency for m at ion is pr eceded by t he ex change of ES-I S-r elat ed I SHs bet w een t he t w o neighbor r out er s.

The IS-IS Routing Protocol Specified in I SO 10589, t he I S-I S r out ing pr ot ocol w as int ended t o pr ov ide a w ay t o dynam ically exchange rout ing inform at ion bet w een rout ers running CLNP in t he I SO CLNS envir onm ent . CLNP w as designed t o use a hop -b y-hop rout e -select ion m echanism t o m ove dat a w it hin a net w or k . The I S-I S pr ot ocol w as specified t o aut om at e t he best pat h calculat ion and select ion pr ocess. The design goals of I S-I S included t he follow ing:

42

•

Funct ion as an int r adom ain r out ing pr ot ocol

•

Pr esent a global view of t he net w or k for opt im al r out ing decisions

•

Pr ov ide fast conver gence in case of failur es

•

Provide net w ork st abilit y

•

Efficient ly use net w ork resources, such as rout er m em ory, CPU cycles, and net w ork bandw idt h

To achiev e t hese goals, I S-I S w as designed as a link-st at e r out ing pr ot ocol and opt im ized for u se w it h in a single net w ork dom ain; t herefore, it provides I nt erior Gat ew ay Prot ocol funct ionalit y. I S-I S suppor t s a t w o -level r out ing ( level 1 and level 2 r out ing) designed t o scale r out ing over lar ge dom ains. I t also uses t he Dij kst r a shor t est pat h fir st ( SPF) a lgorit hm t o opt im ize r out e calculat ion, pat h select ion, and t o achieve fast conver gence.

Integrated IS-IS The I nt er net Engineer ing Task For ce ( I ETF) RFC 1195, " Use of OSI I S-I S for Rout ing in TCP/ I P and Dual Envir onm ent s," specifies t he ver sion of t he I S-I S prot ocol, com m only know n as I nt egrat ed I S-I S or Dual I S-I S. I nt egr at ed I S-I S adapt s t he original I S-I S pr ot ocol t hat w as specified for CLNS environm ent s, for also rout ing I P. I t is int erest ing t o not e t hat I nt egrat ed I S-I S is one of few pr ot ocols t hat provides an int egrat ed fram ew ork for concurrent processing of m or e t han one net w or k lay er pr ot ocol; in t his case, I P and CLNP. Ot her r out ing pr ot ocols, such as t he OSPF, usually suppor t r out ing for only one t ype Layer 3 pr ot ocol. OSPF deals only w it h r out ing for I P. I nt egrat ed I S-I S can be used for rout ing in CLNP -only or I P-only net works, as w ell as in dual envir onm ent s, w hich have bot h CLNP and I P t r affic. This book focuses on t he use of I nt egrat ed I S-I S in I P net w or k s and specifically on t he ser v ice provider net w orks t hat m ake up t he I nt ernet . Even t hough not inherent ly designed for rout ing I P, t he successful use of I S-I S for I P r out ing on t he I nt er net led t o dev elopm ent of m any pr opr iet ar y feat ur es out side of RFC 1195 t o im pr ove usabilit y and t o pr ovide flexibilit y and scalabilit y. The I ETF has recent ly reopened t he I S-I S Wor king Gr oup t o explor e possibilit ies of st andar dizing som e of t he v endor-specific feat ures of I nt egrat ed I S-I S and dev eloping new st andar ds t o m eet t he r equir em ent s of em er ging applicat ions, such as Mult ipr ot ocol Label Swit ching ( MPLS) t raffic engineering. Many recent ly st andardized capabilit ies of I S-I S ar e docum ent ed as RFCs, w hereas ot hers are st ill under review in t he I ETF st andards t rack. Also, a second v er sion of I SO 10589, w hich w o uld include m ost of t hese new capabilit ies, is st ill under going r eview ( at t he t im e of w r it ing) and should be published soon. I ETF RFCs and dr aft publicat ions t hat ar e r elevant t o t he subj ect m at t er of t his book ar e m ent ioned w her e necessary.

Chapter Summary The I S-I S r out ing pr ot ocol is one of t hr ee net w or k lay er pr ot ocols specified by I SO t o suppor t t he CLNS. The ot her s ar e CLNP and ES-I S. Even t hough I S-I S w as designed for r out ing I SO CLNP pack et s, it has been adapt ed for use in I P env ir onm ent s as I nt egrat ed I S-I S.

43

I nt egr at ed I S-I S has ev olv ed ov er t he y ear s int o a scalable, r obust , and easy-t o-use I nt erior Gat ew ay Rout ing Pr ot ocol ( I GP) t hat can oper at e in dual m ode t o suppor t ov er lay ed I P and I SO CLNS net w orks. How ever, I S-I S has pr obably gained m or e po pularit y on t he I nt ernet , w here it s prim ary applicat ion is for int radom ain I P rout ing. As an I GP in an I nt ernet rout ing dom ain or aut onom ous sy st em , I nt egr at ed I S-I S plays a crit ical support ive role for t he Border Gat ew ay Pr ot ocol ( BGP) . BGP is designed w it h m ore elaborat e policy-handling capabilit ies and can handle a significant ly lar ge num ber of r out es of t he scale t hat can be found on t he I nt er net . I S-I S is a link-st at e prot ocol and t herefore gat hers rout ing inform at ion from adj acent neighbors int o a lin k-st at e dat abase and uses t he SPF algor it hm ( nam ed aft er Dij kst r a) t o det er m ine t he best pat hs t o dest inat ions w it hin t he net w or k. I n recent years, t he I nt egrat ed I S-I S has been fur t her enhanced t o handle em er ging net working t echnologies, such as Traffic Engineer ing w it h Mult ipr ot ocol Label Sw it ching ( MPLS/ TE) .

Review Questions

1:

Nam e t he t hree net work layer prot ocols t hat support t he I SO CLNS.

2:

I n com paring t he layers of t he TCP/ I P prot ocols suit e and t he I SO CLNS archit ect ure, describe how t he I nt ernet Prot ocol ( I P) differs from t he I SO Connect ionless Net work Prot ocol ( C LNP).

3:

What is t he use of t he I nt radom ain Rout ing Prot ocol Discrim inat or in t he I SO net work layer prot ocol packet headers?

4:

What was I S- I S originally designed for?

5:

How is I S- I S used in an I P net work?

6:

Describe any sim ilarit ies or differences bet ween t he ES- I S pr ot ocol and I P ARP.

References Adrian Tang,, Sophia Scoggins. Open Net working wit h OSI. Pr ent ice -Hall, 1992. I SBN 0 -1 3 3 51842-6 Jam es Mar t in, Joe Leben. DECnet Phase I V – An OSI I m plem ent at ion . Digit al Pr ess. 1992. I SBN 1 -5 5 5 5 8 -076 -9 I SO 7498 AD1: I nfor m at ion Pr ocessing Syst em s – Open Syst em s I nt erconnect ion – Basic Reference Model – Addendum 1: Connect ionless -Mode Transm ission I SO 7498: I nform at ion Processing Syst em s – Open Syst em s I nt erconnect ion – Basic Reference Model

44

Chapter 3. Integrated IS-IS Routing Protocol Concepts A span of int er connect ed r out er s oper at ed and m anaged by t he sam e adm inist r at iv e gr oup is r efer r ed t o as an aut onom ous syst em of r out er s or a rout ing dom ain. Such a sy st em of r out er s allow s for w ar ding of dat a t r affic fr om one locat ion t o t he ot her . The cur r ent I S-I S specificat ion, I SO 10589, r efer s t o net w or k nodes as int erm ediat e syst em s, but t his book uses t he equivalent t er m inology of rout ers m ore frequent ly because it is m ore popular in current net w or k ing lit er at ur e. I ndividual r out ing dom ains ar e int er connect ed t o for m lar ger net w or ks, such as t he I nt er net , allow ing t ransfer of dat a from one rout ing d om ain t o t he ot her over a large geographic span. Rout er s use rout ing prot ocols t o lear n about var ious locat ions w it hin local or r em ot e net w or k dom ains. The t w o basic t y pes of r out ing pr ot ocols follow :

•

I nt e r ior Ga t e w a y Pr ot ocols ( I GPs) — Opt im ized only for o per at ion w it hin a single net w or k dom ain. I GPs ar e also k now n as int r adom ain r out ing pr ot ocols.

•

Ex t e r ior Ga t e w a y Pr ot ocols ( EGPs) — Opt im ized for ex change of r out ing infor m at ion bet w een dom ains. EGPs ar e also r efer r ed t o as int er dom ain r out ing pr ot ocols.

I S-I S is designed and opt im ized t o pr ovide I GP funct ionalit y. The Bor der Gat ew ay Pr ot ocol ( BGP) is a w ell-know n r out ing pr ot ocol w it h ext ensive capabilit ies for int er dom ain r out ing. Typically, rout ing prot ocols support only one net work layer prot ocol ( Layer 3 in t he OSI reference m odel) . Therefore, w hen you use rout ers t o provide connect ivit y for m ult iple Layer 3 pr ot ocols concur r ent ly, t hey ar e usually configur ed w it h differ ent r out ing pr ot ocols for each t ype of Layer 3 pr ot ocol suppor t ed. This appr oach is r e ferred t o as ships in t he night . As m ent ioned in t he preceding chapt er, I nt egrat ed I S-I S support s t wo net work layer pr ot ocols: I SO CLNP and I P. Anot her r out ing pr ot ocol, w hich suppor t s m ult iple Layer 3 pr ot ocols, is t he Cisco pr opr iet ar y Enhanced I nt er ior Gat eway Rout ing Prot ocol ( EI GRP) . EI GRP can be used t o r out e I P, t he I nt er net Packet Exchange Pr ot ocol ( I PX) , and AppleTalk all at t he sam e t im e. Popular r out ing pr ot ocols t hat suppor t only one net w or k layer pr ot ocol include t he Net War e Link Ser v ices Pr ot ocol ( NLSP) , w hich is based on t he I S-I S pr ot ocol and suppor t s only I PX; t he Open Shor t est Pat h Fir st ( OSPF) Pr ot ocol suppor t s only I P. Ver sions 1 and 2 of t he Rout ing I nfor m at ion Pr ot ocol ( RI P) ar e also I P-only r out ing pr ot ocols. I S-I S and OSPF ar e sim ilar in m any r egar ds and ar e t he t w o m ost popular I GPs t hat ar e w idely deploy ed in I nt ernet service provider, I P-based ent er pr ise net w or ks.

IS-IS Routing Domain An I S-I S r out ing dom ain is a net w or k in w hich all t he r out er s r un t he I nt egr at ed I S-I S r out ing pr otocol t o suppor t int r adom ain ex change of r out ing infor m at ion. The net w or k env ir onm ent can be I P-only, I SO CLNP-only, or bot h. The I S-I S pr ot ocol w as or iginally int ended t o suppor t only CLNP. RFC 1195 adapt s t he or iginal I S-I S specificat ion ( I SO 10589) t o su ppor t I P, in w hat

45

is r efer r ed t o as I nt egr at ed I S-I S. The follow ing im plem ent at ion r equir em ent s ar e specified by RFC 1195:

•

Pur e I P dom ains r out e only I P t r affic but suppor t for w ar ding and pr ocessing of OSI packet s r equir ed for I S-I S oper at ion.

• •

Pur e I SO domains carry only I SO t raffic including t hose required for I S-I S oper at ion. A dual dom ain rout es bot h I P and OSI CLNP t raffic sim ult aneously.

I t is also possible t o design a dual dom ain so t hat som e ar eas r out e I P only , w her eas ot her s rout e CLNP only, and ye t ot her s r out e bot h I P and CLNP. RFC 1195 im poses r est r ict ions on t he m anner in w hich I P and CLNP can be m ix ed w it hin an ar ea. The under ly ing goal is t o achiev e consist ent r out ing infor m at ion w it hin an ar ea by hav ing ident ical Lev el 1 link-st at e dat abases on all r out er s in t hat ar ea. Hence, all r out er s in an ar ea ar e r equir ed t o be configur ed in t he sam e w ay , eit her for I P-only or CLNP-only or bot h. To clar ify fur t her , a r out er is not allow ed t o hav e a set of link s dedicat ed t o I P only and anot her set t o CLNP and y et anot her set t o bot h prot ocols. At t he dom ain level, t here is no rest rict ion on m ixing areas t hat are uniform ly I Ponly w it h ot her ar eas t hat ar e unifor m ly CLNP -only or unifor m ly configur ed for bot h I P and CLNP. I n or der w or ds, all link s in an area m ust be configur ed t he sam e w ay , but link s in t he backbone can have t he at t ached r out er s configur ed differ ent ly.

IS-IS Areas and Routing Hierarchies As specified in I SO 10589 and RFC 1195, t he I S-I S prot ocol support s a t wo -level hierarchy for m anaging a nd scaling r out ing in lar ge net w or ks. A net w or k dom ain can be car ved out in a planned w ay or ar bit r ar ily by t he net w or k designer or ar chit ect int o sm all segm ent s k now n as ar eas. This allow s hier ar chical r out ing t o be lever aged for efficient r out ing w it hin t he dom ain. I nt egr at ed I S-I S uses t he legacy CLNP node -based addresses t o ident ify rout ers even in pure I P envir onm ent s. The CLNP addr esses, w hich ar e know n as Net w or k Ser vice Access Point s ( NSAPs) , ar e m ade up of t hr ee com ponent s: an ar ea ident ifier ( ar ea I D) pr efix, follow ed by a sy st em ident ifier ( Sy sI D) , and an N-select or. The N-select or refers t o t he net w ork service user , such as a t r anspor t pr ot ocol or t he r out ing layer . I t has sim ilar int er pr et at ion as t he applicat ion por t num ber used in t he I P Tr ansm ission Cont rol Prot ocol ( TCP) . The CLNP addressing schem e is int roduced lat er in t his chapt er ( see t he sect ion " Addressing Concept s in I nt egrat ed I S- I S" )

an d discussed fur t her in det ail in Chapt er 4 , " Addressing in I nt egrat ed I S-I S."

For now , j ust r em em ber t hat each I S-I S r out er has a unique Sy sI D, w hich t oget her w it h t he area I D and a n N-select or value of 0x00 for m s a special NSAP know n as t he node's net w or k ent it y t it le ( NET) . A gr oup of r out er s belong t o t he sam e ar ea if t hey shar e a com m on ar ea I D. Not e t hat all rout ers in an I S- I S dom ain m ust be associat ed w it h a single phy sical a rea, which is det erm ined by t he area I D in t he NSAP. I n pract ice, an I S-I S r out er can be configur ed w it h m ult iple NSAPs all w it h differ ent ar ea I Ds and sam e Sy sI D in sit uat ions w her e t he r out er is " hom ed" t o m ult iple areas. As discussed lat er, how ever, m ult ihom ing m er ges all t he ar eas inv olv ed int o a single phy sical ar ea. Rout er s belonging t o a com m on ar ea and engaged in

46

Level 1 rout ing are referred t o as Level 1 rout ers. I n CLNP rout ing, Level 1 rout ing involves collect ing SysI D and adj acency inform at ion t hr ough all r out er s and host s in t he local ar ea. Rout er s in differ ent ar eas ex change r out ing infor m at ion t hr ough Lev el 2 r out ing and ar e r efer r ed t o as Lev el 2 or back bone r out er s. I n CLNP Lev el 2 r out ing, r out er s ex change ar ea pr efix infor m at ion w it h t heir peers. For I P rout ing, however, int ra -ar ea I P pr efix es ar e exchanged w it hin t he area in Level 1 rout ing. The I P prefixes originat ed in t he various areas ar e t hen exchanged bet w een ar eas in Level 2 r out ing by r out er s connect ed t o t he backbone. I n m ost designs w it h r out ing hier ar chy, t he Level 2 r out er s ar e also Level 1 r out er s by vir t ue of t heir ident ificat ion w it h a cer t ain ar ea. Ther efor e, in I S-I S, a rout er can funct ion as Level 1 only or Level 2 -only and possibly as bot h Level 1 and Level 2 ( Level 1 -2) . Lev el 1 -2 r out er s act as bor der r out er s t o t heir r espect ive ar eas, pr oviding connect ivit y t o ot her ar eas. The Level 2 backbone is essent ially a virt ual I S-I S ar ea consist ing of r out er s engaged in Level 2 r out ing ( see

Figure 3 - 1 ) .

The Level 2 st r et ch in a net w or k m ust be cont iguous, r equir ing all r out er s t o be

int erconnect ed. Because part it ion repair is not support ed in Cisco I OS and m ost ot her im plem ent at ions, t he cont iguit y r equir em ent also applies t o Level 1 ar eas. I n a hier ar chical net work, som e Level 2 -only r out er s could be em bedded in t he back bone w it ho ut im pact ing t r affic flow bet w een t he r espect ive ar eas suppor t ed by Level 1 -2 rout ers. Exist ing I S-I S specficat ions require only Level 2 rout ers t o provide connect ivit y t o ext ernal dom ains; how ever, Cisco I OS allow s redist ribut ion of ext ernal rout es int o Lev el 1 for hist or ical and pr act ical r easons. Figur e 3 - 1 . I S- I S areas.

Level 1 -only r out er s ar e aw ar e of t he local ar ea t opology only, w hich involves all t he nodes in t he ar ea and t he next -hop r out er s t o r each t hem . Lev el 1 r out er s depend on Lev el 2 r out er s

47

for access t o ot her ar eas and for w ar d all t r affic t o dest inat ions out side t he ar ea t o t he closest Level 2 rout er. Cisco rout ers running I S-I S can b e configur ed t o be eit her Lev el 1 -only, Level 2 -only, or bot h. By default , t hey ar e bot h Lev el 1 and Lev el 2, and special configur at ion is r equir ed t o disable Level 1 or Level 2 capabilit y. Caut ion m ust be exer cised w hen disabling eit her capabilit y because t his m ight int roduce disrupt ive inconsist encies int o t he rout ing environm ent . I n Figure 3-1,

rout ers RTA-1, RTA-2, RTA-3, and RTX m ust be Level 2 -capable t o part icipat e in rout ing

bet w een t he ar eas. RTX can be in it s ow n dedicat ed ar ea and because it doesn't connect t o any Lev el 1 r out er s, it can be configured t o be Level 2 -only . How ev er , t he ot her s m ust be Level 1 -2 and each ident ified w it h a specific ar ea for w hich it pr ovides int er ar ea connect ivit y. RTB-n, RTC-n ( n = 1,2,3) can be configur ed t o be Level 1 -only if t hey don't need t o connect t o t he backbone .

IS-IS Packets Befor e delving int o ot her concept s behind t he I S-I S pr ot ocol, y ou need t o under st and t he fundam ent als of I S-I S packet s and packet form at s. This know ledge aids in t he underst anding of t he capabilit ies of t he pr ot ocol and how it w or ks. Connect ionless pr ot ocols, such as CLNP and I P, t r ansm it dat a in lit t le chunks know n as packet s. I n I SO 10589, packet s ar e r efer r ed t o as prot ocol dat a unit s (PDU) . This book refers t o t hem as packet s in conform it y w it h I P t er m inology. Mult iple packet t ypes ar e used in connect ionless environm ent s, w it h dat a and r out ing infor m at ion packet s being pr edom inant . This sect ion br iefly r eview s t he t ypes of packet s used in t he I S-I S pr ot ocol and t heir gener al form at . I S-I S packet s have t hr ee cat egor ies: hello packet s, link-st at e pack et s, and sequence num ber pack et s. Hello pack et s ar e used t o est ablish and m aint ain adj acencies bet w een I S-I S neighbor s. Link-st at e packet s are used t o dist ribut e rout ing inform at ion bet w een I S-I S nodes. Sequence num ber packet s ar e used t o cont r o l dist r ibut ion of link-st at e packet s, essent ially pr oviding m echanism s for synchr onizat ion of t he dist r ibut ed Link-St at e dat abases on t he rout ers in an I S-I S r out ing ar ea. Hello packet s have t he follow ing subcat egories:

•

LAN Level 1 hello packet s ( PDU Type 15)

•

LAN Level 2 hello packet s ( PDU Type 16)

•

Point -t o-point hello packet s ( PDU Type 17)

Lin k-st at e packet s have t he follow ing subcat egor ies:

• •

Lev el 1 link-st at e packet s ( PDU Type 18) Lev el-2 link-st at e pack et s ( PDU Ty pe 20)

Finally, sequence num ber packet s hav e t he follow ing subcat egor ies:

48

•

Level 1 com plet e sequence num ber packet s ( PDU Type 24)

•

Level 2 com plet e sequence num ber packet s ( PDU Type 25)

• •

Lev el 2 par t ial sequence num ber pack et s ( PDU Ty pe 27)

Lev el 1 par t ial sequence num ber pack et s ( PDU Ty pe 26)

IS-IS Packet Formats Each t ype of I S-I S packet is m ade up of a header and a num ber of opt ional var iable -lengt h fields cont aining specific rout ing-relat ed inform at ion. Each variable -lengt h field has a 1 -by t e t ype label t hat descr ibes t he infor m at ion it cont ains. The value of t he variable -lengt h field is t he specific inform at ion it cont ains. Typically, t he value is com posed of repeat ed blocks of sim ilar infor m at ion, t he lengt h of w hich is specified in a 1 -byt e lengt h field. Type, lengt h, and v alue for m a tuple ( TLV) , w hich has becom e a synonym for var iable -lengt h fields. The t ypes of variable -lengt h fields ar e act ually specified as num er ic code values. Bot h cur r ent I S-I S specificat ions, I SO 10589 and RFC 1195, use code in r at her t han t ype, but TLV has gained m ore popularit y t han CLV in current net w orking lit erat ure because it is used in ot her prot ocol specificat ions. The different t ypes of I S-I S packet s have a slight ly differ ent com posit ion of t he header fields but t he first eight fields, each 1 -by t e long, ar e r epeat ed in all packet s ( see Figure 3 - 2 ) . Each t ype of pack et t hen has it s ow n set of addit ional header fields, w hich ar e t hen follow ed by TLVs. The addit ional header fields vary in com posit ion, lengt h, and order of t he inform at ion.

Figure 3 - 2

show s t he gener ic packet for m at and t he com m on fields shar ed by all I S-I S pack et s. Figur e 3 - 2 . I S- I S hea der fields.

49

•

I nt r a dom a in Rout ing Pr ot ocol D iscr im ina t or — This is t he net w or k layer ident ifier assigned t o I S-I S, as specified by I SO 9577. I t s value is 10000011 ( binary) , 0x83 ( hexadecim al) , or 131 ( decim al) .

•

Le ngt h I ndica t or — Lengt h of t he pack et header fields in oct et s.

•

Ve r sion / Pr ot ocol I D Ex t e n sion— Cur r ent ly has a v alue of 1.

•

I D Lengt h— I ndicat es lengt h of t he sour ce I D ( Sy sI D) field. A v alue of 0 im plies a len gt h of 6 byt es; a value of 255 im plies 0 lengt h. Ot her possible values ar e 1 t o 8 for act ual lengt h in byt es.

•

PD U Type — Specifies t he t y pe of I S-I S pack et . The t hr ee t y pes of I S-I S pack et s ar e hello pack et s, link-st at e packet s ( LSPs) , and sequence num ber packet s ( SNPs) .

•

Version— The v alue is 1 .

•

Re se r ve d— Un u sed bit s. Set t o 0 s.

•

M a x im um Ar e a Addr e sse s— Values bet w een 1 and 254 for act ual num ber . A v alue of 0 im plies a m ax im um of t hr ee addr esses per ar ea.

The Type, Lengt h, and Value at t r ibut es of TLV fields have t h e follow ing m eaning:

•

Type — A num ber code for a specific TLV. I SO10589 uses t he w or d code in place of t ype. How ev er , t ype seem s t o be pr efer r ed in I ETF and Cisco lit er at ur e on I S-I S.

• •

Le n gt h— Lengt h specifies t he t ot al lengt h of t he TLV. Value — Valu e in dicates t he cont ent of t he TLV.

All packet s in each cat egory of packet t ype have sim ilar inform at ion in t he header. The TLV fields ar e appended t o t he header t o m ake up t he ent ir e packet . Each t ype of packet suppor t s only specific TLV fields, which m ight opt ionally be pr esent in a r eal pack et . This t opic is explored furt her lat er in t his chapt er. Table 3 - 1

list s TLVs specified in I SO 10589.

Table 3 - 1 . I SO 1 0 5 8 9 TLVs

TLV Area Address I nt erm ediat e Syst em Neighbors End Syst em Neighbors Part it ion Designat ed Level 2 I nt erm ediat e Syst em Pr efix Neighbors I nt erm ediat e Syst em Neighbors

Type D e scr ipt ion 1 Area address( es) of source node 2 Neighboring rout ers and pseudonodes ( appended t o t he link- st at e packet ) 3 Connect ed workst at ions 4 Level 2 neighbors t hat int erconnect pieces of a part it ioned area w it h a virt ual link over t he Level 2 area 5 Reachable NSAP prefixes ( not including local area prefixes) 6 LAN- connect ed rout ers from which I SI S hello packet s have been received 50

( appended t o LAN hello) Not Specified Padding

7 8

LSP Ent ries Aut hent icat ion I nform at ion

9 10

Padding for hello packet s t o m axim um t ransm ission unit ( MTU) Link- st at e inform at ion I nform at ion for I S- I S packet aut hent icat ion

Enhancem ent s t o t he original I S-I S pr ot ocol as specified in I S0 10589 ar e nor m ally achieved t hr ough t he int r oduct ion of new TLV fields. Enhancem ent s, at t ained in t his m anner include TLVs int roduced by RF1195 for I nt egrat ed I S-I S and r ecent m odificat ions t o suppor t Mult iprot ocol Label Swit ching ( MPLS) Traffic Engineering.

Table 3 - 2

list s t he TLVs int roduced by

RFC 1195. Not e t hat a key st r e ngt h of t he I S-I S pr ot ocol design lies in t he ease of ex t ension t hr ough t he int r oduct ion of new TLVs r at her t han new packet t ypes.

Table 3 - 2 . RFC 1 1 9 5 TLVs

TLV I P I nt ernal Reachabilit y I nform at ion Pr ot ocols Support ed

Type D e scr ipt ion 128 I nt r adom ain I S- I S rout es

I P Ext ernal Reachabilit y I nform at ion I nt erdom ain Rout ing Prot ocol I nform at ion I P I nt erface Address Aut hent icat ion I nform at ion

130

129

131 132 133

Prot ocol ident ifiers of support ed net work layer prot ocols ( for exam ple, I P and CLNP) Rout es ext ernal t o t he I S- I S dom ain, such as t hose im port ed from ot her sources via redist ribut ion For t ransparent dist ribut ion of int erdom ain rout es I P address of t he out going int erface I S- I S packet aut hent icat ion ( sim ilar t o Type 10, but doesn't define aut hent icat ion Type 255)

IS-IS Protocol Functions The r out ing layer funct ions pr ovided by t he I S-I S prot ocol can be grouped int o t w o m ain cat egories: subnet w ork-dependent funct ions and subnet w ork-independent funct ions. I n I S-I S, subnet work refe rs t o t he dat a -link layer. This not ion fundam ent ally differs from I P t er m inology, in w hich a subnet w or k r efer s t o an I P addr ess subnet . Only t w o t ypes of I S-I S

51

subnet w or ks ar e of pr act ical significance in cur r ent applicat ions of t he I S-I S pr ot ocol: point -t o point and br oadcast link s. The subnet w ork-dependent funct ions relat e t o capabilit ies for int erfacing wit h t he dat a -link layer and pr im ar ily involve oper at ions for det ect ing, for m ing, and m aint aining r out ing adj acencies w it h neighbor ing r out er s ov er v ar ious t y pes of int er connect ing net w or k m edia or link s. The ES-I S pr ot ocol and cer t ain elem ent s of CLNP ar e k ey t o t he oper at ion of t he subnet w or k-dependent funct ions. Subsequent sect ions explor e t he subnet w or k-dependent funct ions. I n t hose sect ions, you w ill lear n about I S-I S links, I S-I S adj acencies, and t y pes of I S-I S syst em s ( nodes) . The subnet w ork-independent funct ions provide t he capabilit ies for exchange and processing of r out ing infor m at ion and r elat ed cont r ol infor m at ion bet w een adj acent r out er s as validat ed by t he subnet w or k -dependent funct ions. The I S-I S r out ing engine, discussed lat er in t his sect ion, elabor at es on t he r elat ionship bet w een subsyst em s ( pr ocesses and dat abases) t hat pr ovide t he subnet w or k-independent funct ions w it hin t he fram ew ork of a convent ional rout er.

Subnetwork-Dependent Functions The r ole of t he subnet w or k -dependent funct ions of t he I S-I S pr ot ocol w as descr ibed in t he pr evious sect ion. Cr it ical com ponent funct ions ar e fur t her descr ibed w it hin t his sect ion. The I S-I S rout ing prot o col dist inguishes t w o m ain t ypes of subnet w or ks or links in a net w or k: gener al t opology subnet w or ks and br oadcast subnet w or ks.

Ge n e r a l Topology Su bn e t w or k s General t opology subnet w orks are perm anent or dynam ically est ablished point -t o-point links. An exam p le of t he form er is Packet over SONET/ SDH. Asynchronous Transfer Mode ( ATM) point -t o-point sw it ched vir t ual cir cuit ( SVC) is an exam ple of t he lat t er .

Br oa dca st Su bn e t w or k s Br oadcast subnet w or ks ar e m ult ipoint or local-ar ea net w or k ( LAN) m edia w it h br oadcast capabilit ies, such as Et hernet , Fiber Dist ribut ed Dat a I nt erface ( FDDI ) , or t he Cisco -inv ent ed Dynam ic Packet Transport Technology ( DPT) . N OTE

The Cisco im plem ent at ion of t he I S-I S rout ing prot ocol operat es in broadcast m ode over nonbroadcast m ult iacces s ( NBMA) t echnologies, such as Fram e Relay and ATM, w hen configured in m ult ipoint m ode. This m ode of operat ion requires t he use of Layer 3 -t o-Lay er 2 addr ess m ap st at em ent s and assum es a full-m esh per m anent

52

virt ual circuit ( PVC) environm ent . I n cert ain cas es, special w or kar ounds m ight be r equir ed for effect ive applicat ion of I S-I S in such envir onm ent s. How ever , for such m edia, point -to-point configurat ion is highly recom m ended.

I S- I S N e t w or k N ode s The I SO Connect ionless Net w or k Pr ot ocol is specified for t ransfer of dat a bet w een t w o m ain cat egor ies of net w or k dev ices:

•

End syst e m s— The analogy for an end sy st em is a w or k st at ion or net w or k host w it h lim it ed rout ing capabilit y.

•

I nt e r m e dia t e syst e m s— These ar e net w or k dev ices such as r out er s w it h ex t ensiv e packe t -for w ar ding capabilit ies. The w or d int erm ediat e r efer s t o t he capabilit ies of r out er s as int er m ediat e for w ar ding or r elay devices. Rout er s ar e r efer r ed t o as gat eways in som e older net w or k ing lit er at ur e.

The I S-I S r out ing pr ot ocol is designed t o pr ov ide r out ing int elligence for int erm ediat e syst em s, w hose r ole in t he net w or k is t o r elay dat a bet w een user applicat ions r unning on dist ant ly locat ed end sy st em s. I S-I S allow s t he gat her ing and pr ocessing of r out ing infor m at ion by r out er s w it hin t he sam e dom ain. Rout er s can locat e end syst em s on dir ect ly connect ed segm ent s using ES-I S for CLNP or ARP for I P. Ther efor e, t he com binat ion of ES-I S and I S-I S or ARP allow s r out er s t o per for m t heir pr im ar y funct ion of helping m ove dat a packet s fr om one end sy st em t o ano t her w it hin t he net w or k dom ain.

Adj a ce n cie s The subnet w ork-dependent funct ions of t he r out ing layer pr ovided by I S-I S are responsible for discovering, est ablishing, and m aint aining adj acencies bet w een t he rout ers in an I S-I S dom ain. As st at ed pr eviously, I S-I S w or k s in conj unct ion w it h ES-I S and cer t ain elem ent s of t he CLNP prot ocol t o achieve t his. No special configurat ion is required on Cisco rout ers t o en able ES-I S. The ES-I S operat ion is enabled aut om at ically w hen I S-I S is configur ed on Cisco rout ers, a nd it r uns as a backgr ound pr ocess t o suppor t t he oper at ion of I S-I S. The subnet w or k-dependent funct ions of I S-I S w or k w it h ES-I S t o det erm ine net w ork layer addresses of all adj acent neighbors ( bot h end syst em s and rout ers) . On m ult iaccess links, dat a -link addr esses ( for exam ple, MAC addr esses; also r efer r ed t o as subnet w or k point s of at t achm ent [ SNPAs] ) are obt ained for all adj acent neighbors and st ored in t he adj acency dat abase.

ES-IS Adjacencies ES-I S is designed for host -t o-r out er com m unicat ion in a pure I SO env ir onm ent , such as im plem ent ed in Digit al's DECnet Phase V net w or king ar chit ect ur e. I n an I P envir onm ent , ES-I S is r elev ant only t o t he ex t ent t hat it facilit at es r out er-t o-r out er adj acency for m at ion. I P host s

53

do not par t icipat e in t he ES-I S pr ot ocol and inst ead rely on ARP for Layer 3 -to-Lay er 2 addr ess r esolut ion in det er m ining t he Lay er 2 addr esses of LAN-connect ed host s and t he I P default gat ew ay . I n CLNP env ir onm ent s, end sy st em s and r out er s use t he ES-I S pr ot ocol t o discov er each ot her by sending ESHs and I SHs t o w ell-k now n LAN br oadcast addr esses. End sy st em s send ESHs t ar get ed at t he r out er s t o 09 -0 0 -2 B-0 0 -0 0 -05 ( AllI nt erm ediat eSyst em s) , and rout ers send t he I SHs t o 09 -0 0 -2 B-0 0 -0 0 -04 ( AllEndSyst em s) . ES-I S allow s end sy st em s t o locat e t he closest rout er for access t o ot her nondirect ly connect ed m edia. Rout ers, in t urn, lear n about t he locat ion of end sy st em s t hr ough t he ES-I S adj acency inform at ion. Rout ers also dist r ibut e t he Sy sI D of k now n end sy st em s t o ot her r out er s w it hin t he sam e ar ea by m eans of Level 1 I S-I S r out ing. Ot her ES-I S ev ent s, such as r edir ect ion, ar e bey ond t he scope of t his book . Figur e 3 - 3 . En d Syst e m H e llo ( ESH ) a n d I n t e r m e dia t e Syst e m H e llo ( I SH ) .

IS-IS Adjacencies Direct ly connect ed rout ers enabled for I S-I S r out ing go bey ond t he ES-I S adj acencies descr ibed in t he pr eceding sect ion t o for m I S-I S adj acencies. The I S-I S adj acencies on point t o-point link s ar e for m ed and m aint ained a lit t le differ ent ly t han on br oadcast link s. Consequent ly, different t ypes of I S-I S hellos ( I I Hs) ar e used. The t hr ee t y pes of I I Hs follow :

54

•

Point - t o- point I I H — Used ov er point -to-point links

•

Level 1 LAN I I H — Used ov er br oadcast link s, but for Lev e1 1 adj acencies

•

Level 2 LAN I I H — Used on br oadcast link s, but for Lev el 2 adj acencies

Like all I S-I S pack et s, t he I S-I S hello packet s ar e m ade up of header s and var iable -lengt h fields. The point -t o-point I I Hs and LAN I I Hs hav e slight ly v ar ied infor m ation in t heir header area. Most ly, how ever, sim ilar inform at ion is cont ained in t he header area of bot h packet t y pes ex cept t hat point -to-point I I Hs have a local circuit I D in place of t he LAN I D in LAN I I Hs. Also, point -to-point I I Hs do not hav e t he pr ior it y inform at ion found in LAN I I Hs. As specified in I SO 10589, TLV t ypes used in point -t o-point I I Hs are lim it ed t o t he follow ing:

•

Ar ea Addr esses ( Ty pe 1)

•

Padding ( Ty pe 8)

•

Aut hent icat ion Type ( Type 10)

LAN I I Hs suppor t t he follow ing TLVs fields:

•

Area Addresses ( Ty pe 1)

•

I nt erm ediat e Syst em Neighbors ( Type 6)

• •

Padding ( Ty pe 8) Aut hent icat ion I nfor m at ion ( Type 10) N OTE

The absence of infor m at ion on int er m ediat e syst em neighbor s in point -t o-point I I Hs as specified in t he original hello form at caused reliabilit y is sues in for m ing point -topoint adj acencies. A r ecent I EFT dr aft pr oposes TLV Type 240 t o addr ess t his problem . This draft is discussed lat er in t his chapt er.

Successful for m at ion of an I S-I S adj acency bet w een t w o nodes pav es t he w ay for t he ex change of I S-I S r out ing infor m at ion by using special r out ing infor m at ion and cont r ol packet s k now n as link-st at e packet s ( LSP) and sequence num ber packet s ( SNP) , respect ively. LSP and SNP exchange bet w een I S-I S rout ers is discussed in -dept h in Chapt er 5, " I S- I S Link- State Database." The t y pe of adj acency for m ed bet w een neighbor r out er s det er m ines t he t y pe of r out ing inform at ion t hat is exchanged bet w een t hem . As m ent ioned previously, I S-I S rou t in g h as a t w o -lev el hier ar chy , Lev el 1 and Lev el 2, and t he t y pes of adj acencies t hat can be for m ed ar e consist ent w it h t his hier ar chy . As specified, r out er s in t he sam e ar ea m ust be able t o for m at least a Level 1 adj acency, r egar dless of t he t ype of int erconnect ing links ( point -t o-point or br oadcast ) . On Cisco r out er s, t he default m ode of oper at ion for r out er s in t he sam e ar ea, is t o for m bot h Lev el 1 and Lev el 2 adj acencies. Rout er s t hat belong t o differ ent ar eas can for m only Lev el 2 adj acencies. Poin t -to-point and br oadcast adj acencies ar e fur t her cov er ed in det ail in lat er sect ions of t his chapt er .

55

H e llo I n t e r v a l, H e llo M u lt iplie r , a n d H e llo H oldt im e Rout er s per iodically send hello packet s t o adj acent peer s, ever y hello int erval. Th e h ello int erval is j it t er ed, up t o about 25 per cent , t o r educe t he likeliness of synchr onized I I H t r ansm ission ov er t he net w or k . On Cisco r out er s, t he default v alue of t he hello int er v al is 10 seconds for or dinar y r out er s and 3.3 seconds for t he designat ed int er m ediat e syst em ( DI S) on a m ult iaccess link. I S-I S uses t he concept of hello m ult iplier t o det er m ine how m any hello packet s can be m issed from an adj acent neighbor before declaring it " dead." The m axim um t im e lapse allow ed bet w een r eceipt of t w o consecut iv e hello pack et s r eceiv ed is r efer r ed t o as t he holdt im e. The holdt im e is defined as t he pr oduct of t he hello int er v al and t he hello m ult iplier . On Cisco r out er s, t he default value of t he hello m ult iplier is 3; t her efor e, t he default hold t im e is 30 seconds. I f a r outer does not r eceiv e a hello fr om a neighbor befor e t he holdt im e ex pir es, t he adj acency is t or n dow n. The holdt im e is r eset any t im e a hello is r eceiv ed. Hellos ar e t r ansm it t ed per iodically by r out er s t o neighbor s at t he ex pir at ion of t he hello int erval. However, t he follow ing condit ions w ill also t rigger im m ediat e t ransm ission: Any change in net w ork condit ions causing changes in TLV inform at ion advert ised in t he m ost recent hello t ransm it t ed Elect ion t o or resignat ion from LAN DI S posit ion

I S- I S Point - t o- Poin t Adj a ce n cie s I S-I S adj acencies on point -to-point link s ar e init ialized by r eceipt of I SHs t hr ough t he ES-I S pr ot ocol. This is follow ed by t he exchange of point -t o-point I I Hs. The t ype of adj acency for m ed w ill depend on t he param et ers exchanged in t he I I Hs. The I I Hs also ar e sent per iodically ov er t he link t o ever y hello int er val t o m aint ain t he adj acency. On Cisco r out er s, t he default hello int er val for point -to-point links is 10 seconds. The form at of t he point -t o-point hello packet is show n in

Figure 3 - 4 .

Figur e 3 - 4 . Poin t- to- Poin t H e llo Pa ck e t ( PD U Type 1 7 ) .

56

A r out er per for m s check s on a r eceived I I H t o confir m var ious par am et er s in t he hello header , such as SysI D lengt h, Maxim um Area Addresses, and so on. Sy st em capabilit ies ar e adv er t ised in t he appended TLVs. The TLV fields t hat m ight be appended t o t he point -to-point hello packet are Area Addresses ( Type 1) , Padding ( Type 8) , and Aut hent icat ion ( Type 10) inform at ion. Padding is applied in increm e nt s of 2 by t es up t o at least 1 by t e shor t of t he physical MTU of t he out going int erface. The follow ing is a list of pack et t y pe-specific fields in t he header of a point -to-point hello:

•

Circuit Type— Lev el 1, Lev el 1 -2, or Level 2 only

•

Source I D — Syst em I D of t he r out er t hat gener at ed t he hello pack et

•

H olding Tim e — Maxim um int er val bet w een t w o consecut ive hello packet s befor e t he rout er is considered no longer available

•

PDU Lengt h— Lengt h of t he ent ir e PDU, including header

57

• •

Local Circuit I D — Unique link ident ifier TLV Fie lds— Var iable -lengt h fields

When an I SH is r eceived on a new ly enabled point -t o-point link , t he r out er v er ifies w het her an adj acency alr eady exist s w it h t he sender by checking t he sour ce SysI D in t he I SH against it s adj acency dat abase. The I SH is ignored if an adj acency exist s. I f not , t he receiving rout er cr eat es a new adj acency and set s it s st at e t o " init ializing" and t he syst em t ype t o " unknow n." The r out er t hen sends t he new neighbor an I I H in r esponse. Upon r eceiving a subsequent I I H fro m t he new neighbor , t he r out er t hen m ov es t he adj acency t o an up st at e and changes t he neighbor 's syst em t ype t o I S. I n t his pr ocess, t he local r out er is unable t o det er m ine w het her it s hellos ar e r eaching t he r em ot e end. As specified in I SO 10589, point -to -point hellos do not include t he I S Neighbors TLVs ( Type 6) ; t her efor e, it is im possible t o use a t hr ee -w ay process t o confirm w het her hellos generat ed locally ar e r eaching neighbor s. This m ight lead t o sit uat ions w her e one end of an adj acency is up but t he ot her end is not . An I nt er net dr aft subm it t ed t o t he I ETF pr oposes a m or e r eliable w ay t o for m point -to-point I S-I S adj acencies —by using a t hree -w ay handshak e pr ocess, w hich is backward -com pat ible t o t he I SO 10589 pr ocedur e. I n t he default m ode of opera t ion, I I Hs are padded t o t he MTU size of t he out going int erface. Rout er s m at ch t he size of I I Hs r eceived t o t heir local MTUs t o ensur e t hat t hey can handle t he lar gest possible packet s fr om t heir neighbor s befor e com plet ing an adj acency. When a r out er sends out a hello packet , it set s t he Cir cuit Type field in t he header t o Level 1 only, Level 2 only, or Level 1 -2, depending on it s configurat ion, eit her globally by I S t ype or on an int er face lev el by cir cuit t y pe. The default I S t y pe on a Cisco r out er is t o be bot h a Lev el 1 and Lev el 2, but t his can be m odified t o be Lev el 1 only or Lev el 2 only . Cisco r out er s also allow t he cir cuit t ype of a link t o be m odified individually and independent of t he global I S t ype. A rout er assigns a locally unique link ident ifier t o each point -to-point link by using t he 8 bit Local Circuit I D field in t he hello header. The 8 -bit field allow s upt o 256 unique point -topoint links only t o be defined in an I S-I S rout er. Effort s in t he I ETF's I S-I S Wor k ing Gr oup t o rem ove t his lim it at ion is discussed in a lat er sect ion. One of t he key r equir em ent s of I S-I S is t hat t he lengt h of t he Sy sI D m ust be consist ent on all r out er s acr oss t he dom ain. Consequent ly, if t he I D Lengt h field of t he hello packet ( w hich indicat es t he lengt h of t he SysI D) is set t o a different value from w hat is expect ed, t he r eceiving r out er discar ds t he I I H. On Cisco r out er s, t he lengt h of t he SysI D is fixed at 6 byt es. A v alue of 0 in t he I D field of an I I H indicat es suppor t for a 6 -by t e Sy sI D. This m eans t hat all nodes int eroperat ing w it h Cisco rout ers in an I S-I S net w or k need t o set t he v alue of t he I D field t o 0, t o indicat e t hey also support 6 -by t e Sy sI Ds. Det ails of t he CLNS addr essing schem e used in I S-I S is cov er ed in Chapt er 4 , " Addressing in I nt egrat ed I S-I S." The m axim um num ber of area addresses support ed in a single rout er configurat ion m ust m at ch bet w een adj acent neighbor s as w ell, unless t he v er ify ing r out er suppor t s only a m axim um value of 3. By default , Cisco r out er s suppor t a m axim um of t hr ee ar ea addr esses.

58

This can be changed t o 255 in recent I OS releases. Any disagreem ent in t he m axim um num ber of suppor t ed ar eas causes t he I I H t o be discar ded; ot her w ise, it is accept ed fo r fur t her pr ocessing. As pr eviously not ed, adj acency infor m at ion such as SNPAs and cor r esponding Sy sI Ds ar e obt ained fr om t he I SHs t hat ar e ex changed t hr ough t he ES-I S pr ot ocol. A key r ole of I I Hs, how ever , is t o help est ablish t he t ype of t he adj acency t o b e for m ed. The r eceiving r out er det er m ines t he t ype of adj acency t o be for m ed w it h t he r em ot e r out er fr om t he I S t ype and t he Ar ea I D adver t ised in t he r eceived hello. Thus, in det er m ining t he t ype of adj acency, a r out er consider s all t he addr esses defined in t he Ar ea Addr ess TLVs pr esent in t he I I H r eceiv ed. Because t hey belong t o differ ent ar eas, t w o r out er s w it h nonm at ching Ar ea I Ds can for m only a Level 2 adj acency. I f t w o connect ed Cisco r out er s m at ch in Area I Ds, t hey'll form bot h Level 1 and Level 2 adj acencies accor ding t o default behavior. I f aut hent icat ion is configured, t he rout er appends an Aut hent icat ion TLV field ( Type 10) t o t he hello pack et , w hich is t hen check ed by t he r eceiv ing node. I SO 10589 and RFC 1195 specify use of clear-t ext , sim ple passw ords only. Current ly, Cisco rout ers do not support any ot her m ore sophist icat ed aut hent icat ion m et hods. More sophist icat ed aut hent icat ion using MD5 m essage digest m ight be suppor t ed in t he fut ur e. I f any of t he adj acency checks pr eviously descr ibed fails, a r out er w ill not br ing up t he new adj acency or w ill t ear dow n an ex ist ing adj acency . When a r out er t ear s dow n an adj acency , it gener at es a not ificat ion m essage and r em oves t he cor r esponding ent r y fr om it s adj acency dat abase. I n case of a link failure, t he I S-I S pr ocess r eact s as soon as it obt ains appr opr iat e not ificat ion fr om t he int er face subsy st em , by r em ov ing any adj acencies associat ed w it h t he affect ed int er face. The r out er t hen gener at es and floods an updat ed LSP r eflect ing t he change t o ot her neighbor s.

For m in g a Re lia ble Poin t - t o- Poin t Ad j a ce n cy The t hree -w ay handshake pr ocess for r eliably for m ing point -to-point adj acencies int r oduces a new t y pe lengt h v alue field ( Ty pe 240) , k now n as Point -to-Point Adj acency St at e TLV. For backward com pat ibilit y, older syst em s r unning I S-I S im plem ent at ions t hat do not support TLV Type 240 can ignore it , if encount ered in an I I H, and follow convent ional procedures for form ing t he adj acency. This is necessary so t hat new er and older syst em s can coexist in t he sa m e net work. The t hree -w ay handshak e r equir es a confor m ing sy st em t o m ov e t he st at e of t he point -t o-point adj acency t o up only aft er confir m ing t hat t her e is bidir ect ional com m unicat ion w it h t he r em ot e r out er and t hat it s hellos ar e r eaching t he r em ot e end. Com pliant rout ers include t he SysI Ds of neighbors from which t hey have received hellos in TLV 240. A r out er k now s it s hellos ar e r eaching a point -to-point neighbor w hen it r eceives a hello fr om t hat neighbor in w hich it is list ed in t his TLV. The TLV Ty pe 240 consist s of t he follow ing infor m at ion: Ty pe: 0x F0 ( decim al 240) Lengt h: 5 t o 17 oct et s

59

Value ( 1 oct et ) : Up ( 0) , init ializing ( 1) , dow n ( 2) Ext ended Local Cir cuit I D: 4 oct et s Neighbor Syst em I D: 0 t o 8 oct et s Neighbor Ext ended Local Circuit I D: 0 or 4 oct et s if k now n This TLV enhances t he I S-I S point -to-point adj acency for m at ion pr ocess in t w o w ay s. Fir st , a node can confirm t hree -w ay com m unicat ion w it h it s neighbor by confir m ing t he pr esence of it s SysI D in a TLV 240 at t ached t o hellos r eceived fr om t he neighbor. The local adj acency st at e can t hen be adj ust ed based on t he ex ist ing st at e and t he st at e feat ur ed in t he Value field of TLV 240 fr om t he hello r eceiv ed. Second, t he Ex t ended Local Cir cuit I D field in TLV 240 can be lever aged t o pr ovide unique link I Ds for point -t o-point links beyond t he 256 lim it specified in I SO 10589.

I S- I S Adj a ce n cie s ov e r M u lt ia cce ss M e dia The m et hod specified in I SO 10589 for building adj acencies over br oadcast m edia, such as LANs, differ s slight ly fr om t hat used on point -t o-point links. Som e of t he significant differences ar e as follow s:

•

The pr ocess is not t r igger ed by r eceipt of I SHs. A r out er sends I I Hs on br oadcast int er faces as soon as t he int er face is enabled.

•

The br oadcast m edium is m odeled as a node, called t he pseu donode. The pseudonode r ole is play ed by an elect ed DI S.

•

Depending on t he configur at ion, nodes on t he LAN br oadcast t heir hellos t o w ellk now n Lev el 1 and Lev el 2 br oadcast MAC addr esses.

•

Tw o-way com m unicat ion is confirm ed bet ween adj acent nodes by using a t hree -w ay handshake pr ocedur e m ade possible by t he pr esence of an I S Neighbor s field in t he LAN ( Lev el 1 or Lev el 2) hello pack et s. The r eliable point -t o-point adj acency form at ion int r oduced by TLV Ty pe 240 is sim ilar t o t his pr ocess.

Det ails of t he proce ss for form ing LAN adj acencies is discussed lat er in t his chapt er. For now , how ev er , t ak e a look at t he for m at of t he LAN hello pack et s, w hich is t he sam e for bot h Lev el 1 and Lev el 2.

60

Figur e 3 - 5 . I S- I S LAN H e llo ( PD U Ty pe s 1 5 , 1 6 ) .

The packet t ype –specific fields for I S-I S LAN hellos ar e as follow s:

•

Circuit Type— Tells w het her t his circuit is Level 1 -only, Level 2 -only , or bot h.

•

Source I D — The SysI D of t he or iginat or .

•

H olding Tim e — Tells how long t o w ait for hellos fr om t his r out er befor e declar ing it dead and rem oving it s adj acency.

•

PDU Lengt h— Lengt h of t he ent ir e PDU, fix ed header , and TLVs.

•

Priorit y — This 7 -bit v alue designat es t he pr ior it y to be t he DI S ( Level 1 or Level 2) on t he LAN.

61

•

LAN I D — Sy sI D of t he DI S plus an oct et -long unique I D for t his r out er assigned by t he DI S.

The differ ences bet w een LAN Level 1 and LAN Level 2 hellos is only in t he int er pr et at ion of t he values in t he fields an d t he br oadcast addr esses t o w hich t hey ar e t r ansm it t ed. The MAC-level br oadcast addr esses ar e as follow s:

•

0 1 -8 0 -C2 -0 0 -0 0 -15 for Level 2 adj acencies ( AllL2I Ss)

•

0 1 -8 0 -C2 -0 0 -0 0 -14 for Level 1 adj acencies ( AllL1I Ss)

The I S-I S PDU t y pes for LAN Lev el 1 and Level 2 pack et s ar e 15 and 16, r espect iv ely . 1

Exam ple 3 -

show s a sam ple t r ace capt ur e of a LAN Lev el 1 hello fr am e. The ex am ple display s a sour ce

addr ess of 0x 00D058F78941 and a dest inat ion or dest inat ion addr ess of 0x 0180C2000014. The t ar get addr ess is t he AllL1I S addr ess. Ex a m ple 3 - 1 Tra ce of I S- I S LAN Le v el 1 H e llo

DLC:

----DLC: DLC: hex) bytes. DLC: DLC: DLC: DLC: LLC: ----LLC: LLC: LLC: LLC:

DLC Header ----Frame 1 arrived at

19:03:01.2025; frame size is 1514 (05EA

Destination = Multicast 0180C2000014 Source = Station 00D058F78941 802.3 length = 1500 LLC Header ----DSAP Address = FE, DSAP IG Bit = 00 (Individual Address) SSAP Address = FE, SSAP CR Bit = 00 (Command) Unnumbered frame: UI

The follow ing TLVs fields can be found in LAN hello pack et s:

•

Ar e a Addr e sse s ( Type 1 ) — Cont ains ar ea addr esses configur ed on t he r out er

•

I S N e igh bor s ( Type 6 ) — MAC addresses ( SNPAs) of Level 1 ( Level 2) neighbors t hat I I Hs received from over t he LAN int erface in an init ializing or up st at e

•

Paddin g ( Ty pe 8 ) — Used t o m ake hello as lar ge as MTU ( or at least MTU - 1 oct et s)

•

Au t h e n t ica t ion ( Type 1 0 ) — Passw ord inform at ion

Forming LAN Adjacencies When a LAN int erface is enabled for I S-I S r out ing, t he r out er im m ediat ely sends out I I H pack et s w it h a locally defined LAN I D, consist ing of it s own SysI D and a unique local circuit I D. I t also begins t o list en t o ESHs, I SHs, and I I Hs t o discov er any connect ed adj acencies. I t subsequent ly runs t he DI S elect ion process, depending on it s configurat ion, t o det erm ine w het her it is eligible t o be a Lev el 1 or Lev el 2 DI S on t he LAN. The m anner in w hich a r out er pr ocesses r eceived I I Hs depends on it s configur at ion ( I S t ype and circuit t ype) . As in t he case of point -t o-point link s, all I I Hs r eceiv ed ar e check ed for

62

configurat ion conform it y and aut hent icat ion. The I D Lengt h and Maxim um Area Addresses fields in t he received I I Hs m ust m at ch local values, and aut hent icat ion passw ords m ust be confirm ed before t he adj acency is furt her processed. Exam ples of addit ional inform at ion cont ained in hello packet s are t he neighbor's SysI D, holding t im er ( holdt im e) , Level 1 or Level 2 pr ior it y , and configur ed ar ea addr esses. A Level 1 adj acency is for m ed w hen t he ar ea addr esses m at ch unless configur ed ot her w ise. A Level 2 adj acency is fo rm ed alongside t he Level 1 unless t he rout er is configured t o be Level 1 -only . I f no m at ching ar eas ex ist bet w een t he configur at ion of t he local r out er and t he ar ea addr esses infor m at ion in t he r eceived hello, only a Level 2 adj acency is for m ed. I f t he t ra nsm it t ing rout er is configured for Level 2 -only, t he r eceiving r out er m ust be capable of for m ing a Level 2 adj acency; ot her w ise, no adj acency for m s. When a rout er receives a hello packet , it checks for an exist ing adj acency w it h t he t ransm it t er. I f an adj a cency is know n, it r eset s t he holdt im e t o t he value in t he hello r eceived. I f t he neighbor is not know n, t he receiving rout er creat es one, indicat ing t he t ype of adj acency ( Level 1 or Level 2) and set s it s st at e t o init ializing unt il subsequent r eceived he llo pack et s confir m t w o-w ay com m unicat ion. Rout er s include t he MAC addr esses of all neighbor s on t he LAN t hat t hey have received hellos from , allow ing for a sim ple m echanism t o confirm t w o -w ay com m unicat ion. Two -w ay com m unicat ion is confir m ed w hen subseque nt hellos received cont ain t he receiving rout er's MAC address ( SNPA) in an I S Neighbors TLV field. Ot herw ise, com m unicat ion bet w een t he nodes is deem ed one -w ay , and t he adj acency st ay s at t he init ialized st at e. An adj acency m ust be in and up st at e for a r out er t o send or pr ocess r eceiv ed LSPs.

Pseudonodes As discussed in t he pr eceding sect ion, all I S-I S r out er s connect ed over a com m on LAN m ult icast hellos t o w ell-know n addr esses, t her eby for m ing adj acencies w it h each ot her . Aft er adj acency is det erm ined, lin k-st at e infor m at ion is ex changed ( also r efer r ed t o as LSP flooding) . LSP flooding is t he essence of dynam ic rout ing inform at ion exchange bet w een I S-I S r out er s. The t w o key r equir em ent s for LSP flooding ar e as follow s:

•

Accuracy of inform at ion and t im elines s of t he updat es

•

Minim um bandw idt h usage and low pr ocessing over head

Accuracy and t im eliness im ply spont aneous and frequent updat es. This cont radict s t he need t o conserve net w ork resources, as st ipulat ed by t he requirem ent for m inim um bandw idt h usage and low pr ocessing ov er head. This sect ion focuses on t he adj acency for m at ion pr ocess and net w or k r esour ce m anagem ent on m ult iaccess m edia. To m inim ize t he com plexit y of m anaging m ult iple adj acencies on m ult iaccess m edia, such as LANs, w hile enfor cing efficient LSP flooding t o m inim ize bandwidt h consum pt ion, I S-I S m odels m ult iaccess link s as nodes, r efer r ed t o as pseudonodes ( see Figure 3 - 6 ) . As t he nam e im plies, t his is a v ir t ual node, w hose r ole is play ed by an elect ed DI S for t he LAN. Separ at e DI Ss ar e

63

elect ed for Level 1 and Level 2 r out ing. I n t he elect ion pr o cess, only r out er s w it h adj acencies in an up st at e are considered. Elect ion of t he DI S is based on t he highest int erface priorit y, w it h t he highest SNPA addr ess ( MAC addr ess) br eaking t ies. The default int er face pr ior it y on Cisco r out er s is 64. Figur e 3 - 6 . LAN Pse udonode .

Despit e t he cr it ical r ole of t he DI S in LSP flooding, no backup DI S is elect ed for eit her Level 1 or Level 2. For t unat ely, t his doesn't t ur n out t o be a cont ent ious pr oblem because of t he frequency of periodic dat abase synchronizat ion t hat occurs on broadcast links. I f t he current DI S fails, anot her rout er is im m ediat ely elect ed t o play t he role. As m ent ioned previously, t he DI S t r ansm it s hello packet s t hree t im es fast er t han t he int erval for ot her rout ers on t he LAN. The default hello int er val for t he DI S is 3.3 seconds r at her t han t he 10 seconds specified for ot her nodes. This allow s for quick det ect ion of DI S failur e and im m ediat e r eplacem ent . As pr eviously expr essed, per iodic dat abase synchr onizat ion on br oadcast links allow s pr eem pt ion of t he exist ing DI S w it hout significant disr upt ion of I S-I S oper at ion on such m edia. This im plies t hat an elect ed rout er is not guarant eed t o rem ain t he DI S if a new r out er w it h a higher pr ior it y show s up on t he LAN. Any eligible r out er at t he t im e of connect ing t o t he LAN im m ediat ely t akes over t he DI S role, assum ing t he pseudonode funct ionalit y. No m echanism is specified for m aking a r out er ineligib le t o be t he DI S. How ever, t his is achievable, t o som e ext ent , by configuring a rout er's LAN int erface w it h t he low est priorit y value relat ive t o t he pr ior it ies of ot her nodes on t he LAN. The I S-I S specificat ion ( I SO 10589) defines t hree t ypes of designat e d int er m ediat e sy st em s, as follow s:

•

LAN Level 1 DI S

•

LAN Level 2 DI S

•

Par t it ion-designat ed Level 2 I S

Elect ion of par t it ion-designat ed Level 2 I Ss is specified in I SO 10589 t o pr ovide a m eans for r epair ing par t it ioned Lev el 1 ar eas in an I S-I S dom ain. An I S-I S v ir t ual link is est ablished ov er

64

t he Level 2 backbone bet w een par t it ion-designat ed Level 2 rout ers, which are elect ed from am ong t he Level 2 rout ers in t he part it ions. I nt ra -area t raffic is t hen forw arded bet w een t he part it ions over t he virt ual link. I S-I S par t it ion r epair is not suppor t ed on Cisco r out er s and, t her efor e, is not discussed fur t her in t his book . The r esponsibilit ies of LAN Lev el 1 and Lev el 2 DI Ss include t he follow ing:

•

Gener at ing pseudonode link-st at e pack et s t o r epor t link s t o all sy st ems on t he broadcast subnet work

•

Carrying out flooding over t he LAN for t he corresponding rout ing level

The new ly elect ed or r esigning DI S is also r esponsible for pur ging t he old pseudonode LSP fr om t he net w or k . A DI S m ight r esign w hen pr eem pt ed or w hen disconnect ed from t he link eit her by an int er face shut dow n or t he disabling of t he I S-I S process. Because of it s crit ical r ole, det ect ion of DI S failur e is expedit ed using a shor t er hello int er val, w hich is 3.3 seconds rat her t han t he 10 seconds used for ordina r y nodes.

The IS-IS Routing Engine Figure 3 - 7

show s the I S-I S r out ing engine, w hich is adapt ed fr om t he m or e elabor at e

r epr esent at ion of t he pr ocesses t hat w or k t oget her t o pr ov ide t he com plex of subnet w or k independent funct ions defined in I SO 10589. This sim plified r epr esent at ion show s only t he r elev ant dependencies bet w een various processes of t he I S-I S pr ot ocol w it hin t he fr am ew or k of a convent ional rout er's forw arding archit ect ure. The receiving and forw arding processes specified in I SO 10589 ar e not necessar ily applicable t o an I P r out er and ar e t her efore n ot discussed. I dent ical but separ at e r out ing engine ar chit ect ur e is m aint ained for each of t he t w o lev els of r out ing.

65

Figur e 3 - 7 . I S- I S r out ing e ngine .

I P rout ers using I nt egrat ed I S-I S as t he rout ing prot ocol conform t o requirem ent s for I P packet handling as specified by RFC 1812 ( Requirem ent s for I nt ernet Gat ew ays) . Such I P r out er s m ust handle t he I SO packet s r elevant t o t he oper at ion of I S-I S and also m ust suppor t ot her I P rout er funct ionalit y, such as I nt ernet Message Prot ocol ( I CMP) and Address Resolut ion Prot ocol ( ARP) .

The Routing Information Base The Rout ing I nfor m at ion Base is com posed of t w o dat abases t hat ar e cent r al t o t he ope rat ion of I S-I S: t he Link-St at e dat abase and t he For w ar ding dat abase. The Link-St at e dat abase is fed w it h r out ing infor m at ion by t he updat e pr ocess.

Th e Upda t e Pr oce ss The updat e process generat es local link-st at e inform at ion, based on t he adj acency dat aba se built by t he subnet w or k -dependent funct ions, w hich t he r out er adv er t ises t o all it s neighbor s in link-st at e packet s. A r out er also r eceives sim ilar link-st at e infor m at ion fr om ever y adj acent neighbor, keeps copies of LSPs received, and re -advert ises t he m t o ot her neighbors. Rout ers in an ar ea m aint ain ident ical Lev el 1 Link-St at e dat abases, w hich are synchronized using SNPs. This m eans t hat r out er s in an ar ea w ill hav e ident ical v iew s of t he ar ea t opology , w hich is necessar y for r out ing consist ency w it hin t he ar ea. A Lev el 2 Link-St at e dat abase cont ains ar ea pr efix infor m at ion t hat t ies all t he ar eas t oget her for int er-ar ea ( Lev el 2) r out ing.

Th e D e cision Pr oce ss

66

The decision pr ocess cr eat es t he For w ar ding dat abase by r unning t he shor t est pat h fir st ( SPF) algor it hm ( also r efer r ed t o as t he Dij kst r a algor it hm ) on t he Link-St at e dat abase. A r out er r uns separ at e SPF pr ocesses for Lev el 1 and Lev el 2.

Rou t in g Ta ble The I S-I S For w ar ding dat abase, w hich is m ade up of only best I S-I S rout es, is fed int o t he Rou t ing I nfor m at ion Base ( RI B) , essent ially t he I P r out ing t able of a r out er t o be used in pack et-sw it ching decisions. When m ult iple sour ces exist for r out ing infor m at ion in a r out er , such as st at ic r out es and BGP, a Cisco r out er uses t he concept of adm inist r at ive dist ances t o pr efer one r out ing sour ce t o t he ot her s. The pr ot ocol w it h t he low est adm inist r at ive dist ance wins. ( Table 3 - 3 list s adm inist rat ive dist ances for various rout ing prot ocols.) The accept ed best rout e is t hen inst alled in t he rout ing t able. Rout ing t able inform at ion m ight be processed fur t her int o t he fast -sw it ching cache or t he Cisco Expr ess For w ar ding ( CEF) For w ar ding I nform at ion Base ( FI B) t o speed up swit ching packet s t hrough t he rout er. Typically, I S -I S is used in conj unct ion wit h BGP for rout ing I P packet s. BGP brings in ext ernal rout e s, w her eas I S-I S, as an I GP, is r esponsible for int er nal r out es ( m ost ly nex t -hop inform at ion for t he BGP r out es) . Consequent ly, lit t le over lap occur s in r out ing infor m at ion obt ained fr om eit her sour ce, allow ing I S-I S and BGP r out es t o coexist in t he r out ing t able.

Table 3 - 3 . Adm inist r a t ive D ist a nce s of Rout ing Pr ot ocols

Rou t e Pr ot ocol RI P v1 and v2 I GRP EI GRP I nt ernal EI GRP Ext ernal OSPF I nt egrat ed I SI S BGP I nt ernal BGP Ext ernal St at ic t o Next Hop St at ic t o I nt erface Connect ed

Adm inist r a t ive D ist a nce 120 100 90 170 110 115 20 200 1 1 0

67

Addressing Concepts in Integrated IS-IS This sect ion is a shor t pr elude t o Chapt er 4 , "Addressing in I nt eg rat ed I S-I S," int roducing only t he key concept s for addr essing in t he I S-I S envir onm ent . As a prot ocol originally designed for rout ing CLNP packet s, I S-I S used t he node -based addr essing schem e of CLNP as it s basic addr essing pr em ise. I nt egr at ed I S-I S, w hich can be used for rout ing I P packet s, inherit s m any concept s from t he original specificat ion, including t he CLNS addressing schem e for ident ifying net w ork nodes. Therefore, it is a fundam ent al r equir em ent t hat ev en w hen I nt egr at ed I S-I S is used in an I P -on ly environm ent , t he nodes m ust have I SO NSAP addresses ( referred t o as NETs) . How ever, I P requires t he links t o be addr essed w it h I P subnet s. For t unat ely , t he for m at for CLNS addr esses used on I P r out er s is sim ple; m ost people can deal w it h t he t w o addr ess ing schem es and solv e t he single issue of r out ing I P. Chapter 4

r ev iew s CLNS addr essing and pr ov ides pr act ical ex am ples of how t hey ar e used on I P

r out ing. I P addr essing on t he links conform s t o basic I P addressing principles and has no r elat ionship w it h t he CLNS addr essing schem e. The lat t er exist s solely for use by t he I S-I S prot ocol. As I nt egrat ed I S-I S for I P r out ing is enabled on t he int er faces, t he I P subnet s ar e aut om at ica lly added t o t he rout er's LSP by using t he I P reachabilit y and relat ed TLVs int r oduced by RFC 1195. The I P pr efix es ar e t hen assem bled int o an I P Link-St at e dat abase, w hich is t he fed t o SPF algor it hm t o det er m ine t he best r out es.

Security I S-I S enfor ces basic securit y t hrough packet aut hent icat ion by using special TLVs. I SO 10589 specifies TLV Type 10, w hich can be pr esent in all I S-I S packet t ypes. RFC 1195 also specifies TLV Type 133 for aut hent icat ion, w hich rem oves passw ord lengt h rest rict ions im posed by I SO 10589. Bot h specificat ions define only sim ple passw or ds t r ansm it t ed as clear t ex t w it hout encr y pt ion. Sim ple, clear-t ex t passw or d aut hent icat ion obv iously does not pr ov ide enough pr ot ect ion against m alicious at t acks on t he net w or k, even t hough it can help isolat e oper at or configur at ion er r or s r elat ed t o adj acency set ups. TLV Types 10 and 133 bot h pr ovide accom m odat ion for fut ur e TLV field t ypes, w hich m ight per m it m or e com plex and secur ed aut hent icat ion using schem es such as HMAC-MD5. An I ETF draft p roposal specifies t his appr oach for im pr oved and sophist icat ed aut hent icat ion of I S-I S pack et s. Only t he sim ple passw or ds specified in I SO 10589 ar e suppor t ed in av ailable ( at t he t im e of w r it ing) Cisco I OS r eleases. A unique secur it y advant age of I S-I S co m pared t o ot her I P rout ing prot ocols is t hat I S-I S pack et s ar e dir ect ly encapsulat ed ov er t he dat a link and ar e not car r ied in I P pack et s or ev en CLNP packet s. Therefore, t o m aliciously disrupt t he I S-I S rout ing environm ent , an at t acker has

68

t o be physically at t ached t o a r out er in t he I S-I S net w or k, a challenging and inconvenient t ask for m ost net w or k hack er s. Ot her I P r out ing pr ot ocols, such as RI P, OSPF, and BGP, ar e suscept ible t o at t acks from rem ot e I P net works t hrough t he I nt ernet because rout ing prot o col packet s are ult im at ely em bedded in I P packet s, w hich m akes t hem suscept ible t o rem ot e access by int r usiv e applicat ions.

Summary This chapt er r eview s t he basic concept s under lying t he design of t he I S-I S rout ing prot ocol. The chapt er also discusses t he two -level hierarchy for cont rolling dist ribut ion of rout ing infor m at ion w it hin I S-I S ar eas and bet w een t hem : Level 1 and Level 2, r espect ively. You learned t hat t echnically all I S-I S r out er s belong t o one phy sical Lev el 1 ar ea because of t he n ode-based addressing schem e of CLNP. The relat ed issue of subopt im al int erarea rout ing r esult ing fr om t he ar chit ect ur e pr oposed in I SO 10589 and adopt ed by RFC 1195 is discussed in det ail in Chapt er 7 , " General Net work Design I ssues." Chapt er 7 also discusses w or kar ounds and I S-I S pr ot ocol enhancem ent s t hat addr ess t his m aj or lim it at ion of t he or iginal I S-I S pr ot ocol ar chit ect ur e. Ot her charact erist ics of t he I S-I S prot ocol discussed in t his chapt er include funct ional or ganizat ion int o subnet w or k -dependent and subnet w or k-independent capabilit ies, I S-I S packet for m at s, addr essing, and secur it y. Tied int o t he subnet wo rk-dependent capabilit ies ar e pr ocesses t hat r elat e t o adj acency discovery, form at ion, and m aint enance. On broadcast links, m anagem ent of t he pot ent ially com plex dat abase synchronizat ion process bet w een t he m any possible adj acent rout ers is achieved by t he elect ion of t he designat ed I S t o pr ovide t he pseudonode funct ionalit y. The sect ion on I S-I S packet for m at s elabor at ed on t he basic building blocks —nam ely , t he header and t he TLV fields. I t w as not ed t hat a key st r engt h of t he I S-I S prot ocol is t he sim plicit y by w hich it can be ex t ended t hr ough t he int r oduct ion of new TLVs w it hout m aj or changes t o t he pr ot ocol ar chit ect ur e. Per haps t he m ost confusing aspect of I S-I S is t he need t o deal w it h t w o addr essing schem es w hen using it for r out ing I P. Because I nt egrat ed I S-I S adapt s t he original I S-I S t o carry I P inform at ion, m ost of t he original archit ect ure ( including node addr essing) is por t ed. I nt egr at ed I S-I S suppor t s dual-m ode oper at ion, in w hich bot h I P and CLNP pack et s ar e r out ed essent ially by t he sam e I S-I S pr ocess. The next chapt er cover s CLNP addr essing and helps allev iat e som e of t he challenges in dealing w it h t his dichot om y . Like m ost pr ot ocols, secur it y is a concer n for I S-I S even t hough neit her I SO 10589 nor RFC 1195 specified any st r ong aut hent icat ion schem es for dealing w it h m alicious at t ack s w it hin an int er net w or king envir onm ent . The sim ple, clear-t ex t passw or ds specified pr ov ide a useful w ay t o cont rol net w ork m isconfigurat ion and t o im plem ent configurat ion policies. An I ETF dr aft specificat ion ( I S-I S HMAC-MD5 Aut hent icat ion) pr oposes m or e secur ed aut hent icat ion of I S-I S pack et s by using HMAC-MD5 aut hent icat ion schem es.

69

Review Questions

1:

How m any levels of hierarchy does t he I S- I S rout ing prot ocol support and what is t heir significance?

2:

What is t he reason for subopt im al int erarea rout ing in t he I SO 10589 archit ec ture?

3:

Nam e t he t wo cat egories of I S- I S prot ocol funct ions and describe t he services t hey provide.

4:

What is t he general layout of I S- I S packet form at s?

5:

List t he TLVs specified by I SO 10589.

6:

List t he TLVs specified by RFC 1195 and describe t heir significance.

7:

How does t he TLV Type 133 specified by RFC 1195 differ from t he original aut hent icat ion TLV Type 10 specified by I S0 10589?

8:

Describe any differences bet ween t he adj acency form at ion proc esses on point- to- point and broadcast links.

9:

Describe t he t hree- way adj acency form at ion process t hat has been proposed in t he I ETF t o enhance t he m et hod for fo rm ing adj acencies on point- t o- poin t lin k s.

10:

What is t he relevance of t he pseudonode funct ionalit y?

11:

Briefly describe t he DI S elect ion and replacem ent process.

12:

Explain w hy no backup DI S exist s.

N OTE

RFC dr aft s ar e cont inuously being updat ed, so t heir num ber suffixes m ight change — at one point , t hey m ight cease t o ex ist as dr aft s as t hey becom e RFCs.

References dr aft -iet f-isis -3 w ay-02.t xt : Three -w ay Handshake for I S-I S Point -to-Point Adj acencies dr aft -ieft -isis -h m ac-01.t x t : I S-I S HMAC-MD5 Aut hent icat ion I SO 9542, " End Syst em t o I nt er m ediat e Syst em Rout ing Exchange Pr ot ocol." For use in conj unct ion w it h I SO 8473. Also published as RFC 995. I SO/ 8473/ Add.3 Prot ocol for providing t he connect ionless -m ode net work service -Addendum 3: Pr ovision of t he under lying ser vice assum ed by t he I SO 8473 over subnet w or ks, w hich pr ovide t he OSI dat a link ser v ice.

70

Chapter 4. Addressing in Integrated IS-IS This chapt er focuses on net w or k addr essing concept s in I nt egr at ed I S-I S and at t em pt s t o d e myst ify t he seem ingly cum ber som e CLNP net w or k addr essing, w hich is m andat or y on I P r out er s, even w hen using I nt egr at ed I S-I S in I P-only environm ent s. As discussed in Chapt er 3 , " I nt egrat ed I S-I S Rout ing Pr ot ocol Concept s," I nt egr at ed I S-I S r et ains m ost of t he concept s of t he original I S-I S r out ing pr ot ocol, as specified in I SO 10589, and defines new TLVs ( RFC 1195) t hat enable support for I P rout ing. The CLNP node -based addressing schem e is one of t he key concept s ret ained in I nt egrat ed I S-I S. The node -based addr essing schem e r equir es only a single addr ess for t he ent ir e node. I n cont r ast how ev er , link-based addr essing applies m ult iple addr esses t o a node by assigning a unique address t o each connect ing link. These addresses are applied t o t he int erfaces w here net w ork links connect t o t he rout er. The I P addr essing schem e is link-based, as m ent ioned in Ch apt er 1 ," Overview of I P Rout ing." I n t his schem e, each link is assigned an I P subnet w ork num ber t hat defines t he corresponding int erface address. Consequent ly, an I P node can have m any I P addresses assigned t o it , depending on t he num ber of enabled int er faces. I n t he node -based schem e, I S-I S needs only a single addr ess per I S-I S node. Mult iple addr esses can be defined on an I S-I S r out er , but t hey ar e not t ied t o any specific link s. This can be done for special r easons discussed lat er in t his chapt er . Even w hen m ult iple CLNP addr esses ar e defined on an I S-I S rout er, t he sam e unique Syst em I dent ifier is ret ained in all t he addr esses. CNLP addr esses used in I S-I S are called net w ork service access point s ( NSAP) and are, t herefore, frequent ly referred t o as NSAP a ddresses. Recall from

Chapt er 2

,

" I nt r oduct ion t o t he I S-I S Rout ing Prot ocol," t hat in t he Open Syst em I nt erconnect ion ( OSI ) reference m odel, each layer provides special services t o t he next higher layer . The NSAP defines t he appr opr iat e ser vice int er faces, sim ilar t o t he pr ot ocol t ype used by I P r out er s for TCP an d UDP. An NSAP addr ess consist s of sever al com ponent s, including a unique Syst em I dent ifier t hat allow s it t o ident ify an ent ir e node in a Connect ionless Net w or k Pr ot ocol ( CLNP) net w or k. When using I nt egr at ed I S-I S for r out ing I P, bot h CLNP and I P addr esses ar e configur ed on t he r out er s. How ever , I P host s not par t icipat ing in t he dynam ic r out ing pr ocess don't need t o have NSAP addr esses. Fr equent ly , t he I P host s do not need t o r un a dy nam ic r out ing pr ot ocol and inst ead r ely on I P ser vices, such as ARP, DHCP, and st at ic default r out es t o com m unicat e w it h rout ers and ot her I P devices. Som e I P host s support dynam ic rout ing p r ot ocols, such as t he Rout ing I nfor m at ion Pr ot ocol ( RI P) or t he Open Shor t est Pat h Fir st ( OSPF) Pr ot ocol. I n a pur e I SO or dual net w or k , t he I SO host s ( end sy st em s) hav e NSAPs and r ely on t he ES-I S pr ot ocol t o com m unicat e w it h r out er s and ot her end sy st em s . To review t he int roduct ory I P m at erial, r efer t o Chapt er 1 . This chapt er int roduces and focuses on only I SO addressing concept s for CLNP. Lat er, insight s int o requirem ent s, ca v eat s, and suggest ed best pr act ices for defining and configuring NSAPs on Cisco rout ers for I nt egrat ed I S-I S r out ing ar e discussed. I SO t erm inology refers t o dat a link ( Layer 2) addresses ( LAN MAC addresses, Fram e Relay DLCI s, and so on) as subnet w or k point of at t achm ent s ( SNPAs) . Because a net w or k device m ight connect t o m ult iple links, it can have m ult iple SNPA addr esses but r equir es only one OSI net w or k addr ess. I SO pr ot ocols pr oviding net w or k layer ser vices can int er pr et bot h NSAP and

71

SNPA addresses. As discussed pr ev iously , a pr im ar y funct ion of t he ES-I S prot ocol is t o provide NSAP-to-SNPA m apping for net w or k devices.

Figure 4 - 1

illust rat es t he applicat ion of

SNPAs and NSAPs t o v ar ious nodes in an I S-I S net w ork. Figur e 4 - 1 . Applica t ion of I SO N SAP a nd SN PAs.

The NSAP addr essing schem e, w hich is a m aj or dependency for I S-I S oper at ion, is specified in I SO 8348/ AD2. This specificat ion is also available as RFC 941 from t he I ETF ( www.iet f.org ) . The parent docum ent , I SO 8348, defines t he I SO net w ork layer service requirem ent s for connect ion-orient ed services. I SO 8348/ AD1 provides addit ional specificat ion for connect ionless -m ode t ransm ission, whereas I S0 8348/ AD2 dea ls w it h net w or k layer addr essing. Subsequent sect ions of t his chapt er explain t he for m at of NSAP addr esses and how t hey ar e configur ed on Cisco r out er s t o suppor t I S-I S rout ing. Hopefully, if you feel m ore com for t able w it h I P addr essing, y ou w ill ov er com e any int im idat ion t hat CLNP addr essing poses and appreciat e it s inherent sim plicit y, especially for I S-I S r out ing applicat ions in I P env ir onm ent s.

OSI Network Addresses I n t he OSI archit ect ure, t he net w ork layer provides services t o a user in t he layer above, su ch as t he t ransport service elem ent . I f you designat e t he net w ork layer by N, t he net w ork user is t he N+ 1 ser v ice elem ent ( see Figure 4 - 2 ) . An N+ 1 ent it y in Rout er A t hat w ant s t o com m unicat e w it h an N+ 1 peer in Rout er B m ust pr ov ide t he peer 's N ser v ice access point ( NSAP) as t he dest inat ion of t he serv ice r equest w hile pr ov iding it s ow n NSAP as t he sour ce t o facilit at e bidir ect ional com m unicat ion. I n a r out er , t he N+ 1 ent it y or t he N ser vice user is eit her a t r anspor t layer ent it y or t he r out ing layer .

72

Figur e 4 - 2 . Pe e r- to- pe e r la ye r com m unica t ions.

The NSAP addr ess for m at has a com ponent k now n as t he NSAP select or (NSEL) for ident ify ing t he t arget net work service user. The NSEL is furt her discus sed lat er in t his sect ion. Ot her com ponent s of t he NSAP ar e t he Syst em I dent ifier ( SysI D) and t he Area I dent ifier (Area I D) . The SysI D uniquely ident ifies a net w or k node, w her eas t he Ar ea I D specifies t he hom e ar ea of t he node. I S-I S r equir es all sy st em s to be associat ed w it h at least one ar ea in t he net w or k dom ain. I n sum m ar y, an NSAP addr ess consist s of t he follow ing t hr ee par t s: t he Ar ea I D, SysI D, and NSEL. When t he r out ing layer is specified as t he net w or k ser vice user , t he value of t he NSEL is set t o zer o, and t he NSAP is called t he net work ent it y t it le ( NET) . I n a pu r e I SO CLNS envir onm ent , or dinar y dat a packet s have sour ce and dest inat ion NSAPs w it h non-zero NSEL v alues. Such pack et s ar e obv iously not m eant for t he r out ing lay er and m ight be dir ect ed at som e t r anspor t ser vices elem ent in t he r out er or possibly j ust t r aver sing t he rout er. On t he ot her hand, in I P-only environm ent s, such as t he I nt ernet , t here are no CLNP applicat ions, so t he r out ing layer is t he only user of CLNP net w or k ser vices. I n t his case, t he only I SO pack et s in oper at ion ar e ES-I S and I S-I S r out ing infor m at ion and cont r ol packet s. The follow ing m at erial focuses only on t he I SO CLNS archit ect ure. Refer t o Chapt er 1 for addit ional infor m at ion on I P addr essing.

NSAP Format NSAP addr esses ar e not fix ed in lengt h and can be up t o 160 bit s ( 20 by t es) long com par ed t o t he fixed 32 bit s ( 4 byt es) of I P addr esses. I SO 8348/ AD2 specifies a hier ar chical schem e for defining global and public NSAP addresses. The follow ing are t he seven t op -level addressing dom ains:

•

X .1 2 1 — I nt ernat ional plan for public dat a net works

•

I SO D CC— Dat a Count ry Code

•

F.6 9 — Telex

•

E.1 6 3 — Public Swit ched Telephone Net work

73

•

E.1 6 4 — I SDN

•

I SO 6 5 2 3 — Int ernat ional Code Designat or ( I CD) for organizat ions

•

Loca l— For local use only w it hin net w ork dom ain

Ev en t hough for m at det ails differ for each t op-level dom ain, all NSAP addresses conform t o t he gener ic for m at show n in Figure 4 - 3 . Figur e 4 - 3 . N SAP a ddr e ss for m a t .

The NSAP form at shows t wo m ain com ponent s: t he init ial dom ain part ( I DP) and t he dom ain specific par t ( DSP) . The I DP is fur t her br oken dow n int o t he aut hor it y and for m at ident ifier ( AFI ) and t he init ial dom ain ident ifier ( I DI ) . The DSP consist s of t he high or der DSP, I D, and SEL fields. The I D field is for t he SysI D of t he node and t he SEL r epr esent s t he NSAP select or ( NSEL) . Bot h t he Sy sI D and NSEL w er e discussed in t he pr eceding sect ion. Th e det ails of t he nam ing and funct ions of all var ious fields in t he NSAP ar e not discussed her e because t hey ar e ir r elevant t o t he subj ect m at t er of t his book. How ever , t he AFI and I DI fields ar e of gr eat int er est , so t hey ar e discussed in det ail her e. The AFI indicat es t he t op -level addr essing dom ain associat ed w it h t he NSAP and t he synt ax of t he DSP sect ion. Possible values of t he AFI r ange fr om 0 t o 99 decim al values. The t op -level addr ess dom ains sponsor v ar ious subdom ains, w hich ar e assigned a v alue in t he I DI field. Each t op -level dom ain specifies it s ow n for m at for t he I DI field. For ex am ple, t he I SO 6523 I CD addr ess dom ain has a f ou r-digit for m at , w her eas t he I SO DCC uses a t hr ee-digit form at for t he dat a count ry code. Ex am ples of I DI v alues for I SO 6523 I CD subdom ains used by t he Unit ed St at es gover nm ent f ollow :

•

U.S. gove r n m e n t civilia n or ga n iza t ion s— 0 0 0 5

74

•

U.S. D e pa r t m e n t of D e fe n se — 0 0 0 6

The I DI value of 0005 refers t o U.S. governm ent civilian organizat ions t hat conform t o t he U.S. gov er nm ent st andar d know n as Governm ent Open Syst em I nt erconnect ion Profile ( GOSI P) . As said befor e, t he value of t he AFI also det er m ines t he synt ax of t he DSP. The DSP synt ax can be in binar y oct et s, decim al digit s, or even char act er s. Table 4 - 1

show s t he AFI values for var ious t op-lev el addr ess dom ains and DSP sy nt ax t y pes. For

exam ple, AFI 47 r efer s t o t he I SO 6523 I CD addr essing dom ain and indicat es a binar y synt ax for t he DSP. Sim ilar ly , AFI 39 r efer s t o t he I SO DCC addr essing dom ain and binar y sy nt ax for t he DSP.

Table 4 - 1 . AFI Va lu e s for Addr e ss D om a in s a n d D SP Syn t a x Type s

Addr e ss D om a in X.121 I SO DCC F.69 E.163 E.164 I SO 6523 I CD Local Exam ple 4 - 1

D SP Synt a x D e cim a l 36 38 40 42 44 46 48

Bina ry 37 39 41 43 45 47 49

Ch a r a ct e r

50

show s an I SO 6523 addr ess t hat confor m s t o t he GOSI P st andar d.

Ex a m ple 4 - 1 A Com ple t e I S0 6 5 2 3 N SAP

47.0005.80123456000089AB001.AABBCCDDEEFF.00 ^ ^ ^ ^ AFI IDI AREA NSEL

^ SYSID

show s a com plet e 20-byt e NSAP w it h key fields in t he layout delineat ed by grou ping r elat ed char act er s. The follow ing five m aj or fields can be easily discer ned:

Exam ple 4 - 1

•

AFI ( 4 7 ) — Address dom ain indicat ing binary DSP synt ax

•

I D I ( 0 0 0 5 ) — GOSI P I DI

•

Ar e a ( 8 0 1 2 3 4 5 6 0 0 0 0 8 9 AB0 0 0 1 ) — Area inform at ion w it h hierarchy det ails

• •

SysI D — 6 -byt e Syst em I dent ifie r N SEL— NSAP select or specify ing r out ing lay er as net w or k ser v ice user

75

Simplified NSAP Format As show n in Figure 4 - 4 , t he various fields in t he NSAP form at can be grouped int o t hree m ain sect ions: Area I D, Syst em I D, and NSEL. This int erpret at ion of t he NSAP form at reduces it s seem ing com plexit y. The result ing st r uct ur e is r efer r ed t o as t he sim plified NSAP for m at . Fut ur e discussions of t he NSAP in t his chapt er ar e based on t he sim plified NSAP for m at . Figur e 4 - 4 . Sim plifie d N SAP for m a t .

The Ar ea I D field consist s of t he AFI ( fir st byt e) and all subsequent fields up t o t he beginning of t he Syst em I D sect ion. The Area I D field has variable lengt h. The lengt h of t he Syst em I D field is specified t o be 1 t o 8 by t es. The NSEL is t he last by t e. The m ax im um size of t he NSAP addr ess in t he sim plified for m at r em ains 20 by t es. N OTE

Most current im plem ent at ions of I S-I S, including t he Cisco im plem ent at ion, have adopt ed a fix ed-size, 6 -byt e Syst em I D lengt h in com pliance w it h t he U.S. GOSI P v er sion 2.0 st andar d.

Considering t he GOSI P-specified 6 -byt e lengt h of t he Syst em I D field and t he 1 -by t e NSEL field, t he Ar ea I D m ay t her efor e var y bet w een 1 and 13 byt es. Because only 1 byt e is sufficient t o define t he Area I D, t he sm allest lengt h of an NSAP on a Cisco r out er is 8 by t es. For I P applicat ions, it is sufficient t o define NSAPs as sim ple as possible by allocat ing 1 by t e for t he AFI , at least 2 byt es for t he act ual ar ea infor m at ion, 6 byt es for t he Syst em I D, and 1 b yt e for t he NSEL for a t ot al m inim um of 10 byt es.

Exa mple 4 - 2

sh ow s a 1 0 -by t e NSAP, based on

t his recom m endat ion. NSAPs are configured in hexadecim al form at from t he I OS com m and line int erface ( CLI ) w it h t he leading AFI byt e ( decim al value) and t railing NSEL byt e ( 00) delineat ed by dot s ( per iods) . The r em ainder of t he addr ess bet w een t he AFI and NSEL is br ok en dow n int o 4 -digit ( 2 byt es in Hex) gr oups and separ at ed by dot s. I n com par ison, I P addr essing uses a differ ent for m at , called dot t ed-decim al r epr esent at ion. See Chapt er 1 for a r ev iew on I P addr essing.

76

Ex a m ple 4 - 2 Sim ple N SAP Addr e ss

49.0001.0000.0000.0001.00 ^ ^ Area ID SysID

^ NSEL

When using I S-I S for I P r out ing, y ou can follow t he sim plified NSAP for m at t o cr eat e a sim ple Ar ea I D w it hout r egar d for ot her det ails, such as I DI , dom ain, and det ails of t he ar ea infor m at ion. I n t he pr eceding exam ple, an AFI value of 49 is pr efixed t o t he int ended ar ea infor m at ion ( 0001) t o form t he Area I D ( 49.0001) . Recall from

Tabl e 4 - 1

t hat t he AFI v alue of 49

is designat ed for local pr iv at e use sim ilar t o t he r eser v ed pr iv at e addr ess space specified in RFC 1618. The next char act er s aft er t he AFI ar e in hexadecim al for m at ; t he fir st 12 digit s represent t he 6 -by t e Sy sI D and t he last 2 digit s r epr esent t he NSEL byt e. Alt hough 10 -byte -long NSAPs ar e sufficient for I P r out ing pur poses, m ost ser vice pr ovider s using I S-I S st ill configure 20 -byte -long addr esses on t heir r out er s w het her t hey use conj ect ured addresses ( wit h AFI 49) or addre sses fr om t he public space ( obt ained fr om one of t he t op -level addressing dom ains) . For rout ing on t he I nt ernet , I S-I S ( and cer t ainly any ot her I GP such as OSPF) is confined t o t he local dom ain ( or aut onom ous syst em ) . The Border Gat eway Prot ocol ( BGP) is u sed inst ead for sharing rout ing inform at ion bet ween aut onom ous syst em s. I n pract ice, t he NSAPs configured on I P rout ers for I S-I S r out ing do not need t o be globally unique or ev en 20 by t es long. This is ex plained fur t her in t he nex t sect ion.

Obtaining Globally Unique NSAP Addresses The I nt er net is com posed of m any separ at e I P net w or k dom ains, w hich collabor at e by shar ing rout ing inform at ion t o form t he I nt ernet 's gigant ic m ult inat ional and int ercont inent al fram ework. Each const it uent net work of t he I nt ernet is considered an independent rout ing dom ain or an aut onom ous syst em ( AS) . BGP has st ood t he t est of t im e t o em er ge as t he only viable pr ot ocol for exchanging r out ing inform at ion bet w een t he m any ASs t hat form t he I nt ernet . I n t he early days of t he I nt erne t , an alt er nat iv e r out ing pr ot ocol based on CLNP called I nt erdom ain Rout ing Prot ocol ( I DRP) w as pr oposed, but it w as not w idely adopt ed because of t he ubiquit y of I P and it s dom inance ov er CLNP. BGP provides flexible rout ing policies for cont rolling rout in g infor m at ion w it hin an AS, as w ell as out bound and inbound rout ing inform at ion. I S-I S belongs t o t he class of r out ing pr ot ocols called I nt erior Gat eway Prot ocols ( I GPs) , w hich w or k alongside BGP and pr ov ide support ive roles for rout ing in an AS. Typically, all t he aut onom ous sy st em s on t he I nt er net r un BGP and an I GP ( I S-I S or OSPF) . How ever , all t he inst ances of I GPs r unning in t he different net w ork dom ains t hat const it ut e t he I nt ernet are isolat ed from each ot her. Only BGP is used for ex changing r out ing inform at ion bet w een ASs. Therefore, a service provider can fr eely choose any t y pe of I GP t o use w it hin it s AS. When I S-I S is used as an I GP, t he r equir ed NSAPs can be based on t he sim plified for m at because t hey do not need t o be globally unique — j ust as pr ivat e I P addresses can be defined on t he int ernal links in an AS w it hout any significant ext er nal im plicat ions except br eaking Tr acer out es and Pings t o and fr om r em ot e net w or ks. Globally unique NSAP addr esses do m ake sense, how ever , for int er connect ed t elecom m unicat ions syst em s, such as ATM swit ches, SONET/ SDH Add Drop Mult iplexers

77

( ADM) , and any devices t hat use CLNP-based applicat ions for global connect ivit y. Besides OSPF, I S-I S is one of t he m ost w idely deployed I GPs in I SP net w or ks. Ther e ar e m any r easons for t his: hist orical reasons based on specific pract ical experience, t roubleshoot ing sim plicit y, perceived robust ness and fast convergence, or m ere subj ect ive convenience. As indicat ed, ev en t hough globally unique NSAP addr esses ar e not r equir ed t o r un I S-I S in an I nt ernet AS for t he cur r ent applicat ion, m ost ser vice pr ovider s have deployed 20-byt e globally unique addr esses.

ISO NSAP Addressing Authorities An address regist rat ion aut horit y oversees address assignm ent s for each of t he t op -lev el addressing dom ains. For ex am ple, I SO 6523 specifies r ules for allocat ion of I CD addr esses ( AFI 47) by an I nt ernat ional Regist rat ion Aut horit y ( RA) . Applicat ions for addresses are processed t hrough a sponsoring aut horit y, such as a count ry's nat ional st andards body. The RA does not pr ocess any dir ect applicat ions fr om or ganizat ions. As indicat ed in t he pr evious sect ion, I DI 0005 and 0006 are allocat ed t o t he U.S. Nat ional I nst it ut e of St andards ( NI ST) and subsequent ly reallocat ed t o inst it ut ions and organizat ions of t h e U.S. feder al gov er nm ent . The Brit ish St andards I nst it ut e ( BSI ) , w hich is t he nat ional st andards body of t he Unit ed Kingdom ( UK) , act s as t he UK sponsor for I CD addresses. BSI also runs an independent I CD addr ess allocat ion schem e t hr ough a business dev elopm ent group. The schem e called I dent ifiers for Organizat ions for Telecom m unicat ions Addressing (I OTA) w as m ot iv at ed by dem and for Asynchronous Transfer Mode (ATM) End Syst em Addresses ( AESA) for use on ATM sw it ches in coor dinat ion w it h t he ATM for um . The I OTA schem e w as int r oduced w it h a br oader obj ect ive t o provide I CD form at ident ifiers for organizat ions, in any part of t he w orld, and t o supply globally unique addresses and ident ifiers for any kind of applicat ion. The I OTA I DI v alue is 0124 and goes w it h an AFI pr efix of 47 at t he beginning of t he AESA. An ex am ple of an I OTA-based NSAP addr ess is show n in Exam ple 4 - 3 . The reader is referred t o t he I OTA sit e list ed in t he " References " sect ion for m ore inform at ion . Ex a m ple 4 - 3 I OTA- Ba sed N SAP Address

47. 0124. xxxxxx. yyyyyyyyyyyyyy . -- ---- ------ -------------^ ^ ^ ^ | | | | AFI IDI OrgID Org. Assigned

AABBCCDDEEFF .00 ------------ -^ ^ | | SysID NSEL

As show n in Exam ple 4 - 3 , t he first t hree left m ost byt es of an I OTA-based NSAP are t he I OTA or ganizat ion I D ( 47.0124) . The act ual synt ax of t he DSP is binar y, but it is r epr esent ed in hexadecim al. Count ing fr om left , oct et s 4 t hr ough 6 ( Or g I D) r epr esent t he or ganizat ion ident ifier assigned by t he I OTA RA. Oct et s 7 –13 ar e adm inist er ed and assigned locally by t he or ganizat ion. The last seven oct et s m ake up t he SysI D and NSEL fields. The I SO DCC NSAP addr essing hier ar chy is as popular as t he I SO 6523 I CD scheme an d h as been adopt ed by num erous organizat ions, prim arily for addressing t elecom m unicat ion sy st em s, dev ices, and r elat ed obj ect s. I SO DCC is specified in I SO 3166 and uses 39 as AFI . Just as in t he case of I SO 6523 I CD NSAP addr esses, adm inist r at ion of t he DCC addr ess space

78

is coordinat ed t hrough nat ional organizat ions. I n t he Unit ed St at es, for exam ple, t he Am erican Nat ional St andards I nst it ut e ( ANSI ) is t he RA. The address allocat ion procedure is specified in ANSI X3.216 in conform ance w it h I TU X.660/ I SO/ I EC 9834-1, w hich descr ibes a hier ar chy of RAs. The I DI assigned t o ANSI is 840, w hich is pr efix ed w it h AFI 39 and specifies binar y encoding of t he DSP in accor dance w it h I SO 8348/ AD2. The AFI and I DI ar e decim als but encoded in binary-coded decim al ( BCD) for m at w it h oct et boundar ies at 8 bit s. Not e t he leading zer o fill in t he I DI field in Exam ple 4 - 4 . Refer t o t he ANSI Web sit e in t he " References " sect ion for addit ional inform at ion. Ex a m ple 4 - 4 An AN SI I CD N SAP Addr e ss

39 0840 xxxxxx yyyyyyyyyyyyyy AABBCCDDEEFF 00 -- ---- ------ -------------- ------------ -^ ^ ^ ^ ^ ^ | | | | | | AFI IDI OrgID Org. Assigned SysID NSEL Cur r ent ly, t he Cisco I OS CLI does not pr ov ide for m at t ing help dur ing ent r y of t he NSAP in a rout er configurat ion. Know ledge of field boundaries in t he NSAP addressing archit ect ure by net w or k oper at or s is, t her efor e, cr it ical for configur ing NSAPs and enabling I S-I S on Cisco r out er s.

Defining the System ID By now , it is clear t hat t he Sy sI D is one of t hr ee k ey com ponent s of an NSAP addr ess, w hich is r equir ed t o enable I S-I S r out ing on a r out er . The ot her com ponent s ar e t he Ar ea I D and t he NSEL. Accor ding t o I SO 10589, t he SysI D can be of var iable lengt h bet w een 1 t o 8 byt es. How ever, Cisco's im plem ent at ion of I S-I S uses a fix ed 6 -byt e lengt h in confor m ance w it h t he GOSI P 2.0 st andard. I t is probably not by coincidence t hat t he 6 -by t e lengt h specified by GOSI P 2.0 m at ches t he lengt h of a LAN MAC addr ess. Ther efor e, you can use one of t he LAN MAC addr esses on a r out er as it s SysI D, essent ially em bedding a MAC addr ess ( a Layer 2 addr ess) in t he NSAP, w hich is a Lay er 3 addr ess. Of cour se, on an I P r out er w it h m any LAN int erfaces, y ou need t o decide w hich MAC addr ess t o use as t he Sy sI D. How ev er , t he Sy sI D doesn't hav e t o be a MAC addr ess. Alt hough an I P addr ess has no v isual r elat ionship w it h t he dat a -link address, except indirect ly t hr ough m apping by t he Addr ess Resolut ion Pr otocol ( ARP) , a link bet w een t he NSAP and t he dat a -link address ( SNPA) can be easily est ablished for single -point -at t ached CLNS host s by using t heir MAC addr esses at t he point of at t achm ent as t he Sy sI D. Because a r out er m ight have m any act ive LAN int erfaces , direct one -t o-one LAN address -t o-NSAP m apping m ight not alw ays be possible. Net w or k oper at or s can follow any convenient m et hod t o define SysI Ds for t heir r out er s w hile confor m ing t o t he r equir em ent s and caveat s list ed in t he follow ing sect ion.

Requirements and Caveats The follow ing is a list of r equir em ent s and caveat s t hat m ust be follow ed t o define NSAP for I S-I S r out ing in gener al and in par t icular on Cisco r out er s:

79

•

Each node in an I S-I S r out ing ar ea m ust hav e a unique Sy sI D.

•

The Sy sI D of all nodes in an I S-I S r out ing dom ain m ust be of t he sam e lengt h. The lengt h of t he SysI D is 6 byt es ( fixed) on Cisco r out er s. All r out er s connect ing t o t he Level 2 backbone m ust have unique SysI Ds r elat ive t o each ot her . N OTE

Sy sI Ds ar e r equir ed t o be unique only w it hin a specific ar ea; t her efor e, a r out er in one ar ea can pot ent ially shar e t he sam e Sy sI D w it h a r out er in anot her ar ea w it hout any conflict unless t hey are bot h connect ed t o t he backbone for Level 2 rout ing. I n pract ice, how ever, m ost service providers keep SysI Ds unique for each rout er in t he ent ir e dom ain r egar dless of w het her t he net w or k is a single -ar ea dom ain or has m ult iple ar eas.

In

Chapt er 5, " The I S- I S Link- St at e Dat abase,"

t he I S-I S Link-St at e dat abase is discussed and it is not ed

t hat t he ident ifier s for link-st at e packet s ar e t ied t o t he SysI Ds of t he or iginat ing r out er s. This explains t he need for unique SysI Ds for nodes in t he sam e ar ea ( Level 1) or t he backbone ( Level 2) . One popular w ay t o define unique Sy sI Ds is by padding a dot t ed -decim al loopback I P address w it h zer os t o t r ansfor m it int o a 12-digit address, w hich can t hen be easily rearranged t o r epr esent a 6 -byt e SysI D in hexadecim al, by regrouping t he digit s in four s and separ at ing t hem w it h dot s.

Exam ple 4 - 5

show s an ex cer pt fr om t he configur at ion on a Cisco r out er .

Typically, r out er s ar e configur ed w it h loopback addr esses for ot her pur poses, such as BGP rout ing or net work m anagem ent .

Exam ple 4 - 5

elaborat es t he procedure for defining an NSAP

based on t he loopback addr ess. Ex a m ple 4 - 5 Ex a m ple of Syst e m I D

Interface Loopback 0 IP address 192.168.1.24

Router isis Net 49.0001.1921.6800.1024.00 In

Exam ple 4 - 5 ,

t he loopback addr ess is t r ansfor m ed as follow s:

St e p 1 . Each oct et in t he dot t ed -decim al not at ion of t he loopback I P addr ess t hat is not t hr ee digit s is pr efixed w it h zer os, padding it t o t hr ee digit s, as fo llow s: 192.168.1.24 ---> 192.168.001.024 St e p 2 . Aft er St ep 1, you have 12 digit s, w hich you can easily r ear r ange int o t hr ee gr oups of 4 digit s, as follow s:

80

192.168.001.024 ---> 1921.6800.1024 St e p 3 . 1921.6800.1024 can t hen be used as t he unique Sy sI D of t he r out er . The ar ea pr efix and NSEL suffix ar e added t o obt ain t he com plet e NSAP addr ess, as show n in

Exam ple 4 - 6 .

Ex a m ple 4 - 6 Obt a ining t he Com ple t e N SAP Addr e ss 1921.6800.1024 ---> 49.0001.1921.6800.1024.00 ------- -------------- -^ ^ ^ | | | AreaID SysID NSEL This m et hod of defining t he NSAP or NET is fr equent ly used by I nt er net ser vice pr ovider s t hat r un t he I S-I S pr ot ocol as I GP. Ev en t hough t his m ight not be t he only int uit iv e w ay , t he m et hod offer s oper at ional convenience by associat ing m ult iple applicat ions t o a single loopback addr ess on t he r out er . A single loopback addr ess can be used as t he BGP r out er I D, t he basis for t he I S-I S SysI D, t he MPLS/ TE rout er I D, and for net w ork m anagem ent applicat ions. OSPF also uses a loopba ck addr ess on a r out er , w hen available, as t he r out er I D; in t ypical sit uat ions, how ever, OSPF and I S-I S ar e not used t oget her as I GPs in t he sam e net w or k, even t hough t hat is possible for m er ging t w o or iginally separ at e net w or ks or dur ing a r out ing pr ot ocol m igr at ion fr om one t o t he ot her . Because t he Ar ea I D and t he NSEL ar e t he sam e for all nodes in t he sam e ar ea, it 's t he unique SysI D t hat pr ovides uniqueness t o t he NET of a rout er. An I S-I S r out er m ust hav e at least one NSAP configur ed, and t he Sy sI D m u st be unique for t he ar ea in w hich it belongs. How ev er , I SO 10589 allow s up t o t hr ee NSAP addresses per node —all of w hich m ust have t he sam e unique SysI D of t he node, differ ent iat ed only by t he ar ea pr efix . The concept of hav ing m ult iple NSAP addr esses on t he sam e r out er is called m ult ihom ing in I S-I S. Mult ihom ing is addressed furt her in t he next sect ion. I t is im port ant t o underst and t hat m ult ihom ing does not allow a rout er t o be connect ed t o m ult iple separ at e ar eas. I nst ead, configur ing m ult iple NSAPs w it h different area prefixes on a rout er m er ges t he differ ent ar eas, and t he r out er cont inues t o belong t o a single, but unified, ar ea.

Configuring Multiple NETs for a Single IS-IS Process Unt il r ecent ly , only a single I S-I S r out ing pr ocess could be enabled on a Cisco r out er . Ev en t hough only a single NET is r equir ed for an I S-I S process, m ult iple NETs can be configured for t he sam e process by defining m ult iple NSAPs different iat ed only by t he Area I Ds. This allow s t he rout er t o m ult ihom e t o t he m ult iple areas defined, effect iv ely m er ging t he ar eas int o a single area. During norm al operat ion, for exam ple, a Level 1 I S-I S r out er par t icipat es in flooding Level 1 LSPs t hroughout it s hom e area. I f t his rout er connect s t o m ult iple areas, it also ext ends t he floodin g of Level 1 LSPs bet w een t hose areas, effect ively m erging t hem . An exam ple of a m ult ihom ed configur at ion is show n in Exam ple 4 - 7 . In

Exam ple 4 - 7 ,

49.0001 and 49.0002 ar e t he t w o ar eas t o w hich t his r out er is dual-hom ed.

Not ice t hat it k eeps t he sam e sy st em in bot h NSAP addr esses. The NSEL is all zer os in bot h addresses. Configuring t he t w o addresses allow s t he r out er t o m er ge ar eas 49.0001 and

81

49.0002 by passing t he Level 1 LSPs from each area int o t he ot her. This is furt her illust rat ed in

Figure 4 - 5 .

Ex a m ple 4 - 7 I S- I S M ult ihom ing Configur a t ion

RTA# Interface Loopback 0 Ip address 192.168.1.24

Router isis Net 49.0001.1921.6800.1024.00 Net 49.0002.1921.6800.1024.00 Figur e 4 - 5 . M ult ihom ing in I S- I S.

As show n in

Figure 4 - 5 ,

RTA is in Area 49.0001 and RTB is in Area 49.0002. Because t hey are in

differ ent ar eas, t hey for m Lev el 2 adj acencies w it h each ot her w hile m aint aining Level 1 adj acencies w it h dev ices in t heir local ar eas. I f RTA is configur ed w it h a second NET ( 49.0002.1921.6800.1024.00) ( see Exam ple 4 - 7 ) , t he t wo rout ers t hen form a Level 1 adj acency based on t he com m on ar ea pr efix ( 49.0002) . RTA cont inues t o m aint ain it s Level 1 adj acencies w it h devices in 49.0001, and RTB does t he sam e w it h devices in 49.0002. Because of t he new ly for m ed Lev el 1 adj acency bet w een RTA and RTB, how ev er , t he dev ices begin t o exchange all t heir or iginally separ at e Level 1 dat abases, w hich ar e t hen flooded t o t he ot her Lev el 1 neighbor s. This effect iv ely m er ges t he t w o ar eas.

82

Under nor m al cir cum st ances, oper at or s need t o configur e r out er s w it h only one ar ea pr efix . Mult ihom ing is useful for t he follow ing purposes, w hich are furt her elaborat ed in subsequent sect ions:

•

Mer ging areas

• •

Split t ing areas Renum ber ing

Mult ihom ing allow s net w or k oper at or s t o per for m any of t hese t hr ee act iv it ies w it hout a m aj or " flag" day ( w hich w ould r equir e t he ent ir e or a m aj or par t of t he net w or k t o go out of ser v ice) . A r ecent enhancem ent in Cisco I OS Soft w ar e, r efer r ed t o as I S-I S m ult i-ar ea, enables an I S-I S r out er t o act as an ar ea bor der r out er , int er connect ing m ult iple isolat ed ar eas t o t he Level 2 backbone. The essent ial difference bet w een m ult i-ar ea suppor t in I S-I S and I S-I S m ult ihom ing is t hat t he I S-I S m ult i-area feat ure is designed t o support m ult iple, independent Level 1 areas on t he sam e r out er by using m ult iple I S-I S processes, w hereas m ult ihom ing m erges m ult iple ar eas under a single I S-I S pr ocess. I n bot h cases, each ar ea is r epr esent ed by an NSAP t hat differ s fr om t he ot her s by only t he Ar ea I D. I n t he m ult i-ar ea configur at ion, how ev er , each pr ocess get s it s ow n NSAP, w her eas t he NSAPs ar e gr ouped under t he sam e pr ocess in m ult ihom ing configurat ions. Addit ional inform at ion on m ult i-a r ea suppor t is available in Chapt er 9,

" Configuring I S-I S for I P Rout ing on Cisco Rout ers."

Merging Areas The pr ocess of m er ging ar eas w it h I S-I S m ult ihom ing is illust rat ed in Figure 4 - 5 , w her e y ou st ar t w it h t w o dist inct ar eas: 49.0001 and 49.0002 ( wit h RTA in 49.0001) . By m ult ihom ing RTA, y ou end up w it h a unified ar ea and a m er ged Lev el 1 Link-St at e dat abase.

Splitting Areas The pr ocess of split t ing ar eas is, essent ially, t he r ever se of m er ging. I n t his case, you st ar t w it h a co m m on ar ea, 49.0001, dual-hom e RTB t o t he new ar ea, 49.0002, and subsequent ly isolat e it fr om ar ea 49.0001. This r esult s in t he for m at ion of a Level 2 backbone for com m unicat ion bet w een t he t w o separ at e ar eas ( see Figure 4 - 6 ). Figur e 4 - 6 . Split t ing a r e a s.

83

Renumbering NSAP Addresses The pr ocess of r enum ber ing is sim ilar t o split t ing and m er ging, except t hat dur ing r enum ber ing, you nor m ally w ant t o elim inat e one ar ea pr efix and r eplace it w it h a new er one on a few or all t he r out er s. As show n in

Figure 4 - 7 ,

y ou st ar t w it h 49.0001 as t he ar ea pr efix and

w ant t o r enum ber t o 49.0002. To accom plish t his, apply new NSAPs w it h t he new ar ea pr efix t o bot h RTA and RTB. I n t he t hir d st ep, r em ov e t he NSAPs w it h 49.0001 fr om one r out er and t hen t he ot her . This r esult s in seam less and nonint r usive r econfigur at ion of t he r out er s w it h new NSAP addr esses, w it hout dow nt im e.

84

Figur e 4 - 7 . Re num be r ing N SAP a ddr e sse s.

An int er est ing point t o not e is t hat I S-I S m ult ihom ing is not analogous t o t he concept of secondary I P subnet s, w here m ult iple isolat ed logical subnet s can be creat ed on t he sam e link. Anot her subt le differ ence is in how t he t w o feat ur es ar e configur ed. I n I S-I S m ult ihom ing, t he m ult iple NSAP addresses are configured globally on t he ent ire rout er, w hereas secondary I P subnet s ar e enabled by ov er lay ing separ at e subnet s on a single phy sical link .

85

NSAP Selector Values The NSEL field specifies a user of t he net w or k layer ser vice. The r out ing layer is r egar ded as a special user of net w or k lay er ser v ices and is assigned a v alue of zer o for t he NSEL. The NSAP configur ed on I S-I S r out er s alw ay s uses 0x 00 for t he NSEL; such addr esses ar e also r efer r ed t o as net work ent it y t it les ( NETs) . NSEL values have t he sam e connot at ion as t he Pr ot ocol I dent ifier in Lay er 2 addr esses or TCP por t num ber s. The NSEL v alue assist s t he net w or k lay er in handing off dat agr am s t o t he appr opr iat e applicat ion or ser v ice user . According t o t he OSI lay er ing schem e, t he basic user of net w or k lay er ser v ices is t he t r anspor t lay er . CLNP dat a pack et s t hat ar e not m eant for t he r out ing pr ocess hav e t ar get NSAP addr esses w it h non-zer o NSEL values t o indicat e t he net w or k ser vice user at t he t r anspo r t lay er . This does not apply t o I P pack et s t hat ar e r out ed based on an I P dest inat ion addr ess. For exam ple, t he NSEL value of 0x21 ident ifies t he t r anspor t layer of DECNet Phase I V and a value of 0x22 for OSI Transport Layer TP4. OSI TP4 is im plem ent ed in DECNet Phase V ( see Table 4 - 2 ) .

The t ransport la yer t hen ult im at ely hands off t o a higher pr ot ocol layer , possibly t o

t he end applicat ion.

Table 4 - 2 . N SAP Se le ct or ( N SEL) Va lue s

N SEL Va lue 0x00 0x21 0x22

N e t w or k Se r vice Use r Rout ing Layer ( for inst ance, I S- I S) DECNet Phase I V Transport Layer OSI Transport Layer TP4

NSAP Examples This sect ion pr esent s concr et e ex am ples of CLNP NSAP addr esses ( see Exam ples 4 -8 ,

4-9,

and 4 - 1 0 )

t o help t he r eader pr ecipit at e m at er ial cov er ed on CLNP addr essing st r uct ur e. Ex a m ple 4 - 8 A CLN P Ex a m ple

47.0001.aaaa.bbbb.cccc.00 Area = 47.0001, SysID = aaaa.bbbb.cccc, NSel = 00 Ex a m ple 4 - 9 A CLN P Ex a m ple

39.0f01.0002.0000.0c00.1111.00 Area = 39.0f01.0002, SysID = 0000.0c00.1111, NSel = 00 Ex a m ple 4 - 1 0 A CLN P Ex a m ple

49.0002.0000.0000 .0007.00 Area = 49.0002, SysID = 0000.0000.0007, Nsel = 00

NSAP Address–to–Host Name Mapping As discussed in t he pr eceding sect ion, an NSAP can be long ( up t o 20 by t es, com par ed t o 4 by t es in I P addresses) . Also, t he hexadecim al represent at ion doesn't provide any operat ional convenience for r out er configur at ion, t r oubleshoot ing, or r out ine oper at ions act ivit ies, such as

86

inspect ion and m aint enance of t he I S-I S r out ing env ir onm ent . Wor k ing w it h long NSAP addr esses m ight be a daunt ing t ask, especially in high-pressure t roubleshoot ing sit uat ions. The Sy sI D appear s in sev er al at t r ibut es, such as adj acency infor m at ion, ident ifier s of linkst at e packet s ( LSPs) in t he I S-I S dat abase, and feat ures in t he out put of m any com m ands t hat ar e used by net w or k oper at or s t o gat her infor m at ion about t he net w or k . Most people ar e bet t er at w or king w it h sym bolic nam es t han w it h num er ic r epr esent at ions. Wit h t he gr eat success of t he I P Dom ain Nam e Syst em ( DNS) , it is obvious t hat a sim ilar facilit y for t r anslat ing bet w een t he hex adecim al r epr esent at ions of NSAP addr esses and r out er host nam es is a necessar y convenience for t he net w or k oper at ions st aff. Cisco I OS Soft ware provides t wo m echanism s for t he rout er host nam e– to– NSAP addr ess m apping. These m echanism s essent ially provide a host nam e -to-SysI D m apping. The first and older m et hod, st at ic host nam e m apping, uses st at ic m apping st at em ent s in t he r out er 's configur at ion. The alt er nat ive m et hod, dy nam ic host nam e m apping, w as st andar dized only r ecent ly in t he I ETF. I t em ploys a dynam ic m echanism t o achieve t he sam e pur pose. The follow ing sect ions r ev iew t hese t w o m et hods.

Static Host Name Mapping The I OS com m and clns host < host na m e > < nsa p> creat es st at ic host nam e – to– NSAP addr ess ( act ually SysI D) m ap t ables on Cisco r out er s. This m et hod has been available for a w hile and, despit e it s m anual approach and usabilit y challenges in large net w orks, it offers convenience t o m any net w or k oper at ions engineer s w ho w or k w it h I S-I S. Exam ple 4 - 1 1

show s RTA and RTB configur ed w it h st at ic CLNP host st at em ent s t hat enable t he

r out er s t o r esolve each ot her 's NSAP ( act ually t he SysI D) t o t he cor r esponding nam e. This allow s a r out er 's nam e t o be used in place of t he Sy sI D com ponent in t he Link-St at e Pack et I dent ifier ( LSP I D) , pr oviding t rem endous convenience when t roubleshoot ing or reviewing ent r ies in t he I S-I S Link-St at e dat abase. Ex a m ple 4 - 1 1 St a t ic H ost N a m e– to– N SAP Addr e ss M a pping

RTA Router isis Net 49.0001.1111.2222.3333.00 CLNS host RTA 49.0001.1111.2222.3333.00 CLNS host RTB 49.0001.4444.4444.6666.00 RTB Router isis Net 49.0001.4444.5555.6666.00 CLNS host RTA 49.0001.1111.2222.3333.00 CLNS host RTB 49.0001.4444.4444.6666.00 Dynamic Host Name Mapping The challenges involved in m aint aining st at ic CLNS host t ables in large net w orks, and t he obv ious success and conv enience of I P DNS, inspir ed t he need for a dy nam ic appr oach for

87

m apping and r esolv ing host nam es t o NSAP addr esses. RFC 2763 specifies an enhancem ent t o t he I S-I S prot ocol t hat allows host nam e – to– NSAP address m apping infor m at ion t o be t r anspor t ed w it hin t he I S-I S prot ocol it self rat her t han an ext ernal DNS-like applicat ion. This aut om at ic m echanism for gat hering host nam e – to– NSAP address m apping inform at ion bet w een I S-I S r out er s is significant ly m or e convenient t han t he cum bersom e m anual approach t hat r elies on st at ic t ables. RFC 2763 int r oduces an opt ional TLV ( Ty pe 137) , w hich is car r ied in LSPs of part icipat ing rout ers, providing a sim ple and reliable m echanism for advert ising host nam e inform at ion. Type, Lengt h, and Va lue ( TLV) fields are discussed in det ail in Chapt er 5 . TLV 137 is used for carrying a 7 -bit ASCI I r epr esent at ion of a r out er 's host nam e, 1 by t e per char act er . The lengt h of t his TLV r anges fr om 1 t o 255 by t es. Rout er s r unning im plem ent at ions of I S-I S t hat suppor t opt ional TLV 137 r ead and inst all host nam es w it h cor r esponding SysI D infor m at ion in a host t able t hat is used t o r esolve t he SysI D com ponent of I Ds of LSPs in t he Link-St at e dat abase. The dy nam ic host t able also allow s r out er host nam es t o be used w it h t he CLNS Tr acer out e and Ping t r oubleshoot ing t ools. Cisco rout ers running older releases of I OS, and ot her vendor rout ers t hat cannot int erpret TLV 137, should j ust ignore it w hen encount er ed in an LSP. Obviously, for such r out er s, st at ic host nam e m apping is t he only alt er nat iv e. St at ic ent r ies m ust also be configur ed on all r out er s in t he net w or k for such r out er s t hat do not suppor t TLV 137.

Summary A r out ing pr ot ocol essent ially assem bles and or ganizes addr essing infor m at ion accor ding t o locat ion w it hin a net w or k . I S-I S w as or iginally designed for r out ing in I SO CLNS env ir onm ent s w her e t he Lay er 3 pr ot ocol is CNLP and t he net w or k lay er addr esses ar e descr ibed as NSAPs. Adapt ing I S-I S t o car r y I P infor m at ion didn't elim inat e NSAP addr essing alt oget her because of t he st r ong links w it hin t he pr ot ocol basis. Ther efor e, using I S-I S on I P rout ers requires node based NSAPs t o be defined in addit ion t o t he link-based I P addr esses on t he int er faces. This chapt er at t em pt s t o dem y st ify NSAP addr essing by ex plaining w hy it is st ill feat ur ed in I nt egr at ed I S-I S, even for I P-only r out ing, and by discussing t he NSAP addr essing ar chit ect ur e. The NSAP for m at is cover ed and you st udied t he t hr ee m aj or r elevant com ponent s w hen using I S-I S for I P r out ing, nam ely Ar ea I D, SysI D, and NSEL. Even t hough t he I S-I S-r elat ed specificat ions suggest 1 t o 8 byt es for t he SysI D, Cisco r out er s suppor t a fixed 6 -byt e lengt h in conform ance wit h t he U.S. GOSI P v er sion 2.0 st andar d. This chapt er discusses t he significance of t he Sy sI D in I S-I S oper at ions and pr ov ides guidelines for defining unique NSAPs on r out er s in an I S-I S ar ea or dom ain. One m et hod is t o base t he Sy sI D on a loopback I P addr ess on t he r out er. I n general, globally unique NSAPs are not needed for I S-I S r out ing in t he I P dom ains t hat for m t he I nt er net , even t hough som e ser vice pr ovider s obt ain and deploy such NSAPs in t heir net works. The chapt er discusses t he seven t op -level NSAP addressing dom a ins and pr ovides insight int o t he r ole of RAs t hat allocat e NSAP addr esses t o gov er nm ent and pr iv at e or ganizat ions w or ldw ide. An int erest ing subj ect , I S-I S m ult ihom ing is discussed and com par ed w it h I S-I S m ult i-ar ea suppor t and I P subnet t ng. Mult ihom ing co nfigur at ions ar e useful for t r ansit ions such as

88

m er ging, split t ing, and r enum ber ing of I S-I S ar eas. Mult ihom ing causes Lev el 1 LSPs t o be exchanged bet ween I S-I S ar eas inst ead of using Level 2 r out ing. How ever , exchanging Level 1 LSPs bet w een ar eas effect ively m erges t hem . A significant difference bet ween m ult ihom ing and t he m ult i-area feat ure is t hat t he lat t er uses m ult iple I S-I S pr ocesses t o suppor t m ult iple independent ar eas, w her eas t he for m er m er ges ar eas under one pr ocess. An NSAP can be as long as 2 0 byt es and a gr eat er par t of it is r epr esent ed in hexadecim al, a for m at w it h w hich m any people hav e difficult y w or k ing. Net w or k oper at or s w ho w or k w it h I SI S on a r egular basis cher ish t he conv enience of w or k ing w it h sy m bolic nam es r at her t han long NSAP a ddresses. This chapt er discussed t he t w o m et hods available on Cisco rout ers for NSAP address– to–sym bolic nam e m apping: st at ic m apping and dynam ic m apping. The lat t er m et hod is specified by t he I ETF RFC 2763. This chapt er concludes w it h a r ev iew of NSAP exa m ples t hat illust r at es how t o delineat e t he t hr ee m aj or fields in an NSAP.

Review Questions

1:

What does t he acronym NSAP represent and what is an NSAP used for?

2:

What are t he t hree m aj or com ponent s of an NSAP? Describe t he significance of each.

3:

What is t he m axim um lengt h of an NSAP and what is t he m inim um lengt h t hat can be configured on a Cisco rout er?

4:

What 's t he AFI field in an NSAP, and what is it s significance?

5:

How m any OSI t op- layer address dom ains exist ? List t hem .

6:

Associat e t he following addresses wit h one of t hese t op- level address dom ains:

1 39.0005.1100.2200.432A.26CD.00 2 47.0001.2211.3311.5566.ACD7.2351.00AC.210700 7:

How m any byt es of t he NSAP are allocat ed t o t he SysI D on a Cisco rout er? What is t he value specified by I SO 10589?

8:

I S- I S has two levels of rout ing, Level 1 and Level 2. Elaborat e on t he relevance of t he m aj or fields of t he NSAP t o t hese rout ing levels in t he I SO CLNS environm ent .

9:

List som e of t he requirem ent s and caveat s for defining t he syst em I D on a device.

10:

How m any NSAPs can you have per rout er according t o I SO 10589? What is t he purpose o f having m ore t han one NSAP per router?

11:

What does SNPA st and for and what is it s relevance in t he I S- I S routing environm ent?

12:

I dent ify t he area address, SysI D, and NSEL values in t he following address:

47.005.8001.443E.AB11.BD48.0C1F.00 The NSAP address components are as follows: Area: 47.005.8001.443E

89

System ID: AB11.BD48.0C1F N-selector:00

References ANSI Organizat ion Regist rat ion Fact Sheet :

web.ansi.org/ public/ services/ reg_org.htm l

I dent ifiers for Organizat ions for Telecom m unicat ions Addressing I OTA;

ht t p: / / www.bsi-

global.com / DI SC/ index.xhtm l

I ETF RFC 1237, " Guidelines for OSI NSAP Allocat ion in t he I nt ernet " I ETF RFC 2763, " Dynam ic Host nam e Exchange Mechanism for I S-I S" I S0 8348/ AD2, " Addendum t o t he Net work Service Definit ion Covering Net work Layer Addressing" ( RFC 941) I SO 8348, "Net work Service Definit ion St andard"

90

Chapter 5. The IS-IS Link-State Database In

Chapt er 3 ,

" I nt egrat ed I S-I S Rout ing Pr ot ocol Concept s," you r ead about t he t w o m ain

cat egor ies of I S-I S funct ional capabilit ies: t he subnet w ork-dependent and subnet w or kindependent funct ions. As you m ight r ecall, t he subnet w or k-dependent funct ions are prim arily responsible for adj acency form at ion and m anagem ent , w hereas t he subnet w ork-independent funct ions pr ovide capabilit ies for exchanging and m anaging r out ing and r elat ed cont r ol inform at ion. The I S-I S r out ing engine r epresent ed in Figure 3 -8 illust rat es t he funct ional or ganizat ion of t he key pr ocesses and subsyst em s t hat ar e r esponsible for t he subnet w or kindependent funct ions. The I S-I S Link-St at e dat abase, w hich is feat ur ed pr om inent ly in t he r out ing engine, is t he bot t om line of all t he com plex oper at ions t hat w or k t oget her t o achieve t he obj ect iv es of t he I S-I S pr ot ocol. Those obj ect ives include t he efficient collect ion and dissem inat ion of r out ing infor m at ion and t he expedient det er m inat ion of t he m ost opt im al pat h bet w een any t w o point s in t he net w ork. The significance of t he I S-I S r out ing engine in t he over all I S-I S prot ocol fram ew ork underscores t he im port ance of underst anding t he funct ions and operat ion of t he I S-I S dat abase for anyone int erest ed in t he nut s and bolt s of t he I S-I S pr ot ocol. This chapt er focuses pr im ar ily on t he I S-I S Link-St at e dat abase and discusses it s archit ect ural int ernals. The discussion covers t he role of t he dat abase updat e process, including how it gat hers, st or es, and dissem inat es r out ing infor m at ion. The obj ect ive of t he chapt er is t o pr ovide you w it h a com plet e under st anding and appr eciat ion of t he sophist icat ed innar ds of t he I S-I S prot ocol. The infor m at ion elem ent s st or ed in t he I S-I S Link-St at e dat abase ar e r efer r ed t o as link-st at e packet s ( LSPs). LSPs cont ain r out ing infor m at ion gener at ed by I S-I S r out er s t o descr ibe t heir im m ediat e surrounding. Recall from

Chapt er 3

t hat LSPs are one of t hree cat egories of I S-I S

packet s; hello packet s and sequence num ber packet s ( SNPs) ar e t he ot her s. LSPs cont ain inform at ion such as t he follow ing:

•

Area inform at ion

•

Adj acent rout ers

•

I P subnet s

• •

Met ric inform at ion Aut hent icat ion inform at ion

The infor m at ion cont ained in an LSP r epr esent s a par t ial v iew of t he ent ir e t opology of t he local area. You m ight recall from previous chapt ers t hat t he original specificat ions of I S-I S ( I SO 10589 and RFC 1195) r equir e each r out er in an I S-I S r out ing dom ain t o be t ied t o at least one pare nt ar ea. N OTE

I S-I S im plem ent at ion ext ensions in r ecent Cisco I OS r eleases suppor t m ult i-ar ea configur at ions in w hich a single r out er can connect t o m ult iple independent ar eas.

91

Mult i-ar ea suppor t in I S-I S is int ended for use in pure I SO dom ains and for sca ling auxiliary net w orks for m anaging t elecom m unicat ion net w ork elem ent s such as SONET Add Dr op Mult iplexor s.

The r out er s in an ar ea ex change LSPs by m eans of a pr ocess called flooding. The flooding pr ocess is discussed in det ail lat er in t his chapt er . LSPs lear ned fr om neighbor s in t he sam e ar ea ar e st or ed locally on each r out er in t he Lev el 1 I S-I S Link- St at e dat abase. Each ar ea in an I S-I S dom ain has it s ow n unique Lev el 1 Link-St at e dat abase. I t is a k ey r equir em ent of link-st at e prot ocols such as I S-I S t hat all r out er s in an ar ea r eceive and assem ble all int r a -ar ea LSPs int o ident ical Link-St at e dat abases t hat r epr esent t he t opology of t he ar ea. Each r out er t hen r uns t he shor t est pat h fir st ( SPF) algorit hm over it s dat abase t o obt ain best pat hs for dest inat ions w it hin t he ar ea. As discussed in Chapter 2 , " I nt roduct ion t o t he I S-I S Rout ing Pr ot ocol," and Chapt er 3 , I S-I S suppor t s a hier ar chical r out ing ar chit ect ur e w it h t w o levels: Level 1 and Level 2. The Level 1 Lin k-St at e dat abase suppor t s r out ing w it hin an ar ea, and t he Level 2 Link-St at e dat abase suppor t s r out ing bet w een ar eas. The Lev el 2 Link-St at e dat abase is a collect ion of Level 2 LSPs flooded over t he backbone. The Level 2 LSPs cont ain pieces of infor m at ion about t he Level 2 t opology as seen from t he perspect ive of rout ers at t ached t o t he backbone. The com plet e Level 2 t opology is obt ained b y running t he SPF algorit hm over t he Level 2 dat abase. I n a t ypical net w or k layout , t he individual Level 1 ar eas ar e int er connect ed by a backbone form ed by Level 2 -capable rout ers, referred t o as Level 1 -2 rout ers. Level 1 -2 r out er s m aint ain t w o separ at e Lin k-St at e dat abases for Level 1 and Level 2 rout ing, respect ively. This is illust r at ed in Figure 5 - 1 , w hich show s an I S-I S r out ing dom ain w it h t w o ar eas, 49.0001 and 49. 0002. Figur e 5 - 1 . Le v e l 1 a n d Le v e l 2 Lin k- St at e dat abases.

92

Figure 5 - 1

also show s r out er s in each ar ea funct ioning as Level 1 -only and w it h only a single

dat abase. For Cisco r out er s, t he default configur at ion is bot h a Lev el 1 and Lev el 2 r out er . How ev er , r out ing can be t ur ned off for Lev el 1 or Lev el 2, if necessar y , t o conser v e m em or y and processing res our ces. I f a r out er is not connect ed t o t he backbone and it is r unning low on syst em r esour ces, for exam ple, it can be configur ed as Level 1 -only so t hat it builds and m aint ains only a Lev el 1 Link-St at e dat abase. Sim ilar ly , a r out er sit t ing in t he m iddle of t he back bone of t he net w or k , w it hout any dir ect connect ions t o a Lev el 1 ar ea, can be configur ed as a Level 2 -only rout er. I n t his case, t he Level 2 configurat ion is necessary t o m aint ain cont iguit y of t he Level 2 backbone.

Chapt er 7 ,

" General Net work Design I ssues," focuses on I S-

I S net w or k design issues in ser v ice pr ov ider env ir onm ent s and elabor at es on v ar ious design consider at ions, including scenar ios w it h lar ge flat single Level 1 - or Level 2 -only ar chit ect ur es w it hout any hier ar chy . The pur pose of such a design is usually t o opt im ize pat h select ion in t he I S-I S r out ing env ir onm ent , w hile at t he sam e t im e pr eser v ing r out er m em or y and processor resources. All rout ers in t he single -ar ea dom ain hav e t he sam e Lev el 1 or Lev el 2 dat abase from w hich t hey derive rout ing inform at ion.

Figure 5 - 2

illust rat es a nonhierarchical

dom ain spanned by a single Lev el 1 ar ea. Figur e 5 - 2 . Sin gle a r e a dom a in , Le ve l 1 - on ly .

Alt ernat ively, all t he rout ers can be configured as Level 2 -only , as show n in Figure 5 - 3 ; in w hich case, t hey all hav e ident ical Lev el 2 Link-St at e dat abases. Figur e 5 - 3 . Sin gle a r e a dom a in , Le ve l 2 - on ly .

93

As m ent ioned ear lier , I S-I S pack et s ar e cat egor ized as follow s:

•

Hello packet s

• •

LSPs SNPs

Hello pack et s ar e cent r al t o t he oper at ion of t he subnet w or k -dependent funct ions, which essent ially involve form ing and m aint aining adj acencies. LSPs r elat e t o t he oper at ion of t he subnet w or k-independent funct ions, which m anage t he rout ing inform at ion-gat her ing pr ocess. SNPs help ensur e t he r eliabilit y of t he flooding pr ocess, w hich in t ur n leads t o efficient dat abase synchronizat ion bet w een t he Leve l 1 r out er s in t he var ious ar eas and t he Level 2 r out er s in t he backbone. Flooding and dat abase synchr onizat ion ar e discussed lat er in t his chapt er in t he " Flooding and Link- St at e Dat abase Synchronizat ion " sect ion. That sect ion also discusses t he specific r oles played by t he var ious t ypes of SNPs in flooding and dat abase synchr onizat ion. The LSPs collect ed int o t he various dat abases t oget her provide t he basis for t he big pict ur e int er pr et at ion of t he t opology of an ar ea or t he back bone. This int er pr et at ion is achiev ed w it h t he help of t he SPF algorit hm . By piecing t oget her t he inform at ion cont ained in t he LSPs t o det er m ine t he t opology of t he ar ea or t he back bone, SPF also helps det er m ine t he shor t est pat h bet w een t w o point s in t he net w ork. The SPF algorit hm is discussed in det ail in Chapt er 6 , " The Short est Pat h First Algorit hm ." This ch apt er now t ur ns t o issues r elev ant t o t he Link-St at e dat abase, such as secur it y , dat a int egrit y, efficiency, and resource conservat ion. These t opics are discussed from bot h prot ocol design and im plem ent at ion perspect ives.

IS-IS Link-State Packets Lev el 1 and Level 2 LSPs ar e sim ilar in for m at even t hough each t ype of packet car r ies infor m at ion for differ ent levels of t he I S-I S rout ing hierarchy. This sect ion review s t he generic

94

LSP packet for m at and ident ifies differ ences bet w een Level 1 and Level 2 LSPs. I t also look s at t he TLVs associat ed w it h each t y pe of LSP.

Link-State Packet Format As not ed in Chapt er 3 , all I S-I S pack et s hav e a header t o w hich TLV fields ar e appended ( r efe r t o Figure 3 - 2 ) .

show n in

A com plet e layout of t he LSP form at , including t he header and t he TLV sect ions, is Figure 5 - 4 .

Figur e 5 - 4 . LSP for m a t .

The PDU t ypes for Level 1 and Level 2 LSPs ar e num ber ed 18 and 20, r espect ively. The int er pr et at ion of t he header fields fr om t he t op of t he pack et up t o and including t he PDU

95

Lengt h field is t he sam e for all I S-I S pack et s. The header fields follow ing t he PDU Lengt h field ar e specific t o t he LSP for m at and have t he follow ing m eanings:

•

Rem a ining Lifet im e — Rem aining t im e for t he LSP t o ex pir e.

•

LSP I de n t ifie r ( LSP I D ) — Associat es an LSP w it h it s sour ce for ident ificat ion.

•

Se que nce N um be r — The sequence num ber of t he LSP.

•

Ch e ck su m— Checksum of t he LSP calculat ed over fields st art ing from t he LSP I D field t o t h e en d.

•

Pa r t it ion— Bit 8. Set if source of LSP support s part it ion repair.

•

At t ached— Bit s 4 – 7. Set t o indicat e at t achm ent t o anot her ar ea w it h applicable m et r ics as follow s: bit 4 – default , bit 5 – delay , bit 6 – ex pense, bit 7 – er r or .

•

Ove r loa d— Bit 3. Set t o indicat e t hat t he Link-St at e dat abase of t he sour ce is over loaded and t hat pr ocessing and m em or y r esour ces ar e lim it ed .

•

I S Type — Bit s 1 and 2. I ndicat es t he t y pe of r out er ; Lev el 1 ( only bit 1 set ) or Lev el 2 ( bot h bit s 1 and 2 set ) . Ot her com binat ions ar e not defined.

Var ious t ypes of TLV fields can be included in LSPs t o pr opagat e differ ent kinds of r out ing infor m at ion. Each TLV follow s a gener ic for m at , w hich includes fields for t he t ype of TLV, t he lengt h of t he specific TLV, and t he value or cont ent s of t he TLV. The sect ion in t his chapt er t it led " Link- St at e Pack et TLVs" provides in -dept h cov er age of t he t y pe of TLVs t hat m ight be cont ained in LSPs. The LSPs in t he Link-St at e dat abase of a Cisco r out er can be v iew ed w it h t he com m and show isis da t a ba se ( see

Exam ple 5 - 1 ) .

This com m and displays t w o separ at e Link-St at e dat abases:

Level 1 and Level 2. A var iat ion of t he com m and can be ent er ed t o display only one dat abase by using t he Lev el-1 or Lev el-2 com m and opt ions. Ex a m ple 5 - 1 Out put of show isis da t a ba se Co m m a n d

RTB# sh isis database IS-IS Level-1 Link State Database LSPID LSP Seq Num 0000.0000.0005.00-00 0x000007EF 0000.0000.0006.00-00 0x000007E7 0000.0000.0007.00-00* 0x000007FB 0000.0000.0007.01-00* 0x000007E3

LSP Checksum 0xDD14 0x2ECA 0x6FCB 0xA91D

LSP Holdtime 667 1126 960 782

IS-IS Level-2 Link State Database LSPID LSP Seq Num 0000.0000.0001.00-00 0x000007EB 0000.0000.0007.00-00* 0x000007EF 0000.0000.0007.01-00* 0x000007CB

LSP Checksum 0x27F 0x1637 0x2C5F

LSP Holdtime ATT/P/OL 858 0/0/0 851 0/0/0 630 0/0/0

ATT/P/OL 0/0/0 0/0/0 1/0/0 0/0/0

Each dat abase cont ains LSPs for a specific r out ing lev el. I n Exam ple 5 - 1 , t he following inform at ion is pr ovided for each LSP: LSP I D, LSP sequence num ber , LSP checksum , LSP holdt im e, rem aining lifet im e ( LSP holdt im e) , st at us of at t achm ent ( ATT) , overload st at us ( OL) , and par t it ion suppor t ( P) .

96

Depending on t he set up of a r out er , t he sy st em I D com ponent in t he LSP I Ds can be r esolv ed int o t he corresponding host nam es of t he s ource rout ers ( see Exam ple 5 - 2 ) . As y ou can see, all t hese elem ent s t hat descr ibe t he LSP in t he show isis da t a ba se out put ar e ex cer pt s fr om t he LSP header . The follow ing sect ions discuss t hem fur t her .

LSP Re m a in in g Life t im e The Rem aining Lifet im e field in an LSP feat ur es a t im er t hat t r ack s t he age of an LSP. The ult im at e goal for t r ack ing t he age of an LSP is t o pur ge t he Link-St at e dat abase of st ale inform at ion. The t w o im port ant t hreshold values associat ed w it h t he rem aining lifet im e are LSP m axage and LSP refresh int erval. LSP m ax age is t he upper bound of t he r em aining lifet im e of an LSP and specifies t he m ax im um life span of an LSP. I SO 10589 specifies a v alue of 20 m inut es ( 1200 seconds) . Recent changes in Cisco I OS Soft w are allow larger values of t he LSP lifet im e t o be configured ( up t o 653,350 seconds) using t he lsp- m ax- lifet im e com m and. When an LSP is cr eat ed at t he originat ing rout er, t he Rem aining Lifet im e field is set t o t he value of LSP m axage and flooded t hroughout t he area t hrough adj acent neighbors. The rem aining lifet im e of an LSP decr eases w it h t im e. When an LSP ages up t o t he r efr esh int er v al ( t hat is, t he r em aining lifet im e has decr eased by t he r efr esh int er val) , it is r egener at ed by t he sour ce. Ot her w ise, t he LSP w ould cont inue t o age unt il t he r em aining lifet im e r eaches zer o v alue; at w hich point , it w ould be pur ged out of t he net w or k . Th e refresh int erval is t he per iodic int er val at w hich LSPs ar e r egener at ed or r efr eshed by t he originat ing rout ers even if no net w ork changes necessit at e t hat . When t he LSP is regenerat ed, t he rem aining lifet im e is reset t o m axage and reflooded int o t he net w ork. At t he refresh t im e, t he value of t he Rem aining Lifet im e is t he difference bet ween m axage and t he refresh int erval. I SO 10589 specifies an LSP refresh int erval of 15 m inut es, w hich is 900 seconds. Recent Cisco I OS r eleases allow higher v alues of t he r efr esh int er v als t o be configur ed using t he com m and lsp- r e fr e sh- in t e r va l. Up t o 635,530 seconds of r efr esh t im e can be configur ed in place of t he 9 0 0 -second default . I f a rout er does not refresh it s LSP aft er t he refresh int erval and t he LSP ages on t o zer o r em aining lifet im e, all r out er s t hat hav e a copy of t his LSP ev ent ually pur ge it fr om t heir dat abases aft er a gr ace per iod of60 seconds. The gr ace per iod, w hich is r efer r ed t o as ZeroAgeLifet im e is n ot a configur able par am et er in Cisco I OS Soft w ar e. I ncreasing t he refresh int erval reduces t he frequency of periodic refreshing of LSPs. This in t ur n, r educes t he t oll on net w or k r esour ces, such as bandw idt h and pr ocessing cost s. Lar ger refresh int ervals t ha n t he default ar e r ecom m ended only in st able net w or k envir onm ent s. I f t her e is a need t o adj ust t he LSP r efr esh int er v al, t he LSP m ax age also m ust be adj ust ed accordingly, w it h m axage being a lit t le higher t han t he refresh int erval.

97

Link - St a t e Pa ck e t I de n t if ie r Th e Lin k-St at e Packet I dent ifier ( LSP I D) , as t he nam e im plies, is used t o dist inguish LSPs fr om each ot her and t o ident ify t he or iginat ing r out er s. The LSP I D consist s of t he follow ing t hr ee com ponent s:

•

Syst em I dent ifier ( SysI D)

• •

Pseudonode I dent ifier ( PSN I D)

Figure 5 - 5

LSP num ber show s t he LSP st r u ct ure. The size of t he SysI D is 6 byt es, w it h a 1 -byt e Pseudonode

I D and a 1 -byt e LSP num ber appended. Figur e 5 - 5 . St r uct ur e of t he LSP I D .

Th e Sy sID com ponent of t he LSP I D refers t o t he originat ing rout er. The non -zer o Pseudonode I D ident ifies special LSPs t hat ar e r efer r ed t o as pseudonode LSPs. A pseudonode LSP is associat ed w it h a m ult iaccess link, and it is gener at ed by t he designat ed int er m ediat e sy st em on t hat link . A r out er 's r egular LSP has a Pseudonode I D v alue of zer o. The LSP num ber r efer s t o fr agm ent s of an LSP ( r egular or pseudonode) . The fir st fr agm ent of an LSP is num ber zer o. When any fr agm ent of a lar ge LSP is lost in t r ansm ission, t he r eceiver dr ops all t he ot her fr agm ent s and t he w hole set m ust be r et r ansm it t ed, w ast ing pr ecious bandw idt h. I n cont rast t o t he Open Short est Pat h First ( OSPF) Prot ocol, I S-I S does not use m any t y pes of LSPs t o dist r ibut e r out ing infor m at ion. All r out ing inform at ion, as for Level 1 rout ing, is bundled int o a single LSP, w hich can be fr agm ent ed as necessar y. Because fr agm ent at ionont he -fly has undesirable consequences on processing resources of rout ers, how ever, I S-I S m it igat es t he negat iv e consequences by const r aining t he m axim um size of an LSP unit and proact ively fragm ent ing a large LSP int o sm aller unit s, w hich are independent ly flooded t hr ough t he net w or k. The m axim um size of an LSP is 1492 byt es. The I S-I S specificat ion, I SO 10589, requires hellos t o be padded t o t he m axim um LSP buffer size or t he MTU of t he out going int er faces ( MTU usually used) , m eaning bot h sides of an adj acency m ust nor m ally hav e t he sam e MTU t o for m an adj acency .

Figure 5 - 6

show s ex am ples of LSP I Ds. The t hir d

ex am ple show s t he LSP I D of an LSP fr agm ent .

98

Figur e 5 - 6 .

Figure 5 - 6

LSP I D e x a m ple s.

As indicat ed pr eviously, t he num er ic SysI D in t he LSP I D ( r efer t o Exam ple 5 - 1 ) is r eplaced by t he host nam e of t he or iginat ing r out er if st at ic host nam es ar e in place or dy nam ic nam e resolut ion is in effect .

Exam ple 5 - 2

show s a show isis da t a ba se out put in w hich t he LSP I Ds

feat ure t he host nam es of t he corresponding source rout ers. Ex a m ple 5 - 2 N a m e- Ba se d Syst e m I D s

RTB#show isis database IS-IS Level-1 Link State Database: LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL RTA.00-00 0x00000065 0x1EDF 989 0/0/0 RTA.01-00 0x0000005A 0x370E 744 0/0/0 RTB.00-00 *0x00000067 0x8475 1128 1/0/0 IS-IS Level-2 Link State Database: LSPID LSP Seq Num RTB.00-00 *0x00000070 RTC.00-00 0x00000063 RTC.02-00 0x0000005D

LSP Checksum LSP Holdtime ATT/P/OL 0x6289 1176 0/0/0 0x657A 965 0/0/0 0xB1BE 1088 0/0/0

This show isis da t a ba se out put cont ains t w o LSPs from RTA in t he Level 1 dat abase, represent ed by RTA.00-00 and RTA.01-00, r espect ively. Even t hough gener at ed by t he sam e rout er, each LSP has a different pseudonode num ber in it s LSP I D. RTA.00-0 0 , w h ich h as a zer o pseudonode num ber and is RTA's own regular LSP. RTA.01-00 has a non -zer o Pseudonode I D, and t her efor e r epr esent s a pseudonode LSP gener at ed for a LAN on w hich RTA is t he DI S. The pseudonode LSP list s all know n rout ers connect ed t o t he LAN, w hereas a r out er 's ow n LSP car r ies infor mat ion such as adj acent neighbor s on all int er faces, I P pr efix infor m at ion, and so on.

Link - St a t e Pa ck e t Se qu e n ce N u m be r I n t he LSP header , 4 byt es ar e dedicat ed t o t he Sequence Num ber field for num ber ing LSPs by t he updat e process. The LSP sequence num ber is specified as a 32 -bit unsigned int eger and incr eases in 1 incr em ent s fr om 0 t o an upper t hr eshold of 1 less t han t he num ber 2 t o t he

99

pow er of 32 ( 2^ 32 – 1) . The v alue 2^ 32 is r efer r ed t o as SequenceModulus. The fir st LSP gener at ed by a r out er , w hen it fir st connect s t o a net w or k , has a sequence num ber of 1. The sequence num ber is incr eased by 1 w henev er a new er v er sion of t he LSP is gener at ed as a r esult of changes in a r out er 's envir onm ent . The sequence num ber plays a key r ole in t he dat abase synchroniz at ion process by helping rout ers in t he sam e area ident ify older LSPs from new er ver sions. Also, w hen a r out er cr ashes and r econnect s t o t he net w or k, it gener at es a new LSP w it h a sequence num ber of 1. I f t he r out er 's older LSP at t he t im e of cr ash has a h igher sequence num ber and hasn't been pur ged fr om t he net w or k, how ever , one of t he ot her r out er s in t he sam e ar ea sends a copy of t he older LSP t o t he r ecov er ed r out er . The r out er t hen adj ust s it s sequence num ber t o be close t o t he value before it crashed, by gener at ing y et anot her LSP w it h cur r ent infor m at ion but w it h a sequence num ber t hat is lar ger t han t hat of t he older LSP by 1. The size of t he Sequence Num ber field ( 4 by t es) allow s a r out er t o gener at e new LSPs w it h increm ent ing sequence num bers for a long t im e w it hout r unning over . The follow ing calculat ion elaborat es on t he reasoning behind t his claim . First , consider t he m axim um possible sequence num ber, account for inherent prot ocol delays in regenerat ing LSPs, and t hen convert t he t im e it t akes t o at t ain t he m ax im um sequence num ber int o y ear s. St e p 1 . The t ot al num ber of possible sequence num ber adj ust m ent s, count ing from 1, is 2^ 32 – 1 = 4,294,967,295. St e p 2 . Using t he specified m inim um LSP r egener at ion int er val of 30 seconds, t he t im e r equir ed t o deplet e t he sequence num ber space is ( 4,294,967,295 x 30) seconds. St e p 3 . The r esult ing value fr om St ep 2 is conver t ed int o year s, as follow s: ( 4,294,967,295 x 30 seconds) / ( 60 seconds x 60 m inut es x 24 hours x 365 days) = 4085.77 years Even account ing for leap year s, it w ill t ake m or e t han 4000 year s for a r out er t hat is cont inuously generat ing it s LSP ( unrealist ically) t o overrun t he Sequence Num ber field. St ill w onder ing w hat m ight happen if by som e m agic a r out er 's LSP sequence num ber w er e t o r each t he m axim um possible sequence num ber ? Well, I SO 10589 inst r uct s t hat an event r efer r ed t o as At t em pt ToExceedMaxim um SequenceNum ber should be logged and t he I S-I S process disabled for t he period of m axage + ZeroAgeLifet im e t o allow t he m ost recent LSP t o ex p ire and be purged from t he net w ork. The rout er can t hen be rest art ed, enabling it t o kick off w it h a new LSP w it h a sequence num ber v alue of 1.

Link - St a t e Pa ck e t Ch e ck su m To guarant ee t he int egrit y of t he inform at ion in an LSP, t he originat ing rout er com pute s a checksum on t he LSP and ent er s it int o t he LSP Checksum field. The checksum value is ver ified by any r out er t hat r eceives a copy of t he LSP. The Checksum field is t he t hir d colum n in t he out put of t he show isis da t a ba se com m and ( r efer t o Exam ple 5 - 2 ) . The LSP checksum is

100

calculat ed over fields st art in g aft er t he Rem aining Lifet im e field up t o t he end of t he LSP. The checksum is unm odified as copies of t he LSP ar e pr opagat ed t hr ough t he net w or k fr om one r out er t o t he ot her . I t m akes sense t o exclude t he Rem aining Lifet im e field because it cont ains a cont inuously changing t im er value. The checksum helps det ect corrupt ed LSPs or st ale LSP duplicat es t hat hav e not y et been pur ged fr om t he net w or k . When a r out er r eceiv es w hat look s lik e a copy of it s LSP but w it h cor r upt ed infor m at ion, it t r ies t o pur ge it fr om t he net w or k by flooding a new er LSP w it h cur r ent link-st at e infor m at ion and a higher sequence num ber t han t hat of t he corrupt ed LSPs. All ot her rout ers in t he area t hen r eceive and inst all t he new er LSP, t hus pur ging t he older LSP fr om t heir dat abases. I n general, any r out er t hat det ect s a cor r upt ed LSP init iat es a pur ge by flooding a copy w it h t he r em aining lifet im e r eset t o 0. This act ion effect ively causes ot her r out er s in t he ar ea also t o pur ge t he LSP. Cor r upt ed LSPs ar e not used in r out ing calculat ions or r eflooded as is. I f t he or iginat or is st ill connect ed t o t he ar ea, it or iginat es and r efloods a v alid copy of t he LSP. I f an LSP is cont inuously being corrupt ed in t ransm ission, purged from t henet w ork by ot her r out er s, and t hen r eissued by t he sour ce, t his r esult s in a sit uat ion descr ibed as an LSP corrupt ion st orm . This phenom enon is covered in det ail lat er in t his chapt er in t he sect ion " I S- I S Link- St ate Dat abase I nt egrit y I ssues ."

An LSP corrupt ion st orm is a resource -int ensiv e act iv it y t hat can

pot ent ially result in m ore com plicat ed net w ork problem s and even a net w ork m elt dow n if per v asiv e. Cisco I OS Soft w are allow s rout ers t o be configured t o ignore cor r upt ed LSPs and t o log er r or s only locally . The r out er-level I OS com m and lsp- ignore- e r r or s can be used t o enable t his capabilit y.

Ot h e r LSP H e a de r I n for m a t ion : Pa r t it ion , At t a ch e d, Ove r loa d, a n d I S Ty pe Fie lds This sect ion look s at t he bit fields in t he last byt e of t he LSP header . These fields include t he 1 -bit Part it ion field, t he 4 -bit At t ached field, t he 1 -bit Overload field, and t he 2 -bit I S Ty pe field. Pa r t it ion— The or iginal I S-I S specificat ion, I SO 10589, describes how t o repair a part it ioned Leve l 1 ar ea by cr eat ing an alt er nat e Lev el 1 pat h t hr ough t he Lev el 2 back bone. This ar r angem ent t akes advant age of t he exist ence of connect ions fr om each of t he Level 1 part it ions t o t he backbone and t he lat t er's cont iguit y t o est ablish a repair pat h by reco nnect ing t he par t it ions ov er t he back bone. This w or k s by elect ing a Lev el 2 -capable r out er in each part it ion as t he part it ion -designat ed Lev el 2 I S and est ablishing a special adj acency , k now n as virt ual adj acency or virt ual link bet w een t hem . The virt ual link provides t he Level 1 repair pat h t hrough t he backbone. The part it ion designat ed r out er s adver t ise t he vir t ual adj acencies by set t ing t he par t it ion bit in t heir Level 1 LSPs, t hus signaling t he exist ence of t he vir t ual link t o Level 1 r out er s for for w arding dat a bet w een t he par t it ions.

Figure 5 - 7

illust rat es area part it ion repair. Det ails regarding det ect ion of

101

an ar ea par t it ion, elect ion of par t it ion-designat ed rout ers, and est ablishm ent of virt ual links are beyond t he scope of t his book. ( For m ore com plet e coverage, refer t o I SO 10589.) Par t it ion r epair is an opt ional capabilit y in I S-I S and is cur r ent ly not suppor t ed in Cisco I OS Soft w are. Cisco rout ers enabled for I S-I S r out ing, t her efor e, alw ays set t he par t it ion bit in t heir LSPs t o zer o and also ignor e t he par t it ion bit if it is set in any r eceiv ed LSPs. Consequent ly , t he par t it ion bit has no r elev ance t o t he oper at ion of I nt egr at ed I S-I S on Cisco r out er s. Figur e 5 - 7 . Ar e a pa r t it ion r e pa ir .

Attach e d— The 4 -bit At t ached field is set by Level 2 rout ers in t heir Level 1 LSPs t o indicat e t o sam e -area Level 1 rout ers t hat t hey are connect ed in ot her areas. Connect ivit y t o anot her area in t he dom ain essent ially im plies at t achm ent t o t he backbone. I S-I S ar eas, as specified in I SO 10589, ar e st ubs, and Lev el 1 r out er s for w ar d pack et s t o ot her ar eas in t he dom ain t hr ough t he closest Lev el 2 r out er . Lev el 2 r out er s in an ar ea adv er t ise t hem selv es t o t he Lev el 1 r out er s by set t ing t he at t ach bit s in t heir Le vel 1 LSPs. Even t hough t he at t ached bit s ar e specified in bot h Level 1 and Level 2 LSPs, t hey ar e r elevant only in t he Level 1 r out ing fr am ew or k . The 4 bit s also allow an I S-I S r out er t o indicat e w hich of t he 4 m et r ic t y pes ar e suppor t ed for at t aching t o t he back bone. Each bit is dedicat ed t o a specific t y pe of m et r ic ( see Table 5 - 1 ) .

The four t ypes of m et rics support ed by t he I S-I S prot ocol ( default , delay, expense,

102

and error) is discussed in det ail in Chapt er 3 . These m et rics ar e designed for qualit y-o f-ser v ice applicat ion. Only t he default m et r ic is suppor t ed in Cisco I OS Soft w ar e.

Table 5 - 1 . At t a che d Bit s Fie ld Se t t ings

4 5 6 7

Bit posit ion in Oct e t ( 00001000) ( 00010000) ( 00100000) ( 01000000)

At t a ch e d Fie ld Bit s 0001 0010 0100 1000

M e t r ic Type Default Delay Ex pense Error

Ove r loa d— Bit 3 in t he last by t e of t he LSP header signals t he r esour ce av ailabilit y st at eof a r out er . I f t his bit is set , it indicat es an over load condit ion at t he r out er . An over load condit ion indicat es t he rout er's perform ance is inhibit ed by low m em ory and processing resources. LSPs w it h t he overload bit set are not reflooded and also are not used in calculat ing pat hs t hrough t he overloaded rout er. This m eans t hat t he overloaded rout e r is circum vent ed for t ransit t r affic; how ever , pat hs in w hich t he over loaded r out er is t he last hop ar e calculat ed. The Cisco I OS com m and se t- ove r loa d- bit allow s m anual set t ing of t he ov er load bit . The ov er load bit can be lev er aged t o deliber at ely pr ev ent t ransit t raffic from flow ing t hrough a specific rout er. This is discussed furt her in Chapt er 7 . I S Type — The I S Ty pe bit s in t he LSP indicat e w het her t he LSP is fr om a Lev el 1 or Lev el 2 r out er . This essent ially indicat es t he t ar get Link-St at e dat abase for st or ing t he LSP. The possible bit set t ings for t he I S Ty pe field ar e show n in Table 5 - 2 .

Table 5 - 2 . I S Type Fie ld Se t t ings

Bit s V a lu e s 00 01 10 11

Bit s in Oct e t 00000000 00000001 00000010 00000011

I S Type Unused Lev el- 1 Unused Lev el- 2

is a de code of an LSP fr om a packet analyzer show ing t he fields in t he LSP header sect ion. All t he LSP -specific header fields discussed earlier are feat ured, present ing an Exam ple 5 - 3

int erest ing view of t he st ruct ure and form at of t he LSP header. Ex a m ple 5 - 3 LSP H e a de r D e code

IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS:

Protocol ID = 83 (Intermediate System Routing Exchange Protocol) Header length = 27 Version / Protocol ID Extension = 1 ID Length = 0, Indicate 6 Octets PDU type = 18 (Link State, Level 1) Version = 1

103

IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS:

Reserved = 0 Maximum Area Addresses = 0 Frame length is 100 byte(s) Remaining life is 1199 second(s) Link State Frame ID: Source ID = 000000000001 Pseudo-node = (Not a pseudo-node) Link frame no. = 0 Frame Sequence = 6203 Checksum = E6CF Attributes = 0B O... .... = Partition repair not supported .0.. .... = Not attached using error metric ..0. .... = Not attached using expense metric ...0 .... = Not attached using delay metric ....1 ... = Attached using default metric .... .0.. = No LSP Database Overload .... ..11 = Level 2 intermediate system

Link-State Packet TLVs The pr ev ious sect ions of t his chapt er r ev iew ed t he LSP packet form at and discussed fields in t he LSP header . As show n in Figure 5 - 2 , TLV fields ar e appended t o t he header of an I S-I S pack et , depending on it s t y pe and t he specifics of t he rout ing environm ent , t o form t he com plet e packet . This sect ion cover s t he TLVs defined for Level 1 and Level 2 LSPs by I SO 10589 and RFC 1195.

Table 5 - 3

list s t he TLVs for Level 1 LSPs defined in bot h st andards, and

list s t he TLVs for Level 2 LSPs. Som e TLVs ar e used in bot h Level 1 and Level 2 LSPs. Those unique t o a specific lev el of LSP ar e bolded. Som e of t he r ecent TLVs defined by t he Table 5 - 4

I ETF for v ar ious ex t ensions t o I nt egr at ed I S-I S, such as MPLS t raffic engineering, are covered in t he sect ion " I S- I S Met ric Ext ensions " lat er in t his chapt er.

TLVs for Level 1 LSPs Table 5 - 3 list s t he TLVs specified in I SO 10589 and RFC 1195 t o support t he I S-I S Lev el 1 r out ing envir onm ent . TLVs ( Type, Lengt h, Value) fields also ar e r efer r ed t o as CLV ( Code,

Lengt h, Value) fields in t he previously m ent ioned st andar ds. TLV is used because it is m or e com m on in recent lit erat ure and I ETF publicat ions. The End Syst em Neighbors inform at ion TLV ( Type 3) is bolded because it is specific only t o t he Level 1 r out ing envir onm ent .

Table 5 - 3 . Le ve l- 1 TLV s

TLV Area Address I nt erm ediat e Syst em Neighbors En d Sy st e m N e igh bor s Aut hent icat ion I nform at ion I P I nt ernal Reachabilit y I nform at ion Prot ocols Support ed

Type 1 2 3 10 128 129

Source I SO 10589 I SO 10589 I SO 1 0 5 8 9 I SO 10589 RFC 1195 RFC 1195

104

I P I nt erface Address

132

RFC 1195

The uses of t he v ar ious Lev el 1 TLVs ar e descr ibed her e:

•

Ar e a Addr e ss TLV— This TLV list s t he set of ar ea addr esses configur ed on t he originat ing rout er. The TLV feat ures only in nonpseudonode LSPs and is in t he fir st fr agm ent if t he LSP is fr agm ent ed. The Ar ea Addr ess TLV is m ade up of t he follow ing fields: - Type ( 1 byt e ) — 1 - Le n gt h ( 1 byt e ) — Tot al lengt h of t he Value field - Value — n x (1 -by t e addr ess lengt h + v ar iable ar ea addr ess)

•

I nt e r m e dia t e Syst e m N e ighbor s TLV— This TLV capt ur es t he list of adj acent Lev el 1 r out er s. I t consist s of t he follow ing fields: - Type ( 1 byt e ) — 2 - Le n gt h ( 1 byt e ) — 1 by t e + n x ( sy st em I D lengt h + 5 in by t es) for n neighbors - Value — 1 byt e vir t ual flag + n m ult iples of ( 4 -by t e ne ighbor m et ric inform at ion + neighbor SysI D + 1 byt e Pseudonode I D)

The I nt erm ediat e Syst em Neighbors TLV is repeat ed for each neighbor. The TLV differs from t he I S Neighbors TLVs ( Type 6) used in LAN hello packet s. Specifically, t his TLV ( Type 2) also car ries m et ric inform at ion for each of t he neighbors. I S-I S m et rics is an int erest ing t opic and is discussed in det ail in t he sect ions " I S- I S Met rics I nform at ion " and " I S- I S Met ric Ext ensions " lat er in t his chapt er .

•

En d Syst e m N e igh bor s TLV— This TLV is av ailable only in Lev el 1 LSPs. I t capt ur es and list s adj acent Lev el 1 r out er s as w ell as end sy st em s, such as I SO CLNP w or kst at ions capt ur ed t hr ough t he ES-I S pr ot ocol. I t has t he follow ing st r uct ur e: - Type ( 1 by t e ) — 3 - Le n gt h ( 1 byt e ) — 4 by t es + Sy sI D lengt h of ES neighbor - Value — Com m on m et ric + m ult iples of SysI D of ES neighbors End sy st em s w it h t he sam e m et r ic ar e gr ouped t oget her in a single TLV.

•

Au t h e n t ica t ion I n for m a t ion TLV— This TLV pr ov ides for LSP authent icat ion t hr ough a sim ple clear-t ext password schem e. No ot her password t ypes for I S-I S pack et aut hent icat ion have been st andar dized as of t his w r it ing. How ever , t he I ETF I S-I S Working Group is looking at a m ore sophist icat ed MD5 -based aut hent icat ion schem e.

105

Aut hent icat ion is discussed in furt her det ail in Chapt er 9 , " Configuring I S-I S for I P Rout ing on Cisco Rout er s" . - Type ( 1 byt e ) — 1 0 - Le n gt h ( 1 byt e ) — Specified lengt h of t he Value field in byt es w it hin t he range of 1 – 254 byt es - Value — This field is m ade up of t w o com ponent s: Ty pe of Aut hent icat ion and Aut hent icat ion Passw or d, as follow s:

o

Ty pe of aut hent icat ion ( 1 by t e) 0 and 2 –2 5 4 – Reserved 1 – Clear-t ext password 2 5 5 – Dom ainw ide aut hent icat ion

o

Aut hent icat ion password —For aut hent icat ion Type 1, t his is a var iable -lengt h clear-t ext passw or d up t o 254 byt es long.

•

I P I n t e r n a l Re a ch a bilit y I n for m a t ion TLV— This TLV st or es a list of dir ect ly connect ed I P pr efixes. I t is used only in nonpseudonode LSPs. Each prefix is assigned a m et ric value, w hich corresponds t o t hat of t he link over w hich t he I P prefix is configur ed. - Type ( 1 byt e ) — 1 2 8 - Le n gt h ( 1 byt e ) — Mult iples of 12 byt es - Value — Mult iple ent r ies, each consist ing of t he follow ing:

o o o •

4 byt es for m et ric inform at ion 4 byt es for I P pr efix 4 by t es for I P subnet m ask

Pr ot ocols Su ppor t e d TLV— This TLV ident ifies t he Layer 3 pr ot ocols suppor t ed by I nt egr at ed I S-I S. I t m ust appear in t he first fragm ent ( LSP num ber 0) if t he LSP is fr agm ent ed. Cur r ent ly, t he only pr ot ocols suppor t ed ar e CLNP ( NLPI D 0x81) andI P ( NLPI D 0xCC) . - Type ( 1 byt e ) — 1 2 9 - Le n gt h ( 1 byt e ) — Tot al lengt h of t he Value field in by t es - Value — Net work layer prot ocol ident ifiers ( NLPI Ds) for support ed prot ocols, 1 by t e each

106

•

I P I n t e r fa ce Addr e ss TLV— This TLV cont ains one or m or e of t he I P addr esses configured on t he originat or of t he LSP. I n recent I OS releases, t he highest loopback addr ess is ent er ed aut om at ically in t his field. - Type ( 1 byt e ) — 1 3 2 - Le ngt h ( 1 by t e ) — Tot al lengt h of t he Value field in by t es - Value — Mult iples of 4 -by t e I P addr esses

show s a Level 1 LSP out put fr om a Cisco r out er displayed by t he com m and show isis da t a ba se . An LSP I D and t he k ey w or d " det ail" ar e ent er ed as ar gum ent s t o display t he Exam ple 5 - 4

det ails of a specific LSP. The out put show s t he LSP header and t he TLVs in t he LSP. The following TLVs are present : Area Address TLV, Prot ocols Support ed TLV, I P Address TLV, I nt er nal I P Reachabilit y TLV, I S Neighbor s TLV, and t he ES Neighbor s TLV. LSP show s t hat only I P ( NLPI D OxCC) is support e d. This is because CLNP r out ing is not enabled and because I S-I S is used for r out ing only I P on t his r out er . Ex a m ple 5 - 4 Le v e l- 1 LSP fr om a Cisco Rou t e r

RTD#show isis database 0000.0000.0004.00-00 level-1 detail IS-IS Level-1 LSP 0000.0000.0004.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL 0000.0000.0004.00-00* 0x0000000F 0x6699 1036 1/0/0 Area Address: 49.0002 NLPID: 0xCC IP Address: 11.1.1.4 Metric: 10 IP 10.1.2.0 255.255.255.0 Metric: 10 IP 192.168.2.12 255.255.255.252 Metric: 10 IP 11.1.1.4 255.255.255.255 Metric: 10 IS 0000.0000.0004.02 Metric: 10 IS 0000.0000.0002.01 Metric: 0 ES 0000.0000.0004 The follow ing calculat ion enables you t o det er m ine how m any I P pr efixes can be adver t ised in an LSP. Th e follow ing const raint s are t o be considered in t he calculat ion:

•

The m ax im um size ( m ax LSPsize) of an LSP is 1492 by t es.

•

The LSP header ( lspHeader size) is 27 byt es.

•

The m axim um lengt h of a TLV ( m axTLVlengt h) is 255 byt es.

•

Each TLV 128 consist s of t y pe ( 1 byt e) , lengt h ( 1 byt e) , and I P pr efixes ( n x 12 by t es) up t o t ot al of 255 by t es.

•

The m axim um num ber of fragm ent s of an LSP ( m axLSPfragm ent s) is 256. The num ber of fragm ent s is det erm ined from t he 1 -byt e LSP Num ber field in t he LSP ident ifier.

•

The fir st fr agment cont ains ot her TLVs, and t he r em aining 255 fr agm ent s ar e packed w it h only TLV 128.

The act ual calculat ion is as follow s:

107

1.

The t ot al space available for TLVs in an LSP is TLVSpace = m axLSPsize - lspHeader size = 1492 - 27 = 1465 byt es

2.

The num ber of TLVs t hat can fit int o TLVSpace is 1465/ 255 = 5.7, approxim at ely 6 Assum ing a 1– byt e Type field and 1 -byt e Lengt h field, overhead for 6 TLVs is 6 x 2 = 12 by t es.

3.

Act ual space available for prefixes is 1 4 6 5 – 12 byt es over head = 1453 byt es

4.

Num ber of pr efix es, each 12 byt es ( address + subnet m ask + m et ric) t hat can fit int o TLVSpace is 1453/ 12 = 121.08 ( appr ox im at ely 121 I P pr efix es per LSP)

Consider ing t hat few ot her TLVs can be gener at ed by t he r out er , t he num ber of I P pr efixes t hat can be suppor t ed per I S-I S r out er is 256 fr agm ent s, each cont aining 121 pr efix es, for a t ot al of 30,976 pr efix es.

TLVs for Level 2 LSPs Table 5 - 4

list s t he Level 2 TLVs, w hich ar e t he subj ect of t his sect ion. The blocked TLVs ar e

av ailable only in Lev el 2 LSPs. The ot her s ar e shar ed TLVs and can be used in bot h Lev el 1 and Lev el 2 LSPs ( r efer t o Table 5 - 3 ) . As in Table 5 - 3 , t he TLV t y pe and t he st andar d in w hich a TLV w as or igina lly specified ar e show n in t his t able.

Table 5 - 4 . Le ve l- 2 TLV s

TLV Area Address I nt erm ediat e Syst em Neighbors Part it ion- Designat ed Level 2 I nt erm ediat e Syst em Prefix Neighbors Aut hent icat ion I nform at ion I P I nt ernal Reachabilit y I nform at ion Prot ocols Support ed I P Ext ernal Reachabilit y I nform at ion

Type 1 2 4 5 10 128 129 130

Source I SO 10589 I SO 10589 I SO 10589 I SO 10589 I SO 10589 RFC 1195 RFC 1195 RFC 1195

108

I nt erdom ain Rout ing Prot ocol I nform at ion I P I nt erface Address

131 132

RFC 1195 RFC 1195

The uses of t he v ar ious Lev el 2 TLVs ar e as follow s:

•

Ar e a Addr e ss— Ty pe 1. Sam e as defined for Lev el 1 LSPs.

•

I nt e r m e dia t e Syst e m N e ighbor s— Ty pe 2. Sam e as defined for Lev el 1 LSPs.

•

Pa r t it ion- D e sign a t e d Le ve l 2 I n t e r m e dia t e Syst e m TLV— This TLV suppor t s par t it ion r epair of a par t it ioned Level 1 ar ea by cr eat ing a vir t ual pat h over t he backbone bet w een t w o Level 2 r out er s in each of t he par t it ions. Par t it ion r epair is cur r ent ly not suppor t ed on Cisco r out er s. - Type ( 1 byt e ) — 4 - Le n gt h ( 1 byt e ) — Lengt h of Sy sI D - Value — SysI D of part it ion -designat ed Lev el 2 I S

•

Pr e fix N e igh bor s TLV— This TLV collect s inform at ion on reachable NSAP prefixes. The TLV is relevant only for I SO CLNP rout ing bet w een areas ( Level 2 rout ing) . Pr efix es w it h t he sam e m et r ic value ar e bundled t oget her in t he sam e TLV. Ther e can be m ult iples of t his TLV in an LSP, and it can occur in any fr agm ent of an LSP. - Type ( 1 byt e ) — 5 . - Le n gt h ( 1 byt e ) — Tot al lengt h of t he Value field. - Value — Each Prefix Neighbor TLV consist s of 4 by t es of com m on m et r ic + m ult iples of ( 1 -byt e address prefix lengt h + address prefix) . Au t h e n t ica t ion I n for m a t ion TLV— Ty pe 10. Sam e as defined for Lev el 1 LSPs.

•

I P I nt e r na l Re a cha bilit y I nfor m a t ion— Ty pe 128. Sam e as defined for Lev el 1 LSPs.

•

Pr ot ocols Suppor t e d— Ty pe 129. Sam e as defined for Lev el 1 LSPs.

•

I P Ex t e r na l Re a cha bilit y I nfor m a t ion— This TLV collect s I P r out es obt ained fr om ot her rout ing prot ocol sources by m eans of redist ribut ion int o I S-I S: - Type ( 1 byt e ) — 1 3 0 - Lengt h ( 1 byt e ) — n x 1 2 , w her e n is t he num ber of ext er nal r out es - Value — Mult iples of 4 -byt e m et ric inform at ion + ( 4 -by t e I P pr efix and 4 -byt e prefix m ask) Only t he I S-I S default m et r ic t ype is suppor t ed on Cisco r out er s. When configur ing r edist r ibut ion on a Cisco r out er, t w o choices of m et ric labels for ext ernal rout es apply:

109

int er nal or ex t er nal. The act ual v alue applied t o ex t er nal r out es depend on t he label select ed in t he configurat ion. Redist ribut ion is covered in det ail in Chapt er 9 .

•

I n t e r dom a in Rou t in g Pr ot ocol I n for m a t ion ( I D RPI ) TLV— This TLV is specified in RFC 1195 t o suppor t int er act ion of t he I S-I S pr ot ocol w it h any I nt er dom ain Rout ing Pr ot ocol r unning on t he boundar y of t he I S-I S dom ain. I t is current ly not support ed in Cisco I OS Soft w ar e: - Type ( 1 byt e ) — 1 3 1 . - Le n gt h ( 1 byt e ) — Tot al lengt h of t he Value field. - Value — This field is m ade up of t w o com ponent s. A byt e specifies t he t ype of I nt er dom ain I nfor m at ion field as follow s: 0 – Reser v ed. 1 – Ext er nal I nfor m at ion field has special for m at . 2 – Ext ernal I nform at ion field cont ains a single 2 -byt e aut onom ous syst em ( AS) num ber . The AS num ber is t o be used for t agging all subsequent I P ext er nal r eachabilit y infor m at ion in t he LSP up t o t he occur r ence of anot her I DRPI TLV. Ext ernal I nform at ion field, w hich depends on t he t ype of t he I nt erdom ain I nform at ion field.

•

I P I n t e r fa ce Addr e ss TLV— Ty pe 132. Sam e as defined for Lev el 1 LSPs. The TLV can occur m ult iple t im es and in any LSP fr agm ent . The sam e addr esses m ust be in bot h Level 1 and Level 2 LSPs if t he r out er is Level 1 -2 .

Exam ple 5 - 5

show s a Lev el 2 LSP fr om a Cisco r out er . Som e of t he infor m at ion in t his LSP is also

pr esent in t he Level 1 LSP displayed fr om t he sam e r out er ( r efer t o Exam ple 5 - 4 ) . I nform at ion specific t o t he Level 2 LSP is t he I P Ext ernal Reachabilit y I nform at ion TLV. The ES Neighbor s TLV is pr esent in only t he Lev el 1 LSP and t he t w o LSP shar e a com m on I P addr ess in t he I P I nt erface TLV ( 11.1.1.4) . Ex a m ple 5 - 5 Le v e l- 2 LSP fr om a Cisco Rou t e r

RTD#show isis database 0000.0000.0004.00-00 level-2 detail IS-IS Level-2 LSP 0000.0000.0004.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL 0000.0000.0004.00-00* 0x00000012 0xC837 389 0/0/0 Area Address: 49.0002 NLPID: 0xCC IP Address: 11.1.1.4 Metric: 10 IS 0000.0000.0004.02 Metric: 10 IS 0000.0000.0003.00 Metric: 10 IS 0000.0000.0002.01

110

Metric: Metric: Metric: Metric: Metric:

128 IP-External 172.16.0.0 255.255.0.0 10 IP 10.1.2.0 255.255.255.0 20 IP 11.1.1.2.255.255.255.255 10 IP 11.1.1.4 255.255.255.255 10 IP 192.168.2.12 255.255.255.252

IS-IS Metrics Information TLVs specified by I SO 10589 cont ain m et r ic infor m at ion:

•

ES Neighbor s TLV ( Ty pe 2)

• •

I S Neighbor s TLV ( Ty pe 3) Pr efix Neighbor s TLV ( Type 5)

The overall form at s of t hese TLVs exhibit m inor differences; how ever, t he for m at oft he m et r ic fields is t he sam e in all of t hem .

Figure 5 - 8

shows t he m et ric fields in t he I S Neighbors TLV. Of

t he follow ing four t ypes of m et r ic specified, only t he default is cur r ent ly suppor t ed on Cisco r out er s: Figur e 5 - 8 . I S N e ighbor s TLV m e t r ic fie lds.

•

D e fa ult m e t r ic— Must be suppor t ed by all r out er s in t he dom ain. Fr equent ly int er pr et ed as a m easur e t hat is inv er sely pr opor t ional t o bandw idt h. Ther efor e, low er values im ply high bandwidt h a nd are bet t er.

•

Dela y m et ric— Opt ional. Measur es t he t r ansit delay of a link .

•

Ex pense m et ric— Opt ional. Measur es t he financial-relat ed cost s of using a link.

•

Er r or m e t r ic— Opt ional. Measures t he residual error probabilit y of a link.

Bit 8 ( t he S bit ) of each m et ric byt e indicat es support for t he specific m et ric. For t he default m et r ic, t his bit is r eser ved and is alw ays set t o 0. I n t he case of t he ot her m et r ic t ypes, if bit 8 is set , t he m et r ic is unsuppor t ed. Bit 7 is t his int er nal/ ext er nal bit . I t is set t o 0 t o indicat e t hat t he specific m et ric is an int ernal t ype and t o 1 t o indicat e ext ernal t ype. The follow ing I P infor m at ion TLVs specified by RFC 1195 also cont ain m et r ic infor m at ion:

111

• • Figure 5 - 9

I P I nt er nal Reachabilit y TLV ( Type 128) I P Ext ernal Reachabilit y TLV ( Ty pe 130) show s t he layout of t he m et r ic fields in t he I P I nt ernal Reachabilit y TLV, w hich is quit e

sim ilar t o t he for m at of t he I S Neighbor s TLV, as show n in Figure 5 - 8 . Obviously, RFC 1195 borrow s direct ly from t he m et ric definit ions of I SO 10589. Not ice t hat , in

Figure 5 - 9 ,

only t he

default m et r ic has t he I / E field. The set t ing for t he default m et r ic ( int er nal or ext er nal) applies t o all t h e ot h er m et rics. The I / E bit fields in t he ot her byt es are reserved. Figur e 5 - 9 . I P I n t e r n a l Re a ch a bilit y m e t r ic fie lds ( TLV 1 2 8 / TLV 1 3 0 ) .

The default m etr ic m ust be suppor t ed on all nodes in t he r out ing dom ain. The delay, expense, and er r or m et r ics ar e opt ional and ar e specified t o suppor t qualit y -o f-service rout ing. The delay, expense, and er r or m et r ics ar e r elevant t o pat h select ion cr it er ia defined by t he Globally Unique Qualit y of Ser v ice par am et er s t hat can be set in t he Qualit y of Ser v ice ( QoS) Maint enance field of a CLNP packet header . The QoS Maint enance field specifies opt ional pat h select ion crit eria by t he net w ork services user. Each t y pe of m et r ic is independent of t he ot her , and t heir consider at ion in pat h select ion r elat iv e t o each ot her depends on v ar ious bit set t ings of t he QoS Maint enance field in conj unct ion w it h select ion of a globally unique QoS cr it er ion. Each t ype of m et r ic is allocat ed a byt e in t he TLV. Set t ing bit 8 ( S) of a QoS m et r ic indicat es t hat it is not suppor t ed. Because t he default m et ric m ust be support ed, it s bit value 8 is specified as 0. As indicat ed previously, cur r ent ly none of t he opt ional QoS-relat ed m et rics are suppo r t ed in Cisco I OS. Only t he default m et ric is available as pat h select ion crit eria. The default m et ric is a scalar param et er referred t o as cost . I n m ost current applicat ions, it is given an inverse bandw idt h connot at ion. I t is essent ially a num eric represent at ion of t he t raffic-handling capacit y of a link . I n subsequent t ext , any r efer ence t o a m et r ic im plies t he default m et r ic, w hich is t he only t ype I S-I S m et ric support ed on Cisco rout ers. As discussed previously, bit 7 of t he m et ric field is

112

used t o classify t he m et r ic as int er nal or ext er nal. I nt ernal m et rics r efer t o r out es gener at ed w it hin t he I S-I S dom ain, w her eas ext ernal m et rics refer t o rout es originat ing out side t he local dom ain or fr om anot her r out ing pr ot ocol sour ce. Wit h bit 8 r eser v ed and bit 7 for int er nal or ext ernal classificat ion, only t he rem aining 6 bit s of t he m et ric byt e are available for t he m et ric value. Using 6 bit s for t he m et r ic value gives a m axim um value of 63 per link. On Cisco rout ers, m et ric values are configured on int erface s and apply t o t he out going link . I OS does not aut om at ically assign t he link m et r ic based on bandw idt h. The default value for I S-I S m et rics on all int erfaces, regardless of connect ing link speed, is 10. Link m et ric can be m odified by configur at ion. For comput at ional purposes, t he m et ric m ust be a posit ive value, and 1 is recom m ended as t he m inim um . The t ot al m et ric for a pat h is t he sum m et ric on t he out going int er faces of all link s bet w een sour ce and dest inat ion. I SO 10589 specifies t he m axim um m et ric valu e for a com plet e pat h t o be only 1023. Ther efor e, it is im por t ant for oper at or s t o plan link m et r ic assignm ent s t o achieve t he desir ed pat h differ ent iat ion. The nex t sect ion discusses r ecent I ETF ex t ensions t o t he I S-I S prot ocol t hat increase t he m axim um values of t he default m et ric. The ext ension int roduces m ore flexibilit y in m et ric assignm ent and facilit at es t he designing of I S-I S net w orks. I t also provides support for recent innovat ions in I P r out ing, such as I S-I S-based MPLS t r affic engineer ing.

IS-IS Metric Extensions Tw o new ly pr oposed LSP TLVs specify w ider fields for t he default m et r ic, allow ing lar ger int erface m et ric values t han t he previous 63 m axim um . This enhancem ent can be leveraged for basic I P r out ing, as w ell as MPLS-based t raffic engineering applicat ions. These new TLVs ar e as follow s:

• •

Ext ended I nt erm ediat e Syst em Reachabilit y TLV ( Type 22) Ext ended I P Reachabilit y TLV ( Type 135)

The Ext ended I S Reachabilit y TLV is an ext ension of t he I nt erm ediat e Syst em Neighbors TLV ( Type 2) , and t he Ext e nded I P Reachabilit y TLV ext ends t he I P I nt ernal Reachabilit y TLV ( Type 128) . These TLVs t ake advant age of t he fact t hat cur r ent and m ost w idely deployed im plem ent at ions of t he I S-I S pr ot ocol do not suppor t t he QoS m et r ic t ypes, nam ely delay, ex pense, and error m et rics. The fields reserved for t hese m et rics are, t herefore, w ast ed. These TLVs are designed t o reassign t he QoS m et ric fields t o t he default m et ric. TLV Type 22 dedicat es 24 bit s for m et r ic, and TLV Type 135 dedicat es 32 bit s com par ed t o t he 6 bit s or iginally specified. Anot her new TLV is t he Tr affic Engineer ing Rout er I D TLV ( Type 134) , w hich is used t o designat e t he addr ess on a st able int er face, such as a loopback int er face, for configur ing various capabilit ies of t he rout er. The Rout er I D TLV cont ains t he 4 -oct et Rout er I D of t he r out er or iginat ing t he LSP, and it is essent ially r elevant only for MPLS t r affic engineer ing. This TLV is not discussed furt her because MPLS is beyond t he scope of t his book.

113

Extended IS Reachability TLV (Type 22) The Ext ended I S Reachabilit y TLV is int ended t o replace t he I S Neighbors TLV ( Type 2) w it h a prim ary obj ect ive t o provide support for larger m et ric values, in general, and also t o support I S-I S-dependent MPLS t raffic engineering. The proposed form at for t his TLV is as follow s:

•

Type ( 1 byt e ) — 2 2

• •

Le n gt h ( 1 byt e ) — Tot al lengt h of t he Value field Value — 3 by t es of default m et r ic - 1 by t e of lengt h of sub -TLVs - 6 byt es of syst em I D + 1 -by t e pseudonode num ber - 0 – 244 by t es of sub -TLVs

The 3 by t es of t he m et r ic field ar e used t o encode t he m et r ic as a 24-bit unsigned int eger. For pr act ical pur poses, a m axim um pat h value ( 0xFE000000) is specified t o pr event com put at ion overflow s by exist ing im plem ent at ions of t he SPF algorit hm . Also links w it h t he m axim um possible m et ric of 2^ 24 – 1 ar e t o be ignor ed in pat h calculat ions. Sub-TLVs are used for MPLS t raffic engineering purposes.

Extended IP Reachability TLV (Type 135) The Ex t ended I P Reachabilit y TLV em bodies t he sam e ideas behind t he Ex t ended I S Reachabilit y TLV and is d esigned t o replace TLV 128. I t s prim ary goal is t o ut ilize t heQoS m et r ic fields t o suppor t lar ge m et r ic values for I P pr efixes w hile using sub -TLVs for dist r ibut ing MPLS t r affic engineer ing r esour ce infor m at ion. The for m at of t his TLV is as follow s:

•

Type ( 1 byt e ) — 1 3 5

•

Le n gt h ( 1 byt e ) — Tot al lengt h of t he Value field

•

Value — 4 by t es of m et r ic infor m at ion - 1 by t e of cont r ol infor m at ion, com posed of t he follow ing: 1 bit of up/ down st at us 1 bit of sub-TLV presence bit 6 bit s of pr efix lengt h - 0 – 4 byt es of I Pv4 prefix - 0 – 249 by t es of opt ional sub -TLVs m ade up of:

114

1 by t e of lengt h of sub -TLVs 0 – 250 byt es of sub -TLVs The up/ dow n st at us bit is int ended t o pr event r out ing loops, and it is set w hen a r out e is adver t ised fr om Level 2 int o Level 1. This pr event s such rout es from being re -advert ised back int o Lev el 2. Sub-TLVs specify MPLS t raffic engineering at t ribut es. The 4 -by t e ( 32-bit ) m et ric field perm it s large m et ric values lim it ed t o a m axim um of M AX_ PATH _ M ETRI C ( 0xFE000000) . Prefixes w it h m et rics larger t han MAX_ PATH _ M ETRI C ar e ignor ed in SPF com put at ions.

Figure 5 - 1 0

show s a side -b y-side com parison of graphical represent at ions of TLV

Ty pes 128/ 130 and TLV Ty pe 135. Figur e 5 - 1 0 . Com pa r ison of TLV 1 2 8 / 1 3 0 a n d TLV 1 3 5 .

Exam ple 5 - 6

show s an LSP w it h ent r ies for TLV 22 and TLV 135 in it alics capt ur ed on a Cisco

r out er w it h t he show isis da t a ba se de t a il com m an d. Ex a m ple 5 - 6 LSP w it h Ex t e nde d TLVs

RTX#show isis database RTB.00-00 level-1 detail IS-IS Level-1 LSP RTB.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL RTB.00-00 0x000000FE 0x59C3 1185 1/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: RTB IP Address: 11.1.1.2 Metric: 10 IP 10.1.1.0/24 Metric: 10 IP 192.168.2.0/30 Metric: 100 IP 11.1.1.2/32 Metric: 100 IS-Extended RTB.02 Metric: 10 IS-Extended RTA.01 Metric: 0 ES RTB Support for TLV Types 22 and 135 ( I S-I S w ide m et r ics) is available in r ecent Cisco I OS r eleases of t he 12.0S and 12.0T t r ains. The r out er-level com m and m et ric- st yle w ide enables a Cisco r out er r unning t he appr opr iat e I OS r elease t o send LSPs w it h w ide m et r ics and t o

115

r eceiv e and cor r ect ly int er pr et LSPs w it h TLV Ty pes 22 and 135. The com m and m et ric- st yle t r a n sit ion allow s sm oot h m igr at ion fr om old nar r ow m et r ics t o t he new w ider m et r ics. This opt ion w or k s by allow ing a r out er t o send and r eceiv e bot h nar r ow and w ide m et r ics. I n part icular, MPLS t raffic engineering configurat ion requires use of t he new w ide m et ric opt ion. The com m and m et ric- st yle na r r ow r einst at es or iginal and default behavior. Met ric configur at ion and use of t he m et ric- st yle com m and ar e discussed in m or e det ail in Chapt er 8 , " Net w or k Design Scenar ios" and Chapter 9 , " Configuring I S-I S for I P Rout ing on Cisco Rout ers."

Sequence Number Packets Lin k-st at e packet s and t heir r elevance t o t he pr ocess of gat her ing and dissem inat ing r out ing infor m at ion w it hin the I S-I S prot ocol is covered, in det ail, in t he preceding sect ion. This sect ion discusses SNPs, w hich ar e used in auxiliar y m echanism s t hat ensur e int egr it y of t he LSP-based rout ing inform at ion dist ribut ion process. You m ight recollect t hat hello packet s est ablish and m aint ain adj acencies bet w een neighbor r out er s, w her eas LSPs ar e t he vehicles for shar ing r out ing infor m at ion. I n a link-st at e r out ing envir onm ent , r out er s in an ar ea r eceive t he LSPs from all ot her rout ers in t he area t hrough t heir direct ly co nnect ed neighbor s in a pr ocess called flooding. Thr ough flooding, r out er s in an ar ea build ident ical ( synchr onized) Lev el 1 Link-St at e dat abases. The Lev el 1 Link-St at e dat abases on t he r out er s in an ar ea ar e synchronized by m eans of explicit m echanism s in w hich SNPs play a k ey r ole as cont r ol pack et s. The t w o k inds of SNPs follow :

•

Com plet e sequence num ber packet s ( CSNP)

•

Par t ial sequence num ber packet s ( PSNP)

CSNPs and PSNPs shar e t he sam e pack et for m at and each car r ies a collect ion of LSP sum m aries. The basic differ ence bet w een t hem is t hat a CSNP adv er t ised by a r out er cont ains sum m ar ies of all t he know n LSPs in it s dat abase, w her eas t he PSNP cont ains only a subset . Separ at e Lev el 1 and Lev el 2 CSNPs and PSNPs ar e gener at ed t o suppor t t he Lev el 1 and Lev el 2 Lin k-St at e dat abases, r espect ively. For exam ple, a Level 1 CSNP cont ains sum m ar ies of all t he LSPs in t he Lev el 1 Link-St at e dat abase. Each of t he LSP sum m ar ies pack ed int o CSNPs and PSNPs consist s of four k ey pieces of infor m at ion ex t r act ed fr om t he LSP header adequat e for unique LSP ident ificat ion. The follow ing ar e cont ained in an LSP sum m ar y :

•

Lin k-St at e Packet I dent ifier ( LSPI D)

•

Sequence num ber

• •

Check sum Rem aining lifet im e

Complete Sequence Number Packets I S-I S pr ov ides m echanism s t hat allow r out er s to use CSNP on bot h point -t o-point and br oadcast links t o check consist ency of t heir Link-St at e dat abases. This w ay , t hey can

116

det er m ine w het her t hey have cur r ent copies of all LSPs gener at ed by t he ot her r out er s in t he local ar ea or in t he back bone. As y ou m ight recall, int ra -area rout ing is Level 1 and int erarea r out ing is Level 2. Rout er s t hat discover t hey do not have cur r ent copies ar e m issing som e LSPs, a r esult of t he CSNP ex change ( on point -to-point links) or broadcast ( on LANs) , use PSNPs t o r equest cur r ent copies. This pr ocess is r efer r ed t o as Link-St at e dat abase synchronizat ion . The dat abase synchronizat ion process over point -to-point link s differ s a lit t le from how it is perform ed over broadcast links. I n t he case of point -t o-point link s, CSNPs are sent only once w hen t he I S-I S adj acency is init ialized, pr eceding t he exchange of LSPs over t he link . LSPs ar e ex changed r eliably ov er point -to-point link s in a w ay t hat ensur es all LSPs sent ov er t he link fr om one end ar e r eceiv ed at t he ot her end. On b r oadcast links, CSNPs ar e br oadcast per iodically by t he DI S t o com pensat e for an LSP exchange pr ocess t hat is not inher ent ly r eliable. As explained in Chapt er 2 , t he DI S plays t he role of pseudonode, w hich is an abst ract ion for represent ing broadcast links as net w ork nodes. This r educes t he num ber of one-to-one com m unicat ions in a br oadcast envir onm ent and, consequent ly, r educes t he am ount of infor m at ion t hat is exchanged w hen m a ny nodes int er connect in such env ir onm ent s. Rout ers connect ing t o t he sam e broadcast link form and m aint ain Level 1 and Level 2 adj acencies w it h each ot her by per iodically sending hellos t o t he m ult icast addr esses k now n as AllL1I S and AllL2I S, respect ively. Adj acency m aint enance and dat abase synchronizat ion on br oadcast links ar e independent pr ocesses. On br oadcast links, LSPs ar e also br oadcast t o t he sam e br oadcast addr ess m ent ioned befor e: AllL1I S for Level 1 LSPs and AllL2I S for Level 2 LSPs. The Level 1 - and Lev el 2 -designat ed rout ers coordinat e Link-St at e dat abase sychronizat ion by also periodically m ult icast ing Level 1 and Level 2 CSNPs t o t hese sam e br oadcast addr esses. I n conform it y t o t he generic I S-I S packet for m at , CSNPs consist of header s and va riable lengt h fields ( TLVs) .

Figure 5 - 1 1

show s t he CSNP packet for m at .

117

Figur e 5 - 1 1 . CSN P for m a t .

Most of t he fields in t he CSNP header ar e discussed in Chapt er 2 . The follow ing fields are of int er est :

•

Source I D — The Sour ce I D r efer s t o t he SysI D of t he r out er t hat gener at ed t he CSNP. On a point -t o-point link , it is t he Sy sI D of t he nodes on eit her side of t he link . On a br oadcast link, it is t he SysI D of t he designat ed r out er .

•

St a r t LSP I D — The st ar t LSP I D is t he LSP I D of t he fir st LSP in t he LSP Ent r ies TLV at t ached t o t he header.

•

End LSP I D — This is t he LSP I D of t he last LSP in t he LSP Ent r ies TLV field.

Table 5 - 5

list s t he t y pes of TLVs in CSNPs: t he LSP Ent r ies TLV and a TLV for aut hent icat ion of

t he CSNP pack et .

Table 5 - 5 . TLVs Suppor t e d in CSN Ps

TLV LSP Ent ries

Type 9

Source I SO 10589

118

Aut hent icat ion I nform at ion •

10

I SO 10589

LSP Ent r ie s— This is collect ion of LSP sum m ar ies of all k now n LSPs in t he cor r esponding Lev el 1 or Lev el 2 Link-St at e dat abases of t he adver t ising r out er , sor t ed in or der of ascending LSP I D. - Type ( 1 byt e ) — 9 - Le n gt h ( 1 byt e ) — Tot al lengt h of t he Value field - Value — Mult iples of LSP sum m ar ies, each consist ing of t he r em aining lifet im e ( 2 byt es) , LSP I D ( I D lengt h + 2 byt es) , LSP sequence num ber ( 4 byt es) , and LSP check sum ( 2 by t es)

•

Au t h e n t ica t ion I n for m a t ion— TLV Type 10. As defined for Level 1 and Level 2 LSPs ( see

Tables 5 - 3

and 5 - 4 ).

Partial Sequence Number Packets As indicat ed in t he preceding sect ion, PSNPs norm ally do not cont ain sum m ar ies of all t he LSPs in t he or iginat ing r out er 's dat abase. I nst ead, PNSPs com plem ent CSNPs in t he dat abase sy nchr onizat ion pr ocess and per for m t he follow ing t w o k ey funct ions:

•

Rout er s use PSNPs t o ack now ledge r eceipt of one of m or e LSPs ov er point -to-poin t link s.

•

Rout er s r equest t r ansm ission of cur r ent or m issing LSPs by using PSNPs. This applies t o bot h point -to-point and br oadcast link s.

Because t he list of LSP sum m ar ies ent er ed int o a PSNP is not consist ent as in t he case of CSNPs, w hich list sum m ar ies of all k now n LSPs, t he St ar t LSP I D and End LSP I D fields ar e ir r elev ant t o t he applicat ion and pur pose of PSNPs. These fields ar e t her efor e not pr esent in t he PSNP header ( see Figure 5 - 12 ).

119

Figur e 5 - 1 2 . PSN P for m a t .

Table 5 - 6

list s t he TLVs t hat can be found in PSNP. These ar e t he sam e as t hose suppor t ed by

CSNPs.

Table 5 - 6 . TLVs Suppor t e d in PSN Ps

TLV LSP Ent ries Aut hent icat ion I nform at ion

Type 9 10

Source I SO 10589 I SO 10589

Flooding and Link-State Database Synchronization Lin k-st at e r out ing pr ot ocols, such as I S-I S and t he OSPF Pr ot ocol, oper at e on t he pr em ise t hat all nodes in an ar ea obt ain t he sam e descr ipt ion or v iew of t he ar ea t hr ough t he ex change of link-st at e infor m at ion ( LSPs in t he case of I S-I S) . The LSPs, w hich are st or ed in t he Link-St at e dat abase, are t hen fed as input t o t he rout e calculat ion algorit hm ( SPF algorit hm ) , t o det er m ine t he shor t est pat h t o any node in t he ar ea. A consist ent v iew of t he ar ea's t opology allow s all rout ers in t he area t o independent ly calculat e opt im al and loop -fr ee r out es t o all dest inat ions w it hin t he ar ea. Each I S-I S r out er assem bles infor m at ion about it s im m ediat e sur r ounding, such as it s ow n Sy sI D and t hose of neighbor s, dir ect ly connect I P subnet s, and so on, int o an LSP. The LSP is t hen adver t ised t o dir ect ly connect ed neighbor s and event ually r eaches all nodes in t he ar ea by m eans of a m echanism k now n as flooding. Under st able

120

condit ions, t he Lev el 1 Link-St at e dat abase is ident ical on all r out er s in t he ar ea. The local r ou t e calculat ion algor it hm at each node sew s t he LSPs t oget her int o t he t opology of t he ent ir e ar ea, j ust like put t ing t he pieces of a j igsaw puzzle t oget her .

Figure 5 - 13

show s how a r out er

assem bles t he LSPs fr om ever y node in t he ar ea t o r epr esent t he ar ea's t opology. I t is necessary for all rout ers in t he area t o obt ain t he sam e and consist ent v iew of t he ar ea's physical and addressing layout t o achieve efficient and loop -fr ee for w ar ding w it hin t he ar ea. The flooding pr ocess is com plem ent ed w it h aux iliar y m echanism s, r efer r ed t o as dat abase synchronizat ion , t o guar ant ee ex act r eplicat ion of t he ar ea dat abase at ev er y node. Figur e 5 - 1 3 . LSPs in a n a r e a Lin k- St at e dat abase.

Chapter 2

discussed t he key processes underlying t he I S-I S prot ocol ( receive, updat e, decision,

and forw ard processes) . The updat e process is responsible for flooding. The individual updat e pr ocesses r unning on t he I S-I S r out er s in an ar ea w or k collabor at ivelyt o achieve t he sam e Lin k-St at e dat abases on all t he rout ers in t he area. The int errelat ed processes —flooding and dat abase synchronizat ion —ar e t he subj ect m at t er of t he subsequent sect ions in t his chapt er . When fed w it h t he Link-St at e dat abase, t he SPF algorit hm organizes t he various net w ork dest inat ions in t he LSPs int o t he short est -pat h t r ee w it h t he calculat ing r out er at t he r oot . This is achieved by using available m et ric inform at ion t o com put e t he pat hs w it h t he low est

121

cum ulat iv e m et r ic t o all k now n dest inat ions. These best r out es ar e t hen fed int o t he for w ar ding dat abase. The SPF algor it hm is discussed in det ail in Chapt er 6 . Even t hough Level 1 r out ing w it hin an ar ea is m ainly cit ed t o explain flooding and dat abase synchr onizat ion, sim ilar and independent flooding also occur s w it hin t he backbone bet w een t he Level 2 r out er s t hat int er connect ar eas. When r out ing conver ges, t he Level 1 r out er s at t ain a com plet e t opological v iew of t heir r espect iv e ar eas, w her eas Lev el 2 r out er s at t ain a com plet e m ap of t he t opological r elat ionship bet w een ar eas. Lik e all link-st at e r out ing pr ot ocols, I S-I S uses a suit e of t im er s and flags t o m anage p rocesses, such as flooding and oper at ion of t he SPF algor it hm . The t im er s and flags pr ovide cont r ol and event m anagem ent t hat ensur e st abilit y in t he r out ing envir onm ent . The t im er s help opt im ize use of syst em r esour ces, such as pr ocessing capacit y, m em or y, and link bandw idt h. Tim er s ar e also a m aj or fact or in achieving opt im al r out ing conver gence dur ing significant changes in t he net work. The following sect ion discusses t wo im port ant flags: t he Send Rout ing Message ( SRM) flag and t he Send Sequence Num ber ( SSN) flag. Dat abase m aint enance -relat ed t im ers, such as m axage, regenerat ion, and ret ransm ission t im ers,are t hen discussed.

SRM and SSN Flags SRM and SSN flags play im port ant roles in flooding and dat abase synchronizat ion. The updat e process uses t he SRM flag t o cont r ol deliv er y of LSPs t o adj acent neighbor s. The SSN flag is used in t he follow ing t w o w ay s:

•

To acknow ledge LSPs received in reliable flooding over point -t o-point links

•

To request com plet e LSP inform at ion during dat abase synchronizat ion over broadcast links

The SRM and SSN flags essent ially pr ov ide a m eans t o enfor ce efficient queuing of LSPs and PSNPs by decoupling LSP for w ar ding and ack now ledgm ent t o achiev e opt im ized ut ilizat ion of processing and link bandw idt h resources. The relevance of t hese flags is discussed furt her in t he follow ing sect ions.

Flooding Flooding is t he v ehicle for r eplicat ion and dist r ibut ion of t he Link-St at e dat abases w it hin a net w or k , a phenom enon t hat is cr it ical t o t he oper at ion of link-st at e r out ing pr ot ocols. An I SI S rout er gener at es an LSP, w hich it floods out t o all adj acent neighbor s ov er it s I S-I S-enabled int er faces. The I S-I S r out er also r eceives and pr ocesses LSPs flooded by ot her neighbor s. When a r out er r eceiv es an LSP fr om a neighbor , it k eeps a copy in t he corresponding local Lin k-St at e dat abase ( Level 1 or Level 2) and also floods copies over all I S-I S int er faces ot her t han t he one on w hich t he LSP w as r eceiv ed. To flood out an LSP, t he r out er fir st set s t he SRM flag individually for t arget int erfaces and clea r s t he flags w hen t he specific LSP has been successfully t ransm it t ed. On point -to-point links, successful t ransm ission is confirm ed by

122

r eceipt of a PSNP ack now ledgm ent . No ack now ledgm ent is r equir ed on br oadcast link s. When LSPs t hat ar e duplicat es of alr e ady k now n v er sions ar e r eceiv ed, t hey ar e dr opped. Flooding ov er point -t o-point link s is descr ibed as r eliable because LSPs t r ansm it t ed ov er such link s m ust be ack now ledged w it h a PSNP by t he r out er at t he r eceiv ing end. On br oadcast m edia, CSNPs are periodically t ransm it t ed by t he Level 1 - and Level 2 -designat ed rout ers t o assist ot her r out er s in synchr onizing t heir dat abases. Any r out er on t he m edium t hat does not hav e all or cur r ent copies of t he LSPs sum m ar ized in t he CSNP uses a PSNP t o r equest w hat it needs. Dat abase synchr onizat ion is a dynam ic act ivit y in a net w or k. Rout er s gener at e new LSPs w hen changes occur in t heir im m ediat e r out ing env ir onm ent . New LSPs ar e flooded w it h higher sequence num bers and new checksum values, and t he SRM and SSN flags a re used t o effect ively coor dinat e flooding and synchr onizat ion. The com m and show isis da t a ba se priva t e can be used t o check t he st at us of SRM and SSN flags on Cisco r out er s ( see Exam ple 5 - 7 ). Ex a m ple 5 - 7 St a t us SSN a nd SRM Fla gs

RB#show isis database private IS-IS Level-1 Link State Database: LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL RTA.00.00 0x00000068 0x18E2 909 0/0/0 Address 0x614846DC,length 360,max_length 360,on_paths Root distance 10,index 13,parent index 1,parent count 1 RTA Sc0/0 *HDLC* Up 28 L1 IS-IS SRM bits set on no interfaces SSN bits set on no interfaces RTB.00-00 0x000007DF 0x1A73 721 0/0/0 Address 0x1391B),length 415,max)length 415,on_paths Root distance 10,index 3,parent index 2,parent count 1 RTB Sc0/0 *HDLC* Up 27 L1 IS-IS SRM bits set on no interfaces SSN bits set on no interfaces Exam ple 5 - 7

show s t hat no SRM and SSN flags have been set for any LSPs, m eaning t hat t her e

ar e no LSPs t hat ar e pending t o be flooded or t hat need t o be acknow ledged for any in t er face. This com m and can be useful in t roubleshoot ing sit uat ions of congest ion result ing from relat ively large volum es of t raffic or lack of processing and bandw idt h resources on rout ers in t he net work.

Floodin g ov e r Poin t - t o- Poin t Lin k s As m ent ioned in the preceding sect ion, I S-I S uses a r eliable flooding m echanism on point -topoint links. This seem s reasonable because on a point -t o-point link, only one neighbor is on t he ot her end, and it should be fairly st raight forw ard t o t rack explicit acknow ledgm ent of LSPs fr om t hat single neighbor at alm ost insignificant bandw idt h cost .

123

CSNPs sim plify t he synchr onizat ion pr ocess. They cont ain a sum m ar y of t he r out er 's LinkSt at e dat abase. CSNPs ar e ex changed only once on a point -to-point link, w hen adj acency is first est ablished bet w een t he t w o connect ed r out er s. CSNPs pr ov ide a quick w ay t o r ev iew and m at ch t he LSPs in each neighbor 's dat abase w it h t he cont ent s of t he local dat abase t o det er m ine m issing or out dat ed copies of LSPs. The cur r ency of LSPs is det er m ined by sequence num ber com parison. PSNPs request current or m issing copies of LSPs. A rout er also can proact ively flood out LSPs t hat it det erm ines t he neighbor does not have. As indicat ed previously, SRM and SSN flags are at t he heart of t he reliable flooding process. Whereas t he SRM flag is set on any link s ov er w hich copies of a specific LSP need t o be flooded out , t he SSN flag is set on only point -t o-point links over w hich LSPs have been r eceived and flag t he need t o send out a PSNP ack now ledgm ent . The flags ar e clear ed aft er appr opr iat e act ions hav e occur r ed. When a r out er t r ansm it s an LSP ov er a point -t o-point link , it ex pect s t o hav e a PSNP acknow ledgm ent back from t he neighbor. I f t he acknow ledgm ent is not received w it hin a specified per iod, r efer r ed t o as t he ret ransm ission int erval, t he LSP is assum ed lost dur ing t r ansm ission and is r et r ansm it t ed. An LSP is cont inually r et r ansm it t ed on a point -to-point link unt il it is ack now ledged w it h a PSNP by t he neighbor . Figure 5 - 1 4

illust r at es t he flooding pr ocess on a point -to-point link . RTB has a point -to-point

connect ion t o RTA and RTC. I n t his exam ple, RTB receives an LSP from RTA w it h LSPI D RTA.00-00 and sequence num ber ( SEQ# ) 100. I t inst alls a copy of RTA.00-00 in t he LS dat abase, set s SSN on int er face 2, and set s SRM on int er face 3. RTB t hen for w ar ds a copy of RTA.00-00 t o RTC and a PSNP ack now ledgm ent t o RTA. Then RTA im m ediat ely clear s t he SSN flag on int er face 2 but leaves t he SRM flag on int er face 3. RTC r eceives RTA.00-00 from RTB, inst alls it in t he LS dat abase, and set s an SSN flag on int er face 4. RTC t h en sen ds a PSNP acknow ledgm ent t o RTB and clears t he SSN flag on int erface 4. When RTB receives t he PSNP acknowledging RTA.00-00 fr om RTC, it t hen clear s t he SRM flag on int er face 3.

124

Figur e 5 - 1 4 . Floodin g ove r poin t- to- point link s.

I nit ial CSNP ex change ov er point -to-point link s helps speed up t he sy nchr onizat ion pr ocess. Losing any of t hese CSNPs undoubt edly dr ags out t he sy nchr onizat ion process.

Figure 5 - 15

illust r at es a scenar io in w hich an init ial CSNP is lost . RTC is alr eady adj acent and synchr onized t o RTA and RTB. RTC, t her efor e, has it s ow n LSP and t hose of RTA and RTB in it s dat abase. I f t he CSNP fr om RTC is lost in t he pr ocess of sy nchr onizing w it h t he new ly adj acent RTD on t he p o int -t o-point connect ion, RTD will not im m ediat ely know about LSPs from RTA and RTB. When RTC receives RTD's CSNP, how ever, it det ect s t hat RTD doesn't yet know about LSPs from RTA and RTB. Therefore, it proact ively floods t hem out . This prolongs t he t im e it t ak es RTD t o k now about all LSPs.

125

Figur e 5 - 1 5 . Loss of init ia l CSN P on a point- to- point link .

Floodin g on Br oa dca st Lin k s On broadcast lin k s, LSPs ar e flooded t o Lev el 1 or Lev el 2 neighbor s by using t he applicable m ult icast addr ess, allL1I S ( 01-8 0 -C2 -0 0 -0 0 -14) or allL2I S ( 01-8 0 -C2 -0 0 -0 0 -15) , respect ively. The flooding operat ion does not em ploy acknow ledgm ent rout ines t hat guarant ee reliable deliv er y of LSPs, as in t he point -to-point case. Flooding on broadcast links is, t herefore, descr ibed as best effort . Reliable flooding sim plifies t he dat abase synchronizat ion process, rem oving any clear delineat ion bet w een t he flooding and synchronizat io n processes. On t he cont rary, unreliable flooding r equir es a dist inct m echanism t o ensur e dat abase sy nchr onizat ion. To sy nchr onize dat abases over br oadcast links, I S-I S r out er s r ely on per iodic m ult icast of CSNPs fr om t he DI S. Separ at e CSNPs for Lev el 1 and Lev el 2 t hat ex ist ar e adv er t ised t o allL1I S and allL2I S m ult icast addresses, respect ively. As discussed in Chapter 3 , I S-I S m odels broadcast links, such as LANs, as pseudonodes, w h ich are represent ed by DI Ss. The DI S cont rols only flooding and dat abase synchronizat ion on broadcast links. I S-I S r out er s on a br oadcast link ar e not r est r ict ed t o for m ing adj acencies wit h only t he DI S. Hello packet s are m ult icast out and rout ers be com e adj acent t o each ot her aft er a t hree -w ay handshak e, w hich essent ially m eans each r out er has r epor t ed seeing t he ot her . The CSNPs sent out by t he DI S ar e not ack now ledged eit her , and per iodic flooding

126

ensur es t hat all r out er s r eceiv e copies, w hich t hey check against t he cont ent s of t heir LinkSt at e dat abase. By looking at t he cont ent s of CSNPs, LAN r out er s can ident ify m issing or new er LSPs and subsequent ly r equest copies w it h a PSNP. The PSNP sent out is pack ed w it h sum m ar ies of r equest ed LSPs. The r equest er t hen receives t he com plet e LSPs from t he DI S or ot her peer s on t he link . SRM flags also ar e set on br oadcast link s; how ev er , t hey ar e im m ediat ely clear ed aft er t he cor r esponding LSPs ar e t r ansm it t ed because no acknow ledgm ent is expect ed. CSNPs ar e p er iodically adver t ised on br oadcast links ever y CSNP int er v al, w hich is 10 seconds by default . Per iodic CSNP adv er t isem ent can be ex pensiv e w it h r egar d t o bandw idt h consum pt ion. This is, how ever , t he t r adeoff for a sim pler schem e t o achieve reliabilit y on broadcast links. Such links w ere t radit ionally t hought t o be less expensive t han point -t o-point w ide-area links, and t his m ight have influenced t he prot ocol design in t his r egar d. Cisco I OS pr ovides a com m and t hat allow s t he per iodic int er val for t r ansm it t ing CSNPs t o be m odified t o reduce t ransm ission frequency. Figure 5 - 1 6

is a sim plified illust r at ion of flooding on a br oadcast link. I n t he scenar io show n, RTC

is t he last t o connect t o t he link . RTA and RTB ar e alr eady connect ed, and RTA is t he designat ed rout er ( DI S) . Aft er form ing adj acencies w it h RTA and RTB, RTC builds an LSP, RTC.00-00, st or es a copy in it s Link-St at e dat abase, and floods anot her copy out of int er face 3 ont o t he link. Lat er RTA, t he DI S, adver t ises a CSNP by m ult icast over t he link. RTC r eceives a copy of t he CSNP, check s it against t he local Link-St at e dat abase, and not ices t hr ee m issing LSPs: RTA.00-00, RTA.01-00, and RTB.00-00. At t his t im e, RTC has only it s ow n LSP, RTC.0000, in t he local Link-St at e dat abase. RTC t hen sends out a PSNP ont o t he link t o obt ain t he com plet e copies of RTA.00-00, RTA.01-00, and RTB.00. RTA floods RTA.00-00, RTB.00-00, and t he pseudo LSP RTA.01-00 t hr ough m ult icast , and RTC r eceives copies. Figur e 5 - 1 6 . Flooding ove r br oa dca st link s.

127

Flooding over NBMA Transport Media I n I S-I S, net w or k link s ar e eit her point -to-point or m ult ipoint br oadcast and no special provisions are m ade for nonbroadcast m ult iaccess ( NMBA) m edia, such as Asynchronous Transfer Mode ( ATM) , Fram e Relay, and I nt egrat ed Services Digit al Net work ( I SDN) . Alt hough it is fr equent ly r ecom m ended t o use point -to-point subint erfaces for NBMA links, som e pr act ical sit uat ions m ight not lend t hem selves t o t his t ype of design. I n t his case, such NBMA links m ust be configured as broadcast m ult ipoint links. How ever, t his configurat ion requires all nodes connect ing over t he NBMA cloud t o be fully m eshed. I n m ost cases, t he virt ual circuit s in t he NBMA cloud ar e not fully m eshed, t her efor e, t he m ost suit ed approach ( adopt ed by m ost net w ork operat ors) is t o configure t he ATM or Fram e Relay perm anent virt ual circuit s ( PVCs) as point -t o-point subint er faces. Because an NBMA int er face can hav e a lar ge num ber of PVCs, an ATM or Fr am e Relay cloud can have a pot ent ially high degr ee of m eshed PVCs, leading t o ex t r em e lev els of LSP flooding act iv it y . This, in t ur n, can adv er sely im pact net w or k st abilit y and scalabilit y. You can lim it excessive flooding over highly redundant NBMA PVC m eshes by gr ouping a subset of subint erfaces int o I S-I S m esh gr oups.

I S- I S M e sh Gr ou p s I S-I S m esh groups help lim it excessive and redundant flooding over NBMA clouds. During norm al operat ions, I S-I S r out er s r eflood any new LSPs ov er all ot her int er faces ex cept t he one on w hich t he LSP w as r eceived. The concept of I S-I S m esh gr oups allow s gr ouping of r out er int erfaces, t ypically NBMA subint erfaces, t oget her so t hat w hen an LSP is received from one of t he subint er faces in t he gr oup, it is not r eflooded over ot her subint er faces in t he sam e g roup. The t r ick about m esh gr oups is t hat t hey assum e a full m esh bet w een all r out er s in t he m esh and t hat ever y m em ber r out er get s a copy of t he or iginal LSP t hat is not flooded t o t he gr oup. Alt hough t his solves t he problem of redundant flooding, som e rout ers m ight not receive t heir copies of LSPs t hat ar e not t o be flooded t o t he gr oup if t he full m esh is br ok en. Ther efor e, you m ight need alt ernat ive unrest rict ed flooding pat hs w it hin t he net w ork t o guarant ee t hat all flooded LSPs r each ever y t ar get node in t he net work. The concept of I S-I S m esh gr oups is elabor at ed in Figure 5 - 17 , w hich show s a gr oup of r out er s connect ed ov er an NBMA cloud w it h a par t ial PVC m esh.

Figur e 5 - 1 7 . I S- I S m e sh gr oups.

128

A subset of t he r out er s in Figure 5 - 1 7 ( RTA, RTC, RTD, a nd RTF) form a fully m eshed subcloud. RTB and RTE connect only t o t w o neighbor s each. I n t his scenar io, it is desir able t o use point -t o-point subint erfaces t o int erconnect t he rout ers; however, t he relat ively high level of int erconnect ivit y im plies a lot o f redundant flooding over t his cloud. I f RTA floods an LSP, for exam ple, all t he ot her rout ers in t he fully m eshed subcloud ( RTC, RTD, RTF) r eceive copies of t he or iginal and subsequent ly r eflood it t o each ot her , even t hough t hey all r eceived copies alr eady. This evident ly result s in redundant flooding. I n a full m esh of n num ber of rout ers, a single LSP t ransm it t ed t o ( n – 1) nodes result s in ( n – 2) unnecessar y t r ansm issions of t he sam e LSP at t he ex pense of cr it ical pr ocessing and bandwidt h resources. I nit ially, one of t he r out er s in t he m esh floods an LSP t o ( n – 1) adj acent neighbors. Then t he rem aining ( n – 2) neighbor s flood copies of t his LSP t o each ot her , w it h copies on t he sam e link cr ossing each ot her . Aft er a specific LSP is r eceiv ed fr om a neighbor, t he sam e LSP received secondhand from anot her neighbor is not flooded t o t he first neighbor. This is w hy t he num ber of r edundant t r ansm issions is lim it ed t o(n – 2) . I f all n n od es t r ansm it t ed LSPs, t her e w ould be a t ot al of n (n – 1) original LSP t ransm issions and ( n – 1) ( n – 2) redundant t ransm issions. Mesh gr oups can be used t o lim it t he w ast e in bandw idt h and pr ocessing r esour ces r esult ing fr om r edundant flooding. Because t he oper at ion of m esh gr oups assum es a full m esh of rout ers in t he group, t he likely candidat es in Figure 5 - 1 7 for a m esh group set up are RTA, RTC, RTD, and RTF. RTB and RTE ar e left out of t he m esh gr oup and flooding is not r est r ict ed ov er t heir int erfaces. I n t his scenario, RTB and RTE provide redundant pat hs for guarant eeing

129

deliver y of any LSP t o ever y r out er in t he net w or k if any of t he links in t he m esh gr oup fail. I n t his ar r angem ent , any new LSP t hat RTA r eceiv es fr om a m em ber of t he m esh gr oup is flooded t o only nonm em ber s ( RTB and RTE) . I f an LSP is r eceived on a subint er face t hat is not in t he m esh gr oup, it is flooded ov er all ot her int erfaces as usual. The Cisco I OS int erface com m and isis m esh- g r o u p [ n u m | blocked] configur es m esh gr oups. You can use t he opt ional k ey w or d blocked t o com plet ely disable flooding on an int er face or subint erface. Even t hough t he I S-I S m esh grou p feat ur e has been suppor t ed in Cisco I OS for a w hile, a draft proposal describing t he m echanism w as subm it t ed only recent ly t o t he I ETF I SI S Wor k ing Gr oup for consider at ion and adopt ion as a st andar d feat ur e of I nt egr at ed I S-I S.

Protocol Timers and Other IS-IS Database Parameters I S-I S uses a suit e of t im er s t o cont r ol v ar ious ev ent s and t o ensur e r out ing st abilit y w it hout com prom ising t he capabilit y t o converge fast enough in case of significant changes in t he net w or k . Var ious t im er s ar e used t o ensur e int egr it y of t he Link-St at e dat abase by enforcing per iodic r efr esh of individual LSPs and aging out of st ale infor m at ion. This sect ion discusses r elevant t im er s for net w or k oper at ion pur poses and pr ovides insight int o associat ed I OS com m ands t hat allow t im e r adj ust m ent s w her e possible.

Maxage Maxage r efer s t o t he m ax im um life span of an LSP fr om t he t im e it is gener at ed by t he sour ce. I SO 10589 specifies m ax age as a pr ot ocol const ant w it h a v alue of 1200 seconds ( 20 m inut es) . The t im e lapse unt il expirat ion of an LSP is indicat ed in t he Rem aining Lifet im e field of t he LSP on Cisco r out er s. Cisco I OS adher es t o t he m ax age specificat ion in I SO 10589 by set t ing t he Rem aining Lifet im e field of an LSP t o 1200 seconds w hen it is fir st gener at ed. Act ually , t he r em aining lifet im e is r efer r ed t o as LSP holdt im e on a Cisco r out er ( show isis da t a ba se de t a il com m and) . Usually , an LSP is r efr eshed by it s sour ce befor e it s r em aining lifet im e r eaches zer o ( see t he next sect ion, " LSP Generat ion I nt erval" ) . I f a rout er is rem oved from t he net w or k , how ev er , it is not av ailable t o r efr esh it s LSP, and t he LSP ages unt il it ex pir es at a r em aining lifet im e value of zer o. Occasionally, anot her r out er in t he net w or k init iat es a pur ge of a cor r upt ed LSP fr om t he net w or k by set t ing t he r em aining lifet im e of t he LSP t o zer o and r e flooding t he LSP t o it s neighbor s. The Zer oAgeLifet im e is t he t im e an LSP is r et ained aft er it expir es, befor e it is pur ged fr om t he dat abase. I t s value is specified as 60 seconds by I SO 10589. You can use t he I OS com m and m ax- lsp- lifetim e t o m odif y t h e default value of m axage, w hich is specified as 1200 seconds. All of t he 2 by t es of t he Rem aining Lifet im e fieldar e lev er aged by Cisco I OS t o allow a m uch higher v alue ( up t o 65,535 seconds) t o be configurable on Cisco rout ers; 65,535 ( 2 16 – 1) seconds is approxim at ely 18.2 hour s. Max age is consider ed a pr ot ocol const ant and m ust hav e a consist ent v alue on all I S-I S rout ers in t he net w ork. Therefore, if a rout er receives an LSP w it h a rem aining lifet im e higher

130

t han t he ex pect ed v alue of m ax age, t he LSP is consider ed cor r upt ed and is t her efor e discar ded.

LSP Generation Interval This t im er has t w o v ar iet ies:

•

The m a x im um LSP ge ne r a t ion int e r va l— This int er v al is k now n also as t he LSP r efr esh int er val. I t r efer s t o t he per iodic r eplacem ent of an LSP by t he or iginat in g rout ers before t he LSP expires; 900 seconds ( 15 m inut es) is specified ( com pared t o 1200 seconds of m ax age) .

•

The m inim um LSP ge ne r a t ion int e r va l— This int er val defines t he m inim um int er val bet w een consecut iv e gener at ions of an LSP by a r out er . A v alue of 30 seconds is specified for t his param et er.

The LSP refresh int erval needs t o be less t han m axage t o require a rout er t o periodically gener at e a new er copy of it s LSP int o t he net w or k , ev en w hen t her e ar e no changes t o r epor t , before t he LSP expires. This procedure helps ensure t he cont inued int egrit y of t he LSP t hroughout t he net work. You can use t he I OS com m and lsp -r efr esh-int erval t o m odify t he r efr esh int er val. Set t ing t his t im er r easonably high helps cut dow n on bandw idt h over head and saves processing r esour ces. Exer cise caut ion w hen set t ing t he r efr esh int er val. I f set t oo high, you m ight significant ly inhibit expedient r em oval of incor r ect link-st at e inform at ion from t he net w or k .

M in im u m LSP Tr a n sm ission I n t e r va l The m inim um LSP t r ansm ission int er val specifies t he m inim um int erval bet ween consecut ive t r ansm issions of t w o LSPs. The default is 33 m illiseconds. The r elat ed I OS com m and for m odifying t he set value is isis lsp- int erva l. As discussed in t he sect ion on point -to-point flooding, t he reliable flooding m echanism r equir es a r out er t o r et r ansm it LSPs ont o point -to-point links unt il it r eceives an acknowledgm ent from t he neighbor. The int erval bet ween ret ransm issions is t he r et r ansm ission int er val and is set at a default value of 5 seconds. You can u se t he I OS com m and isis ret ra nsm it - in t e r va l t o m odify t he LSP r et r ansm ission int er v al t o a m or e desir able v alue.

CSN P I nt e r va l The CSNP int erval relat es t o t he periodic t ransm ission of CSNPs by t he DI S on a broadcast m edium . The default value is 10 seconds . The I OS com m and isis csnp- in t e r va l enables y ou t o m odify t his default . I f t he rout ers on a broadcast link are fairly st able, an operat or m ight decide t o incr ease t he CSNP int er val so t hat CSNPs ar e adver t ised less fr equent ly, t her eby conser v ing link bandw idt h .

131

Table 5 - 7

list s t he t im er s discussed in t his sect ion, providing default values and t he relevant

Cisco I OS com m ands for m odifying t hem .

Table 5 - 7 . I S- I S D a t a ba se Tim e r s

Tim er

D e fa ult Va lue Maxage 1200 seconds LSP refresh int erval 900 seconds LSP t ransm ission int erval 33 m illiseconds LSP ret ransm it int erval 5 seconds CSNP int erval 10 seconds

isis isis isis isis isis

I OS Com m a nd m a x - lsp- in t e r va l lsp- r e f r e sh- in t e r v a l lsp- in t e r va l r e t r a n sm it - in t e r va l csnp- in t e r v a l

More About the IS-IS Link-State Database The previous sect ions re view com ponent s of t he I S-I S Link-St at e dat abase and discuss flooding m echanism s designed t o opt im ize Link-St at e dat abase synchronizat ion on various m edia. I n a st able I S-I S net w ork, usual rout ing-r elat ed act iv it ies include sending and r eceiv ing hello packet s t o m aint ain adj acencies, periodic advert ising of CSNPs on broadcast links, and t he r efr eshing of LSPs. Net w or k inst abilit ies t r igger dynam ic disr upt ions, w hich w hen ext ensive result in a deplet ion of processing and bandw idt h resources and ult im at ely m e lt dow n of t he net w or k. This sect ion looks at t he oper at ion and m aint enance of t he I S-I S dat abase and discusses som e st abilit y and perform ance -r elat ed issues per t aining t o t hese act ivit ies.

IS-IS Link-State Database and Network Stability Aft er init ial flood ing and sy nchr onizat ion of t he Link-St at e dat abase, t he net w or k becom es r elat iv ely quiet . LSPs ar e gener at ed and flooded only w hen a change occur s in a r out er 's environm ent , which creat es corresponding changes in t he TLVs cont ained in it s LSP. I S-I S r ou t ers use only a single LSP t o r epr esent t he r out er 's im m ediat e envir onm ent , and t he LSP can be fr agm ent ed if necessar y. A TLV cont ent change r esult s in gener at ion and flooding of t he ent ir e LSP w it h appr opr iat e m odificat ions. The follow ing event s can t r igger regenerat ion of a new LSP:

•

I S-I S adj acency flap

•

I P int er face flap

•

Change in int erface m et ric

• •

Changes int erarea rout es Changes in redist ribut ed ( ext ernal) rout es

Any occur r ence of t he list ed ev ent s com pr om ises t he pr ev iously issued LSP and r equir es a new LSP t o be gener at ed t o r eplace t he old one.

I S- I S Lin k- St a t e D a t a ba se I n t e gr it y I ssu e s

132

The int egr it y of t he Link-St at e dat abase is cr it ical t o t he oper at ion of t he I S-I S pr ot ocolin gener al and specifically for calculat ing accur at e r out ing infor m at ion t o pr event cost ly r out ing loops. Dat abase synchr onizat ion and per iodic LSP r efr esh ar e key m echanism s for ensur ing t he int egr it y of t he Link-St at e dat abase. This sect ion discusses ot her auxiliary m echanism s t hat direct ly or indirect ly help guarant ee t he reliabilit y of t he inform at ion in t he dat abase. I t also cover s t he m echanism s for discover ing duplicat e SysI Ds and det ails t he use of t he Sequence Num ber and Check sum fields.

LSP Ch e ck su m The I S-I S prot ocol does not rely on t he dat a -link cyclic r edundancy check ( CRC) t o guarant ee t he LSP int egrit y. I nst ead, I S-I S r out er s use a check sum v alue calculat ed ov er a gr eat er par t of t he LSP t o ensur e t he int egr it y of t he cont ent s of any LSP. The checksum is calculat ed fr om t he Sy sI D field t o t he end of t he LSP and is inser ted int o t he header by t he or iginat or of t he LSP. The LSPs m ight be corrupt ed w hile sit t ing in m em ory; t herefore, it is necessary t o check t he validit y of LSPs befor e flooding t hem dur ing r efr esh. When a node r eceives an LSP, it checks t o m ake sure t hat t he LSP w as not cor r upt ed in t r ansm ission befor e it inst alls a copy in t he local dat abase and r efloods copies t o ot her neighbor s. I t is com m on know ledge t hat in cert ain net w orking environm ent s, t ypically w here Fram e Relay t o ATM conver sion sw it ches ar e used, LSPs ar e easily cor r upt ed w hen flooded fr om one end of t he net w or k t o t he ot her . The st andar d pr ocedur e for handling a cor r upt ed LSP at a r eceiving node is t o not only discar d it but also t o at t em pt t o pur ge it fr om t he ent ir e net w or k . To init iat e a pur ge, a r out er set s t he Rem aining Lifet im e field of t he LSP t o zer o and floods it t o int o t he net w or k. Event ually, t he ow ner or or iginal sour ce of t he LSP r eceives a copy of t he LSP being purged. The ow ner t hen reissues a new er copy back int o t he net w ork. I f t he m edia pr oblem r em ains, a sit uat ion of cont inuous flooding and pur ging of m any LSPs in t he net w or k occur s, a net w or k sit uat ion r efer r ed t o as an LSP corrupt ion st orm . LSP corrupt ion st orm s consum e net w ork resources, cause t rem endous net w ork problem s, and can pot ent ially disr upt net w or k ser vices. I n gener al, r out er s r eceive copies of an LSP over m ult iple link s; t her efor e, alt hough a cor r upt ed copy m ight com e in ov er one link , a good copy m ight m ake it over anot her link. I t m ight be possible t o obt ain accur at e net w ork inform at ion by ignor ing bad LSPs obt ained ov er a specific pat h in t he net w or k , inst ead of cr eat ing a sit uat ion t hat can det eriorat e t he net w ork. Cisco I OS pr ovides a com m and for configur ing I S-I S r out er s in env ir onm ent s pr one t o LSP corrupt ion s t orm s t o ignore LSP checksum errors. The rout er-level com m and ignore- LSPe r r or s enables Cisco r out er s t o silent ly discar d cor r upt ed LSPs and t o log t he ev ent . On a point -t o-point link, if an LSP is discarded, it is not acknow ledged and t he source ret ransm it s it . On broadcast links, no ret ransm ission occurs; how ever, rout ers event ually discover m issing LSPs from CSNPs advert ised by t he DI S and can subsequent ly request full copies w it h PSNPs.

133

LSP Sequence Number As m ent ioned pr ev iously , t he pr im ar y r ole of t he Sequence Num ber field is t o help ident ify new er LSPs fr om older ver sions. Any t im e t hat a r out er r egener at es it s LSP, eit her because of a r efr esh ( nor m ally ever y 15 m inut es) or a change in t he net w or k, it incr eases t he sequence n u m ber by 1 . An int erest ing phenom enon occur s w hen a r out er cr ashes and r eloads. The r out er 's neighbor s dr op t heir adj acencies, but t hey do not r em ove t he LSP of t he cr ashed r out er fr om t heir dat abases unt il t he rem aining lifet im e reaches a zero value and t he ZeroAgeLifet im e passes . When t he r out er r ecov er s, it gener at es and floods it s LSP w it h an init ial sequence num ber of 1. The neighbor s t hat have t he sam e LSP w it h a higher sequence num ber t hen flood t heir copies t o t he r eboot ed r out er , t hink ing t heir LSPs ar e new er because of t he higher sequence num ber . Upon det ect ing a sequence num ber m ism at ch of it s ow n LSP, t he r eloaded r out er issues y et anot her copy of t he LSP w it h a sequence num ber gr eat er by 1 t han t he highest sequence num ber value in t he LSPs received from neighbors. This process rest ores t he rout er close t o it s sequence num ber v alue befor e t he r eboot .

Duplicate System IDs The fundam ent al obj ect ive of addressing is t o achieve unique ident ificat ion of t he addr essed elem ent s. I n conform ance w it h t his ideal, I S-I S does n ot t oler at e duplicat e addr esses. I n discussing I S-I S addressing concept s,

Chapt er 4 ,

" Addressing in I nt egrat ed I S-I S," not es t hat

bot h I P addr esses and I SO NSAP addr esses need t o be configured on I S-I S rout ers even in I Ponly envir onm ent s. As discussed in t he sect ion on I P addr essing in Chapt er 1 , " Over view of I P Rout ing," I P addr esses ar e m ade unique by defining unique I P subnet s for t he links in t he net w or k and assigning unique host addr esses t o t he int er faces of devices t hat connect t o links. However, t he node -based addr essing schem e used in I SO CLNP and adopt ed by I nt egr at ed I SI S assigns a globally unique addr ess t o each net w or k dev ice in a dom ain. Wit hin an ar ea, a node's NSAP is m ade unique by it s unique SysI D com ponent of t he NSAP. The unique SysI D also for m s par t of t he LSP I D, pr ov iding a m eans t o differ ent iat e bet w een LSPs in t he LinkSt at e dat abase . To sim plify operat ions, service providers use dom ainw ide unique SysI Ds —ev en t hough in a t w o -lev el net w or k w it h m any ar eas, it is possible t o hav e Lev el 1 nodes in separ at e ar eas share t he sam e SysI D provided t hey do not connect t o t he I S-I S back bone ( Level 2) . A unique SysI D is, however, required for each node in single -level ( Level 1 -only or Level 2 -only ) r out ing dom ains and is highly r ecom m ended for hier ar chical dom ains w it h m any ar eas. You can easily achieve t his by using unique I P loopback addresses o n t he rout ers t o creat e SysI Ds ( as discussed in Chapt er 4 ) . Using dom ainwide unique SysI Ds in m ult i-area net w orks provides advant ages in net w ork operat ions involving device m ana gem ent , t r oubleshoot ing, and m aint enance. Obviously, I S-I S oper at ions ar e ser iously im pact ed in scenar ios in w hich t w o or m or e r out er s in t he sam e area or connect ed t o t he backbone share t he sam e SysI D. First , t his m eans assigning t he sam e NSAP or NET t o them if t hey ar e in t he sam e ar ea; second, t his m eans

134

m ix ing up t heir LSPs, r egar dless of w het her t hey ar e in t he sam e ar ea or connect ed t o t he backbone. Each rout er encloses inform at ion specific t o it s rout ing environm ent int o it s LSP — t hat is, it calculat e s and ent er s a checksum on infor m at ion in t he LSP header . When t he LSPs ar e m ix ed up, t he sour ces see a differ ent check sum t han ex pect ed on w hat look s lik e t heir LSPs. Suspect ing a corrupt ed LSP, each rout er issues anot her copy w it h a higher sequence n u m ber and floods it out int o t he r est of t he net w or k. Sim ilar act ivit y occur r ing on ot her r out er s w it h duplicat e addr esses cr eat es a sit uat ion of cont inuous r egener at ion and pur ging of t he LSPs w it h duplicat e I Ds. This sit uat ion undoubt edly result s in net work inst abilit y. I f a r out er det ect s t hat anot her device m ight be shar ing it s Sy sI D, it gener at es an er r or sim ilar t o t he follow ing:

%CLNS-4-DUPSYSTEM: ISIS: possible duplicate system ID 0000.0000.0002 detected

Summary This chapt er cov er s one of t he k ey under lying concept s of t he I S-I S rout ing prot ocol: t he I S-I S Lin k-St at e dat abase. First , t he funct ional organizat ion of t he I S-I S Link-St at e dat abase is discussed. I n support of t he t wo -lev el r out ing hier ar chy , each r out er suppor t s a Lev el 1 and a Level 2 dat abase for Level 1 and Level 2 rout ing, respect ively. Subsequent discussions in t he chapt er focus on elem ent s st or ed in t he dat abase ( LSPs) and t he associat ed cont r ol pr ocesses and elem ent s t hat help in building and m aint enance of t he dist r ibut ed Link-St at e da t abase. Sequence num ber packet s ( CSNP and PSNP) and var ious t im er s used in r elat ed cont r ol pr ocesses ensur e t he int egr it y and consist ency of t he LSPs st or ed in t he Level 1 and Level 2 Lin k-St at e dat abases across m ult iple rout ers. Each Lev el 1 dat abase describes t he t opological organizat ion of t he corresponding area in t he dom ain, w her eas a single Level 2 dat abase capt ur es t he over all layout of t he Level 1 ar eas in relat ion t o each ot her. Consequent ly, all t he rout ers in an area build t he sam e Level 1 dat aba se for t he ar ea and at t ain a consist ent view of t he int r a -ar ea t opology. I n a sim ilar m anner, Level 2 rout ers connect ing t o t he backbone build ident ical Level 2 dat abases. This is a crit ical requirem ent for each rout er t o calculat e loop -fr ee pat hs t o all know n dest inat ions in t he net w or k. Each r out er feeds t he infor m at ion in t he Link-St at e dat abase as input t o t he SPF algor it hm for com put at ion of best pat hs.

Chapt er 6

provides de t ailed cover age of t he SPF

algorit hm . LSP copies ar e dist r ibut ed in t he Lev el 1 ar eas and t he back bone by a m echanism r efer r ed t o as flooding. Cont rol m echanism s involving CSNPs, PSNPs, SRM and SSN flags, and various t im er s ar e em ploy ed t o assist flooding of LSPs and sy nchr onizat ion of t he Link-St at e dat abase bet w een r out er s. This chapt er cov er s pack et for m at s of LSPs, CSNPs, and PSNPs, pr ov iding det ails about fields in t he header s, as w ell as t he TLVs suppor t ed by t hese pack et s. Flooding oper at ions ar e dis cussed and elabor at ed on for point -t o-point and br oadcast links and r ecom m endat ions ar e

135

m ade for dealing w it h NBMA link s. Mesh gr oups pr ov ide an alt er nat iv e for handling ex cessiv e and redundant flooding in highly m eshed NBMA environm ent s. This chapt er also covers I S-I S m et rics, not ing t hat m et ric inform at ion is carried in specific LSP TLVs. The I S-I S pr ot ocol suppor t s four t ypes of m et r ics, of w hich only t he default m et r ic is im plem ent ed by m ost rout er vendors, including Cisco Syst em s. The m et rics discussion review s r ecent ex t ensions t o t he I S-I S prot ocol w it hin t he I ETF t o support larger m et ric values. These m et ric-r elat ed enhancem ent s ar e designed t o over com e lim it at ionsof t he default m et r ic, w hich w as or iginally specified t o hav e a m ax im um of only 63 per int er face and 1023 for an ent ir e pat h. The Ext ended I S Reachabilit y and Ext ended I P Reachabilit y TLVs, which were recent ly pr oposed in t he I ETF, ar e designed t o addr ess t hese lim it at ions. I n gener al, oper at ion of r out ing pr ot ocols is aut om at ed and guided b y m any prot ocol t im ers. The I S-I S pr ot ocol has it s fair shar e of t im er s ( as indicat ed pr eviously in r elat ion t o t he LinkSt at e dat abase) . This chapt er concludes w it h an ov er v iew of v ar ious cr it ical t im er s, w hich ar e k ey t o t he oper at ion of I S-I S an d ar e u lt im at ely responsible for rout ing st abilit y.

Review Questions

1:

What t ype of inform at ion is st ored in an Link- St at e dat abase, and how is t his inform at ion collect ed?

2:

Describe t he use of t he Link- St at e dat abase in I S- I S.

3:

What is t he difference bet ween Level 1 and Level 2 Link- St at e dat abases?

4:

What is t he m eaning of Link- St at e dat abase synchronizat ion?

5:

Describe t he general form at of a link- st at e pack et .

6:

List t he four fields in t he LSP header t hat adequat ely describe t he LSP.

7:

What are TLVs?

8:

List fiv e TLVs t hat carry m et ric inform at ion and where t hey are originally specified.

9:

What is t he form at of t he LSP I dent ifier ( LSPI D) ? Give an exam ple.

10:

Nam e t he t ypes of m et ric inform at ion specified by I SO 10589.

11:

What are t he lim it at io ns of t he default m et ric specified by I S0 10589?

12:

How are t he m et ric lim it at ions of I SO 10589 addressed by TLVs Type 22 and Type 135 recent ly proposed in t he I ETF I S- I S Working Group?

13:

What are sequence num ber packet s? List all t ypes.

14:

What ar e I S- I S m esh groups?

136

15:

What is m axage and m axim um LSP regenerat ion int erval? List t he Cisco I OS com m ands t hat can be used t o change t heir v alu es.

16:

Can t wo rout ers in t he sam e area have t he sam e syst em I D? Briefly describe what happens when t wo rout ers in t he sam e area are configured wit h t he sam e sy st em I D.

References dr aft -iet f-isis -h m ac-00.t xt : I S-I S HMAC-MD5 Aut hent icat ion http: / / search.ietf.org/ internet- drafts/ draft- iet f- isis- traffic- 02.txt

I ETF RFC 2763, " Dynam ic Host nam e Exchange Mechanism for I S-I S." N. Shen, H. Sm it . 2000. http: / / www.ietf.org/ rfc/ rfc2763.txt?num ber= 2763

I ETF RFC 2973, " I S-I S Mesh Groups." R. Balay, D. Kat z, J. Par k er . 2000. http: / / www.ietf.org/ rfc/ rfc2973.txt?num ber= 2973

I SO 10589, " I nt erm ediat e Syst em t o I nt erm ediat e Syst em I nt raom ain Rout ing Exchange Pr ot ocol" for use in conjunct ion w it h t he pr ot ocol for pr oviding t he connect ionless-m ode net w or k ser vice ( I SO 8473) . I SO/ I EC. 1992. Also r epr int ed as RFC 1142, " OSI I S-I S I nt ra dom ain Rout ing Pr ot ocol." Edit or D. Or an. 1990. Perlm an, Radia. I nt erconnect ions, Second Edit ion: Bridges, Rout ers, Swit ches and I nt ernet working Prot ocols. Addison-Wesley, 1991. I SBN 020-1634481 RFC 1195, " Use of OSI I S-I S for Rout ing in TCP/ I P and Dual Environm ent s." Ross Callon. 1990.

137

Chapter 6. The Shortest Path First Algorithm The essence of a r out ing pr ot ocol is t o collect r out ing infor m at ion about t he net w or k ing envir onm ent and t o det er m ine t he best pat hs t o all know n dest inat ions. As discussed in Chapt er 2,

"I ntrodu ct ion t o t he I S-I S Rout ing Pr ot ocol," t hese funct ions ar e per for m ed by t w o

pr ocesses w it hin t he ar chit ect ur e of t he I S-I S pr ot ocol: t he updat e pr ocess and t he decision pr ocess. The updat e pr ocess is r esponsible for building t he I S-I S dat abase and ensur ing it s int egrit y. The decision process uses t he short est pat h first ( SPF) algorit hm t o calculat e t he best pat hs t o all k now n dest inat ions based on t he infor m at ion in t he Link-St at e dat abase. The SPF algor it hm w or k s by com put ing t he shor t est pat h t r ee fr om a specific node t o all ot her nodes in t he ar ea, t her eby, yielding t he best r out es t o ever y know n dest inat ion fr om t hat par t icular sour ce. The SPF algor it hm is nam ed aft er t he Dut ch m at hem at ician, Edsger Wy be Dij k st r a and is also k now n as Dij kst ra's algorit hm . E. W. Dij kst r a w as bor n in Rot t er dam , Net her lands in 1930, w her e he st udied physics and m at hem at ics and lat er becam e a r enow ned com put er scient ist . Dij kst ra discovered t he SPF algorit hm in 1956, w hile researching an algorit hm t o assist in finding t he best w ay t o t r avel bet w een t w o point s. Refer r ing t o it as t he short est subspanning t ree algorit hm , Dij kst ra used his discovery t o solve t he problem of dist ribut ing elect ric current t o all essent ial cir cuit s of an ear ly com put er design, in a m anner t hat opt im iz ed usage of expensive copper w ir e. This chapt er focuses on t he I S-I S rout e calculat ion process and operat ion of t he SPF algorit hm . The m at erial in t his chapt er is organized int o t he follow ing sect ions:

•

Over view of t he SPF algor it hm

• •

Calculat ing I S-I S r out es w it h t he SPF algor it hm I S-I S SPF operat ion on Cisco rout ers N OTE

The Open Short est Pat h First ( OSPF) prot ocol is anot her rout ing prot ocol t hat ut ilizes t he Dij kst ra algorit hm for rout e calculat ion. OSPF is sim ilar t o I S-I S in m any r egar ds, ev en t hough t hey fundam ent ally differ in design and archit ect ure.

Overview of the SPF Algorithm The SPF algor it hm is one of t w o popular algor it hm s em ployed by r out ing pr ot ocols for best pat h det erm inat ion. The ot her is t he Bellm an-Ford algorit hm , w hich is m ore frequent ly used in dist ance -vect or rout ing prot ocols. A basic difference bet ween t he Bellm an-For d algor it hm and t he SPF algor it hm is t hat in t he for m er , each node bases it pat h calculat ion on k now ledge of t he cost t o all dir ect ly connect ed neighbor s plus t he adver t ised cost s for rout es heard from t hese neighbor s. I n cont r ast , t he SPF algor it hm r equir es each node t o have com plet e infor m at ion about t he ent ir e t opology. All nodes inside an ar ea, t her efor e, obt ain an ident ical

138

Lin k-St at e dat abase for t he ar ea. The Link-St at e dat abase cont ains t he link-st at e inform at ion of all nodes w it hin t he ar ea ( t hat is, t he link-st at e packet s fr om each node in t he ar ea) . An adv ant age of r out ing pr ot ocols based on t he SPF algor it hm ov er t hose based on t he Bellm an-For d algor it hm is t hat t hey ar e less suscept ible t o r out ing loops. Pr ot ocols based on t he Bellm an-For d algor it hm ar e easily suscept ible t o loops because t he r out er s depend on infor m at ion fr om neighbor s, w hich m ight no longer be useful aft er a failur e. Such pr ot ocols, t her efor e, use elaborat e hold -dow n m echanism s, and ot her pr ocedur es, such as split -horizon, poison r ever se, and count -t o-infinit y, t o prevent loops. The hold -dow ns result in t he long conver gence t im es associat ed w it h Bellm an-Ford based prot ocols, which are t ypically distance vect or r out ing pr ot ocols. Link-st at e rout ing prot ocols converge fast er because each node recalculat es rout ing inform at ion based on receipt of changed link-st at e packet s ( LSPs) , and LSPs ar e im m ediat ely gener at ed and flooded out w hen changes occur. How ev er , SPF-based prot ocols are m ore resource -int ensiv e, w it h each r out er r equir ing m or e m em or y t o hold t he Lin k-St at e dat abase and m ore processing capacit y t o run t he SPF algorit hm .

Basics of Graph Theory Dij kst r a's algor it hm pr ovides a gener ic solut ion t hat is applicable t o any pr oblem t hat can be m odeled as a dir ect ed gr aph ( digr aph) . A dir ect ed gr aph consist s of a set of v er t ices ( nodes) int er connect ed by a set of dir ect ed edges or ar cs ( link s) . I n t he sam ple gr aph show n in Figure 6 1,

v er t ices ar e t he num ber ed cir cles and can be r epr esent ed by t he set { 1, 2, 3, 4, 5} . An ar c

is an or der ed pair of v er t ices. For ex am ple, t he ar c bet w een v er t ex 1 and 2 is t he ar r ow point ing fr om ver t ex 1 t o ver t ex 2, w hich is r epr esent ed as ( 1, 2) . Tw o ar cs bet w een ver t ices 2 and 3 point in opposit e dir ect ions. These ar e r epr esent ed as ( 2, 3) and ( 3, 2) and cor r espond t o t he dir ect ion of t he link s bet w een v er t ex 2 and 3. Figur e 6 - 1 . A dir e ct e d gr a ph .

The set of ar cs in

Figure 6 - 1

can t herefore be represent ed as { ( 1, 2), ( 1, 3) , ( 2, 3) , ( 2, 4) , ( 3,

2) , ( 3, 4) , ( 4, 5) , ( 5, 3) } . The set of v er t ices and set of ar cs can be assigned let t er ed nam es as follow s:

139

N = { 1, 2, 3, 4, 5} , for t he set of v er t ices L = { ( 1, 2) , ( 1, 3) , ( 2, 3) , ( 2, 4) , ( 3, 2) , ( 3, 4) ( 4, 5) , ( 5, 3) } , for t he set of ar cs The gr aph can be nam ed G and r epr esent ed as G = ( N, L) , w her e N is t he set of v er t ices and L is t he set of ar cs. A pat h is a sequence of sim ilar ly dir ect ed ar cs bet w een any t w o v er t ices in a gr aph. I n 1,

Figure 6 -

for exam ple, t he pat h from vert ex 1 t o vert ex 4 can be eit her t he sequence ( 1, 2 ) , ( 2, 4) , or

( 1, 3) , ( 3, 2) , ( 2, 4) . The obj ect ive of t he SPF algor it hm is t o det er m ine t he shor t est pat h fr om any r efer ence ver t ex, s, t o all ot her ver t ices in t he gr aph. The SPF algor it hm uses an it er at ive m echanism t o solve t he problem . The next sect io n show s t he oper at ion of t he SPF algor it hm for a dir ect ed gr aph r epr esent ed by G = ( N, L) , given a fixed vert ex, s, in t he set N w here

•

N — Set of vert ices

• •

L— Set of ar cs d( i, j ) — Dist ance from vert ex i t o j , where - d( i, j ) = infinit y, if vert ices i and j a re not direct ly connect ed

•

P— Set of ver t ices w hose shor t est pat hs fr om t he r efer ence ver t ex have alr eady been det er m ined

•

L( n) — Current least cost from vert ex s t o vert ex n

The algorit hm det erm ines t he short est pat h from reference vert ex s t o each vert ex n in t he gr aph. I n gener al, t hr ee m ain st eps ar e inv olv ed in t he pr ocess: 1.

I nit ializat ion

2.

Select ion of t he nex t v er t ex

3.

Updat e of least cost pat hs

Operation of the SPF Algorithm The t hr ee pr im ar y st eps in t he oper at ion of t he SPF algor it hm ar e elabor at ed as fo llow s: St e p 1 . Set i = 0,P0 = { v0 = s} , L( s) = 0. L( n) = d( s, n) if n is direct ly connect ed t o s. L( n) = infinit y for n not direct ly connect ed t o s. Label each node n w it h [ L( n) ,s] . set i = 1. St e p 2 . Find t he next ver t ex vi not in P, w hich has L( vi) = m in L( n) , for all vi} . Move vi t o P. New vert ex is vi.

140

St e p 3 . Updat e least cost pat hs of v er t ices not in P: L( n) = m in{ L( n) , L( vi) + d( vi,n) } . I f L( n) is r eplaced, updat e label on n t o [ L( n) , NH( vi) ] , w her e NH( vi) is t he next hop t o vi fr om S. Replace i by i+ l, ( i = i+ l) . I f i = N- i, st op; ot her w ise go t o St ep 2. St ep 1 is t he init ializat ion st age. Because t he algor it hm is it er at iv e, it pr oceeds in st ages, w it h each st age denot ed by t he value of i. At t he init ializat ion st age, i is set t o 0. The com put at io n is per for m ed r elat ive t o a r efer ence ver t ex, s. The r efer ence ver t ex is also know n as t he sour ce. Thr ee separ at e list s ar e used in t he oper at ion of t he algor it hm : Un k n ow n ( U) — Set of v er t ices t hat hav en't been consider ed y et Te nt a t ive ( T) — Set of vert ices under considerat ion Pa t h s ( P) — Set of ver t ices t o w hich t he shor t est pat h has been com put ed At init ializat ion ( i = 0) , t he r efer ence ver t ex, v0 = s, is select ed and placed in t he set of know n closest ver t ices ( P)—t hat is, P0 = { v 0 = s} . The r est of t he ver t ices in t he gr aph ar e placed in set U. The cost of s t o it self, L( s) , is 0. The cost s fr om s t o dir ect ly connect ed ver t ices ar e set t o t heir know n values, w her eas cost s for ver t ices t hat ar e not dir ect ly know n ar e consider ed unk now n and, t her efor e, set t o infinit y. I n St ep 2, t he algor it hm det er m ines t he next closest ver t ex t o s fr om t he set T, not es t he associat ed cost and it s next hop, and t hen pr om ot es it t o t he set P. I nit ially, only t he ver t ices dir ect ly connect ed t o s ar e m ov ed fr om t he U set t o T for consider at ion. The ver t ex w it h t he low est cost is pr om ot ed t o t he set P. When a v er t ex is pr om ot ed fr om T t o P, all nodes dir ect ly connect ed t o it ar e t hen placed in T for consider at ion, if t hey ar e not alr eady t her e. I n t he final st ep, t he least cost associat ed w it h ev er y node in T is updat ed r elat iv e t o t he m ost r ecent ver t ex pr om ot ed t o P and t he next hop is also changed t o t hat of t he pr om ot ed ver t ex. An exist ing least cost value is replaced only if t he new valve is low er. The algor it hm t hen pr oceeds t o t he next it erat ion by going t o St ep 2 and cont inues t hrough St ep 3 again, unt il ev er y node has been m ov ed t o t he set P. For a gr aph w it h N v er t ices, including t he reference vert ex at w hich t he calculat ion is cent ered, N-1 it er at ions exist st ar t ing at 0. At t he end of t he ( N-1) it erat ion, t he com put at ion provides t he short est dist ance from t he r efer ence t o all ot her v er t ices in t he gr aph.

141

The det er m inat ion of t he shor t est pat h bet w een any t w o v er t ices in a digr aph is analogous t o finding t he shor t est pa t h bet w een any t w o nodes in a dat a com m unicat ions net w or k. As not ed ear lier , t he funct ion of r out ing pr ot ocols is t o det er m ine t he shor t est pat h bet w een nodes in a net w or k by som e opt im alit y cr it er ia, fr equent ly t he least cost or low est m et r ic. I n a per fect analogy, t he r out er s in a com m unicat ions net w or k cor r espond t o t he ver t ices of a digr aph, and t he links or adj acencies cor r espond t o t he ar cs. Because t he t r affic flow bet w een net w or k nodes is bidir ect ional, each net w or k link cor r esponds t o a pair of parallel ar cs facing opposit e dir ect ions. The link s in a net w or k ar e t y pically assigned w eight ed v alues r efer r ed t o as cost s or m et r ics. Most r eal net w or ks apply scalar link cost s, w hich ar e inver sely pr opor t ional t o bandw idt h. Ther efor e, t he fast est links are assigned sm aller cost v alues. Finding t he shor t est pat h bet w een nodes in a net w ork, t herefore, im plies det erm ining t he least cost pat h bet w een t hem . Ot her possible m et ric opt ions are hop count and com posit e m et rics. Com posit e m et rics ar e based on t he combined evaluat ion of bandwidt h, delay, reliabilit y, load, m axim um t r ansm ission unit ( MTU) , and ot her link char act er ist ics.

Computational Cost of the SPF Algorithm The pr ev ious sect ions descr ibe how t he SPF algor it hm w or k s and indicat e t hat t he com put at ional cost associat ed w it h t he algor it hm depend on t he num ber of nodes and link s involved. The SPF algorit hm can be resource -int ensive for large net w orks w it h t he com put at ion t im e r equir ed r eaching an or der of N^ 2, w her e N is t he num ber of nodes. This or der of com plexit y can be discer ned int uit ively consider ing t hat , for a t ot al of N nodes, N-1 it er at ions ar e r equir ed t o det er m ine all t he least cost pat hs fr om a r efer ence node t o all ot her nodes in t he gr aph. At each it er at ion, t he num ber of oper at ions r equir ed t o det er m ine t he ver t ex w it h t he least cost is pr opor t ional t o N. I f N nodes ar e in a gr aph and t he t ot al num ber of link s in t he gr aph is L, it can be show n t hat , in general, t he SPF com put at ion t im e is proport ional t o t he num ber of links —L t im es t he log o f t he num ber of links, L in t he net w or k. That is t he com put at ional cost of t he SPF of t he or der , O( LlogL) . I n nonhighly m eshed net works —for ex am ple, w her e all nodes ar e int er connect ed w it h t he few est possible link s in a linear ar r angem ent , L equals t o N-1 . LlogL can be ex pr essed as Llog( N-1) , w hich is equiv alent t o LlogN. I n sum m ar y , y ou can est im at e t he or der of com put at ional com plexit y of Dij kst ra's SPF algorit hm t o be O( LlogN) , w here L is t he t ot al num ber of links and N is t he num ber of nodes in t he net w ork. The com put at ional com plexit y is dir ect ly r elat ed t o t he pr ocessing t im e r equir ed for execut ion t o com plet ion of t he algor it hm . Anot her elem ent of int er est in t he oper at ion of t he Dij k st r a algor it hm is st or age or m em or y r equir em ent s.

Memory Requirements Each r out er in t he gr aph st or es N LSPs, one fr om each node in t he ar ea. Because each LSP cont ains infor m at ion about connect ed link s and adj acent neighbor s, t he size of each LSP is pr opor t ional t o K, t he num ber of connect ed links. Ther efor e, each node needs st or age space

142

pr opor t ional t o N* K links. That is, m em or y r equir em ent s at each node is of t he or der O( N* K) or O( L) , w her e L is t he t ot al num ber of links. I n a nonhighly m eshed envir onm ent s, w her e L is of t he sam e or der as t he num ber of nodes ( N) , t he m emory requirem ent s can be est im at ed t o be of t he or der O( N) . Excessive m em ory requirem ent s and t he corresponding high processing t im e of t he SPF algorit hm for large num bers of nodes are t he prim ary drivers for int roducing hierarchy int o t he net work design. I S-I S pr ov ides a t w o -lev el hier ar chy t hat allow s ar ea ex plosion t o be cont ained by building m ult iple r easonably sized Lev el 1 ar eas and gluing t hem t oget her w it h a Lev el 2 back bone.

SPF Calculation Example illust rat es t he operat ion of t he Dij kst ra algorit hm based on t he graph in Figure 6 - 2 . An anim at ion t hat also illust r at es in st ep-t hr ough m anner t he oper at ion of t he Dij kst r a algor it hm Table 6 - 1

is at t he follow ing r efer enced Web sit e:

http: / / ciips.ee.uwa.edu.au/ ~ m orris/ Year2/ PLDS210/ dij kstra.htm l .

Figur e 6 - 2 . Topology for illu st r a t ion of D ij k st r a a lgor it h m .

In

Figure 6 - 2 ,

bidir ect ional ar r ow ed links ar e used for ar cs and t o im ply sam e cost bet w een

adj acent nodes in eit her dir ect ion. This m ight not be t he case in r eal net works. Specifically, I S-I S does not require m at ching m et ric values in bot h direct ions for t he sam e link. The t opology show n in Figure 6 - 2 has fiv e nodes and sev en link s. The algor it hm is per for m ed using node 1 as t he r efer ence node. I n a r eal net w or k , each node per for m s a sim ilar calculat ion by using it self as t he r efer ence. The goal is t o obt ain t he least cost ( best ) pat h fr om t he sour ce of t he calculat ion t o all ot her nodes in t he t opology. The algor it hm is init ialized at i = 0. Colum n i r epr esent s t he it er at ions. L( n) is t he value of t he cur r ent t otal cost fr om s t o node n for a specific it er at ion. " nex t hop" is t he dir ect ly connect ed nex t hop t o get t o a specific node. Ot her abbr ev iat ions in t he t able ar e as follow s:

• •

P— The set of ent r ies in t he Pat hs set or list ( v a lu e ) — Direct ly connect next hop from S

143

Table 6 - 1 . Ex a m ple of D ij k st r a 's Ca lcu la t ion ( s = 1 )

N ode 1 L( 1) , next i P hop 0 { 1} 0 ( 1) 1 { 1, 3} 2 { 1, 3, 2} { 1, 3, 2, 3 4} { 1, 3, 2, 4 4, 5} Table 6 - 1

N ode 2 L( 2) ,next hop 2 ( 2) 2 (2) 2 ( 2)

N ode 3 L( 3) ,next hop 1 ( 3) 1 ( 3) -

N ode 4 L( 4) ,next hop I nfinit y 3 ( 3)

N ode 5 L( 5) , next hop I nfinit y 6 ( 3)

-

-

3 ( 3)

6 ( 3)

-

-

-

5 ( 3)

show s t he pat hs t hat ar e select ed fr om t he Tent at ive set at ever y it er at ion in boldface.

Only Nodes 2 and 3 ar e m ov ed t o t he Tent at iv e set in it er at ion i = 1. Each pat h show s t he m et r ic t o t he dest inat ion and t he nex t hop. The nex t hops fr om node 1 t o nodes 2 and 3 ar e nodes 2 and 3 t hem selv es because t hey ar e dir ect ly connect ed. Nodes t hat ar e not dir ect ly connect ed t o s inher it t he nex t hop of t heir par ent s. For exam ple, t he best pat h t o get t o node 4 is t hr ough node 3 w it h a cost of 3. The best pat h t o node 5 is t hr ough node 4; how ever , t he par ent of node 4 is node 3. Ther efor e, node 3 becom es t he next hop t o get t o node 5 fr om node 1. Not e t hat t he nex t -hop com put at ion expr esses t he dat agr am for w ar ding par adigm , in w hich each node is int er est ed only in t he next hop as it for w ar ds a pack et t ow ar d t he dest inat ion along t he opt im um pat h.

Ex pla n a t ion of Ta ble 6 - 1 ( SPF Ca lcu la t ion Ex a m ple ) The st eps in t he operat ion of t he SPF algorit hm illust rat ed in Table 6 - 1 are explained here. The ex planat ions follow the it er at ions in t he ex am ple.

1 I n t he first it erat ion, node 1 is select ed as t he source, and = corresponding L( 1) = 0 and NH = 1 are ent ered under node 1 t o 0 indicat e t he next hop from t he source t o node 1 is it self, and t he cost is 0. No act ion is t ake n for t he ot her nodes. i I n it erat ion 1, nodes direct ly connect ed t o node 1, which are nodes = 2 and 3, are put int o t he T set . The next hop from node 1 t o node 2 1 is node 2, and t he cost is 2. The next hop from node 1 t o node 3 is node 3 it self, and t he cost is 1. Nodes 4 and 5 rem ain in t he Unknown set and are assigned cost s of infinit y. Node 3 is prom ot ed from T t o P because it has t he lowest cost . i Aft er node 3 is prom ot ed from T t o P, it s direct ly connect ed = neighbors t hat are not yet in P, nodes 4 and 5, are ent ered int o T.

144

2

Not e t hat node 2 is already t here wit h a cost of 2. The pat h from t he source t o node 2 t hrough 3 has a cost of 5, so t he original ent ry is ret ained because it has a lower cost . Nodes 4 and 5 use node 3 as next hop from t he source. The t ot al cost from node 1 t o node 4 is 3, and t he corresponding cost t o node 5 is 6. Node 2 is, t herefore, prom ot ed from T t o P because it has t he lowest cost . i Aft er node 2 is prom ot ed t o P, it s direct ly connect ed neighbors t hat = ar e not yet in P are considered. This happens t o be only node 4, 3 which is already in T. The t ot al cost from node 1 t o 4 t hrough node 2 is 5, so t he previous pat h wit h lower cost is ret ained. Node 4 is prom ot ed t o P because it has a lower associat ed cost t han node 5. i Aft er node 4 is prom ot ed t o P, it s direct ly connect ed neighbors t hat = are not yet in P are considered. This happens t o be only node 5. 5 Node 5 is current ly in T. However, t he cost from node 1 t o node 5 t hrough 4 is lower t han t he previous cost of 6. Therefore, node 4 replaces node 3 as t he parent of node 5. Also, node 5 inherit s t he next hop associat ed wit h node 4, which is coincident ally node 3. The next hop from node 1 t o node 5 rem ains node 3, but t he cost is reduced t o 5. Because node 5 is t he only node in T, it is prom ot ed t o P. Figure 6 - 3

show s t he r esult ing least cost t opology, at t he end of t he algor it hm , as seen fr om t he

per spect iv e of node 1. Nodes 2 and 3 ar e dir ect ly connect ed, but t he best pat h t o node 4 is t hr ough node 3, and t he best pat h t o node 5 is t hr ough node 3 and t hen node 4. Figur e 6 - 3 . Le a st- cost t opology fr om n ode 1 .

Calculating IS-IS Routes with the SPF Algorithm Annex C2 of I SO 10589 specifies use of t he SPF algor it hm for rout e calculat ion w it hin t he I SI S prot ocol. Annex C of RFC 1195 specifies m odificat ions of t he SPF algorit hm for support ing I P r out ing w it hin t he I S-I S pr ot ocol. Dij kst r a's algor it hm cr eat es a shor t est pat h t r ee of t he

145

net w or k t opology, fr om w hich t he short est ( best ) pat hs t o various dest inat ions in t he net work ar e det er m ined and ent er ed int o t he I P r out ing t able. To obt ain best pat hs for I P r out es, I P subnet s ar e consider ed as leaves in t he shor t est pat h t r ee. Ther efor e, net w or k event s result ing in changes in only I P reachabilit y ent ries cont ained in link-st at e packet s do not r equir e com put at ion of t he ent ir e shor t est pat h t r ee. I n such cases, t he I S-I S prot ocol perform s part ial rout e calculat ion ( PRC) rat her t han a full run of t he SPF algorit hm . Th e per v asiv eness of PRC in I S-I S r out e com put at ions opt im izes per for m ance for I P r out ing conver gence in m ost sit uat ions. The pr eceding sect ion indicat es t hat t he com put at ion t im e of t he SPF algor it hm is of t he or der O( LlogN) , w her e L is t he num ber of link s and N is t he num ber of nodes. The logN fact or result s fr om St ep 2 in t he oper at ion of Dij k st r a's algor it hm ( r efer t o Figure 6 - 2 ) . The elem ent s in t he set T are pres or t ed by cost t o av oid t he need for a linear sear ch in select ing t he elem ent w it h t he low est cost . The processing t im e required by t he binary search m echanism used in sort ing T w hile inser t ing new ent r ies int r oduces t he logN fact or . By using a finit e pat h cost based on a 6 -bit field ( as specified by I SO 10589) , it is possible t o fur t her opt im ize and r educe t he or der of com plexit y t o j ust O( N) , elim inat ing t he logN fact or . This is achieved using quick ar r ay sor t dat a st r uct ur es, w hich sor t nodes by hashing t hem according t o pat h cost rat her t han logical dist ance. Unfort unat ely, over t im e, t he 6 -bit m et ric field has proved insufficient for providing flexibilit y in designing I S-I S net w or ks, as w ell as in ot her applicat ions of I S-I S r out ing, such as MPLS t raffic engineering. The adopt ion of larger pat h cost s ( w ide m et rics) in I S-I S ( see Chapt er 5, " The I S- I S Link- St at e Dat abase" )

obviously t akes aw ay t he opt im izat ion opport unit y w it h s m all finit e

pat h cost s ( narrow m et rics) . The m odificat ions t o t he SPF algor it hm int r oduced by RFC 1195 for use in I S-I S r out ing allow s load balancing ov er m ult iple equal-cost pat hs. I n general, how ever, t he Dij kst ra algorit hm w or k s as descr ibed in t he pr eceding sect ion. The oper at ion of t he SPF algor it hm is descr ibed w ell in Annex C of RFC 1195. The follow ing t hr ee list s ar e used in building t he shor t est pat h t ree: Unknow n or candidat e list ( UNK) , Tent at ive ( TENT) list , and know n Pat hs ( PATHS) list . At t he st ar t of t he SPF pr ocess, all nodes ar e placed in t he Unknow n list . The sour ce node is t hen m oved t o PATHS at init ializat ion. Nodes exam ined for candidacy t o t he PATHS list ar e placed in t he TENT list w it h t heir next -hop and m et r ic infor m at ion adj ust ed accordingly. I S-I S m aint ains an adj acency dat abase for all neighbor s, w hich feeds t he SPF pr ocess w it h nex t -hop inform at ion for direct ly connect ed neighbors in t he TENT list . For nondirect ly connect ed host s, t he fir st hop is obt ained fr om t he par ent in PATHS. Ent r ies ar e st or ed in TENT and PATHS as t riple set s, { n, d( n) , Adj ( n) } , where

•

n = Syst em I D

• •

d( n) = Dist ance of n from t he root syst em , s Adj ( n) = Set of valid adj acencies for n know n by s

At each st ep of t he algor it hm , t he TENT list is ex am ined, and t he node w it h t he least cost fr om t he sour ce is m oved int o PATHS. When a node is placed in PATHS, all I P pr efixes adver t ised by it ar e inst alled in t he I S-I S Rout ing I nform at ion Base ( RI B) w it h t he corresponding m et ric and nex t hop. The dir ect ly connect ed neighbor s of t he node t hat j ust m ade it int o PATHS ar e t hen

146

added t o TENT if t hey are not already t here and t heir associat ed cost s adj ust ed accordingly, for t he nex t select ion. Not e t hat I P int er nal and ext er nal pr efixes ar e st or ed as 8 byt es consist ing of t he addr ess and m ask and ar e alw ay s leav es.

IS-IS SPF Operation on Cisco Routers The act ual im plem ent at ion of a pr ot ocol on a specific r out er plat for m is m ost ly t r anspar ent t o t he net work operat or, and int eroperabilit y bet ween product s from different vendors is guided by com pliance t o st andar ds. The det ails of a specific vendor im plem ent at ion and soft w ar e coding also ar e fr equent ly pr opr iet ar y infor m at ion. How ever , a net w or k engineer seeking a bet t er underst anding of I S-I S and t he m echanics of oper at ion on a sp ecific plat form m ight benefit significant ly from st udying various param et ers, such as default t im ers, flags, and ot her default const ant s, and how t hey ar e configur ed. Addit ionally, specificat ions such as I SO 10589 and RFC 1195 provide useful guidance. This sect ion pr ov ides som e insight s int o t he oper at ion of I S-I S, and specifically t he oper at ion of t he SPF algor it hm , on Cisco r out er s. The SPF pr ocess w or k s on Cisco r out er s as descr ibed in t he pr eceding sect ion. Thr ee separ at e list s ( UNK, TENT, and PATH) are used in t he algorit hm for calculat ing t he short est pat h t ree for an ar ea. The com put at ion is based on t he cont ent s of t he Link-St at e dat abase and t he configur at ion of t he r out er s. The SPF algor it hm is execut ed on t he r out e pr ocessor by t he SPF pr ocess, w hich is cont rolled by t he I S-I S decision pr ocess fr om an ar chit ect ur al st andpoint of I S-I S. The decision pr ocess liaises w it h t he updat e pr ocess, w hich m anages t he Link-St at e dat abase. Any changes in t he Link-St at e dat abase t riggers t he SPF process and can r esult in a full r un of t he SPF algor it hm or a PRC. As specified by I SO 10589, t he SPF pr ocess r uns no m or e fr equent ly t han ever y 10 seconds by default . Event s t hat t r igger t he SPF pr ocess can be v iew ed w it h t he com m and show isis spf- log ( see Exam ple 6 - 1 ) . I n a dynam ic envir onm ent , a sequence of consecut ive ev ent s can t ak e place w it hin t he 10 seconds bet w een r uns of t he SPF pr ocess. Only t he fir st t r igger is st or ed in t he SPF event log in cur r ent r eleases of I OS. Som e older I OS releases st ore t he last t rigger. Ex a m ple 6 - 1 show isis spf- log com m a n d

#show isis spf-log Level 2 SPF log When Duration 08:52:29 4

Nodes 72

Count 4

First trigger RTA.00

LSP Triggers TLVCONTENT

On a Cisco 7500 r out er , w it h t he RSP4 pr ocessor , t he dur at ion of t he SPF pr ocess is nor m ally less t han 1 second for a net w or k w it h few er t han 1000 nodes. A 200 MHz pr ocessor , execut ing one inst r uct ion per cycle, per for m s 200 m illion inst r uct ions per second. Consider ing t hat an av er age of appr ox im at ely 100,000 inst r uct ions ar e ex pended per node t o calculat e t he SPF t r ee, t his t r anslat es int o com put ing t he shor t est pat h t r ee for 2000 nodes in a second. Ther efor e, for a r easonably lar ge net w or k of about 500 nodes in a single all Lev el 1 I S-I S ar ea, it t ak es about 250 m illiseconds t o com put e t he shor test pat h t r ee. Not e t hat t his num ber is not a har d figur e, and sever al fact or s, such as t he follow ing, can influence t he out com e:

147

•

Act ual t opology of t he net w ork ( highly m eshed or not ) .

•

Type of operat ing syst em s ( preem pt ive or nonpreem pt ive processing) .

•

Th e act ual num ber of inst ruct ions execut ed per cycle. ( Som e processors can perform t wo inst ruct ions per cycle.)

•

I nher ent opt im izat ions in t he code.

As previously not ed, t he processing t im e required by t he SPF algorit hm is of t he order O( LlogN) , w her e L is t he num ber of links, and N is t he num ber of nodes. The logN fact or exist s because of t he sor t ing of t he TENT list dur ing each it er at ion in t he SPF algor it hm . I n addit ion, t he com plexit y of t he sor t ing pr ocess depends on t he ext ent of int er connect ivit y bet w een nodes. Not e t hat w hen a node m ov es fr om t he TENT list int o t he PATHS list , all dir ect ly connect ed nodes st ill in t he UNK list m ove int o t he TENT list , w her e sor t ing is per for m ed dur ing inser t ion. The ent r ies on t he PATHS list s at t he end of each r un of t he SPF pr ocess ar e only candidat es for t he r out ing t able on t he r out er . The r out e pr ocessor ex pends som e m or e cy cles com par ing t he I S-I S r out es w it h sim ilar r out es ( sam e pr efix es) fr om ot her sour ces, such as BGP, st at ic rout es, OSPF, and so on, and inst alls t he pr efixes fr om t he sour ce w it h low est adm inist r at ive dist ance in t he r out ing t able. The SPF t r ee com put ed by t he Dij kst r a algor it hm consider s t he r out er s as ver t ices w it h I P addr esses adver t ised by t he r out er s as leaves. As a r esult , t he ent ir e shor t est pat h t r ee for net w or k changes r elat ed only t o I P pr efixes does not need t o be recalculat ed. I nst ead, t he rout er runs a part ial com put at ion t o find an alt ernat ive I P prefix if one ex ist s. Also, w hen best pat hs ar e select ed, t w o or m or e sim ilar r out es w it h w or se m et r ics ar e kept as backup elem ent s for use as alt er nat ive r out es in case t he select ed pr im ar y goes aw ay . This allow s Cisco I OS t o quick ly find an alt er nat iv e pat h w hen any r out e change occur s. Because t he t opology of t he net w ork is det erm ined by t h e adj acencies adver t ised in t he LSPs, t he loss of an adj acency im plies a change in t opology and, t her efor e, subsequent scheduling of a com plet e SPF r un. When a point -t o-point link goes dow n, for ex am ple, a r out er loses t he adj acency t o t he neighbor at t he ot her end. This signals a change in t opology and, t her efor e, scheduling of a full SPF. How ev er , a br oadcast int er face, such as Et her net , m ight hav e only an I P subnet connect ing t o I P w orkst at ions, so losing t hat int erface can im ply losing only t he I P subne t and not necessar ily an adj acency because t her e m ight not be anot her I S-I S r out er on t he link . Because t he I P subnet is only a leaf of t he SPF t r ee, t his does not flag a change in net work t opology, and, t herefore, only PRC is run t o find an alt ernat ive pa t h . The t hr ee cost ly act ivit ies for t he r out e pr ocessor of an I S-I S rout er are SPF, PRC, and LSP generat ion. Delays are em ployed bet w een successive occurrences of any of t hese act ivit ies t o help cont rol processor ut ilizat ion. The init ial w ait and m inim um int er val bet w een successive r uns of t he SPF and PRC pr ocess and consecut ive LSP t r ansm issions over t he sam e link ar e show n in

Table 6 - 2 .

Table 6 - 2 . D e la ys Be t w e e n Pr oce ssin g- I nt ensive I S- I S Eve nt s

Pr oce ss

I nit ia l W a it ( se conds)

I nt e r va l ( se conds)

148

SPF PRC LSP generat ion

5.5 2 0

10 5 5

An LSP is gener at ed and flooded as soon as possible w it hout any delay. How ever , an int er val of at least 5 seconds occur s bet w een t w o consecut iv e LSPs. When a r out er r eceiv es an LSP, w hich indicat es an adj acency change, a 5.5 -second delay is im posed before runn ing t he SPF pr ocess. Per iodic SPF r uns ar e scheduled at least 10 seconds apar t . Running of t he SPF pr ocess st alls t r ansm ission, as w ell as pr ocessing of LSPs r eceived fr om neighbor s. Because PRC runs are involved only w it h calculat ing leaf inform at ion, t he y ar e held up w hen a full SPF is scheduled. This is because a new t opology m ight em er ge aft er r unning t he full SPF pr ocess, w hich m ight im pact t he I P pat h r esolut ion. Cisco I OS pr ovides com m ands t o m odify t he default int er vals, show n in Table 6 - 2 . You can use t he following com m ands t o m odify t he SPF int e rval, PRC int erval, and LSP generat ion int erval, respect ively:

•

isis spf- in t e r va l

• •

isis prc- in t e r va l

Chapter 7 ,

isis lsp- g e n- in t e r va l " General Net work Design I ssues," discusses ne t work design recom m endat ions for t he

I S-I S pr ot ocol and cov er s in -dept h adj ust m ent of t hese t im er s t o pr ovide opt im al per for m ance of t he I S-I S prot ocol. Also, a recent I ETF draft st udies convergence charact erist ics of I S-I S im plem ent at ions and recom m ends changes in t he current specificat ions and im plem ent at ion appr oaches t o at t ain convergence t im es in t he order of m illiseconds rat her t han t he order of seconds achievable t oday.

Summary This chapt er int roduces t he reader t o t he t heoret ical foundat ions of t he SPF algorit hm . I t explains how t he SPF algorit hm calculat es rout es in I S-I S and pr ov ides an ov er v iew of how SPF oper at es on Cisco r out er s r unning I S-I S. The SPF algor it hm is nam ed aft er it s inv ent or , Dut ch m at hem at ician and com put er scient ist Edsger W. Dij k st r a. SPF is used in conj unct ion w it h t he gr aph t heor y t o find t he shor t est pat h bet w een t w o point s. This innov at ion is used w it h num er ous applicat ions, and cer t ainly use in dat a com m unicat ions net w or ks for pat h det er m inat ion is one of t hem . The r out er s and links ( adj acencies) in a com m unicat ions net w or k can be m odeled as t he v er t ices and ar cs of a dir ect ed gr aph, and t he Dij kst r a algor it hm can be used t o calculat e t he best pat hs bet w een nodes in t his m odel. The I S-I S prot ocol uses t he Dij kst ra algorit hm in t his m anner t o det erm ine t he best rout es in a net w ork. Wit hin t he I S-I S ar chit ect ur e, t he updat e pr ocess is r esponsible for t he building and m aint enance of t he Link-St at e dat abase w hereas t he decision process uses t he inform at ion in t he dat abase t o calcu lat e r out es. The SPF algor it hm is at t he cor e of t he oper at ion of t he decision pr ocess. On Cisco r out er s, t he I S-I S SPF process runs t he SPF algorit hm t o calculat e

149

I S-I S r out es. The pr ocessing t im e associat ed w it h t he SPF algor it hm depends on t he num ber o f nodes and links in t he net w or k; gener ally, it is of t he or der O( LlogN) , w her e L is t he num ber of link s, and N is t he num ber of nodes. The Dij k st r a algor it hm builds a shor t est pat h t r ee of t he r out er s in t he net w or k based on adj acency infor m at ion adv er t ised in I S-I S link-st at e packet s. I P pr efixes adver t ised by r out er s ar e gr aft ed int o t he SPF t r ee as leaves. Any adj acency changes t r igger a com plet e r ecalculat ion of t he shor t est pat h t r ee ( t hat is, a full r un of t he SPF pr ocess) . Only a par t ial r out e calculat ion is perform ed for changes in only I P infor m at ion.

Review Questions

1:

What is t he basic applicat ion of t he SPF algorit hm ?

2:

What is a direct ed graph, and how is an int ernet work m odeled as a direct ed graph?

3:

Nam e the three list s used in t he operat ion of t he Dij kst ra algorit hm for com put ing I S- I S r out es.

4:

What is t he est im at ed processing cost of t he Dij kst ra algorit hm ?

5:

What is t he difference bet ween a full SPF and a part ial rout e calculat ion ( PRC) ?

References Alaet t inoglu, et al. " Towards Millisecond I ETF Convergence." Dr aft -alaet t inoglu -isis convergence -00.t xt . I ETF I NTERNET DRAFT. 2000. Chart rand, Gary. I nt roduct ion t o Graph Theory . Dover Publicat ions, 1977. I SBN 0 -4 8 6 -2475-9. pp. 1 0– 2 4 . Cor m en, Thom as H. H., Ronald L. Rivest , and Char les E. Leiser son. I nt roduct ion t o Algorit hm s. MI T Press, 1990. Edsger Wybe Dij kst r a: John Morris:

http: / / www.cs.utexas.edu/ users/ UTCS/ report/ 1997/ dij kstra.htm l .

http: / / ciips.ee.uwa.edu.au/ ~ m orris/ Year2/ PLDS210/ dij kstra.htm l .

Perlm an, Radia. I nt erconnect ions, Second Edit ion: Bridges, Rout ers, Swit ches and I nt ernet working Prot ocols. Addison-Wesley, 1999. I SBN 0201634481. pp. 317–3 2 2 . Pr ofile page of E. W. Dij k st r a:

http: / / kzoo.edu/ ~ k98m n01/ dij kstra.htm l .

RFC 1195, " Use of OSI I S-I S for Rout ing in TCP/ I P and Dual Environm ent s." Ross Callon. 1990. pp. 51–5 7 .

150

St allings, William . High - Speed Net works, TCP/ I P and ATM Design Principles . Prent ice Hall, 1998. I SBN 0 -1 3 -525965 -7. Chapt er 12, pp. 384 – 397.

151

Part II: Integrated IS-IS Network Design for IP Internets Part I I I nt egrat ed I S- I S Net work Design for I P I nt ernet s Chapt er 7 General Net work Design I ssues Chapt er 8 Net work Design Scenarios

152

Chapter 7. General Network Design Issues Significant issues t hat deser ve consider at ion in gener al net w or k design m ost ly r elat e t o scalabilit y, st abilit y, and conver gence. This applies t o t he design of t he physical layout of t he net w ork, as w ell as rout ing and t raffic m anagem ent . Scalabilit y, st abilit y, and conv er gence ar e r elevant t o bot h int er dom ain and int r adom ain r out ing. For int r adom ain r out ing, t hese issues deserve careful considerat ion, regardless of t he I GP select ed; and in all cases, only a syst em at ic, well-st r uct ur ed appr oach w ill lead t o t he de sir ed obj ect iv es of t he design. The follow ing elem ent s of net w or k design dir ect ly im pact net w or k scalabilit y, st abilit y, and convergence and are cert ainly im port ant considerat ions w hen designing I nt egrat ed I S-I S net w or k s:

•

H ierarchy — The net w or k ar chit ect m ust decide t o deploy I S-I S in flat ar chit ect ur e or w it h a t w o -lev el hier ar chy . This also m eans deciding w het her t o r un t he w hole dom ain logically flat ( Level 1 -only or Level 2 -only) or t o use hier ar chy w it h m ult iple Level 1 ar eas w it h a Lev el 2 back bone. I f deploy ing a hier ar chy , w hen and w her e t o cr eat e ar ea boundar ies becom e im por t ant consider at ions.

•

Addressing— Bot h I P and CLNP ( NSAP) addr esses ar e needed in t he I S-I S net w ork, and assignm ent of bot h t y pes of addr esses should be w ell planned.

•

Su m m a r iz a t ion— This is a key consider at ion, bot h fr om t he st andpoint of const r aining r out ing inst abilit ies as w ell as r educing t he am ount of r out ing infor m at ion t hat is adv er t ised in t he net w or k . Select ion of t he point s in t he net w or k at w hich t o sum m ar ize r out ing infor m at ion is usually influenced by t he locat ion of ar ea boundaries. Sum m arizat ion point s are not alw ays obvious and relat ed decisions are, t her efor e, im por t ant ear ly in t he design pr ocess.

Each of t hese fact ors needs t o be t horoughly explored in t he plannin g st ages of t he net w or k and r e -evaluat ed dur ing t he deploym ent st ages t o t est viabilit y of any assum pt ions m ade ear lier . This is im por t ant t o successfully achieve t he ult im at e design obj ect ives of t he net w or k. Each of t hese fact or s is fur t her discussed in det ail in t his chapt er.

IP Network Design Principles The basic principles of good net w ork design apply t o all I GPs including I S-I S. The classic design m et hodology of layering t he net w ork int o t hree m ain com ponent s ( core, dist ribut ion, and access) needs t o be applied as m uch as possible. The follow ing sect ions discuss t hese t hr ee com ponent s.

Core The cor e is t he net w or k back bone and it s pr im ar y funct ion is t o sw it ch pack et s as fast as possible. As t he core is t he heart of t he net w ork, it m ust be redundant , reliable, and have full r eachabilit y t o ever y dest inat ion in t he net w or k.

153

Because packet sw it ching in t he core m ust be fast , filt ering and policy im plem ent at ions in t his part of t he net w ork m ust be lim it ed and, if possible, avoided because, in general, t hese feat ur es slow dow n t he r at e of pack et pr ocessing and adv er sely im pact per for m ance of t he core rout ers. Backbone rout ers need full rout ing inform at ion so t hat t hey can opt im ally for w ar d pack et s t o any ot her dev ice in t he net w or k w it hout r ely ing on a default -r out e.

Distribution The dist r ibut ion layer is nor m ally t he aggr egat ion point of t r affic upst r eam fr om t he edge t o t he cor e or dow nst r eam t r affic in t he opposit e dir ect ion. I t can also cont r ol and isolat e inst abilit ies on t he edge fr om t he cor e. The dist r ibut ion r out er s ar e t he point s at w hich r out e sum m ar izat ion should t ake place. This r educes t he size of t he r out ing t ables and also aids in pr ev ent ing inst abilit ies on t he edge or access layer fr om disr upt ing t he cor e. The sm aller t he num ber of r out es t hat a back bone r out er has t o deal w it h, t he fast er it can m ak e sw it ching decisions, w hich in t ur n helps r educe sw it ching lat ency in t he cor e. Packet filt er ing and policy im plem ent at ion can also be per for m ed at t he dist r ibut ion layer or fur t her out at t he access lay er as discussed in t he nex t sect ion. By using pack et filt er ing, y ou can prot ect t he core from unint erest ing or unwant ed t raffic. Policy r out ing can be used t o for w ar d t r affic based on ot her cr it er ia, such as packet t ype or sour ce addr ess, inst ead of t he usual dest inat ion addr ess.

Access The access layer is nor m ally t he point at w hich cust om er s connect t o t he ser vice pr ovider net work. Access rout ers provide t he int erconnect ion bet ween cust om er prem ise equipm ent ( CPE) and t he dist ribut ion layer ( see Figure 7 - 1 ).

154

Figur e 7 - 1 . Cla ssic t h r e e- la ye r m odel.

Because t he access layer is t he connect ion t o t he ext er ior of t he ser vice pr ovider net w or k, appr opr iat e secur it y m easur es m ust be enfor ced t o pr ev ent unaut hor ized access and any secur it y holes t hat m ight be used t o launch denial of ser vice at t acks of any for m . Ther efor e, filt er ing and secur it y policies m ust be applied t o access devices t o ensur e t hat all devices w it hin t he net w or k ar e pr ot ect ed fr om ext er nal at t acks and also cust om er devices ar e pr ot ect ed fr om at t acks or iginat ing fr om w it hin t he net w or k or it s ot her per ipher ies. You can apply a num ber of basic com m on access filt ers t o prot ect from spoofing, broadcast , and direct ed broadcast sources. RFC 2827, " Net w ork I ngress Filt ering: Defeat ing Denial of Ser vice At t acks w hich em ploy I P Sour ce Addr ess Spoofing," pr ovides guidance for im plem ent ing such securit y filt ers. This sect ion br iefly discussed t he im por t ance of a layer ed m et hodology as t he basic underlying principle for designing scalable net w orks. The t hree -lay er ed appr oach is r ecom m ended as t he basis for ar chit ect ing net w or ks t hat can gr ow t o a significant ly lar ge num ber of nodes. For com plet eness, how ever, t he follow ing t w o design issues also need t o be consider ed: A hier ar chical r out ing t opology and a w ell-laid -out I P addr essing schem e.

H ie r a r ch ica l Topology a n d Rou t in g Hier ar chy is ult im at ely t he k ey t o successfully scale a net w or k . I f y ou design a net w or k w it h hier ar chy in m ind fr om t he st ar t , t he net w or k can be ex t ended in size w it h only t r iv ial

155

adj ust m ent s. I f y ou leav e hier ar chy out , t he net w or k w ill lik ely encount er pr oblem s as it gr ow s and ult im at ely will com prom ise perform ance and reliabilit y. Why m ust y ou alw ay s design w it h hier archy in m ind? The m ain reason is t hat , ult im at ely, a flat net w or k does not scale. For ex am ple, in t he case of I S-I S, as t he net w ork grow s, increasing t he num ber of nodes increases t he num ber of LSPs flooded, w hich in t urn increases t he com plex it y and t im e taken for t he SPF com put at ion. The m or e nodes w it hin t he net w or k , t he m or e link s t her e ar e, t he m or e LSPs t hat ar e flooded, t he m or e infor m at ion t hat SPF has t o deal w it h, t he m or e CPU cy cles r equir ed for r out e com put at ion, and so on. The m ost ex pensiv e part of t he rout e com put at ion ( SPF) is over t he int ra -ar ea t opology—t herefore, it m akes sense t o segm ent t he net w ork int o sm aller m anageable sect ions or ar eas. I f t his is done, t her e w ill be few er nodes and link s in each ar ea, and few er LSPs w ill be flooded. Consequent ly, t he SPF pr ocess w ill have less infor m at ion t o deal w it h during rout e com put at ion, saving valuable CPU cycles for ot her crit ical funct ions of t he r out er . Anot her sound r eason for using a hier ar chical design w it h ar eas is t o hide inst abilit ies w it hin a problem at ic region from t he rest of t he net w ork. I S-I S cur r ent ly suppor t s t w o lev els of hier ar chy. By adopt ing a hier ar chical design, you can use sum m ar izat ion t o r educe t he am ount of infor m at ion t r ansfer r ed bet w een ar eas and also at r edist r ibut io n point s. Layering t he net w ork int o core, dist ribut ion, and access gives you m ore cont rol and, t herefore, m akes t he net work m ore m anageable. This approach is beneficial in I S-I S net w or k design scenar ios. A sm all and sim ple I S-I S net w or k can be init ially deployed as a flat net w ork. How ever, you need t o det erm ine up -fr ont w hen it m ight be necessar y t o m igr at e t o a hier ar chical t opology. I t is difficult t o say exact ly how m any nodes j ust ify m oving t o a hierarchical m odel. Cert ainly, t his depends on m any fact ors and r equir es k eeping t he final goal in m ind w hen m ak ing such a call. The follow ing fact or s need t o be consider ed w hen designing an I S-I S net w or k t o scale int o t he fut ur e:

•

How m any nodes are t here current ly?

•

How m any nodes ar e expect ed in t he fut ur e?

•

How is t he net w ork split in t erm s of geography?

•

What m edia t echnology is used t o int er connect t he nodes? What ar e t he link speeds and how st able ar e t hey ?

Ot her fact or s t hat need t o be consider ed ar e int er dom ain r eachabilit y and default r out e originat ion and p ropagat ion. Each of t hese fact ors influences t he net work design. Obviously, som e hav e a st r onger influence t han ot her s. You m ight st ar t w it h a sim ple net w or k of 10 nodes, for ex am ple. Wit h only 10 nodes, do y ou have an im m ediat e need for hier ar chy? Per haps not . Suppose, how ev er , t hat 1 or 2 of t hese

156

nodes ar e in a r egion t hat exper iences const ant flapping, w hich is uncont r ollable because of operat ing condit ions; one approach t o cont ain t he problem is t o int roduce hierarchy int o t he net w or k. Having t he flapping links in one area const rains t he inst abilit ies t o only t he affect ed r egion. As show n in Figure 7 - 2 , w hen a link goes dow n, a new rout er LSP is generat ed and flooded. The LSP is t hen flooded fur t her t hr ough t he net w or k so t hat all r out er s becom e aw ar e of t he ev ent and m ake adj ust m ent s as necessar y. Figu r e 7 - 2 . LSP flooding.

By m oving t o a hier ar chical t opology w it h m ult iple ar eas, you can cont ain t he flooding of LSPs w it hin t he ar ea. Wher e possible, y ou can also configur e t he r out er s for only a single lev el of rout ing ( Level 1 -only or Level 2 -only inst ead of Level 1 -2) . This sav es on m em or y and CPU pr ocessing because r out e calculat ions w ill be per for m ed on only one Link-St at e dat abase inst ead of t w o. By default , a Cisco rout er behaves as Level 1 and Level 2 ( t hat is, Level 1 -2) . Addit ional configurat ion is required t o reduce it t o a single level capabilit y. The m ost logical place t o st ar t w hen designing an I S-I S net w or k is t he back bone. As previously d iscussed, I S-I S cur r ent ly suppor t s t w o levels of hier ar chy: t he backbone, w her e Lev el 2 r out ing is per for m ed, and t he ar eas w her e Lev el 1 r out ing occur s. ( see Figure 7 - 3 ). Ther efor e, it m ak es sense t o st ar t w it h a cont iguous Lev el 2 back bone. This w ay , as t he net w or k gr ow s, you can add in t he Level 1 ar eas a nd m igrat e t o a full hierarchical m odel for scaling purposes, if necessary.

157

Figur e 7 - 3 . I S- I S hie r a r chica l a r e a s.

I n t he past , I nt er net ser v ice providers avoided building hierarchical I S-I S dom ains because t he st ubby ar eas specified in I SO 10589 and por t ed int o RFC 1195 did not pr ov ide t he necessar y int elligence for Level 1 -only r out er s t o det er m ine t he best ex it point fr om t he ar ea. I n t his fram e w or k, Level 1 r out er s follow a default r out e t o t he closest Level 1 -2 rout er. Level 2 r out er s flag connect ivit y t o t he backbone t o Level 1 r out er s by set t ing t he at t ached bit in t heir Lev el 1 LSP, w hich is flooded t hr oughout t he ar ea. Ev en t hough t he select ed default r out er m ight be t he closest in t he ar ea, it m ight not be t he best ex it out of t he ar ea w hen t he ov er all cost t o t he dest inat ion is consider ed. This possibilit y of subopt im al pat h select ion w as t he m ain r eason w hy m ost ser v ice pr ov ider s built flat I S-I S t opologies.

Figure 7 - 4

show s t hat t o send

t r affic fr om RTA t o RTB, you need t o t r aver se a num ber of links —t he closest exit point for RTA is t hr ough t he link w it h a m et r ic of 40. This leads t o t he near est Lev el 1 -2 in t he dir ect ion of t he final dest inat ion. How ever, t he t ot al pat h cost of 150 is w ors e w hen com par ed t o t he alt er nat e pat h, w hich has a bet t er t ot al pat h cost of 120, ev en t hough t he cost of 50 t o t he Level 1 -2 r out er on t hat pat h is w or se.

158

Figur e 7 - 4 . Subopt im a l r out ing.

Because int er ar ea r out es ar e not available t o Level 1 -only r out er s, t hey ar e unaw ar e of t he end -t o-end m et ric inform at ion associat ed w it h such rout es. Therefore, t his m odel does not facilit at e BGP shor t est pat h select ion, m aking it generally unsuit able for use in I SP net w orks. Building a flat net w or k pr ovides a w or kar ound. Addit ionally, you m ight also ar gue t hat building a flat net w or k is m uch less com plex t han building a hier ar chical one. Aft er all, in I SP netw or k s, t he I GP is prim arily used for det erm inat ion of t he BGP next -hop and local r out es, so w hy m ak e t he t opology m or e com plex t han it needs t o be? A recent enhancem ent in Cisco I OS Soft ware, known as I nt erarea Rout e Leaking, rem oves t he subopt im al r out ing lim it at ion in I S-I S Lev el 1 r out ing. When enabled, t his feat ur e allow s a Level 1 -2 r out er t o inj ect I P pr efix infor m at ion fr om t he Level 2 dat abase int o t he Level 1 dat abase of it s local ar ea t hr ough it s Level 1 LSP, t her eby " leaking" int er ar ea r out es into Level 1. When designing I S-I S net w or ks, alw ays r em em ber t hat t he backbone m ust be cont iguous. I n ot her w or ds, a Level 1 -only r out er should never be inser t ed bet w een any t w o Level 2 r out er s ( Level 2 -only or Level 1 -2) . I n gener al, t he design of t he net w ork t opology needs t o st art from t he core. As discussed pr ev iously , t he cor e aligns w it h t he I S-I S Level 2 backbone w hen considering a hierarchical t opology. Proper layout of t he core provides m ore flexibilit y for fut ure grow t h. I f t he init ial size of t he ne t w or k is not lar ge, t he backbone can be deployed as a flat t opology w it hout m ult iple

159

areas. I n t his case, t he backone is configured as Level 2 -only. As t he next work grows, it m ight get t o a point w here hierarchy m ust be int roduced t o scale furt her. This m e ans deploy ing Level 1 ar eas in addit ion t o t he exist ing Level 2 backbone t o accom m odat e gr ow t h. Depending on t he design and gr ow t h obj ect iv es of t he net w or k , t he Lev el 1 ar eas can be added in a m anner t hat r eflect s t he hier ar chy of physical t opology. A key design consider at ion at t his j unct ur e is t he dem ar cat ion of t he Lev e1 1 ar eas fr om t he back bone. As not ed previously, t he core rout ers ideally should not perform any funct ions t hat place addit ional load on t he CPU because t he pr im ar y funct ion of t he cor e is t o sw it ch I P packet s as fast as possible. Wit hin an I S-I S net w or k, how ever , you can sum m ar ize I P subnet s fr om Level 1 ar eas int o t he Level 2 backbone, and also w hen leaking r out es, fr om Level 2 int o Level 1. One of t he goals of good net w or k design is t o reduce t he am ount of rout ing inform at ion t hat is t ransferred t o and from t he core. Therefore, it m ight be beneficial t o configure t he core rout ers as Level 1 -2 and t hen push t he Level 1 -only r out ing out t o t he dist r ibut ion lay er . How ever , t his design also has som e dr aw backs. Many access r out er s m ight be at t ached t o t he dist r ibut ion r out er s, w hich can r esult in t oo m any r out er s in a single ar ea. I n such cases, net w ork inst abilit ies m ight be unm anageable, im posing lim it at ions on scaling and fut ure gr ow t h potent ial. A possible solut ion is t o m ake t he cor e r out er s pur e Level 2; t hen configur e t he dist ribut ion rout ers as Level 1 -2, and finally t he access rout ers as Level 1 -only . As t he dist ribut ion rout ers t ake over t he dual Level 1 -2 funct ion, subopt im al rout ing is elim inat ed by using Rout e Leaking. Finally, w it h t he access rout ers being Level 1 -only, any inst abilit ies are not passed back up int o t he cor e. As obvious from t he preceding discussion, t radeoffs m ust be m ade in t he design process. The per fect net w or k is not always realizable. A successful I S-I S net w or k s is one t hat is st able and scalable and conver ges r easonably fast w hen t her e ar e changes. A definit iv e m ax im um num ber of r out er s t hat can be suppor t ed w it hin a single I S-I S ar ea is har d t o det er m ine. Current ly ( at t he t im e of w rit ing) , t here are som e reasonably large -sized net w or k s w it h close t o a 1000 r out er s in a single ar ea, oper at ing successfully w it hout any significant issues. How ever , 1000 nodes per ar ea is not an absolut e num ber . The num ber of nod es t hat can be cr am m ed int o a single ar ea depends m ainly on t he design of t he physical t opology, st abilit y of t he links, t he num ber of I P subnet s, and t he m em ory and CPU capacit ies of t he r out er s. What w or k s for one net w or k m ight not necessar ily w or k for a not her net work; and t her efor e, each design m ust be evaluat ed individually on it s ow n m er it s. Figure 7 - 5

show s how you can com bine hier ar chy and ar ea r out ing over t he cor e, dist r ibut ion,

and access layer s. Only Level 2 LSPs ar e flooded bet w een t he cor e and dist r ibut ion layer s. The access layer devices in t he sam e ar ea as t he dist r ibut ion r out er s r eceiv e and ex change only Lev el 1 LSPs w it h t he dist r ibut ion r out er s. Designing t he net w or k t his w ay pr ot ect s t he cor e layer fr om inst abilit ies w it hin t he access layer .

160

Figur e 7 - 5 . I S- I S h ie r a r ch y u sin g a r e a r ou t in g.

I P Addr e ssin g La y ou t One of t he m ain fact or s t hat det er m ines how w ell an I GP scales is t he addr essing lay out planned int o t he net w or k ar chit ect ur e. This applies t o any r out ing pr ot ocol r egar dless of w het her it is link-st at e or dist ance vect or, int radom ain or int erdom ain. I f an incorrect addressing schem e is used in t he design and deployed in t he earlier phases of t he im plem ent at ion, t here m ight be ch allenges in t he fut ur e t o scale fur t her . This sect ion br iefly ex am ines and highlight s som e of t he issues t hat should be consider ed w hen designing an I P addr essing lay out for use w it h I S-I S. Perhaps I nt egrat ed I S-I S lends it self a lit t le m ore t ow ard a less -st ringent I P addressing st r uct ur e t han ot her link-st at e I GPs, especially in single ar ea deploym ent s. This is because it can handle a lar ge num ber of nodes in an ar ea. This is par t icular ly advant ageous for exist ing I P net w orks t hat have poor, discont iguous addressing layout s, w hich are difficult or nearly im possible t o sum m ar ize. How ever , t his is not a good r eason for not follow ing good design pr act ices and pr inciples w hen lay ing out an I P addr essing st r uct ur e for use w it h I S-I S. I m proper addressing assignm e nt can significant ly im pede successful oper at ion of a net w or k. Poor I P addr essing m akes a good level of sum m ar izat ion difficult t o achieve. Net w or ks t hat r un w it hout decent levels of sum m ar izat ion ar e pr one t o st abilit y pr oblem s because t hey cannot t ake ad vant age of sum m arizat ion t o help cont ain inst abilit ies and rout e flaps, as w ell as r educe t he load on r out er s. Wit hout sum m ar izat ion, t he num ber of r out es pr opagat ed

161

t hroughout t he net w ork could be larger. This, in t urn, requires m ore processing and places m or e dem ands on t he CPU dur ing net w or k chur ns. I P addr ess assignm ent is oft en seen as a labor ious t ask by m ost net w or k oper at or s, being a m undane adm inist r at ive chor e. I t is, t her efor e, oft en im plem ent ed w it hout due car e and consider at ion of t he pit falls t hat poor planning br ings. Aft er I P addr esses have been allocat ed and assigned, it is oft en difficult t o change and reassign t hem . I f reassignm ent is possible, dow nt im e is involved; t her efor e, ser vice is int er r upt ed. Of cour se, t he changes ar e im plem ent ed dur ing a m aint enance w indow . When designing an I P addr essing st r uct ur e, also ensur e t hat t he chosen addr ess r ange of any subnet is lar ge enough t o allow for addit ional gr ow t h. I t w ould be a gr eat w ast e of effor t t o m et iculously plan t he addr ess assignm ent schem e, only t o lat er r un out of addr esses on som e segm ent s. Alw ays keep sum m ar izat ion in m ind w hen designing t he I P addr essing schem e because it w ill help cont r ol t he num ber of r out es t hat populat e t he I P r out ing t able. You lear ned t hat sum m ar izat ion is im port ant w hen designing an I P addressing schem e —but you m ight be w onder ing w hat sum m ar izat ion act ually does. I n sim ple t er m s, sum m ar izat ion enables m or e det ailed t opology infor m at ion t o be hidden and set s a boundar y lim it for cont aining any net work changes . This r educes t he num ber of r out er s t hat ar e affect ed by any such changes. By r educing t he num ber of r out er s affect ed by a change, you effect ively r educe t he num ber of rout ers t hat are involved in convergence calculat ions t hat shield t he net w ork from a po t ent ial m elt dow n. Now t hat you have seen t he huge benefit s t o be gained fr om using a w ell-planned I P addr essing schem e ( w it h good sum m ar y capabilit y) , it is t im e t o consider w hich par t s of t he net w or k t o apply sum m ar izat ion t o. The m ost logical places t o configure sum m arizat ion are on r out er s at t he dist r ibut ion layer bet w een t he cor e and access layer s ( w hen dealing w it h t he classical t hree -layer hierarchical m odel) . This ensures t hat you allow full t opology inform at ion t o be leak ed only w her e r equir ed. Summ arize from t he access layer t ow ard t he core, by having t he dist ribut ion rout ers sum m ar ize each block of access lay er pr efix es int o shor t er pr efix es t hat ar e adv er t ised int o t he core. At t he dist ribut ion rout er, you can sum m arize t he four advert isem ent s co m ing from t he access r out er s int o a single pr efix ( r efer t o Figure 7 - 6 ) . The four access prefixes are hidden from t he core rout er, prot ect ing t he core rout er from any inst abilit ies t hat m ight arise on t he access r out er s.

162

Figur e 7 - 6 . Sum m a r izing fr om dist r ibut ion t o cor e .

You can also sum m ar ize at t he dist r ibut ion lay er fr om t he cor e dow nst r eam t ow ar d t he access layer. Typically, access devices t hat at t ach t o a dist ribut ion layer ( or direct ly t o t he core) r equir e only a default r out e. I n ot her scenar ios, such as dual hom ing, it m ay be necessar y t o t ake appropriat e m easures t o avoid any pot ent ial for subopt im al pat h select ion. I n

Figure 7 - 7 ,

you can see t hat pr act ically all cor e pr efixes ar e sum m ar ized int o one adver t isem ent —t he default rout e. This is s how n as a pr efix of all 0s—0.0.0.0/ 0.

163

Figur e 7 - 7 . Sum m a r izing fr om dist r ibut ion t o a cce ss.

The pr im ar y obj ect ive of I P r out e sum m ar izat ion is to lim it t he size of t he rout ing t able, w hich assist s in scaling t he net w or k in a st able m anner . Designing an I P addr essing schem e t o be used w it h I nt egrat ed I S-I S is no differ ent fr om designing for any ot her I GP. I n sum m ar y , t o achiev e t he obj ect iv e of a s uccessful, scalable net w ork, apply t he design pract ices and pr inciples elabor at ed her e. and plan car efully for fut ur e gr ow t h.

Using IS-IS as an IGP Ov er t he past few y ear s, I S-I S has becom e incr easingly m or e popular for use as an I GP. Previously, I S-I S w as m ore prevalent in governm ent and academ ic net works, t he m aj orit y of w hich w er e pur e CLNS envir onm ent s t hat did not car r y I P pr efix infor m at ion. The I S-I S pr ot ocol seem s t o be w idely per ceiv ed as difficult t o under st and and t o configur e. One of probable re asons for t his is t he addit ional requirem ent for CLNP ( or NSAP) addresses. The node -based NSAP addr esses differ vast ly fr om I P addr esses ( see Chapt er 4 , " Addressing in

164

I nt egrat e d I S-I S" ) and require fam iliarit y t o w ork w it h com fort ably. How ever, t he com parable r out ing pr ot ocol, such as t he Open Shor t est Pat h Fir st ( OSPF) Pr ot ocol, w or k s w it h only I P addresses. Even t hough OSPF is sim ilar in m any regards t o I S-I S, differ ences in t he CLNP and I P addr essing schem es ( node-based versus link-based, r espect ively) r esult in OSPF defining it s ar ea boundar ies on t he r out er it self, w her eas I S-I S defines it s boundar ies on t he net w or k links bet w een r out er s in differ ent ar eas. Also, because an NSAP can pot ent ially be up t o 20 byt es in lengt h, it adds t o t he com plexit y of t he pr ot ocol. Anot her r eason m any people did not adopt t he pr ot ocol ear lier w as t hat t her e w as inadequat e inform at ion regarding design and configurat ion guidelines. This is now im pr oving and cer t ainly a m aj or fact or in t he gr ow ing popular it y of t he pr ot ocol. Many m aj or ser vice pr ovider s r un I S-I S in som e of t he lar gest I P net w or k s in t he w or ld. I nherent ly, t he I S-I S pr ot ocol t ends t o be v er y scalable and can accom m odat e lar ge ar eas. Being pur e link-st at e, it can react quickly t o changes and t hus at t ain fast convergence. Also, because I S-I S uses TLVs t o encode infor m at ion in all packet s, it can be easily ext ended. I S-I S has m any configur able t im er s t hat y ou can t une t o enhance it s oper at ion, such as r educing convergence t im e, increasing st abilit y, and cont rolling flooding —t o nam e but a few. Alt hough t hese t im ers m ight be m ore challenging t o t une effect ively, t hey m ake t he prot ocol m ore flexible, scalable, and robust . This is a defin it e plus because y ou can lit er ally t ailor t he pr ot ocol by using t he t im er s t o m eet your specific net w or k r equir em ent s. One of t he reasons t hat I S-I S is such a flex ible and r elat iv ely sim ple pr ot ocol is t hat not m any r igid st andar ds exist for it t o adher e t o —especially w hen com pared t o OSPF. Som e m ight be disappoint ed about t he lack of r igor ous st andar ds t hat cover som e t he m or e r ecent ly added capabilit ies, y et ot her m ight see it as an adv ant age.

Protocol Limitations to Consider Like any I GP, I nt egrat ed I S-I S has som e lim it at ions. Many of t he pr evious pr ot ocol lim it at ions hav e been r em ov ed as a r esult of r ecent I ETF dr aft s and RFCs and cor r esponding enhancem ent s in Cisco I OS Soft ware. The following sect ions exam ine t hese lim it at ions in m ore det ail.

M e t r ic Lim it a t ion Before t he int roduct ion of new TLVs t hat support larger m et rics, I nt egrat ed I S-I S w as lim it ed t o a 6 -bit int er face m et r ic and a 10-bit pat h m et r ic. This gav e a r ange of 1 t o 63 for t he int er face m et r ic and a value of 1023 for t he t ot al pat h m et r ic. I f im plem ent at ions t hat do not suppor t t he new TLVs ar e used, t he int er face and m axim um pat h m et r ic lim it at ion st ill applies.

Ar e a Lim it a t ion Before t he int roduct ion of rout e leaking, I S-I S ar eas r esem bled t he m odel of an OSPF " st ub ar ea, " w it h t he ex cept ion t hat ext ernal inform at ion could be redist ribut ed int o t he Level 1

165

ar eas on Cisco r out er s. As a r esult , t he only w ay t o ex it an ar ea w as t o for w ar d pack et s t o t he closest Level 1 -2 rout er, increasing t he pot ent ial for subopt im al forw arding. Rout e leaking elim inat ed t his pr oblem by pr ov iding a m eans t o " leak " r out es pr esent in t he Lev el 2 dat abase t o t he Lev el 1 ar eas. As a r esult of t his new capabilit y , a Lev el 1 r out er can m ake a m uch bet t er decision r egar ding t he best point t o exit t he ar ea t o r each t h e final dest inat ion. This is par t icular ly useful for shor t est ex it r out ing w hen coex ist ing w it h BGP, and also for opt im al r eachabilit y t o t he loopback addr ess of t he pr ov ider edge ( PE) r out er w hen using I nt egrat ed I S-I S in Mult iprot ocol Label Swit ching -based Virt ual Privat e Net w orks ( MPLSVPN) applicat ions. MPLS is a m echanism used t o for w ar d packet s acr oss a net w or k fr om an ingr ess r out er t ow ar d an egr ess r out er w it hout t he need t o analy ze net w or k lay er dest inat ion I P addr esses. MPLS assigns labels t o packet s and ut ilizes label sw apping t o for w ar d t he packet s t hr ough t he net w or k. Each packet car r ies a shor t , fixed-lengt h label t hat infor m s sw it ching nodes along t he pat h how t o pr ocess and for w ar d t he dat a. Virt ual privat e net works ( VPNs) can be defined as net w orks in w hich connect ivit y bet w een m ult iple cust om er sit es is deploy ed on a shar ed infr ast r uct ur e w it h t he sam e access or secur it y policies as a pr iv at e net w or k infr ast r uct ur e. A det ailed descr ipt ion of t he concept s and ar chit ect ur es of MPLS-VPN is beyond t he scope of t his book.

M a x im u m N u m be r of Adv e r t ise d I P Pr e fix e s A m aj or lim it at ion t o consider is t he m axim um num ber of rout es an I S-I S r out er can suppor t , w hich is lim it ed t o approxim at ely 30,000 rout es. This lim it at ion exist s because of a m axim um o f 256 LSP fr agm ent s per r out er , each of w hich w ill not t ak e m or e t han 121 I P pr efix es. This is essent ially a t echnical lim it at ion of t he prot ocol and should not be considered for pract ical pur poses because in m ost applicat ions, t he I GP does not car r y t his m any r out es. The m aj or it y of t he r out es ar e car r ied in BGP, w hich r elies on t he I GP t o help r esolv e nex t hop infor m at ion. Ther efor e, t he I GP t r acks subnet s assigned t o links in t he net w or ks, and t he or der of I GP rout es is norm ally significant ly far less t ha n 30, 000. A recent ly published I ETF draft , draft -herm elin -ex t -lsp -frags-00.t xt , proposes increasing t he m axim um num ber of LSP fragm ent s beyond t he 256 current lim it by using m ult iple syst em I Ds on t he sam e int er m ediat e syst em . How ever , as m ent ioned pr eviously, a current ly deployed net w or k t hat car r ies anyw her e close t o t he 30,000 I P pr efixes per r out er in it s I GP is open t o ser ious scr ut iny . Ex ist ing I GPs w er e nev er designed t o car r y t his num ber of r out es and m ight exper ience oper at ional pr oblem s if t hey are pushed t o t hese lim it s.

M e t r ics, N on h ie r a r ch ica l D e sign As pr eviously m ent ioned, by default , all I S-I S int er face m et r ics ar e set t o 10. Ther efor e, all t he int er face m et r ics m ight need t o be r edefined and configur ed depending on t he r equir ed t r affic flow .

166

Tw o m ain st y les of m et r ics ex ist : nar r ow and w ide. Nar r ow m et r ics ar e com m only called old st yle TLVs and w ide m et r ics ar e r efer r ed t o as new -st yle TLVs. The follow ing sect ions look at how t he m et r ics ar e used and assigned.

Usin g N a r r ow M e t r ics I f u sin g older im plem ent at ions t hat do not support t he new TLV t ypes ( w hich allow int erface m et r ic v alues lar ger t han 63) , y ou m ust t ak e car e w hen deciding w hich v alue t o apply t o each int erface. All int erface m et rics m ust be configured m anually because aut oconfigura t ion does not ex ist based on par am et er s, such as bandw idt h, as in OSPF. Also, w it h bandw idt h capacit y of m edia t ypes increasing t o ext rem ely high values, such as OC192, t here is a huge range of bandw idt h t o fit int o t he sm all range of narrow m et rics — especially if t here are sm all bandw idt h int erfaces t o consider in t he net w ork. Met r ics ar e an im por t ant consider at ion w hen designing any net w or k , and I S-I S is no except ion. The int er face and pat h m et r ics influence t he w ay t he t r affic flow s ar ound t he net w ork, and, t herefore, you m ust carefully plan m et ric assignm ent s t o achieve t he desired r esult s. As w it h m ost r out ing pr ot ocols, in I S-I S, a low er m et r ic is pr efer r ed over a lar ger value. Ther efor e, w hen using nar r ow m et r ics, w hich allow s an int er face m et r ic r ange fr om 1 t o 63, 1 is t he best and 63 is t he w or st t hat can be assigned. I f y ou hav e no ot her alt er nat iv e t han t o use t he old -st yle TLVs and, t her efor e, " nar r ow " m et r ics, you need t o m ake an infor m ed decision about w hich m et r ic values t o assign t o t he low est and highest bandwidt h int erfaces in t he net w or k. When deciding w hich values t o assign, it is pr udent t o t ake int o consider at ion addit ional int er faces of higher bandw idt h t hat m ight be used in t he near fut ur e. Ther e is lit t le benefit t o designing a m et r ic schem e t hat r equir es m aj or m odificat ions w hen new int er faces ar e added. So, plan ahead and be pr oact iv e. I nv est igat e w hich int er face speeds m ight be added in t he fut ur e and leave r oom for gr ow t h. I f fut ur e int er faces ar e know n in adv ance, y ou can easily a ccom m odat e t hem .

U sin g W id e M e t r ics Wide m et r ics pr ov ide a m uch lar ger r ange for bot h int er face and t ot al pat h m et r ics. Wide m et r ics use 24 bit s for int er face m et r ics and 32 bit s for pat h m et r ics com par ed t o 6 bit s and 10 bit s, respect ively, for narrow m et r ics. This pr ov ides a huge r ange t o design w it h and effect ively rem oves t he lim it at ions associat ed w it h narrow m et rics. Som e recent applicat ions, such as MPLS t raffic engineering, are support ed using only w ide m et r ics. Ther efor e, all r out er s t hat ar e r equired t o run MPLS t raffic engineering m ust support t he new -st yle TLVs ( Types 22 and 135) .

167

Again, a st r uct ur ed appr oach m ust be t ak en w hen deciding on a m et r ic assignm ent using w ide m et r ics. Alt hough t he pr evious issues have been r em oved, it w ould be difficult and t im e consum ing t o ent er lar ge m et r ic values on each r out er int er face. This calls for a sim ple and pr act ical m et r ic assignm ent schem e.

Assign in g M e t r ic V a lu e s I n t he vast m aj or it y of cases, you init ially need t o assign a low er m et r ic value t o a higher bandw idt h int er face t o ensur e t hat t he t r affic is for w ar ded along t he pat h w it h t he low est delay . Because a high pr ice t ag is associat ed w it h high bandw idt h int er faces and corresponding circuit s, it seem s logical t o use t he large capacit y links as m uch as possible. Also, t he less -congest ed pat h should be t he one t hat has t he least delay—alt hough t his is not alw ay s t he case. N OTE

Alt hough bandw idt h is t he t er m t hat is per haps m ost com m only used w hen choosing t he best pat h, t he m ost im por t ant fact or t o consider is delay .

Of cour se, t his m ight not be applicable t o all design scenar ios. I n a num ber of valid cases, you m ight w ant t r affic t o follow along t he pat h w it h t he least num ber of hops, w hich m ight not be t he sam e high -bandwidt h pat h ( again, seeking t he low est delay, or possibly t he highest reliabilit y) . Because I nt egrat ed I S-I S uses only int er face cost as a v alid m et r ic, y ou can r ely only on m anual configurat ion t o achieve t he desired t raffic-f l o w . When designing t r affic flow w it hin and bet w een point s of presence using I nt egrat ed I S-I S, you m ight w ant t r affic t o flow acr oss t he shor t est pat h possible w it h t he least num ber of hops t o reach t he dest inat ion, inst ead of t aking t he rout e w it h t he highest bandw idt h. Consider 8,

Figure 7 -

for exam ple, w hich show s a higher m et r ic assigned t o t he 155 Mbps int er faces than t he

ot her low er bandw idt h int er faces. This ensur es t hat t he t r affic t akes t he pat h w it h t he least num ber of hops t o get fr om sour ce X t o dest inat ion Y.

168

Figur e 7 - 8 . I S- I S I n t e r fa ce m e t r ic a ssign m e n t .

Usually, I nt ernet service providers t ry t o keep t he num ber of hops t hat t raffic t raverses in t heir net w orks t o a m inim um . Therefore, in som e cases, assigning a low er cost t o a low er bandwidt h lin k m ight be preferred t o reduce t he hop count , provided t here is enough capacit y on t he pat h t o handle available t r affic.

Usin g Bot h N a r r ow a n d W ide M e t r ics Toge t h e r You can use eit her nar r ow or w ide m et r ics w hen using a nonhier ar chical design. The t y pe of m et r ic t hat can act ually be configur ed depends on t he I OS ver sion in use. N OTE

Cisco I OS Soft w are default s t o narrow m et rics. I f w ide m et rics is desired, it m ust be enabled w it h t he com m and m et ric- st yle w ide u n d er r ou t e r isis. The addit ional keyw or ds le ve l- 1 , le ve l- 2 , or le ve l- 1 -2 should be appended depending on t he m ode of oper at ion of t he r out er . All nodes should be configur ed w it h t he sam e m et r ic st y le.

Nar r ow and w ide m et r ics can coexist . The pr edom inant r eason t o configur e w ide m et r ics, in addit ion t o t he exist ing narrow m et rics, is t o provide a required t ransit ion from one m et ric

169

st yle t o t he ot her . Rout ing issues m ight occur w hen som e nodes use t he old -st y le TLVs and ot hers use t he new -st y le TLVs. I n such cir cum st ances, t he infor m at ion on w hich t he SPF calculat ion is based m ight var y significant ly from node t o node. This can cause rout ing loops; and t herefore, net w ork adm inist r at or s need t o ensur e t hat all nodes ar e configur ed sim ilar ly.

M ig r a t ion f r om N a r r ow t o W id e M e t r ics Cisco I OS Soft w ar e pr ovides a t hir d m et r ic st yle com m and t o suppor t t r ansit ion dur ing m et r ic m igr at ion. The com m and m et ric- st yle t r a nsit ion is hidden in I OS. I f a m igrat ion from old -st y le t o new -st y le m et r ics is r equir ed, t he easiest and m ost pain -fr ee m et hod is t o int r oduce a flag day, w hen availabilit y of net w or k ser vices is com plet ely disr upt ed w hile t he changes ar e being im plem ent ed. The dow nside of t his is t hat ser vice int er r upt ion m ight not be accept able because of oper at ions char t er . Anot her appr oach t o m et r ic m igr at ion is t o use bot h t he new -st y le and old -st y le TLVs t oget her w it h t he m et ric- st yle t r a n sit ion com m and. Doing t his, for ces each r out er t o adv er t ise and pr ocess r out es w it h old and new m et ric inform at ion, w hich even t hough im plies redundancy, ensures t hat all rout ers in t he net w or k under st and all t he adver t ised infor m at ion. One requirem ent for using t his approach is t hat t he configured m et ric lim it s for t he old -st yle and new -st y le TLVs need t o be t he sam e. By k eeping bot h v alues t he sam e, t he com put at ion of t he SPT is not affect ed and is consist ent across t he net w ork. Bew ar e, how ev er , t hat t his par t icular m et hod does hav e som e shor t -t erm disadvant ages, such as t he follow ing:

•

All int er face m et r ics ar e lim it ed t o a m axim um value of 63.

•

The size of t he LSPs increases beca use m or e infor m at ion m ust be cont ained w it hin t hem . Therefore, t he originat ing rout er m ight fragm ent t he LSPs m ore frequent ly t han befor e, w hich m ight lead t o som e per for m ance issues.

•

There m ight be som e inst abilit y experienced during t he t ransit ion period because of t he possibilit y of increased fragm ent at ion and flooding of m ore LSPs t hroughout t he net w or k . This m ight consum e addit ional net w or k bandw idt h and also r equir e addit ional buffer ing and pr ocessing. N OTE

I f differ ent int er face m et r ics ar e used and an adj acency is advert ised m ore t han once by bot h TLV t y pes, t he int er face and adj acency w it h t he low est m et r ic is used.

170

Because t he use of bot h m et r ic-st yles is only r ecom m ended in t r ansit ion, t he dur at ion of t his per iod m ust not be ex cessiv e; and t her efor e, t he disadvant ages hold t r ue only over t he shor t t erm .

Chapt er 8

, " Net w ork Design Scenarios," provides pract ical exam ples for t ransit ioning

bet w een nar r ow and w ide m et r ics.

N on h ie r a r ch ica l D e sign When designing a nonhier ar chical I nt egr at ed I S-I S net w or k , y ou use t he sam e ar ea pr efix in t he NSAP for all r out er s in t he dom ain. The ar ea is nor m ally r un as a flat Lev el 1 or Lev el 2 net w or k. I n t his scenar io, each r out er m aint ains a single dat abase, and t here is no need for sum m ar izat ion or r out e leaking w it hin t he ar ea. A nonhier ar chical design has scaling lim it at ions and ult im at ely r equir es som e for m of r edesign int o a hier ar chical t opology if t he net w or k is t o gr ow successfully t o a lar ge num ber of nodes. As discussed pr ev iously , t he m ain dr iv er for using a nonhier ar chical design in t he past w as t hat it helped av oid subopt im al int er ar ea r out ing in Lev el-1 ar eas. This lim it at ion no longer exist s in r ecent I OS soft w ar e. A nonhier archical single ar ea design m ight pot ent ially hav e m or e r out er s per ar ea t han a hierarchical design using a num ber of areas. This m ight m ake t he SPF com put at ion m ore com plex and r equir e a longer r un t im e t o com plet ion. As discussed pr eviously, only a par t ial SPF ( PRC) needs t o be r un w hen changes ar e ex t er nal t o t he ar ea or only I P pr efix es ar e affect ed by t he changes. I nst abilit ies in one part of t he net w ork are not m asked from ot her par t s w it hin a single ar ea. The benefit s of running a rout er as bot h Level 1 and Lev el 2 w it hin a single ar ea ar e r educed in a nonhierarchical design. Such a scenario is cert ainly possible; alt hough in pract ice, it m akes lit t le sense. Consider t he design in Figure 7 - 9 . The design has a cor e of r out er s r unning as bot h Level 1 and Level 2, w it h leaf r out er s r unning as Level 1 -only and connect ed redundant ly ( du al-hom ed) t o t he cor e. Assum e only Lev el 2 adj acencies ar e enabled bet w een t he cor e r out er s so t hat t hey do not exchange Level 1 LSPs —m eaning Level 1 LSPs w ill not t r aver se t he cor e bet w een Level 1 r out er s. Level 1 r out er s have to depend on default r out es t o r each r em ot e segm ent s; how ever , because all r out er s ar e in t he sam e ar ea and t he cor e r out er s ar e not at t ached t o r out er s in differ ent ar eas, t hey w ill not set t he " at t ached bit " in t heir Level 1 LSPs. Therefore, t he Level 1 -o nly r out er s hanging off t he cor e w ill not set default s t o near by Level 1 -2 rout ers, m aking end -t o-end reachabilit y im possible. Rout e leaking could be used t o adver t ise r out es fr om t he Level 2 dat abase int o Level 1 r out er s, but t her e w ould be lit t le point in doing t his because rout e leaking is m eant for advert ising int erarea rout es int o Level 1 in a m ult i-ar ea hier ar chical net w or k.

171

Figur e 7 - 9 . N onhie r a r chica l a r e a s.

A w ay ar ound t his is t o enable Level 1 r out ing over all r out er s. How ever , t his defeat s t he purpose of running Level 2 addit ionally on t he core rout ers because t his t ransform s t he w hole dom ain int o a flat Lev el 1 ar ea w it h r edundant Lev el 2 r out ing. I f no connect ions t o ext er nal ar eas exist , no int er ar ea r out ing is r equir ed and, t her efor e, you can m ake all r out er s Level 1 or Level 2 -only t o opt im ize use of net w or k r esour ces. I f an area is designed as Level 1 -2 and one or m or e of t he cor e rout er s ar e connect ed t o ot her ar eas, t he at t ached bit is set in t he Level 1 LSPs of Level 1 -2 r out er s, pr ov iding an ex it point for Lev el 1 only r out er s. I n t his scenar io, you can also select ively leak int er ar ea pr efixes Level 2 int o Level 1. This avoids t he possibilit y of subopt im al r out ing and ensur es t hat t he Level 1 r out er s pick t he best point for ex it ing t he ar ea.

Figure 7 - 1 0

show s t his t y pe of design.

172

Figur e 7 - 1 0 . Ru n n in g a n I S a s Le ve l 1 t o Le ve l 2 in a sin gle a r e a .

A design w it hout hier ar chy is cer t ainly m uch sim pler t han one w it h hier ar chy . As y ou hav e j ust seen, how ev er , a design can som et im es be a lit t le m or e challenging w hen m ix ing bot h Lev el 1 and Lev el 2 r out ing.

Interaction with BGP I nt egrat ed I S-I S coexist s w it h BGP, predom inant ly w it hin I nt ernet service provider net w orks. Underst anding t he int eract ion bet ween I S-I S and BGP is par am ount w hen designing such net w orks. Som et im es, t his int eract ion can be com plex. Wit hin such environm ent s, I nt egrat ed I S-I S, being an I nt erior Gat ew ay Prot ocol, is used t o car r y t he BGP nex t -hop and local r out es. This is t he m ain funct ion w hen using I nt egr at ed I SI S as an I GP in such env ir onm ent s. As discussed lat er , how ev er , I nt egr at ed I S-I S int er act s in ot h er w ay s w it h BGP. The next hop addr esses associat ed w it h BGP r out es m ust be know n for t he BGP r out es t o be useful for for w ar ding t r affic. A pr ocess w it hin I OS scans t he I P r out ing t able t o ensur e t hat t he next hop of BGP learned prefixes is valid and reachab le. I f a next hop is found t o be invalid or unr eachable, an alt er nat e pat h is select ed. Sy nchr onizat ion is a BGP capabilit y t hat cont r ols how BGP int er act s w it h t he I GP. The sy nchr onizat ion feat ur e is enabled by default w hen r unning BGP, and it s pur pose is t o ensur e t hat all I nt er nal BGP ( iBGP) lear ned r out es ar e k now n also w it hin t he I GP and, t her efor e, av ailable at all ot her r out er s in t he aut onom ous

173

syst em before advert ising such rout es t o ext ernal dest inat ions. This avoids t raffic black-holing, w her e t raffic is at t r act ed fr om r em ot e ASs, only t o be dr opped because som e r out er in t he pat h doesn't k now how t o r out e t o t he t ar get addr ess. The synchr onizat ion r equir em ent can be disabled w it h t he " no synchr onizat ion" com m and under t he BGP pr ocess. I n t his scenar io, r out es w ill be adv er t ised, ir r espect iv e of t he ex ist ence of an I GP r out e. How ever , synchr onizat ion needs t o be t ur ned off only w hen all t r ansit r out er s w it hin t he AS ar e r unning BGP or w hen t he AS is not a t r ansit AS. I n

Figure 7 - 11 ,

AS2 is shown

as a t r ansit , for w ar ding t r affic bet w een AS1 and AS3. Figur e 7 - 1 1 . I n t e r a ct ion w it h BGP: iBGP syn ch r on iza t ion .

RTA and RTB ar e ex t er nal BGP peer s ( eBGP) and so ar e RTD and RTE. RTB and RTD ar e int er nal BGP peers ( iBGP) . I f RTC in AS2 w ere t o run I S-I S only and not par t icipat e in t he iBGP w it h RTB and RTD, you w ould need t o r edist r ibut e eBGP r out es int o I S-I S t o ensur e t hat RTC has full inform at ion t o forw ard packet s bet w een AS1 and AS3. How ever, redist ribut ing BGP int o I GP should be av oided at all cost s. One sim ple r eason for t his is t hat t her e m ight be m or e rout es carried in BGP t han I S-I S can support . You m ight recall t hat current ly I S-I S is lim it ed t o about 30,000 rout es, w hereas t he I nt ernet BGP t able is cur r ent ly ( at t he t im e of w r it ing) holding ov er 100,000 r out es. Synchronizat ion ensures t hat t raffic is not rout ed bet w een AS1 and AS3 t hrough RTC, w hich has no know ledge about t he ext er nal r out es exchanged bet w een RTB and RTD t hr ough BGP. The best apro ach t o solv e t his is t o enable BGP peer ing on RTC. I n t hat case, sy nchr onizat ion can be t ur ned off on all BGP r out er s in AS2.

174

Use of the Overload Bit with BGP Anot her sit uat ion w her e I nt egr at ed I S-I S int er act s w it h BGP is w hen using a feat ur e of t he I SI S pr ot ocol t o avoid black-holing t r affic at init ial pow er-on or dur ing r eload of a r out er . Nor m ally , t he r out er set s t he ov er load-bit in it s LSP t o w ar n all ot her r out er s of an ov er load condit ion t hat would m ake it pot ent ially unreliable as t ransit . The capa bilit y is defined in t he original I S-I S specificat ion but w as never lever aged in act ual im plem ent at ions. A r ecent ly int r oduced applicat ion of t he over load bit is for cont r olling int er act ion of I S-I S and BGP in pot ent ial service -im pact ing sit uat ions. When a rout er running bot h I nt egrat ed I S-I S and BGP r eloads, it m ight not hav e had enough t im e t o r eceive t he full BGP t able befor e it st ar t s par t icipat ing in for w ar ding t r affic, even t hough it m ight advert ise reachabilit y t o I GP next hop of a BGP rout e. I n such a sit uat ion, t r affic can be dr opped if t he r out er is used as t r ansit for dest inat ions it does not yet know . To av oid t his sit uat ion, y ou can use a pr ot ect ion m echanism w it hin I S-I S t hat set s t he ov er load bit in t he rout er's LSP t o t ell all ot her rout ers not t o include t his par t icular r out er w hen calculat ing t he shor t est pat h t r ee. The r out er t hen w ait s for a signal fr om t he BGP pr ocess aft er a r easonable int er v al w hen all BGP pr efix es ar e ex pect ed t o hav e been r eceiv ed. Because BGP has m any m or e pr efixes t o r eceiv e and deal w it h t han an I GP, such as I S-I S, it t ypically t akes m uch longer t o converge. Aft er BGP convergence is flagged, t he rout er can t hen flood out anot her LSP w it h t he ov er load bit t ur ned off. The follow ing com m and can be used t o set t he overload bit on st ar t up unt il BGP signals t hat it has finished conver ging:

router isis set-overload-bit on-startup wait-for-bgp Figure 7 - 1 2

illust r at es t he use of t he ov er load bit . Ther e is a default delay of t w o m inut es ( w it hin

w hich BGP is expect ed t o updat e I S-I S w it h it s st at e) . How ever, t his updat e delay pa ram et er is configur able under t he BGP r out er pr ocess as show n her e:

175

Figur e 7 - 1 2 . I nt e r a ct ion w it h BGP: ove r loa d bit .

router bgp 100 bgp update-delay I n m ost current I nt ernet dom ains, BGP t ypically converges in less t han 5 m inut es depending, of cour se, on a num ber of fact or s, such as t he num ber of r out es, num ber of peer s, t y pe of r out er s, bandw idt h capacit y, and so on. Should it t a ke longer t han expect ed for BGP t o converge and t he BGP not ificat ion is delayed significant ly longer t han expect ed, I OS clears t he ov er load bit aft er 10 m inut es. Anot her scenar io in w hich t he use of t he ov er load bit pr ov ides a sim ilar adv ant age as in t he int er act ion w it h BGP is w hen r unning I nt egr at ed I S-I S as t he I GP for MPLS net w or ks. Dur ing boot up, an MPLS r out er m ight not y et hav e r eceiv ed all labels; t her efor e, it w ould be w ise not t o use t his r out er for a per iod of t im e, t o allow it t o fully r eceive all labels. I n t his sit uat ion, t he I S-I S ov er load bit can again be set on st ar t up of t he r out er . A t y pical v alue in t his case w ould be appr ox im at ely 2 m inut es. The addit ional com m ands t hat allow t he ov er load bit t o int er act w it h BGP ar e av ailable in recen t r eleases of Cisco I OS Soft w ar e. The I ETF dr aft dr aft -m cpherson-isis -t r ansient -00.t xt ex plains and for m alizes t he use of t he ov er load bit in I S-I S t o av oid black -holing t raffic.

176

IS-IS Scaling Issues—Network Stability and Convergence As w it h any pr ot ocol, t he capabilit y t o scale is im por t ant because it allow s a net w or k t o gr ow in a cont r olled and st able m anner . Many fact or s det er m ine w het her a net w or k w ill successfully scale. I f a net w or k is inher ent ly unst able, it w ill be difficult t o scale. The inst abilit ies m ight be because of flapping links, w hich fr equent ly ar e not under t he cont r ol of t he net w or k oper at or . How ever , t he net w or k oper at or can im pose cer t ain changes t o cont ain t he inst abilit ies.

Scalability The m ain fact or s t hat cont r ibut e t o net w or k sca labilit y are as follow s:

•

Num ber of rout ers

•

Num ber of links

•

Num ber of int ernal and ext ernal rout es

•

St abilit y of links

•

Flooding

• •

Mem or y Pr ocessing capacit y ( CPU)

The flooding of LSPs is pr obably t he m ost influent ial of t hese fact or s w hen looking at scaling. The less infor m at ion t hat r out er s in t he net w or k have t o handle, t he m or e t he net w or k can scale. I n ot her w or ds, you can scale by cont r olling t he am ount of flooding t hr oughout t he net w or k. This also pr ofoundly affect s t he am ount of pr ocessing t hat t he r out e rs have t o per for m . The r out e pr ocessor s in t he r out er s don't need t o w or k as har d w hen t her e ar e only few LSPs and not m uch r out ing infor m at ion in each LSP t o w or k w it h. Ther efor e, t he am ount of backgr ound flooding can be significant ly r educed t o enhance scalabilit y. The t w o m ain flooding-relat ed t im ers —Maxage and LSP refresh int erval—can be incr eased t o t he r egion of t heir m axim um values, approxim at ely 18.7 hours, t o help reduce t he frequency of periodic flooding. The LSP refresh int erval and Maxage can be adj ust ed, as show n in t he follow ing configurat ion

snippet:router isis lsp-refresh-interval 65000 max-lsp-lifetime 65535 I OS j it t er s t hese t im er s w it hin som e lim it s fr om t he configur ed values t o ensur e t hat r out er s do not refresh t heir LSPs at t he sam e t im e t o prevent overloading t he rout ers. N OTE

Th e lsp- r e fr e sh- int erva l is alw ay s configur ed w it h a v alue less t han t he m ax- lsplifet im e t o ensur e t hat exist ing LSPs ar e r efr eshed befor e t hey r each m axage and ex pir e.

177

Ot her t im er s can be m odified t o reduce t he am ount of flooding and incr ease scalabilit y . For ex am ple, because ex cessiv e flooding ov er low -bandw idt h links m ight cause problem s, Cisco I OS Soft w ar e uses a pacing m echanism t hat allow s flooding t o consum e only 50 per cent of t he configured bandw idt h, on low -bandw idt h links at T1 rat es and below . The int erface com m and isis lsp- in t e r va l also can be used in conj unct ion w it h t his t o cont r ol t he int er v al bet w een successiv e LSP r et r ansm issions. Anot her scenar io in w hich flooding needs t o be cont r olled t o assist scalabilit y is w hen r unning I nt egr at ed I S-I S over NBMA net works. I S-I S does not suppor t t he point -t o-m ult ipoint net work t ype, and, t her efor e, it is r ecom m ended t o use point -t o-point subint erfaces for NBMA m edia. For highly m eshed NBMA envir onm ents, m esh gr oups can be used t o cont r ol t he flooding over t he point -t o-point link s. Mesh gr oups select iv ely block flooding on a per-subint erface basis. Flooding m ust be facilit at ed over t he best - and m ost -robust pat hs only. The m esh -gr oup feat ur e m ust be used w it h car e because m isconfigur at ion coupled w it h link failur es can r esult in par t it ioned flooding. See Chapter 8 for fur t her discussions on I S-I S m esh-group applicat ions. The oper at ion of I S-I S m esh groups has been recent ly st andardized in t he I EFT and published in RFC 2973.

Stability By using a hier ar chical net w or k design w it h m ult iple ar eas, y ou can cont r ol t he am ount of flooding in t he net w ork. Also, by im plem ent ing a st ruct u red I P addressing schem e and t aking adv ant age of sum m ar izat ion, y ou can r educe t he am ount of I P infor m at ion t hat t he r out er s hav e t o cope w it h. So, by using a com binat ion of ar eas, sound I P addr essing, and sum m ar izat ion, t he net w or k can be opt im ized t o sca le t o a lar ge num ber of nodes. This com binat ion of areas, w ell-planned I P addr essing schem e, and sum m ar izat ion also cont ribut es largely t o t he st abilit y of t he net w ork. As discussed previously, by using sum m arizat ion, inst abilit ies can be hidden from t he rest of t he net w or k. This cont r ibut es t o t he ov er all st abilit y of t he net w or k and m ust be im plem ent ed w her e possible. A st able net w or k pr ov ides an ex cellent base for gr ow t h and needs t o be consider ed w it h equal or gr eat er im por t ance t han t he int r oduct ion of new feat ures. I t is ext rem ely difficult t o int r oduce new feat ur es if t he net w or k is not st able; t her efor e, st abilit y m ust be given pr ior it y at t ent ion.

Processing Resources You m ight recall from

Chapt er 6 ,

" The Short est Pat h First Algorit hm ," t hat t he am ount of rout ing

infor m at ion car r ied in t he net w or k has dir ect bear ing on t he load placed on t he r out e processors in rout ers during rout ing churns. Unt il recent ly, t he com put at iona l t oll of t he SPF Algor it hm posed a significant challenge t o I P r out er s.

178

For t unat ely, t he ar chit ect ur e of m oder n r out er s pr ovides a clean separ at ion bet w een t he dat a forw arding plane and t he cont rol plane. Therefore, rout e processors in m ost m odern rout ers are hardly involved in heavy-dut y packet forw arding. I n such rout ers, t he rout e processor dedicat es m ost of it s processing recources t o cont rol plane act ivit ies, including rout e com put at ion. Also, t he fast er CPUs used in cur r ent r out e pr ocessor designs alleviat e m ost com put at ional challenges. The ar chit ect ur e of t he I S-I S pr ot ocol also pr ovides unique oppor t unit ies t o place less st r ess on t he r out e pr ocessor , specifically for I P r out ing applicat ions. For exam ple, I P pr efixes ar e ent er ed on t he shor t est path t ree as leaves; t herefore, any changes in I P -only infor m at ion r esult s in t he less pr ocessing-int ensive Part ial Rout e Calculat ions ( PRC) inst ead of t he m ore pr ocessor-int ensive full run of t he SPF algorit hm . The I S-I S pr ocess r esponsible for SPF and PRC com put at ions is t he decision process. The updat e pr ocess is r esponsible for flooding LSPs. The ext ent of CPU ut ilizat ion is cer t ainly of m uch less concer n t hese days because of t he availabilit y of fast and capable pr ocessor s. On RSP4/ RSP8-based and t he 1200 0 I nt ernet Rout er series, t he I S-I S SPF process norm ally consum es less t han one per cent of t he r out e pr ocessor 's CPU r esour ces. This pr ovides net w or k operat ors w it h great er confidence in running t he I S-I S pr ot ocol as an I GP. Also, I S-I S can sur v iv e subst ant ial inst abilit ies in net w orks of t he scale of hundreds of rout ers and t housands of r out es, w it h CPU ut ilizat ion spiking only t em por ar ily t o r easonable nont hr eat ening levels.

Improving Convergence Conver gence has alw ays been an im por t ant t opic for m any netw or k oper at or s because it defines net w or k availabilit y in t he face of disr upt ive inst abilit ies. The t im e t aken for an I GP t o conv er ge depends on a num ber of fact or s, including t he size of t he net w or k , st abilit y , and available bandw idt h on t he links in t he net w or k ; t he pr ocessing capacit y of t he r out er s; and so on. From a prot ocol perspect ive, Dij kst ra's short est pat h first algorit hm is cent ral t o I S-I Sr elat ed r out ing conver gence issues. Alt hough t he base SPF algor it hm has essent ially r em ained unchanged in m ost I S-I S im plem ent at ions, t her e has been significant effor t in t he Cisco im plem ent at ion t o pr ovide var ious enhancem ent s t ow ar d speeding up conver gence. Recent dev elopm ent s led t o t he em er gence of OC-192 int erfaces, providing speeds in t he 10 Gbps range. Ther e have also been sever al enhancem ent s t o r est or at ion and pr ot ect ion m echanism s at Lay er 2, r esult ing in r est or at ion of link failur e w it hin t he sub 100-m illisecond range. I OS enhancem ent s t o I nt egrat ed I S-I S include new capabilit ies, such as being desig ned t o speed up Layer 3 convergence: Fast hellos, capabilit y t o disable hello padding, 1 -second hello holdt im es, and so on. These feat ur es, t oget her w it h sev er al enhancem ent s t o t he SPF Algor it hm , help achiev e bet t er conv er gence t im es t han befor e. A basic definit ion of convergence is t he t im e it t akes for t he net w ork t o reest ablish connect iv it y bet w een t w o point s aft er a failur e ev ent occur s. This also im plies t hat t her e is an alt er nat ive pat h bet w een t he t w o point s, t hat t r affic is r er out ed t o aft er t he fa ilure. This is a sim ple definit ion of conver gence, and oft en it can be m uch m or e com plex w hen applied t o a lar ge I SP env ir onm ent .

179

The conver gence t im e pr edom inant ly depends on t he follow ing:

•

Link failur e det ect ion

•

Change pr opagat ion

•

I nit ial w ait befor e SPF com put at ion

•

SPF com put at ion t im e

• •

Rout ing t able updat e Forwarding inform at ion base updat e

Lin k Fa ilu r e D e t e ct ion Link failur es can be det ect ed in a num ber of w ay s. Each r out er k eeps t r ack of t he st at e of it s int er faces by look ing at t he phy sical st at e. For exam ple, rout ers w it h connect ing serial lines keep t rack of an elect rical signal from t he CSU/ DSU. Opt ical int erfaces t rack incom ing light signals. Failur es of t hese signals can be det ect ed w it hin m illiseconds. The det ect ion and r ecept ion of an elect r ical or opt ical signal is not enough t o j udge t he end -t oend int egrit y of a link. To ensure full connect ivit y over a link bet w een end devices, som e form of k eepaliv e pr ot ocol is used w it hin t he fr am ew or k of a Lay er 2 pr ot ocol. HDLC and PPP ar e exam ples of Laye r 2 pr ot ocols w it h keepalive m echanism s. These Layer 2 keepalives ar e sim ilar t o t he Layer 3 hellos used in I nt egr at ed I S-I S and OSPF. Typical t im e -ou t befor e a failur e is est ablished occur s aft er loss of t hr ee k eepaliv es. Keepaliv es ar e nor m ally sent ev ery 10 seconds by default , giving a 30 -second int erval of no keepalives before loss of connect ivit y is declar ed. When t he use of Lay er 2 k eepaliv es does not sufficient ly indicat e t he end -to-end st at e, ot her m et hods m ust be used; and it is oft en t he r out ing p rot ocol it self t hat is relied on t o keep t r ack of t he st at e t hr ough t he hello pr ot ocol. As discussed in pr evious chapt er s, I nt egr at ed I S-I S uses I I Hs bet w een rout ers, and each I I H carries a hold -t im e field. The holdt im e indicat es how long a r out er m ust w ait for a neighbor 's hello befor e t ear ing dow n t he adj acency . The m inim um holdt im e t hat can be adv er t ised in an I I H is 1 second. The default I I H holdt im e in I OS is 30 seconds. When an int er face or link goes dow n, Layer 2 keepalives are lost . I n t his sit uat io n, y ou do not alw ay s hav e t o w ait for t he I S-I S holdt im e t o ex pir e because t he int erface is im m ediat ely rem oved from t he Layer 2 adj acency t able, and t he neighbor relat ionship is t orn dow n. This Layer 2/ Layer 3 int eract ion m echanism assist s great ly in det e ct ing link failure and reducing t he overall convergence t im e. As you can see, t he holdt im e is an im por t ant fact or t hat m ust be t aken int o consider at ion and it s v alue m ust be chosen w it h gr eat car e w hen designing or configur ing a net w or k t o achiev e fast convergence. Many I SPs have configured conservat ive holdt im es of approxim at ely 60 seconds t o m aint ain st abilit y w it hin t heir net w orks. By configuring such conservat ive holdt im es, t he net work m ight t ake longer t o converge t han necessary, and t his is a t radeoff decision t hat m ust be m ade by t he net w or k adm inist r at or . I n recent I OS releases, you have t he opt ion t o set t he holdt im e t o a m inim um value of 1 second. The follow ing configur at ion show s how t o do t his:

180

interface pos0/0 isis hello-interval minimal W it h t he hold t im e fix ed at 1 second, t he hello- int erva l depends on t he v alue of t he configured hello- m ult iplie r . I f y ou m aint ain t he default hello- m ult iplie r of 3, I I Hs ar e t hen adver t ised ever y 333 m illiseconds, w hich is ext r em ely fast and can incr ease ban dwidt h, buffer, and CPU usage. When using t he m inim um holdt im e value, it m ay be necessar y t o r em ove t he addit ional padding fr om t he hello pack et s. You can do so as follow s:

router isis no hello-padding Th e no hello- pa dding com m and r em ov es padding fr om a ll I I Hs on all int erfaces t hat run I SI S. By rem oving t he hello padding and also set t ing t he hello int erval t o t he m inim um , link failures can be quickly det ect ed. Keep in m ind, however, t hat t his m ight cause inst abilit y wit hin t he net work if unst able links ex ist . Ther efor e, a t r adeoff m ust be m ade depending on t he r equir ed out com e.

LSP Ge n e r a t ion a n d Ch a n ge Pr opa ga t ion The pr eceding sect ion discusses t he m et hods of link failur e det ect ion and how you can lessen t he t im e necessar y t o det ect link failur es. This sect ion ex am ines how new LSPs t hat r eflect net w or k changes ar e issued and pr opagat ed t hr oughout t he net w or k . This act ion is oft en r efer r ed t o as LSP generat ion an d flooding. When a change occur s, a r out er gener at es a new LSP t o r eflect t he cur r ent st at e of it s im m ediat e env ir onm ent . The follow ing ar e ex am ples of ev ent s t hat cause new LSPs t o be gener at ed:

•

Adj acency flap int er face or I P addr ess change in r edist r ibut ed I P r out es

• •

Change in int er ar ea I P r out es. Assignm ent of a new int er face m et r ic

An I S-I S ro ut er also r egener at es it s LSP per iodically at t he ex pir at ion of t he r efr esh int er v al or w hen t he LSP is pur ged by anot her r out er because of packet cor r upt ion. Bot h of t hese sit uat ions ar e not dir ect ly r elat ed t o any changes in t he st at e of t he net w or k . N O TE

I n addit ion t o adj acencies and dir ect ly connect ed I P pr efixes, ot her t ypes of r out ing infor m at ion ar e also car r ied in LSPs. This addit ional infor m at ion m ight include I P prefixes redist ribut ed from ot her I GPs and int erarea I P rout es. Any changes in t hese t y pes of infor m at ion w ould also cause a new LSP t o be issued t o r eplace t he ex ist ing LSP.

181

I n t he event of const ant changes, it m ight be pr oblem at ic if t he r out er sends out a const ant st r eam of new v er sions of t he sam e LSP. To pr ev ent such a sit uat ion, a default m inim um int er val of 5 seconds exist s bet w een r egener at ion of an LSP. Addit ional changes cannot be adv er t ised in a new LSP unt il aft er t he 5 -second lapse. The LSP generat ion it self does not norm ally t ake m ore t han a few m illiseconds. How ever, t his a lso depends on t he ev ent for w hich t he new LSP is being gener at ed. Aft er t he new LSP is gener at ed, it is flooded t o all ot her r out er s in t he ar ea. As discussed in previous chapt ers, I S-I S uses a r eliable flooding m echanism on point -to-point link s and a best effort m echanism support ed by periodic synchronizat ion on broadcast m edia ( see Figure 7 - 13 ). Figur e 7 - 1 3 . Link fa ilur e a nd flooding.

The speed of pr opagat ing an LSP t hr oughout t he net w or k is an im por tant consider at ion and depends on a num ber of fact or s. The fir st fact or is t he av ailable net w or k bandw idt h, and t he second is t he diam et er of t he net w ork. Each hop t hat t he LSP m ust t raverse can t ake approxim at ely 15 t o 20 m illiseconds t o process. I f m ult ip le LSPs are flooded t hroughout t he net w or k sim ult aneously , t he delay at each hop can incr ease. On a point -t o-point link, if a neighbor does not acknow ledge r eceipt of an LSP, it is r et r ansm it t ed ever y 5 seconds by default , unt il a cor r esponding acknow ledgment is received. I f LSPs are dropped, t hey are likely t o be r eceived t hr ough differ ent pat hs. So, as you can see, fur t her explor at ion is r equir ed t o fully under st and t he effect of LSP pr opagat ion w it h r espect t o ov er all conv er gence.

182

Flooding is st alled during t he SPF com put at ion as all pr ocessing r ecour ces ar e dedicat ed t o t he SPF com put at ion t o speed up ex ecut ion. This also pr ev ent s possible r ace condit ions w hen t he link-st at e dat abase ( LSDB) changes during t he SPF com put at ion. I nit ial dat abase synchroniza t ion is anot her fact or t hat m ight influence overall convergence. I f t he lsp- int erva l is 33 m illiseconds, for exam ple, and t he LSDB is holding 600 LSPs, it m ight t ake appr oxim at ely 20 seconds t o flood out t he full LSDB. On LANs, a r out er t hat has j ust been brought up can synchronize it s LSDB only aft er it receives CSNPs. On t he average, t his m ight t ak e 10 seconds because by default , CSNPs ar e t r ansm it t ed by t he DI S ev er y 10 seconds. On point -to-point links, t he LSDBs are synchronized aft er adj acency est ablishm ent . Recent I OS r eleases allow t he lsp- int erva l t o be r educed, w hich can speed up dat abase synchr onizat ion and, t her efor e, help decr ease t he over all conver gence t im e.

I n it ia l W a it Be for e SPF Com pu t a t ion Changes t o t he Link-St at e dat abase t r igger SPF and PRC com put at ions. I f a r out er r eceives a new LSP, it is pr obable t hat it w ill r eceive m or e LSPs in t he follow ing seconds. Specifically, any change in t he t opology can im pact m any r out er s. Therefore, if a rout er runs SPF im m ediat ely when it det ect s a change , it probably m ight need t o r un a second SPF r ight aft er t he fir st . Because of t his, t r igger ing an im m ediat e SPF can cause slow er conver gence t han inst ead of w ait ing a shor t t im e t o capt ur e m ult iple event s before running SPF. Cisco I OS Soft w ar e has a delay m echanism t o assist in such sit uat ions. An int ent ional delay of 5.5 seconds occurs bet w een LSDB change det ect ion and running t he SPF com put at ion. This v alue is chosen t o be a lit t le higher t han t he default LSP gener at ion int er v al of 5 seconds t o t ake DI S changes int o considerat ion. Som et im es, changes in t he DI S can cause rout ers t o gener at e a new LSP t w ice, w her e t he second LSP gener at ion is defer r ed for 5 seconds.

0 SPF Com p u t a t ion Tim e The dur at ion of t he SPF com put at ion ov er an ar ea depends on m any fact ors, including t he follow ing:

•

Size of t he ar ea ( num ber of nodes and link s)

•

Num ber of I P prefixes ( I nt ernal and Ext ernal)

• •

CPU speed Syst em capacit y of rout e processor ( m em ory bandw idt h, et c.)

The SPF r unt im e also includes t he inser t ing of best r out es int o t he I P r out ing t able. Not e t hat packet for w ar ding cont inues dur ing SPF com put at ion, based on t he cur r ent cont ent s of t he r out ing t able.

183

Gener ally, w hen using a high-speed CPU in t he 200 MHz range, SPF runt im es for an average sized area about 400 nodes should t ake significant ly less t han 5 seconds. I n Chapt er 6 , sect ion " I S- I S SPF Oper at ion on Cisco Rout ers ," it w as est im at ed t hat it w ould t ak e appr ox im at ely one second t o com put e t he SPF t r ee for 1000 nodes by such a pr ocessor . I f t he SPF com put at ion t akes longer t han 5 seconds, rout ers t hat have sent LSPs m ight st art t o ret ransm it t hem if t h e LSPs have not been acknow ledged yet . Under such cir cum st ances, a higher LSP r et r ansm it value can be used as a w or k ar ound; how ev er , a long SPF r unt im e im plies t her e ar e under ly ing issues t hat need t o be furt her invest igat ed. Sim ilar t o t he init ial delay bet w een det ect ing t he ev ent and r unning t he fir st SPF, an int ent ional delay is also enfor ced bet w een consecut iv e SPF r uns. This delay is set t o a m inim um of 10 seconds by default , and it is int ended t o pr event r unning excessive SPF com put at ions in rapid succession. The com m and spf- int erva l can be used t o m odify t he default m inim um delay value. I n any case, a sm aller value t han t he default does not necessarily reduce t he overall convergence t im e because t here m ight be ot her fact ors in play wit hin t he specific env ir onm ent .

Exponential Backoff The I S-I S Exponent ial backoff feat ur e w as only r ecent ly int r oduced int o Cisco I OS Soft w ar e. The goal of t his feat ure is t o expedit e convergence by providing fast , appropriat e responses t o net w or k ev ent s, y et slow dow n r e sponsiveness in t he face of consist ent chur n t o r egain st abilit y. The slow dow n delays conver gence but r em oves t he pot ent ial for sever e and prolonged disrupt ion of net work availabilit y. The exponent ial backoff algorit hm is essent ially an int elligent t hr ot t ling algor it hm t hat cont r ols LSP gener at ion, SPF, and PRC com put at ions in r esponse t o net w or k event s. The algor it hm uses t he follow ing t hr ee par am et er s and t w o const ant s:

•

I nit ial w ait per iod

•

Secondar y w ait per iod

•

Max im um int er v al

• •

I ncr ease fact or ( const ant ) St able period fact or ( const ant )

The algor it hm w or k s as follow s. When t he fir st occur r ence of a par t icular net w or k ev ent t r igger s a r esponse or act ion, t he init ial w ait t im er is st ar t ed. The appr opr iat e act ion is t ak en at t he expirat ion of t his t im er. I f, s hor t ly aft er t his fir st ev ent , t he sam e ev ent r eoccur s, t he t im er is fired again t ow ard an appropriat e response. How ever, for t his event , t he t im er is set so t hat t he int er v al bet w een t he pr ev ious act ion and t he nex t is at least t he secondar y w ait per iod. For any subsequent occur r ence of t he sam e ev ent , t he t im er is r eset so t hat t he nex t act ion occur s aft er an int er val of t he secondar y w ait per iod t im es t he incr ease fact or . The incr ease fact or is a fix ed const ant of v alue t w o, and it is used t o double t he w ait int er v al bet w een successive r esponses t o t he sam e net w or k event aft er t he t hir d occur r ence. So, t he int er v al bet w een r esponses t o t he second and t hir d ev ent s is t w ice t he secondar y w ait per iod, and t he int er val bet w een t he t hir d and t he four t h r esponses is at least four t im es t he

184

secondar y w ait per iod. The int er val bet w een r esponse doubles again t o at least eight t im es t he secondar y w ait per iod aft er t he nex t ev ent and so on. The int er v al bet w een t w o successiv e r esponses is allow ed t o incr ease only up t o t he m axim um int erval. From t here on, it is fixed. The algor it hm is init ialized back t o use of t he init ial w ait per iod only aft er t he sam e r esponse is not t r igger ed over an int er val longer t han t he st able per iod fact or t im es t he m axim um int erval. The st able per iod fact or is also a fix ed const ant of v alue 2. The incr ease fact or and t he st able per iod fact or ar e cur r ent ly not configur able.

Exponential Backoff Parameters Th e lsp- ge n- in t e r va l com m and cont r ols how oft en a r out er is allow ed t o gener at e and flood out a new LSP. Not e t hat ex cept dur ing LSP r efr esh, no new LSPs ar e sent out w hen t he net w or k is st able. While t he com and lsp- r e fr e sh- int erva l ( default – 15 m inut es) cont rols per iodic r esfr esh, t he lsp- ge n- int erva l com m and cont r ols t he fr equency of issuin g LSPs w hen t r igger ed by net w or k ev ent s. The default is t o send out LSPs not m or e t han once ev er y 5 seconds. The com m and is configur ed as show n in t he follow ing ex am ple:

router isis lsp-gen-interval , where x = maximum interval, y = initial wait period, and z = secondary wait period. Th e < y> par am et er is t he num ber of m illiseconds delay bet w een t he fir st t r igger and t he fir st LSP gener at ion act ion. The < z> par am et er is t he num ber of m illiseconds w ait ed bet w een t he fir st and t he second LSP gene r at ion act ions. Fr om t hen on, t he w ait bet w een t he second and t he t hir d act ion is 2z, t he w ait bet w een t hir d and t he four t h is 4z, and so on, doubling ev er y t im e sequent ially. Aft er t he w ait int er v al gr ow s t o x seconds, it r em ains fix ed unt il t her e ar e no longer any t r igger s for at least t w ice t he m ax im um int er v al ( t hat is, 2x ) . Then, t he w ait aft er a t r igger is r ev er t ed t o t he init ial w ait per iod. Th e spf- int erva l com m and cont r ols how oft en a full SPF com put at ion is allow ed. This param et er can be adj ust ed t o prevent t he rout er from perform ing SPF com put at ions t oo fr equent ly. The default is t o r un SPF no fr equent t han once ever y 10 seconds. The com m and is applied w it h t he ex ponent ial back off par am et er s as follow s:

router isis spf-interval , where x = maximum interval, period, and z = secondary wait period.

y =initial wait

The par am et er < y> is t he num ber of m illiseconds w ait bet w een t he fir st t r igger and t he fir st SPF. The par am et er < z> is t he num ber of m illiseconds w ait bet w een t he fir st and t he second SPF. Fr om t hen on, t he w ait bet w een successiv e SPF r uns doubles r elat iv e t o t he pr ev ious period. Aft er t he int erval bet ween consecut ive SPF runs grows t o t he m axim um int erval ( x) , t his delay is r et ained for all subsequent r uns. The w ait int er v al r ev er t s t o t he int ial w ait per iod only w hen t he lapse bet w een t o t w o consecut ive t r igger is at least t w ice t he m axim um int erval.

185

Th e prc- int erva l com m and cont r ols how oft en y ou ar e allow ed t o r un a PRC ( par t ial r out e com put at ion) . This is essent ially a cu t -dow n v er sion of t he SPF com put at ion inv ok ed only w hen I P pr efix infor m at ion changes. The par am et er s descr ibed for SPF ar e sim ilar ly applied t o PRC t riggers. The follow ing show s how t o configure exponent ial backoff for PRC:

router isis prc-interval w her e x = m axim um int erval, y = init ial w ait per iod, and z = secondar y w ait per iod.

Exponential Backoff Example Suppose y ou m odify t he SPF int er v als and configur e an init ial w ait of 1 second, a secondar y w ait of 5 seconds, and a m ax im um int er v al of 3 0 seconds. Suppose, fur t her , t hat t her e is a const ant st r eam of SPF t r igger s. The fir st SPF r un t akes place 1 second aft er t he fir st t r igger occur s. The second SPF t hen t ak es place 5 seconds lat er aft er t he fir st SPF. The t hir d SPF occurs 10 seconds lat er aft er t he second. The four t h SPF occur s 20 seconds aft er t he t hir d. The fift h SPF t akes place 30 seconds aft er t he four t h because t he m axim um int er val bet w een t w o act ions is set t o 30 seconds. The six t h SPF happens 30 seconds lat er , and so on. I f t he st rea m of SPF t r igger s st ops for 60 seconds aft er t he last SPF, t he init ial w ait per iod can be applied again as t he int er val bet w een t he next t r igger t o t he subsequent r un of SPF. Suppose t hat you adj ust t he LSP -generat ion int erval and configure an init ial w ait of 10 m illiseconds, a secondar y w ait of 2.5 seconds, and a m ax im um int er v al of 10 seconds. Under const ant change, an LSP w ill be cr eat ed 10 m illiseconds aft er t he fir st change. Ther eaft er , t he int er vals bet w een consecut ive LSP generat ions w ill be 2.5, 5, 10, 10, 10… seconds. Aft er 20 seconds of no changes, t his ser ies can st ar t ov er again. As dem onst r at ed, t he exponent ial backoff algor it hm pr ovides a m echanism t o aggr essively achieve fast convergence w hile ret aining t he capabilit y t o be m ore conservat ive tow ar d achieving st abilit y w hen flux in t he net w or k is pr olonged. Alt hough t his feat ur e has been av ailable in Cisco I OS Soft w ar e for a w hile now , it has not y et been w idely used. Ther efor e, net w or k oper at or s should exer cise caut ion w hen deploying it in prod uct ion net w or ks. Fam iliar it y w it h t he net w or k and a clear sense of obj ect ives and ex pect at ions ar e essent ial for successful deploy m ent . I t is difficult t o specify any absolut e recom m endat ions for values of t he param et ers used in t he backoff algorit hm because effect iv e v alues depend on t he env ir onm ent and desir ed r esult s. When choosing par am et er v alues, it m ight be useful t o ex per im ent in a t est env ir onm ent pr ior t o pr oduct ion deploy m ent .

Fast Convergence at Adjacency Setup Pack et s sent t o a r out er r ight after it has com plet ed boot up m ight be lost . This is possible because I S-I S r out er s ar e allow ed t o be adj acent befor e t heir link-st at e dat abases ar e com plet ely sy nchr onized.

186

Consider

Figure 7 - 14 .

I n t he ev ent of RTB r eloading, t her e could be a sm all w indow dur ing w hich

it m ight not have synchronized it s dat aba se w it h all neighbor s and doesn't k now t he com plet e t opology. LSPs m ight flood bet w een neighbors pot ent ially at t ract ing t raffic t o dest inat ions not yet resolved. This m eans RTB m ay black-hole t r ansit t r affic t hat could hav e been r out ed by neighbor s ov er alt er nat e pat hs av ailable. Figur e 7 - 1 4 . Fa st con ve r ge n ce a t a dj a ce n cy se t u p.

Assum e t hat t he shor t est pat h fr om RTC t o net w or k N is t hrough RTB and RTA. RTB reloads, and t he net w or k r econver ges. The new pt h fr om RTC t o net w or k N is t hrough RTF - > RTE - > RTD -> RTA. How ever, t he LSP originat ed from RTB does not expire im m ediat ely from t he LSDBs on all r out er s ( except RTB it self) . Aft er RTB has com plet ed t he reload and backup running, adj acencies wit h RTC, RTE, and RTA are re -est ablished. Before dat abases are synchr onized how ever , RTC r uns SPF and uses t he old ver sion of RTB's LSP in view of t he new valid adj acency and, t herefore, rediscovers t he old rout e t o prefix N. The LSP of a r out er is not im m ediat ely pur ged fr om t he Link-St at e dat abase by neighbors w hen it s adj acency is invalidat ed, even t hough r elat ed r out es ar e cleaned up fr om t he r out ing t able. Hav ing discov er ed t he old r out e fr om t he old LSP of RTB, RTC begins forwarding t raffic t o RTN t hrough RTB, even t hough t he lat t er is yet t o fully discover t he ent ire t opology and com put e r out es. Tr affic for w ar ded by RTC t o RTB in t hese ear ly st ages m ight be dr opped, and RTC w ould hav e been bet t er off using t he alt er nat e pat h. A recent enhancem ent t o t he I S-I S im plem ent at ion in Cisco I OS Soft w ar e allow s a r out er t o im m ediat ely flood it s ow n LSP ev en befor e sending CSNP pack et s. This does not elim inat e t he black -holing pr oblem . How ev er , t he ov er load bit can be set in t he ear ly LSP t r ansm it t ed t o not ify ot her rout ers not t o calculat e t ransit pat hs t hrough t he reloaded rout er for a w hile. The r out er can be configur ed t o adver t ise it s LSP w it h t he over load bit for a specific am ount of t im e aft er r eload, as follow s:

set-overload-bit on-startup

187

By t he end of t he int er v al w hen t he r out er is ex pect ed t o be fully oper at ional, a nor m al LSP w it h t he over load bit clear ed is t hen flooded int o t he net w or k. A t ypical set t ing for t he w ait ing per iod unt il t he r out er is fully oper at ional is 120 seconds.

Comparing Integrated IS-IS and OSPF The incr easing popular it y of I S-I S has dr aw n significant at t ent ion t o it s r elat iv e m er it s in cam par ison w it h OSPF. The I P net w or king com m unit y has fr equent ly expr essed int er est in an elaborat e com parison bet ween t he t wo prot ocols, m ost ly from a pract ical st andpoint . However, very frequent ly, t he I S-I S ver sus OSPF debat e ends up w it h an academ ic slant —if not religious. Of int erest are t he sim ilarit ies and differences bet w een t hese prot ocols, as w ell as any adv ant ages and disadv ant ages of using one v er sus t he ot her . The bot t om line, how ev er , is t hat t w o pr ot ocols ar e so sim ilar , in t er m s of basic funct ionalit y and oper at ion, such t hat it is r eally difficult , if not im possible t o say, if one is gener ally bet t er or m or e efficient t han t he ot her . Ther e ar e m any differ ences, bot h significant and t r iv ial, t hat t end t o slant adv ant ages t ow ar d one ov er t he ot her for specific applicat ions or in deploy m ent -specific envir onm ent s. This sect ion com par es I ntegrat ed I S-I S and OSPF, ident ifies m aj or sim ilarit ies and crit ical differ ences as obj ect iv ely as possible, and t r ies t o r efr ain fr om biased com m ent s, such as t hose fr equent ly w it nessed in sim ilar com par isons. The advant ages and disadvant ages of eit her pr otocol ar e m ent ioned w her e possible. The over all goal of t his sect ion is t o pr esent you w it h obj ect ive fact s about each pr ot ocol w it hout m aking any j udgm ent s. Net w or k oper at or s seeking t o choose I S-I S or OSPF as an I GP should benefit from t he follow ing discu ssions, w hich should also help clar ify any m isconcept ions or unfounded bias t ow ar d eit her pr ot ocol.

A Brief Historical Tour A br ief hist or ical r eview of each pr ot ocol m ight be appr opr iat e her e t o set t he st age for t he follow ing discussions. Bot h I nt egrat ed I S-I S and OSPF w er e specified in t he lat t er par t of t he 1980s. Around 1988, t he Unit ed St at es Nat ional Science Foundat ion Net work ( NSFnet ) deployed an int er ior gat ew ay pr ot ocol based on an ear ly I S-I S dr aft . Ar ound t he sam e t im e, dev elopm ent w or k on OSPF w as st ar t ed. OSPF act ually evolved fr om t his ear ly ver sion of I S-I S but w it h I P as it s basic pr em ise. OSPF cor e concept s, such as t he flooding of link-st at e infor m at ion, t he shor t est pat h fir st algor it hm ( SPF) for calculat ing best pat hs, use of designat ed r out er on br oadcast link s, and so on w er e all bor r ow ed fr om t his ear lier v er sion of I S-I S. Ver sion 1 of t he OSPF pr ot ocol w as published as RFC 1131 in Oct ober 1989. Near t he sam e t im e ( Decem ber 1990) , I nt egrat ed I S-I S feat ur ing ext ensions for I P r out ing w as also published as RFC 1195. The I S-I S prot ocol w as originally specifed in I SO 10589 for dynam ic r out ing of CLNP dat agr am s in t he I SO CLNS env ir onm ent . Cisco's im plem ent at ion of I nt egrat ed I S-I S w as first released in t he 1991/ 1992 t im e fram e. Significant enhancem ent s t o t he Cisco I OS im plem ent at ion of I S-I S w er e int r oduced in 1994 in conj unct ion w it h suppor t for Net w ar e Link Ser vice Pr ot ocol ( NLSP) , w hich w as designed for rout ing Novell's I PX Prot ocol. These enhancem ent s im proved resilience and robust ness of t he Cisco im plem ent at ion and int r oduced new capabilit es t hat at t r act ed t he int er est of net w or k archit ect s in t he I nt ernet com m unit y looking at m igrat ing t heir net w orks from t he Rout ing

188

I nfor m at ion Pr ot ocol ( RI P) t o a m or e r obust I GP. Lar ge scale deployment of t he I S-I S pr ot ocol in m aj or I SPs began in 1995. Anot her issue t hat pot ent ionally played int o t his w as t he U.S. gover nm ent int er est in t he I SO CLNS suit e, w hich w as r eflect ed in a r equir em ent for CLNP r out ing suppor t in t he NSFNet pr oj ect by t he Nat ional Science Foundat ion ( NSF) . Wit h it s dual rout ing capabilit ies, I S-I S seem ed t o be t he best choice of I GP t o suppor t int egr at ed r out ing of bot h I P and CLNP. Wit h a fast gr ow ing deploy ed base, t he Cisco im plem ent at ion quickly m at ured, becom ing st able and robust for use in large net w orks. I t is int er est ing t o not e t hat m ost of t he lar gest I SP net w or ks t oday r un I S-I S for r out ing I P only . I S-I S st ill rem ains popular for I SO rout ing applicat ions in t elecom m unicat ion m anagem ent net w or k s. Unlike I S-I S, w hich s t art ed life as an I SO prot ocol, OSPF w as inherent ly designed t o support only I P and w as pr om ot ed in t he I ETF as t he pr efer r ed I GP for I P net w or ks —or at least it appeared so. Because I S-I S suppor t w as not av ailable on m any r out er s ( not iceably Bay and 3Com rout er s) , OSPF aut om at ically becam e t he r out ing glue for r easonably lar ge net w or ks w it h m ult ivendor r out er plat for m s. An act ive Wor king Gr oup in t he I ETF and evolving specificat ions also w ent a long w ay t o help pr om ot e OSPF; and so OSPF becam e m or e popular and m or e w idely adopt ed com par ed t o I S-I S. I nt erest in I nt egrat ed I S-I S for I P r out ing cont inued t o gr ow , and m ost I SPs t hat spr ung up in Eur ope elect ed t o deploy t he I SO st andar ds based on I S-I S inst ead of OSPF, w hich is an I ETF st andard. Som e U.S.-based I SPs even m igrat ed from OSPF t o I nt egrat ed I S-I S. I n t he lat er par t of t he 90s, m any new I SPs adopt ed t he business m odels, net w or k ar chit ect ur e, and pr ot ocols of t he est ablished lar ge pr ovider s and t hus w ent w it h I S-I S for I GP, fur t her increasing t he deplo y ed base. OSPF also cont inued t o flour ish and cont inued t o be adopt ed by m any I SPs. I n sum m ary, bot h I S-I S and OSPF hav e pr ev ailed t hr ough t he t est of t im e and hav e est ablished t hem selves as t he I GPs of choice for service provider net ow orks. New ext ensions t o bot h pr ot ocols, such as MPLS t r affic engineer ing, have been developed over t he past t w o year s, and w it h act ive w or king gr oups for eit her pr ot ocol in t he I ETF, t hey cont inue t o evolve, essent ially in lock-st ep fashion. OSPF has been updat ed by m any RFCs since RFC1131, including a m aj or r ev ision. Ver sion 2 of t he OSPF pr ot ocol w as fir st published in July 1991 as RFC1247. The m ost cur r ent I EFT st andar d for v er sion 2 of t he OSPF pr ot ocol w as published as RFC 2328 in April 1998. All t he OSPF RFCs m ent ioned so far addr ess I Pv 4. RFC 2740 st andar dizes OSPF for I Pv6. Most of t he or iginal w or k on t he OSPF pr ot ocol w as done and docum ent ed by John Moy , w ho w as t hen at Pr ot eon, I nc. Moy w as chair m an of I ETF OSPF Wor k ing Gr oup for m any y ear s. Obviously, t he m any dedicat ed par t icipant s in t he OSPF w or king gr oup m eet ings also cont r ibut ed t o t he shaping of t he pr ot ocol in div er se w ay s. I S-I S w as seem ingly abandoned in t he I ETF aft er t he release of RFC1195 in 1990. Also, t here w as no m aj or st andardizat ion effort in t he I TU for a w hile, so I SO 10589 and RFC1195 r em ain

189

t he aut horit at ive com plet e st andards for I S-I S v er sion 1 and I nt egr at ed I S-I S, respect ively. How ever , t he I ETF I S-I S w orking group has been re -opened ov er t he last couple of y ear s t o st andardize various new app liciat ions of I S-I S, such as MPLS Traffic Engineer ing, I Pv6, and m any ot her s. Also, a second v er sion of t he I S-I S pr ot ocol is cur r ent ly being w or k ed on w it h plans t o capt ur e m ost of t he enhancem ent s over t he year s in a single place. I t should be not ed t hat t he m em berships of bot h relevant I TU and I ETF w orking groups are cont ribut ing t o t his effor t . This sect ion closes w it h an int er est ing obser v at ion t hat OSPF seem s t o be m or e docum ent ed t han I S-I S, and a large collect ion of t echnical t ext books are readily a vailable in bookst or es. Ther e is also a lar ger collect ion of OSPF design guides, w hit e paper s, and applicat ion not es at v ar ious v endor w eb sit es, including Cisco Connect ion Online ( cco.cisco.com or

www.cisco.com ) .

This

obvious dispar it y in cover age bet w een I S-I S and OSPF is int ended t o be addr essed by t his book .

Terminology The nex t sect ion cont inues t he discussions by look ing at specific com m onalit ies and differences bet w een I S-I S and OSPF. The m ost obvious place t o cont inue is t o consider t he sim ilar it ies. How ever , befor e t hat , t ake a quick look at t er m inologies associat ed w it h each prot ocol. As previously indicat ed, t hese prot ocols originat ed in different st a ndar d bodies, I S-I S in I SO ( now t he I TU) and OSPF in t he I ETF, and t her efor e, each is associat ed lar gely w it h different t erm inologies.

Table 7 - 1

list s t he t er m inology associat ed w it h each pr ot ocol and

at t em pt s t o m arch t hem w it h equivalent s in ot her prot ocol.

Table 7 - 1 . I S- I S Ve r sus OSPF Te r m inology

I S- I S End Syst em I nt erm ediat e Syst em ( I S) Circuit Subnet w ork Point of At t achm ent ( SNPA) Prot ocol Dat a Unit ( PDU) Designat ed I nt erm ediat e Syst em Not Applicable I nt erm ediat e Syst em t o

OSPF

Com m ent s

Host Rout er Link Dat alink Address Pack et Designat ed Rout er ( DR) Backup Designat ed Rout er ( BDR) Hello packet

190

I nt erm ediat e Syst em Hello PDU ( I I H) Link- St at e Packet ( LSP)

Link- St at e Advert isem ent ( LSA)

I S-I S r out ing infor m at ion is st or ed in TLVs, w hich ar e par t of LSPs. LSAs ar e act ually com par able t o TLVs used in LSPs, how ever , each LSA has it s ow n header , w her eas TLVs share a com m on header.

Link- St at e Packet

Link- St at e Updat e

OSPF link-st at e updat e is a vehicle for flooding LSAs. LSPs are advert ised individually.

Com plete Sequence Num ber Packet ( CSNP) Part ial Sequence Num ber Packet ( PSNP) Rout ing Dom ain Level 2 Subdom ain Level 1 Area Virt ual Link

Dat abase Descript ion Packet ( DBD) Link- St at e Acknowledgm ent or Request Packet Aut onom ous Syst em Backbone area Area ( non- backbone) Virt ual Link

Designed in OSPF for connect ing a part it ioned backbone or connect ing an ar ea t hat is not dir ect ly connect ed t o t he back bone ov er anot her ar ea. I n I S-I S, virt ual links are used t o connect a part it ioned Level 1 area ov er Lev el 2.

Any Level 2 rout er

AS boundary Rout er ( ASBR)

I n OSPF, t he ASBR r edist r ibut es ex t er nal r out es int o t he OSPF dom ain . Any Level 2 rout er can dist ribut e ext er nals int o t he dom ain. No special nam e. Not e: Cisco I OS Soft w ar e allow s Level 1 rout e r s t o r edist r ibut e ext er nal r out es int o t he I S-I S

191

dom ain .

Syst em I D

Rout er I D

The sy st em I D is t he k ey for SPF calculat ions. An I P address is sym bolically car r ied in LSPs. A r ecent I ETF enhancem ent of t he I S-I S pr ot ocol int r oduces a Rout er I D TLV ( Type 134) for MPLS t raffic engineer ing applicat ions.

Link- St at e Packet I D Link- St at e I D ( LSPI D)

I n I S-I S, t he LSP I D is consist ent and cont ains t he syst em I D of t he originat or, t he Pseudonode num ber, and t he LSP fragm ent num ber. I n OSPF, t he cont ent s of t he LS I D field depends on t he LS t y pe.

No equivalent in I S- Advert ising Rout er IS Common Grounds As pr eviously m ent ioned, t her e is a lot of sim ilar it y bet w een I S-I S and OSPF. The com m onalit ies ar e st r ong fr om a funct ional per spect ive, even t hough t her e a r e also significant ar chit ect ur al differ ences bet w een t hem , w hich w ill be cover ed in lat er sect ions. Som e of t he high-lev el sim ilar it ies ar e t he follow ing:

•

Bot h pr ot ocols ar e link-st at e prot ocols, requiring rout ers in an area t o exchange r out ing or link-stat e infor m at ion. The link-st at e infor m at ion is gat her ed in a Link-St at e dat abase and pr ov ides an abst r act ion of an ar ea's t opology .

•

Bot h pr ot ocols use a sim ilar m echanism , know n as flooding, for exchanging r out ing infor m at ion.

•

Bot h prot ocols use t he concep t of designat ed r out er on br oadcast links t o cont r ol flooding and const r ain r esour ce r equir em ent s for m any-t o-m any adj acencies over such m edia.

•

Bot h pr ot ocols use pr act ically t he sam e algor it hm , t he shor t est pat h fir st algor it hm ( Dij kst ra's Algorit hm ) for com put ing best pat hs based on infor m at ion in t he Link-St at e dat abase.

•

Bot h prot ocols support a t w o -level rout ing hierarchy.

•

Bot h prot ocols support classless rout ing of I P prefixes.

Highlights of Differences There are several t echnical differences bet w een the archit ect ures of t he I S-I S and t he OSPF pr ot ocols and t heir hist or ical back gr ound. This sect ion is int ended t o highlight som e of t he m aj or t echnical differences, as show n in Table 7 - 2 .

192

Table 7 - 2 . M a j or D iffe r e nce s Be t w e e n I S- I S and OSPF

I S- I S 1 I S- I S is an int egr at ed pr ot ocol t hat suppor t s rout ing of bot h I SO CLNP and I P Packet s. 2 I S- I S encoding requires t ransim ission of I S- I S packet s on t he dat a link. 3

4

5

6

7

OSPF Designed t o rout e only I P packet s.

OSPF packet s are encapsulat ed in I P packet s and, t herefore, are t ransm it t ed over t he net work layer. I S- I S is designed as one of t hr ee OSPF is not a net work layer net work layer prot ocols t hat prot ocol and runs over I P as support s t he I SO connect ionless prot ocol t ype 89. net working environm ent . Recognized at t he dat a link as an I SO Fam ily Prot ocol ( dat a - link t ype FEFE on Et hernet ) , I S- I S has Net work Layer prot ocol I D 0x83 wit hin t he I SO fam ily. I S- I S rout ers advert ise LSPs OSPF uses different LSA t ypes t o cont aining TLVs wit h rout ing carry different kinds of rout ing inform at ion direct ly t o adj acent inform at ion. LSAs are packed in neighbors. updat e packet s for advert ising t o neighbors. I S- I S packet s use TLVs for I n OSPF, only LSA are carrying inform at ion allowing ext ensible. easy ext ensibilit y of all PDU. An I S- I S rout er can skip a TLV All OSPF rout ers in a net work t ype if t he im plem ent at ion does m ust recognize all enabled not suppor t it . ext ensions or LSA opt ions for proper operat ion. Mult iple TLVs can be nest ed in an All OSPF LSAs have t heir own I S- I S Packet wit h a single header header, such as sequence result ing in bandwit h effici ent num ber, age, and I D of rout er t r anspor t . t hat generat ed t he inform at ion. Only t ype 1 and 2 LS allow m ult iple prefixes in each LSA. Because each t ype 3, 4, and 5 LSAs can hold only a single I P pr efix, every dest inat ion out side an area will require it s own LSA and independent header

193

inform at ion. 8 I S- I S support s only broadcast and point -t o- point links for all pract ical purposes and does not support NBMA links, which can be configured as point - t o- point or as broadcast if fully m eshed.

OSPF suppor t s m any link t y pes, such as t he follow ing: Point -t o-point Br oadcast Nonbroadcast m ult iacess Point -t o-m ult ipoint Dem and circuit s

9 A 3- way adj acency form at ion is st andardized for only broadcast links. Effort is under w ay in t he I ETF t o st andardize a 3- way process on point -t o- point links. 10 I nit ial dat abase synchronizat ion occurs aft er adj acencies are form ed. 11 I S- I S rout ers are assocat ed wit h a single area. The whole rout er belongs t o t he area. 12 Area boundaries int ersect links. 13 I S- I S areas are st ubs by default . The recent ly published RFC 2966 st andardizes leaking of int erarea rout es from Level 2 int o Level 1. 14 I S- I S support s only reliable flooding on point -t o- point links. Flooding on broadcast links is not reliable; however, reliabilit y is achieved by periodic synchronizat ion wit h t he help of t he DI S. 15 DI S can be replaced preem pt ively. There is no backup DI S. 16 Part ial rout e calculat ion ( Part ial SPF) is m ore prevalent in an I SI S area because I P prefixes are

OSPF adj acency form at ion involves a m ore elaborat e m ult ist age process.

I nit ial dat abase synchronizat ion precedes adj acency form at ion. OSPF rout ers can be at t ached t o m ult iple areas. I nt erfaces are assigned t o ar eas. Areas int ersect on rout ers. By default , OSPF areas are not st ubs but can be configured as such if necessary. OSPF ensures reliable flooding on all links.

The designat ed rout er ( DR) cannot be preem pt ed. There is a backup DR. Part ial SPF is lim it ed t o int erarea and ext ernal rout es. Any int erarea link flap will result in

194

leaves in t he SPF t ree. I n genera l, t his im plies less load on t he rout e processor on t he average and a plus for large areas. 17 No nat ive support for I P Mult icast rout ing.

full SPF requiring sm aller areas and hierarchical t opologies t o sca le.

MOSPF ext ensions provide support for nat ive I P Mult icast rout ing.

IS-IS Versus OSPF—A Closer Look Table 7 - 2

provides concise point -b y-point highlight s of t he differences bet ween I nt egrat ed I S-I S

and OSPF. The follow ing sect ion discusses in det ail t hese differ ences and t heir r elat ive m er it s bet w een t he t w o prot ocols. Where necessary, achit ect ural det ails are p rovided t o elaborat e t he discussions. The discussions ar e or ganized in t he follow ing t opics:

•

Encapsulat ion

•

Packet Form at s and Encoding I ssues

•

Neighbor Discovery and Adj acency Maint enance

•

Dist r ibut ion of Rout ing I nfor m at ion

•

Rout e Charact erist ics and Met ric I nfor m at ion

•

Robust ness and Reliabilit y I ssues

•

Net work Archit ect ure

•

St abililit y, Convergence, and Scalabilit y

•

Securit y

• •

Operat ions: Maint enance and Troubleshoot ing Conclusions: Which Prot ocol I s Bet t er?

Encapsulation I nt egr at ed I S-I S r uns dir ect ly ov er t he dat a link alongside I P as a net w or k layer ( Layer 3) prot ocol. I SI S packet s are recognized at t he dat a -link lay er as belonging t o t he I SO net w or k layer prot ocol fam ily and on Et hernet by t he prot ocol t ype 0xFEFE. The corresponding prot ocol t y pe for I P is 0x 0800. Even t hough I S-I S is a net w ork layer prot ocol, it is essent ially a rout ing applicat ion and does not provide com plet e dat agram t ransm ission services as in t he case of I P, CLNP, or Novell's I nt ernet Packet Exchange ( I PX) . One benefit of running I S-I S over t he dat a link is t hat it is shielded fr om I P pack et spoofing and sim ilar denial of ser vice ( DoS) at t acks. The dow nside, how ever , is t hat I S-I S cannot be used over ATM virt ual circuit s ( VC) w it h t he t ype of encapsulat ion know n as VC Mult iplexing ( AAL5MUX) . This is because t his m et hod of encapsulat ion suppor t s only one Layer 3 pr ot ocol per VC. For m ost pract ical purposes, how ever, w hen I S-I S is used for I P r out ing, I S-I S packet s m ust be sent over t he sam e ATM VC. This, t her efor e, r est r ict s use of I S-I S for I P r out ing in ATM envir onm ent s t o only alt er nat e ATM encapsulat ion m et hods, such as LLC/ SNAP ( also

195

r efer r ed t o as AAL5SNAP) or AAL5NLPI D encapsulat ion, w her e t he ATM layer can dist inguish bet w een m ult iple Layer 3 pr ot ocols over t he sam e VC. An I ETF dr aft pr oposes a w or kar ound t o t his issue in w hich bot h I S-I S and I P pack et s can be sent ov er an ATM VC w it h AAL5MUX encapsulat ion but t he ATM layer is not r elied on t o dem ult iplex t he I S-I S and I P st r eam s. This w or kar ound suggest s r out er s should r ead int o t he fir st by t e of t he Lay er 3 header t o dist inguish bet w een I P and I SO fam ily pack et s, such as I S-I S, CLNP, and ES-I S pack et s. Anot her issue associat ed w it h t he Lay er 2 encapsulat ion of I S-I S is t hat som e oper at ing sy st em s t hat suppor t I P net w or k ing hav e been im plem ent ed t o different iat e Layer 3 packet s in t he ker nel, r equir ing ar duous ker nel m odificat ions t o suppor t I S-I S for I P r out ing in t hese oper at ing sy st em s. OSPF r uns ov er I P as pr ot ocol num ber 89. TCP and UDP ar e sim ilar ly encapsulat ed in I P, w it h pr ot ocol num ber s 6 and 17, r espect iv ely . Encapsulat ing OSPF in I P m eans OSPF pack et s ar e t ransm it t ed w it h addit ional I P header inform at ion, t hereby increasing packet overhead. This also subj ect s OSPF packet s t o I P packet spoofing and denial of ser vice at t acks. However, because OSPF is encapsulat ed in I P, t her e ar e no issues w it h using it for I P r out ing over ATM VCs w it h AAL5MUX encapsulat ion. Also, if an operat ing syst em already support s I P, no changes ar e necessar y t o suppor t OSPF.

Packets Types and Encoding Issues Table 7 - 3

list s I S-I S packet t ypes and t heir cor r esponding analogies in t he OSPF w or ld. Ther e is

st riking sim ilarit y—ev en each pr ot ocol uses a significant ly differ ent encoding schem es.

Table 7 - 3 . I S- I S a nd OSPF Pa ck e t Type s

I S- I S OSPF Hello packet s Hello packet s Link- St at e pack et s Link- St at e Updat e ( LSPs) packet s

Com m ent s I S-I S car r ies r out ing infor m at ion in TLVs w it hin LSP. OSPF uses LSAs t hat are t ransm it t ed in Lin k-St at e Updat e pack et s. LSAs also hav e header s.

Com plet e Dat abase Sequence Num ber Descript ion packet s packet s Lin k-St at e Request Part ial Sequence packet s Num ber packet s Lin k-St at e Acknow ledgm ent packet s

196

V a r ia b le Le n g t h Fie ld s I S-I S uses var iable lengt h packet s ext ensively t o adver t ise infor m at ion about t he r out ing environm ent . TLVs are used in all I S-I S pack et s m ak ing each of t he I S-I S packet t ypes ext ensible. I S-I S r out er s ar e supposed t o ignor e unsuppor t ed TLVs. LSPs ar e flooded int act w it h unsupport ed TLV inform at ion. This provides flexibilit y for ext ending t he ent ire prot ocol w it h new capabilit ies, such as MPLS Tr affic Engineering, I Pv6. TLVs can be nest ed as sub TLVs, providing even m ore flexibilit y for current and pot ent ial fut ure ext ensions. I S-I S does not r equir e any par t icular alignm ent of pack et fields. OSPF uses fix ed for m at pack et s w it h fields aligned in 32-b it boundaries. This efficient encoding m akes it easier for r out er s t o par se OSPF packet s. The disadvant age t o t his, t hough, is t hat t he packet for m at s ar e not ext ensible. OSPF uses var ious t ypes of link-st at e adv er t isem ent s ( LSAs) for advert ising rout ing infor m at ion. LSAs ar e adv er t ised t o neighbor s in link-st at e updat e packet s. LSAs are how ever ext ensible. OSPF uses opaque LSAs for prot ocol ext ensions. For exam ple, LSA t ypes 9, 10, and 11 ar e used for adver t ising applicat ion-specific inform at ion, such as MPLS Traffic Engineering at t ribut es. Unlike I S-I S, LSA t y pes t hat ar e not r ecognized on r eceipt ar e not flooded t o neighbor s. This m eans t hat all OSPF r out er s m ust r ecognize ext ensions net work-w ide for t hat new capabilit y t o w ork. How ever, I S-I S allow s r out er s t o ignor e unr ecognized TLVs.

M TU M a t ch in g Bot h OSPF and I S-I S require com m unicat ing rout ers t o have m at ching m axim um t ransm ission unit ( MTU) sizes in or der t o for m adj acencies. This is needed so t hat r out er s w ill not adv er t ise pack et s lar ger t han a neighbor can r eceiv e and pr ocess. How ev er , each pr ot ocol uses a different m echanism t o check against MTU m ism at ch. I S-I S pads hellos t o t he MTU size w hile OSPF advert ises t he int erface MTU in dat abase descript ion packet s. Recent enhancem ent s t o t he I S-I S pr ot ocol allow hello -padding t o be disabled t o save link bandwidt h. The rat ional behind t his is t hat m ost m edia have consist ent default MTUs t hat ar e m at ched on all connect ed devices. Anot her r eason is t hat net w or k oper at or s have cont r ol over t he MTU set t ing and can ensur e m at ching configur at ions on all connect ed int er faces dur ing phy sical set up of t he link .

Fr a gm e n t a t ion Because of t he obvious t oll of fr agm ent at ion and r eassem bly on r out er s, bot h I S-I S and OSPF em ploy v ar ious m echanism s t o av oid hop-b y-hop co nvent ional fragm ent at ion and reassem bly of large packet s. The m et hod used by eit her prot ocol involves sending sm all self-cont ained independent LS packet fragm ent s t hat are t ransm it t ed fast er and m ore efficient ly. For exam ple, only a fr agm ent t hat is lost needs t o be r et r ansm it t ed out of t he set r epr esent ing t he original inform at ion. The difference in t he approach t o handling fragm ent at ion bet w een t he t w o prot ocols is t hat an I S-I S r out er fr agm ent s a lar ge LSP t o t he MTU or LSP buffer size at t he sour ce. The m ax im um size of an LSP is 1492 by t es. A set of TLVs ar e appended t o a header t hat has an LSP I D t hat differ s fr om t hat of t he ot her fr agm ent s by t he LSP fr agm ent num ber .

197

Also, all t he LSP fr agm ent s have differ ent sequence num ber s and checksum num ber s t hat m ake t hem independent unit s and ar e flooded independent ly. A list of TLVs ar e pr ovided in Chapter 3 ,

" I nt egrat ed I S-I S Rout ing Pr ot ocol Concept s," ( Table 3 - 1 and Table 3 - 2 ).

Link- State Database,"

Chapt er 5, " The I S- I S

feat ures addit ional recent ly specified TLVs.

I n cont rast , OSPF cont rols fragm ent at ion by using different t ypes of self-cont ained LSAs for adv er t ising differ ent k inds of infor m at ion. Fiv e LSA t y pes ar e defined by t he base OSPF specificat ion, and addit ional specificat ions ( Opaque LSAs, and so on) are specified for ex t ensions ( see Table 7 - 4 ) . This appr oach is equally effect ive, except t hat it has t he pot ent ial of int roducing overhead t hat w ould adversely im pact available net w ork resources, such as bandw idt h and m em or y . Each LSA has it s ow n header cont aining infor m at ion such as sour ce r out er I D, sequence num ber , checksum , and age. I n addit ion, LSA t ypes 3, 4, and 5 hold only a single pr efix per LSA, t he ov er head can be subst ant ial. Ty pe 1, 2 LSAs can hold m ult iple pr efixes per LSA, how ever , because t her e ar e no size lim it s for t hese LSA convent ional hopb y-hop fragm ent at ions, and reassem bly will be used if t hey grow large.

Table 7 - 4

list s current ly

defined OSPF LSA t y pes. The m any differ ent LSAs suppor t ed by OSPF hav e good design pr ot ocol int ent ions, such as lim it ing fragm ent at ion and reducing bandwidt h consum pt ion by providing granular link-st at e inform at ion. This m eans t hat pot ent ial sm all-size pack et s and only t he specific infor m at ion w ould be advert ised in response t o any event . How ever, t his undoubt edly int roduces com plex it y int o t he m anagem ent of link-st at e inform at ion. On t he cont rary, I S-I S LSPs ar e larger and few er in a net w ork of com parable size. This im plies less com plexit y in m anaging t he I S-I S LS dat abase; how ever , a lot of r edundant infor m at ion is r et r ansm it t ed w it h a r egener at ed LSP in r esponse t o net w or k event s w ast ing bandw idt h.

Table 7 - 4 . OSPF LSA Type s

Type Nam e 1 Rout er

2

Net work

3

I P Net work Sum m ary

4

AS Border Rout er ( ASBR) Sum m ary

D e scr ipt ion Originat ed by a rout er t o describe it s set of act ive int erfaces and neighbors. I t list s t he I P prefixes associat ed wit h each of t he at t ached links and t he st at e and cost associat ed wit h each neighbor. Generat ed by t he Designat ed Rout er on a broadcast link and list s all at t ached rout ers. I t also describes t he link t ype, broadcast , NBMA, and so on. Generat ed by t he area border rout ers ( ABRs) in hierachical t opologies. Used for report ing int erarea rout es wit hin t he sam e AS. Generat ed by t he ABR t o provide inform at ion about known ASBRs, which im port ext ernal rout es int o t he AS. 198

5

AS Ext ernal

6

Group Mem bership NSSA

7

8

Ext ernalat t ribut es 9- 11 Opaque

Generat ed by ASBRs t o describe known dest inat ions out side of t he AS. Support s m ult icast ext ensions t o OSPF ( MOSPF) . Not support ed in Cisco I OS Soft ware. Used t o i nj ect ext ernal rout es from a st ub area int o t he OSPF dom ain. Generat ed by t he Not So- St ubby Area ( NSSA) ASBR. Convert ed int o t ype 5 LSAs by t he ABR when export ing t o t he rest of t he OSPF dom ain. Proposed for int eract ion wit h BGP. Used for ext ended capabilit ies such as MPLS Traffic Engineering.

Neighbor Discovery and Adjacency Maintenance Neighbor discovery and adj acency m aint enance are perform ed by m eans of periodic t r ansm ission and r ecept ion of hellos in bot h I S-I S and OSPF. I n bot h cases, hello packet s also ser v e as v ehicles for det ect ing and negot iat ing com m on and ex t ended capabilit ies. Because I S-I S runs over t he dat a link, I S-I S hellos ar e adver t ised t o Layer 2 br oadcast addresses ( allL1I Ss and allL2I Ss) . On m ult ipoint links such as Et hernet , t he corresponding br oadcast addr esses ar e 0180.C200.0014 and 0180.C200.0015. Because of t heir encapsulat ion in I P packet s, OSPF hellos are advert ised t o Layer 3 m ult icast addresses AllSPFRout ers ( 224.0.0.5) and AllDRout ers ( 224.0.0.6) . Table 7 - 5 ,

shows t he default values of corresponding hello -relat ed t im ers in I S-I S and OSPF. An

int erest ing difference bet w een I S-I S and OSPF regarding hello -r elat ed t im er s is t hat I S-I S does not require t he hello int erval and holdt im e t o m at ch bet w een adj acent neighbors. Rat her, each hello packet cont ains a hold -t im e value t hat is used t o reset t he hold t im er at t he receiver. I n cont rast , OSPF requires all hello -relat ed t im er values ( Hello int erval, Dead t im er) t o m at ch on all r out er s on t he sam e subnet . The dow nside of t his r equir em ent for OSPF is t hat m odifying t he hello t im ers is int rusive, w hereas in I S-I S t his is not . The follow ing subsect ions highlight significant differences in adj acency form at ion processes bet w een t he t w o pr ot ocols.

Table 7 - 5 . D e fa ult Va lue s of H e llo- Re la t e d Tim e r s

Ty pe of I nt erfa ce Point - to- point

I S- I S

OSPF

Hello – 10s Hello – 10s

Com m ent s Wait t im er specifies how long t o wait if DR fails before st art ing DR elect ion

Holdt im e –

199

30s

Dead –

pr ocess.

40s Wait – 40s Hello – 10s Hello – 10s

Broadcast

Holdt im e – 30s

Dead – 40s Wait – 40s

NBMA

N/ A

Hello – 30s Dead – 120s Wait – 120s

Lin k Ty pe s I S-I S and OSPF suppor t m ult iacess br oadcast m edia, such as Et her net or sim ilar m edia, in t he sam e w ay . The sam e goes for point -to-point links. OSPF addit ionally support s nonbroadcast m ult iaccess ( NBMA) m edia, such as ATM and Fram e Relay. OSPF can also m odel NBMA m edia as point -t o-m ult ipoint .

Table 7 - 6

show s a com par ison of t he link t y pes suppor t ed by t he t w o

prot ocols. I S-I S does not pr ov ide dir ect suppor t for NBMA m edia. When used in I S-I S net works, NBMA m edia m ust b e configured as Broadcast m edia if all nodes are fully m eshed. Alt er nat ively, t he individual PVCs can be configur ed as point -t o-point links. I f t he NBMA cloud is highly m eshed, I S-I S m eshed gr oups can be used in conj unct ion w it h point -t o-point configurat io n t o cont r ol ex cessiv e flooding.

Table 7 - 6 . I S- I S a nd OSPF N e t w or k Link Type s

I S- I S OSPF Broadcast Broadcast N/ A nonbroadcast m ult iaccess

Point - to-

Com m ent s NBMA links can be configured as broadcast m edia, or pvcs can be configured as point - t o- point links in I S- I S environm ent s.

Point - to- point

200

point N/ A N/ A

Point - tom ult ipoint Dem and Circuit s

For m in g Ad j a ce n cie s The essence of for m ing adj acencies w it h r egar ds t o link-st at e pr ot ocols is t o build a st at eful relat ionship t hat is leve raged by ot her prot ocol m echanism s t o ensure consist ency of relevant link-st at e inform at ion bet w een com m unicat ing neighbor rout ers. The process of exchanging link-st at e infor m at ion is also k now n as dat abase synchronizat ion. Ther e ar e significant differences bet ween I S-I S and OSPF in how rout ers form adj acencies. I S-I S adj acencies ar e for m ed aft er 2 -w ay ( point -t o-point links) or 3 -w ay ( br oadcast link s) com m unicat ion has been est ablished t hrough t he exchange of hellos. A recent ly published I ETF draft proposes a m echanism for 3 -w ay handshake over point -to-point links. A 3 -w ay adj acency handshake is available in Cisco I OS 12.0 S and ot her releases. I S-I S r out er s pr oceed t o sy nchr onize t heir LS dat abases aft er t hey hav e becom e adj acent . The pot ent ial for t r ansient r out ing pr oblem s w hen adj acency form at ion precedes dat abase synchronizat ion can be resolved t hrough t he use of t he I S-I S ov er load bit . OSPF follow s a com plex m ult ist age progressive process t hat requires rout ers t o synchronize t heir dat abases befor e est ablishing adj acencies. This is int ended t o prevent t ransient rout ing problem s t hat occur w hen adj acent rout ers not having com plet e forw arding int elligence at t ract t r ansit t r affic. One of t he ear ly st ages in t he OSPF adj acency pr ocess involves est ablishing 2 w ay com m unicat ion bet w een neighbor s.

D e sign a t e d Rou t e r s The designat ed r out er concept is used by bot h I S-I S and I S-I S on br oadcast m edia t o lim it t he m agnit ude of LS st at e infor m at ion exchanged bet w een r out er s on such m edia. The DR concept helps r educes t he num ber of adj acencies for m ed on br oadcast m edia t o or der N inst ead of order NxN, w here N is t he num ber of nodes. Each prot ocol uses different m echanism s t o r ealize t his concept . For exam ple, I S-I S elect s only one designat ed rout er ( Designat ed I S) w it hout a back up. The I S-I S DI S can be pr eem pt ed at any t im e by a r out er w it h a higher pr ior it y . A new DI S m ust be elect ed w hen t he current DI S is lost . Because t he DI S advert ises hellos fast er ( t hree t im es fast er by default ) t han ot her nodes on t he LAN, DI S failur e det ect ion is fast , so t he pot ent ial for disrupt ion is m inim ized. I n t he DI S elect ion process, I S-I S uses t he highest dat a -link addr ess ( MAC) as t ie br eak er w hen int er face pr ior it ies ar e t he sam e. The pr ior it y field available in LAN hello packet s is 6 b it s, so t he r ange of int er face pr ior it y for I S-I S rout ers is 0 – 127 w it h 64 as default on Cisco r out er s. Also on LANs, all I S-I S nodes becom e adj acent t o each ot her by broadcast ing hellos and going t hrough t he 3 -w ay handshak e. The m any-t om any adj acencies thr ough hello br oadcast ar e st r aight for w ar d because r eliable dat abase

201

synchr onizat ion is not r equir ed t o com plet e adj acency est ablishm ent . LSPs ar e also br oadcast t o everyone, and t he DI S assist s w it h dat abase synchronizat ion by periodically broadcast ing CSNPs t hat cont ain sum m ar ies off all know n LSPs. I n cont r ast , OSPF elect s DR and a backup DR ( BDR) t o conduct flooding on a LAN. The DR cannot be pr eem pt ed and t he BDR t ak es ov er t he DR; t he fir st act iv e r out er on t he LAN segm ent usually assum es t he DR r ole. The availabilit y of a BDR m akes r eplacem ent of t he DR t ransparent in case of a failure. All ot her nodes on t he LAN can be adj acent t o only t he DR and BDR. This is necessary because OSPF requires dat abases t o be reliably synchronized before adj acencies ar e est ablished. For m ing adj acencies w it h only t he DR and BDR is designed t o r educe com plex it y of dat a ex change and m ininize flooding. I n sum m ary, I S-I S solves t he NxN adj acency pr oblem by choosing a sim ple pr ocess t hat uses per iodic sy chr onizat ion t o achiev e reliabilit y and a det erm inist ic DI S elect ion process in w hich t he DI S is pr eem pt ible. OSPF solv es t he sam e pr oblem but uses a slight ly m or e com plex process t hat m akes DR elect ion nondet erm inist ic but guarant ees reliable flooding on broadcast m edia.

Distribution of Routing Information I S-I S and OSPF ar e link-st at e r out ing pr ot ocols and, t her efor e, r equir e r out er s t o obt ain accurat e inform at ion about t he net w ork t opology t hat is subsequent ly used t o calculat e t he best pat hs t o all know n dest inat ions in t he net w or k at each r out er . The t opology infor m at ion is also r efer r ed t o as link-st at e inform at ion, and it is spread from rout er t o rout er by a m echanism know n as flooding. I S-I S r out er s use link-st at e pack et s t o or ganize a v ar iet y of link-st at e infor m at ion. LSPs const it ut e t he unit s of inform at ion st ored in I S-I S LS dat abase. An LSP is flooded fr om one node t o t he next int act . The m axim um size of an LSP ( LSP Maxim um Tr ansm ission Unit ) is specified as 1492 by t es and should be suppor t ed by all link s in t he I S-I S net w or k . When t her e is any t opology change, a r out er floods a new copy of it s ent ir e LSP w it h t he updat ed infor m at ion. OSPF uses link-st at e advert isem ent s ( LSAs) for dist ribut ing rout ing inform at ion. LSAs are t he sm allest unit s of infor m at ion st or ed in t he OSPF LS dat abase. LSAs ar e gener ally sm all fix edsize pack et s. Ty pe 1 and Ty pe 2 LSAs can hav e m any pr efix es per LSA. Ot her LSAs do not . LSAs ar e gr ouped and adver t ised in LS Updat e packet s. Because LS updat es ar e gener at ed locally at any r out er , t hey do not carry a consist ent set of LSAs. I n cont rast , I S-I S link-st at e pack et s ar e alw ay s flooded int act as or iginat ed at t he sour ce.

Floodin g Flooding is t he m et hod used by link-st at e pr ot ocols t o dist r ibut e link-st at e infor m at ion in a net w or k . Shar ing link-stat e inform at ion in t his m anner allow s rout ers t o have consist ent view s of t he net w or k's t opology and, t her efor e, calculat e loop fr ee opt im al pat hs t o dest inat ions in t he net w or k . Link-st at e prot ocols use various m echanism s t o com pare t heir dat abases t o

202

ens ur e consist ency. The pr ocess of exchanging link-st at e infor m at ion t o ensur e consist ent v iew s of t he net w or k acr oss r out er s is k now n as dat abase synchronizat ion. To suppor t synchr onizat ion, r out er s com par e t heir dat abases by exchanging sum m ar y header s of all k now n LSPs or LSAs. I S-I S per for m s r eliable flooding on only point -t o-point links w here explicit acknow ledgm ent of received LSPs is required. On LANs, I S-I S nodes br oadcast t heir LSPs t o all at t ached devices. The DI S t hen per iodically m ult icast s a CSNP that cont ains a sum m ar y of ever y know n LSP in t he LS dat abase t o help synchr onize dat abases bet w een r out er s connect ed t o t he LAN. OSPF per for m s r eliable flooding on bot h point -to-point link s and LANs and, t her efor e, r equir es ack now ledgm ent of all LSAs flooded out . On LANs, or dinar y r out er s pass on t heir LSAs t o t he DR and BDR. The DR t hen r efloods t he LSAs t o all ot her nodes on t he LAN and r eceiv es acknowledgm ent from t hem . Because in OSPF ev er y dest inat ion out side an ar ea ( int er ar ea and ex t er nal) is st or ed in individual LSAs ( Type 3 and Type 5) , sum m ar izing t he LS dat abase m ight r equir e a packet s larger t han t he MTU of t he out going int erface. I n such cases, OSPF uses I P fragm ent at ion and r eassem bly . Each of t he r esult ing fr agm ent s is assigned a sequence num b er and adv er t ised sequent ially aft er each fr agm ent is ack now leged by t he r eceiv ing end. One adv ant age of I S-I S t hat has alr eady been m ent ioned is t hat individual int er ar ea and ex t er nal r out es do not need t heir ow n LSP header s, and m ult iple pr efix es ar e packed int o TLVs ( t ypes 128, 130, and 135) , w hich shar e t he sam e LSP header . I n gener al, t her e ar e few er LSPs in an I S-I S environm ent t han t here are in a com parable OSPF net w ork. Therefore, a change in t opology m ight t r igger an updat e of m any differ ent OSPF LSAs, whereas a sim ilar ev ent in I S-I S m ight t r igger few er LSPs t o be flooded.

I S- I S LSP a n d OSPF LSA Agin g Lin k-st at e r out ing pr ot ocols pr ovide m echanism s t o r em ove st ale infor m at ion fr om t he LinkSt at e dat abase. Bot h I S-I S and OSPF provide aging t im ers in link-st at e pack et s for t his purpose. The Rem aining Lifet im e field ( LSP Holdt im e on Cisco rout ers) in I S-I S is a dow ncount ing t im er t hat st ar t s fr om 1200 seconds ( default ) and indicat es how m any m or e seconds befor e t he LSP w ill expir e. OSPF uses an up -count ing count er t hat indicat es t he num ber of seconds since t he LSA w as or iginat ed. The m ax im um t im e an LSP/ LSA can ex ist befor e it expir es is know n as m axage. For I S-I S, t he default is 1200 seconds ( 20 m inut es) . For OSPF, t he default is 60 m inut es. I S-I S allow s Maxage t o be configur able up t o a m axim um of 18.7 hour s. The OSPF Max age is fix ed at 1 hour . To pur ge an LSP fr om t he net w or k befor e it expir es, an I S-I S r out er set s t he r em aining lifet im e field t o 0 and t hen floods it . I S-I S allow s any r out er t o pur ge cor r upt ed LSPs fr om t he net w or k. This could lead t o LSP cor r upt ion st or m s, w her e one r out er pur ges an LSP and t he or iginat or r eissues t he LSP, and it is again cor r upt ed by som e int er vening device. The r out er level com m and ignore- lsp- e r r or s pr ev ent s a r out er fr om pur ging a cor r upt ed LSP. OSPF

203

allow s rout ers t o prem at urely purge only unexpired LSAs t hat t hey originat ed. This prevent s sit uat ions sim ilar t o LSP corrupt ion st orm s t hat can occur in I S-I S env ir onm ent s. To ensure cont inuit y of operat ion, I S-I S an d OSPF rout ers regenerat e new copies of t heir LSPs t o r efr esh exist ing copies per iodically even befor e t hey expir e. For I S-I S, t his occur s ev er y 15 m inut es. OSPF r out er s r efr esh t heir LSAs ever y 30 m inut es. OSPF LSAs w it h t he DoNot Age bit set ar e not aged w hile st or ed in a r out er 's Link-St at e dat abase. Ther efor e, t hey do not need t o be r efr eshed ev er y 30 m inut es. How ev er , such LSAs w ill be ev ent ually pur ged fr om t he LS dat abase if t hey becom e st ale aft er being held for at least 60 m inut es and t he or iginat or not r eachable for t he sam e per iod. The per iodic int er val at w hich LSPs/ LSAs ar e r egener at ed is know n as t he Refr esh I nt er val. Table 7 - 6

list s relat ed t im ers for I S-I S and OSPF and t heir default v alues.

Table 7 - 7 . I S- I S a n d OSPF M a x a ge a n d Re fr e sh Tim e r s

Tim er Maxage

I S- I S 20 m inut es ( default )

OSPF 60 m inut es

Com m ent s Configur able 16-bit field in I S-I S allow s up t o 18. 7 hour s. The OSPF v alue is fix ed.

Refr esh I nt er val

15 m inut es ( default )

30 m inut es

Configurable up t o 18.7 hours for I S- I S.

Route Characteristics and Metric Information Various t ypes of r out es ar e r ecognized by bot h I S-I S and OSPF. I n I S-I S, t her e ar e I nt er nal r out es ( TLV t y pe 128 and 135) and Ex t er nal r out es ( TLV t y pe 130) . I nt er nal r out es ar e fur t her cat egorized int o int ra -ar ea ( Level 1) and int er ar ea ( Level 2) . By specificat ion, ext er nal r out es can be int roduced int o t he I S-I S dom ain only t hrough Level 1 -2 rout ers by redist ribut ing from an ex t er nal r out ing sour ce. Cisco I OS Soft w ar e, how ev er , pr ov ides a soft w ar e k nob t hat allow s redist ribut ion of ext ernal rout es by Level 1 -o n ly r out er s. This is allow ed for oper at ion conv enience. Sim ilarly, OSPF support s int ra -ar ea r out es ( Ty pe 1 and Ty pe 2 LSAs) and int er ar ea r out es ( Ty pe 3 LSAs and ex t er nal r out es ( Ty pe 5 LSAs) . Ex t er nal r out es ar e not adv er t ised int o OSPF st ub ar eas. Not -So -St ubby Areas ( NSSA) allow lim it ed int roduct ion of ext ernal rout es int o t he r est of t he OSPF dom ain by m eans of Ty pe 7 LSAs, w hich ar e conv er t ed t o Ty pe 5 by t he NSSA. I S-I S rout es carry m et ric inform at ion. Out of t he four t ypes of m et rics specified, only t he default t ype is suppor t ed in Cisco I OS Soft w ar e. I S-I S m et r ics hav e an inv er se bandw idt h int epr et at ion, w it h sm aller values associat ed w it h bigger bandw idt h. The 7 bit s used for nar r ow m et r ics allow only v alues bet w een 0 and 63 per int er face and up t o 1023 per pat h. Wide m et r ics allow lar ger and flexible m et r ic values, 32 bit s in TLV t ype 135 for ext ended I P reachabilit y inform at ion and 24 bit s in TLV t ype 22 for ext ended I S reachabilit y inform at ion. Cisco I OS Soft w are does not aut om at ically assign m et rics on int er faces based on t he

204

bandw idt h. A default v alue of 10 is assigned on all int er faces, ev en t hough differ ent v alues can be m anually assigned. I S-I S m et r ics can be t agged as I nt er nal or Ext er nal based on t he set t ing of t he I / E bit . When t he I / E bit is set ( Ex t er nal) , 64 is added t o t he adv er t ised v alue of t he m et ric. ( Som e Cisco I OS releases add 128 inst ead.) OSPF also uses a m et r ic ( cost ) t hat is inv er sely pr opor t ional t o bandw idt h. The cost on an int er face is aut om at ically assigned based on a default reference bandw idt h of 100Mb/ s. The cost is calcuat ed as ( Reference Bandw idt h) / ( I nt erface Bandw idt h) . A cost of 1 is assigned if t he calculat ed value is m ore t han 1. The reference bandw idt h is configurable. Also, int erface cost can be m anually assigned. OSPF allow s assignm ent of lar ge cost s because of t he w ide m et r ic fields in LSAs. The m et r ic field is 16 bit s in Type 1 LSAs and 24 bit s in Types 3, 4, 5, and 7 LSAs. OSPF also r ecognizes t w o t ypes of m et r ics for ext er nal r out es: Type 1 ( E1) and Type 2 ( E2) . Type 1 consider s t he cost t o t he ASBR in addit ion t o t he adver t ised cost of t he r out e. Ty pe 2 uses only t he adv er t ised cost .

Robustness and Reliability Issues Robust ness and reliabilit y are int roduced in I S-I S and OSPF in var ious for m s. For exam ple, eit he r pr ot ocol uses age t im er s in LSPs/ LSAs so t hat t hey can be per iodically r efr eshed t o ensur e t heir int egr it y . The age t im er s also allow st ale link-st at e infor m at ion t o event ually expir e so t hat t hey can be pur ged fr om t he net w or k. Flooding loops ar e pr event ed by decrem ent ing t he Rem aining Lifet im e in I S-I S LSP at each flooding hop. OSPF also enfor ces sim ilar r obust ness by incr easing t he LS age field. The use of checksum s also helps ensur e t he ent egr it y of LSPs and LSAs. I S-I S enfor ces r eliable flooding on p oint -t o-point link s r equir ing ev er y LSP flooded t o be acknow ledged. LSPs flooded on br oadcast m edia ar e not acknow ledged, but t he DI S, w hich sim plifies flooding on an I S-I S LAN, periodically broadcast s CSNPs w it h sum m aries of know n LSPs t o ensure consist en cy of link-st at e infor m at ion acr oss r out er s. Reliable flooding is achiev ed t hr ough sim ple per iodic updat es. Rout er s t hat ar e m issing LSPs or hav e st ale inform at ion aft er com paring t heir dat abases w it h cont ent s of t he CNSPs can request com plet e copies w it h PSNPs. OSPF r equir es flooded LSP t o be ack now ledged on all link s. Also, OSPF has a DR and a BDR t o ensur e t he undisr upt iv e oper at ion of t he LAN in case t he DR fails.

Network Architecture This sect ion discusses cont raint s im posed by I S-I S and OSPF on net w ork t opologies and ex plains any differ ences bet w een t he t w o pr ot ocols in t his r egar d.

H ie r a r ch y Hier ar chy is r equir ed pr im ar ily for t he net w or k t o cont ain t he per ils of gr ow t h and expansion w hile scaling t o lar ger num ber of nodes. Hier ar chy allow s t he net w ork t o be divided int o sm aller sect ions. Each sect ion can t hen oper at e independent ly at one lev el and y et be link ed

205

t oget her at a higher level. This t ype of organizat ion of t he net w ork allow s rout ing inform at ion t o be m anageable at t he low er level. I t also helps by const raining regional problem s, t hereby hiding inst abilit ies from t he rest of t he net w ork. Bot h I S-I S and OSPF suppor t t w o lev els of hierarchy. I S-I S uses a logical hier ar chy based on r out ing lev els, r efer r ed t o as Lev el 1 and Lev el 2. Lev el 1 r ou t ing occur s w it hin a phy sical ar ea. Lev el 2 r out ing occur s bet w een t he bor der r out er s fr om t he r espect iv e ar eas in t he I S-I S dom ain. All I S-I S r out er s m ust belong t o a single physical area as defined by t he area I D in t he NSAP address. The border rout ers, w hich ar e also k now n as Lev el 1 -2 rout ers, glue t he areas t oget her by exhanging rout ing inform at ion from t heir respect ive areas. The collect ion of Level 1 -2 r out er s is also know n as t he I S-I S backbone. The I S-I S backbone consist s of int erconnect ed Level 2 capable r out er s, som e of w hich m ay be Level 1 -2 rout ers. The I S-I S backbone m ust be cont iguous. For I S-I S, t his also m eans t hat t he Level 2 r out er s m ust be int er connect ed t hr ough ot her Level 2 r out er s. Because I S-I S is designed ar ound a node-based addr essing schem e and each r out er m ust belong t o a single ar ea ev en t hough it m ay be a Lev el 1 -2 rout er, I S-I S ar eas, t her efor e, for m boundar ies on link s as show n in Figure 7 - 15 . Figur e 7 - 1 5 . Ar e a t opology in I n t e gr a t e d I S- I S.

OSPF also suppor t s a t w o -lev el hier ar chy—r egular ar eas and a back bone ar ea t hat is designat ed as ar ea 0 in t he Cisco im plem ent at ion. Because OSPF is designed ar ound link s and t he link-based I P addressing schem e, area assignm ent is by links and, t herefore, rout er int er faces. This m eans t hat OSPF ar eas for m boundar ies on t he r out er s t hem selv es and not t he link s as in I S-I S.

Figure 7 - 16

show s how OSPF ar eas ar e car v ed out . The back bone glues

ordinary areas t oget her. OSPF rout ers t hat int erconnect m ore t han one area are referred t o as ar ea bor der r out er s ( ABRs) . I n t he Cisco im plem ent at ion, one of t hese ar eas m ust be ar ea 0 for exchange of int er ar ea infor m at ion. OSPF also r equir es t he backbone t o be cont iguous and t hat all ar eas connect t o t he backbone t hr ough an ABR. OSPF allow s use of vir t ual link s t o connect r em ot e ar eas t o t he backbone t hr ough ot her ar eas if dir ect physical connect ivit y is not possible. OSPF also allow s a vir t ual link t o connect physically separ at e ar ea 0s t o m aint ain cont iguit y of t he backbone. I n cont rast , I S-I S virt ual links ar e specified for connect ing

206

par t it ions of a Level 1 ar ea over t he Level 2 backbone. Cisco im plem ent at ion of I S-I S does not suppor t vir t ual links. Figur e 7 - 1 6 . Ar e a t opology in OSPF.

I S- I S a n d OSPF Ar e a s OSPF ar eas can be one of sev er al t y pes, such as or dinar y , st ub, t ot ally st ubby , not -so -st ubby, and t ot ally-n ot -so -st ubby. However, I S-I S ar eas w er e or iginally designed t o be st ubs w it h t he Lev el 1 areas r ely ing on a default t o for w ar d t r affic out of t he ar ea. Accor ding t o t he or iginal specificat ion, I SO 10589, I S-I S ar eas ar e sim ilar t o OSPF t ot ally st ubby ar eas ( no int er ar ea rout es, no ext ernals) . How ever, Cisco I OS Soft w are allow s redist ribut ion of ex t er nal r out es int o Level 1, m aking I S-I S ar eas behav e lik e OSPF t ot ally -n ot -so -st ubby ar eas ( ex t er nals allow ed, no int er ar ea r out es) . Recent enhancem ent s published in RFC 2966 and suppor t ed in Cisco I OS addit ionally allow int erarea rout es t o be advert ise d int o I S-I S Level 1, m aking I S-I S ar eas look m or e like or dinar y OSPF ar eas, w her eby bot h ext er nals and int er ar ea r out es ar e br oadly allow ed. An int erest ing difference bet w een I S-I S and OSPF is t hat I S-I S r equir es r out er s on t he sam e segm ent w it h m ism at ched ar ea I Ds t o for m only Level 2 adj acencies, m aking t hem Level 1 -2 r out er s connect ed t o t he backbone w hile st ill ident ified w it h t heir r espect ive ar eas. Tw o I S-I S r out er s in t he sam e ar ea can also for m bot h Lev el 2 adj acencies, ev en t hough t hey ar e not r equir ed t o as in t he pr evious case. I f such r out er s ar e dir ect ly connect ed, t he int er connect ing link w ill be in bot h t he Lev el 1 ar ea as w ell as t he Lev el 2 back bone. I n cont r ast , an OSPF link can be associat ed w it h only one ar ea, and r out er s on t he sam e lin k segm ent m ust agr ee on a com m on ar ea I D t o be adj acent . This sect ion discussed basic I S-I S funct ionalit y and did not consider t he I S-I S m ult iar ea feat ure support ed in I OS. I S-I S m ult iarea funct ionalit y enables I S-I S r out er s t o assign int erfaces t o m ut iple Level 1 ar eas and t he backbone, m aking t hem behave in t he sam e w ay

207

as OSPF rout ers. I S-I S m ult i-ar ea suppor t is cur r ent ly not st andar dized and w as designed for I SO CLNS environm ent s t o opt im ize rout ers usage in such environm ent s. This feat ure requires r unning m ult iple I S-I S pr ocesses on t he Cisco r out er s and defining a unique ar ea I D for each process. One of t he processes m ust be Level 1 -2 t o int er connect t he Lev el 1 ar eas. The pr ocesses can t hen be applied t o int er faces as necessar y .

Ar e a I D a n d Rou t e r I D I S-I S defines t he ar ea I D as par t of a r out er 's NSAP, w hich is also k now n as t he Net w or k Ent it y Tit le ( NET) . I nt egrat ed I S-I S dist inguishes t hree com ponent s in an NSAP: area I D, syst em I D, and N-Select or ( see Chapter 4 , for furt her det ails) . The syst em I D com ponent plays t he r ole of a unique r out er I D. LSPs ar e also differ ent iat ed by t he syst em I D com ponent in t he LSPI D. This is t r ue for bot h I P and I SO r out ing. RFC 1195 defines TLV Type 132 for specifying an associat ed I P int er face addr ess w hen I S-I S is used for I P r out ing, but t his is only for infor m at ional pur poses and has only oper at ional significance in m aint enance and t roubleshoot ing sit uat ions. I f available, t he highest loopback addr ess is ent er ed int o t he I P I nt er face Addr ess TLV. An I P Rout er I D TLV ( Type 134) has been specified for MPLS TE applicat ions of I S-I S. Only t he ar ea I D and t he sy st em I D ar e r elev ant for basic r out ing funct ionalit y and bot h ar e defined in t he NSAP. OSPF v er sion 2 for I Pv 4 r out ing ex plicit ly defines t w o separ at e 32-bit num ber s for ar ea I D and r out er I D. I n Cisco I OS Soft w are, t he area I D is configured as part of net w or k st at em ent s. The r out er I D is usually t he highest loopback addr ess or t he highe st I P addr ess on any int er face on t he r out er .

Stability, Convergence, and Scalability I n general, I S-I S and OSPF have com parable st abilit y and convergence charact erist ics. Apart from t he archit ect ural differences discussed in t he preceding sect ions, t he t w o pr ot ocols ar e funct ionally t he sam e and hav e few adv ant ages ov er each ot her w hen configur ed and used pr oper ly. Oft en, st abilit y and fast conver gence ar e opposing vir t ues. Hello packet s ar e used t o det ect adj acency failures in sit uat ions w here t he failure is not det ect ed at t he low er lay er s. Because t he act ual t im e r equir ed for pr ot ocol m echanism s t o select an alt er nat e pat h and rout e -around failures is generally sm all, t he t im e t aken t o det ect failures becom es crit ical for fast m ight result in net work ins t abilit ies, im pact ing net w ork resources, such as bandw it h, processing capacit y, and m em ory. Adj ust ible t im ers, such as t he hello -int erval, I S-I S holdt im e, and OSPF Dead int erval, provides t rade -offs bet w een st abilit y, fast conver gence, and conser vat ion of net w ork resources. I n sum m ary, im port ant fact ors t hat affect net w ork st abilit y and conv er gence ar e t he speed at w hich failur es ar e det ect ed and pr opagat ed t hr oughout t he net w or k, t he size of t he net w or k, and t he pr ocessing capabilit ies of t he r out er s.

208

Ro u t e Ca lcu la t ion Bot h I S-I S and OSPF use t he sam e SPF algor it hm for r out e com put at ion, so t hey should hav e com parable convergence t im es, everyt hing being equal. How ever, because I S-I S pr opagat es I P r out es w it hin an ar chit ect ur al fr am ew or k designed for t he I SO node -based addr essing schem e, I P pr efix es end up as leaf nodes in t he SPF t r ee. This pr ov ides gr eat er oppor t unit ies for I S-I S t o per for m only t he less CPU-int ensive par t ial r out e calculat ion w hen net w or k event s do not affect t he basic t opology but only I P pr efix es. OSPF is built ar ound link s, and any I P pr efix change in an ar ea w ill t r igger a full SPF. Wit h OSPF, only changes in int er ar ea and ext ernal rout es result in part ial SPF calculat ions. Consequent ly, I S-I S PRC is m or e per v asiv e t han OSPFs par t ial SPF runs. This difference allows I S-I S t o be m or e t oler ant of lar ger single area dom ains w hereas OSPF forces hierarchical designs for relat ively sm aller net w orks. This seem ing advant age allow ed I SP net w or k oper at or s t o deploy lar ge single I S-I S dom ains t o over com e pr oblem s w it h subopt im al r out ing w it h hier ar chical designs. Of cour se, use of ar eas and hierarchy in net w orks is good design pract ice t hat prepares t he net w ork for fut ure grow t h and helps pr ev ent pr oblem s associat ed w it h lar ge flat t opologies. While ar eas and hier ar chy ar e good for scalabilt y, on t he dow nside, t hey also add com plexit y.

M a n a gin g St a bilit y a n d Con ve r ge n ce Even t hough not w idely deployed, Cisco offer s I S-I S ex ponent ial back -off m echanism s in recent I OS releases; see t he sect ion on " I m proving Convergence" ear lier in t his chapt er . These m echanism s allow aggressive t im er values t o be configured for LSP generat ion; t he SPF and PRC pr ocesses in order t o achieve responsive react ion t o net w ork changes but backs off t o less aggr essive par am et er s w hen t he chur n per sist s. Cur r ent ly, OSPF allow s only pacing of flooding and SPF calculat ions t o m aint ain st abilit y of t he net w or k. I n t he fut ur e, I OS w ill suppor t exponent ial back-off algor it hm s for OSPF, as w ell as ot her int elligent ev ent dam pening capabilit ies for link flaps and LSA gener at ion. Cisco's im plem ent at ions of I S-I S and OSPF ar e bot h sensit iv e t o bandw idt h consum pt ion and use pacing m echanism s t o e nforce t his bandwidt h conservat ion. For exam ple, I S-I S t hr ot t les updat es on int er faces w it h low bandw idt hs in t he T1 r ange t o only a m ax im un of 50 per cent of t he bandw idt h, and OSPF uses t he LSA group pacing feat ure t o ensure t hat rout ers do not per iodically r efr esh t heir LSAs at t he sam e t im e. A current I OS im plem ent at ion advant age of I S-I S ov er OSPF is t he use of t he ov er load bit t o pr event undue loss of t r affic dur ing BGP conver gence. OSPF doesn't suppor t t he concept of ov er load bit t hat enables a r out er t o signal m em ory overload, real or fict it iously, in order t o deflect pot ent ial t ransit packet s before t he rout er is ready t o forw ard t hem . How ever, a feat ur e t hat allow s OSPF link-cost m anipulat ion during BGP convergence should provide sim lilar funct ionalit y, prevent ing unnecessary blackholing of t raffic in cert ain t ransient sit uat ions. I n t his applicat ion, a r out er adv er t ises Rout er LSAs w it h lar ge cost v alues so t hat it is not preferred for t ransit t raffic unt il it is ready.

209

Sca lin g in N BM A En v ir on m e n t s I S-I S can use m esh gr oups ( RFC 2973) t o cont r ol r edundant LSP flooding in highly m eshed NBMA env ir onm ent s w hen PVCs ar e configur ed as point -to-point links. OSPF doesn't have an exact ly com parable feat ure but can use per int erface LSA blocking t o prevent LSA t r ansm ission over a link.

Siz e Lim it a t ion s of I S- I S LSPs a n d OSPF LSAs I n I S-I S, an LSP I D cont ains an 8 -bit fragm ent num ber field. Therefore, an I S-I S rout er can allow up t o 256 fragm ent s of it s LSP. The m axim um size of an LSP is 1492 byt es. Taking out header byt es of 27 byt es leaves 1465 byt es for TLVs. This m eans t hat an I S-I S r out er has t heor et ically up t o 256* 1465 of space t o pack I P r eachabilit y TLVs. A couple of ot her TLVs w ill be st or ed in t he fir st fr agm ent . I n Chapt er 5 , a t heoret ical est im at e indicat ed t hat t he m axim um num ber of I P r out es I S-I S can suppor t is appr oxim at ely 31,000 pr efixes. Anot her issue is t hat I S-I S uses an 8 -bit field for point -t o-point circuit I Ds lim it ing t he num ber of point -t o-point adj acencies t o 256 for each r out er . Also, 8 bit s ar e used for defining a pseudonode num ber in t he LSPI D, w hich m eans a r out er can be DI S for only 256 LANs. Ther e is also a lim it t o t he num ber of r out er s t hat can be ad ver t ised in pseudonode LSP by t he DI S. Most of t hese lim it at ions are being addressed by various I ETF draft proposals. For exam ple, t he RFC draft " dr aft -iet f-isis -3 w ay-01.t xt " proposes a m et hod for new TLV hello packet s t hat increase t he m axim um num ber of p oint -t o-point adj acencies. OSPF has sim ilar lim it s im posed by t he m axim um 64K byt es size of Rout er and Net w or k LSAs. This figur e allow s appr ox im at ely 5000 Link s for Ty pe 1 and Ty pe 2 LSAs. Consider , for exam ple, Type 1 LSAs. Using 24 byt es for fixed fields , 12 byt es r esult s in a lit t le m or e t han 5400 Ent r ies, as t his figur e is close t o t he 65535 m axim um num ber of links t hat is suppor t ed by t he 1 6-bit link field specified in t he Rout er LSA. Not e also t hat all ot her LSAs apar t fr om Types 1 and 2 hold single p r efixes. Because t her e is no lim it t o t he num ber of such LSAs, a lar ge num ber of int er ar ea r out es or ext er nals w ill be dem anding on t he m em or y r esour ces of a r out er . This a good r eason w hy BGP r out es held in t he I nt er net r out e t ables should not be dist ribu t ed int o any I GP. Ther e ar e also pr act ical lim it at ions on how m any r out es a r out er can effect iv ely suppor t in an efficient m anner .

How Large Can IS-IS and OSPF Areas Be? How lar ge an ar ea a specific r out ing pr ot ocol can suppor t has alw ay s been an int r iguin g quest ion for m any net w or k ar chit ect s and oper at or s. This issue w as discussed ear lier in t he chapt er for I S-I S in t he " I S-I S Scaling I ssues" sect ion. The size of an ar ea is a funct ion of m any fact ors, including available net w ork resources, such as m em ory, CPU speed of t he r out er s, bandw idt h, and so on, and st abilit y of t he links. The lar ger t he ar ea, t he m or e r esour ce r equir ed t o suppor t it . Also, unst able ar eas place undue pr ocessing bur den on t he r out er s. Cont inuous flooding of link-st at e inform at ion chew s up net w or k bandw idt h, ult im at ely leading t o net w or k congest ion, w hich m akes t he net w or k unusable. I t is speculat ed t hat som e I S-I S dom ains have deployed appr oxim at ely 1000 r out er s w it h any significant pr oblem s. This

210

m ight seem t o be t r ue because m ost of t he t ier 1 I SPs t hat use I S-I S cur r ent ly deploy on single ar ea dom ains w it h m or e t han 500 r out er s. Appr ox im at ely , 350 OSPF r out er s hav e also been r epor t ed in som e net w or k s. Ther e ar e var ious vendor r ecom m endat ion r egar ding m axim um t est ed ar ea sizes. Som e vendors r ecom m end 50 r out er s per ar ea and a m axim um of 3 ar eas per ABR. I n r ealit y, num ber s ar e not absolut es. What m at t ers m ost is net w ork st abilit y and available resources. I S-I S t ends t o suppor t lar ger net w or ks m ainly because t he I P pr efixes ar e leaves in t he SPF t ree, m eaning full SPF is not r un in m ost cases w her e a link failur e does not im pact t he cor e nodal t opology. I n OSPF, all I P link failur es in an ar ea t r igger LSA updat es, w hich, in t ur n, cause full SPF r uns. Ther efor e, a lar ge OSPF ar ea w ould be m or e dem anding on pr ocessing r esour ces on t he av er age t han an I S-I S net w or k of com par able size.

Security I nt egr at ed I S-I S st andards, I SO 10589 and RFC 1195, specifiy only plain -t ext passw or ds for aut hent icat ion of I S-I S packet s. Cur r ent r eleases of I OS suppor t only sim ple passw or ds I OS. MD5 aut hent icat ion for I S-I S packet s has been proposed in t he I ETF for st andardizat ion and w ill soon be available in Cisco I OS Soft w ar e. Because I S-I S pack et s ar e not encapsuat ed in I P pack et s but r at her ov er t he dat a link, t hey are harder t o spoof and, t herefore, less suscept ible t o com m on denial of ser v ice at t ack s. OSPF suppor t s plain -t ext , as w ell as MD5 aut hent icat ion. As discussed pr ev iously , OSPF pack et s ar e encapsulat ed ov er I P and ar e, t her efor e, subj ect t o spoofing and ot her denial of ser vice at t acks. Use of MD5 aut hent icat ion is, t her efor e, st r ongly advised for OSPF deploym ent s.

Operations: Configuring, Maintenance, and Troubleshooting Bot h t he I nt egrat ed I S-I S and OSPF pr ot ocols hav e been w idely deploy ed and hav e been in use for som e t im e for m ost im plem ent at ions t o be m at ur ed and w ell har dened. How ever , for a long t im e, only Cisco seem ed t o hav e a usable im plem ent at ion of I S-I S. Cur r ent ly , t her e ar e I S-I S im plem ent at ions from ot her rout er vendors t hat are int erope r able w it h t he Cisco im plem ent at ion. Of t he t w o pr ot ocols, OSPF has evolved t he m ost since incept ion, under t he auspices of I ETF OSPF Wor king Gr oup. I t is, t her efor e, not by coincidence t hat OSPF is also t he m ost com plex of t he t w o pr ot ocols fr om bot h pr otocol design and operat ions perpect ive. How ever, I nt egrat ed I S-I S hasn't seen m uch st andar dizat ion since I SO10589 and RFC 1195 w er e published. Most of I S-I S im plem ent at ion exper ience and feat ur e evolut ion w er e developed by Cisco Syst em s. I S-I S was first im p lem ent ed as an I SO only pr ot ocol at Cisco before lat er enhanced w it h I P capabilit ies. I S-I S's t ies w it h I SO CLNP is obvious fr om it s nonconvent ional configurat ion for I P rout ing, w hich requires I SO NSAP t o be configured in place of I P net w or k st at em ent s as found in RI P, OSPF, and EI GRP/ I P. OSPF has a MI B t hat consist s of over 100 m anagem ent variables. The OSPF MI B is available in Cisco I OS Soft w ar e and pr esent s it self as a convenient r esour ce for OSPF configur at ion and general prot ocol m aint enance. A significant num ber of t he OSPF MI B var iables ar e designed for m onit oring puposes. I S-I S MI B is st ill an I ETF draft , and it is current ly not support ed in I OS ev en t hough suppor t is im m inent .

211

Conclusion: Which Protocol Is Better? I S-I S and OSPF hav e been est ablished as pr act ical I GPs for deploy m ent in lar ge scale I P net w or ks. They ar e bot h effect ive and, for t he m ost par t , ar e funct ionally ident ical. The or iginal design of I S-I S w as opt im ized for large LANs ( periodic synchronizat ion, sim ple LAN flooding) and SPF co m put at ion perform ance ( sm all m et rics) . OSPF w as opt im ized for efficient bandw idt h ut ilizat ion and reliabilit y. High-speed r out ing t echnology has significant ly evolved since incept ion of t hese prot ocols, obsolet ing m ost of t hese original design crit eria; yet , bot h pr ot ocols hav e w it hst ood t he t est s of t im e and hav e em er ged as t he only v iable I GP opt ions for lar ge scale r out ing. Bot h pr ot ocols have been w idely deployed. OSPF is m or e w idespr ead fr om m edium t o lar ge net works. I S-I S is used in m ost Tier 1 I SP ne t w orks and in single area configurat ions proving it self as v er y scalable. I t is w idely speculat ed t hat m ost of t he lar ge I SPs adopt ed I S-I S because at one t im e it had t he m ost st able im plem ent at ion coupled w it h a U.S. gov er nm ent m andat e t o suppor t I SO CLNS alongside I P. Hav ing had a lot of success w it h I S-I S, t hese lar ge I SPs hav en't seen any good r eason t o sw it ch t o OSPF. OSPF has a lar ger num ber of vendor im plem ent at ions but t her e ar e few m at ur ed and st able I S-I S im plem ent at ions. I S-I S is m or e ex t ensible, even t hough OSPF can also be ext ended by using opaque LSAs. OSPF is m or e of a full I nt er net st andar d, bet t er docum ent ed and m or e widely underst ood. Most I P-based ent er pr ise net w or ks have deployed OSPF w her eas I S-I S r em ains lar gely deployed in t he ser vice pr ovider space. That OSPF is a full I nt er net st andar d m ight explain it s com plexit y. Wit h t he except ion of t he arcane language used in current I S-I S st andar ds and t ies t o I SO and NSAP addr essing, I S-I S is a fairly sim ple prot ocol. I S-I S h as recent ly at t ract ed a lot of int er est in t he I EFT, and t her e is consider able ongoing effor t for it s adv ancem ent . Many v endor s and lar ge I SPs ar e back ing I S-I S effort s in t he I ETF. Bot h prot ocols cont inue t o evolve and current ly provide support for I Pv6. I S-I S suppor t s I Pv 6 t hr ough ext ensions t o t he or iginal pr ot ocol w her eas OSPF pr ovides suppor t by m eans of a new prot ocol, OSPF version 3. Bot h prot ocols cont inue t o cross feat ures and capabilit ies and seem t o be adv ancing in lock -st ep. Wit h rout e -leaking available in I S-I S, any ar chit ect ur al gap bet w een I S-I S and OSPF has fur t her been br idged. I t is com plet ely unr ealist ic t o say one pr ot ocol is bet t er t han t he ot her . They ar e bot h t he best in t heir class t o do t he j ob. Consider fact or s such as t he follow ing t o help y ou select one ov er t he ot her:

•

Dual I P and CLNS suppor t r equir em ent

•

Technical fam iliarit y of t he net w ork engineering and operat ions st aff

•

Technical k now ledge of v endor suppor t st aff

•

Coher ent st andar ds and m at ur it y

•

Mat ur it y of vendor im plem ent at ion

212

• •

Mult ivendor int ero perabilit y requirem ent s Need t o build flat net work or large areas

Summary The beginning of t his chapt er exam ines t he fundam ent als of net w or k design and discusses basic design principles, such as hierarchy, scalabilit y, and convergence. Addressing, sum m arizat ion, and r edist r ibut ion ar e not ed as cr it ical fact or s in designing a scalable net w or k . Then, t he chapt er discusses and evaluat es var ious design pr inciples fr om t he st andpoint of I SI S. The use of I nt egr at ed I S-I S as an I GP is cov er ed in det ail. This discussion consider s t he lim it at ions and st r engt hs of t he I S-I S pr ot ocol and int er act ion w it h BGP. Scaling issues ar e pr esent ed and t he issues of net w or k st abilit y and conver gence ar e discussed in relat ion t o I S-I S. The size of a net w or k is isolat ed as a k ey cont ribut or t o net w ork per for m ance. The effect of t he num ber of nodes and num ber of link s ar e discussed. The chapt er also point s out t hat st abilit y of t he link s also cont r ibut es t o t he ov er all st abilit y of t he net w or k . Var ious design opt ions ar e discussed for I S-I S applicat ions, including hierarchical designs w it h m ult iple ar eas, and flat single -ar ea designs ar e also cov er ed. Hier ar chy is discussed as a good appr oach for const r aining net w or k inst abilit ies and for net w or k gr ow t h and ex pansion. The chapt er defines design t rade -offs bet w een net w ork st abilit y and fast convergence and indicat es t hat , overall, a fast rout e processor is a key asset for achieving fast conv er gence. A k ey t hem e of t he chapt er is t hat design obj ect iv es and ex pect at ions should alw ay s be clearly st at ed as a philosopy behind any build out . The lat er sect ions of t he chapt er r ev iew t he exponent ial back-off feat ur e, w hich can be used t o m it igat e a good com pr om ise bet w een t he conflict ing design goals of fast conv er gence and st abilit y . Ex ponent ial backoff allow s for quick r eponse t o net w or k changes w hile r et aining t he capabilit y t o slow dow n act ions t o cont ain m assive inst abilit ies during persist ent changes in t he net work. A considerable am ount of space in t he chapt er is dedicat ed t o com parat ive analysis of I S-I S v er sus OSPF. The com par ison t ak es off w it h a br ief hist or ical r ev iew of t he or igins of bot h pr ot ocols. Som e t im e is spent on sim ilar it ies bet w een t he t w o pr ot ocols, and highlight s of t he differ ences bet w een t hem is pr esent ed in t able for mat . The r est of t he chapt er discusses in dept h bot h archit ect ural and im plem ent at ion differences. A final conclusion is draw n t hat t he t w o pr ot ocols ar e sim ilar , for t he m ost par t , in funct ionalit y and have pr oven t hem selves in r eal-w or ld deploy m ent s and e it her can do t he j ob. Som e guidelines ar e pr ovided t o assist net w or k oper at or s in m ak ing t he difficult choice bet w een t he t w o.

213

Chapter 8. Network Design Scenarios This chapt er looks at deploying I nt egrat ed I S-I S in v ar ious net w or k ing env ir onm ent s fr om a design perspect ive. I P-only net w or ks ar e exam ined, based on I nt er net ser vice pr ovider ( I SP) deploym ent s. The discussions focus on using I nt egrat ed I S-I S in point -t o-point and m ult ipoint design scenarios. Packet over SONET ( PoS) , a com m on high-speed-to-point t r anspor t t echnology is used as t he pr em ise for ex plor ing I S-I S configur at ion over point -to-point links. The m ult ipoint sect ion looks at Fram e Relay, Asynchronous Transfer Mode ( ATM) , and, in gener al, m esh t r anspor t env ir onm ent s, all of w hich ar e cur r ent ly deployed on a lar ge scale in real net w orks. The chapt er t hen considers st rat egies for m igrat ing from ot her prot ocols, bot h classful and classless, t o I nt egrat ed I S-I S. Exam ples ar e pr ovided t o dem onst r at e how t o car r y out such m igr at ions successfully . The coexist ence of I nt egr at ed I S-I S w it h ot her I nt er ior Gat ew ay Pr ot ocols is discussed. I n som e cases, I S-I S m ust r un alongside anot her I GP, usually on t em porary during m igrat ion, yet som et im es, even perm anent ly. Finally, t his chapt er covers h ow bot h I P and CLNP coexist in dual environm ent s. I ssues t hat m ight exist in dual deploym ent s ar e highlight ed.

Case Study: Migration of Areas Alt hough I nt egrat ed I S-I S r equir es each r out er t o be in only one ar ea, m ult iple NSAPs addr esses ( each w it h a differ ent ar ea I D) can be used sim ult aneously for t he pur pose of r enum ber ing, split t ing, or m er ging of ar eas. Using m ult iple NSAPs on an I S-I S r out er is also k now n as m ult ihom ing. I n t he default m ode of oper at ion, Cisco I OS allow s up t o t hr ee NSAP addr esses, each w it h a differ ent ar ea I D but t he sam e syst em I D. I t should be st r essed t hat configur ing a r out er w it h m or e t han one ar ea addr ess m ust be for only t r ansit ional sit uat ions. Mult ihom ing is covered in det ail in Chapt er 4 , " Addressing in I nt egrat ed I S-I S," in t he " Configuring Mult iple Net s for a Single I S- I S Process"

sect ion.

As y ou lear ned in t he pr e vious chapt ers, for I S-I S r out er s t o for m a Lev el 1 adj acency , t hey m ust hav e at least one ar ea com m on addr ess. Figure 8 - 1

show s t he m igr at ion of t he four r out er s in ar ea 49.0001 t o ar ea 49.0002. Figur e 8 - 1 . Ar e a m igr a t ion .

214

The follow ing elabor at es how each of t he r out er s can be m igr at ed. We st ar t w it h a sim plified sam ple configur at ion as follow s:

router isis net 49.0001.0000.0000.0001.00 The fir st st ep is t o apply t he second NSAP addr ess w it h t he new ar ea pr efix 49.0002 t o each of t he r out er s as show n her e. Each r out er has it s ow n sy st em I D, w hich does not change in t he n ew addr ess:

router isis net 49.0001.0000.0000.0001.00

net 49.0002.0000.0000.0001.00

Dur ing t he m igr at ion, m ult iple adj acencies are not creat ed. How ever, each rout er is aw are t hat it has a num ber of NSAP addr esses, placing it in m ult iple ar eas. The final st ep is t o r em ov e t he NSAP w it h t he old ar ea I D, 49.0001, fr om all t he r out er s, leav ing t he NSAP w it h t he new ar ea I D as show n her e :

router isis net 49.0002.0000.0000.0001.00 This com plet es t he m igrat ion process. During t he m igrat ion, no loss of adj acency occurs, and, t her efor e, t her e is no loss of connect iv it y or ser v ice disr upt ion.

Case Study: Migration from Narrow to Wide Metrics Wit h t he availabilit y of I S-I S w ide m et r ics suppor t in I OS, oper at or s of m any ex ist ing net w or k s have been considering m igrat ing t heir configurat ions from narrow m et rics t o t ake advant age of t he flexibilit y and convenience larger m et ric values provide. As d iscussed in t he previous chapt er , t he easiest and least painful w ay t o do t his m igr at ion is by calling a flag day , shut t ing dow n t he net w ork, m aking appropriat e changes, and t urning t he rout ers back up. How ever, st ringent service level agreem ent s ( SLAs) in som e envir onm ent s pr event t his appr oach. For t unat ely , t her e ar e ot her opt ions. Ther e ar e act ually t w o ot her appr oaches t hat ar e discussed in t he follow ing sect ions. Nar r ow m et r ics t hat allow m et r ic values up t o 63 ar e suppor t ed by TLVs t hat allocat e only 6 bit s for t he m et ric field. These TLVs are com m only r efer r ed t o as old st y le TLVs. Suppor t for new w ide m et r ics is pr ov ided by new st y le TLVs t hat allocat e 24 or 32 bit s for m et r ic. See Chapt er 5, " I S- I S Link- State Database," sect ion " I S- I S Met ric Ext ensions ," for m or e det ails.

Method 1 The first m et hod involves advert ising t he sam e in for m at ion t w ice each t im e w it h a differ ent m et r ic for m at : once w it h old -st y le TLVs and once w it h new -st y le TLVs. This ensur es t hat all rout ers underst and t he advert ised inform at ion.

215

The advant ages and disadvant ages of using t his m et hod is cover ed in Chapt er 6 , " The Short est Pat h Fir st Algor it hm ." This sect ion focuses on t he act ual t r ansit ion st eps t hat need t o be follow ed w hen using t his m et hod: St e p 1 . All r out er s ar e pr esum ably r unning old soft w ar e or new soft w ar e in default m ode so t hey adv er t ise and use only t he old -st y le TLVs. St e p 2 . Mak e sur e t he r out er s ar e r unning soft w ar e t hat suppor t s new -st y le TLVs and configur e t hem t o adv er t ise bot h old -st yle and new -st yle m et rics. Rout er s t hat hav e not yet been upgraded cont inue advert ising and processing only old -st yle TLVs. Reconfigur ed r out er s w it h new soft w ar e w ill r eceiv e bot h t y pes of TLVs and pr ocess bot h. The configur at ion is show n as follow s: router isis metric-style transition St e p 3 . When all t he r out er s hav e been upgr aded as descr ibed in St ep 2, configur e t hem as follow s t o adv er t ise and accept only new -st y le TLVs: router isis metric-style wide St e p 4 . Finally, m et r ic values gr eat er t han 63 can now be configur ed because all t he r out er s can now send and int er pr et r out ing r eceiv ed w it h new -st y le TLVs.

Method 2 I n t his m et hod, r out er s adv er t ise only one st y le of TLV at t he sam e t im e but can under st and bot h st y les of TLV dur ing t he m igr at ion. The benefit of t his m et ho d is t hat LSPs rem ain approxim at ely t he sam e size during m igrat ion. Also, no am biguit y ex ist s because t he sam e infor m at ion is not adv er t ised t w ice inside a single LSP. The disadvant age is t hat all rout ers m ust underst and t he new -st yle TLVs before any rout e r can st ar t adver t ising t hem . Ther efor e, t his t r ansit ion schem e is useful w hen t r ansit ioning t he com plet e net w or k ( or ar ea) t o use w ide m et r ics. This m et hod also inv olv es m or e st eps. This m et hod r equir es t he follow ing t r ansit ion st eps: St e p 1 . All r out er s ar e r unning older soft w ar e or new soft w ar e but in default m ode, so t hey can adv er t ise and use only old -st yle TLVs. Upgr ade each r out er t o new soft w ar e t hat support s new -st yle TLVs and configure it t o advert ise old -st y le TLVs but also accept bot h TLV st yles as follow s: router isis metric-style narrow transition St e p 2 . Reconfigur e each r out er in t ur n t o adver t ise only new -st y le TLVs but also t o accept bot h st y les of TLVs:

216

router isis metric-style wide transition St e p 3 . I n t his st ep, all t he r out ers ar e configur ed for t he last t im e t o adv er t ise and accept only new -st y le TLVs as follow s: router isis metric-style wide The m igr at ion is ov er and m et r ics gr eat er t han 63 can be configur ed as desir ed. N OTE

Sum m a r y of Cisco I OS Configur a t ion Com m a nds

The follow ing subcom m ands ar e av ailable under r out er isis:

• m et ric- st yle na r r ow ( de fa ult ) — Enables t he r out er t o adv er t ise and accept only old -st yle TLVs

• m et ric- st yle w ide — Enables t he r out er t o adv er t ise and accept only new -st yle TLVs

• m et ric- st y le t r a nsit ion— Enables t he r out er t o adv er t ise and accept bot h st yles

• m et ric- st yle n a r r ow t r a n sit ion— Enables t he r out er t o adv er t ise old st yle TLVs and accept bot h st yles

• m et ric- st y le w ide t r a n sit ion— Enables t he r out er t o adv er t ise new st y le TLVs and accept both st yles

The follow ing is a sum m ar y , of t he st eps used in t w o m et r ic t r ansit ion schem es: Met hod 1: Narrow , t o t ransit ion, t o w ide Met hod 2: Nar r ow , t o nar r ow t r ansit ion, t o w ide t r ansit ion, t o w ide

217

Using IS-IS in ISP Networks As discussed in t he pr evious chapt ers, I nt egrat ed I S-I S has only t w o t ypes of net w or k m odels: point -t o-point and broadcast . I S-I S does not suppor t t he point -to-m ult ipoint m odel as in OSPF. You can, how ever, design and configure I S-I S r out er s w it h a w or k ar ound t o suppor t NBMA t r ansport if necessary. This sect ion review s t he different connect ion m odels: point -t o-point and m ult ipoint . I t also exam ines t ypical pr oblem scenar ios w it h r unning I S-I S ov er NBMA net w or k s and look s at how y ou can ov er com e t hese issues. The last par t of t his sect ion discusses scaling in NBMA environm ent s, exam ines t ypical problem s, and provides various w ays t o solve t hem .

Point-to-Point Connections: PoS The sim plest net w or k m odel is point -t o-point connect ivit y. Running I S-I S ov er point -to-point link s, such as PoS, is st r aight for w ar d. PoS is m ost com m only used in I SP back bones as a high-speed int er connect . Ther e ar e var ious t ypes of PoS int erfaces, current ly reaching speeds of 10 gigabit s per second ( OC192/ STM-16) and deployed in high -speed r out er s. Only a single t y pe of hello packet is used w hen r unning I nt egr at ed I S-I S ov er point -to-point links, r egar dless of w het her t he adj acency is Level 1, Level 2, or Level 1 and Level 2. This differ s significant ly fr om r unning I nt egr at ed I S-I S over LANs, w here separat e hello pa cket s are sent for Lev el 1 and Lev el 2. A num ber of special pur pose com m ands can be applied t o point t o-point links, such as com m ands for adj ust ing t he ret ransm ission int erval. I n general, configur ing point -to-point links for I S-I S is t r iv ail and t hor oughly cov er ed in Chapter 9 , " Configuring I S-I S for I P Rout ing on Cisco Rout ers." Mult ipoint environm ent s pose int erest ing challenges when enabled for I S-I S r out ing. Som e of t he issues ar e discussed in t he follow ing sect ion.

Multipoint Connections: Frame Relay, ATM, and IS-IS Mesh Solutions I S-I S does not direct ly support NBMA t ransport and cert ainly does m ake provisions for point t o-m ult ipoint net work m odel. This raises an int riguing quest ion: How do you m odel nonbr oadcast m ult iaccess ( NBMA) net w or ks, such as Fr am e Relay and ATM? The answ er is t hat y ou can use a br oadcast or point -to-point m odel. I n or der t o m odel an NBMA net w or k as a m ult ipoint br oadcast LAN, you need full connect ivit y bet w een all nodes and, t herefore, full m esh of perm anent virt ual circuit s bet w een all rout ers connect ed t o t he m edium . This is not alw ays possible because m ost NBMA environm ent s are designed as a hub and spok e ar chit ect ur e, or t he NBMA cloud is sim ply n ot fully m eshed for econom ic or feasibilit y r easons.

218

Even in a full m esh envir onm ent , if any of t he vir t ual cir cuit s is lost , you m ight have a sit uat ion in w hich flooding is br ok en and t he Link-St at e dat abase is no longer synchronized across all rout ers, leading t o pr oblem s such as r out ing loops. The follow ing sect ions discuss som e possible pr oblem scenar ios t hat m ight be encount er ed w hen designing I nt egr at ed I S-I S for an NBMA env ir onm ent .

Pr ob le m Sce n a r ios w it h N BM A As point ed out pr ev iously , w hen r unning I S-I S in a point -t o-point env ir onm ent ov er ser ial links, I S-I S gener at es and sends only a single hello pack et , r egar dless of t he t y pe of adj acency , Lev el 1, Lev el 2 , or bot h. I n a point -to-m ult ipoint br oadcast env ir onm ent , such as a LAN, I nt egr at ed I S-I S gener at es and sends a differ ent hello pack et , Lev el 1 and Lev el 2 adj acencies. Cisco I OS consider s a ser ial int er face w it h Fr am e Relay encapsulat ion as a m ult ipoint int er face, and, t her efor e, LAN hellos ar e adver t ised over such int er faces. Wit h t his in m in d, consider t he scenar io show n in Figure 8 - 2 . Figu r e 8 - 2 . Pr oble m s for m in g n e igh bor s ove r Fr a m e Re la y .

The Fr am e Relay cloud is show n as a m ix ed configur at ion of point -t o-point and m ult ipoint int erfaces. This r esult s in a connect iv it y pr oblem . As y ou can see, RTA is configur ed as a m ult ipoint br oadcast int er face and is, t her efor e, gener at ing and sending LAN hellos. The ot her r out er s w it hin t he cloud ( r out er s RTB, RTC, and RTD) have single point -t o-point subint er face connect ion t o RTA and, t her efor e, gener at e and send out point -to-point hello packet s t o RTA. Consequent ly, RTA never form s adj acencies w it h any of t hem .

219

The out put of t he show clns neighbor com m and fr om RTA show n in Exam ple 8 - 1 confirm s t hat t he adj acencies w it h all t he ot her r out er s ar e in " init " st at e, m eaning t he adj acency ar e st uck in " I nit ializat ion" . They should be " Up" if com plet ed. Ex a m ple 8 - 1 sh ow cln s n e igh bor com m a nd Out put on RTA

RT1#show clns neighbors System Id Protocol RTB RTC RTD

Interface

SNPA

State

Holdtime

Type

Se0/0.1 Se0/0.2 Se0/0.3

DLCI 10 DLCI 20 DLCI 30

Init Init Init

L1L2 L1L2 L1L2

IS-IS IS-IS IS-IS

I f all t he r out er s w it hin t he Fr am e Relay cloud are not r econfigur ed t o have t he sam e int er face t ype, point -t o-point or m ult ipoint , no adj acency w ill be com plet ed. Ther efor e, LSPs ar e not exchanged over t hese int erfaces. To fix t his problem , RTA needs t o be reconfigured as a point t o-point subint er face, w it h each PVC in a differ ent I P subnet . Figure 8 - 3

show s a second pr oblem scenar io t hat m ight occur w hen r unning I nt egr at ed I S-I S

ov er an NBMA ATM cloud. Figur e 8 - 3 . N on fu lly m e sh e d N BM A clou d w it h M u lt ipoin t con figu r a t ion .

Figure 8 - 3

show s an ATM cloud in w hich all r out er s ar e fully m eshed w it h vir t ual cir cuit s and bot h

t he solid and dot t ed lines ar e act iv e. The full m esh allow s t he cloud t o be m odeled as a br oadcast link and configur ed as such t o w or k w it h I S-I S. The pr oblem w it h t his m odel is t hat t he full m esh ATM cloud does not have t he com plet e br oadcast capabilit ies of a m ult ipoint

220

br oadcast t echnology , such as Et her net . When any of t he VCs fails ( consider t he dot t ed lines as failed cir cuit s) , t he any-to-any connect ivit y is lost , breaking t he floodin g m odel. I ndividual VCs ar e not t r ack ed in t he I S-I S adj acency dat abase for m ult ipoint int er faces, so any failur es ar e not dect ect ed in t he I S-I S envir onm ent . Alt hough m odeling an NBMA cloud as a br oadcast LAN is suppor t ed, it w or k s only as long as all t h e VCs of t he fully m eshed t opology ar e up. The oper at ion of r out ing and for w ar ding m ight br eak w hen one or m or e v ir t ual cir cuit s go dow n. The follow ing sect ion covers t he preferred solut ion w hen running I nt egrat ed I S-I S over NBMA.

N BM A Solu t ion : Poin t - t o- Po in t Su bin t e r fa ce s The pr ev ious sect ion consider ed pr oblem s associat ed w it h NBMA clouds w hen t hey ar e eit her m odeled as br oadcast m ult ipoint link s or w hen m ult ipoint int er faces ar e connect ed t o point -t opoint int erfaces. I n bot h cases, t he associat ed proble m s w er e obv ious. Tr y ing t o sim ulat e point -t o-m ult ipoint connect ivit y did not w or k, and m odeling as br oadcast r equir ed all VC t o be up all t he t im e or flooding st ops w or k ing pr oper ly and t he LS dat abases w ill be unsy nchr onized bet w een rout ers. The t hird opt ion is t o m odel t he VCs as point -to-point links by using point -topoint subint erfaces. The point -t o-point m odel is m or e r obust and pr ovides a viable alt er nat e. I t allow s t r acking of t he individual VCs, and each adj acency is m onit or ed and consider ed in t he LS dat abase. A full m esh of PVCs is not r equir ed, m aking it econom ically feasible. As viable as t his approach is, it present s scaling challenges in environm ent s w it h highly m eshed virt ual cir cuit s. These envir onm ent s m ight exper ience r edundant flooding pr oblem s, placing undue burden on net w ork resources, such as bandw idt h, m em ory, and processing capacit y. When using point -t o-point subint er faces in NBMA envir onm ent s, I P addr esses can be conser v ed using I P unnum ber ed int er faces w hich ar e t ied t o loopback addresses. I f dist inct addr esses ar e r equir ed for t he links, I P subnet s w it h 30 -bit m asks ( / 30 subnet s) can be used. This keeps t he m inim um num ber of required host s t o t w o per subnet . Also, recent releases of Cisco I OS Soft w ar e suppor t 31-bit m asks t hat provide m or e addr ess sav ings. To address scaling issues result ing from redundant flooding in highly m eshed environm ent s, I S-I S m esh gr oups can be used. This is discussed in t he nex t sect ion.

N BM A Sca lin g Most net w ork operat ors configure t heir Fram e Relay and ATM NBMA net w or ks using point -topoint subint erfaces. Also, frequent ly, NBMA int erfaces support a large num ber of PVCs. A full m esh, alt hough, provides convenient redundancy and m ight result in a pot ent ially high num ber of LSPs being flooded out of t he subinterfaces—acr oss t he m esh, r esult ing in scaling issues. The higher t he ext ent of t he m esh, t he lar ger t he num ber of adj acencies. Wit h a lar ge num ber of adj acencies t o support , a rout er's LSP m ight grow m ore t han t he m axim um LSP size,

221

r equir ing fr agm ent at ion. This can have adver se effect s on t he net w or k because t he num ber of LSPs is m or e of a concer n t han t he act ual size of t he LSPs in such env ir onm ent s. I n essence, larger num ber of LSPs requires m ore SPF com put at ion t im e. I n sum m ary, a large NBMA full m esh ca n result in pot ent ial perform ance and scalabilit y issues. Excessive flooding in such environm ent s can be lim it ed by grouping subint erfaces int o m esh groups. Mesh gr oups ar e designed for opt im izing flooding ov er lar ge NBMA clouds w it h m any point -t o-point co nnect ions. The basic idea behind m esh gr oups is t hat each m em ber of t he m esh gr oup does not r eflood LSPs r eceived fr om anot her m em ber of t he gr oup t o ot her m em ber s of t he sam e gr oup because t hey w ould have alr eady r eceived copies. How ever , LSPs r eceived fr om nonm em ber r out er s ar e flooded t o all m em ber s of t he m esh gr oup, as w ell as ot her adj acent nonm em ber s. Figures 8 - 4

and 8 - 5 show t he flooding oper at ion of m em ber s and nonm em ber s of a m esh gr oup.

Mesh -gr oups ar e enabled on Cisco r out er s as show n in Exam ple 8 - 2 . Figur e 8 - 4 . M e sh gr ou p e x a m ple : m e m be r floodin g.

222

Figur e 8 - 5 . M e sh gr oup e x a m ple : nonm e m be r flooding.

Ex a m ple 8 - 2 M esh- Gr oup Configur a t ion

interface ATM2/0.1 point-to-point ip address 182.168.200.9 255.255.255.252 ip router isis isis mesh-group 10 All int er faces t hat belong t o t he sam e m esh gr oup ar e ident ified w it h t he sam e m esh gr oup num ber . For ex am ple, t he int er face show n Exam ple 8 - 2 is ident ified wit h m esh -group num ber 10. Also, t he m esh group synt ax allow s you t o select ively configure full blocking on individual int er faces inst ead of placing t hem in a gr oup. Mesh gr oups need t o be used w it h car e. To ensur e flooding is not disr upt ed, select t he m ost r eliable PVCs t o flood ov er . Failur e t o do so m ight com prom ise flooding and result in u nsynchronized dat abases w hen crit ical VC connect ions fail. Figure 8 - 4

illust r at es m esh gr oup oper at ion. As show n, an LSP r eceived fr om anot her m em ber is

not for w ar ded t o ot her m em ber s of t he sam e gr oup, but for w ar ded t o nonm em ber s.

Figure 8 - 5

show s t hat an LSP r eceiv ed fr om a nonm em ber of t he m esh gr oup is for w ar ded t o bot h m em ber s and nonm em ber s. As m ent ioned pr eviously, t he alt er nat ive t o gr ouping subint er faces int o a m esh gr oup is t o block flooding individually on each subint er face. I f full LSP blocking on select ed subint er faces is enabled, no flooding occurs at all over t hose int erfaces. Problem s m ight aris e if a lar ge num ber of subint er faces ar e put int o block ing m ode, and som e of t he few t hat ar e allow ed t o flood fail. The follow ing configurat ion ( Exam ple 8 - 3 ) enables select iv e int er face block ing on an individual subint er face.

223

Ex a m ple 8 - 3 Block ing LSP Flooding on I ndividua l I nt e r fa ce s

int ATM2/0.1 point-to-point ip address 192.168.200.9 255.255.255.252 ip router isis isis mesh-group blocked When using select ive int er face blocking, m or e r obust flooding can be achieved by allow ing adv er t isem ent of CSNPs on t hose subint er faces t hat ar e ot her w ise block ed fr om flooding LSPs. This is configur ed as show n in Exam ple 8 - 4 . Ex a m ple 8 - 4 LSP Block in g w it h CSN P Floodin g

int ATM2/0.1 point-to-point ip address 192.168.200.9 255.255.255.252 ip router isis isis mesh-group blocked isis csnp-interval Of t he t w o m et hods —select iv e LSP block ing on indiv idual int er faces and m esh -groups —t he pr efer r ed appr oach is select ive blocking. This m et hod is pr efer r ed m ainly because it is m or e st r aight for w ar d and easier t o configur e and m onit or . Also, it can be used t o gener ally flood few er LSPs. Use of m esh gr oups is a m or e sophist icat ed appr oach and r equir es m or e planning t o be effect ive and efficient . Also, t r oubleshoot ing pr oblem s m ight be m or e com plicat ed.

LSP Tim e r s in N BM A N e t w or k s To allev iat e som e of t he load on net w or k r esour ces caused by flooding m any LSPs, y ou can m odify a num ber of LSP t im er s t o r est r ict t he for w ar ding of LSPs ov er point -t o-point int er faces. The follow ing ar e r elevant com m ands. Th e isis lsp- int erva l com m and cont rols t he int erval bet w een successive LSP t ransm issions. The value is specified in m illiseconds. By default and in line w it h t he st andar d, Cisco I OS Soft w ar e m aint ains a delay of at least 33 m illiseconds bet w een consecut ive LSP t r ansm issions. On low -speed lines, t his m ight st ill be t oo fast and m ight consum e t oo m uch of t he lim it ed bandw idt h av ailable. Recent I OS releases rest rict bandw idt h used for LSP t ransm ission on links w it h T1 capacit y and less t o no m or e t han 50 per cent of t he configur ed bandw idt h. Th e isis ret ra nsm it - in t e r va l com m and specifies t he t im e bet w een r et r ansm issions of a single LSP on a po int -to-point link and has a 5 -second default . The com m and is not applicable t o broadcast m edia. To reduce t he num ber of ret ransm issions on a link, t he configured value needs t o be conservat ively higher. Ret r ansm issions occur only w hen LSPs ar e dr opped; so configur ing a higher v alue w ill hav e m inim al effect on convergence. I n a net w ork w it h m any redundant pat hs, a higher value is easily j ust ified because t he possibilit y of a r out er not r eceiving an LSP in t im ely fashion is less. Th e isis ret ra nsm it - t hrot t le- in t e r va l com m and specifies t he m inim um delay in m illiseconds bet w een r et r ansm issions of LSPs on an int er face. I n a lar ge net w or k w it h m any nodes, it m ight be useful t o cont r ol t he r at e at w hich LSPs ar e r esent out of an int er face. By default , a 3 3 -m illisecond gap ex ist s bet w een consecut iv e LSPs confor m ance w it h an I SO 10589

224

specificat ion of 30 LSP t r ansm issions per second. All t he t hr ee com m ands discussed in t his sect ion cont r ol LSP flooding and can be used t oget her w it h m esh -gr oups in t he gr oup m ode for m axim um effect .

Migrating from Other IGPs to Integrated IS-IS Wit h t he increasing popularit y of I nt egrat ed I S-I S, a num ber of I SPs have m igrat ed I GPs from ot her prot ocols, w hereas ot hers are st ill w eighing t he benefit s. The m ain rat ional behind t he m igr at ions is t o deploy a scalable and r obust pr ot ocol t hat conv er ges fast . Ease of t roubleshoot ing and m aint enance are also key fact ors. Yet , ot hers m ight have a need t o deploy a link-st at e pr ot ocol t hat suppor t s advanced applicat ions, such as MPLS t r affic enginee r ing. This sect ion discusses basic m igr at ion t echniques t hat have been used w it h a lot of success. Ther e m ight be sever al ot her appr oaches t o I GP m igr at ion, and t he net w or k oper at or is advised t o chose t he m ost convenient m et hod based on t he cir cum st ances. The m igr at ion pr ocedur e differ s depending on t he t ype of t he exist ing I GP. I f t he exist ing I GP is a classful dist ance -vect or prot ocol, such as t he Rout ing I nform at ion Prot ocol ( RI P) , or I nt erior Gat ew ay Rout ing Prot ocol ( I GRP) , for exam ple, t he procedure requires different consider at ions t han if m igr at ing fr om a classless pr ot ocol, such as Open Shor t est Pat h Fir st ( OSPF) .

Migrating from a Classless IGP to Integrated IS-IS This sect ion covers t echniques and st rat egies for m igrat ing from classless I GPs, such as t he Enhanced I nt erior Gat ew ay Prot ocol and OSPF, t o I nt egrat ed I S-I S, w hich is it self anot her classless prot ocol. The nex t sect ion elabor at es on t he m et hodology for m igr at ing fr om EI GRP. The ent ir e m igr at ion pr ocess is pr esent ed in det ail, and r elevant I OS show and debugging com m ands for verifying and t roubleshoot ing any pot ent ial problem s are also provided.

Sce n a r io: M igr a t in g fr om EI GRP t o I n t e gr a t e d I S - I S The scenario considered is m igrat ion from a flat EI GRP net w ork t o a single ( Level 2) I nt egr at ed I S-I S net w ork. EI GRP is act ually an int elligent dist ance -vect or prot ocol. I t is classless and support s variable lengt h subnet m ask s ( VLSMs) . EI GRP uses hellos j ust as I S-I S and OSPF t o discov er and m aint ain neighbor s. I t builds a t opology t able, based on r out ing updat es ex changed bet w een neighbors. The m igrat ion from EI GRP t o I nt egrat ed I S-I S is not t oo com plex , alt hough a m igr at ion fr om a pur e link-st at e prot ocol m ight be sim pler because of sim ilar charact erist ics, such as flooding not being dir ect ly t ied t o t he set of r out es ent er ed int o t he r out ing. A num ber of m et hods can be used t o achieve a successful m igr at ion. Tw o specific appr oaches ar e

225

out lined in t he follow ing t ext . The fir st appr oach is t he Redist r ibut ion m et hod, and t he second is t he Back gr ound m et hod.

•

Redist ribut ion m et hod— This approach involves configuring I nt egrat ed I S-I S at t he edge of t he net w or k in addit ion t o EI GRP and t hen r edist r ibut ing t he pr ot ocols int o each ot her , w hile gr adually ext ending t he pr ocess int o t he cor e. This m et hod is co m plex because configur ing m ut ual r edist r ibut ion at m ult iple point s in a net w or k can cr eat e r out ing loops if appr opr iat e filt er s ar e not car efully applied t o st op r out e feedback. How ever , if planned and execut ed car efully, t his appr oach allow s gr aceful m igrat ion t hat does not significant ly im pact availabilit y of t he net w ork.

•

Ba ck gr ound m e t hod— The second appr oach, and possibly t he bet t er , inv olv es r unning bot h pr ot ocols in par allel and m ak ing use of adm inist r at iv e dist ances t o m ak e EI GRP r out es pr efer r ed init ially and r ever sing t hat lat er so t hat I S-I S r out es ar e pr efer r ed. This can be achieved by set t ing t he adm inist r at ive dist ance of all I S-I S r out es t o 255 w it h t he dist ance com m and under t he I S-I S r out ing pr ocess. This ensures t hat I nt egrat ed I S-I S r out es are never used in preference of EI GRP rout es for sim ilar r out es w it h t he sam e pr efix lengt h. I S-I S r out es have an adm inist r at ive dist ance of 115, and EI GRP uses 90 by default . Configur ing explicit adm inist r at ive dist ance for I S-I S m ight not be r equir ed init ially because for sim ilar int er nal r out es, EI GRP r out es w ill be pr efer r ed ov er I S-I S rout es. How ever, care needs t o be t aken if t her e ar e EI GRP sum m ar y and ext er nal r out es in t he net w or k. These r out es have adm inist rat ive dist ances of 5 and 170, respect ive ly. Using explicit dist ances is, t her efor e, bet t er and safer .

Aft er I S-I S has been enabled on t he w hole net w or k and adj acencies and LS dat abases ver ified, EI GRP r out er s can t hen be m ade less pr efer able by m oving t he adm inist r at ive dist ance of 255 fr om t he I S-I S pr ocess t o t he EI GRP pr ocess in each r out er . I t is r ecom m ended t o k eep t he EI GRP pr ocess in t he back gr ound t o ex pedit e r est or at ion t o t he old set up if t her e ar e any issues. The final st ep involves r em oving EI GRP fr om t he net w or k alt oget her . Bot h t he Dist ribut ion and t he Background m et hods require running t he t w o prot ocols t oget her t o som e ex t ent and, t her efor e, can place r esour ce dem ands on t he r out er s. I f r unning bot h pr ot ocols at t he sam e t im e is not suit able for t he specific env ir onm ent , an int r usiv e appr oach t hat r equir es t ear ing dow n EI GRP befor e enabling I S-I S can be em ploy ed. This w ould, how ev er , r equir e net w or k dow nt im e. Table 8 - 1

list s default adm inist rat ive dist ances in Cisco I OS Soft ware for various rout ing

pr ot ocols.

Table 8 - 1 . D e fa ult Adm inist r a t ive D ist a nce s

Cisco I OS Rou t in g Pr ot ocol D e fa u lt Adm in ist r a t ive D ist a n ce Connect ed int erface 0

226

St at ic rout e EI GRP sum m ary rout e eBGP EI GRP ( int ernal) I GRP OSPF I S- I S RI P EGP EI GRP ( ext ernal) iBGP

1 5 20 90 100 110 115 120 140 170 200

Soft w a r e a n d H a r dw a r e Au dit Before enabling I nt egrat ed I S-I S t o r un in par allel w it h EI GRP, it is essent ial t o under st and t he capabilit es of each r out er , fr om bot h har dw ar e and soft w ar e st andpoint s, by car r ying out a com plet e audit of t he net w or k . Wit h r egar d t o har dw ar e, t his ensur es t hat no m aj or issues r elat ing t o CPU and m em or y r equir em ent s w ould ar ise in t he m iddle of t he m igr at ion. Also, it m ight be useful t o m ake sur e each r out er is r unning an I OS r elease t hat not only suppor t s I S-I S but also all t he capabilit ies and services r equir ed for nor m al oper at ion of t he net w or k. The net w or k ar chit ect s and oper at ions st aff involved in t he m igr at ion should j oint ly plan t he ent ire operat ion. Som e guidance on t he phases involved is provided lat er in t his chapt er. The m igrat ion act ivit ies need t o also be prudent ly docum ent ed for post m ort em evaluat ion of successful m igrat ion or any challenges encount ed during t he process. This m ight provide opport unit ies for enhancing cert ain aspect s of t he net w ork.

I n t e gr a t e d I S- I S Con figu r a t ion s Exam ple 8 - 5

show s a t ypical I nt egr at ed I S-I S configurat ion t hat m ight be used for t he m igrat ion.

This configur at ion specifies each r out er as Level 2 -only and includes an adm inist r at ive dist ance of 255. This w ill configur e t he ent ir e net w or k t o r un a single flat Lev el 2 I S-I S ar ea. I S-I S m ust be enabled on t he appr opr iat e int er faces of each r out er by applying t he ip rout er isis com m and. Bot h t he lsp- r e fr e sh- int erva l an d m ax- lsp- lifet im e values are increased t o t heir m axim um t o reduce periodic LSP flooding. Wide m et rics are configured t o allow great er int erface and pat h m et r ic values t o be used. Wide m et r ics ar e r equir ed w hen configur ing I S-I S t o suppor t MPLS t r affic engineer ing. Ex a m ple 8 - 5 I S- I S Process Configura t ion

227

! router isis net 49.0001.1234.5678.9abc.00 passive-interface loopback0 lsp-refresh-interval 65000 max-lsp-lifetime 65535 is-type level-2-only distance 255 ip log-adjacency-changes ignore-lsp-errors metric-style wide level-2 ! Ot her I nt egrat ed I S-I S t im er s m ight be m odified t o suppor t t he specific net w or k envir onm ent aft er t he m igrat ion. Som e of t he t im er s of int er est ar e list ed her e. I S-I S r out ing-pr ocess level com m and:

•

spf- int erva l

•

prc- int erva l

•

lsp- ge n- in t e r va l

I nt erface level com m ands:

•

csnp- in t e r va l

•

hello- in t e r va l

• •

hello- m ult iplie r

Chapter 9

ret ra nsm it - in t e r va l covers st eps for enabling I S-I S and explains in det ail t he t im er for t he preceding

com m ands.

Con figu r in g I n t e gr a t e d I S - I S in Pa r a lle l w it h EI GRP When enabling I S-I S t o r un in par allel w it h EI GRP, at t ent ion m ust be paid t o LSP flooding and t he fr equency of SPF/ PRC calculat ions because t hey m ight place heav y dem ands on net w or k resources, such as m em ory, CPU, and bandw idt h. The follow ing needs t o be verified w hen t he t wo prot ocols are running sim ult aneously:

•

I P addr essing

•

Sum m arizat ion

•

Default r out ing ( if r equir ed)

•

Appropriat e int erface m et rics t o direct t raffic flow

•

Consist ent collect ion of LSP in t he Link-St at e dat abase across all rout ers

•

I S-I S adj acencies form ed

•

Fr equency of SPF and PRC calculat ions

228

Aft er t he preceding checks have been com plet ed w it h sat isfact ion and it has been confir m ed t hat t her e ar e no im m inent pr oblem s, a m aint enance per iod can be scheduled for t he final cut over fr om EI GRP t o I S-I S. I t is alw ay s safe t o hav e a m inim al dow nt im e for t he cut ov er , ev en t hough it m ight not be r equir ed. Downt im e is a t er m used w hen t he net w or k is not av ailable t o user s. This m eans t hat par t of t he net w or k or it s ent ir et y w ill be unav ailable. The act ual t im e r equir ed m ight depend on t he size and t he com plex it y of t he net w or k and also t he num ber and ex per ience of suppor t st aff involved in t he pr ocess. Migr at ion of 500 nodes, for exam ple, m ight call for sever al hour s of dow nt im e. Aft er com plet ing all planned v er ificat ions, t he dist ance can be r ev er sed, by apply ing a v alue of 2 5 5 t o EI GRP rout es or low ering t he dist ance of I S-I S r out es so t hat t hey w ould be pr efer r ed over EI GRP r out es. Usually, a clea r ip rout e * com m and m ight be r equir ed t o help flush out t he old EI GRP r out es and r epopulat e t he I P r out ing t able w it h t he pr efer r ed I S-I S r out es.

M igr a t ion Ph a se s: Ex a m ple EI GRP t o I S - I S M igr a t ion depict s a sim ple net w ork running EI GRP as t he I GP. I S-I S is configur ed t o r un alongside EI GRP and lat er t o t ak e pr efer ence ov er EI GRP.

Figure 8 - 6

Figur e 8 - 6 . Sim ple EI GRP ne t w or k t o m igr a t e t o I S- I S.

M igr a t ion Ph a se s This sect ion ident ifies t he differ ent m igr at ion phases and discusses w hat occur s in each phase.

229

Ph a se 1 : The net w or k is r unning EI GRP in a flat net w or k . Har dw ar e and soft w are au dit s per for m ed and soft w ar e and har dw ar e upgr aded ar e needed t o suppor t t he m igr at ion. Ph a se 2 : I nt egr at ed I S-I S is configur ed t o r un in par allel and in t he back gr ound w it h a higher adm inist rat ive dist ance. This allow s creat ion of t he I S-I S Link-St at e dat abase in all t he r out er s but t he rout ing and forw arding t ables rem ain unalt ered. This phase is probably t he m ost crit ical because norm al operat ion of I S-I S m ust be car efully ver ified. The good new s her e is t hat t he oper at or can t r oubleshoot any I nt egr ated I S-I S pr oblem s w it hout disr upt ing net w or k ser vice; how ever , addit ional m em or y r equir em ent s and an incr ease in CPU ut ilizat ion m ight pose som e challenges. This phase can be considered com plet e only aft er t he I S-I S dat abase has been fully populat ed in each r out er w it h all ex pect ed LSPs and t he pot ent ial for gener at ing I S-I S r out es t hat r eflect t he EI GRP r out es in t he cur r ent r out ing t able has been confir m ed. Ph a se 3 : Cu t -ov er of t he w hole net w or k t o I nt egr at ed I S-I S as t he pr im ar y I GP by t ransferring t he h igh adm inist r at ive dist ance com m and t o t he EI GRP pr ocess. Ph a se 4 : EI GRP is com plet ely r em oved fr om t he net w or k aft er nor m al oper at ion aft er for w ar ding under I S-I S is confir m ed t o be flaw less.

Ph a se 1 —Con figu r a t ion s a n d Ot h e r St a t u s I n for m a t ion Exam ple 8 - 6

show s a t ypical EI GRP configur at ion t hat m ight be pr esent on t he r out er s pr ior t o

m igr at ion. Ex a m ple 8 - 6 Typica l EI GRP Configur a t ion

! router eigrp 10 network 192.168.10.0 network 192.168.20.0 no auto-summary !

Ph a se 2 —Con figu r a t ion s a n d Ot h e r St a t u s I n for m a t ion At t his point , I nt egrat ed I S-I S needs t o be configured in t he background for every rout er, as show n in

Exam ple 8 - 7 .

Ex a m ple 8 - 7 Ena bling I S- I S in t h e Ba ck gr ou n d

! hostname RTA ! clns routing ! interface Serial1/0:1 ip address 192.168.20.5 255.255.255.252 ip router isis isis metric 500 level-2 ! router eigrp 10 network 192.168.10.0

230

network 192.168.20.0 no auto-summary ! router isis passive-interface Loopback0 distance 255 ip net 49.0001.1921.6810.0001.00 is-type level-2-only metric-style wide level-2 max-lsp-lifetime 65535 lsp-refresh-interval 65000 log-adjacency-changes ! Because an adm inist rat ive dist ance of 255 is configured for I nt egrat ed I S-I S, EI GRP ext ernal r out es w it h an adm inist r at iv e dist ance of 170 w ill not be pr eem pt ed in t he I P r out ing t able. Var ious show com m ands can be used t o m onit or and v er ify nor m al oper at ion of I S-I S. As m ent ioned previously, t his st age is crit ical because I S-I S m ust be t uned and ver ified t o be fully oper at ional. The subsequent st ages of t he m igr at ion should be sm oot h if t his phase goes well. The follow ing ex am ples show essent ial infor m at ion needed to verify t he correct configurat ion and oper at ion of I nt egr at ed I S-I S. The show com m ands in Exam ple 8 - 8 capt ur e t he st at us and operat ing param et ers for I S-I S. I m por t ant lines ar e highlight ed. Ex a m ple 8 - 8 Ve r ifying I S- I S Configura t ion

RTD#show clns Global CLNS Information: 3 Interfaces Enabled for CLNS NET: 49.0001.1921.6810.0001.00 Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64 ERPDUs requested on locally generated packets Intermediate system operation enabled (forwarding allowed) IS-IS level-2-only Router: Routing for Area: 49.0001 RTD#show clns protocol IS-IS Router: System Id: 1921.6810.0001.00 IS-Type: level-2-only Manual area address(es): 49.0001 Routing for area address(es): 49.0001 Interfaces supported by IS-IS: Serial1/0:1 - IP FastEthernet5/0 - IP FastEthernet2/0 - IP Redistributing: static Distance: 110 (Comment: This distance is for ISO routing) RRR level: none Generate narrow metrics: level-1 Accept narrow metrics: level-1 Generate wide metrics: level-2 Accept wide metrics: level-2

231

The com m and show clns prot ocol is part icularly useful because it helps verify t he t he configur at ion by displaying a single out put t hat show s t he syst em I D, ar ea addr ess, I S t ype, I S-I S-enabled int er faces, and w ide m et r ic suppor t . Ex a m ple 8 - 9 Ve r ifyin g Adj a ce n cie s For m e d

RTD#show clns neighbor System Id RTH RTB

Interface SNPA State Se1/0:1 *HDLC* Up Fa5/0 0003.fec9.cc54 Up

Holdtime 24 24

Type Protocol L2 IS-IS L2 IS-IS

Use t he show clns neighbor com m and t o ver ify t hat t he r ight adj acencies have been for m ed. An adj acency m at r ix , show ing w hich neighbor s ar e ex pect ed in t he adj acency t able, m ust be pr epar ed ahead t o facilit ate t his verificat ion.

Exam ple 8 - 10

show s how t o obt a in m ore inform at ion

about each neighbor. Ex a m ple 8 - 1 0 Obt a ining M or e I nfor m a t ion About N e ighbor s

RTD#show clns neighbor detail System Id Interface SNPA State RTH SE1/0:1 *HDLC* Up Area Address(es): 49.0001 IP Address(es): 192.168.20.38* Uptime: 00:37:01 RTB Fa5/0 0003.fec9.cc54 Up Area Address(es): 49.0001 IP Address(es): 192.168.10.161* Uptime: 01:54:16

Holdtime 25

25

Type L2

L2

Protocol IS-IS

IS-IS

I S-I S needs t o be m onit or ed for st abilit y aft er it is deploy ed acr oss t he net w or k and pr ior t o prom ot ing it above EI GRP. Typical vit al st at ist ics t o m onit or include increm ent ing LSP sequence num bers, high num bers of SPF com put at ions, checksum errors, and ret r ansm issions. The out put of t he show clns t r a ffic com m and provides st at ist ics for I S-I Sr elat ed t r affic. Ex cer pt s of t his com m and out put ar e show n in Exam ple 8 - 11 . This inform at ion is also useful for t r oubleshoot ing pot ent ial pr oblem s. Som e of t he int er est ing lines in t he out put ar e highlight ed. Ex a m ple 8 - 1 1 M onit or ing I S- I S Tr a ffic St a t ist ics

RTD#show clns traffic [snip] IS-IS: Level-2 Hellos (sent/rcvd): 13465/2568 IS-IS: PTP Hellos (sent/rcvd): 2035/489 IS-IS: Level-2 LSPs sourced (new/refresh): 57/3 IS-IS: Level-2 LSPs flooded (sent/rcvd): 146/399. IS-IS: LSP Retransmissions: 1 IS-IS: Level-2 CSNPs (sent/rcvd): 2356/5 IS-IS: Level-2 PSNPs (sent/rcvd): 123/14 IS-IS: Level-2 DR Elections: 15 IS-IS: Level-2 SPF Calculations: 67 IS-IS: Level-2 Partial Route Calculations: 38 IS-IS: LSP checksum errors received: 0 IS-IS: Update process queue depth: 0/200 IS-IS: Update process packets dropped: 0

232

The following t ext provides guidelines for int erpret ing t he inform at ion in Exam ple 8 - 11 .

•

LSPs sourced indicat e st abilit y of t he I S.

•

LSP r et r ansm issions need t o st ay low .

•

PRCs cannot be checked elsewhere. Part ial ro ut e calculat ions ar e used w hen a change t hat does not affect t he t opology is r epor t ed t hr ough an LSP; t y pical ex am ples ar e t he addit ion or r em oval of an I P pr efix or m et r ic changes, changes r elat ed t o ext er nals r out es or passiv e int er faces.

•

LSP check sum errors indicat e problem s and possible packet corrupt ion. This infor m at ion r eflect s cor r upt ed LSPs w er e r eceived on t his r out er . LSPs m ight be cor r upt ed dur ing t r ansit or w hen st or ed in m em or y. You can t r ack dow n t he cause by m oving from one rout er t o t he ot her along t he pat h t o t he or iginat or and check ing w hich int er m ediat e r out er s also ar e seeing t he sam e er r or s. The I S-I S pr ocess also per iodically scans t he LS dat abase and gener at es an er r or log for any cor r upt ed LSPs found.

•

LSP corrupt ion st orm s ( purging and r eflooding) lead t o fr equent SPF r uns and high CPU. The com m and ignore- lsp- e r r or can be configur ed under t he I S-I S r out ing process t o st abilize t he sit uat ion if necessary.

• •

The updat e queue should not st ay full. The updat e queue should not dr op m uch.

Aft er t he I S-I S oper at ion is v er ified acr oss t he r out er s, t he Link-St at e dat abase needs t o be scanned for t he presence of LSPs from all t he rout ers running I S-I S.

Exam ple 8 - 1 2

show s how t o

list LSP ent r ies in t he LS dat abase. Ex a m ple 8 - 1 2 List in g LSPs in t h e Lin k- St at e Dat abase

RTD#sh isis database IS-IS Level-2 Link State Database LSPID LSP Seq Num RTA.00-00 0x00000006 RTH.00-00 0x00000016 RTC.00-00 0x00000017 RTB.00-00 0x000000E4 RTG.00-00 0x0000001B RTG.02-00 0x00000001 RTG.03-00 0x00000006 RTD.00-00 * 0x00000025 RTD.02-00 * 0x00000004 RTD.03-00 * 0x00000006 Exam ple 8 - 1 3

LSP Checksum 0xB0CB 0xE873 0x6A3C 0x5568 0xFD58 0x6C24 0x9C28 0x9BEE 0xBEF8 0x3A41

LSP Holdtime 62058 58673 65031 62068 63197 56073 61399 63197 61506 54372

ATT/P/OL 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

shows how t o view t he infor m at ion car r ied in an LSP. The LSPs ar e flooded int act ,

and t he sam e infor m at ion needs t o be pr esent in each LSP w hen v iew ed on any of t he ar ea rout ers. During t he m igrat ion, every LSP needs t o be checked t o m ake sure it carries accurat e infor m at ion about t he or iginat or 's envir onm ent . The collect ion of infor m at ion in all t he LSPs needs t o accurat ely reflect t he net w ork's t opology. Ex a m ple 8 - 1 3 Vie w in g t h e I n for m a t ion Ca r r ie d in a LSP

233

RTD#show isis database RTA.00-00 detail IS-IS Level-2 LSP RTA.00-00 LSPID LSP Seq Num LSP Checksum RTA.00-00 0x0000000D 0xA461 Area Address: 49.0001 NLPID: 0xCC Hostname: RTA IP Address: 192.168.10.8 Metric: 10 IS-Extended RTA.02 Metric: 100 IS-Extended RTB.00 Metric: 100 IP 192.168.20.216/30 Metric: 0 IP 192.168.10.12/32 Metric: 10 IP 192.168.10.32/32 Metric: 100 IP 192.168.10.24/30

LSP Holdtime 60837

ATT/P/OL 0/0/0

Br oadcast segm ent s, such as Et her net , should have a consist ent DI S for each level of r out ing. I n t his m igrat ion, I S-I S is being deploy ed as a single Lev el 2 dom ain; t her efor e, t he Lev el 2 DI S on all br oadcast links m ust be ver ified, as show n in Exam ple 8 - 1 4 , t o be t he sam e. Any inconsist ency w ill hinder dat abase synchronisat ion over t he segm ent . I f t her e ar e any anom alies, t he r oot cause needs t o be invest igat ed and cor r ect ed befor e m oving on t o t he nex t phase of t he m igr at ion.

Exam ple 8 - 14

show s t he out put of t he show clns int e r fa ce

com m and w it h t he DI S inform at ion highlight ed. The circuit I D of a broadcast link is associat ed w it h t he syst em I D or t he host nam e of t he DI S. I n t his case, RTD is show n t o be t he DI S. The 02 suffix in RTD.02 indicat es t his is t he second br oadcast segm ent on w hich RTD is play ing t he r ole of DI S. The ot her int er est ing infor m at ion in t his out put is t he num ber of Lev el 2 adj acencies on t he segm ent . This does not include t he vir t ual Pseudonode, and t he count should r eflect ot her act ual adj acent r out er s dir ect ly connect ed t o t he segm ent . You can r ead m ore about DI S and pseudonode funct ionalit y in Chapt er 4 in t he " Form ing LAN Adj acencies " sect ion. Ex a m ple 8 - 1 4 Con fir m in g D I S Con sist e n cy on Br oa dca st Link s

RTD#show clns int fasteth5/0 FastEthernet5/0 is up, line protocol is up Checksums enabled, MTU 1497, Encapsulation SAP ERPDUs enabled, min. interval 10 msec. RDPDUs enabled, min. interval 100 msec., Addr Mask enabled Congestion Experienced bit set at 4 packets CLNS fast switching enabled CLNS SSE switching disabled DEC compatibility mode OFF for this interface Next ESH/ISH in 33 seconds Routing Protocol: IS-IS Circuit Type: level-2-only Interface number 0x1, local circuit ID 0x2 Level-2 Metric: 6000, Priority: 127, Circuit ID: RTD.02 Number of active level-2 adjacencies: 2 Next IS-IS LAN Level-2 Hello in 2 seconds By default , I S-I S set s t he m et ric t o 10 on all int erfaces, regardless of bandwidt h. There fore, pat h select ion w ould be essent ially based on hop count if t he m et r ic is not adj ust ed t o r eflect bandw idt h of t he various links or t o influence t raffic flow along t he preferred pat h. I n cont rast , EI GRP, by default , aut om at ically t akes int o consider at ion t he charact erist ics of links, including bandw idt h t o assign m et r ics, w it h t he low er m et r ic gener ally im plying bet t er bandw idt h. The

234

m et r ic assigned t o a r out e is t he t ot al of t he m et r ic on all out going int er faces on a specific pat h t o t hat dest inat ion. Again, t he low er value is bet t er. Therefore, t o ensure t raffic flow under I S-I S is consist ent w it h t he exist ing t r affic flow under EI GRP, t he m et r ic on all act ive I SI S int er faces needs t o be m anually adj ust ed on ever y r out er t o cor r espond t o EI GRP values or sim ilar , accor ding t o a layout t hat is planned in advance. Enabling I S-I S on all r out er s w it h a dist ance of 255 should not change t he ex ist ing t r affic flow under EI GRP because EI GRP r out es have a bet t er adm inist r at ive dist ance and ar e st ill pr efer r ed over sim ilar I S-I S r ou t es. At t his point , t he net w or k has t w o fully funct ional r out ing pr ot ocols, w it h one as t he pr im ar y sour ce of r out es. Vigilant m onit or ing of t he net w or k needs t o cont inue w it h pr ying int o each rout er's configurat ion, checking I S-I S adj a cencies, verifying consist ency of t he I S-I S LS dat abase on all r out er s, ver ifying consist ency of LSP infor m at ion, checking t he I P r out ing t ables, and forwarding t ables ( FI B and Adj acency Dat abases —See

Chapter 1 ,

" Overview of I P

Rout ing" sect ion) . I t w ould be useful also t o t ake not e of t he num ber of r out es in t he r out ing t able befor e going on t o t he nex t phase. The show ip rout es sum m a ry an d sh ow ip cef sum m a ry com m an ds sh ou ld prov ide t his infor m at ion.

Ph a se 3 —Con figu r a t ion s a n d Ot h e r St a t u s I n for m a t ion The t hir d phase is t o t r ansfer t he adm inist r at iv e dist ance of 255 fr om t he I S-I S r out ing process, t he EI GRP rout ing process, m aking t he lat t er t he less preferred source of rout es. This ensur es t hat I nt egrat ed I S-I S becom es t he prim ary source of rout ing inform at ion t hat feeds r out es int o t he r out ing t able, and t hen m akes it int o t he for w ar ding t ables ( CEF, and so on) . Exam ple 8 - 1 5

show s how t he dist ance com m and is r em oved fr om t he I S-I S pr ocess and a sim ilar

com m and is placed in t he EI GRP process. This m ight require dow nt im e t o be scheduled for final clean up. Ex a m ple 8 - 1 5 Re ve r sin g Pr ior it ie s w it h t h e D ist a nce Co m m a n d

RTD(config)#router isis RTD(config-router)#no distance 255 ip RTD(config-router)# RTD(config)#router eigrp 10 RTD(config-router)#distance 255 RTD(config-router)# The r out ing t able m ight need t o be clear ed t o for ce r out es sour ced fr om I S-I S t o t ak e pr ecedence. The clear ip rout e * com m and does j ust t his. Aft er t he rout ing t able is populat ed w it h I S-I S r out es, a quick show ip r ou t e su m m a r y com m and ent r y should pr ov ide r out e st at ist ics t hat can be com pared w it h sim ilar inform at ion gat hered from t he previous phase. Th e show ip rout e com m and should be used t o scr ut inize t he r out ing t able fur t her t o m ake sur e all pr efix es ar e available and, m ost im por t ant ly, t hat t hey ar e fr om t he I S-I S pr ocess and not EI GRP. The show ip rout e isis an d sh ow ip r ou t e e igr p com m ands need t o be used t o check subset s rout es for I S-I S and EI GRP, r espect ively. The show ip r out e e igr p com m and should n ot display any EI GRP ent r ies in t he r out ing t able. The show ip cef and r elat ed

235

com m ands should be used t o confirm t hat all rout es are available in t he forw arding t able. Exam ple 8 - 1 6

show s a sam ple out put of I S-I S Level 2 rout es for t he I P rout ing t able. Also, t he

ping an d t racerout e com m ands can be used t o t est reachabilit y and pat h select ion t o various dest inat ions in t he net w ork t o confirm norm al rout ing is rest ored. Ex a m ple 8 - 1 6 Ve r ifyin g t h e Rou t e s in t h e I P Rou t in g Ta ble

RTD#show ip route isis i L2 196.172.60.0/24 [80/17846] via 192.168.10.161, FastEthernet5/0 192.28.235.0/28 is subnetted, 1 subnets i L2 192.28.235.0 [80/17846] via 192.168.10.161, FastEthernet5/0 192.168.20.0/24 is variably subnetted, 3 subnets, 2 masks i L2 192.168.20.138/32 [80/17846] via 192.168.10.161, FastEthernet5/0 i L2 192.168.20.216/30 [80/17846] via 192.168.10.161, FastEthernet5/0 i L2 192.168.20.192/30 [80/17846] via 192.168.10.161, FastEthernet5/ 192.168.10.0/24 is variably subnetted, 9 subnets, 3 masks i L2 192.168.10.8/32 [80/17846] via 192.168.10.161, FastEthernet5/0 i L2 192.168.10.9/32 [80/6000] via 192.168.10.161, FastEthernet5/0 i L2 192.168.10.12/32 [80/17846] via 192.168.10.161, FastEthernet5/0 i L2 192.168.10.22/32 [80/17846] via 192.168.10.161, FastEthernet5/0 i L2 192.168.10.23/32 [80/6000] via 192.168.10.161, FastEthernet5/0 i L2 192.168.10.20/32 [80/17846] via 192.168.10.161, FastEthernet5/0 i L2 192.168.10.128/30 [80/23458] via 192.168.10.161, FastEthernet5/0 i L2 192.168.10.104/30 [80/17846] via 192.168.10.161, FastEthernet5/0 i L2 192.168.10.112/28 [80/14462] via 192.168.10.161, FastEthernet5/0

Ph a se 4 —Con figu r a t ion a n d Ot h e r St a t u s I n for m a t ion By t he end of Phase 4, it should be com plet ely confir m ed t hat all for w ar ding is r est or ed and I S-I S r out es ar e able t o com plet ely suppor t r out ing in t he net w or k. EI GRP is no longer r equir ed for pr im ar y r out ing or even for fallback. Disabling of EI GRP r out ing fr om t he net w or k can, t herefore, proceed. The EI GRP configurat ion is rem oved w it h t he follow ing line of configur ation from each rout er:

RTD(config)#no router eigrp 10 This concludes t he m igrat ion process. The net w ork should cont inue being m onit ored for proper forw arding and opt im izat ion opport unit ies, such as sum m arizat ion, m et ric adj ust m ent s of opt im al pat h select ion , and so on in t he new r out ing envir onm ent . The r ecor d of event s dur ing t he m igr at ion needs t o be consult ed for post m or t em evaluat ion. This infor m at ion can pr ovide t he basis for any r ecom m endat ions on fut ur e gr ow t h, changes, and m anagem ent of t he net work.

M igr a t in g fr om OSPF t o I n t e gr a t e d I S- I S Bot h OSPF and I nt egr at ed I S-I S ar e pur e link-st at e prot ocols and, t herefore, use sim ilar m echanism s for flooding and r out e com put at ion. Migr at ing fr om a single ar ea OSPF dom ain t o a single level I S-I S r out ing dom ain should be st r aight for w ar d; t her e should be no change in t he charact erist ics of rout ing in any significant m anner, as com pared t o t he m igrat ion from t radit ional dist ance -vect or prot ocols. I f OSPF is deployed w it h hierarchy, t he hierarchy can be

236

m aint ained w it h I S-I S r out e leaking. How ever , if a hier ar chical OSPF dom ain is not lar ge and t he sim plicit y associat ed w it h t r oubleshoot ing and m aint enance of a flat I S-I S dom ain is of int er est , t his is also possible, even t hough m or e car eful planning w ill be r equir ed .

M igr a t ion Ph a se s The sam e m igr at ion pr inciples and phases t hat w er e elabor at ed for EI GRP m igr at ion in t he previous sect ion can be applied. I n part icular, t he background m et hod can be effect ively used. OSPF has a bet t er adm inist r at iv e dist ance of 110 compared t o 115 for I S-I S, so t echnically in phase 2, t he adm inist r at ive dist ance for I S-I S does not need t o be changed t o 255. How ev er , a higher adm inist r at iv e dist ance m ust be applied t o OSPF in phase 3.

M e t r ics I n t he default m ode of oper at ion, OSPF t r ansform s int erface bandwidt h int o m et ric inform at ion. Unlike EI GRP, how ever, only bandw idt h inform at ion is used and ot her link char act er ist ics, such as delay, r eliabilit y, and MTU, ar e not used t o com put e com posit e m et r ics. OSPF m et r ic or cost v alues ar e inv ersely pr opor t ional t o bandw idt h. The cost on an int er face is assigned based on a default r efer ence bandw idt h of 100Mb/ s and calcuat ed by dividing t he r efer ence bandw idt h by t he int er face bandw idt h. A value 1 is applied for all r esult s gr eat er t han one. The reference bandwidt h is configurable. Also, if necessary, t he int erface m et r ic can also be m anually assigned. For t he pur pose of m igr at ing t o I S-I S, t he OSPF cost s can be not ed for all int er faces and direct ly port ed m anually int o t he I S-I S configur at ion for corresponding int erfaces. The out put of t he show ip ospf int e r fa ce pr ov ides t he cost associat ed w it h an int er face. The OSPF cost s should be obt ained in adv ance for each r out er and ent er ed int o a m igr at ion planning spreadsheet or t able for lat er use. Because OSPF allow s cost v alues lar ger t han 63 per int erface, t his approach m ight require I S-I S w ide m et r ics t o suppor t any lar ge v alues. Using t he sam e m et r ic v alues on cor r esponding OSPF and I S-I S int er faces w ould guar ant ee t he new I S-I S pat hs t o be ident ical t o t he pr ev ious OSPF pat hs. I t w ould m ak e t he m igr at ion pr act ically loop fr ee as I S-I S is m ade prim ary from rout er t o rout er. Rout es int alled from eit her OSPF or I S-I S w ould have pr act ically ident ical char act er ist ics. The net w or k can act ually rem ain fully funct ional as a higher dist ance is applied t o OSPF in each r out er and differ ent rout ers independent ly choose I S-I S or OSPF as t he sour ce of r out es based on cur r ent configur at ion.

M on it or in g N e t w or k Re sou r ce s Probably t he single m ost im port ant issue in m ig rat ing from OSPF t o I S-I S is availabilit y of enough net w ork resources, such as bandw idt h, rout er m em ory, and CPU capacit y, t o handle t wo resource dem anding prot ocols running independent ly and concurrent ly on each rout er.

237

Check ing av ailable r esour ces dur ing t he inv ent or y st age and upgr ading as needed befor e t ur ning up I S-I S in par allel w it h OSPF should go a long w ay t o for est all any sur pr ises t hat m ight appear in t he m iddle of t he m igrat ion. Wit h all t hese issues in m ind, t he m igrat ion from OSPF sh ou ld be sim ilar t o t he m igrat ion from EI GRP, and t he m igrat ion phases discussed ear lier should be applicable her e also.

M igr a t in g fr om a Cla ssfu l I GP t o I n t e gr a t e d I S - I S Migr at ing fr om a classful pr ot ocol is not any m or e challenging t han t he pr evious scenar ios discussed. Classful prot ocols require deploym ent of flat net w orks by t heir inherent nat ure. The r edist r ibut ion m et hod of m igr at ion w ill not w or k w ell her e because I S-I S being a classless prot ocol m ight carry det ailed rout ing inform at ion t hat t he classful prot ocol m ight not be able t o handle. As you m ight know , classful pr ot ocols do not suppor t VLSMs and discont iguous subnet s. Classless prot ocols do. Also, classful prot ocols, such as RI Pv1 and t he I nt erior Gat ew ay Rout ing Prot ocol ( I GRP) , are based on dist ance ve ct or concept s, and t he cont ent s of t he rout ing t ables are direct ly t ied t o rout ing updat es. I n cont rast , I S-I S gener at es r out ing inform at ion based on a com plet e m odel of t he t opology built on inform at ion gat hered from LSPs; t her e, r out ing dy nam ics m ight differ . Also, RI P uses hop count for m et r ics, and I GRP uses a com posit e m et r ic sim ilar t o EI GRP. The m igrat ion from a classful prot ocol t o I nt egrat ed I S-I S m ight also r equir e a change in t he physical t opology if I S-I S is t o be deploy ed w it h hier ar chy . I n m ost cases, however, t he classful m igr at ion involves deploying a flat Level 2 I S-I S dom ain, and so t he back gr ound m et hod can be successfully em ployed w it h m inim al challenges. I f hier ar chy is r equir ed, fir st consider w hich r out er s for m t he backbone of t he net w or k . As discussed in previous chapt ers, I nt egrat ed I S-I S r equir es a cont iguous back bone, w hich w it hin a hierarchical t opology m ust be a collect ion of Level 2 rout ers. The select ion of t he back bone r out er s depends on sev er al cr it er ia. The pr im ar y consider ation inv olv es ident ify ing w hich r egions of t he net w or k ar e best suit ed t o be par t of t he back bone. These should be cor e st r at egic locat ions t hat bor der ot her geogr aphic r egions. The layer ed appr oach discussed in Chapt er 7 , " General Net w ork Design I ssues," can be leveraged here. Ot her crit eria t hat m ust be t aken int o considerat ion, include net w ork resources, such as bandw idt h of net w or k links, r out er m em or y, and CPU capacit y. Rem ember t hat link-st at e pr ot ocols hav e t o cr eat e and m aint ain a Link-St at e dat abase, as w ell as t he r out ing t able and m ight r equir e m or e m em or y t han a dist ance vect or pr ot ocol w hen deployed in com par able net w orks. Also, t he new backbone needs t o be fully redun dant . This concludes t he discussion of gener al issues t hat need t o be consider ed w hen m igr at ing from a flat classful prot ocol t o I nt egrat ed I S-I S. The next sect ions cover specific consider at ion for m igr at ing fr om RI P.

M igr a t in g fr om RI P t o I n t e gr a t e d I S - I S 238

This sect ion looks at m igrat ing from t he Rout ing I nform at ion Prot ocol ( RI P) t o I nt egrat ed I SI S. Consider

Figure 8 - 7 ,

w hich is a flat RI P net w or k . Fir st , y ou m ust decide w hich r out er s need t o

becom e t he backbone. This is not such a difficult decision given t he cur r ent t opology. Take a look at t he Eur opean r egion: Rout ers RTA1, RTB1, and RTC1 are obvious candidat es for backbone rout ers. I n t he USA region, rout ers RTB2 and RTD2 are t he best candidat es t o be backbone rout ers. Finally, in t he Asian region, rout ers RTC3 and RTD3 are t he obvious choices. Figur e 8 - 7 . Tr a n sfor m in g fr om fla t t o a h ie r a r ch ica l r ou t in g t opology.

The backbone rout ers provide redundant connect ivit y t o ot her regions. Each select ed b ackbone r out er also has r edundant connect ions int o it s ow n r egion. The backbone r out er s w ill cert ainly be excellent point s for rout e sum m arizat ion in t he hierarchical t opology. The Eur opean r egion can be fur t her segm ent ed int o a full t hr ee-layer hierarchy w it h rout ers RTD1, RTE1, RTF1, and RTG1 considered as t he dist ribut ion rout ers, and RTH1 operat ing as an access r out er . Sum m ar izat ion can be applied at t he dist r ibut ion point s, bet w een t he cor e and

239

access layers. The dist ribut ion rout ers are configured as bot h Lev el 1 and Lev el 2, w it h t he core being Level 2 -only and t he access being Level 1 -only. Wit h all t he r out er s assigned r oles —backbone, dist ribut ion, or access —and t heir corresponding I S t ypes defined, preparat ion for t he act ual m igrat ion can begin. The background m igrat ion m et hod w ill be m ost suit able and t he phases used in t he m igr at ion fr om EI GRP can be follow ed. RI P has a w or se default adm inist r at iv e dist ance of 120, and I S-I S has a v alue of 115, so t he I S-I S v alue needs t o be changed t o a w or se v alu e in phase 2. Alt er nat iv ely , t he adm inist r at ive dist ance for RI P can be low er ed t o, for exam ple, 50 t o ensur e t hat t he RI P rout es rem ain prim ary. RI P uses hop count so no special m et r ic assignm ent s need t o be pr epar ed ahead of t im e. However, if specific m e t ric adj ust m ent s have been m ade by applying m et ric offset s t o influence pat h select ion in t he RI P environm ent , appropriat e m et ric adj ust m ent s need t o be m ade t his for w ar d int o I S-I S. A sim ple w or ksheet for m et r ic conver sion fr om t he RI P envir onm ent t o t he I S-I S env ir om ent w ould be r ight fully in place. I n phase 3, t he cut ov er t o I S-I S as prim ary is perform ed by m aking t he I S-I S adm inst rat ive dist ance bet t er, eit her by rem oving t he adm inist rat ive dist ance of 255 from t he I S-I S configur at ion or r em ov ing t he dist ance of 50 fr om RI P if t he alt er nat e appr oach w as used. The cut ov er can t y pically st ar t fr om t he edge t ow ar d t he cor e w it h t he clea r ip rout e * com m and used in each r out er t o r efr esh t he I P r out ing t able. I n phase 4, RI P can be disabled fr om t he net w or k aft er a r easonable level of cer t aint y has been est ablished t hat I S-I S is oper at ing as expect ed and r out ing is fully funct ional. Because RI P is a classful pr ot ocol, t her e m ight hav e been a pot ent ial w ast e of addr esses in t he RI P env ir onm ent w hile assigning cont iguous I P subnet s t o m ake rout ing w ork. I S-I S is m or e flex ible w it h addr ess assignm ent as a classless pr ot ocol and m ight pr esent oppor t unit ies for m or e efficient addr ess assignm ent in t he new net w or k. Any addr ess changes should, how ever , be im plem ent ed aft er t he m igrat ion is com plet ed.

M igr a t in g fr om I GRP t o I n t e gr a t e d I S - I S All t he discussions for m igr at ing fr om RI P ar e applicable t o I GRP because bot h pr ot ocols have sim ilar r out ing funct ionalit y and char act er ist ics, such as classful addr essing and distance vect or rout ing. How ever, a key difference bet w een t hem lies in m et ric definit ion. RI P uses hop count , and I GRP uses a com posit e m et ric based on bandw idt h, delay, reliabilit y, and MTU. Therefore, t he preparat ions for t he m igrat ion from I GRP needs t o in clude planning of m et ric conversion t o provide t he desired pat h select ion w hen I S-I S is m ade pr im ar y ov er I GRP. I n t his scenar io also, t he backgr ound m et hod is m ost suit able for t he m igr at ion. The adm inist rat ive dist ance of I GRP is 100 com pared t o 115 for I S-I S. This m eans t hat I GRP r out es w ould be pr efer r ed ov er I S-I S r out es, and no dist ance adj ust m ent is r equir ed in phase 2. Making I S-I S pr im ar y w ill r equir e apply ing a lar ger dist ance t o I GRP in phase 3.

240

Coexisting with Other IP IGPs I nt egr at ed I S-I S m ight be r equir ed t o coex ist w it h ot her I GPs in som e net w or k s. This can possibly happen dur ing m igr at ion fr om one pr ot ocol t o anot her , such as w hen using t he redist ribut ion m et hod for m igrat ion t o I S-I S. This also happens in t he backgr ound appr oach dur ing t he cut over phase. How ever, t here m ight be pract ical scenarios w here coexist ence m ight be needed for long-t erm norm al operat ion. I n t his sit uat ion, I S-I S m ight be deploy ed in one r egion of t he net w or k and t he ot her pr ot ocol in an adj acent r egion. I n ot her sit uat ions, I SI S m ight be in t he cor e, and anot her less r obust pr ot ocol m ight exist on t he fr inges r unning on r out er s t hat m ight not suppor t I S-I S. When I nt egrat ed I S-I S coexist s w it h anot her I GP on a m or e per m anent basis, m ut ual redist ribut ion is required t o exchange r out es bet w een t he t w o pr ot ocol dom ains. Under t hese circum st ances, t he pot ent ial for rout ing loops because of rout e feedback is high. Therefore, car e m ust be t aken t o ensur e t hat r edist r ibut ion occur s at only car efully select ed point s in t he netw or k , and r out e filt er s m ust also be used t o r educe any pot ent ial for r out e feedback . Adm inist r at ive dist ances m ight have t o be adj ust ed on r out er s t hat r un bot h pr ot ocols t o ensur e pr efer ence of cer t ain r out es fr om a specific pr ot ocol sour ce. As a lin k-stat e prot ocol, I nt egrat ed I S-I S obt ains rout ing inform at ion t hrough LSP exchange, and because each r out er m ust hav e a consist ent v iew of t he t opology based on infor m at ion cont ained in t he LSPs, LSP filt ering is not allow ed. How ever, ext ernal rout es can be filt er ed during redist ribut ion int o t he I S-I S rout ing dom ain. Rout es from I S-I S can also be filt er ed before inclusion in ot her prot ocol environm ent s.

Using IS-IS in Dual Environments As specified in RFC 1195, I nt egrat ed I S-I S support s rout ing in dual enviro nm ent s w it h bot h I SO CLNS and I P services. I nt egrat ed I S-I S can be used t o for w ar d bot h I P and CLNP pack et s sim ult aneously in such environm ent s. This sect ion briefly discusses requirem ent s for using I SI S in such envir om ent s and pot ent ial issues t hat m ight ar ise. A crit ical requirem ent for using I S-I S in a dual env ir onm ent is t o k eep all r out er s in an ar ea consist ent ly configur ed. I n ot her w or ds, each ar ea m ust be configur ed t o sur ppor t eit her I P only or CLNP only, or bot h, and all r out er s in t he ar ea m ust be configured sim ilarly. This is necessar y so t hat all r out er s in t he ar ea can build a consist ent level Link-St at e dat abase and obt ain ident ical view s of t he areas t opology. How ever, an I P-only r out er can connect t o anot her r out er in an ar ea t hat suppor t s bot h I P and CLNP and for m Lev el 2 adj acencies w it h t hat rout er for sharing of I P rout ing inform at ion. Figure 8 - 8

show s a net w or k t opology w it h t hr ee separ at e ar eas. Ar ea 1 suppor t s only I SO CLNP,

and so all r out er s in t his ar ea m ust be configur ed for I S-I S in I SO CLNP m ode only . Ar ea 2 suppor t s bot h I P and I SO CLNP, and so r out er s in t his ar ea m ust oper at e in dual m ode. Ar ea 3 is an I P-only area, and t herefore, all rout ers in t his area m ust be configured for I P only. Also, as show n in t he illust r at ion, t his r equir em ent does not apply t o t he back bone w her e Level 2 r out ing is per for m ed.

241

Figur e 8 - 8 . Using I S- I S in D ua l I P a nd I SO dom a ins.

Som e k ey point s t o not e about using I S-I S for I P and I SO CLNP follow :

•

An adm inist r at ive dist ance of 110 is used for I SO CLNP r out ing and 115 for I P r out ing.

•

CLNP st at ic rout es are aut om at ically redist ribut ed int o I S-I S, while explicit configurat ion is required t o carry I P st at ic rout es int o I S-I S. Also, t he redist ribut e st at ic st at em ent r equir es t he k ey w or d ip for t he I P set up.

•

Enabling I S-I S for I P r out ing aut om at ically enables CNLS r out ing on t he ent ir e r out er . How ev er , r ecent I OS r eleases allow CNLS t o be disabled w hen using I S-I S for only I P r out ing. This can be done w it h t he com m and no clns r out ing.

•

I S-I S r out ing for I P on an int eface is enabled w it h t he int er face lev el I OS com m and ip r out e r isis < t a g> , w her eas clns r out ing is enabled sim ilar ly but w it h t he com m and cln s r ou t e r isis < t a g> .

•

Mak ing an int er face passiv e r em o v es bot h t he ip rout er isis < t ag> an d clns rout er isis < t a g> com m ands fr om t he int er face configur at ion, and no adj acencies ar e for m ed over t hat int er face for I P or CLNP r out ing. How ever , any I P pr efixes configur ed on t he int er face ar e car r ied int o t he r outer's LSP. Because CLNP rout ing is com plet ely disabled on t he int er face, car e m ust be used w hen apply ing t he pa ssive - int erfa ce com m and in dual env ir onm ent s.

Exam ples 8 - 17

and 8 - 18 illust r at e pr oblem s t hat ar ise w hen r out er s in t he sam e ar ea ar e

configured inconsist ent ly.

Case Study 1: Mixing ISO and IP show s a scenar io in w hich a connect ion RTA and RTB is confiigur ed for bot h I P and CLNP rout in g on RTA but enabled for only I P r out ing on RTB. This configur at ion is not allow ed

Exam ple 8 - 1 7

in I OS because accor ding t o RFC 1195, a link bet w een t w o r out er s in t he sam e ar ea m ust be

242

configured ident ically at eit her end. Therefore, no adj acency is form ed bet w een RTA and RTB, as show n in t he show clns neighbors com m and out put . Ex a m ple 8 - 1 7 Sa m e Ar e a Rou t e r s w it h D u a l ( I P a n d CN LP) a n d I P- On ly Con figu r a t ion s

Configuration for RTA ! Int serial0 Ip address 192.168.10.9 255.255.255.252 Ip router isis !

Configuration for RTB ! Int serial1 Ip address 192.168.10.10 255.255.255.252 Ip router isis clns router isis ! RTA#show clns neighbors System ID RTB

Interface Se0

SNPA *HDLC*

State Up

Holdtime 23

Type L1

Protocol ES-IS

Case Study 2: Mixing ISO and IP Exam ple 8 - 1 8

show s a scenar io w her e I S-I S is enabled for CLNP r out ing at one end of t he

connect ion, at RTA, and I P -only r out ing at RTB. This is also not allow ed because bot h rout ers ar e in t he sam e ar ea, so adj acency is not for m ed bet w een RTA and RTB, as show n in t he show clns ne ighbor s ou p u t . Ex a m ple 8 - 1 8 Sa m e Ar e a Rout e r s w it h I P - On ly a n d CLN P- On ly Con figu r a t ion s

Configuration for RTA ! Int serial0 Ip address 192.168.10.9 255.255.255.252 Ip router isis clns router isis !

243

Configuration for RTB ! Int serial1 Ip address 192.168.10.10 255.255.255.252 Ip router isis ! RTA#show clns neighbors System ID RTB

Interface Se0

SNPA *HDLC*

State Init

Holdtime 23

Type L1

Protocol IS-IS

Summary This chapt er pr esent s v ar ious case st udies t o elabor at e on v ar ious net w or k design issues w hen I S-I S is deployed as an I GP. The chapt er st ar t s by r eview ing t w o m igr at ion scenar ios t hat involve m aking changes in exist ing I S-I S configur at ions. The fir st is concer ned w it h m igr at ion of I S-I S ar eas fr om one ar ea I D t o anot her , and t he second deals w it h m igrat ion fr om nar r ow t o w ide m et r ics. Next , I S-I S configur at ions ar e r ev iew ed for point -to-point link s and for NBMA t r anspor t deployed in I SP envir onm ent s. A gr eat am ount of t im e is dedicat ed t o issues r elat ing t o deploying I S-I S in NBMA environm ent s wit h hig hly m eshed PVCs. Com m on configur at ion problem s and solut ions are review ed. The review s indicat e t he best m odel for NBMA links in I S-I S net w or k s is t he point -t o-point m odel in which point -t o-point subint er face is used t o m odel t he virt ual circuit s as point -t o-point links. I S-I S m esh gr oups ar e also suggest ed as a solut ion t o addr ess scaling issues posed by r edundant flooding in highly m eshed envir onm ent s using t he point -to-point m odel. A subst ant ial part of t he chapt er focuses on m igrat ing from ot her I GPs t o I S-I S. Tw o approaches are recom m ended: The Redist ribut ion and Background m et hods. An elaborat e exam ple based on m igr at ion fr om EI GRP is discussed. The w hole pr ocess is also sum m ar ized int o four phases. Migr at ion fr om OSPF is br iefly discussed, and t he Background m et hod em er ged her e also as t he r ecom m ended appr oach. Specific consider at ions for OSPF ar e highlight ed. The four-phase m igr at ion appr oach based on t he Back gr ound m et hod w as also ident ified t o be applicable for m igrat ing from classful prot ocols, such as RI P and I GRP. The final sect ions of t he chapt er w er e focused on t w o im por t ant issues, nam ely coexist ence of I S-I S w it h ot her I P I GPs and using I S-I S in dual envir onm ent s. Tw o case st udies t hat w er e

244

focused on configur at ion issues w hen m ixing I SO CNLS and I P r out ing in Dual dom ains ar e present ed t o reinforce earlier discussions on RFC1195 requirem ent s.

Review Questions

1:

What is t he m ain purpose and use of configuring up t o t hree different area addresses on a single rout er?

2:

What is t he consequence of configuring m ore t han one area address on a single rout er?

3:

What is t he pur pose of t he t ransit ion keyword when used wit h t he m etric- st yle com m and?

4:

How m any t ypes of hello packet s are used on point- t o- point int erfaces on Cisco rout ers?

5:

What is t he pur pose of t he m esh- group blocked com m and?

6:

What is t he default behavior of a m em ber wit hin a m esh group?

7:

What is t he pur pose of t he dist ance com m and?

8:

What precaut ions m ust be t aken when configuring m ut ual redist ribut ion bet ween I nt egrat ed I S- I S and ot her coexist in g I GPs?

9:

What caveat m ust always be adhered t o when running I S- I S for CLNS and I S- I S for I P in t he sam e area?

245

Part III: Configuring and Troubleshooting Integrated IS-IS Part I I I Configuring and Troubleshoot ing I nt egrat ed I S- I S Chapt er 9 Configuring I S- I S for I P Rout ing on Cisco Rout ers Chapt er 10 Troubleshoot ing t he I S- I S Rout ing Prot ocol

246

Chapter 9. Configuring IS-IS for IP Routing on Cisco Routers This chapt er pr ovides guidelines, pr ocedur es, and an over view of configur at ion com m ands for enabling I S-I S on Cisco r out er s. The Cisco im plem ent at ion of t he I S-I S prot ocol provides num erous com m ands for enabling various capabilit ies and opt im izat ion of I S-I S funct ionalit y, som e of w hich ar e infr equent ly used in r eal applicat ions. This chapt er focuses on r elev ant capabilit ies, feat ures, and r elat ed com m ands com m only used by net w or k oper at or s w ho r un I S-I S in t heir net w orks. How ever, w herever possible, som e less -com m on configur at ion t ips ar e highlight ed. For t he com plet e suit e of suppor t ed feat ur es and com m ands, check out t he Cisco I OS con figurat ion m anuals, available at

www.cisco.com .

Not e t hat t his book pr im ar ily focuses on applicat ion of t he I S-I S prot ocol in I P-only envir onm ent s, such as t hose found in I nt er net ser vice pr ovider net w or ks. This focus is cert ainly reflect ed in t his chapt er as can be discerned from t he exam ples and relat ed discussions. This chapt er discusses t he follow ing:

•

Configuring I S-I S on point -t o-point serial links

• •

Configuring I S-I S on br oadcast link s ( t hat is, on a LAN) Configuring I S-I S on nonbroadcast m ult iaccess ( NBMA) m edia - ATM point -to-point - ATM m ult ipoint - Er am e Relay point -t o-point - Fram e Relay m ult ipoint - I SDN m ult ipoint

The follow ing specialized t opics and r elevant configur at ion exam ples ar e cover ed:

•

Con figuring I S-I S capabilit ies - Adv er t ising t he I P default r out e in I S-I S - Redist ribut ion - I P r out e sum m ar izat ion - Secondary addresses, unnum bered int erfaces, and t unneling configurat ions

247

•

Aut hent icat ion

•

Dom ain -w ide pr efix dist r ibut ion ( Level 2 t o Level 1 r out e leak ing)

• •

I S-I S m ult i-ar ea configur at ion Configuring I S-I S for opt im ized perform ance

The follow ing t w o basic st eps are required t o enable I S-I S r out ing on Cisco r out er s r unning appr opr iat e Cisco I OS r eleases t hat suppor t I S-I S:

•

Configur e t he r out ing process.

•

Apply I S-I S r out ing t o r elev ant int er faces.

The Cisco I OS configurat ion com m and rout er isis [ t ag] enables t he I S-I S r out ing pr ocess. The t ag is an opt ional keyw or d for labeling t he r out ing pr ocess, and it has only local significance in recent versions of I OS. This m eans t hat it doesn't hav e t o be consist ent acr oss all r out er s. Most ser vice pr ovider s use t he sam e t ag on all r out er s in t heir dom ain for consist ency. Be aw ar e t hat in som e older ver sions of I S-I S, rout ers m ight be unable t o form adj acencies w hen t he t ags ar e m ism at ched. Adding an NSAP addr ess in t he r out er configur at ion level com plet es basic configur at ion for t he r out ing pr ocess. The com m and clns rout ing is aut om at ically added t o t he configurat ion upon act ivat ionof t he rout ing process. However , r ecent changes in I OS ( for exam ple, 12.0S and 12.0ST r elease t r ains) m ake t his com m and r elevant only in envir onm ent s w her e I SO CLNP for w ar ding is r equir ed. For pur e I P envir onm ent s, CLNP for w ar ding is not r equir ed, and t he ent r y can be rem oved using t he negat ion com m and, no clns r out ing. When basic I S-I S r out ing is enabled, a Cisco r out er funct ions as bot h a Lev el 1 and Lev el 2 rout er unless eit her Level 1 or Level 2 m ode of operat ion is m anually disabled. The I OS r ou t er-level com m and no is- t ype < level- 1 | le ve l- 2 - o n ly > disables Lev el 1 or Lev el 2 r out ing on all int er faces. The nex t st ep aft er configur ing t he r out ing pr ocess is t o enable I S-I S r out ing on t he int er faces of int er est w it h t he com m and ip rout er isis [ t ag] . As indicat ed pr eviously, CLNP r out ing is enabled by default w hen t he I S-I S pr ocess is act ivat ed. I f t he r out er has t o oper at e in dual m ode, rout ing bot h I P and CLNP, t he int erface -level com m and clns rout er [ t ag] needs t o be configur ed. I f only I P r out ing suppor t is r equir ed, t he ip rout er [ t ag] com m and is sufficient and t he CLNP r out ing m ight be disabled globally, as explained ear lier . The int er face com m and [ no] isis circuit t ype < level- 1 | le ve l- 2 > can be used t o specify t he desir ed level of r out ing ( Level 1 or Level 2) depending on t he g lobal configurat ion at t he rout er level. I t is int er est ing t o not e t hat in t he I S-I S confiur at ion, no I P net w or k st at em ent s ar e used as in t he case of ot her I P r out ing pr ot ocols. The I P subnet s on I S-I S enabled int er faces ar e aut om at ically placed in t he I P reachabilit y TLVs used in LSPs, w hich are t hen flooded t o adj acent neighbor s.

248

Point-to-Point Serial-Link Configuration The I S-I S configur at ion for point -to-point links is t he m ost com m only used in real net w orks, for point -t o-point ser ial int er faces, as w ell as t o NBMA point -t o-point subint er faces. The point t o-point configurat ion lends it self t o various advant ages because it provides congruency t o t he under lying physical t opology.

Figures 9 - 1

and 9 - 2 depict a sim ple point -to-point set up of t w o

r out er s ( RT1 and RT2) connect ed dir ect ly by a ser ial link . The r out er s ar e in t he sam e I S-I S ar ea in

Figure 9 - 1

but in differ ent ar eas in Figure 9 - 2 .

Figur e 9 - 1 . I S- I S point- to- poin t con figu r a t ion ( r ou t e r s in sa m e a r e a ) .

Figur e 9 - 2 . I S- I S point- to- poin t con figu r a t ion ( r ou t e r s in diffe r e n t a r e a s) .

249

Also show n ar e r elev ant ex cer pt s of t he I S-I S configur at ions on t he r out er s. I n Figure 9 - 1 , bot h r out er s ar e in t he sam e ar ea and so shar e a com m on ar ea pr efix ( 49.0001) . Ther efor e, according t o t he default I OS behavior, t hey w ill est ablish Level 1 and Level 2 adj acencies. I n cont r ast , how ever , t he r out er s in Figure 9 - 2 ar e in differ ent ar eas, so t hey w ill for m only a Lev el 2 adj acency. The follow ing com m ands ar e useful for ver ifying pr oper configur at ion and oper at ion of I S-I S on Cisco r out er s:

•

show clns pr ot ocol— Pr ov ides a sum m ar y of t he pr ot ocol st at e on t he r out er ( see Exam ple 9 - 1 )

•

show clns ne ighbor s [ de t a il] — Show s adj acency st at e inform at ion about known neighbors ( see Exam ple 9 - 2 )

•

show clns int e r fa ce — Show s I S-I S r out ing infor m at ion per t aining t o an int er face ( see Exam ple 9 - 3 )

•

show isis t opology — Show s pat h infor m at ion for I S-I S nodes in t he Lev el 1 and Lev el 2 t opology ( see Exam ple 9 - 4 )

•

show isis da t a ba se — Display s k now n LSPs in t he lev el-1 and lev el-2 dat abases( see Exam ple 9 - 5 )

Exam ples 9 - 1 Figure 9 - 2 .

t hrough 9 - 5 show out put s of t hese com m ands capt ur ed fr om t he r out er s set up in

Each exam ple feat ures an out put from each rout er t o show t he st at eof eit her side of

t he connect ion. Because t he set up is basic, m ost of t he out put is self-explanat ory. Som e

250

infor m at ion is pr ov ided on t he show isis da t a ba se out put in Table 9 - 1 . More inform at ion is pr ov ided on t he ot her com m ands in Chapt er 10 , " Troubleshoot ing t he I S-I S Rout ing Prot ocol." Ex a m ple 9 - 1 sh ow clns pr ot ocol Ou t p u t

RT1#show clns protocol IS-IS Router: System Id: 0000.0000.0001.00 IS-Type: level-1-2 Manual area address(es): 49.0001 Routing for area address(es): 49.0001 Interfaces supported by IS-IS: Loopback0 - IP Serial0/0 - IP Redistributing: static Distance: 110 RRR level: none Generate narrow metrics: level-1-2 Accept narrow metrics: level-1-2 Generate wide metrics: none Accept wide metrics: none RT2#show clns protocol IS-IS Router: System Id: 0000.0000.0002.00 IS-Type: level-1-2 Manual area address(es): 49.0002 Routing for area address(es): 49.0002 Interfaces supported by IS-IS: Loopback0 - IP Serial0/0 - IP Redistributing: static Distance: 110 RRR level: none Generate narrow metrics: level-1-2 Accept narrow metrics: level-1-2 Generate wide metrics: none Accept wide metrics: none Ex a m ple 9 - 2 show clns ne ighbor s de t a il Com m a n d Ou t p u t

RT1#show clns neighbors detail System Id

Interface

SNPA

State

RT2 Se0/0 *HDLC* Area Address(es): 49.0002 IP Address(es): 192.168.1.2* Uptime: 00:48:46 RT2#show clns neighbors detail System Id Interface SNPA RT1 Se0/0 *HDLC* Area` Address(es): 49.0001 IP Address(es): 192.168.1.1* Uptime: 00:52:14

Holdtime Up

State Up

Type 27

Protocol L2

Holdtime 26

IS-IS

Type Protocol L2 IS-IS

251

Ex a m ple 9 - 3 sh ow cln s in t e r fa ce Com m a n d Ou t pu t

RT1#show clns interface ser 0/0 Serial0/0 is up, line protocol is up Checksums enabled, MTU 1500, Encapsulation HDLC ERPDUs enabled, min. interval 10 msec. RDPDUs enabled, min. interval 100 msec., Addr Mask enabled Congestion Experienced bit set at 4 packets CLNS fast switching enabled CLNS SSE switching disabled DEC compatibility mode OFF for this interface Next ESH/ISH in 3 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x0, local circuit ID 0x100 Level-1 Metric: 10, Priority: 64, Circuit ID: RT1.00 Number of active level-1 adjacencies: 0 Level-2 Metric: 10, Priority: 64, Circuit ID: RT1.00 Number of active level-2 adjacencies: 1 Next IS-IS Hello in 8 seconds RT2#show clns interface serial0/0 Serial0/0 is up, line protocol is up Checksums enabled, MTU 1500, Encapsulation HDLC ERPDUs enabled, min. interval 10 msec. RDPDUs enabled, min. interval 100 msec., Addr Mask enabled Congestion Experienced bit set at 4 packets clns fast switching enabled clns SSE switching disabled DEC compatibility mode OFF for this interface Next ESH/ISH in 8 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x0, local circuit ID 0x100 Level-1 Metric: 10, Priority: 64, Circuit ID: RT2.00 Number of active level-1 adjacencies: 0 Level-2 Metric: 10, Priority: 64, Circuit ID: RT2.00 Number of active level-2 adjacencies: 1 Next IS-IS Hello in 2 seconds Ex a m ple 9 - 4 sh ow isis t opology Com m a n d Ou t pu t

RT1#show isis top IS-IS paths to level-1 routers System Id Metric Next-Hop RT1 --

Interface

SNPA

Interface

SNPA

Se0/0

*HDLC*

RT2#show isis topology IS-IS paths to level-1 routers System Id Metric Next-Hop RT2 --

Interface

SNPA

IS-IS paths to level-2 routers System Id Metric Next-Hop RT1 10 RT1 RT2 --

Interface Se0/0

SNPA

IS-IS paths to level-2 routers System Id Metric Next-Hop RT1 -RT2 10 RT2

*HDLC*

252

Ex a m ple 9 - 5 show isis da t a ba se Com m a n d Ou t p u t

RT1#show isis database IS-IS Level-1 Link State Database LSPID LSP Seq Num RT1.00-00 * 0x00000008 RT1.01-00 * 0x00000001

LSP Checksum 0x8B75 0x459B

LSP Holdtime 1126 1131

ATT/P/OL 1/0/0 0/0/0

IS-IS Level-2 Link State Database LSPID LSP Seq Num RT1.00-00 * 0x0000008A RT2.00-00 0x0000001E

LSP Checksum 0x8FED 0xB82C

LSP Holdtime 1126 998

ATT/P/OL 0/0/0 0/0/0

RT2#show isis database IS-IS Level-1 Link State Database LSPID LSP Seq Num RT2.00-00 * 0x00000019 RT2.01-00 * 0x0000000D

LSP Checksum 0x3DAB 0x339F

LSP Holdtime 883 980

ATT/P/OL 1/0/0 0/0/0

IS-IS Level-2 Link State Database LSPID LSP Seq Num LSP Checksum RT1.00-00 0x0000008A 0x8FED RT2.00-00 * 0x0000001E 0xB82C

LSP Holdtime 931 808

ATT/P/OL 0/0/0 0/0/0

Table 9 - 1

descr ibes t he fields in t he show isis da t a ba se com m and out put show n in Exam ple 9 - 5 .

Table 9 - 1 . Ex pla na t ion of t he Fie lds in t he show isis da t a ba se Com m a nds

At t ribut e * LSPI D LSP Seq Num ber LSP Checksum LSP Holdt im e ATT P OL

Com m ent s I ndicat es LSP is originat ed by t he local syst em . LSP ident ifier. Colum n list s all known Level 1 and Level 2 LSPs. LSP sequence num ber for t racking t he current version of LSP. Check sum calculat ed at LSP origin. I f it changes during st orage or flooding, t he LSP is corrupt ed and needs t o be purged from t he net work. Tim e t o expir at ion of LSP in seconds. At t ached bit . Set in Level 1 LSP by Level 2 rout ers t o help Level 1 int erarea t raffic. Part it ion bit . I ndicat es t hat t he rout er support s part it ion repair. Overload bit . When set , it indicat es resource problem s, and t he originat ing rout er should not be used in t ransit pat hs. Can be m anually set for adm inist rat ive reasons in I OS wit h se t- overloa d- bit com m and.

253

Configuring IS-IS on Broadcast Multiaccess Links Even t hough I S-I S oper at ion on br oadcast link s differ s a lit t le fr om I S-I S oper at ion on point t o-point links, t he basic configur at ion is not significant ly different . Wit h broadcast links, you also act iv at e t he I S-I S r out ing pr ocess and t hen enable I S-I S r out ing on t he int er faces w her e adj acencies are t o be form ed. I n t he LAN configurat ion exam ple show n Figure 9 - 3 , t hree rout ers ( RT1, RT2, and RT3) are int erconnect ed over an Et hernet link. All rout ers are in t he sam e ar ea. Figur e 9 - 3 . Et h e r n e t LAN con figu r a t ion e x a m ple .

A significant differ ence bet w een a point -to-point scenar io and t his ex am ple is t hat , in t his case, one of t he rout ers is elect ed t o be t he designat ed int erm ediat e syst em ( DI S) t o sim plify dat abase synchronizat ion over t he broadcast m edium . The DI S effect ively em ulat es t he LAN as a pseudonode and uses an I D based on it s sy st em I D t o r epr es ent t he pseudonode. The pseudonode I D is also used by all r out er s connect ed t o t he LAN ( including t he DI S) as t heir circuit I D. The circuit I D associat es an I S-I S int er face w it h a link , and it is show n in t he show clns int e r fa ce out put for t he r espect iv e int er face.

Configuring IS-IS on NBMA Media This sect ion review s configurat ion exam ples for popular nonbroadcast m ult iaccess m edia ( NBMA) , such as Asynchronous Transfer Mode ( ATM) , Fram e Relay ( FR) , and I nt egrat ed Dat a Services Net work ( I SDN) . I S-I S t r eat s this m edia as br oadcast m edia w hen t hey ar e configured as m ult ipoint . This assum es t hat devices connect ed t o such m edia are fully m eshed w it h each ot her , w hich m ight not be alw ay s t he case. When r out er s connect ing t o NBMA m edia are not fully m eshed, rout ing m ight not w or k w ell because sy nchr onizat ion of t he LS dat abase m ight be flaw ed. I n such cases, it is necessary t o ensure t hat t he DI S is connect ed t o every

254

node on t he NBMA cloud, so t hat t he per iodic Com plet e Sequence Num ber Packet s ( CSNP) sen t ou t by t he DI S r eaches ev er y r out er . The Cisco I OS Soft w are offers an alt ernat ive for m ult ipoint NBMA configurat ion. The opt ion is k now n as point -to-point and allow s t he logical connect ions under lying such m edia ( per m anent vir t ual cir cuit s, PVCs) t o be m odeled as point -to-point links. The point -t o-point NBMA links sim plify t he NBMA t opology for operat ion of rout ing prot ocols, by reflect ing act ual connect ivit y bet w een net w or k devices. For highly m eshed NMBA clouds w it h point -to-point set ups, t he I S-I S m esh gr oup featu r e provides a m eans t o reduce redundant flooding. I S-I S m esh gr oups ar e discussed in Chapt er 5, " The I S- I S Link- State Database,"

in t he sect ion, " Flooding over NBMA Transport Media ."

The follow ing subsect ions feat ur e configur at ion exam ples for ATM, FR, and I SDN. Bot h point t o-point and m ult ipoint configurat ion exam ples are provided fo r ATM and FR.

ATM Configuration The ATM point -to-point configurat ion procedure for I S-I S is sim ilar t o t he serial point -t o-point exam ple discussed earlier. Figure 9 - 4 show s an ATM point -to-point ex am ple. Figur e 9 - 4 . ATM point- to- point e x a m ple .

I f t he ATM cloud is highly m eshed w it h lot s of PVC int er connect ions, an I S-I S m esh gr oup configurat ion needs t o be used t o reduce t he incidence of undesirable redundant flooding. Redundant flooding w ast es net w or k resources and can im pact perform ance. The I S-I S m esh gr oup feat ur e is cov er ed in Chat per 5 and also in Chapter 8 , " Net work Design Scenarios." The

255

m ult ipoint ex am ple show n in Figure 9 - 5 requires I P and CLNS m ap st at em ent s in t he ATM m aplist configur at ion sect ion. Figur e 9 - 5 . ATM m ult ipoint e x a m ple .

Frame Relay Configuration Just as in t he case of ATM, FR set ups can be configured in point -t o-point or m ult ipoint m odes. The I S-I S point -to-point configur at ion ( see Figure 9 - 6 ) is sim ilar t o t he ser ial point -to-point exam ple w it h t he obvious difference being t he subint erface configurat ion and t he FR m ap st at em ent . Figur e 9 - 6 . Fr a m e Re la y poin t- to- point e x a m ple .

256

Figure 9 - 7

show s an FR m ult ipoint configurat ion exam ple. The point -t o-point configurat ion is

recom m ended over t he m ult ipoint configurat ion because it is m aps t he Layer 3 layout of t he net work t o t he underlying Layer 2 infras t r uct ur e w it h a clear indicat ion of w hich r out er s hav e PVCs bet w een t hem . This helps avoid pr oblem s w it h r out ing over a nonfully m eshed m ult ipoint clou d. Figur e 9 - 7 . Fr a m e Re la y m u lt ipoin t e x a m ple .

Sim ilar t o t he case of ATM, t he I S-I S m esh group feat ure m ust alw ays be considered for highly m eshed FR env ir onm ent s w it h point -to-point configurat ions. This helps lim it unnecessary flooding of LSPs.

ISDN Configuration show s a t ypical m ult ipoint I SDN configurat ion, w hich follow s t he generic m ult ipoint appr oach discussed w it h r egar d t o ATM and FR. The k ey differ ences in all t hr ee cases lie in t he Figure 9 - 8

Layer 2 configurat ion specifics for each t echnology.

257

Figur e 9 - 8 . I SD N e x a m ple .

Configuring IS-IS Capabilities The Cisco im plem ent at ion of I S-I S pr ovides num er ous configur at ion opt ions for enabling v ar ious I S-I S capabilit ies and m odifying prot oco l par am et er s bot h globally and on a perint er face basis. This sect ion pr esent s som e of t hese configur at ion opt ions, such as adver t ising default r out es, r out e sum m ar izat ion, and enabling aut hent icat ion. Rout e leaking and I S-I S m ult i-ar ea suppor t ar e feat ur e s recent ly int roduced int o t he Cisco I S-I S im plem ent at ion. The essence of t hese feat ur es and basic configur at ions ar e discussed br iefly. For a cur r ent and m or e com plet e list of I S-I S configur at ion opt ions av ailable in t he Cisco I OS Soft w ar e, see t he Cisco Configurat ion Guide at

www.cisco.com .

Advertising the IP Default Route in IS-IS I n t he or iginal pr ot ocol design of I S-I S, Lev el 1 ar eas ar e st ubs and Lev el 1 -only r out er s aut om at ically inst all a default route t o t he nearest Level 1 -2 rout er in t he area. Level 1 -2 rout ers set t he ATT bit in t he Level 1 LSPs t hey advert ise int o t heir nat ive areas. TheATT-bit set t ing in LSPs provide a clue t o Level 1 -only r out er s about Lev el 2 -capable rout ers in t he ar ea. The Le vel 2 rout ers connect ed t o t he I S-I S back bone ar e ex pect ed t o k now about all r out es in t he I S-I S dom ain and do not set any aut om at ic default s. To adv er t ise a default r out e int o t he

258

I S-I S back bone r equir es t he r out er-level default - infor m a t ion or igina t e com m and. When configur ed on a r out er , t he com m and inser t s t he I P pr efix 0.0.0.0/ 0 as t he default r out e int o it s Level 2 LSP t ar get ed at t he ot her Level 2 r out er s in t he dom ain. The default is adver t ised int o t he backbone, w het her t he r out er has pr ior or no know ledge of a default r out e fr om anot her sour ce. Exam ple 9 - 6 ,

w hich is based on Figure 9 - 9 , show s t he configur at ion and applicat ion of t he default -

infor m a t ion or igina t e com m and. Not ice t he default ent r y in t he out put of t he show isis dat abase com m and in Exam ple 9 - 6 . Figur e 9 - 9 . D ia gr a m for

Exam ple 9 - 6 .

Ex a m ple 9 - 6 Th e de fa ult - inform a t ion origina t e Co m m a n d

RT1# show running-config [snip] Hostname RT1 ! router isis default-information originate net 49.0001.0000.0000.0001.00 [snip] RT2#show isis database detail RT1.00-00 IS-IS Level-2 LSP RT1.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL RT1.00-00 0x000000E1 0x7A1E 651 Area Address: 49.0001 NLPID: 0xCC Hostname: RT1 IP Address: 10.1.1.1 Metric: 10 IS RT1.01 Metric: 10 IS RT2.00 Metric: 0 IP 0.0.0.0 0.0.0.0 Metric: 10 IP 10.1.1.1 255.255.255.255 Metric: 10 IP 192.168.1.0 255.255.255.252

0/0/0

Redistribution Cisco I OS Soft w are allow s I P rout es from ot her rout ing sources t o be im port ed int o I S-I S. Exam ples of t he ext erna l sources are st at ic rout es, t he Rout ing I nform at ion Prot ocol ( RI P) ,

259

and t he Open Shor t est Pat h Fir st Pr ot ocol ( OSPF) . The I P ext er nal r eachabilit y TLV is used for adding ext er nal r out es int o t he I S-I S dom ain. Even t hough RFC 1195 specifies t he I P ext er nal r eachabilit y for only Level 2 LSPs, Cisco I OS Soft w ar e pr ovides a special capabilit y for using t hem in Lev el 1 LSPs, w hich allow s ex t er nal r out es int o a Lev el 1 ar ea. Most ser vice pr ovider net w or ks use I S-I S as t he I GP in large single -area Level 1 -on ly or Level 2 -only dom ains. For t hose w it h Level 1 -only backbones, t he capabilit y t o redist ribut e int o Level 1 provides flexibilit y t o im port ext ernal rout es int o t he I S-I S dom ain. Ev en t hough t his behavior is not st andar dized, it should not pose int er oper abilit y issues w it h ot her v endor r out er s because bot h ex ist ing I S-I S st andards, I SO 10589 and RFC 1195, require I S-I S im plem ent at ions t o ignore unsupport ed or unknow n opt ional TLVs encount ered w hile parsing I S-I S pack et s. The I OS r out er-level com m and redist ribu te enables r edist r ibut ion. This com m and t akes on ot her opt ions, such as m et r ic v alue, m et r ic t y pe, r out e m ap, and so on. I n t he Cisco im plem ent at ion of I S-I S, CLNS st at ic r out es ar e aut om at ically dist r ibut ed int o I S-I S. However, I P st at ic rout es are redist ribut ed only by m anual configurat ion. When st at ic I P r out es need t o be r edist r ibut ed, t he redistribute com m and r equir es t he k ey w or d ip t o go w it h it , in addit ion t o t he ot her ar gum ent s pr ev iously m ent ioned. The m et r ic t y pe for ex t er nal r out es can be eit her int ernal or ext ernal. I nt ernal m et rics are com parable t o m et rics used for int ernal rout es. Ext ernal m et rics require t he I / E bit ( bit 7) of t he m et ric field t o be set in addit ion t o t he act ual m et r ic, r esult ing in higher m et r ic v alues. I n cur r ent Cisco I OS Soft w ar e r eleases, w hen using nar r ow m et r ics, bit 8 of t he default m et r ic field is set for ext er nal m et r ics, r esult ing in an incr ease of t he m et r ic value by 128. By default , t he int er nal m et r ic t ype is assigned if not hing is specified in t he configur at ion. Also, t he ext ernal rout es are added int o Level 2 unless Level 1 is explicit ly st at ed in t he configurat ion.

Figure 9 - 10

illust r at es basic exam ples of r edist r ibut ion in I S-I S. I n

Exam ple 9 - 7 ,

only

t he ip k ey w or d is used w it h t he redist ribut e com m and. Figur e 9 - 1 0 . N e t w or k t opology for I S- I S r ou t e r e dist r ibu t ion e x a m ple s.

Ex a m ple 9 - 7 Configur ing Ba sic Rout e Re dist r ibut ion in I S- I S

RT1#conf t Enter configuration commands, one per line. RT1(config)#router isis

End with CNTL/Z.

260

RT1(config-router)#redistribute static ip RT1(config-router)#^Z RT1#show running-config [snip] router isis redistribute static ip metric 0 metric-type internal level-2 net 49.0001.0000.0000.0001.00 ! ip route 172.16.1.0 255.255.255.0 Null0 [snip] The follow ing out put fr om RT1 ( see Exam ple 9 - 8 ) displays t he cont ent s of it s ow n Level 1 and Lev el 2 LSPs. I n Exam ple 9 - 7 , not e t hat int ernal m et r ic t y pe has been assigned by default and t he m et r ic applied is 0.

Exam ple 9 - 8

show s t hat t he ex t er nal st at ic r out e has been added t o only t he

Lev el 2 LSP. Ex a m ple 9 - 8 LSP Cont e nt s in Ca se of Sim ple Re dist r ibut ion

RT1#show isis database RT1.00-00 detail IS-IS Level-1 LSP RT1.00-00 LSPID LSP Seq Num RT1.00-00 * 0x00000DB0 1/0/0

LSP Checksum 0xEB25

LSP Holdtime 979

Area Address: 49.0001 NLPID: 0xCC Hostname: RT1 IP Address: 10.0.0.1 Metric: 10 IP 10.1.1.0 255.255.255.0 Metric: 10 IP 10.0.0.1 255.255.255.255 Metric: 10 IP 192.168.1.0 255.255.255.252 Metric: 10 IS RT1.02 Metric: 10 IS RT1.01 Metric: 0 ES RT1 IS-IS Level-2 LSP RT1.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime RT1.00-00 * 0x00000E3D 0x6F45 977 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: RT1 IP Address: 10.0.0.1 Metric: 10 IS RT1.02 Metric: 10 IS RT1.01 Metric: 10 IS RT2.00 Metric: 0 IP-External 172.16.1.0 255.255.255.0 Metric: 10 IP 10.1.1.0 255.255.255.0 Metric: 10 IP 10.0.0.1 255.255.255.255 Metric: 10 IP 192.168.1.0 255.255.255.252

ATT/P/OL

ATT/P/OL

I n Exam ple 9 - 9 , t he m et ric t ype is explicit ly set t o ext er nal in t he configur at ion, but no m et r ic value is applied. As explained pr eviously, t he I / E bit needs t o t hen be set for t he ext er nal m et ric t ype, effect ively increasing t he m et ric value by 64. How ever, Cisco I OS Soft w are set s bit 8 of t he narro w m et r ic inst ead of bit 7, consequent ly adding 128 inst ead t o t he or iginal

261

value of 0. The Level 2 LSP displayed in Exam ple 9 - 9 show s 128 as t he m et r ic v alue for t he ext ernal rout e, 172.16.1.0/ 24. Ex a m ple 9 - 9 Con figu r in g Re dist r ibu t ion w it h Ex t e r n a l M e t r ics

RT1#conf t Enter configuration commands, one per line. End with CNTL/Z. RT1(config)#router isis RT1(config-router)#redistribute static ip metric-type external RT1(config-router)#^Z RT1#show running-config [snip] router isis redistribute static ip metric 0 metric-type external level-2 net 49.0001.0000.0000.0001.00 ! ip route 172.16.1.0 255.255.255.0 null 0 [snip] RT1#show isis database level-2 RT1.00-00 detail IS-IS Level-2 LSP RT1.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime RT1.00-00 * 0x00000E44 0x7FAD 703 Area Address: 49.0001 NLPID: 0xCC Hostname: RT1 IP Address: 10.0.0.1 Metric: 10 IS RT1.02 Metric: 10 IS RT1.01 Metric: 10 IS RT2.00 Metric: 128 IP-External 172.16.1.0 255.255.255.0 Metric: 10 IP 10.1.1.0 255.255.255.0 Metric: 10 IP 10.0.0.1 255.255.255.255 Metric: 10 IP 192.168.1.0 255.255.255.252

ATT/P/OL 0/0/0

The I P r out ing t able out put fr om RT2 show s t he ext er nal r out e, 172.16.1.0/ 24, w hich w as redis t r ibut ed fr om a st at ic sour ce int o I S-I S on r out er RT1 ( see Exam ple 9 - 1 0 ) . The m et ric ent ered for t his rout e, 138, is t he t ot al of t he m et ric on t he out going int erface from RT2t o RT1 ( 10) plus t he m et ric of 128 advert ised by RT1. Ot her rout es received from RT1 ( 10.0.0.1/ 32 and 10.1.1.0/ 24) are regist ered w it h a m et r ic of 20 ( 10 adv er t ised by RT1 and addit ional 10 for t he m et ric from RT2 t o RT1) . Ex a m ple 9 - 1 0 Re pr e se nt a t ion of Ex t e r na l I S- I S Rout e s in t he I P Rout ing Ta ble

RT2#show ip route 172.16.0.0/24 is subnetted, 2 subnets i L2 172.16.1.0 [115/138] via 192.168.1.1, Serial0/0 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.0.0.2/32 is directly connected, Loopback0 i L2 10.1.1.0/24 [115/20] via 192.168.1.1, Serial0/0 C 10.2.2.0/24 is directly connected, Ethernet0/0 i L2 10.0.0.1/32 [115/20] via 192.168.1.1, Serial0/0 192.168.1.0/30 is subnetted, 1 subnets C 192.168.1.0 is directly connected, Serial0/0

262

Th e route - m ap opt ion of t he redist ribut e com m and pr ovides m or e flexibilit y for configur ing redist ribut ion, such as select ive im por t at ion of ext er nal r out es int o t he I S-I S envir onm ent , applying special t ags, and even set t ing t he m et r ic of r edist r ibut ed r out es. When used for select ive im port at ion of rout es int o I S-I S, r out e m aps pr ovide a filt er ing effect by cont rolling w hich elem ent s fr om an ex t er nal sour ce ar e allow ed or denied int o I S-I S. 11b

Exam ples 9 - 11a

and 9 -

show redist ribut ion w it h rout e m aps. I n t he first exam ple, st at ic rout es are redist ribut ed

int o I S-I S w hile filt er ing t hr ough t he r out e m ap TEST. Rout e m ap TEST m at ches t he st at ic r out es against access list 1, w hich per m it s only 172.16.2.0/ 24 int o t he I S-I S envir onm ent . RT1's LSP is show n fr om RT2. Also show n is t he r out ing t able of RT2. In

Exam ple 9 - 1 1 b,

t he rout e m ap approach is used t o set t he m et ric for rout es im port ed int o I S-

I S. Ex a m ple 9 - 1 1 a Using Rout e M a ps t o Filt e r Ex t e r na l Rout e s

RT1#show running-config ! router isis redistribute static ip metric 0 route-map TEST metric-type external level2 net 49.0001.0000.0000.0001.00 ! ip route 172.16.1.0 255.255.255.0 Null0 ip route 172.16.2.0 255.255.255.0 Null0 ! access-list 1 permit 172.16.2.0 ! route-map TEST permit 10 match ip address 1 RT2#show isis database level-2 RT1.00-00 detail IS-IS Level-2 LSP RT1.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime RT1.00-00 0x00000E62 0x8588 1026 Area Address: 49.0001 NLPID: 0xCC Hostname: RT1 IP Address: 10.0.0.1 Metric: 10 IS RT1.02 Metric: 10 IS RT1.01 Metric: 10 IS RT2.00 Metric: 128 IP-External 172.16.2.0 255.255.255.0 Metric: 10 IP 10.1.1.0 255.255.255.0 Metric: 10 IP 10.0.0.1 255.255.255.255 Metric: 10 IP 192.168.1.0 255.255.255.252

ATT/P/OL 0/0/0

RT2#show ip route 172.16.0.0/24 is subnetted, 1 subnets i L2 172.16.2.0 [115/138] via 192.168.1.1, Serial0/0 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.0.0.2/32 is directly connected, Loopback0 i L2 10.1.1.0/24 [115/20] via 192.168.1.1, Serial0/0 C 10.2.2.0/24 is directly connected, Ethernet0/0 i L2 10.0.0.1/32 [115/20] via 192.168.1.1, Serial0/0

263

C

192.168.1.0/30 is subnetted, 1 subnets 192.168.1.0 is directly connected, Serial0/0

Ex a m ple 9 - 1 1 b Se t t in g t h e M e t r ic w it h a Rou t e M a p

RT1# show running-config ! router isis redistribute static ip route-map SETMETRIC net 49.0001.0000.0000.0001.00 is-type level-1 metric-style wide ! route-map SETMETRIC permit 10 set metric 1000 set level level-1 RT1#show isis database detail RT1.00-00 level-1 IS-IS Level-1 LSP RT1.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime RT1.00-00 * 0x00000E56 0x0A4C 1128 0/0/0 Area Address: 49 NLPID: 0xCC Hostname: RT1 IP Address: 10.0.0.1 Metric: 10 IS-Extended RT1.02 Metric: 10 IS-Extended RT1.01 Metric: 10 IS-Extended RT2.00 Metric: 1000 IP 10.1.1.0 255.255.255.0 Metric: 1000 IP 10.0.0.1 255.255.255.255 Metric: 1000 IP 192.168.1.0 255.255.255.252

ATT/P/OL

IP Route Summarization An I S-I S r out er can be configur ed t o sum m ar ize I P r out es int o Level 1, Lev el 2, or bot h, at t he sam e t im e, w it h t he follow ing r out er-level configurat ion com m and: sum m a ry- a ddr e ss < prefix > [ level- 1 | le ve l- 2 | le ve l- 1 - 2 ] . By default , sum m ar ies go int o Level 2 if no r out ing lev el opt ion is indicat ed. An illust r at ion of how summ arizat ion is configured and it s operat ion is pr ov ided by t he ser ies of out put s show n in Exam ple 9 - 1 3 , w hich is based on Figure 9 - 1 1 . The set of out put s in Exam ple 9 - 1 2 depict t he scenar io w her e sum m ar izat ion is not configur ed y et on RT1, w hich has t hree int erfaces: loopba ck 0 , Et h e r n e t 0 / 0 , an d Se r ia l0 / 0 . Exam ple 9 - 12 shows t he LSP for RT1 as capt ur ed on RT2 and t he r out ing t able on RT2. The r out e of int er est , 11.1.1.0/ 24, is not sum m arized here; however, it is sum m arized in Exam ple 9 - 1 3 int o 11.1.0.0/ 16.

264

Figur e 9 - 1 1 . N e t w or k dia gr a m for su m m a r iza t ion e x a m ple .

Ex a m ple 9 - 1 2 I S- I S Configur a t ion W it hout Sum m a r iza t ion

RT1#show running-config interface loopback 0 ip address 10.0.0.1 255.255.255.255 ip router isis ! interface Ethernet0/0 ip address 11.1.1.1 255.255.255.0 ip router isis ! interface Serial0/0 ip address 192.168.1.1 255.255.255.252 ip router isis router isis net 49.0001.0000.0000.0001.00 RT2#show isis database level-2 RT1.00-00 IS-IS Level-2 LSP RT1.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime RT1.00-00 0x00000E62 0x8588 1026 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: RT1 IP Address: 10.0.0.1 Metric: 10 IS RT1.02 Metric: 10 IS RT1.01 Metric: 10 IS RT2.00 Metric: 10 IP 11.1.1.0 255.255.255.0 Metric: 10 IP 10.0.0.1 255.255.255.255 Metric: 10 IP 192.168.1.0 255.255.255.252

ATT/P/OL

RT2#show ip route 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks C 10.0.0.2/32 is directly connected, Loopback0 C 10.2.2.0/24 is directly connected, Ethernet0/0 i L2 10.0.0.1/32 [115/20] via 192.168.1.1, Serial0/0 11.0.0.0/24 is subnetted, 1 subnets i L2 11.1.1.0 [115/20] via 192.168.1.1, Serial0/0 192.168.1.0/30 is subnetted, 1 subnets C 192.168.1.0 is directly connected, Serial0/0 Ex a m ple 9 - 1 3 I S- I S Configur a t ion w it h Sum m a r iza t ion

265

RT1#show running-config ! router isis summary-address 11.1.0.0 255.255.0.0 net 49.0001.0000.0000.0001.00 RT2#show isis dat l2 RT1.00-00 det IS-IS Level-2 LSP RT1.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime RT1.00-00 0x00000E68 0x0D4A 1193 Area Address: 49.0001 NLPID: 0xCC Hostname: RT1 IP Address: 10.0.0.1 Metric: 10 IS RT1.02 Metric: 10 IS RT1.01 Metric: 10 IS RT2.00 Metric: 10 IP 10.0.0.1 255.255.255.255 Metric: 10 IP 11.1.0.0 255.255.0.0 Metric: 10 IP 192.168.1.0 255.255.255.252

ATT/P/OL 0/0/0

RT2#show ip route 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks C 10.0.0.2/32 is directly connected, Loopback0 C 10.2.2.0/24 is directly connected, Ethernet0/0 i L2 10.0.0.1/32 [115/20] via 192.168.1.1, Serial0/0 11.0.0.0/16 is subnetted, 1 subnets i L2 11.1.0.0 [115/20] via 192.168.1.1, Serial0/0 192.168.1.0/30 is subnetted, 1 subnets C 192.168.1.0 is directly connected, Serial0/0 Secondary Addresses, Unnumbered Interfaces, and Tunneling Configurations This sect ion discusses I S-I S configur at ion on r out er s w it h secondar y I P subnet s, I P unnum bered int erface s, and I P t unnel int erfaces. The out put s in Exam ples 9 - 1 3 ,

9-14,

and 9 - 1 5

feat ure t he respect ive configurat ions and LSPs of t he rout ers involved.

Con f ig ur in g I S - I S on Rou t e r s w it h Se con da r y I P Su bn e t s No special configurat ion is required t o advert ise secondary I P subnet s from I S-I S-enabled int erfaces by t he I S-I S pr ocess. Not e t hat t he I S-I S configurat ion does not require I P net w ork st at em ent s, and I P subnet s on int er faces w her e I S-I S rout ing is enabled are aut om at ically added t o LSPs by w ay of I P int er nal r eachabilit y or ex t ended I P r eachabilit y TLVs.

Exam ple 9 - 1 4 ,

w hich is based on Figure 9 - 12 , show s t he configur at ion of RT1 w it h a secondar y I P subnet . Also show n is t he cor r esponding LSP of RT1.

266

Figur e 9 - 1 2 . N e t w or k dia gr a m for

Ex a m ple 9 - 1 4 .

Ex a m ple 9 - 1 4 Se con da r y I P Su bn e t Con figu r a t ion

RT1 (config-if)#ip address 11.1.1.1 255.255.255.0 secondary RT1 (config-if)#^Z RT1#show running-config [snip] Interface Ethernet0/0 Ip address 11.1.1.1 255.255.255.0 secondary Ip address 10.1.1.1 255.255.255.0 ! Interface Serial0/0 Ip address 192.168.1.1 255.255.255.252 No ip directed-broadcast Ip router Isis ! Router Isis Net 49.0001.0000.0000.0001.00 ! [snip] RT1#show Isis database level-1 RT1.00-00 detail IS-IS Level-1 LSP RT1.00-00 LSPID LSP Esq. Num LSP Checksum LSP Hold time RT1.00-00 * 0x00000033 0x3CBB 1125 Area Address: 49.0001 NLPID: 0xCC Hostname: RT1 IP Address: 10.0.0.1 Metric: 10 IP 10.1.1.0 255.255.255.0 Metric: 10 IP 11.1.1.0 255.255.255.0 Metric: 10 IP 192.168.1.0 255.255.255.252 Metric: 10 IP 10.0.0.1 255.255.255.255 Metric: 10 IS RT1.02 Metric: 10 IS RT1.01 Metric: 0 ES RT1

ATT/P/OL 1/0/0

Con figu r in g I S - I S on Rou t e r s w it h U n n u m be r e d Lin k s I P unnum ber ed int er faces can be used w it h I S-I S w it hout any problem s. When connect ed int erfaces are num bered, Cisco I OS Soft ware requires t hat I P addresses on int erface s connect ed t o t he sam e link belong t o t he sam e subnet for t he I S-I S adj acency t o w or k.

267

How ever, t his requirem ent does not apply w hen using unnum bered int erfaces on point -topoint link s, eit her in ser ial or NBMA. Bot h sides of t he point -to-point link need t o be configur ed as unnum ber ed int er faces for t he adj acency t o be est ablished.

Figure 9 - 1 3

show s I S-I S enabled

on unnum ber ed int er faces. Figur e 9 - 1 3 . I P u n n u m be r e d con figu r a t ion .

Exam ple 9 - 1 5

show s t he r out ing t able on RT1 and RT2. Not ice t hat each r out er show s t he

bor r ow ed addr ess: at t he ot her r out er as t he next hop of lear ned r out es. Ex a m ple 9 - 1 5 Th e I P Rou t in g Ta ble in a n Un n u m be r e d En vir on m e n t

RT1# show ip route 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks I L2 10.0.0.2/32 [115/20] via 10.0.0.2, Serial0/0 C 10.1.1.0/24 is directly connected, Ethernet0/0 C 10.0.0.1/32 is directly connected, Loopback0 11.0.0.0/24 is subnetted, 1 subnets C 11.1.1.0 is directly connected, Ethernet0/0 RT2#show ip route 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.0.0.2/32 is directly connected, Loopback0 i L2 10.1.1.0/24 [115/20] via 10.0.0.1, Serial0/0 C 10.2.2.0/24 is directly connected, Ethernet0/0 i L2 10.0.0.1/32 [115/20] via 10.0.0.1, Serial0/0 11.0.0.0/24 is subnetted, 1 subnets i L2 11.1.1.0 [115/20] via 10.0.0.1, Serial0/0

I S- I S ov e r I P Tu n n e ls 268

Figure 9 - 1 4

show s t he configurat ion of I S-I S r out ing ov er an I P t unnel. The ex am ple is sim plist ic

because in a r eal scenar io, t he t unnel w ould span ov er a cloud of non-I S-I S rout ers t o connect t w o I S-I S net w ork segm ent s. I n t his scenario, I S-I S connect ivit y is bet w een RT3 and RT4 only over t he I P t unnel. This configur at ion has no r elevance t o vir t ual links, w hich ar e not support ed in current Cisco I OS releases. The show clns neighbors out put s in

Exam ple 9 - 1 6

confirm t hat t he adj acency is form ed over t he t unnel. The rout ing t ables of RT4 show I S-I S rout es are being learned over t he t unnel. Figur e 9 - 1 4 . I S- I S ove r I P t u n n e l con figu r a t ion .

Ex a m ple 9 - 1 6 I P I S- I S ove r Tunne l Configur a t ion

RT3#show clns neighbors System Id Interface Protocol RT4 Tu0

SNPA

State

Holdtime

Type

192.168.2.2

Up

27

L2

RT4# show clns neighbors System Id Interface SNPA State Holdtime Protocol RT3 Tu0 192.168.2.1 Up 25 IS RT4#show ip route 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks C 10.1.2.0/24 is directly connected, Ethernet0/0 i L2 10.1.1.0/24 [115/20] via 10.0.0.3, Tunnel0 C 10.0.0.4/32 is directly connected, Loopback0 11.0.0.0/24 is subnetted, 1 subnets i L2 11.1.1.0 [115/30] via 10.0.0.3, Tunnel0 192.168.2.0/30 is subnetted, 1 subnets

IS-IS

Type L2

IS-

269

C

192.168.2.0 is directly connected, Serial0/0

Authentication I SO 10589 and RFC 1195 specify only sim ple plain -t ext passwords for aut hent icat ion of I S-I S pack et s. A m or e r ecent RFC dr aft ( I S-I S HMAC-MD5 Aut hent icat ion, draft -iet f-isis -h m ac00.t x t ) proposes a m echanism for using t he HMAC-MD5 aut hent icat ion algor it hm t o pr ov ide a m ore sophist icat ed aut hent icat ion schem e for I S-I S. Cur r ent Cisco I OS Soft w ar e suppor t s only t he sim ple t ex t -based passw ords. As m ent ioned in Chapter 3 , " I nt egrat ed I S-I S Rout ing Pr ot ocol Concept s," I S-I S pack et s ar e not encapsulat ed in Lay er 3 pack et s ( I P or CLNP) as is t he case of ot her I P r out ing pr ot ocols. Encapsulat ion over Layer 2 pr ovides I S-I S som e secur it y advant ages, in t hat t he I S-I S pr ocess cannot be inundat ed by I P at t acks fr om r em ot e. I t w ould r equir e physical access t o t he I S-I S net w or k t o at t em pt an at t ack on t he I S-I S pr ocesses r unning on t he r out er s. This is cer t ainly consider ed a secur it y adv ant age. Clear-t ext I S-I S aut hent icat ion can be configured in t he follow ing t hree w ays:

•

A passw or d can be assigned t o an int er face for Lev el 1 or Lev el 2 aut hent icat ion. By default , t he passw or d is applied t o Lev el 1 if Lev el 2 is not specifie d. The password is inser t ed in all I S-I S pack et s, I I Hs, LSPs, CSNPs, and PSNPs for t he specified lev el. The passw ord is configured w it h t he int erface -level com m and isis pa ssw ord < st r ing> , w her e st ring is t h e clear-t ex t passw or d.

•

Ar ea-level aut hent icat ion can be configur ed w it h t he r out er-level com m and a r e a pa ssw ord < st ring> . This causes inser t ion of t he passw or d int o all Lev el 1 LSPs, CSNPs, and PSNPs.

•

Dom ain -w ide aut hent icat ion is enforced by insert ing passw ords in Level 2 LSPs, CSNPs, and PSNPs. I t is ena bled w it h t he com m and dom ain- pa ssw or d < st r ing> .

Exam ple 9 - 1 7 ,

w hich is based on Figure 9 - 15 , show s a configur at ion exam ple and illust r at es t he

oper at ion of per-int erface or link aut hent icat ion in I S-I S. I n

exam ple 9 - 1 6 ,

a passw or d is

configur ed on only one side of t he ser ial link , on RT1. Obser v e how t he adj acency is affect ed, as show n in t he show clns neighbor ou t p u t . Figur e 9 - 1 5 . N e t w or k dia gr a m for

Ex a m ples 9 - 1 6

and

9-17.

270

Ex a m ple 9 - 1 7 Ena bling I S- I S Aut he nt ica t ion on a n I nt e r fa ce

RT1#configure terminal Enter configuration commands, one per line. RT1(config)#int s0/0 RT1(config-if)#isis password cisco level-2 RT1(config-if)#^Z RT1#show clns neighbor System Id Interface Protocol RT2 Se0/0 ES-IS RT2#show clns neighbor System Id Interface Protocol RT1 Se0/0

SNPA *HDLC*

End with CNTL/Z.

State

Holdtime

Up

Type

278

IS

SNPA

State

Holdtime

Type

*HDLC*

Init

21

L2

IS-IS

The out put s of t he show clns neighbor com m and display t he adj acency st at us on bot h r out er s aft er t he passw or d is configur ed on only RT1, w it h no m at ching passw or d on r out er RT2. This inform at ion indicat es t hat RT1 com plet ely ignores t he I I Hs of RT2 because t hey could not be aut hent icat ed. RT1, how ev er , st ill discov er s ES-I S adj acency w it h RT2 by m eans of I SHs ex changed bet w een t hem . On t he ot her hand, RT2 is not configur ed for aut hent icat ion, so it accept s and pr ocesses t he I I Hs fr om RT1 and t hen m oves t he st at us of t he adj acency t o I nit . The adj acency rem ains in I nit st at e because RT2 never receives an I I H from RT1 recognizing RT2 as an I S neighbor, t o com ple t e t he t hr ee-w ay adj acency form at ion pr ocess. The follow ing out put of debug isis adj - pa ck e t s on RT1 dem onst r at es t he aut hent icat ion pr ocess bet w een RT1 and RT2 ( see Exam ple 9 - 1 8 ) . Configuring a passw ord on RT2 t o m at ch t he passw or d on RT1 r esult s in successful aut hent icat ion and subsequent com plet ion of t he t hree w ay handshak e pr ocess. Ex a m ple 9 - 1 8 D e bu ggin g Au t h e n t ica t ion Fa ilu r e s

RT1# debug isis adj-packets *Apr 23 04:25:36: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), type L1L2, cir id 00, length 1499 *Apr 23 04:25:36: ISIS-Adj: Authentication failed *Apr 23 04:25:42: ISIS-Adj: Sending serial IIH on Serial0/0, length *Apr 23 04:25:46: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), type L1L2, cir id 00, length 1499 *Apr 23 04:25:46: ISIS-Adj: Authentication failed *Apr 23 04:25:50: ISIS-Adj: Sending serial IIH on Serial0/0, length . RT2#conf t Enter configuration commands, one per line. End with CNTL/Z. RT2(config)#int s0/0 RT2(config-if)#isis password cisco RT2(config-if)#^Z

cir

1499 cir

1499

RT2#show clns neighbor

271

System Id Protocol RT1 IS-IS

Interface Se0/0

SNPA *HDLC*

State Up

Holdtime

Type

21

L2

Domain-Wide Prefix Distribution (L2 to L1 Route Leaking) RFC 2966 specifies a m echanism for dom ain -w ide pr efix dist r ibut ion in an I S-I S net w ork, effect ively r em oving t he st ub-only capabilit y specified by I SO 10589 for Level 1 ar eas. This feat ur e is av ailable in cur r ent Cisco I OS Soft w ar e and it is k now n as I S-I S rout e leaking. Th e obj ect iv e of r out e leak ing is t o enable int er ar ea rout es t o be leaked int o I S-I S Lev el 1 ar eas so t hat Level 1 rout ers have m ore inform at ion t o m ake opt im al int erarea rout ing decisions. Wit hout dist ribut ing int erarea rout es int o Level 1, I S-I S ar eas funct ion as st ubs, and Lev el 1 rout ers forward t raffic t o dest inat ions in ot her areas t hrough t he nearest Level 1 -2 r out er . The Cisco I OS configurat ion for rout e leaking uses t he rout er-level redist ribut e com m an d w it h a new ly defined opt ion. No special TLVs ar e r equir ed t o adver t ise int er ar ea r out es fr om Level 2 int o Level 1. The capabilit y j ust allow s Level 2 rout es carried in TLVs 128, 130, and 135 t o be inj ect ed int o t he var ious Level 1 ar eas in t he dom ain. RFC 2966 specifies a pr ocedur e t o pr event r out e feedback , w hich ensur es t hat r out es adv er t ised int o Level 1 fr om Lev el 2 ar e not adv er t ised back int o Level 2. TLV 135 feat ur es a dedicat ed up/ dow n ( U/ D) bit ( see Figure 9 - 1 6 ) , w hich is set w hen a r out e is adver t ised fr om Level 2 int o Level 1. RFC 2966 pr oposes using bit 8 in t he default m et r ic field of TLV 128 and 130 as t he up/ dow n bit t o pr ot ect against r out ing loops w hen rout e leaking is enabled. Prefixes w it h t he U/ D bit set are never propagat ed from Level 1 t o Lev el 2. Figur e 9 - 1 6 . Up/ D ow n ( U/ D ) bit in I P r e a ch a bilit y TLVs.

Because Cisco I OS Soft w ar e set s bit 8 for ext er nal m et r ics w hen r out es for ext er nal sour ces ar e adver t ised int o I S-I S, using t he sam e bit for r out e leaking m ight r esult in conflict ing sit uat ions. Also not e t hat only I S-I S r out es t ha t ar e Lev el 2 r out es in t he r out ing t able ar e

272

" leaked" int o Level 1. Rem em ber t he follow ing w hen configuring rout e leaking in Cisco -based I S-I S env ir onm ent s:

•

Use w ide m et r ics by configur ing m et ric- st yle w ide under t he I S-I S r out er pr ocess. This allow s TLV 135 t o be used for car r y ing I P r eachabilit y infor m at ion. TLV 135 has a dedicat ed up/ down ( U/ D) bit .

•

Do not enable t he ext ernal m et ric t ype w hen redist ribut ing rout es from ext ernal sources int o I SI S.

The follow ing t w o differ ent com m and-line synt axes ar e sup por t ed in Cisco I OS Soft w ar e for configuring rout e leaking. The second variant of t he com m and is deprecat ed:

•

12.1, 12.0S, and 12.0ST Releases:

redistribute isis ip level-2 into level-1 distribute-list •

12.0S and 12.0ST Releases:

advertise ip L2-into-L1 Also, t he I P pr efix es need t o be pr esent in t he r out ing t able as t he I S-I S Level 2 r out e for t hem t o be adv er t ised int o Lev el 1. I n t he ex am ple show n in

Figure 9 - 17 ,

RT2 advert ises 12.1.1.0/ 24 t o RT1 t hrough Level 2. As

depict ed in t he configurat ion show n in Exam ple 9 - 1 9 , RT1 t hen sum m arizes 12.1.1.0/ 24 int o 12.0.0.0/ 8 and t hen " leaks" it int o Level 1. The r out e is adv er t ised int o Lev el 1 by adding t he sum m ary prefix t o t he locally generat ed Level 1 LSP and flooding it int o area 49.0001. 9 - 19

Exam ple

also show s t he Level 1 LSP of RT1 displayed in det ail fr om RT5. Figur e 9 - 1 7 . D ia gr a m for t h e Le ve l 2 t o Le ve l 1 r ou t e le a k in g e x a m ple .

Ex a m ple 9 - 1 9 Rou t e Le a k in g Ex a m ple

RT1# interface Ethernet0/0 ip address 11.1.1.1 255.255.255.0 ip router isis ! interface Serial0/0 ip address 192.168.1.1 255.255.255.252

273

ip router isis ! router isis summary-address 12.0.0.0 255.0.0.0 level-1 redistribute isis ip level-2 into level-1 net 49.0001.0000.0000.0001.00

RT5#show isis data level-1 detail RT1.00-00 IS-IS Level-1 LSP RT1.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL RT1.00-00 0x000000F7 0xF8AA 518 Area Address: 49.0001 NLPID: 0xCC Hostname: RT1 IP Address: 10.1.1.1 Metric: 10 IS RT1.02 Metric: 10 IS RT1.01 Metric: 10 IS RT5.00 Metric: 10 IP 10.1.1.1 255.255.255.255 Metric: 10 IP 11.1.1.0 255.255.255.0 Metric: 10 IP 192.168.1.0 255.255.255.252 Metric: 20 IP-Interarea 12.0.0.0 255.0.0.0

1/0/0

Multi-Area Configuration Pr ior t o t he availabilit y of I S-I S m ult i-ar ea capabilit y in Cisco I OS r eleases, each I S-I S r out er could be in only a single ar ea ( even w hen configur ed w it h m ult iple ar ea I Ds for m ult ihom ing) . As m ent ioned in Chapter 4 , " Addressing in I nt egrat ed I S-I S," in m ult ihom ing scenarios, t he m ult iple ar eas configur ed ar e effect ively m er ged int o a single ar ea; also, only one I S-I S pr ocess can be configur ed per r out er . Mult i-ar ea suppor t allow s a single r out er t o par t icipat e in up t o 29 independent Lev el 1 ar eas w it h one of t hem doubling as Level 2 if necessar y. The feat ur e is designed pr im ar ily for t elecom m unicat ions m anagem ent net works t hat use I S-I S for rout ing. I S-I S m ult i-ar ea support provides t he flexibilit y t o have one rout er support m ult iple areas in t he m anagem ent net w or k in a cost -effect ive m anner. I n essence, t his feat ur e allow s up t o 29 I S-I S pr ocesses t o be configur ed on a single r out er , one of w hich can be Le vel 1 -2 and t he rem ainder only Level 1. Not e, how ever, t he follow ing r est r ict ions:

•

Only one of t he pr ocesses can suppor t Lev el 2 int er ar ea r out ing.

•

Each int er face cannot be in m or e t han one ar ea ( Lev el 1) . Subint er faces ar e t r eat ed t he sam e as regular int e rfaces.

•

Separ at e ar eas in t he sam e r out er m ust have unique ar ea I Ds, and individual r out er s in an ar ea m ust hav e unique sy st em I Ds.

•

Redist r ibut ion bet w een pr ocesses is not allow ed; how ev er , ex t er nal r out ing sour ces can be r edist r ibut ed int o each ar ea independent ly.

274

•

I S-I S m ult ihom ing can be used t o m er ge m ult iple ar eas by shar ing t he ar ea I Ds of t he areas being m erged under each part icipat ing I S-I S pr ocess.

Figure 9 - 1 8

show s a m ult i-area scenario. I n t he corresponding Cisco I OS configurat ion out put for

RT1 show n in Exam ple 9 - 20 , t hree processes are running, t agged Core ( Level 1 -2) , Access-2 ( Level 1) , and Access-3 ( Level 1) . Each process has a different area I D in it s NSAP address, but t hey all shar e t he sam e syst em I D ( 0000.0000.0001) . The m ult i-ar ea funct ionalit y is bor r ow ed fr om t he OSPF pr ot ocol and pr esent s significant advant ages for efficient net w or k d esign. For m ore inform at ion, see t he I nt roduct ion and Configurat ion Guide on I S-I S m ult iar ea suppor t . Figur e 9 - 1 8 . D ia gr a m for t h e m u lt i- a r e a configur a t ion e x a m ple .

Ex a m ple 9 - 2 0 M u lt i- Ar e a Con figu r a t ion Ex a m ple

RT1# interface Serial1/0 ip address 192.169.1.1 255.255.255.0 ip router isis Core interface Ethernet0/0 ip address 11.1.2.1 255.255.255.0 ip router isis Access-2 interface Ethernet0/1 ip address 11.1.3.1 255.255.255.0 ip router isis Access-3 router isis CORE net 49.0001.0000.0000.0001.00 ! router isis Access-2 net 49.0002.0000.0000.0001.00 is-type level-1 ! router isis Access-3 net 49.0003.0000.0000.0001.00 is-type level-1

275

Configuring IS-IS for Optimized Performance The pr evious sect ions discuss r udim ent ar y I S-I S configur at ion fo r various scenarios, using t he t w o basic st eps r equir ed t o enable I S-I S on Cisco rout es: configuring t he rout ing process and enabling I S-I S rout ing on int erfaces. Cisco I OS Soft w are provides num erous com m ands for enabling various capabilit ies of t he I S-I S pr ot ocol and opt im izing it s per for m ance. I n m ost cases, t he configurat ion opt ions enabled are t arget ed at im proving efficiency of t he dat a for w ar ding pr ocess and achieving net w or k design obj ect ives, such as r out ing st abilit y and fast convergence. The com m a nd opt ions can be enabled globally under t he configur at ion of t he I SI S r out ing pr ocess ( r out er-level configurat ion) or for specific int erfaces ( int erface -level configur at ion) . As you m ight be aw ar e by now , t he t w o cat egor ies of I S-I S configurat ion com m ands are int erface -lev el com m ands and r out er-level com m ands. This sect ion discusses som e com m only used ( alt hough nonessent ial) I S-I S com m ands. 9 - 21 ,

Exam ple

w hich show s t he t ypical configurat ion of an I nt ernet rout er, provides t he basis for

discussions in t his sect ion. This configurat ion is for illust rat ive pur poses only . Ex a m ple 9 - 2 1 I nt e r ne t Rout e r I S- I S Configur a t ion

RT1#show running-config ! clns routing ! interface Loopback0 ip address 172.168.123.1 255.255.255.255 no ip directed-broadcast ! interface Serial0/0 ip unnumbered Loopback0 no ip directed-broadcast ip router isis isis metric 15 level-2 isis password cisco level-2 isis hello-multiplier 12 level-2 isis hello-interval 5 level-2 ! router isis summary-address 10.1.0.0 255.255.0.0 passive-interface Loopback0 net 49.0001.0002.0003.0004.0005.0006.00 is-type level-2-only metric-style wide spf-interval 30 no hello padding log-adjacency-changes ! ip classless ! end The configurat ion in Exam ple 9 - 21 feat ures t he following addit ional int erface -level configurat ion com m ands:

•

isis m e t r ic

276

•

isis pa ssw or d

•

isis h e llo- int erva l

•

isis h e llo- m ult iplie r

Exam ple 9 - 2 1

also show s t he follow ing nonessent ial ro u t er-level com m ands:

•

is- t ype

•

m et ric- st y le

•

spf- int erva l

•

ignore- l sp- e r r or s

•

no he llo pa dding

•

log- a dj a ce ncy- ch a n ge s

• •

pa ssive - int e r fa ce sum m a ry- a ddr e ss

All t he com m ands in t he pr eceding t w o list s ar e not r equir ed t o enable I S-I S. How ever, t hey ar e added t o opt im ize oper at ional efficiencies of t he pr ot ocol and net w or k design. These com m ands ar e discussed fur t her in t he follow ing sect ions. The isis pa ssw ord an d sum m arya ddress com m ands ar e cov er ed ear lier in t his chapt er , in t he sect ions on aut hent icat ion and sum m a rizat ion, respect ively.

isis hello-interval and isis hello-multiplier Commands By default , t he int er val bet w een hello packet s is 10 seconds, w it h som e j it t er ing applied t o prevent net w ork-w ide synchr onizat ion. The cor r esponding default for t he he llo m ult iplie r is 3. The pr oduct of t hese t w o par am et er s gives t he holdt im e for t he adj acency. The holdt im e is t he int er val aft er w hich if a hello packet has not been r eceived fr om t he neighbor , it w ill be declar ed " dead" and t he adj acency t or n dow n. The holdt im e ha s a dir ect bear ing on t he speed of conv er gence. The holdt im e can be m odified by adj ust ing t he hello int er v al and hello m ult iplie r , as needed, t o provide t he desired effect on net w ork st abilit y and convergence. The holdt im e value cannot be m odified direct ly on Cisco r out er s. I n t he sam ple configur at ion show n in

Exam ple 9 - 2 1 ,

t he hello int er val has been r educed t o 5 and t he m ult iplier incr eased t o

12, r esult ing in a holdt im e of 60 seconds r at her t han t he 30-second default v alue.

isis metric and metric-style Commands You can use t he isis m e t r ic com m and t o m odify t he default m et ric value for Level 1 or Level 2 separ at ely. I n bot h sit uat ions, t he default value is 10. I n t he configur at ion show n in Exam ple 9 21,

t he m et r ic is changed t o 15 for only Lev el 2. Not ice t hat t his r out er w ould par t icipat e only

in Lev el 2 r out ing on all it s act iv e I S-I S int er faces because of t he global, r out er-level is- t ype le ve l- 2 - only com m and. Th e m et ric- st yle com m and is a r ecent int r oduct ion based on t he I S-I S enhancem ent s in t he I ETF ( I S-I S ext ensions for Tr affic Engineer ing, dr aft -iet f-isis -t raffic-02.t xt ) , specifically t o

277

facilit at e MPLS t r affic engineer ing. The follow ing ar e t he cur r ent ar gum ent opt ions for t his com m and:

•

na r r ow — Bases int er pr et at ion of t he m et r ic field in TLVs 2, 128, and 130 on I SO 10589 and RFC 1195. The r out er is lim it ed t o a m axim um m et r ic of 63 per int er face and 1023 for an ent ir e pat h.

• •

t r a n sit ion— Allow s r out er s t o send and r eceiv e bot h old and new m et r ic for m at s. w ide — Allow s r out er s t o use a new m et r ic for m at t o suppor t lar ge m et r ic v alues.

The default is m et ric- st y le n a r r ow . Th e w ide opt ion pr ov ides a lot of flexibilit y for m et ric assignm ent in I P net working environm ent s. The t ransit ion opt ion is recom m ended only for m igr at ion pur poses and car r ies som e ov er head w it h it . Ther efor e, net w or k oper at or s need t o avoid enabling t r ansit ion m ode for long-t erm operat ion. This is fur t her discussedin Chapt er 7 , " Gener al Net w or k Design I ssues," and a m igr at ion scenar io is pr ovided in Chapt er 8 .

isis-type Command Th e isis- t ype com m and det er m ines t he m ode of oper at ion of all act iv e I S-I S-enabled int er faces on a Cisco r out er . The ar gum ent opt ions for t his com m and ar e as follow s:

•

le ve l- 1 - 2 — This is t he default m ode of oper at ion. I n t his m ode, t he rout er is capable of bot h Lev el 1 and Lev el 2 funct ionalit y and can for m eit her t y pe of adj acencies w it h neighboring I S-I S r out er s.

•

le ve l- 1 — I n t his m ode, t he rout er can form only Level 1 adj acencies on all int erface on w hich I S-I S is enabled. A r out er oper at ing in t his m ode for w ar ds all packet s t o ot her ar eas in t he dom ain t o t he near est Level 1 -2 r out er in t he local ar ea.

•

le ve l- 2 - only— I n t his m ode, t he rout er can part icipat e only in Level 2 rout ing. Rout er s pr ov iding ex t ensions t o t he I S-I S Lev el 2 back bone t hat do not connect t o any Level 1 dom ains could be configured t o operat e in t his m ode t o conserve syst em resources. Som e I SP net w orks using I S-I S as t he I GP em ploy flat net w or k designs w it h all t he I S-I S r out er s as Lev el 2 only . This allow s for easy m igr at ion t o a hierarchical design; you can j ust m igrat e t he edge t o different areas and leave t he cor e int act .

spf-interval Command I n default oper at ion m ode, t he I S-I S SPF pr ocess on Cisco r out er s r uns per iodically , no m or e fr equent ly t han every 5 seconds. That is, by default , t he norm al m inim um int erval bet w een t w o consecut ive SPF calculat ions is 5 seconds. How ever, cert ain net w ork changes, such as link failures, can t rigger im m ediat e runs. The SPF process m ight be cost ly in t erm s o f CPU cy cles depending on t he size of t he net w or k ( t hat is, t he num ber of nodes, link s, and pr efix es involved) .

278

Th e spf- int erva l com m and specifies t he int erval bet w een SPF calculat ion event s. A sm aller int erval m ight result in fast er convergence but possib ly affect t he st abilit y of t he net w or k. Typically, larger int erval values are used only in st able net w ork environm ent s. For ex am ple, t he configur at ion show n in Exam ple 9 - 2 1 is opt im ized for a st able env ir onm ent , w hich is less pr one t o net w or k chur n; t her efor e, t he SPF pr ocess is set t o r un no m or e fr equent ly t han ev er y 30 seconds. Recent I S-I S enhancem ent s in I OS include new opt ions for t he spf- int erva l com m and. This change allow s aggr essive low int er vals t o be specified and pr ovides for backoff t o m or e conservat ive values when changes in t he net work becom e ram pant . The backoff m echanism is also im plem ent ed for par t ial r out e calculat ions and also gener at ion of LSPs. Exponent ial backoff is discussed in det ail in Chapt er 7 . Th e show isis spf- lo g com m and is a r elat ed com m and t hat enables y ou t o v iew an SPF act iv it y log. A sam ple out put of t he show isis spf- lo g com m and is show n in Exam ple 9 - 2 2 . The out put show s var ious t r igger s t hat caused t he r unning of t he SPF pr ocess on t his r out er . PERI ODI C indicat es periodic runs of t he SPF process, w her eas TLVCONTENT im plies t hat t he SPF calculat ion w as t r igger ed by a change in t he cont ent s of t he TLV field of t he LSP ow ned by t he list ed rout er. Ex a m ple 9 - 2 2 show isis spf- log Com m a n d Ou t pu t

RT1#show isis spf-log Level 2 SPF Log When Duration 02:38:48 0 02:31:35 0 02:22:30 0 TLVCONTENT 02:16:36 0 TLVCODE 02:11:27 0 DELADJTLVCONTENT 02:08:10 0 02:01:36 0 01:46:36 0 01:31:36 0

Nodes 5 5 5 2

Count 3 1 2 4

Last Trigger LSP RT3.00-00 RT1.00-00 RT1.02-00

Triggers NEWADJ TLVCONTENT PERIODIC NEWMETRIC PERIODIC TLVSTYLE

2

4

RT1.00-00

NEWADJ

2 2 2 2

2 1 1 1

RT1.00-00

DELADJ TLVCONTENT PERIODIC PERIODIC PERIODIC

The follow ing list ex plains t he t r igger s show n in Exam ple 9 - 2 2 :

•

PERI ODI C— Periodic SPF process ( LSPDB refresh int erval)

•

N EW SYSI D — New syst em I D assigned

•

N EW LEVEL — I S-I S process level changed

•

N EW M ETRI C— New m et ric assigned t o an int erface

•

TLV COD E— LSP w it h a new TLV code field r eceiv ed

•

TLVCON TEN T— LSP w it h changed TLV cont ent s received

•

N EW AD J— New neighbor adj acency up

•

D ELAD J— Adj acency delet ion

279

passive-interface Command The obj ect iv e of t he pa ssive int erfa ce com m and is t o pr event pr ot ocol act ivit y over a specific int er face. This is a gener ic com m and applicable t o all r out ing pr ot ocols suppor t ed in Cisco I OS Softw ar e. When configur ed under t he I S-I S pr ocess, t he pa ssive - int erfa ce com m and pr ev ent s t r ansm ission of I I Hs ov er t he specific int er face and as a r esult pr ev ent s for m at ion of I S-I S adj acency over t hat int er face. Typically, t he pa ssive - int erfa ce com m and is used w h en t her e is a need t o adv er t ise t he pr efix fr om a net w or k int er face w it hout for m ing adj acencies over t hat int erface. I n Cisco I OS Soft w are, specifying an I S-I S int er face as passiv e r em ov es t he I S-I S configurat ion from t hat int erface. The I P subnet con figur ed on t he int er face is st ill adver t ised int o t he I S-I S env ir onm ent .

The log-adjacency-changes, ignore -lsp-errors, and no hello padding Commands Th e log- a dj a ce ncy- cha nge s com m and enables logging of I S-I S adj acency changes. You can use t his t o gener at e SYSLOG t raps for net work operat ions and m anagem ent purposes. The logged inform at ion is also useful for t roubleshoot ing purposes. Exam ples of t he m essages logged ar e show n in Exam ple 9 - 2 3 . Ex a m ple 9 - 2 3 Tr a ck in g Adj a ce n cy Ch a n ge s

RT1#show log %CLNS-5-ADJCHANGE: ISIS: Adjacency to 0000.0000.0001 (ethernet 0) %CLNS-5-ADJCHANGE: ISIS: Adjacency to 0000.0000.0002 (ethernet 0) Th e ignore- lsp- e r r or s com m and is used in net w or k env ir onm ent s pr one t o pack et cor r upt ion. The com m and allow s t he r out er t o ignor e any cor r upt LSP t hat w ould nor m ally hav e t r igger ed a pur ge act ion. A r out er pur ging anot her 's LSP is t he cor r ect behavior of t he pr ot ocol but could easily degener at e int o an adv er se net w or k sit uat ion ( r efer r ed t o as LSP packet corrupt ion st orm s) . I n t his sit uat ion, a rout er's LSPs are repeat edly corrupt ed by t he t r anspor t m edium and ar e pur ged by ot her syst em s in t he net w or k, r esult ing in an SPF chur n t hat could pot ent ially lead t o a net w or k m elt dow n. Th e no he llo pa dding com m and is designed t o pr ev ent net w or k bandw idt h fr om being w ast ed by t he per iodic ex change of hellos over int erfaces w it h large m essage t ransm ission unit ( MTU) sizes. The I S-I S pr ot ocol r equir es hellos t o be padded t o t he lar ger of t he MTU or LSP buffer size. This w ould t echnically guar ant ee t hat syst em s for m ing adj acencies over a link can r eceiv e an d pr ocess each ot her s LSPs and ot her I S-I S packet s over t he link. How ever, in pract ice, t he sam e MTU size is used on t he int er faces of t he connect ing r out er s; t her efor e, padding hello packet s is ir r elevant in m ost cases. The com m and disables t he default behavior, result ing in significant bandw idt h savings, especially in sit uat ions w here sm all hello int ervals have been configur ed and t he MTU size is r easonably lar ge. A global r out er-level variant of t his com m and provides opt ions t o select ively disable padding on all I S-I S int er faces or all point -to-point int erfaces or all m ult ipoint int erfaces ( see Exam ple 9 -

280

24) .

You can use an int er face -level var iant of t he com m and for a single int er face applicat ion,

as show n in Exam ple 9 - 25 . Ex a m ple 9 - 2 4 D isa bling H e llo Pa dding on M ult iple I nt e r fa ce s

RTA(config)#router isis RTA(config-router)#no hello padding ? multipoint Pad LAN hello PDUs point-to-point Pad point-to-point hello PDUs Ex a m ple 9 - 2 5 D isa bling H e llo Pa dding on a n I nt e r fa ce

RTA(config)#int pos 2/0 Rtr-A(config-if)#no isis hello padding

Summary This chapt er focuses on t he configur at ion of t he I S-I S r out ing pr ot ocol on Cisco r out er s. The ear ly sect ions of t his chapt er look at enabling I S-I S r out ing on differ ent net w or k t r anspor t m edia t ypes, specifically point -t o-point , broadcast , and nonbroadcast m ult iaccess m edia. Specific m edia -dependent configur at ions ar e pr ovided, cover ing point -to-point serial, ATM point -t o-point , ATM m ult ipoint subint erfaces, Fram e Relay point -t o-point , Fram e Relay m ult ipoint , and I SDN m ult ipoint ( BRI int erface) . The chapt er also explains t he I S-I S configurat ion procedure. This involves a t wo -st ep pr ocess: configuring t he I S-I S r out ing pr ocess and enabling I S-I S r out ing of t he appr opr iat e int er faces. This chapt er also discusses how t o enable I S-I S capabilit ies. Redist ribut ion, sum m arizat ion, and origina t ion of a default r out e int o t he I S-I S environm ent are discussed and configurat ion exam ples are provided. Som e t im e is spent discussing configurat ion of I S-I S ov er I P unnum ber ed int er faces, I P t unnels, and t he use of secondar y addr esses. I S-I S w as or iginally designed t o support a t wo -layer hier ar chy w it h an addr essing schem e t hat put s a w hole r out er in one ar ea. I n t he t w o -level hier ar chy schem e, m ult iple st ub Level 1 ar eas int er connect ov er a back bone. The st ub Lev el 1 ar eas ar e int er connect ed by t he Lev el 2 backbone. I n t his schem e, Level 1 -only rout ers point default rout es t o Level 1 -2 r out er s t o rout e t o ot her areas. This could pot ent ially result in subopt im al rout ing. How ever, recent prot ocol enhancem ent s allow leaking of int erarea rout es int o Level 1, t hus opt im izing pat h select ion for int er ar ea dest inat ions. This chapt er also show s y ou how t o configur e t he Lev el 2 t o Level 1 rout e leaking capabilit y. Anot her recent ly added capabilit y allow s for m ult i-ar ea suppor t on a single r out er . The sect ion on I S-I S m ult i-area support addresses t he configurat ion requirem ent s for t his funct ionalit y. The lat er sect ions of t his chapt er r ev iew a t y pical configur at ion of an I S-I S r out er in a ser v ice provider net w ork and look at t he various com m ands t ypically em ployed t o opt im ize oper at ion of t he I S-I S process. I n t hese sect ions, it is not ed t hat t he I OS com m and -line int er face suppor t s num er ous com m ands t hat can be used t o achiev e net w or k design obj ect iv es, such as scalabilit y, fast convergence, and net work st abilit y.

281

This chapt er is dedicat ed t o get t ing t he r eader fam iliar w it h Cisco I OS configur at ion of t he I SI S pr ot ocol and discusses som e " best pr act ices" configur at ion opt ions.

References http: / / www.cisco.com / univercd/ cc/ td/ doc/ product/ software/ ios120/ 12cgcr/ np1_c/ 1cprt1/ 1cisis.htm # 4552 .

RFC 2966, "Dom ain -wide Prefix Dist ribut ion wit h Two-Level I S -I S." Li, Tony, Przygienda, Tony, Sm it , Henk. dr aft -iet f-isis -h m ac-00.t xt : I S-I S HMAC-MD5 Aut hent icat ion. dr aft -iet f-isis -t raffic-02.t xt : I S-I S ex t ensions for Tr affic Engineer ing.

282

Chapter 10. Troubleshooting the IS-IS Routing Protocol This chapt er covers com m on problem s t hat m ight result in fault y operat ion of t he I S-I S pr ot ocol, and discusses pr ocedur es t o t r oubleshoot t hem . Most of t he t im e, fault y oper at ion r esult s fr om m isconfigur at ions, w hich could be easily discer ned by car efully r eview ing configurat ions of t he rout ers involved and t he out put of basic CLNS- and I S-I S-r elat ed show com m ands. How ever , som e issues m ight pr esent m or e of a challenge. Such issues m ight r equir e adv anced k now ledge of t he I S-I S prot ocol archit ect ure and capabilit ies, evaluat ion of packet capt ures, and com p licat ed net work-w ide debugging pr ocedur es. To quickly evaluat e and r esolve pr oblem s, in ever y case, you need a solid t echnical under st anding of t he I S-I S pr ot ocol. I n addit ion, y ou need t o k now how t o configur e, debug, and int er pr et t he var ious associat ed show com m ands av ailable in Cisco I OS Soft w ar e. The Cisco im plem ent at ion of t he I S-I S pr ot ocol adds m any nonst andar dized feat ur es and associat ed configur at ion com m ands, com m only r efer r ed t o as k nobs. This chapt er discusses funct ional problem s and includes p ract ical exam ples t hat show you how t o t roubleshoot I S-I S pr oblem s, fr om t he ver y basic t o t he m or e advanced. The Cisco Technical Assist ance Cent er ( TAC) is t he aut horit at ive resource for service -im pact ing issues and out ages t hat require im m ediat e at t ent ion. Ex per ience show s, how ev er , t hat ev en w hen an issue is referred t o t he Cisco TAC, problem s can be resolved fast er if t he person calling in t he case has a good k now ledge of t he pr ot ocol, can descr ibe t he sy m pt om s adequat ely , and can work collaborat ively w it h t he support engineer. Lin k-st at e r out ing pr ot ocols, such as OSPF and I S-I S, are generally m ore com plicat ed t o t roubleshoot t han are dist ance -vect or prot ocols. Com pared t o OSPF, however, I S-I S seem s t o be easier t o w or k w it h by far . But t his sim plicit y is not obv ious because t he oper at ion of I nt egr at ed I S-I S in I P environm ent s st ill occurs w it hin t he fram ew ork of t he Connect ionless Net work Prot ocol ( CLNP) . This requires knowledge of CLNP, including it s node -based addr essing schem e, w hich differ s fr om t he link-based addr essing schem e used in I P. " The I S- I S Link- State Database,"

Chapt er 5,

pr ovides det ailed insight int o CLNP addr essing and helps dem yst ify

t he subj ect . Befor e delving int o t he act ual t r oubleshoot ing m et hodology, it m ight be useful t o r eview som e Cisco I OS show com m ands com m only used for t roubleshoot ing I S-I S r out ing pr oblem s. The follow ing is a shor t list of im por t ant com m ands:

•

show clns ne ighbor — Enables y ou t o v erify t he st at us of adj acencies

•

show clns int e r fa ce — Enables y ou t o v er ify t he configur at ion of an act iv e CLNS int erface

•

show isis da t a ba se — Enables y ou t o check for t he pr esence of all ex pect ed LSPs

•

show isis spf- log— Enables y ou t o check how fr equent ly t he SPF process is being run and t he associat ed t riggers

283

Som e of t hese com m ands ar e discussed in Chapt er 9 , " Configuring I S-I S for I P Rout ing on Cisco Rout er s." The nex t sect ion provides a det ailed explanat ion of t hese key t r oubleshoot ing and m onit or ing com m ands as a pr elude t o t he ensuing discussions on t r oubleshoot ing m et hodology. For exam ple, t he show isis da t a ba se com m and enables y ou t o check bot h t he Level 1 and Level 2 dat abases. I f you do not underst and t he out put , how ever, t he com m and is not a useful t roubleshoot ing t ool. An im port ant point is t hat an I S-I S r out er uses only a single LSP for each lev el of r out ing. An LSP m ight be fr agm ent ed if t her e ar e t oo m any TLVs t o be con t ained in it s m axim um size of 1492 byt es. I n m ost cases, how ever, each rout er generat es j ust a single LSP for Lev el 1 or Lev el 2 r out ing. Because y ou hav e t o deal w it h a single LSP, I S-I S appear s t o be m uch easier t o t r oubleshoot t han OSPF. That said, it is st ill im por t ant t o under st and all t he infor m at ion in an LSP. When t roubleshoot ing com plicat ed problem s, you m ight have t o debug I S-I S act iv it ies on t he rout er. The following list ident ifies useful I S-I S prot ocol debugging com m ands. Alt hough debugging is gener ally CPU-int ensive, t hese com m ands do not over bur den t he pr ocessor . How ever , alw ays assess t he r out er s sit uat ion befor e enabling any of t hese com m ands. You should enable only a single debugging com m and at a t im e, and y ou should capt ur e t he console screen for lat er r ev iew :

•

debug isis a dj - pack et s

• •

debug isis updat e - pa ck e t s debug spf- e ve n t s

Th e log- a dj a ce ncy- cha nge s an d ignore- lsp- e r r or s r ou t er-level configurat ion com m ands gener at e st at us-logging inform at ion t hat can prove useful in t roubleshoot ing. The rout er logs can be ex por t ed t o a SYSLOG ser v er and used for m anagem ent and t r oubleshoot ing pur poses.

Interpreting the Output of Key IS-IS show Commands This sect ion det ails t he out put of som e of t he key t r oubleshoot ing com m ands discussed in t he previous sect ion. The Cisco I OS show com m ands pr ovide infor m at ion about act ivit ies occur r ing on t he r out er and ser v e as ex cellent t ools for diagnosing pr oblem s. The out put of t he follow ing com m ands ar e exam ined based on t he t opology and configur at ion of t he r out er s in Figure 10- 1 : Fig u r e 1 0- 1 . Sim ple I S- I S dom a in t opology .

284

•

show clns

•

show clns pr ot ocol

•

show clns ne ighbor s

•

show clns int e r fa ce

•

show isis da t a ba se

•

show isis t opology

•

show isis spf- log

Figure 10- 1

show s a sim ple t opology of an I S-I S dom ain consist ing of t w o ar eas ( 49.0001 and

49.0002) , each w it h t w o r out er s. This t opology pr ovides pr act ical significance t o t he out put of t he com m ands t hat w ill be st udied. The r out er configur at ions ar e pr ovided as w ell. Ex a m p le 1 0- 1 Rout e r Configur a t ions in Sim ple I S- I S N et w ork ( r e fe r t o

Figu r e 1 0 - 1 )

RT5 interface Loopback0 ip address 11.1.1.5 255.255.255.255 ! interface Ethernet0/0 ip address 10.1.1.5 255.255.255.0 ip router isis ! router isis passive-interface Loopback0 net 49.0001.0000.0000.0005.00 is-type level-1 metric-style wide RT1 interface Loopback0 ip address 11.1.1.1 255.255.255.255 ! interface Ethernet0/0 ip address 10.1.1.1 255.255.255.0 ip router isis ! interface Serial0/0 ip address 192.168.1.1 255.255.255.252 ip router isis ! router isis passive-interface Loopback0 net 49.0001.0000.0000.0001.00 metric-style wide log-adjacency-changes RT2 interface Loopback0 ip address 11.1.1.2 255.255.255.255 ! interface Ethernet0/0 ip address 10.1.2.1 255.255.255.0 ip router isis !

285

interface Serial0/0 ip address 192.168.1.2 255.255.255.252 ip router isis ! router isis passive-interface Loopback0 net 49.0002.0000.0000.0002.00 metric-style wide log-adjacency-changes RT6 interface Loopback0 ip address 11.1.1.6 255.255.255.255 ! interface Ethernet0/0 ip address 10.1.2.6 255.255.255.0 ip router isis ! router isis passive-interface Loopback0 net 49.0002.0000.0000.0006.00 is-type level-1 metric-style wide show clns The I S-I S r out ing pr ot ocol oper at es w it hin t he CLNP fr am ew or k ev en w hen used in pur e I P environm ent s. Therefore, t o verify t he operat ion of I S-I S rout ers or t roubleshoot problem s, oft en you m ust use I OS CLNP -relat ed com m ands. The show clns com m and, w hich is t he base of t he CLNP-relat ed show com m ands, suppor t s sev er al ar gum ent s t hat enable y ou t o quer y specific at t ribut es and st at us inform at ion o n an I S-I S r out er about t he I SO CLNS env ir onm ent . The follow ing ar e ex am ples of t hese com m and ar gum ent s:

•

int erfa ce— Pr ov ides CLNP int er face st at us and configur at ion

•

is- neighbors— Pr ovides infor m at ion about r out er adj acencies

•

neighbors— Pr ovides infor m at ion about r out er and end-sy st em adj acencies

•

pr ot ocol— Pr ov ides infor m at ion about t he r out ing pr ocess for t he CLNP pr ot ocol

• •

route — Displays rout ing inform at ion for CLNP prefixes t ra ffic— Display s CLNP st at ist ics

The out put of show clns w it h som e of t he pr eceding argum ent s is discussed in det ail lat er in t his sect ion.

Exam ple 10- 2

show s t he out put of show clns w it hout any ar gum ent s as issued on

RT1 and RT2. The com m and displays concise infor m at ion r egar ding t he m ode of oper at ion and t he NSAP addr ess of an I S-I S r out er . The ar ea pr efix in t he NSAP addr ess is also delineat ed. For exam ple, out put from RT1 show s RT1 is a Level 1 -2 r out er w it h 49.0001.0000.0000.0001.00 as t he NSAP and 49.0001 as t he ar ea I D. The out put also show s t hat CLNS for w ar ding, w hich in t his case im plies I S-I S r out ing, is enabled on t w o int er fa ces. This is confirm ed from t he configurat ion of RT1 in Ex am ple 10-1 , which show s I S-I S is enabled on Ser ial0/ 0 and Et her net 0/ 0. Ex a m p le 1 0- 2 sh ow cln s Com m a n d Ou t pu t

286

RT1#show clns Global CLNS Information: 2 Interfaces Enabled for CLNS NET: 49.0001.0000.0000.0001.00 Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64 ERPDU's requested on locally generated packets Intermediate system operation enabled (forwarding allowed) IS-IS level-1-2 Router: Routing for Area: 49.0001 RT2#show clns Global CLNS Information: 2 Interfaces Enabled for CLNS NET: 49.0002.0000.0000.0002.00 Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64 ERPDU's requested on locally generated packets Intermediate system operation enabled (forwarding allowed) IS-IS level-1-2 Router: Routing for Area: 49.0002 Th e show clns com m and proves useful for t roubleshoot ing problem s t hat relat e t o adj acency form at ion. For exam ple, it enables you t o quickly verify w het her a rout er is configured for t he appr opr iat e ar ea. The com m and pr o v ides a concise snapshot of t he I S-I S configur at ion and key param et ers. Configurat ion t im er inform at ion show n in t his out put pert ains t o bot h ESHs and I SHs. ESHs ar e r elat ed t o ES-I S, w hich is an aux iliar y pr ot ocol t hat suppor t s t he I SO CLNS env ir onm ent .

show clns protocol Cur r ent Cisco I OS r eleases offer s a show < la ye r 3 > pr ot ocol com m and for any of t he Lay er 3 pr ot ocols suppor t ed on Cisco r out er s. The show ip prot ocol com m and is popular and used frequent ly t o t roubleshoot I P rout ing problem s. The show clns pr ot ocol com m and has sim ilar im por t ance and displays sim ilar infor m at ion for t he CLNS envir onm ent .

Ex am ple 10- 3

show s t he

out put of t he fam iliar show ip pr ot ocol com m and for pur poses of com par ison w it h t he out put of t he show clns prot ocol com m and show n in Ex am ple 10-3 . Th e show ip prot ocol com m and show s I P r out ing pr ot ocols enabled on t he r out er and also t he neighbor rout ers t hat have supplied rout ing inform at ion ( for I S-I S in t his case) . The adm inist r at ive dist ances associat ed w it h each neighbor and t he last t im e it pr ovided an updat e ar e also show n. As show n in

Figure 10-1 ,

t he neighbors of RT1 are RT5 and RT2. Their loopback

addresses t o ident ify t hem . Ex a m p le 1 0- 3 show ip prot ocol Com m a n d Ou t p u t

RT1#show ip protocol Routing Protocol is "isis" Invalid after 0 seconds, hold down 0, flushed after 0 Outgoing update filter list for all interfaces is Incoming update filter list for all interfaces is Redistributing: isis Address Summarization: None Routing for Networks:

287

Ethernet0/0 Serial0/0 Passive Interface(s): Loopback0 Routing Information Sources: Gateway Distance 11.1.1.2 115 11.1.1.5 115

Last Update 00:02:25 00:02:15

Alt hough sim ilar t o t he I P equiv alent , t he out put of t he show clns prot ocol com m and feat ures slight ly different cont ent . The out put in Exam ple 10- 4 show s t hat I S-I S is enabled w it hout any t ag associat ed w it h t he I S-I S process. The m ode of operat ion, t he s yst em I D, and t he ar ea pr efix es ar e show n. The out put also show s t he sy st em I D 0000.0000.0001.00 w it h t he pseudonode num ber ( 00) appended. Unlike t he show clns com m and, t he show clns pr ot ocol com m and is ex plicit about w hich int er faces ar e enabled for I S-I S r out ing ( in t his case Serial0/ 0 and Et hernet 0/ 0) . I t also show s t hat I S-I S is configur ed for I P only on t hese int erfaces. The adm inist rat ive dist ance of 110 pert ains t o I S-I S for CLNP. The default adm inist rat ive dist ance of 115 is used for I P rout ing. This v alue is cor r ect ly show n in t he out put of t he show ip prot ocols com m and in

Figure 10- 3 .

Fig u r e 1 0- 3 . N e t w or k dia gr a m for

Exam ples 1 0 - 1 7 to 1 0 - 2 2 .

You m ight r ecall t hat t he not ion of adm inist r at ive dist ance is used in Cisco I OS Soft w ar e t o indicat e t he r elat iv e degr ee of preference bet ween different rout ing inform at ion sources for t he sam e Layer 3 pr ot ocol. The adm inist r at ive dist ance of I P r out es is 0 for connect ed r out es, for exam ple, 1 for st at ic rout es, 110 for OSPF rout es, and 115 for I S-I S. Som e lines in t he follow ing out put ( t he last few ) per t ain t o t he for m at st yle of I S-I S m et rics, and t hey ar e display ed as a r esult of t he m et ric- st yle w ide com m and in t he configur at ion. Wide m et rics are part icularly relevant for MPLS t raffic engineering, w hich w as nam ed by Cisco as Rout ing w it h Resource Reservat ion ( RRR) before st andardizat ion effort s st art ed in t he I ETF. Ex a m p le 1 0- 4 show clns prot ocol Com m a n d Ou t pu t

RT1#show clns protocol IS-IS Router: System Id: 0000.0000.0001.00 IS-Type: level-1-2 Manual area address(es): 49.0001 Routing for area address(es): 49.0001 Interfaces supported by IS-IS:

288

Serial0/0 - IP Ethernet0/0 - IP Redistributing: static Distance: 110 RRR level: none Generate narrow metrics: Accept narrow metrics: Generate wide metrics: Accept wide metrics:

none none level-1-2 level-1-2

show clns neighbors Th e show clns neighbors com m and is discussed in Chapt er 9 , w her e it is used t o ver ify t he pr oper oper at ion of I S-I S and t he st at us of adj acencies w it h dir ect ly connect ed I S-I S r out er s. Th e show clns neighbors com m and is synt act ically sim ilar t o com m ands such as show ip ospf ne ighbor s an d show ip e igr p ne ighbor s, w hich check t he st at us of adj acencies in OSPF and EI GRP, r espect ively. How ever , t her e is no r efer ence t o a Layer 3 r out ing pr ot ocol in t he show clns neighbors com m an d. Exam ple 10- 5

( r efer t o

show s an out put of t he show clns ne ighbor s com m a nd, capt ur ed fr om RT1

Figure 10-1 ) .

Adding t he det ail opt ion t o t he com m and displays m or e infor m at ion about

each k now n neighbor , such as t he ar ea I D and I P addr ess. Ex a m p le 1 0- 5 show clns ne ighbor s Com m a n d Ou t pu t

RT1#show clns neighbors System Id RT2 RT5

Interface Se0/0 Et0/0

SNPA *HDLC* 00d0.58eb.ff01

State Up Up

Holdtime 27 25

Type Proto L2 IS-IS L1 IS-IS

State Up

Holdtime 24

Type Proto L2 IS-IS

Up

23

L1

RT1#show clns neighbors detail System Id Interface SNPA RT2 Se0/0 *HDLC* Area Address(es): 49.0002 IP Address(es): 192.168.1.2* Uptime: 02:15:11 RT5 Et0/0 00d0.58eb.ff01 Area Address(es): 49.0001 IP Address(es): 10.1.1.5* Uptime: 02:15:11

IS-IS

Gener ally , t he out put show s t he follow ing for each neighbor:

•

Syst em I D — Sy st em ident ifier of t he neighbor .

•

I nt e r fa ce — Phy sical int er face w her e t he neighbor is connect ed.

•

SN PA ( Subne t w or k Point of At t a chm e nt ) — This is t he dat a -link t y pe or addr ess ( HDLC or PPP for serial and MAC addre ss for LANs) .

•

State — St at e of t he adj acency ( up, dow n, or init ) .

289

•

Holdt im e — This is t he int er val befor e t he adj acency expir es. The holdt im e is t he pr oduct of t he hello int er v al and hello m ult iplier . The default v alues of t he lat t er t w o par am et er s ar e 10 and 3, respect ively. The holdt im e is reset t o t he m axim um value ev er y t im e a hello pack et is r eceiv ed and decr eases unt il t he nex t r eset .

• •

Type — The t ype of adj acency ( Level 1, Level 2, or bot h) . Prot ocol— Rout ing pr ot ocol sour ce ( I S-I S or I SO I GRP) .

show clns interface Th e show clns int e r fa ce com m and is analogous t o t he show ip int e r fa ce com m and. Bot h com m ands provide prot ocol inform at ion regarding specific st at us and param et er set t ings. Wit hout any opt ion, t he show clns int e r fa ce com m and spills out infor m at ion about all int er faces on t he r out er , indicat ing w hich int er faces ar e enabled for CLNS for w ar ding and which are not . An int erface -specific opt ion provides an out put for only t he nam ed int erface, as show n in Exam ples 10-6 t hr ough 1 0 -8 . Ex a m p le 1 0- 6 Poin t- to- Point Se r ia l I nt e r fa ce

RT2#show clns interface Serial 0/0 (1)Serial0/0 is up, line protocol is up (2) Checksums enabled, MTU 1500, Encapsulation HDLC (3) ERPDUs enabled, min. interval 10 msec. (4) RDPDUs enabled, min. interval 100 msec., Addr Mask enabled (5) Congestion Experienced bit set at 4 packets (6) CLNS fast switching enabled (7) CLNS SSE switching disabled (8) DEC compatibility mode OFF for this interface (9) Next ESH/ISH in 2 seconds (10) Routing Protocol: IS-IS (11) Circuit Type: level-1-2 (12) Interface number 0x0, local circuit ID 0x100 (13) Level-1 Metric: 10, Priority: 64, Circuit ID: RT2.00 (14) Number of active level-1 adjacencies: 0 (15) Level-2 Metric: 10, Priority: 64, Circuit ID: RT2.00 (16) Number of active level-2 adjacencies: 1 (17) Next IS-IS Hello in 4 seconds Ex a m p le 1 0- 7 LAN I nt e r fa ce

RT2#show clns interface ethernet0/0 (1) Ethernet0/0 is up, line protocol is up (2) Checksums enabled, MTU 1497, Encapsulation SAP (3) ERPDUs enabled, min. interval 10 msec. (4) RDPDUs enabled, min. interval 100 msec., Addr Mask enabled (5) Congestion Experienced bit set at 4 packets (6) CLNS fast switching enabled (7) CLNS SSE switching disabled (8) DEC compatibility mode OFF for this interface (9) Next ESH/ISH in 4 seconds (10) Routing Protocol: IS-IS (11) Circuit Type: level-1-2 (12) Interface number 0x2, local circuit ID 0x2 (13) Level-1 Metric: 10, Priority: 64, Circuit ID: RT6.01 (14) Number of active level-1 adjacencies: 1 (15) Level-2 Metric: 10, Priority: 64, Circuit ID: RT6.01 (16) Number of active level-2 adjacencies: 0

290

(17) 1Next IS-IS LAN Level-1 Hello in 4 seconds (18) Next IS-IS LAN Level-2 Hello in 3 seconds Ex a m p le 1 0- 8 I nt e r fa ce N ot Ena ble d for CLN S

RT2#show clns interface FastEthernet1/0 (1) FastEthernet1/0 is administratively down, line protocol is down (2) CLNS protocol processing disabled Exam ple 10- 6

show s t he out put for a point -t o-point serial int erface,

Ex am ple 10- 7

for a broadcast

int er face, and Exam ple 10- 8 show s t he cor r esponding out put for an int er face on w hich I S-I S r out ing is not enabled. The lines in t he exam ples ar e num ber ed. Lines 3 t hr ough 9 in Exam ples 1 0 -6

and 1 0 - 7 are not part icularly im port ant for t roubleshoot ing I S-I S in I P environm ent s.

1 0 -1

com par es t he lines of int er est in Exam ples 10-6 and 1 0 -7 .

Table

Ta ble 1 0 - 1 . Ex pla na t ion of t he sh ow cln s in t e r fa ce Co m m a n d

Ex a m ple 1 0- 6 Poin t - t oLine Point 1 Line up, prot ocol up, im plies working int erface. 2 Encapsulat ion is HDLC and t he default CLNS MTU is 1500, m at ching t he default of t he physical MTU. 10 11

12

Ex a m ple 1 0- 7 Br oa dca st Line up, prot ocol up, im plies working int erface. All OSI - relat ed prot ocols ( CLNP, ESI S, I S- I S) are encapsulat ed 802.2( SAP) , lim it ing t he MTU t o 1497 byt es com pared t o t he 1500 MTU of t he physical int erface. I S- I S r out ing is enabled on I S- I S r out ing is enabled on t his t his int erface. int erface. Level 1 and Level 2 Level 1 and Level 2 adj acencies can adj acencies can be form ed be form ed on t his int erface. on t his int erface. I nt erface num ber ( 0x0) .

I nt erface num ber ( 0x2) .

Assigned by configur at ion t ur ns.

Assigned by configur at ion t ur ns. Used as an

Used as an index by SRM and SSM

index by SRM and SSM flags for flooding.

flags for flooding. Local circuit I D is 0x2, which is t he sam e as t he Local circuit I D is 0x100 for serial

int erface num ber for LAN-t y pe int er faces.

point -t o-point .

13

14

Met ric and priorit y for Level Met ric and priorit y for Level 1 1 ( default s) . ( default s) . The circuit I D on t he LAN is t he syst em I D of DI S + t he pseudonode num ber ( RT6.01) Zero Level 1 adj acencies One Level 1 adj acency ( wit h RT6) . over t his int erface.

291

15 16

17 18

Met ric and priorit y for Level 2 ( default s) . One Level 2 adj acency ( wit h RT1) over t his int erface. Point - to- point I I H due in four seconds. No ent ry.

Met ric and priorit y for Level 2 ( default s) . Zero Level 2 adj acencies over t his int erface. LAN Level 1 I I H due in four seconds. LAN Level 2 I I H due in t hree seconds.

Use of 802.2 ( SAP) Et her net encapsulat ion for CLNS pack et s ( CLNP, ES-I S, I S-I S) r esult s in t he CLNS m axim um t ra nsm ission unit ( MTU) being t hree byt es short er t han t he physical int erface MTU. I n t he SAP encapsulat ion, one byt e is used for t he Dest inat ion Service Access Point ( DSAP) , one byt e for t he Sour ce Ser vice Access Point ( SSAP) , and one byt e for t he cont rol fields. Tab le 1 0 -1 elabor at es on t he key lines in t he out put of t he show isis clns int erfa ce com m and t hat deser ve at t ent ion w hen t r oubleshoot ing I S-I S adj acency problem s. Cer t ainly, t he fir st t hing t o check is t he st at us of t he physical int er face ( lines 1 and 2) . Next , check lines 10 and 11; t hese indicat e w het her I S-I S is enabled on t he int er faces, as w ell as t he adj acency count .

show isis database Most I S-I S-r elat ed r out ing failur es ar e caused eit her by pr oblem s w it h adj acency for m at ion or rout e inst allat ion. The previous sect ions of t his chapt er discuss I S-I S-r elat ed com m ands, such as show clns int e r fa ce an d show clns ne ighbor s, for t r oubleshoot ing I S-I S adj acency pr oblem s. This sect ion focuses on t he show isis da t a ba se com m and, w hich pr ov es useful w hen t roubleshoot ing rout e inst allat ion problem s. I n Chapt er 9 , t he show isis da t a ba se com m and is m ent ioned as an im port ant t ool for verifying t he proper operat ion of I S-I S. As you m ight recall from previous chapt ers, I S-I S r ou t er s exchange LSPs w it h t heir neighbors aft er form ing adj acencies. The LSPs received from neighbors are t hen grouped int o Level 1 and Lev el 2 Link-St at e dat abases based on t he t ype of adj acencies exist ing on t he r out er . LSPs cont ain relevant inform at ion about t he originat or's rout ing environm ent , such as I P prefix infor m at ion, w hich is held in I P r eachabilit y TLVs. One of t he im por t ant st eps in t r oubleshoot ing r out ing pr oblem s is t o check t he Level 1 and Level 2 Link-St at e dat abases for t he presence of all expect e d LSPs. This is done w it h t he show isis da t a ba se com m and. Exam ple 10- 9

feat ur es a sam ple out put of t his com m and, w hich display s a sum m ar y of all k now n

LSPs in t he Level 1 and Level 2 dat abases. The keyw or d opt ions t o t he com m and , Le v e l 1 ( l1 ) or Le v e l 2 ( l2 ) , display eit her of t he t wo dat abases, respect ive ly. Ot her com m and opt ions, such as t he lsp id an d det ail, can be used separ at ely or com bined, as in show isis da t a ba se < lsp id> de t a il, t o display det ails about a specific LSP ( see Ex am ple 10-1 0 ) . The det ails of t he inform at ion in an LSP m ight provide clues about m issing rout ing inform at ion. Under st anding and correct ly int erpret ing t he inform at ion in an LSP is very crit ical t o solving rout ing problem s, such as m issing or inaccurat e rout ing inform at ion.

292

Ex a m p le 1 0- 9 show isis da t a ba se Co m m a n d

RT1#show isis database IS-IS Level-1 Link State Database LSPID LSP Seq Num LSP Checksum RT1.00-00 * 0x000000DD 0xE942 RT1.01-00 * 0x00000087 0xA810 RT5.00-00 0x00000F6E 0xED30 IS-IS Level-2 Link State Database LSPID LSP Seq Num LSP Checksum RT1.00-00 * 0x000000E5 0x7BFA RT2.00-00 0x00001C9C 0x5F3E RT1#

LSP Holdtime 528 1039 1159

ATT/P/OL 1/0/0 0/0/0 0/0/0

LSP Holdtime 1041 1135

ATT/P/OL 0/0/0 0/0/0

The out put in Exam ple 10- 9 is t aken from RT1, which is r epr esent ed in

Figure 10-1 .

This out put

displays t he separ at e Level 1 and Level 2 dat abases and list s all know n LSPs. Var ious at t r ibut es, such as LSP I D, LSP check sum , and so on, ar e list ed for each LSP. The Lev el 1 dat abase list s t hr ee k now n LSPs, t w o of w hich ar e gener at ed by RT1 ( also m ar k ed by an aster isk [ * ] ) . The t hir d is gener at ed by RT5. That bot h RT1 and RT5 have LSPs in t he Level 1 dat abase is an obv ious indicat ion t hat t hey ar e in t he sam e ar ea. One of t he LSPs, RT1.01-00, is a pseudonode LSP because it has a non -zero LSP num ber in t he LSP I D. This LSP is generat ed by RT1, which is t he designat ed int erm ediat e syst em ( DI S) . Level 2 dat abase show s only t w o LSPs, one each fr om RT1 and RT2. This m eans t hat RT2 is t he only Lev el 2 neighbor of RT1. This also im plies t hat RT1 has for m ed only a Lev el 1 adj acency w it h RT5 and only a Level 2 adj acency w it h RT2. This is because RT2 is in anot her ar ea and RT5 is in t he sam e ar ea but has been configur ed t o be a Lev el 1 -only rout er. All r out er s in t he sam e ar ea hav e t he sam e set of LSPs in t heir Lev el 1 dat abases. Sim ilarly, all Level 2 r out er s have an ident ical list of Level 2 LSPs. Any inconsist ency in t he Level 1 dat abase for r out er s in t he sam e ar ea or t he Level 2 dat abase for r out er s connect ed t o t he Level 2 backbone surely flags a problem . Level 1 LSPs generat ed by Level 2 -capable rout ers need t o be checked for t he ATT bit set t ing. The ATT bit flags a default r out e t o Level 1 r out er s in t he ar ea. I n Ex am ple 10-6 , RT1.00-00, or iginat ed by RT1, has t he ATT bit set . This indicat es t o RT5 t hat RT1 is connect ed t o t he back bone and can pr ov ide connect iv it y t o other ar eas.

Exam ple 10- 10

show s t he cont ent s of

RT2.0 0 -00 as displayed on RT1. The out put displays all I P pr efixes adver t ised by RT2 t o ot her Lev el 2 r out er s and can help y ou t o t r oubleshoot any pot ent ial r out ing pr oblem s associat ed w it h RT2. Not e t hat 11.1.1.6 or iginat es fr om RT6 ( r efer t o Figure 10-1 ) , but it is advert ised t hrough Level 2 t o t he r est of t he net w or k by RT2. The ot her I P pr efixes in t his LSP ar e dir ect ly connect ed net w or k s. Ex a m p le 1 0- 1 0 show isis da t a ba se det a il Com m a n d

RT1#show isis database level-1 RT2.00-00 detail IS-IS Level-2 LSP RT2.00-00 LSPID LSP Seq Num

LSP Checksum

LSP Holdtime

ATT/P/OL

293

RT2.00-00 0x00001C9C 0x5F3E Area Address: 49.0002 NLPID: 0xCC Hostname: RT2 IP Address: 11.1.1.2 Metric: 10 IS-Extended RT1.00 Metric: 10 IP 10.1.2.0/24 Metric: 0 IP 11.1.1.2/32 Metric: 10 IP 11.1.1.6/32 Metric: 10 IP 192.168.1.0/30

1015

0/0/0

show isis topology An out put of t he show isis t opology com m and is show n in Ex am ple 10-1 1 . This com m and pr ovides a view of t he r elat ive locat ion of all know n r out er s in bot h t he local ar ea and t he back bone. I n Figure 10- 2 , RT5 is a Level 1 rout er and RT1 is a Level 1 -2 r out er , bot h in ar ea 49.0001. RT2 and RT6 are bot h Level 1 -2 rout ers in area 49.0002. The Level 2 backbone expands across t he largest shaded oval. The sm aller ovals cover individual Level 1 areas. The out put of show isis t opology from RT1 indicat es only one pat h t o a Level 1 rout er ( RT5) connect s t o Et hernet 0/ 0 ( see Ex am ple 10-1 1 ) . The MAC addr ess of RT5 is also pr ov ided. Tw o pat hs ar e in t he backbone t o Level 2 r out er s, bot h going t hr ough Ser ial0/ 0. Fig u r e 1 0- 2 . Th e show isis t opology com m a n d.

Th e show isis t opology com m and is sim ilar t o t he show isis rout e com m and, w hich pr ovides, in essence, a Level 1 r out ing t able for I S-I S nodes in an ar ea. The show isis t opology com m and ex t ends show isis rout e t o cov er Lev el 2 nodes in pur e I P env ir onm ent s and does not need t he clns rout er com m and t o be configured on I S-I S-enabled int er faces as in t he case of t he show isis rout e com m an d. Ex a m p le 1 0- 1 1 show isis t opology Com m a n d

RT1#show isis topology IS-IS paths to level-1 routers System Id Metric Next-Hop RT1 -RT5 10 RT5 IS-IS paths to level-2 routers System Id Metric Next-Hop RT1 --

Interface

SNPA

Et0/0

00d0.58eb.ff01

Interface

SNPA

294

RT2 RT6

10 20

RT2 RT2

Se0/0 Se0/0

*HDLC* *HDLC*

show isis spf-log I n m ost Cisco rout ers, a rout e processor is responsible for running t he I S-I S pr ot ocol and calculat ing I S-I S-specific rout ing inform at ion. I S-I S r out es com pet e w it h sim ilar infor m at ion fr om ot her r out ing pr ot ocol sour ces, such as st at ic r out es and OSPF if enabled, for spot s in t he global I P r out ing t able of t he r out er . The rout e processor runs t he SPF process for I S-I S by using t he I S-I S Link-St at e dat abase as input t o calculat e I S-I S r out es. The SPF pr ocess is r un per iodically or t r igger ed based on net w or k act ivit y, such as LSP cont ent changes or r eceipt of a new LSP. Th e show isis spf- lo g com m and logs event s r elat ed t o t he SPF pr ocess pr oviding infor m at ion such as t r igger s and dur at ion of ev ent s. Rev iew ing t he SPF log can help y ou t o t r oubleshoot a chur n in t he net w or k. By st udying t he SPF log, for exam ple, you can det erm ine t he reason for a high spik e in CPU ut ilizat ion at t he r out e pr ocessor at t r ibut able t o t he I S-I S SPF pr ocess. A sam ple out put of show isis spf- log is show n in

Exam ple 10- 12 .

The out put show s t hat at

1: 56: 08, t he SPF pr ocess w as t r igger ed by som e ev ent r elat ing t o LSP RT1.01.00. The last colum n of t his line show s t he t r igger w as a TLVCONTENT on RT1.01-00. I n Chapter 9 , t he spfint e r va l configur a t ion com m and is discussed and a list of SPF ev ent t r igger s is pr ov ided. An augm ent ed list of t r igger s is pr ov ided in Table 10-2 . Ex a m p le 1 0- 1 2 show isis spf- log Com m a n d

RT1#show isis spf-log Level 1 SPF log When Duration Nodes 03:40:08 0 3 03:25:08 0 3 03:10:07 0 3 02:55:07 0 3 02:40:07 0 3 02:25:06 0 3 02:10:06 0 3 01:56:08 0 2 01:55:06 0 2 01:40:06 0 2 01:36:31 0 2 01:28:31 0 2 01:28:25 0 3 01:25:06 0 3 01:10:06 0 3

Count 1 1 1 1 1 1 1 1 1 1 1 2 1 1 1

Last trigger LSP

RT1.01-00

RT5.00-00 RT1.01-00 RT5.00-00

Triggers PERIODIC PERIODIC PERIODIC PERIODIC PERIODIC PERIODIC PERIODIC TLVCONTENT PERIODIC PERIODIC LSPEXPIRED NEWADJ TLVCONTENT NEWLSP PERIODIC PERIODIC

Ta ble 1 0 - 2 . Eve nt Tr igge r s of t he SPF Pr oce ss

Tr igge r Code AREASET ATTACHFLAG CLEAR

D e scr ipt ion Area change At t ached bit set t ing change Manual clear

295

CONFI G DELADJ DI S ES HI PPI TY LSPDB I P_DEF_ORI G I PDOWN I P_EXTERNAL I PI A I PUP NEWADJ NEWLEVEL NEWMETRI C NEWSYSI D PERI ODI C TLVCODE TLVCONTENT

Configurat i on change Adj acency delet ion DI S elect ion End syst em inform at ion change Overload bit st at e change Default inform at ion change Connect ed I P prefix down Rout e redist ribut ion change I nt erarea rout e change Connect ed I P prefix up New neighbor adj acency up I S- I S process level changed New m et ric assigned t o an int erface New syst em I D assigned Periodic SPF process ( LSPDB refresh int erval) LSP wit h a new TLV code field received LSP wit h changed TLV cont ent s received

Other Useful IS-IS Troubleshooting Commands Table 10- 3

list s a few m ore I S-I S com m ands useful for t roubleshoot ing. The com m ands are

gr ouped by CLNS and I S-I S, I P and Syst em . A few I S-I S and clns clea r com m ands ar e also pr ov ided. I ssuing t he cle a r com m and usually clear s dat a st r uct ur es and r eset s r elat ed obj ect s. The t able also feat ur es useful debugging com m ands, som e of w hich ar e discussed in t he nex t sect ion. Consult t he Cisco I OS Soft w are com m and reference guides m ent ioned in t he references at t he end of t his chapt er for m or e infor m at ion about t he use and im pact of each com m and befor e applying t hem on product ion rout ers ( specifically references 3 and 4) .

Ta ble 1 0 - 3 . I S- I S Usefu l Tr ou ble sh oot in g Com m a n ds

CLNS sh ow com m ands: show clns ca che show clns t r a ffic show isis rout e CLNS cle a r com m ands: cle a r clns ca che cle a r cln s e s- n e igh bor s

I S- I S show com m and: show clns r out e

I S- I S cle a r com m and: clea r isis *

296

cle a r clns is- n e igh bor s cle a r cln s n e igh bor s cle a r cln s r ou t e CLNS de bug com m ands: de bug clns e ve nt s de bug clns pa ck e t s de bug clns r out ing

Syst em show com m ands: show ve r sion sh ow r u n

I S- I S de bug com m ands: de bu g isis a dj- pa ck e t s de bug isis snp- pa ck e t s debug isis spf- event s debug isis spf- t r igge r s debug isis spf- st a t ist ics debug isis upda t e - pa ck e t s I P show com m ands: sh ow ip pr ot ocol sh ow ip r ou t e su m m a r y show ip t r a ffic

Debugging IS-IS Problems The CLNS and I S-I S debug com m ands show n in Table 10-3 ar e all use ful for t roubleshoot ing I SI S problem s. How ever, t he follow ing t hree debugging com m ands are t he m ost useful and are com m only used. Each is discussed in m or e det ail in t he follow ing subsect ions:

•

debug isis a dj - pack et s

•

de bug isis spf- e v e n t s

•

debug isis updat e - pa ck e t s

de bu g isis a dj - pa ck e t s As t he nam e im plies, t he debug isis adj - pack et s com m and helps debug adj acency pr oblem s by display ing infor m at ion about hello pack et s sent and r eceiv ed by a r out er . Adj acent r out er s send hellos t o each ot her t o m aint ain t he adj acency for each level of r out ing, w hich can be v iew ed by using t he debug isis adj - pa ck e t s com m and ( see Ex am ple 10-1 3 ) . Not e also t hat separ at e hello pack et s ar e ex changed for Lev el 1 and Lev el 2. Ex a m p le 1 0- 1 3 debug isis adj - pack et s Com m a n d Ou t p u t

RT1#debug isis adj-packets IS-IS Adjacency related packets debugging is on RT1# Mar 6 20:25:13: ISIS-Adj: Sending L2 IIH on Ethernet0/0, length 1497 Mar 6 20:25:13: ISIS-Adj: Sending L1 IIH on Ethernet0/0, length 1497 Mar 6 20:25:15: ISIS-Adj: Rec L1 IIH from 00d0.58eb.ff01 (Ethernet0/0), cir ty7 Mar 6 20:25:16: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L9 Mar 6 20:25:16: ISIS-Adj: rcvd state UP, old state UP, new state UP

297

Mar 6 20:25:16: Mar 6 20:25:16: Mar 6 20:25:16: Mar 6 20:25:18: Mar 6 20:25:19: Mar 6 20:25:19: Mar 6 20:25:21: Mar 6 20:25:22: Mar 6 20:25:25: Mar 6 20:25:25: cir ty7 Mar 6 20:25:25: Mar 6 20:25:25: L1L9 Mar 6 20:25:25: Mar 6 20:25:25:

ISIS-Adj: ISIS-Adj: ISIS-Adj: ISIS-Adj: ISIS-Adj: ISIS-Adj: ISIS-Adj: ISIS-Adj: ISIS-Adj: ISIS-Adj:

Action = ACCEPT Sending L2 IIH on Ethernet0/0, length 1497 Sending L1 IIH on Ethernet0/0, length 1497 Sending serial IIH on Serial0/0, length 1499 Sending L1 IIH on Ethernet0/0, length 1497 Sending L2 IIH on Ethernet0/0, length 1497 Sending L1 IIH on Ethernet0/0, length 1497 Sending L2 IIH on Ethernet0/0, length 1497 Sending L2 IIH on Ethernet0/0, length 1497 Rec L1 IIH from 00d0.58eb.ff01 (Ethernet0/0),

ISIS-Adj: Sending L1 IIH on Ethernet0/0, length 1497 ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type ISIS-Adj: rcvd state UP, old state UP, new state UP ISIS-Adj: Action = ACCEPT

de bu g isis spf - e ve n t s Th e debug isis spf- e ve n t s com m and enables debugging of ev ent s r elat ed t o t he SPF pr ocess. I t pr ov ides a r eal-t im e out put unlike t he show isis spf- lo g com m and, w hich provides a hist or y of SPF act iv it ies.

Ex am ple 10-1 4

shows an out put for t he sequence of event s

t hat occur w hen Et her net 0/ 0 is shut dow n on RT1 ( r efer t o Figure 10- 2 ) , causing it t o flag it s ow n LSP, and t hat lear ned fr om RT5, over t his int erface for SPF recalculat ion. The debug out put also show s SPF-r elat ed ev ent s and r ecom put at ion of t he Lev el 1 and Lev el 2 shor t est pat h t rees ( SPTs) . Ex a m p le 1 0- 1 4 D e bu ggin g SPF Eve n t s

RT1#debug isis spf-events RT1(config)#int e0/0 RT1(config-if)#shut RT1(config-if)#^Z Mar 6 20:17:26: recalculC Mar 6 20:17:26: recalculC Mar 6 20:17:28: Mar 6 20:17:28: Mar 6 20:17:28: Mar 6 20:17:28: Mar 6 20:17:28: Mar 6 20:17:28: Mar 6 20:17:28: 214 Mar 6 20:17:28: 208 Mar 6 20:17:28: 207 Mar 6 20:17:28: 209 Mar 6 20:17:28: 207 Mar 6 20:17:28: 112

ISIS-SPF: L1 LSP 1 (0000.0000.0001.00-00) flagged for ISIS-SPF: L1 LSP 5 (0000.0000.0005.00-00) flagged for ISIS-SPF: ISIS-SPF: ISIS-SPF: ISIS-SPF: ISIS-SPF: ISIS-SPF: ISIS-SPF:

Compute L1 SPT 3 nodes for level-1 Move 0000.0000.0001.00-00 to PATHS, metric 0 Add 0000.0000.0001.01-00 to TENT, metric 10 Add 0000.0000.0001 to L1 route table, metric 0 Move 0000.0000.0001.01-00 to PATHS, metric 10 Aging L1 LSP 1 (0000.0000.0001.00-00), version

ISIS-SPF: Aging L2 LSP 2 (0000.0000.0001.00-00), version ISIS-SPF: Aging L1 LSP 3 (0000.0000.0001.01-00), version ISIS-SPF: Aging L2 LSP 4 (0000.0000.0002.00-00), version ISIS-SPF: Aging L1 LSP 5 (0000.0000.0005.00-00), version ISIS-SPF: Aging L2 LSP 6 (0000.0000.0006.01-00), version

298

Mar 6 114 Mar 6 Mar 6 Mar 6 Mar 6 Mar 6 Mar 6 Mar 6 metric Mar 6 Mar 6 Mar 6 Mar 6 Mar 6 Mar 6 Mar 6 metric Mar 6 metric Mar 6 metric Mar 6 table, Mar 6 (rej) Mar 6 214 Mar 6 209 Mar 6 207 Mar 6 210 Mar 6 207 Mar 6 113 Mar 6 115 Mar 6

20:17:28: ISIS-SPF: Aging L2 LSP 7 (0000.0000.0006.00-00), version 20:17:28: 20:17:33: 20:17:33: 20:17:33: 20:17:33: 20:17:33: 20:17:33:

ISIS-SPF: ISIS-SPF: ISIS-SPF: ISIS-SPF: ISIS-SPF: ISIS-SPF: ISIS-SPF:

Aging L2 LSP 8 (0000.0000.0001.01-00), version 1 Compute L2 SPT 5 nodes for level-2 Move 0000.0000.0001.00-00 to PATHS, metric 0 Add 49.0001 to L2 route table, metric 0 Add 0000.0000.0001.01-00 to TENT, metric 10 considering adj to 0000.0000.0002 (Serial0/0)

20:17:33: 20:17:33: 20:17:33: 20:17:33: 20:17:33: 20:17:33: 20:17:33: 20d 20:17:33: d 20:17:33: d 20:17:33: m0 20:17:33:

ISIS-SPF: ISIS-SPF: ISIS-SPF: ISIS-SPF: ISIS-SPF: ISIS-SPF: ISIS-SPF:

(accepted) Add 0000.0000.0002.00-00 to TENT, metric 10 Next hop 0000.0000.0002 (Serial0/0) Move 0000.0000.0001.01-00 to PATHS, metric 10 Move 0000.0000.0002.00-00 to PATHS, metric 10 Add 49.0002 to L2 route table, metric 10 Redundant IP route 10.1.2.0/255.255.255.0,

ISIS-SPF: Redundant IP route 11.1.1.2/255.255.255.255, ISIS-SPF: Redundant IP route 11.1.1.6/255.255.255.255, ISIS-SPF: Add 192.168.1.0/255.255.255.252 to IP route ISIS-SPF: Next hop 0000.0000.0002/192.168.1.2 (Serial0/0)

20:17:33: ISIS-SPF: Aging L1 LSP 1 (0000.0000.0001.00-00), version 20:17:33: ISIS-SPF: Aging L2 LSP 2 (0000.0000.0001.00-00), version 20:17:33: ISIS-SPF: Aging L1 LSP 3 (0000.0000.0001.01-00), version 20:17:33: ISIS-SPF: Aging L2 LSP 4 (0000.0000.0002.00-00), version 20:17:33: ISIS-SPF: Aging L1 LSP 5 (0000.0000.0005.00-00), version 20:17:33: ISIS-SPF: Aging L2 LSP 6 (0000.0000.0006.01-00), version 20:17:33: ISIS-SPF: Aging L2 LSP 7 (0000.0000.0006.00-00), version 20:17:33: ISIS-SPF: Aging L2 LSP 8 (0000.0000.0001.01-00), version 2

de bu g isis u pda t e- pa ck e t s I n I S-I S, updat e infor m at ion is pr opagat ed by m eans of LSPs w hen changes occur in t he net w or k . CNSPs ar e sent only one t im e on point -to-point links aft er adj acency is for m ed, but per iodically on br oadcast links t o com pensat e for unr eliable adver t isem ent of LSPs over such m edia. The debug update - pack et s com m and displays any updat e -relat ed inform at ion, such as LSPs and CSNPs. The r elat ed com m and, debug isis snp- pa ck e t s, display s only sequence num ber pack et s w it h m or e det ail. Lines 1 and 2 of

Exam ple 10- 15

Exam ples 10-1 5

and 1 0 - 1 6 show sam ple out put s of t hese debugs.

are act ually console logs for flapping Serial0/ 0. The debug out put

st ar t s fr om line 3. I n line 3, a new LSP is built ; t his line t ur ns out t o be differ ent fr om t he older copy . This, t her efor e, t r igger s a full SPF t o be scheduled ( line 5) . Lines 6 and 7 show LSP ex change ov er Ser ial0/ 0. Lines 11 and 14 show t he one -t im e CSNP exchange w hen a point -t opoint link is first brought up. I n lines 15, 16, 17, a PSNP is cr eat ed t o obt ain com plet e LSPs for

299

nodes 2 and 5 as a r esult of t he CSNP ex change. I n line 18, a Lev el 1 LSP is built appar ent ly t o set t he at t ach bit . The change in t he Level 1 LSP r esult s in r unning SPF for Level 1 in line 23. I n line 22, t he n ew Lev el 1 LSP is sent out on Et her net 0/ 0 follow ed by a CSNP in line 23. Ex a m p le 1 0- 1 5 debug isis upda t e - pack et s Com m a nd Upda t e

RT1#debug isis update-packets (1) *Mar 2 23:25:02: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, chp (2) *Mar 2 23:25:03: %CLNS-5-ADJCHANGE: ISIS: Adjacency to RT2 (Serial0/0) Up, newy (3) *Mar 2 23:25:07: ISIS-Update: Building L2 LSP (4) *Mar 2 23:25:07: ISIS-Update: TLV contents different, code 16 (5) *Mar 2 23:25:07: ISIS-Update: Full SPF required (6) *Mar 2 23:25:07: ISIS-Update: Sending L2 LSP 0000.0000.0001.00-00, seq 160, ht0 (7) *Mar 2 23:25:07: ISIS-Update: Rec L2 LSP 0000.0000.0002.00-00, seq 1D16, ht 11, (8) *Mar 2 23:25:07: ISIS-Update: from SNPA *HDLC* (Serial0/0) (9) *Mar 2 23:25:07: ISIS-Update: LSP newer than database copy (10) *Mar 2 23:25:07: ISIS-Update: No change (11) *Mar 2 23:25:08: ISIS-SNP: Rec L2 CSNP from 0000.0000.0002 (Serial0/0) (12) *Mar 2 23:25:08: ISIS-SNP: Rec L2 PSNP from 0000.0000.0002 (Serial0/0) (13) *Mar 2 23:25:08: ISIS-SNP: PSNP entry 0000.0000.0001.00-00, seq 160, ht 1197 (14) *Mar 2 23:25:08: ISIS-Update: Sending L2 CSNP on Serial0/0 (15) *Mar 2 23:25:08: ISIS-Update: Build L2 PSNP entry for 0000.0000.0002.00-00, se6 (16) *Mar 2 23:25:08: ISIS-Update: Build L2 PSNP entry for 0000.0000.0006.00-00, se2 (17) *Mar 2 23:25:08: ISIS-Update: Sending L2 PSNP on Serial0/0 (18) *Mar 2 23:25:09: ISIS-Update: Building L1 LSP (19) *Mar 2 23:25:09: ISIS-Update: Important fields changed (20) *Mar 2 23:25:09: ISIS-Update: Important fields changed (21) *Mar 2 23:25:09: ISIS-Update: Full SPF required (22) *Mar 2 23:25:09: ISIS-Update: Sending L1 LSP 0000.0000.0001.00-00, seq 15A, ht0 (23) *Mar 2 23:25:09: ISIS-Update: Sending L1 CSNP on Ethernet0/0 Ex a m p le 1 0- 1 6 de bug isis sna p- pa ck e ts Com m a n d Ou t p u t

RT5#debug isis snp-packets IS-IS CSNP/PSNP packets debugging is on RT5# Mar 6 20:02:28: ISIS-SNP: Rec L1 CSNP from 0000.0000.0001 (Ethernet0/0) Mar 6 20:02:28: ISIS-SNP: CSNP range 0000.0000.0000.00-00 to FFFF.FFFF.FFFF.FFF Mar 6 20:02:28: ISIS-SNP: Same entry 0000.0000.0001.00-00, seq 15D Mar 6 20:02:28: ISIS-SNP: Same entry 0000.0000.0001.01-00, seq 104 Mar 6 20:02:28: ISIS-SNP: Same entry 0000.0000.0005.00-00, seq FEA

CLN S pin g a nd t r a ce r ou t e I n addit ion t o t he plet hor a of show and debug com m ands av ailable for m onit or ing and t roubleshoot ing I S-I S, t he ping clns an d t ra cerout e clns com m ands com e in handy for t r oubleshoot ing for w ar ding pr oblem s associat ed w it h t he CLNP pr ot ocol. For t hese com m ands

300

t o w or k in an env ir onm ent w it h dy nam ic I S-I S r out ing, y ou m ust use t he clns rout er isis com m and t o enable CLNP for w ar ding on t he r elevant int er faces. These com m ands pr ovide t he CLNP equivalent s of t he ping an d t racerout e for t est ing node r eachabilit y in t he I S-I S dom ain. These com m ands are irrelevant in I P-only env ir onm ent s w her e t he clns rout er isis com m and is not configur ed on t he r out er int er faces. How ever, t his is cert ainly a t roubleshoot ing capabilit y t hat som e net w ork operat ors m ight find useful. The CLNS ping an d t racerout e com m ands ar e indispensable t ools for dual I P/ CLNP or pur e I SO CLNS env ir onm ent s. Exam ples 10-1 7

t hrough 1 0 - 1 9 show t he configur at ion and CLNS r out ing envir onm ent of RT5.

Exam ples 10-2 0

and 1 0 - 21 show t he CNLS env ir onment fr om t he per spect ive of RT2, w hich is

locat ed in ar ea 49.0002. This capt ur e of t he gener al CLNS r out ing envir onm ent of

Figure 10-3

provides background inform at ion t o help you underst and t he CLNS ping an d t racerout e from RT5 t hr ough t he back bone t o RT6.

Ex am ples 10-2 2

ping from RT5 t o RT6.

is t he out put of t he de bu g cln s pa ck e t com m and fr om

Ex am ple 10- 24

Exam ple 10- 23 . Exam ples 10-2 5

and 1 0 - 23 show st andar d and ex t ended CLNS

and 1 0 - 26 dem onst rat e how t he st andard and ex t ended CLNS

t racerout e com m ands w or k . Ex a m p le 1 0- 1 7 Con figu r a t ion for RT5 in

Figure 1 0 - 3

RT5#show running-config clns routing ! interface Loopback0 ip address 11.1.1.5 255.255.255.255 ! interface Ethernet0/0 ip address 10.1.1.5 255.255.255.0 ip router isis clns router isis ! router isis passive-interface Loopback0 net 49.0001.0000.0000.0005.00 is-type level-1 metric-style wide Ex a m p le 1 0- 1 8 sh ow cln s rout e fr om RT5

RT5#show clns route CLNS Prefix Routing Table 49.0001.0000.0000.0005.00, Local NET Entry Ex a m p le 1 0- 1 9 show isis rout e fr om RT5

RT5#show isis IS-IS Level-1 System Id RT1 RT5

route Routing Table - version 13975 Next-Hop Interface SNPA RT1 Et0/0 00d0.58f7.8941 --

Default route out of area - (via 1 L2-attached IS) System Id Next-Hop Interface SNPA RT1 Et0/0 00d0.58f7.8941

Metric 10

State Up L2-IS

Metric 10

State Up

301

Ex a m p le 1 0- 2 0 show clns r out e fr om RT5

RT2#show clns route CLNS Prefix Routing Table 49.0002.0000.0000.0002.00, Local NET Entry 49.0001 [110/10] via RT1, IS-IS, Up, Serial0/0 49.0002 [110/0] via RT2, IS-IS, Up Ex a m ple 1 0 - 2 1 show isis rout e fr om RT2 fr om

Figure 1 0 - 3

RT2#show isis route IS-IS Level-1 Routing Table - version 6873 System Id Next-Hop Interface RT6 RT6 Et0/0 RT2 --

SNPA 00d0.58f7.8041

Metric 10

State Up

Ex a m p le 1 0- 2 2 CLN S St a nda rd p in g Co m m a n d

RT5#ping clns 49.0002.0000.0000.0006.00 Type escape sequence to abort. Sending 5, 100-byte CLNS Echos with timeout 2 seconds !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms Ex a m p le 1 0- 2 3 CLN S Ex t e nde d p in g Co m m a n d

RT5#ping Protocol [ip]: clns Target CLNS address: 49.0002.0000.0000.0006.00 Repeat count [5]: 2 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source CLNS address [49.0001.0000.0000.0005.00]: Include global QOS option? [yes]: Pad packet? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Sweep range of sizes [n]: Verbose reply? [no]: Type escape sequence to abort. Sending 2, 100-byte CLNS Echos with timeout 2 seconds !! Success rate is 100 percent (2/2), round-trip min/avg/max = 4/4/4 ms Ex a m p le 1 0- 2 4 CLN S Pa ck e t D e bu gs D u r in g CLN S pin g

RT5#debug clns packet Mar 10 07:50:43: CLNS: Originating packet, size 100 Mar 10 07:50:43: from 49.0001.0000.0000.0005.00 to 49.0002.0000.0000.0006.00 via 0000.0000.0001 (Ethernet0/0 00d0.58f7.8941) Mar 10 07:50:43: CLNS: Echo Reply PDU received on Ethernet0/0! Mar 10 07:50:43: CLNS: Originating packet, size 100 Mar 10 07:50:43: from 49.0001.0000.0000.0005.00 to 49.0002.0000.0000.0006.00 via 0000.0000.0001 (Ethernet0/0 00d0.58f7.8941) Mar 10 07:50:43: CLNS: Echo Reply PDU received on Ethernet0/0!

302

Ex a m p le 1 0- 2 5 CLN S St a nda rd t ra cerout e

RT5#traceroute clns 49.0002.0000.0000.0006.00 Type escape sequence to abort. Tracing the route to 49.0002.0000.0000.0006.00 1 49.0001.0000.0000.0001.00 0 msec ! 0 msec ! 0 msec ! 2 49.0002.0000.0000.0002.00 0 msec ! 0 msec ! 0 msec ! 3 49.0002.0000.0000.0006.00 0 msec ! 0 msec ! 0 msec ! Ex a m p le 1 0- 2 6 CLN S Ex t e nde d t racerout e Com m a n d

RT5#traceroute Protocol [ip]: clns Target CLNS address: 49.0002.0000.0000.0006.00 Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Extended commands [n]: y Source CLNS address [49.0001.0000.0000.0005.00]: Include global QOS option? [yes]: Pad packet? [no]: Validate reply data? [no]: Data pattern [0x60CD]: Sweep range of sizes [n]: Verbose reply? [no]: Type escape sequence to abort. Tracing the route to 49.0002.0000.0000.0006.00 1 49.0001.0000.0000.0001.00 4 msec ! 0 msec ! 0 msec ! 2 49.0002.0000.0000.0002.00 0 msec ! 0 msec ! 0 msec ! 3 49.0002.0000.0000.0006.00 0 msec ! 0 msec ! 0 msec !

Troubleshooting IS-IS Routing Problems The discussions in t he pr evious sect ions of t his chapt er focus on t ools and com m ands, r anging from sim ple t o com plex, needed for t roubleshoot ing I S-I S pr oblem s. These sect ions pr ov ide a good foundat ion for discussing act ual pr oblem s and t r oubleshoot ing m et hodology. Com m on I S-I S r out ing pr oblem s fall under t he follow ing t w o br oad cat egor ies:

• •

Adj acency form at ion problem s Rout e m aint enance problem s

During norm al operat ion, I S-I S r out er s for m and m aint ain adj acencies w it h each ot her by using hello pack et s. Rout ing infor m at ion is t hen ex changed by flooding LSPs, w hich ar e st or ed in appr opr iat e Link-St at e dat abases ( Level 1 or Level 2) . Sequence num ber packet s ( CSNPs and PSNPs) pr ov ide cont r ol for t he flooding pr ocess and ensur e dat abase sy nchr onizat ion. All t hese pr ocesses need t o occur successfully t o ensur e accur at e dissem inat ion of r out ing inform at ion in t he I S-I S dom ain. Any failures result in inconsist encies t hat ult im at ely result in r out ing pr oblem s. The follow ing sect ions ident ify pr oblem s and list t he cor r esponding w ays t o isolat e t hose pr oblem s.

303

IS-IS Adjacency Formation Problems Adj acency form at ion problem s are com m on I S-I S failur es. They m ainly occur as a r esult of rout er m isconfigurat ion, hardware and soft ware failures, int eroperabilit y problem s bet w een different I OS Soft w are releases, and int eroperabilit y problem s bet w een rout ers from different vendor s. Adj acency pr oblem s ar e easier t o isolat e t han r out ing pr oblem s. The follow ing list of adj acency pr oblem s ar e discussed in t his sect ion:

•

Mism at ched Level 1 and Level 2 int erfaces

•

Misconfigured NSAPs

•

Duplicat e syst em I Ds

• •

Mism at ched MTUs Misconfigured I P addresses and Subnet s

M ism a t ch e d Le ve l 1 a n d Le ve l 2 I n t e r fa ce s The default m ode of oper at ion for Cisco r out er s r unning I S-I S is Level 1 -2. I n t his m ode, a r out er can for m bot h Lev el 1 and Lev el 2 adj acencies w it h neighbor s in t he sam e ar ea and for m only Level 2 adj acencies w it h neighbor s in differ ent ar eas. Figure 10-4 diagr am s such a configur at ion. I n t he out put show n in Ex am ple 10-2 3 , RT1 form s a Level 1 -2 adj acency w it h RT5, w hich is in t he sam e ar ea ( 49.0001) , but for m s only a L2 adj acency w it h RT2, w hich is in ar ea 49.0002. The default Level 1 -2 m ode can be m odified for all int erfaces on t he rout er by using t he rout er configurat ion-level com m and I S- t ype or for a specific int erface w it h t he int erface level configur at ion com m and isis circuit - t ype le v e l [ le ve l- 1 | le ve l- 2 ] . I f RT1 is m isconfigur ed as a Lev el 1 only on Ser ial0/ 0 using any of t he pr ev iously m ent ioned com m ands, it loses t he adj acency w it h RT2. Consequent ly, t he dom ain w ill be par t it ioned and t her e w ill be no com m unicat ion bet w een ar ea 49.0001 and ar ea 49.0002. This behav ior is confir m ed in Ex am ple 10-2 7 . Fig u r e 1 0- 4 . Te st n e t w or k for st u dyin g m ism a t ch e d le ve ls of r ou t in g be t w e e n connect ed int e r fa ce s.

Ex a m p le 1 0- 2 7 sh ow cln s n e igh bor s D ur ing N or m a l Ope r a t ion

RT1#show clns neighbors System Id RT5 RT2

Interface Et0/0 Se0/0

SNPA 00d0.58eb.ff01 *HDLC*

State Up Up

Holdtime 26 23

Type Protocol L1L2 IS-IS L2 IS-IS

304

Ex a m p le 1 0- 2 8 Sim ula t ing M ism a t che d Le ve ls of Rout ing on a Se r ie l Link ( r e fe r t o Figure 1 0 - 4

RT1#conf t Enter configuration commands, one per line.

End with CNTL/Z.

RT1(config)#router isis RT1(config-router)#is-type level-1 RT1(config-router)# ^Z

RT1#show clns neighbors System Id RT5 RT2

Interface Et0/0 Se0/0

SNPA 00d0.58eb.ff01 *HDLC*

State Up Up

Holdtime 26 280

Type Protocol L1 IS-IS IS ES-IS

I n exam ple 10-2 8 , t he show clns neighbors out put show s t hat RT1 dr opped t he I S-I S adj acency w it h RT2 and show s inst ead an ES-I S adj acency in place. This is because t he ES-I S adj acency process runs independent ly of I S-I S, a nd it is sust ained by ESHs r at her t han I I Hs. Also because RT1 w as m ade globally a Level 1 r out er w it h t he I S-t ype com m and, it has for m ed only a Level 1 I S-I S adj acency w it h RT5.

M iscon figu r e d N SAPs ( N ETs) Each I S-I S node m ust have at least one NSAP addr ess ( NET) t o ident ify it as a net w ork node. This NET consist s of t he ar ea I D of t he node, t he Sy st em I D, and a 0 -value NSEL. The syst em I D is r equir ed t o be unique w it hin t he ar ea; t he NSEL v alue is fix ed at 0x 00. The ar ea I D ( also r efer r ed t o as t he area prefix ) m ust be t he sam e for all nodes in t he sam e ar ea. For nodes w it h m ult iple NETs, t he sy st em I D m ust be t he sam e in all of t hem , and at least one of t he ar ea pr efix es m ust be shar ed w it h anot her node in t he sam e ar ea. The effect of m isconfigur ing a NET is illust r at ed in Figure 10- 5 . I n t his exam ple, RTE, RTF, and RTG ar e m eant t o be t oget her in ar ea 49.0001. They ar e also m eant t o for m bot h Lev el 1 and Lev el 2 adj acencies. Fig u r e 1 0- 5 . Te st n e t w or k for st u dy in g m iscon figu r e d N SAP pr oble m .

The out put s of t he show clns neighbors com m and fr om RTE, RTF, and RTG show n in Exam ple 1 0 -2 9

indicat e RTE form ed only Level 2 adj acencies w it h RTF and RTG. How ever, RTF and RTG

form ed Level 1 -2 adj acencies w it h each ot her as ex pect ed. This cr eat es a suspicion about t he configur at ion and oper at ion of RTE.

305

Ex a m p le 1 0- 2 9 Tr ouble shoot ing M isconfigur e d N SAPs

RTE#show clns neighbors System Id RTF RTG

SNPA 0000.0c76.f098 0000.0c76.f096

Interface Et0 Et0

State Up Up

Holdtime 27 26

Type Protocol L2 IS-IS L2 IS-IS

State Up Up Up

Holdtime 27 9 28

Type L2 L2 L1L2

RTF#show clns neighbors System Id RTB RTE RTG

SNPA *HDLC* 0000.0c76.f1fa 0000.0c76.f096

Interface Se0 Et0 Et0

Protocol IS-IS IS-IS IS-IS

RTG#show clns neighbors System Id RTE RTF

SNPA 0000.0c76.f1fa 0000.0c76.f098

Interface Et0 Et0

State Up Up

Holdtime Type Protocol 18 L2 IS-IS 24 L1L2 IS-IS

A glance at t he MAC addresses under t he SNPA colum n of Ex am ple 10-2 9 show s t hat RTE has a higher MAC addr ess t han RTF and RTG, so w it h each node r et aining t he default int er face pr ior it y value, RTE should be b ot h t he Lev el 1 and Lev el 2 DI S. This is confir m ed by t he show clns int e r fa ce out put of RTE, show n in Ex am ple 10-3 0 . The value of t he circuit I D gives t hat clue. In

Ex am ple 10- 31 ,

RTF point s correct ly t o RTE as t he Level 2 DI S but incorrect ly t o it self as t he

Level 1 DI S. This im plies t hat t her e is a pr oblem w it h Level 1 com m unicat ion. Because t his is a n ew set up and all t he default s hav e not been t am per ed w it h, t he only fact or t hat m ight dict at e t he t ype of adj acency for m ed is t he ar ea pr efix. Fur t her inspect ion of t he NET configur ed on RTE show s t hat it w as m isconfigur ed w it h 49.0002.0000.0000.0002.00 r ather t han 47.0002.0000.0000.0002.00. This area I D m ism at ch result ed in RTF and RTG form ing only Level 2 adj acencies w it h RTE. Ex a m p le 1 0- 3 0 D e t e r m in ig t h e D I S on t h e LAN ( r e fe r t o

Figu r e 1 0 - 5 )

RTE#show clns interface e0 Ethernet0 is up, line protocol is up Checksums enabled, MTU 1497, Encapsulation SAP ERPDUs enabled, min. interval 10 msec. RDPDUs enabled, min. interval 100 msec., Addr Mask enabled Congestion Experienced bit set at 4 packets CLNS fast switching enabled CLNS SSE switching disabled DEC compatibility mode OFF for this interface Next ESH/ISH in 4 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x0, local circuit ID 0x1 Level-1 Metric: 10, Priority: 64, Circuit ID: RTE.01 Number of active level-1 adjacencies: 0 Level-2 Metric: 10, Priority: 64, Circuit ID: RTE.01 Number of active level-2 adjacencies: 2 Next IS-IS LAN Level-1 Hello in 1 seconds Next IS-IS LAN Level-2 Hello in 1 seconds Ex a m p le 1 0- 3 1 Confir a m a t ion of D I S Conflict

RTF#show clns interface

306

Ethernet0 is up, line protocol is up Ethernet0 is up, line protocol is up Checksums enabled, MTU 1497, Encapsulation SAP ERPDUs enabled, min. interval 10 msec. RDPDUs enabled, min. interval 100 msec., Addr Mask enabled Congestion Experienced bit set at 4 packets CLNS fast switching enabled CLNS SSE switching disabled DEC compatibility mode OFF for this interface Next ESH/ISH in 4 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x0, local circuit ID 0x1 Level-1 Metric: 10, Priority: 64, Circuit ID: RTF.01 Number of active level-1 adjacencies: 1 Level-2 Metric: 10, Priority: 64, Circuit ID: RTE.01 Number of active level-2 adjacencies: 2

D u p lica t e Sy st e m I D s in a n Ar e a All I S-I S nodes in an ar ea m ust hav e t he sam e ar ea pr efix and a unique sy st em I D. I f a node has m ult iple NETs configured, each address m ust ret ain t he sam e syst em I D. This is a crit ical pr ot ocol r equir em ent , especially because t he syst em I D for m s par t of t he LSPI D, and uniqueness is required t o ident ify t he ow ner s of LSPs flooded w it hin t he ar ea. When differ ent nodes in t he ar ea ar e er r oneously configur ed w it h t he sam e sy st em I D, t he pr oblem is det ect ed and each node logs appr opr iat e er r or m essages t o t hat effect ( see Exam ple 10- 32 ) . I f t he nodes are direct ly connect ed, each rout er im m ediat ely det ect s t he pr oblem as it exchanges hellos t o est ablish adj acency. Consequent ly, t he adj acency fails. I f t hey ar e not dir ect ly connect ed, how ev er , t hey ov er w r it e each ot her 's LSP for som e t im e unt il t he I S-I S pr ocess det er m ines, based on t he fr equency of occur r ence, t hat t he pr oblem is because of duplicat e syst em I Ds and logs appr opr iat e er r or m essages.

Exam ple 10- 33

show s t he out put of t he debug

isis adj - p a ck e t com m and for a duplicat e sy st em I D sit uat ion bet w een dir ect ly connect ed neighbor s. Ex a m p le 1 0- 3 2 Loggin g of D u plica t e Syst e m I D Er r or s

RT1#show logging Mar 10 16:41:20: %CLNS-3-BADPACKET: ISIS: LAN L1 hello, Duplicate system ID det) Mar 10 16:42:22: %CLNS-3-BADPACKET: ISIS: LAN L1 hello, Duplicate system ID det) Mar 10 16:43:21: %CLNS-3-BADPACKET: ISIS: LAN L1 hello, Duplicate system ID det) Ex a m p le 1 0- 3 3 D e bugging D uplica t e Syst e m I D Sce na r ios

RT1#debug isis adj-packet Mar 10 16:41:53: ISIS-Adj: Mar 10 16:41:55: ISIS-Adj: cir ty7 Mar 10 16:41:55: ISIS-Adj: Mar 10 16:41:56: ISIS-Adj: Mar 10 16:41:58: ISIS-Adj: cir ty7 Mar 10 16:41:58: ISIS-Adj: Mar 10 16:41:59: ISIS-Adj:

Sending L1 IIH on Ethernet0/0, length 1497 Rec L1 IIH from 00d0.58eb.ff01 (Ethernet0/0), Duplicate system id Sending L1 IIH on Ethernet0/0, length 1497 Rec L1 IIH from 00d0.58eb.ff01 (Ethernet0/0), Duplicate system id Sending L1 IIH on Ethernet0/0, length 1497

307

Mar 10 16:42:00: ISIS-Adj: Rec L1 IIH from 00d0.58eb.ff01 (Ethernet0/0), cir ty7 Mar 10 16:42:00: ISIS-Adj: Duplicate system id

M ism a t ch e d I n t e r f a ce M TU s I SO 10589 m andat es t he padding of t r ansm it t ed hello pack et s, w hich ar e used t o est ablish and m aint ain adj acencies, t o t he m axim um possible dat a size a r out er can r eceive and pr ocess on an int er face. This pr ov ides a pack et-size negot iat ion m echanism , w hich ensures adj acency form s only bet w een syst em s t hat can receive and process t he larges t possible dat a size t hat t he ot her can t r ansm it . Cisco I OS Soft w ar e adher es t o t his specificat ion by padding hellos t o t he full MTU size of t he int erface. Consequent ly, in t he default m ode of operat ion, I S-I S r out er s r unning Cisco I OS Soft w ar e do not for m adj acencies if t heir physical int erface MTU values do not m at ch. Verificat ion of possible MTU m ism at ch should, t herefore, be considered w hen t roubleshoot ing adj acency problem s.

Ex am ples 10-3 4

and 1 0 - 35 , w hich are based on Figur e 10-6 , illust rat e adj acency

failure result ing from an MTU m ism at ch.

Figure 10- 6

show s t w o r out er s connect ed back -to-back

ov er a ser ial link . As seen in t he debug out put in Ex am ples 10-3 4 and 1 0 - 35 , t he adj acency of t he ser ial link is dr opped at appr oxim at ely 20: 44: 16 w hen t he MTU on RT2 is changed fr om 1500 t o 2000. Fr om t hen on, RT2 p ads it s hellos t o 1999, w hich ar e ignor ed by RT1. Aft er t hr ee hellos ar e ignor ed by RT1, t he hello holdt im e expir es, t he adj acency is dr opped, and an adj acency change ev ent is logged. Fig u r e 1 0- 6 . I n v e st iga t in g a n M TU m ism a t ch pr oble m .

RT1 r et ains an ES-I S adj acency w it h RT2; how ever , RT2 r eceives and pr ocesses t he sm aller 1 4 9 9 -byt e hellos from RT1 and put s t he I S-I S adj acency in init st at e, hoping t o com plet e t he t hree -w ay handshake t o est ablish full I S-I S adj acency. The I S-I S adj acency is never com plet ed as long as t he t w o RT2's MTU r em ain lar ger t han t hat of RT1. Ex a m p le 1 0- 3 4 D e bugging a n M TU M ism a t ch on RT1

RT1#debug isis adj-packet IS-IS Adjacency related packets debugging is on Mar 10 20:43:56: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 Mar 10 20:43:59: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2 Mar 10 20:43:59: ISIS-Adj: rcvd state UP, old state UP, new state UP

308

Mar 10 20:43:59: Mar 10 20:44:05: Mar 10 20:44:13: Mar 10 20:44:22: Mar 10 20:44:29: Down, hod Mar 10 20:44:29: Mar 10 20:44:31: Mar 10 20:44:40: Mar 10 20:44:48: Mar 10 20:44:57: Mar 10 20:45:07:

ISIS-Adj: Action = ACCEPT ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 %CLNS-5-ADJCHANGE: ISIS: Adjacency to RT2 (Serial0/0) ISIS-Adj: ISIS-Adj: ISIS-Adj: ISIS-Adj: ISIS-Adj: ISIS-Adj:

L2 adj count 0 Sending serial Sending serial Sending serial Sending serial Sending serial

IIH IIH IIH IIH IIH

on on on on on

Serial0/0, Serial0/0, Serial0/0, Serial0/0, Serial0/0,

length length length length length

1499 1499 1499 1499 1499

RT1#show clns neighbors System Id RT2

Interface Se0/0

SNPA *HDLC*

State Up

Holdtime 250

Type Protocol IS ES-IS

RT1#show clns interface serial0/0 Serial0/0 is up, line protocol is up Checksums enabled, MTU 1500, Encapsulation HDLC ERPDUs enabled, min. interval 10 msec., last sent 14:13:29 RDPDUs enabled, min. interval 100 msec., Addr Mask enabled Congestion Experienced bit set at 4 packets CLNS fast switching enabled CLNS SSE switching disabled DEC compatibility mode OFF for this interface Next ESH/ISH in 28 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x1, local circuit ID 0x100 Level-1 Metric: 10, Priority: 64, Circuit ID: RT1.00 Number of active level-1 adjacencies: 0 Level-2 Metric: 10, Priority: 64, Circuit ID: RT1.00 Number of active level-2 adjacencies: 0 Next IS-IS Hello in 6 seconds Ex a m p le 1 0- 3 5 D e bugging a n M TU M ism a t ch on RT2

RT2(config)#interface s 0/0 RT2(config-if)#mtu 2000 RT2(config-if)#^Z RT2#debug isis adj-packet IS-IS Adjacency related packets debugging is on RT2# Mar 10 20:44:16: ISIS-Adj: Sending serial IIH on Serial0/0, length 1999 Mar 10 20:44:21: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L9 Mar 10 20:44:21: ISIS-Adj: rcvd state DOWN, old state UP, new state INIT Mar 10 20:44:21: ISIS-Adj: Action = GOING DOWN Mar 10 20:44:21: %CLNS-5-ADJCHANGE: ISIS: Adjacency to RT1 (Serial0/0) Down, nes Mar 10 20:44:21: ISIS-Adj: L2 adj count 0 Mar 10 20:44:21: ISIS-Adj: Sending serial IIH on Serial0/0, length 1999 Mar 10 20:44:29: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L9 Mar 10 20:44:29: ISIS-Adj: rcvd state DOWN, old state DOWN, new state INIT Mar 10 20:44:29: ISIS-Adj: Action = GOING UP, new type = L2 Mar 10 20:44:29: ISIS-Adj: New serial adjacency

309

Mar 10 Mar 10 L1L9 Mar 10 Mar 10 Mar 10 Mar 10

20:44:29: ISIS-Adj: Sending serial IIH on Serial0/0, length 1999 20:44:38: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type 20:44:38: 20:44:38: 20:44:38: 20:44:47:

ISIS-Adj: ISIS-Adj: ISIS-Adj: ISIS-Adj:

rcvd state DOWN, old state INIT, new state INIT Action = GOING UP, new type = L2 Sending serial IIH on Serial0/0, length 1999 Sending serial IIH on Serial0/0, length 1999

RT2#show clns neighbors System Id RT1

Interface Se0/0

SNPA *HDLC*

State Init

Holdtime 27

Type Protocol L2 IS-IS

RT2#show clns interface Serial0/0 is up, line protocol is up Checksums enabled, MTU 2000, Encapsulation HDLC ERPDUs enabled, min. interval 10 msec., last sent 12:52:30 RDPDUs enabled, min. interval 100 msec., Addr Mask enabled Congestion Experienced bit set at 4 packets CLNS fast switching enabled CLNS SSE switching disabled DEC compatibility mode OFF for this interface Next ESH/ISH in 7 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x0, local circuit ID 0x100 Level-1 Metric: 10, Priority: 64, Circuit ID: RT2.00 Number of active level-1 adjacencies: 0 Level-2 Metric: 10, Priority: 64, Circuit ID: RT2.00 Number of active level-2 adjacencies: 0 Next IS-IS Hello in 7 seconds Som e net w ork operat ors hold t he not ion t hat because default dat a -link capabilit ies are m ost ly st andardized, know n up front , and configurable, padding hellos t o ensur e MTU consist ency unnecessar ily w ast es pr ecious net w or k bandw idt h. This has pr om pt ed t he int r oduct ion of a com m and in I OS t o t ur n off hello padding. Tw o com m ands ar e av ailable t o suppor t t his capabilit y: [ no] hello pa dding [ m ult i- poin t | poin t- to- point ] — Can be applied globally at t he r out er lev el [ n o] isis h e llo pa ddin g— For int erface -level configurat ion Exam ple 10- 36

illust r at es t he effect of disabling I S-I S hello padding on a ser ial int er face and

changing t he MTU t o 2000. The debug isis adj - pa ck e t s com m and show s t he size of hello packet s t o be only 38 byt es w it h padding of hellos disabled. Despit e t he higher MTU on one side on t he link , t he adj acency is r et ained. Ex a m p le 1 0- 3 6 D isa blin g H e llo Pa ddin g

RT1(config-router)#int se0/0 RT1(config-if)#no isis hello padding RT1(config-if)#mtu 2000 RT1(config-if)#^Z

310

RT1#show clns interface Serial0/0 Serial0/0 is up, line protocol is up Checksums enabled, MTU 2000, Encapsulation HDLC ERPDUs enabled, min. interval 10 msec. RDPDUs enabled, min. interval 100 msec., Addr Mask enabled Congestion Experienced bit set at 4 packets CLNS fast switching enabled CLNS SSE switching disabled DEC compatibility mode OFF for this interface Next ESH/ISH in 40 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x1, local circuit ID 0x100 Level-1 Metric: 10, Priority: 64, Circuit ID: RT2.00 Number of active level-1 adjacencies: 0 Level-2 Metric: 10, Priority: 64, Circuit ID: 0000.0000.0000.00 Number of active level-2 adjacencies: 1 Next IS-IS Hello in 3 seconds No hello padding RT1#debug isis adj-packets *Mar 1 03:41:57: type L19 *Mar 1 03:41:57: *Mar 1 03:41:57: *Mar 1 03:41:58: *Mar 1 03:42:06: type L19 *Mar 1 03:42:06: *Mar 1 03:42:06: *Mar 1 03:42:06:

ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir ISIS-Adj: ISIS-Adj: ISIS-Adj: ISIS-Adj:

rcvd state UP, old state UP, new state UP Action = ACCEPT Sending serial IIH on Serial0/0, length 38 Rec serial IIH from *HDLC* (Serial0/0), cir

ISIS-Adj: rcvd state UP, old state UP, new state UP ISIS-Adj: Action = ACCEPT ISIS-Adj: Sending serial IIH on Serial0/0, length 38

RT1#show clns neighbors System Id RT2

Interface Se0/0

SNPA *HDLC*

State Up

Holdtime 22

Type Protocol L2 IS-IS

M iscon figu r e d I P Addr e sse s a n d Su bn e t s Originally, t he I S-I S prot ocol relied on only I S-I S hellos t o form and m aint ain adj acencies, using a t hr ee-w ay handshak e on br oadcast link s and a t w o -w ay handshak e on point -to-point link s, all independent of t he I P configurat ion. The increasing popularit y of I S-I S for r out ing I P has pr om ot ed v ar ious enhancem ent s bot h w it hin t he I ETF and in v endor-specific im plem ent at ions t hrough feat ure int roduct ions. One such feat ure int roduced recent ly int o Cisco I OS Soft ware releases req uires direct ly connect ed I P rout ers using I S-I S for r out ing t o be also connect ed t o t he sam e I P subnet in or der t o for m adj acencies. This is not t he case in older Cisco I OS Soft w are releases, w here direct ly connect ed rout ers could st ill form I S- I S adj acencies ev en t hough t hey w er e not pr oper ly configur ed t o be on t he sam e I P subnet . Recent changes in I OS r equir e t he sour ce I P addr ess of an I P neighbor t o be validat ed before bringing up t he adj acency. This behavior is im plem ent ed in Cisco I OS Soft w are 12.0S releases, w hich are opt im ized for I P net w orks. This m akes verificat ion of t he I P address configurat ion an im port ant st ep in t roubleshoot ing I S-I S adj acency pr oblem s.

311

The effect of I P addr ess m isconfigur at ion is illust r at ed in t he follow ing debugging and show com m and out put ( based on Figur e 10-7 ) . I n Ex am ple 10- 37 , t he I P addr ess of RT2's ser ial int er face is changed t o 192.168.5.2/ 30. This er r oneous ent r y causes adj acency t o be invalidat ed at RT1 and logging of an adj acency change m essage. I n t his case, t he I S-I S adj acency dr ops and it is r eplaced by an ES-I S adj acency. The debugging out put show n in Exam ple 10- 32 includes an error, " I SI S-Adj : No usable I P int e r face addr esses in ser ial I I H fr om 0." I P unnum ber ed configur at ions ar e not affect ed by t he r equir em ent t hat adj acent neighbor s m ust be on t he sam e subnet . Fig u r e 1 0- 7 . Te st n e t w or k for in ve st iga t in g I P a ddr e ss a n d su bn e t m iscon figu r a t ion .

Ex a m p le 1 0- 3 7 Sim ula t ing a nd D e bugging M isconfigur e d I P Addr e sse s

RT2#config terminal Enter configuration commands, one per line. End with CNTL/Z. RT2(config)#int s0/0 RT2(config-if)#ip address 192.168.5.2 255.255.255.252 RT2(config-if)#^Z RT2#show clns neighbors System Id RT1 RT6

Interface Se0/0 Et0/0

SNPA *HDLC* 00d0.58f7.8041

State Up Up

Holdtime 257 7

Type Protocol IS ES-IS L1 IS-IS

State Up Up

Holdtime 284 26

Type Protocol IS ES-IS L1 IS-IS

RT1#show clns neighbors System Id RT2 RT5

Interface Se0/0 Et0/0

SNPA *HDLC* 00d0.58eb.ff01

RT1#debug isis adj-packets Mar 10 21:44:19: Mar 10 21:44:20: L1L9 Mar 10 21:44:20: from 0 Mar 10 21:44:24: Down, hod Mar 10 21:44:24: Mar 10 21:44:27: Mar 10 21:44:30: L1L9 Mar 10 21:44:30: from 0

ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type ISIS-Adj: No usable IP interface addresses in serial IIH %CLNS-5-ADJCHANGE: ISIS: Adjacency to RT2 (Serial0/0) ISIS-Adj: L2 adj count 0 ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type ISIS-Adj: No usable IP interface addresses in serial IIH

312

IS-IS Route Maintenance Problems This sect ion focuses on r out e m aint enance pr oblem s. The adj acency for m at ion problem s discussed in t he pr eceding sect ion ar e m uch easier t o t r oubleshoot and r esolve t han r out er m aint enance problem s, which are norm ally not obvious in very large net works unt il a specific addr ess or subnet becom es unr eachable. Obviously, m ost I S-I S pr oblem s relat e t o adj acency pr oblem s. When no adj acency issues exist , it becom es challenging t o isolat e r out ing pr oblem s; how ever , on Cisco r out er s, t he r out ing t able m ight be fed w it h r out ing infor m at ion fr om m ult iple sources. Most rout ers connect ed t o t he I nt ernet are configured w it h t w o I P rout ing prot ocols, t ypically BGP for int erdom ain rout ing and I S-I S or OSPF for int radom ain rout ing. Fr equent ly in t hese sit uat ions, lit t le over lap occur s in pr efixes adver t ised by each pr ot ocol, so t her e is pr act ically no cont ent ion in populat ing t he rout ing t able. The r out es in t he I P r out ing t able ar e or ganized int o m or e efficient dat a st r uct ur es for fast er r out e look up. Fast pack et for w ar ding can be achiev ed on Cisco r out er s w it h t w o basic m echanism s:

• •

Fast sw it ching Cis co Express Forwarding

Overview s of t hese m echanism s are provided in Chapt er 1 , " Ov er v iew of I P Rout ing." Refer t o t he r efer ences pr ov ided at t he end of t his chapt er for fur t her det ails about t hese m echanism s. Ev en t hough v er y r ar e, r out e m aint enance pr oblem s m ight r elat e t o pr oblem s in t he lookup m echanism rat her t han t he act ual source of t he rout e. This sect ion focuses on only I S-I Sr elat ed causes. The follow ing ar e t he m ost comm on causes of rout ing inconsist encies in I S-I S and are discussed in det ail in t he follow ing sect ions:

•

I S-I S rout e advert isem ent problem s

•

I S-I S r out e inst allat ion pr oblem

•

Discont iguous Level 2 subdom ain

•

Rout e flaps

•

LSP corrupt ion st orm s

•

Aut hent icat ion pr oblem s

•

I S-I S sum m ar izat ion and r edist r ibut ion pr oblem s

I S- I S Rou t e Adv e r t ise m e n t Pr oble m s Rout e advert isem ent problem s refer t o t he inabilit y of accurat e rout ing inform at ion t o reach a r em ot e dest inat ion fr om a specific r out er or sect ion of t he net w or k. As a link-st at e prot ocol, I S-I S r out ing infor m at ion is adv er t ised by m eans of link-st at e packet s. Tr oubleshoot ing r out ing basically inv olv es inspect ing t he LSP of t he sour ce node at bot h t he sour ce and r out er s in t he r egion of t he net w or k w her e t he r out es ar e m issing. An I S-I S r out er adv er t ises r out ing infor m at ion t o t he r est of t he net w or k by one of t he follow ing m et hods:

313

•

The rout e is a subnet connect ed t o t he rout er, and t he corresponding int erface is enabled for I S-I S r out ing.

•

Passive int er face.

•

Ex t er nal r outes by m eans of redist ribut ion from anot her rout ing source ( st at ic, anot her dynam ic r out ing pr ot ocol such as RI P, or a connect ed int er face) .

•

Rout e sum m ar ies.

I f a r out e is not being hear d in t he r est of t he ar ea or dom ain, t he fir st st ep in t r oubleshoot ing t he pr oblem is t o m ake sur e t he pr ocedur e for int r oducing t he r out e int o t he I S-I S pr ocess has been pr oper ly configur ed.

Adv e r t isin g I P Su bn e t s by Act iv a t in g I S- I S on I n t e r fa ce s I f t he fir st m et hod is used, t he ip rout er isis com m and m ust be applied t o t he appropriat e int erface. Not e t hat I S-I S does not use a net w or k st at em ent for adv er t ising an I P r out e as is com m only done for ot her prot ocols. I nst ead, enabling I S-I S on an int er face t r igger s t he form at ion of adj acencies on t hat int erface and also advert ise s t he at t ached I P subnet in an LSP t o all neighbor s. The show ip int e r fa ce br ie f com m and confir m s t he int er face on w hich t he r out e is connect ed, follow ed by a show clns int e r fa ce com m and. The act ual configur at ion of t he int er face can also be v er ified w it h t he com m and show running- config | be gin int e r fa ce < t ype a nd num ber> , as sh ow n in Exam ple 10- 38 . Ex a m p le 1 0- 3 8 Adve r t ising I S- I S Rout ing I nfor m a t ion

RT1#show run | begin interface Serial0/0 interface Serial0/0 mtu 2000 ip address 192.168.1.1 255.255.255.252 no ip directed-broadcast ip router isis no ip mroute-cache no fair-queue clockrate 2000000 no isis hello padding I f t he int er face is pr oper ly configur ed, t he nex t st ep m ight be t o t ak e a look at t he I P reachabilit y inform at ion fields of t he rout er's LSP w it h t he com m and show isis da t a ba se le v e l det a il LSPI D. This com m and provides insight int o t he inform at ion in t he LSP t hat is adver t ised t o ot her neighbor s. I t is assum ed t hat t her e ar e no adj acency pr oblem s w it h any of t he neighbor s in t he dir ect ion of t he net w or k w her e t he r out e is m issing. The le ve l- 1 keyword is used if t he r out e is m issing in only t he local ar ea, and t he le ve l-2 k ey w or d is used if t he r out e is not pr esent in ot her ar eas w it hin t he sam e dom ain. I f no adj acency pr oblem s ex ist , I S-I S r out ing is enabled cor r ect ly on t he int er face w her e t he r out e should be t ak en fr om , and t he pr efix is seen in t he LSP of t he local r out er ; t hen t he pr oblem is com plex and r equir es m ore insight . The show isis da t a ba se le ve l de t a il LSPI D com m and should be used on t he rem ot e rout ers t o check t he presence a nd currency of t he LSP in quest ion. The debug isis update - p a ck e t com m and assist s w it h debugging any issues w it h per iodic dat abase

314

synchr onizat ion on LANs. Not e t hat synchr onizat ion issues ar e absent on point -t o-point link s because of t he r eliable flooding pr ocess used on such link s.

Adv e r t isin g a Su bn e t w it h p a ssiv e- in t e r f a ce Th e pa ssive - int erfa ce com m and is nor m ally used w hen t he subnet on an int er face needs t o be adv er t ised w it hout for m ing adj acency or sending r edundant hello m essages ov er t hat int er face. For exam ple, a loopback int er face is nor m ally defined as a passive int er face so t hat it s addr ess w ill be adv er t ised w it hout w ast ing CPU cy cles t o gener at e unnecessar y hellos t o nonexist ent neighbor s. I f a loopback addr ess is not adver t ised, t he configur ation should be check ed t o m ak e sur e it is specified as a passiv e int er face. Cur r ent Cisco I OS Soft w ar e r eleases r em ove t he ip r ou t e r isis com m and fr om t he int er face configur at ion w hen t he int er face is defined as passiv e.

Adv e r t isin g Ex t e r n a l Rou t e s The m ost com plicat ed rout ing m aint enance problem s involve redist ribut ion. Redist ribut ion of st at ic r out es is m anageable and r elat ed pr oblem s ar e easy t o t r oubleshoot . Pr oblem s t hat r elat e t o r edist r ibut ion of a dynam ically lear ned r out e ar e far m or e com plicat ed. This is pr im ar ily because no inher ent loop-pr event ion m echanism s ar e associat ed w it h r out e r edist r ibut ion. The safest w ay t o r edist r ibut e r out es w it hout est ablishing loops and r out e feedback is t o lim it t he point s w her e r edist r ibut ion occur s. When pr oblem s occur in such sit uat ions, it is best t o t roubleshoot at t he point s of redist ribut ion ( border rout ers) . Redist r ibut ed I P r out es ar e ent er ed as ex t er nals int o t he LSP. The show isis da t a ba se le v e l det a il LSPI D com m and can be used t o inspect t he LSPs of t he border rout ers t o ensure t he ext ernal reachabilit y inform at ion reaches t he LSPs correct ly. When t he I S-I S dom ain has m ult iple point s of redist ribut ion, m ore t han one LSP can int roduce t he ext ernal rout es int o t he I S-I S dom ain, r equir ing car e t o be t ak en so t hat t he bor der r out er s do not point t o each ot her as t he best ex it fr om t he dom ain t o t he ex t er nal dest inat ions. The r out er-lev el displa y- route - de t a il com m and pr ov ides k now ledge about w hich LSPs ar e responsible for specific rout es in t he rout ing t able. Th is is a useful t ool for t r oubleshoot ing rout ing problem s and t racking where t he ent ries in t he rout ing t able originat e from .

Figur e 10-8

dem onst r at es t he oper at ion of t his com m and, and t he com m and out put is show n in Ex am ple 1039.

A par t ial configur at ion of RT1 and t he out put of t he sh ow ip r ou t e isis com m and ex ecut ed

on RT1 ar e included in Exam ple 10- 39 . Also show n is a show isis da t a ba se com m and fr om t he sam e r out er . Each I S-I S ent r y in t he r out ing t able of RT1 indicat es t he num ber of t he LSP fr om w hich it cam e. The LSP num ber s ar e show n in br ack et s in t he show isis da t a ba se out put . For exam ple, 10.1.2.0/ 24 is lear ned fr om LSP num ber 4, w hich is RT2.00-00. The displa y- rout e - de t a il com m and also display s back up pat hs for r out es, w hich ar e alt er nat iv e, less -preferred pat hs. The follow ing backup ent ry is provided for t his rout e: Fig u r e 1 0- 8 . D e m on st r a t in g u se of t h e displa y- rout e- det ail com m a n d.

315

Backup ix/lvl/metric:9/L2/30 The int er pr et at ion of t his back up pat h is as follow s:

•

ix — I ndex of sour ce LSP ( LSP 9)

• •

lvl— Lev el 1 or Lev el 2 ( Lev el 2) m et ric— Th e m etr ic v alue ( 30)

This ex t r a infor m at ion pr ov ided by t he displa y- route - de t a il com m and giv es m or e insight int o t he rout ing environm ent and can significant ly help you t o t roubleshoot rout ing problem s. I n t his case, 10.1.2.0/ 24 is learned from LSP4 ( RT2.00-00) as pr im ar y , but a back up pat h is being adver t ised t hr ough LSP9 ( RT4.00-00) . The or igins of t hese LSPs ar e obv ious fr om t he n am es. Ex a m p le 1 0- 3 9 displa y- rout e- det ail Com m a n d Ex a m ple

RT1#show running-config [snip] router isis passive-interface Loopback0 default-information originate net 49.0001.0000.0000.0001.00 metric-style wide log-adjacency-changes display-route-detail

RT1#show ip route isis 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks i L2 10.1.2.0/24 [115/20] via 192.168.1.2, Serial0/0, from LSP 4 Backup ix/lvl/metric: 9/L2/30 11.0.0.0/32 is subnetted, 6 subnets i L1 11.1.1.3 [115/10] via 10.1.1.3, Ethernet0/0, from LSP 7 Backup ix/lvl/metric: 8/L2/10 i L2 11.1.1.2 [115/10] via 192.168.1.2, Serial0/0, from LSP 4 Backup ix/lvl/metric: 9/L2/30 i L2 11.1.1.6 [115/20] via 192.168.1.2, Serial0/0, from LSP 4 Backup ix/lvl/metric: 9/L2/30 i L1 11.1.1.5 [115/10] via 10.1.1.5, Ethernet0/0, from LSP 5 Backup ix/lvl/metric: 8/L2/20 i L2 11.1.1.4 [115/20] via 192.168.1.2, Serial0/0, from LSP 9

316

Backup ix/lvl/metric: 4/L2/20 192.168.2.0/30 is subnetted, 1 subnets i L1 192.168.2.0 [115/20] via 10.1.1.3, Ethernet0/0, from LSP 7 Backup ix/lvl/metric: 4/L2/30 8/L2/110 */L2/120

RT1#show isis IS-IS Level-1 LSPID RT1.00-00 RT1.01-00 RT3.00-00 RT5.00-00

data Link State Database LSP Seq Num LSP Checksum * 0x000000FA 0xAF5F * 0x000000F4 0x40FC 0x0000119B 0xCA8D 0x000000EC 0x1E90

LSP Holdtime 661 349 668 434

ATT/P/OL 1/0/0 (1) 0/0/0 (3) 1/0/0 (7) 0/0/0 (5)

IS-IS Level-2 Link State Database LSPID LSP Seq Num LSP Checksum RT1.00-00 * 0x00000101 0x9FB7 RT1.01-00 * 0x0000000D 0x8D30 RT2.00-00 0x00001FC0 0x1F57 RT2.01-00 0x00000001 0xBA0C RT3.00-00 0x0000119D 0x01F4 RT4.00-00 0x00001191 0x06F3

LSP Holdtime 563 1193 739 730 714 834

ATT/P/OL 0/0/0 (2) 0/0/0 (6) 0/0/0 (4) 0/0/0 (10) 0/0/0 (8) 0/0/0 (9)

Adv e r t isin g Su m m a r y Rou t e s Frequent ly, net work operat ors at t em pt t o sum m ar ize r out ing infor m at ion by r epr esent ing a set of r out es w it h one or a few er num ber of pr efix es t han in t he or iginal set . This is good pr act ice and helps save on syst em resources, such as m em ory and net w ork bandw idt h. I f m any sm aller pr efix es ar e sum m ar ized int o one pr efix, less space is r equir ed in t he LSP t o adver t ise t hose pr efixes, and, t her efor e, less bandw idt h is needed t o flood t he sm aller LSP t hr oughout t he ar ea. When r out es ar e sum m ar ized, t hey m ight becom e par t of an aggr egat e. Ther efor e, t r oubleshoot ing m issing r out es in such envir onm ent s should involve checking w het her t hey ar e r epr esent ed accur at ely by t he sum m ar ies as int ended.

I S- I S Rou t e I n st a lla t ion Pr oble m s Rout e inst allat ion pr oblem s involve sit uat ions w her e an LSP fr om a r em ot e rout er is properly r eceived, but a r out e in t he LSP is not inst alled in t he r out ing t able as expect ed. I S-I S does not hav e any com plicat ed schem es for inst alling r out es t hat ar e det er m ined by t he SPF pr ocess t o be t he best pat h. For exam ple, OSPF ext er nal lin k-st at e adv er t isem ent s hav e a for w ar ding addr ess w hen non-zer o has t o be lear ned t hr ough OSPF for a r out ing bit t hat cont r ols inser t ion int o t he r out ing t able t o be set appr opr iat ely. I S-I S has no concept of a r out ing bit . The m ost plausible r eason w hy a n I S-I S r out e should not m ake it int o t he r out ing t able is because t her e is a sim ilar r out e fr om anot her r out ing sour ce w it h a bet t er adm inist rat ive dist ance t han I S-I S. Rout e inst allat ion pr oblem s ar e r ar e in I S-I S, an d w h en t hey do occur , t he r eason is m ost cer t ainly a soft w ar e failur e or an int er oper abilit y issue. You can use t he follow ing com m ands t o isolat e r out e inst allat ion pr oblem s:

•

show ip r out e [ isis]

317

•

show isis da t a ba se le ve l de t a il LSPI D

Th e show ip rout e pr efix com m and det er m ines t he absolut e absence of t he prefix from t he r out ing t able. I f t he r out e is pr esent but fr om anot her sour ce, t he adm inist r at ive dist ance should be low er ; ot her w ise, t her e's an issue. The isis keyw or d list s only all I S-I S r out es in t he I P rout ing t able. This m ight prove useful t o confir m w het her only a specific r out e fr om I S-I S is affect ed. I f a r out e is not in t he r out ing t able as ex pect ed, t he show isis da t a ba se com m and specifying t he r out ing level, t he LSPI D of t he sour ce LSP, and t he det ail keyw or d should be used t o pr obe fur t her int o t he cont ent s of t he LSP. Help fr om an ex per t m ight be r equir ed t o confirm t he problem .

Un st a ble I S - I S Rou t e s Rout e inst abilit y m eans t hat t he rout e is available only int erm it t ent ly. This is usually described as a rout e flap. Rout e flap m ight result j ust from an unst able link or possibly because of a m or e com plex under ly ing condit ion, such as an int er m it t ent r out ing loop. Typically, at t he point w her e t he flap is seen, t he LSP t hat cont ains t he r out e is per iodically adver t ised and w it hdr aw n, or new er versions are cont inuously being received. Rout e flaps can also hav e a dev ast at ing effect on t he r out ing env ir onm ent if a lar ge num ber of LSPs and r out er s ar e affect ed. This m ight cause t he SPF pr ocess t o r un for pr olonged per iods, r esult ing in potent ially dangerous levels of CPU ut ilizat ion on t he affect ed rout ers. I f t he net w or k changes affect only I P pr efixes, only par t ial r out e calculat ion ( PRC) m ight be per for m ed by t he I S-I S SPF pr ocess. Ot her sit uat ions m ight r equir e scheduling of a " full" SPF. The lat t er is m or e CPU-int ensiv e. By far , t he m ost com m on causes of r out e flaps ar e unst able links. Anot her w ell-k now n cause is cor r upt ion of an LSP in a net w or k dev ice as it is being flooded t hr ough t he net w or k . LSP corrupt ion st orm s are discussed lat e r in t his chapt er. I n a lar ge net w or k , t he displa y- route - de t a il com m and discussed in t he pr eceding sect ion can det er m ine t he LSP associat ed w it h t he unst able r out e ( r efer t o Exam ple 10- 35 ) . The focus of pr oblem isolat ion can t hen be placed on t he sour ce of t he LSP. I n m ost cases, a r out e flap pr oblem can b e quickly confirm ed by looking at t he sequence num ber s of LSPs in t he sam e link st at e dat abase. The sh ow isis da t a ba se ou t pu t in 1 0 -4 0

Exam ple

feat ur es a far higher sequence num ber for t he LSP w it h I D RT2.00-00 t han for t he ot her

k now n LSPs. The huge discr epancy signals eit her pr oblem s at t he sour ce or somew her e in bet w een t he sour ce and t he point of obser v at ion. I f t he sour ce and t he r out er at w hich t he pr oblem is being obser ved ar e dir ect ly connect ed, you can use st andar d pr ocedur es t o t r oubleshoot t he phy sical and dat a link lay er s. The show int erfa ce or show clns int e r fa ce com m and can provide link st at us inform at ion and som e leads m ight be available in t he logs.

318

Because t he pr oblem m ight be adj acency r elat ed, t he debug isis adj - p a ck e t debugging opt ion can be enabled t o obser v e t he pr oblem fur t her . At t he sour ce of t he LSP, t he debug isis spf- lo g com m and provides inform at ion regarding event s affect ing t he locally sourced LSP and, t herefore, som e clues t o t he problem ( refer t o Ex am ple 10-1 2 and Table 10- 2 ). Ex a m p le 1 0- 4 0 Tr ouble shoot ing Unst a ble Rout e s

RT1#show isis database IS-IS Level-1 Link State Database LSPID LSP Seq Num LSP Checksum RT1.00-00 * 0x00000093 0x7EF7 RT1.01-00 * 0x0000008B 0xA014 RT5.00-00 0x00000085 0xEC29

LSP Holdtime 438 838 1107

ATT/P/OL 1/0/0 0/0/0 0/0/0

IS-IS Level-2 Link State Database LSPID LSP Seq Num LSP Checksum RT1.00-00 * 0x00000095 0xA819 RT2.00-00 0x00001F57 0xE0FE

LSP Holdtime 1082 781

ATT/P/OL 0/0/0 0/0/0

LSP Cor r u p t ion St or m s LSP cor r upt ion st or m s occur w hen LSPs ar e cor r upt ed by a net w or k dev ice as t he LSPs ar e flooded. When a r out er r eceives a cor r upt ed LSP, it pur ges it fr om t he net w or k by set t ing it s r em aining lifet im e t o 0 and flooding it back int o t he netw or k . Cor r upt ed LSPs ar e det er m ined t hr ough checksum m at ching. When a cor r upt ed LSP is pur ged, t he sour ce r egener at es anot her copy and re -adver t ises it back int o t he net w or k. This adver t ise-and -purge act ivit y w ill likely occur unt il t he sour ce of t he cor r upt ion is rem oved from t he net w ork. Corrupt ion st orm s consum e net w or k r esour ces, such as CPU and bandw idt h, and can ser iously im pact net w or k per for m ance. LSP cor r upt ion st or m s can be elim inat ed w it h t he r out er-level com m and ignorelsp- e r r or s.

D iscon t igu ou s Le v e l 2 Su b d om a in s I S-I S r equir es t he Level 2 backbone t hat int er connect s t he var ious ar eas t o be cont iguous. This condit ion can easily be violat ed by bad net w or k design or r out er m isconfigur at ion, as show n in

Figure 10- 9 .

Cisco rout ers funct ion as Level 1 -2 by default and caut ion should be

exercised in t urn ing off Level 2 r out ing unt il t he im pact is w ell under st ood. The Level 1 -only rout er in area 49.0002 disrupt s t he cont inuit y of t he Level 2 pat h, prevent ing areas 49.0001 and 49.0003 fr om r eaching each ot her . Fig u r e 1 0- 9 . Ca se st u dy for fr a gm e n t e d Le ve l 2 ba ck bone.

319

Authentication Problems I S-I S specificat ions ( I SO 10589 [ 1] and RFC 1195 [ 2] ) pr ov ide a sim ple passw or d schem e for aut hent icat ion. Three kinds of aut hent icat ion m et hods t hat use sim ple passw or d ar e suppor t ed on Cisco r out er s, as discussed in Chapt er 9 .

•

Link aut hent icat ion

• •

Area aut hent icat ion Dom ain aut hent icat ion

When aut hent icat ion is configur ed, a clear-t ext password is insert ed int o I S-I S pack et s, such as LSPs, CSNPs, and PSNPs, as ar e also hellos ( link aut hent icat ion only ) . The passw or d is verified before a packet is accept ed for processing. Clearly, a passw ord m ism at ch bet ween t he sour ce of t he packet and t he r ecipient could cr eat e bot h adj acency and r out ing m aint enance pr oblem s, depending on t he t ype of aut hent icat ion enabled.

Ex am ple 10- 41

show s a debug adj -

pa ck e t out put for a link aut hent icat ion failur e. Ex a m p le 1 0- 4 1 D e bugging Aut he nt ica t ion Fa ilur e s

RT1# debug isis adj-packets *Apr 23 04:25:36: ISIS-Adj: type L1L2, cir id 00, length 1499 *Apr 23 04:25:36: ISIS-Adj: *Apr 23 04:25:42: ISIS-Adj: *Apr 23 04:25:46: ISIS-Adj: type L1L2, cir id 00, length 1499 *Apr 23 04:25:46: ISIS-Adj:

Rec serial IIH from *HDLC* (Serial0/0), cir

Authentication failed Sending serial IIH on Serial0/0, length 1499 Rec serial IIH from *HDLC* (Serial0/0), cir

Authentication failed

* Apr 23 04: 25: 50: I SI S-Adj : Sending serial I I H on Serial0/ 0, lengt h 1499

IS-IS Error Logging The errors logged by Cisco I OS Soft w ar e fr equent ly pr ovide infor m at ion about pr oblem s occurring on t he rout er or t he net w ork in general and should alw ays be checked for pert inent clues w hen t roubleshoot ing problem s.

Ex am ple 10- 42

show s an I S-I S-r elat ed logged er r or t hat

indicat es t hat an addr ess pr efix t hat had a lengt h of 135 by t es w as det ect ed, w hich is m or e t han t he expect ed m axim um size. This log infor m at ion also pr ovides t he I D of t he LSP car r ying t he m alfor m ed TLV w it h t he bad infor m at ion.

Exam ple 10- 43

show s t hat a hello pack et is r eceiv ed

fr om an ATM VC w it h a lengt h of 51 by t es r at her t han t he ex pect ed 53 by t es. Exam ple 10- 44

shows inform at ion logged for an ad j acency change.

Ex a m p le 1 0- 4 2 I S- I S Loggin g for M a lfor m e d Pa ck e t s on PoS Lin k

Mar 10 11:59:46.171: %CLNS-3-BADPACKET: ISIS: L1 LSP, option 1 address prefix length 135 > max NSAP length (21), ID 0000.0000.04B7.00-00, seq 25948, ht 1115 from *PPP* (POS6/0).

320

Ex a m p le 1 0- 4 3 I S- I S Logging for M a lfor m e d Pa ck e t on ATM PVC

Nov 16 02:18:04.848 EDT: %CLNS-4-BADPACKET: ISIS: P2P hello, option 8 length 53 remaining bytes (51) from VC 2 (ATM4/0.2) Ex a m p le 1 0- 4 4 Logs for Adj a ce n cy Ch a n ge s

RT1#show log %CLNS-5-ADJCHANGE: ISIS: Adjacency to 0000.0000.0001 (ethernet 0) % CLNS-5 -ADJCHANGE: I SI S: Adj acency t o 0000.0000.0002 ( et hernet 0)

Summary The net w or k engineer should hav e a good under st anding of t he concept s behind a net w or k prot ocol and be able t o apply t hat knowle dge in t roubleshoot ing scenarios, logical and pr act ical, in t he r eal w or ld. This chapt er focuses on t he applicat ion of t he concept s discussed in t he previous chapt ers for t roubleshoot ing I S-I S r out ing pr oblem s. The pr act ical m at er ial cov er ed in Chapter 9 is heavily lever aged, and ever y effor t is m ade t o pr esent pr act ical exam ples for t he reader. The m at erial present ed cat egorizes I S-I S failures int o t w o m ain groups: adj acency problem s and r out e m aint enance pr oblem s. The discussion about t r oubleshoot ing t ools, such as show com m ands and debug com m ands, show y ou how t o r ev iew specific pr oblem s and ex am ples. The v ar ious com m and and debug out put ex am ples enable y ou t o build up ex per t ise in t roubleshoot ing I S-I S r out ing pr oblem s and also ser v e as an ex cellent r efer ence sour ce.

Review Questions

1:

List t he t wo m ain cat egories of I S- I S problem s discussed in t his chapt er and provide exam ples of each.

2:

List t wo show com m ands t hat are useful for t roubleshoot ing adj acency problem s.

3:

List a debug com m and t hat provides help in t roubleshoot ing I S- I S adj acency problem s.

4:

What are LSP corrupt ion st orm s, and how do t hey im pact a net work's perform ance.

5:

Describe t he m et hodology for t roubleshoot ing an LSP corrupt ion st orm .

References Callon, Ross. "Use of OSI I S-I S for Rout ing in TCP/ I P and Dual Environm ent s." I ETF RFC 1195. 1990. ht t p: / / www.cisco.com / univercd/cc/ td/ doc/ product/ software/ ios121/ 121cgcr/ switch_c/ xcprt2/ xcdcef.htm .

321

I nt egr at ed I S-I S Com m ands. http: / / www.cisco.com / univercd/ cc/ td/ doc/ product / soft ware/ ios122/ 122cgcr/ fiprrp_r/ 1rfisis.ht m .

I nt ra -dom ain Rout ing I nfor m at ion Ex change Pr ot ocol for Use in Conj unct ion w it h t he Pr ot ocol for Providing t he Connect ionless -m ode Net w ork Service ( I SO 8473) . I SO/ I EC 10589. 1992. I P r out ing Pr ot ocol Com m ands.

http: / / www.cisco.com / univercd/ cc/ td/ doc/ product/ software/ ios100/ rpcr/ 66004.htm .

I S-I S int ra -dom ain r out ing infor m at ion exchange pr ot ocol ( I SO10589, p.37) .

322

Part IV: Appendixes Part I V Appe ndixes Appendix A I S- I S Packet Form at s Appendix B Answers t o Review Quest ions

323

Appendix A. IS-IS Packet Formats I S-I S Packet Fields ( Alphabet ical Order) Hello Packet s Lin k-St at e Packet s Sequence Num ber Packet s

IS-IS Packet Fields (Alphabetical Order) •

ATT— At t achm ent Bit s ( Flags at t achm ent t o ot her ar eas)

•

Ch e ck su m— Check sum of cont ent s of LSP fr om sour ce I D field t o t he end

•

Circuit Type— Defines w het her lin k is Lev el-1 an d Lev el-2

•

End LSP— LSP I D of last LSP in CSNP

•

H olding Tim e — Defines how long t o w ait for a hello fr om t his sy st em befor e clear ing t he adj acency

•

I D Lengt h— Lengt h of t he Sy st em I D field in an NSAP( NET)

•

I n t r a dom a in Rou t in g Pr ot ocol D iscr im in a tor— Net w or k lay er pr ot ocol ident ifier

•

I S Type — Defines t y pe of r out er , Lev el-1 or Lev el-2

•

LAN I D — LAN I dent ifier , Consist s of t he Syst em I D of t he designat ed int er m ediat e sy st em plus a unique num ber

•

Le ngt h I ndica t or — Lengt h of t he fixed header of t he packe t in byt es

•

Local Circuit I D — Unique ident ifier for a link

•

LSP I D — I dent ifier for rout er's LSP, consist ing of t he Syst em I D of t he rout er, fr agm ent num ber , and a nonzer o oct et for pseudonode num ber in case of pseudonode LSP

•

M a x im um Ar e a Addr e sse s— Nu m ber of ar eas per m it t ed

•

O L— LSP overload bit ( also represent ed as LSPDBOL)

•

P— Part it ion repair bit

•

PDU Lengt h— Lengt h of pack et ( PDU) in by t es

•

PD U Type — Ty pe of pack et

•

Priorit y — Priorit y for node for DI S arbit rat ion

•

R— See Reserved

•

Rem a ining Lifet im e — Rem aining t im e for an LSP t o expire

•

Re se r ve d— Unspecified fields, t r ansm it t ed as 0s and ignor ed on r eceipt

•

Se que nce N um be r — Sequence num ber of LSP

•

Source I D — Sam e as syst em ident ifier ( SysI D)

•

TLV Fie lds— Type ( or code) , Lengt h and Value fields, also know n as var iable -lengt h fields

•

Ve r sion / Pr ot ocol I D Ex t e n sion— Of t he I S-I S pr ot ocol ( defined as 1)

324

Hello Packets Figu r e A- 1 . LAN Le ve l- 1 h e llo pa ck e t for m a t ( PD U Ty pe 1 5 ) .

Ex a m ple A- 1 An a lyz e r Ca pt u r e : LAN Le ve l- 1 H e llo Pa ck e t

ADDR

HEX

ASCII

0000: 01 80 c2 00 00 14 00 d0 58 f7 89 41 05 dc fe fe | .ÓÂ....DX÷ 0010: 0020: 0030: 0040: 0050: 0060: 0070: 0080: 0090:

03 00 04 eb 00 00 00 00 00

83 0a 03 f8 00 00 00 00 00

1b 05 49 41 00 00 00 00 00

01 d9 00 00 00 00 00 00 00

00 40 01 d0 00 00 00 00 00

0f 00 84 58 00 00 00 00 00

01 00 04 eb 00 00 00 00 00

00 00 0a ff 00 00 00 00 00

00 00 01 01 00 00 00 00 00

03 00 01 08 00 00 00 00 00

00 01 01 ff 00 00 00 00 00

00 01 06 00 00 00 00 00 00

00 81 0c 00 00 00 00 00 00

00 01 00 00 00 00 00 00 00

00 cc d0 00 00 00 00 00 00

01 01 58 00 00 00 00 00 00

| | | | | | | | |

A.Üww

. .............. ...Ü@.........Ì. ..I.."........DX ëøA.DXëÿ..ÿ..... ................ ................ ................ ................ ................

325

00a0: 00b0: 00c0: 00d0: 00e0: 00f0: 0100: 0110: 0120: 0130: 0140:

00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00

Ex a m ple A- 2 D e code of

DLC:

----DLC: DLC: hex) bytes. DLC: DLC: DLC: DLC: LLC: ----LLC: LLC: LLC: LLC:

00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00

Ex a m ple A- 1

00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00

| | | | | | | | | |

................ ................ ................ ................ ................ ................ ................ ................ ................ ................

( Pa r t 1 )

DLC Header ----Frame 1 arrived at

19:03:01.2025; frame size is 1514 (05EA

Destination = Multicast 0180C2000014 Source = Station 00D058F78941 802.3 length = 1500 LLC Header ----DSAP Address = FE, DSAP IG Bit = 00 (Individual Address) SSAP Address = FE, SSAP CR Bit = 00 (Command) Unnumbered frame: UI

Ex a m ple A- 3 D e code of

IS-IS: ----IS-IS: IS-IS: Protocol) IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS:

Ex a m ple A- 1

( Pa r t 2 )

ISO Network Layer Header ----Protocol ID = 83 (Intermediate System Routing Exchange Header length = 27 Version / Protocol ID Extension = 1 ID Length = 0, Indicates 6 Octets PDU type = 15 (Hello, LAN Level 1) Version = 1 Reserved = 0 Maximum Area Addesses = 0 Circuit Type = 3 (Both level 1 and level 2 routing) Source ID = 000000000001 Holding time is 10 second(s) Frame length is 1497 byte(s) Designated Intermediate System for Level 1 Priority = 64 Address = 000000000001 ID = 01

Ex a m ple A- 4 D e code of

Ex a m ple A- 1

( Pa r t 3 )

IS-IS: ----- ISO Network Layer Variable Fields ----IS-IS: IS-IS: Variable field: IS-IS: Field Code = 129 (Protocols Supported) IS-IS: Field length = 1 IS-IS: NLPID'sfor protocols within this IS: IS-IS: NLPID = CC (Internet IP) IS-IS: Variable field: IS-IS: Field Code = 1 (Manual Area Addresses)

326

IS-IS: Field length = 4 IS-IS: Manual Area Address: IS-IS: Length = 3 IS-IS: Format = 49 (Local Binary) IS-IS: Address = 490001 IS-IS: Variable field: IS-IS: Field Code = 132 (IP Interface Address) IS-IS: Field length = 4 IS-IS: IP Interface Address: IS-IS: IP Address = [10.1.1.1] IS-IS: Variable field: IS-IS: Field Code = 6 (System Neighbors) IS-IS: Field length = 12 IS-IS: Neighbor = 00D058EBF841 IS-IS: Neighbor = 00D058EBFF01 IS-IS: Variable field: IS-IS: Field Code = 8 (Padding) IS-IS: Field length = 255

327

Figu r e A- 2 . LAN Le ve l- 2 h e llo pa ck e t s ( PD U Ty pe 1 6 ) .

Ex a m ple A- 5 An a lyz e r Ca pt u r e : LAN Le ve l- 2 H e llo Pa ck e t

ADDR

HEX

ASCII

0000: 01 80 c2 00 00 15 00 d0 58 f7 89 41 05 dc fe fe| .ÓÂ...DX÷ 0010: 0020: 0030: 0040:

03 00 04 eb

83 0a 03 f8

A.Üww

1b 01 00 10 01 00 00 03 00 00 00 00 00 01 | . .............. 05 d9 40 00 00 00 00 00 01 01 81 01 cc 01 | ...Ù@.......?.Ì. 49 00 01 84 04 0a 01 01 01 06 06 00 d0 58 | ..I.."........DX 41

Ex a m ple A- 6 D e code of

Ex a m ple A- 5

( LAN Le v e l- 2 H e llo Pa ck e t )

IS-IS: -----ISO Network Layer Header ----IS-IS: IS-IS: Protocol ID = 83 (Intermediate System Routing Exchange Protocol) IS-IS: Header length = 27

328

IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS:

Version / Protocol ID Extension = 1 ID Length = 0, Indicates 6 Octets PDU type = 16 (Hello, LAN Level 2) Version = 1 Reserved = 0 Maximum Area Addesses = 0 Circuit Type = 3 (Both level 1 and level 2 routing) Source ID = 000000000001 Holding time is 10 second(s) Frame length is 1497 byte(s) Designated Intermediate System for Level 2 Priority = 64 Address = 000000000001 ID = 01 Figu r e A- 3 . Poin t- to- poin t h e llo pa ck e t s ( PD U Ty pe 1 7 ) .

329

Link-State Packets Figu r e A- 4 . Le ve l- 1 lin k- st a t e pa ck e t s ( PD U Type 1 8 ) .

Ex a m ple A- 7 An a lyz e r Ca pt u r e : Le ve l- 1 LSP

ADDR

HEX

ASCII

0000: 01 80 c2 00 00 14 00 d0 58 f7 89 41 00 67 fe fe | .ÓÂ....DX÷

A.gww

0010: 03 83 1b 01 00 12 01 00 00 00 64 04 af 00 00 00 | . ........d.-... 0020: 00 00 01 00 00 00 00 18 3b e6 cf 0b 01 04 03 49 | ........;æÌ....I 0030: 00 01 81 01 cc 89 03 52 54 31 84 04 0b 01 01 01 | ...Ì 0040: 0050: 0060: 0070:

87 a8 00 00

1a 01 00 00

00 00 00 00

00 00 01 00

.RT1"......

00 0a 18 0a 01 01 00 00 00 0a 1e c0 | ..............À 00 00 00 20 0b 01 01 01 16 0b 00 00 | "...... ........ 01 00 00 0a 00 03 0a 00 80 80 80 00 | ............ÓÓÓ. 01 | .....

330

Ex a m ple A- 8 D e code of

DLC:

----DLC: DLC: hex) bytes. DLC: DLC: DLC: DLC: LLC: ----LLC: LLC: LLC: LLC:

( Le v e l- 1 LSP Pa r t 1 )

Frame 318 arrived at

18:50:53.1251; frame size is 117 (0075

Destination = Multicast 0180C2000014 Source = Station 00D058F78941 802.3 length = 103 LLC Header ----DSAP Address = FE, DSAP IG Bit = 00 (Individual Address) SSAP Address = FE, SSAP CR Bit = 00 (Command) Unnumbered frame: UI

Ex a m ple A- 9 D e code of

IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS:

Ex a m ple A- 7

DLC Header -----

Ex a m ple A- 7

( Le v e l- 1 LSP Pa r t 2 )

-----ISO Network Layer Header ----Protocol ID = 83 (Intermediate System Routing Exchange Protocol) Header length = 27 Version / Protocol ID Extension = 1 ID Length = 0, Indicates 6 Octets PDU type = 18 (Link State, Level 1) Version = 1 Reserved = 0 Maximum Area Addesses = 0 Frame length is 100 byte(s) Remaining life is 1199 second(s) Link State Frame ID: Source ID = 000000000001 Pseudo-node = 00 (Not a pseudo-node) Link frame no. = 0 Frame Sequence = 6203 Checksum = E6CF Attributes = 0B 0... .... = Partition repair not supported .0.. .... = Not attached using error metric ..0. .... = Not attached using expense metric ...0 .... = Not attached using delay metric .... 1... = Attached using default metric .... .0.. = No LSP Database Overload .... ..11 = Level 2 intermediate system

Ex a m ple A- 1 0 D e code of

Exam ple A- 7

( Le ve l- 1 LSP Pa r t 3 )

IS-IS: ----- ISO Network Layer Variable Fields ----IS-IS: IS-IS: Variable field: IS-IS: Field Code = 1 (Manual Area Addresses) IS-IS: Field length = 4 IS-IS: Manual Area Address: IS-IS: Length = 3 IS-IS: Format = 49 (Local Binary) IS-IS: Address = 490001 IS-IS: Variable field: IS-IS: Field Code = 129 (Protocols Supported) IS-IS: Field length = 1 IS-IS: NLPID's for protocols within this IS: IS-IS: NLPID = CC (Internet IP) IS-IS: Variable field:

331

IS-IS: Field Code = 137 (Dynamic Hostname) IS-IS: Field length = 3 IS-IS: Variable field: IS-IS: Field Code = 132 (IP Interface Address) IS-IS: Field length = 4 IS-IS: IP Interface Address: IS-IS: IP Address = [11.1.1.1] Ex a m ple A- 1 1 D e code of

Exam ple A- 7

( Le ve l- 1 LSP Pa r t 3 Cont inue d)

IS-IS: ----- ISO Network Layer Variable Fields ----IS-IS: Variable field: IS-IS: Field Code = 135 (Extended IP Reachability) IS-IS: Field length = 26 IS-IS: Variable field: IS-IS: Field Code = 22 (Extended IS Reachability) IS-IS: Field length = 11 IS-IS: Variable field: IS-IS: Field Code = 3 (Neighboring End Systems) IS-IS: Field length = 10 IS-IS: Default metric = 0 IS-IS: Delay metric = Not supported IS-IS: Expense metric = Not supported IS-IS: Error metric = Not supported IS-IS: Neighbor ID = 000000000001

332

Figu r e A- 5 . Le ve l- 2 lin k- st a t e pa ck e t s ( PD U Type 2 0 )

Ex a m ple A- 1 2 An a ly z e r Ca pt u r e : Le ve l- 2 LSP

ADDR

HEX

ASCII

0000: 01 80 c2 00 00 15 00 d0 58 f7 89 41 05 dc fe fe | ÓÂ....DX÷ 0010: 0020: 0030: 0040:

03 00 04 eb

83 0a 03 f8

A.Üww

1b 01 00 10 01 00 00 03 00 00 00 00 00 01 | . ............. 05 d9 40 00 00 00 00 00 01 01 81 01 cc 01 | ...Ù@.........Ì. 49 00 01 84 04 0a 01 01 01 06 06 00 d0 58 | ..I.."........DX 41

333

Ex a m ple A- 1 3 D e code of

IS-IS: ----IS-IS: IS-IS: Protocol) IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS:

I S-I S:

( Le v e l- 2 LSP Pa r t 1 )

Protocol ID = 83 (Intermediate System Routing Exchange Header length = 27 Version / Protocol ID Extension = 1 ID Length = 0, Indicates 6 Octets PDU type = 20 (Link State, Level 2) Version = 1 Reserved = 0 Maximum Area Addesses = 0 Frame length is 131 byte(s) Remaining life is 1199 second(s) Link State Frame ID: Source ID = 000000000001 Pseudo-node = 00 (Not a pseudo-node) Link frame no. = 0 Frame Sequence = 6188 Checksum = E72A Attributes = 03 0... .... = Partition repair not supported .0.. .... = Not attached using error metric ..0. .... = Not attached using expense metric ...0 .... = Not attached using delay metric .... 0... = Not attached using default metric .... .0.. = No LSP Database Overload .... ..11 = Level 2 intermediate system

Ex a m ple A- 1 4 D e code of

IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS: IS-IS:

Exam ple A- 1 2

ISO Network Layer Header -----

Exam ple A- 1 2

( Le v e l- 2 LSP Pa r t 2 )

----- ISO Network Layer Variable Fields ----Variable field: Field Code = 1 (Partition Area Addresses) Field length = 4 Partition Area Address: Length = 3 Format = 49 (Local Binary) Address = 490001 Variable field: Field Code = 129 (Protocols Supported) Field length = 1 NLPID'sfor protocols within this IS: NLPID = CC (Internet IP) Variable field: Field Code = 137 (Dynamic Hostname) Field length = 3 Variable field: Field Code = 132 (IP Interface Address) Field length = 4 IP Interface Address: IP Address = [11.1.1.1] Variable field: Field Code = 22 (Extended IS Reachability) Field length = 22 Variable field: Field Code = 135 (Extended IP Reachability) Field lengt h = 58

334

Sequence Number Packets Figu r e A- 6 . Le ve l- 1 com ple t e se qu e n ce n u m be r pa ck e t s ( PD U Type 2 4 ) .

Ex a m ple A- 1 5 An a ly z e r Ca pt u r e : Le ve l- 1 CSN P

ADDR

HEX

ASCII

0000: 01 80 c2 00 00 14 00 d0 58 f7 89 41 00 66 fe fe |.ÓÂ....DX÷ 0010: 0020: 0030: 0040: 0050: 0060: 0070:

03 01 ff 18 18 28 05

83 00 ff 33 13 be fd

21 00 09 f6 a5 06 ec

01 00 40 c7 61 12 ab

00 00 04 04 04 04

18 00 a6 1b a8 77

Ex a m ple A- 1 6 D ecode of

01 00 00 00 00 00

00 00 00 00 00 00

00 00 00 00 00 00

Exam ple A- 1 5

----- DLC Header ----DLC: Frame 75 arrived at hex) bytes.

00 00 00 00 00 00

63 ff 00 00 00 00

00 ff 01 01 03 05

00 ff 00 01 00 00

00 ff 00 00 00 00

00 ff 00 00 00 00

00 ff 00 00 00 00

A.fww

|. !.......c..... |..........ÿÿÿÿÿÿ |ÿÿ.@.|.......... |.3öÇ............ |..¥a............ |(p...w.......... |.yì«

( Le v e l- 1 CSN P Pa r t 1 )

DLC:

18:48:07.8401; frame size is 116 (0074

335

DLC: Destination = Multicast 0180C2000014 DLC: Source = Station 00D058F78941 DLC: 802.3 length = 102 LLC: ----- LLC Header ----LLC: DSAP Address = FE, DSAP IG Bit = 00 (Individual Address) LLC: SSAP Address = FE, SSAP CR Bit = 00 (Command) LLC: Unnumbered frame: UI LLC: IS-IS: ----- ISO Network Layer Header ----IS-IS: Protocol ID = 83 (Intermediate System Routing Exchange Protocol) IS-IS: Header length = 33 IS-IS: Version / Protocol ID Extension = 1 IS-IS: ID Length = 0, Indicates 6 Octets IS-IS: PDU type = 24 (Complete Sequence Numbers, Level 1) IS-IS: Version = 1 IS-IS: Reserved = 0 IS-IS: Maximum Area Addesses = 0 IS-IS: Frame length is 99 byte(s) IS-IS: Source: IS-IS: ID = 000000000001 IS-IS: Pseudo-node = 00 (Not a pseudo-node) IS-IS: Start Link State ID = 000000000000-00-00 IS-IS: End Link State ID = FFFFFFFFFFFF-FF-FF Ex a m ple A- 1 7 D e code of

Exam ple A- 1 5

( Le v e l- 1 CSN P Pa r t 2 )

IS-IS: ----- ISO Network Layer Variable Fields ----IS-IS: Variable field: IS-IS: Field Code = 9 (Link State Frame Entries) IS-IS: Field length = 64 IS-IS: Link State Frame Data: IS-IS: Remaining Life is 1190 second(s) IS-IS: Link State Frame ID: IS-IS: Source ID = 000000000001 IS-IS: Pseudo-node = 00 (Not a pseudo-node) IS-IS: Link frame no. = 0 IS-IS: Frame Sequence = 6195 IS-IS: Checksum = F6C7 IS-IS: Link State Frame Data: IS-IS: Remaining Life is 1051 second(s) IS-IS: Link State Frame ID: IS-IS: Source ID = 000000000001 IS-IS: Pseudo-node = 01 IS-IS: Link frame no. = 0 IS-IS: Frame Sequence = 6163 IS-IS: Checksum = A561 IS-IS: Link State Frame Data: IS-IS: Remaining Life is 1192 second(s) IS-IS: Link State Frame ID: IS-IS: Source ID = 000000000003 IS-IS: Pseudo-node = 00 (Not a pseudo-node) IS-IS: Link frame no. = 0 IS-IS: Frame Sequence = 10430 IS-IS: Checksum = 0612 [snip]

336

Figu r e A- 7 . Le ve l- 2 com ple t e se qu e n ce n u m be r pa ck e t s ( PD U Type 2 5 ) .

337

Figu r e A- 8 . Le ve l- 1 pa r t ia l se qu e n ce n u m be r pa ck e t s ( PD U Type 2 6 ) .

Ex a m ple A- 1 8 An a ly z e r Ca pt u r e : Le v e l- 1 PSN P

ADDR HEX ASCII 0000: 01 80 c2 00 00 14 00 d0 58 eb f8 41 00 56 fe fe | .ÓÂ....DXëøA.Vww 0010: 0020: 0030: 0040: 0050: 0060:

03 03 00 00 00 00

83 00 00 00 02 00

11 09 00 00 ed 00

01 40 00 00 19 00

00 04 04 04 04

1a af af aa af

Ex a m ple A- 1 9 D e code of

01 00 00 00 00

00 00 00 00 00

00 00 00 00 00

Exam ple A- 1 8

00 00 00 00 00

53 00 00 00 00

00 01 01 03 05

00 00 01 00 00

00 00 00 00 00

00 00 00 00 00

00 00 00 00 00

| | | | | |

. ........S..... [email protected].......... .....-.......... .....ª.......... ..í..-.......... ....

( Le v e l- 1 PSN P Pa r t 1 )

DLC:

----- DLC Header ----DLC: DLC: Frame 103 arrived at 19:04:39.3473; frame size is 100 (0064 hex) bytes. DLC: Destination = Multicast 0180C2000014 DLC: Source = Station 00D058EBF841

338

DLC: 802.3 length = 86 DLC: LLC: ----- LLC Header ----LLC: LLC: DSAP Address = FE, DSAP IG Bit = 00 (Individual Address) LLC: SSAP Address = FE, SSAP CR Bit = 00 (Command) LLC: Unnumbered frame: UI LLC: IS-IS: ----- ISO Network Layer Header ----IS-IS: IS-IS: Protocol ID = 83 (Intermediate System Routing Exchange Protocol) IS-IS: Header length = 17 IS-IS: Version / Protocol ID Extension = 1 IS-IS: ID Length = 0, Indicates 6 Octets IS-IS: PDU type = 26 (Partial Sequence Numbers, Level 1) IS-IS: Version = 1 IS-IS: Reserved = 0 IS-IS: Maximum Area Addesses = 0 IS-IS: Frame length is 83 byte(s) IS-IS: Source: IS-IS: ID = 000000000003 IS-IS: Pseudo-node = 00 (Not a pseudo-node) Ex a m ple A- 2 0 D e code of

Exam ple A- 1 8

( Le v e l- 1 PSN P Pa r t 2 )

IS-IS: ----- ISO Network Layer Variable Fields ----IS-IS: IS-IS: Variable field: IS-IS: Field Code = 9 (Link State Frame Entries) IS-IS: Field length = 64 IS-IS: Link State Frame Data: IS-IS: Remaining Life is 1199 second(s) IS-IS: Link State Frame ID: IS-IS: Source ID = 000000000001 IS-IS: Pseudo-node = 00 (Not a pseudo-node) IS-IS: Link frame no. = 0 IS-IS: Frame Sequence = 0 IS-IS: Checksum = 0000 (No checksum sent) IS-IS: Link State Frame Data: IS-IS: Remaining Life is 1199 second(s) IS-IS: Link State Frame ID: IS-IS: Source ID = 000000000001 IS-IS: Pseudo-node = 01 IS-IS: Link frame no. = 0 IS-IS: Frame Sequence = 0 IS-IS: Checksum = 0000 (No checksum sent)IS-IS: Link State Frame Data: IS-IS: Remaining Life is 1194 second(s) IS-IS: Link State Frame ID: IS-IS: Source ID = 000000000003 IS-IS: Pseudo-node = 00 (Not a pseudo-node) IS-IS: Link frame no. = 0 IS-IS: Frame Sequence = 2 IS-IS: Checksum = ED19

339

Figu r e A- 9 . Pa r t ia l se qu e n ce n u m be r pa ck e t s ( PD U Type 2 7 ) .

340

Appendix B. Answers to Review Questions

Chapt er 1 Chapt er 2 Chapt er 3 Chapt er 4 Chapt er 5 Chapt er 6 Chapt er 8 Chapt er 10

Chapter 1

1:

Nam e t he t w o pla nes of operat ion in a m odern rout er.

A:

The t w o planes of operat ion are Cont rol and Dat a planes.

2:

I P for w ar ding and I P r out ing ar e r elat ed concept s. What is t he difference bet ween t hem ?

A:

I P forw arding is t he process by w hich a rout er m oves a pack et from t he ingress port t o t he egress port . This process is som et im es called packet sw it ching or rout ing. How ever, I P rout ing involves m ore t han j ust sw it ching of packet s. I P rout ing is t he m uch broader process of exchanging rout ing inform at ion in a dom ain t o build t he rout ing t ables required t o m ake t he forw arding decisions.

3:

Nam e t he t hr ee com m on classificat ions of I P r out ing pr ot ocols.

A:

The t hree com m on classificat ions are classless and classful; int radom ain and int erdom ain; and dist ance vect or and link st at e.

4:

Nam e t hr ee basic pack et-sw it ching m echanism s suppor t ed in Cisco I OS Soft w ar e.

A:

Process sw it ching, fast sw it ching, and Cisco Express Forw arding.

5:

What is t he crit ical short com ing of t he I Pv4 archit ect ure t hat I Pv6 t ries t o address and how it is addr essed?

341

A:

I Pv6 is int ended t o provide a larger address space t han I Pv4 . I Pv6 addresses are 1 2 8 - bit s long com pared t o t he 3 2 - bit I Pv4 addresses.

Chapter 2

1:

Nam e t he t hr ee net w or k layer pr ot ocols t hat suppor t t he I SO CLNS.

A:

The t hree net w ork layer prot ocols are CLN P, ES- I S, and I S- I S.

2:

I n com par ing t he layer s of t he TCP/ I P pr ot ocols suit e and t he I SO CLNS ar chit ect ur e, describe how t he I nt ernet Prot ocol ( I P) differs from t he I SO Connect ionless Netw or k Prot ocol ( CLNP) .

A:

I n TCP/ I P, t he I nt ernet Prot ocol is t he only net w ork layer prot ocol. CLN P coexist s w it h ot her prot ocols such as ES- I S and I S- I S in t he I SO CLN S archit ect ure.

3:

What is t he use of t he I nt r adom ain Rout ing Pr ot ocol Discr im inat or in t he I SO net w or k layer pr ot ocol packet header s?

A:

I t pla ys t he r ole of net w ork layer prot ocol ident ifier and allow s different iat ion bet w een t he m ult iple I SO net w ork layer prot ocols.

4:

What w as I S-I S originally designed for?

A:

I S- I S w as int ended t o be used as a dynam ic rout ing prot ocol for rout ing Connect ionless N et w ork Prot ocol pack et s in t he I SO CLN S environm ent .

5:

How is I S-I S used in an I P net w or k ?

A:

The I S- I S uses Type Lengt h Value ( TLV) fields for carrying rout ing inform at ion in I S- I S protocol packets. RFC 1 1 9 5 specifies addit ional TLVs for carrying I P inform at ion in I S- I S packet s, t hus providing support for I P rout ing.

6:

Descr ibe any sim ilar it ies or differ ences bet w een t he ES-I S pr ot ocol and I P ARP.

A:

Bot h ARP and ES- I S are netw ork host - level protocols for discovering adj acencies on connect ed m edia and provide net w ork layer t o dat a link layer address m apping.

I P ARP is used on only broadcast m edia and m ult ipoint net w ork m edia, w hereas ES- I S also w orks over point t o- point links. Unlike ARP, Layer 3 t o Layer 2 address m apping is a subset of t he funct ionalit y provided by ESI S. Ot her funct ions of ES- I S in t he I SO CLN S environm ent are redirect ion and aut oconfigurat ion.

Chapter 3

1:

How m any levels of hie rarchy does t he I S-I S r out ing pr ot ocol suppor t and w hat is t heir significance?

A:

Tw o levels, Level 1 and Level 2 , are specified by I SO 1 0 5 8 9 and adopted by RFC 1 1 9 5 . Hierarchical rout ing

342

allow s cont rol over t he spread of rout ing updat es, w hich is a key requirem ent for net w ork st abilit y and scalabilit y.

2:

What is t he reason for subopt im al int erarea rout ing in t he I SO 10589 archit ect ure?

A:

I n t he I SO 1 0 5 8 9 archit ect ure, t he Level 1 rout ing areas are st ubs and do not have a com plet e view of t he dom ain t hat is necessary for m aking opt im al exit decisions out of t heir local area. I nst ead, Level 1 rout ers point default s t o t he nearest Level 2 rout er, w hich m ight not necessarily be on t he best pat h t o a specific dest ina t ion out side t he a rea .

3:

Nam e t he t w o cat egor ies of I S-I S pr ot ocol funct ions and descr ibe t he ser v ices t hey pro v ide.

A:

The t w o cat egories are t he subnet w ork- dependent funct ions and t he subnet w ork- independent funct ions. The form er is prim arily responsible for t he adj acency f orm at ion process, and t he lat t er for m anaging t he rout ing inform at ion updat e and m aint enance processes.

4:

What is t he gener al lay out of I S-I S pack et for m at s?

A:

All I S- I S packet s are com posed of a header and variable- lengt h TLV fields.

5:

List t he TLVs specified by I SO 10589.

A:

See Table 3 .1 .

6:

List t he TLVs specified by RFC 1195 and descr ibe t heir significance.

A:

See Table 3 .2 . The TLVs specified by RFC 1 1 9 5 allow t he I S- I S prot ocol, w hich w as originally designed for rout ing I SO CLN P packet s, t o be used for I P rout ing.

7:

How does t he TLV Type 133 specified by RFC 1195 differ fr om t he or iginal aut hent icat ion TLV Type 10 specified by I S0 10589?

A:

TLV Type 1 3 3 does not place any rest rict ion on t he lengt h of t he aut hent icat ion TLV ( 2 5 5 oct et s in TLV 1 0 ) . Also, it does not specify aut hent icat ion Type 2 5 5 for rout ing dom ain privat e aut hent icat ion as in TLV 1 0 .

8:

Descr ibe any differ ences bet w een t he adj acency for m at ion pr ocesses on point -to-point and br oadcast link s.

A:

Point - t o- point adj acency form at ion is preceded by det ect ion of I SHs; also, reliabilit y is not built int o t he process because of t he lack of an I S N eighbor TLV field in point -t o- point hellos. A reliable t hree- w ay adj acency for point -t o- point links has been proposed in t he I ETF for st andardizat ion.

9:

Descr ibe t he t hr ee-way adj acency for m at ion pr ocess t hat has been pr oposed in t he I ETF t o enhance t he m et hod for for m ing adj acencies on point -t o-point links.

A:

The m et hod allow s for int roduct ion of a new TLV field ( 2 4 0 ) , w hich w ill include I S neighbor inform at ion in point -t o- point hellos. This inform at ion can t hen be used for a t hree- w ay handshake in t he adj acency form at ion process.

10:

What is t he relevance of t he pseudonode funct ionalit y?

343

A:

The pseudonode funct ionalit y is provided on broadcast m edia as a w ay t o cont rol flooding in such environm ent s. LSPs are m ult icast t o neighbors on such links, and t he DI S t hat act s as t he pseudonode facilit at es dat abase synchronizat ion over t he LAN by periodically m ult icast ing sum m aries of all know n LSPs. This allow s use of a less reliable but periodic m echanism t o alleviat e t he challenges of reliably advert ising LSPs a mong t he m any possible adj acencies on m ult iaccess or broadcast links.

11: A:

Briefly describe t he DI S elect ion and replacem ent process. DI S elect ion is by highest int erface priorit y w it h t he highest SN PA ( MAC address) as t he t ie breaker. Elect ion also is pre- em pt ive and any new ly connect ed rout er can t ake over t he DI S funct ions if it bet t er qualifies t o be t he DI S, a ccording t o t his crit eria .

12: A:

Ex plain w hy no ba ck up DI S ex ist s. A backup DI S is unnecessary because of t he periodic dat abase synchronizat ion on LAN m edia and t he short er hello int erval used by t he DI S, w hich allow s for fast det ect ion of any failures and subsequent replacem ent .

Chapter 4

1:

What does t he acr ony m NSAP r epr esent and w hat is an NSAP used for ?

A:

N SAP m eans net w ork service access point . This is OSI t erm inology for a net w ork layer address. N SAP addresses provide t he foundat ion for rout ing dat agram s in a CLN P net w ork, and I S- I S funct ions are designed around N SAPs. Therefore, I P rout ers need t o be configured w ith NSAPs w hen using I S- I S for I P rout ing.

2:

What ar e t he t hr ee m aj or com ponent s of an NSAP? Descr ibe t he significance of each .

A:

The t hree com ponent s are area address ( area I D) , syst em I D ( SysI D) , and t he N SAP select or ( N SEL) . The area address ident ifies t he nat ive area of a net w ork node and helps det erm ine t he t ype of adj acencies one node form s w it h anot her. The SysI D is a unique ident ifier of a node w it hin an I S- I S area. The N SEL det erm ines t he higher level user of t he net w ork service t hat packet s m ust be delivered t o for processing at a node. The value of t he N SEL is 0 x0 0 for t he rout ing layer.

3:

What is t he m ax im um lengt h of an NSAP and w hat is t he m inim um lengt h t hat can be configured on a Cisco rout er?

A:

The m axim um lengt h of an N SAP is 1 6 0 bit s ( 2 0 byt es) . The m inim um size t hat can be configured on a Cisco rout er is 8 bytes. The 8 bytes includes 1 byte of N SEL, 6 bytes of SysI D, and 1 byte of area I D. H ow ever, it is recom m ended t hat t he AFI st ands apart from t he act ual area value in t he area I D. Therefore, 9 byt es m akes m ore sense w here 2 byt es are allocat ed for t he area, one of w hich is t he AFI .

4:

What 's t he AFI field in an NSAP, and w hat is it s significance?

A:

AFI st ands for address and form at ident ifier. The AFI designat es t he t op- level address dom ain t o w hich t he N SAP belongs and also defines t he synt ax ( binary, decim al, or charact er) of t he dom ain- specific part of t h e N SAP.

5:

How m any OSI t op-layer address dom ains exist ? List t hem .

344

A:

6:

A:

There a re seven t op- layer OSI addressing dom ains:

•

X .1 2 1 — I nt e r na t iona l pla n for public da t a ne t w or k s

•

I SO D CC— Da t a count ry code

•

F.6 9 — Te le x

•

E.1 6 3 — Public Sw it che d Te le phone ne t w or k

•

E.1 6 4 — I SD N

• •

I SO 6 5 2 3 — I nt erna t iona l code designa t or ( I CD) for or ga niza t ions Loca l— For loca l u se on ly w it h in a n e t w or k dom a in

Associat e t he follow ing addr esses w it h one of t hese t op -level addr ess dom ains: 1.

3 9 .0 0 0 5 .1 1 0 0 .2 2 0 0 .4 3 2 A.2 6 CD .0 0

2.

4 7 .0 0 0 1 .2 2 1 1 .3 3 1 1 .5 5 6 6 .ACD 7 .2 3 5 1 .0 0 AC.2 1 0 7 0 0

You can associat e an N SAP address w it h one t op- level dom ain from t he value of it s AFI , w hich is t he left m ost byt e in t he address:

7:

1.

AFI va lue of 3 9 is I SO D CC.

2.

AFI va lu e of 4 7 is I SO 6 5 2 3 ( I CD ) .

How m any by t es of t he NSAP ar e allocat ed t o t he Sy sI D on a Cisco r out er ? What is t he v alue specified by I SO 10589?

A:

Cisco follow s t he convent ion specified by t he US GOSI P version 2 st andard, w hich requires 6 byt es for t he syst em I D field. I SO 1 0 5 8 9 specifies a range of 1 t o 8 byt es.

8:

I S-I S has t w o levels of r out ing, Level 1 and Level 2. Elabor at e on t he r ele vance of t he m aj or fields of t he NSAP t o t hese r out ing levels in t he I SO CLNS envir onm ent .

A:

Level 1 rout ing is based on only t he Syst em I D field in t he N SAP, w hereas Level 2 rout ing uses only t he Area field. On a Cisco rout er, t he com bined lengt h of t he Syst em I D and N- Select or fields is alw ays 7 byt es, so t he area address can easily be discerned as t he rem ainder of t he N SAP aft er st ripping t he t railing 7 byt es.

9:

List som e of t he r equir em ent s and cav eat s for defining t he sy st em I D on a dev ice.

A:

The syst em I D of all nodes in t he rout ing dom ain m ust have t he sam e lengt h. On Cisco rout ers, t he system I D length m ust be 6 bytes.

Each node in an area m ust have a unique syst em I D.

10:

How m any NSAPs can you have per r out er accor ding t o I SO 10589? What is t he purpose of having m ore t han one NSAP per rout er?

A:

According t o I SO 1 0 5 8 9 , a rout er can have up t o t hree N SAPs, all of w hich m ust use t he sam e syst em I D

345

a nd 0 x 0 0 for t he N- select or but different area prefixes. Mult iple N SAPs per rout er m ight be necessary for renum bering N SAPs in an area or dom ain, part it ioning an area or m erging different areas in a net w ork dom ain.

11:

What does SNPA st and for and w hat is it s r elev ance in t he I S-I S r out ing env ir onm ent ?

A:

SN PA st ands for subnet w ork point of at t achm ent . I t has no relevance t o t he Subnet w ork Access Point ( SNAP) field a ssocia t ed w it h t he Et hernet 8 0 2 .3 SN AP fra m e form a t . SN PA is t he I SO na m e for a da t alink address, such as a MAC or a Fram e Relay DLCI address. Layer 3 rout es point t o an out going dat alink int erface t hat is also described by it s address, t he SN PA.

12:

I dent ify t he ar ea addr ess, SysI D, and NSEL values in t he follow ing addr ess:

A:

4 7 .0 0 5 .8 0 0 1 .4 4 3 E.AB1 1 .BD4 8 .0 C1 F.0 0

The NSAP address com ponents are as follow s:

Area: 4 7 .0 0 5 .8 0 0 1 .4 4 3 E

Syst em I D: AB1 1 .BD4 8 .0 C1 F

N- select or: 0 0

Chapter 5

1:

What t ype of infor m at ion is st or ed in an Lin k-St at e dat a base, and how is t his inform at ion collect ed?

A:

There a re t w o t ypes of Link - State databases in I SI S, Level 1 and Level 2 . These dat abases st ore link- st at e packet s, w hich are generated by routers in an area or t he backbone, respect ively, and spread out by a process called flooding.

2:

Descr ibe t he use of t he Link-St at e dat abase in I S-I S.

A:

As a lin k - state protocol, I S- I S requires each rout er in an area t o have t he sam e view of t he area's t opology. The Link- State database contains LSPs from ot her rout ers in t he area and describes t he t opology of t he area. Each rout er bases it s route ca lcula t ion on t he inform a t ion in t he Link - St at e dat abase. The rout e calculat ion is done using t he short est pat h first ( Dikj st ra) algorit hm .

3:

What is t he differ ence bet w een Level 1 and Lev el 2 Link-St at e dat abases?

A:

The Level 1 Link- St at e dat abase describes a single I S- I S area. I t cont ains only LSPs from t he rout ers

346

in t ha t a rea . A sepa ra t e Level 1 Link - St at e dat abase exist s for each area in an I S- I S dom ain ( if m ore t han one ex ist s) .

An I S- I S dom ain w it h m ult iple areas has a backbone, w hich int erconnect s t he areas. The Level 2 dat abase describes t he backbone and consist s of Level 2 LSPs from t he rout ers connect ed t o t he ba ck bone.

4:

What is t he m eaning of Link-St at e dat abase synchr onizat ion?

A:

Link - State database synchroniza t ion is t he process of using reliable or periodic flooding m echanism s t o ensure t hat rout ers in t he sam e area or t he backbone have ident ical Level 1 or Level 2 dat abases, respect ively.

5:

Descr ibe t he gener al for m at of a linkst at e pack et .

A:

A lin k - state packet is com posed of a 2 7 - byt e header and variable- lengt h TLV fields.

6:

List t he four fields in t he LSP header t hat adequat ely descr ibe t he LSP.

A:

LSP I D, Sequence N um ber, Rem aining Lifet im e, and Checksum fields.

7:

What are TLVs?

A:

TLV st ands for Type, Lengt h, and Value. TLVs are special inform at ion fields t hat are appended as necessary t o t he header of an I S- I S packet . Every t ype of I S- I S packet support s a specific set of TLVs. The sam e TLV t ype can be used in different I S- I S pa ck e t t ype s.

8:

List five TLVs t hat carry m et ric infor m at ion and w her e t hey ar e or iginally specified.

A:

I S- neighbor TLV ( I SO 1 0 5 8 9 )

I nternal I P Reachability TLV ( RFC 1 1 9 5 )

Ext ernal I P Reachabilit y TLV ( RFC 1 1 9 5 )

Ext ended I S Reachabilit y TLV ( RFC Draft )

Ext ended I P Reachabilit y TLV ( RFC Draft )

347

9:

What is t he form at of t he LSP I dent ifier ( LSPI D) ? Giv e an ex am ple.

A:

The LSPI D is com posed of t he syst em I D of t he originating router, a pseudonode num ber, and an LSP fragm ent num ber.

Exam ple: 0 0 0 .0 0 0 0 .0 0 0 1 .0 0 - 0 0 or RTA.0 0 - 0 0 , w here t he first 6 byt es represent t he syst em I D, t he sevent h byt e is t he pseudonode num ber, and t h e last byt e is t he LSP fragm ent num ber. I f I SI S dynam ic nam e resolut ion is enabled on t he rout er or CLN S host nam es are configured, t he syst em I D is replaced by t he host nam e of t he source rout er.

10:

A:

Nam e t he t ypes of m et r ic infor m at ion specified by I SO 105 8 9 . I SO 1 0 5 8 9 specifies four t ypes of m et rics: default , reliabilit y, m onet ary cost , and delay.

11:

What ar e t he lim it at ions of t he default m et r ic specified by I S0 10589?

A:

Only 7 bit s a re dedica t ed t o t he va lue of t he default m et ric, allow ing a m axim um value of only 6 3 unit s.

I n addit ion, t he m axim um m et ric for an ent ire pat h is 1 0 2 3 unit s. Even t hough t he default m et ric has a connot at ion of bandw idt h, it is not assigned aut om at ically based on t he int erface bandw idt h of a rout er.

12:

How ar e t he m et r ic lim it at ions of I SO 10589 addr essed by TLVs Type 22 and Type 135 recent ly proposed in t he I ETF I S-I S Wor k ing Gr oup?

A:

Beca use a ll w idely deployed I S- I S im plem ent at ions use only t he default m et ric, TLV Types 2 2 and 1 3 5 propose t he ext ension of t he defa ult m et ric field w it h t he fields of t he unused m et ric t ypes. The ex t ended defa ult m et ric field allow s larger m et ric values and provide m ore fle x ibilit y t o net w ork adm inist rat ors in designing and expanding t heir net w orks.

13:

What ar e sequence num ber packet s? List all t y pes.

A:

Sequence num ber packets cont ain LSP sum m ary TLVs and aid t he flooding process, as w ell as dat abase synchronizat ion. Tw o t ypes of sequence num ber packet s exist : com plet e sequence num ber

348

packet s ( CSN P) and part ial sequence num ber packet s ( PSN Ps) . CSN Ps cont ain sum m aries of all k n ow n LSPs. They are exchanged on point -t opoint links only once aft er t he adj acency is brought up. H ow ever, t hey are advert ised periodically on broadcast links by t he DI S. PSN Ps t hat norm ally cont ain sum m aries of a subset of k now n LSPs in t he a rea a re used t o request com plet e copies of LSPs on bot h point -t o- point links and broadcast links. PSN Ps are also used as acknow ledgm ent s on point -t o- point link s t o support reliable flooding.

14: A:

What ar e I S-I S m esh groups? I S- I S m esh groups are used t o lim it redundant flooding in N BMA environm ent s w it h point -t opoint subint erfaces and highly m eshed underlying PVCs.

15:

What is m axage and m axim um LSP regenerat ion int erval? List t he Cisco I OS com m ands t hat can be used t o change t heir v alues.

A:

Maxage specifies t he m axim um life span of an LSP, from t he t im e it is genera t ed a t t he source u n t il it expires.

The I OS rout er- level com m and m ax- lsp- int erval is used t o m odify t he value of m axage. The default value in Cisco I OS is 2 0 m inut es ( 1 2 0 seconds) .

Maxim um LSP regenerat ion int erval, also know n as t he LSP refresh int erval, is t he periodic int erval bet w een t he t im es at w hich a rout er m ust refresh it s LSP t hroughout t he w hole netw ork. LSP refresh occurs before m axage is reached. The I OS rout erlevel com m and lsp- r e fr e sh- int erva l is used t o m odify t his t im er.

16:

Can t w o r out er s in t he sam e ar ea hav e t he sam e sy st em I D? Br iefly descr ibe w hat happens w hen t w o rout ers in t he sam e ar ea ar e configur ed w it h t he sam e syst em I D.

A:

N o. All rout ers in t he sam e area m ust have different syst em I Ds t o m ak e t hem unique so t hat packets sourced from t hem ( H ellos, LSPs, SN Ps) can be uniquely ident ified. W hen t w o or m ore rout ers in t he sam e area share t he sam e syst em I D, t heir LSPs get m ixed up and each rout er sees incorrect inform at ion in w hat seem s t o be it s LSP. The rout ers, t herefore, cont inuously t ry t o updat e

349

each ot hers LSP creat ing unnecessary resource consum ing churn in t he net w ork. An error is logged if LSP regenerat ion exceeds a frequency t hreshold.

Chapter 6

1:

What is t he basic applicat ion of t he SPF algor it hm ?

A:

The SPF algorit hm w as designed t o find t he short est dist ance bet w een t w o point s in any problem t hat can be m odeled as a graph.

2:

What is a dir ect ed gr aph, and how is an int er ne t w or k m odeled as a dir ect ed gr aph?

A:

A direct ed graph or digraph consist s of t he set of vert ices and t he set of int erconnect ions bet w een t he vert ices r e fe r r e d t o a s arcs or direct ed edges. An int ernet w ork is m odeled as a direct ed graph by represent ing t he net w ork nodes or rout ers as vert ices and t he net w ork links ( adj acencies) as arcs. Bidirect ional t raffic flow is depict ed by parallel opposit e arrow s.

3:

Nam e t he t hree list s used in t he operat ion of t he Dij kst ra algorit hm for com put ing I S-I S r out es.

A:

Pat hs, Tent at ive, and Unknow n.

4:

What is t he est im at ed pr ocessing cos t of t he Dij kst r a algor it hm ?

A:

The com put at ional cost direct ly dependent on t he com plexit y of execut ion of Dij kst ra algorit hm , w hich is of t he order, O( LlogN ) , w he re L is t he num ber of links and N is t he num ber of nodes.

5:

What is t he differ ence bet w een a full SPF and a par t ial r out e calculat ion ( PRC) ?

A:

A fu ll SPF is a com plet e com put at ion of t he short est pat h t ree ( SPT) caused by an adj acency change. PRC is a part ial com put at ion of t he SPF algorit hm and perform ed w hen only an I P prefix change is report ed in a new LSP.

Chapter 8

1:

What is t he m ain purpose and use of configur ing up t o t hr ee differ ent ar ea addr esses on a single rout er?

A:

You configure m ult iple area addresses w it hin a t ransit ion period w hen m igrat ing from one area address t o a not her.

2:

What is t he consequence of configur ing m or e t han one ar ea addr ess on a single r out er ?

A:

The Link - St at e dat abases of t he t w o areas are m erged, consequent ly m erging t he areas int o one.

3:

What is t he pur pose of t he t r a nsit ion k ey w or d w hen used w it h t he m et ric- st yle

350

com m and? A:

I t e n a ble s t h e r ou t e r t o advertise and accept both old- and new - st yle TLVs.

4:

How m any t y pes of hello pack et s ar e used on point -to-point int er faces on Cisco r out er s?

A:

Only a single hello packet

5:

What is t he pur pose of t he m esh- gr oup block e d com m and?

A:

I t block s LSP flooding on t he applicable int erface.

6:

What is t he default behavior of a m em ber w it hin a m esh gr oup?

A:

W it hin t he m esh group, an LSP received from a m em ber is not forw arded t o ot her m em bers of t he sam e group but forw arded t o nonm em bers.

7:

What is t he pur pose of t he dist ance com m an d?

A:

The dist ance com m and places an adm inist rat ive w eight , referred t o as adm inist rat ive dist ance, on rout es from a part icular rout ing prot ocol. The adm inist rat ive dist ance is used t o discrim inat e bet w een m ult iple inst ances of t he sam e rout e received from m ult iple rout ing prot ocol sources. The rout e w it h t he low est adm inist rat ive dist ance is preferred for insert ion int o t he rout ing t a ble.

8:

What pr ecaut ions m ust be t aken w hen configur ing m ut ual r edist r ibut ion bet w een I nt egr at ed I S-I S and ot her coexist ing I GPs?

A:

Configure rout e filt ers t o st op redist ribut ion feedback and elim inat e any possibilit y of rout ing loops.

9:

What cav eat m ust alw ay s be adher ed t o w hen r unning I S-I S for CLNS and I S-I S for I P in t he sam e ar ea?

A:

All rout ers w it hin t he area m ust be configured in a consist ent m anner so t hat t hey are I P- only, CLNS- only, or operat ing in dual m ode—bot h I P and CLN S. They are applied on a per- rout er basis and not per- interface basis.

Chapter 10

1:

List t he t w o m ain cat egor ies of I S-I S pr oblem s discussed in t his chapt er and pr ov ide ex am ples of each.

A:

Adj acency form at ion problem s ( for exam ple, m isconfigured I P int erface addresses) and rout e m aint enance problem s ( for exam ple, rout e advert isem ent problem s) .

2:

List t w o show com m ands t hat are useful for t roubleshoot ing adj acency problem s.

A:

show clns neighbors and show clns int erface

3:

List a debug com m and t hat pr ovides help in t r oubleshoot ing I S-I S adj acency pr oblem s.

351

A:

debug isis adj - packet

4:

What are LSP corrupt ion st orm s, and how do t hey im pact a net w ork's perform ance.

A:

LSP corrupt ion st orm s occur w hen LSPs are cont inuously corrupt ed by a m alfunct ioning device in t he net w ork; t he corrupt ed LSPs are purged from t he net w ork and t hen reflooded by t heir sources. This flooding and purging leads t o a w ast e of net w ork bandw idt h and m ight cause high CPU ut ilizat ion in t he rout ers. I f CPU is cont inuously pegged high levels, t he rout ers m ight event ually run out of processing resources leading t o disrupt ion of net w ork services.

5:

Describe t he m et hodology for t roubleshoot ing an LSP corrupt ion st orm .

A:

Because t he rout ers in t he net w ork m ight already be overloaded, debugging is used as a last resort . You can use t he show process cpu com m and t o t rack CPU ut ilizat ion, and you can use show isis spf log t o det erm ine t he LSPs responsible for any SPF churns. A t rail can t hen be follow ed t o det erm ine t he locat ion of t he culprit device t hat is corrupt ing LSPs.

352